Patch Management

Microsoft has following categories of updates:

Critical Update
Security Update
Definition Update
Update Rollup
Service Pack
Tool
Feature Pack
Update

Critical Update – is an update which fixes specific, non-security related, critical bug. That bug can cause for example serious performance degradation, interoperability malfunction or disturb application compatibility.

Security Updates – is an update which fixes security vulnerability. Security updates have their own severity defined by Microsoft Security Response Center. There are 5 levels of the security update severity defined by MSRC:

Critical – The update fixes a vulnerability whose exploitation could allow for the propagation of an Internet worm without user action.

Important – The update fixes a vulnerability whose exploitation could result in the compromise of the confidentiality, integrity, or availability of users’ data, or of the integrity or availability of processing resources.

Low – The update fixes a vulnerability whose exploitation is extremely difficult, or whose impact is minimal.

Moderate – The update fixes a vulnerability whose exploitation is mitigated to a significant degree by factors such as default configuration, auditing, or difficulty of exploitation.

Unspecified – The update does not have a severity rating.

Every security update has also Exploitation Index which is not presented to the user in Windows Update or WSUS.

The main confusion seen in the field regarding update categories is within WSUS, Windows Update and MBSA.

WSUS

Windows Server Update Services (WSUS) can synchronize updates based on the category but not based on severity (see below). Selecting “Critical Updates” in the WSUS Configuration\Options\Products and Classifications will only synchronize and download Critical updates that fix critical bugs (for example hardware or driver compatibility). These Critical Updates have nothing to do with Critical Security Updates.

If you want to synchronize Security updates you need to select “Security Updates” in the Classification tab. It will download critical, important, moderate, low and unspecified security related updates.

Critical Updates (as opposed to Critical Security Updates) have no MSRC severity set (WSUS will display it as “Unspecified”):

Windows Update

Windows Update will display simplified categories to the end user as usually they don’t need to know about severity ratings or exact type of update:

Important – include all Security Updated regardless of MCRS severity, Critical Updates, Definition Updates, Update Rollup and Service Pack

Optional/Recommended – include Feature Pack and standard Updates.

If we want to match exact types of updates to simplified version used by Windows Update in control panel you can use below table:

MBSA

Microsoft Baseline Security Analyzer – provides a streamlined method to identify missing security updates and common security misconfigurations. MBSA is a basic vulnerability scanner which can run locally or remotely. MBSA will scan for missing Security Updates (critical, important, moderate, low) and display their maximum MSRC severity rating.

Hope this blog post helped you to understand different categories and severity levels of Microsoft updates.

Main takeaway:

Critical update is an update which fixes critical non-security related bug.

Critical Security Update is an update which fixes critical security vulnerability.

Important update is category displayed by Windows Update and include all Security updates regardless of the MCRS severity rating as well as other update categories like Critical Updates, Definition updates etc.

Important Security Update is an update which fixes important security vulnerability.

Client Side

In the client side first thing we need to check is the locationservices.log to make sure that the correct SUP point is detected by the client, else make sure that the client is correctly reporting to the SCCM server and that the software update is enabled. Make sure that the server name and the port is specified correctly.

Locationservices.log

================

Calling back with the following WSUS locations LocationServices 4/29/2010 10:39:40 AM 2844 (0x0B1C)

WSUS Path='https://SCCMCEN.SCS.IN:443', Server='SCCMCEN', Version='2' LocationServices 4/29/2010 10:39:40 AM 2844 (0x0B1C)

Calling back with locations for WSUS request {10066528-1C1B-4A0C-958B-F29ACBEDBBDF} LocationServices 4/29/2010 10:41:31 AM 2844 (0x0B1C)

Calling back with the following distribution points LocationServices 4/29/2010 11:27:23 AM 2552 (0x09F8)

Distribution Point='\\SCCMCEN.SCS.IN\SMSPKGC$\CEN00003\4ea80bd5-c8ac-4f98-be8a-1c18f24a34e4', Locality='LOCAL', DPType='SERVER', Version='6487', Capabilities='<Capabilities SchemaVersion="1.0"><Property Name="SSL" Version="1"/></Capabilities>', Signature='' LocationServices 4/29/2010 11:27:23 AM 2552 (0x09F8)

Now once the policy agent triggers the scan cycle the windows update agent in the client will contact the WSUS server which in our case is also the SUP point. Once the scan is successfully completed this information is send as state message to the SCCM server. This can be checked in windowsupadte.log or you can check WUAhandler.log under SCCM client log.

WUAHandler.log

