SMS Planning Tips

Consider these hidden factors before deploying SMS

Microsoft Systems Management Server (SMS) is a key technology for creating an enterprise-class systems-management service. SMS offers organizations the ability to inventory hardware and software, deploy applications, manage resources remotely, proactively track software licenses, monitor network objects, and create management reports. SMS is a complex and comprehensive product, so planning carefully for its implementation in your organization is crucial. Many companies skip the initial planning stage for most products. For SMS, skipping this stage will result in a failed implementation and ultimately cause companies to shelve or discard the product.

To Consult, or Not
One of the first questions you should ask yourself when implementing SMS is whether you need outside help. Increasingly, companies that need specific skills and expertise and don't feel that they have them inhouse hire consultants. This step is a logical one to take; unfortunately, few consulting organizations really specialize in SMS.

Consulting companies try hard to meet every technical need a customer has. I don't know of any consulting organization that would tell you it knew nothing about the product you were asking about and turn down your business. You must establish some criteria that will help you determine whether a consultant is a good fit for the project.

This article reveals the hidden factors that you must address when planning for SMS. Any consulting company that you talk to about helping you implement SMS should discuss these factors with you. Consultants who don't initiate such a discussion might have read the SMS Administrator's Guide or had some classroom training, but they probably don't have real-world experience with SMS.

The best way to locate a good consulting company is to ask other companies that have implemented SMS to recommend the consultants they used. To find companies using SMS, check online technology forums or attend a local SMS user group meeting.

If you'll be planning and implementing SMS on your own, you still must consider these hidden factors. Long before you start building servers and installing clients, gather the information I outline here and use it in your planning. I don't cover all the bases—the SMS Administrator's Guide (which is included in HTML format with SMS) is an important resource for anyone planning an SMS rollout. Rather, the factors I list here are important ones that are sometimes completely overlooked.

Employee Considerations
A big part of planning your SMS structure is to know how many people the company employs and how many use a computer, because you must install special client software on each computer in the SMS environment. Of course, you must know the number of computers because you need to know the number of SMS client licenses you must purchase, but the number of clients also determines the type of server and the overall SMS structure that you should use.

Most consulting organizations identify this number as a key factor in planning, but consultants sometimes miss another equally important number: the expected increase in head count over the next 2 years. You should provide for growth when you build your SMS infrastructure. If your head count has doubled 6 months after you roll out SMS and you haven't planned for it, SMS performance might suffer. And when SMS takes a performance hit, all functions—from server services to client components—respond more slowly than usual.

During setup, the SMS installation program prompts you for the number of clients that you'll assign to the SMS site. SMS uses this number to perform a calculation, then automatically tunes Microsoft SQL Server with the appropriate performance-parameter settings. (SMS stores all the information it gathers in a SQL Server database.) So, the number you enter should reflect any growth you expect over the next 2 years. Even if your number isn't exactly right, allowing some room for growth can save a great deal of troubleshooting and restructuring down the road.

Client Considerations
SMS's purpose is to interact with the computers on which it's installed, so you should do everything you can to ensure that the interaction will be smooth. Many client considerations are obvious, but a few that might not be so apparent are planned workstation OS upgrades, mobile clients, and clients running virus-scanning software.

Workstation OS. When you intend to implement SMS throughout a company, you must be aware of all the workstation OSs that are in use. Each OS works a little differently with SMS. For example, Windows 95's security model is different from Windows 2000 Professional's security model, so SMS installs different services that react in different ways to handle the two models. Optimizing SMS to work with the client OSs in your organization should be part of your SMS deployment plan.

One detail that SMS planners often overlook is their company's plan to upgrade workstation OSs throughout the organization. Companies frequently decide to implement SMS when they're facing workstation OS upgrades because SMS is so good at deploying these upgrades. If your company has an aggressive plan to upgrade the OS level on the company's computers after implementing SMS, you must consider key factors such as possible WAN and LAN upgrades to accommodate the traffic OS distribution will generate.

Mobile clients. Over the past several years, the theory that employees should be able to do their work anywhere has taken hold. More employees work from home and on the road. Mobile employees offer an interesting dilemma in implementing SMS because SMS is geared more toward computers that are connected to the network than it is toward unconnected users. However, if you don't identify and include mobile clients in your SMS deployment, you won't have complete information about the systems in your organization.

Microsoft says it's working on mobile-client solutions for upcoming versions of SMS, but in the meantime, companies with mobile employees must use third-party solutions. Altiris offers a full range of add-ons that complement and extend SMS and increase its viability in the mobile world. Other vendors that offer mobile solutions for SMS include Callisto Software, Mobile Automation, and Open Software Associates. You can find the URLs for these vendors in "Related Web Sites."

Virus-scanning software. Virus-scanning and -detection software is a crucial application on today's computers, but depending on the way you deploy it, virus software can affect SMS-client installation. When SMS inventories the software on the computer, it thoroughly reads the binary header information of specified files to obtain the product name, product version, and manufacturer name. This comprehensive scanning process can cause computer slowdowns if you've installed and configured virus software to provide deep and aggressive protection. You can modify both SMS and virus applications to alleviate the problem, but you must include this step in your overall deployment plan.

