|SMS Feature Pack Sync Tool Teardown A to Z|
By: Richard Threlkeld
Posted On: 4/10/2003
The SMS Software Update Services Feature Pack (SUS FP) is an excellent way to manage security hotfixes in your enterprise and Microsoft office updates. The SUS FP is not an endeavor that should be taken lightly though. As with any major project that will impact the clients in your enterprise, you will need to evaluate the following:
- Reboot policies
- Testing processes
- Client notification and interaction
The SUS FP is really just a collection of interconnected tools. Some pieces of the SUS FP, such as the Sync tool, can be fully automated where you can set them up and they will take care of themselves. Other pieces, such as using the Distribute Software Updates Wizard, take a little more administrative interaction but in the long run do help to cut down in overall development time. Over the next few articles, I’ll try to expose some of the underlying processes behind the SUS FP by breaking down the individual pieces and also outlining what I think are my “Best Practices”. In this first article, I’ll give an overview of configuring the Sync Tool for your site as well as troubleshooting any issues that may arise. I’ll also walk you through the process of checking to make sure that the tool is running correctly and hopefully you’ll have a better understanding of how it functions.
What it does
Some people have been a little confused as to what the Sync Tool actually does. You’ll read a lot of technical jargon in the Microsoft help files about “Security Patch Bulletin Catalogs” and what not. Let me clear all this up in one simple statement: The Sync tool’s only purpose in life is to keep the scan tool up-to-date. How is this done? Well, in the past when you needed to deploy security hotfixes to your enterprise you had to research which patches were released, download the patches, then create a package to check if they were missing, then apply them if they were. With the advent of the Microsoft Security Baseline Analyzer (MSBA) and its integration into the SUS FP, you no longer need to do that as it is almost fully automated. I’ll explain later on how your time scripting packages will be saved, but here is a brief overview of the Sync Tools integration with the Scan Tool which we’ll tear down in a later article as well. First, the Sync Tool and the Scan Tool are both one SMS package but different programs inside of that package. The Scan Tool uses the MSBA to evaluate which patches are missing from the machine it is scanning and which patches are installed. But how does it know about new updates when they are released? By parsing through and gathering data from a file called mssecure.xml that’s how (don’t worry, I’ll spare everyone the time of explaining why the magic of XML saves us here and how it’s the wave of the future). In its role with the SUS FP, the MSBA will parse through a copy of mssecure.xml stored locally on the client. This is where the Sync Tool comes in. When it runs, the Sync Tool goes out to the Microsoft website ( http://go.microsoft.com/fwlink/?LinkId=9160) and places an updated copy of this file in the package source directory. To save a little confusion here mssecure.xml is actually contained in a CAB file called mssecure.cab for safe keeping. After downloading mssecure.cab successfully, the Sync Tool will next refresh the Distribution Points that you have assigned for the package. The next time the Scan Tool runs on a client, it will now use this updated copy of mssecure.xml or the “Security Patch Bulletin Catalog”.
After installation of the SUS FP, your first steps should be to make the appropriate changes to the package and to the Sync tool program to fully automate the process. Trust me on this, if you take the appropriate steps to configure the Sync Tool when you first set up the SUS FP you will save yourself headaches in the future. The Sync tool is the baseline for the Scan Tool’s ability to automatically update itself and ultimately patch distribution accuracy.
How it works
Before we get to far, let me give a technical overview of how the Sync Tool works. First Syncxml.exe does some basic checks to see the environment it’s running on such as the Operating System and Service Pack level. Next it makes sure that everything in the program command line is specified. The necessities to run are /site, /code, /target, and /package. All of this data that it’s gathering so far is written to a common log file stored in the TEMP directory, SecuritySyncXML.log (note: TEMP may not be C:\TEMP, it can also be inside the “Local Settings” folder under the profile directory for the person running the tool, even sometimes the SMSCliSvcAcct& or SMSCliToknAcct& so be careful when looking for the log). Next is where the real fun begins. A custom library was written be Microsoft for the Sync Tool, Advertisement.dll, and is located in the package source directory. Advertisement.dll is a COM interface to do the DP refresh command from SyncXML, and is also used by the SUS FP setup to create packages, programs, collections, and advertisements. Advertisement.dll takes its input from ini files, such as Download.ini. The Sync Tool installs this library to the System32 directory at runtime and registers it on the Sync Host. A few more checks are done to make sure it has all information it needs like file format (CAB), download URL, and destination location – All this data is read from Download.ini and SecurityPatch.ini. There is also another library that is next used, PatchDownloader.dll, which is used to actually download the files from the web. It will download to a temp folder and run a digital signature check before copying the file to the package source folder. Bogus signatures will cause a failure in the advertisement of course. It supports HTTP, FTP, and UNC source locations, so port 80 applies, and whatever port is used for FTP applies. There are currently no UNC source locations to worry about. The DSUW also uses PatchDownloader.dll for it’s downloads of patches themselves which I’ll go into in another article. This information is used next by calling Advertisement.dll to download the latest version of mssecure.cab (for those true techie geeks the function call to PatchDownloader.dll is “DownloadFiles” with the download URL and destination location used as parameters). The Sync Tool next creates a file in the TEMP directory that it will use to update the Distribution Points:
Server=Your site Server
SiteCode=Your Site Code
Name=Always blank because the package name is specified separately
DataSourcePath=The Data Source in the SMS Package Properties
Finally, the Sync Tool will update the distribution points by once again calling upon Advertisement.dll (this time the function call is “Create Package”, but the contents of the file I outlined above are called as a parameter this time basically giving it instructions on where the updates are happening).
So now you know how it works but what next? Well you need to make sure that the Sync Tool is running in the appropriate context for your organization. There are two schools of thought on how to run the Sync Tool which I’ve coined the Attended Method and the UnAttended Method. The Attended Method is the default setup for the Sync Tool in which it runs more visibly. With the UnAttended Method however, you set up the sync tool to run under the context of letting SMS take care of everything behind the scenes for you (I recommend using this methodology).
When the SUS FP is initially installed on your site server, it will create 3 collections and one package. Both the package and the collections will start with Security Update Tool followed by the site code in parenthesis like the following:
Security Update Tool (ABC)
By default, the SUS FP sets an advertisement for you for the Sync Tool. The target collection is to one of the 3 collections that I mentioned above followed by “Sync Host”. During setup you will be prompted for a Sync Host, that machine will be placed in this collection. The Sync Tool will execute on the machine(s) in this collection in turn updating the Scan Tool. Most people have just been setting their site servers up as the only machine in this collection right off the bat but I don’t recommend doing this initially. If you initially set up your site server as the Sync Host and walk away how are you to know if the Sync Tool is sending errors to the screen or having access problems? Upon first setting up the SUS FP, you should use your personal workstation to make sure everything is functioning properly and when you are confident that there are no problems then you can add your site server to the Sync Host collection. I’ll also take this opportunity to insert what should now be widely known configuration to turn on “Use HTTP 1.1 through proxy connections” on the advanced tab of Internet Explorer’s settings page as checking this setting can save you headaches down the road.
Now when the Sync Tool runs on the Sync Host in the Attended Method you should see some progress messages, depending on what switches you have specified for the Sync Tool, and you may possibly even see internet authentication if your proxy has been setup to require authentication. Although there may be nothing you can do for internet authentication in your company, you can make the Sync Tool run completely silently by adding /s to the command line in the SMS program. An example of running the Sync Tool in the Attended Method with the silent switch:
Syncxml.exe /s /site <site server> /code <site code> /target <package_source> /package <packageID>
But this means you need to constantly be logged on to the workstation that your Sync Host is specified as. This is because when the calls are made to Advertisement.dll that updates your DPs, an account with appropriate rights to SMS needs to be executing this process. Personally, I’d rather set up the Sync Tool to run without me and just let it do its thing which is why I use the “UnAttended” Method.
The UnAttended Method is pretty much the same as the Attended, but I suggest using this method and let SMS handle everything. With the UnAttended Method, you are setting up your site server to be your Sync Host and letting it work without your account needing to stay logged on to access SMS Providers. To do this, follow the following steps:
- Ensure that the browser settings on the Sync Host are set to use HTTP 1.1 as I outlined earlier
- Check to make sure that the firewall and/or proxy of the Sync Host allow anonymous access. If not set it up so that just the Sync Host’s IP Address is allowed to have anonymous access
- Set up the Sync Host to be the SMS Site Server and configure the SMSCliToknAcct& account to have SMS object permissions to the package
- Make sure that the package source directory is located on the Sync Host (because the SMSCliToknAcct& is a local account and doesn’t have SMB level network access to update this directory)
- Edit the program properties and on the “Environment” tab make sure “Weather or not a user is logged on” is selected which will change the package to “Run with Administrative Rights”
- Verify that the SMSCliToknAcct& account has full rights to the package source directory
Now, if you don’t want to set up your Sync Host as the site server for whatever reason, then you additionally will need to:
- Edit the package properties to include a DP refresh schedule. Make sure that the refresh starts shortly after the time that the Sync Tool advertisement happens to ensure that the latest version of mssecure.xml us going out to the DPs
- Change your program command in the SMS program to include the /unattend switch like so: Syncxml.exe /s /unattend /site <site server> /code <site code> /target <package_source> /package <packageID>
I need take a moment here to re-emphasize here that it is very important to have the package source located locally on the machine that you have designated as your Sync Host when using the UnAttended Method, especially if the Sync Host is not the site server. This should be considered before even setting up the SUS FP at your site.
So why did I have you make all these changes? The reason you gave the SMSCliToknAcct& full permissions to the package and its source directory is because your account is no longer running the Scan Tool, it is. To download mssecure.cab, the SMSCliToknAcct& needs rights to the directory it’s extracting to and rights to update the package distribution points. With the last two changes I had you make for setting up the
Sync Tool if the Sync Host is not a site server it will still follow the same process I outlined before, but by including /unattend in the command line it will exit before it tries to update the DPs, basically making it’s only purpose to download mssecure.cab to the package source directory. The task of updating your DPs has now been handed off to the daily schedule you gave to SMS. Now set up your site server as the Sync Host and that’s it for the UnAttended Method!
No matter what method you wish to use, I also recommend setting up your machine in the Sync Host collection as well and modify the advertisement setting for the Sync Tool by checking “Allow users to run programs independently of Advertisements”. I suggest doing this because in case of a problem you can always run the Sync tool on your machine ASAP getting the latest version of mssecure.xml to your workstations and then troubleshoot why the Sync Tool is having problems later.
First step should be to read through the excellent FAQ that Microsoft has put together:
SMS Status Messages: The Sync Tool is a normal SMS Advertisement so your first place to start for successes and failures should be the console. This is pretty straight forward, if everything is green then your good to go. (Don’t be fooled by seeing an exit code of “0” in the status messages. This is actually the success code for the Sync Tool, usually followed by the message “Security bulletin update completed successfully”).
SecuritySyncXML.log: The main things to look for here are the return codes from Advertisement.dll. A successful Sync will look something like the following (UnAttended Method):
Initialized log file - SyncXML started at 4/4/2003 3:30:11 PM
Command line enable UNATTEND
Command line specified package to update on DPs as ABC00071
Command line specified folder to update as \\SMSSERVER\F$\SecurityPatch.
Command line specified site code: ABC.
Command line specified site server: SMSSERVER.
Download completed - http://go.microsoft.com/fwlink/?LinkId=9160
Download completed successfully.
One common error seen by many is “Failed to update Distribution Points. Error code: 87”. If you are seeing this, then you are probably trying to configure the Passive Method and need to check the following:
- Check the program settings for the package in SMS. Click the Environment tab and make sure its set to run “Weather or not a user is logged on”
- Make sure that the SMSCliToknAcct& has full instance permissions to the package object and to the package data source directory
- Make sure that /unattend is in the program command line. This error is because of the WMI calls that Advertisement.dll is making to SMS while trying to update the DPs are being executed by an account that does not have rights to SMS (most likely the SMSCliToknAcct&)
Another couple of common errors are “Download failed - http://go.microsoft.com/fwlink/?linkid=10730” or “Sync tool failed to download "http://go.microsoft.com/fwlink/?LinkId=9160". Error code: 5”. If you see either of these, make sure that:
- “Use HTTP 1.1 through proxy connections” on the advanced tab of Internet Explorer’s settings page is checked
- The SMSCliToknAcct& or the account that is logged on and executing the Sync Tool has full control of the package source directory
- The Sync Host has access to the internet
- • Your Firewall or Proxy is set up to allow anonymous connections for the Sync Host's IP Address
Another tricky one to troubleshoot is also “Unable to write to <package_data_source>. Aborting program” in your log file. This is usually because of account access. In this case make sure that the Sync Host is the same computer that has the package source directory and that the SMSCliToknAcct& has full control to that directory.
You may also see an error code of 12007, something like this in your log: “Sync tool failed to download " http://go.microsoft.com/fwlink/?LinkId=9160". Error code: 12007”. This indicates a “access denied” return code when PatchDownloader.dll is called and is trying to get through the proxy or firewall. Once again check to make sure that at least the IP Address for the Sync Host can have anonymous access to the proxy and/or firewall.
Hopefully this article has given you some insight to how the Sync Tool works and some better ideas as what kind of configurations are best for your site. This will save you some time during your deployment. Special thanks to Rob Wickham of Microsoft for his help clearing up some of the technical pieces of this article. If you have any other questions or problems, please feel free to contact me at firstname.lastname@example.org . In my next article we’ll break down the Scan Tool in the same way.