SMS 1.2

Remote Help Desk and software distribution at your fingertips

Few Windows NT-related tools are as useful as Systems Management Server(SMS), Microsoft's solution for administrating networked PCs. SMS has made itsname by addressing day-to-day computing problems, including inventorymanagement, software distribution, network monitoring, and Help Desk remotecontrol. 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 ManagementProtocol (SNMP) traps, and it works with third-party network management softwaresuch as HP's OpenView (for an overview of OpenView, see the sidebar, "Whatis HP OpenView?"). SMS is also not a fault manager, but it can aid productssuch as Computer Associates (CA) Unicenter TNG in this task (for informationabout Unicenter TNG, see Joel Sloss, "Unicenter TNG.")

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

Software Distribution
For network administrators, nothing ties stomachs in knots and sends coffeebills into triple digits quite like the impending rollout of a new softwaresuite. We've all uttered such words as, "If I could just automate thisprocedure to distribute the software one time and let the users install it."This need to simplify often leads us to try various means of softwaredistribution such as email attachments, network install points, diskettes, andeven CD-ROMs. In the end, we usually pick a competent person in the targeteddepartment, buy that person lunch, promise a faster computer on the desktop, andbeg that person to go from computer to computer supervising the softwareinstallation. Sometimes this approach works, but usually it doesn't. You andyour staff have to go and correct user problems, which is not an efficient useof your time. To address the need for streamlining such tasks, SMS promisesunattended software distribution--even if your users don't log on to theircomputers 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 replicationservice and security (specifically User Manager for Domains and Server Manageradministrative tools). In addition to requiring you to learn these tools, SMSthrows 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 SMSservice).

You also need a pretty husky machine. The ideal configuration is to installSMS and SQL Server on a Backup Domain Controller (BDC). SMS needs to access useraccount information, and Microsoft recommends this configuration to eliminatesome of the network overhead. I used an HP NetServer LX Pro 4x 200MHz PentiumPro 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 outof hard disk space.

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

