In some instances it is not necessary to update the wsusscn2.cab file on each acquisition. For instance, custom XML files are independent of the wsusscn2.cab file. Also, If you run multiple acquisitions on or after Patch Tuesday and the wsusscn2.cab file is current, the subsequent acquisitions can skip the download and extraction of the current wsusscn2.cab file until the next update.

 The following example is for custom XML files to acquire and manage third party content, however, the syntax to skip the wsusscn2.cab file can be applied to any acquire job.

 

 Copy the custom XML files into the data/PatchManager/patch/custom folder prior to acquisition. 

 

1.> Create a new custom acquisition job named custom. This can be reused to acquire custom content by updating the Bulletins with the bulletin ID’s to be acquired.

2.> In the Command Line Overrides section add the following syntax to disable the wsusscn2.cab file update. This will speed up the acquire process by bypassing the wsussnc.2cab file download and extraction.

 

-SKIP_WSUSSCNCAB_DOWNLOAD Y -SKIP_WSUSSCNCAB_EXTRACTION Y

 

3.> Enter the bulletins to be acquired separated by a comma. In this example we are using 2 custom bulletins to manage Notepad++ and FileZilla via Radia Patch Manager.

4.> Set Force and Replace to Y to automatically update the CSDB with the latest bulletin data. Only use Force and Replace set to Y when re-acquiring specific content, otherwise set both to N.

5.> Set acquire Microsoft patches to Yes.

6.> Run the acquire and check the CSDB editor for the bulletins.

Hi there, Is there a way to export the published packages in Radia.

There was some discussion at the Radia Summit about getting Radia to not prompt for a BitLocker PIN upon reboot. I thought I would share what we do.. We basically configure a "Post Connection Script" (EXBEXIT) in COP. As part of that we run this code. It is partial and written in Winbatch but I think you will get the point. Basically, it is determining if Radia will reboot. If so, it uses the Microsoft utilities to read if PIN and TPM are enabled. If so, it runs the code to disable the PIN entry for one reboot. The only drawback that we live with is if the user cancels reboot, the PIN will not be promoted for on the next reboot (which could be a while). However, our security team was fine with the risk as the device is still encrypted, there is just no PIN for one boot.

FileWrite(hLogFile,StrCat(DateTime(),@tab,"Reboot (RADSETUP.BOOTTYPE) is ",BootType))
if BootType <> "N"
 FileWrite(hLogFile,StrCat(DateTime(),@tab,"A reboot is required. Running command to determine if PIN should be disabled on next reboot"))

 ManageBDE =  StrCat(WinDir,"\system32\manage-bde.exe") ; Default Location for 32-bit via Radia
 if FileExist(StrCat(WinDir,"\sysnative\manage-bde.exe"))
  ManageBDE =  StrCat(WinDir,"\sysnative\manage-bde.exe") ; if 64-bit, this is the location
 endif

 if FileExist(ManageBDE)
  output = GetStdOut(StrCat(ManageBDE," -protectors -get c:"))
  if StrIndexNc(output,"TPM AND PIN",1,@FWDSCAN)
   FileWrite(hLogFile,StrCat(DateTime(),@tab,"TPM AND PIN Found"))
   RunShell(ManageBDE, "-protectors -disable c:", "", @HIDDEN, @WAIT)
   FileWrite(hLogFile,StrCat(DateTime(),@tab,"Disabled PIN entry for next boot"))
  else
   FileWrite(hLogFile,StrCat(DateTime(),@tab,"TPM AND PIN NOT Found, not running command to disable PIN"))
  endif
 else
  FileWrite(hLogFile,StrCat(DateTime(),@tab,"Can not find manage-bde (key bitlocker file)"))   
 endif
endif

 

In the service RCA_AGENT_0910_UPGRADE_WIN
(which comes with 9.1 media for client upgrade purposes)
contains a zstop for client version which is EDMGETV(ZMASTER,ZPKGRELI)>='V0910.20140131'
unfortunately, the version in ZPKGRELI for version 7.9.x (we have 7.9.6 and 7.9.8 clients) shows as
V796.20120220
V7 is NOT less than V09 and so the zstop takes effect, and the package does not install.

Before we reinvent the wheel to fix it..Has anyone already run into this and if so how did you deal with it?

Question

In Client Automation Enterprise (CAE), when running a dmabatch to sync the core with satellites, sometimes some changes are reflected for the PRIMARY.SECURITY Domain in the sync.log, even this domain is not in use.

Example:

