Chapter 2: Primary Site Installation

 < Day Day Up > 



This chapter focuses on the process of installing a Microsoft Systems Management Server (SMS) 2003 primary site server. Although SMS is relatively easy to install, its implementation is far from trivial-as you'll see in the course of reading this book. Because creating an SMS site requires a great deal of thought, we begin this chapter with a discussion of planning considerations. Planning includes identifying such issues as your current network and domain structures, your Active Directory directory service structure, which SMS features you plan to install, what kinds of computers and operating systems your client base consists of, and personnel and training concerns. Next, we'll review preinstallation considerations, including hardware and software requirements and Microsoft SQL Server setup issues. We'll then look at the installation process itself, examining both express and custom setups. We'll also discuss the steps involved in removing SMS from the server if necessary. Then we review changes that take place after installation, such as what SMS services were added, what registry changes were made, and what service accounts or other Active Directory objects were created. We'll also take our first look at the SMS 2003 directory structure. Last, you'll learn how to navigate the SMS Administrator Console.

Note 

Installation of secondary sites and the implementation of site hierarchies are discussed in Chapter 4, 'Multiple-Site Structures,' and migration from SMS 2.0 sites to SMS 2003 is detailed in Chapter 20, 'Migration Issues.'

Planning Considerations

Perhaps the most commonly heard complaint at training sessions for new users of any version 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 start to work with almost immediately, SMS 2003 is a more complex product consisting of a rich set of services and components. 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'll deploy SMS 2003 can't be stressed enough. In short-planning, planning, planning!

To illustrate this point, the Microsoft Systems Management Server 2003 Concepts, Planning, and Installation Guide, one of the Online Library documents included with SMS 2003, has no less than seven excellent chapters (Chapters 7-13) that thoroughly outline a deployment and implementation planning strategy before even discussing the rather straightforward installation steps. Chapter 1 of the Microsoft Systems Management Server 2003 Operations Guide, available as a downloadable file from the SMS documentation Web site, as an orderable book, and through Microsoft TechNet, provides a step-by-step set of procedures for deploying an SMS site based on a set of common deployment scenarios. The information contained in these documents is quite detailed, so there's really no need for us to 'recreate the wheel' in that respect. I strongly encourage you to read those chapters-perhaps two or three times-for the details of SMS planning and site designing. Here, however, we'll highlight those key essentials that you should take into consideration in any deployment strategy. Let's take a look at each of these key elements and ponder some of the questions that can help us develop a strong implementation and deployment strategy.

Network Infrastructure

The first, and probably the most important, material you'll need is information 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 2003 requires the use of IP.

  • Into how many subnets is your network divided?

    Can you identify departments, regions, or other organizational divisions by their subnet? SMS 2003 assigns clients based on IP address or Active Directory site boundaries, or both.

  • How reliable is your network infrastructure?

    SMS 2003 will take advantage of well-maintained and optimized networks but will exploit poorly maintained networks. For example, if you're using 100 Mbps switches but have installed 10 Mbps network cards in your computers, your throughput will be only 10 Mbps. If you've installed 100 Mbps network cards, your throughput will be 100 Mbps. As another example, if your network is poorly routed, data collected from clients may take longer than expected to propagate from the client to the SMS site database.

  • What Microsoft Windows NT/2000 domain model is in use in your organization?

    Although not strictly speaking a network infrastructure issue, the Windows NT/2000 domain model is generally influenced by the network topology. The Windows NT/2000 domain model in use might influence your design of an SMS site hierarchy. If your Windows NT/ 2000 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, Windows 2000, and Windows Server 2003 domains.

  • Are you using Active Directory?

    SMS 2003 can leverage the use of Active Directory objects such as registered servers and computers and user and group accounts for discovery purposes.

  • Do you use Active Directory sites?

    If so, how many sites do you have and would, or should, your planned SMS site hierarchy mirror your Active Directory sites?

Once you have a clear understanding of your network infrastructure, you'll be better equipped to design an SMS site structure that takes advantage of the strengths of your network infrastructure while avoiding its weaknesses. In addition, you'll be better able to discern whether you'll need to make any changes to that infrastructure.

Organizational Structure

