Appendix E - Designing Your SMS Sites and Hierarchy

The task of designing your SMS sites and hierarchy is done during the planning phase, before implementing SMS 2003 in your production environment. This appendix includes an overview of SMS hierarchy design and guidelines for designing your SMS sites and arranging them in a hierarchy.

To benefit most from this appendix, you should be familiar with the following chapters in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide:

• Chapter 2: “Understanding SMS Sites”

• Chapter 3: “Understanding SMS Features”

While designing your SMS sites and hierarchy, see Appendix F: "Appendix F - Capacity Planning for SMS Component Servers," to determine how many site servers and site systems you need.

The following topics are covered in this appendix:

• Overview

• Strategies for Planning

• Site Deployment Planning

• Designing SMS Sites and the SMS Hierarchy

• Site Configuration Planning

• Advanced Design Issues

• Reviewing and Testing the Design in the Lab

Overview

When planning your SMS sites, start by examining your organization’s infrastructure. To successfully design your sites and hierarchy, perform the preplanning steps identified earlier in this book in “Preplanning Phase.” This includes gathering and analyzing data about your organization and its environment. After you analyze this data, examine the technical and business considerations that affect SMS site and hierarchy design. Then you can create an appropriate design. The design should provide the ability for server hardware to scale up as your organization grows.

It is critical that you test your hierarchy design before deploying SMS in your production environment. To do this, create a representative test hierarchy in a test environment that is isolated from your production network. The test hierarchy is a smaller scale version of your SMS hierarchy. You can use the data that you gather, and the experience that you gain in your test lab and during your pilot project, to refine your final hierarchy design and implementation. Appendix D: “Appendix D - The Pilot Project,” guides you through the process of creating a pilot project to troubleshoot and refine your design while planning your server and client deployment for SMS 2003.

Designing an SMS site involves defining site boundaries and roaming boundaries, establishing the SMS site systems to be deployed within the site and their physical locations, and determining recommended hardware specifications.

Designing the SMS hierarchy involves establishing the logical relationships between distinct SMS sites and determining where information is reported. In designing the SMS hierarchy, you choose a primary site to serve as the central site. The central site is the parent to other sites. The first primary site you install is a stand-alone site. It has neither parent sites nor child sites. The site can remain a stand-alone site, or you can attach it to other sites to build a hierarchy. Determining the type of site to deploy in each location is a critical step in the hierarchy design planning process. After you define the sites, you can build your hierarchy.

Note

Implementing a single SMS site to manage all network resources is usually not practical for large organizations or for any organization with multiple locations communicating over wide area network (WAN) links. These organizations usually require multiple SMS sites arranged in hierarchies.

Figure E.1 shows a sample hierarchy design based on geographic location for an international company that has its headquarters in Chicago.

Figure E.1   A three-tier SMS hierarchy based on geographic location

Figure E.2 shows a sample hierarchy based on the residential and commercial organizational divisions for a company with a single location in Seattle.

Figure E.2   A two-tier SMS hierarchy based on organizational division

Strategies for Planning

Your goal is to deploy and configure SMS successfully and efficiently, with minimum interruption to your users and the network. Proper planning and a well-documented pilot project can help you achieve this.

Divide your deployment and configuration into phases, communicating and documenting the results at each phase. See the “High Level Planning” section for guidelines on dividing your deployment and configuration into phases. As you do this, review the “Key Elements to a Successful Deployment” section later in this appendix. A sample high-level deployment plan is provided at the end of this section.

For more information about deployment scenarios, see Chapter 1: “Scenarios and Procedures for Deploying SMS,” in the Microsoft Systems Management Server 2003 Operations Guide.

High Level Planning

Plan your steps, and then document the results as you proceed from one step to the next. There are four general phases in an SMS deployment:

• Site deployment

• Site and hierarchy configuration

• Client deployment

• Feature configuration

In the site deployment phase, you install your SMS sites. In the site and hierarchy configuration phase, you configure each site and build a hierarchy by attaching sites. In the other phases, you deploy your clients and configure the SMS features you want to use, such as software metering. Feature configuration is not covered in this book. For information about configuring features, see the Microsoft Systems Management Server 2003 Operations Guide.

Table E.1 shows the high level steps for deploying and configuring an SMS hierarchy and SMS clients. Depending on the complexity of your SMS hierarchy design, and the size of your computing environment, you might perform these steps in varying order in different areas of your organization.

Table E.1   High Level Deployment and Configuration Steps

Phase	Steps
Site deployment	Install primary sites. Install secondary sites.
Site and hierarchy configuration	Configure site security. Configure tasks, alerts, and status system. Configure site boundaries and roaming boundaries. Prepare site system computers. Assign site system roles. Configure site communications. Attach SMS sites.
Client deployment	Enable resource discovery and client installation methods.
Feature configuration	Enable and configure the SMS client agents.

You can approach deployment and configuration in different ways, depending on the size and complexity of your SMS hierarchy. Table E.1 shows one approach. Be aware that you can customize the order of these steps differently for your environment. This is especially true for larger or more complex environments.

For example, you might choose to deploy all your SMS sites before deploying any SMS clients. Or, as you deploy each SMS site, you might deploy SMS clients to that site. Or, you might choose to deploy SMS clients when you have finished connecting the sites in each hierarchy branch. Make these decisions when you plan your deployment and configuration. The plan you design is dependent on many factors. Your pilot project can help you optimize the plan.

Key Elements of a Successful Deployment

An understanding of the key elements of a successful SMS deployment is important as you plan your deployment and configuration. Incorporate these elements into your plan. Practice these recommended strategies during the pilot project and during the actual implementation of SMS. Deploying SMS to the production environment shares many characteristics with deploying SMS during the pilot project. You should use the pilot project to validate the deployment and configuration plan that you create. The pilot project is described at the end of this appendix.

The key elements to a successful SMS deployment are listed here.

Communicate to Managers and Administrators Throughout the Deployment

While you are deploying and configuring SMS, inform the project manager and all appropriate personnel at each phase of deployment. Inform network administrators and Active Directory administrators about your site installation schedule and the active network links that will be affected during the installation so that they are prepared for any surges in network activity. Inform your help desk staff in advance of any SMS installations, so that they are prepared for questions or problem reports from end users.

Schedule Major SMS Activities for Non-peak Hours

Minimize the effect of the deployment by carefully scheduling major SMS activities for non-peak hours. For example, if your plan includes deploying secondary sites over slow or unreliable links, you should schedule these deployments to occur after critical business hours. Also, if one group of users is in the midst of completing a major project or deadline, consider waiting to deploy SMS to that group until their project is finished.

Inform and Educate Your Users About SMS Before Deploying It

Develop an information and training strategy for users in your organization, and test the strategy on the users in your pilot group. By educating users about SMS functionality, you can alleviate any privacy concerns they might have about running the SMS client on their computers.

Document the Installation Steps

Each administrator who is involved in deploying SMS sites should use procedural documentation as a guideline and checklist. Creating this documentation is part of the planning process. In your deployment and configuration plan, include step-by-step instructions for setting up and configuring the operating system (if necessary), Microsoft® SQL Server™, SMS 2003, Internet Information Services (IIS), and other necessary components that are outlined in the “Getting Started” chapter. Test the documented plan in your lab and during the pilot project. Revise the plan as needed when you test it so that you can successfully implement the plan when you deploy SMS in your production environment. Your plan revisions might involve modifying the deployment steps described in the “High Level Planning” section earlier in this appendix.

Include Risk Management in Each Phase

Be sure you analyze the risks that are introduced at each phase of the pilot project. To avoid risks, you must exercise change control and management. Potential risks are described in Appendix A: “Appendix A - Understanding Methodology and Risk.” Keep your project plan document updated with identified risks and results at each phase. This information will be valuable to you later, when you implement SMS in your production environment.

Pay Attention to Detail

The simplest logistical details must be planned for any enterprise-wide software deployment. Otherwise, something as seemingly insignificant as a lost key to your server room can cause your deployment to fail. Prepare a checklist of the logistical details of each site deployment, and include items that your administrator must be prepared for, such as:

• Server room access codes or keys.

• Emergency contact phone numbers and working communication devices.

• Problem escalation plan.

• Any electrical or other wiring work required in the server room before deployment.

• Server rack reorganization, if necessary.

• Location of the SMS installation media.

• Required system password information.

• Log book for recording installation and site configuration information, problems, and results.

Schedule Resources

In the preplanning phase, the project manager creates a team of SMS administrators with varying roles. Planning your deployment requires scheduling the assigned administrators to perform their roles in the pilot project, site deployment, site configuration, and client deployment. If you do not secure resources early in the project, your SMS deployment will be at risk. Scheduling resources might include arranging for long-distance transportation and accommodations in other regions. Ensure that your support and administrative teams are properly trained and prepared for the deployment. For more information, see Appendix B: "Appendix B - Preplanning Phase Steps."

Configure SMS Properly and Document the Effects of Configuration Changes

Ensure that you plan to configure SMS properly so that it does not unnecessarily load the network during deployment. Be especially careful when you configure components, such as Network Discovery and inventory, which could use substantial bandwidth or disk space. For example, do not configure any network-intensive feature for a brief interval on a busy network. Consider the business reasons you have defined for using particular SMS features. For example, if inventory reports are not required to run and be revised on a daily basis, then you do not configure inventory to run on a daily basis.

Document the effects of each configuration change in your project plan. For more information, see Appendix G: "Appendix G - Deploying and Configuring SMS Sites."

Important

Enable SMS features in a controlled manner. Avoid enabling multiple features simultaneously, which can cause unexpected network bandwidth consumption and result in a loss of productivity in your organization.

Test Your Design and Implementation in a Test Lab and Pilot Project

As you plan your deployment, it is important that you test configuration variations and deployment scenarios in your test lab environment on an isolated network in your organization. Not testing can result in undesirable results in your production environment at deployment time.

Do not set up your test lab in your production environment, and do not install SMS on any of your production servers before installing it and working with it in your test lab. Because site codes and server names are registered in Windows Internet Name Service (WINS), be sure to reserve special names to use in your test lab. Do not use these again in your production environment. Ensure that your test lab closely replicates your proposed production environment. For information about setting up a representative test lab, see Appendix B: "Appendix B - Preplanning Phase Steps."

Later, conduct a pilot project to deploy SMS to a small fraction of your production environment, and then monitor the results. The pilot project verifies that your SMS design is valid, and that the testing of that design is valid. For more information, see Appendix D: "Appendix D - The Pilot Project."

Create and Document a Backup and Recovery Plan

Incorporate backup and recovery preparation into your SMS deployment plan. A solid backup plan enables you to recover more quickly and easily if you encounter any problems during the deployment. Test these plans in your test lab and pilot project. For more information, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.

Sample Plan

This section includes a basic, sample deployment plan for a particular scenario. Although the scenario is fictitious, it is designed to give the reader an idea of how to document the plan at a high level. The rest of this appendix describes in detail the decisions you must make when devising your plan. This sample deployment plan is primarily designed to show you how to create a high level plan for deploying and configuring SMS. It is not designed to replace your customized plan.

This sample deployment plan is for a large organization called Contoso Pharmaceuticals that has 20,000 newly installed client computers in one central location. All of these clients are in one Active Directory® site. Contoso’s Active Directory infrastructure uses only one Active Directory forest. Contoso has three other locations in different geographic regions. Each location is in its own Active Directory site and is connected to the central location’s network by a 1.5 Mbps T1 link.

Contoso’s IT department is divided into two administrative areas. One IT group is responsible for supporting computers at headquarters, and the other supports computers at the remote offices. The company is planning for significant future growth, both at its headquarters and in remote locations. Based on this divided management scope, the decision is made to create one administrative SMS site that directly manages all the desktop computers at headquarters, and another SMS site that manages the computers at all remote branch offices.

After thorough planning, Contoso’s IT department might create and document a high level SMS site and client deployment plan like the one shown in the following worksheet. Central headquarters has three primary sites: one for the secondary sites to report to, another to assign local Advanced Clients to, and one to be the central site for reporting. The clients at the secondary sites are required to run the Legacy Client. Contoso’s IT department creates a document similar to this:

Figure E.3   Sample high-level SMS 2003 deployment and configuration plan

High Level SMS Deployment and Configuration Plan at Contoso Pharmaceuticals

Install an SMS primary site server at headquarters. Use site code A01. Use this site for administrative purposes only, like reporting and gathering status. Perform the following tasks at site A01: ____ Remove existing SMS site boundaries to prevent client installations. ____ Configure SMS object permissions. ____ Configure maintenance tasks, alerts, and status system. ____ Lock down and configure Internet Information Services (IIS) for SMS reporting. ____ Set up the reporting point. Using the SMS Administrator console at primary site A01, install secondary sites at each of the three remote offices. Use site codes A02, A03, and A04. Perform the following tasks as each secondary site is installed: ____ Configure SMS object permissions. ____ Configure maintenance tasks, alerts, and status system. ____ Configure site communications (senders and addresses). ____ Add a CAP and a distribution point to each secondary site server. ____ Configure the secondary site with site boundaries. ____ Configure a discovery method at the secondary site. ____ Use Client Push Installation to install the SMS Legacy Client on each computer assigned to a secondary site. Install another SMS primary site server at headquarters. Use site code B01. Perform the same tasks listed in step 1. Then perform the following tasks at this primary site: ____ Add a management point and distribution points to the site. ____ Configure SMS site boundaries. ____ Enable Active Directory System Discovery but not SMS client installation. Install another SMS primary site server at headquarters. Use site code C01. This will become the central site. Then: ____ Perform the same tasks listed in step 1. ____ Install a server locator point at site C01. Complete the hierarchy: ____ Configure site communications (senders and addresses) as needed. ____ Attach sites A01 and B01 each to their parent central site CO1. ____ Create queries in site B01 to divide your clients up into collections. ____ Use the Client Push Installation Wizard to install the Advanced Client one collection at a time in site B01.

The final project deployment plan that Contoso creates is much more detailed than the high level plan displayed in this worksheet. The final project plan includes all the details created in the project plans for hierarchy design, security strategy, backup and recovery, site and client deployment, and configuration.

After Contoso administrators have deployed the SMS hierarchy, they enable SMS features, one at a time, at each SMS site. As they enable each feature, they monitor it and test it before enabling another feature.

Contoso is careful to verify the integrity of the SMS hierarchy at each step, even as they are testing their deployment plan in the test lab and pilot project. For example, the site systems for the planned hierarchy are put in place, and the integrity of the SMS hierarchy is confirmed before any site boundaries are configured or clients installed.

Site Deployment Planning

After designing your hierarchy and testing the design, you should plan and carefully document how you will deploy SMS. Some of your deployment decisions depend on the SMS features that you plan to use and how you plan to use them. The section “Preplanning Phase,” earlier in this book, contains guidelines on analyzing and documenting your environment and your requirements. You must take this information into account when you create a deployment and configuration plan.

Caution

Use your test lab to verify and modify the plan. Then, finalize the plan during the pilot project. Do not merely insert the SMS 2003 product CD and run Setup.exe without planning your deployment. This is extremely risky and is not recommended. Installing SMS in your production environment without planning can cause unexpected network activity resulting in reduced productivity.

SMS site deployment should be done using a phased approach. In creating your plan for deployment, there are a number of things to consider, and many decisions to make. Be sure to consider the following items in your deployment plan:

• Hardware and licensing

• Active Directory

• SMS site server deployment

• SMS site database server

• SMS Administrator console and related tools

• Setup options

• Domain and security requirements

• NetBIOS requirements

• Site naming

Hardware and Licensing Requirements

Determine the number of SMS site licenses and SQL Server licenses you must have to deploy your SMS hierarchy. Your exact SMS hardware requirements are dependent on numerous factors that are derived from your computing and network environment, and from how you will use SMS features. Use the information in Appendix F: “Appendix F - Capacity Planning for SMS Component Servers,” with your pilot project results to determine server sizing. Also, review the basic hardware recommendations in the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide You should adjust your hardware requirements as needed during the pilot project.

Your deployment plan should include the following tasks:

• Checking the hardware compatibility list

• Obtaining SMS site licensing and SQL Server licensing

• Determining how to allocate hardware

Checking the hardware compatibility list

