How to manually trigger scan and install for Windows Server 2016, Windows Server 2019 and Windows Server 2022 with USOClient.exe?

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.

To know more about USOClilent.exe, refer to my another article here – https://sccmpeek.wordpress.com/2020/05/01/wuauclt-and-usoclient/

Client computers show up in Unknown tab in Deployment status after updates deployment

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.

03-22-2022 03:07:45.477    CommonDataAccess.SetSecureChannelProtocols    6 (0x6)    SCHANNEL Protocol 'TLS 1.2' 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.

WUServer:https://contososup.test.lab:8531
WUStatusServer:https://contososup.test.lab:8531

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

  1. Go to SCCM console
  2. Navigate to the Software Update Point
  3. Right click on it and then on Properties
  4. Select General tab
  5. Uncheck Require SSL communication to the WSUS server

References

20H2 feature update download failed with 0x80D02002

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.asmx
01-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.asmx
01-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.asmx
01-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

This link http://172.15.2.81:8530/Content/CF/A3AB52924275C34D9A6B4B6A10891438984BEFCF.esd returned also 404 on the client computer.

Going to the WSUS content directory, I found that the esd file was well and sound there. This is a common issue caused by esd MIME type missing.

Solution:

  1. Go to the WSUS server
  2. Open IIS Manager
  3. Navigate to WSUS Administration, then Content
  4. On the right panel, click on Add to add esd MIME type:
  • File name extension: .esd
  • MIME type: application/vnd.ms-cab-compressed

5. In the end, restart IIS by running in an elevated CMD:

IISRESET

References

How to install out of band Windows update?

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.

What is an out-of-band Window update? To put it simple, “An out-of-band patch is a patch released at some time other than the normal release time. Microsoft, for example, normally releases patches on the second Tuesday of every month.

There are three possible ways to install KB5001567 .

Release ChannelAvailableNext Step
Windows Update and Microsoft UpdateYesGo to Settings Update & Security > Windows Update. In the Optional updates available area, you’ll find the link to download and install the update.
Microsoft Update CatalogYesTo get the standalone package for this update, go to the Microsoft Update Catalog website.
Windows Server Update Services (WSUS)NoYou can import this update into WSUS manually. See the Microsoft Update Catalog for instructions.

For details, refer to – March 15, 2021—KB5001567 (OS Builds 19041.868 and 19042.868) Out-of-band (microsoft.com)

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.

