Planning, Deploying, and Managing MS Windows 2000 with Systems Management Server 2.0

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: February 1, 1999

Abstract

The purpose of this paper is to show network administrators and IT managers how they can use Microsoft® Systems Management Server to plan for rolling out Microsoft Windows® 2000 in their organizations. The paper examines how planning for Active Directory can be facilitated with Systems Management Server and covers operating system deployment with Systems Management Server in general.

Overview

There are a variety of approaches to use when planning for and executing an upgrade to the Microsoft® Windows® 2000 Server and Windows 2000 Professional operating systems. Although each situation is unique, certain concepts and requirements are common to every upgrade scenario. The purpose of this guide is to illustrate how Systems Management Server 2.0 can be used to accomplish an efficient upgrade to Windows 2000. This guide will not attempt to outline the specific details of a complete Windows 2000 deployment. For detailed information on deploying Windows 2000, see the Windows 2000 Deployment Guide.

When planning an upgrade, you must understand your existing network infrastructure. You must also assess the current and future needs of your users and the physical limitations of your network environment, such as bandwidth, hardware, and geographical constraints. By taking stock of your existing network topology and envisioning your post-deployment goals, you can plan for a smooth operating system deployment.

Specifically, upgrading to Windows 2000 includes:

Choosing a domain structure
Planning sites, domains, and organizational units (OUs)
Assessing network traffic
Assessing network topology
Preparing the network and machines for upgrade

Systems Management Server and Operating System Deployment

Systems Management Server can help to gather the majority of the information you need to plan your deployment, automate certain deployment steps, and streamline deployment planning, execution, and troubleshooting.

The following table shows some of the steps involved in planning for and executing Windows 2000 deployment and how Systems Management Server can help accomplish these steps:

Deployment task	Systems Management Server feature
Gather data about the existing network topology, such as subnets, bandwidth, and existence of unwanted protocols to be removed	Network Trace, Network Monitor, Network Discovery, Reporting
Gather information about existing hardware, with the goal of determining which machines can be upgraded	Hardware inventory
Gather information about existing operating system (OS) and application software, with the goal of determining whether interim OS upgrades are needed and whether there is software in use that is not supported by the new OS	Software Inventory
Gather information about users to determine their networking needs, physical locations, logical groupings and projected OUs	Inventory
Upgrade target machines to appropriate OS Service Pack	Package, Advertisement, Remote Control
Upgrade servers to Windows 2000. Promote to Active Directory	Unattend.txt, Package, DCPROMO, Remote Control, Reporting
Upgrade workstations to Windows 2000	Software distribution
Gather data about the status of the deployment process	Systems Management Server can report on the status of deployment during the deployment process, giving you powerful monitoring capabilities and the information you need to troubleshoot potential problems

Benefits of Deploying with Systems Management Server

You can use Systems Management Server to plan and execute the centralized deployment of Windows 2000 upgrade packages to any number of geographically dispersed systems. Using Systems Management Server to drive the upgrade process offers the following benefits:

Full status reporting integrated with Windows 2000 setup allows simple monitoring and management of distributed upgrades from a central location.
Upgrades can be launched with administrative privileges to support upgrades in locked down or low rights environments.
Upgrades can be executed without a user logged on to support headless servers and off-hours OS upgrades.
Highly flexible and dynamic target evaluation offers extensive and automated control over which systems receive the upgrade package.
Extensive scheduling options support varied corporate deployment policies such as absolute mandatory, delayed mandatory, optional, and others.
Automatic load balancing between distribution points accommodates large numbers of concurrent or near-concurrent upgrades.

Systems Management Server also provides additional management features such as support for pre-Windows 2000 and mixed-OS environments, advanced software distribution capabilities, remote software and hardware inventory management, license metering, and remote diagnostics functionality.

Assumptions

Because a variety of approaches can be used when deploying Windows 2000, it is necessary to specify the environment in an example. To make this guide as useful and informative as possible, a few assumptions were made that create a customized environment.

Windows NT Server and Systems Management Server Infrastructure

The descriptions and examples in this document are based on a previously standing Windows NT® environment. A fictitious company, Main Street Market, is referred to throughout this guide to show how an organization could migrate from Windows NT 4.0 to a Windows 2000-based environment with the use of Systems Management Server 2.0. With Main Street Market, as with the rest of this guide, it is assumed that Systems Management Server is already implemented within the present infrastructure. This guide does not address the deployment of Systems Management Server but only the process of using it. For information on deploying Systems Management Server, please refer to the documentation included with Systems Management Server.

Introducing Main Street Market

Main Street Market is a national company with three major locations: corporate headquarters in Dallas and branch offices in Chicago and New York. There are smaller satellite offices around each of the three main locations. The satellite offices report into their local branch office. The company uses a Windows NT 4.0 master domain model to manage its organization. There is an account (master) domain in Dallas and resource domains in Chicago and New York. Some of the company's applications that are specific to the finance organization run on Novell NetWare servers. There are currently 1,000 users in Dallas, 500 in New York, and 200 in Chicago. The satellite offices add about another 500 users dispersed over 20 offices into the structure.

Main Street Market has deployed Systems Management Server 2.0 into its environment as part of the help desk support structure to manage hardware and software assets and provide unattended software upgrades. All servers and workstations have been identified using Network Discovery and are in the Systems Management Server database. A Systems Management Server primary site is in Dallas, and secondary sites are in Chicago and New York.

These assumptions are not limitations but merely parameters around which this guide was written. Systems Management Server is still useful if it is deployed simultaneously with Windows 2000 and it is not limited to a Windows NT environment.

Deployment Team

A deployment team has the responsibility of conducting the test deployment in an atmosphere that will represent the demands and procedures included in the actual deployment. The deployment team is divided into planning, installation, and support teams and a project leader, all of which are expanded upon in the Conducting the Test Deployment section.

Test Lab

The deployment team requires a simulated environment where it can conduct the test deployment. The planning team will decide what the conditions of the environment will be. For example, you may want a variety of configurations that will represent the actual make-up of your organization.

Deployment Process Overview

For the deployment of Windows 2000, the Systems Management Server administrator initiates the distribution of packages, the basic unit of software distribution. A package contains all of the information--command lines, schedules, configurations, etc.--relating to the Windows 2000 deployment. The information is distributed and organized within the package accordingly:

Programs: At least one program is contained within the package. Programs direct the installation of the software and any other command line that is run at each client.
Package Source Files: Files that execute the programs within the package.
Distribution Folder: The directory where the package source files are placed on the distribution points, which are shares on sites systems to which the package source files are copied. Clients access the files from the distribution points.

Packages are created at the primary site server with the Systems Management Server administrator console or by obtaining a package definition file (PDF) and using one of the wizards that guides the deployment process. After the package is created, it is distributed to the targeted collection of machines. The clients do not receive the package information directly form the server. Instead, the information is mediated from the server to the clients through two gateways: the client access point (where Windows 2000 is advertised to the clients) and the distribution point (where the clients access the source files to run the Windows 2000 installation).

First, the package source files are copied to the distribution points. Next, an advertisement of the package is made and copied to the client access point (CAP). An advertisement displays the package, its programs, the schedule of when the program is available, and the computers that it is targeting. The clients contact the CAP within their site to see if the advertisement is applicable for them. If the clients find out that they are targeted by the advertisement, then they contact the distribution point within their site to obtain the program and files associated with the package. Figure 1 outlines the software distribution process.

Figure 1: Windows 2000 Software Distribution

Before any steps can be completed the Systems Management Server's advertised programs client agent must be installed at each client in the targeted collection. Systems Management Server uses a variety of agents, installed on clients, to enable and perform the desired process, such as software distribution or hardware inventory. The advertised programs client agent enables and performs the process of distribution at the client.

Assessment of Current Infrastructure

Systems Management Server provides a number of features designed specifically to enhance the Windows 2000 deployment features and address potential problems encountered during a wide-scale OS upgrade. These features enable you to use Systems Management Server to assess the current computing infrastructure, plan for Windows 2000 sites, domain, and organizational units, upgrade existing equipment to meet the standards needed for Windows 2000 deployment, and execute the actual deployment.

Assessing the Network

The domain model in Windows 2000 is a multimaster system that allows administrators to modify objects stored in the directory on any domain controller (DC). This differs from the model in Windows NT 4.0 where changes could only be made to objects via the primary domain controller (PDC). Windows 2000 also introduces the concept of sites that allow you to co-locate workstations and servers for optimal bandwidth utilization and efficiently manage replication. Directory information is periodically replicated between DCs, which may be scheduled between sites so that you can control bandwidth utilization.

Network Discovery

The discovery process within Systems Management Server is used to gather computer and router information from the network. It is similar to the discovery process of a Simple Network Management Protocol (SNMP) management system. Network Discovery can be configured to find entities on a subnet or within a domain. It also can discover any object that is running an SNMP agent. If the network configuration contains more than one subnet, then the administrator may specify additional subnets. If the subnet addresses are not known, then all subnets within the specified hop count will be added to the list the first time a discovery is run.

Each entity identified by the discovery process is added to the Systems Management Server database. Routers and computers are identified by their role, such as router, domain controller, member server, and so forth. Systems Management Server identifies the operating system, if applicable, and the Internet protocol (IP) address and subnet mask of each entity. A report can be created from this information to develop a map of the network that identifies all subnets, machines on each subnet, and connectivity between subnets. Figure 2 shows the network discovery possibilities of identifying all users within a collection of Systems Management Server.

Figure 2: Network Discovery

All systems within Main Street Market have been discovered and are in the Systems Management Server database. Microsoft Windows NT 4.0 Workstation, Windows 95, and Windows 98-based clients have been identified. The default collections in Systems Management Server facilitate the process of determining client systems. All Windows NT 4.0 servers and Novell NetWare servers have also been identified. Because the Network Discovery process will find all subnets within the network, all routers have been identified and stored in the database. This discovery enables you to easily measure traffic using the processes discussed in the next section.

Network Trace