Before you install Windows Server 2003 or Windows 2000 family products on a computer, check the Microsoft hardware compatibility list (HCL) to determine whether the computer is certified by Microsoft as being compliant with Windows 2000 or Windows Server 2003, and that the computer hardware is listed in the HCL. You can access the HCL at https://www.microsoft.com/hwdq/hcl. SMS runs successfully on a variety of host systems. There are no SMS-specific reasons to run SMS on hardware certified by Microsoft. However, if you do require the assistance of Microsoft Product Support Services, they might require that your hardware be certified by Microsoft before they can assist in resolving any issues you have.

Obtaining SMS site licensing and SQL Server licensing

Carefully plan to purchase the correct number of SMS site licenses and SQL Server licenses that you estimate needing before deploying SMS. For licensing requirements, see the “Getting Started” chapter.

Determining how to allocate hardware

Consider the logistical aspects of deploying your SMS site server hardware at locations that do not have existing server hardware in place. Determine who will do the server installations and how to ship the computers to remote locations. You might decide to install SMS on the servers before shipping the servers to their locations. Or, you might choose to ship the servers to their production location and then install SMS on them.

There are three possible staging methods for server installations:

1. Perform the SMS installation at a central location for all primary and secondary site servers, and then ship the preinstalled servers out to each site.

   At primary site locations, the local SMS administrator physically installs the primary site server computer.

   At secondary sites, a local user physically installs the secondary site server computer, according to instructions accompanying the computer.

2. Perform the SMS software installation centrally for all primary site servers, but do not install SMS on the secondary site servers. Install and configure the operating system on the secondary site servers and ship those computers to each site. A local user at the secondary site installs the secondary site server computer equipment. The SMS administrator installs SMS from the SMS Administrator console at the central location. Or, if network bandwidth is limited, the administrator uses another method to install the remote secondary site.

3. Perform the installation of each primary and secondary site server computer and SMS software on location. This is done by an SMS administrator who travels to the location.

Active Directory Considerations

To take advantage of the simplified administration and many of the new features in SMS 2003, migrate to Active Directory. Active Directory migration can be performed before or after your SMS deployment.

Important considerations are:

• Active Directory schema extensions for SMS.

• Active Directory environment preparation.

• Managing Active Directory replication.

• Domain controller issues.

• Active Directory forest considerations.

Active Directory Schema extensions for SMS

In planning your SMS 2003 deployment, an important decision for organizations using Active Directory is whether or not to extend the Active Directory schema for SMS. In Windows 2000 domains, you cannot remove the SMS schema extensions after you have extended the schema. If you choose to extend the Active Directory schema, you must decide whether to do it before, during, or after setup. Determine who the Active Directory administrator is and what permissions are needed to perform the schema extension. For more information, see the “Setup Options” section later in this appendix.

Active Directory environment preparation

Carefully consider your Active Directory site configuration before you define SMS site boundaries. If the SMS site server is in an Active Directory domain, then you must ensure that the Active Directory administrator has configured the IP subnets for the forest and that the chosen Active Directory site configuration is relatively stable. Do not set up Active Directory site boundaries in SMS if the Active Directory site configuration is only temporary, except during the pilot project.

Managing Active Directory replication

To understand Active Directory replication issues when you are deploying SMS Legacy Clients, you must have an understanding of both Active Directory account replication and SMS client account activity. Determine whether the interaction of Active Directory replication and SMS might be an issue in your organization.

It is important that Active Directory replication is monitored during your SMS deployment. Due to the creation and modification of domain accounts during SMS Legacy Client deployment to domain controllers, an SMS client deployment in a large, highly dispersed network with slow network links generates a lot of updates to the Group Security Policy file. Many copies of the Group Security Policy file are replicated to domain controllers. On a domain controller, this file could reach a size of several hundred kilobytes. This can cause severe backlogging and disruption of File Replication Service and a detrimental effect on domain controller activity. It can also generate many Windows security log messages. Be sure to monitor Active Directory replication in your test lab and during the pilot project. Consult with your Active Directory administrator to ensure that Active Directory replication is optimized.

For more information about SMS accounts and file replication, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Security and Appendix C: “Appendix C - Client Deployment Planning.”

For more information about Active Directory replication, see Chapter 6: “Active Directory Replication,” in the Microsoft Windows 2000 Distributed Systems Guide in the Microsoft Windows 2000 Resource Kit.

Domain controller issues

Carefully consider your Active Directory deployment. If you are planning to upgrade your domain controllers to an operating system in the Windows 2000 Server family or in the Windows Server 2003 family, be aware of the best practices and potential issues that are described in this section.

Important

As a best practice, when you are upgrading a Windows NT 4.0 operating system, upgrade the primary domain controller (PDC) to Windows 2000 or the Windows Server 2003 family before upgrading any other domain controller computer in the domain. The first domain controller computer in the domain that you upgrade adopts the role of the PDC. For example, if the first computer that you upgrade from Windows NT 4.0 is a backup domain controller (BDC), that computer automatically becomes PDC emulator for the domain.

Consider, for example, a scenario in which you plan to implement an SMS 2003 site at each of your organization’s remote branch offices. Each branch office has a Windows NT 4.0 BDC connected over a slow WAN link. You plan to install SMS 2003 on each branch office BDC. SMS requires that you first upgrade these BDCs to an operating system in the Windows 2000 or Windows Server 2003 family. However, when you upgrade the BDCs at your branch offices, the first BDC you upgrade automatically becomes the PDC emulator. If you allow this to happen, all of the Active Directory replication traffic is sent to and from this branch office, over the slow network link, creating bottlenecks on your network.

When you plan your deployment, consider the following alternatives if you must install an SMS 2003 site on a domain controller:

• Upgrade your PDC to Windows 2000 or the Windows Server 2003 family before you upgrade any SMS site servers that are domain controllers.

• Properly plan and deploy Active Directory throughout the organization before you deploy SMS 2003. This is a significant task that should be performed by the Active Directory administrator. This alternative could delay your SMS 2003 implementation.

• Instead of deploying SMS to your branch office BDCs, install SMS on stand-alone servers that are running Windows 2000 or Windows Server 2003 family operating systems. This alternative might require you to acquire new hardware, which could be expensive.

• Replace the Windows NT 4.0 BDCs at your remote locations with stand-alone servers that are running Windows 2000 or Windows Server 2003 family operating systems, and let all the authentication traffic flow over the WAN to the nearest domain controller. If this scenario is not feasible for your organization, a recommended best practice is to set up a newly upgraded domain controller at a location close to the domain controller that is acting as PDC emulator, and then ship the new domain controller to the remote office after domain controller replication is completed. Or, create a domain controller on a portable computer that is running Windows 2000, and connect it to the network at the remote office. Then, to avoid the initial replication traffic, upgrade the older Windows NT 4.0 BDC to Windows 2000 Server or Windows Server 2003 family. Afterward, you can decommission the portable computer.

Active Directory forest considerations

When you are deploying SMS sites in an Active Directory environment, be aware of limitations across forests, described in the “Active Directory Considerations” section later in this appendix.

SMS Site Server Deployment Considerations

You should plan the sequence in which you deploy and connect your SMS site servers. You build the SMS hierarchy by attaching sites to other sites. You attach sites by specifying parent sites for each site, except for the central site. Typically, you install the primary sites first, configure them for security, maintenance tasks, and status alerts, and then set up communications between them.

After you install and configure the senders and addresses between sites, install secondary sites. You cannot install a secondary site until you install its parent primary site. By using the guidelines here, create and document a plan for deploying your sites. For more information about SMS site concepts, see Chapter 2: “Understanding SMS Sites” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

Caution

If you are using the Windows Cluster service, do not install the site server or any SMS site system on the shared disk (cluster disk) of a Windows server cluster. For more information about SMS interoperability with the Windows Cluster service, download the “Microsoft Windows 2000 Server Clustering Interoperability with SMS” white paper from https://www.microsoft.com/smserver/techinfo.

Deploying Central and Administrative Sites

The first SMS site you deploy is a primary site. It is not required that this site be your central site, although you can choose for it to be the central site. Large organizations that do not use their central site for administrative purposes might use the first primary site that is installed as an administrative site and later attach it to the central site. Often, a central site does not directly manage any clients (no SMS clients are assigned to the central site). Instead, the central site acts only ** as an administrative site — the central repository of information and administration, such as SMS reporting and remote tools.

Figure E.4 shows a sample central and administrative site deployment plan, indicating only the order in which the SMS administrator plans to deploy the sites in the SMS hierarchy. Client deployment and site configuration is not included in this basic plan.

1. Set up and configure primary site A00 as the administrative site for the hierarchy. It is used for reporting, help desk functions (such as remote control), and other administrative purposes. No clients will be assigned to this site.

2. Install and configure a secondary site reporting to primary site A00.

3. Install and configure another secondary site reporting to primary site A00.

4. Install a fourth SMS site as a primary site with no clients reporting to it. Then, configure this site as a parent to primary site A00. It becomes the central site in the hierarchy, and all data propagates up to it. To reduce the load on the central site server, primary site A00 remains an administrative site for SMS software distribution.

5. Install primary site B00 and configure it to use the central site as its parent. Both Advanced Clients and Legacy Clients will be assigned to this site.

6. Attach a secondary site to primary site B00. Legacy Clients will be assigned to this site.

Figure E.4   Sample site deployment plan

Configuring Primary Sites with Clients

After you install an SMS site, you use the SMS Administrator console to configure the site boundaries and other site settings. For planning information about these tasks, see the “Site Configuration Planning” section later in this appendix. In general, plan to perform post-installation tasks in the following order:

1. Configure SMS object permissions.

2. Configure tasks, alerts, and status system.

3. Configure site boundaries and roaming boundaries.

4. Prepare site system computers.

5. Assign site system roles.

6. Configure site communications.

7. Attach SMS sites.

8. Enable resource discovery and client installation methods.

9. Enable SMS features one at a time.

If you attach sites that have existing hardware or software inventories, a burst of network traffic occurs as the inventory data is sent up the hierarchy. Remember this when you deploy your sites, so the extra traffic has as little effect on business functions as possible.

Deploying Secondary Sites

Before you install a secondary site, you must install a parent primary site. By default, the SMS Administrator console is not installed on a secondary site server. You can install the SMS Administrator console on the secondary site server or at a workstation that can connect to the parent primary site if you must distribute duties among administrators. You can set object permissions in the remote SMS Administrator console to limit access to only secondary site clients.

There are several different methods of installing a secondary site. The method you choose is dependent on the resources that are available to you at the location of the secondary site, available network bandwidth, and administrative privileges configured at your SMS site. For each secondary site in your hierarchy, plan to use one of these methods:

• Use the SMS 2003 product CD.

• Connect to an image of the SMS 2003 CD on a mapped network drive, hard disk, or a removable disk of the secondary site.

• Use the SMS Administrator console at the primary site.

You can install the secondary site from the primary site server by having SMS transfer all required files from the primary site to the secondary site server during the installation process. Alternatively, you can reduce network traffic during the installation by inserting the SMS 2003 CD on the secondary site server and having SMS install the files from the CD.

SMS Site Database Server Considerations

Using the guidelines here, create and document a plan for deploying your site systems.

While you are designing your SMS hierarchy, you decide whether to implement your SMS site database on your SMS site server, or on another computer. Either way, SQL Server must be installed before you run SMS Setup. If you are using an older version of SQL Server and plan to upgrade to SMS 2003, see Appendix H: "Appendix H - Upgrading to SMS 2003."

Typically, performance is better if the SMS site server and the SMS site database are installed on the same computer. If your organization requires you to install SQL Server on a remote computer, analyze the intervening network connection to ensure that a high-availability, high-bandwidth network connection is in place. In this scenario, you might consider installing a second network adapter in both the site server and the computer running SQL Server and then dedicating this second card for communications between the site server and the computer running SQL Server. For more information, see Appendix F: "Appendix F - Capacity Planning for SMS Component Servers."

Important

When you create the SMS site database, ensure that you use the default SQL Server 2000 Sort Order option with the Collation Designator. SMS supports both case-sensitive and case-insensitive sort orders. In case sensitive mode, only dictionary order is supported with case sensitive sort order. Also, in case sensitive mode, performance is significantly slower. In all cases, the collation, and therefore the sort order, of the SMS site database must match the collation of the SQL Server on which it resides. For more information about specifying SQL Server 2000 collations when you create a database, see your SQL Server documentation.

Preparing the SQL Server Computer

Although multiple SMS sites can share a SQL Server database for storing data, it is recommended that you do not share SQL Server databases among SMS sites. One consideration for your SMS 2003 implementation is which version of SQL Server to use for your SMS site database. Check the requirements in the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide before you make this decision. As with all other site systems, ensure that the computer running SQL Server has sufficient memory, CPU capacity, and disk I/O capacity to manage the SMS and SQL Server processes. SMS 2003 does not support SQL Server in a clustered environment.

Planning for SQL Server Database Replication

If your plans include implementing SQL Server database replication to improve performance on the SMS site database server, ensure that you plan to deploy a server that is running SQL Server to host the replicated tables. Plan to install SQL Server on this server. Configure your server locator point or management points or both to connect to the replicated SQL Server computer instead of the SMS site database server. SQL Server provides a tool for configuring replication. See the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide to find out which version of SQL Server is required for replication support in SMS. See your SQL Server documentation for SQL Server version considerations when you replicate SQL Server databases.

*SPWhen you upgrade from SMS 2003 to SMS 2003 SP1, you need to reconfigure SQL Server database replication because 15 new tables and stored procedures have been added to the replication database. *SP

For information about configuring SQL Server database replication, see Appendix G: "Appendix G - Deploying and Configuring SMS Sites," and your SQL Server documentation.

SMS Administrator Console and Related Tools

Plan how you will implement the SMS Administrator console to administer your SMS sites and how you will implement the Recovery Expert to back up and recover your SMS sites.

SMS Administrator Console

SMS Setup automatically installs the SMS Administrator console when you are installing a primary site. You can also install the SMS Administrator console on any computer in your site that is running a Windows operating system. This operating system must be on the list of supported operating systems in the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

Consider who will be using the SMS Administrator console and what level of access to give to each SMS user. Anyone with permissions for SMS Administrator console items for a site can use the console to connect to an SMS site database and administer those items.

Backup and Recovery

Planning for backup and recovery is a crucial part of planning your SMS deployment. Do not wait until you have deployed SMS to implement your backup and recovery plan. At this stage in planning, it is important that the appropriate members of your SMS team are educated in the SMS backup task, the Recovery Expert tool, and other recovery tools that are included in SMS 2003.

Be sure to plan for a Recovery Expert Web site, document your backup and recovery plan, and keep the plan in a secure location. The documentation and backup data must be available to the appropriate personnel if the system fails. For more information, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.

Setup Options

To run SMS Setup, you must have administrative credentials on the computer. Before you run Setup, plan for making the following choices during setup:

• Express vs. Custom setup

• Advanced vs. Standard security mode

• Extending the Active Directory schema for SMS

Important

Before you install SMS, ensure that the time settings on computers in your organization are synchronized, and then perform network time synchronization routinely. A number of problems can arise in your SMS hierarchy if time is not synchronized, such as a backlog of status messages and software metering summarizations that are not valid, to name just two issues.

Express vs. Custom Setup

Carefully choose one of the two options for installing a primary site: Express Setup or Custom Setup. Many SMS 2003 features are enabled by default if you use Express Setup, but they are disabled by default if you use Custom Setup.

Always use Custom Setup to deploy SMS in your production environment. Express Setup is only appropriate for setting up evaluation sites on an isolated network. Custom Setup allows you to control which features Setup installs, and it is required for Advanced Security.

Table E.2 describes which SMS components are available with each setup option.

Table E.2   Component Data by Setup Option

Option	Custom primary site installation	Express primary site installation	Secondary site installation	SMS Administrator console installation
Site server	Installed	Installed	Installed	Not available
SMS Administrator console	Installed	Installed	Available	Installed
Remote Tools	Optional	Installed	Optional	Not available

By default, the Express Setup option:

• Installs all core SMS components and client agents.

• Enables Legacy Client Push Installation.

• Enables all discovery methods.

• Creates all necessary service accounts.

• Enables the client access point (CAP), management point, and distribution point roles on the site server.

Table E.3 lists default settings that result from the Express Setup option.

Table E.3   Express Setup Default Settings

