Microsoft has released an update to the Windows Update Agent (WUA) that is referred to as the WUA SelfUpdate. This update is intended to harden WUA to prevent malicious attacks such as the recent FLAME malware (http://www.wired.com/threatlevel/2012/06/flame-microsoft-certificate/). Microsoft has approached this update using a modified Controlled Release methodology. The exact criteria regarding the timeline is unknown. Microsoft has not made available a stand-alone installer or provided a hook through the WUA.api (which Kaseya leverages) to trigger the SelfUpdate.
At this time, not all Windows OS machines are eligible for the SelfUpdate. However, we have found that for those endpoints that are eligible for the SelfUpdate (as determined by Microsoft), those that are configured to download patches from the internet OR any patches that are tagged as “Internet-based Install Only” may fail to install. Both of these methods of installation leverage the Windows Update Agent on the local machine. This failure is attributed to the requirement by the Windows Update Agent to complete the SelfUpdate process before patches can be installed. The WUA.api cannot trigger the SelfUpdate. Therefore, these patches may fail on endpoints that are eligible for the SelfUpdate when WUA is used for installation.
The SelfUpdate is not a traditional patch. Traditionally, when a patch scan runs on a machine (whether that scan is called by Kaseya through the .api OR when a user or admin leverages the “Check for Updates” function within the local Windows Update/Automatic Update/Microsoft Update utility), WUA communicates with Microsoft to discover the patches that are missing from and applicable to the endpoint. WUA writes the results into c:\Windows\WindowsUpdate.log and, if Kaseya requested the scan, will hand the results to Kaseya’s patch .dll for Kaseya-specific processing. However, this self update process is not part of a typical patch scan. Instead, WUA is checking whether the update is needed prior to actually scanning for missing patches. In the WindowsUpdate log, the process looks similar to this (actual entries may vary based on the system, but the general information should be similiar):
2012-07-07 10:42:19:416 1136 e58 Setup Checking for agent SelfUpdate
2012-07-07 10:42:19:416 1136 e58 Setup Client version: Core: 7.5.7601.17514 Aux: 7.5.7601.17514
2012-07-07 10:42:19:416 1136 e58 Misc Validating signature for C:\Windows\SoftwareDistribution\WuRedir\9482F4B4-E343-43B6-B170-9A65BC822C77\muv4wuredir.cab:
2012-07-07 10:42:19:416 1136 e58 Misc Microsoft signed: Yes
2012-07-07 10:42:23:020 1136 e58 Misc Validating signature for C:\Windows\SoftwareDistribution\WuRedir\9482F4B4-E343-43B6-B170-9A65BC822C77\muv4wuredir.cab:
2012-07-07 10:42:23:020 1136 e58 Misc Microsoft signed: Yes
2012-07-07 10:42:23:035 1136 e58 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
2012-07-07 10:42:23:035 1136 e58 Misc Microsoft signed: Yes
2012-07-07 10:42:26:717 1136 e58 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
2012-07-07 10:42:26:732 1136 e58 Misc Microsoft signed: Yes
2012-07-07 10:42:28:074 1136 e58 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
2012-07-07 10:42:28:090 1136 e58 Misc Microsoft signed: Yes
2012-07-07 10:42:28:105 1136 e58 Setup Determining whether a new setup handler needs to be downloaded
2012-07-07 10:42:28:105 1136 e58 Setup SelfUpdate handler is not found. It will be downloaded
2012-07-07 10:42:28:105 1136 e58 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.6.7600.256"
2012-07-07 10:42:28:776 1136 e58 Setup Setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.6.7600.256" is applicable and needs to be downloaded.
2012-07-07 10:42:28:776 1136 e58 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256"
2012-07-07 10:42:28:823 1136 e58 Setup Setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256" is applicable and needs to be downloaded.
2012-07-07 10:42:28:823 1136 e58 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256"
2012-07-07 10:42:28:885 1136 e58 Setup Setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256" is applicable and needs to be downloaded.
2012-07-07 10:42:28:885 1136 e58 Setup SelfUpdate check completed. SelfUpdate is required.
After the SelfUpdate completes, the patch scan process proceeds. Again, this check for the SelfUpdate does not appear to run when the scan is requested by a third-party such as Kaseya. Rather, the check occurs when the Windows Update Agent locally creates a connection with Microsoft and when Windows Update policies are not implemented (Windows Update policies can be controlled using utilities such as Group Policy or Kaseya > Patch Management > Windows Auto Update. Details are available here: http://support.microsoft.com/kb/328010). This connection appears to occur when the endpoint is configured to get patch information automatically from Microsoft.
In previous updates to the Windows Update Agent, Microsoft has published a .cab file containing download URLs that allow third parties to trigger the SelfUpdate via the WUA.api (detailed here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa387285(v=vs.85).aspx). In one such update, Microsoft did not update the .cab file until the end of the controlled release, but a stand-alone installer was made available for download, which Kaseya was able to distribute to endpoints to force the update. With this release, Microsoft has not provided these tools which has left third-parties, including Kaseya, without a reliable way to trigger the SelfUpdate.
At this time, we have identified four potential work-arounds to the SelfUpdate issue. Each has some inherent benefits and considerations, and you may find a combination of these could benefit your environment. As we have additional information, and/or if we confirm any additional options to address this issue, we will provide an update.
OPTION 1: Attempt to force the SelfUpdate through custom Agent Procedures
The steps outlined below have proven successful in some, but not all, situations. We cannot at this time predict the components necessary to lead to 100% successful results. However, we do know the following:
***This process provides the high-level details necessary to create a set of custom Agent Procedures to backup then clear the necessary registry settings, attempt to force SelfUpdate, Reboot, then restore the registry settings to the original entries (a reboot prior to the restore is often, but not always, required).
*** Uses REG.exe available beginning on Windows XP (NOT available on Windows 2000!)
*** #workingDir# can be any directory
*** WUA version can be found in machines ptchscn2.xml file after a Kaseya patch scan
or in C:\Windows\WindowsUpdate.log
*** The latest WUA version (following a successful self-update) will be 7.6.7600.256
** Start the process to attempt a forced self-update
-- Backup the "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" registry node
REG.exe EXPORT "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" "#workingDir#\WinAU.reg"
-- Backup the "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU" registry node
REG.exe EXPORT "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU" "#workingDir#\WinAUPolicies.reg"
-- Stop the WUA service
NET STOP wuauserv
-- Delete specific Windows Update registry values
REG.exe DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /va /f
-- Delete Windows Automatic Update Policy keys
REG.exe DELETE "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /f
-- Add the necesary values (Windows Update configured to notify but no download/install)
REG.exe ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v AUOptions /t REG_DWORD /d 2 /f
-- Restart the WUA service
NET START wuauserv
-- Attempt to force selfupdate
-- Pause to give self-check and self-update time to complete (5 - 10 minutes ??)
PAUSE <configure appropriate pause time>
-- Reboot is sometimes required to complete self-update
** After reboot, restore registry to original settings
-- Delete Windows Update registry values set above
-- Restore registry backups
REG.exe IMPORT #workingDir#\WinAU.reg
REG.exe IMPORT #workingDir#\WinAUPolicies.reg
OPTION 2: Configure patches to install from a LAN share or the System Server
This option should allow most or all patches to install on endpoints. Distributable patches do not leverage WUA for installation. Only those patches that are tagged as “Internet-based Install Only” should continue to fail (until SelfUpdate is completed on the endpoint). To configure a LAN share, please complete the steps outlined in KKB000781. Alternatively, choose to install the patches via the KServer by configuring endpoints to use the Patch Management > File Source option of “Pulled from System Server”. If you choose to install patches via the System Server (KServer), ensure the Kaseya install drive has sufficient space to host patches for your environment. Also ensure your KServer has available resources – including RAM, processor, and bandwidth to account for the increased workload. For additional detail regarding File Source Configuration options and benefits and considerations of each, please review the Patch Management TechJam slide deck or Patch Management TechJam recorded presentation.
OPTION 3: Leverage Machine Update
Regardless of the File Source configuration, Machine Update will cause distributable patches to download to the endpoint (either from the internet or via the LAN share or System Server) to the endpoint’s defined working directory. Once downloaded, the patches are installed via command line. This process is the same as when an endpoint is configured to use a LAN share, but will allow those endpoints that are configured with a File Source of “Download from Internet” to bypass the WUA installation process and instead use the distributable file for install. Patches tagged as “Internet-based Install Only” will continue to fail if the SelfUpdate is needed but not present.
OPTION 4: Request User Assistance/Log on locally to endpoints
Request your users launch Windows Update/Microsoft Update on their local machines and run a scan for missing patches. This may not be a desirable option as it requires action on behalf of the end users and may lead to the installation of unintended patches. However, in some envrionments, admins may find this to be a suitable alternative. Launch the WUA Update client (the name will vary based on the Operating System, but should be called Automatic Update, Microsoft Update, or Windows Update) from the Program Menu or Control Panel. Instruct users to click the appropriate button to complete a Scan (if prompted, choose “Custom” not “Express”). The button name may vary based on the OS, but should be easily identifiable on the main screen of the update client. Running the local scan should force any eligible endpoint to complete the SelfUpdate.
KASEYA’S PLANS GOING FORWARD
Kaseya is actively monitoring for a stand-alone installer release from Microsoft, for an update to trigger SelfUpdate via the .api, and for the release of specific URLs that can be used to push the update via the .api. As soon as any of these become available from Microsoft, Kaseya will leverage the appropriate tools to assist with the SelfUpdate in a more streamlined fashion. Past releases of SelfUpdate by Microsoft have included at least one of these functions, and the Kaseya processes built utilizing those tools have been very successful. We are prepared to implement an integrated solution as soon as these key pieces are made available by Microsoft.