Planning Considerations

[Previous] [Next]

Perhaps the most commonly heard complaint at training sessions for new users of SMS is, "I installed SMS out of the box and I can't get it to work." Unlike Microsoft Word or Microsoft Excel, products that you can install and begin using almost immediately, SMS 2.0 is a more complex application. As we've seen, it contains many features and functions and requires more than just a casual walk-through. Indeed, the importance of determining where and how you will deploy SMS 2.0 can't be stressed enough. In short, planning, planning, planning!

The Systems Management Server Administrator's Guide included with SMS 2.0 has an excellent chapter (Chapter 3) that outlines a deployment strategy, so there is really no need for us to reinvent the wheel in that respect. Read that chapter first for the details of SMS planning and site designing. Here we'll look at a few main points that any deployment strategy should take into consideration.

Network Infrastructure

The first, and probably the most important, information you'll need is about your network's infrastructure (boundaries, hierarchy, and connectivity). You should have concise answers to each of the following questions:

• How is your network structured? Is it one large LAN, or is it segmented by routers and remote links into a WAN? This information will influence your placement of SMS sites and site systems.
• What network protocols are you employing? SMS 2.0 requires the use of IP or IPX.
• Into how many subnets is your network divided? Can you identify departments, regions, or other organizational divisions by their subnet? SMS 2.0 assigns clients based on IP address or IPX network number.
• How reliable is your network infrastructure? SMS 2.0 will make the most of well-maintained and optimized networks but will exploit poorly maintained networks. For example, if you are using 100-MB switches but have installed 10-MB network cards in your computers, your throughput will be only 10 MB.
• What Windows NT domain model is in use in your organization? Although not strictly speaking a network infrastructure issue, the Windows NT domain model is generally influenced by the network topology. The Windows NT domain model in use may influence the design of your SMS site hierarchy. If your Windows NT domain structure is no longer efficient or appropriate for your organization's needs, now would be a good time to reconsider and restructure your Windows NT domains.

Once you have a clear understanding of your network infrastructure, you will be better equipped to make other deployment decisions.

Systems Management Server 2.0 Functionality

Next you should consider SMS 2.0 functionality—which is to say you must determine what SMS 2.0 features and functions you intend to implement, and where. You might decide to deploy SMS 2.0 to distribute packages to clients and to collect hardware inventory. Perhaps some clients need to be remotely managed by a help desk while others do not. Perhaps certain departments or regions need to handle their own packages and advertisements. An organization with more diverse requirements may require more SMS 2.0 sites to be installed. For example, client options such as Remote Tools are sitewide options. You cannot deploy Remote Tools for only some clients in a site; instead, you must deploy Remote Tools for all clients in a site. This is where a good understanding of your network infrastructure will be beneficial. It may be possible to use your network's subnets to your advantage. In the Remote Tools scenario, if the clients that require Remote Tools support can be segmented to their own subnet, a separate SMS 2.0 site can be installed to provide Remote Tools support.

As another example, suppose the finance department requires that its employees maintain and deploy their own packages within their department. Their packages are specific to their environment and their users. You could manage all the packages from a central site, but doing so would mean that the finance-specific packages might also need to move through a wider network path than is necessary. If the finance department is defined by its own subnet, it can be given its own SMS 2.0 site. Employees can then deploy their packages only within their own subnet and not affect the rest of the network. Remember that creating multiple sites like this is not always desirable, or even practical. These examples simply demonstrate that you need to focus your thinking as you develop a deployment strategy for SMS 2.0.

Another consideration along these lines, and tying in network infrastructure concerns as well, involves the placement and communication of SMS sites and site systems. In general, SMS site systems, such as client access points (CAPs), logon points, and distribution points, should reside within the same LAN as the site server and SMS database server, or they must at least have reliable, high-speed connections available if they are located remotely. This requirement is due largely to the amount of information that is transferred between these site systems and the site server. The network traffic involved will be discussed as we talk about enabling and managing each SMS feature later in this book. For now, let's look at one scenario.

Hardware inventory is collected on the SMS client by the Hardware Inventory Client Agent, with changes copied to a CAP. The CAP, in turn, sends the changes on to the site server. The site server updates the SMS database with the change information. The amount of data that is generated, and the corresponding network bandwidth that will be used, will be determined by the number of clients involved and how frequently inventory information is collected. Bandwidth considerations will generally be less of a concern within a local network than across a wide area link. In other words, it will be more efficient and perhaps less disruptive to the network to collect this inventory if the client, CAP, site server, and database are all located in the same LAN.