Feature	Enabled or disabled	Interval
Network Discovery	Disabled	Not applicable
Windows User Group Discovery	Enabled	One day
Windows Networking User Account Discovery	Enabled	One day
Heartbeat Discovery	Enabled	One week
Active Directory System Discovery	Enabled	One day
Active Directory User Discovery	Enabled	One day
Active Directory System Group Discovery	Enabled	One day
*SPActive Directory Security Group Discovery *SP	Enabled	One day
Legacy Client Push Installation	Enabled	Not applicable
Advertised Programs Client Agent	Enabled	One hour
Remote Tools Client Agent	Enabled	Not applicable
Hardware Inventory Client Agent	Enabled	One week
Status summarizers (summarize and replicate)	Enabled	One hour
Collection update	Enabled	One day
Software Metering Client Agent	Disabled	Not applicable
Software Inventory Client Agent	Disabled	Not applicable

Advanced vs. Standard Security Mode

It is important that you plan to choose which security mode, standard or advanced, to implement when you install SMS. The security mode you choose has an effect on the kind and number of accounts that are created and used for SMS security.

Important

If you choose advanced security mode, then you can never change the mode to standard security.

Advanced security mode has some prerequisites that you should plan for. For example, advanced security mode requires that Active Directory be enabled. These prerequisites are described in Scenarios and Procedures for Microsoft Systems Management Server 2003: Security.

The supported parent-child configurations for advanced security mode are:

• SMS 2003 advanced security site reporting to SMS 2003 advanced security site.

• SMS 2003 standard security site reporting to SMS 2003 advanced security site.

• SMS 2.0 site reporting to SMS 2003 advanced security site.

If you choose the standard security mode during setup, you can switch to advanced security mode after installation.

Extending the Active Directory Schema for SMS

You extend the Active Directory schema to publish SMS objects in Active Directory. If you do not extend the schema, SMS cannot publish objects, and the following features are not available for Advanced Clients in SMS:

• Global roaming

• Automatic site assignment where the server locator point is not specified

Although SMS 2003 Setup prompts you to extend the schema, you can extend schema before, during, or after you run Setup. It is recommended that you extend the schema before you run Setup so that you can verify that schema extension was successful, and if not successful, troubleshoot the problem before you run Setup.

Note

If you do not extend the Active Directory schema for SMS, your server locator point and management points are not published to Active Directory, and you must manually register the server locator point (and any management points that are operating in a Network Load Balancing cluster) in WINS.

If you choose to extend the Active Directory schema during setup, be aware that you perform this task only once per Active Directory forest, and the logged-on user who is running SMS Setup must have administrative credentials. For information about using ExtADSch.exe to extend the SMS schema before or after running SMS Setup, see Appendix G: "Appendix G - Deploying and Configuring SMS Sites" and the white paper “Active Directory Schema Modification and Publishing.”

Important

Before enabling any Active Directory Schema changes in a Windows 2000 domain, the option to allow the schema to be extended has to be enabled. This does not apply to the Windows Server 2003 domains. For more information about the Active Directory schema, see the Microsoft Windows 2000 Distributed Systems Guide in the Microsoft Windows 2000 Server Resource Kit. Also see Microsoft Knowledge Base article 216060 at .

Domain and Security Requirements

Every SMS 2003 and sms 2003 SP1 site server and site system computer must belong to a Windows domain. Also, computers must belong to a domain to become SMS 2003 clients. SMS 2003 does not officially support operations in a workgroup environment. *SP SMS 2003 SP1 provides limited support for SMS clients on computers in a workgroup, with the following conditions and exceptions:

• Workgroup support is for Advanced Clients only.

• Clients must use NetBIOS for name resolution.

• Installing the SMS client software requires administrative rights on the computer.

• Active Directory discovery and user targeting is not supported.

• Global roaming is not supported. *SP

Planning your SMS deployment includes a number of security considerations. Your SMS security strategy affects all of the following:

• Operating system configuration

• Support for software that works with SMS, such as IIS, SQL Server and Windows Management Instrumentation (WMI)

• Logical and physical placement of site systems

• Creation of user and computer accounts

• Communications to appropriate departments in the organization

• Policies and procedures for use of SMS

For more information, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Security.

NetBIOS Requirements for Browsing and WINS

All SMS servers and clients must have NetBIOS enabled. However, you may be able to disable the Windows Computer Network Browser service (“browsing”) and use DNS with Active Directory instead of WINS if certain conditions apply. This section lists those conditions.

The Windows Computer Network Browser service (“browsing”) is required if any one of the following is true:

• SMS is running in standard security mode.

• Some SMS clients are running the Legacy Client.

SMS 2003 requires WINS if any one of the following is true:

• SMS is running in standard security mode.

• Some SMS clients are running the Legacy Client.

• The Active Directory schema has not been extended for SMS.

• Your SMS hierarchy is distributed across different Active Directory forests or includes workgroup clients.

Also, if any SMS sites in your hierarchy span more than one Active Directory domain, you must configure the DNS-suffix search order of client systems to include the DNS suffixes of all domains with SMS clients or servers. This can be configured with group policy in Windows Server 2003. For information, see your Windows documentation.

WINS is used to register SMS management points and SMS server locator points in addition to name resolution. Configure your SMS servers and clients to use WINS so SMS site servers can register their services and clients can locate them. Management points that are not in Network Load Balancing (NLB) cluster will be automatically registered in WINS. However, you must you must manually register the following types of site systems in WINS:

• Server locator point

• Management points in a Network Load Balancing cluster

You can disable browsing and not use WINS if all of the following are true:

• Active Directory is implemented in your environment.

• The Active Directory schema is extended for SMS and all SMS sites are publishing identity data to Active Directory.

• All SMS servers and clients are in the same Active Directory forest.

• SMS is running in Advanced Security mode.

• All SMS clients are running the Advanced Client.

• You have no SMS 2.0 child sites.

For more information, see the section “Manually Add SMS Site System Roles in Windows Internet Name Service” in Appendix G later in this guide.

Site Naming

As described earlier in this appendix, it is a good practice to develop a logical site-code and naming-convention strategy. With consistent naming conventions, administrators can use the site codes to locate the parent-child relationships within the hierarchy. This is also useful for support and recovery issues.

Remember the following:

• SMS site codes cannot be changed after they are created.

• It is important to be consistent with your IT organization’s existing naming conventions.

• Do not use the same site code name for more than one site in your enterprise.

• Avoid the use of extended characters in site code names.

• If you are using Active Directory, your Active Directory site names must use only valid characters, as described in Active Directory documentation.

• Do not use MS-DOS directory names that are not valid, such as AUX, PRN, NUL, or CON, for your SMS site codes.

• Symbols are not accepted in the database name during setup.

Designing SMS Sites and the SMS Hierarchy

Understanding the benefits and required resources that are associated with each SMS feature, and the effects of those features on your SMS hierarchy, can be complex. The design process requires reviewing the technical and business considerations that can affect the design. Many of these considerations are listed in this appendix, although you might include additional considerations that apply to your organization in particular. Plan how to address these considerations using design specifics, and prioritize the considerations as you examine them.

Using this information, determine the locations of your SMS sites. If you have more than one site in your SMS hierarchy, determine which sites use similar designs and which ones require different designs.

Determine where these site types will be located in relation to one another, and map out your hierarchy. When designing your hierarchy, review and test it in the test lab. Making modifications to your hierarchy design during this phase is easier and entails less risk than if you make changes after deployment.

When designing the SMS hierarchy, consider the physical layout of your network and the administrative requirements of your organization. The SMS hierarchy you design should reflect both the layout of your network and the administrative requirements of your organization.

Business Considerations

At this stage of the planning process, ensure that you have completed the following tasks and have included this information in your project plan documentation:

• Collected the computing environment data listed in the Preplanning section of this document.

• Determined your objectives

• Developed a clear understanding of the SMS 2003 features to implement

• Identified the numbers and types of resources located throughout your organization

With this information, you can address the business and technical considerations that affect your hierarchy design. When designing your hierarchy, examine these considerations, determine whether they are applicable to your environment, and prioritize their relevance.

Major business considerations that can affect your hierarchy design are listed in this section. As you examine these considerations, determine their applicability and their relative priority in your design.

Geographic Profile

Be aware of multiple languages and time zones that exist across your enterprise. These can affect the placement of your site servers and the language version of the software you deploy. If your organization has locations in more than one country or region, then your SMS hierarchy will probably span those geographic areas. For more information, see the “Multilanguage Site Hierarchies” section later in this appendix.

Operations scheduled at night in one SMS site might conflict with operations of a child or parent site in another time zone. By coordinating SMS scheduled activities among time zones, you can reduce the possibility of scheduling conflicts. Be aware of international policies and procedures that affect your hierarchy design.

Organizational Structure

Your organizational structure can affect hierarchy design. You might have reason to define site boundaries based on organizational division. For example, you might logically group resources based on organizational units, billing departments, or scope of control.

Also, consider who will access the data that SMS generates and which SMS sites should display discovery and inventory data. Because this data flows up the hierarchy, consider business needs for data being gathered at particular levels or sites in the hierarchy.

Note

Some SMS data flows down the SMS hierarchy and some flows up. For more information, see Chapter 2: “Understanding SMS Sites” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

Information Technology Organization and Organizational Policy

Whether computer management in your organization is centralized or decentralized helps you determine how many secondary sites and tiers to include in your SMS hierarchy. Depending on the scope of control, each IT management location is likely to require a primary site. Locations that do not have local IT administration are good candidates for hosting secondary sites.

Consider the help desk model of your organization. If you use a central help desk for your entire organization, and you want your help desk personnel to use the central site server to access resource information for the entire organization, you might design a deep hierarchy. Or, if you have multiple help desks, each of which is responsible for different departments within your organization, you might distribute the workload for help desk personnel across multiple primary sites in a flat hierarchy. This design gives you more sites that can perform help desk operations. SMS clients report to sites that service their particular department, provided that the departments do not span slow or unreliable network links.

Other IT policies can also affect site design. For example, consider what your expected system response times are, as specified in service level agreements in your organization. Every tier in the hierarchy increases the time it takes for configuration changes to be sent up and down the hierarchy. For example, the greater the depth of your hierarchy, the longer it takes for status to flow up and for advertisements to flow down. Remember this when you analyze bandwidth capacity and expected response times.

Consider who will control the SMS deployment. Hierarchy design and deployment must be carefully controlled because rogue SMS sites and hierarchies can seriously disrupt operations of your production SMS deployment. If organizations do not allow servers to be installed in locations that do not have an onsite administrator, then you cannot install SMS sites at these locations.

Data Flow

Your hierarchy design directly affects how SMS data flows, such as how sites report data to one another. Most data flow can be controlled between sites but not within sites. This affects how you design the parent-child relationships in your hierarchy. The type of site servers deployed in an SMS site depend on network topology and remote management needs. Large numbers of advertised programs, or frequent hardware and software inventory intervals, can increase the network traffic between the sites in your hierarchy. This traffic affects the network links that connect the sites in your hierarchy. If you carefully schedule SMS activities and spread the load by implementing multiple sites, you might be able to distribute the load more evenly on your network.

Resources Available for Implementing SMS

Personnel and budget limitations can affect your SMS hierarchy design. Your organization must have the workforce resources necessary in the appropriate locations to deploy, support, and maintain the SMS hierarchy that you design. For example, secondary sites are appropriate in locations that lack IT resources. Budget constraints can impose limits on your hierarchy and site design. Determine how many new servers you can afford, which existing servers can support or be upgraded to support SMS services, and whether to combine site system roles on servers that have more processing power.

Consider your hardware budget. Each tier in a hierarchy processes all the objects of the sites below it. As you continue to add clients at lower tiers in the hierarchy, each set of site servers requires progressively more processing power than those in the tier below it.

Note

To manage the level of processing power needed at each tier of the hierarchy, you can control which data is propagated to higher tiers. Part of hierarchy design is determining which data to propagate to the central site and which data to filter out.

Legal Policies

Legal relationships among the suborganizations that the hierarchy spans can affect hierarchy design. For example, you might be required to create isolated SMS sites for your organization’s finance department or for a partially owned subsidiary. Your organization’s policy might mandate that its information be contained in separate databases. It is difficult to completely isolate suborganizations within a single hierarchy. To ensure legal compliance, plan your security requirements simultaneously while designing your SMS hierarchy. For more information, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Security.

Technical Considerations

Technical considerations have an extensive effect on your hierarchy design. The most important considerations are listed here. As you examine the considerations, determine their where they are relevant to your situation and, if so, their relative priority in your design planning.

Previous Installations and Interoperability

Your organization’s history of systems management can affect how you design your SMS hierarchy today. You might already have computers grouped into sites that you choose to use as SMS 2003 sites. Also, if you are running any platforms that are not supported by SMS 2003, such as Novell NetWare, Windows 95, Windows Millennium Edition, or the Alpha processor, consider whether to upgrade these platforms now or to exclude them from your SMS 2003 deployment.

If you have an existing SMS 2.0 infrastructure in place, it affects your hierarchy design. If, for interoperability reasons, you must maintain an SMS 2.0 site in your SMS 2003 hierarchy indefinitely, then design a hierarchy that accommodates that site. For more information about interoperability issues, see Chapter 6: “Understanding Interoperability with SMS 2.0” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

Capacity and Performance

The SMS sites and hierarchy you design need to be able to scale up as your organization grows. For example, if your organization plans to add more remote offices to its infrastructure, you might need to deploy more SMS sites later. Or, your organization might anticipate adding more clients to already existing SMS sites. This knowledge encourages you to consider future capacity needs when planning for server capacity and performance. Growth expectations affect how deep or flat your planned hierarchy is and how many sites you implement in your SMS hierarchy. For more information about capacity planning, see Appendix F: "Appendix F - Capacity Planning for SMS Component Servers."

Network Topology

Your network infrastructure, and its associated constraints, influence hierarchy design. The SMS site boundaries you define, and which clients are included in each site, are affected by all of the following:

• Connection speed and reliability

• Available bandwidth

• Line quality

• Latency

• Peak usage patterns

SMS requires a fast, reliable network link for all processes that interact between SMS site systems, the SMS site database server, and SMS site servers. The recommended design is to have an SMS site at the end of a WAN link that contains clients you want to manage. This can be a secondary site, which requires fewer resources than a primary site and can be remotely administered. It is better to have a secondary site server share the workload with an existing server than to have site systems connect over slow network links.

Client Environment

Consider the number of computer resources that must be discovered and supported as SMS clients, both now and as your organization grows. In general, the site’s performance is better if it has fewer resources to manage. Also, managing laptops with SMS affects the placement of management points and how to define roaming boundaries.

Active Directory Site Structure

Active Directory implementation directly affects how you define SMS site boundaries, because you can use Active Directory site names as SMS site boundaries. SMS collections that are used to distribute software and perform other SMS functions can be categorized by Active Directory group, container, or organizational unit. Also, SMS has limitations across Active Directory forests. Be aware of these considerations as you design your SMS sites and hierarchy. For more information, see the “Active Directory Considerations” section later in this appendix.

Server Environment

You might choose to assign SMS site system roles to existing servers in your infrastructure. Backup and recovery strategies for production servers might also affect server locations and the number of servers. For more information about your server needs in a recovery scenario, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.

Important

If you have any existing servers running the Windows Cluster Service, be sure to investigate SMS 2003 interoperability with Windows Clustering in the downloadable white paper at https://www.microsoft.com/smserver.

Remote Access Servers

SMS 2003 includes support for client computers connected to slow and unreliable links, such as a dial-up connection to a remote access server. It is recommended that you assign these clients to an SMS site that is well-connected to the remote access server serving the client connections.

Domain Models and Security

Security policies, including Windows security, folder structure, and account policies, can affect site design. It is critical that you address these security issues when designing your sites and planning your SMS deployment. For more information, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Security.

After carefully reviewing all business and technical considerations that affect your SMS implementation, rank them in order of priority. When making design decisions, these prioritized considerations help you meet the requirements you identified in the preplanning phase.

SMS Site and Hierarchy Design

Determine what types of SMS sites fulfill your needs at each location in your enterprise. Begin by planning your SMS site boundaries.

Important

Now is the time to begin managing risks. When you proceed with your design, make a list of potential risks to test and review in your test lab. It is equally important to think through the implications of your choices when making design decisions. If you are not sure of potential design implications, put those on your list too. You can address these issues when you review your design. For more information about risk management, Appendix A: “Appendix A - Understanding Methodology and Risk.”

When developing your SMS site design, depending on your WAN configuration, you will probably notice that you have many similar sites. For example, you might have:

• Several primary sites that have approximately 10 child sites.

• Several secondary sites that have approximately 25 clients.

• Several sites that have a large number of help desk personnel for support.

Look for similarities like these and determine a standard configuration for each type of site you plan to deploy.

