In-Depth
Smart Software Distribution
SMS packages are notorious bandwidth hogs. This unique four-step method overcomes the main drawbacks you face in using SMS for software distribution.
Microsoft Systems Management Server (SMS) 2.0 provides an elaborate means
to handle software distribution to client machines. The main methods involve
defining distribution servers on which the source files are installed
so that clients can then connect to these network sharepoints and install
the software from there. This approach works well when you follow Microsoft’s
recommendation to place a site server at each local area network location.
Doing so allows the administrator to schedule package sending from the
administering site to all necessary child sites at times of low bandwidth
usage over the wide area network links.
Unfortunately, there are reasons why it might not be feasible to place
a site server at each LAN location, including insufficient systems administrator
personnel at remote sites and inadequate hardware or other re- sources
to dedicate to the SMS site server function. Under such circumstances,
when an SMS site must span a WAN, the inability to schedule package delivery
poses significant risks of WAN-link bandwidth saturation.
The Giant Bandwidth Sucking Sound
Client issues frequently arise when an SMS site spans multiple
LANs. By default, an SMS client will choose a distribution server randomly
from the list of distribution servers in its site. If the distribution
server it chooses happens to reside across a WAN link, then the actual
client installation of the distributed software will happen very, very
slowly. In the meantime, WAN bandwidth across the saturated link may not
be available for critical purposes such as domain account or Active Directory
synchronization.
Two BackOffice Resource Kit utilities, Prefserv and Setsmsvr, designed
to ameliorate this problem direct the client to a specific distribution
server on its own LAN. These utilities have command-line switches that
can be used to write entries to the client registry to direct the client
to a preferred distribution server—preferably one on the same LAN as the
client.
| SMS
Program Components |
| Each SMS package you advertise using the
method I outline in this article has four program components:
• The third-party setup program provided by the software
vendor and manually copied to each distribution server.
• The Getipadd utility, which you customize once and
then incorporate by reference into the current Initiating
program and all desired future Initiating programs.
• The Initiating program, which you write specifically
for the current software rollout and which calls the
Getipadd utility in its first several lines.
• The actual SMS Program, which you define as part
of an SMS package and typically initialize via a Universal
Naming Convention (UNC) pathname in the “Command line:”
box under Program Properties, General tab.
—John Peter Recher
|
|
|
The main disadvantage to this approach is that changes must be implemented
and then maintained on each client. While it’s true that you can develop
a program for release to a specially defined SMS collection of machines
to update their registries so they point to the preferred distribution
server, this is one more client customization you need to perform and
maintain.
The alternative I’ve developed has these advantages:
- You control the timing of source file distribution to remote LANs,
even when those LANs aren’t defined as separate SMS sites.
- You can manage it centrally to avoid the need for SMS expertise at
the remote site.
- You set it up once, then easily incorporate it by reference into
each program you subsequently distribute. This reference eliminates
the need to pre-configure clients to any distribution server whatsoever;
the client selects the closest server on-the-fly immediately before
software installation.
- The client has instant access to the latest version of the program
you created to perform the third-party software installation.
- You avoid the need to redistribute the package whenever you change
your installation program.
My approach uses four phases:
- Prepare the distribution points.
- Customize the client subnet resolution program, called Getipadd.
- Write the initiating program for the software you want to install
and incorporate Getipadd by reference.
- Create the SMS program to run your initiating program on the clients.
1. Prepare the Distribution Points
To enable SMS clients targeted for a software rollout to access the distribution
files, the files must reside in a sharepoint accessible to these clients.
If you rely on the built-in SMS distribution method within a single site
that spans a WAN, your WAN bandwidth will be at the mercy of the SMS scheduler.
To assert control over the sending of the distribution files:
- Create a table to refer to as you proceed (see Table 1). Useful columns
include “Subnet,” “Default Gateway,” “Approximate Number of Clients,”
and “Preferred Distribution Server.”
- On each distribution server in the Preferred Distribution Server
column of your table, create a new subdirectory under the default smspkgd$
share and name it something intuitive. For example, if the software
to be distributed is Adobe 5.0, name the subdirectory adobe5. The UNC
path then becomes \\servername\smspkgd$\adobe5.
- Place your third-party distribution files under this new subdirectory.
Because you perform this step manually, you determine the timing of
this file copy procedure yourself, instead of allowing SMS to distribute
the software when it chooses. And because you create the new subdirectory
under the default smspkgd$ share, the new subdirectory inherits the
file system permissions the clients need for access. By default, these
are Full Control for BUILTIN\Administrators, plus Read/ Execute for
BUILTIN\Users and BUILTIN\Guests.
| Table 1. Keep
careful track of this information, because you’ll need it. |
|
Subnet
|
Default
gateway |
Approx.
# of clients |
Preferred
distribution server |
| 10.1.2.128 |
10.1.2.129 |
105
|
SERVERTWO
|
| 10.1.3.64 |
10.1.3.65 |
97
|
SERVERONE
|
|
|
The files you want to install are now on one or more sharepoints that
your SMS clients can access, so we’re ready to proceed to phase two.
Tip: Bear in mind that SMS doesn’t automatically create the default package
share “smspkgd$” until the site distributes its first program containing
files to a given distribution server. The approach described here doesn’t
involve programs containing files. Therefore, you may need to create the
smspkgd$ share manually if it doesn’t already exist on your distribution
server.
2. Customize the Client Subnet Resolution Program
Use SMS Installer, the freeware program AutoIT!, or another programming
tool to create the Getipadd utility to determine which subnet the client
is on and point the client to the preferred distribution server on its
subnet. The code in Listing 1 shows how to implement Getipadd using SMS
Installer. I’ve put in as many remarks as I can concoct to make this a
self-documenting program. These remarks help explain the reasoning for
each successive step, both to others who might have to use your program
later and for you if you need to add or delete preferred distribution
servers over time.
Listing 1. Getipadd.ipf, an SMS installer program to set an
SMS client’s preferred distribution server. (To
download a text version of this listing, right-click here
and "Save As".)
Check free disk space
Rem Define a variable to hold the hostname of the
optimal
Rem distribution server for this client.
Set Variable PREFSERV to
Rem This program works on both NT clients and Windows
9x
Rem clients, so check for the OS
If System Has Windows 95 or Later Running Start
Block
Rem Check the client registry for the
default gateway
Rem and place it in a variable called DEFGATE
Get Registry Key System\CurrentControlSet\Services\Class\NetTrans\0000
place in Variable DEFGATE
Rem Now compare the value of DEFGATE to
the list of
Rem default gateways on your network, and create an
Rem IF block for each distribution server you want to use.
If DEFGATE Equals "10.1.2.129"
then
Rem Create a new registry
key on the client called
Rem HKLM\SOFTWARE\PREFSERV
Rem Set the value of this new registry key to
the
Rem best distribution server for this client.
Registry Key SOFTWARE\PREFSERV = SERVERTWO
Rem Once this client's optimal
distribution server is
Rem set, exit the program to minimize execution
time.
Exit Installation
End Block
Rem This client wasn't on the subnet whose
default
Rem gateway is 10.1.2.129, so continue
If DEFGATE Equals "10.1.3.65"
then
Rem Create a new registry
key on the client called
Rem HKLM\SOFTWARE\PREFSERV
Rem Set the value of this new registry key to
the
Rem best distribution server for this client.
Registry Key SOFTWARE\PREFSERV = SERVERONE
Rem Once this client's optimal
distribution server is
Rem set, exit the program to minimize execution
time.
Exit Installation
End Block
Rem Refer to your Subnets and Their Preferred
Rem distribution servers table, and repeat the IF block
Rem for each subnet with clients whose optimal
Rem distribution server you want to set.
Rem End of Windows 9X-specific commands
End Block
Rem If the system isn't Windows 9X, maybe it's NT
or higher.
If System Has Windows NT Running Start Block
Rem NT doesn't use a registry key to record
the default
Rem gateway, so run the builtin ipconfig utility and pipe
Rem the output to a file for automatic analysis.
Rem Define a variable that will hold each line, in turn,
Rem that ipconfig outputs.
Set Variable LINE2PROCESS to
Rem Define a location for the ipconfig
output.
Rem Do NOT use %TEMP% because %TEMP% does not exist unless
Rem a user is logged on.
Get Environment Variable windir into Variable WINDIR
Rem If this client already ran this program
in the past,
Rem re-run it clean now.
Check If File exists %WINDIR%\ipcfg.txt Start Block
Delete File(s) %WINDIR%\ipcfg.txt
End Block
Rem Give the system enough time to delete
any
Rem existing ipcfg.txt file before trying to create a new
one.
Sleep for 1000 Milliseconds
Rem Run ipconfig and pipe the output to
%WINDIR%\ipcfg.txt.
Execute cmd /c ipconfig > %WINDIR%\ipcfg.txt (Wait)
Rem Search each LINE2PROCESS for the IP
address of
Rem this client's default gateway
While LINE2PROCESS Does Not Contain
"default gateway" do
Read lines of file %WINDIR%\ipcfg.txt into variable
LINE2PROCESS Start Block
Rem Search each
line of ipcfg.txt for the string
Rem "default gateway"
Rem Look at the IP address of the
default gateway
If LINE2PROCESS
Contains “10.1.2.129” then
Rem
Compare the value of default gateway to the list
Rem of default gateways
on your network.
Rem Create a new registry
key on the client called
Rem HKLM\SOFTWARE\PREFSERV
Rem Set the value of this
new registry key to the
Rem best distribution
server for this client.
Registry Key SOFTWARE\PREFSERV
= SERVERTWO
Rem
Once this client's optimal distribution server
Rem is set, exit the program
to minimize execution time.
Exit Installation
End Block
Rem This client
wasn't on the subnet whose default
Rem gateway is 10.1.2.129, so continue
If LINE2PROCESS
Contains "10.1.3.65" then
Rem
Compare the value of default gateway to the list
Rem of default gateways
on your network.
Rem Create a new registry
key on the client
Rem called HKLM\SOFTWARE\PREFSERV
Rem Set the value of this
new registry key to the
Rem best distribution
server for this client.
Registry Key SOFTWARE\PREFSERV
= SERVERONE
Rem
Once this client's optimal distribution server
Rem is set, exit the program
to minimize execution time.
Exit
Installation
End Block
Rem Refer to your
Subnets and Their Preferred
Rem Distribution Servers table, and
repeat the IF
Rem block for each subnet with clients
whose optimal
Rem distribution server you want to
set.
Rem End of NT-specific commands
End Block
End Block
End Block
Rem No client restart is needed, so set RESTART to Nothing
Set Variable RESTART to
Exit Installation
Here’s how Getipadd works:
- A utility runs and pipes its output to a text file. The utility can
be provided with the OS or can be custom-made.
- A small custom program written with AutoIT!, SMS Installer, Visual
Basic, or any number of other tools parses the text file, looking for
tell-tale text strings.
- The custom program makes changes to the client registry or file system
based on the tell-tale text strings found.
- Other programs then use the client registry or file system changes
to guide their own operation.
To speed execution time on the clients, be sure to use ipconfig without
the /all parameter. This practice produces a smaller ipcfg.txt output
file for parsing, yet still provides the required default gateway information.
To further speed execution time on each client, put the IF blocks for
the most frequently used default gateways in the program first so that
more clients exit the Getipadd utility sooner, thereby multiplying the
time savings for the client community. Use the “Approximate # of Clients”
column in your Subnets and Their Preferred Distribution Servers table
to place the IF blocks in descending order by the number of clients affected.
Finally, note that Getipadd creates a SOFTWARE\PREFSERV key under HKEY_LOCAL_MACHINE
(HKLM) instead of under HKEY_CURRENT _USER (HKCU). This is by design,
because the HKCU key doesn’t exist unless a user is currently logged on.
Creating the key under HKCU would needlessly limit the usability of the
Getipadd utility.
You’ve placed the distribution files on the distribution servers and
have created a utility called Getipadd that an SMS client can use immediately
before third-party software installation to determine the best distribution
server on-the-fly. Now you’re ready for the next phase.
3. Write the Initiating Program for the Software
After customizing the Getipadd utility by inserting the default
gateways and corresponding preferred distribution servers for your network,
incorporate Getipadd by reference at the beginning of your software rollout
program, that is, your Initiating program. In the code snippet in Listing
2, the first 23 lines (with appropriate customization changes, of course)
will be added to the beginning of all your Initiating programs for release
to SMS clients. These 23 lines create or update the HKEY_LOCAL_MACHINE\SOFTWARE\
PREFSERV key with the current optimal preferred distribution server. The
last three lines then run the actual third-party Setup program for the
software you need to roll out.
Listing 2. Adobinst.exe, the initiating program that determines
the optimal distribution server for this client and installs software
from the corresponding sharepoint. (To
download a text version of this listing, right-click here
and "Save As".)
Rem Program Adobinst.exe to (a) determine
the optimal
Rem distribution server for this client and
Rem (b) install software from the corresponding sharepoint.
Check free disk space
Rem Create a working directory. Do NOT use %TEMP%
because
Rem it does not exist when no user is logged on.
Get Environment Variable windir into Variable WINDIR
Create Directory %WINDIR%\adobe5
Rem Place the Getipadd executable that you’ve customized
Rem into the working directory.
Install File D:\sms development\getipadd.exe to %WINDIR%\adobe5\getipadd.exe
Rem Run the customized getipadd program that (a) determine
Rem the client's subnet residence and
Rem (b) set PREFSERV accordingly.
Rem Because Getipadd is executed at runtime, its result will
Rem be absolutely up-to-date.
Execute %WINDIR%\adobe5\getipadd.exe (Wait)
Rem getipadd has created (or updated) HKLM\SOFTWARE\PREFSERV,
Rem so read this registry key into a variable.
Rem Now execute the third-party Setup program from the
Rem optimal distribution server.
Get Registry Key SOFTWARE\PREFSERV place in Variable PREFSERV
Execute \\%PREFSERV%\smspkgd$\adobe5\setup.exe (Wait)
Set Variable RESTART to
Exit Installation
Now we need the power of SMS to activate your Initiating program on the
clients.
4. Create the SMS Program To Run Your Initiating
Program
The final step is to use SMS to run your program. Naturally, you
must create an SMS Package and within it, an SMS Program.
The distribution files are already in place on the preferred distribution
servers, so when you define the Package properties, don’t select the “This
package contains source files” checkbox on the Data Source tab of Package
Properties. Instead, use the “Command line:” box under Program Properties
to start your Initiating program.
| Keep
It Secret |
|
Create a special hidden sharepoint from which your
SMS clients can execute your current and future initiating
programs. Under this sharepoint, create a subdirectory
with an intuitive name for your current initiating program.
For our Adobe 5.0 example, we create a new subdirectory
under the hidden sharepoint and call it “adobe5”. After
copying the initiating program that you wrote in phase
three into this subdirectory, refer to it in the “Command
line:” box of your SMS Program by using the complete
UNC name. For instance, if the server name is HEROIC,
and the hidden share you have created is EXECS$, then
the UNC name to specify in the “Command line:” box of
your SMS Program is \\heroic\execs$\adobe5\
adobinst.exe.
The main advantage of creating a hidden share separate
from the smspkgd$ one automatically created by SMS is
confidentiality. After all, when an SMS program is about
to run on a client, the client can see its details,
including the path from which it will run. Executing
your initiating program from a directory other than
smspkgd$ helps keep probing eyes out of smspkgd$.
—John Peter Recher
|
|
|
Remember to specify “Use Windows NT client software installation account”
on the Program Properties Environment tab. This is necessary because the
client will need to access the UNC location. Because this UNC location
isn’t on the default smspkgd$ sharepoint, an NT SMS client’s local SMSCliToknAcct&
doesn’t have rights to this network share. For this reason, always use
the “Windows NT client software installation account” option on the Program
Properties Environment tab when using this four-phase method when NT clients
are involved. Specifying “Windows NT client software installation account”
doesn’t cause a problem on Windows 95 or Windows 98 clients as long as
those clients have Read rights to the UNC location. For information on
how to create this account, consult SMS online Help and search for “About
the SMS Windows NT Client Software Installation Account.”
Special Considerations
Bear two points in mind when taking advantage of this four-phase
method.
First, the Getipadd preferred distribution server utility goes hand-in-hand
with the manual software distribution I discussed in phase one. After
all, if you were to rely on SMS to distribute the software, then SMS itself
would determine which distribution server was “preferred”—and as I’ve
pointed out, SMS wouldn’t necessarily make the optimal choice. Depending
on the circumstances, this choice could result in bandwidth saturation
and glacial client installation times.
Second, in defining an SMS program in SMS 2.0, it’s possible to specify
the option, “Use Windows NT client software installation account,” only
under certain circumstances. Namely, when defining the SMS program, on
the Environment tab, this option isn’t available when the “Program can
run” option is set to “Only when a user is logged on.” Therefore, if it’s
crucial that your initiating program run only when a user is logged on,
then set the Advertised Programs Client Agent Properties accordingly.
To do this, modify the Advertised Programs Client Agent Properties for
the site so that the “When new advertised programs are available” section
shows “Display a notification message” as checked. In this way, you in
effect tell the Advertised Programs Client Agent that although it may
“present” the SMS program whether or not a user is logged on, it may not
run the SMS program without a user logged on to respond to the notification
message. The result is the desired one: Your initiating program won’t
run unless a user is logged on to authorize the installation.
We’ve Expanded the Frontier
SMS 2.0 provides a highly automated means of software distribution
and client installation of third-party products. When an SMS site spans
relatively low bandwidth communications links, this automation has drawbacks.
By using the four-phase method detailed here, you leave open all the regular,
automated SMS methods, yet also augment them to assert more direct control
over the software distribution and client installation phases. In this
way, you use the installed client base as it was meant to be used, but
with considerably less worry about the bandwidth implications of the SMS
software distribution mechanisms.
In addition, the Getipadd utility detailed in phase two allows a PC to
mimic human feedback. Getipadd uses a simple utility (ipconfig) included
with the OS to create output that’s then parsed to configure the same
client’s registry dynamically. The result of this on-the-fly self-configuration
can then be used to guide other programs. I believe the handiness of the
technique I’ve explained goes far beyond software installation, providing
a type of “client feedback” that works wherever a program can be used
on a client to generate output that’s then parsed to configure the same
client dynamically.