Network Trace shows you a schematic of any site in your site hierarchy, including all the computers filling server-side roles and any routers. Network Trace uses information in the discovery database to identify resources such as routers by their IP addresses and other discoverable attributes. The schematic shows clearly which, if any, of these computers and routers are off-line or unavailable due to broken connection. You can show or hide the roles played by computers in the schematic. Figure 3 is an example of a network trace map.

Figure 3: Network Trace

Using Network Monitor

You can use Network Monitor within Systems Management Server to determine current network bandwidth utilization. Network Monitor is a tool that lets you analyze local and remote network traffic and determine existing protocols. A collection agent is needed on each subnet to capture traffic and relay this information to the management station running the network monitor. Assuming that at least one Systems Management Server server already exists on each subnet, that machine can become the collection agent. If no Systems Management Server server is available, then any Windows NT Server or Windows NT Workstation can perform the task by installing the Network Monitor Agent.

Network Monitor can run on each subnet that is identified using Network Discovery. The resulting information begins to paint a picture of current network activity. Network traffic that crosses subnet boundaries can also be captured to determine how frequently service requests are going across a router, especially if your goal is to keep the majority of network traffic local and to minimize router hops for a request. Figure 4 shows an example of Network Monitor.

Figure 4: Network Monitor

The information gathered by Network Monitor should be charted by subnet over at least a 24-hour period to determine the current bandwidth utilization. All peak activity should be captured to ensure accuracy of the information. Recurring activities, such as server backup, should be included in the information gathering, because they can negatively impact other activities using the network at the same time. Once information is gathered and charted, you should have a good understanding of bandwidth utilization patterns. This information will help pinpoint any existing trouble spots and remove bottlenecks as you move to Windows 2000.

Removing Unwanted Protocols

The Windows 2000 Active Directory is dependent on the TCP/IP protocol. Part of the planning process for moving to Windows 2000 and the Active Directory will be to remove any unwanted protocols from the networking environment. The information that is gathered from the network monitor helps determine the protocols running on machines. Once identified, these machines can be targeted for conversion to TCP/IP. If they are currently running TCP/IP, then other protocols can be removed from these machines. This consolidation of transport protocols simplifies network management. Routing information through the network is faster, and translating packets between different transports uses less network bandwidth.

Main Street Market identified IPX/SPX on certain subnets in Dallas and Chicago because finance users need to access Novell NetWare servers running financial applications in those locations. NetBEUI was also identified in New York and Chicago. This was running between some users that had set up a peer-to-peer network. The central IS people decided to eliminate NetBEUI from those workstations and to run TCP/IP on the Novell servers to reduce the complexity of the network.

Using Network Monitor to Expose Saturation and Bottlenecks

Part of the process of implementing Windows 2000 is to consolidate the existing Windows NT 4.0 domain structure and simplify the networking environment. The Network Monitor experts that come as part of the Network Monitor can help determine server and network bottlenecks, and help to eliminate them prior to the migration to Windows 2000. The following table shows some of the experts that will be useful to Main Street Market.

Task	Expert
Determine average server response time for servers on a network subnet.	Average Server Response Time expert
Determine the top senders and receivers.	Top Users expert
Determine protocols on the network and helps identify those to remove.	Protocol Distribution expert

The Average Server Response Time expert calculates the average server response time for servers on a network subnet. Creating a baseline of server response time and comparing it to historical data is useful for quantifying server responsiveness under different conditions and for planning server configurations.

The Top Users expert will tell you which servers and workstations are utilizing the most bandwidth on the network. This information will enable you to consolidate or eliminate infrequently accessed systems and better balance the load on over worked systems.

The Protocol Distribution expert calculates statistics about the distribution of protocols found in frames in a capture file. This information can be used to determine which protocols are consuming network bandwidth.

Hardware Inventory

An accurate hardware inventory of existing hardware and software is needed prior to upgrading to Windows 2000.

Determining Existing Hardware

Hardware inventory can be gathered once a system is discovered by Systems Management Server and is in the Systems Management Server database. Depending on the OS involved, you have different mechanisms to gather this inventory. If an existing server is running Windows NT, then an intelligent inventory agent is installed and gathers information at predetermined intervals. If the system is Windows NT Workstation, Windows 98, Windows 95, or Windows 3.x, a logon script-initiated inventory process gathers the information.

The most important data that is gathered through the hardware inventory process includes processor, memory, BIOS, and hard disk information. These are the key computer components that will help determine if your machine is capable of running Windows 2000. Queries and reports that ship with Systems Management Server can help categorize systems. For example, one query will determine all machines with 32 MB or more of RAM. Reports generated from this information can be used for planning upgrades. Figure 5 is an example of Systems Management Server's ability to identify hardware configuration on a client.

Figure 5: Resource Explore: Hardware

Meeting Windows 2000 Hardware Requirements

Windows 2000-based servers have recommended hardware configurations depending on their planned functionality. DCs should have a minimum of 64 MB of RAM (128 MB recommended) because these machines authenticate users and keep a copy of the directory. File, print, and application servers require different amounts of memory. Once hardware inventory information is in the Systems Management Server database, a report can be run and checked against the Windows 2000 hardware compatibility list (HCL) to ensure that existing hardware meets Windows 2000 requirements.

Note: Windows 2000 system requirements are subject to change. Refer to the final Windows 2000 documentation for system requirements.

Determining Upgrade Needs

Once system hardware has been checked against established standards and the Windows 2000 HCL, systems not meeting these standards can be targeted for upgrades. Certain systems may not warrant an upgrade; replacing the workstation or server may be required. For example, if a machine has a BIOS that is not Year 2000 compliant and cannot be upgraded, it should be replaced before upgrading to Windows 2000.

The report in Figure 6, which represents Dallas, shows that most of Main Street Market's clients and servers meet the requirements for Windows 2000. STREET-DC-02 meets the minimum memory requirements for a DC, but the memory will be upgraded to the recommended 128 MB.Numerous Windows 95-based machines are targeted for upgrade to Windows 2000 Professional and will have more memory added to them to meet the growing application needs of the company.

Figure 6: Crystal Report: HCL Comparison

Software Inventory

An accurate software inventory of existing servers and client workstations is needed prior to upgrading to Windows 2000. It is critical to know what operating system and application software is running as you plan your Windows 2000 deployment.

Determining Installed Operating Systems

The Systems Management Server discovery process captures the operating system and version number for each machine and stores that information in the Systems Management Server database. Queries can then be run on the database to create reports categorizing the different systems by operating system. These systems will be targeted for different upgrade packages depending on their configuration. The criteria that define the queries can then be used to define collections later on in the process.

The operating systems can also be identified through the use of Crystal Reports in Systems Management Server. The queries developed in the previous section are used to develop reports. You can generate and view reports from within the Systems Management Server Administrator Console. The reports access the data directly from the Systems Management Server database and are created automatically by the Crystal Reports engine. This facilitates management because reports are continuously created and can be viewed as needed. Several reports are included in Systems Management Server, but you can also create new ones.

Main Street Market generated a report that showed all discovered systems by name, NT domain, and subnet. They saved this report as an HTML file and placed it on their Intranet so the IT administrators and deployment planning team could see this information easily. Because this information can be updated automatically, the company can ensure accuracy and timeliness for making decisions. Figure 7 shows an example of this report as viewed through a browser.

Figure 7: Crystal Report: Installed Operating Systems

Determining Windows NT Service Packs

Each version of Windows NT will have minimum recommendations for service packs prior to upgrading to Windows 2000. The Systems Management Server software inventory process determines which service pack is running on the system. Windows NT 4.0 systems should be upgraded to Service Pack 4 prior to upgrading to Windows 2000. Windows NT 3.51 should have Service Pack 5. Windows NT 3.5 cannot be upgraded directly to Windows 2000. It should be upgraded to Windows NT 3.51 or 4.0 before upgrading to Windows 2000.

Determining Software Incompatible with Windows 2000

Applications designed to run on Windows NT 4.0 should upgrade to Windows 2000 with few or no changes. The major applications that are affected are anti-virus and system utility applications, such as disk defragmentation programs. DOS-based applications and non-32 bit applications may need to be tested before upgrading to Windows 2000. The Systems Management Server software inventory process will gather information on installed applications. A query and report can be run to categorize all applications and identify which are compatible with Windows 2000.

Figure 8: Crystal Report: Installed Software

Main Street Market has determined that many clients are running non-standard applications. Some clients in Dallas, New York, and Chicago are still running 16-bit word processing and spreadsheet programs; these applications will need to be tested to ensure they work with Windows 2000. The company's anti-virus software will need to upgrade to a Windows 2000-compatible package. This software will be removed prior to upgrading to Windows 2000. The new software will be installed following the successful upgrade.

Cleaning Up the Environment

Applications that are incompatible with Windows 2000 should be deleted, modified, or upgraded. Cleaning up the applications environment in this manner presents a good opportunity for you to standardize on applications that are widely used, such as Microsoft Office. By removing incompatible and infrequently used applications, the upgrade will go more smoothly and the resulting environment will be easier to support and manage. Unwanted utilities and other programs that users load from the Internet or home should also be deleted. Many of these applications can contain viruses or cause other problems within an organization. Identifying and eliminating these is crucial to ensuring a smooth migration to Windows 2000.

Main Street Market determined from its software inventory that users in Chicago were running a very old version of an accounting package. This package will be targeted for upgrade to the latest version prior to the Windows 2000 deployment. They also found legacy applications on servers that are no longer used. These will be deleted prior to the upgrades. A large number of extraneous program components were discovered on many client systems. These were mainly DLLs and other files left behind when applications were removed. Cleanup packages will be targeted at these systems to ensure a clean environment prior to upgrade.

Leveraging Windows 2000 Deployment Tools

Remote OS Installation and IntelliMirror™ management technologies are important change and configuration management features included in Microsoft Windows 2000 that complement the distribution tools in Systems Management Server. Remote OS Installation allows systems administrators to use network boot technology and server-based distribution software to install local copies of the Windows 2000 operating system on personal computers throughout the enterprise. Once Windows 2000 is operational on a PC, IntelliMirror enables network administrators to provide policy-based management of users Windows 2000-based desktops, including data, settings, and software.