Planning Site Boundaries and Roaming Boundaries

Because the boundaries of an SMS site are defined by IP subnet or Active Directory site name, most SMS sites are mapped to your physical network topology.

Planning site boundaries involves deciding which resources and subnets to include in each site. Each SMS client is assigned to a single SMS site. Legacy Clients must exist within the site boundaries as defined. If this condition is not met, the Legacy Client software might be removed from client computers. Advanced Clients, however, are explicitly assigned to a site according to the site code. This assignment is independent of site boundaries. Multisite client assignments are not supported in SMS 2003.

One method of gathering information about resources in your organization is to initiate discovery in SMS without initiating client installation. For more information, see the “Initiating Discovery Without Initiating Client Installation” section in Appendix C: "Appendix C - Client Deployment Planning."

Note

Classless interdomain routing (CIDR) uses a single IP address to designate many unique IP addresses. CIDR is also called supernetting. Supernetted IP subnets are not supported as SMS 2003 site boundaries. To take advantage of any subnet grouping technologies in SMS, such as supernetting, you must use Active Directory site names for your site boundaries instead of IP subnets. For more information about supernetting, see the Windows 2000 Resource Kit.

The subnets included in your site boundaries should be connected with reliable links so that all resources in the site have a fast connection to all other site resources. As a rule, if two subnets are separated by a slow link, do not include them both in the same site. Instead, create a separate SMS site at each physical location. If the physical location contains many users, contains users with very different needs, or has more than one group manages the computers, you might split a single physical location into more than one SMS site.

Computers must be members of a domain to be included in SMS site boundaries. Workgroup computers are not supported in SMS.

Because site boundaries generally reflect the layout of your enterprise, use the network diagram you created in the preplanning phase when considering where to set your site boundaries. Your diagram identifies the number and types of users on each local area network (LAN) and WAN. Evaluate how to build the existing subnets into the separate sites based on link speed. Also, consider the location of the domains in your site, because you can enable resource discovery by domain, which is a reliable way to find all computers while using little overhead.

If a client is located within the site boundaries or roaming boundaries of its assigned site, it accesses available software package files locally. Otherwise, the client accesses the content as if it were remotely connected (that is, using the download and run method of software installation instead of run from network method). For more information, view the animation Roaming in SMS 2003 or read the white paper Configuration and Operation of Advanced Client Roaming, both available from the SMS 2003 Product Documentation Web site https://www.microsoft.com/smserver/techinfo/productdoc.

Site-wide Settings

When you plan your site boundaries, consider the fact that the site settings you configure for client agents, components, discovery methods, installation methods, and other features apply to all of the clients you assign to that site.

Note

In some cases, you might want some clients within a site to have configurations that are different from other clients in the site. For example, you might want the Remote Tools Agent to require user permission on desktop computers only and not on your servers. With an Active Directory Group Policy or registry modification, the user permission setting can be overridden for the servers in your site. For more information, see the “Clients with Special Configurations” section in Chapter 4: “Understanding SMS Clients” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide. Also, view the animation Roaming in SMS 2003 or read the Roaming Boundaries white paper, both available at the SMS 2003 Product Documentation Web site https://www.microsoft.com/smserver/techinfo/productdoc.

Roaming Boundaries for Advanced Clients

Roaming boundary planning is an important component of site design because the roaming boundaries you specify designate how software is distributed to Advanced Clients.

SMS site boundaries determine which resources the SMS site manages. Roaming boundaries enable SMS software distribution to Advanced Clients. For this reason, plan to define roaming boundaries in SMS sites where Advanced Clients need to access advertised programs. Roaming boundaries are also used in the site assignment of Advanced Clients and to configure protected distribution points.

If a client roams to a location that has no roaming boundaries defined, that client reverts to its assigned site’s management point and distribution point. In this scenario, the client treats the distribution point as a remote distribution point.

Avoid creating overlapping roaming boundaries. If an Advanced Client is within the roaming boundaries of more than one site, the client might not communicate with the correct site.

Important

In an Active Directory environment, each SMS site server publishes its list of roaming boundaries in Active Directory. To obtain the full benefits of Advanced Client roaming, you must have Active Directory deployed — and the Active Directory schema extended for SMS — in your site. This allows your Advanced Clients to perform global roaming. In the absence of Active Directory, your SMS clients are limited to regional roaming. For more information about roaming, see Chapter 2: “Understanding SMS Sites,” and Chapter 4: “Understanding SMS Clients” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide. Also, view the animation Roaming in SMS 2003 or read the Roaming Boundaries white paper, both available at the SMS 2003 Product Documentation Web site https://www.microsoft.com/smserver/techinfo/productdoc.

When you plan your site and hierarchy design, it is important to understand how roaming boundaries differ from site boundaries:

• Site boundaries are composed of IP subnets and/or Active Directory site names and define which resources the site manages.

• Roaming boundaries are used by Advanced Clients to access distribution points that can provide them with advertised software packages.

• Roaming boundaries are similar to SMS site boundaries because they can be defined by IP subnets and Active Directory sites. However, you can also use IP address ranges to define roaming boundaries. This is beneficial to SMS clients that connect to the network by way of remote access or a virtual private network.

• By default, site boundaries are included in the site’s roaming boundaries.

For more information about site boundaries and roaming boundaries, see Chapter 2: “Understanding SMS Sites” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide, and view the animation Roaming in SMS 2003 or read the Roaming Boundaries white paper, both available at the SMS 2003 Product Documentation Web site https://www.microsoft.com/smserver/techinfo/productdoc.

Note

When determining your site boundaries, consider the location of your client access points (CAPs), distribution points, management points, and server locator point relative to the clients that will use them. Be sure that stationary clients can access these site systems using fast, reliable links. For information about creating CAPs, distribution points, management points, and server locator points as site systems, see “Assigning Site System Roles” section later in this appendix.

Client Management Needs

When designing your SMS hierarchy, remember client management needs, because you will use SMS to service and manage client computers. SMS clients interact with the following SMS servers:

• Client access points

• Management points

• Distribution points

• Server locator points

You must establish management points for site communications with Advanced Clients and CAPs for site communications with Legacy Clients. You can also include a server locator point in your hierarchy design to help clients find CAPs. Consider using a server locator point for determining assigned site codes for Advanced Clients if Active Directory is not enabled. Install the server locator point only in a primary site. Plan to make distribution points available to your sites for storing software packages to be distributed to clients.

It is recommended that you do not deploy clients to locations that do not have locally available site servers, CAPs (for Legacy Clients only), and distribution points. SMS requires a fast, reliable link for all processes that interact between CAPs, distribution points, and site servers. Customers who must deploy a small number of SMS clients in a site without a local site server must understand the performance risks involved.

Number of clients assigned to an SMS site

There are several different factors that affect the maximum number of clients that can be managed by a site. These include SMS site server hardware specifications, site server load signatures, and the number and types of SMS features enabled. Scheduled intervals for SMS tasks to be performed on clients (such as inventory and software distribution and the amount of inventory that you configure SMS to collect) are also factors.

For information about determining the number of clients you can assign to one SMS site, see Appendix F: "Appendix F - Capacity Planning for SMS Component Servers."

Client types

The type of client you install in each site affects the location of your CAPs and management points.

Advanced Client

The Advanced Client is the preferred SMS 2003 client. It is designed for computers running Windows 2000 and later. Deploy the Advanced Client where possible. Some considerations for the Advanced Client when designing your sites are as follows:

• If you have Advanced Clients reporting to a site, you must make a management point available to those clients.

• Advanced Clients are assigned to primary sites, not to secondary sites.

• An Advanced Client is assigned to only one site.

• For regional roaming, the Advanced Client benefits from the use of local distribution points, even if the client is not assigned to the local site. However, in the case of global roaming, the client can use only local distribution points, which requires Active Directory. Be aware of limitations across forests and other considerations, which are described later in this appendix.

• In particular, the Background Intelligent Transfer Service (BITS)-enabled transfer of packages, transfer of inventory, and updates of clients mean that software distribution and client upgrades do not have an adverse effect on the clients at remote locations.

• With BITS enabled, the Advanced Client is able to send and receive files in any situation in which an HTTP link can be established. This includes using a virtual private network. Also, BITS can handle priority requests. For example, if BITS has started transferring a large Microsoft Office XP package, but SMS generates a delta inventory, the inventory momentarily interrupts the package download so that it can be uploaded.

• The use of the Advanced Client through a proxy server that performs network address translation is not supported.

• If Active Directory is not available, or if you do not plan to extend the Active Directory schema for SMS, establish a server locator point at a primary site in your hierarchy. This enables your Advanced Clients to use automatic site assignment.

Figure E.5 shows two Advanced Client laptops traveling away from their assigned site servers in Chicago and New York to Milan. Note that these laptops still communicate with the management points at their assigned sites, but they receive software distributions from the local SMS site.

Figure E.5   Legacy Client and Advanced Client management with management points and client access points

Legacy Client

The Legacy Client is designed for computers that are required to run Windows NT 4.0 or Windows 98. Some site design considerations are as follows:

• Because Legacy Clients are managed by CAPs, you must plan to install a CAP in each site that has Legacy Clients.

• You can install a server locator point at a primary site in the hierarchy to help your Legacy Clients locate CAPs.

Important

If you have installed the Legacy Client on a computer running the Microsoft Window® 98 or Microsoft Windows NT® 4.0 operating system, and you upgrade those computers to the Microsoft Windows 2000 or later operating system, the Legacy Client agent is removed from the client as part of the upgrade process. It is recommended that you install the Advanced Client on that computer after you upgrade the operating system to Windows 2000 or later.

Common client activity cycles

Most client activity depends on the SMS components you enable and the intervals of time you set for running those components. As a result, the impact of client activity generated by SMS can vary greatly.

When designing your sites, take into consideration the following feature-related client activity cycles:

• Heartbeat Discovery

• Hardware and software inventory

• Polling for new advertisements (software distribution)

• Running an advertisement (software distribution)

• Status reporting, configuration verification, and client software updating

For an overview of SMS client activity cycles and how your clients are affected by the values you set, see Chapter 4: “Understanding SMS Clients” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

Active Directory Considerations

Because Active Directory sites are based on physical network segments, the recommended method of defining your SMS site boundaries is to base them on your Active Directory sites. This allows SMS administrators to split or combine IP boundaries based on logical, not physical, criteria. One advantage to using Active Directory sites as SMS sites is that subnet changes or additions made within an Active Directory site do not require additional configuration in SMS 2003. Subnet changes are automatically reflected within your Active Directory site boundaries for SMS. Remember that Active Directory discovery methods can only be used to discover clients whose site boundaries are defined by Active Directory site names.

Be aware that a single SMS site cannot span multiple Active Directory forests, although it can span multiple domains within a single forest. All SMS site systems must be in the same Active Directory forest as the SMS site server. For general information about multiple forest considerations, download the white paper Windows 2000/2003: Multiple Forests Considerations. Be aware of limitations across forests and considerations in the following areas when you design your SMS hierarchy:

• Communications within an SMS site

• Site-to-site communications

• Client communications

• Secure key exchange

Communications within an SMS site

Communication between an SMS site server and its site systems is not supported across forests. This includes communications between the SMS site server to the SMS site database server. Plan your hierarchy design so that all SMS site servers, including the SMS site database server, and all site systems and SMS clients are within the same forest.

Site-to-site communications

Site-to-site communications have limitations across forests. A child primary site in one forest can attach to a parent in a different forest. A child secondary site cannot attach to a parent in a different forest. Data is sent up the hierarchy from a child primary site to its parent site. For site-to-site communications to work, the SMS addresses at the sending site must have access to the receiving site and vice-versa. If one or more of the forests is running in Windows 2000 Active Directory mixed mode or if Windows Server 2003 Active Directory is using the interim domain functional level, you must specify user accounts as addresses for site-to-site communications to work.

Windows Server 2003 and site communications

Communications across forests work in SMS if the following conditions are met:

• You are using the Windows Server 2003 family

• The forest functional level is set to Windows Server 2003

• SMS is running in advanced security mode

• The forests are configured with a transitive trust

The forest functional level can be set to Windows Server 2003 only if all of your domain controllers are running an operating system in the Windows Server 2003 family. If the forest functional level is set to Windows Server 2003, then creating additional accounts is not required for SMS site-to-site communications to work. For more information about forest functional levels, see the Windows Server 2003 family documentation.

Client roaming across Active Directory forests

Without Active Directory, client roaming is limited to regional roaming (roaming to lower level sites in the SMS hierarchy). With Active Directory, Advanced Clients can perform global roaming within the forest of their assigned site (roaming to higher level sites or sibling sites across the hierarchy).

If the SMS hierarchy is distributed among multiple Active Directory forests, the Advanced Client cannot roam outside the forest that contains the client’s assigned site unless WINS is enabled. In this scenario, WINS is required for the client to locate the resident management point. If WINS is enabled, roaming Advanced Clients are able to communicate with resident management points to receive distribution point location information. For information about roaming, see Chapter 2: “Understanding SMS Sites” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide. Also, view the animation Roaming in SMS 2003 or read the Roaming Boundaries white paper, both available at the SMS 2003 Product Documentation Web site https://www.microsoft.com/smserver/techinfo/productdoc.

Secure key exchange

Another limitation across forests is that there is no secure key exchange by way of Active Directory across forests. For more information about domain trusts, forest trusts, and key exchange, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Security.

Windows NT Domain Requirements

If you plan to have SMS 2003 sites in Windows NT 4.0 domains in your environment, be sure that all of the SMS components are contained within a Windows NT domain and WINS is enabled for the domain. Although an SMS site cannot be distributed among multiple Windows NT domains, the SMS hierarchy can. The support for SMS in Windows NT domains is similar to that of Active Directory forests. Global roaming, however, is not supported across Windows NT domains. Regional roaming requires WINS.

Naming SMS Sites

It is a good practice to develop a logical site code and naming convention strategy. With consistent naming conventions, administrators can use the site codes to locate the parent-child relationships within the hierarchy. This is also useful for support and recovery issues. Do not use the same SMS site code in more than one location in your enterprise.

Important

SMS site codes cannot be changed after they are created. Be sure to carefully plan your site codes and site names before deploying the SMS hierarchy. It is important to follow your organization’s naming convention policy when designing your SMS hierarchy. You should avoid using extended characters in site code names.

If you are using Active Directory, your Active Directory site names must use only valid characters. The Active Directory naming convention requires that Active Directory site names are legal Domain Name System (DNS) names. Otherwise, SMS will not recognize those Active Directory sites. Only use the standard characters A–Z, a–z, 0–9, and the hyphen (-) in site names. For more information about creating Active Directory sites, see the Windows 2000 Server Deployment Planning Guide.

Important

Do not use MS-DOS directory names that are not valid for your SMS site codes, such as AUX, PRN, NUL, or CON. Although you might not encounter problems during the SMS site installation, you can experience problems later if the SMS site code is used as a folder name.

Determining the Locations and Types of Site Servers

Part of the design process is planning your central site, primary sites, and secondary sites, if necessary. To do this, you must understand parent-child relationships, how many clients each site will have, and how the sites communicate with one another. By determining the locations of your primary and secondary sites, you are effectively designing the hierarchy itself.

When you design your sites, consider how you will link them in a hierarchy, based on how each SMS site fits into your project scope and objectives. Carefully balancing usage patterns against available hardware resources is critical to the success of your hierarchy design. It is important that you decide where to install the SMS Provider and SQL Server before installing an SMS site.

Management Scope and Parent-Child Site Relationships

Sites near the top of the hierarchy store information about sites lower in the hierarchy. With proper permissions, administrators at the top sites can manage all computers at their sites and at all sites beneath them in the hierarchy. Make sure that administrators at each level have a legitimate need to manage the sites beneath them in the hierarchy. If possible, when you design the site infrastructure, have each site report to the parent primary site that has the greatest need to directly administer the site. This is especially important for secondary sites, which rely completely on their parent sites for management. This approach might not always be practical, but it is an important design goal.

Primary and Secondary Site Decisions

Plan your primary site locations and determine whether you need secondary sites in your hierarchy. Remember that secondary sites report up to primary sites and do not have SQL Server installed locally. Also, an SMS site running in advanced security mode cannot report to an SMS site running in standard security mode. SMS administrators, using the SMS Administrator console, administer secondary sites remotely. Secondary sites can be placed on both the LAN and in remote locations, such as remote offices that do not have IT staff.

