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.

Why Winzero DomainReconfigure?

Winzero's DomainReconfigure enables administrators and IT Managers to perform complex Windows NT, 2000 and 2003 domain migration projects using a project based methodology.

DomainReconfigure seamlessly migrates domain users, passwords, user properties, global and domain local groups, group properties, group members, servers and worksations while maintaining current access to shares, printers, profiles, email and SQL resources.

Winzero DomainReconfigure is the choice for achieving successful migrations that are transparent to the end user, with verifiable returns on investment.


"The Success of any migration project is not measured by the number of users or groups or workstations or servers migrated or the superb OU design structure of active directory, but by the result when the migrated user logs into the new domain, that his or her desktop and access to resources is exactly the same as it was before." - Akos Sandor, VP Enterprise Solutions, Winzero.