Tải bản đầy đủ (.pdf) (48 trang)

Tài liệu Module 4: Minimizing the Impact on Network Operations During an Upgrade doc

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.43 MB, 48 trang )

#




&RQWHQWV##
#
2YHUYLHZ#4
#
0DLQWDLQLQJ#1HWZRUN#6HUYLFHV##
'XULQJ#DQ#8SJUDGH#5
#
0DLQWDLQLQJ#6HFXULW\#'XULQJ#DQ#8SJUDGH#49
#
'HWHUPLQLQJ#WKH#,PSDFW#RI#DQ##
8SJUDGH#RQ#$SSOLFDWLRQV#57
#
/HYHUDJLQJ#([LVWLQJ#'LUHFWRU\#,QIRUPDWLRQ#58
#
0DLQWDLQLQJ#1HWZRUN#3HUIRUPDQFH##
'XULQJ#DQ#8SJUDGH#5:
#
/DE#$=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN##
2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#64
#
5HYLHZ#74
#
#
Module 4: Minimizing
the Impact on Network
Operations During an


Upgrade

#

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#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH##LLL#


,QVWUXFWRU#1RWHV#
This module provides students with the ability to develop a strategy for
upgrading from Microsoft
®
Windows NT
®
version 4.0 to Microsoft Windows
®

2000 while maintaining network reliability, security, availability, and
performance.
At the end of this module, students will be able to:
„# Examine existing network services and develop a strategy for ensuring their
reliability during an upgrade.
„# Determine how a domain upgrade will modify existing security and develop
a strategy for maintaining desired security levels during the upgrade.
„# Determine in advance how server applications will behave in a Windows
2000 environment.

„# Describe how the Active Directory

Connector (ADC) allows migration of
user attributes to the Active Directory directory service.
„# Develop a strategy for regulating traffic to optimize network performance
during the upgrade.

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_04.ppt
„# Module 4, “Minimizing the Impact on Network Operations During an
Upgrade”

3UHSDUDWLRQ#7DVNV#
To prepare for this module, you should:
„# Read all of the materials for this module.
„# Read all of the delivery tips.
„# Complete the lab.
„# Read chapter 10 of the Windows 2000 Server Deployment Planning Guide,
“Determining Domain Migration Strategies,” on the Student Materials
compact disc.
„# Read chapter 21 of the Windows 2000 Server Deployment Planning Guide,
“Testing Applications for Compatibility with Windows 2000,” on the
Student Materials compact disc.
„# Read chapter 23 of the Windows 2000 Server Deployment Planning Guide,

“Defining Client Administration and Configuration Standards,” on the
Student Materials compact disc.

3UHVHQWDWLRQ=#
93#0LQXWHV#
#
/DE=#
93#0LQXWHV#
LY##0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#


0RGXOH#6WUDWHJ\#
Use the following strategy to present this module:
Make sure that students understand that the strategies outlined in this module
are steps that must be added to the basic upgrade plan if an organization’s
current network environment warrants it. Not all upgrade plans will include all
strategies outlined in this module.
Be prepared throughout this module to provide a quick review of each service
to students who may not have an extensive Windows NT 4.0 background. You
may wish to use the Glasgow computer in class to demonstrate various
Windows NT 4.0 tools or to draw comparisons.
This module is one of the longer modules of the course. Consider taking a short
break in the middle of the module. Keep students’ attention and interest by
asking questions about what services, security, needs, or requirements exist in
their environment and how each topic might impact them.
„# Maintaining Network Services During an Upgrade

For many students, network reliability will be the area of greatest concern.
Several of the topics in this section discuss differences in the way that
Windows NT 4.0 and Windows 2000 manage common networking services.

Although these topics reveal potential pitfalls, you will also discuss why
other areas should not be an issue during the domain upgrade. Emphasize
the importance of careful planning when considering network reliability.
Be prepared to provide a short review of basic concepts of the Domain
Name System (DNS), to put the first topic of this section into context for
students who lack prerequisite knowledge.
You may wish to summarize a few of the benefits of Active Directory
integrated zones. Consolidating DNS and Active Directory replication
eliminates the need to maintain multiple replication topologies; multi-master
writes eliminate the single point of failure in the DNS hierarchy, and secure
dynamic updates prevent unauthorized changes to resource records.
Whichever method is chosen for DNS server upgrades, it is best if the DNS
server that holds the primary zone data is a Windows 2000 Server to support
SRV (service) resource records and dynamic update.
The proper SRV record format in the zone text files on a Windows NT 4.0
DNS server is maintained and is displayed once the DNS server is upgraded
to Windows 2000.
Make sure that students understand that a pure Windows 2000 network
contains only Windows 2000 clients and servers
Students should remember from prerequisite courses that Dynamic Host
Configuration Protocol (DHCP) can be configured to always update DNS or
only when the client requests it. It can also be configured to clean up host
(A) resource records when a lease expires.
Supporting LAN Manager replication during an upgrade is a rather complex
topic because it involves many different components and steps. Make sure
that students begin with a clear understanding of the difference between
NTLM protocol replication, File Replication service (FRS) and multi-master
replication. Students may have many questions on this topic, so be prepared
to provide background information and communicate the need for planning
this service’s integration with Windows 2000.

# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH##Y#


Supporting Remote Access Service (RAS) during an upgrade is also a
complex topic to explain because of the many different scenarios in which
an organization can find its RAS servers as an upgrade proceeds. Take the
time to thoroughly explain all the different gyrations.
Make sure you read the Group Policy documents referenced in the module.
Many students may still be confused about the function and purpose of
Group Policy.
„# Maintaining Security During an Upgrade
An upgrade to Windows 2000 will have a minimal effect on user accounts,
group accounts, user profiles, and trust relationships. Students working with
sensitive information will be particularly interested in how changes to trusts
affect administrative access. Emphasize that these changes are designed to
take advantage of new Active Directory features and will likely result in
tightened security in the long term; but in migrating to the new environment,
students need to change the way they think about security administration
and implementation, and security templates.
„# Determining the Impact of an Upgrade on Applications
The only way to determine the impact that an upgrade will have on an
application is to perform a test. Emphasize to students that testing
applications is just one component of the much larger domain upgrade test.
Developing a test plan is covered in more detail in module 7 “Planning to
Deploy a Migration Strategy” of course 2010A, Designing a Microsoft
Windows 2000 Migration Strategy.
„# Leveraging Existing Directory Information
Many applications store user attributes that can be ported into Active
Directory. This topic focuses on Microsoft Exchange 5.5 as an example of
how an application information store can be used to facilitate migration

operations. Since this is a planning course, you do not need to detail the
configuration options of or demonstrate the ADC. Refer students to their
compact discs for more information. Emphasize that identifying these types
of information stores is an important part of planning the early phases of
domain upgrade.
„# Maintaining Network Performance During an UpgradeThe key to network
performance during an upgrade is site implementation. Be prepared for
questions from students that deviate from the topic. Handle their questions
in a way that doesn’t distract from the main upgrade-related planning issues.
(Students should have a full understanding of replication and topology
design from prerequisite courses). Make sure students understand that the
site topology is defined during the Active Directory design, prior to upgrade
planning. The key during upgrade is implementing the sites in a timely
manner to control replication and logon traffic.



# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH##4#


2YHUYLHZ#

0DLQWDLQLQJ#1HWZRUN#6HUYLFHV#'XULQJ#DQ#8SJUDGH

0DLQWDLQLQJ#6HFXULW\#'XULQJ#DQ#8SJUDGH

'HWHUPLQLQJ#WKH#,PSDFW#RI#DQ#8SJUDGH#RQ#$SSOLFDWLRQV

/HYHUDJLQJ#([LVWLQJ#'LUHFWRU\#,QIRUPDWLRQ


0DLQWDLQLQJ#1HWZRUN#3HUIRUPDQFH#'XULQJ#DQ#8SJUDGH


