Tag Archives: Software Updates

ConfigMgr CB 1610 Software updates dashboard

One of the nice new enhancements that came with the recently released 1610 update for ConfigMgr current branch is the Software Updates Dashboard. This dashboard is available in the Monitoring > Overview > Security section in the ConfigMgr console

If you haven’t installed update 1610 yet, here is what the dashboard looks like:

sudashboard01

WUAHandler.log – Scan failed with error = 0x80244019

In an SCCM Current Branch 1602 environment with a Server 2008 R2 Software Update Point (have not upgraded to Server 2012 R2 yet), in a different site I had about 120 clients at a specific site that were not successfully scanning for updates.

I usually run the built in report “Last scan states by collection” to make sure the clients are scanning for software updates without issues.

When checking WUAHandler.log on the client I saw the errors

OnSearchComplete – Failed to end search job. Error = 0x80244019.
Scan failed with error = 0x80244019.

0x80244019

If you look up the error 0x80244019 it means “Same as HTTP status 404 – the server cannot find the requested URI (Uniform Resource Identifier).”

One thing to check is that you can actually get to the WSUS server in an Internet browser by going to http://wsusserver.domain.com:8530/SimpleAuthWebService/SimpleAuth.asmx and making sure it is reachable. If it is reachable it should take you to a page saying:

0x802440192

In my issue it was the proxy between the SUP and my client. My client was trying to go through a proxy instead of bypassing it, then it was getting the 404 error from the WSUS.  There is also a good post on the Technet forums where people have had a bypass list which was lowercase, but in SCCM their SUP was in uppercase which caused the exact error. The post can be found here

In my site we are using a WinINET proxy script which sets the proxy for the Internet , and we also set the WinHTTP proxy. Our WinINET proxy had a bypass list for the WSUS server but our WinHTTP proxy did not for this specific site.

From Microsoft: https://support.microsoft.com/en-au/kb/900935

The Automatic Updates service does not have access to the user-specific proxy server settings that may be configured in Internet Explorer. WinHTTP has been employed, instead of WinInet in Internet Explorer, as the Automatic Updates service affects system wide level configuration and should require administrator level control

To view the current WinHTTP proxy and bypass list, load up cmd prompt and run:

netsh winhttp show proxy

To add the bypass list to your WinHTTP proxy, you can either set it manually through command prompt, or through group policy.

netsh winhttp set proxy proxy-server=”proxyserver.com:port” bypass-list=”*.domain.com;<local>”

The example above added a bypass list for a server <servername>.domain.com

Note: After setting the proxy through cmd using netsh winhttp or group policy, you must restart your computer before you do the next Software Update scan

After restarting the computer for the proxy settings to take affect and doing another Software Update evaluation scan on the client, the WUAHandler “Successfully completed scan.” on the clients.

 

 

 

Software updates not synchronizing – Sync failed: WSUS update source not found on site

I installed a trial of Configuration Manager 2016 Technical Preview 4 and set up and configured the Software Update point. I wasn’t able to synchronize any updates.

I checked wsyncmgr.log and saw Sync failed: WSUS update source not found on site
wsussource1

The workaround was to configure the Software Update Point and disable/remove all Classifications and Products and then to schedule another sync.

wsussource2
wsussource3
wsussource4

After this, I scheduled another sync, and the sync completed.

wsussource5

I then went back and re-configued the Software Update Point for the Classifications and Products I wanted, then scheduled another sync and it worked fine.

wsussource6

Software Update Compliance Issues – SCCM 2012

I had quite a few servers that were reporting incorrect compliance for Software Updates to our SCCM 2012 server. After doing Software Updates Scan Cycle on the client, the WUAHandler.log would always say successful. When doing a Software Updates Deployment Evaluation Cycle the log UpdatesDeployment.log said:

EnumerateUpdates for action (UpdateActionInstall) – Total actionable updates = 0

So if there were no updates available to be installed, why were my Software Update compliance reports showing the client as non-compliant and the Deployments in the Monitoring node in the console saying the client In Progress for a Software Update group deployment?

This blog post saved me http://blogs.technet.com/b/scotts-it-blog/archive/2015/02/23/refreshing-state-messages-in-system-center-configuration-manager-2012.aspx