All site systems within an SMS site need to be well-connected. The recommended design is to always have an SMS site at the end of a WAN link because, for site-to-site communications, SMS provides bandwidth scheduling, throttling, and data compression. This site can be a secondary site, which requires fewer resources than a primary site.

Determining the number of child sites per parent

When you are planning how to group child sites in the SMS hierarchy, do the following:

• Optimize your management plan by effectively grouping child sites.

• Take into account how communication between sites affects design.

• Review your plan for performance weaknesses and excessive costs.

Optimizing your management plan

One common method that is used to group sites is by company division. Leaders in each division might want to manage their own software distribution because they have the clearest understanding of the division’s internal needs. This can also reduce the load levels on the site systems. For example, the manufacturing division wants to distribute quality control software to its client computers, and the sales division wants to distribute sales support tools to its client computers. You can set up one SMS site that includes the manufacturing division, and another site that contains the sales division. This prevents a large, unnecessary load that can occur when the central site distributes all the organization’s software to all the sites and clients in the hierarchy. If the sales division reports to a different site than the manufacturing division, then the software distribution load will be balanced between sites.

Another way to group sites is by region. Grouping sites by region can reduce the cost of the site-to-site links by reducing the distance between sites. Also, many organizations have faster links available within local regions. A regional grouping can also reduce the software distribution load. For example, if a company distributes updates to the inventory database, the sales force for the Southeast region might not require updates for local inventory for the Northwest region. On a large scale, the primary site for South America might not need to distribute the Greek version of Microsoft Office, but the primary site for the Mediterranean region would.

These two strategies are not mutually exclusive, however. You might create sites according to work function within a region, for example.

Site communications

Communications between sites requires SMS senders. When planning your deployment, determine which types of senders you will implement. For more information, see Appendix E: "Appendix E - Designing Your SMS Sites and Hierarchy."

Performance, server sizing, and cost issues

Performance is measured by system resources that are used as data is processed. Performance can be increased by increasing throughput efficiency.

Proper server sizing ensures that your hierarchy design provides a scalable solution — one that can adapt to increased demands without a significant investment in more resources.

When you have a tentative plan for grouping your SMS sites, review the plan for performance, scalable servers, and cost. For example, dozens of primary sites that each have high-end server hardware but support only four small child sites might be very expensive. Consider reducing the number of primary sites and grouping the small child sites with other sites to take advantage of the high-end equipment at the primary site.

For more information about capacity planning and server sizing, see Appendix F: "Appendix F - Capacity Planning for SMS Component Servers."

Server sharing at secondary sites

A secondary site server does not require the same resources as a primary site server because it does not run SQL Server. For this reason, secondary site servers at small, simple sites might be able to share the workload with servers already located close to their clients. If you are considering using this configuration, test the effect of these applications on the secondary site server and the effect that SMS might have on other applications.

Note

Do not install your SMS site servers on computers running the Windows Cluster Service without understanding SMS interoperability with the Cluster Service. For more information, see the white paper at https://www.microsoft.com/smserver.

Central Site

Whether you have clients reporting to your central site depends on the size and complexity of your organization and whether you use the central site server for other purposes. Alternatively, clients can report to child sites beneath the central site. Because all status and client data flows up in the hierarchy to the central site, adding a large number of clients to this site can diminish central site server performance and client performance. If you plan to use your central site server for other purposes, such as SMS reporting, consider not having clients report directly to the central site.

A deciding factor in what roles you assign to the central site server, and whether clients report directly to it, is the robustness and capacity of the hardware on this server. If you do assign roles to the central site, the server should be robust enough to handle both local processing and organization-wide processing.

After you have designed your sites and determined the site reporting structure, you connect your sites to form a single hierarchy that reports up to the central site server. It is recommended that you begin at the bottom tier of your hierarchy, planning the lower level sites that attach to higher level sites. Work your way up the hierarchy, attaching to higher level sites as you go. From this structure you can determine the most logical location of your central site.

Flat vs. Deep Hierarchies

Building a hierarchy is influenced by many internal and external factors. Depending on the business needs and physical layout of your organization, your hierarchy design will ultimately resemble a flat hierarchy or a deep hierarchy.

Note

It is recommended that you design a flatter hierarchy, which makes the hierarchy easier to configure, administer, and support. With fewer tiers in your hierarchy, SMS needs less time to deploy software to lower level sites and report status back to the top of the hierarchy.

Limiting the Impact of Site Failures

When deciding on a hierarchy design that best suits your organization, consider how much you need to limit the effect of possible site failures.

In a deep hierarchy, if a site server with a relatively large number of lower level sites fails, the detrimental effects will be greater because a relatively large number of clients will be disconnected from the parent of the failed site. However, in a flat hierarchy, the sites and the SMS clients are more distributed. If a site server in a flat hierarchy fails, fewer clients are affected.

Figure E.6 shows a deep hierarchy containing 4,500 lower level clients. Figure E.7 contains the same number of clients, but it is a flat hierarchy. If the second-tier site fails in the deep hierarchy, as shown in Figure E.6, 3,400 clients will lose connectivity to the central site. In Figure E.7, which shows one possible second-tier site failure, only 500 clients are disconnected.

Figure E.6   A deep hierarchy, with 3,400 clients disconnected by a site failure

Figure E.7   A flat hierarchy, with only 500 clients disconnected by a site failure

Although there are many model combinations that might fit your organization, be sure to test your hierarchy design during the pilot project. For information about running the pilot project and refining hierarchy design, see Appendix D: "Appendix D - The Pilot Project."

Assigning Site System Roles

You can assign all of the system roles to the primary site server or distribute them among other servers. When planning the placement of site system roles in your hierarchy, remember that some of the roles are assigned during installation and others are assigned through the SMS Administrator console. See Table E.5 for server assignment during installation, Microsoft Internet Information Services (IIS) requirements, and role restrictions.

For site system supported platforms, see the “Getting Started” chapter in this book. Be aware of the changes that you can and cannot make to your sites after deployment. Some site system roles can be moved after installation but others cannot.

Site Servers and Site System Relocation

If your organization’s needs change and expand unexpectedly after you deploy SMS, you might find that your original hierarchy design reduces performance to unacceptable levels. If this occurs, you must revisit your design. You might be able to improve the performance of your site by moving and assigning site system roles to additional computers. Table E.4 describes the site system roles that can be moved from one computer to another. For more information about moving the SMS site server, SMS site database server, or SMS Provider, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.

Table E.4   Moving SMS Site Servers and Site Systems

Site system or role	Can the role be moved?
Site server	No, you cannot move the site server to another computer. However, you can move the site server to another domain, or you can restore the site server to a different computer with the same server name.
SMS site database server (SQL Server)	Yes, you can move the SMS site database from the site server to a remote server running SQL Server, or you can move the SMS site database from one remote server to another remote server. However, after you have moved the SMS site database from the site server, you cannot move it back.
SMS Provider	No
SMS Administrator console	Yes
Client access point	Yes
Distribution point	Yes
Server locator point	Yes
Management point	Yes
Reporting point	Yes

After you have installed a reporting point on a server, you cannot move your IIS installation on that server from one disk to another without reinstalling the reporting point.

For information about locating your site servers, see the “Determining the Locations and Types of Site Servers” section earlier in this appendix.

Site System Roles

Assigning site system roles to servers in your organization is a task you perform for each site after installing its SMS 2003 site server. Include site system placement in your hierarchy design.

Table E.5 summarizes the SMS site systems and roles that are assigned automatically during SMS setup. Note that the site server is automatically assigned during installation and can share roles with site systems.

Table E.5   Server Assignment During Installation, IIS Requirements, and Role Restrictions

Site system, role, or SMS Provider	Assigned during installation	Can share roles with other site systems	Requires IIS	Can exist in a secondary site
SMS site database server (SQL Server)	√	√
SMS Provider	√	√
Client access point	√	√		√
Distribution point	√	√	√	√
Distribution point with BITS enabled	√	√	√	√
Server locator point		√	√
Management point		√	√	√
Reporting point		√	√

Note

If you want to assign a CAP, distribution point, management point, or server locator point role to a server in another domain, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Security.

SMS site database server and the SMS Provider

Before deployment, it is important that you decide where to install the SMS Provider and SQL Server. The SMS site database server must be installed with SQL Server. When initially deploying an SMS 2003 site, you can install SQL Server wherever you want. The SMS Provider can be installed on either the site server or a remote computer running SQL Server that contains the SMS site database. For information about SQL Server version requirements, see the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

However, it is recommended that you install your SMS site database on your site server. If not, SMS competes with other applications on the LAN segment for network bandwidth, and SQL Server has the increased overhead of completing network operations before responding. This might slow the processing of SQL Server. After a site is set up, the SMS Provider cannot be moved to the site server if it is installed on a remote computer running SQL Server. Installing the SMS site database on your site server also simplifies the recovery process. For more information, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.

Be aware of your organization’s policy with regard to database servers. For example, if a separate department controls all the computers running SQL Server in your organization, the policy might mandate that the SMS Provider not be installed on the remote computer running SQL Server. Or, the policy might not allow installation of SMS on your SMS site server. Be sure you have this information during the design phase.

If possible, plan on dedicating your SQL Server database to SMS 2003. In general, it is recommended that you do not share the SMS site database server with other SQL Server applications because doing so can reduce SMS performance. This recommendation mainly applies to organizations hosting a large number of SMS clients and to other SQL Server applications that use excessive amounts of processor time. Check your IT organization’s policy before sharing your SMS site database with other SQL Server applications.

If you install an SMS site and use an SMS site database that belongs to a different SMS site, neither site functions correctly. An SMS site cannot share its SMS site database with another SMS site, regardless of version. However, two sites can use the same computer that is running SQL Server if they have separate SMS site databases, and if the computer running SQL Server is not an SMS site server.

SQL Server database replication

If you anticipate heavy network traffic between your server locator points or management points and the SMS site database server, consider implementing an extra database for the purpose of SQL Server database replication. To improve the performance on the SMS site database server, Advanced Client policy tables of the SMS site database that are used by management points can be replicated to a separate computer running SQL Server. In this case, SQL Server database replication automatically keeps the replicated Advanced Client policy database synchronized with the SMS site database.

SQL Server database replication allows management points and server locator points to query the SMS data they need and service client requests without placing additional load on the SMS site database server. The work is then distributed among one or more computers running SQL Server that are not hosting the SMS site database, which improves performance of SQL Server resources. The replication process is handled entirely by the SQL Server publication and subscription services.

SMS Administrator console

The SMS Administrator console is easy to install from the SMS product CD to any computer running Windows 2000 Professional Service Pack 2 or later. Appropriate permissions must be assigned for a user to run it and administer SMS sites.

Because the SMS Administrator console is a snap-in for Microsoft Management Console (MMC), you can customize your SMS Administrator consoles for varying levels of access by different groups of SMS users, such as your help desk staff. For more information, see Chapter 16, “Using the SMS Administrator Console” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

Client access point

Plan to have at least one CAP in every SMS site. If the SMS site contains only Advanced Clients, you must still maintain one CAP, because without Legacy Clients, the CAP is used by some SMS site server components.

If the SMS site contains a significant number of Legacy Clients, be sure you have enough CAPs to support those clients. Consider assigning the CAP role to one or more site systems, other than the site server, to reduce the load on the site server. When determining the number of CAPs you need, consider the load on the CAP and whether you require fault tolerance across your CAPs.

Your goal is to keep the number of CAPs deployed to a minimum, while still enabling the CAPs to service Legacy Client needs effectively. This ensures that clients do not experience any unacceptable reductions in service, such as not receiving timely advertisements. Because SMS site server processes perform replication serially and must cycle through each CAP, it takes longer for this process to complete if you have many CAPs. This is an important consideration, because all Legacy Client files are replicated to each CAP.

When you make configuration changes to an SMS site, all the Legacy Clients contact the CAPs at their next wakeup interval and update the client from the CAPs based on these changes. An example of a configuration change is installing an SMS service pack. The default wakeup interval is 25 hours. Although your CAPs might not always be heavily loaded, make sure that you have enough capacity to perform these operations after your hierarchy is set up. This is especially true for sites that contain a large number of clients. It is important to remember that CAPs also receive data from clients, including inventory and status messages.

The SMS site server is automatically installed as a CAP. If you want to dedicate a primary site to performing only SMS server activities, you can remove the CAP role from the site server after you have created another CAP in the site and assign it to another server. This ensures that the primary site is dedicated to performing site server activities and that these services are not affected by client requests. This is especially true in a large site with thousands of clients.

The CAP role can be assigned to servers or to server shares. If you create the CAP as a server, SMS chooses the largest NTFS partition and creates the CAP directory structure on that partition. If you want to choose the partition where the CAP directory structure is created, create a share on that partition, create a new server share, and assign the CAP role to that server share.

For information about sizing CAPs and determining the number of CAPs per site, see Appendix F: "Appendix F - Capacity Planning for SMS Component Servers."

Distribution point

Distribution points can be created as a server or as a server share. When you create the distribution point as a server, SMS uses all available NTFS partitions for package storage. If you want to restrict SMS to use a specific NTFS partition, create a share on that partition and create a new server share as a site system, then assign the distribution point role to that server share.

The load on a distribution point varies with the number and size of the packages you distribute. You determine the necessary computing capacity of distribution points the same way you would size any file server in your organization — through testing and the collection of empirical data in your test lab.

The number of distribution points needed in a site depends on the number of clients that need access to packages for software distribution. The number of distribution points might also depend on the location of clients. It is preferable to specify a distribution point that is in close proximity to a group of client computers. The more software distribution you do, and the larger the software packages you deploy, the more distribution points you need.

Note

Distribution points receive packages and package updates from the site server without bandwidth throttling. Customers might choose to install a secondary site in the remote office to gain the site-to-site bandwidth-sensitive and scheduling capabilities of SMS senders. However, because of improvements to software distribution in SMS 2003 SP1, you might consider installing a distribution point rather than a secondary site.

*SPBefore SMS 2003 SP1 was released, SMS 2003 was designed to process a single thread per package. This resulted in SMS copying content to one particular distribution point, and when successful, moving to the next distribution point when multiple distribution points were targeted to receive the package. The failure of any one distribution point to receive the package could cause the package distribution process to stop.

In SMS 2003 SP1, the package distribution process is multi-threaded. SMS copies content to multiple distribution points in parallel. Because of this change, failure of a single distribution point does not stop the distribution of the package to other distribution points. This change improves both reliability and response time for package deployment, and effectively allows a single site to support a much larger number of distribution points. The following benefits can result:

• Reduced elapsed time for package distribution to all distribution points of the site.

• Simplified site hierarchy, because in some cases a secondary site can be replaced by a distribution point.

• Faster software deployment, which is key for patch deployment.

• Lower hierarchy deployment costs, which results in fewer required site servers.

• Faster hierarchy deployment, because it is faster and easier to deploy a distribution point than a site server.

• Lower maintenance costs, because it is easier to manage a distribution point than a site.

Configure how may packages SMS processes concurrently per SMS 2003 SP1 site on the Distribution Point tab in the Software Distribution component properties dialog box in the SMS Administrator console. When your site hierarchy includes previous versions of SMS (SMS 2.0 or SMS 2003), this setting is not configurable from an SMS 2003 SP1 Administrator console.

Before SMS 2003 SP1, in an SMS hierarchy with three or more tiers, a source package was resent from the central site even when a site closer to the target site had a copy of the package. SMS 2003 SP1 includes improvements to fan-out distribution that can help reduce the workload on the SMS site initiating the distribution of a package, as well as reducing the network load on the link between the initiating site and the target sites. When you select the Send package from the nearest site in the hierarchy option on the Distribution Point tab in the Software Distribution component properties dialog box, the site where the package is originally created identifies which parent site has the correct package contents and version that is closest to the target site. This action affects package distribution in the following ways:

• When compressed package source files with the correct version are available at a parent site that is near the requesting site, the source site instructs the closest parent site to send content to the requesting site.

• When a site’s distribution point is targeted to receive a new package, the source files are retrieved from the closest higher-level parent site in the hierarchy.

• When a new distribution point is created, the site where the package was originally created identifies the parent site that has the correct package contents and version that is closest to the target site. That parent site then updates the newly created distribution point.

• SMS 2.0 child sites are updated by the closest parent SMS 2003 site that contains the updated package source files. *SP

BITS-enabled distribution point