ADD PRIMARY.SECURITY.FILE.AXXX

ADD PRIMARY.SECURITY.FILE.AXXX

ADD PRIMARY.SECURITY.FILE.AXXX

REP PRIMARY.SECURITY.PACKAGE.XXX

REP PRIMARY.SECURITY.PACKAGE.XXX

REP PRIMARY.SECURITY.PACKAGE.XXX

Answer

Everytime  the core server/ tomcat server is restarted, the default packages(SCAP, Vulnerability)  gets published into CSDB even though they already been published.

And  if this is done the first time dmasync just after the restart ,these logs gets generated though there is no usage or change of the security domain.

 This can be verify with below steps.

1) On core machine stop all the services except the Configuration Server and DCS service.

2) Run a dmabatch sync from satellite, and check logs. The logs will not contain any of primary.security domain changes as no default package data is published to core CSDB.

3) Start the core service/tomcat service and than do the dmabatch. the logs will have primary.security domain changes.

 This process is part of the design and this a expected behavior.

 

To avoid these repeated logs ,the promotion of the default paakcges should be stopped.

This can be achceived by:

 

1)Once these packages gets published into CSDB, If these packages gets removed from the priming folder, these promote will not happen again and again.

 

2) Stop tomcat server -2) Take backup of the <CA-installed dir>\VulnerabilityServer\content\priming\services

3) Remove the content from the <CA-installed dir>\VulnerabilityServer\content\priming\services folder.

4) Start tomcat server

Team,

Is there any best practice available to use the branch cache technology along with Radia or any third part tool recommended ?

Regards,

Vinod

To Recover the OpenLDAP database:

1.Stop the RCA Directory service service.

2.Open the command prompt and navigate to the directory

<InstallDir>\Directoryservice.

3.Run the following command:

db_recover -cef –h database\rmp

 

To Export the OpenLDAP database:

1.Stop the RCA Directory service service.

2.Open the command prompt and navigate to the directory

<InstallDir>\Directoryservice.

3.Run the following command:

slapcat –f slapd.conf –l openldapP.ldif

 

To Import the OpenLDAP database:

1.Stop the RCA Directory service service.

2.Rename the existing rmp folder.(<InstallDir>\Directoryservice\Database\rmp)

3.Create a new rmp folder.

4.Copy the DB_CONFIG file from the existing rmp folder to the new folder.

5.Open the command prompt and navigate to the directory <InstallDir>\Directoryservice.

6.Run the following command:

Slapadd –f slapd.conf –l openldapP.ldif

7.Restart the directory services.

Problem:

The following error appears in the logs and no October 2021 bulletins are being acquired. 

 

20211012 15:22:04 Error: can't read "bulletin_srvc_options(MS-KB5005635)": no such element in array
while executing
"split $bulletin_srvc_options($bname) "
(object "::Acquire::nEWMSFT0" method "::Acquire::NEWMSFT::get_srvc_filtered_bulletin_list" body line 14)
invoked from within
"get_srvc_filtered_bulletin_list"
(object "::Acquire::nEWMSFT0" method "::Acquire::NEWMSFT::convert_bulletins" body line 4)
invoked from within
"$p1 convert_bulletins"
20211012 15:22:04 Error: can't read "bulletin_srvc_options(MS-KB5005635)": no such element in array

 

Cause:

The Offline scan file format has changed.

 

Resolution:

Development is currently working on an official hotfix and a test hotfix is available. Please open a case with support and request the patch.tkd module. 

Starting with Radia 10 CP4, Software Download Manager is enabled by default. The Download Manager will download bits in the background using only radstgrq.exe and will not consume a Radia connect.

Refer to the 10.0CP4_Guides/New_Features_10.0_CP4.pdf starting on page 54 for detailed information on the new Software Download Management feature in CP4. 

Using preload=b initiates the background transfer of files to the endpoint.  

These instructions are for example WINDOWS_1903_ESD. This will deliver the Windows 10 install media to the end point in the background.  The Windows 10 ISO was extracted and published using basic component select mode. 

 

• Download the ISO, extract and publish the media. Example WINDOWS_1903_ESD

 

NOTE: After the service is published open the CSDB and set desired bandwidth throttling on the service.

 

 

• Assign WINDOWS_1903_ESD in Policy, NOTE: The service is set to Optional so it can be targeted using sname=WINDOWS_1903_ESD

 

