SMS 1.2

Few Windows NT-related tools are as useful as Systems Management Server (SMS), Microsoft's solution for administrating networked PCs. SMS has made its name by addressing day-to-day computing problems, including inventory management, software distribution, network monitoring, and Help Desk remote control. Before I jump in and explain what SMS is, let me say what SMS isn't. SMS is not a network manager, but it can intercept Simple Network Management Protocol (SNMP) traps, and it works with third-party network management software such as HP's OpenView (for an overview of OpenView, see the sidebar, "What is HP OpenView?"). SMS is also not a fault manager, but it can aid products such as Computer Associates (CA) Unicenter TNG in this task (for information about Unicenter TNG, see Joel Sloss, " Unicenter TNG.")

According to Michael Emanuel, SMS product manager at Microsoft, "SMS is happy to manage the desktop and does a very good job of it." I decided to examine that assertion by testing SMS on two tasks (software distribution and remote control of the desktop) that are an absolute must for successfully managing the desktop.

Software Distribution
For network administrators, nothing ties stomachs in knots and sends coffee bills into triple digits quite like the impending rollout of a new software suite. We've all uttered such words as, "If I could just automate this procedure to distribute the software one time and let the users install it." This need to simplify often leads us to try various means of software distribution such as email attachments, network install points, diskettes, and even CD-ROMs. In the end, we usually pick a competent person in the targeted department, buy that person lunch, promise a faster computer on the desktop, and beg that person to go from computer to computer supervising the software installation. Sometimes this approach works, but usually it doesn't. You and your staff have to go and correct user problems, which is not an efficient use of your time. To address the need for streamlining such tasks, SMS promises unattended software distribution--even if your users don't log on to their computers regularly.

Installing SMS
Desktop management is not a trivial process--and neither is installing SMS. Before you begin, make sure you have a good understanding of NT's replication service and security (specifically User Manager for Domains and Server Manager administrative tools). In addition to requiring you to learn these tools, SMS throws a few more at you, such as SMS Trace (for monitoring SMS's actions), setgug (for configuring SMS), and sendcode (for sending codes to the SMS service).

You also need a pretty husky machine. The ideal configuration is to install SMS and SQL Server on a Backup Domain Controller (BDC). SMS needs to access user account information, and Microsoft recommends this configuration to eliminate some of the network overhead. I used an HP NetServer LX Pro 4x 200MHz Pentium Pro with 512MB of RAM and a 2GB hard disk running NT Server 4.0 Service Pack 2 (SP2). I had plenty of memory and computing power, but to my surprise, I ran out of hard disk space.

Before you install SMS, you must install SQL Server (SMS stores its information in SQL Server tables). I took the easy approach when I installed SQL Server and accepted all the default prompts.

