Virtual Domain Migration Part 1

Preparing the source domain

Before the virtual domain migration begins, the two way trust relationship between the source and target domain must be stable. Administrative rights must be in place such that the SourceDomain\Domain Admin group is a member of the TargetDomain\Administrators group and the TargetDomain|Domain Admin group is a member of the SourceDomain\Administrators group.

Review the prior three steps of Premigration:
Premigration I
Premigration II
Premigration III

The onsite resource will need to logon to a computer in the source domain with an administrative account and install four Winzero software products: DirectoryObjectExtractor, AdminAccess, Computer2User and ScheduleManager.
Once the four products are installed on the computer in the source domain, the WebEx session can begin with the Virtual Consultant.

Connect to the WebEX session as outlined in the email from the Virtual Consultant. Once the session is established, change presenter so that the Virtual Consultant has remote access to the computer.

In the first stage of the migration, the Virtual Consultant will run a series of reports using DirectoryObjectExtractor and save these reports to Drive:\\Winzero\DirectoryObjectExtractor\ in Microsoft Excel format. Zip all the reports in this folder to one file and email it to the Virtual Consultant.

After the reports are completed, the Virtual Consultant will launch AdminAccess and add the TargetDomain\Admin Group to the Computer\Administrators group to every computer in the source domain. This process may take a long time depending on the number of computers in the source domain. By adding the TargetDomain\Domain Admin group to every DC, Server and workstation in the source domain prepares the way for administrative access to all resource from the target domain. Any computers that were unreachable will need to be accomplished on a case per case basis until all computers are verified with proper access.

The next stage is important and may take some time. Using ScheduleManager, the Virtual Consultant will install and configure the Winzero Scheduling Service on every computer in the source domain configured to start automatically, run from an administrative service account from the target domain.

Before moving on to the next step of the Virtual Domain Migration, the Winzero Scheduling Service must be running on every DC, member server and workstation in the source domain.

PasswordCopy 64bit Windows

Domain PasswordCopy is not supported for 64bit version of Windows DCs. The password copy process fails with errors and the passwords are not extracted from the source or set on the target DC.

Work Around

By using a proxy 32bit Windows domain controller and replicating to the 64bit domain controllers, passwords can be copied from source to target domains.

32bit Source DC - 64bit Target DC

Add a temporary 32bit Windows Domain controller to the target domain. Move the PDC emulator to the 32bit DC. Using the Winzero CopyPassword Domain Edition, copy the passwords as normal. Once the password copy process is complete, and enough time has passed for the target domain controls to replicate, move the PDC emulator back to the target 64bit DC and remove the 32 bit Domain Controller from the target domain.

64bit Source DC - 32bit Target DC

Add a temporary 32bit Windows Domain controller to the source domain. Move the PDC emulator to the 32bit DC. Using the Winzero CopyPassword Domain Edition, copy the passwords as normal. Once the password copy process is complete, and enough time has passed for the target domain controls to replicate, move the PDC emulator back to the source 64bit DC and remove the 32 bit Domain Controller from the source domain.

64bit Source DC - 64bit Target DC

Add a temporary 32bit Windows Domain controller to both the source and target domains. Move the PDC emulator of each to the 32bit DC. Using the Winzero CopyPassword Domain Edition, copy the passwords as normal. Once the password copy process is complete, and enough time has passed for the domain controls to replicate, move the PDC emulator back to the 64bit DC and remove the 32 bit Domain Controller from the source and target domain.

Pre-Migration III

Preparing the Source Domain

For the purposes of this document, the Source domain can be a Windows NT4, 2000 or 2003 domain.

Administrative Access:
Using Winzero AdminAccess verify that all computers including workstations, domain controllers and servers have the source domain’s Domain Admins Group as a member of the local domain Administrators Group. Install AdminAccess in the source domain verify or add the Domain Admin Group to every computer in the domain.

DNS Configuration:
Once the target domain’s DNS server is configured and running, configure the DNS network card clients of the source domain computers to point to the new DNS Server and add the new domain to the domain suffix list.

