Smart Software Distribution -- Microsoft Certified Professional Magazine Online

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.

By John Peter Recher
06/01/2002

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.

Register! Top 5 Hybrid AD Management Mistakes and How to Avoid Them