Just as important as having an intimate understanding of your network infrastructure is to fully comprehend your organizational structure. Areas of discussion would include the geographical, physical, and hierarchical or reporting structures of the organization, the current or proposed server and client environments (or both), and matters of security. You should have ready answers for these related questions:

  • What are the potential geographical implications for your proposed SMS site(s)?

    Are there any language or international operating system version concerns that you should address?

  • Where are your offices and potential SMS sites physically located?

    How do these sites communicate through the network (really part of the network infrastructure, but valid to restate here)?

  • What's the company's departmental or hierarchical layout?

    What kind of management structure is in place? What kind of departmental communication and reporting takes place and is required? What does your IT organization look like? Who in IT is responsible for what areas of the network infrastructure, servers, clients, Internet access, and backup/recovery?

  • How poorly or well does the organization structure fit your Active Directory domain and organizational unit (OU) structure?

  • What long term plans for your organization might impact the current structure (mergers, acquisitions, sales)?

  • What political implications need to be considered?

Needless to say, the answers to these questions will have a significant impact on your design strategy, especially the last item. In addition, as with your network infrastructure, you'll be better able to identify those areas that you should perhaps address prior to your implementation of any SMS site.

Server Environment

You'll need to know what kind of server environment you currently have and whether it can support your SMS site. Among the questions to be asked are:

  • How many servers do you have and where are they located within the organization?

    Do you plan to manage any of these servers through SMS?

  • Who is responsible for managing these servers and what's their level of responsibility?

    Will these managers assume any of the responsibilities inherent in managing SMS servers?

  • What are the hardware and operating system levels of these servers- that is, memory, disk space, CPU speed, operating system version, and service pack level?

    Are any upgrades required? Even though SMS 2003 supports a Windows NT domain structure, it can be installed only on servers running Windows 2000 with Service Pack 2 (or later) or Windows Server 2003.

  • What roles and functions have been assigned to these servers-that is, DHCP, DNS, IIS, WINS, Terminal Services, clustering? Which are domain controllers?

  • How are these servers currently being utilized, and what's their projected change in resource allocation over the next three to five years?

    Tools such as System Monitor can be valuable in ascertaining resource utilization.

  • If you plan to manage mobile (for example, laptop) clients by utilizing SMS 2003's advanced security, does your network run in Active Directory native mode? If not, can it do so?

Understanding and documenting this data about your servers gives you valuable assistance in determining placement of your SMS servers and whether you can use existing hardware or need to invest in upgrades or new equipment.

Client Environment

As important as your server configuration is the client environment that you'll be supporting. You should be able to have answers to this list of questions:

  • How many clients do you have and where are they located within your organization? How many of these do you plan to manage through SMS?

  • Who is responsible for managing these clients now and what's their level of responsibility? Will these managers assume any of the responsibilities inherent in managing SMS clients?

  • What are the operating system and service pack levels of these clients-that is, do they fall within the levels supported by SMS? What are the main applications installed? Should you consider any proprietary applications?

  • How many of your clients are considered 'mobile,' that is, using laptop computers? How do your mobile clients connect to the network?

In Chapter 1, 'Overview,' we briefly discussed the fact that SMS 2003 provides support for a wide range of clients, including mobile clients, but within a smaller range of operating systems than with SMS 2.0. The answers to these questions help to identify which clients can and can't be managed by SMS 2003, where you might need to perform upgrades, and potentially where you might need to maintain a down-level SMS 2.0 site for legacy clients.

Security

Securing your SMS site is explored in detail in Chapter 17, 'SMS Security.' Nevertheless, you should ask some security-related questions during your planning and documentation phase. These questions include:

  • What security policies are currently in place that might affect the deployment of SMS sites, servers, and clients? What kinds of security groups have been created?

  • Who has administrative access, and to what degree have administration-related activities been delegated?

  • What group policies and client lockdown levels are in force for users and computers?

The extent to which users have or don't have control over their desktops will have a significant impact on many areas of SMS-most importantly, installation of the client and deployment of packages, as we'll see later in this book. Also, you might need to address the delegation of administrative tasks to determine whether and how to best address the delegation of SMS-related administrative activities.

Systems Management Server 2003 Functionality