Install Winzero DNSReset in the source domain. Select all computers (servers, workstations and domain controllers and set the new DNS serve IP address as the primary DNS Server and set the domain suffix of the new domain as the first and primary domain suffix in the domain suffix list. The DNSReset change will over ride DHCP setting before the source computers are migrated to the target domain.

If the source domain is NT4 also add the IP Address of the NT4 WINS server to all computers in the source domain.

Create a Domain Local Group
Create a Domain Local group called DomainNetBiosName$$$ example: WINZERO$$$. Add 3 $ signs to the local group name. DO NOT add members to this group.

Password Policies
Check and verify that the minimum domain password policy and restrictions are greater or equally restrictive to any source domain password policy. Passwords will not migrate if the password policy of the target domain is more restrictive then the password policy of the source domain.

Registry Settings:
Check, add and verify the registry settings of the PDC or PDC emulator or FSMO server. (Usually the first installed domain controller in the source domain)

HKEY_LOCAL_MACHINE
SYSTEM\CurrentControlSet\Control\Lsa
Key: AllowpasswordExport
Type: DWORD
Set to: 1

HKEY_LOCAL_MACHINE
SYSTEM\CurrentControlSet\Control\Lsa
Key: RestrictAnonymous
Type: DWORD
Set to: 0

HKEY_LOCAL_MACHINE
SYSTEM\CurrentControlSet\Control\Lsa
Key: TcpipClientSupport
Type: DWORD
Set to: 1

HKEY_LOCAL_MACHINE
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Key: MaxUserPort
Type: DWORD
Set to: 0x0000fffe (hex) or 65534 (decimal)

Pre-Domain Migration II

Preparing the Target Domain

Create or configure the new domain. For the purposes of this document, we will use Windows 2003 as the new target domain or an existing Windows 2003 target domain.

Domain Configuration:
Select the new domains NetBios name to be unique do not use the name of any existing domains. Example: Old NetBios Name: WINZERO. New NetBios Name: WINZEROAD. Do not use ( _ ) underscores in domain names.

Select a DNS name for the domain that does not reflect the name of a web domain or ftp domain. Example: Web: www.winzero.ca, Domain Name: winzero.dev an internal name not registered on public DNS servers. Do not use ( _ ) underscores in domain names.

Promote Windows 2003 to be a Windows 2003 domain this would be the equivalent of a Windows 2000 domain in Native mode.

Configure DNS to be Active Directory aware and reside in the target domain.
Configure the DNS network card client to point to the new DNS Server.

If a NT4 domain will be part of the migration project, point the Domain Controllers network card WINS client to the NT4 domains WINS server.

OU Creation:
Create an OU in the target domain that will contain all Administrative and service accounts. Example: NETADMINS.
Move all the Administrative accounts and administrative groups to the new OU. These accounts to move would be: Administrator, Administrators, Domain Admins, Enterprise Admins, DNSAdmins etc.

Create Service Accounts
Create one or more service accounts in the newly created Administrative OU. DO NOT prefix these accounts with symbols such as #, _ or $. These symbols are escape characters in LDAP and will present issues later. Assign domain logon locally and run as a service rights using both the domain and domain controller policies. These newly created service accounts will be used later to replace service accounts in the source domain(s).

Create a Migration Account
Create an account to be used for the migration. Create this account in the new administrative OU. Add the migration account to the Administrators Group, Domain Admins Group and the Enterprise Admins Group. Set the user rights for both domain and domain controller policies to enable logon locally and Run as a Service.

Create a Domain Local Group
Create a Domain Local group called DomainNetBiosName$$$ example: WINZEROAD$$$. Add 3 $ signs to the local group name. DO NOT add members to this group.

Pre-Windows 2000 Compatible Access Group.
Check and Verify that the Everyone group is a member of the Pre-Windows 2000 Compatible Access group. If not add the Everyone group.

Password Policies

Check and verify that the minimum domain password policy and restrictions are less or equally restrictive to any source domain password policy. Passwords will not migrate if the password policy of the target domain is more restrictive then the password policy of the source domain.

Registry Settings:
Check, add and verify the registry settings of the PDC emulator or FSMO server. (Usually the first installed domain controller in the target domain)

HKEY_LOCAL_MACHINE
SYSTEM\CurrentControlSet\Control\Lsa
Key: AllowpasswordExport
Type: DWORD
Set to: 1

HKEY_LOCAL_MACHINE
SYSTEM\CurrentControlSet\Control\Lsa
Key: RestrictAnonymous
Type: DWORD
Set to: 0

HKEY_LOCAL_MACHINE
SYSTEM\CurrentControlSet\Control\Lsa
Key: TcpipClientSupport
Type: DWORD
Set to: 1

HKEY_LOCAL_MACHINE
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Key: MaxUserPort
Type: DWORD
Set to: 0x0000fffe (hex) or 65534 (decimal)

Pre-Migration I

Migration Terminology

Migration terminology reference used in conducting a migration project with DomainReconfigure:

Migration, migrate and domain migration:
The recreation of objects such as users, groups and computer accounts with object properties from one domain to another. Although objects names maybe the same, the recreated objects are unique with new SIDs that do not retain permissions from the original domain without performing either a SIDHistory or an Update process.

SIDHistory Process:
SIDHistory process is the ability to associate an account, users or groups, to append the SID of the original account as a property to the newly created account. The new account will have access rights and permissions using the SID of the new account and the original account.
There are limitations to this method when account name is used for permissioning such as domain\account.

Update Process:
The update process is the alternate method to SIDHistory to associate original account rights and permissions to the newly created accounts. The update process appends the newly created account SID on resources where the original account SID is found. The update process appends the new account SID to files, folders, shares, registry, printers, profile, and mapped drive ACLs where the original SID is found. The new SID is also appended to any local group, domain or computer, where the original account maybe a member.

Source Domain:
Migrations are always performed in pairs regardless of the number of domains involved in the migration project. The source domain is the domain being migrated from.

Target Domain:
Migrations are always performed in pairs regardless of the number of domains involved in the migration project. The target domain is the domain being migrated to.

Roller Over:
Roller over is the process of moving a computer from one domain to another. Both workstations and servers can be rolled over to the new domain. A computer account is created in the new domain, the original account is removed from the original domain and the computer joins the new domain.

Cut Over:
Cut over is the final step of enabling the new user account as the primary user account. This process involves 3 steps, the account has been migrated, and all workstations the user has logged on to have been updated. (You can use Winzero Computer2User to associate users and workstations). When the cut over process happens, the original user account is disabled, the new account is enabled, all workstations are in the new domain and the new domain is set to be the default logon domain.