• Create a preload background job or new timer instance to initiate the background transfer of WINDOWS_1903_ESD. Use sname=WINDOWS_1903_ESD and preload=b to enable the background transfer of the WINDOWS_1903_ESD service. Since this is a preload no radtray is available during this operation. The radstrgq.exe process runs while the transfer is running and will start and stop with system reboots, etc.

NOTE: Use DNAME=RADSTAGE or leave DNAME= off the command line so it will be automatically set to RADSTAGE.

Radskman.exe mname=radia,dname=RADSTAGE,uid=$MACHINE,ip=jlongoR11,port=3464,cat=prompt,cop=y,context=m,LOG=connect_preload_software.log,LOGSIZE=4096000,mnt=n,dname=radstage,sname=WIN10_1909_ESD,preload=b,rcsuri=tcp://jlongoR11:3464,datauri=http://jlongoR11:3466

 

• The service exists under the RADSTAGE folder

 

• The data is downloaded to the DATA folder

 

• After the preload completes create a new job or timer instance to build the media, note the preload=b has been removed.

Radskman.exe mname=radia,uid=$MACHINE,ip=jlongoR10,port=3464,cat=prompt,cop=y,context=m,LOG=connect_preload_software.log,LOGSIZE=4096000,mnt=n,sname=WINDOWS_1903_ESD,dname=software

 

• The new connect runs like a normal Radia connect and will display in the radtray.

 

• Once complete the media should exist in the expected folder.

 

• Review the new Download reporting in ReportingServer to see status of downloads for devices and services.

 

 

Radia Patch Manager users who do not use the metadata model will acquire patch data into the Acquisition server. This data is not automatically deleted after the acquire process publishes content into the CSDB. Over time this data can build into several hundred GB's.

NOTE:  MS-KB890830 (Microsoft Malicious Removal Tool) is a static bulletin ID so this data will be re-downloaded if deleted. For this reason the MS-KB890830 folder can be left in place. 

 Once this data is published to the CSDB the data can be deleted using the following steps.

• On the acquisition server, Navigate to the data/PatchManager/patch/Microsoft folder.
• Delete only the folders that contain the patch content. (Example: MS15, MS16, MS17, MS-KB).
• Do not delete the bulletins (.xml) or the wsus/wua folders.

 

  Radia 10 users, when running an acquisition via a command line there are a couple of new command line options including a new ARCH entry and Released date range to limit the acquired content.

I recently wrote a short article on LinkedIn and thought I would share it with the Radia community on this forum who may not be a part of the LinkedIn groups.

 

At Evergreen Systems we take security patching to the next level by developing custom Radia bulletins for our customers on demand.

With ZERO hour security patching you can have a Radia Patch Management solution in place within an hour of a critical security patch release.

Our custom bulletins don't require an updated wsusscn2.cab file. This is a huge advantage over the standard acquisition and deployment process since there is no need to run a 2 hour acquisition, and deployment of the 200MB+ wsusscn2.cab file before the enterprise can even start patching the enterprise. In some environments, it literally takes days to roll out the updated wsusscn2.cab file each month before patching can begin leaving the enterprise vulnerable for several days.

With ZERO hour patching from Evergreen Systems you can start patching the environment using Radia Patch Manager within hours of the critical security patch release.

For more information about our support offerings send an email to support@evergreensys.com

 

Our group is at a bit of a stalemate when it comes to adding OS level Zstops to all CSDB services.

We currently support over 800 applications and when a new OS comes out we can spend months testing all our applications on the new OS platform.  Unfortunately, and as an example; if the service currently has a WIN7 zstop on it we can’t quickly test the applications on WIN10. It’s a long process carefully adjusting Zstops on every application so they can even be tested. (We have to do this by exporting the .xpi files and opening them in notepad, changing the Zstop, and reimporting back into the system.) That way it doesn’t modify the date and time stamp of the service and force a reinstall of the software throughout the environment.  As another example, if the application ends up working on WIN10 we would typically add the new OS Zstop to the service and will be faced with the same problem later when WIN12 comes out. 

That means that our only other solution is to NOT add an OS Zstop at all unless the software just won’t work on a particular OS.  We’ve gone through many discussions on the pros and cons of adding the OS level Zstop to all software. The biggest pro of adding the OS Zstops is to prevent major catastrophes like blue screening every machine that has a particular software on a new OS. The major con of the OS Zstop is that it can take months of testing on the new OS. With hundreds of supported applications, it becomes a huge undertaking.   

I’m curious what other companies are doing and if they face the same pain points that we go through when a new OS enters the picture? Maybe there is some solution we aren’t even considering?