Now suppose that your company needs to send packages from a central location to various geographic regions around the world. Package files are copied to distribution points within the SMS site. These files include source files, programs, and installation scripts and can represent a fairly large amount of data. Microsoft Office, for example, could require more than 200 MB of storage space. This data must be moved across the network to the distribution points, and generally moves in an uncompressed state. You could certainly plan for one large SMS 2.0 site, with distribution points in each geographic region. Your packages will then need to be copied to these distribution points across WAN links and will have to contend with any other WAN traffic that may be occurring. Alternatively, you could plan for an SMS site in each geographic region. Each SMS site can have one or more local distribution points. Package files are compressed before they are sent from one site to another. Also, you can adjust how much bandwidth is actually used when communicating from one site to another. This arrangement should significantly improve WAN performance related to package distribution.

Personnel, Training, and Testing

As you develop your deployment strategy, keep in mind who needs to use SMS 2.0. The features and functions of SMS 2.0 can easily be delegated to various users. Help desk personnel, for example, can be given access to Remote Tools but not to any other features. An SMS administrator in the finance department might be given the ability to create packages and advertisements and to deploy them only to finance department users. This distribution of tasks is an essential part of determining where and how to implement SMS 2.0 and to establish the appropriate levels of training and security required. Security options are explored in Chapter 16.

Another consideration might be staffing issues. In a small site, one person may be responsible for most or all SMS-related support issues, including not only things like package distribution and remote control, but also site design, database maintenance, network analysis and troubleshooting, status message analysis, SQL administration, package scripting, and general troubleshooting. But in a medium-sized SMS site structure—let's say three SMS sites with perhaps a thousand clients—one person will be hard-pressed to adequately maintain all aspects of the SMS sites. In fact, each site should have at least one SMS administrator assigned. In an ideal setting, SMS 2.0 will be provided with a support team among whose members tasks will be divided throughout the SMS site structure. Remember that SMS 2.0 is designed to be a network management tool. This product is not trivial to set up or to maintain. Treat it with the same consideration that you give your Windows NT domain support and your network infrastructure support. It truly requires no less.

Along with appropriate staffing comes appropriate training. Even if management and budget constraints would prefer it otherwise, SMS 2.0 is definitely not the kind of product that you can install out of the box and begin using immediately. (You will hopefully come to this conclusion yourself by the end of this book.) And while you could teach yourself how to use SMS 2.0, the most effective learning environment will be one that is structured and controlled, and one in which you can freely destroy SMS if you like!

Several Microsoft-certified training centers offer courses in SMS 2.0. Other training centers offer their own versions of SMS 2.0 training. You should seriously consider some kind of formal training for yourself and your staff before rolling out SMS 2.0. This training might cover administrative tasks for those users involved in the day-to-day operations of SMS 2.0, such as using Remote Tools or creating advertising packages. For those staffers involved in the background support of SMS 2.0, training should include a thorough review of SMS services and processes, security, site system roles, network traffic considerations, and performance issues. Guides such as this book will serve to supplement and reinforce that training.

MORE INFO

---

For information about courses, certifications, and training providers, refer to Microsoft's training Web page, at www.microsoft.com/train_cert.

Consider too the possibility of instituting a lab environment in which you can simulate your network environment, experiment with different site and site system configurations, perform stress testing on site systems and network load—without worrying about damaging SMS. Such an undertaking is not always possible, of course, but think of how much time, energy, and expense you might save by testing your SMS strategy in a lab rather than in live production.

Client and Server Configuration

The configuration topic includes two areas of concern: current configuration and standard configuration. SMS 2.0 does have some specific hardware and software requirements for both the server and the client computers. As part of your deployment strategy, it would be more than prudent to canvass your current install base of computers and determine which ones meet the requirements to be SMS clients and SMS site systems. You can then identify those computers that require upgrades in software or hardware and those instances in which an investment in new equipment is preferred. With the help of SMS 2.0, you can establish hardware and software standards for your organization that will be applicable to all new computers purchased, and you can identify those current computers to which the standards must be applied. As you continue to test and refine your network infrastructure, again with the help of SMS 2.0, these standards may be extended to include recommendations for network devices, protocols, and communication links as well.