Main Street Market will deploy some new Windows 2000 Professional systems during the deployment. Systems Management Server will deliver the Windows 2000 Professional images to select distribution points throughout the company. As these machines are deployed to users desktops, technicians will install the operating system from the Systems Management Server distribution points. This ensures consistency and load balancing throughout the company as the new systems are deployed.

Windows NT 4.0 / 2000 Coexistence

To make the process of migration as smooth as possible, Windows 2000 can coexist with Windows NT 4.0. If an organization is currently using Windows NT 4.0 as a server OS, they can run a mixed migration. For example, you could choose to upgrade your PDCs to Windows 2000, but continue to run your backup DCs on Windows NT 4.0 until you are comfortable with a complete migration.

The Windows 2000 Active Directory is designed to operate in a mixed environment. A mixed domain, with both Windows 2000 and previous versions of Windows NT 3.5x and 4.0 DCs, works and acts like a Windows NT 4.0 domain. You can run both Windows NT 4.0 and Windows 2000 Server simultaneously. Coexistence provides a smooth transition from both a previous Windows NT and a non-Windows NT environment. The upgrade process from previous versions of the servers to the Active Directory can take place one DC at a time. First, upgrade the PDC to Windows 2000 Server and the Active Directory. The new DC populates the Active Directory from the Windows NT Server 4.0 domain directory during the upgrade. The existing, previous versions of Windows NT 3.5x and 4.0 DCs continue to operate as before, unaware of the new changes. After each DC is upgraded to Windows 2000 Server, the domain will become a pure Windows 2000 and Active Directory environment.

Systems Management Server Collections

Collections are a set of resources such as workstations and servers that are grouped in a logical order rather than a site order. Collections gather resources according to user-defined criteria and provide a manageable view into the Systems Management Server database by partitioning the data into useful categories. You can define and populate collections by setting membership rules. These are criteria that Systems Management Server uses to determine if a resource is a member of a particular collection. Membership rules are based on one of the following:

Query
A specific Resource or Group

After you define the membership rules, you can use them as a target for software distribution and other management tasks. A resource can belong to multiple collections. You do not need to wait until resources are discovered to create collections. Rules for collections can be defined at any time.

Systems Management Server periodically evaluates resources against the membership rules. As clients are inventoried, Systems Management Server includes them in any collection whose rules they satisfy. If you define collections with query-based membership rules, Systems Management Server updates the list of resources included in a collection by using the latest information in the site database. Systems Management Server updates the list of resources on demand, or you can schedule collection evaluations.

Main Street Market will create collections of systems that will help the transition to organizational units (OUs) within the Active Directory. Members of all the finance groups within the company and their machines will be part of a Finance collection. As the environment is moved to Windows 2000 and the Active Directory, this collection will simplify migration to a new Finance OU.

Determine Targeted Collection

Systems Management Server requires a specified collection of machines that it will target for upgrade. The targeted collection comprises a variety of machines, including the existing configurations that need to be upgraded and the potentially new clients. These machines are identified from information gathered by the software and hardware inventories and the "Windows 2000 Capable Query." The inventories and query determine the compatibility of existing machines with Windows 2000 and identify the need for any new clients. After reviewing the inventory and query results, you can create a targeted collection and decide which machines will take priority in the migration process due to the tasks they perform in the network, such as web-based transactions or centralized administrative duties.

Windows 2000 Server and Professional System Requirements

The results of the hardware and software inventories are compared with the system requirements for Windows 2000. The machines that do not meet the requirements can be targeted for upgrade with the Systems Management Server. The Windows 2000 minimum processor requirements are a 32-bit Intel-based, such as a Pentium-compatible 166 MHz or higher, or a 200 MHz Alpha processor. Older 486-based systems are supported but not recommended. Hard disk requirements are a minimum of 300 MB of free disk space for Windows 2000 Professional and 500 MB of free disk space for Windows 2000 Server. Minimum recommended memory requirements are 32 MB for Windows 2000 Professional and 64 MB for Windows 2000 Server.

Creating a Test Query

One way to find configurations that will be migrated is to create a "Windows 2000 Capable" query. The goal of a "Windows 2000 Capable" query is to help identify the computers that are already capable of running Windows 2000. The machines that meet the requirements become a part of the targeted machine group.

Because this criteria for the target machine group is a combination of several elements and the basic built-in queries provided by Systems Management Server 2.0 cannot be merged, a new query must be generated. The easiest way to produce the query is to use the Query Statement Properties dialog box. This menu of choices can quickly formulate the desired queries in an easy to read format. The "Windows 2000 Capable" query for the server OS would be as follows:

 [
System Resource.OperatingSystemNameandVersion is like '% NT % 4.0'
OR
System Resource.OperatingSystemNameandVersion is like '% NT % 3.5%'
]
AND
Logical Disk.Freespace is greater than or equal to 400
AND
[
Processor.Description is like 'x86 Family 4 %'
OR
Processor.Description is like 'x86 Family 5 %'
OR
Processor.Description is like 'x86 Family 6 %'
OR
Processor.Description is like 'Alpha Family %'
]

The job of the "Windows 2000 Capable" query is to search all Windows NT computers in the Systems Management Server database that do not have Microsoft Windows 2000 Server or Professional installed and that meet the hardware requirements for upgrade. The workstation query follows the same format, but the words "client operating system" replace "server operating system." The information gathered by the queries will be used in defining the installation details when you advertise the package to install Windows 2000. All workstations that meet the criteria of the query will be targeted for the installation. Figure 9 shows the view of the query from the Systems Administrator Console.

Figure 9: "Windows 2000 Capable" Query

Planning for Active directory

Site Planning

A Windows 2000 site is defined as a collection of computers with a local affinity. By definition, a site is a collection of IP subnets or an area of high and persistent bandwidth. Subnets that have a fast and reliable network connection should be combined into one site. A network connection should be at least 512 kilobits per second (Kbps) to be considered fast. However, the available bandwidth for directory replication has to be taken into consideration. You may have a one-megabit network connection between locations. But, if certain applications already consume 80 percent of the bandwidth and the remaining 20 percent must be shared between file sharing applications and network administrative applications (such as Domain Naming Service), the bandwidth cannot be classified as a high-speed connection.

Sites and Domains

The site concept has been used by various Microsoft BackOffice® family applications to minimize replication traffic over slow wide area network (WAN) links. Unfortunately, the site concepts used in the different BackOffice applications do not match. Windows 2000 and the Active Directory directory services introduce a new site concept that is not optimized for the needs of a specific application, but uses the underlying IP network to determine locations where a good network connection is available. Systems Management Server uses the same site concept, so mapping between sites in Windows 2000 and Systems Management Server is easy.

An Active Directory site is a combination of one or more IP subnets. The administrator can define these subnets and can add subnets to a site. Sites support two features:

They optimize replication traffic over slow WAN networks.
They help clients to find domain controllers that are close to them.

Replication within a site and between sites follows different topologies. Within a site, a domain controller postpones notification of recent changes for a configurable interval. The directory store creates a default replication topology, which consists of a bi-directional ring. The directory service will always make sure that the topology is not broken and that no DC is excluded from the replication process.

Using Systems Management Server to Plan Windows 2000 Sites

The Systems Management Server site topology is similar to the Windows 2000 site topology. The Systems Management Server site affords the same benefits of bandwidth control and scheduling as a Windows 2000 site. Systems Management Server has more granular control of bandwidth utilization, because software distribution typically uses more bandwidth than Windows 2000 directory replication traffic. Clients can use site information to find domain controllers or resources that are close to them.

The Systems Management Server Network Discovery process helps determine the current subnet topology. By using the network monitor, current areas of high bandwidth connectivity are discovered that can be used as the basis for creating the Windows 2000 sites. Finding the most efficiently located DCs and resources helps to minimize network traffic over slow WAN links.

When a client starts a logon process, the first information a client receives from a DC is its site membership, the domain controller's site membership, and whether the DC is the closest to the client. If the DC is not the closest, the client can query for a DC in its own site and can then communicate with the closer DC only. Network Monitor can help analyze the existing logon process in the Windows NT 4.0 domain in order to determine which controllers are processing the logon requests. As you plan your Windows 2000 site topology, this information helps determine where to place DCs in order to limit WAN traffic.

Consolidating Windows NT Domains

Systems Management Server can use a TCP/IP subnet as the basis for creating a Systems Management Server site. This works well with Windows 2000 because the Windows 2000 Active Directory structure is based on IP subnets, enabling a better mapping of the Systems Management Server environment to the Windows 2000 directory structure.

Simplification of Domain Models

The combination of the Active Directory and the improved security model enables you to reduce the number of domains in the enterprise. Through the Network Discovery process, and the means to upgrade to the new Windows 2000 infrastructure, Systems Management Server can facilitate consolidating domains by providing a map of the current infrastructure. The primary reason for choosing a master domain model is to allow local staff to administer local resources without granting these users administrative rights to user accounts in the master domain. This enables centralized control of users and local control of access to resources.

The origin of many multiple master domains can be found in the limitations of Windows NT DCs. Within a Windows NT 4.0 environment, a domain was deployed based on security boundaries and the limitations of the directory to hold approximately 40,000 objects, which is insufficient for many larger companies. An organization had to create additional account or master domains and establish trusts between these master domains to accommodate greater than 40,000 objects. With Windows 2000, a domain is deployed using the security boundary as a criterion but is no longer bound by the 40,000-object limitation. Testing has proven that the active directory in a Windows 2000 domain can contain over a million objects, thereby removing, for all practical purposes, capacity as a design criterion. The former domain structure can be reestablished within a single domain using an OU hierarchy. You can use the upgrade to the Active Directory to reduce the number of domains and thus simplify network administration and network structure.

Using Systems Management Server to Plan Organizational Units

You can use the advanced discovery features of Systems Management Server to create collections of machines that will map into Windows 2000 domains and OUs. A Systems Management Server collection is a group of machines that satisfy one or more criteria. As systems are inventoried into the Systems Management Server database, they can be put into collections that match the criteria for creating an OU within the Active Directory in Windows 2000.