Can someone explain why/how the MySQL and Tomcat process are used on a Full Service Satellite. I had always understood these where part of the Core. However, I am seeing a bunch of stuff with netstat showing there is internal communication between some of these components during client connect. (SATLRCCDLIN549 is 127.0.0.1/localhost). I am running 9.1. TCP 127.0.0.1:3479 SATLRCCDLIN549:50604 ESTABLISHED [mysqld-nt.exe] TCP 127.0.0.1:3479 SATLRCCDLIN549:50605 ESTABLISHED [mysqld-nt.exe] TCP 127.0.0.1:3479 SATLRCCDLIN549:50607 ESTABLISHED [mysqld-nt.exe] TCP 127.0.0.1:3479 SATLRCCDLIN549:50608 ESTABLISHED [mysqld-nt.exe] TCP 127.0.0.1:3479 SATLRCCDLIN549:50609 ESTABLISHED [mysqld-nt.exe] TCP 127.0.0.1:3479 SATLRCCDLIN549:50610 ESTABLISHED [mysqld-nt.exe] TCP 127.0.0.1:3479 SATLRCCDLIN549:50611 ESTABLISHED [mysqld-nt.exe] TCP 127.0.0.1:3479 SATLRCCDLIN549:50612 ESTABLISHED [mysqld-nt.exe] TCP 127.0.0.1:3479 SATLRCCDLIN549:50613 ESTABLISHED [tomcat.exe] TCP 127.0.0.1:50605 SATLRCCDLIN549:3479 ESTABLISHED [tomcat.exe] TCP 127.0.0.1:50607 SATLRCCDLIN549:3479 ESTABLISHED [tomcat.exe] TCP 127.0.0.1:50608 SATLRCCDLIN549:3479 ESTABLISHED

I have patched around 40 machines in our environment using RCA but I want to know why the finalizing patch installation takes too much time. Also need to know about why I am getting too much errors on

Can anyone confirm or deny that there is/was a 255 path limit in the Batch Publisher? I think I remember this from long ago. It used to be a Windows problem. Now Windows addressed it, however, I think utilities still needed to be updated to work with the newer APIs. We are probably using an older version of it, so maybe it was addressed in a new release. We can likely work around it, or call it into support. Just looking to see if anyone else knows the answer off the top of their head.

Details from the error I am pretty sure because the path is over 255 for this file.

20160121 09:06:12 Error: Target <Q:/_AUTOPUBLISH/MDT_W8X64_ENT_WIN/V6.3.0.0/deployprod/Deploy/Operating Systems/Windows 8.1 Ent (x64) 2014.11.21/sources/sxs/amd64_netfx-system.directoryservices.protocols_b03f5f7f11d50a3a_6.3.9600.16384_none_3cdb1f0252010eb1/system.directoryservices.protocols.dll> does not exist
20160121 09:06:12 Error: could not read "Q:/_AUTOPUBLISH/MDT_W8X64_ENT_WIN/V6.3.0.0/deployprod/Deploy/Operating Systems/Windows 8.1 Ent (x64) 2014.11.21/sources/sxs/amd64_netfx-system.directoryservices.protocols_b03f5f7f11d50a3a_6.3.9600.16384_none_3cdb1f0252010eb1/system.directoryservices.protocols.dll": no such file or directory

RADIA customers are able to acquire MS15-093 out of band patch successfully through Radia Patch Manager.

After manually upgrading a 100 server infrastructure with the 8.10.0003 patch, why isn't there functionality in the RCA console to import a Satellite patch to the Core and execute the stage it to the satellites and remotely install it on the satellites?

You would have to have it done in stages: 1. Import the patch 2. Stage the patch to the satellite 3. Execute the patch. In my mind, the staging should be done in advance of installation and it should be done so in a fashion that it doesn't flood the WAN while it copies to the Satellite. Execution needs to be done separately due to the possible scheduling restrictions imposed by a Change Management system.

Also, patches shouldn't require manual installation for desired components. If I need the 8.10.0003 patch PLUS the OS Management components, I should be able to select this from the console and then have the system update itself when I tell it too.

Supression of Reboots would be a necessary component.

Centralized reporting of success, failure, pending-reboots, etc. would be needed.

It is long past time to giving us this feature for maintaining our RCA infrastructure.

I would like to better understand the use of these two tables. I understand HSAPSTATS is the history table for SAPSTATS. But how is the SAPSTATS table populated and with what information?

Hi,

Why does the Operations and Configuration tab does not show up for each Satellite servers under RCA console?

