3. Managing the Advanced Client Download Cache
When
you configure the advertisement properties, you can specify whether the
package should be downloaded to the Advanced Client before it’s run.
If so, it’s stored in the Advanced Client download cache. It can happen
that the cache becomes too full to accommodate the download of any
additional packages. When a package is downloaded and placed into cache,
the client agent locks it. The package is unlocked after 24 hours have
passed since the program was run or 30 days have passed and the program
hasn’t run. After the package is unlocked, it can’t be locked again
unless it’s removed from cache and downloaded again.
When a package needs to be downloaded and the
cache is too full, SMS checks the other cached packages to see whether
it can delete any or all of the oldest packages to free up enough space
to accommodate the new package. If it can, it does so and downloads the
package. If it can’t, as might be the case if a package is locked, the
package isn’t downloaded.
Users with administrative credentials on the
client can manage this download cache. They can change the size of the
cache and its location, as well as delete the contents of the cache. You
can manage the Advanced Client download cache by following these steps:
1. | Open the Systems Management icon in Control Panel and select the Advanced tab, shown in Figure 17. You manage the Advanced Client download cache settings in the Temporary Program Download Folder frame.
|
2. | Enter the Amount of Disk Space To Use value or use the slide bar to set the amount.
|
3. | Click Change Location to modify the disk location for the download cache folder.
|
4. | Click Delete Files to delete the entire contents of the download cache.
|
When
you schedule an advertised program to run at a predefined time, the
Advertised Programs Client Agent on the Legacy Client and the SMS
Software Distribution Agent on the Advanced Client will check the
assigned time against the system time as reported on the client.
This can cause significant problems for you if the client’s system
clock is off. For example, if the client’s system clock is set for a
different time zone, the package might not run when you expect it to. Another
scenario involves trial software. Suppose a user obtains a trial
software application that’s timed to run for a specific period—say, 120
days. The user likes the product but doesn’t want to actually buy it (a
license no-no!) or hasn’t finished evaluating it. So the user simply
sets the system clock back a month, or a year, or even two years. This
can really muck up your package distribution. To
avoid this problem, be sure to build in some kind of time
synchronization routine for your clients that periodically synchronizes
their time with the site server or some other designated time server.
This goes for site systems and the server running SQL Server as well.
Windows 2000 and later domains make time-synchronization easy and
mandatory. |
|
4. Advertised Programs Process Flow
The advertisement and its associated files are
generated in a process even more straightforward than the package
distribution process, as illustrated in Figure 18.
Just as with the package distribution process, when the advertisement
is created and written to the SMS database, a SQL trigger causes the SMS
SQL Monitor service to write a wake-up file (.OFN) to Offer Manager’s
inbox (\SMS\Inboxes\Offermgr.box).
The
Offer Manager component generates instruction files for the Advertised
Programs Client Agent on the target client computers and writes these to
the \SMS\Inboxes\Offerinf.box directory on the site server. These
instruction files consist of an offer file (with a name similar to that
of the package but with an .OFR extension), which is the actual
advertisement; an installation file (.INS) that references the
advertisement ID and the collection ID it’s targeting; and up to three
lookup files (.LKP), depending on the collection membership. These
lookup files act as filters to determine whether the client (sitecodesystm.lkp), the user (sitecodeusr.lkp), or the user group (sitecodeusrgrp.lkp) should receive the advertisement. At this time, Offer Manager also evaluates the collection membership
to determine which lookup files to create. Once again, ever-faithful
Inbox Manager copies these instruction files to the Offerinf.box folder
on the CAPs. For Advanced Clients, the SMS Policy Provider copies the
advertisement information to the management point as an Advanced Client
policy.
On the Legacy Client, when the Advertised
Programs Client Agent runs, it uses the file Launch32.exe to begin the
process, as shown in Figure 19.
Launch32.exe itself starts ODPsys32.exe and ODPusr32.exe, two other
threads called Offer Data Providers (ODPs). These threads read the
lookup files that were created by Offer Manager and copied to the
Offerinf.box on the CAP by Inbox Manager. These files specify whether
the client computer, user, or user group should receive the
advertisement.
If the client, user, and user group should
receive the advertisement, the Advertised Programs Client Agent reads
the instruction and offer file for the advertisement to collect more
detailed information. It checks parameters such as the operating system
platform on the client and the system time to determine whether to
receive the offer. If all is fine, the client agent receives the offer,
passes it to the Advertised Programs Manager, generates a status message
to that effect, and writes the status message back to the CAP.
The
Advertised Programs Manager then reads the .PKG, .ICO, and .NAL files
for the package in question from the Pkginfo.box folder on the CAP.
Based on the information stored there, the client agent connects to an
appropriate distribution point and executes the program. When the
program is completed—successfully or unsuccessfully—the client agent
again generates a program status message that it writes to the CAP. You
can view this status message using the Status Message Viewer in your SMS
Administrator Console.
On the Advanced Client, the SMS Agent
Host (CCMexec.exe) is responsible for retrieving Advanced Client policy
updates from the management point and providing the SMS Software
Distribution Agent with advertised program and package information. It’s
also responsible for forwarding status information back to the
management point.
