Tài liệu Module 7: Minimizing the Impact on Network Operations During a Domain Restructure docx

&UHDWLQJ#1HZ#'16#'RPDLQV#7KDW#+RVW#WKH#659#5HVRXUFH# 5HFRUGV# If you plan to create a new DNS domain to host the SRV resource records of the Active Directory domain, your restructure pla

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2000 Microsoft Corporation All rights reserved

Microsoft, MS, Windows, Windows NT, Active Directory, and Windows 2000 are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted

Other product and company names mentioned herein may be the trademarks of their respective owners

Project Lead/Instructional Designer: Sangeeta Garg (NIIT (USA) Inc.) Lead Program Manager: Angie Fultz

Instructional Designer: Robert Deupree (S&T OnSite) Subject Matter Expert: Brian Komar (3947018 Manitoba Inc) Technical Contributors: John Pritchard, Greg Parsons, David Cross, Rodney Fournier, Tony de

Freitas, Christoph Felix, Shaun Hayes, Megan Camp, Richard Maring, Glenn Pittaway, Anne Hopkins, Bob Heath, Jeff Newfeld, Jim Glynn, Paul Thompson (Mission Critical Software, Inc.), David Stern, Lyle Curry, Steve Tate, Bill Wade (Wadeware LLC)

Testing Leads: Sid Benavente, Keith Cotton Testing Developer: Greg Stemp (S&T Onsite) Testers: Testing Testing 123

Instructional Design Consultants: Susan Greenberg, Paul Howard Instructional Design Contributor: Kathleen Norton

Graphic Artist: Kirsten Larson (S&T OnSite) Editing Manager: Lynette Skinner

Editors: Marilyn McCune (Sole Proprietor), Wendy Cleary (S&T OnSite), Jane Ellen Combelic

(S&T OnSite)

Copy Editor: Shawn Jackson (S&T Consulting) Online Program Manager: Debbi Conger Online Publications Manager: Arlo Emerson (Aditi) Online Support: Eric Brandt (S&T Onsite)

Multimedia Development: Kelly Renner (Entex) Testing Leads: Sid Benavente, Keith Cotton Testing Developer: Greg Stemp (S&T OnSite) Courseware Testing: Data Dimensions, Inc

Production Support: Lori Walker (S&T Consulting) Manufacturing Manager: Rick Terek (S&T Onsite) Manufacturing Support: Laura King (S&T Onsite) Lead Product Manager, Development Services: Bo Galford Lead Product Managers: Dean Murray, Ken Rosen Group Product Manager: Robert Stewart

# 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH# # LLL#

,QVWUXFWRU#1RWHV#

This module provides students with the ability to develop a strategy for restructuring Microsoft® Windows NT® version 4.0 domains to Microsoft Windows® 2000 domains while maintaining network reliability, security, availability, and performance

There is no lab for this module

At the end of this module, students will be able to:

„#Examine existing network services and develop a strategy for ensuring their reliability during the domain restructure

„#Plan for issues that arise due to the cloning of accounts when restructuring a Windows 2000 domain

„#Describe how the Active Directory™ Connector (ADC) allows migration of user attributes to the Active Directory directory service

0DWHULDOV#DQG#3UHSDUDWLRQ#

This section provides you with the required materials and preparation tasks that are needed to teach this module

5HTXLUHG#0DWHULDOV#

To teach this module, you need the following materials:

„#Microsoft PowerPoint® file 2010a_07.ppt

„#Module 7, “Minimizing the Impact on Network Operations During a Domain Restructure”

3UHSDUDWLRQ#7DVNV#

To prepare for this module, you should:

„#Read all of the materials for this module

„#Read all of the delivery tips

„#Read the technical white paper, Dynamic Host Configuration Protocol for Windows 2000, which is located on the Student Materials compact disc

„#Read the technical white paper, Microsoft Windows 2000 Windows Internet Service (WINS) Overview, which is located on the Student

Materials compact disc

„#Read the technical white paper, Windows 2000 DNS, which is located on the

Student Materials compact disc

„#Chapter 23, “Defining Client Administration and Configuration Standards,” will provide information on Group Policy