Characteristics of a Windows 2000 Domain

In Windows 2000, a domain is a partition of the namespace where a common security policy applies. A domain's security policy defines password length, password history, the lifetime of logon tickets, account lockouts, and so forth. When a user account is created in a domain it is given a security identifier (SID). A portion of the SID always contains an identifier of the domain where the SID was originally issued. This makes it easy to find out which domain contains a user or group and to determine whether to grant access to resources.

Characteristics of an Organizational Unit

An OU is a container that can host other objects. A Windows 2000 OU is a container that holds objects, such as users, groups, printers, or other OUs. OUs can be used for delegating administrative rights. The permission to create objects within an OU and change attributes on these objects can be assigned to specific users and groups, resulting in an improved granularity of administration.

Using Systems Management Server to Map Organizational Units

Figure 10: Mapping an Organizational Unit

For example, an OU may be created for the Finance group. A Systems Management Server collection named Finance can be created and all machines that belong to users in the Finance group will become part of it.

As a result, the Systems Management Server hierarchy resembles the Windows 2000 directory structure that will exist after deployment is complete. Because collection updates are automatic as new machines enter the hierarchy, they automatically become part of the collection. Figure 11 is an example of the criteria for the Finance collection.

Figure 11: Criteria for the Finance Collection

Upgrading from Windows NT 4.0 Domains

All domains can easily be upgraded to the Active Directory. Depending on the organizational structure, the flexibility of the Active Directory allows you to create a new topology for your domain or to enhance the centralized or decentralized nature of your current structure.

Single Domain Model

The single domain model is easily upgraded to a Windows 2000 domain. In a Windows NT 4.0 topology one primary domain holds the master copy of the Security Account Manager (SAM) database. In this architecture, all user accounts, machine accounts, and resource definitions use security principle definitions from the SAM database on the PDC. By definition, only one copy of the SAM database can be modified at any given time, and the database is owned by the PDC.

With Windows 2000, a single Windows NT 4.0 domain usually becomes a single domain within the Active Directory. Many of the new features, such as an OU hierarchy and delegation of administrative rights can be used to better arrange and administer the single domain. The users and resources are consolidated into a hierarchical OU namespace, which can result in a much clearer representation of the actual business structure reflected in the domain.

Master Domain Model

A master domain model's upgrade typically happens in a top-down manner, where the master domain is the first domain to be upgraded and the resource domains are upgraded later and joined in a tree or forest. Depending on whether the company is centralized or decentralized, you may find that your entire organization now easily fits into one domain. You can use OUs to mirror the old master domain structure.

Resources from second-tier domains can be moved from the former resource domains to the new domain. This approach is effective if you want to upgrade from several domains to a single domain and dissolve the resource domains into OUs in the master domain, resulting in both a more centralized control for the administrators and a finer granular control of administrative delegation while having fewer domains to manage.

In this model, Systems Management Server is used in the following manner:

Systems Management Server discovery has identified all machines, subnets and users in the organization.
Collections are created to map machines into the OUs that are created as Windows 2000 and the Active Directory are implemented.
Users are grouped into Systems Management Server collections and can easily be mapped into user OUs in the Active Directory.

Another approach is to use the flexibility of domain trees by retaining the resource domains and moving the user accounts to the domains where they really belong. This results in a more decentralized topology and allows people and groups to work independently.

Multiple Master Domain Model

For businesses that need a Multiple Master Domain, two deployment approaches are appropriate. The first approach is to build a single domain tree. For this structure, the business units must decide on one root domain and who will own that root domain. The individual business units can be implemented as different domains on the nested lower levels of the tree. Because all systems are in the Systems Management Server database, upgrading becomes an easy task. Software distribution can target machines by collection to upgrade to Windows 2000. Each collection consists of machines in the proposed Windows 2000 domains.

Another approach is to build a forest of sub-trees by creating a domain tree for each master domain. The sub-trees are allowed to maintain a common schema, a common global catalog, and the transitive trust relationship so that users can still access resources from all over the domain tree. In this case, a Systems Management Server collection is created for each proposed domain and appropriate machines are put into them. The collections can be upgraded as each sub-tree is built.

Complete Trust Domain

The independence of a complete trust domain can be retained when upgrading from Windows NT 4.0 to the Active Directory. The organization can introduce some centralization and build one tree, or retain decentralization and build a forest that consists of several trees. Both cases result in a flat structure. However, with Windows 2000 the management of trust relationships will be much easier and more scalable.

The Systems Management Server hierarchy that is already established within a complete trust model mirrors the eventual Windows 2000 active directory tree structure and can be retained. Existing Windows NT 4.0 domains are upgraded to Windows 2000 domains using software distribution. A software package to convert new Windows 2000-based servers into domain controllers can be developed and deployed to ensure that a single tree or forest is created. An answer file (unattend.txt) can be used with the DCPROMO command after an installation of Windows 2000 that contains the correct entries to create or join a new forest, tree or domain. An example of part of the section in the unattend.txt that applies is below:

 [DCInstall]
 ReplicaorMember = Replica
 ReplicaOrNewDomain = Replica
 TreeOrChild = Child
 CreateOrJoin = Join
 ReplicaDomainDNSName = streetmarket.com

Conducting the Test Deployment

The test deployment of Windows 2000 occurs in two phases: within a lab and within a pilot group. Both phases incorporate all of the steps necessary to execute the deployment at large. It is necessary to prepare and plan for an organized testing environment to ensure that the transition from testing to actual execution is as smooth as possible. The following section gives a brief overview of the deployment process and the steps involved in beginning, following through, and completing the test deployment.

Overview of the Deployment Process

The following is an outline of the test deployment process. Each of these points is expanded on in the remainder of this section. To use Systems Management Server 2.0 to deploy Windows 2000 upgrades in a test environment:

Plan for the test deployment. Create a planning team, project leader, installation, and support teams, and a collection of pilot resources to test.
Determine the preferred machine configurations specific to your organization.
Create and test an unattended installation of Windows 2000 that is independent of Systems Management Server to ensure the compatibility of your machines with the product.
Build and test the Windows 2000 upgrade methods required by your organization that will be distributed by Systems Management Server.
Prepare the Windows 2000 source files by copying them to a location accessible by the Systems Management Server Service Account. Include any required migration DLLs or other customized setup components.
Create packages for Windows 2000 Professional and Windows 2000 Server using the supplied PDFs. If necessary, create or modify programs to facilitate options specific to your organization's upgrade methods.
Specify the distribution points the package should be copied to. The copy process will begin as the configured schedule allows, as soon as the distribution point is specified for the package, subject to any inter-site address/package priority settings
Initiate the distribution by creating an advertisement for the Windows 2000 package / program to the pilot collection. To make execution of the advertisement mandatory, add an assignment to the advertisement. You can also specify advertise after and expires after dates and times to control the availability of the distribution if desired.
If assigned, the advertisement can be executed regardless of user logon status (clients running Windows NT only). If you do not create an assignment, users must select the advertisement for execution by accessing the Advertised Programs Wizard in the Control Panel. The advertisement can be executed without requiring the user to have administrative privileges.
Status of the advertisement, including the number of advertisement receipts, executions, successes, and failures can be viewed in the Advertisement Status Summarizer. Additional status information is available in the Status Message Viewer.
Run any test suites necessary to verify functionality of the upgraded machines.
To expand beyond pilot testing, create advertisements for the Windows 2000 package to one or more collections with appropriate membership criteria to receive the upgrade package. The "Windows NT 4.0 Workstations" collection is supplied by default and will contain all systems in the site running Windows NT 4.0 Workstation. If necessary, specify additional distribution points for the package to increase availability or balance load.

Assembling the Deployment Team

Once you are familiar with Windows 2000, you need to assemble a planning team and provide them with the tools and the authority that they need to do the job. Then the team can begin the work of planning the deployment process and can assemble the resources needed to carry out that the plan. A deployment team is critical to any deployment, whether you will use software management tools or perform the deployment manually.

Most Systems Management Server projects can be split into two major efforts: the Systems Management Server infrastructure and the package creation for software distribution. Both parts of a Systems Management Server project require very different skills that are not normally found in one resource.

The personnel who work on the Systems Management Server infrastructure must be expert with all relevant server operating systems such as Windows NT Server and Novell NetWare. The personnel who work on the Systems Management Server infrastructure will also need networking skills, system administration skills, and other server skills relevant to the organization. Personnel who work on Windows 2000 package creation must be expert with all relevant server and client operating systems such as Windows NT 4.0 Server and Workstation, Windows 98, Windows 95, Windows 3.x, and Macintosh. These staff members must also be expert with client applications and the use of package creation tools.

Because of this breakdown, most Systems Management Server projects will require at least two dedicated resources and, depending on the size of your organization and project, perhaps more of both types of resources.

Composition of the Planning Team

The planning team should include representatives from a variety of units in the organization. Depending on the nature of your organization, you will probably want to include people from the following areas:

Corporate Management
Information Systems Management
Corporate System Architecture Planning (for technical leadership)
Technical Staff (LAN administrator, WAN administrator, and database administrator for the SQL Server™)
Line-of-Business Management
End-User Community

Project Leader

The choice of project leader is critical to the success of the entire effort. Select an individual with a good mix of management, organizational, and technical skills who has the authority to complete the project in a timely manner. Your organization might choose a Microsoft Solution Provider to serve as project leader because Solution Providers are familiar with the products and processes.

Assemble Installation and Support Teams

The installation and support teams will be used in testing as well as during the production rollout. The assigned staff must have the skills to handle the new features of Windows 2000 and the technical requirements of the Systems Management Server environment. Try to include individuals in these teams who can represent the end user's perspective, whether they are technical staff or end users with the necessary skill set. A successful deployment of Windows 2000 requires constant attention to the end user's perspective on the process and the final desktop environment.

Setting Up a Test Lab and Pilot Resources

The planning team will conduct the test deployment for both Windows 2000 Server and Professional in two phases. The first phase takes place within a test lab. A selected number and variety of machines go through a test installation. Once the lab phase is successfully completed, the second phase is to test the deployment in a pilot group within the organization.

