Have you ever wondered exactly what happens when an SMS client polls a client access point (CAP) for your SMS site to see if any new advertisements have been added, or how much of a load this really puts on your network? Before these questions can be answered, you first need to understand the variables that affect this process:
- Is software distribution enabled (via the Advertised Programs Client Agent configuration)? If not, you can stop here...
- How many total machines are in the SMS site?
- What mechanisms are being used to target advertisements to a machine? There are three alternatives:
- Directly at machines, via a collection of machines names.
- To user groups, via a collection of user group names.
- To users, via a collection of user names.
- How many different "objects" (machines, groups, or users) are targeted?
- How many different advertisements are defined at the site?
- How many different packages are defined at the site?
- How frequently has the client been instructed to check?
Assuming software distribution is enabled, all SMS client machines will check the CAP three times looking for advertisements: once for machine-targeted advertisements, once for user group-targeted advertisements, and once for user-targeted advertisements. This process will be repeated based on the "Check for new programs" cycle time (again configured via the Advertised Programs Client Agent).How Does It Work?
So how exactly does this work? Let's look at the "machine-targeted" process specifics. The "System Offer Data Provider" (running as "ODPSYS32.EXE") performs the following tasks:
- Connect to the CAP for the site, e.g. "\\SMSSERVER01\CAP_XXX" where "XXX" is the SMS site code.
- Translate the machine's SMS-assigned GUID into an instruction file name by looking up the GUID in the "XXXSYSTM.LKP" file located in the "\\SMSSERVER01\CAP_XXX\OfferInf.box" directory. For example, the located instruction file name could be "XXXABCDE.INS".
- Read the "XXXABCDE.INS" instruction file to determine which advertisements have been targeted to this machine.
- Read the "offer file" (e.g., "XXX20001.OFR", which is located in the same "OfferInf.box" directory), really an "advertisement information" file, to get the details for each advertisement targeted at the machine.
- Hand off the list of advertisements (including the package ID and program name for each) to the "Advertised Programs Monitor" (SMSAPM32) for further processing.
This same process is performed for user groups and users as well, with some small differences:
- The "WNet User Groups Offer Data Provider" (running as "ODPUSR32.EXE") performs the checks.
- The "XXXUSER.LKP" file (for user-targeted advertisements) and "XXXUSRGRP.LKP" file (for user group-targeted advertisements) are used in place of "XXXSYSTM.LKP". The instructions file names are determine using the logged-on user's groups and user name as a key.
So what happens to these lists of advertisements once SMSAPM32 gets them? This is a little more straight-forward:
- For each package ID (from the details provided with the advertisement), connect to the CAP for the site and read the package and program details. These are contained in "\\SMSSERVER01\CAP_XXX\PkgInfo.box" and are named using the SMS package ID, e.g. "XXX00001.PKG".
- Check the local advertisement installation status files to see if the advertisement has already been run.
- If necessary, execute the specified program, wait for it to finish, and generate the necessary status messages containing the results.
- Have any advertisements been removed from the list? If so, check to see if the program associated with includes uninstall information - execute the uninstall command if it does.
Makes perfect sense, right? If not, take a look at the ODPSYS32.LOG, ODPUSR32.LOG, ODPWNT32.LOG, and SMSAPM32.LOG files (preferably using the SMS Trace support tool) - watch a full cycle to see in excruciating detail exactly what goes on.Estimating Traffic
So how do you estimate how much traffic this process generates? That's where this process gets interesting, not so much in what it does, but how it does it. It probably would not surprise you to learn that SMS is not very efficient. Some examples:
- To find each of the LKP lookup files (three of them), the SMS client scans the entire "CAP_XXX\OfferInf.box" looking for the file, instead of just trying to open it. It also doesn't stop the directory scan until it has retrieved the full file list.
- To find each of the OFR offer files (one per advertisement), the SMS client again scans the entire "CAP_XXX\OfferInf.box" directory looking for the file (like before).
- To find each of the INS instruction files (one per machine, group, and user), the SMS client again scans the entire "CAP_XXX\OfferInf.box" directory looking for the file (like before).
- To find each of the PKG package information files (one per advertised package), the SMS client this time scans the entire "CAP_XXX\PkgInfo.box" directory looking for the file.
- The SMS client appears to be capable of caching the LKP, OFR, INS, and PKG files, copying a new version to the local machine any time the file on the CAP changes: the log files indicate that it is checking to see if the local copy is up-to-date, but it never makes a local copy. So each time it reads the network copy.
So what does it do efficiently? There is one process that does seem to be written as efficiently as possible: when reading the LKP lookup files (which are sorted), the SMS client appears to use random file access and a binary search algorithm - it finds the proper entry very quickly. (Sorry, no others examples were found.)
Using the information above, combined with some specifics below, should enable the calculation of a reasonable estimate:
- A LKP lookup file record is 80 bytes long, with one record per machine targeted by at least one advertisement.
- The network traffic generated by a directory scan is about 120 bytes per file name contained in the directory.
- The size of a typical OFR file is 140 bytes.
- An INS file contains one 18-byte record for each advertisement targeted to a machine, user, or group.
- The size of a typical PKG file is about 200 bytes.
See for Yourself
Try the CAP Polling Calculator, a web-based tool designed to give you a reasonable estimate of the amount of traffic generated by a single client polling cycle (something to consider before running trying to access a CAP through a slow-speed connection), the total amount of traffic generated by your client population, and how much better it could be if Microsoft could eliminate all of those directory scans...