Browsing under Satellite Management for each satellite server there are different tabs available like Summary, Properties, Cache, Server Pools, Locations, Reporting, Operations and Configurations tab. We get an error while selecting Operations and Configuration tab alone ?

Screenshot attached.

Regards,

Vinod

Hi,

In Core/Satellite model, we have an option in RMP.CFG to enable/disable the SAP Automatic Management. If enabled it does two things 

1. Create SAP instances for any new Satellite server added in the environment

2. Create RPS_ User account under PRDMAINT.POLICY.USER class

 

So is there a way we can disable the user creation only and not the SAP instance creation ?

 

Regards,

Vinod

When logging in the Radia Console v.9.0, with an Active Directory (AD) user, a screen saying "E*rror Retrieving Capabilities*" is shown.

This happens because the account used to log in is in a different organization unit (OU), container (cn)  or groups than the one specified in the Authentication Group DN when creating the Directory Service, so please try to have the user in just one OU,CN or group.

If it is necessary for the user to be on several OU, CN, groups please contact PSL Support

Hi,

In 9.x Core Satellite Architecture - What kind of information would be send from Client Agent to the Core? Like we are not doing any OSM connects so what other information would be send. Can this be tracked ?

Regards,

Vinod

 

Microsoft has announced a smaller wsusscn2.cab file will be available in a temp location until March 2022 when the new smaller wsusscn2.cab file will be available in the default location. This workaround can be used to publish and distribute the smaller wsusscn2.cab while we investigate options to add this temp location in Radia. I have run through these steps using the new wsusscn2.cab in the lab and successfully acquired MS-KB5007186. If you have any questions or problems please open a case with support. 

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/announcing-a-smaller-wsus-scan-cab/ba-p/2928256

The smaller wsusscn2_new.cab file can be manually downloaded for Radia to use to publish and distribute to the Radia end points.

1.> Download the new wsusscn2_new.cab and rename the file to wsusscn2.cab
http://download.windowsupdate.com/microsoftupdate/v6/wsusscan/wsusscn2_new.cab

For data acquisition:
2.> Copy the wsusscn2.cab file to
C:\Program Files (x86)\PSL\RCA\Data\PatchManager\patch\microsoft
C:\Program Files (x86)\PSL\RCA\Data\PatchManager\patch\microsoft\wua

For metadata only acquisition:
2.> Copy the wsusscn2.cab file to
C:\Program Files (x86)\PSL\RCA\Data\PatchManager\patch\msft
C:\Program Files (x86)\PSL\RCA\Data\PatchManager\patch\msft\wua

3.> Add the following syntax to the acquire job, command line overrides section. 
-SKIP_WSUSSCNCAB_DOWNLOAD Y -SKIP_WSUSSCNCAB_EXTRACTION N

4.> Run the acquire job. The new smaller wsusscn2.cab file will be used to publish and distribute Security patch content in Radia.

Microsoft has released out-of-band security updates to address a critical Windows print spooler vulnerability. Persistent has created the following custom XML files to distribute the security patches. Please open a case with Persistent and request the required kb numbers.  

Windows Print Spooler Remote Code Execution Vulnerability

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527

 

Here are all the bulletins that have the July 2021 OOB patch. These are applicable to x86 and x64 systems. Please open a support case with the required kb numbers. 

Windows 7 and Windows Server 2008 R2
July 6, 2021 KB5004953 (Monthly Rollup) Out-of-band

2021-07 Security Monthly Quality Rollup for Windows 7 for x86-based Systems (KB5004953)
2021-07 Security Monthly Quality Rollup for Windows 7 for x64-based Systems (KB5004953)
2021-07 Security Monthly Quality Rollup for Windows Server 2008 R2 for x64-based Systems (KB5004953)

Windows 8.1 and Windows Server 2012 R2
July 6, 2021 KB5004954 (Monthly Rollup) Out-of-band

2021-07 Security Monthly Quality Rollup for Windows 8.1 for x86-based Systems (KB5004954)
2021-07 Security Monthly Quality Rollup for Windows 8.1 for x64-based Systems (KB5004954)
2021-07 Security Monthly Quality Rollup for Windows Server 2012 R2 for x64-based Systems (KB5004954)

Windows 10 1607 LTSB and Windows Server 2016
July 7, 2021 KB5004948 (OS Build 14393.4470) Out-of-band

2021-07 Cumulative Update for Windows 10 1607 LTSB for x86-based Systems (KB5004948)
2021-07 Cumulative Update for Windows 10 1607 LTSB for x64-based Systems (KB5004948)
2021-07 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5004948)

