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

#





&RQWHQWV##
#
2YHUYLHZ#4
#
0DLQWDLQLQJ#5HOLDELOLW\#RI#1HWZRUN#6HUYLFHV##
'XULQJ#D#'RPDLQ#5HVWUXFWXUH#5
#
3UHSDULQJ#IRU#$FFRXQW#0LJUDWLRQ#,VVXHV#4:
#
/HYHUDJLQJ#([LVWLQJ#'LUHFWRU\#,QIRUPDWLRQ##
'XULQJ#D#'RPDLQ#5HVWUXFWXUH#5;
#
5HYLHZ#63
#
#
Module 7: Minimizing
the Impact on Network
Operations During a
Domain Restructure

#

Information in this document is subject to change without notice. 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. Complying

with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

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.

3UHVHQWDWLRQ=#
93#0LQXWHV#
#
/DE=#
3#0LQXWHV#
LY##0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#

There are several chapters of the Windows 2000 Server Deployment Planning
Guide that will also help you prepare your delivery. These documents are in the
Additional Readings\Deployment Guide folder on the Student Materials
compact disc:
„# Chapter 10, “Determining Domain Migration Strategies”, will provide
information on the LAN Manager Replication service, domain security, and
user profiles.
„# 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 Restructure

For 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.

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


2YHUYLHZ#
„
0DLQWDLQLQJ#5HOLDELOLW\#RI#1HWZRUN#6HUYLFHV#'XULQJ#D#
'RPDLQ#5HVWUXFWXUH
„
3UHSDULQJ#IRU#$FFRXQW#0LJUDWLRQ#,VVXHV
„
/HYHUDJLQJ#([LVWLQJ#'LUHFWRU\#,QIRUPDWLRQ#'XULQJ#D#

'RPDLQ#5HVWUXFWXUH


One of your primary migration goals is to ensure continuous network
functionality with minimal impact on business productivity. Maintaining
network operations may require additional steps to be added to your domain-
restructuring plan.
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.

6OLGH#2EMHFWLYH#
7R#SURYLGH#DQ#RYHUYLHZ#RI#
WKH#PRGXOH#WRSLFV#DQG#
REMHFWLYHV1#
/HDG0LQ#
,Q#WKLV#PRGXOH/#\RX#ZLOO#OHDUQ#
DERXW#PLQLPL]LQJ#WKH#LPSDFW#
RI#D#GRPDLQ#UHVWUXFWXUH#RQ#
\RXU#QHWZRUN#UHOLDELOLW\/#

VHFXULW\/#DYDLODELOLW\/#DQG#
SHUIRUPDQFH1#
5# # 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#


‹‹
#0DLQWDLQLQJ#5HOLDELOLW\#RI#1HWZRUN#6HUYLFHV#'XULQJ#D#
'RPDLQ#5HVWUXFWXUH#
„
3URYLGLQJ#5HOLDEOH#'16#6HUYLFHV
„
3URYLGLQJ#5HOLDEOH#1HW%,26#5HVROXWLRQ#6HUYLFHV
„
3URYLGLQJ#5HOLDEOH#'+&3#6HUYLFHV
„
3URYLGLQJ#5HPRWH#$FFHVV#6HUYLFHV#LQ#D#0L[HG#
(QYLURQPHQW
„
6XSSRUWLQJ#/$1#0DQDJHU#5HSOLFDWLRQ
„
0LJUDWLQJ#/RJRQ#6FULSWV#WR#*URXS#3ROLF\
„
0LJUDWLQJ#6\VWHP#3ROLFLHV#WR#*URXS#3ROLF\


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
to a new forest.

6OLGH#2EMHFWLYH#
7R#GHVFULEH#D#VWUDWHJ\#IRU#
PDLQWDLQLQJ#UHOLDEOH#QHWZRUN#
VHUYLFHV#GXULQJ#D#GRPDLQ#
UHVWUXFWXUH1#
/HDG0LQ#
$#GRPDLQ#UHVWUXFWXUH#ZLOO#
DIIHFW#VHYHUDO#QHWZRUN#
VHUYLFHV1#&DUHIXO#SODQQLQJ#LV#
UHTXLUHG#WR#PDLQWDLQ#UHOLDEOH#
QHWZRUN#FRQQHFWLYLW\1#

.H\#3RLQW#
:KLOH#PDQ\#RI#WKHVH#WRSLFV#
DUH#FRYHUHG#LQ#PRGXOH#7/#
³0LQLPL]LQJ#WKH#,PSDFW#RQ#
1HWZRUN#2SHUDWLRQV#'XULQJ#
DQ#8SJUDGH/´#WKH#FRQWHQW#
IRFXVHV#RQ#SODQQLQJ#LVVXHV#
IRU#UHVWUXFWXULQJ/#DV#
RSSRVHG#WR#XSJUDGLQJ1#
# 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH##6#


