Microsoft's Systems Management Server (SMS) gives systems administrators tools to centrally manage their networks. Because SMS offers the ability to inventory, remotely control, and distribute software, it is an indispensable tool. But often, administrators don't know how to leverage their investment in SMS and fully use its potential on their network. One of my clients recently needed this knowledge.
The company had deployed SMS to centrally manage network clients and inventory workstations. One important objective was to manage client workstations running the Oracle Applications family of products with SmartClient architecture. This full-function, 31-module database client offers client-side form controls and database access; in its typical configuration, this software weighs in at just more than 500MB. A program this size is already difficult to manage; when you add distribution to each desktop of software patches from Oracle and customized information-gathering forms, you escalate the challenge. In an enterprise of several hundred workstations and numerous disparate sites, SmartClient is almost impossible to manage.
One of the most difficult aspects of managing SmartClient is its ability to connect to different database instances. An instance is a separate database running on the Oracle Server that may include different add-in components or contain different working sets of data. Because SmartClient's modules are tightly integrated, you must update all clients immediately when a component changes. Failure to update a client can result in corrupted data or compromise the integrity of the database. Therefore, precise coordination of component updates on the server and the client is imperative. The fact that customers often update their database components several times a week adds to the requirement for robust and reliable distribution mechanisms. Using SMS's inventory and software distribution utilities, I designed a robust, reliable, and relatively simple method of updating several hundred database instances of SmartClient.
Managing Instances
The first problem I needed to solve was determining which database instance each user was accessing. The customer had previously installed SmartClient Release 15 on all desktops, and several different icons on each Windows 95 desktop pointed to different database instances. All these icons made determining who was connecting to each database instance quite difficult.
The customer prepared a list of who had access to each database instance. Then, I created machine groups within SMS to logically group workstations based on which database instance the workstation's user accessed. The machine grouping let me systematically identify which modules I needed to update at each workstation (e.g., machines accessing database instance A require patches 12345 and 67890).
The next step was finding out which version of SmartClient was installed and what patches or customizations were on the workstation. The oaconfig.ora configuration file contains an entry (e.g., ORACLE_RELEASE=SC16) that identifies the version of the client. Using the SMS Administrator's console, I opened the Package Properties window and clicked New Package. Then, I clicked Inventory, shown in Screen 1. From the Setup Package for Inventory, I selected Inventory this package (e.g., oaconfig.ora) and clicked Add OR, as Screen 2 shows. I instructed SMS to look for a String 0 entry whose properties were ORACLE_RELEASE=SC16, as Screen 3 shows. The next time the inventory interval expires and the client logs on, the inventory process will scan for the configuration file. If the file contains the Release 16 entry, the SMS console will show that fact in the workstation's Properties window. I can then query the SMS database to determine which computers have this release installed and which machines I need to upgrade.
Tracking Patches
I was making progress. I had defined the machine groups and configured an inventory package so that anyone could query the enterprise to see who had SmartClient installed, which version it was, and what database the client was using. But I wasn't out of the woods: I needed a method to determine which patches the customer had applied to each workstation. The best way I found to track the patches was to place an entry in a file on the workstation that would identify patches. I settled on an INI-based file with a section heading, entry, and value that showed which patch was installed and for which instance; for example,
\[Production_Instance\]
Patch_123456=Installed
At first I thought I could place this entry in the oaconfig.ora file, but SMS might not work effectively with that method. The inventory rules that you can define to look within a file for a text entry require an offset address. This address is a hexadecimal number pointing to a location in a file so that SMS knows to look for the defined text. Unfortunately, SMS can read in only 1024 bytes, which limits your ability to consistently locate the text in the file. Because I couldn't predict the size of the oaconfig.ora file or how it might change with future releases, I needed a better solution. Rather than design a scheme that I might need to redesign later, I created a new file (patch.ini) to house the patch entries. I placed the file in the Oracle directory, because SmartClient would function even if the user deleted the file.
The next step was designing the delivery mechanism and the procedure for updating the client. Because I was using machine groups in SMS to logically group the users of each instance, the delivery scheme didn't need to determine which database instance a workstation was using. My customer also wanted to distribute the patches and automatically patch the client even if the user wasn't at the computer. To ensure that the patch didn't corrupt data, I had to ensure that SmartClient was not running when the patch arrived. The customer wanted the patches to execute immediately to ensure that the clients were in sync with forthcoming updates.
To accomplish these tasks, I needed to send all jobs out as Mandatory, which meant that even if the client wasn't at the computer, the job would run 5 minutes after the Package Command Manager picked it up from the distribution server. The customer instructed its users to exit SmartClient and start the update process as soon as a SmartClient patch arrives.
For greater assurance, I also forced SmartClient to quit automatically if it was running. In the Microsoft Windows NT Resource Kit, I discovered the kill.exe utility, which can force any running application to quit. Furthermore, kill.exe lets you kill the application by specifying the window's title, not a window handle, which is often a nightmare to locate when you're running a batch file. This feature made my job easier, because SmartClient's window caption is always Oracle Applications. By including this kill application in the delivery process, I could automatically update the client by ensuring that SmartClient would not be running.
Installation Script
My last challenge was to structure the update files and write a process to update the SmartClient installation. You usually distribute Oracle's patches for SmartClient as individual files that you copy to the workstation. Because SMS requires a shared directory to distribute software from, I created a share on the SMS Site Server and placed the SmartClient patches in a hierarchical directory based on database names. In each database directory, I placed a directory name, which was the patch number, and organized the files in subdirectories to mirror how the files would look on the workstation.
After configuring the distribution point, I needed to create the installation script that patched the SmartClient software on the workstations. I identified four steps in the patch process:
- Copy the patch files to the target workstation's SmartClient directory.
- Ensure that the files being copied are newer than files they are replacing. This step prevents the problem of copying older files over newer ones on the workstation, which is a common occurrence with Oracle's patches.
- Ensure that the SmartClient is not running when the files are updated.
- Inform the user that the patch has been installed successfully.
Because I had already figured out how I was going to accomplish each of these steps, I proceeded to create the installation script, the SMS package, and the SMS job to do the work. I created a simple batch file, shown in Listing 1, for the customer to run. The first step in the script, as Callout A in Listing 1 shows, was to use the kill command to ensure that Oracle SmartClient was not running on the workstation when the package arrived. The >nul parameter sends the working output of the kill command to the null device so that the client doesn't see unusual information.
The next step was to inform the user which patch the administrator was installing; as you can see, you can bundle several patches within a single distribution. The xcopy command uses two relatively uncommon switches. When SMS 1.1 or later distributes a job to a workstation, the client and the distribution server use interprocess communications (IPC) connections to communicate. Because no drive letter is connected to the server, I needed to write the batch file to work with SMS's IPC-based communications. The command interpreter (command.com or cmd.exe) sets the %0 variable to the fully delineated path of the application currently running, including the application name (e.g., \\servera\sms_shrd\oracle\batch.bat). I needed to trim this variable to identify only the path information and not the name of the batch file. The path information told xcopy the location of the files to copy. Therefore, when I referenced the %0 variable, I also used ".." to tell the interpreter that I wanted the previous level of information; in this example, the path is \\servera\sms_shrd\oracle\. To accomplish the second requirement of the distribution (to ensure that only the newest files were copied to the client), I added the /D parameter to the xcopy command. This parameter forces the command to copy the file only if it is newer than the destination.
The last step was to track patches as they were installed on each workstation. Using lwed.exe (shareware available from the Walnut Creek CDROM Web site, http://www.simtel.com), I wrote an INI-style file in the Oracle directory. LWED uses the format LWED -w <File Name> <Section Heading> <Entry> <Value>. To obtain the information
\[Production_Patches\]I specified LWED -w patch.ini Production_Patches Patch_123456 installed.
Patch_123456=Installed
Armed with this script, I created an SMS package to deliver the program to the workstations. I defined the package to point to the distribution point on the site server and configured the package to execute the batch file. I configured a job to send the package to the production database users. Because my customer wanted the update to occur right away, I configured the package as a mandatory package that automatically installed 5 minutes after it arrived at the workstation.
When the job arrives at the workstation, it displays a 5-minute warning that the package will be executed. The user can start the package right away or let it start in 5 minutes. The program displays a DOS prompt indicating that the patching process is executing. If SmartClient is running, the program forces it to exit. The batch file copies the patch files and then stops so that the user can see that the patch has completed. The user then can close the DOS windows and continue working. You can add an Exit command to the end of the script to close the DOS windows automatically.
As you can see, you can overcome barriers to software maintenance if you have a distribution engine. Consider how much time you spend maintaining your client workstations, and explore the opportunities SMS offers.
