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...

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.

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.

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.

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.