This PowerShell script in the blog above forced my client to re-send its compliance to the SCCM 2012 server:

$SCCMUpdatesStore = New-Object -ComObject Microsoft.CCM.UpdatesStore
$SCCMUpdatesStore.RefreshServerComplianceState()

Then when checking UpdatesStore.log on the client:
Successfully raised Resync state message.
Resend status completed successfully.

I then checked the SCCM 2012 console in 15 minutes and the Deployments section in the Monitoring node showed the client as Successful instead of In Progress, and the SCCM 2012 update compliance reports showed the client as Compliant.

OnSearchComplete – Failed to end search job. Error = 0x80244019. Scan failed with error = 0x80244019.

Another day another scan issue on a Windows Server 2008 R2 with SCCM 2012 client installed.

When checking report of which clients had scan issues, I investigated a particular client which had the following error in WUAHandler.log “OnSearchComplete – Failed to end search job. Error = 0x80244019. Scan failed with error = 0x80244019.”

To get more information, I looked into C:\Windows\WindowsUpdate.log and found:

WARNING: GetAuthorizationCookie failure, error = 0x80244019, soap client error = 10, soap error code = 0, HTTP status code = 404
WARNING: Failed to initialize Simple Targeting Cookie: 0x80244019
WARNING: PopulateAuthCookies failed: 0x80244019
WARNING: RefreshCookie failed: 0x80244019
WARNING: RefreshPTState failed: 0x80244019
WARNING: PTError: 0x80244019
WARNING: Reporter failed to upload events with hr = 80244019.

Is this instance, it was a proxy issue. To view the proxy set from CMD:

netsh winhttp show proxy

My particular server did not need to use a proxy so I reset it by:

netsh winhttp reset proxy

However in some cases, some users have had to add a bypass-list using the <local> parameter for their WSUS server so the proxy is bypassed for the WSUS server. A reboot is needed after this. For more information read “set proxy” https://technet.microsoft.com/en-us/library/cc731131(v=ws.10).aspx#BKMK_5

Failed to run BeginSearch() on WUAgent. Error = 0x80070422

In an SCCM 2012 environment I was running through some reporting on which clients reported back scan errors so I could fully patch all servers. Upon checking the servers which failed to report software update compliance, I checked the C:\Windows\CCM\WUAHandler.log and saw the error “Failed to run BeginSearch() on WUAgent. Error = 0x80070422”

0x80070422

In my case, this was an easy fix. If you check services.msc you will see that the Windows Update service (or Automatic Updates service depending which version of Windows Server you are running) was stopped or disabled.

After starting this service and running a Software Updates Scan Cycle again, the WUAHandler.log reported that the cycle worked fine.

0x80070422_2

Wsyncmgr.log – Sync failed: The request failed with HTTP status 503: – SCCM 2012

I was told by a client that they were having issues synchronizing software updates using SCCM 2012.

The first thing I checked was the Wsyncmgr.log to find out what was going on. The Wsyncmgr.log showed “Sync failed: The request failed with HTTP status 503: Service Unavailable. Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer”

On the SCCM 2012 server running the SUP role, I opened up IIS Manager, looked at the Application Pools and noticed that the WsusPool was set to “Stopped“. I started it again and thought it was fixed, but the client advised me that it had crashed again shortly later.

iisapp2

I checked Task Manager on the server and noticed that IIS Worker Process was using 1864.1MB of memory.

iisapp5

I then right clicked on the WsusPool back in IIS Manager, then Advanced Settings, and noticed that the memory limit was set to a lower ammount.

iisapp4

I increased this limit to 4GB to be safe, restarted the WsusPool and then the SUP was able to syncrhonize fine. The Wsyncmgr.log looked good and the problem never came back for the client.

Part 2 – Deploying Software Updates with Maintenance Windows – SCCM 2012

Part 2 of this post I will be creating a Software Update Group for all released Windows 8.1 Updates and deploy them to a Windows 8 client which is a member of a Collection with a Maintenance Window set.

Part 1 can be seen here if you missed it.

Once I create an all updates deployment group for a product, I would normally create the groups on a monthly basis for products. For example Patch Tuesday when Microsoft releases patches. I would create a software update group and deployment package for all Windows 8.1 updates called WIN_8_1_ALL today on June 21st, then create another Win_8_1_15072015 on 15th of July 2015 for the next lot of updates Microsoft releases.