Main Street Market set up a lab consisting of four servers (a control, application, file/print, and utility server) and three workstations (each running Windows NT 4.0 Workstation). After a successful lab test, they tested Windows 2000 Server on one of the production backup DCs and Windows 2000 Professional on the IS group within the organization.

Determining Machine Configurations

After the planning team has been assembled and educated on Windows 2000 capabilities and the variables in your organization that may affect how you deploy Windows 2000, you can decide on the preferred configuration for servers and workstations.

Determining Server Configurations

You need to define the different servers that will be upgraded to Windows 2000. This is an opportune time to consolidate functions into fewer, larger servers or to distribute functions to more, smaller servers. Much of the analysis done previously with Network Monitor to help you understand network bandwidth and any saturation points or bottlenecks will help you make these decisions. Configure any test servers as they would be configured in your production environment. This includes software, hardware, and networking configuration settings. For instance, if your production environment includes computers with nearly full disks, obsolete and possibly unused software, and an assortment of network adapter cards, your test computers should have these characteristics too. The selected configuration and any modifications will be tested rigorously in your lab before company-wide implementation.

Determine a minimum hardware configuration for running Windows 2000 Server. Most server configurations can be categorized under one of the following types:

Control: These are domain controllers, global catalog servers, and any other servers that have a partition of the active directory. These servers require enough memory and processor capacity to authenticate users and machines and provide the capabilities for using the Active Directory.
Application: These are application servers and are typically member servers. These servers require enough memory and processor capacity to enable users to run their applications and get good response time from the applications. They also require adequate disk space to hold the applications.
File and Print: These are used for file storage and contain print queues. These systems typically have a lot of disk space and less memory and processor capacity than application or control servers. The requirements for this type of server will vary depending on the number of users connecting to it.
Utility Server: These provide infrastructure functions, such as Dynamic Host Configuration Protocol, Domain Naming Service (DNS), or Remote Access Service. The memory and processor capacity of these servers is similar to that of a controller. They will depend on the number of users and processes requiring their services simultaneously.

Determining Workstation Configurations

You will need to define which client operating systems will migrate to Windows 2000. Try to ensure that at least one client for each platform that is used in your production environment is represented during the test deployment. For instance, Main Street Market uses clients running the Windows NT 4.0 OS. As you did with the test servers, configure the clients as they would be configured in your production environment. This includes software, hardware, and networking configuration settings.

Although you can use other methods to determine the preferred client configuration, Microsoft recommends that you start from the complete configuration, which uses all of the most powerful features of Windows 2000. You can then work backward to a configuration that may have fewer features but more closely fits your company's needs. The selected configuration and any modifications should be tested rigorously in your lab before company-wide implementation.

Determine a minimum hardware configuration for running Windows 2000 Professional and the other standard applications your organization will use. These configurations should be standardized for three different types of workers: administrative, office productivity, and power user.

Administrative Configuration: For workers who use only a few applications in their daily work. For example, they may occasionally use Microsoft Excel worksheets and Microsoft Word for writing memos. The Windows 2000 Professional configuration will be minimal.
Office Productivity Configuration: For workers who use many applications on Windows 2000. This configuration will be more robust than the administrative configuration. For example, memory capacity is twice that of the administrative configuration.
Power User Configuration: For workers who run numerous Windows 2000 Professional applications concurrently and take full advantage of the power of the OS. This configuration requires a high-end hardware configuration.

Migrating Existing Configurations

Planning for migrating existing servers and workstations is critical. You need to determine whether you need to convert existing files, macros, custom programs, or standard applications and how to train end users and administrators. Before upgrading, address the following questions:

Which existing files, macros, scripts, and custom programs will be needed in the new environment?
What, if any, extra steps are required to use the existing files, macros, and scripts in Windows 2000?
What existing applications and custom programs should be upgraded or replaced to run properly with Windows 2000?
What is the user knowledge base, and what steps need to be taken for users to be proficient in Windows 2000?

The server and workstation configurations that you have developed on paper should now be installed in the lab for testing and evaluation. You should install Windows 2000 on a test system (one existing server and workstation) in the same way that you plan to install Windows 2000 in production. This means setting up the network installation location on the server and then installing Windows 2000 on the test system server and workstation.

Main Street Market will test the process to upgrade existing Windows NT 4.0 DCs to Windows 2000 DCs and to migrate other servers and workstations.

Migrating Server Configurations

One of each type of server should be configured as seen in production. This should include a backup DC (BDC), a file and print server, an application server, and a utility server, such as a DNS server. All mission critical or important server applications should be configured as they appear in production. This is particularly important for any financial, database, and messaging-based systems. Verify any issues with running the application on Windows 2000 with the applications manufacturer.

Hardware configurations for each server type may need to be modified to ensure they accommodate Windows 2000. A faster network infrastructure may be warranted as determined by your previous analysis with Network Monitor. This may require faster network adapters in all the servers. Many of the control servers and application servers will require additional memory, processor, and disk capacity to accommodate new services, such as the Active Directory.

Main Street Market must upgrade the memory and processor capacities of their DCs because of the increased activity of the Active Directory. They will upgrade some of their mission-critical applications to take advantage of the added features of the Active Directory, thereby increasing the need for processing power. They are also using this upgrade process as an opportunity to add additional disk capacity to many of the file and print servers.

Migrating Workstation Configurations

Depending on how the test installation proceeds and the type of end users being upgraded, the configuration may need to be modified by either adding or removing selected features. For example, a power user will use many of the Windows 2000 Professional features and run many of the company's applications concurrently, whereas an administrative user may only use an occasional Microsoft Excel spreadsheet or compose a memo in Microsoft Word. Depending on the needs of each user some configurations may increase while others decrease. For example, because Main Street Market has a greater need for power users than office productivity users, the majority of users will get the power user configuration. Side-by-side evaluations of different configurations can be performed to help determine which one works best.

Determining Systems Management Server Client Access Points

At least one client access point (CAP) and distribution point must be available to the targeted collection for the advertised programs to be run successfully. The primary purpose of the CAP is to provide communication between client and server. The primary purpose of the distribution point is to store the package information. All CAPs and distribution points in the site hierarchy should be examined and adjusted prior to the distribution of Windows 2000 to ensure that they will be ready for the advertisement. Usually, when the primary site is installed, it assumes the role of the CAP and distribution point. However, other computers can assume these roles.

In the case of Main Street Market, the Dallas primary site server, the Chicago secondary site server, and the Dallas secondary site servers are not CAPs or distribution points. Separate machines assume these roles and relate back to their associated site server.

Determining Systems Management Server Distribution Points

There are two important considerations for distribution points. All clients must have fast and reliable access to at least one distribution server. When you decide on the distribution servers per site and per package, verify that each client that requires access to the package has access to a local distribution server. Distribution servers need a lot of disk space. The exact amount depends on how much software you distribute to them. Remember that the distributed packages are decompressed, and they stay on the distribution point until you remove them using the Manage Distribution Points Wizard. If you use two different configurations for Windows 2000, you may need separate Systems Management Server packages. The more common implementation is to use the same package with different installation options.

A subset of existing distribution points can be used to distribute Windows 2000. If certain servers are in local proximity to the targeted clients, use the Manage Distribution Points Wizard to target distribution to those servers. Ensure that a client can access at least two possible distribution servers to balance the load during the installation process.

Creating and Testing an Unattended Installation

The unattended test installation is independent of the Systems Management Server software distribution process, which includes package creation and distribution. The Systems Management Server Installer or other package development tool can assist in creating and testing the unattended installation. This test installation is necessary because it ensures that Windows 2000 is compatible with the targeted machines.

Systems Management Server Installer

The Systems Management Server Installer can be used to create the PDF, a script, and a compressed executable file that is distributed to distribution points, CAPs, and the clients. Systems Management Server Installer creates the package definition in the form of self-extracting executable files. These files can be added to a package and then advertised to clients. The Systems Management Server Installer can augment the standard Windows 2000 installation and setup utilities that are used to create unattended installations of the different Windows 2000 configurations. The Systems Management Server Installer can add to the Windows 2000 installation process by loading standard applications onto the system following the operating system installation.

Note: Systems Management Server Installer cannot be used to repackage a Windows 2000 installation. It can add additional features following the installation of the operating system.

Server Installation

Develop server installations for each of the different server types defined earlier. The control and utility servers will have similar installations. The controllers will require running DCPROMO following their upgrade to Windows 2000 to make them into Windows 2000 DCs. This can be done using a Systems Management Server Installer script or by running dcpromo /answer: unattend.txt (where unattend.txt is an answer file providing DCPROMO with the information to create a controller).

If you are adding additional services to the ones already in Windows NT 4.0, these should be added to the installations. The file and print and the application servers may differ in their installations. Again, the major difference will be in services added. Use the profiling tools provided with Windows 2000 or in the Windows 2000 Resource Kit to create unattended server installations.

Test the unattended installation on each of the server types to ensure they update properly. Document the process and any anomalies to ensure reproducible results.

Workstation Installation

Develop three workstation installations, one for each of the three user profiles defined above: administrative, office productivity, and power user. If the office productivity user and the power user require all of Windows 2000, you may need only two configurations. Using the profiling tools provided with Windows 2000 or in the Windows 2000 Resource Kit creates unattended client installations. You can also use the Systems Management Server Installer to create a highly customized installation process. Test the unattended installation on each of the different OS platforms defined for the different user profiles. It is highly recommended that you document all of your findings and results.

Run DCPROMO

When you upgrade a Windows NT 4.0 DC to Windows 2000, it becomes a stand-alone server. All the previous domain information is retained on the server. DCPROMO must be run on the new Windows 2000 Server to transform it into a Windows 2000 DC that participates in the Active Directory.

A Systems Management Server package can be executed after the Windows 2000 upgrade process to create a DC. The Systems Management Server Installer can create a customized package that repackages the execution of DCPROMO and answers the questions in the GUI. The Systems Management Server package could consist of running DCPROMO with an answer file (available in the Windows 2000 Resource Kit), such as the following:

dcpromo /answer: unattend.txt

Figure 12 shows an example of a DCPROMO package.

Figure 12: DCPROMO Package

Systems Management Server Software Distribution Test of Windows 2000

Systems Management Server packages contain all the files and commands you need to execute the programs in the package as well as other information, such as which distribution points provide the package source files to clients.

Creating Windows 2000 Packages

The Windows 2000 package can be created with a Distribution Wizard or manually through the Systems Management Server Administrator Console. With either process, the steps are the same. Creating a new package involves creating a Package Source Directory for package source files and determining package properties. A single package can contain several different helper files, EXEs, and INFs, which allow for multiple configuration options. The same package definition can be used again when defining different Windows 2000 installation packages.

Determining Package Properties

The following properties must be determined to create a package. In the case of Main Street Market, packages are configured from the Systems Management Server Administrator Console.

Determine identification for the package.

General information, such as name, version number, publisher, language, comments, and vendor of software—i.e., Windows 2000, V1, Microsoft, server operating system.
Determine whether the package contains definition files.

A package definition file (PDF) is a text file that contains information about package and program properties that can be imported to help create the Systems Management Server package. The information includes the command line definitions for the programs to be executed and supporting information such as package name, version, and so forth. For instance, the command lines for Windows 2000 give the user different installation options such as manual and unattended. Systems Management Server uses these information files for automated installations of software
Set up the package source directory that contains the package source files.

A package source directory must be created for package source files so these files are accessible to the Systems Management Server service account when Windows 2000 is distributed. The package source directory can be a directory on a drive or the drive itself, including a CD-ROM drive. This directory is created like any other directory.
Set up compression.

The user can determine whether Systems Management Server should create and store a compressed copy of the package source files. When a package is sent to distribution points in other Systems Management Server sites, Systems Management Server automatically compresses package source files. Usually, files distributed within the site are not compressed.
Determine how Systems Management Server stores the package sources on distribution points.

Use the Data Access tab to specify whether to access the distribution folder through the common Systems Management Server package share or to specify a custom share name for the package.
Determine whether the package source files on distribution points will need to be updated, and how often.

The Distribution Settings tab can be used to set an update schedule for your distribution points. This is useful for organizations that want to deploy the Windows 2000 Package to different users at different times and when additional features and options are added along the way.

Figure 13 shows the package as it is seen from the Systems Management Server Administrator Console.

Figure 13: Windows 2000 Package

Creating Programs

Each software distribution package requires at least one program. Programs are sets of commands that run on clients. Almost any activity can be assigned to a program. For example, a program can run batch files, distribute data files, replace system drivers, and in the case of Main Street Market install client and server operating systems.

Determining Program Properties

Different program properties are required for the different installations of Windows 2000 Server and Professional. Each of the three installations of Windows 2000 Professional will require a separate program. The program command lines will differ based on the scripting you created for each. The other criteria for the workstation packages should be the same, such as whether a reboot is required after installation.

Figure14 shows a program for Windows 2000 Professional.

Figure 14: Program Properties Dialog Box

A separate server package is needed to upgrade to Windows 2000 Server. Within the package, a different program is required for each installation as determined through previous testing. Another package and program could be created to run DCPROMO on the DCs or just an additional program within the Windows 2000 upgrade package.

Setting Up Package Source Files at Distribution Points

Clients must have access to at least one distribution point to install distributed packages. Systems Management Server copies the package to the distribution point as soon as it is specified.

If the targeted clients are running on different network operating systems, such as Windows NT and NetWare, then the Windows NT-based clients must have access to the package from a Windows NT distribution point and the NetWare clients from a NetWare distribution point.

A trust relationship may also be set up between domains, allowing the targeted clients in different domains and operating systems access to the package.

Because Main Street Market has both Windows NT Server and NetWare clients, distribution points will be established for each. Some of the NetWare servers in Chicago and Dallas will be set up as distribution points to service the NetWare clients.

Managing Distribution Points

Systems Management Server replicates package source files to the specified distribution points. You must ensure that a distribution point contains all the information that it needs to respond to the advertisement that the client received.

If the package source files referred to by the advertisement are not already on the distribution point, then Systems Management Server sends a package to that distribution point.

The Manage Distribution Points Wizard allows the administrator to:

Specify new distribution points.
Refresh existing distribution points.
Update package data on selected distribution points.
Remove package from selected distribution points.
Main Street Market decided to eventually eliminate the NetWare servers in Chicago. When the NetWare distribution points are no longer needed, they will be removed by deleting the NetWare servers in Site Systems.

Creating and Distributing Advertisements

Systems Management Server presents the program as an advertisement to make the package available to clients. The following is specified in an advertisement:

The package and program to run on the client
The target collection
The schedule of when the program is available
When or whether the program is assigned (mandatory)

Systems Management Server uses collections to determine which clients receive an advertisement for a program. Often, one collection is used as a target for a series of programs. Any new applications that are suggested as compliments to the Windows 2000 client OS can be advertised in one of the following ways:

The administrator chooses to run the program immediately.
The administrator chooses to run the program at a scheduled time.
The administrator chooses to let the user make the decision of whether to run the program and when. When the program is made available the user can run the program immediately, schedule it to run later, or allow it to run at the schedule originally assigned.
The administrator chooses to let the user run the program at the user's discretion. No assignment or schedule is set.

Main Street Market advertises the three Windows 2000 installation programs to the test clients. The clients are in their own collections to simulate an actual production installation. They are assigned to run unattended, when no one is logged onto the system. The four server installations are assigned in a similar way. All the DCs will have the DCPROMO package executed after the Windows 2000 Server upgrade is performed.

Scheduling

Each advertisement has two schedules associated with it. The first is when the package will be sent to the distribution points. The package is sent as soon as you assign a distribution point to the package. This should be done during off-hours, to simulate what you should do for the actual deployment. Do not attempt to distribute Windows 2000 during production hours, as it will negatively impact your network bandwidth. Use Network Monitor to measure the network bandwidth used during the distribution of both the Windows 2000 Professional and Server packages to distribution points.

The second schedule is when to advertise the package to the clients for installation. This should be tested in a phased approach, so as not to overburden the network and the distribution servers. Each collection can be advertised to separately to provide the phased implementation. Installation to Windows NT Workstations and Servers can occur during off-hours when no one is logged into the system.

Main Street Market will test the distribution of Windows 2000 Server and Professional packages across the WAN to Chicago and New York to measure network bandwidth utilization. Because they run centralized network backups, it is critical that they don't interfere with these backups. Server and workstation installations will be tested in Dallas and remotely in New York and Chicago to ensure they are successful.

Conditional Distribution

The target of a software distribution (a collection) can be the results of a query. A query should be developed with hardware and software prerequisites for installing and running Windows 2000. The query can ensure that the target systems meet minimal requirements, such as memory and available hard disk space, prior to distribution and installation. This helps prevent failed installations and ensures that users have adequate resources to run the applications.

The "Windows 2000 Capable" query will be used to help ensure that all systems will successfully upgrade to Windows 2000. This query ensures that at least 400 MB of free disk space are available for Windows 2000 Server and at least 300 MB of disk space are available for Windows 2000 Professional. In the case of Main Street Market, they want to upgrade only Pentium-class machines and ensure that workstations have at least 64 MB of RAM and that servers have at least 128 MB of RAM. Service pack versions are also checked with the query to ensure minimal requirements prior to upgrading.

Installing Windows 2000 on a New Machine

Systems Management Server cannot directly install Windows 2000 on a machine that does not have an existing OS. For this scenario, a technician may be deployed to each new machine as it is deployed and run an installation from a Systems Management Server distribution point using a boot floppy. The installation is run from the same distribution points as the upgrading of existing systems. This installation process may need additional scripting to ensure that the proper server or workstation type is installed.

Since many new machines are typically shipped with an OS, this installation process should format the drive to ensure that only the required image is installed on the server or workstation.

Evaluating Status

Systems Management Server can evaluate the status of software distribution. Each stage of the distribution is logged so that the test team can verify it. The status of the package indicates successful delivery to the distribution points, successful installation to the target machines, and successful upgrade to Windows 2000. During the installation of Windows 2000, the setup program writes out status management information files (MIFs) to Systems Management Server that indicate successful stages of the process.

With the completion of the test deployment, the successfully upgraded computers should be tested to ensure that the installed configuration is the one that is desired. Suggestions such as the following test the installation:

Connect to and browse through the network.
Set up a printer and test printing to local and network printers.
Open, run, and close applications on both the client computer and the server.
Shut down completely.

A Systems Management Server package containing a test script can be run to test the installation.

You should test applications that your organization is most dependent upon for operation. If problems arise, then try removing related features from the proposed configuration. Document any changes made to the original configuration.

If the preferred client configuration works as expected, you may want to conduct additional testing of the optional software features and components in Windows 2000. This testing can determine whether Windows 2000 is running optimally. For this testing, conduct side-by-side evaluations on two computers, changing individual features on each one, to determine the following:

Responsiveness and throughput
Ease of use
Stability
Compatibility
Functionality

The status of a distributed package can be viewed from the Systems Management Server Administrator Console. System Status is a comprehensive tool for viewing the status of your Systems Management Server sites and hierarchy. Figure 15 is an example of a Package Status Summary report.

Figure 15: Package Status Summary Report

Evaluating Test Results

The Windows 2000 installation process generates MIFs that tell Systems Management Server the status of the installation. This is one way to help troubleshoot a potentially failed installation.

After all the different Windows 2000 packages are delivered to all the OS platforms, review the results of each installation. If there were any problems, correct them and execute this phase of the test deployment until you get the expected results.

You should now evaluate your findings and results of the entire testing phase. If everything is checking out then you are ready to deploy. However, if you find issues that are unacceptable you may want to investigate the causes of the problem or re-evaluate the packages you are deploying so that you can meet the requirements of your testing process.

Deploying Windows 2000

