[SOLVED] Server 2022 - 21H2, build 20348.2700 - 0x80d02002 Windows update error

Hi @steyrs !

Looks like @Maxstar gave me the go ahead to reply directly to this thread. I may be a little slow on the responses as some recent projects have me quite busy! I am a full time SCCM sysadmin, so hopefully I can help you track down the root cause of your client's issues.

Some quick questions to give me an idea of what is going on.

Do you have the updates deployed to the collection the target server is located in?
Is this issue happening across your environment or only on this one system?
Are there any GPOs that determine the WSUS server location (sometimes this gets forgotten when switching to sccm)?
Will you be able to share client CCM logs?
Is the client in a boundary group?


If you are unsure on any of these, no problem! Based on your answers, Ill craft some commands for you to run.
 
Last edited:
Hello @Sunfish

Thank you for trying to troubleshoot this issue together with me.
Don't worry about response time - this is server acting as a jumphost - so it is not vital for production. It would be nice to have fixed though :)
I'm a full time SCCM sysadmin myself - but haven't been able to nail this one...

Do you have the updates deployed to the collection the target server is located in?
- Yes updates have been deployed to a collection containing this server.

Is this issue happening across your environment or only on this one system?
- Only on this one system (I have another server acting up - but that is a different animal)

Are there any GPOs that determine the WSUS server location (sometimes this gets forgotten when switching to sccm)?
- Yes - we have GPOs in place (screenshot attached)

Will you be able to share client CCM logs?
- Absolutely - let me know which ones you need.

Is the client in a boundary group?
- Yes it is.
 

Attachments

  • Policy-setting-sccm.png
    Policy-setting-sccm.png
    12.8 KB · Views: 4
@steyrs

So still reviewing the logs and want a spot check from @Maxstar before I offer a fix.

Just some information I am sure you are aware of, but I want to provide it just in case. Typically when SCCM is the primary driver for updates in a domain we do not want to set the WSUS location with GPO. If you have only one WSUS, then it can work out if your GPO points to your SUP / WSUS. However, if you have more than one SUP, you can encounter issues where GPO overrides the SCCM wanted location (especially in fallback scenarios). It can work but can also cause headaches. I understand that some organizations require the GPO be set, so if you can't for your environment I completely understand!

For more information please review: Manage settings for software updates - Configuration Manager
 
So I am seeing some errors in your WUAHandler.log and UpdateDeployment.log indicating the system is unable to read the WUA Group Policy object. The good news is that it does see the SUG containing the updates and the desired WSUS location. Ensure that your system is able to contact the DC if gpupdate fails.

Please rename the Registry.pol file, run a gpupdate, and kick off the actions to run a scan and eval of updates. If you encounter any issues or you do not see updates in software center after 30 minutes, please upload a fresh copy of the client-side logs.

Step 1
Rename Registry.pol File

  • Click on the Start button and in the search box, type Command Prompt
  • When you see Command Prompt on the list, right-click on it and select Run as administrator
  • When command prompt opens, copy and paste the following commands into it, press enter after each

Rich (BB code):
rename %SystemRoot%\System32\GroupPolicy\Machine\Registry.pol Registry.pol.bak

Step 2
Run gpupdate

  • Click on the Start button and in the search box, type Command Prompt
  • When you see Command Prompt on the list, right-click on it and select Run as administrator
  • When command prompt opens, copy and paste the following commands into it, press enter after each

Rich (BB code):
gpupdate /force

If a reboot is required, please reboot at this time.

Step 3

Run ConfigMgr Actions

  • Click on the Start button and in the search box, type Command Prompt
  • When you see Command Prompt on the list, right-click on it and select Run as administrator
  • When command prompt opens, copy and paste the following commands into it, press enter after each

Rich (BB code):
WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule "{00000000-0000-0000-0000-000000000113}" /NOINTERACTIVE
WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule "{00000000-0000-0000-0000-000000000114}" /NOINTERACTIVE
 
@steyrs

Just some information I am sure you are aware of, but I want to provide it just in case. Typically when SCCM is the primary driver for updates in a domain we do not want to set the WSUS location with GPO. If you have only one WSUS, then it can work out if your GPO points to your SUP / WSUS. However, if you have more than one SUP, you can encounter issues where GPO overrides the SCCM wanted location (especially in fallback scenarios). It can work but can also cause headaches. I understand that some organizations require the GPO be set, so if you can't for your environment I completely understand!

For more information please review: Manage settings for software updates - Configuration Manager
Hi Sunfish.
I haven't performed the original setup of this SCCM environment - so I'm not sure why it was decided to set the WSUS location with GPO (the setup is rather old - so maybe because of "best practice" back in the day?)
We only have one SUP - it's a rather small setup with +400 servers and +1600 clients - so maybe it's okay for now?
I will check out the link you provided - and discuss our setup with our consultant next time I meet him
 
Step 1
Rename Registry.pol File


Rich (BB code):
rename %SystemRoot%\System32\GroupPolicy\Machine\Registry.pol Registry.pol.bak