You will want to give your SMS installation serious thought. You need to provide a site code (a three-character unique identifier) and specify whether you have more than one domain (who doesn't?). You also need to decide whether to manage your domains as one SMS site or as several individual sites. The SMS manual does a good job of explaining the differences among site configurations, but not the complexity involved. I chose to manage two domains as one SMS site. I installed SMS on the Windows NT Magazine Lab's NTLABS domain and set up 10 clients running NT Workstation on the Lab's CLIENT domain. Between both domains, I was managing about 25 clients, with a mix of fictitious users and some potential problem users (the Windows NT Magazine Lab staff).

After I installed SMS, I made sure all the SMS services were running and waited for my domains to show up on the SMS Administrator screen, as shown in Screen 1. Several minutes passed and nothing appeared. I fired up the SMS Trace utility and watched as line after line of user names went scrolling by while SMS seemingly went through my entire user list. I didn't think too much about SMS's approach until I noticed SMS was listing users on other domains outside the two domains I specified for use with SMS. SMS adds only the clients and logon servers on the domains that you specify, but it will snoop around every domain it can find. I tried to turn this feature off, but with no luck. You can use the setgug.exe file to change how often SMS enumerates clients, but you can't limit SMS's discovery to only certain domains. After about 90 minutes, SMS discovered approximately 200 machines and several domains across several routers.

For SMS to work, you need to install client software on each workstation in the SMS site. You can install this software manually, or you can configure SMS to automatically install the software on the clients as they log on. I chose the latter option because I didn't like the idea of having to hoof it to each machine.

For SMS to automatically add workstations as users log on, you must enable the Automatically Configure Workstation Logon Scripts option. You then need to configure NT's directory replication service. Appendix D of the SMS manual describes this process in detail, but I found the description unclear and incorrect. After I called Microsoft's Product Support Services (PSS), I was able to use the logon script feature and test the replication service. Everything worked well on my NTLABS and CLIENT domains.

Next, I needed to tell SMS to use all detected logon servers so that it would install the server software on each logon server and, more importantly, install the client software on each server. After the client software is on the servers, NT can replicate the SMS autologon scripts and client software throughout the domain.

Everything worked fine on the NTLABS domain. When I logged on to this domain, SMS installed its client software on my machine, added my machine to its site (under the NTLABS domain), and queried and inventoried my machine. I then tried to log on as a client to the CLIENT domain--nothing happened! I decided to test the replication services and found no problems; I could replicate a test file on the NEC RISCstation 2200 server just fine. So what was the problem? To find out, I had to fire up the trusty SMS Trace utility. I discovered that SMS had not replicated the server software (at least not the MIPS executables).

Now I admit I never specified that the Primary Domain Controller (PDC) on the CLIENT domain was a MIPS box. By default, SMS installs only Intel and Alpha versions of the software. SMS requires that you add the distribution server to the SMS site before you can have the server add other potential clients. Because I hadn't installed the MIPS executables, SMS wasn't running in the CLIENT domain. Fortunately, the SMS setup program lets you install additional software. I installed the MIPS executables and tried logging on to the CLIENT domain again, with the same result--nothing.

I wasn't aware that SMS works in semi-realtime. When you view an object's properties (in this case, the SMS service), you see two views: Current Properties and Proposed Properties, as Screen 2, shows. You make changes to the SMS service in Proposed Properties. After you finish your changes, you tell SMS to update the site, and then you wait.

Some SMS veterans will tell you that SMS stands for Slow-Moving Software, and they are right. SMS works the same way whether you have a network of 10 computers or 10,000 computers. This design means that changes can take a while to finish as SMS propagates them through your network. You can alter the speed at which the SMS site runs, so you do have some measure of control in the process. The software lets you adjust the load SMS places on your server. Because I was running SMS from the HP NetServer LX Pro, which has more horsepower than Al Unser, Jr.'s Indy car, I told SMS to run at the maximum setting (very fast). Of course, I still had to wait for this change to take place.

Remote Control with SMS
While I was waiting for my configuration changes, I decided to use SMS's remote control features. Under Windows 95 and NT, these features are straightforward. However, you'll have to do a bit more configuring with MS-DOS clients. I ran the remote control features on my NT machines. SMS adds a remote control component automatically to your clients the first time they join the SMS site. Users on the client machines must select a check box to grant you permission to take remote control of their systems. Screen 3 shows the check box for allowing remote control.

If you've ever had to use the remote control feature on Intel's LAN DESK, you'll recognize SMS's remote feature. Both products use the same technology. If you use Dynamic Host Configuration Protocol (DHCP), you need to do some additional configuration and use NetBIOS and Windows Internet Name Service (WINS). Because SMS uses the IP address in the inventory record for the client, and the IP address may not match the address that DHCP assigns, you won't always be able to establish a connection. Therefore, you have to use NetBIOS to resolve the address so that you can connect every time.

After you establish your remote connections, you can open a client record from the SMS Administrator, navigate to the Help Desk option, and choose the Remote Control icon, as you see in Screen 4. After a short pause, SMS displays a mirror image of the client's screen on your machine, as shown in Screen 5. The screen refresh of the remote desktop is slow, but you can perform tasks on the remote system: For example, you can type in commands, launch programs, and reboot. I can't even begin to tell you how useful this feature is!

After spending about two hours waiting for the changes to take place, I decided there had to be a better way. I called Microsoft's PSS and got a quick lesson in the utilities on the SMS CD-ROM. I found out I had been waiting on SMS's SITE_CONFIG_
MANAGER service and that I needed to use a program, sendcode.exe, to send the appropriate code (191) to the service to wake it up. I tried logging on to the CLIENT domain again and--success!

Deploying Office 97
I decided to test SMS's software deployment features by rolling out Office 97 to all machines on the network. I began by checking Microsoft's SMS Web page for help with installing Office 97. I was glad to find a comprehensive guide, including step-by-step instructions on how to install the software at http:// www.microsoft.com/smsmgmt/office97.htm. After reading the instructions, I was ready to deploy Office 97.

The first step was to use the Setup /a option. I installed Office 97 on the SMS site server. The administrative install takes roughly 365MB of space. I had a little more than half a gigabyte free on the server, so space was not a problem. Next, I located the Package Description File (PDF) on the Office 97 CD-ROM. This file tells SMS the particulars about Office 97 or any program. Using SMS Administrator, I opened Package View from the File menu. A package, in SMS parlance, is the software you distribute to the client systems for later installation. I created a new package and dragged the Office 97.pdf file from my NT Explorer window to the package window. I told SMS where I had put the administrative install of Office 97 (Setup /a) and clicked OK. Screen 6 shows the Setup Package for Workstations dialog box with the path to the Office 97 administrative install.

Now that the package was ready to deploy, I needed to create a job. A job is the mechanism that delivers the package. I chose the Jobs View from the SMS Administrator File menu and selected New. The Job Details screen, as you see in Screen 7, presents several options. I selected All Personal Computers (a prepackaged query) as my source for the target machines. I then set several options to control SMS's behavior and submitted the job. Ordinarily, you first run a query so you know exactly which machines you are targeting. Because I wanted to target all machines in the Windows NT Magazine Lab, I was able to run the job immediately. Next I brought up the Job Status Details screen, as you see in Screen 8, so I could monitor the deployment's progress.

Nothing was happening with the deployment, so I decided to kick start SMS with

sendcode SMS-SITE_CONFIG_ MANAGER 191

Sure enough, SMS kicked into high gear, the job went active, and SMS began churning away.

After about half an hour, I was antsy. When I checked the Job Status Details screen, the job was still active but nothing was happening. I fired up the SMS Trace utility and discovered I'd run out of disk space. How could that be? If I had taken the time to read the warning about the required amount of disk space on the .pdf file, I could have avoided this problem.

Office 97 takes only 365MB of disk space, but it compresses the files before it ships them to the distribution server, which in this case was the same machine. SMS copies the resulting compressed file (135MB) to the distribution server (same machine) and decompresses it into a temporary file. After successfully decompressing the file, SMS copies the resulting expanded files (365MB) to a file share that all SMS clients can access (another 365MB). SMS then deletes the temporary directory. If you do the math, you get 365MB + 135MB + 365MB + 365MB = 1230MB. You recover the extra 365MB from the temporary directory, but you need 1.3GB of free disk space to start the installation process.

Luckily for me, SMS lets you specify a particular distribution server. I chose a BDC in the NTLABS domain that had plenty of free disk space available. I cancelled the previous job, fired up a duplicate specifying the BDC as the distribution server, started the job with sendcode, and waited.

After about 15 minutes, I logged on to one machine in the NTLABS domain. SMS fired up and greeted me with a new Package Command Manager screen, as you see in Screen 9.

I quickly saw that I had a new package (the Office 97 package I created) in the Pending Commands window. When I logged on to the CLIENT domain, SMS displayed the same Package Command Manager screen. I logged on to all the client machines and saw the same screen on every system. The next step was to install the software.

SMS doesn't force you to install the software right away. Instead, when you create the job, you can specify a grace period so that your users have some time before they must install the new package. You can also choose to never make a job mandatory, as was the case with my job. I clicked Execute, which brought up the Office 97 installation splash screen.

I thought I had successfully arrived at the last stage of installation, but I had forgotten to give Administrator permissions to the client I was logged on as, so the installation failed. I granted the client the necessary rights and tried again. After finding the package in the execution window, I clicked Execute and successfully installed Office 97. I then went around to every target machine in the CLIENT domain to test the software deployment (i.e., I did my best to imitate end users installing the software). I also tried to install a few machines in the NTLABS domain and badgered a coworker into doing the same. Each machine successfully installed Office 97.

Final Thoughts
Is SMS for you? I spent between 24 hours and 32 hours configuring SMS and deploying Office 97 on about 25 to 30 machines (for information about using SMS to deploy software to more than 1000 clients, see the sidebar, "SMSworks"). If I had performed this procedure manually, I would have spent just as much time, if not more, just installing Office 97.

Once you have the software distribution mechanism in place, your next deployment will be far simpler. Even so, setting up SMS is not a trivial task. If I hadn't had Microsoft PSS's help, setting up SMS would have taken me considerably longer.

You need to realize that SMS is a precision tool: You must have the proper training and support to get the greatest benefit. Good news--Microsoft PSS provides outstanding support. Although PSS can seem like a monolithic machine, I had the privilege of working with several support engineers and was impressed by their knowledge and professionalism.

You will need training and support when you set up SMS. If you are going to use SMS to improve your efficiency, allow for the time and money you need for training and support when you prepare your deployment budget.

The bottom line is that SMS can automate software distribution and provide remote control of client desktops, albeit with some difficulty. I've only skimmed two of SMS's most popular features in this article. When you throw in client inventory, a network sniffer, SNMP trap handling, software auditing, true integration with Microsoft desktop operating systems, and Crystal Reports for ad hoc reporting, all for an attractive price, you have a compelling argument for using SMS. Add in the appropriate budget for training and support, and you might be able to keep your coffee bill in the low double digits.

Contact:

Microsoft * 206-882-8080 Web: http://www.microsoft.com/smsmgmt Preparing to install the distribution software on the client machine with the Package Command Manager