Component Considerations
Determining which SMS components are most crucial to your company will affect how you deploy SMS. During the planning stage, you should sit down with everyone involved and verify the objectives for implementing a systems-management product. SMS provides every aspect of systems management, and some aspects will be more important to your company than others. Pinpoint the most crucial systems-management need, then list the other components in order of importance. Obviously, you should be most concerned about successfully implementing the components your company thinks are most important.

For example, if your company is implementing SMS primarily because of its hardware and software inventory component, then much of your testing in the pilot phase should be to identify any problems with the SMS inventory services. As I mentioned earlier, the SMS software inventory process is intensive and can cause aggressive virus-scanning software to severely degrade the client computer's processing speed. A few changes to the virus scanner can alleviate the problem, but realizing up front that the inventory component must withstand rigorous testing could change how you roll out SMS.

When remote control is the key SMS component, you must address certain LAN and WAN considerations (such as slow links) and employee privacy and security concerns. If creating detailed reports about software usage and valid application licenses is the most crucial aspect, then you need to restructure the site by adding a top-level SMS reporting server. You might need to change the location of distribution points, client access points, and logon points and change the types of servers that you deploy at the other ends of WAN links to make SMS more reliable, easier to manage, and easier on network bandwidth.

Site and Network Considerations
When you begin working with SMS, you realize that it's dependent on a hierarchical structure that differs greatly from one company to another depending on the company's size, number of locations, network link speeds, and number of employees in each location. You must carefully consider how to organize your SMS structure.

SMS and SQL Server must reside on a Win2K or Windows NT server. SMS 2.0 works with Novell NetWare servers, but key components such as client logon and server inventory can have problems if NetWare servers are present. The next version of SMS, which is code-named Topaz and due in second quarter 2002, won't support NetWare at all. If you have NetWare servers in your network, identify the potential problems and plan for them. You might want to migrate from NetWare to Windows before deploying SMS.

You should also factor into your SMS deployment plans any planned Windows server OS upgrades. For example, many companies are opting to install a Win2K Active Directory (AD) forest parallel to an existing NT 4.0 domain structure so that they can slowly migrate resources to Win2K. In such a scenario, implementing SMS only in the Win2K forest and installing the SMS client software on computers as you migrate users to the new forest might make sense. This method would help provide for a controlled SMS deployment and, if planned properly, could help track users as you migrate them to AD.

Company Politics
Believe it or not, company politics can seriously affect the overall design and deployment of SMS. A design based on politics might not be the most efficient, but it can lead to greater acceptance of SMS.

For example, if your company has several sites, one site might require that it handle all software distributions locally instead of a central location distributing software. To meet this requirement, you'd need SMS expertise and a larger server in that location. Or one location might require that before your Help desk uses remote control to manage a remote computer, SMS requests the user's permission, whereas other sites don't require this additional security measure. To provide this feature, you need a separate component server at the location that wants the feature. (You can assign an existing server the responsibility for providing SMS component services—you don't necessarily need a separate server.)

Company politics can lead you to consider a unique SMS design. Consultants don't know your company's internal workings and might neglect to ask you about them, so you need to think about them on your own.

Ongoing Support
If many of your staff are unfamiliar with SMS, you must plan to find the best training possible. Deployment and post-deployment support services are a staple of any consulting contract, but training is harder to come by. If you locate a consulting company that offers this added benefit, latch on to it and add it to the front of your Rolodex. If not, look for a training course that offers hands-on classes by trainers who have actually worked with SMS in some type of company setting. The majority of training courses follow the approved Microsoft course material to the letter but offer no real-world experience.

You can't train everyone. Some selected IT employees will receive SMS training; others will learn SMS through experience over time. But administrators do require expertise to run SMS. When a site in the SMS hierarchy loses an employee who's trained or experienced with the product, the site and the whole SMS structure are affected.

When planning your SMS hierarchy, consider a top-down, umbrella-like support structure. Locate most of the SMS expertise at the top of the umbrella, and let it drip down from there. Then, when a lower-level employee resigns, a higher-level, SMS-proficient technician can cover the site until you train or hire a replacement. To roll out SMS, you first install a primary site server, which maintains information for the entire SMS hierarchy. Below the primary site server, you distribute child site servers; below them, for locations with few employees, you install secondary site servers. Thus, if you use the umbrella support structure I described, you're actually following the SMS design model.

If SMS is the first systems-management­type application your company has implemented, you might need to add some IT staff members to manage it. For most organizations, though, SMS just changes how the existing IT staff works by improving efficiency and delegation of tasks.

The Planning Imperative
SMS is a complete systems-management solution that can help large companies lower the cost of owning computer equipment and software and manage these resources more efficiently. Reading the SMS Administrator's Guide and visiting Microsoft's SMS Web site (http://www.microsoft.com/smsmgmt/default.asp) doesn't tell you everything you need to know to successfully implement this robust service. A consultant can help you plan and deploy SMS, but you need to choose your consultant carefully and make sure that he or she and you review all the hidden factors that might affect your SMS deployment—and determine during the planning phase how to address them. Overplanning for SMS is definitely the best way to ensure success.