Combine Systems Management Server with other utilities to manage a complex enterprise activity
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.