Using the Systems Management Server 2.0 software distribution feature, you can simultaneously upgrade all the computers to Windows 2000-based servers and workstations in your site. With a new software installation, you can run the same virus scan utility on all the clients, or distribute a licensed application to just a small subset of your users. You can allow your users to execute any of these programs whenever they like, or you can wait to run the applications until users have logged off the network.

Systems Management Server 2.0 allows targeting to users, user groups, or clients that share any set of computer hardware or software attributes you specify. Systems Management Server resources are grouped into Systems Management Server collections. In Systems Management Server 2.0, there is improved status reporting, better performance, and optional package compression. There is an additional benefit for any user whose computer becomes a Systems Management Server client. As new clients are added to the Systems Management Server site, they not only receive notification of new distributions as they become available but also receive all existing distributions for the target collections they are in.

Now that you are familiar with the particular steps needed to deploy Windows 2000 Server and Professional, an approach for the migration at large needs to be created and addressed. Preparing for server and workstation upgrades involves:

Developing the queries that will create a target collection
Determining if new servers or workstations will be deployed.
Determining the phases of the rollout, such as which groups will be deployed when.
Training the administrators and end users.

The results from the test deployment will provide much of the information required for the actual implementation within the organization, but there are still several tasks not covered in the test that must be included in the upgrade process. Though the order and steps may vary slightly from one organization to another, the fundamental methodology remains the same.

Preparing for Server and Workstation Upgrades

As mentioned in the Conducting the Test Deployment section, queries can help to determine whether a server has sufficient hardware to allow for the OS upgrade. Because Windows 2000 Server and Workstation each have specific hardware requirements, the following criteria for a query will check for the machines that do not meet the minimum requirements:

System.SystemRole is equal to 'Server'
and
Operating System.Name is like '%NT%'
and
Memory.TotalPhysicalMemory (KBytes) is less than 64000
and
Logical Disk.FreeSpace (MBytes) is less than 500

The above query searches for Windows NT Servers. To change the scope to Workstations, replace the word in the first line from 'Servers' to 'Workstations' and change the parameters of the hardware requirements to reflect those of Windows 2000 Professional. The memory parameter should be 32 and the disk space parameter should be 300. The results of these two queries should comprise a list of the hardware upgrades necessary prior to the OS deployment.

The number of servers and workstations in the organization will determine whether the next query is required. Because Windows 2000 uses DNS as the name resolution method to access the Lightweight Directory Access Protocol (LDAP)-based Windows NT Active Directory, the NetBIOS names from Windows NT 3.x and 4.0 environments must be compatible with standard DNS names. If the number of machines is relatively small, then a query can be formulated to produce a list of all servers and workstations whose names can be checked manually. However, in larger deployments, the following query would be helpful:

System Resource.NetbiosName is like '%_%' or
System Resource.NetbiosName is like '%#%' or
System Resource.NetbiosName is like '%@%'

DNS names are not case sensitive and can contain the letters A-Z, numbers 0-9 and the hyphen symbol (-). Thus, the above query should continue with the remaining allowable characters that can be used in a NetBIOS name but not a DNS name, such as ! $ % ^ & () ~ '. Any server or workstation names that do not fit the DNS convention should be changed if possible.

Main Street Market ran both queries to determine which machines needed to be upgraded and which names required modification. A small group of workstations and a few servers in Dallas and Chicago need to have additional memory added. Some workstations in New York do not have enough disk space to accommodate the upgrade to Windows 2000 Professional. Main Street Market is standardizing on workstations with a minimum of 64 MB of RAM and 2 GB hard drives. The systems that have at least 2 GB disk drives, but do not have enough free space, will be targeted to remove files to accommodate the upgrade. Systems that do not have 2 GB drives will be upgraded.

Target Collections

Migration to Windows 2000 begins with the servers because advancing to Active Directory begins with the upgrade of the PDC. However, the next steps require more thought. The following questions will need to be addressed:

What types of organizational units are being planned?
Are there changes to the domain structures?
How much fault tolerance is required of the Active Directory and/or the Windows NT 4.0 SAM database?

There are multiple factors to consider when deciding which collections should be targeted for deployment. One of the easiest scenarios is when not all machines have the appropriate hardware. Obviously, the collection should comprise those machines that have the minimum disk space and memory. A collection of these machines can be created through the use of a query rule. Another possible application of the query rule is in the case where priority is placed on the tasks being performed by a machine. An organization can review the inventory and query results and then create a target collection in which machines, such as Web-based transaction servers or servers responsible for centralized administrative duties, are upgraded first.

Alternatively, the business model of the organization may drive the upgrade process. For example, certain individuals or user groups may be entitled to software upgrades sooner than others. Direct membership rules can be used to create a collection of these users and any resources that they use. This is the scenario for Main Street Market where the majority of the Finance group, being heavy users of the system, need to be upgraded first to take advantage of the power and new features of Windows 2000.

Deploying New Servers

New servers can easily be deployed by using the Systems Management Server scripts tested or through manual installation. The scripted installation process for new machines detailed in the Conducting the Test Deployment section can be used here. This involves accessing a distribution point for Windows 2000 Server with a boot floppy to begin the installation. Windows NT 4.0-based servers cannot be added to a domain once it has been switched from a mixed domain to a pure Active Directory domain because the PDC turns off the Windows NT 4.0 downlevel replication support after the switch has been initiated. Upgrading the server to Windows 2000 will overcome this limitation.

Deploying New Workstations

New workstations can be deployed by either using the Systems Management Server scripts or through manual installation. The specific configuration is dependent upon the demands of the end users. For example, Main Street Market divides their users into three separate groups: administrative, office productivity, and power user. The scripted installation process for new machines detailed in the Conducting the Test Deployment section can be used here. This involves accessing a distribution point for Windows 2000 Professional with a boot floppy to begin the installation for one of the three types of machines.

Rollout in Phases

The second phase of the test deployment involves launching a pilot group within the organization. It is important to conduct this phase with a cross-section of the platforms and applications being used. In the case of Main Street Market, the pilot group consisted of three workstations in the Finance department, one for each type of user. The group also contained a mixture of Line of Business and commercial applications for medium to heavy users of the system.

The results from the pilot, coupled with the data garnered from the test lab, should serve as a guide in the deployment schedule. For example, the acceptable traffic generated from the installation process is a major consideration in determining whether the deployment should take place during regular business hours. Another limiting factor is the time required to complete a workstation. Windows 2000 Professional deployments can occur with no one logged into the system, but the last of the consecutive installations should be completed prior to the return of the users.

The rollout should also take non-technical factors into consideration. The personnel required to support the new workstations should be evaluated. Usually, the service levels within the organization will provide a guide to the acceptable ratio of users to support staff. Also, the availability of training sessions for both administrators and end users of the system should be evaluated against the rollout schedule.

Train Administrators on Windows 2000

OUs that comprise the domain may require different levels of administration. As such, the administrators of the system will have varying access rights that will determine the amount of training required. Ideally, administrators should receive instruction prior to being granted access rights to their respective OUs.

Administrators should also be trained in all aspects of server, workstation, and network administration prior to Windows 2000 deployment. At a minimum the training should be provided in the following areas:

How to add, modify, and delete users and groups
How to manage file and folder access
How to navigate using Start, Find, Explorer, and Network Neighborhood
How to navigate the Active Directory
How to create printers
How to add and remove applications and services
How to monitor system and network performance

Administrators should also be trained in the basics of Systems Management Server. Most organizations will have a dedicated person or team to manage Systems Management Server, but all administrators should have an understanding of remote control and software distribution. They should also be aware of the additional services that each Windows 2000 Server will have.

Train End Users on Windows 2000

A common complaint from end users is that they receive training either too early before or too late after the system is deployed. To minimize this effect, the rollout phases determined earlier should serve as a template for scheduling user training. By conducting training as the systems are upgraded, users can immediately use the knowledge they have gained. This approach tends to decrease the number of help desk calls during and after the deployment.

Training requirements can be categorized by type of user: administrative, office productivity, and power user. Users who are upgrading from Windows NT 4.0 will require minimal training, because the user interface in Windows 2000 is similar to Windows NT 4.0. These users will only need to understand the new features. Users who have no experience with Windows NT will require more extensive training. Using the Active Directory will require the most training and initiation for most users, because this is the most comprehensive new feature in Windows 2000. At a minimum, training should be provided in the following areas:

How to logon and logoff from the system
How to navigate using Start, Find, Explorer, and Network Neighborhood
How to navigate the Active Directory
How to print
How to start a program
How to create shortcuts on the desktop
How to use Help

Although the course materials should focus on the characteristics of Windows 2000, it is advantageous to give end users some basic information about the capabilities of Systems Management Server. Providing them with an awareness of the remote control features and the automated scripts will cause less confusion when such tools are employed. Also, a brief description of the Advertised Program Manager (APM) used on the Windows 2000 clients should be explained. These Systems Management Server features can simply be described to end users as part of the new system to avoid potential complication arising from the introduction of another software package. Figure 16 shows an example of what the APM looks like on the client.

Figure 16: Advertised Program Manager Wizard

Main Street Market: Sample Deployment

This section explains the step-by-step process that Main Street Market will follow to implement the Active Directory and Windows 2000 into their current infrastructure.

Mapping Systems Management Server Sites

Main Street Market has deployed Systems Management Server 2.0 into its environment as part of its help desk support structure, using it to manage hardware and software assets and provide unattended software upgrades (as previously discussed in the beginning of this document). All systems have been identified using Network Discovery and are in the primary site database. The primary site is in Dallas, and secondary sites are in Chicago and New York. Figure 17 shows the mapping of Main Street Market's Windows NT 4.0 servers and workstations onto a Systems Management Server database, where they become Systems Management Server sites.

Figure 17 Mapping Systems Management Server Sites

Proposed Upgrade Path

Figure 18 shows the current Windows NT 4.0 domain structure and the proposed upgrade from three individual domains (a master and two resource domains) to a single Windows 2000 domain. By dissolving the resource domains into OUs within the new domain, Main Street Market can mirror the old master domain structure.

Cc768065.plan18_big(en-us,TechNet.10).gif