As clients roam from location to location, computers with the Advanced Client installed check for the availability of SMS sites with distribution points that contain needed software content. The Advanced Client remains assigned to its original site. However, when the Advanced Client needs to retrieve an advertised package, it can download or run the package from a local distribution point, rather than from its assigned site. Remember this when you choose remote servers to be distribution points.

To protect your Advanced Clients from excessive bandwidth consumption, enable BITS on your distribution points that serve Advanced Clients. This provides an efficient file transfer mechanism through client-sensitive bandwidth throttling. It also provides checkpoint restart download of packages, which allows files to be transferred to the client in a throttled manner. For more information about how bandwidth is used by BITS see the whitepaper Background Intelligent Transfer Service in Windows Server 2003.

Plan to have both your CAPs and distribution points on the same high-speed, reliable connection as the site server. Although these site systems can function over a WAN, the consequences can be detrimental and potentially cause significant network activity on your WAN.

Important

BITS requires Microsoft Internet Information Services on the management point and that you enable BITS on the distribution point.

Protected distribution point

The protected distribution point is designed to protect network links to distribution points from unwanted traffic. The SMS administrator specifies which roaming boundaries or site boundaries Advanced Clients must be in to use the protected distribution point. Any clients outside those boundaries are unable to download or run packages from that distribution point. An Advanced Client located within the boundaries of a protected distribution point prefers the protected distribution point and does not contact distribution points outside those boundaries. Legacy Clients do not respect the boundaries of the protected distribution point.

To restrict access to a distribution point that is across a slow or unreliable network link, plan to enable it as a protected distribution point. This is beneficial at remote locations, where a small number of SMS clients and a distribution point are connected to the primary site by a WAN. For example, consider configuring a protected distribution point on secondary site servers that are connected to their parent primary site by a WAN link.

Management point for Advanced Clients

Even though Advanced Clients are only assigned to primary sites, management points can be installed on both primary and secondary sites. A management point on a secondary site is known as a proxy management point. It can be set up and used for roaming Advanced Clients if roaming boundaries are enabled. Proxy management points increase bandwidth efficiency by servicing roaming clients that are within the secondary site’s roaming boundaries. For more information, see the “Management points at secondary sites” section later in this appendix.

Multiple management points

Typically, an SMS site containing Advanced Clients uses only the default management point. However, multiple management points can be implemented in one site to meet either network load balancing or backup needs.

Network load balancing is having two or more management points on sites that have a high percentage of Advanced Clients. This balances the load of network traffic flowing from clients to the management point.

Backup is having an extra management point on a site in case the default management point fails. In this scenario, the administrator designates the backup management point as the default management point. Note that the secondary management point does not provide automatic failover. It remains idle until it is designated as the default management point.

Note

Network Load Balancing Service is a Windows 2000 Advanced Server feature that is used to build a server cluster, which is a set of computers that work together to provide a service. The typical setup involves using one network adapter to manage the computers and a second network adapter to service clients. The latter network adapter has a single virtual IP address. The other computers in the cluster share the same virtual IP address as the network adapter used to service SMS clients. For information about configuring Network Load Balancing, see the Windows 2000 Advanced Server documentation.

Management points at secondary sites

Advanced Clients located at a secondary site and reporting to a management point at a parent primary site across a WAN link might have an effect on the available bandwidth of the WAN link between the secondary site and its parent primary site. Significant network traffic can be produced when client status and hardware or software inventory data is sent to the parent primary site. Because an Advanced Client can be assigned only to a primary site, network traffic generated by Advanced Client policy requests also reduces the available bandwidth between the two sites.

Installing a proxy management point at the secondary site can significantly reduce the effect on available network bandwidth created by Advanced Clients located within that site’s roaming boundaries or site boundaries. Advanced Clients send inventory data, software metering data, and status data to the proxy management. The proxy management point uses the site’s sender functionality to transfer the data to the parent primary site. By using the sender’s bandwidth control functionality, you can specify when the data is sent to the primary. The proxy management point also caches some Advanced Client policy information. Advanced Clients obtain this Advanced Client policy information from the proxy management point, rather than from the management point at the primary site. Figure E.8 represents these communications.

Figure E.8   Proxy management point communications over a WAN link

Plan to include a single proxy management point at a secondary site if you have a significant number of Advanced Clients using resources in that site.

SQL Server database replication for management points

If the number of Advanced Clients grows significantly, you can replicate the tables in the SMS site database to a different instance of SQL Server than the one used by the SMS site database. This reduces the load on the primary site’s SQL Server database because the management points query a different instance of SQL Server when servicing Advanced Client requests. The replicated tables can be on the computer with the management point or on a stand-alone computer running SQL Server with no other SMS site system roles.

Some of the standard configurations that you can use include:

• A single management point accessing the site server SQL Server database directly. This is suitable when relatively small numbers of Advanced Clients must be supported.

• A single management point with its own replicated SQL Server database. This configuration takes the load off the site server SQL Server database and allows the management point to continue operation when the site server SQL Server database is unavailable.

• Multiple management points that are using network load balancing and accessing a single replicated SQL Server database. This is suitable when higher numbers of Advanced Clients must be supported. High resiliency is provided by isolation from the site server database and network load balancing with dynamic failover.

• Multiple management points that are behind a network load balancing server, each with their own local, replicated SQL Server. This is suitable when very high numbers of Advanced Clients must be supported. Local SQL Server installations and network load balancing provide maximum throughput and resiliency.

Management point requirements

Remember the following requirements and features when planning management point roles:

• You must install IIS and BITS on SMS management points.

• If you want to implement database replication, see the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide for information about the SQL Server version requirements.

Important

For a management point to be assigned to a site, that site and all its parent sites must be running SMS 2003.

Management point security recommendations

Consider the following security recommendations as you plan for management points in your SMS site.

Maintain one management point at the primary site

Every primary site must have one management point that is used to manage Advanced Clients. However, if you require a secondary site you have the option of installing a proxy management point at the secondary site. For more information about proxy management points, see Appendix E: "Appendix E - Designing Your SMS Sites and Hierarchy."

In this scenario, maintaining one management point at the primary site is inherently more secure than maintaining an additional proxy management point at the secondary site for the following reasons:

• No need for Advanced Clients to trust an additional management point.

• No need for proxy management point to access the SMS site database remotely at the primary site.

However, having the ability to configure a proxy management point is a key feature of SMS. For this reason, the same management point authentication functionality that exists at the primary site (Active Directory and trusted root key) is also used to authenticate proxy management points. Nevertheless, reducing the number of management points can minimize the potential for security attacks and should be considered when designing your site deployment strategy.

Note

If you need to maintain a proxy management point at a secondary site, you can reduce the potential for security attacks by using IPSec to secure communications between the proxy management point and the remote SMS site database.

Maintain the management point on its own server

You can configure a management point to run on the site server, or on its own server. Configuring the management point to run on its own server option is inherently more secure for the following reason:

• A potential security attack through IIS on the management point would not necessarily compromise the site server, or the SMS site database if it is maintained on the site server.

However, when you configure the management point to run on its own server, it still needs to communicate with the SMS site database. If you choose to replicate the SMS site database to the management point server, periodically the management point must update the SQL replica. Because this communication occurs across the network, it is exposed to potential security attacks.

Nevertheless, maintaining the management point on its own server can be more secure. If a security attack on the management point is successful, it is essential that the attack does not result in control of the SMS site database. The network connection between a remote management point and the SMS site database server can be physically secured, and IPSec can be used to further reduce the potential to attack communication between the management point and the SMS site database server.

Configure Advanced Clients to use a TCP port other than Port 80

SMS 2003 RTM Advanced Clients by default use only TCP Port 80 for communication with management points, server locator points, and BITS-enabled distribution points.

In SMS 2003 SP1, you can change the TCP port to provide additional security for this kind of communication. Specify the TCP ports used by Advanced Clients on the Ports tab in the properties of the SMS site. For more information about changing the TCP port for communications, see Appendix E: “Changing the Advanced Client Default HTTP Port” in Scenarios and Procedures for Microsoft Systems Management Server 2003: Security.

Management point troubleshooting

There are several reasons the management point installation might fail. The MPMSI.log file in the SMS/Logs folder on the SMS site server logs management point installation errors. If you have problems installing the management point, search on “return value 3” for errors in this log file. In addition, status messages relating to the failure of the management point to install are recorded for the SMS_Site_Component_Manager component on the SMS site server associated with the management point, as well as SMS_Executive and MP_Control_Manager components on the management point.

The following is a list of configurations to verify when troubleshooting the installation of a management point:

• If your management point is a computer running Microsoft Windows Server™ 2003, verify that IIS and BITS Server Extensions are installed. IIS is not installed by default because it is in Windows 2000. When you install IIS on a computer running Windows Server 2003, the BITS Server Extensions must be manually added to the installation. BITS Server extensions are installed as part of the management point installation on a computer running Windows 2000.

• If your management point is Windows 2000 and you are using the IIS Lockdown tool on the IIS 5.0 server, apply the SMS server template from the SMS 2003 toolkit available at the Microsoft Download center.

• Verify that the server has an NTFS partition.

• Verify that the Distributed Transaction Coordinator (DTC) Service is enabled. If the DTC Service is not enabled or running, status message 4961 is generated for the SMS Site Component Manager, and the error is recorded in the MPMSI.log file.

• Verify that the Task Scheduler service is enabled. On Windows Server 2003 Domain controllers, the Task Scheduler service is disabled by default. If the Task Scheduler Service is not enabled or running, status message 4962 is generated for the SMS Site Component Manager, and the error is recorded in the MPMSI.log file.

• Verify that the COM+ System Application service is not disabled. This service is set to Manual by default.

• Verify that the Windows Management Instrumentation service is running.

• Verify that the World Wide Web Publishing Service is running.

• Verify that the Default Web site has started and is running.

• Verify that the Default Web site is using Port 80.

• Verify that the virtual directories (ccm_incoming and vdir) are created on the IIS Server.

• Verify that the SMS Agent Host service is installed, running, and can be started and stopped in a timely manner.

If all of these configurations are verified, try updating the MDAC version on the management point to 2.8. For more information, see article 820761in the Microsoft Knowledge Base.

If the management point is installed correctly, but errors are recorded in the management point event log, verify that the IIS IWAM_computername account and the copy of IWAM_computername are synchronized. For more information, see article 297989 in the Microsoft Knowledge Base.

You can verify whether Advanced Clients can access the management point by connecting to http://<ServerName>/sms_mp/.sms_aut?MPLIST, where ServerName is the name of the management point. If a blank page displays with no errors in the Windows header, the client can access the management point.

Server locator point

Plan for a server locator point in your SMS hierarchy when any of the following are true:

• You use Logon Script-initiated Client Installation to deploy Legacy Clients or Advanced Clients

• You want to automatically assign Advanced Clients to sites without extending the Active Directory schema for SMS

The server locator point requires minimal planning. Unlike management points, server locator points are supported only in primary sites, not secondary sites, and they are used for both Advanced Clients and Legacy Clients. The number of server locator points you include in your site depends on the number of clients in that site. Typically, you need only one server locator point in your SMS hierarchy.

Typically, you install the server locator point at the central site. If the server locator point creates too much load at the central SMS site database, you have the option to use a replicated SQL Server database for that site. If there are excessive client requests, causing excessive traffic on a single server locator point, you can set up multiple server locator points at the central site.

Server locator points are only accessed by the Legacy Client at client logon time and produce minimal network traffic — approximately a 1-KB upload and a 1-KB download to the client. Because the Advanced Client only accesses the server locator point once, for automatic site assignment at its initial logon time, the bandwidth impact is insignificant.

Like management points, server locator points require IIS.

Note

Replication of both the management point and server locator point databases is supported by some versions of SQL Server. SQL Server supports replication to third-party heterogeneous databases; however, they are not supported by SMS 2003. For more information, see the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

Reporting point

Reporting points communicate only with the local SMS site database. A reporting point server requires IIS. You implement reporting points only on primary site servers, not on secondary site servers. The placement of your reporting points depends on what data you want to report. For example, a reporting point placed as high as the central site can report on data that is produced by all tiers of the hierarchy, except for the status of advertisements sent only to a lower level site in the hierarchy.

Large organizations with numerous report users and additional scalability needs might consider planning for multiple reporting points. With multiple reporting points, you can provide different reporting point access URLs to different sets of users for accessing reports. However, be aware of the potential for performance degradation of the SMS site database server if your use of reports and reporting queries is very high, especially if you have a large number of report users running the same reporting query.

Note

Although a Recovery Expert Web site is not a site system, it can share roles with other site systems. If you plan to install a Recovery Expert Web site, you must allocate an IIS server for it. For more information about Recovery Expert Web sites, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.

Site Configuration Planning

After you install SMS 2003, and before you deploy SMS client software, you must configure the new site. It is important to perform site configuration in a controlled manner. The information that you gather during planning, guides the settings that you enable when you configure individual SMS sites and build your SMS hierarchy. You begin the site configuration process by defining site characteristics and configuring site system roles at a single site. When you configure individual sites, you can build an SMS hierarchy by establishing intersite communications and attaching sites to form the site-reporting structure you designed earlier in the planning phase. Or, you can configure all of your sites and then build your hierarchy.

This section, which helps you plan the configuration of your sites and hierarchy up to the point of installing clients, includes planning guidelines for configuring your SMS site servers, site systems, and senders. For configuration information that is relevant to each specific SMS feature, see the Microsoft Systems Management Server 2003 Operations Guide.

Modify your site-deployment plan document based on the configuration planning guidelines in this section. In addition to configuration details, include a copy of your hierarchy design in your document. Use this diagram to pinpoint the locations of site system roles, the discovery and installation methods used in each site, and the types of communication methods used between sites.

If you have a large organization, consider how you can categorize your plans. For example, you might have one plan that you use to deploy and configure a group of sites, if you expect to have identical configurations in each. You might also have a plan that encompasses all of your secondary site deployments.

Configuring an SMS Site

Planning to configure a single SMS site involves planning for security rights, scheduling maintenance tasks, and assigning site system roles. Plan to configure your SMS site before you enable any discovery or client installation methods. This section describes how to plan for:

• Configuring site security.

• Configuring tasks, alerts, and status system.

• Configuring site boundaries and roaming boundaries.

• Preparing site system computers.

• Assigning site system roles.

Configuring Site Security

After you install SMS 2003, use the SMS Administrator console to configure security for the new SMS site. This configuring prevents users from making unauthorized changes to the SMS system. After you configure security, you can set up alerts and maintenance tasks, configure the boundaries of the site, and assign the site systems that help run SMS on the site. Create your site security configuration plan by using the guidelines in .

Configuring Tasks, Alerts, and Status System

In your deployment and configuration plan, include information about how to configure the following items for monitoring and maintaining your SMS site.

Configuring the SMS status system

Plan to configure the three status summarizers with threshold periods, and choose a threshold period that is appropriate for how often you plan to check the status summarizer.

• Advertisement Status Summarizer

• Component Status Summarizer

• Site System Status Summarizer

For more information, see Part 2 in the Microsoft Systems Management Server 2003 Operations Guide.

Scheduling SMS site database maintenance tasks

Plan to configure the site maintenance tasks in the SMS Administrator console. These tasks are critical to properly maintaining a site. They enable you to schedule key database activities such as backups and data deletion. Determine how you can schedule these tasks to maintain an appropriate database size, and be prepared to recover a site if a site fails.

Plan to properly back up the SMS site server so that you can restore it if the site server or SMS site database server fails. You can automate site backups by enabling and configuring the integrated Backup SMS Site Server task. This is not enabled by default in your site settings. It is important that you become familiar with Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery before you implement SMS in your production environment.

You should also schedule regular maintenance tasks for SMS administrators to perform, such as:

• Reviewing site status messages and reports.

• Checking for unprocessed inventory files.

• Checking the size of database devices and logs.

• Verifying that site systems have ample disk space (this is done by default by the Backup SMS Site Server task and is tracked by the Site System Status Summarizer).

Configuring logging

To assist in troubleshooting problems within your SMS site, plan to enable logging. Use the SMS Service Manager tool in the SMS Administrator console to enable logging. You can specify which components are logged and set the log file size. For more information, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.

Configuring Windows Event Viewer, System Monitor, and Performance Logs and Alerts

In evaluating system performance, setting up a monitoring configuration is the first step. By using Event Viewer and event logs, you can gather information about hardware, software, and system problems, and you can monitor Windows security events. With System Monitor, you can measure the performance of your SMS site server. With Performance Logs and Alerts you can collect performance data automatically from local or remote computers. You can view logged counter data by using System Monitor, or you can export the data to spreadsheet programs or databases for analysis and report generation.