3URYLGLQJ#5HOLDEOH#'16#6HUYLFHV#
„
(IIHFW#RI#D#5HVWUXFWXUH#RQ#'16#6HUYLFHV
„
0DWFK#$FWLYH#'LUHFWRU\#'RPDLQV#WR#'16#'RPDLQV
z
,QVWDOO#D#VHFRQGDU\#:LQGRZV#5333#'16#VHUYHU#LQ#WKH#WDUJHW#
GRPDLQ
z
7UDQVIHU#]RQH#ILOH#WKHQ#UHFRQILJXUH#:LQGRZV#5333#'16#DV#WKH#
SULPDU\#'16#VHUYHU
z
3URPRWH#:LQGRZV#5333#'16#VHUYHU#WR#EH#D#GRPDLQ#FRQWUROOHU#
DQG#FRQILJXUH#$FWLYH#'LUHFWRU\#LQWHJUDWHG#]RQHV#
„
&UHDWH#1HZ#'16#'RPDLQV#WR#+RVW#659#5HFRUGV
z
,QVWDOO#D#SULPDU\#:LQGRZV#5333#'16#VHUYHU#LQ#WKH#WDUJHW#GRPDLQ

z
'HOHJDWH#QHZ#VXE0GRPDLQV#RI#H[LVWLQJ#'16#GRPDLQV#WR#
:LQGRZV#5333#'16#VHUYHU
z
0RYH#UHYHUVH#ORRNXS#]RQHV#WR#:LQGRZV#5333#'16#VHUYHU


When performing domain restructuring from Windows NT 4.0 or a separate
Windows 2000 forest, one of the first administrative tasks is to integrate the
source network DNS infrastructure with the DNS infrastructure required for the
target Windows 2000 forest.

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
Directory.

Bind 8.1.2 and later supports SRV resource records and dynamic updates
and can be used to support Active Directory domains.

The approach you take to ensure ongoing DNS name resolution during the
migration phase depends on the name of the Active Directory root domain.
0DWFKLQJ#$FWLYH#'LUHFWRU\#'RPDLQV#WR#'16#'RPDLQV#
If you plan to match the Active Directory domain name to the existing NT 4.0
DNS domain name, your restructure plan must include:

„# Establishing a DNS server in the target Windows 2000 domain. This DNS
server must be capable of storing the necessary SRV resource records for
Active Directory and must also have the ability to accept dynamic updates.
6OLGH#2EMHFWLYH#
7R#GHVFULEH#D#VWUDWHJ\#IRU#
SURYLGLQJ#UHOLDEOH#'16#
VHUYLFHV#GXULQJ#D#GRPDLQ#
UHVWUXFWXUH1#
/HDG0LQ#
<RXU#GRPDLQ#UHVWUXFWXUH#
SODQ#PXVW#GHILQH#KRZ#'16#
ZLOO#EH#PDGH#DYDLODEOH#WR#WKH#
WDUJHW#$FWLYH#'LUHFWRU\#
HQYLURQPHQW1#
5HPLQG#VWXGHQWV#WKDW#WKHUH#
LV#QR#QHHG#WR#PDLQWDLQ#WKH#
'16#]RQH#IRU#DQ#$FWLYH#
'LUHFWRU\#GRPDLQ#WKDW#LV#
EHLQJ#UHPRYHG#IURP#WKH#
QHWZRUN1#
#
,Q#DGGLWLRQ#WR#VXSSRUWLQJ#
659#UHVRXUFH#UHFRUGV/#'16#
DOVR#SURYLGHV#VXSSRUW#IRU#
PXOWL0PDVWHU#UHSOLFDWLRQ#E\#
XVLQJ#$FWLYH#'LUHFWRU\0
LQWHJUDWHG#]RQHV#DQG#WKH#
VXSSRUW#IRU#G\QDPLF#XSGDWHV#
RI#]RQH#UHVRXUFH#UHFRUGV1#
#

5HPLQG#VWXGHQWV#WKDW#
VHFXUH#G\QDPLF#XSGDWHV#
DOORZ#RQO\#WKH#RZQHU#RI#D#
'16#UHVRXUFH#UHFRUG#WR#
PRGLI\#DQ#H[LVWLQJ#'16#
UHVRXUFH#UHFRUG1#
1RWH#
1RWH#
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.

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


3URYLGLQJ#5HOLDEOH#1HW%,26#5HVROXWLRQ#6HUYLFHV#
„
(IIHFW#RI#D#5HVWUXFWXUH#RQ#1HW%,26 5HVROXWLRQ#6HUYLFHV
z
0LJUDWHG#DFFRXQWV#DUH#LVRODWHG#IURP#WKH#UHVRXUFHV#DQG#
QDPH#UHVROXWLRQ#VHUYLFHV#RI#WKH#VRXUFH#GRPDLQ#
„
5HVWUXFWXULQJ#'RPDLQV#WR#6HUYH#1HW%,26#&OLHQWV
z
'HWHUPLQH#LI#WKH#:LQGRZV#,QWHUQHW#1DPH#6HUYLFH#LV#
UHTXLUHG#
GXULQJ
D#UHVWUXFWXUH

z
,QWHJUDWH#WKH#:,16#WRSRORJ\#RI#WKH#VRXUFH#GRPDLQ#ZLWK#
WKDW#RI#WKH#WDUJHW#GRPDLQ
z
3ODQ#IRU#WKH#GHFRPPLVVLRQLQJ#RI#:,16#VHUYHUV#LQ#WKH#
VRXUFH#GRPDLQ


Down-level Microsoft clients require NetBIOS name resolution to locate
network resources. Certain applications and services also use NetBIOS names
to inform network clients of their presence. Ensure that your plans include a
way to determine the need for NetBIOS name resolution services in the target
domain and the deployment of a WINS server within the Windows 2000 target
forest to support NetBIOS clients and applications.
7KH#(IIHFW#RI#D#5HVWUXFWXUH#RQ#1HW%,26#5HVROXWLRQ#
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.

6OLGH#2EMHFWLYH#
7R#GHVFULEH#D#VWUDWHJ\#IRU#
SURYLGLQJ#UHOLDEOH#1HW%,26#
UHVROXWLRQ#VHUYLFHV#GXULQJ#D#
GRPDLQ#UHVWUXFWXUH1#
/HDG0LQ#
:LOO#\RX#VWLOO#UHTXLUH#:,16#
DIWHU#WKH#GRPDLQ#
UHVWUXFWXUH"#
5HPLQG#VWXGHQWV#WKDW#
UHPRWH#1HW%,26#UHVRXUFHV#
FDQ#DOVR#EH#UHVROYHG#XVLQJ#
WKH#/0+2676#FRQILJXUDWLRQ#
WH[W#ILOH#VWRUHG#LQ#WKH#
V\VWHPURRW
?V\VWHP65?#
GULYHUV?HWF#IROGHU1#
1RWH#
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#
# 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH##:#

3URYLGLQJ#5HOLDEOH#'+&3#6HUYHU#6HUYLFHV#
„
(QVXULQJ#7KDW#'+&3#6HUYLFHV#&RQWLQXH#WR#2SHUDWH
z
0LJUDWH#'+&3#VHUYLFHV#WR#WKH#WDUJHW#GRPDLQ#HDUO\#LQ#WKH#
UHVWUXFWXUH
8SJUDGH#WKH#H[LVWLQJ#'+&3#VHUYHU#LI#WKH#VRXUFH#GRPDLQ#
LV#D#:LQGRZV#17#713#GRPDLQ
0LJUDWH#WKH#'+&3#VHWWLQJV#WR#D#QHZ#VHUYHU#E\#XVLQJ#WKH#
1(76+#FRPPDQG
z
'HWHUPLQH#QHZ#VFRSH#RSWLRQV#WKDW#QHHG#WR#EH#FRQILJXUHG


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.
(QVXULQ J#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.
6OLGH#2EMHFWLYH#
7R#GHVFULEH#D#VWUDWHJ\#IRU#
SURYLGLQJ#UHOLDEOH#'+&3#
6HUYHU#VHUYLFHV#GXULQJ#D#
GRPDLQ#UHVWUXFWXUH1#
/HDG0LQ#
%HFDXVH#\RX#FDQQRW#UXQ#WZR#
'+&3#VHUYLFHV#RQ#WKH#VDPH#
SK\VLFDO#QHWZRUN/#\RX#QHHG#
HLWKHU#WR#PDLQWDLQ#WKH#
H[LVWLQJ#'+&3#VHUYLFHV#RU#
PRYH#WKHP#WR#WKH#
:LQGRZV#5333#WDUJHW#
GRPDLQ1#
5HPLQG#VWXGHQWV#WKDW#WZR#
'+&3#VHUYLFHV#FDQQRW#FR0
H[LVW#RQ#WKH#VDPH#SK\VLFDO#
QHWZRUN#XQOHVV#WKH#,3#
DGGUHVVHV#IRU#WKH#'+&3#
VFRSH#DUH#VSOLW#EHWZHHQ#
'+&3#VHUYHUV#LQ#WKH#VRXUFH#

DQG#WDUJHW#GRPDLQV#ZLWKRXW#
RYHUODS1#
.H\#3RLQWV#
7KH#GKFSFPG
#
FRPPDQG#
FDQ#EH#XVHG#WR#VFULSW#WKH#
DXWKRUL]DWLRQ#RI#D#'+&3#
VHUYHU1#
#
7KH#1(76+#FRPPDQG#FDQ#
EH#XVHG#WR#H[SRUW#VHWWLQJV#
IURP#ERWK#:LQGRZV#17#713#
DQG#:LQGRZV#5333#'+&3#
6HUYHU#VHUYLFHV1#
;# # 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#
# 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH##<#


3URYLGLQJ#5HPRWH#$FFHVV#6HUYLFHV#LQ#D#0L[HG#(QYLURQPHQW#
„
(IIHFW#RI#D#5HVWUXFWXUH#RQ#5$6#DQG#55$6
z
:LQGRZV#17#713#5$6#DQG#55$6#VHUYHUV#XVH#18//#VHVVLRQ#WR#
GHWHUPLQH#GLDO0LQ#SHUPLVVLRQV
z
%\#GHIDXOW/#$FWLYH#'LUHFWRU\#GRHV#QRW#DOORZ#18//#VHVVLRQ#FRQQHFWLRQV#
„
$OORZLQJ#18//#6HVVLRQ#$XWKHQWLFDWLRQ
z
$GG#WKH#(YHU\RQH#JURXS#WR#WKH#3UH0:LQGRZV 5333#&RPSDWLEOH#$FFHVV#
EXLOW0LQ#JURXS#
„
(QVXULQJ#WKDW#5$6#DQG#55$6#6HUYLFHV#&RQWLQXH#WR#2SHU DWH
z

'HWHUPLQH#KRZ#UHPRWH#DFFHVV#VHUYHUV#ZLOO#EH#PLJUDWHG#
z
(QVXUH#WKDW#UHPRWH#DFFHVV#DXWKHQWLFDWLRQV#ZLOO#EH#VXFFHVVIXO#
z
5HPRYH#EDFNZDUG#FRPSDWLELOLW\#SHUPLVVLRQV
z
,GHQWLI\#DGGLWLRQDO#5HPRWH#$FFHVV#3ROLF\#VHWWLQJV#WR#FRQILJXUH


Routing and Remote Access in Windows 2000 provides dial-in and tunneling
access to Windows 2000 networks. An inter-forest restructure requires planning
to integrate Windows NT 4.0 Remote Access Service (RAS) and Routing and
Remote Access Service (RRAS) that are migrated to a Windows 2000 target
domain.
7KH#(IIHFW#RI#D#5HVWUXFWXUH#RQ#5$6#DQG#55$6#
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.

6OLGH#2EMHFWLYH#
7R#GHVFULEH#D#VWUDWHJ\#IRU#
SODQQLQJ#VXSSRUW#IRU#UHPRWH#
DFFHVV#VHUYLFHV#GXULQJ#WKH#
UHVWUXFWXULQJ#SURFHVV1#
/HDG0LQ#
,Q#JHQHUDO/#LW#LV#D#JRRG#LGHD#
WR#FRQYHUW#WKH#5RXWLQJ#DQG#
5HPRWH#$FFHVV#VHUYHUV#WR#
:LQGRZV#5333#HDUO\#LQ#WKH#
UHVWUXFWXULQJ#SURFHVV#
WKURXJK#DQ#XSJUDGH#RU#D#
UHFRQILJXUDWLRQ1#
8VH#WKH#VOLGH#WR#GLVFXVV#
ZKDW#KDSSHQV#ZKHQ#D#
QHWZRUN#WKDW#LQFOXGHV#5$6#
DQG#55$6#VHUYHUV#LV#VSOLW#
EHWZHHQ#VRXUFH#DQG#WDUJHW#
GRPDLQV1#
#
(PSKDVL]H#WKDW#WKH#LVVXHV#
DQG#SODQQLQJ#VWHSV#
GLVFXVVHG#RQ#WKLV#SDJH#
DSSO\#RQO\#WR#VFHQDULRV#WKDW#
UHVWUXFWXUH#D#:LQGRZV#17#
713#VRXUFH#GRPDLQ#LQWR#D#
:LQGRZV#5333#WDUJHW#
GRPDLQ1#
1RWH#

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 pre-
Windows 2000 Server when running the Active Directory Installation
wizard
OR
„# Adding the Everyone group to the Pre-Windows 2000 Compatible Access
built-in group.

The Pre-Windows 2000 Compatible Access group is able to query the
properties of objects in Active Directory without authenticating with Active
Directory. This allows Windows NT 4.0 RAS servers to function by connecting
to Active Directory servers will NULL sessions to determine whether a
connecting user has dial-in permissions.
(QVXULQ J#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.
# 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH# # 44#


6XSSRUWLQJ#/$1#0DQDJHU#5HSOLFDWLRQ#
„
(IIHFW#RI#D#5HVWUXFWXUH#RQ#5HSOLFDWLRQ#6HUYLFHV
z
&ORQHG#DFFRXQWV#ZLOO#QRW#UHFHLYH#SUHYLRXV#ORJRQ#VFULSWV#

DQG#SROLFLHV#XQWLO#ILOH#UHSOLFDWLRQ#LV#LQWHJUDWHG#ZLWK#
:LQGRZV#5333#)56
„
,QWHJUDWLQJ#5HSOLFDWLRQ#6HUYLFHV
z
(QVXUH#WKDW#WKH#WZR#ILOH#UHSOLFDWLRQ#V\VWHPV#DUH#EULGJHG
z
0DLQWDLQ#WKH#EULGJH#EHWZHHQ#WKH#UHSOLFDWLRQ#V\VWHPV#
z
'HWHUPLQH#ZKHQ#WR#UHPRYH#WKH#EULGJH#EHWZHHQ#
UHSOLFDWLRQ#V\VWHPV


Windows NT 4.0 Server uses the LAN Manager Replication service to replicate
logon scripts, System Policies, and other data. Windows 2000 does not support
LAN Manager Replication service but offers the same functionality through
FRS.
7KH#(IIHFW#RI#D#5HVWUXFWXUH#RQ#5HSOLFDWLRQ#6HUYLFHV#
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.
6OLGH#2EMHFWLYH#
7R#H[SODLQ#KRZ#WR#PDLQWDLQ#
/$1#0DQDJHU#UHSOLFDWLRQ#
IXQFWLRQDOLW\#DIWHU#

:LQGRZV#5333#)56#LV#
LPSOHPHQWHG1#
/HDG0LQ#
%HFDXVH#:LQGRZV#5333#
GRHV#QRW#VXSSRUW#/$1#
0DQDJHU#UHSOLFDWLRQ/#\RX#
PXVW#GHYHORS#D#VWUDWHJ\#IRU#
LQWHJUDWLQJ#ZLWK#WKH#)561#
(PSKDVL]H#WKDW#WKH#LVVXHV#
DQG#SODQQLQJ#VWHSV#
GLVFXVVHG#RQ#WKLV#SDJH#
DSSO\#RQO\#WR#VFHQDULRV#LQ#
ZKLFK#D#:LQGRZV#17#713#
GRPDLQ#LV#UHVWUXFWXUHG#LQWR#D#
:LQGRZV#5333#IRUHVW1#/$1#
0DQDJHU#5HSOLFDWLRQ#LV#QRW#
SUHVHQW#ZKHQ#D#:LQGRZV#
5333#GRPDLQ#LV#PLJUDWHG#WR#
D#:LQGRZV#5333#GRPDLQ#LQ#
DQRWKHU#IRUHVW1#
'HOLYHU\#7LS#
2SHQ#WKH#OEULGJH1FPG#VFULSW#
DQG#VKRZ#WKH#OLQHV#WKDW#PXVW#
EH#FRQILJXUHG=#
#
6HW#/0'HVWLQDWLRQ (4#
5HSODFH#ZLWK#
6HW#/0'HVWLQDWLRQ #
??VHUYHU?UHSO'?VFULSWV#
#

,I#\RX#ZDQW#WR#XVH#URERFRS\/#
FRQILJXUH#WKH#OLQHV#DV#VKRZQ#
KHUH=#
#
#5HP#&DOO#=;&RS\#
&DOO#=5RERFRS\#
#
,I#\RX#ZDQW#WR#XVH#[FRS\/#
OHDYH#DV#RULJLQDOO\#VKLSSHG1#
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.

'HOLYHU\#7LS#
,Q#WKH#VHFWLRQ#WLWOHG#=[FRS\#RU#
=5RER&RS\/#UHPRYH#WKH#
HFKR#IURP#WKH#IURQW#RI#WKH#
OLQH#WKDW#\RX#ZDQW#WR#XVH1#
7LS#

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


0LJUDWLQJ#/RJRQ#6FULSWV#WR#*URXS#3ROLF\#
„
(IIHFW#RI#D#5HVWUXFWXUH#RQ#/RJRQ#6FULSWV
z
8VHU#DFFRXQWV#FRQILJXUHG#IRU#ORJRQ#VFULSWV#ZLOO#FRQWLQXH#WR#
SURFHVV#WKH#VFULSWV#LI#WKH#VFULSW#LV#SURSHUO\#PLJUDWHG
„
0LJUDWLQJ#/RJRQ#6FULSWV#WR#:LQGRZV#5333#
z
,QYROYHV#EULGJLQJ#ILOH#UHSOLFDWLRQ#V\VWHPV
„
8VLQJ#:LQGRZV#5333#*URXS#3ROLF\#WR#3URFHVV#6FULSWV
z
,GHQWLI\#DOO#ORJRQ#VFULSWV#LQ#WKH#1(7/2*21#VKDUH
z
'HWHUPLQH#LI#XVHU0EDVHG#ORJRQ#VFULSWV#FDQ#EH#UHPRYHG
z
'HWHUPLQH#ZKHUH#WR#DSSO\#*URXS#3ROLF\#VFULSWV


Windows NT 4.0 user-based logon scripts are implemented as MS-DOS
®
batch
files stored in the NETLOGON share of primary domain controllers (PDCs)
and backup domain controllers (BDCs). When users accounts are moved or
cloned to a target Windows 2000 domain, the logon script property for those
users are retained as account attributes in the target Windows 2000 domain.

7KH#(IIHFW#RI#D#5HVWUXFWXUH#RQ#/RJRQ#6FULSWV#
Logon scripts will continue to process for cloned and moved user accounts,
provided that the scripts are properly migrated to the target domain. Non-
migrated scripts will not process for accounts that have been cloned or moved
to a new domain because they will not be found in the authenticating domain
controller's NETLOGON share in the target domain.
0LJUDWLQJ#/RJRQ#6FUL SWV#WR#:LQGRZV#5333#
If users are cloned to a Windows 2000 target domain, Windows NT 4.0 user-
based logon scripts must be migrated to the Windows 2000 NETLOGON share
by bridging the LAN Manager Replication service and FRS. The bridge will
ensure that the contents of the NETLOGON share are identical in both the
source and target domains so that the same logon script is processed for both
the source and cloned user accounts.
If users are moved between two Windows 2000 domains, ensure that any
required logon scripts are copied into the NETLOGON share of a domain
controller in the target domain.
6OLGH#2EMHFWLYH#
7R#GHVFULEH#D#VWUDWHJ\#IRU#
WUDQVLWLRQLQJ#IURP#:LQGRZV#
17#713#XVHU0EDVHG#ORJRQ#
VFULSWV#WR#:LQGRZV#5333#
*URXS#3ROLF\1#
/HDG0LQ#
,Q#DGGLWLRQ#WR#DSSO\LQJ#
:LQGRZV#17#713#XVHU0EDVHG#
ORJRQ#VFULSWV/#:LQGRZV#
5333#VXSSRUWV#*URXS#3ROLF\#
VFULSWV1#
5HPLQG#VWXGHQWV#WKDW#*URXS#
3ROLF\#FDQ#EH#DSSOLHG#RQO\#WR#

VLWHV/#GRPDLQV#DQG#28V1#
*URXS#3ROLF\#FDQQRW#EH#
DSSOLHG#WR#GRZQ0OHYHO#
FRPSXWHU#DFFRXQWV1#
#
5HPLQG#VWXGHQWV#WKDW#*URXS#
3ROLF\#VFULSWV#FDQ#EH#
VHSDUDWHG#LQWR#FRPSXWHU0
EDVHG#VFULSWV#IRU#ERWK#WKH#
VWDUWXS#DQG#VKXWGRZQ#
VHTXHQFHV/#RU#LQWR#XVHU0
EDVHG#VFULSWV#WKDW#FDQ#EH#
DSSOLHG#ZKHQ#FOLHQWV#UXQQLQJ#
:LQGRZV#5333#HLWKHU#ORJ#RQ#
RU#ORJ#RII1#
47# # 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#


8VLQJ#:LQGRZV#5333#*URXS#3ROLF\#WR#3URFHVV#6FULSWV#
When moving computer accounts to a target Windows 2000 domain, logon
scripts can be converted to Windows 2000 Group Policy. Group Policy allows
greater flexibility in applying scripts; for example, scripts can be assigned to
both computer and user accounts at the container level in Active Directory.
Additional scripts can also be applied through the use of Group Policy, such as
user logoff and computer startup and shutdown scripts. By using the Windows
Script Host to process the scripts, more flexible commands can be executed
than were possible in the MS-DOS batch file format used for Windows NT
user-based logon scripts.
To determine if Group Policy can be used in the target environment to process
scripts, the following steps must be added to the domain restructure plan:

„# Identifying all logon scripts in the NETLOGON share. Identify scripts and
the person responsible for maintaining them. This person’s account must be
granted write access to the script in the target domain for editing purposes.
„# Determining if user-based logon scripts can be removed from the network.
Users authenticating at Microsoft Windows 95, Windows 98, or Windows
NT 4.0 workstations will require down-level user-based logon scripts. If
these clients exist, you must maintain user-based logon scripts. Also, since
Group Policy cannot be applied to user accounts directly, there may be
situations that require the continued use of standard logon scripts.
„# Determining where to apply Group Policy scripts in the Active Directory
hierarchy. If you intend to deploy Group Policy as a replacement or
supplement to user-based logon scripts, you must consider where you will
apply the scripts in the Active Directory hierarchy. Group Policy can only
be applied at the site, domain, and organizational unit (OU) levels.

For more information on Group Policy deployment design, see course
1561B, Designing a Microsoft Windows 2000 Directory Services
Infrastructure.


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


0LJUDWLQJ#6\VWHP#3ROLFLHV#WR#*URXS#3ROLFLHV#
„
(IIHFW#RI#D#5HVWUXFWXUH#RQ#6\VWHP#3ROLFLHV
z
6\VWHP#3ROLFLHV#ZLOO#QRW#SURFHVV#IRU#PLJUDWHG#FOLHQWV#
DXWRPDWLFDOO\

„
,QWHJUDWLQJ#6\VWHP#3ROLFLHV#LQ#:LQGRZV#5333
z
%ULGJH#WKH#ILOH#UHSOLFDWLRQ#VHUYLFHV
„
0LJUDWLQJ#6\VWHP#3ROLFLHV#WR#:LQGRZV 5333
z
'HWHUPLQH#ZKDW#PLJUDWHG GRZQOHYHO FOLHQWV#UHTXLUH#6\VWHP#
3ROLFLHV#
z
'HWHUPLQH#ZKDW#VHWWLQJV#IURP#6\VWHP#3ROLFLHV#QHHG#WR#EH#
DSSOLHG#WR#FOLHQWV#XSJUDGHG#WR#:LQGRZV#5333#
z
'HWHUPLQH#ZKHUH#LQ#WKH#28#VWUXFWXUH#WR#GHSOR\#*URXS#3ROLF\
z
'HWHUPLQH#LI#6\VWHP#3ROLFLHV#VKRXOG#EH#GHFRPPLVVLRQHG


During an inter-forest restructure, different mixes of System Policies and Group
Policy will be applied to users and computers. This will depend on whether the
user account or computer account is located in a Windows 2000 or Windows
NT 4.0 domain.
When a computer account is in a Windows NT 4.0 domain, system policies are
applied to the computer. When a user account is located in a Windows NT 4.0
domain, system policies are applied to the user. If a computer or user account is
in a Windows 2000 domain, group policies are applied to that account.
For example, if a user with an account on a Windows 2000 domain logs on to a
computer with an account in a Windows NT 4.0 domain:
„# Computer settings are applied from any system policy that applies to the
computer account.

„# User settings are applied from any group policy objects that apply to the
user account.


Only Windows NT 4.0 clients process System Policies. Group
Policy is available only to clients running Windows 2000.

7KH#(IIHFW#RI#D#5HVWUXFWXUH#RQ#6\VWHP#3ROLFLHV#
After restructuring a Windows NT 4.0 domain into a Windows 2000 forest,
System Policies from the source domain will not be automatically processed by
migrated clients authenticating in the target domain. To allow System Policies
to continue to process for Windows NT 4.0 clients, you must integrate the
Windows 2000 FRS with Windows NT LAN Manager Replication to allow
synchronization between the two file replication services
#or migrate System
Policies to Windows 2000.
6OLGH#2EMHFWLYH#
7R#GHVFULEH#D#VWUDWHJ\#IRU#
WUDQVLWLRQLQJ#IURP#:LQGRZV#
17#713#6\VWHP#3ROLFLHV#WR#
:LQGRZV#5333#*URXS#
3ROLF\1#
/HDG0LQ#
%\#GHIDXOW/#:LQGRZV#5333#
GRHV#QRW#SURFHVV#:LQGRZV#
17#713#6\VWHP#3ROLFLHV1#
7KH#LVVXHV#GLVFXVVHG#RQ#
WKLV#SDJH#DSSO\#RQO\#WR#LQWHU0
IRUHVW#GRPDLQ#UHVWUXFWXUH#
VFHQDULRV1#6\VWHP#3ROLFLHV#

DUH#QRW#DQ#LVVXH#ZKHQ#
SHUIRUPLQJ#LQWUD0IRUHVW#
PLJUDWLRQ1#
,PSRUWDQW#
49# # 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#


,QWHJUDWLQJ#6\VWHP#3ROLFLHV#LQ#:LQGRZV#5333#
To ensure that System Policies continue to process for Windows NT 4.0
computer accounts in a Windows 2000 domain, you must migrate the Windows
NT 4.0 system policy file (Ntconfig.pol) to the Windows 2000 NETLOGON
share. Use a bridge between the LAN Manager Replication service in Windows
NT 4.0 and FRS in Windows 2000, to connect the NETLOGON shares so that
System Policies are available in the Windows 2000 network.
0LJUDWLQJ#6\VWHP#3ROLFLHV#WR#:LQGRZV#5333#
Processing System Policies for migrated clients in a Windows 2000 domain is
necessary only until clients are upgraded to Windows 2000. Once all users are
migrated to and authenticating against the Windows 2000 target domain and
client computers are upgraded, System Policy functionality must be replaced
with Group Policy. The following steps are necessary in a restructure plan to
fully migrate System Policies to Group Policy:
„# Determine what migrated down-level clients require System Policies. Only
previous Microsoft clients whose accounts have been moved to the target
domain require System Policies from the NETLOGON share.
„# Determine what settings from System Policies need to be applied to clients
upgraded to Windows 2000. System Policy settings can be migrated to
Group Policy using the Gpolmig.exe Windows 2000 Resource Kit utility.
This tool translates current System Policy settings into Group Policy
settings and maps the necessary registry settings to the Windows 2000
registry settings.

„# Determine where in the OU structure to deploy Group Policy. You can
apply Group Policy at different levels of the Active Directory hierarchy.
When deploying Group Policy, you need to determine which policies must
be applied at the domain level, and which policies must be applied at
specific OUs in the Active Directory hierarchy.

For design considerations for Group Policy, see course 1561B,
Designing a Microsoft Windows 2000 Directory Services Infrastructure.

„# Determine whether System Policies must be decommissioned in the target
domain. Only when all previous Microsoft clients are upgraded to
Windows 2000 can you remove System Policies from the NETLOGON
share and replace them with Group Policy.


For more information on how System Policies and Group Policy are
processed in a mixed environment, see Chapter 23 of the Windows 2000 Server
Deployment Planning Guide, “Defining Client Administration and
Configuration Standards”, on the Student Materials compact disc.

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


‹‹
#3UHSDULQJ#IRU#$FFRXQW#0LJUDWLRQ#,VVXHV#
„
0LQLPL]LQJ#$XWKHQWLFDWLRQ#,VVXHV#'XULQJ#5HVWUXFWXUH
„

3URYLGLQJ#5HOLDEOH#6HUYLFH#$FFRXQW#2SHUDWLRQ
„
0LJUDWLQJ#+DUG0&RGHG#$FFRXQW#0DSSLQJV
„
0LJUDWLQJ#8VHU#5LJKWV#$VVLJQPHQWV
„
0LJUDWLQJ#8VHU#3URILOH#


During the domain restructure, accounts are moved or cloned to a target
Windows 2000 domains. If done improperly, this process can affect several
areas, including password continuity, service accounts, application
functionality, and user rights.
6OLGH#2EMHFWLYH#
7R#GHVFULEH#WKH#LVVXHV#WKDW#
RFFXU#GXH#WR#WKH#FORQLQJ#RI#
DFFRXQWV#ZKHQ#UHVWUXFWXULQJ#
D#:LQGRZV#5333#GRPDLQ1#
/HDG0LQ#
&DUHIXO#SODQQLQJ#LV#UHTXLUHG#
WR#PLJUDWH#DFFRXQWV#WR#WKHLU#
QHZ#GRPDLQV1#
4;# # 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH#


0LQLPL]LQJ#$XWKHQWLFDWLRQ#,VVXHV#'XULQJ#5HVWUXFWXUH#
„
3DVVZRUGV#$UH#1RW#&ORQHG#DQG#$FFRXQWV#$UH#(QDEOHG
„
0LQLPL]LQJ#$XWKHQWLFDWLRQ#6HUYLFH#,VVXHV

z
'HWHUPLQH#KRZ#SDVVZRUGV#ZLOO#EH#VHW#RQ#FORQHG#DFFRXQWV
z
'HWHUPLQH#KRZ#WR#VHFXUHO\#GLVWULEXWH#FORQHG#XVHU#DFFRXQW#
SDVVZRUGV
z
'HWHUPLQH#ZKHWKHU#DFFRXQWV#VKRXOG#EH#GLVDEOHG#
z
'HWHUPLQH#ZKHQ#FOLHQWV#ZLOO#EH#DOORZHG#WR#ORJ#RQ#XVLQJ#
WDUJHW#FORQHG#DFFRXQWV#
Clone
Clone
Clone
Windows NT 4.0 Domain
Windows 2000 Domain
Password: X2ty7Jr!
Password: X2ty7Jr!
Password:Username
Password:Username


When accounts are cloned from a source domain to a Windows 2000 target
domain during an inter-forest restructure, user passwords are not maintained.
Authentication issues can arise due to this fact.
7KH#(IIHFW#RI#D#5HVWUXFWXUH#RQ#8VHU#$XWKHQWLFDWLRQ#
To perform migration operations, trust relationships must be created and
maintained between the source and target domains. If the Active Directory
Migration Tool (ADMT) is used to clone users, the new accounts are, by
default, enabled, making it possible for a cloned user to log on with either the
source account or the cloned account credentials. This can cause user and

administrative confusion when configuration changes are applied to the source
account rather than to the cloned account.
Passwords are not migrated during an inter-forest domain restructure. Failed
user logon attempts due to incorrect passwords can generate significant support
issues during migration.

Refer to the Migration Tools Comparison worksheet on the Student
Materials compact disc for information on how each migration tool handles
passwords.

0LQLPL]LQJ#$XWKHQWLFDWLRQ#6HUYLFH#,VVXHV#
To minimize the impact of authentication service issues during a domain
restructure:
„# Determine how passwords will be set on cloned accounts. Each tool handles
passwords differently. For example, MoveTree maintains the existing
password when a user account is moved. ADMT, however, can set random
complex passwords on user accounts, and set the password on migrated
accounts to the user name. ClonePrincipal, by default, sets the password to
NULL on cloned accounts. Additional scripting is required to set initial
passwords when using this tool.
6OLGH#2EMHFWLYH#
7R#SODQ#IRU#LVVXHV#LQYROYHG#
ZLWK#XVHU#DXWKHQWLFDWLRQ#
ZKHQ#FORQLQJ#DFFRXQWV#WR#D#
QHZ#IRUHVW1#
/HDG0LQ#
(YHQ#WKRXJK#XVHU#DFFRXQWV#
DUH#PLJUDWHG#WR#
:LQGRZV#5333/#XVHU#
SDVVZRUGV#DUH#QRW#FDUULHG#

RYHU1#
5HPLQG#VWXGHQWV#WKDW#WKH#
VRXUFH#LQ#DQ#LQWHU0IRUHVW#
UHVWUXFWXUH#FDQ#EH#D#
:LQGRZV#17#713#GRPDLQ#RU#
D#:LQGRZV#5333#GRPDLQ1#
#
([SODLQ#WR#VWXGHQWV#KRZ#
HDFK#LQWHU0IRUHVW#PLJUDWLRQ#
WRRO#KDQGOHV#SDVVZRUGV1#
#
0HQWLRQ#WKDW#VHUYLFH#
DFFRXQWV#DUH#DOZD\V#VHW#
ZLWK#FRPSOH[#UDQGRP#
SDVVZRUGV#ZKHQ#WKH\#DUH#
FORQHG#ZLWK#WKH#$'071##
1RWH#
# 0RGXOH#:=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#D#'RPDLQ#5HVWUXFWXUH# # 4<#


„# Determine how to securely distribute cloned user account passwords. The
initial passwords set by ADMT must be distributed to all users in a secure
fashion. Options include using e-mail or physical delivery of the password
to each individual user.

If passwords are initially set to match the user name or are left blank, it
is a good idea to set the User must change password at next logon option.

„# Determine whether accounts must be disabled during the cloning process.
By default, ClonePrincipal will disable the newly cloned accounts until an

administrator enables them in Active Directory Users and Computers in the
Microsoft Management Console (MMC). ADMT offers more flexibility
because you can decide to disable either the source or target account.
„# Determine when clients will be allowed to log on using target cloned
accounts. The ADMT can be configured to disable cloned accounts.
Accounts must not be made available to users until the target environment is
fully deployed and tested, passwords are distributed, and source accounts
are disabled.

7LS#