You will want to give your SMS installation serious thought. You need toprovide a site code (a three-character unique identifier) and specify whetheryou have more than one domain (who doesn't?). You also need to decide whether tomanage your domains as one SMS site or as several individual sites. The SMSmanual 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 setup 10 clients running NT Workstation on the Lab's CLIENT domain. Between bothdomains, I was managing about 25 clients, with a mix of fictitious users andsome potential problem users (the Windows NT Magazine Lab staff).

After I installed SMS, I made sure all the SMS services were running andwaited for my domains to show up on the SMS Administrator screen, as shown inScreen 1. Several minutes passed and nothing appeared. I fired up the SMS Traceutility and watched as line after line of user names went scrolling by while SMSseemingly went through my entire user list. I didn't think too much about SMS'sapproach until I noticed SMS was listing users on other domains outside the twodomains I specified for use with SMS. SMS adds only the clients and logonservers on the domains that you specify, but it will snoop around every domainit can find. I tried to turn this feature off, but with no luck. You can use thesetgug.exe file to change how often SMS enumerates clients, but you can't limitSMS's discovery to only certain domains. After about 90 minutes, SMS discoveredapproximately 200 machines and several domains across several routers.

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

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

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

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

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

I wasn't aware that SMS works in semi-realtime. When you view an object'sproperties (in this case, the SMS service), you see two views: CurrentProperties and Proposed Properties, as Screen 2, shows. You make changes to theSMS service in Proposed Properties. After you finish your changes, you tell SMSto 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 10computers or 10,000 computers. This design means that changes can take a whileto finish as SMS propagates them through your network. You can alter the speedat which the SMS site runs, so you do have some measure of control in theprocess. 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 morehorsepower than Al Unser, Jr.'s Indy car, I told SMS to run at the maximumsetting (very fast). Of course, I still had to wait for this change to takeplace.

Remote Control with SMS
While I was waiting for my configuration changes, I decided to use SMS'sremote control features. Under Windows 95 and NT, these features arestraightforward. However, you'll have to do a bit more configuring with MS-DOSclients. I ran the remote control features on my NT machines. SMS adds a remotecontrol component automatically to your clients the first time they join the SMSsite. Users on the client machines must select a check box to grant youpermission to take remote control of their systems. Screen 3 shows the check boxfor 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. Ifyou use Dynamic Host Configuration Protocol (DHCP), you need to do someadditional 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 alwaysbe able to establish a connection. Therefore, you have to use NetBIOS to resolvethe address so that you can connect every time.

After you establish your remote connections, you can open a client recordfrom the SMS Administrator, navigate to the Help Desk option, and choose theRemote Control icon, as you see in Screen 4. After a short pause, SMS displays amirror image of the client's screen on your machine, as shown in Screen 5. Thescreen refresh of the remote desktop is slow, but you can perform tasks on theremote system: For example, you can type in commands, launch programs, andreboot. 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, Idecided there had to be a better way. I called Microsoft's PSS and got a quicklesson in the utilities on the SMS CD-ROM. I found out I had been waiting onSMS'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. Itried logging on to the CLIENT domain again and--success!

Deploying Office 97
I decided to test SMS's software deployment features by rolling out Office97 to all machines on the network. I began by checking Microsoft's SMS Web pagefor 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 wasready to deploy Office 97.

The first step was to use the Setup /a option. I installed Office 97 on theSMS site server. The administrative install takes roughly 365MB of space. I hada little more than half a gigabyte free on the server, so space was not aproblem. Next, I located the Package Description File (PDF) on the Office 97CD-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 laterinstallation. I created a new package and dragged the Office 97.pdf file from myNT Explorer window to the package window. I told SMS where I had put theadministrative install of Office 97 (Setup /a) and clicked OK. Screen 6 showsthe Setup Package for Workstations dialog box with the path to the Office 97administrative 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 theSMS Administrator File menu and selected New. The Job Details screen, as you seein Screen 7, presents several options. I selected All Personal Computers (aprepackaged query) as my source for the target machines. I then set severaloptions to control SMS's behavior and submitted the job. Ordinarily, you firstrun a query so you know exactly which machines you are targeting. Because Iwanted to target all machines in the Windows NT Magazine Lab, I was ableto run the job immediately. Next I brought up the Job Status Details screen, asyou see in Screen 8, so I could monitor the deployment's progress.

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

sendcode SMS-SITE_CONFIG_ MANAGER 191

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

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

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

Luckily for me, SMS lets you specify a particular distribution server. Ichose a BDC in the NTLABS domain that had plenty of free disk space available. Icancelled the previous job, fired up a duplicate specifying the BDC as thedistribution 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 yousee in Screen 9.

I quickly saw that I had a new package (the Office 97 package I created) inthe Pending Commands window. When I logged on to the CLIENT domain, SMSdisplayed the same Package Command Manager screen. I logged on to all the clientmachines and saw the same screen on every system. The next step was to installthe software.

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

I thought I had successfully arrived at the last stage of installation, butI had forgotten to give Administrator permissions to the client I was logged onas, so the installation failed. I granted the client the necessary rights andtried again. After finding the package in the execution window, I clickedExecute and successfully installed Office 97. I then went around to every targetmachine in the CLIENT domain to test the software deployment (i.e., I did mybest to imitate end users installing the software). I also tried to install afew 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 anddeploying Office 97 on about 25 to 30 machines (for information about using SMSto deploy software to more than 1000 clients, see the sidebar, "SMSworks").If I had performed this procedure manually, I would have spent just as muchtime, if not more, just installing Office 97.

Once you have the software distribution mechanism in place, your nextdeployment 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 meconsiderably longer.

You need to realize that SMS is a precision tool: You must have the propertraining and support to get the greatest benefit. Good news--Microsoft PSSprovides outstanding support. Although PSS can seem like a monolithic machine, Ihad the privilege of working with several support engineers and was impressed bytheir knowledge and professionalism.

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

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