Preplanning
Preplanning involves thoroughly examining, understanding, and documenting your computing environment and computer management objectives.
During preplanning you:
Analyze and document your current network and computing environment.
Analyze your organization’s needs and identify objectives.
Establish a test lab environment.
Assemble the team.
Begin assembling the project plan.
Learn SMS.
Note
It is important, while performing these preplanning steps, that you understand your entire planning methodology and the risks involved. For more information about understanding an overall methodology and mitigating risks, see Appendix A: "Appendix A - Understanding Methodology and Risk."
The first three steps are a particularly important part of the preplanning process and are described in the next three sections. The other three steps are described in Appendix B: "Appendix B - Preplanning Phase Steps." After you have completed this phase, you can begin your new installation of SMS 2003 or decide whether and how to upgrade an existing SMS 2.0 installation.
Analyze and Document Your Current Environment
A thorough understanding of your computing environment helps you determine the scope of your SMS implementation project. Having accurate information about your physical network infrastructure and the issues that influence your network operations is critical to many of the decisions you make as you plan your SMS deployment.
For example, network topology greatly influences the locations, types, and number of SMS site servers that are deployed.
To optimally design your SMS site and site hierarchy, it is essential that you create detailed documentation of your computing environment. Diagrams are a useful way to deal with complex concepts, such as network topology. Where appropriate, create these diagrams and include them in your project plan documentation.
Start by collecting and collating the data described in this section. For an overview of the type of data you can collect, see Table 1.1. As you examine your environment, review how SMS integrates into existing operational processes and the effect it will have on existing operational roles and responsibilities. Also, be sure to anticipate and track proposed infrastructure changes.
Table 1.1 Preplanning Data
Environment |
Data needed |
---|---|
Previous installations |
The history of your organization’s systems management solutions |
Current installations |
List of any existing software distribution, patch management, or other system management product currently in use |
Geographic profile |
Diagram of the geographic locations of your organization’s sites, including information about international operating system languages and time zones |
Organizational structure |
Diagram of the divisions or departments within your organization and their associated managing and reporting structures |
Network topology |
Diagram of your network infrastructure, including LAN and WAN architecture, physical topology, network size, bandwidth, usage, traffic patterns, network protocols, and subnets |
Client environment |
The number of clients at each location, software applications and operating systems in use (including logon scripts, if applicable), client mobility and type of network connectivity (dial-up, wireless, LAN-connected) |
Active Directory® directory services site structure |
Diagram of the forest, domains, and Active Directory sites in your Active Directory site structure, if applicable, and organizational unit information for later use in SMS operations |
Domain models |
Diagram of your organization’s Microsoft Windows NT® and Microsoft Windows® 2000 domain models and trust relationships |
Server environment |
Diagram of the locations of the core servers on your network, indicating their primary functionality and operating system version level (domain controllers, servers running Terminal Services, file servers, Web servers, DHCP, WINS, and DNS servers) |
Security |
Documentation containing your security settings, including Windows security groups, Administrator and Domain Administrator accounts, client lockdown levels, shared folder access restriction policy, account policies, account control needs, and sensitivity to security risks |
Information Technology (IT) organization |
Knowledge of your IT organization, the support areas defined for IT staff members, what the management control policies are and any policies that play a part in the success of the organization’s infrastructure projects |
As you collect this information, document it in diagrams, charts, and tables that you can later insert into the project plan. If possible, create your network and organization diagrams using an overlay method. For example, create a domain model diagram by using clear media, such as transparency paper, that can overlay a printed diagram of your network topology.
Planning Guide
You can use the Preplanning worksheets contained in the file Preplanning.xls to help collect and document this information.
Note
Because your SMS site structure can be based on both IP subnets and Active Directory sites, pay particular attention to the location and clustering of IP subnets and Active Directory sites.
Analyze Your Needs and Identify Objectives
Having a clear understanding of how you want to install and modify SMS to suit your business and technical needs is an integral part of the preplanning process.
This knowledge allows you to define the business and technical objectives to include in your project plan. For example, reducing the cost of software upgrades and simplifying hardware asset tracking are common objectives. A technical objective might be migrating from a Windows NT domain structure to a Windows 2000 domain structure or implementing Active Directory in your network environment.
It is important to understand what you need, want, and expect from SMS. A core requirement that is often stated is to distribute software, but what exactly does this mean? Which software, how often is it to be distributed, and to how many users? What size are the application files, where are the destination computers located, and are there any language-related issues? Will software package installations be optional, mandatory, or a combination of both?
The answers to these questions can have a significant impact on your design.
Identify Requirements
To establish business objectives, you must first gather specific information about your organization. This helps you determine which SMS features you want to use.
Use your organizational charts and the sample chart in Table 1.2 to create a list of requirements. It is important to make these requirements measurable because your requirements are part of the project’s deliverables and milestones. Map each requirement to the SMS feature that you will use to meet that need. Table 1.2 is meant as an example of how you can map a business need to an SMS feature. In many cases, you might not find a clear one-to-one map of a business need to a feature, and in some cases, a business need can map to many features.
Table 1.2 Examples of Mapping SMS Features to Business Needs
Business needs |
SMS 2003 features |
---|---|
Configuration management Track hardware and software assets, and collect files from client computers. |
Hardware and software inventory Reporting |
Produce and share reports on computer assets and application monitoring from any Web-based computer. |
Reporting |
Centrally administer client reporting across products that can use Active Directory. |
Active Directory discovery |
Manage site boundaries by Active Directory site names instead of (or in addition to) IP subnets. |
Active Directory site boundaries |
Release management and license compliance Deliver software to clients for automatic or user-assisted installation. |
Software distribution Reporting |
Create preconfigured, self-extracting software packages and perform unattended software installations on clients. |
SMS Installer |
Convert SMS Installer packages to Windows Installer format (.msi). |
SMS Installer |
Increase efficiency of site-to-site software package replication (conserve bandwidth in updating software packages on distribution points). |
Delta replication |
Manage laptops over slow network links, and reduce the cost of remote client operation over expensive WAN links. |
Advanced Client |
Monitor usage of software programs. |
Software metering Reporting |
Incident management Perform remote troubleshooting. |
Remote Tools Hardware and software inventory Reporting |
It is recommended that you list your requirements in order of priority. In situations where time is limited, the design effort must first focus on the essential requirements to ensure that key functionality is delivered. On time-limited projects, it is still important to be aware of lower priority issues, because a design that is based on only the essential requirements might prevent the implementation of other deliverables.
In accordance with Microsoft Solution Framework best practice, requirements must be:
Specific
Measurable
Achievable
Results-oriented
Time-specific
The metrics to measure success must be known and achievable within the allowed time, budget, and other constraints. Following this guideline assists you in establishing and tracking project milestones.
Assessing Time and Budget Allotments
When you are determining your requirements, assess the amount of money and time that can be allocated for the project.
Expenses for the project can potentially include software licensing, IT staff salaries, training costs, and hardware procurement or upgrades. Identify how much money you can afford to spend on the project before you finalize your SMS hierarchy design or hire additional staff.
Knowing when you and your team must complete the project is relevant to how much work can be accomplished. It is recommended that you not move forward with planning your SMS configuration and deployment until you establish the length of time that can be dedicated to the project.
After each phase of the project, it is a good idea to review any changes in budget and time allotments and whether these allotments are appropriate for the expected scope of the project.
Establish Test Lab Environment
Set up a test lab on an isolated network in your organization. Do not set up your test lab in your production environment, and do not install SMS on any of your production servers before you install it and work with it in your test lab. Installing SMS in a production environment without first testing it on an isolated network can cause undesirable and potentially damaging results. Later, during the deployment planning stage, you will design a pilot project for further testing. The pilot project is described in Appendix D: "Appendix D - The Pilot Project."
Note
If your test lab uses the same Active Directory forest as your production network, then do not use the same site codes in your test lab as you do in production. If you use the same site codes in both the test lab and the production network, it is possible for SMS clients in production to be incorrectly directed to SMS sites in the test lab, and for SMS clients in the test lab to be directed to SMS sites in the production environment.
Use the test lab to perform tests throughout the steps of the planning phase:
Designing the SMS hierarchy
Planning the deployment and site configuration
Planning your security strategy
Planning for backup and recovery
Also, use the lab to perform tests throughout the steps of the deployment phase:
Deploying the hierarchy
Deploying SMS clients
Maintain your lab for post-deployment testing.
Developing the Test Lab
Your test lab computers must use at least the minimum recommended configuration required for their SMS roles. The computers must contain configurations that are representative of those in your organization.
Minimum recommended configuration
Lab computers must meet the minimum recommended configuration for the roles they perform in SMS. For example, ensure that your SMS site servers and site systems have the minimum system requirements specified in the “Getting Started” chapter in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide.
Standard configurations
If your organization has standard client and server configurations, use those configurations in the lab. If it is possible, use the same hardware, software, network connectivity, and logon scripts that are used 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.
Creating a Representative Test Environment
For the test results to be useful, ensure that the lab environment reflects your production environment as closely as possible. Use the network diagram you created at the beginning of preplanning to help you create a representative test environment. Add at least one client for each client platform that you plan to support.
Include a representative of each type of site system role, server, and client that will exist in your full SMS hierarchy. Also, the network link connecting these objects should mirror the network speed and availability in production.
Your hierarchy should contain a central site and a representative number of child primary sites and secondary sites. Include desktop and mobile clients (portable computers) that are based on the standard configurations of your organization. Your test data might be distorted if you create a test environment that contains computers that have only fast processors and a lot of memory, instead of less powerful, smaller computers in the hierarchy. You can gain valuable information by analyzing how your planned SMS hierarchy functions in your network as it exists today, including outdated computers and obsolete applications.
The closer your test installation resembles your actual network design and hardware, the more valuable your results are as you plan the deployment of SMS throughout your organization. In your test lab, install all applications that are in use in the production environment so that they are available for application compatibility testing.
During testing and the pilot project, test and refine your project plan documentation regarding support and deployment. As you plan your SMS hierarchy design, you might need to add more servers or clients to your test environment, depending on your needs as the planning progresses.
Maintaining the Test Lab
After deploying SMS 2003, keep your test lab intact. Use it for future testing of SMS service pack and feature pack installations, proposed site changes, software distribution scenarios, and other SMS activities. For example, it is important that you test each software package in your test lab before you distribute it in your production environment. Continually update your test lab environment as your production environment changes. By maintaining this test lab throughout the life of SMS, you will always have an isolated SMS hierarchy for testing purposes.
Because the test lab represents your production environment, it is ideal for performing periodic recovery tests. This helps you identify shortcomings in your backup and recovery plan. For more information about preparing your test lab for recovery tests, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Maintenance, Backup, and Recovery.