Lets get started. In the Software Library, then Software Updates, then All Software Updates, I have specified the criteria (on far right side) to search for the Product = Windows 8.1 Updates. I will be adding all Windows 8.1 updates to a software update group.

sup16

Once I have created my Windows 8.1 Software Update Group, I will be download them to a Deployment Package. I right clicked on the newly created Software Update Group and clicked Download.

sup17

I have given the deployment package the same name as my software update group to make things easier, and specified the path to where I will download these software updates to.

sup18

I have used the default settings for the rest of the settings. The updates will now download. This will take a while. My all Windows 8.1 updates deployment package was around 5GB.

sup19

Once my Windows 8.1 deployment package has finished downloading, I have created a collection to prepare to deploy my Windows 8.1 updates.

I will be using Maintenance Windows in this example to make sure my Windows 8.1 client installs updates during the times I specified in my Maintenance Window.

After the device collection is created, I right clicked on the collection and went to the Maintenance Windows tab to create a new Maintenance Window.

sup20

I have created my schedule and applied my maintenance window schedule type to Software Updates.

sup21

I did a Machine Policy Retrieval & Evaluation Cycle on my Windows 8.1 and looked at the ServiceWindowManager.log in C:\Windows\CCM\Logs to verify that my client picked up the new Maintenance Windows.

sup27

I have now gone back into the SCCM 2012 console, back to the Software Update Group I created earlier and will now be deploying my Windows 8.1 updates group to the collection I created with the Maintenance Window.

sup22

sup23

I have made my deployment type to Required.

sup24

I have set the available time to 5:35PM and my deadline to 5:36PM. Once my client picks up the policy, the updates won’t install until my Maintenance Window of 6PM has been activated.

sup25

I have left these settings as is. I want my client to restart during the maintenance window.

sup26

I have selected the default settings for the rest and finished the deployment wizard.

On my Windows 8.1 client I have run Software Updates Scan Cycle and Software Updates Deployment Evaluation Cycle

sup28

I looked at the UpdatesDeployment.log on my client in C:\Windows\CCM\Logs and it said that it was waiting for the next maintenance window to start so it could install the updates. Once it hit 6PM which is the time of my maintenance window, the updates started installing.

Once all the updates have been installed on the client and the client has been restarted to apply the updates, I checked the Monitoring node, then deployments, then the Windows 8.1 deployment I created and I can see that my test Windows 8.1 client is now compliant.

sup29

Clients failing to download Windows updates – Group policy settings were overwritten by a higher authority

I was facing an issue where every SCCM 2012 client at a certain site would not download Windows updates from the SUP on the SCCM 2012 server.

First thing I checked was the C:\Windows\CCM\Logs\WUAHandler.log on the client.

Reading WUAHandler.log in CMTrace I saw:

Enabling WUA Managed server policy to use server: http://servername.domain.com:8530 WUAHandler 20/05/2015 12:05:39 PM 6628 (0x19E4)
Waiting for 2 mins for Group Policy to notify of WUA policy change… WUAHandler 20/05/2015 12:05:39 PM 6628 (0x19E4)
Group policy settings were overwritten by a higher authority (Domain Controller) to: Server servername.domain.com:8530 and Policy ENABLED WUAHandler 20/05/2015 12:05:41 PM 6628 (0x19E4)
Failed to Add Update Source for WUAgent of type (2) and id ({03C8F032-8F2F-4821-9359-A1732F6F7A9D}). Error = 0x87d00692. WUAHandler 20/05/2015 12:05:41 PM 6628 (0x19E4)
Its a WSUS Update Source type ({03C8F032-8F2F-4821-9359-A1732F6F7A9D}), adding it. WUAHandler 21/05/2015 1:08:23 PM 6312 (0x18A8)

What was happening was the SCCM agent was trying to set the server to get the updates from http://servername.domain.com:8530 but there was a group policy set which overrides the SCCM setting, and was changing the location to servername.domain.com:8530. Notice the difference? The group policy was set without the http://

I found the incorrect setting in group policy and added the http:// to the link, did another “Software Updates Deployment Evaluation Cycle” on the client and all the updates started flowing through for all machines.