Figure 18: The Proposed Deployment-Upgrading to a Single Domain, Dissolving Branch Offices

Each location will become a Windows 2000 site to control directory replication traffic within the domain. Even though there are T1 links between sites, a lot of network traffic already exists within the current structure. Three Systems Management Server sites were deployed to take advantage of the bandwidth control and scheduling features of Systems Management Server. The proposed Windows 2000 sites will map one-for-one to the existing Systems Management Server sites.

Upgrading the Master Domain

Before the branch offices can be dissolved into OUs, Main Street Market must upgrade the master domain to Windows 2000 and install the Active Directory on the PDC. At this stage, the master domain could join an existing active directory tree. Because Main Street Market will have only one active directory tree, the upgrade will create a new tree. The existing trust relationships are maintained after the upgrade. The downlevel resource domains still operate as Windows NT 4.0 domains with Windows NT 4.0-style trusts.

Figure 19: Upgrading the Master Domain

Because Main Street Market deployed a master domain BDC to each branch office, all the controllers are on different subnets. All the existing servers in the master domain are in the Systems Management Server database, which makes it easy to identify which subnet each machine is on. Since the PDC is the first machine upgrading to Windows 2000, the IS staff wants to upgrade it manually. This is easy to do because the PDC is physically located where the IS staff resides.

The IS staff runs a manual upgrade to the PDC by connecting to a distribution point in Dallas and executing the same script that will upgrade the other controllers. This upgrades the machine to Windows 2000 Server, but keeps it as a Windows NT 4.0-style DC. DCPROMO is now run on this machine to create a Windows 2000 DC that is running the Active Directory. The process creates a new tree structure, and IS staff defines a new NT domain as MAINSTREET.COM.

Upgrading BDCs to Windows 2000 Using Systems Management Server Software Distribution

After the PDC is successfully upgraded to Windows 2000 and the Active Directory is installed, the IS staff needs to upgrade the remaining BDCs in the master domain. One BDC is in the branch office in Chicago. That office has no local IS staff, so the IS staff at corporate headquarters will use software distribution in Systems Management Server to upgrade the BDC from Windows NT 4.0 to Windows 2000. The Windows 2000 DC installation package developed during the test deployment phase is used. This package is advertised to the Chicago BDC, and the installation runs to completion. The former Chicago BDC is now a stand-alone Windows 2000-based server.

Figure 20: Upgrading a Master Domain BDC in Chicago

The BDC in the New York branch office also needs to be upgraded to Windows 2000. The same Systems Management Server package is advertised to the BDC, but there is a problem during the upgrade. Status during the installation indicates that the upgrade failed after the first reboot stage. The IS staff decides to upgrade the New York BDC manually. They establish a remote control session with the BDC to initiate and watch the upgrade process. They start the installation from a distribution point in New York, but do not use the installation script so they can watch the process. During the upgrade, they see a message that there is a video driver that is incompatible with Windows 2000. This incompatibility is what caused the problem during the unattended upgrade. For some reason this incompatibility was not picked up during the test deployment phase. The IS staff correct the problem and advertise the Windows 2000 installation package, and the upgrade proceeds smoothly. The central IS staff informs the Windows 2000 deployment team, and the team ensures that appropriate queries exist in Systems Management Server to ensure that this video driver is detected and corrected prior to an upgrade.

The DCPROMO package developed during the test deployment is now advertised to the two former Windows NT 4.0 BDCs to make them controllers in the Active Directory. These installations are run overnight and proceed smoothly. The Active Directory is now established at all three locations.

Creating Organizational Units

Because the goal is to dissolve the branch office domains into OUs in the master domain, Main Street Market must create the OUs before the resources are moved. Initially, the users and machines in the master domain are divided into five OUs: Human Resources, Finance, R&D, Operations, and Sales. In addition, a Chicago OU and New York OU are created to manage the branch offices. The OUs create a hierarchical namespace that enables greater administrative control.

Systems Management Server can facilitate the organization of resources and the movement of those resources to the new OU structure. A Systems Management Server collection is created for each group of machines and users. The collection criteria define the machines by IP subnet and the users by group affiliation.

The new OUs can only be accessed from client or server machines that already have the Active Directory client access software installed. Downlevel clients are not aware of the existence of the OUs, and the resource domains do not notice any changes in the master domain. A Systems Management Server package can deliver the new Active Directory client access software to all the Windows NT 4.0 Workstation downlevel clients. This access enables the clients to participate in the new Active Directory structure.

Figure 21 Creating the OU Hierarchy in the Master Domain

Upgrading DCs in the Branch Office Domains

The IS staff needs to upgrade the PDCs in the branch office domains to Windows 2000 and the Active Directory. This step is mandatory if Main Street Market intends to move either servers or security information (SIDs and ACLs) from the branch office domains to the new Windows 2000 domain. Only the Active Directory supports this operation. Windows NT 4.0 did not allow the moving of objects from one domain to another because the SID includes information about the issuing domain and applications used this information to identify DCs that can resolve SIDs.

The Active Directory provides an SID tracking mechanism that allows the correct DC to be found, even if the SID has changed. The IS staff upgrades all branch office BDCs to servers. Some of these machines will become Windows 2000 DCs and some will remain stand-alone servers.

Figure 22: Upgrading Branch Office DCs

The PDCs and BDCs are upgraded to Windows 2000 using the same Systems Management Server package as the one used to upgrade the master domain BDCs. Because the upgrade of the New York BDC was problematic, the IS staff looks carefully at the hardware and software inventory of each DC to ensure that no incompatibilities exist that could prevent a successful upgrade to Windows 2000. They notice that the New York domain's PDC has the same video driver that caused earlier problems. They replace this driver, advertise the Windows 2000 upgrade package, and verify that it executed properly on each PDC. The same is done for the BDCs. The DCPROMO package is then executed on the former PDCs and on the two former BDCs in each branch office, upgrading them to Windows 2000 DCs.

Moving Servers to the Master Domain

The IS staff moves resources from the resource domains to OUs in the master domain. The servers in the resource domains are already part of the Systems Management Server collections whose names map to the new OUs. The dsmove utility is executed through a Systems Management Server package advertised to the Chicago and New York collections to move the servers into the appropriate OUs. Client applications that use Uniform Naming Convention (UNC) names to connect to the servers will continue to function properly. UNC names are not aware of the domain membership of a server, so moving them is inconsequential to client access. Here is an example of a VBScript that will move a machine named STREET-DC-01 from the HQ OU into the Chicago OU:

Set Root = GetObject("LDAP://RootDSE")

DomainName = Root.Get("defaultNamingContext")
Set Domain = GetObject("LDAP://" & DomainName)

Set Comp = GetObject("LDAP://CN=STREET-DC-01,OU=HQ," & DomainName)

Set ParentObject = Domain.GetObject("organizationalUnit","OU=Chicago")
Set tmpObject = ParentObject.MoveHere(Comp.ADSPath, Comp.Name)
ParentObject.Setinfo

A Systems Management Server collection for the Finance group was created earlier. Finance users from each of the three main locations were placed into that collection. A Systems Management Server package can be executed to run the dsmove utility to move all the users in the Finance collection to the Finance OU. The package can be advertised to the collection and executed there.

Removing the PDCs from the resource domains is premature at this point. The domain still exists and is responsible for the SIDs it issued. If a former BDC from the resource domain was moved to the master domain and a local domain group was used for access permissions, then the former BDC must contact a DC (the PDC) in the resource domain to perform the user's logon operation. The use of two-way transitive Kerberos trust between Active Directory domains allows pass-through authentication from the master domain to the resource domain.

Checking Access Control Lists

When controllers were moved to the new Windows 2000 domain, access permissions were moved with them. The global groups created in the old Windows NT 4.0 master domain are still valid. Because the member servers take the groups with them to the new domain, the local groups on member servers are still valid. The local groups used in Chicago and New York, which give access to local resources, must be moved to the new Windows 2000 domain. All of these groups appear as Windows 2000 groups in the new domain.

Moving Workstations to the Master Domain

Systems Management Server can facilitate moving the client workstations from the resource domains to the master domain. Windows NT 4.0 Workstations must be removed from the existing domains, upgraded to Windows 2000, and added to the new Windows 2000 domain. A Systems Management Server package can be advertised to the appropriate collection to execute an automated script, which performs the upgrade and domain change. An example is the Windows 2000 Professional package shown in Figure 23.

Figure 23: Program Properties Dialog Box

The [Identification] section in the unattend.txt answer file would be filled in to have the new workstations join the new Windows 2000 domain. The unattend.txt file can also put the workstations into either the New York or Chicago OU, as shown in the following example:

 [Identification]
 JoinDomain = Mainstreet
 CreateComputerAccountInDomain = Mainstreet
 MachineObjectOU= Chicago
 DomainAdmin = Administrator
 DomainAdminPassword = password

Removing Resource Domains

With all the resources moved from the resource domains to the Windows 2000 domain, the Main Street Market IS staff has successfully upgraded from Windows NT 4.0 to Windows 2000 using Systems Management Server as a facilitator. Moving the resource DCs to the Windows 2000 domain can eliminate the resource domains. Because there are only two DCs to worry about, the IS staff establishes a remote control session to each and manually moves the machine into the new domain's Active Directory. This process is faster than developing a separate script to perform the upgrade.

Assuring Backward Compatibility

Backward compatibility is a critical need for customers who have installed Windows NT Server versions 3.5x or 4.0. The Active Directory was designed from the start with built-in backward compatibility. The Active Directory provides complete emulation of the Windows NT 3.5x and 4.0 directory service. Administrative tools and applications written to the Win32® API will continue to work unmodified in Active Directory environments. A next generation Windows NT Domain Controller installed in a Windows NT 3.5x or 4.0 domain looks and acts exactly like a Windows NT 4.0 Domain Controller. This means that an investment in existing Windows NT network infrastructure and applications is protected. Customers can deploy Windows NT Server 4.0 today with complete confidence that their investment will support a smooth upgrade to the Active Directory.

Where to Go for More Information

For more information go to https://www.microsoft.com/smsmgmt.