PasswordCopy Issue

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

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

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.