Link to home
Start Free TrialLog in
Avatar of Firstcom
Firstcom

asked on

Windows Updates are not deploying to clients from a new SCCM Current Branch server

Our previous environment was with Config Manager 2012R2.  We had a CAS and two primaries.  Those three servers are in readonly mode due to Microsoft trying to fix an issue we had with replication.  Microsoft cannot fix the issue or get them back out of readonly mode.  I have spun up another SCCM server and have installed Current Branch onto it.  I am using just a Primary site, as we do not need a CAS or the 2nd primary.  I have pushed out the client with the new SiteCode to 9 test computers, successfully.  I have created two packages and deployed them successfully to one of the test machines.  

I have set up a Software Update Point on the new Current Branch server.  I have the sync settings set to Synchronize from Microsoft Update.  The updates synced yesterday (it took 4.5 hours).  However, when I deploy to the clients, the WUAHandler.log displays the following entries:
4/27/2017 10:09:45 AM      Its a WSUS Update Source type ({91AF792C-F745-433A-8D97-A7E0344FAF1E}), adding it.      WUAHandler      4864 (0x1300)
4/27/2017 10:09:45 AM      Enabling WUA Managed server policy to use server: http://ConfigManager16.firstcom.local:8530      WUAHandler      4864 (0x1300)
4/27/2017 10:09:45 AM      OS Version is 6.1.7601      WUAHandler      6896 (0x1AF0)
4/27/2017 10:09:45 AM      Waiting for 2 mins for Group Policy to notify of WUA policy change...      WUAHandler      4864 (0x1300)
4/27/2017 10:09:51 AM      Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://127.0.0.1:1550 and Policy ENABLED      WUAHandler      4864 (0x1300)
4/27/2017 10:09:51 AM      Failed to Add Update Source for WUAgent of type (2) and id ({91AF792C-F745-433A-8D97-A7E0344FAF1E}). Error = 0x87d00692.      WUAHandler      4864 (0x1300)

Our Group Policy administrator states that he believes that this setting is not set in any GPO.  I am unsure of where or what to check to get this going through.
ASKER CERTIFIED SOLUTION
Avatar of aravind anche
aravind anche
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Firstcom
Firstcom

ASKER

I renamed the Registry.pol and then reran the Software Updates Scan Cycle.  A new Registry.pol file was then created, but I get the same error messages in the WUAHandler.log

4/27/2017 10:53:58 AM      Its a WSUS Update Source type ({91AF792C-F745-433A-8D97-A7E0344FAF1E}), adding it.      WUAHandler      7632 (0x1DD0)
4/27/2017 10:53:58 AM      Enabling WUA Managed server policy to use server: http://ConfigManager16.firstcom.local:8530      WUAHandler      7632 (0x1DD0)
4/27/2017 10:53:58 AM      OS Version is 6.1.7601      WUAHandler      2188 (0x088C)
4/27/2017 10:53:58 AM      Waiting for 2 mins for Group Policy to notify of WUA policy change...      WUAHandler      7632 (0x1DD0)
4/27/2017 10:54:02 AM      Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://127.0.0.1:1550 and Policy ENABLED      WUAHandler      7632 (0x1DD0)
4/27/2017 10:54:02 AM      Failed to Add Update Source for WUAgent of type (2) and id ({91AF792C-F745-433A-8D97-A7E0344FAF1E}). Error = 0x87d00692.      WUAHandler      7632 (0x1DD0)

I will look through the article that you have provided a link to and will let you know my findings.
While looking at the article that you have provided, it states that I can try to "Use the same WSUS server as the Software Update Point for the SCCM as well".  It then states, "To configure the WSUS server and the software update point server to be the same server with the same port number as well so that both the group policy and the SCCM use the same server as the update point. To do this follow these steps:

1.    Configure the software update point to use a particular server and port #"

The only place I see the settings for this in the Software Update Point Component Properties is on the Sync Settings tab.  Currently, I have it set to Synchronize from Microsoft Update."

