ADUM Enterprise Competitive Software Upgrade.

For a limited time, if you own any Quest Software, Scriptlogic Software, ForensiT, NetIQ, Winzero or Microsoft ADMT, it is the best time to take advantage of our competitive upgrade to ADUM Enterprise reg. $649.00 for just $349.00 and learn what ADUM offers over the competition.

WHAT DO I GET?
ADUM Enterprise Edition gives you a unified unrestricted license for our ADUM Enterprise Edition Software bundle consisting of ADMigrator, ServerMigrator, PasswordCopy, SecuRED and TakeControl as well as a number of OEM and third party administrative tools including any future software releases until Dec 31, 2013.  ADUM Enterprise Edition also includes support and maintenance until Dec 31 2013

HOW MUCH AND WHEN IS IT AVAILABLE?
This offer is available now for a limited time to existing QUEST, NETIQ, Scriptlogic, ForensiT, MIcrosoft and Winzero customers for just $349.00 USD online only at this special link only.

http://www.managered.com/adum-upgrade.html

DO I QUALIFY?
If you own or use any Quest Software, Scriptlogic Software, ForensiT, NetIQ, Microsoft ADMT, ManageRED ADUM Small business, ADUM Server, Resemble or Winzero Enterprise Toolbox, ITPro Toolbox, WADMIgrator, ServerMigrator, Resemble, ACLReporter, DNSReset, PasswordCopy, SVRCompare, RemoveUnknown or any other discontinued Winzero Software now is the time to ACT!

ManageRED Software
Upgrade Now

What are the Key Differences Between ADUM and ADMT?

The main difference between ADMT and ADUM – ADMigrator is it’s coexistence during incremental migrations  and the fact that it does not 100% rely on sIDHistory.

How Does ADUM Handle Workstation Migration?

With regards to Workstations and computers, ADUM uses a remote agent scheduled to update computers locally. Once deployed every account that has been migrated and that has information on the computer resources is remapped whereby the SID of the target account (user or group) is appended where the source account is found including local groups, profiles, printers mapped drives, Outlook profiles, account rights. File, folder and share permissions. This way both the source and target account have the same profile and rights at the workstation level and the server resources level until a final cleanup is performed.

Because this feature is run prior to cutting the user over to the new domain , it is possible to stage and verify the entire migration without user impact before the user accounts are enabled in the target domain.

So, when the user is ready to be cutover to the new domain and the workstation is moved by rebooting to join it to the new domain, the target user or users are enabled in the target domain and disabled in the source domain. This feature allows for a complete or partial reversal, if for any reason the migrated accounts need to be move back to the source domain.

More ADUM - ADMigrator Features...

ADUM Active Directory Questions Answered.

ADUM ENT and SBS includes ADMigrator for domain migration, server migration  software, securtiy reporting software, password Sychronization software as well as 3rd party utilities for SQL and Sharepoint and more to facilitate a success full migration. ManageRED also includes a migration expert to get you started or a vitual expert available throughout your migration as require. Most importantly there is no per user licensing! 

ADUM Active Directory Migration  Questions and Answers.

Continuous synchronization
Password synchronization can be scheduled throughout the project for accounts that have been stage but not yet cutover. Object properties, group membership and newly created accounts  synchronization is a manual process… This feature is by design, allowing you to control the migration and be aware of the changes in the source domain throughout the migration process.

Statistics
ADUM contains both premigration and ongoing validation reporting solutions as well as continuous save results feature  for each step of the migration

Undo
Because of the nature of the migration process, during the migration both the old accounts and migrated objects exist in both domains (source accounts and target accounts have the same rights and security). At any given time only one account is enabled. The source account is enabled during the migration process with a target disabled account in the target domain. After cutover, the target account is enabled and the source account disabled. To undo the account migration is just a simple reversing the enable-disable property of the accounts. The only real  undo feature is for workstations and servers, if they need to be moved back to the source domain. The original source domain user and group objects are  never changed.