Plan to configure your Windows event logs so that they do not fill up rapidly with SMS (or other application) events. For example, you might plan to set each log in the Windows Event Viewer (System, Security, and Application) to Overwrite Events as Needed or to Overwrite Events Older than <user-defined number> Days.

Note

Windows security auditing is a powerful method for monitoring security. Plan to set the appropriate audit policies in Domain Security Policy or Local Security Policy. Auditing failure events is sufficient for most purposes. Enabling success events provides many details on SMS activity, but it also consumes considerable computer resources. With Windows security auditing enabled, you can watch the security event log for events that are related to SMS. For information about configuring Security Policy see your Windows product documentation.

For more information, see Part 2, “Maintaining SMS in Your Organization,” in the Microsoft Systems Management Server 2003 Operations Guide.

Setting up SQL Server alerts

Determine whether you want to use SQL Server alerts. Plan to configure these in SQL Enterprise Manager on your SMS site database server. Define alerts for events, such as a database or transaction logs running out of disk space, or for fatal errors in database processes. For more information, see your SQL Server product documentation.

Configuring Site Boundaries and Roaming Boundaries

How you configure site boundaries and roaming boundaries affect:

• Whether discovered computers are assigned to SMS sites.

• How packages are distributed to Advanced Clients.

Remember that SMS clients can be assigned to only one SMS site, and Advanced Clients can only be assigned to primary sites.

Avoid configuring site boundaries or roaming boundaries that overlap other boundaries. IP subnets or Active Directory sites should not be contained in more than one SMS site. This ensures that there is no confusion about which site a client is assigned to. You cannot predict the results in SMS if your sites have overlapping site boundaries or roaming boundaries.

Using correctly defined subnet boundaries or Active Directory sites ensures that SMS 2003 sites have unique boundaries. However, it is fairly easy to have incorrectly defined subnet boundaries or Active Directory sites. To avoid this problem, watch for the following issues:

• Ensure that a subnet is not used to define multiple Active Directory sites. Active Directory does not enforce such uniqueness in all cases. Keep a record of site definitions so that this problem is obvious if it does occur.

• If a subnet is used to define an Active Directory site, do not use it to also define an SMS site. Instead, define the SMS site by using the Active Directory site.

Check with network administrators to ensure that subnet masks are specific enough to ensure that the resulting subnets are unique. For example, use a subnet mask such as 255.255.255.0 if 255.255.0.0 would create subnets that would include clients at multiple locations. This can be a problem particularly if you use virtual LANs, where sufficiently specific subnets are not needed other than to define SMS and Active Directory sites.

Caution

If a client operating system’s codepage is different from the servers that receive its discovery data, the servers might not be able to use the discovery data and will not assign the client to the site even if it should be. This can happen if your Active Directory site names contain a double-byte character set (DBCS) string.

Setting site boundaries

Legacy Clients cannot be assigned to an SMS site until you configure site boundaries in the SMS Administrator console. For large organizations, create a plan to add your site boundaries by using a controlled method. For example, if you are using a large number of individual IP subnets as your site boundaries, consider using a phased approach when you are adding site boundaries to an SMS site. Also, remember that the site boundaries of secondary sites automatically become the roaming boundaries of the parent primary site.

As a best practice, use Active Directory site names to define site boundaries.

Setting roaming boundaries

Advanced Clients cannot be assigned to an SMS site until you configure roaming boundaries. To provide Advanced Client access to management points and to software packages on distribution points, configure roaming boundaries in the SMS site. By default, each site boundary is also configured as a roaming boundary.

As a best practice, use Active Directory site names for roaming boundaries. If your environment is not Active Directory-enabled, then use IP subnets. In the absence of Active Directory, or if you have the choice of using either IP subnets or IP address ranges to define your roaming boundaries, choose IP subnets. IP address ranges require a slightly longer look-up time and have a slightly greater effect on both SMS client and server performance. If you have dial-up or VPN clients, and if each IP address has a subnet mask of 255.255.255.255, use IP address ranges for roaming boundaries.

As a best practice, specify local roaming boundaries for the well-connected segments of an SMS site (such as over a LAN). Specify remote roaming boundaries for the slow or unreliable network links in your SMS site (such as RAS, a wireless network, or a 56 Kbps dial-up connection).

Note

Because the client is usually connected over a slow or unreliable network link when it is in a remote roaming boundary, you can preserve bandwidth by enabling Background Intelligent Transfer Service (BITS) on the distribution point and configuring the advertisement to download before it runs.

Preparing Site System Computers

Your hierarchy design identifies the site system roles you plan to implement in your SMS site and the locations of those site systems. When you review the placement of site systems, ensure that they are well connected to the site server. For more information, see Chapter 8: “Designing Your SMS Sites and Hierarchy.”

In planning site systems, make sure that the computer you use in a site system role has the required disk space and other resources available. For a list of the basic requirements for site systems, see the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide. Ensure that users, services, and SMS client accounts have the necessary permissions on the server. For example, Legacy Clients must be able to access CAPs and distribution points.

Site systems that use IIS require a minimum IIS configuration. When you are planning to deploy management points, server locator points, BITS-enabled distribution points, and reporting points, pay attention to configuring IIS for security. Ensure that only the necessary components and ports are enabled in IIS. For details about configuring IIS for SMS site systems, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery, and the Security Checklists spreadsheet provided with Scenarios and Procedures for Microsoft Systems Management Server 2003: Security.

Site systems that are on a computer running Windows Server 2003 and have other requirements are reporting points, management points, and BITS-enabled distribution points. For more information, see the “Special Windows Server 2003 Requirements” section later in this appendix.

Caution

If you use the Microsoft IIS Lockdown tool (Iislockd.exe) to increase security protection, be sure to apply it to IIS-enabled SMS site system computers (by using the SMS 2003-specific template) before you enable the computer as an SMS site system. If you use the IIS Lockdown tool after you create the site system, your site IIS-dependent site system will not function properly. For more information about the IIS Lockdown tool, see your IIS documentation.

Be aware of the following prerequisites and other considerations in setting up management points, server locator points, CAPs, reporting points, and distribution points. For information about supported operating systems, see the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

Important

Do not install SMS site components on computers or shared folders whose names use DBCS.

Management point

You install management points in primary sites or install them as proxy management points at secondary sites. To be a management point, the computer must have IIS installed and enabled. Management points require access to the SMS site database. A primary site can have only one logical management point (the default management point). Typically, for Advanced Client policy requests and other communications, the Advanced Client uses the default management point of the SMS site to which it is assigned — its assigned management point.

However, with Network Load Balancing, multiple management points can be implemented in one primary site to meet the capacity needs of your organization. You combine multiple management points of one site into a Network Load Balancing cluster. Management points in a Network Load Balancing cluster do not register automatically with WINS because they share a virtual IP address. In the absence of Active Directory, you must manually register the Network Load Balancing server’s virtual IP address in WINS. For more information about using SQL Server database replication with management points, see the “Planning for SQL Server Database Replication” section earlier in this appendix. For more information about using Network Load Balancing, see the “Management points and Windows Network Load Balancing” section. Stand-alone management points are automatically registered in the WINS database.

Note

When you enable a server as a management point, the WMI service is stopped and restarted on that server.

Management points and Windows Network Load Balancing

A primary site server can have multiple physical management points. However, it can have only one logical management point — the default management point. Advanced Clients communicate only with the default management point. Other management points are unused, unless they are configured using the Windows Network Load Balancing service (also known as Network Load Balancing).

If you expect to have a large number of Advanced Clients in an SMS site, consider using Network Load Balancing to spread client communication activity over several management points. If you anticipate growth in your organization, Network Load Balancing can help you scale management point performance to keep up with the increasing demands of your Advanced Clients.

Note

Do not confuse Windows Network Load Balancing service with Windows Cluster service. Cluster service is one of two complementary Windows clustering technologies. The other clustering technology, Network Load Balancing, complements Cluster service by supporting highly available and scalable clusters for front-end applications and services.

If you have multiple management points in a Network Load Balancing cluster, SMS clients regard them as one unique management point, using one virtual IP address. SMS clients access the management point hosts by using the IP address, which then uses the Network Load Balancing cluster to optimize traffic by distributing client requests across management points. This allows for increased client connections and throughput, and it also allows the management points to be managed by their site server without interfering with client traffic. SMS sites continue to administer the management points as separate nodes.

The following Network Load Balancing configurations are supported for SMS 2003 management point clusters:

• Unicast mode with a single network adapter

• Unicast mode with dual network adapters

Multicast modes are not supported.

An important configuration option to consider when you are setting the parameters for Network Load Balancing is how clients choose a preferred host in the cluster. This is called affinity, and there are three affinity options: None, Single, and Class C affinity.

The None option specifies that Network Load Balancing does not have to direct multiple requests from the same client to the same cluster host (no client affinity).

The Single option specifies that Network Load Balancing should direct multiple requests from the same client IP address to the same cluster host.

Class C affinity specifies that Network Load Balancing should direct multiple requests from the same TCP/IP Class C address range to the same cluster host.

SMS 2003 management points in a Network Load Balancing cluster are only supported if the affinity is set to Single or None. The default setting for affinity is Single.

Server locator point

The server locator point is installed only in a primary site, not in a secondary site. To be a server locator point, the computer must have IIS installed and enabled. Also, if Active Directory is not enabled, or if the Active Directory schema is not extended for SMS, you must manually register the SMS hierarchy’s server locator point in WINS for automatic site assignment of Advanced Clients.

Plan to deploy a server locator point in your SMS hierarchy to provide any of the following:

• Automatic site assignment for the Advanced Client in the absence of Active Directory (in this scenario, you must manually register the server locator point in WINS)

• Site assignment and locating CAPs for Legacy Clients during Logon Script-initiated Client Installation

• Locating management points for Advanced Clients during their initial Logon Script-initiated Client Installation

• Site assignment and locating management points for Advanced Clients that have insufficient rights during their initial Logon Script-initiated Client Installation

Client access point

When you prepare a computer to be a CAP, ensure that at least one NTFS partition is available. SMS does not support CAPs on non-NTFS partitions such as FAT and FAT32.

Every SMS site must have at least one CAP. When you install SMS, the site server is automatically configured as a CAP. The SMS administrator can move the CAP to another server if necessary. You can create additional CAPs to distribute the client workload.

Distribution point

If you plan to advertise many packages to the client computers in your SMS site, consider assigning the distribution point role to one or more computers other than the site server, to reduce server load.

Distribution point with BITS enabled

To protect distribution point users from excessive bandwidth consumption during download, plan to enable BITS on distribution points that serve Advanced Clients. This provides an efficient file transfer mechanism through client-sensitive bandwidth throttling. Like server message block, BITS also provides checkpoint restart download of packages, which allows downloads to continue from the point at which they were stopped when a lost connection is re-established, instead of starting the transmission from the beginning. For more information about how bandwidth is used by BITS see the whitepaper Background Intelligent Transfer Service in Windows Server 2003.

SMS does not support the creation of a distribution point on a computer that is running Windows 2000 Advanced Server with the Windows Cluster service enabled.

Protected distribution point

If you want a site’s distribution point to be protected from use by clients that are outside of a particular site boundary or roaming boundary, configure it to be a protected distribution point. For example, you might configure a secondary site server that manages a single remote subnet to be a protected distribution point to prevent Advanced Clients in other sites from accessing that distribution point across the WAN connection.

Reporting point

When you are planning your deployment, consider whether you want to use the reporting feature in SMS. If so, plan how many reporting points you anticipate using, who will be authorized to run SMS reports, and where you will deploy each reporting point. To be a reporting point, the computer must have IIS installed and enabled.

For each site, determine whether you want the site server to serve as a reporting point, and whether you want to assign the reporting point role to one or more site systems. In some cases, consider using secured, dedicated computers as SMS reporting points. Also, consider whether you want to install a reporting point at only the central site, or install a reporting point at each SMS site in the hierarchy. This decision depends on how you plan to use SMS reporting.

Your pilot project helps you determine the effect of having a reporting point on your SMS site server. Larger organizations might want to set up separate administrative sites that contain a reporting point.

Also, consider whether you want to use supplemental reports, or just the predefined reports that are included with SMS. Supplemental reports can provide your organization with more reporting options. If you decide to use supplemental reports, be sure your staff has the appropriate programming skills to create supplemental reports, and that it is appropriately trained to build adequate security into those reports. The predefined reports that are included with SMS have built-in security.

Plan to define the criteria for what will be included in supplemental reports. Also consider whether you want to allow users to run real-time reports, or just allow users to view reports that are generated at non-peak times.

Before you can begin using reports in SMS, you must enable one or more of your site systems as a reporting point.

Special Windows Server 2003 requirements

Management points have a special requirement if they are installed on a computer that is running an operating system in the Windows Server 2003 family. Before you deploy a management point, you must enable IIS and enable BITS as a Windows component on the site system server. If you do not enable BITS in Windows first, enabling a server as a management point fails.

A reporting point also has a special requirement when it is installed on a computer that is running an operating system in the Windows Server 2003 family. Before you deploy the reporting point, you must enable Active Server Pages as a Windows component on the reporting point server. Otherwise, your reporting point will not function properly. For more information, see your Windows Server 2003 documentation.

Important

Before upgrading a computer that is running IIS to Windows Server 2003, you must either disable IIS, or ensure that it is locked down by using the IIS Lockdown tool. If you have an SMS reporting point on a computer running a Windows 2000 Server family operating system, and you do not run the IIS Lockdown tool before you upgrade that server to Windows Server 2003, your reporting point will not be operable after the operating system upgrade. To reinstate reporting functionality, you must enable IIS after the upgrade by invoking Internet Information Services (IIS) Manager in Administrative Tools. For more information, see your Windows Server 2003 documentation.

Assigning Site System Roles

You create a site system by specifying the server to be used as the site system and assigning the site system role to it. When you create a site system on a computer that is running an operating system in the Windows 2000 Server or Windows Server 2003 family, SMS installs the appropriate components on the computer, and the new site system begins performing its role in the SMS site.

Note

The process of assigning a site system role to a server is usually referred to as creating the <site system role>. For example, assigning the CAP role to a server is creating the CAP.

The SMS site server is automatically assigned the site server role. Similarly, the computer running SQL Server that contains the SMS site database is automatically assigned the SMS site database server role. By default, SMS assigns CAP and distribution point roles to the site server, but these roles can also be assigned to other computers.

You can remove the CAP, distribution point, management point, server locator point, and reporting point role from an SMS site. To reassign a CAP, distribution point, server locator point, or reporting point role to a different site system, remove it from the first site system and assign it to the next. To reassign a management point, enable another computer as a management point, disable the default management point setting from the current management point, and then enable the new management point as the default management point. You cannot reassign the SMS Provider role.

For information about modifying and deleting site system roles, see the “Creating Site Systems” section in Appendix G: "Appendix G - Deploying and Configuring SMS Sites."

Configuring an SMS Hierarchy

Configuring the SMS hierarchy consists of installing primary sites and setting up communication between them. Then you install and configure the senders and addresses between sites. Finally, you build the SMS hierarchy by attaching sites to other sites.

Your deployment plan should include setting up the hierarchical structure between the sites in the SMS hierarchy. This reporting structure is based on your hierarchy design and determines how data flows between the sites. Because this data flow can significantly affect the efficiency of your SMS system, plan the hierarchy before you install SMS. Use the guidelines described earlier in this appendix.

To configure the SMS hierarchy, you perform the following tasks:

• Configure site communications

• Attach SMS sites

Configuring Site Communications

Plan your site settings so that each SMS site can communicate with its parent site and child sites. This involves installing and configuring senders on each site, and then creating addresses to the other sites that you want the site to communicate with.

In your deployment plan, include validating each of the requirements for configuring site communications. For more information, see Appendix G: "Appendix G - Deploying and Configuring SMS Sites."

Choosing Senders

The choice of senders you install depends on the existing connectivity system between your sites. If you have reliable, high-speed network connections between sites, plan to use Standard Sender. If you have RAS connections between sites, select the appropriate type of RAS sender for your connection. If you want to send large amounts of package data for software distribution to sites using physical media instead of over the network, use Courier Sender.

SMS sites are created with the following senders installed and configured by default:

• At primary sites, Standard Sender and Courier Sender

• At secondary sites, Courier Sender and either Standard Sender or Asynchronous RAS Sender

