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
- To user groups, via a collection of user group
- 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
- 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
- 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
- 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.
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.
- 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...