Troubleshooting

Cause:  All necessary configuration changes have not been made.

Solution:  Properly configure your migration environment and try the operation again.

See also:  Checklist: Before using Active Directory Migration Tool, Migration requirements, Before performing an interforest migration, and Before performing an intraforest migration

Cause:  The agent is dispatched with invalid credentials or the migration environment is not configured correctly.

Solution:  An agent is dispatched to a remote computer using the credentials of the account used to run Active Directory Migration Tool. Once installed on the remote computer, the agent runs under the local system account. The credentials that you provide to the wizard before the agent is dispatched to the remote computer are used to write results back to a share created on the computer on which Active Directory Migration Tool is running. The agent must have the right to log on locally to the remote computer, and, if the agent is used to migrate computers, it must have Administrative rights in the source domain.

To ensure that you have the correct credentials, create trusts such that the source domain trusts the target domain and the target domain trusts the source domain. Add the Domain Admins group of the target domain (target\Domain Admins) to the built-in Administrators group of the source domain (source\Administrators). Log on using the target\Domain Admins account and supply a set of credentials for the source\Administrators account when prompted. This will provide you with administrative permissions on both the source and target domains.

See also: Migration requirements

Cause:  You have an active connection, such as a mapped drive or a printer, to a computer on which an agent is being installed. The dispatch operation will fail because the credentials of the agent installation conflict with the existing set of credentials.

Solution:  Remove any active connections between the computer that is running Active Directory Migration Tool and the computer to which the agent is being dispatched.

Cause:  The agent monitor tried to connect to the agent while the agent was still initializing.

Solution:  Click Refresh one or more times to update the the Agent Monitor.

Cause:  The default administrative share for the system volume of the computer to which the agent was dispatched is not enabled.

Because the default share is not enabled, the Active Directory Migration Tool cannot read the log file.

Solution:  Reenable the default share of the system volume.

Cause:  By default, the Active Directory Migration Tool agent is installed to the folder specified by the %ProgramFiles% environment variable on the target computer. Since this environment variable does not exist by default on Windows NT 3.51 computers, the agent is installed to the %SystemRoot% folder instead.

Solution:  This is a warning message. No action is necessary.

Cause:  This can be caused by an incorrect migration environment configuration or some malfunction with either the source or target computers.

Solution:  Join the computer to a domain and create the computer account in the domain as described in the following procedures:

To change the domain membership of a computer running Windows NT 4.0 or earlier

1. Log on to the computer using an account with local administrator permissions.
2. Open the Control Panel, and then double-click Network.
3. Click Change, and then, in Domain Name, type the name of the domain you want this computer to join.

To change the domain membership of a computer running Windows 2000

1. Log on to the computer using an account with local administrator permissions.
2. On the Desktop, right-click My Computer, and then click Properties.
3. On the Network Identification tab, click Properties, and then click Domain.
4. In Domain, type the name of the domain you want this computer to join.

Notes

• To join a domain, you must enter credentials of an account with administrative permissions on the domain you want the computer to join.
• You must restart the computer to complete joining the computer to the domain.

Cause:  If the Group Policy template associated with a user whose user rights are being removed contains the nondomain-qualified name of the user (for example, if it contains User1 instead of DomainA\User1), then the remove operation will fail.

Solution:  Correct the user name entry in the Group Policy template.

Solution:  Active Directory Migration Tool creates several log files in the Logs folder under the Active Directory Migration Tools folder on the computer on which the tool is installed. User and group migration progress is recorded in Migration.log; dispatcher progress is recorded in Dispatcher.log; and the progress of the Trust Migration Wizard is recorded in Trust.log. Additionally, the progress of each agent is recorded in log files named for the computer to which the agents are dispatched. These log files are located in the Agents folder under the previously mentioned Logs folder. Each agent also records information a Dctlog.txt file which is created in the folder specified by the %TEMP% variable on each computer to which an agent is dispatched.

Cause:  You are not on a computer on which Active Directory Migration Tool has been installed.

Solution:  The agent may write log entries to the computer on which it runs. Since the agent software is removed when the agent's task is finished, you can view the event log entries on the computer to which the agent was dispatched by running the Windows 2000 Event Viewer from the computer on which Active Directory Migration Tool is installed.

Cause:  Incorrect logging level setting.

By default, Active Directory Migration Tools writes summary information to its log files. The level of detail can be increased by changing the registry entry that controls the logging level.

Solution:  On the computer on which Active Directory Migration Tool is installed, set the value of the HKEY_LOCAL_MACHINE\Software\Mission Critical Software\DomainAdmin\TranslationLogLevel registry key to 7.

Verbose logging mode is used for problem diagnosis and troubleshooting. The verbose logging mode can create very large log files, particularly in cases where large numbers of files, or other objects whose access control lists must be updated, exist on the target computer. Since the agent logs are written to the folder specified by the %TEMP% environment variable, the volume to which that environment variable points should have ample disk space. When logging in verbose mode, it may be necessary to change the value of the %TEMP% environment variable before dispatching an agent.

Cause:  When the tool generates reports, it does not automatically update the console.

Solution:  To view the reports, close and reopen Active Directory Migration Tool.

Cause: This error may occur when the Agent Monitor is closed before all agents have finished writing their results back to the Active Directory Migration Tool reporting database.

Solution:  To prevent this problem, wait until all agents have completed their tasks before closing the Agent Monitor.

Cause:  When performing an interforest migration, Active Directory Migration Tool always sets the User Must Change Password option for migrated users. If the user account has the User Cannot Change Password option set, then the target account won't be able to log on until one or both options have been changed.

Solution:  Change the options using one of the following methods:

To enable the ability to change the user password

1. In Active Directory Users and Computers, on the View menu, click Advanced Features.
2. Right-click the user, and then click Properties.
3. On the Security tab, allow the Change Password permission for Everyone and for the user.

