Windows Domain Migration

How to Disable Win7 and Win2008R2 UAC

2011-04-03T14:40:00.000-07:00

To manage, migrate or run remote migration apps on Windows Vista, Windows 7, Windows 2008 and Windows 2008R2, the User account control must be disabled.

Open an elevated command prompt as administrator.
To disable the UAC, run the following commands:

%windir%\System32\cmd.exe /k %windir%\System32\reg.exe ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f

and optionally, the following command to suppress all elevation consent request and notification:

%windir%\System32\cmd.exe /k %windir%\System32\reg.exe ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v ConsentPromptBehaviorAdmin /t REG_DWORD /d 0 /f

The WADMigrator Warm and Fuzzies

2010-11-12T20:52:00.000-08:00

Acitve Directory Migration With Minimal End-User Impact.

The Winzero Active Directory Domain Migrator was designed with least end user impact foremost in mind. This was achieved by reducing any impact on the source domain during the migration process.

By understanding the processes involved during each migration phase is to understand that at any time during the migration the source domain remains untouched until the final step where the end user’s account is enabled in the target domain and their workstation is cut over to join the target domain.

Migration Steps
During the account, contact and group migration, new accounts are created in the target domain, accounts are not moved. The new security accounts in the target domain all have new SIDs and their original SIDs are appended to each target account’s SIDHistory. NO impact on source accounts.

Once the accounts and groups are recreated in the target domain, their SIDs are matched in an account migration table with the original source accounts for both users and groups. The table is laid out in four columns: source UNCName, target UNCName, source SID and target SID. Once again NO impact on source accounts.

After the migration tables are created, all resources in the source domain, servers and workstations, are reACLed by appending the target name or SID to each object thereby creating a state of co-existence between all objects in the source domain and target domain. In other words; regardless whether the source or target account is trying to access any resource: files, folders, shares, profile objects or email, both accounts have the same access to each resource. Again NO impact on source accounts.

During the final phase of the migration, referred to as the cutover, workstations and/or servers are migrated to the target domain. During this process the source accounts of the selected users are disabled and their target accounts are enabled just prior to moving the accounts workstation to the target domain. The workstation reboots and joins the new domain. This is the only impact on the source domain: the user account is disabled and the computer is moved to the target domain.

Rollback Plan
If for any reason the migration or subset of a migration must be reversed, WADMigrator would be used to:
A) enable the source accounts, disable the target user accounts and
B) migrate the migrated workstations back to the source domain.
All the original source domain user accounts and group accounts with the original rights and permissions still exist, untouched in the source domain.

During all phases of the migration the source domain is not touched or restructured in any way. Only until the source domain controllers are removed will the properties of the source domain cease to exist in its original form.

Active Directory Domain Migration Checklist

2009-08-18T19:53:00.000-07:00

Before beginning an Active Directory migration, a number of mandatory requirements are needed to be in place in order to complete the migration successfully. These requirements are standards to meet both the requirements for Microsoft Windows migration and the Winzero Active Directory Migrator.

Download the Domain Migration Checklist

New Release: Winzero TakeControl

2009-04-08T09:51:00.000-07:00

Winzero new product release: TakeControl allows administrators to gain administrative access to files, folders and shares without destroying the original permissions by appending the Administrators group SID to ACLs.

The Challenge
To gain access to files and folders, Administrators can take ownership and grant full access control permissions and rights to themselves if they want to modify, rename or delete these files or folders. During this process the original permissions are removed.

The Solution
Grant Administrators full control to files, folders or shares without taking ownership or destroying the original permission using Winzero TakeControl.

Avoid Take Ownership

Using standard Windows functions, if you must access a file or a folder that you do not have rights to, you must take ownership of that file or folder. When you do this, you replace the security permissions that were originally created for the file or folder.

Winzero TakeControl uses an append process to add the Administrators group with full control to each folder ACL and file ACL. without changing the original NTFS permission.

Download a fully functional trial version or learn more how TakeControl can help with profile migration and server migration projects.

Top 5 Interforest Active Directory Migration Tips

2009-02-16T10:24:00.000-08:00

Migrating between Microsoft's Windows Active Directory forests can be an intimidating project. This article provides 5 Active Directory migration tips that are bound to save IT pros time and aspirin.

1. Plan, plan, plan

Planning is the best way to a smooth Active Directory migration.

The most common error is a lack of planning. Don't horribly underestimate the impact … an AD migration. Research the impact thoroughly and properly develop migration plans.

At the end of a thorough evaluation, IT pros will know their AD requirements for structure, security, bandwidth, hardware and timeline. AD is not forgiving, so it's easier to get it right the first time than try to clean up afterward.

2. Ask for help

Going it alone is a sure-fire way to blow it. Try not to reinvent the wheel.

Not asking for help before starting the project is asking for trouble and results in the same mistakes our experts have seen – and solved – many times.

3. Ensure redundancy

A lack of server redundancy can be the costliest of AD blunders. Except for single-server environments, a minimum of two domain controllers should be installed for load-balancing and failover.

4. Enlist expert support