One of your primary migration goals will be to ensure continuous network
functionality with minimal impact on business productivity. Potential benefits
of upgrading your existing Microsoft
®
Windows NT
®
4.0 domains to Microsoft
Windows
®
2000 include improved manageability, scalability, security, and
availability. Achieving these benefits while maintaining network operations
may introduce additional considerations to your basic upgrade plan.
This module explores the effects of a domain upgrade on various components
of a Windows NT 4.0 network and suggests planning steps and techniques to
reduce or eliminate interruptions during the upgrade.
At the end of this module, you will be able to:
„# Examine existing network services and develop a strategy for ensuring their
reliability during an upgrade.
„# Determine how a domain upgrade will modify existing security and develop
a strategy for maintaining your desired security levels during the upgrade.
„# Determine in advance how server applications will behave in a Windows
2000 environment.
„# Describe how the Active Directory

Connector allows migration of user
attributes to the Active Directory directory service.
„# Develop a strategy for regulating traffic to optimize network performance

during the upgrade.

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#XSJUDGH#RQ#
\RXU#QHWZRUN#UHOLDELOLW\/#
VHFXULW\/#DYDLODELOLW\/#DQG#
SHUIRUPDQFH1#
'HOLYHU\#7LS#
7HOO#VWXGHQWV#WKDW#PRGXOH#6/#
³'HYHORSLQJ#D#'RPDLQ#
8SJUDGH#6WUDWHJ\/´#LQ#
FRXUVH#5343$/#'HVLJQLQJ#D#
0LFURVRIW#:LQGRZV#5333#
0LJUDWLRQ#6WUDWHJ\/#FRQWDLQV#
VWHSV#WKDW#DOO#RUJDQL]DWLRQV#
PXVW#LQFOXGH#LQ#WKHLU#
XSJUDGH#SODQV1#7KH#FXUUHQW#
PRGXOH#ZLOO#FRYHU#DGGLWLRQDO#
SODQQLQJ#VWHSV#WKDW#PD\#EH#
UHTXLUHG#GHSHQGLQJ#RQ#WKH#
FXUUHQW#QHWZRUN#
HQYLURQPHQW1#
5# # 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#



‹‹
#0DLQWDLQLQJ#1HWZRUN#6HUYLFHV#'XULQJ#DQ#8SJUDGH#

3URYLGLQJ#5HOLDEOH#'16#6HUYLFHV

3URYLGLQJ#5HOLDEOH#1HW%,26#5HVROXWLRQ#6HUYLFHV

3URYLGLQJ#5HOLDEOH#'+&3#6HUYHU#6HUYLFHV

6XSSRUWLQJ#/$1#0DQDJHU#5HSOLFDWLRQ

6XSSRUWLQJ#5HPRWH#$FFHVV#6HUYLFHV

3ODQQLQJ#IRU#,QWHUDFWLRQ#%HWZHHQ#*URXS#3ROLF\#DQG#
6\VWHP#3ROLFLHV

0LJUDWLQJ#DQG#$SSO\LQJ#/RJRQ#6FULSWV


For many network administrators, the biggest risk during a domain upgrade will
be potential interruptions to network operations. Because an upgrade 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 upgrade.

„# Determining your current usage of NetBIOS names so that you can evaluate
the possibility of removing the Windows Internet Name Service after the

upgrade.
„# Identifying normal interruptions to Dynamic Host Configuration Protocol
(DHCP) Server services during the upgrade process so that you can
maintain maximum reliability.
„# Maintaining NTLM protocol replication functionality after Windows 2000
File Replication service (FRS) is implemented.
„# Developing a strategy for planning Routing and Remote Access support
during the upgrade process.
„# Developing a strategy for transitioning from Windows NT 4.0 System
Policies to Windows 2000 Group Policy.
„# Developing a strategy for transitioning from Windows NT 4.0 logon scripts
to Windows 2000 Group Policy.

6OLGH#2EMHFWLYH#
7R#GHVLJQ#D#VWUDWHJ\#IRU#
PDLQWDLQLQJ#UHOLDEOH#QHWZRUN#
VHUYLFHV#GXULQJ#D#GRPDLQ#
XSJUDGH1#
/HDG0LQ#
$#GRPDLQ#XSJUDGH#ZLOO#DIIHFW#
VHYHUDO#QHWZRUN#VHUYLFHV1#
&DUHIXO#SODQQLQJ#LV#UHTXLUHG#
WR#PDLQWDLQ#UHOLDEOH#QHWZRUN#
FRQQHFWLYLW\1#
'HOLYHU\#7LS#
8VH#WKH#VOLGH#WR#SRLQW#RXW#
HDFK#VHUYLFH#WKDW#ZLOO#EH#
GLVFXVVHG#LQ#WKLV#VHFWLRQ1#
# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH##6#



3URYLGLQJ#5HOLDEOH#'16#6HUYLFHV#

