How to manually trigger scan and install for Windows Server 2016, Windows Server 2019 and Windows Server 2022 with USOClient.exe?
You may want to initiate scan and install for Windows Server 2019 and 2022. Your first reaction to achieve this may be to run USOClient.exe StartScan and StartInstall.
However, USOClient.exe StartScan and StartInstall does NOT work on Windows Server 2022. For Windows Server 2022, you need to run USOClient.exe StartInteractiveScan, which will trigger scan and install for updates deployed with or without deadline.
For Windows Server 2019, you can still user USOClient.exe StartScan to trigger scan while StartInstall to trigger install. Alternatively, you can also simply use USOClient.exe StartInteractiveScan to trigger both.
For Windows Server 2016, just use USOClient.exe StartScan and StartInstall to trigger scan and install respectively. StartInteractiveScan does NOT work for Windows Server 2016.
Client computers show up in Unknown tab in Deployment status after updates deployment
One of the most common issues you ever come across is that client computers stay in Unknown tab in Deployment status in SCCM console. There are several reasons for this:
The client computer is turned off
The client computer is considered inactive by SCCM, though it is running actually as you observed
The client computer has an issue with updates scanning
The last probability is most seen. Recently I ran into such an issue caused by problematic updates scanning.
ScanAgent.log shows the following messages.
03-21-2022 16:43:40.123 ScanAgent 2928 (0xb70) ScanJob({383C1CD8-0555-44E4-A96A-551EA38718F6}): CScanJob::OnScanComplete -Scan Failed with Error=0x80240437
03-21-2022 16:43:40.139 ScanAgent 2928 (0xb70) ScanJob({383C1CD8-0555-44E4-A96A-551EA38718F6}): CScanJobManager::OnScanComplete- failed at CScanJob::OnScanComplete with error=0x80240437
0x80240437 means –
Error Code: 0x80240437 (2149844023)
Error Name: WU_E_PT_SECURITY_VERIFICATION_FAILURE
Error Source: Windows Update Agent
Error Message: There was a problem authorizing with the service.
This error code points out that the client has a communication security issue with the software update point. Looks like the client was rejected by the software update point server.
LocationServices.log reveals the wsus server it was trying to connecting to.
03-21-2022 16:43:35.295 LocationServices 2928 (0xb70) Calling back with the following WSUS locations
03-21-2022 16:43:35.295 LocationServices 2928 (0xb70) WSUS Path='https://contososup.test.lab:8531', Server='contososup.test.lab', Version='4241', LocalityEx='BOUNDARYGROUP', SUPFallbackIn='0'
As you can see, the client was connecting to contososup.test.lab at port 8531. Testing the communication between the client and the software update point with TNC contososup.test.lab -Port 8531. All was good.
Then I captured two network trace files while triggering a Software Update Scan cycle from Configuration Manager client UI. The two network traces show the following interesting behaviour.
Client –
Server –
The client and server could establish TCP 3 handshake but failed with TLS 1.2 connection. At that moment, I suspected the server might not support TLS 1.2. However, SoftwareDistribution.log from the software update point server proved me wrong. The logs says TLS 1.2 is indeed enabled.
Remoting into the software update point server, I verified TLS 1.2 with IIS Crypto, a good free tool to check TLS settings.
What else to check? I launched WSUS console on the software update point server and caught sight of the following!
WSUS server was actually using port 8530 instead of 8531. Why the client was trying to connect at 8531? I went back to the client computer and check its wsus settings in the registry, which has the same information found in LocationServices.log.
As you know, SCCM sets local group policy to define WSUS settings. Is there something wrong about software update point role? With that thought, I went back to SCCM console and examined the software update point role settings. Voila, there is the answer: Require SSL communication to the WSUS server option is checked.
SOLUTION
Go to SCCM console
Navigate to the Software Update Point
Right click on it and then on Properties
Select General tab
Uncheck Require SSL communication to the WSUS server
20H2 feature update download failed with 0x80D02002
Issue: 20H2 feature update download failed with 0x80D02002
Windows update log has the following errors –
01-01-0001 00:00:00.000Â Â Â #55#[0]8960.7D9C::08/09/21-18:09:02.3541227 [WUTraceLogging] [Misc] Info=Got WSUS Client/Server URL: http://172.15.2.81:8530/ClientWebService/client.asmx01-01-0001 00:00:00.000Â Â Â #55#[0]8960.7D9C::08/09/21-18:09:02.3590630 [WUTraceLogging] [WebServices] Info=Proxy Behavior set to 1 for service url http://172.15.2.81:8530/ClientWebService/client.asmx01-01-0001 00:00:00.000Â Â Â #55#[0]8960.7D9C::08/09/21-18:09:02.3964267 [WUTraceLogging] [Misc] Info=Got WSUS Reporting URL: http://172.15.2.81:8530/ReportingWebService/ReportingWebService.asmx01-01-0001 00:00:00.000Â Â Â #55#[0]8960.4C20::08/09/21-21:00:54.1149752 [WUTraceLogging] [DownloadManager] Info=*FAILED* [80004001] Method failed [CAgentDownloadManager::CanRetryWithDifferentCDNForError:24396]01-01-0001 00:00:00.000Â Â Â #55#[0]8960.4C20::08/09/21-21:00:54.1149922 [WUTraceLogging] [DownloadManager] Info=DO job {D96EE675-7C64-47C9-BBA8-47BDB064AB78} failed, updateId = 87A4F644-BF21-422D-9778-9AACD2B36AF9.201, hr = 0x80D02002. File URL = http://172.15.2.81:8530/Content/CF/A3AB52924275C34D9A6B4B6A10891438984BEFCF.esd, local path = C:\Windows\SoftwareDistribution\Download\dcf11aeb8b625a215d88bf67bd90b9bb\19042.631.201119-0144.20h2_release_svc_refresh_CLIENTBUSINESS_VOL_x64FRE_zh-cn.esd, The response headers = HTTP/1.1 404 Not Found
One of my customers came across a “weird” issue that one Windows update KB5001567 refuses to show up in the WSUS console regardless of repeated synchronizations. With a little search on the internet, I found it to be an out-of-band Windows update.
There are three possible ways to install KB5001567 .
Release Channel
Available
Next Step
Windows Update and Microsoft Update
Yes
Go to Settings > Update & Security > Windows Update. In the Optional updates available area, you’ll find the link to download and install the update.
To install an out-of-band Windows update, another feasible alternative is to download and install it manually. Take this KB5001567for example. We can download it from Windows Catalog site and then install it on each computer by hand or via GPO.
Copy windows10.0-kb5001638-x64_64937e493ea9574759536d4b2695c05dfa5543e3.cabalong with other expanded files to a shared path (that is, copy all the extracted files)
Use the following DISM command to install the update:
Third-party updates download failed with 0x80073633
Days ago one of my customers reached out to telling me that he had a problem with third-party updates download, which always failed with 0x80073633 meaning
The background of the issue was that the was trying to download third-party (Intel) updates from within SCCM console.
Checking the PatchDownloader.log in %temp% directory on the computer where SCCM console is installed, I found the following information corresponding exactly to what he saw from SCCM.
11/6/2020 09:40:03 Software Updates Patch Downloader Download http://aaa.bbb.ccc:8530/Content/D8/63B1ED2921E30447184094523CA4A1C005F9D5D8.cab to C:\Users\smsadmin\AppData\Local\Temp\2\CABB8AA.tmp returns 0 11408 (0x2C90) 11/6/2020 09:40:03 Software Updates Patch Downloader Using machine settings for CRL checking. 11408 (0x2C90) 11/6/2020 09:40:03 Software Updates Patch Downloader Cert revocation check is disabled so cert revocation list will not be checked. 11408 (0x2C90) 11/6/2020 09:40:03 Software Updates Patch Downloader To enable cert revocation check use: UpdDwnldCfg.exe /checkrevocation 11408 (0x2C90) 11/6/2020 09:40:03 Software Updates Patch Downloader Verifying file trust C:\Users\smsadmin\AppData\Local\Temp\2\CABB8AA.tmp 11408 (0x2C90) 11-06-2020 09:40:03.332 Software Updates Patch Downloader 11408 (0x2c90) Authentication of file C:\Users\smsadmin\AppData\Local\Temp\2\CABB8AA.tmp failed, error 0x800b0004 11-06-2020 09:40:03.345 Software Updates Patch Downloader 20792 (0x5138) ERROR: DownloadUpdateContent() failed with hr=0x80073633
It failed because the client computer running SCCM console did not trust the root certificate of the CAB file. To resolve it, we need to import the root certificate into the trusted root store.
Right click on it and review the Certificate Path, and review if there are any trust errors. Figure 1
If the certificate shows any errors, you will need to export and import that root certificate into the machine’s trusted root store running the ConfigMgr console. Click on View Certificate (Figure 1) and import it into the trusted root store (Figure 2).
After that third-party updates downloading succeeded. Figure 3.
When reviewing ServiceWindowManager.log or RebootCoordinator.log you can see maintenance windows type information. For example,
RebootCoordinator.log:
Entered ScheduleRebootImpl – requested from ‘UpdatesDeploymentAgent’. set Rebootby = 1589774990. set NotifyUI = True. set PreferredRebootWindowType = 4  13228 (0x33AC) 5/18/2020 12:09:50 Scheduled reboot from agent UpdatesDeploymentAgent. Deadline local time: 05/18/2020 12:09:50 PM, PreferredRebootWindowType = 4            13228 (0x33AC) 5/18/2020 12:09:50 No CCM Identification blob 13228 (0x33AC) Not in Maintenance/Service Mode, check ServiceWindowsManager next    13228 (0x33AC) 5/18/2020 12:13:50 CheckRebootWindow: Service Windows found for type:4 13228 (0x33AC) 5/18/2020 12:13:50 ServiceWindowsManager has allowed us to Reboot       13228 (0x33AC) 5/18/2020 12:13:50 MTC task does not exist. Creating new request.              13228 (0x33AC) 5/18/2020 12:13:50 MTC allowed us to reboot   13228 (0x33AC) 5/18/2020 12:13:50 Raising client SDK event for class NULL, instance NULL, actionType 4l, value 1589774990              300        60, user NULL, session 4294967295l, level 0l, verbosity 30l           13228 (0x33AC) Notified UI grace period start with 300 grace seconds and 60 final seconds.  13228 (0x33AC) 5/18/2020 12:13:50 MTC task for reboot ‘fa76c245-5f82-41a3-a872-f73a90f6f0c4’. Checking if it can run now…              13228 (0x33AC) 5/18/2020 12:13:50 MTC allowed us to reboot   13228 (0x33AC) 5/18/2020 12:13:50 System reboot request succeeded.     13228 (0x33AC) 5/18/2020 12:13:51 Reboot initiated    13228 (0x33AC) 5/18/2020 12:13:51 User logoff notification received  12636 (0x315C) 5/18/2020 12:15:10Reboot Coordinator received a SERVICEWINDOWEVENT END Event          1564 (0x061C) 5/18/2020 12:15:16
All WSUS clients fail to connect to WSUS server for updates – 0x8024401f
The issue is that all the wsus clients suddenly fail to connect to wsus server for updates, the Windows Update window showing 0x8024401f error which means “Same as HTTP status 500 – an error internal to the server prevented fulfilling the request.“.
Looking into Windows Update log, the following exceptions caught my eyes:
Could not find a base address that matches scheme https for the endpoint with binding WebHttpBinding. Registered base address schemes are [http]
With this, I know that there is something wrong with IIS configuration. However, I could not find what went wrong after hours of struggling. To save time, I deleted WSUS Administration application (IIS Admin console>right click on WSUS Administration and select Remove) from IIS and reinstalled it via the steps below:
Delete the site from IIS Administration
Open CMD as admin
Navigate to C:\Program Files\Update Services\Tools and run: WsusUtil.exe postinstall CONTENT_DIR=C:\WSUS
If you use SQL Server for WSUS, run: WsusUtil.exe postinstall SQL_INSTANCE_NAME=”<SQLSVR_SERVER_NAME>” CONTENT_DIR=C:\WSUS
For example:
C:\Program Files\Update Services\Tools>WsusUtil.exe postinstall CONTENT_DIR=C:\WSUS Log file is located at C:\Users\Administrator\AppData\Local\Temp\tmpFA1D.tmp Post install is starting Post install has successfully completed
If you have Configuration Manager managed client host, there will be ROOT\ccm\Client namespace in WMI. Class SDKCCM_ClientUtilities has a properties with two possible values:
RebootPending
IsHardRebootPending
If you have Configuration Manager managed client host, there will be ROOT\ccm\Client namespace in WMI. Class SDKCCM_ClientUtilities has a properties with two possible values:
RebootPending
IsHardRebootPending
NAMESPACE
CLASS
PROPERTY
VALUE
PRODUCT
NOTES
ROOT\ccm\Client
SDKCCM_ClientUtilities
DetermineifRebootPending
RebootPending
SCCM
ReturnValue needs to be 0 and this value is not null
ROOT\ccm\Client
SDKCCM_ClientUtilities
DetermineifRebootPending
IsHardRebootPending
SCCM
ReturnValue needs to be 0 and this value is not null
You can use the following PowerShell command to verity the client host needs a reboot or not.
More often than not, it is difficult to tell whether Windows Update failure is caused by WSUS itself or by Windows operating system. In that case we may need to remove WSUS settings from the client and restore Windows Update default settings in order to find out where the problem resides.
More often than not, it is difficult to tell whether Windows Update failure is caused by WSUS itself or by Windows operating system. In that case we may need to remove WSUS settings from the client and restore Windows Update default settings in order to find out where the problem resides.
Here are two methods to achieve this.
Remove WSUS Settings via PowerShell
Click Start and open PowerShell as Administrator (Right Click > Run as Administrator)
Stop the Windows Update Service by entering the command: Stop-Service -Name wuauserv
Remove the Windows Update registry key by entering the command: Remove-Item HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate -Recurse
Finally, restart Windows Update Service by running: Start-Service -Name wuauserv
Remove WSUS Settings Manually
Click Start and type regedit into the start search box, then Right Click and Run as Administrator.
Navigate to HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\
Right Click and Delete the registry key WindowsUpdate, then close the registry editor.
Open the Services Console by entering services.msc in the start search box.