Demo steps –

  1. Create folder C:\temp
  2. Download the Update to C:\temp directory  (KB5001638 download path: http://download.windowsupdate.com/d/msdownload/update/software/updt/2021/03/windows10.0-kb5001638-x64_64937e493ea9574759536d4b2695c05dfa5543e3.msu )
  3. Expand the .msu file to extract the .cab file by running below command in CMD:

   expand -F:* C:\temp\windows10.0-kb5001638-x64_64937e493ea9574759536d4b2695c05dfa5543e3.msu C:\temp

  1. Copy windows10.0-kb5001638-x64_64937e493ea9574759536d4b2695c05dfa5543e3.cab along with other expanded files to a shared path (that is, copy all the extracted files)
  2. Use the following DISM command to install the update:

    dism /online /add-package /packagepath:\\<Shared-Path>\windows10.0-kb5001638-x64_64937e493ea9574759536d4b2695c05dfa5543e3.cab

If you want to use GPO to save efforts in case of too many computers –

  1. Create a bat file and put the command at step 5 in it and save the bat file.
  2. Then, use GPO startup script to run batch file. Refer to – Using Startup, Shutdown, Logon, and Logoff Scripts in Group Policy | Microsoft Docs

References

Third-party updates download failed with 0x80073633

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

Error Code: 0x3633 (13875)
Error Name: ERROR_IPSEC_IKE_INVALID_SIG
Error Source: Windows
Error Message: Invalid certificate signature

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.

  1. Copy the .CAB file (download it from http://aaa.bbb.ccc:8530/Content/D8/63B1ED2921E30447184094523CA4A1C005F9D5D8.cab ) to the machine running the ConfigMgr console if failing to download via console
  2. Right click on it and review the Certificate Path, and review if there are any trust errors. Figure 1
  3. 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).
  4. After that third-party updates downloading succeeded. Figure 3.

Figure 1

Figure 2

Figure 3

References

Maintenance Window types in Configuration Manager

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

Here is a list of maintenance window types –

VALUESERVICE WINDOW TYPEDESCRIPTION
1ALLPROGRAM_SERVICEWINDOWAll Programs Service Window
2PROGRAM_SERVICEWINDOWProgram Service Window
3REBOOTREQUIRED_SERVICEWINDOWReboot Required Service Window
4SOFTWAREUPDATE_SERVICEWINDOWSoftware Update Service Window
5OSD_SERVICEWINDOWOSD Service Window
6USER_DEFINED_SERVICE_WINDOWCorresponds to non-working hours.

References

https://docs.microsoft.com/en-us/previous-versions/system-center/developer/jj155419(v=cmsdk.12)?redirectedfrom=MSDNhttps://docs.microsoft.com/en-us/previous-versions/system-center/developer/jj155419(v=cmsdk.12)?redirectedfrom=MSDN

All WSUS clients fail to connect to WSUS server for updates – 0x8024401f

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:

2020-05-28 17:26:02:714 776 1120 WS WARNING: Nws Failure: errorCode=0x803d000f
2020-05-28 17:26:02:714 776 1120 WS WARNING: …………http://x.x.x.x/ClientWebService/client.asmx………………………………………
2020-05-28 17:26:02:714 776 1120 WS WARNING: ……………… HTTP ……………500 (0x1F4)………………System.ServiceModel.ServiceActivationException……
2020-05-28 17:26:02:714 776 1120 WS WARNING: ……………………………

I tried to visit http://x.x.x.x/ClientWebService/client.asmx (you need to enable trace in iis) from the client and it showed the following in the browser:

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:

  1. Delete the site from IIS Administration
  2. Open CMD as admin
  3. 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

How to Check for a Pending Reboot on a host with SCCM client installed

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
NAMESPACECLASSPROPERTYVALUEPRODUCTNOTES
ROOT\ccm\ClientSDKCCM_ClientUtilitiesDetermineifRebootPendingRebootPendingSCCMReturnValue needs to be 0 and this value is not null
ROOT\ccm\ClientSDKCCM_ClientUtilitiesDetermineifRebootPendingIsHardRebootPendingSCCMReturnValue 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.

Invoke-WmiMethod -ComputerName localhost -Namespace "ROOT\ccm\ClientSDK" -Class "CCM_ClientUtilities" -Name DetermineIfRebootPending | Select-Object -Property PSComputerName,RebootPending

PSComputerName RebootPending
—————————— ————————-
D00155DD61A6F False

You can also replace localhost with a real computer name to verify a remote host.

References

Logs to collect for Windows Update

Windows Update functionality often runs into trouble. When Windows Update issue happens, we can collect the following logs for analysis.

WindowsUpdate.log

  • Windows 10, Windows Server 2016: Open Powershell and run (file will be save on the desktop):
Get-WindowsUpdateLog

Or just get the logs under C:\Windows\Logs\WindowsUpdate

  • Windows 7/8/2008/2012: C:\Windows\WindowsUpdate.log

ReportingEvents.log

C:\Windows\SoftwareDistribution\ReportingEvents.log

Event logs

Applicatioin.evtx and System.evtx in C:\windows\system32\winevt\logs

If it is related to software update management in Configuration Manager, this article KB4505440 from Microsoft Knowledge Base should be helpful.

References

Remove WSUS settings and restore Windows Update default

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

  1. Click Start and open PowerShell as Administrator (Right Click > Run as Administrator)
  2. Stop the Windows Update Service by entering the command:
    Stop-Service -Name wuauserv
  3. Remove the Windows Update registry key by entering the command:
    Remove-Item HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate -Recurse
  4. Finally, restart Windows Update Service by running: Start-Service -Name wuauserv

Remove WSUS Settings Manually

  1. Click Start and type regedit into the start search box, then Right Click and Run as Administrator.
  2. Navigate to HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\
  3. Right Click and Delete the registry key WindowsUpdate, then close the registry editor.
  4. Open the Services Console by entering services.msc in the start search box.
  5. Find and restart the Windows Update Service
Design a site like this with WordPress.com
Get started