==============

Async searching of updates using WUAgent started. WUAHandler 4/29/2010 10:42:20 AM 3488 (0x0DA0)

Async searching completed. WUAHandler 4/29/2010 11:24:21 AM 1496 (0x05D8)

Successfully completed scan. WUAHandler 4/29/2010 11:24:25 AM 2752 (0x0AC0)

Its a WSUS Update Source type ({D4F72DDB-F6C4-4B05-835F-A8C23098857A}), adding it. WUAHandler 4/29/2010 11:25:24 AM 2752 (0x0AC0)

Existing WUA Managed server was already set (https://SCCMCEN.SCS.IN:443), skipping Group Policy registration. WUAHandler 4/29/2010 11:25:25 AM 2752 (0x0AC0)

Added Update Source ({D4F72DDB-F6C4-4B05-835F-A8C23098857A}) of content type: 2 WUAHandler 4/29/2010 11:25:25 AM 2752 (0x0AC0)

Async searching of updates using WUAgent started. WUAHandler 4/29/2010 11:25:25 AM 2752 (0x0AC0)

Async searching completed. WUAHandler 4/29/2010 11:26:28 AM 2396 (0x095C)

Successfully completed scan. WUAHandler 4/29/2010 11:26:32 AM 3756 (0x0EAC)

Completion of scan is important and if the same is not successfully done you can take the help of the following link to troubleshoot the issues. This link is of WSUS troubleshooting but you can get hints to troubleshoot the error code.

Now when the policy agent triggers the software update deployment cycle the scan result is compared with the catalogue and then it downloads only the required updates and install on schedule. You can check the updatestore.log, updatedeploymemt.log for more details. You can also check windowsupdate.log for more details.

Updatedeployment.log

The execution manager will have the following entries

Execmgr.log

==========

Mandatory execution requested for program Software Updates Program and advertisement

Once update is installed, then depending on the reboot setting the system will be rebooted. This information is tracked using

RebootCoordinator.log

Disable automatic updates (Via GPO

Software update Components involved are:

1. Windows update agent (WUA)

2. Software update client agent (from SCCM)

3. Windows management instrumentation (WMI)

Note: Make sure you disable the automatic updates via GPO

Windows Update agent(WUA): is responsible for scheduling and initializing scan, detection, download, and install of updates on the client machine. WUA Agent is an implanted service in a Windows service (SVCHOST.exe) and is named Windows Update which you can see from services.msc.

If you disable WUA Agent, software update agent will not function correctly. So it always recommended to not disable this service.

Software update client agent (from SCCM): When you enable the software update agent, it will install 2 actions on the client 1) Software update scan cycle 2) software update deployment Evaluation Cycle

Software Update Scan Schedule: This action perform the software update scan (along with WUA) against the Microsoft update catalog, which occurs every 7 days by default.

Software update Deployment evaluation: This action Initiate the software update deployment to start download and install the updates.

Note: when you create software update deployment with deadline for ex: at 4.00 PM ,the actual time that software update client start updating the installation is depends on setting disable deadline randomization ((located in the Computer Agent client settings)

ets have a look at client troubleshooting steps. (Note: Client logs can be found at %windir%\ccm\logs\ ,if you have not changed the default path).

There are many logs on the client which help you to troubleshoot client issues,but we only look at important logs what is required for software updates.

1. First log to check is locationservices.log—>This log is used to check the correct software update point has been detected by the client.You can also see the management point and distribution point entries from this log.

2. 2nd log to check is wuahander.log –> when the software update scan cycle initiated, Windows update agent (windows update service) will contact WSUS (SUP) for scanning and if is successful,a state message will be sent to site server confirming that,software update scan is completed successfully which can be seen from this log. Get the report to know the software update scan results from

here

For some reason,if you don’t see the successfully completed scan message,you should start troubleshooting from this log based on the error .

3rd log is windowsupdate.log –>If software update scan is successful from wuahandler.log ,you can ignore this log file and directly move to next log (updatesdeployment.log) .If Software update scan is not successful then,you should look at this log for more information. This log Provides information about when the Windows Update Agent connects to the WSUS server and retrieves the software updates for compliance assessment and whether there are updates to the agent components.

Using these 2 logs (wuahandler.log and windowsupdate.log) ,try to fix the errors and make sure ,you see the scanning successful from wuahandler.log

4.4th log to check is UpdatesDeployment.log—> Provides information about the deployment on the client, including software update activation, evaluation, and enforcement. Verbose logging shows additional information about the interaction with the client user interface.

This log shows the number of updates and deployments being targeted to a machine.

SCCM Configmgr 2012 Troubleshoot Client software update issues

One of most important and critically used feature in configuration manager 2012 is Software updates .It is always challenging and import task for any sccm administrator to achieve good patch compliance success rate within the given SLA(Service level agreement).Patch compliance success rate is depends mainly on heath of your SCCM clients and some times things may go wrong even though sccm client is healthy (able to receive applications/packages and performing inventory except patches).

I have created lot of SSRS reports on software update compliance out of many,one of the widely used report is get the patch compliance status of software update group for specific collection with linked report to get the computers with unknown and required status for troubleshooting (to check when was the last hardware,last software scan,last user ,OS etc).

Coming to the subject line, I have been seeing many questions on the configuration manager forums and social networking sites on software update patching issues .couple of questions on the subject line are like

1) Client getting packages ,applications but not software updates