Inter-forest migration destructive or not, Intra-forest migration destructive or not Site topology migration, migration without trusts Advanced object selection capabilities Property population rules Security descriptor migration Consolidated resource updating Workstation update Laptop update Server infrastructure update Clean-up SIDHistory

ADUM does not require trust relationship (but is perferred) by installing one console in the source domain and one console in the target domain each portion of the migration is run in the domain where the action needs to take place sharing a common project.

ADUM is project based, you can create multiple projects of sub migrations with selected objects (users, groups, computers etc) or you can granualarly customize the migration by importing a text list of samAccountNames for users, groups and netBIOS UNC names for computers to limit the scope of the migration.

ADUM is completely modifiable… select or add any Active Directory attribute for user and group objects that are writable and necessary for your unique migration scenario.

ADUM uses both SIDHistory and a Remapping process in INTRA FOREST Migrations to maintain security and access to resources with an append process thus allowing for duality during the migration process where both source account and target accounts have the same access to resources.

ADUM uses Remapping process in INTER FOREST Migrations to maintain security and access to resources with an append process thus allowing for duality during the migration process where both source account and target accounts have the same access.

Both Server and Workstation (as well as  laptops)  Remapping process can be scheduled daily to maintain ACL changes during the migration period. This process uses and an append feature that appends the SID of the target account where the Source account has access inluding: files, folders, shares, rights, NTFS permissions, share permissions, profiles,  Outlook, printer access, mapped drives etc. An additional feature over rides DHCP for the default DNS server, and the primary DNS suffix list order as well as setting the default logon domain during the computer cutover stage.

Once the migration is complete and and stable the ADUM Remap Process will cleanup and remove the source SID from all resources, servers and workstations, as well as perform a sIDHistory cleanup if sIDHistory was used. During the entire process the source domain is never changed except the servers and workstation are moved to the new domain.

ADUM external domain feature: if the source object is a member of an universal security or an universal distribution  groups in any external trusted domain, the target object  can be adde to the the external domain groups using an automated process, whereby Universal security group accounts are appended and Distribution Group accounts are relaced when the accounts are cut over to the new domain.

The ADUM software bundle  is completely customizable and with the addition of utilizing a migration expert throughout the project as need, Active Directory Migrations need not be over whelming.

Learn More...

ADUM - Migration Software Without Limits

Does this sound familiar?

You are about to start a migration project; wether it is a windows domain migration or a server migration, you are faced with trying to calculate how many users, mailboxes or servers you have or that will need to be migrated.

Does this sound familiar?

In order to start this migration project you will need to form a budget committee to get approval for third party migration software that is licensed by migrated accounts or by the number of servers being migrated.

Does this sound familiar?

Just before beginning your migration, you will need to invite all the migration software developers for a meeting to see if you can get a better price then the absorbent amount originally quoted.

Because all this sounds so familiar, ManageRED Software introduces ADUM: the non-restrictive and unlimited migration software bundled solution. No per-user, no per-server and no per-operator licensing required. ADUM requires only one software bundle license without restrictions within one company. The ADUM migration software bundle is licensed to the company not the individual using the software or the number of objects being migrated.

To further enhance the ADUM concept, ManageRED Software has created three (3) software package editions: ADUM Enterprise Edition, ADUM Small Business Edition and the ADUM Server Edition.

To guarantee success of your next migration project, our ADUM migration software is now bundled with consulting services from an expert migration specialist to help you get started and guide you through your project. You may even purchase additional consulting time as your project requires or have our consultants perform the Active Directory, domain or server migration for you.

You can learn more about ADUM migration software at ManageRED Software including how you can get ADUM with virtual consulting time of a migration expert.

How to Disable Win7 and Win2008R2 UAC

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

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

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 ADUM Active Directory Migrator.

Download the Domain Migration Checklist

New Release: Winzero TakeControl

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

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

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

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

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.

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)