Virtual Migration Part 5 - Resource Remapping

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

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

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

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

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.