„#Chapter 21, “Testing Applications for Compatibility with Windows 2000,”

will support the topic of upgrade impact on applications

„#Chapter 20, “Synchronizing Active Directory with Exchange Server Directory Services,” will provide more background on using the Active Directory Connector

The following documents are also on the Student Materials compact disc and will help to further prepare you to deliver this module:

„#Microsoft Windows 2000 Market Bulletin: Active Directory™ Client Extensions for Windows 95, 98 and Windows NT® 4

„#Windows 2000 Operating System Comparison Chart

„#Deploying the Active Directory Connector

„#Knowledge Base article Q151777, "XADM: How to Move a Microsoft Exchange Server to a New Domain" (It describes how to change the service account within the Exchange Schema.)

# 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH# # Y#

0RGXOH#6WUDWHJ\#

Use the following strategy to present this module:

The previous module in this course, module 6, “Developing a Domain Restructure Strategy,” discussed the basic steps that all organizations must include in their domain restructure plan Make sure students understand that the number of additional planning steps they must add to that base plan will be dictated by the components in their current network environment

This module may prove to be the most challenging to teach because of the wide variety of topics covered and the background understanding you must have It is important that you be very familiar with each component discussed in the module, from the perspectives of both Windows NT 4.0 and Windows 2000 Be prepared to contrast the way Windows NT 4.0 handles a particular component with the way it is handled in Windows 2000

Encourage interaction during this module Ask students how they currently configure a particular network services or handle domain security Then ask them how they might ensure reliability or availability of those components given what they have learned

Students will likely have questions that relate to the topics in the module but are not directly discussed Be flexible in addressing their issues, because they have business needs for ensuring the reliability of network operations during their migration If you are unsure of the answer, turn the question over to the class and use it as an opportunity for discussion

„#Maintaining Reliability of Network Services During a Domain RestructureFor many students, network reliability will be the area of greatest concern Several of the topics in this section discuss differences in the ways that Windows NT 4.0 and Windows 2000 manage common networking services Potential pitfalls are revealed, with viable work-around solutions

Anticipate the types of questions that students will ask while you prepare for this module Although students meeting the prerequisites for this course should have an understanding of all of the topics in this module, their level

of familiarity will vary dramatically Be prepared to provide background information if students seem confused

„#Preparing for Account Migration Issues

It is critical that you clearly communicate the impact of a domain restructure

on each topic This tells students why they should care about these topics—for example, the trusts required by the migration tools make it possible for a

user to log on to either the source or target domain, possibly impacting

administrative overhead Although this may scare some students and make them wary of Windows 2000, you will earn their attention by underscoring the importance of planning

„#Leveraging Existing Directory Information This section focuses on how Microsoft Exchange directory information can

be used during migration You do not have to be an expert with Exchange

to successfully deliver this topic Focus on the three things that Exchange can provide in Active Directory and the steps that must be followed If questions on the ADC arise, point students to the white paper on their compact discs

At the end of this module, you will be able to:

„#Examine existing network services and develop a strategy for ensuring their reliability during the domain restructure

„#Plan for issues that arise due to the cloning of accounts when restructuring a Microsoft® Windows® 2000 domain

„#Describe how the Active Directory™ Connector (ADC) allows migration of user attributes to the Active Directory directory service

5# # 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#

‹

‹#0DLQWDLQLQJ#5HOLDELOLW\#RI#1HWZRUN#6HUYLFHV#'XULQJ#D# 'RPDLQ#5HVWUXFWXUH#

For many network administrators, the biggest risk during a domain restructure

is potential interruptions to network operations Because a restructure will affect numerous network services, careful planning is necessary to ensure a smooth transition Important planning issues include:

„#Examining how Domain Name System (DNS) data will be replicated in a Windows 2000 network so that you can provide reliable DNS naming services during the domain restructure

„#Establishing the need for NetBIOS name resolution so that the continued use of WINS can be evaluated after the restructure

„#Identifying normal interruptions to Dynamic Host Configuration Protocol (DHCP) Server services during the restructure process so that backup services can be planned to ensure maximum reliability