2) Most of the clients receiving deployed software updates but still few do not get.

3)Clients not detecting software updates

4) clients log says ,patches required but sccm reports says,updates not required( means complaint)

5) Client log says patches not required but sccm report says ,updates required.

6)Software update failing to install ,how to fix

7) I have added patches to the existing software update group/deployment and these newly added patches not deploying successful and many more ….

The solution for the most of the above issues can be identified and solved by analyzing the the client logs before we do in-depth troubleshooting.

In this blog post (SCCM 2012 Troubleshoot software update client issues),I will explain you the basic troubleshooting steps (only on client side ) which will help you to resolve issues on your own by analyzing the logs and take it further afterwards.

Before we jump into the troubleshooting,I would like to illustrate the main components which are involved in deploying software updates.

When you enable software update agent setting in client agent settings,a policy will be created with this setting and stored in SQL Database.So when client initiate machine policy,it communicate with management point which includes the software update client feature installation instructions to be installed or applied on the client. In this process, Client will create local GPO with WSUS Settings by leaving automatic updates .

If you do not disable automatic updates (Via GPO) leaving the door open for the WUA to do things on its own outside the control of ConfigMgr including installing any updates approved directly in WSUS (including new versions of the agent itself which are automatically approved) and rebooting systems which have a pending reboot. Neither of these is desirable in a ConfigMgr managed environment and thus the recommendation for disabling automatic updates. As for the rest of the Windows Update GPO settings, they are meaningless in the context of ConfigMgr so it doesn't really matter what you set those to if you disable automatic updates,more from

If you choose to create a GPO for WUA, you must configure the Windows Update Server option to point to the active software update point server in the site or location. If there is an existing GPO that was intended to manage standalone WSUS prior to implementing Configuration Manager in your environment, the GPO could override the local GPO created by Configuration Manager, which can cause issues when the software update client tries to communicate with the software update point server.

Software update Components involved are:

1.Windows update agent (WUA)

2.Software update client agent (from SCCM)

3.Windows management instrumentation (WMI)

If you disable WUA Agent, software update agent will not function correctly. So it always recommended to not disable this service.

Software update client agent (from SCCM): When you enable the software update agent,it will install 2 actions on the client 1) Software update scan cycle 2) software update deployment Evaluation Cycle

Software Update Scan Schedule :This action perform the software update scan (along with WUA) against the Microsoft update catalog, which occurs every 7 days by default.

software update Deployment evaluation:This action Initiate the software update deployment to start download and install the updates.