Recruit a migration expert, as needed, at the start of the migration project to avoid pit falls. Keep the migration expert available, as required, during the begining phases of the project to help guide the success of the project.

5. Use advanced Migration tools.

There are 3 major migration software tools on the market from Quest software, netIQ and Winzero technologies.

Test the tools in a lab, compare cost to benefit and choose the tool that can more easily meet the challenges and issues what will be faced during the migration process.

WADMigrator Premigration Checklist

2009-02-12T15:21:00.000-08:00

Administrative Access:
Create a 2 way trust betwen each source and target domain.
Add both the source and targets Domain Admins group, the Enterprise Admins group to each domains Administrators group.

Create or select an account on the target domain and add it to Domain Admins, Enterprise Admins and Schema Admins Group.
Use the above account as the migration account to perform the migration as well as for the service account.
Enable this account to logon locally and run as a service on both the source and target PDC Emulator.

Domain Policy:
verify that IPFiltering is turned off on both domains
Verify that Windows Firewall is turned off as a group policy

http://domainreconfigure.blogspot.com/search/label/Step%203%20Virtual%20Migration

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.

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

Enable Auditing:
Enable Account Management sucess and failure Auditing for both the domain and domain controller for both the source and target domain.
You will need to reboot the server for the auditing to take effect.

Register DLLs:
On the target domain PDC emulator register clonepr.dll.
Copy Clonepr.dll to the Windows directory from the WADMigrator working directory.
Open the command prompt
Type regsrv32 drive:\Windows\clonepr.dll to successfully register the dll.

Password Policies:
Check and verify that the source minimum domain password policy and restrictions less or equally restrictive to any target 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.

After installation of WADMigrator Verify the following registry setting on both the target and sourec PDC emulators.

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)

Winzero Releases WADMigrator

2009-02-06T09:49:00.001-08:00

Winzero Releases the next solution in Active Directory Migration Challenges - Winzero Active Directory Migrator ensuring coexistence between migrated and un-migrated users, simplifing the migration processes with automated resource updating and continued support during and after the migration process.

Whether migrating to meet specific economic challenges or undergoing acquisition, mergers or divestitures, Winzero Active Directory Migrator provides the features necessary to meet your evolving needs and budget.

PasswordCopy Issue

2008-11-11T10:00:00.000-08:00

Bulletin: 111108

Software Effected:
ServerMigrator, PasswordCopy and WADMigrator

Issue:
Just recently Microsoft has released an update that is preventing passwordcopy from accessing the system32 directory that a number of our clients started experiencing in the last week.

Solution:
We have identified this issue and have resolved it. There will be a new ServerMigrator and PasswordCopy available starting November 12th that over rides the password copy problem some of our clients were experiencing.

New Update Releases:
ServerMigrator2007 version 5.10
PasswordCopy32 version 3.00
WADMigrator version 5.00

* PasswordCopy Server Edition and Domain Edition will be repalced with PasswordCopy32 followed by PasswordCopy64.

Virtual Migration Part 6 Custom Remaping

2008-10-26T10:07:00.000-07:00

Once the common update process of associating source and target accounts for servers and workstations are complete, the Virtual Consultant will use Winzero addons and scripts to associate source and target SIDs for additional resource that are not part of a standard migration.

The Virtual Consultant will follow a set of guidelines to verify that all unique directories and applications that rely on Netbios Name or SID access are updated.

Using Winzero Update Process Addons
The virtual consultant will verify and update resources as needed using the Winzero Migration Addon Tools for the following resources to maintain coexistance during the migration process.

Roaming or mandatory profiles
Exchange 5.5 account associations
Exchange 200x account associations
SQL Server upto version 7
SQL Server 2000/2005
NAS and SAN Server permissions

Using Winzero Custom Scripting
Using the Winzero scripting utility, the Virtual Consultant will identify any unique applications that require updating and automate the update process for:

Any inhouse applications

Once the update process is complete, the Virtual Consultant will conduct a controlled migration of a typical user to verify that all access to resources has been maintained.

Virtual Migration Part 5 - Resource Remapping

2008-08-02T16:24:00.000-07:00

The most crucial aspect of the migration is the Update process. This is how the new target SIDS are associated with the Source SIDS. This processes runs locally on each computer and may take any where from 2 minutes to 5 minutes for workstations and 4 minutes to 6 hours on servers. Because this process is multitasked the total time required is the time required to update the largest server and to locate all workstations. In order for the updater to successfully execute on the remote machine the computer must be online, reachable through DNS or WINS and the account used for the update must have administrative rights locally on the remote computer.

The Virtual Consultant will begin the update process and continue to update all workstations and servers until all computers have been updated using the report information gathered from the Directory Object Extractor Reports.

The Update process runs on the remote computer in the background without disruption to the logged on user. The process appends the target SID of the migrated object every where the source SID has rights or permissions. The Update process appends Local group membership, Share, Folder and File permissions, local profiles, mapped drives, connected printers and user rights.

Using the update method, two essential migration requirements are met. One the virtual consultant running the migration project knows exactly which user and computers are ready to be cut over to the target domain and most importantly the end user now has the exact same rights and permissions in the target domain as they had in the source domain including the same desktop and profile settings.