„#Maintaining LAN Manager replication functionality after Windows 2000 File Replication service (FRS) is implemented

„#Developing a strategy for planning Routing and Remote Access support during the restructuring process

„#Developing a strategy for transitioning from Windows® NT version 4.0 System Policies to Windows 2000 Group Policy

„#Planning for issues involved with user authentication when cloning accounts

If you are performing an intra-forest restructure, any DNS domains with writable zones in the source domain must be migrated to the target domain if these DNS domains will still be required after the restructuring

7KH#(IIHFW#RI#D#5HVWUXFWXUH#RQ#'16#6HUYLFHV#

If you deploy your current DNS infrastructure by using Windows NT 4.0, you must plan to immediately move the primary zones to Windows 2000 to provide support for SRV (service) resource records that are required by Active

7# # 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#

„#Configuring the Windows 2000 DNS server in the target forest as the primary DNS server for all existing zones This is accomplished by first configuring the Windows 2000 DNS server as a secondary DNS server for the existing zone After the existing zone data is transferred to the target Windows 2000 DNS server, its role can be switched to primary DNS server, and the source Windows NT 4.0 primary server must be converted to be a secondary DNS server for the zone

„#Promoting the Windows 2000 DNS server to be a domain controller for the target Active Directory domain This will cause the registration of all necessary DNS resource records into the DNS zone data

„#Changing any primary DNS zones to Active Directory integrated zones in the target forest Active Directory integrated zones will provide more fault tolerance and enable multi-master writes for the DNS zone data In addition, secure dynamic updates can be implemented to prevent Internet Protocol (IP) spoofing

&UHDWLQJ#1HZ#'16#'RPDLQV#7KDW#+RVW#WKH#659#5HVRXUFH# 5HFRUGV#

If you plan to create a new DNS domain to host the SRV resource records of the Active Directory domain, your restructure plan must include the following:

„#Installing a DNS server in the target Windows 2000 domain This DNS server will host all necessary zone resource records for Active Directory

„#Integrating Windows 2000 DNS server with the existing Windows NT 4.0 DNS servers This can involve delegating NS (name server) resource records to Windows 2000 DNS zones that are sub-domains of existing Windows NT 4.0 DNS domains In the case of separate DNS domains, this can involve either editing the root hints for the DNS implementation or creating secondary zones for the newly created domain under Windows NT 4.0 DNS

„#Moving the reverse lookup zones to the Windows 2000 DNS servers This will take advantage of multi-master replication that exists within the Windows 2000 DNS server

6HUYLFHV#

During a domain restructure, computer and user accounts are moved or cloned

to a separate forest, isolating them from the resources and services of the source domain Integrating the WINS topologies of the source and target environments will allow NetBIOS clients in the source domain to connect to resources within the target forest Likewise, migrated clients will be able to find resources within the source environment until the source WINS can be decommissioned

5HVWUXFWXULQJ#'RPDLQV#WR#6HUYH#1HW%,26#&OLHQWV#

When restructuring a Windows NT or Windows 2000 domain that serves NetBIOS clients:

„#Determine if WINS is required during a restructure Incrementally cloning

and activating accounts in the target domain potentially separates accounts from source resources WINS may be required during migration to continue

to access resources in the source environment

Performance console provides NetBIOS-related counters that can be used to determine the continued need for WINS See the section titled Providing Reliable NetBIOS Resolution Services in module 4, "Minimizing the Impact on Network Operations During an Upgrade," in course 2010A,

Designing a Microsoft Windows 2000 Migration Strategy

9# # 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#

„#If WINS is required during or after a restructure to support migrated clients, integrate the WINS topology of the source domain with that of the target domain To ensure that all accounts will have access to all resources on the network:

• Configure at least one Windows 2000 WINS server in the target domain

as a push/pull replication partner with a WINS server in the source domain This will ensure that clients in either environment can access resources across the forest boundary

• Alternatively, all Windows Internet Name Service services can be moved to the target domain This is accomplished by reconfiguring all clients in the source domain to use a WINS server in the target domain