As part of your planning process, you should consider SMS 2003 functionality- which is to say, you must determine what SMS 2003 features and functions you intend to implement, and where. Some of the questions to be considered include:

  • Do you need to track hardware or software configurations or collect files from your clients? Which clients would be affected?

  • Do you need to deliver and install software packages on your clients or automatically initiate client-based programs or routines? Which clients would be affected?

  • Do you need to remotely troubleshoot your clients by taking control of their desktops, viewing system information, transferring files, running programs, or restarting the client? Which clients would be affected?

  • Do you need to track the use of installed applications on your clients and monitor and disallow use of unsupported programs? Which clients would be affected?

  • Do you need or want to manage site boundaries, target collections, and manage mobile clients through the functionality of Active Directory?

  • Do you have a need to produce and publish reports based on inventory and other client properties that can be viewed using a Web browser?

Your answers to these questions will certainly drive your decisions as far as the number of SMS sites to implement, the number and type of site systems to deploy in each site, and the site's ultimate hierarchical structure.

Putting It Together

At this point we can begin to tie some of these planning considerations together. An organization with more diverse requirements might require more SMS 2003 sites to be installed. For example, client options such as Remote Tools are site- wide options. In general, you can't 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 might be possible to use your network's subnets or Active Directory sites to your advantage. In the Remote Tools scenario, if the clients that require Remote Tools support can be segmented to their own subnet or Active Directory site, you can install a separate SMS 2003 site 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 or Active Directory site, you can give it its own SMS 2003 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 isn't always desirable, or even practical. These examples simply demonstrate the need for a clear understanding of your organizational structure and all its implications.

As a third example, consider how well-connected your network servers are. Suppose that a significant number of users move from subnet to subnet and still need access to packages and client component updates. Suppose, too, that some of those subnets are connected to the network through slow or unreliable connections. In this scenario you need to think carefully about the placement of SMS component servers such as client access points (CAPs), management points, and distribution points. Indeed, you might well decide that a better solution is to implement SMS sites in those poorly connected locations so that you have more control over how network bandwidth is utilized across those network connections.

The Hardware Inventory Agent collects hardware inventory on the SMS client, with changes copied to a CAP or management point. The CAP or management point, 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's 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 LAN 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 XP, for example, could require more than 300 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 2003 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 might 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're 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. As you can surmise, a thorough understanding and documentation of your network infrastructure, number and location of your servers and clients, and the structure and location of your Active Directory sites will be extremely valuable in evaluating design decisions.

Personnel, Training, and Testing

As you develop your deployment strategy, keep in mind who needs to use SMS 2003. You can easily delegate the features and functions of SMS 2003 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 2003 and to establish the appropriate levels of training and security required. Security options are explored in Chapter 17.

Another aspect of personnel considerations might be staffing issues. In a small site, one person might 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 2003 will be provided with a support team among whose members tasks will be divided throughout the SMS site structure. Remember that SMS 2003 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 domain support and your network infrastructure support. It truly requires no less.

Let's also not forget the need to properly staff the implementation process. The planning and design stage of your implementation is the ideal time to involve some, if not all, of the interested and affected parties in the deployment process, not only to receive their input, but also to facilitate a higher comfort level with the product and the way it works before it goes live. This leads us into a nice segue and a topic that's near and dear to this author's heart-training.

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

Several Microsoft-certified training centers offer courses in SMS 2003. Other training centers offer their own versions of SMS 2003 training. You should seriously consider some kind of formal training for yourself and your staff before rolling out SMS 2003. This training might include administrative tasks for those users involved in the day-to-day operations of SMS 2003, such as using Remote Tools or creating advertising packages. For those staffers involved in the background support of SMS 2003, 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.

Tip 

From time to time, Microsoft publishes online webcasts that you can view live or later at your leisure (if network administrators can ever find leisure time!). These can be informative and serve as a source of 'continuing' education. Watch for webcast notices on the Microsoft SMS Web site: http://www.microsoft.com/smserver.

Seriously consider setting up 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 isn't 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. And after your SMS sites have been implemented, you can continue to use your lab to test the viability of package scripts, to stage new clients, and to test troubleshooting and recovery strategies. This strategy will have a positive impact on productivity while reducing the potential for problems in the production environment. All in all, this will be money well spent with a quantifiable return on your investment!



 < Day Day Up > 



Microsoft Systems Management Server 2003 Administrator's Companion
Microsoft Systems Management Server 2003 Administrators Companion (Pro-Administrators Companion)
ISBN: 0735618887
EAN: 2147483647
Year: 2006
Pages: 178

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net