When you create a secondary site, you create an address from the new secondary site to the parent site. You can create either a Standard Sender address or one of the RAS Sender addresses. Depending on which type of address you create, the appropriate sender is installed at the new secondary site.

Based on the types of links between SMS sites, choose from the senders in Table E.6.

Table E.6    Choosing SMS Senders

Existing connectivity system between sites	Usage	Sender type
LAN or WAN	Use Standard Sender, the most commonly used sender, for sending to other sites on the same LAN, or on a WAN using routers, switches, or bridges.	Standard Sender (automatically installed and configured when you set up an SMS site)
Asynchronous line	Use Asynchronous RAS Sender for RAS communications over an asynchronous line.	Asynchronous RAS Sender
ISDN line	Use ISDN RAS Sender for RAS communications over an ISDN line.	ISDN RAS Sender
X.25 line	Use X25 RAS Sender for RAS communications over an X.25 line.	X25 RAS Sender
SNA	Use Systems Network Architecture (SNA) RAS Sender in RAS communications over an SNA link.	RAS over SNA Sender
None	Use Courier Sender to send packages between the sites by using removable media instead of network wiring and protocols if you have a slow or unreliable link between a site and its parent. Courier Sender is used only for package distribution, not site-to-site communications.	Courier Sender

Note

If you have physical locations that are not continuously connected to the rest of your network, RAS is usually the most cost-effective way to add a new site to your system. For example, if you have a virtual private network (VPN) server, you can substitute a VPN phone book entry for the Phone book entry in the RAS Sender Address Properties. This works with any of the RAS senders in SMS. However, Advanced Clients at a secondary site prompts the proxy management point at the secondary site to connect directly with the SMS database at the client’s assigned primary site. If that communication is established with a dial-up connection, line usage can dramatically increase because by default, Advanced Clients check for new policy every hour.

When you set up a primary site, Standard Sender is installed and configured by default. So if your site-to-site communications occur over a LAN that uses a supported protocol, you do not have to install another sender. You can edit Standard Sender settings if you want to change the maximum number of concurrent sends or the retry settings for the sender. Increasing the maximum number of concurrent sends can increase the throughput of data between sites, but it can also result in higher demand on network bandwidth. Edit the retry settings to specify the number of times the sender retries a sending if the first attempt fails, and to specify how long it waits between retries.

You can use Courier Sender in software distribution to send package data to other sites by using physical media instead of sending data over the network. When you have large packages that would require excessive time or bandwidth to send them over the network, this sender can be useful. You can use Courier Sender at the source SMS site to create a parcel (a collection of files transferred from one site to another using Courier Sender), write the parcel to a tape, CD, or other physical medium, and then ship the tape or CD to the destination site by mail or a courier service. At the destination site, you can then use Courier Sender to receive the parcel and import the package data into the site. For information about packages and software distribution, see the Microsoft Systems Management Server 2003 Operations Guide.

You might want to create some sender connections from the central site to indirectly connected child sites if you have enough network bandwidth, and you want processes to take place quickly. See Figure E.9 for an example. If you distribute a package from the central site to a secondary site three tiers beneath it in your hierarchy by using the standard connections, it is delivered from the central site to secondary site through sites A and B. Depending on how the direct connection is configured, creating a direct sender from the central site to the indirect secondary site can increase the speed of distribution because the intervening lower level sites are bypassed.

Figure E.9   With Standard Sender, the package traverses through sites A and B when it is delivered to the secondary site for distribution. By using Courier Sender instead, the package is sent directly to the secondary site.

Preparing Servers for Sender Installation

You can install senders on the site server or on other computers that run an SMS 2003-supported operating system. For the Standard Sender, you want to make sure the server that you install the sender on uses the same LAN protocols as the site servers for the destination sites.

For the RAS Sender, plan to install Microsoft RAS on the source and destination sites, and be prepared to create RAS phone book entries for the RAS servers on each destination site.

When you install a sender on a server, the server becomes a site system for the SMS site if it is not already a site system. Make sure you know the name of the computer you plan to install the sender on.

For information about installing, configuring, and deleting senders, see Appendix G: "Appendix G - Deploying and Configuring SMS Sites."

Creating and Configuring Addresses

You can create several different types of addresses, each of which corresponds to a different type of sender. Before you can use a particular sender to contact another site, you must create an address to that site for that sender type. For example, to contact another site through Standard Sender, you must create a Standard Sender address to that site. To contact the site through one of the RAS senders, you must create an appropriate RAS Sender address to the site.

Before you create an address, make sure you know the site code of the SMS site that the address will connect to, the name of the site server for that site, and the type of sender you want to use for that site.

Note

The NetBIOS name of the site server must be used in the sender address and not the IP Address of that server. Using the IP address in place of the NetBIOS name in the sender address will result in a communication failure to the destination site.

To control network load, you can schedule when SMS can use an address and the amount of network bandwidth that SMS can use when it sends to the address. Also, to provide increased throughput or to act as a backup if some addresses are unavailable, you can define multiple addresses to each destination site. If you define more than one address to a site, you can specify the priority for SMS to attempt to use the addresses for that site. The details pane of the SMS Administrator console lists multiple addresses to a destination site in priority order.

*SPIn SMS 2003 SP1, you can limit the amount of data sent between sites to a fine level of granularity. This allows you to specify the size of the data blocks that are sent, and also to specify a time delay between sending each data block. This is called pulse mode.

Pulse mode is useful when you have a very low network bandwidth available between sites. For example, you might have constraints to send 1 KB every five seconds, but not 1 KB every three seconds, regardless of the speed of the link or its usage at a given time.

Configure settings for pulse mode in the properties of an address on the Rate Limits tab. This directly affects the amount and frequency of data transmission by each sender. *SP

For information about creating and configuring addresses, see Appendix G: "Appendix G - Deploying and Configuring SMS Sites."

Attaching SMS Sites

You attach SMS sites to create a hierarchical structure in SMS. Plan the order in which you will attach sites, thereby creating data flow between sites in a hierarchy branch. If a primary site contains a large amount of client data, for example, and you attach the site to another site, be aware that such client data propagates up the hierarchy to the primary parent site. Be sure to plan for this, and configure the appropriate address schedule and rate limits based on the amount and type of data you expect to flow up to the parent primary site.

Advanced Design Issues

Advanced design issues do not affect all site designs, although they can affect some. Consider the following design issues:

• Advantages of multiple sites

• Multilanguage site hierarchies

• Upgrade and interoperability

• Planning for domain migrations

• Planning for Active Directory

Advantages of Multiple Sites

The hierarchy provides a means of extending and scaling SMS support across a wide variety of organizational structures. A single site is the easiest to configure and manage, but there are circumstances in which it is beneficial to set up multiple sites in an SMS hierarchy. What is most important is data flow and ease of administration.

It is important during the design phase to consider your need for additional sites. These needs might belong to one of the following categories:

• Network performance with clients

• Number of resources

• Features required by users

• International considerations

• Number of sites

• Corporate structure

• Domain structure

Network Performance with Clients

Slow network connectivity between the site server and some clients might indicate a need to set up and manage those clients in their own site if the group of clients is well-connected.

Number of Resources

If there are more resources than can be supported by a single site using the SMS features you have chosen, consider creating additional sites.

Features Required by Users

You might have groups of users that require different SMS features. For example, if your IT administrators need remote access to servers residing in a locked room, and you want to disable the permission-required feature of remote access for just those computers, you might assign those servers to a separate site.

International Considerations

You might need to install an international version of SMS in the same hierarchy that contains an English or other localized version of SMS.

Number of Sites

If a hierarchy plan becomes large, you might need to add an additional tier of primary sites to help manage and organize the large number of sites that would otherwise report to the central site.

If, in your test lab environment, the site server response in a parent site degrades to unacceptable levels, you might consider creating additional levels in the hierarchy. The main factors to consider before adding sites in the hierarchy are server performance, the number of clients per site, and administrative issues. Remember that the more tiers you have in the hierarchy, the longer it takes for status messages to propagate up the hierarchy.

For more information, see Appendix F: "Appendix F - Capacity Planning for SMS Component Servers."

Corporate Structure

In some cases, an organization’s policies can play a role in site definition. There might be multiple system administration groups within an organization that require administration of their own resources.

Domain Structure

Your existing domain model might dictate the use of certain discovery methods, or you might choose to organize or reorganize your domain model to more closely map to your SMS architecture (although single sites can handle multiple domains).

Multilanguage Site Hierarchies

International organizations might need to implement a multilanguage hierarchy. For a list of supported SMS site server languages and the client languages supported by each server language, see Appendix D: “Using SMS in International Organizations,” in the Microsoft Systems Management Server 2003 Operations Guide. The SMS client language that is installed must be compatible with the language of the site server to which the client reports. Your hierarchy can contain any combination of SMS site server language versions.

Upgrade and Interoperability

If you plan to upgrade to SMS 2003, you must consider upgrade issues when designing your SMS 2003 hierarchy. Before upgrading, use the SMS 2003 Deployment Readiness Wizard to identify potential interoperability problems and recommend corrective actions.

For example, an SMS 2003 site cannot be attached to an SMS 2.0 site, but SMS 2.0 sites can be attached to SMS 2003 sites. Another unsupported scenario, for example, is promoting an SMS site server that is running a Windows 2000 Server family operating system to a domain controller. Because this action changes or removes local groups, SMS functionality is damaged. These are just a couple of upgrade and interoperability considerations.

For more information about using the SMS 2003 Readiness Analyzer and upgrading to SMS 2003, see Appendix H: "Appendix H - Upgrading to SMS 2003." For information about interoperability, see Chapter 6: “Understanding Interoperability with SMS 2.0” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

Domain Migration Planning

When you design your SMS sites, be aware that SMS Setup creates accounts in the domains that are appropriate at the time you run Setup. If you decide to change your domain model or change the domain that SMS servers are members of, you must make corresponding changes to some of the SMS accounts.

For information about moving SMS servers from one domain to another, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery .

Active Directory Migration Planning

You can take advantage of the simplified administration and many of the new features in SMS 2003 by migrating to Active Directory. As described throughout this book, SMS 2003 integrates with Active Directory in many ways. You can deploy SMS 2003 before, during, or after Active Directory deployment. It is not necessary to deploy Active Directory first.

If Active Directory is already deployed in your organization, review your Active Directory infrastructure when you design your SMS hierarchy. Use the information about your Active Directory environment that you gather in the preplanning phase. Meet with your Active Directory administrators to coordinate your SMS hierarchy design plans and determine if you are satisfied with the current Active Directory infrastructure.

Control over your organizational policy might be an issue in planning for SMS 2003 and a migration to Active Directory. Typically, for larger organizations, one IT group manages Active Directory, and a different group is in charge of SMS. In this case, SMS planners must negotiate with the Active Directory administrators in achieving the best possible SMS hierarchy design.

If you are upgrading from SMS 2.0 to SMS 2003, you do not necessarily need to change your hierarchy based on your new Active Directory design. Be aware of the issues and opportunities that your Active Directory migration presents to your SMS upgrade and determine from those whether you must change your SMS hierarchy design. For more information about upgrading to SMS 2003, see Appendix H: "Appendix H - Upgrading to SMS 2003."

Reviewing and Testing the Design in the Lab

When planning and refining your hierarchy and site design, periodically test your proposed design in a lab environment. Later, you will test your design in your pilot project. During these tests, you can identify and make modifications to your hierarchy.

Changes to Hierarchy Design

During the design phase it is important to understand what can later be changed in your hierarchy, after your SMS 2003 implementation. This section lists supported and unsupported post-deployment activities.

SMS 2003 does not support the following post-deployment activities:

• Changing the disk drive letter on which SMS is installed

• Moving the SMS site database from a remote location to the SMS site server

Important

You can move the SMS site database from the site server to a remote server running SQL Server, or you can move the SMS site database from one remote server to another remote server. However, after you have moved the SMS site database from the site server, you cannot move it back.

• Changing the site code

• Changing the site name

• Changing the computer name of the site server

• Changing the parent site of a secondary site 

• Moving the SMS Provider from the site server to a remote server

Note

The SMS Provider always stays where it was originally installed, either on the site server or on the computer running SQL Server. If the SMS Provider is first installed on a remote computer, and the SMS site database is later moved to a different remote computer running SQL Server, then the SMS Provider must move with it.

SMS 2003 supports the following post-deployment activities:

• Moving the SMS site database from the site server to a remote server (the SMS Provider must remain on the site server)

• Moving the SMS site database from a remote server to another remote server

For information about how to perform these moves, see the Microsoft Systems Management Server 2003 Operations Guide.

Test Lab Development

Ensure that the lab environment matches the production environment as closely as possible.

Minimum Recommended Configuration

Lab computers must meet the minimum recommended configuration for the roles they will play in the SMS site design. For example, your site servers should have the minimum system requirements listed in the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.

Standard Configurations

If you have Legacy Client and server configurations, use those configurations in the lab. To the extent that it is possible, use the same hardware, software, network, and logon scripts that are deployed in your production environment. For example, if your production environment includes computers with nearly full disks, obsolete and possibly unused software, and an assortment of network adapter cards, ensure that your lab computers have the same characteristics.

Duplicating Network Conditions

If production networks are connected by routers or slow links, be sure to duplicate those conditions in the lab. This approach ensures that design concerns can be identified and resolved in the lab rather than during deployment.

Site Design Testing

When testing your SMS design, focus on the functions and configurations important in your particular production environment. For example:

• If your design calls for many secondary sites, consider setting up your lab structure with as many secondary sites as possible.

• If you plan to use SMS for hardware and software inventory or to upgrade client operating systems, verify the procedures in your lab and in your pilot project before deploying SMS.

• Try to replicate and test the limits that you expect to encounter in your organization (for example, the slowest site server, the busiest management point, the least reliable network link, and the largest software packages).

This does not mean that you should set up a full production environment in your lab. However, you must set up a representative sample of your production environment. Plan your testing so that you can use the equipment you have to maximum advantage, and proceed in a logical and controlled manner. Start by testing features that are mission-critical to your company.

Sample Design Verification Plan

A design verification plan will help you proceed with logical and controlled testing of SMS. A staged design verification plan starts with the basics and builds with each successive phase. A sample plan for verifying your SMS design can include the following stages.

Stage 1

Analyze basic SMS functionality in a single-server environment. This approach makes it easier to identify hardware and integration issues with other management tools. It is easier to find and fix problems in the lab than in the production environment. You can complete a significant amount of the testing with a single computer running Windows 2000 Server SP2, and a laptop and desktop computer, each running Windows 2000 Professional.

Stage 2

Add additional servers, site systems, and subnets to the lab in the manner planned for deployment. Then, verify the added functionality. Configure the servers and site systems as you would configure them in production, including software and network protocols. If you have trusted domains in your production environment, set up some trusted domains in the lab. Set up accounts, logon scripts and profiles, and security as you would in your production environment.

Stage 3

Add clients and verify basic client functionality. Try to add at least one client for each platform that is used in your production environment. For example, if your company uses clients running Windows 98, Windows NT 4.0 Workstation, and Windows 2000 Professional operating systems, add at least one of each of these clients at this stage. Install and configure the clients as they would be installed and configured in your production environment.

Stage 4

Create an SMS hierarchy configured in a manner similar to your proposed SMS design. For example, if you plan to use many secondary sites reporting to a single central site, create and test at least four or five secondary sites in your lab. If you plan to create a hierarchy with many levels, create and test a similar hierarchy. If you plan to use an SMS 2.0 site in the hierarchy, create and test a similar site. Be sure that the hierarchy is created and functioning properly and then verify hierarchy-related functionality and system performance. Test over all the network link types and speeds you will actually use in your production environment. If you are using WINS, DNS, DHCP, SNA Server, or RAS, test them as you would use them in production. If you plan to use Courier Sender, test it at this stage.

If the SMS site servers are not dedicated strictly to SMS, test them with the appropriate applications running on them. Ensure that they are installed with any standardized software, such as antivirus software, used throughout your organization.

Stage 5

Perform basic scalability and capacity testing to ensure that your site design and hardware scales to meet your current and future needs. If you can create real loads in your lab environment, do so. Otherwise, simulate expected loads so you can accurately test system performance.

Ensure that your hierarchy design is well-documented in your project plan before proceeding to the deployment phase. Include a diagram of the hierarchy, site codes, server roles, and other relevant information.

Note

Be sure to document and verify the results of your tests against your project requirements. Rework your plan and resolve any major issues before proceeding to the deployment planning phase and pilot project.