„#Plan for the decommissioning of WINS servers in the source domain A timeline must be set to change the target DHCP servers to configure DHCP clients to register their NetBIOS names with the target domain

Windows 2000 WINS server This will cause clients to register with the Windows Internet Name Service in the target domain, rather than with a WINS server in the source domain

If clients exist on your network that are statically configured for Transmission Control Protocol/Internet Protocol (TCP/IP) configuration, the WINS server address must be manually reconfigured at each computer to point to the WINS server in the target domain

After all clients are registering with the target Windows Internet Name Service, all remaining WINS servers on the network must be configured to cease replicating with the decommissioned WINS server and the source WINS services uninstalled

1RWH#

LV#D#:LQGRZV#17#713#GRPDLQ 0LJUDWH#WKH#'+&3#VHWWLQJV#WR#D#QHZ#VHUYHU#E\#XVLQJ#WKH#

1(76+#FRPPDQG

DHCP dynamically assigns IP addresses and provides automatic network configurations to DHCP clients Both Windows NT 4.0 and Windows 2000 DHCP servers can provide services to Windows 2000 and earlier clients and servers

During the migration to Windows 2000, both the source and target domains will run on the same physical network structure DHCP services can be maintained

in the existing source domain structure or can be moved to the target Windows 2000 domain during the restructuring process

(QVXULQJ#WKDW#'+&3#6HUYLFHV#&RQWLQXH#WR#2SHUDWH#

One of the goals in migrating the source DHCP services to the target network is

to maintain the current IP reservations and to ensure that the DHCP options are not changed from their current definitions

„#Migrate DHCP services to the target domain early in the restructure This ensures that current IP address assignments are maintained It also will prevent the need to split the DHCP scope between DHCP servers in the source and target domains There are two strategies that can be used to migrate DHCP Server services to Windows 2000:

• Upgrade the existing DHCP server if the source domain is a Windows

NT 4.0 domain Upgrading the existing DHCP server will convert the DHCP database to the Windows 2000 DHCP Server service and ensure that all current DHCP options are maintained This upgrade will require that the DHCP server be authorized within Active Directory to allow the assignment of IP addresses to clients

;# # 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#

• Migrate the DHCP settings to a new server by using the NETSH command The NETSH command can export the current source DHCP settings to a text file that can in turn be imported into the target

Windows 2000 DHCP Server service

For more information about using NETSH with DHCP, see “Netshell Commands for DHCP,” in the Windows 2000 Server Help files

After the DHCP configuration information is imported into the Windows 2000 DHCP Server in the target domain, the original DHCP scopes must be disabled to prevent DHCP clients from receiving DHCP addresses from the DHCP server in the source domain

„#Determine all scope options that need to be configured if migrating from a Windows NT 4.0 source domain Windows 2000 provides additional scope options that you can configure Perform an analysis to determine whether any of the new settings must be implemented within your DHCP

configuration

1RWH#

,PSRUWDQW#

The main issue with remote access during a domain restructure occurs when Windows NT 4.0 RAS or RRAS servers are moved to join a Windows 2000 target domain Windows NT 4.0 RAS and RRAS servers use NULL sessions to determine dial-in permissions and whether any other dial-in settings, such as call-back telephone numbers, are configured for remote users By default, Active Directory does not accept object attribute queries through NULL sessions

Without proper planning, the interoperability of remote access services in a mixed environment can cause legitimate dial-in users to be denied remote network access

There are no issues with Routing and Remote Access when the restructure takes place between two Windows 2000 domains The is because the Windows 2000 Routing and Remote Access servers do not use NULL sessions

to determine dial-in rights for a remote user

43# # 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#

$OORZLQJ#18//#6HVVLRQ#$XWKHQWLFDWLRQ#

When users use their cloned accounts in the target domain, they authenticate against Active Directory rather than the Windows NT 4.0 Security Accounts Manager (SAM) database If your network contains Windows NT 4.0 RAS servers, and you want to continue providing remote access via down-level remote access servers, you must configure Active Directory to allow pre-Windows 2000 compatible group access by:

„#Setting the Active Directory permissions to be compatible with Windows 2000 Server when running the Active Directory Installation wizard

to Active Directory servers will NULL sessions to determine whether a connecting user has dial-in permissions

(QVXULQJ#WKDW#5$6#DQG#55$6#6HUYLFHV#&RQWLQXH#WR#

2SHUDWH#

To ensure that Windows NT 4.0 RAS and RRAS servers continue to function as required once their computer accounts have been moved and the member servers have been configured to join the target domain, your inter-forest restructure plan must include the following steps:

„#Determine how source remote access servers will be migrated These servers might be upgraded to Windows 2000 and join the target domain New Windows 2000 remote access servers can also be installed in the target domain, effectively replacing and allowing the decommissioning of existing servers

„#Ensure remote access authentications will be successful If Windows NT 4.0 RAS and RRAS servers are present in a Windows 2000 domain, you must set remote access permissions to allow NULL session access to Active Directory If Windows 2000 remote access servers are deployed to replace the existing ones, authentication will take place without additional

configuration

„#Remove backward compatibility permissions After all Windows NT 4.0 RAS servers have been upgraded to or substituted with Windows 2000 servers running Routing and Remote Access, you can remove the Everyone group from the membership of the Pre-Windows 2000 Compatible Access group This is because Routing and Remote Access is able to fully authenticate with Active Directory when determining whether a user has been granted dial-in permission directly or through Remote Access Policy

„#Identify any additional Remote Access Policy settings to configure When configuring dial-in permissions for remote access users, cloned users will automatically inherit dial-in permissions configured on the source account Remote Access Policies also provide additional security parameters, such as encryption-level security that must be used for all remote access

communications, which may be desired to secure remote user access

While the logon script attribute for user accounts is migrated, cloned users will not by default receive logon scripts until the script itself is made available in the target domain System policies must also be migrated to continue processing on computer accounts that have joined the target domain

To ensure that user-assigned logon scripts and system policies will be available

as cloned users begin to authenticate in the target Windows 2000 domain, the contents of the NETLOGON share must be bridged to the Windows 2000 domain

45# # 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#

,QWHJUDWLQJ#5HSOLFDWLRQ#6HUYLFHV#

If you require logon scripts and system policies to continue processing for accounts that are migrated from Windows NT 4.0 to Windows 2000, logon scripts found in the NETLOGON share on Windows NT 4.0 domain controllers must be made available to and replicated within the Windows 2000 structure

An inter-forest domain restructure plan must include the following to provide logon scripts and System Policies to migrated users and keep the files synchronized between the two replication systems:

„#Ensure that the two file replication systems are bridged The lbridge.cmd file found in the Windows 200 Resource Kit will copy the contents of a Windows 2000 domain controller NETLOGON share to the Windows NT 4.0 LAN Manager replication export server The lbridge.cmd file must be configured to allow the synchronization between the Windows 2000 FRS and the Windows NT 4.0 LAN Manager Replication service The edits that must be performed include:

a Manually entering the destination directory for the Windows NT 4.0 export server This universal naming convention (UNC) path will be the target for the copy process

b Selecting whether to use xcopy or robocopy to perform the synchronization between the FRS and LAN Manager Replication topologies

The bridge between the LAN Manager Replication service and FRS requires that an FRS system act as the master copy of the NETLOGON contents All editing to the contents must be performed in the target domain’s

NETLOGON share after the bridge has been established

Robocopy is generally preferred over xcopy because it is able to determine whether any files have been deleted from the source directory It will delete all files from the target directory when the /purge option is used

to ensure that additional scripts are not being created within the Windows

NT 4.0 topology

„#Maintain the bridge between the replication systems After you have made the edits to the command file, you must set the file to run at two-hour intervals by using the Task Scheduler service

„#Determine when to remove the bridge between replication systems The replication bridge only needs to be maintained while clients requiring logon scripts and system policies are authenticating against the Windows NT 4.0 source domains Once all clients are moved to the Windows 2000 forest and are authenticating against Windows 2000 domain controllers, the

Lbridge.cmd task can be removed from the Task Scheduler