Are you wanting me to change it to "Synchronize from an upstream data source location (URL)" and then put in the value of "http://ConfigManager16.firstcom.local:8530"?
keep it to Microsoft update and try
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
DJ and Nagendra, thank you for your help.  It turned out to be a setting that another administrator had set to try and have Kaspersky Security Center to try and deploy Windows Updates after we had our previous SCCM environment go into readonly mode.  Once they disabled that, the values changed from localhost to the previous configuration manager URL.

I then either deleted the two entries in HKLM/software/policies/Microsoft/Windows/Windows Update/
that referenced the previous URL and when the entries came back, they had the new URL.  I also was able to directly edit them as well.

I am getting the following logs now after trying to deploy the updates last night (as the clients didn't fail, but didn't try to install them either).

4/27/2017 10:00:00 PM      CUpdateAssignmentsManager received a SERVICEWINDOWEVENT START Event      UpdatesDeploymentAgent      2936 (0x0B78)
4/27/2017 10:00:00 PM      Suspend activity in presentation mode is selected      UpdatesDeploymentAgent      2936 (0x0B78)
4/27/2017 10:00:00 PM      At least one user has elected to suspend non-business hours activity when in presentation mode. Checking for presentation mode.      UpdatesDeploymentAgent      2936 (0x0B78)
4/27/2017 10:00:00 PM      Proceeding to non-business hours activites as presentation mode is off.      UpdatesDeploymentAgent      2936 (0x0B78)
4/27/2017 10:00:00 PM      Auto install during non-business hours is disabled or never set, selecting only scheduled updates.      UpdatesDeploymentAgent      2936 (0x0B78)
4/27/2017 10:00:00 PM      A user-defined service window(non-business hours) is available. We will attempt to install any scheduled updates.      UpdatesDeploymentAgent      2936 (0x0B78)
4/27/2017 10:00:00 PM      Attempting to install 0 updates      UpdatesDeploymentAgent      2936 (0x0B78)
4/27/2017 10:00:00 PM      Unable to find CCM_PrePostActions.SiteSettingsKey=1.      UpdatesDeploymentAgent      2936 (0x0B78)
4/27/2017 10:00:00 PM      GetActions() did not succeed. 80070490.      UpdatesDeploymentAgent      2936 (0x0B78)
4/27/2017 10:00:00 PM      No actionable updates for install task. No attempt required.      UpdatesDeploymentAgent      2936 (0x0B78)
4/27/2017 10:00:00 PM      Updates could not be installed at this time. Waiting for the next maintenance window.      UpdatesDeploymentAgent      2936 (0x0B78)
4/28/2017 5:00:00 AM      CUpdateAssignmentsManager received a SERVICEWINDOWEVENT END Event      UpdatesDeploymentAgent      7020 (0x1B6C)
4/28/2017 5:00:00 AM      No current service window available to run updates assignment with time required = 1      UpdatesDeploymentAgent      7020 (0x1B6C)
4/28/2017 5:00:00 AM      Attempting to cancel any job started at non-business hours.      UpdatesDeploymentAgent      7020 (0x1B6C)

I am researching this and may just open another Experts Exchange thread on it.  It appears that I either don't have the setting exactly correct in the deployment, or I need to wait a bit longer, or I need to set up Business Hours/Maintenance Hours settings in SCCM somewhere.
open maintenance window, also check the wsus reg key
If you are ok  remove all the adr's and packages, remove the sup role, removing the wsus server role, delete the wsus database, then re-adding everything again from scratch, configure it exactly the same
I just now opened the maintenance window for this test collection of 5 PCs to be 23 hours 59 minutes long.

As for the WSUS Reg Key, I assume you are talking about:
HKLM/software/policies/Microsoft/Windows/Windows Update/WUServer & 
HKLM/software/policies/Microsoft/Windows/Windows Update/WUStatusServer

Those two entries were changed yesterday to reflect the new URL of the new SCCM server.  They see the updates in the logs, but didn't install them due to the reason posted in the previous log.  If you would like, I can paste and requested log files to verify that I am correct in my thinking.  I would rather not have to go through removing and reading everything from scratch, as I believe I am really close to getting this fixed.
those are the keys
I won't have time to work on this further for a week.  I am closing this, as we did get through the issue of the clients still trying to grab updates from the wrong server.