(IIHFW#RI#DQ#8SJUDGH#RQ#'16#6HUYLFHV
z
=RQHV#FDQ#EH#FRQILJXUHG#WR#DFFHSW#659#UHVRXUFH#UHFRUG#
UHJLVWUDWLRQV
z
5HVRXUFH#UHFRUGV#FDQ#EH#G\QDPLFDOO\#XSGDWHG

8SJUDGLQJ#'16#6HUYHUV

'16#8SJUDGH#&RQVLGHUDWLRQV
z
:LQGRZV#5333#'16#DQG#:LQGRZV#17#713#'16#PXVW#EH#
PDQDJHG#ZLWK#WKHLU#RZQ#'16#PDQDJHPHQW#WRROV
z
$FWLYH#'LUHFWRU\0LQWHJUDWHG#]RQHV#FDQQRW#EH#UHSOLFDWHG#
EHWZHHQ#GRPDLQV
z
:LQGRZV#5333#'16#VHUYHUV#FDQ#EH #PDVWHU#VHUYHUV#IRU#
:LQGRZV#17#713#'16#VHUYHUV


Windows 2000 depends on DNS as a locator service for its clients to find
important Windows 2000 services. During an upgrade to Windows 2000, it is
essential to migrate the Windows NT 4.0 DNS service to Windows 2000 as
quickly as possible to provide the required support for SRV resource records.
These are used to locate network servers hosting Lightweight Directory Access
Protocol (LDAP) or Kerberos authentication.

7KH#(IIHFW#RI#DQ#8SJUDGH#RQ#'16#6HUYLFHV#
Upgrading the primary DNS server to Windows 2000, or switching the primary
zone to be hosted on a Windows 2000 server, gains the immediate benefit of
enabling the configuration of zones to accept SRV resource record registrations
and dynamic updates of resource records. DNS zones hosted on a Windows
2000 domain controller can also be configured as Active Directory Integrated.
8SJUDGLQJ#'16#6HUYHUV#
Your upgrade plan must include upgrading any Windows NT 4.0 DNS services
to Windows 2000 DNS services and moving the writable copy of the DNS zone
data to Windows 2000. You can do this in one of two ways:
„# Upgrade the existing Windows NT 4.0 server containing the DNS primary
zone to Windows 2000 and then configure the zone to allow dynamic
updates.

If the primary zone is stored on a primary domain controller (PDC), the
Active Directory Installation wizard will start after the upgrade is
completed. You can configure the zones to allow updates before the wizard
is completed.

6OLGH#2EMHFWLYH#
7R#GHWHUPLQH#D#VWUDWHJ\#IRU#
SURYLGLQJ#UHOLDEOH#'16#
VHUYLFHV#GXULQJ#D#GRPDLQ#
XSJUDGH1#
/HDG0LQ#
3ULRU#WR#SURPRWLQJ#WKH#ILUVW#
GRPDLQ#FRQWUROOHU#LQ#WKH#ILUVW#
GRPDLQ/#'16#VHUYLFHV#PXVW#
EH#LQVWDOOHG#WKDW#VXSSRUW#
659#UHFRUGV1#

'HOLYHU\#7LS#
5HPLQG#VWXGHQWV#WKDW#$FWLYH#
'LUHFWRU\#LQWHJUDWHG#]RQHV#
FDQ#RQO\#EH#LPSOHPHQWHG#RQ#
GRPDLQ#FRQWUROOHUV1#,I#'16#LV#
LQVWDOOHG#RQ#D#PHPEHU#
VHUYHU/#LW#FDQ#RQO\#EH#D#
SULPDU\#RU#VHFRQGDU\#'16#
VHUYHU1#
#
(PSKDVL]H#WKDW#$FWLYH#
'LUHFWRU\#LQWHJUDWHG#]RQHV#
DUH#UHFRPPHQGHG#IRU#DQ\#
'16#GRPDLQV#WKDW#ZLOO#
FRQWDLQ#$FWLYH#'LUHFWRU\±
UHODWHG#UHVRXUFH#UHFRUGV1#
#
.H\#3RLQWV#
,I#DW#OHDVW#RQH#'16#VHUYHU#LV#
QRW#XSJUDGHG#WR#:LQGRZV#
5333/#659#UHFRUGV#UHTXLUHG#
E\#$FWLYH#'LUHFWRU\#PXVW#EH#
PDQXDOO\#DGGHG1#
7LS#
7# # 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#


„# Install a new Windows 2000 server and configure it as the secondary DNS
server for the existing zone. After the zone transfer has taken place, reverse
the roles so that the Windows 2000 DNS server is the primary DNS server

for the zone. The zone can then be configured to allow dynamic updates.

After a domain controller with the DNS service is upgraded to
Windows 2000, convert the DNS zone to Active Directory Integrated to
take advantage of secure dynamic updates and multi-master writes.


If you do not upgrade the Windows NT 4.0 DNS service to Windows 2000 on
at least one DNS server, you must manually add all Windows 2000–related
SRV resource records to the zone text file at the primary DNS server.

In the Windows NT 4.0 DNS Manager, SRV records will appear as
generic resource records in the interface; however, queries to a Windows NT
4.0 DNS server for SRV resource records will succeed.

'16#8SJUDGH#&RQVLGHUDWLRQV#
To minimize the impact of your domain upgrade on DNS services, consider the
following:
„# Windows 2000 DNS and Windows NT 4.0 DNS must be managed with
their own DNS management tools. Windows NT 4.0 DNS cannot be
managed with the Windows 2000 DNS management tool, and vice versa.
Similarly, the Windows NT 4.0 DNS tool cannot be run on a Windows 2000
Server, and vice versa.
„# Active Directory-integrated zones cannot be replicated between domains. If
you require zones to be hosted on DNS servers in different domains, you
will need to configure DNS servers in domains other than the local domain
to be secondary DNS zones.
„# Windows 2000 DNS servers can be master servers for Windows NT 4.0
DNS servers. Likewise, Windows NT 4.0 DNS servers can be master
servers for Windows 2000 DNS servers.


7LS#
1RWH#
# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH##8#


3URYLGLQJ#5HOLDEOH#1HW%,26#5HVROXWLRQ#6HUYLFHV#

(IIHFW#RI#DQ#8SJUDGH#RQ#1HW%,26#5HVROXWLRQ#6HUYLFHV
z
1R#HIIHFW#RQ#1HW%,26#UHVROXWLRQ#RU#WKH#:,16#VHUYLFH#
WKDW#VXSSRUWV#UHVROXWLRQ

5HPRYDO#RI#WKH#:LQGRZV#,QWHUQHW#1DPH#6HUYLFH
z
,I#DOO#FRPSXWHUV#DQG#DSSOLFDWLRQV#LQ#:LQGRZV#5333#
IXQFWLRQ#ZLWKRXW#XVLQJ#1HW%,26 QDPLQJ#VHUYLFHV

'HWHUPLQLQJ#WKH#1HHG#IRU#:,16
z
5XQ#3HUIRUPDQFH#FRQVROH#IRU#D#:LQGRZV#,QWHUQHW#1DPH#
6HUYLFH#VHUYH U#DQG#H[DPLQH#WKH#FRXQWHUV=#
7RWDO#1XPEHU#RI#5HJLVWUDWLRQV26HF#
4XHULHV26HF#
6XFFHVVIXO#4XHULHV26HF


NetBIOS names are used to uniquely identify networking clients and resources.
Windows NT 4.0 uses the Windows Internet Name Service to support NetBIOS
name resolution. Although the Windows Internet Name Service is unnecessary

in a Windows 2000 network, it should not be discontinued until you are certain
that all computers and applications on the network can function without using
NetBIOS name resolution services.
7KH#(IIHFW#RI#DQ#8SJUDGH#RQ#1HW%,26#5HVROXWLRQ#
6HUYLFHV#
An upgrade to Windows 2000 will not affect NetBIOS resolution or the WINS
that supports NetBIOS resolution.
During the upgrade of a Windows Internet Name Service server, the Windows
Internet Name Service will fail during the first restart of the newly upgraded
computer as its database automatically converts to a newer version of the Jet
database. After the conversion is completed, the service will function properly
and maintain all previous records and replication configurations.

Windows Internet Name Service servers can be managed from both
Windows NT 4.0 and from the Windows 2000 toolset.

5HPRYDO#RI#WKH#:LQGRZV#,QWHUQHW#1DPH#6HUYLFH#
You can discontinue the use of the Windows Internet Name Service after the
network is completely migrated to Windows 2000 and all computers and
applications on your network can function without using NetBIOS naming
services. Determining these dependencies is the primary planning issue.
6OLGH#2EMHFWLYH#
7R#GHWHUPLQH#\RXU#FXUUHQW#
XVDJH#RI#1HW%,26#QDPHV#VR#
WKDW#\RX#FDQ#HYDOXDWH#WKH#
SRVVLELOLW\#RI#UHPRYLQJ#WKH#
:LQGRZV#,QWHUQHW#1DPH#
6HUYLFH#DIWHU#WKH#XSJUDGH1#
/HDG0LQ#
:,16#LV#QRW#UHTXLUHG#LQ#D#

SXUH#:LQGRZV#5333#
HQYLURQPHQW1#+RZHYHU/#
GXULQJ#D#GRPDLQ#XSJUDGH#
\RX#ZLOO#VWLOO#QHHG#LWV#
VHUYLFHV1#
.H\#3RLQWV#
8SJUDGLQJ#D#:LQGRZV#17#
713#:,16#VHUYHU#WR#
:LQGRZV#5333#GRHV#QRW#
DIIHFW#WKH#VHUYLFH#RU#LWV#
FRQILJXUDWLRQV1#
#
3ODQQLQJ#WR#UHPRYH#:,16#LV#
WKH#SULPDU\#SODQQLQJ#LVVXH1#
#
(PSKDVL]H#WKDW#LI#1HW%,26#
LV#QR#ORQJHU#UHTXLUHG#RQ#WKH#
QHWZRUN/#1HW%,26#QDPH#
UHVROXWLRQ#UHTXHVWV#PXVW#QRW#
EH#VHQW#WR#WKH#:LQGRZV#
,QWHUQHW#1DPH#6HUYLFH#
VHUYHU#+RQO\#UHJLVWUDWLRQV#
DQG#UHOHDVHV,1#
1RWH#
9# # 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#


If you no longer need NetBIOS resolution services on your network, keeping
the Windows Internet Name Service will burden your network with
unnecessary network traffic related to WINS replication and NetBIOS name

registration, and releases sent to the Windows Internet Name Service servers. If
clients have NetBIOS over Transmission Control Protocol/Internet Protocol
(TCP/IP) enabled, they will continue to broadcast name registrations and
releases.

You can disable NetBIOS on Windows 2000 clients by clicking Disable
NetBIOS over TCP/IP on the WINS tab of Advanced TCP/IP Settings for a
network adapter. Alternatively, you can disable it under Advanced Scope
Options for a DHCP scope by clicking the Microsoft Disable NetBIOS option
under Microsoft Windows 2000 Options.

'HWHUPLQLQJ#WKH#1HHG#IRU#:,16#
To determine if WINS is still required to support NetBIOS name resolution, use
the Performance console administrative tool for a Windows Internet Name
Service server and examine the following counters.
Counter Meaning Explanation

Windows Internet Name
Service Server: Total
Number of
Registrations/Sec
Total number of
unique and group
registrations received
per second.
Consider removing the Windows
Internet Name Service server if
the registrations are zero. This
indicates that there are no clients
registering names with the

Windows Internet Name Service
server.
Queries/Sec Rate at which the
Windows Internet
Name Service server
receives NetBIOS
queries.
A zero value indicates that
NetBIOS name resolution is no
longer taking place. A value
greater than zero might indicate
the continued need for the
Windows Internet Name Service.
Successful Queries/Sec Rate at which the
Windows Internet
Name Service server
successfully resolves
NetBIOS queries.
A zero value indicates that
NetBIOS names are not being
resolved successfully. Compare
this to Queries/Sec. If both are
zero, NetBIOS names are not
being resolved through this
Windows Internet Name Service
server. If queries are taking place
but there are few successful
queries, then NetBIOS name
resolution is taking place.
However, the necessary servers

are not registering or there are
problems with your Windows
Internet Name Service replication
topology that are preventing all
NetBIOS records to be replicated
to all Windows Internet Name
Service servers.
1RWH#
# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH##:#


3URYLGLQJ#5HOLDEOH#'+&3#6HUYHU#6HUYLFHV#
Planning for a DHCP Server Upgrade
1
Upgrade DHCP Server
2
Upgraded DHCP Server cannot
assign IP addresses, provide backup
for DHCP services
3
Authorize DHCP Server
4
IP address assignment is re-enabled
DHCP
Client
DHCP
DHCP
OU
OU
OU

OU
OU
OU
OU
OU
OU
1
1
1
2
2
2
3
3
3
4
4
4


Active Directory requires that the TCP/IP protocol be implemented on the
network. Using DHCP, clients can be automatically configured with TCP/IP
addresses and TCP/IP configuration. A Windows NT 4.0 DHCP server can
provide its services to Windows 2000 and downlevel clients and servers
configured for dynamic address assignment.
7KH#(IIHFW#RI#DQ#8SJUDGH#RQ#'+&3#6HUYHUV#
Dynamically assigned IP addresses will not be distributed during a DHCP
server upgrade. When a Windows NT 4.0 Server is upgraded, the DHCP server
database will be automatically converted to a newer Jet database version. Until
the conversion is complete, DHCP will temporarily register errors in the

system log.
3ODQQLQJ#IRU#D#'+&3#6HUYHU#8SJUDGH#
If DHCP Server services are in use in the domain that you intend to upgrade,
ensure that your upgrade plan includes the following additional steps:
„# Provide backup DHCP services. During the upgrade, the DHCP server will
be unable to provide DHCP-assigned addresses. A backup DHCP server
must be provided to renew DHCP leases that expire during the upgrade
process.
„# Define a process to authorize the upgraded DHCP servers. After upgrade,
the DHCP Server service will be unable to service DHCP requests until a
member of the Enterprise Admins group authorizes the server in Active
Directory. This prevents unauthorized DHCP servers from being
implemented on the network and assigning unapproved TCP/IP addresses to
clients.

6OLGH#2EMHFWLYH#
7R#GHWHUPLQH#D#VWUDWHJ\#IRU#
SURYLGLQJ#UHOLDEOH#'+&3#
6HUYHU#VHUYLFHV#GXULQJ#D#
GRPDLQ#XSJUDGH1#
/HDG0LQ#
'XULQJ#WKH#XSJUDGH#RI#D#
'+&3#VHUYHU/#WKH#'+&3#
6HUYHU#VHUYLFH#ZLOO#EH#
XQDEOH#WR#SURYLGH#'+&30
DVVLJQHG#DGGUHVVHV#WR#
FOLHQWV1#7KH#JRDO#LV#WR#
PLQLPL]H#WKDW#LQWHUUXSWLRQ1#
.H\#3RLQWV
#

$#'+&3#VHUYHU#ZLOO#IDLO#WR#
UHQHZ#OHDVHV#RU#SURYLGH#LWV#
VHUYLFHV#GXULQJ#XSJUDGH1#
#
%DFNXS#IRU#'+&3#VHUYLFHV#
PXVW#EH#SURYLGHG#ZKLOH#WKH#
VHUYHUV#DUH#EHLQJ#XSJUDGHG1#
#
8SJUDGHG#'+&3#VHUYHUV#
PXVW#EH#DXWKRUL]HG#LQ#$FWLYH#
'LUHFWRU\#DIWHU#XSJUDGH1#
#
'HOLYHU\#7LS#
8VH#WKH#VOLGH#WR#H[SODLQ#
ZKDW#KDSSHQV#ZKHQ#D#
'+&3#VHUYHU#LV#XSJUDGHG#
DQG#WKH#VWHSV#WKDW#PXVW#EH#
DGGHG#WR#DQ#XSJUDGH#SODQ#WR#
HQVXUH#WKDW#WKH#'+&3#
VHUYHU#SURYLGHV#UHOLDEOH#
VHUYLFH#GXULQJ#D#GRPDLQ#
XSJUDGH1#
;# # 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#


6XSSRUWLQJ#/$1#0DQDJHU#5HSOLFDWLRQ#

(IIHFW#RI#DQ#8SJUDGH#RQ#5HSOLFDWLRQ#6HUYLFHV
z
/$1#0DQDJHU#UHSOLFDWLRQ#VHUYLFH#LV#UHPRYHG#IURP#WKH#XSJUDGHG#

FRPSXWHU
z
)LOH#5HSOLFDWLRQ#VHUYLFH#KDQGOHV#DOO#UHSOLFDWLRQ#LQ#D#:LQGRZV#5333#
QHWZRUN

3ODQQLQJ#WR#,QWHJUDWH#5HSOLF DWLRQ #6HUYLFHV
z
,GHQWLI\#DOO#:LQGRZV#17#713#H[SRUW#DQ G#LPSRUW#VHUYHUV
z
&UHDWH#D#EULGJH#EHWZHHQ#WKH#:LQGRZV#17#713#VFULSWV#GLUHFWRU\#DQG
:LQGRZV#5333#1(7/2*21#VKDUH
z
0DLQWDLQ#WK H#EULGJH#EHWZHHQ#UHSOLFDWLRQ#V\VWHPV
z
5HFRQILJXUH#WKH#/$1#0DQDJHU#UHSOLFDWLRQ#VHUYLFH
z
'HFRPPLVVLRQ#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.
LAN Manager replication service and FRS are distinct services with different
configurations. With LAN Manager replication service, a single server (usually
a domain controller) hosts an export directory, and a number of domain
controllers or member servers import the contents of the export directory to an
import folder stored on the server. FRS automatically configures every domain
controller to host a replicated System Volume (SYSVOL). Changes made to the
contents of the SYSVOL at any domain controller are replicated in multiple-

master fashion to all other domain controllers in the domain. Only domain
controllers can host the SYSVOL.
7KH#(IIHFW#RI#DQ#8SJUDGH#RQ#5HSOLFDWLRQ#6HUYLFHV#
A non-upgraded export server will continue to replicate the contents of its
export directories to non-upgraded import servers. As Windows NT .0 domain
controllers are upgraded, the LAN Manager replication service is removed.
When the last Windows NT computer is upgraded to Windows 2000, the LAN
Manager replication service will be fully removed from the domain.
Maintaining LAN Manager replication remains important while Windows NT
4.0 domain controllers, configured to provide logon scripts and System
Policies, are present in the domain and are authenticating clients.
6OLGH#2EMHFWLYH#
7R#PDLQWDLQ#17/0#SURWRFRO#
UHSOLFDWLRQ#IXQFWLRQDOLW\#DIWHU#
WKH#:LQGRZV#5333#)LOH#
5HSOLFDWLRQ#VHUYLFH#LV#
LPSOHPHQWHG1#
/HDG0LQ#
%HFDXVH#:LQGRZV#5333#
GRHV#QRW#VXSSRUW#/$1#
0DQDJHU#UHSOLFDWLRQ/#\RX#
QHHG#WR#GHYHORS#D#VWUDWHJ\#
IRU#FRH[LVWLQJ#ZLWK#WKH#)LOH#
5HSOLFDWLRQ#VHUYLFH1#
'HOLYHU\#7LS
#
0DNH#VXUH#VWXGHQWV#DUH#QRW#
FRQIXVHG#E\#/$1#0DQDJHU#
UHSOLFDWLRQ/#)56/#DQG#PXOWL0
PDVWHU#UHSOLFDWLRQ1#

#
([SODLQ#ZKDW#KDSSHQV#WR#
/$1#0DQDJHU#UHSOLFDWLRQ#
ZKHQ#DQ#LPSRUW#RU#H[SRUW#
VHUYHU#LV#XSJUDGHG1#
#
(PSKDVL]H#WKH#UHDVRQV#ZK\#
WKH#WZR#UHSOLFDWLRQ#VHUYLFHV#
QHHG#WR#EH#LQWHJUDWHG1#
#
(PSKDVL]H#HDFK#VWHS#WKDW#
PXVW#EH#DGGHG#WR#DQ#
XSJUDGH#SODQ#WR#LQWHJUDWH#
WKH#WZR#UHSOLFDWLRQ#VHUYLFHV1#
#
6WUHVV#WKH#LPSRUWDQFH#RI#
PRYLQJ#WKH#H[SRUW#VHUYLFHV#
RII#WKH#3'&/#VLQFH#LW#PXVW#EH#
XSJUDGHG#ILUVW1#
#
(PSKDVL]H#WKDW#D#%'&#
FRQILJXUHG#DV#DQ#H[SRUW#
VHUYHU#PXVW#EH#XSJUDGHG#
ODVW/#VR#WKDW#UHSOLFDWLRQ#GRHV#
QRW#KDYH#WR#EH#UHFRQILJXUHG1#
# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH##<#


3ODQQLQJ#WR#,QWHJUDWH#5HSOLFDWLRQ#6HUYLFHV#
Integrating the LAN Manager replication service with FRS will ensure that

clients reliably receive required logon scripts and System Policies, regardless of
the version of the operating system running on the authenticating domain
controller. Integrating the two services will also ensure that updates made to
these files are propagated to all domain controllers in the domain.
To reliably provide logon scripts and System Policies to clients in a domain that
is being upgraded, it is important that an upgrade plan define the following
steps to integrate the LAN Manager replication service and FRS:
„# Identify all Windows NT 4.0 export and import servers.
If the export server is the PDC, move the export services to another
computer. This allows the PDC to be upgraded and allows LAN Manager
replication to continue to replicate scripts and policies for the non-upgraded
backup domain controllers (BDCs) remaining in the domain.

If the export server is a BDC, ensure that it is upgraded last so
that you do not have to redefine the export server for LAN Manager
replication.

„# Create a bridge between the Windows NT 4.0 scripts directory and the
Windows 2000 NETLOGON share.
The Windows 2000 Resource Kit contains a script file named lbridge.cmd
that is used to keep the NETLOGON share in Windows 2000 synchronized
with the Windows NT 4.0 export server. Files are copied from the Windows
2000 NETLOGON share to the Windows NT 4.0 export directory structure.
They are not copied in the reverse direction. The contents of the Windows
NT 4.0 export directory will be replaced by the contents in the Windows
2000 NETLOGON share.

Make Windows NT 4.0 administrators aware of this change
because they cannot continue to update logon scripts and System Policies at
the Windows NT 4.0 export server.


„# Maintain the bridge between the replication systems.
Scheduled Tasks in the Windows 2000 Control Panel can be configured to
periodically run the lbridge.cmd script. An interval of two hours is
commonly configured.
„# Reconfigure the LAN Manager replication service as the upgrade proceeds.
As you upgrade each import server to Windows 2000, remove the upgraded
server from the list of servers to which the export server replicates.
„# Decommission the bridge between the replication systems.
The LAN Manager replication configuration will cease when the final
Windows NT 4.0 computer involved in directory replication is upgraded to
Windows 2000. At this time, the lbridge.cmd task can be removed from the
Schedule Tasks listing.

,PSRUWDQW#
'HOLYHU\#7LS#
5HYLHZ#WKH#GLUHFWRULHV#LQ#
:LQGRZV#17#713#WKDW#KROG#
VFULSWV#DQG#6\VWHP#3ROLFLHV/#
DQG#WKDW#DUH#FRPPRQO\#
UHSOLFDWHG#
V\VWHPURRW?V\VWHP65?UHSO?#
H[SRUW?VFULSWV#DQG#
V\VWHPURRW?V\VWHP65?UHSO?#
LPSRUW?VFULSWV#IROGHUV1#$OVR#
UHYLHZ#WKDW#WKH#1(7/2*21#
VKDUH#LV#QRZ#ORFDWHG#ZLWKLQ#
WKH#6<692/#IRU#:LQGRZV#
5333#+V\VWHPURRW?V\VYRO?#
V\VYRO?GRPDLQ1FRP?VFULSWV,1#

#
7KH#OEULGJH1FPG#VFULSW#FDQ#
EH#FRQILJXUHG#WR#XVH#HLWKHU#
[FRS\#RU#DQRWKHU#:LQGRZV#
5333#5HVRXUFH#.LW#XWLOLW\#
FDOOHG#URERFRS\1#5RERFRS\#
LV#SUHIHUUHG#EHFDXVH#LW#LV#
DOVR#DEOH#WR#GHWHUPLQH#
ZKHWKHU#ILOHV#KDYH#EHHQ#
GHOHWHG#LQ#WKH#VRXUFH#IROGHU1#
7KLV#DOORZV#VFULSWV#WKDW#KDYH#
EHHQ#GHOHWHG#LQ#WKH#VRXUFH#
WR#DOVR#EH#GHOHWHG#LQ#WKH#
WDUJHW#IROGHU1#
,PSRUWDQW#
43# # 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#


6XSSRUWLQJ#5HPRWH#$FFHVV#6HUYLFHV#

(IIHFW#RI#DQ#8SJUDGH#RQ#5RXWLQJ#DQG#5HPRWH#$FFHVV
z
$FWLYH#'LUHFWRU\#GRHV#QRW#DFFHSW#TXHU\LQJ#RI#REMHFW#
DWWULEXWHV#WKURXJK#18//#VHVVLRQV
z
:LQGRZV#17#713#5$6#DQG#55$6#VHUYHUV#UHTXLUH#18//#
DFFHVV#WR#XVHU#GLDO0LQ#SURSHUWLHV#IURP#$FWLYH#'LUHFWRU\

3URYLGLQJ#5HOLDEOH#5HPRWH#$FFHVV#'XULQJ#8SJUDGH
z

*UDQW#WKH#EXLOW0LQ#D FFRXQW/#(YHU\RQH/#SHUPLVVLRQV#WR#
UHDG#XVHU#REMHFW#DWWULEXWHV
z
8SJUDGH#DOO#:LQGRZV#17#713#5$6#DQG#55$6#VHUYHUV DV#
VRRQ#DV#SRVVLEOH


Windows NT 4.0 Routing and Remote Access Service (RRAS) provides users
with remote access to the corporate network. After a remote access server is
upgraded to Windows 2000, it will continue to function as it did in a Windows
NT 4.0 environment.
The main issue with remote access during a domain upgrade occurs when one
or more Windows NT 4.0 domain controllers have been upgraded, and
downlevel remote access servers are still present. 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.
7KH#(IIHFW#RI#DQ#8SJUDGH#RQ#5RXWLQJ #DQG#5HPRWH#$FFHVV#
RAS and RRAS in Windows NT 4.0 use the LocalSystem account to determine
if a user has dial-in permissions and whether any other dial-in settings, such as
call-back phone numbers, have been configured.
When a service logs on as LocalSystem, it logs on with NULL credentials,
meaning that the service does not provide a user name or password. By default,
Active Directory does not accept querying of object attributes through NULL
sessions. In a mixed environment, remote users will be successfully authorized
only in the following situations:
„# A Windows NT 4.0 RAS or RRAS member server in a mixed-mode
Windows 2000 domain contacts a Windows NT 4.0 BDC to determine user
dial-in properties. This is identical to the previous Windows NT 4.0
behavior.


In this scenario, there is no way to guarantee that the member
server will contact a Windows NT 4.0 BDC, as opposed to a Windows 2000
domain controller, to determine dial-in properties.

6OLGH#2EMHFWLYH#
7R#GHWHUPLQH#D#VWUDWHJ\#IRU#
SODQQLQJ#VXSSRUW#IRU#UHPRWH#
DFFHVV#VHUYLFHV#GXULQJ#WKH#
XSJUDGH#SURFHVV1#
/HDG0LQ#
,Q#JHQHUDO/#LW#LV#D#JRRG#LGHD#
WR#XSJUDGH#WKH#5RXWLQJ#DQG#
5HPRWH#$FFHVV#VHUYHUV#
HDUO\#LQ#WKH#XSJUDGH#SURFHVV#
.H\#3RLQWV#
(PSKDVL]H#WKDW#5$6#DQG#
55$6#VHUYLFHV#DUH#
XQDIIHFWHG#ZKHQ#XSJUDGHG1#
+RZHYHU/#LI#GRZQOHYHO#
UHPRWH#DFFHVV#VHUYHUV#DUH#
SUHVHQW#LQ#D#:LQGRZV#5333#
HQYLURQPHQW/#WKH#VXFFHVV#RI#
5$6#FRQQHFWLYLW\#FRXOG#EH#
LQWHUPLWWHQW1#
#
'HVFULEH#KRZ #5$6#DQG#
55$6#XVH#WKH#/RFDO6\VWHP#
DFFRXQW#DQG#WKH#SUREOHPV#
WKLV#FUHDWHV#LQ#D#:LQGRZV#
5333#GRPDLQ1#

#
(PSKDVL]H#WKDW#XQOHVV#5$6#
RU#55$6#VHUYLFHV#DUH#RQO\#
LQVWDOOHG#RQ#%'&/#RU#$FWLYH#
'LUHFWRU\#VHFXULW\#KDV#EHHQ#
UHOD[HG/#WKH#VXFFHVV#RI#GLDO0
LQ#FRQQHFWLYLW\#FRXOG#EH#
LQWHUPLWWHQW1#,W#LV#LPSRVVLEOH#
WR#FRQILJXUH#WKH#5$6#RU#
55$6#VHUYHU#WR#FRQWDFW#D#
%'&#RQO\#IRU#DXWKHQWLFDWLRQ1#
,I#D#:LQGRZV#5333#GRPDLQ#
FRQWUROOHU#DXWKHQWLFDWHV#WKH#
XVHU/#GLDO0LQ#ZLOO#IDLO1#
,PSRUWDQW#
# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH# # 44#


„# A Windows NT 4.0 RAS or RRAS server that is also a BDC in a mixed-
mode Windows 2000 environment will successfully authorize dial-in users
by accessing its local Security Accounts Manager (SAM) database.

In this scenario, if Windows 2000 Routing and Remote Access
servers are present in the domain, there is no way to guarantee that a user
will contact a downlevel server when dialing in.

3URYLGLQJ#5HOLDEOH#5HPRWH#$FFHVV#'XULQJ#8SJUDGH#
Planning is necessary to ensure that a user dialing in will be reliably granted
remote access during an upgrade while the domain is operating in a mixed
environment.

To allow Windows NT 4.0 RAS or RRAS server to reliably retrieve user
properties when operating in a mixed Active Directory environment, your
upgrade plan must include provisions for the following:
„# In a mixed- or native-mode Windows 2000 domain, grant the built-in
account, Everyone, permission to read user object attributes. This can be
accomplished in one of the following two ways:

When upgrading the first domain controller, select Permission
compatible with pre-Windows 2000 server when configuring the
Active Directory Installation wizard. This adds the Everyone account to
the Pre-Windows 2000 Compatible Access local group.

If the first domain controller has already been upgraded, manually add
the Everyone account to the Pre-Windows 2000 Compatible Access
local group with the command
net localgroup “Pre-Windows 2000
Compatible Access” Everyone /add
.


Using the Everyone group workaround has the effect of relaxing
domain security and should be used only after understanding its impact on
Active Directory security.


After all remote access servers have been upgraded to Windows 2000,
you can strengthen permissions by removing the Everyone group from the
membership list of the Pre-Windows 2000 Compatible Access group.

„# Upgrade all Windows NT 4.0 RAS and RRAS servers as soon as possible.

This may alleviate the necessity of relaxing domain security to allow NULL
sessions to read user object attributes. Once all remote access servers have
been upgraded, dial-in users will be reliably authorized.

Windows 2000 remote access servers can be configured uniformly by
using Remote Authentication Dial-In User Service (RADIUS) servers. For
more information, see course 1562B, Designing a Microsoft Windows 2000
Networking Services Infrastructure.

'HOLYHU\#7LS#
&RYHU#HDFK#SRLQW#LQ#WKLV#
VHFWLRQ#VR#WKDW#VWXGHQWV#DUH#
FOHDU#RQ#ZKDW#QHHGV#WR#
KDSSHQ#WR#SURYLGH#UHOLDEOH#
UHPRWH#DFFHVV#GXULQJ#DQ#
XSJUDGH1#
#
<RX#PD\#ZLVK#WR#
GHPRQVWUDWH#KRZ#WR#DGG#WKH#
(YHU\RQH#DFFRXQW#WR#WKH#
3UH0:LQGRZV#5333#
&RPSDWLEOH#$FFHVV#ORFDO#
JURXS1#
#
$VN#VWXGHQWV#ZKDW#WKH#
LPSDFW#LV#WR#GRPDLQ#VHFXULW\#
LI#WKH#JURXS#(YHU\RQH#FDQ#
UHDG#DOO#XVHU#REMHFW#
DWWULEXWHV1#
#

%HFDXVH#PRVW#FRPSDQLHV#
KDYH#PXOWLSOH#UHPRWH#DFFHVV#
VHUYHUV/#LW#PD\#EH#GLIILFXOW#WR#
XSJUDGH#WKHP#DW#WKH#VDPH#
WLPH#LQ#D#ZD\#WKDW#DYRLGV#
UHOD[LQJ#GRPDLQ#VHFXULW\1#
,PSRUWDQW#
&DXWLRQ#
7LS#
1RWH#
45# # 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#


3ODQQLQJ#IRU#,QWHUDFWLRQ#%HWZHHQ#*URXS#3ROLF\#DQG#6\VWHP#3ROLFLHV#

(IIHFW#RI#DQ#8SJUDGH#RQ#6\VWHP#3ROLFLHV
z
,I#:LQGRZV#5333#FOLHQWV#DUH#DXWKHQWLFDWHG#E\#D#:LQGRZV#
5333#GRPDLQ#FRQWUROOHU/#JURXS#SROLF\#LV#DSS OLHG#
z
,I#:LQGRZV#5333#FOLHQWV#DUH#DXWKHQWLFDWHG#E\#D#:LQGRZV#
17#713#GRPDLQ#FRQWUROOHU/#V\VWHP#SROLFLHV#DUH#DSSOLHG
z
:LQGRZV#17#713#FOLHQWV#FDQ#UHFHLYH#RQO\#V\VWHP#SROLFLHV

3ROLF\#8SJUDGH#&RQVLGHUDWLRQV
z
'HWHUPLQH#WKH#PRVW#DSSURSULDWH#PHWKRG#IRU#PLJUDWLQJ#
:LQGRZV#17#713#6\VWHP#3ROLF\#VHWWLQJV
z

5HPRYH#:LQGRZV#17#713#6\VWHP#3ROLFLHV#IURP#WKH#
QHWZRUN#DIWHU#DOO#FOLHQW#FRPSXWHUV#KDYH#EHHQ#PLJUDWHG#WR#
:LQGRZV#5333


Windows NT 4.0 System Policies do not migrate to Windows 2000
automatically. If a Windows NT 4.0 client managed by a Windows 2000 server
is upgraded to Windows 2000, then it receives only Active Directory Group
Policy settings.
7KH#(IIHFW#RI#DQ#8SJUDGH#RQ#6\VWHP#3ROLFLHV#
When a Windows 2000 domain controller authenticates Windows 2000 clients,
group policy is applied. If Windows NT 4.0 domain controller authenticates a
Windows 2000 client, system policies are applied. If the user account is located
in one type of domain, and the computer account in another, additional factors
need to be considered.

Group Policies are only applied to Windows 2000 clients. They are not
applied to Windows NT 4.0 clients at any time. For more information on policy
behavior in a mixed environment, see Chapter 23, “Defining Client
Administration and Configuration Standards”, in the Windows 2000 Server
Deployment Planning Guide on the Student Materials compact disc.

6OLGH#2EMHFWLYH#
7R#GHWHUPLQH#D#VWUDWHJ\#IRU#
WUDQVLWLRQLQJ#IURP#:LQGRZV#
17#713#6\VWHP#3ROLFLHV#WR#
:LQGRZV#5333#*URXS#
3ROLF\1#
/HDG0LQ#
6\VWHP#3ROLFLHV/#ZKLFK#DUH#

DSSOLHG#WR#GRZQOHYHO#
:LQGRZV#FOLHQWV/#GR#QRW#
DXWRPDWLFDOO\#PLJUDWH#WR#
:LQGRZV#53331#
1RWH#
# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH# # 46#


3ROLF\#8SJUDGH#&RQVLGHUDWLRQV#
When planning for policy application, include the following decision points in
your upgrade plan:
„# Determine the most appropriate method for migrating Windows NT 4.0
System Policy settings. Options include migrating the current settings using
the gpolmig.exe resource kit utility, or processing both System Policy and
Group Policy in a mixed environment. In addition, all System Policies
persist in the registry because they are not written to the \Software\Policies
tree. This occurs because any policies outside of the \Software\Policies tree
are not removed when a user logs off from the network.
„# After all client computers have been migrated to Windows 2000, Windows
NT 4.0 System Policies can be removed from the network by deleting the
Ntconfig.pol file from the NETLOGON share of a Windows 2000 domain
controller. FRS will ensure that the file is deleted from all other domain
controllers in the domain.

47# # 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#


0LJUDWLQJ#DQG#$SSO\LQJ#/RJRQ#6FULSWV#
Logon
Logoff

Startup
Shutdown
\\server\netlogon\script.bat
\\server\netlogon\script.bat
Windows 2000 OnlyWindows NT and
Windows 2000
User-based
Logon Scripts
User Policy
Computer Policy


When a domain controller is upgraded to Windows 2000, user-based logon
scripts stored in the NETLOGON share are unaffected and will continue to be
available when clients authenticate. The FRS synchronizes the contents of this
folder with all Windows 2000 domain controllers. To synchronize the contents
of this folder with domain controllers in the domain not yet upgraded, the LAN
Manager replication service must be bridged with FRS.
Downlevel clients will continue to process the user-based logon scripts stored
in the NETLOGON share. Windows 2000 clients will run any user-assigned
logon scripts that are located in the NETLOGON share, as well as any scripts
assigned to the user or computer through Group Policy.
Logon scripts assigned to Windows 2000 clients through Group Policy are
applied at the site, domain, and organizational unit (OU) level. Group Policy
logon scripts that can be deployed in addition to or in replacement of the user-
based scripts include:
„# Logon. Applied before the shell is applied to the user.
„# Logoff. Applied as the user logs off from the computer, before the logon
screen is displayed.
„# Startup. Applied to computers and will run before the Windows logon

prompt is displayed.
„# Shutdown. Applied when the computer is shut down, after the user has
logged off from the computer.

6OLGH#2EMHFWLYH#
7R#GHWHUPLQH#D#VWUDWHJ\#IRU#
WUDQVLWLRQLQJ#IURP#:LQGRZV#
17#713#ORJRQ#VFULSWV#WR#
:LQGRZV#5333#*URXS#
3ROLF\1#
/HDG0LQ#
8VHU0EDVHG#ORJRQ#VFULSWV#
VWRUHG#RQ#:LQGRZV#17#713#
GRPDLQ#FRQWUROOHUV#DUH#
XQDIIHFWHG#ZKHQ#WKH#VHUYHU#
LV#XSJUDGHG1#
.H\#3RLQWV#
/RJRQ#VFULSWV#DUH#QRW#
DIIHFWHG#ZKHQ#D#GRPDLQ#
FRQWUROOHU#LV#XSJUDGHG1#
#
$Q#XSJUDGHG#:LQGRZV#5333#
GRPDLQ#FRQWUROOHU#FDQ#DSSO\#
ORJRQ#VFULSWV#LQ#WKH#
1(7/2*21#VKDUH#WR#DQ\#
FOLHQW1#
#
$Q#XSJUDGHG#:LQGRZV#5333#
GRPDLQ#FRQWUROOHU#FDQ#DSSO\#
D#YDULHW\#RI#VFULSWV#GHILQHG#LQ#

*URXS#3ROLF\#RQO\#WR#
:LQGRZV#5333#FOLHQWV1#
#
'HOLYHU\#7LS#
3RLQW#RXW#WR#VWXGHQWV#WKDW#
VLQFH#*URXS#3ROLF\#FDQQRW#
EH#DSSOLHG#WR#XVHUV/#WKH\#
PD\#KDYH#VLWXDWLRQV#WKDW#
UHTXLUH#WKH#XVH#RI#QRQ±
*URXS#3ROLF\#ORJRQ#VFULSWV1#
# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH# # 48#


These logon scripts are stored in the SYSVOL folder that is replicated between
domain controllers and will only be applied to Windows 2000 clients.

The Windows Script Host, available in Windows 2000, processes MS-
DOS
®
-based logon files, in addition to Microsoft Visual Basic
®
, Scripting
Edition (VBScript) and JScript
®
files not limited by the syntax of the MS-DOS
batch files commonly used in user-based logon scripts.

1RWH#
49# # 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#



‹‹
#0DLQWDLQLQJ#6HFXULW\#'XULQJ#DQ#8SJUDGH#

0LJUDWLQJ#5HVRXUFH#$FFHVV#&RPSRQHQWV

0LJUDWLQJ#7UXVW#5HODWLRQVKLSV

3ODQQLQJ#IRU#6HFXULW\#3ROLF\#$SSOLFDWLRQ

+RZ#8VHU#3URILOHV#$UH#$IIHFWHG#E\#'RPDLQ#8SJUDGH

&OLHQW#6XSSRUW


An upgrade to Windows 2000 will affect virtually every aspect of a network’s
security infrastructure. User accounts, group accounts, trust relationships, and
security templates are all altered or reorganized to take advantage of new
Active Directory features.
6OLGH#2EMHFWLYH#
7R#GHWHUPLQH#D#
FRPSUHKHQVLYH#VWUDWHJ\#IRU#
PDLQWDLQLQJ#VHFXULW\#GXULQJ#
D#GRPDLQ#XSJUDGH1#
/HDG0LQ#
$#GRPDLQ#XSJUDGH#VWUDWHJ\#
VKRXOG#LQFOXGH#PDLQWDLQLQJ#
FXUUHQW#VHFXULW\#OHYHOV#
GXULQJ#WKH#XSJUDGH#SURFHVV1#
'HOLYHU\#7LS#

5HPLQG#VWXGHQWV#WKDW#
VHFXULW\#WHPSODWHV#ZHUH#ILUVW#
LQWURGXFHG#LQ#:LQGRZV#17#
6HUYLFH#3DFN#7#ZLWK#WKH#
6HFXULW\#&RQILJXUDWLRQ#
(GLWRU1#
# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH# # 4:#


0LJUDWLQJ#5HVRXUFH#$FFHVV#&RPSRQHQWV#
SID:
S-15-48430FA4-18AC01D7-5301355C-3F3

6,'V#$UH#0 DLQWDLQHG

'$&/V#DQG#3HUPLVVLRQV#$UH#0DLQWDLQHG

*URXS#0HPEHUVKLS#,V#0DLQWDLQHG

7UXVWV#$UH#0DLQWDLQHG
55
S-15-48430FA4-18AC01D7-5301355C-3F3
Resource


In both Windows NT 4.0 and Windows 2000, discretionary access control lists
(DACLs) provide access to resources. A Windows 2000 upgrade should not
affect resource access because of the way that components of resource access
are maintained. No additional planning is necessary.
The following resource access components are maintained during the domain

upgrade:
„# Security identifiers (SIDs). All user and group SIDs are maintained during
the domain upgrade. A primary SID will change only when an account is
moved between domains during a restructure, or if a security principal is
deleted and recreated with the same name.
„# Group Membership. User accounts retain the same group membership
attributes after a domain upgrade.
„# Share permissions and NTFS file system permissions. During a domain
upgrade, all NTFS and share permissions will be maintained with the same
groups and users referenced within the DACL.
„# Registry permissions. All registry permissions are maintained during the
domain upgrade.
„# Trust relationships. Upgraded domain controllers continue to recognize any
trusts that exist with other downlevel Windows NT domains.

6OLGH#2EMHFWLYH#
7R#GHVFULEH#KRZ#:LQGRZV#
5333#KDQGOHV#UHVRXUFH#
DFFHVV#GXULQJ#D#GRPDLQ#
XSJUDGH1#
/HDG0LQ#
$#:LQGRZV#5333#GRPDLQ#
XSJUDGH#VKRXOG#QRW#DIIHFW#
UHVRXUFH#DFFHVV1#
4;# # 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH#


0LJUDWLQJ#7UXVW#5HODWLRQVKLSV#
Upgrade
Upgrade

Upgrade
ACCT2
ACCT2
RES1
RES1
ACCT1
ACCT1

Existing Trust Relationships that
Map to Default Active Directory
Trust Relationships Are Converted
into Transitive Trust Relationships

Remaining Trust Relationships Are
Converted into Transitive Shortcut
Trust Relationships
Shortcut
Trust
Shortcut
Trust
ACCT1
ACCT1
ACCT2
ACCT2
RES1
RES1
Empty
Root
Empty
Root

Active Directory
Domains
Windows NT Domains


In Windows 2000, trusts are, by default, two-way and transitive in nature. As
you upgrade domains to join the forest, one-way trust relationships in Windows
NT 4.0 domains are automatically reinterpreted and implemented as Windows
2000 trusts. Some one-way trusts become two-way transitive trusts in the new
environment. Others are redefined as shortcut trusts, depending on the order in
which the domains are upgraded and the domain parent-child relationships in
the Active Directory domain hierarchy.
7KH#(IIHFW#RI#DQ#8SJUDGH#RQ#7UXVW#5HODWLRQVKLSV#
No additional steps are required to migrate trust relationships. Each domain that
is upgraded as a child domain will establish a two-way transitive trust between
itself and its parent domain. Domains upgraded as roots of separate trees will
also be linked by a two-way transitive trust. Existing one-way trusts that do not
map to default Windows 2000 trust relationships are maintained, but
reinterpreted as shortcut trusts.

Shortcut trusts can be deleted; however, the default transitive trust
relationships established between domains in a forest cannot.


For information on using shortcut trusts to improve network
performance, see Chapter 9 of the Windows 2000 Server Deployment Planning
Guide, “Designing the Active Directory Structure,” on the Student Materials
compact disc.

6OLGH#2EMHFWLYH#

7R#GHILQH#WKH#ZD\V#WR#
WUDQVODWH#WUXVW#UHODWLRQVKLSV#
LQWR#$FWLYH#'LUHFWRU\#
GRPDLQV1#
/HDG0LQ#
'XULQJ#DQ#XSJUDGH/#WKH#ROG#
:LQGRZV#17#WUXVW#
UHODWLRQVKLSV#DUH#WUDQVODWHG#
LQWR#QHZ#UHODWLRQVKLSV#ZLWKLQ#
WKH#$FWLYH#'LUHFWRU\#GRPDLQ#
VWUXFWXUH1#
'HOLYHU\#7LS#
/HDG#VWXGHQWV#WKURXJK#ZKDW#
KDSSHQV#WR#WKH#WUXVW#
UHODWLRQVKLSV#DV#HDFK#
GRPDLQ#LQ#WKH#VOLGH#LV#
XSJUDGHG#WR#:LQGRZV#53331#
#
%H#VXUH#WR#KLJKOLJKW#KRZ#WKH#
RQH0ZD\#WUXVW#UHODWLRQVKLS#
EHWZHHQ#5(64#DQG#$&&74#
ZLOO#FKDQJH#WR#D#WZR0ZD\#
WUXVW#UHODWLRQVKLS#ZKHQ#
5(64#MRLQV#WKH#IRUHVW#DIWHU#
WKH#XSJUDGH1#
#
$OVR#KLJKOLJKW#WKH#IDFW#WKDW#
WKH#RQH0ZD\#WUXVW#WKDW#
H[LVWHG#EHWZHHQ#5(64#DQG#
$&&75#ZLOO#EH#UHSUHVHQWHG#

DV#D#VKRUWFXW#WUXVW#LQ#
:LQGRZV#53331#7KLV#LV#
EHFDXVH#WKLV#WUXVW#
UHODWLRQVKLS#LV#QRW#RQH#RI#WKH#
GHIDXOW#IRUHVW#WUXVWV/#EXW#GLG#
H[LVW#LQ#:LQGRZV#17#713#WR#
KHOS#DXWKHQWLFDWLRQ#
SHUIRUPDQFH1#
,PSRUWDQW#
1RWH#
# 0RGXOH#7=#0LQLPL]LQJ#WKH#,PSDFW#RQ#1HWZRUN#2SHUDWLRQV#'XULQJ#DQ#8SJUDGH# # 4<#


3URWHFWLQJ#5HVRXUFH#6HFXULW\#
In Windows NT 4.0 domains, one-way trust relationships prevent user accounts
and groups in resource domains from being added to DACLs for resources
located in account domains.
With the upgrade to Windows 2000, migrated one-way trust relationships will
translate to two-way trust relationships. When a Windows NT 4.0 domain
model is upgraded, transitive trusts allow users and groups from any domain to
be recognized by any member computer in the forest and included in groups or
DACLs.
While this will not affect the previous security assignments, this does allow
users and groups to be assigned access to resources that were not possible with
just the one-way trust relationship. You can take the following steps to prevent
any security assignments from changing:
„# Audit memberships in all administrative groups to ensure that new accounts
have not been added to the memberships. If membership in administrative
groups is maintained, this should prevent any users without administrative
privileges to suddenly gain these privileges.

„# Review DACLs for important resources. While it may be time-prohibitive
to review all DACLs for all resources, by focusing on key resources for the
organization, you can confirm that security has not been compromised.

.H\#3RLQWV#
%HFDXVH#RI#WKH#ZD\#WUXVW#
UHODWLRQVKLSV#DUH#
UHLQWHUSUHWHG#DIWHU#DQ#
XSJUDGH/#DGPLQLVWUDWRUV#LQ#
DQ\#GRPDLQ#ZLOO#EH#DEOH#WR#
JUDQW#SHUPLVVLRQ#WR#ORFDO#
UHVRXUFHV#WR#XVHUV#UHVLGLQJ#
DQ\ZKHUH#LQ#WKH#IRUHVW1#
#
'HOLYHU\#7LS#
0DNH#VXUH#VWXGHQWV#
XQGHUVWDQG#WKDW#HYHQ#
WKRXJK#SHUPLVVLRQV#DQG#
DGPLQLVWUDWLYH#JURXS#
PHPEHUVKLS#DUH#QRW#DOWHUHG#
GXULQJ#XSJUDGH/#WUXVWV#DOORZ#
DGPLQLVWUDWRUV#DFFHVV#WR#
DFFRXQWV#WKDW#WKH\#PD\#QRW#
KDYH#SUHYLRXVO\##EHHQ#DEOH#
WR#DFFHVV1#

×