Before starting a migration, the current situation should be investigated. Issues to take care of are :
| Current network infrastructure. (Physical network, routers, switches, protocols, dial-up networking, etc.) |
| Current networking services (DHCP, WINS, DNS, RAS) |
| Current domain structure, trust and domain controller locations. |
| Current hardware clients- and servers. (hcl) |
| Current software on clients- and servers. |
| Security policies. |
| Business critical applications. |
Before an organization decides to migrate to Windows 2000, there must be a reason for the organization to migrate. These reason can be business needs ('we need more than 40.000 users in a domain), business requirements ('customers or government requires IPSec), or business goals (lower TCO). These reasons provide the business value for the migration and are the basics for the migration goals. Business value can be :
| Increased security. (Kerberos, IPSec) |
| Lower TCO. (less domains to administer, less hardware, locked-down clients, group-policy based software distribution, RIS for clients installations, etc.) |
| Increased scalability. |
| Increased productivity personnel. (Windows 2000 clients) |
The migration goals related to these business values can be :
| Certificate services must be available for IPSec. |
| Migrate user accounts to one new Windows 2000 domain from multiple NT 4.0 domains to reduce administration. |
| Make RIS available to install clients. |
| Implement group policies for lock-down clients and software distribution. |
| Data and applications must be available during upgrade. |
After the current situation and the business and migration goals are clear, an Active Directory and DNS design can be made. (See summary Active Directory) Other issues to design are the site design, administrative plan (ou's, administrative delegation, etc), recovery plan (e.g offline BDC) and security plan (Kerberos, PKI, etc).
Now that the current situation is clear, the goals are clarified and there is a new Active directory design there are three possible ways to do the migration :
| The first option is a domain upgrade. Issues concerning an
upgrade are :
| ||||||||||||||||||||||||||||||
| The second option is a domain restructure. Issues concerning a restructure are :
| ||||||||||||||||||||||||||||||
| The third option is an upgrade first with a restructure afterwards.
|
Things to keep in mind when doing a domain upgrade/structure :
| Upgrading the account domains first gives more benefits than upgrading the resource domains. Keep in mind that the first upgraded domain becomes the forest root if not other domain is available in the forest. When determining which domain to upgrade first, look which domain needs an upgrade first (SAM size, specific applications, accounts/ need to be moved to that domain) or which domain must become the forest root. An other issue can be the size. Use smaller domains to get experience with the upgrade. | ||||||
| First upgrade the servers to the latest service pack (SP6a) before doing an upgrade. | ||||||
| Use winnt32 /checkupgradeonly to check compatibility issues before upgrading a machine. | ||||||
| If there will remain pre-Windows 2000 clients in the domain, consider installing the Directory services client. (See summary Active Directory) | ||||||
| Migrate global groups before accounts are migrated. | ||||||
| The netdom utility can, just like admt, be used to move computer accounts. Computer accounts cannot be cloned. The Netdom utility must also be used to create a computer account for a new Windows NT 4.0 domain controller in a Windows 2000 mixed-mode network. | ||||||
| Windows 2000 does not support LMrepl, it uses FRS which is available on domain controllers. When using scripts, upgrade the server with the export folder last and use lbridge.cmd to duplicate the scripts between the two environments during the migration. (schedule it) Lbridge will only replicate between the Windows 2000 NetLogon share and the Windows NT 4.0 export folder, not the other way around. As after an NT 4.0 server is upgraded to Windows 2000, Lan Manager replication is not available anymore, you should remove that machine from the export server' replication partners list. | ||||||
| Windows NT 4.0 RAS service uses the LocalSystem account to connect to a
domain controller to validate the user. This connection uses a null-session.
As this is not supported in a fully secure environment (no Everyone account in
Permissions compatible with pre-Windows 2000 computers-group) there is a
chance the user is not validated. This will not happen if :
For these reasons, upgrade the RAS server early in the project to Windows 2000. |
| When a DHCP server is upgraded, no address are provided during that upgrade. After the upgrade the server must be authorized by a member of the Enterprise administrator group to start issuing addresses again. |
| Certificate services 1.0 does not automatically upgrade to version 2.0 during a Windows 2000 upgrade. Use the certutil utility to update the certificate services database and renew the CRL. |
| An upgraded machine does not have any security template loaded. Use the Security configuration and analyses tool or group policies to assign a security template if additional security is required. |
| In a mixed environment, a Windows 2000 client will receive system policies when connecting to a Windows NT 4.0 domain controller. It will receive group policies when it connects to a Windows 2000 domain controller. Clients before Windows 2000 will NOT use group policies. The resource kit utility gpolmig.exe can be used to migrate system policies to group policies. |
| When using Exchange 5.5, consider using the Active Directory connector between Windows 2000 OU's and Exchange 5.5 recipient containers. This will prevent separate information will be stored in separate databases (Exchange and Active Directory) without being replicated. |
| Watch out for profile issues of users get a new sid after a domain consolidation. |
| After a domain restructure the SIDwalker utility can be used to change the SID's on resource and to remove old SIDhistory information. There is a maximum of 1023 entries for SIDhistory on an account. |
Microsoft tools that are available for the restructure are :
The Active Directory Migration Tool can be used to import NT 4.0 security principals (users, computers and groups) into Windows 2000 Active Directory. (inter-forest) It can also be used to move Active Directory accounts between (source mixed- or native mode, target native mode) Windows 2000 domains. (intra-forest) It has the following requirements :
| The user of the ADTM must be domain administrator in both domains. |
| ADTM moves or clones security principals (users, computers and groups), ClonePrinciple clones (non-destructive) only security principals. |
| ADTM cannot clone computers accounts, it moves them just like Netdom. |
| Security principals are cloned when the domains are in a separate forest. When cloning users, the passwords will not remain. (This option is available in ADMT 2.0, released with Windows 2003 server) The users should be provided with new passwords. When moving accounts within a forest, the passwords are preserved. |
| When doing a migration from a NT 4.0 domain, the registry key hklm\System\CurrentControlSet\Control\LSA\TcpipClientSupport reg_dword ox1 must be created on the PDC in the source domain. (restart required) It enables tcp/ip to access the directory where normally named pipes are used. |
| The source (NT 4.0 domain) must at least trust the target (Windows 2000 domain) domain. ADTM can be used to create the trust. A two way trust is required if the moved users need to access the old NT 4.0 domain. |
| The target (Windows 2000 domain) domain must be in native mode to support SIDhistory. |
| The source server (PDC NT 4.0 domain) must run at least NT4.0 SP4. |
| Administrative shares must be available on the domain controllers. |
| ADMT must run on a domain controller in the target domain, preferable a FSMO holder. |
| Auditing for success- and failure of account management in both domains must be enabled when doing an intra-forest migration. |
| A local group SourceDomainName$$$ must be available on the PDC of the source domain. |
| ADMT, just like ClonePrincipal, must run on the target domain controller when cloning accounts. It can run on both the source or target domain controller when moving accounts. |
The ClonePrincipal utility is part of the support tools and exists of VBscripts that can clone users and groups (not computers) to a new Windows 2000 native mode domain in another forest. While cloning, the password is not preserved but it does use SIDhistory.. It requires NT4.0 SP4 or newer on the source domain. The support scripting on the target domain, use csript.exe. ClonePrincipal uses the following scripts :
| Clonegg.vbs. This script can be used to clone all global groups to a new Windows 2000 domain. |
| Cloneggu.vbs. This script is used to clone multiple global groups and users to the new Windows 2000 domain. |
| Clonelg.vbs. This script can be used to clone all local groups to the new Windows 2000 domain. |
| Clonepr.vbs. This script is used to clone a single global group or user to the new Windows 2000 domain. |
| Sidhist.vbs. This script copies the sid of the source account to the sidHistory of the target account. |
Active Directory object manager which is part of the support tools. Program to move users, groups and OU's between
domains within a forest. It can move computer account but this does not work.
(use Netdom) During the move, the passwords do not change. The tools
must connect to the RID master of the source domain. (mixed or native mode) The
target domain must be in native mode to support SIDhistory.
Only empty global groups can be moved. Movetree uses the movetree.log and
movetree.err log files.
Windows 2000 domain manager. Program to check and maintain Windows 2000 trusts and other domain information. It can be used to create trusts and to move or create computer accounts. Part of the support tools.
Security administration tool. Uses showaccs.exe and sidwalk.exe to view
permissions. Sidwalker.msc can be used to migrate permissions e.g when
SIDHistory is used during a domain reconstruction. It's part of the
support tools. The resource kit utility SubInACL can also be used to watch
and/or modify SIDS on files and folders.
LDP.exe (Active Directory administration tool) can be used to
view the SIDhistory information on an account.
For more info see domain migration cookbook chapter 4 'Restructuring tools' and chapter 7 'Migration of Windows NT 4.0 account domain into Active Directory'.
Last update : 19 February 2003