Windows 10 Version 1809/LTSB and Windows Server 2019
July 6, 2021 KB5004947 (OS Build 17763.2029) Out-of-band

2021-07 Cumulative Update for Windows 10 Version 1809 for x86-based Systems (KB5004947)
2021-07 Cumulative Update for Windows 10 Version 1809 for x64-based Systems (KB5004947)
2021-07 Cumulative Update for Windows 10 LTSB Version 1809 for x86-based Systems (KB5004947)
2021-07 Cumulative Update for Windows 10 LTSB Version 1809 for x64-based Systems (KB5004947)
2021-07 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5004947)

Windows 10 X64 Version 1909
July 6, 2021 KB5004946 (OS Build 18363.1646) Out-of-band

2021-07 Cumulative Update for Windows 10 Version 1909 for x86-based Systems (KB5004946)
2021-07 Cumulative Update for Windows 10 Version 1909 for x64-based Systems (KB5004946)

Windows 10 X64 Version 2004, 2009, 2104
July 6, 2021 KB5004945 (OS Builds 19041.1083, 19042.1083, and 19043.1083) Out-of-band

2021-07 Cumulative Update for Windows 10 Version 2004 for x86-based Systems (KB5004945)
2021-07 Cumulative Update for Windows 10 Version 2004 for x64-based Systems (KB5004945)
2021-07 Cumulative Update for Windows 10 Version 20H2 for x86-based Systems (KB5004945)
2021-07 Cumulative Update for Windows 10 Version 20H2 for x64-based Systems (KB5004945)
2021-07 Cumulative Update for Windows 10 Version 21H1 for x86-based Systems (KB5004945)
2021-07 Cumulative Update for Windows 10 Version 21H1 for x64-based Systems (KB5004945)

 

 

A Radia custom (XML) Patch service can be used to update an endpoint from Windows 10 2004 to Windows 10 2009 using the Windows 10 version 20H2 Enablement Package (KB4562830). This enablement package is a more efficient way of updating the operating system as it does not require the full Windows 2009 ISO image file to be deployed to the endpoints. The KB4562830 enablement package is approximately 86MB in size whereas the full Windows 10 20H2 ISO payload is approximately 4.8GB in size. Therefore, deploying the Windows 10 20H2 feature update using the enablement package requires far less network bandwidth during the upgrade process.

 

Prerequisites

You must have the following prerequisites installed before applying this update:

• Servicing stack update for Windows 10, version 2004: September 8, 2020 or a later servicing stack update
• October 13, 2020 KB4579311 (OS Build 19041.572) or a later cumulative update

In some instances, it is not necessary to update the wsusscn2.cab file on each acquisition. Custom (XML) Patch services are independent of the wsusscn2.cab file so the wsusscn2.download and extraction can be skipped when acquiring custom XML files. 

NOTE: To request custom patch services from professional services, please open a case with support with the kb number or third-party application name, OS and architecture. For instance, KB4562830, Windows 10 2004 x64. 

 

Instructions:

(Request a copy of the custom xml file MSC-KB4562830.xml from support.)

1.> Copy the custom XML file MSC-KB4562830.xml into the <InstallDir>\RCA\data\PatchManager\patch\custom folder prior to acquisition. 

2.> Create a new custom acquisition job named custom or use an existing acquire job. A sample configuration is shown in the screenshot below.

3.> Enter the Bulletin to be acquired: MSC-KB4562830. 

4.> In the Command Line Overrides enter the following syntax to skip the wsusscn2.cab file download and extraction.

      -SKIP_WSUSSCNCAB_DOWNLOAD Y -SKIP_WSUSSCNCAB_EXTRACTION Y

5.> Set “Acquire Microsoft Patches” to Yes.

6.> Run the acquisition from the Operations Tab in the console and check the CSDB editor for the bulletin MSC-KB4562830.

7.> Assign the MSC-KB4562830 service in policy to start updating Windows 2004 systems to Windows 2009(20H2) the KB4562830 enablement package.

 

 

Windows 10, version 1903 will reach the end of service on December 8, 2020. This applies to the following editions of Windows 10 released in May of 2019:

• Windows 10 Home, version 1903
• Windows 10 Pro, version 1903
• Windows 10 Pro Education, version 1903
• Windows 10 Pro for Workstations, version 1903
• Windows 10 Enterprise, version 1903
• Windows 10 Education, version 1903
• Windows 10 IoT Enterprise, version 1903