Virtual Migration Part 4 - SIDHistory

2008-07-08T10:38:00.000-07:00

Once the mapping files are created and saved, the virtual consultant will perform the SIDHistory portion of the domain migration.

The SID History task allows the source SID of security identified users and groups to be appended to each accounts sIDHistory attribute in Active Directory. The SIDHistory attribute adds an extra token to the accounts security access to resources.
All Winzero domain migrations always utilizes both SIDHistory and the REACL process to maximize endusers access to their resources.

Before begining the sIDHistory migration, the following additional dependencies are required.

Success and failure auditing of account management for both source and target domains.
Windows NT and 200x source domains call this user and group management auditing.

An empty local group in the source domain that is named {SourceNetBIOSDom}$$$.

Check the registry so that:
HKEY_LOCAL_MACHINE
System\CurrentControlSet\Control\LSA\TcpipClientSupport
key is set to 1 on the source domain primary domain controller or PDC Emulator.

You must restart the source domain primary domain controller or PDC emulator after the registry configuration.

If the target domain is a Windows 200x domain, Windows security requires user credentials with administrator rights in the target domain.

Virtual Migration Part 3 - Windows Firewall

2008-06-20T14:12:00.000-07:00

Disabling the Windows Firewall for Windows XP 2000 Vista workstations

Before migrating computers (Workstations) to the target domain, create a domain policy to disable Windows Firewall. Computers that have difficulties joining domains tend to automatically set the Windows Firewall by deault, thereby locking out remote access and managemet of the workstation.

Disabling the Windows Firewall
This step describes the method for turning off the Windows Firewall for use only by IT administrators on managed systems.

Note that you still need some kind of firewall protection, so don't disable the Windows Firewall unless you have appropriate firewall software installed at the network level.

From the Start menu, select Run, then enter gpedit.msc.
Expand the Computer Configuration folder, then the Administrative Templates folder.
Expand the Network folder, then the Network Connections folder, then the Windows Firewall folder.
Select the Standard Profile folder.
Double-click the Windows Firewall: Protect all network connections option.
Select Disabled, then click OK.
Select the Domain Profile folder.
Double-click the Windows Firewall: Protect all network connections option.
Select Disabled, then click OK.
Close the Group Policy dialog box.
Disabling the Firewall Using Group Policy

This method is for IT administrators with administrative access to UT-managed machines that are part of a Windows 2000 or 2003 Active Directory domain.

Create a new Group Policy object, and give the object a descriptive name (for example, ITS-Turn off Windows Firewall).
Select the newly created group policy.
Right-click on the newly created policy and select Edit.
Expand the Computer Configuration folder, then the Administrative Templates folder.
Expand the Network folder, then the Network Connections folder, then the Windows Firewall folder.
Select the Standard Profile folder.
Double-click the Windows Firewall: Protect all network connections option.
Select Disabled, then click OK.
Select the Domain Profile folder.
Double-click the Windows Firewall: Protect all network connections option.
Select Disabled, then click OK.
Close the Group Policy dialog box.
In the Security Filter section, click Add.
Search for the objects that this group policy will be applied to, then click OK.
Close the Group Policy editor.

Virtual Domain Migration Part 2

2008-06-10T14:48:00.000-07:00

Preparing the Target domain

Having completed part one of the Virtual Domain Migration, the focus of part two will be to install the Winzero migration tools in the target domain and perform the account migration to the target domain.

The onsite resource will need to logon to a computer in the Target domain with an administrative account and install five Winzero software products: ADSearch, DomainReconfigure or WADMigrator, PasswordCopy Domain Edition, DNSReset and DomainManager.

Once the five products are installed on the computer in the target 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 ADSearch and save these reports to Drive:\\Winzero\ADSearch\Reports\ 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 DomainReconfigure or WADMigrator and begin the account migration process by adding the source and target domain, selecting the users and groups to migrate and migrate the accounts as disabled accounts to the target domain. This process may take a long time depending on the number of accounts in the source domain.

Once the disabled accounts are created in target domain, the Virtual Consultant will configure PasswordCopy Domain Edition to synchronize user passwords between the source and target domains on a scheduled daily bases until the final cutover is performed.

The next stage is important and the resulting account associations must be backed up; the entire migration depends on the accuracy of these three files: map.usr, map.gg and sidhistory.txt. The Virtual Consultant will perform, verify and backup the account associations of the source and target users.

At this time the source domain must be frozen. No new user accounts or groups must be created. Group membership must not be changed.

Before moving on to the next step of the Virtual Domain Migration, the Virtual consultant will verify the creation of the accounts in the target domain using ADSearch for accuraccy.

Virtual Domain Migration Part 1

2008-06-09T12:17:00.000-07:00

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

2007-10-25T14:51:00.000-07:00

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

2006-05-01T14:32:00.000-07:00

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

2006-05-01T13:54:00.000-07:00

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

2006-05-01T12:29:00.000-07:00

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?

2006-04-12T15:37:00.000-07:00

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.