SMS 2003: Troubleshooting the data flow for Security and Office updates
It seems like a fairly common situation we find ourselves in around here is troubleshooting Security or Office updates so I imagine that on occasion you might find yourself in the same boat. If so, the steps below are a high level overview of the process and what we generally follow to troubleshoot these kinds of issues. Overall the process involves four major steps:
- Downloading the latest version of MBSA and the mssecure.xml catalog using SyncXML.exe.
- Scanning the client using ScanWrapper.exe (s_scan.exe and o_scan.exe in SMS 2.0) and verifying updates.
- Verifying Hardware Inventory
- Applying the patch with Patchinstall.exe
Step 1 - Downloading the latest version of MBSA using SyncXML.exe:
Background: One system (can be the SMS Administrators workstation or the site server, but should be a system that is logged onto daily) is configured to be the synchost. This system runs the 'Sync' advertisement that downloads the latest mssecure.cab (containing mssecure.xml) and stores it on the specified Distribution Points. This advertisement requires access to the Internet and runs only when a user is logged on. Once downloaded, the cab file will be dated the day it's downloaded, however the mssecure.xml file contained inside will have the date representing the last time Microsoft updated it. This file is then used to update the targeted Distribution Points. This advert/program should be scheduled to run on the same interval as ScanWrapper however it must be recurring and run first.
Troubleshooting: SyncXML can also be manually run from the Distribution Point without the /s (silent) switch to validate the download. If you suspect a problem during this step of the process, try to manually download the latest version of MBSA use one of the command lines below:
Security Patch:
SyncXML.exe /s /site <siteservername> /code <sitecode> /target \\<synchostserver>\<share>\<path>\SecurityPatch\PkgSource /package <packageID>
Office Patch:
SyncXML.exe /s /site <siteservername> /code <sitecode> /target
\\<synchostserver>\<share>\<path>\OfficePatch\PkgSource /package <packageID
The mssecure.cab is initially stored in the following path by default: Program Files\SecurityPatch\PkgSource\1033
Once this completes, review the following logs if you encounter errors:
\CCM\Logs\SecuritySyncXML.log
\CCM\Logs\OfficeSyncXML.log
(or in SMS_CCM\Logs)
SMS 2.0
%windir%\Temp\SecuritySyncXML.log
%windir%\Temp\OfficeSyncXML.log
For more information see KB889430 – “How to manually update the Security Update Bulletin Catalog file for Systems Management Server 2.0” (https://support.microsoft.com/kb/889430).
Step 2. Scanning the client using ScanWrapper.exe
Background: This program is targeted to all clients. This advertisement uses the mssecure.xml file, downloaded from the previous step to compare the patch state of a client to the latest list of available patches. This comparison results in a list of patches and their status. Their status will either be "installed" or "applicable". Patch data is then stored in Windows Management (WMI) to the CIMV2 namespace in the Win32_PatchState class. Note that this advertisement or program can be scheduled to run on the same interval as SyncXML, however it must be recurring and run a bit after SyncXML completes.
Troubleshooting: If you suspect a problem during this step of the process, try to manually scan the client using one of these command lines:
ScanWrapper.exe /s /cache
ScanWrapper.exe /s /cache /kick (this is the command line from the "expedited" program.
For SMS 2.0 use:
s_scan.exe /s
s_scan.exe /s /kick
o_scan.exe /s
o_scan.exe /s /kick
Note that the /kick parameter forces a Hardware Inventory Cycle.
The command lines can be manually run from the client in the %windir%\system32\vpcache\<package ID> folder. Again, it may be appropriate to run without the /s (silent) switch.
If you experience an error running ScanWrapper check these logs for errors:
\CCM\Logs\ScanWrapper.log
(or in SMS_CCM\Logs)
SMS 2.0 or Legacy
%windir%\ms\sms\logs\ScanWrapper.log
Assuming ScanWrapper completes successfully, the webmtest.exe utility can be used to review the contents of the Win32_PatchState class and its instances:
A. Click Start | Run and type WBEMTEST
B. Click Connect and specify root\cimv2 as the Namespace (\\<system name>\root\cimv2 if connecting remotely) and click Connect.
C. Click Enum Classes select Recursive and click OK.
D. Drill down and alphabetically locate the Win32_PatchState class and double click.
E. Click the Instances button and all patch details will be listed. Patches here may be applicable or installed.
F. Locate the individual bulletin or Knowledge Base article number for which to view details and double click.
G. Click the Show MOF button and locate the appropriate detail, such as "Status".
Step 3. Verifying Hardware Inventory
All patch data that exists in the Win32_PatchState WMI class is collected during the Hardware Inventory Agents next scheduled Hardware Inventory Cycle and sent to the SMS database. This cycle is commonly set to 7 days although it may be necessary to reduce this cycle to receive more timely data or to manually initiate the Hardware Inventory Cycle on a specific client if testing. If the /kick parameter is specified on ScanWrapper.exe, inventory data is sent up immediately after the scan occurs. Unless the /kick parameter is used, the Hardware Inventory Cycle on the Hardware Inventory Agent should be set to occur on a similar interval as ScanWrapper but ScanWrapper should always be run first.
If you experience problems associated with Hardware Inventory check these logs for errors:
(Advanced client)
\CCM\Logs\InventoryAgent.log
(or in SMS_CCM\Logs)
(Legacy Client or SMS 2.0 client)
%windir%\ms\sms\logs\Hinv32.log
The date/time on the most recent entries in the logs can be compared to the Last Hardware Scan date/time from Resource Explorer | Hardware | Workstation Status to verify that the client has sent up inventory.
Step 4. Applying the patch with PatchInstall.exe
Background: PatchInstall.exe is the program that actually applies patches. Patches that are found to be applicable can be rolled up into this single package and targeted to those clients that require them. At least one client must require (list as applicable) a particular update type or specific patch for that update type or specific patch will be selectable from the DSUW. This program is created by executing the Distribute Software Updates Wizard (DSUW). DSUW can be used to create as many PatchInstall packages as necessary. Each patch should be individually downloaded and the proper switches per patch should be defined. See the Knowledge Base article relating to the individual patch for the available command line options. Properties for PatchInstall.exe are defined within the DSUW, however they can also be specified on the command line. (See below). In order to see the results in the SMS Admin console after the PatchInstall program has run, the ScanWrapper program and Hardware Inventory must be run.
The default command line is:
patchinstall.exe <various switches> /m:"PatchAuthorize.xml"
If you experience problems associated during this part of the process check these logs for errors:
\CCM\Logs\PatchInstall.log
\CCM\Logs\PatchUIMonitor.log
(or in SMS_CCM\Logs)
SMS 2.0:
%windir%\Temp\patchinstall.log
======
So as you can see, there’s a lot to this overall process but if you break it down into small, manageable parts your job of troubleshooting will become much simpler. Chances are you’ll never run into any kind of problem distributing patches but if you do then with this information you’ll have a troubleshooting head start.
J.C. Hornbeck | Manageability Knowledge Engineer