Wednesday 9 September 2015

Windows Updates failed 0x80244022

**Another Update - Even more resource regarding WSUS and cleanups that should be used.
Fixing WSUS - When the Best Defense is a Good Offense

*Update - With all the current WSUS issues I suggest folks also have a look at this new article from Microsoft, we are currently investigating its affects as well.
High CPU/High Memory in WSUS following Update Tuesdays


So this morning the Desktop guys started complaining about updates on some machines not working.

I started looking at the machine in question and SCCM seemed fine on the PC.
I checked the WUAhander.log and WindowsUpdate.log and came across the following errors:

WUAhander.log

WindowsUpdates.log

I tried all the Windows update agent tricks in the book as I thought the issue was on the machine.
Then I checked my own workstation and it was doing the same so now start to worry that the WSUS box is on the fritz.

I log in and I am greated with the reset node mmc error when trying to open the WSUS console.
So I restarted the server in the hope that it might do the trick. Upon rebooting it looked fine and then the console stopped working again.

So next I try to figure out whats happening in the event viewer:

Does not mean a lot me so I start to research some of the WSUS error codes. Then one stands out HTTP error 503 and I remember something I read on Eswar's blog
Configmgr OnSearchComplete – Failed to end search job Error 0x80244022 WUAHandler.log

So I checked my Wsuspool in IIS and it was stopped. Starting it only works for a while then it stops again.



So I set out to find out more about HTTP error 503 then I came across the technet blog article:
ConfigMgr 2012 Support Tip: WSUS sync fails with HTTP 503 errors

So I did the changes on my Wsuspool in IIS as follows:
Private Memory Limit: 4194304 (4GB)


When I tried to start the apppool again it gave a error so I did an IISreset and after that everything was working as it should again.

I know this looks like a repeat of the other articles but had to add my experience onto it as well.

Monday 20 April 2015

SCCM 2012 SP1 CU5 Upgrade

So this past weekend I had to perform an upgrade from CU2 to CU5.

The last upgrade I did was way back with SCCM 2007 R2 to R3, and thinking back it was a tedious process starting from your primary then going down the hierarchy.
After some research I found out that there is no more need to install it on every site system manually on CM2012 :)

So I proceeded with my Primary Site first. Installation took about 20min to complete and all were in working order or so it seems.

First thing I saw was packages being distributed after the update.

Only one of my Secondary sites did not get the Configuration Manager Client Upgrade Package (which is hidden from the console btw). The Configuration Manager Client Package I had to prestage the content to the other sites and extract it locally which worked great.











So I remembered the issue I had with a Secondary Site that failed and had to be rebuilt. I used this nifty trick again:
http://scexblog.blogspot.com/2014/04/configuration-manager-client-upgrade.html

Only downside was I had to prestage the Configuration Manager Client Package again as the version updated when using the Client.acu file.

So when that was finally done. I started with the upgrade of the Secondary sites. Which was as easy as deploying a software package to a machine. I also saw an update for the console. So I created 2 Collections. One based on Secondary Sites and one with all machines which had the Console installed but not on version .1600 (CU5).
As a test I made the Server Update available to one server and just ran it from Software Center. As I was looking at the log file it detected that the server had a Console installed an proceeded to update that as well so no need to deploy the Console only update afterwards it seems.
I saw that in the log files that gets created in %windir%\temp folder cm12-sp1cu5-kb2978017-x64-enu.log as well as configmgr2012adminui-sp1-kb2978017-i386.msp.log.



Here are the 2 collection queries I used:

Workstations with a Console installed (I know you can use the ARP displayname as well but more than one way to skin a cat right :))
(You can just change the %Workstation% to %Server% to get all servers with the Console installed)
Consoles:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SoftwareFile.FileName = "Microsoft.ConfigurationManagement.exe" and SMS_G_System_SoftwareFile.FileVersion < "5.0.7804.1600" and SMS_R_System.OperatingSystemNameandVersion like "%Workstation%"

All Secondary Sites:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System  inner join SMS_G_System_ADD_REMOVE_PROGRAMS_64 on SMS_G_System_ADD_REMOVE_PROGRAMS_64.ResourceId = SMS_R_System.ResourceId  where SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName = "Microsoft System Center 2012 Configuration Manager Secondary Site Setup"


As an added check I also installed Site Servicing Console Extension to verify that all the sites were on the correct version.

http://blogs.technet.com/b/configmgrteam/archive/2014/12/09/now-available-microsoft-system-center-2012-configuration-manager-servicing-extension.aspx

https://www.microsoft.com/en-us/download/details.aspx?id=45033