Note: when you create software update deployment with deadline for ex: at 4.00 PM ,the actual time that software update client start updating the installation is depends on on setting disable deadline randomization ((located in the Computer Agent client settings)

A delay of up to 2 hours will be applied with deadline time to install required software updates . This randomization prevents all software update clients from starting update installations at the same time (This setting is disabled by default). If you enable this setting,then the deployed software updates will be installed with deadline what you set i.e at 4.00PM (based on Client local time or UTC).

It is also good to know the patch compliance states which are sent as state messages by client to site server .Patch compliance is calculated based on these 4 states.

Installed :This means the software update is applicable and the client already has the update installed.

Not Required: This means the software update is not applicable to the client .

Required: This means the software update is applicable but is not yet installed.Alternatively, it may mean that the software update was installed but the state message has not yet been sent to to the site server.

Unknown :This means either that the client system did not complete the software scan or the site server did not receive the scan status from the client system.

Enough theory , Lets have a look at client troubleshooting steps. (Note: Client logs can be found at %windir%\ccm\logs\ ,if you have not changed the default path).

There are many logs on the client which help you to troubleshoot client issues,but we only look at important logs what is required for software updates.

For some reason,if you don’t see the successfully completed scan message,you should start troubleshooting from this log based on the error .

You can get the error description from CMTrace.exe tool. Copy the error code and use ctrl+L (Error lookup) from your cmtrace.exe ,get the error description .

If WSUS entries are not set correctly or having any issues locating the correct WSUS,you can set WSUS entry manually or script.Further troubleshooting is required .

The registry location for the WSUS entries as follows:

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU with UseWUSserver =1

3. 3rd log is windowsupdate.log –>If software update scan is successful from wuahandler.log ,you can ignore this log file and directly move to next log (updatesdeployment.log) .If Software update scan is not successful then,you should look at this log for more information. This log Provides information about when the Windows Update Agent connects to the WSUS server and retrieves the software updates for compliance assessment and whether there are updates to the agent components.

Using these 2 logs (wuahandler.log and windowsupdate.log) ,try to fix the errors and make sure ,you see the scanning successful from wuahandler.log

This log shows the number of updates and deployments being targeted to a machine.

From above log snippet ,you see that,the total actionable updates = 0 means ,client do not require any additional updates that you targeted to this PC.For some reason,if the client says non-compliant from your sccm reports,try to refresh compliance state using,and monitor updatestore.log to see if the state messages (like Successfully raised Resync state message)has been sent to the site server (MP) or not.

you can alternatively use the below PowerShell script ,deploy to your clients monthly twice or once as per the business needs.

$SCCMUpdatesStore = New-Object -ComObject Microsoft.CCM.UpdatesStore
$SCCMUpdatesStore.RefreshServerComplianceState()
New-EventLog -LogName Application -Source SyncStateScript -ErrorAction SilentlyContinue
Write-EventLog -LogName Application -Source SyncStateScript -EventId 555 -EntryType Information -Message "Sync State ran successfully"

updatedeployment.log also tell you that,what assignments (Update deployments) made with count of updates in each deployment. From above log, Assignment {C37C45D8-E722-4EB7-AC21-014925079560} has total CI = 6 ,means ,the assignment has total 6 patches .

How do you check the deployment name for particular assignment ? well ,you can add Deployment Unique IDcolumn for software update deployment or use below SQL syntax .

SELECT * FROM vSMS_UpdateGroupAssignment
WHERE vSMS_UpdateGroupAssignment.Assignment_UniqueID= '{C37C45D8-E722-4EB7-AC21-014925079560}'

For some reason,if you don’t see the newly added patches installing ( issue no:7) ,you can checkupdatedeployment.log with particular assignment group and patch count .If the count of patches are less than what it supposed to be,then you may have to refresh the machine policy ,initiate software update scan and wait for a while before client start downloading the policies.

If you see some updates are pending for action (total actionable updates <>0) but not installing,look at CAS.log if your client is able to locate the content on the Distribution point or not.

UpdatesDeployment.log will also tell you ,if enough maintenance window (ServiceWindowManager.log) time available to install the updates.Read the following blogs to know the maintenance window calculation for software update installation.

5.5th log to check check is UpdatesStore.log—>Provides information about the compliance status for the software updates that were assessed during the compliance scan cycle (Status like Missing/Installed).

If you see all things working good, the final log to refer is RebootCoordinator.log—>Provides information about the process for coordinating system restarts on client computers after software update installations.

Below diagram shows the configuration manager Client side software update deployment flowchart captured fromconfiguration manager software update management filed experience guide.

For troubleshooting clients, You can use tools like deployment monitoring tool,configuration manager support center etc.

I normally use the configuration manager support center to troubleshoot the client issues to check if the policy for the deployed software update group received correctly or not based on the PolicyIVersion.

Open the support center (you can download from Microsoft) ,connect to remote machine (need admin rights on remote computer) .

go to policy tab,click on requested and then Load requested policy .you will see list of wmi instances on the left.

click on settings(root\ccm\policy\machine\requestedconfig) ,click on CCM_updateCIassignment ,click thepolicyID ,on the right side,you will see information about the software update group.

check the policy version on the client and on the site server .now you know how to take it further troubleshooting. Good luck.

Couple of common workarounds when troubleshooting software update issues :

1. Stop the windows update service,rename or delete the Software Distribution folder (%windir%\softwareDistribution) and start windows update service. This approach provides a fresh start with a new Windows Update data store if the Datastore.edb file is corrupted.

2. Restart the windows update service ,trigger software update scan cycle and software update deployment evaluation cycle.follow the logs.