Step 2
Run gpupdate


Rich (BB code):
gpupdate /force

Step 3
Run ConfigMgr Actions

Rich (BB code):
WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule "{00000000-0000-0000-0000-000000000113}" /NOINTERACTIVE
WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule "{00000000-0000-0000-0000-000000000114}" /NOINTERACTIVE
Performed the 3 steps - no updates showing up.
Attached new logs (encrypted with the same password as before)
 

Attachments

Hi,

Could you please provide the following file for us to look at?

C:\Windows\System32\GroupPolicy\gpt.ini
 
Sure thing. Attached
Meanwhile - updates have finally shown up in Software Center (see attachment)
 

Attachments

  • gpt.zip
    gpt.zip
    298 bytes · Views: 2
  • Updates-in-Software-Center.PNG
    Updates-in-Software-Center.PNG
    139.2 KB · Views: 4
Glad your updates finally showed up! I guess it took a little longer than expected.
 
Yeah I guess so too :)
Nest step - advice a new maintenance window - to test if it will proceed updating.

Unless you have other suggestions to try first @Sunfish?
 
Depending on your deployment settings. Just make sure you give at least a 6hr maintenance window or the server will not have enough time to patch. I have seen smaller windows throw errors and the updates not kick off due to the maintenance window being too small.
 
Couldn't agree more.
I will set a new maintenance window with plenty of time, and lets see how it goes!
 
Sorry for the delay - other important work came up :)

Unfortunately - no dice - getting the updates installed.
As shown before there are plenty of updates pending - when checking the updates node in Software Center.
And when checking the installation status in Software Center i get the same updates showing there (no surprises)
However when I click "Upcoming" - to check the maintenance window - I get the date and time for the maintenance windows - however now there are now updates available.
Weird - never seen that before. (see the attachments)

Don't be fooled by the maintenance window date compared to when I write this update - I checked the server - the same day as the maintenance window occurred.

Nevertheless it just sat there - doing noting.
Suggestions @Sunfish ?
(maybe we should just ditch the server and install a new one)
 

Attachments

  • 1-updates-pending.webp
    1-updates-pending.webp
    108.7 KB · Views: 4
  • 3-after-click-upcoming-no-items-found.webp
    3-after-click-upcoming-no-items-found.webp
    39 KB · Views: 4
  • 2-installation-status-before-click-upcoming.webp
    2-installation-status-before-click-upcoming.webp
    119.7 KB · Views: 4
are you familiar with support center?

Support Center - Configuration Manager

It should be located in your installation files in the tool directory. Outside of a rebuild for this broken client, I would suggest taking a look with this tool.

You are able to see the maintenance windows from the client side and what types of things can be run in those windows.

Unfortunately I’m not in front of my PC till the weekend to give some commands to run.

The UpdateDeployment.log should have a line at the beginning of the window that indicates the window is starting. There is also the caveat that you must have a deadline set before a maintenance window for a window to work.

I think knowing your SUG deployment setting a would be usefull. I understand it’s working on other systems, but gotta rule it out in the troubleshooting process.

Using SCCM powershell commands from the site server would be the easiest, or you could take screenshots. We are looking for the deadlines and what the user experience is set too under the deadline behavior. Get-CMSoftwareUpdateDeployment would get the information. Target the deployment that contained the updates and is deployed to a collection with the system we are troubleshooting.
 
No I am not familiar with Support Center. (I have used the "old school" way of trouble shooting - checking log files using cmtrace instead.)
...but it definitely seems promising on my first test run - thanks for letting me know about it.

Before we dive into details - the server has finally started patching.
I have set a daily occurring maintenance window (very long time slot: 15 hours)
And after a couple of days it is finally on par with all other servers. (y)
So problem appears to be solved - Novembers rain of patches will tell soon enough...


So maybe the culprit was just not having enough time (within the previous maintenance window) to patch in the first place?

I had a look - with Support Center - at maintenance windows (see attachment)
The maintenance window at the top of the list with ID: 6636582E-3128....) is the daily occurring maintenance window

However there are 8 other maintenance windows
What are these?
If I search these IDs in the SCCM database - I come up empty handed.
A Google search does not really help either.

Do you know what these are Sunfish?
 

Attachments

  • Maintenance-windows-including-ids-not-to-be-found-in-db.webp
    Maintenance-windows-including-ids-not-to-be-found-in-db.webp
    89.1 KB · Views: 4
So, it looks like you have the correct idea with your deadline for October being before the maintenance window and it appears that the device is seeing the Maintenance Window based on your screen shot.

I'm glad that extending the window seems to have resolved your issue as well!

As for the other Maintenance Windows, I don't have a great answer for this. I assume that the user-based windows are the one's set in Software Center's option tab by the users for their business hours and the Update for business is some sort of baseline. I never needed to do a deep dive on the additional windows and only ever found out by using Support Center.

I am very happy you enjoy Support Center, it is so useful! I am always surprised how little it is used out in the wild.
 
Back
Top