To remove the User Must Change Password flag

• In Active Directory Users and Computers, right-click the user, and then click Reset Password.

Cause:  The user account passwords used in the old domain may violate the password restrictions in the new domain.

In an intraforest migration, user account passwords from the source domain are migrated to the target domain. If the source domain user accounts have passwords that violate the password restrictions (such as minimum length) in the target, then the affected migrated users will be unable to log on until their password has been set to a value that fits the target domain password policy.

If the users try to use the invalid passwords, their new user accounts may be locked. If you selected Close target accounts in the Migrate Users Wizard, the new user accounts will be disabled. As a result, the migrated users may not be able to log on until their accounts have been unlocked or marked as enabled.

Solution:  Reset the user account passwords to a value that fits the new domain's password policy, and enable the user accounts if they were disabled due to repeated password failure.

Cause:  Migrated users cannot log on due to password policy, even though password policies appear to be disabled.

During a migration, some administrators may choose to disable their password policies on the target domain. If they try to accomplish this by turning off the minimum password length policy without setting the password policy to zero, it is possible that the users will not be able to log on because an effective password policy is still in effect.

Solution:  Set the password policy to a length of zero. After the zero length policy is in effect, the minimum password length policy can be turned off.

Cause:  There are a number of conditions that must be satisfied for SID History migration to work.

Solution:  Properly configure the migration environment before running Active Directory Migration Tool, and review the configuration topics before proceeding with the migration.

See also: Checklist: Before using Active Directory Migration Tool, Migration requirements, Before performing an interforest migration, and Before performing an intraforest migration.

Note

• When migrating a previously migrated security principal to a new domain, the criteria for migrating SID History should be in place for all three domains.

  For example, you have the following three domains: DomainA, DomainB, and DomainC. DomainA is a Windows NT 4.0 domain. DomainB and DomainC are Windows 2000 domains operating in native mode. User1 in DomainA (DomainA\User1) was migrated to DomainB as DomainB\User1 and SID History was translated. DomainB\User1 now has the primary SID for DomainB\User1 and the SID History value for DomainA\User1. If an administrator wants to migrate DomainB\User1 to DomainC\User1 and preserve all of DomainB\User1's SIDs, then the proper configuration settings must be in place to allow migration from DomainA to DomainC and from DomainB to DomainC. If DomainA has been decommissioned, or if proper configuration cannot be satisfied between DomainA and DomainC, then Active Directory Migration Tool will migrate the SID for DomainB\User1 to DomainC\User1 and log the fact that it could not migrate the DomainA\User1 SID.

  If DomainA does not exist, ADMT will write an error message to the log, but migration will still be successful. This error message can be ignored.

Cause:  If, when migrating a group or user account, domain controllers in the source domain are no longer available, computers in domains outside the target forest that are running Windows NT 3.51, Windows NT 4.0, or Windows 2000 (in a domain operating in mixed mode) may not be able to resolve the group or user object's SID History with the target domain's Global Catalog.

As long as the source domain is accessible, the group or user account name can be resolved. The inability to resolve the account name is an administrative problem only. The inability to resolve the group or user account name through SID History does not prevent that account from having the desired access to that resource. For example, if a user shows up as "Account Unknown" in a group's membership list, that user is still a member of that group and has the rights associated with that group.

Solution:  This SID History resolution problem can be fixed by running the Security Translation Wizard to replace the source account SID with the new target account SID for all resources on all affected computers. This problem will be much more prevalent if you decommission the source account domain prior to migrating the source resource domain. Therefore, you should decommission all source domains together as the last step in the migration process.

Cause:  The settings necessary to run Active Directory Migration Tool have not been correctly established.

Most migration problems are caused by an incorrectly configured migration environment.

Solution:  Open the migration log file and find the account you migrated with SID History. If SID History was added to the account, you should see an entry similar to the following:

1999-10-06 18:28:50-SID for UserAccountName added to the SID History of UserAccountName

If you receive an error message, it's almost certain you have not configured the environment correctly, and you should review the configuration topics before retrying the migration.

For information on up-to-date information and scenarios describing the various tools and methods used to migrate Windows NT networks to Windows 2000 networks and to restructure existing Windows 2000 networks, see the Domain Migration and Restructuring tools page at the Microsoft Web site. (http://www.microsoft.com/)

See also: Checklist: Before using Active Directory Migration Tool, Migration requirements, Before performing an interforest migration, and Before performing an intraforest migration.

Cause:  This is by design. For security reasons, each user who logs on to a Windows 2000 computer receives their own, user specific Recycle Bin. The access control list (ACL) for each instance of the Recycle Bin can contain only one user specific SID. When a user's profile is migrated in Add mode, the SID of the source domain user is added to the SID History of the Recycle Bin. This essentially places two user specific SIDs in the Recycle Bin's ACL. This problem does not occur if profiles are migrated in Replace mode.

Solution:  Click Yes to the error message, and the Recycle Bin will be emptied without a problem. If you click No, the error will continue to appear until the Recycle Bin is emptied.

Cause:  This is by design.

Solution:  If you plan to use Dfs shares in your domain, you should migrate the computers first or migrate the computers and users in the same migration session.

Cause:  Active Directory Migration Tool correctly migrates the Exchange service accounts, but there is a special manual process for updating Exchange service accounts that must be completed while running Exchange. Failure to follow this process could result in system failure or data loss on the Exchange system.

Solution:  Review walkthrough material, scenarios, and other information about performing a domain migration on the Microsoft Domain Migration and Restructuring tools Web page at the Microsoft Web site. (http://www.microsoft.com/) You can also contact Microsoft Product Support Services for details on how to change the service account used by Exchange services in a site.

See also:  Resources