Do you find the Support WebCast transcripts helpful?
Let us know!

Note This document is based on the original spoken Support WebCast transcript. It has been edited for clarity.

Tuanh Nguyen: The purpose of this WebCast is an introduction to the uses of the Active Directory™ Migration Tool (ADMT) in a domain migration. We will explain the concepts and terminology used in domain restructuring and the requirements needed to run ADMT. We will walk through the User Account Migration Wizard as an example. The focus of the WebCast will be limited to the discussions of the Active Directory Migration Tools in a domain migration to a Windows^® 2000 domain.

On to the next slide (slide 2). The Active Directory Migration Tool is a graphical user interface utility that uses wizards to automate migration tasks, such as moving users, groups, computers, service accounts, trust relationships, and other objects from one domain to another. This utility can be downloaded from http://www.microsoft.com/windows2000/downloads/tools/admt/default.asp.

On to the next slide (slide 3). There are two types of domain migrations. There was an error on the slide. It should read domain upgrade and restructure, not upgrade and migration.

A domain upgrade is the process of upgrading the operating system on the Windows NT^® 4.0 primary domain controller (PDC) of a domain and upgrading some or all of the backup domain controllers (BDCs) from Windows NT 4.0 to Windows 2000 Server.

A restructure, on the other hand, is a process that allows you to redesign the forest and the domain structure according to the needs of your organization. In this scenario, objects are cloned or moved from the original domain to a new domain with both the nodes coexisting. You can perform a restructure with three different scenarios — a post-upgrade, instead of an upgrade, or a post-migration.

There are two forms of domain restructures. The first is an intraforest migration. This occurs when you move objects from one domain to another domain within the same forest. This could be between a parent and child domain, or domains and different trees within the same forest. An intraforest migration can only be performed with Windows 2000 domains, due to the fact that Windows NT 4.0 domains cannot exist in the same forest as the Windows 2000 domain.

The other form of migration is an interforest migration. This is when you clone or copy objects from one domain in one forest to another domain in a separate forest. This is a scenario in which you would migrate objects from a Windows NT 4.0 domain to a Windows 2000 domain. However, you can still use this method for Windows 2000 to Windows 2000 domain migrations.

Next slide, please (slide 4). As we mentioned in the last slide, a domain upgrade is the process of upgrading the operating system on the primary domain controller of a Windows NT 4.0 domain to a Windows 2000 Server. Because this is an upgrade of the operating system rather a than fresh installation, it maintains the existing domain structure, users, and groups. In addition, because the users, groups, and computer accounts remain the same, the SIDs are unchanged, leaving resource access unaffected by the upgrade. This is important. Unlike in the domain migrations, the object SIDs will change from one domain to another.

On to the next slide (slide 5). On the other hand, a domain migration allows you to redesign the forest and the domain structure according to the needs of the organization. Therefore, you can consolidate multiple domains into one single centralized domain and reconfigure your administrative processes, sites, and security. A domain migration provides a means for fallback to the existing domain, because both domains are coexisting, until the first domain is decommissioned. Because both domains are coexisting, a timed transition can be planned to move objects to the new domain without interrupting the production environment.

Now we're going to talk about the terminology (slide 6) involved with the Active Directory Migration Tool.

A target domain is the Windows 2000 domain to which you're moving the objects. It is the destination of the objects. A source domain can be a Windows NT 4.0 domain or a Windows 2000 domain that you're moving the objects from.

Security identifiers, also known as SIDs, are domain-unique values built when a user or group is created or when the machine or trust is registered with the domain. When a user logs on, the system creates an access token for the user containing the primary SID of the user, and the SIDs of the domain groups that the user is a member of. This information is used to determine what type of access the user has to certain objects in the domain.

In Windows 2000, the domain restructuring is made considerably easier as a result of a new attribute on Windows 2000 Active Directory Security Principles, called SID history. SID history is used to store the security identifiers from the forest domain of the moved objects. When a user logs on to the target domain, not only a new SID, but also the old SID attributes are added to the user's access tokens and used to determine the user's group membership rights to resources. The SID history attribute can only be updated in native mode in Windows 2000 domains. The principal SID is required to be unique in the Windows 2000 forest; that is, it can only exist once in a target forest, whether it's a primary SID or in the SID history of any object. Therefore, SID history can only be used in two different scenarios, moving security principles between domains in the same forest, which is called intraforest, or cloning security principles between domains in different forests, also known as interforest.

In native mode, Netlogon replication is now switched to off. Replication to Windows NT 4.0 backup domain controllers will cease, and you will no longer be able to add new Windows NT 4.0 backup domain controllers to the domain. It does not inhibit the addition of other earlier-version clients, such as Windows NT 4.0 workstations or member servers. Also, in this mode, Windows 2000 group types, such as Universal, Domain Local, Distribution groups, and group nesting are also enabled.

Mixed mode provides maximum backward compatibility with earlier versions of operating systems. Therefore, Windows 2000 domain controllers and Windows NT 4.0 backup domain controllers can coexist in the Active Directory domain.

Now I'm going to turn it over to Curtis Clay. He's going to continue the rest of the presentation.

Curtis Clay III: Thank you, Tuanh. We're going to now discuss the types of objects that you can migrate to with the Active Directory Migration Tool. As you see here, you can migrate users, groups, computers, service accounts, and trust relationships (slide 7). There is a preferred method of migrating various objects (slide 8) from one domain to the other. For instance, you cannot migrate trust relationships before you migrate the machine accounts associated with these trusts.

We're going on to slide 9. These are the requirements necessary to use the Active Directory Migration Tool. Most of these requirements must be met prior to using the ADMT. The wizard will give detailed instruction as to what has to be in place and what configurations it can make on its own.

Next slide (slide 10). These requirements, as listed before, also include having a two-way trust between the target and the source domain. For the target domain that's running the ADMT, you must be a member of the Admins group. On the source domain, you must be a member of the local administrators' group.

Next slide (slide 11). These settings can be made by the ADMT during the migration wizard process. If these settings are not already in place, as we show here on this slide, the wizard will prompt you to make these changes for you. The empty group is created for internal auditing to take place on the PDC emulator of the source domain. The registry settings that we set (on this slide) are to open pipes for RPC, which is remote procedure call communication between the trusted servers.

Next slide (slide 12). These ADMT wizards, which migrate users, groups, and computers, and include the Security Translation Wizard, and Reporting Wizard, are available to you with the tool. Most of these wizards are self-explanatory.

I'm going to discuss the Security Translation Wizard. The Security Translation Wizard translates the security. What I mean by security is permissions or rights to a particular file, share, computer, or object from the source domain to the target domain. For instance, if your user was using a member server that was a file server on the source domain, and you don't want to create or re-create those shares and permissions on the target domain, or on another server on the target domain, you can use the Security Translation Wizard to reassign rights and permissions to the shares on the file server. Meaning the users in the target domain will still be able to access files and shares on the source domain simply by using the Security Translation Wizard.

Next slide (slide 13). Also among these wizards are the Service Account Migration Wizard, the Exchange Directory Migration Wizard, the Trust Migration Wizard, and the Group Mapping and Merging Wizard. You can also migrate server accounts for applications such as Exchange or SQL, using the Service Account Migration Wizard. Using the Exchange Directory Migration Wizard, you can move the Exchange directory from the source domain to your target domain.

The Trust Migration Wizard allows you to move existing trusts that are in place in the source domain. For example, if source domain A trusts domain X, using the Trust Migration Wizard you can move the trust for domain X to the target domain also.

Using the Group Mapping and Merging Wizard, you can move members of groups from the source domains and place them into groups on the target domain. Keep in mind that you cannot migrate built-in groups or users, because these groups and accounts have identical SIDs, and will not migrate over to the target domain, mostly because no two SIDs can be the same in a forest or a domain.

The Service Account Migration Wizard migrates over service accounts for a non-local service, such as Exchange or a SQL server account, service accounts that are used to run services with a set of credentials other than the local system authority. This isn't usually done, because even though the local system authority contacts have absolute control of the computer on which it operates, it has no rights on any other computer on the network.

The Active Directory Migration Tool can also change the security descriptors for Exchange mailboxes, distribution lists, custom receipts or recipients, organizations, sites, and containers, as well as the primary Windows NT or Windows 2000 account for each mailbox to reflect the SID for the new security principle in the target domain. This process ensures the new security principle or the new user has the same access to the resources and Exchange components as the original user.

Next slide (slide 14). From this point on we're going to walk through migrating over user accounts. We're only going to use screen shots here. So this is going to show us how to migrate over a user account and the various options we have at our disposal. This is only one of the wizards that's available to you, and because we're kind of limited on time, this is the only wizard we're going to walk through today.

Next slide (slide 15). In this slide, we have the option to test our migration or simply proceed without testing.

Slide 16. In this slide you can use either the NetBIOS name or the fully qualified domain name when you're selecting your target or source domain.

Next slide (slide 17). In this window, you have the opportunity to select the users being migrated from the source to the target domain. To add users, you will need to click on the Add button, and a domain browser window will appear so that you can choose what users you want to migrate from the source domain.

Slide 18. You can place these users into their own container, meaning organizational units (OU), or just simply place them into the Users container. You can click on the Browse button and the Active Directory Users and Computers window will appear so that you can choose which container to place the users in, on the target domain.

Next slide (slide 19). At present, the Active Directory Migration Tool does not migrate passwords. You have the option to create complex passwords, which is recommended, and/or a password that is the same as the user name. You'll be given the option to place the password in a file on your domain controller, and the default location is located in the Programs\Active Directory Migration Tool\passwords.text file. After the user has successfully input the correct password for the first time when logging on to the new domain, they will be prompted to change their password.

Next slide (slide 20). On this window of the wizard, we can make decisions on how to manage the accounts after the migration. We can disable the accounts immediately for either domain, the source or the target, or set the accounts to expire on the source domain after a period of time. Some users choose the option to disable accounts in the target domain, in the event that the users are not to be put in use immediately. Or you can disable the accounts in the source domain if the source domain is set to be collapsed or decommissioned immediately after the migration process is complete.

This is also where we get the option to migrate over the users' SIDs or security identifiers from the source domain. This is only necessary if the source domain is to remain functional, and the user will need to access resources in both domains.

Slide 21. Here we are given the option to translate roaming profiles. This process edits the profile directory on the source domain to include the newly created SID from the target domain, which allows the user access to their roaming profile. This ensures that the user still gets the look and feel they had in the source domain.

You can also update the user rights that the user had in the source domain or the new target domain. For instance, if the user had rights to add computers to a domain, that right would be migrated from the source domain to the target domain.

We have the option to move users or associated groups, or update group memberships if the account had been migrated incrementally. We can also assign a prefix or suffix to migrated accounts so that they can be differentiated from your normal accounts.

Next slide (slide 22). This gives us options on how to handle conflicts by either renaming, replacing, or by not migrating at all to user accounts from the source domain. In renaming, you can simply add a predetermined prefix or suffix to the conflicting accounts. With replacing, you are given the option to remove the user's rights and/or group membership from the conflicting account on the target domain.

Next slide (slide 23). Finally, as with nearly all of the wizards for Windows 2000, you get a summary of selections that we made and the option to go back and make changes.

Next slide (slide 24). This is the window you're going to see that monitors the progress of your migration. The status will appear when you click Finish, and it will show you the progress of the migration. The process can vary greatly as to how long the migration process will take, depending on the options selected, the performance of your system, and network bandwidth.

These next two slides (slides 25 and 26) give the resources and some other documentation you can use to help in migrating your domain from Windows NT 4.0 to Windows 2000, or restructuring your domain across two Windows 2000 forests.

We're now going to turn it back over to Jason so he can take some questions.

Jason Bennet: Thank you so much for that presentation, Tuanh and Curtis. Just a couple of quick notes before we move on to the Q&A portion of the Support WebCast.

To access information on all upcoming Support WebCasts and the archived content from all past WebCasts, an easy-to-remember URL is http://support.microsoft.com/webcasts/.

One-on-one product support issues are outside the scope of these Support WebCasts. If you do need technical assistance, please submit an incident on the Web, or call Microsoft Product Support Services and speak to a support professional.

First question: What does the menu option migrating from Exchange actually do?

Tuanh: If he's talking about the Exchange Migration Wizard, basically that's going to migrate over Exchange mailboxes, distribution lists, custom recipients, organizations, sites, and containers, as well as the primary Windows NT 4.0 or Windows 2000 account for each mailbox, to reflect the SID for the new security principle and the target of the domain.

Jason: If that user needs more information, please give us some clarification on what you're looking for.

Curtis: You are given the option to select as many accounts as you like when you go through the wizard. If you're going to use user migration, you can only select users. If you're going to use group migration, you can select the group, and you're given the option to move the users over that are members of that group.

It's kind of difficult to understand the question, but basically, when you click the Add button in the User Account Migration Wizard, you can select every user that you want to move over at that time. It doesn't let you do it in bulk, as in hold down the SHIFT key and select 30 users or 100 users at once. You have to select them individually. This cuts down on any mistakes or any possibility that you may migrate over a user that you weren't prepared to migrate.

Jason: Are you planning to make changes to this tool, which currently lacks features for consolidation during migration filter selection, et cetera? Where can we give feedback on this tool?

Curtis: You can give feedback through this WebCast, and there is an updated utility for this tool being created as we speak. But I do not know what features it will have or when it's going to be released.

Jason: I would like to migrate users into a new slate in Windows 2000 Active Directory, prepopulated with current information from our HR database. How can I choose to bring some attributes but not others, like descriptions? Also, why is it forcing a change on my CN, common name, to be the Windows NT account name?

Curtis: I'm not entirely sure I understand the question. When you migrate a user over, and if your schema is updated to include all the attributes of that user, they will be included in the migration.

The second part of the question is unclear to me. The CN is usually the name of the user from the Windows NT account that you're migrating from or the source domain to the target domain. You have the option to rename user accounts or assign a prefix to these user accounts using the user migration wizard.

Jason: How are Windows 95 or Windows 98 logons affected after a domain upgrade?

Curtis: That question doesn't seem to be on topic. The Windows 95 and Windows 98 client logon is still the same way they log on in Windows NT 4.0. Some clients will have to be physically moved over to the domain. In other words, their Windows 95 and Windows 98 machines may have to physically change their domain membership on those individual machines. But on Windows NT 4.0 and Windows 2000 machines, there's an agent that runs and changes their domain membership. After they reboot, they're part of the new Windows 2000 target domain. Windows 95 and Windows 98 machines don't actually join domains. They just log on to a domain. So I think that they won't be affected by this process.

Jason: I'm trying to move users from a child domain to the root domain, but in the target domain box, it only shows the root, and not the child domains. Am I setting up something incorrectly?

Tuanh: If it's a child of the parent, then the only target would be the parent domain. There will not be any other domains listed, unless there are other child domains within the forest or other trees in the forest also. So that would be by design.

Jason: I have a new site that I'm bringing up as a BDC, but since I built that server I have migrated my PDC to Windows 2000. Will my BDC now work in the new Windows 2000 domain?

Curtis: I might need some more clarification on that question. As long as your Windows 2000 domain is not in native mode, your BDC should work in that Windows 2000 domain.

Jason: I'm trying to use the Exchange Migration Wizard, and in the log file I get this message: "Unable to load Dapi.dll." I have downgraded to version 5.0, as mentioned in the Knowledge Base, but I still get the error message. Have you tried this wizard? Does it work at all, and what does it actually do?

Curtis: The Exchange Migration Wizard is not a part of the Active Directory Migration Tool. That's a wizard for migrating Exchange from one domain to another, and that would be outside the scope of this WebCast.

Jason: How can I enable registry access in the source domain?

Tuanh: When you migrate over the computers, and also when you use the Security Translation Wizard, there is a section in there so that you can translate over the registry ACLs and permissions.

Jason: Next question: What order would you migrate in?

Tuanh: It depends on what type of scenario you're talking about. If you're talking about an intraforest migration, what we would recommend is migrating the global groups first, because for global groups to exist, their members can only be part of the same domain. So you would first migrate over global groups. Then you would move over the users, and then service accounts, member servers, and then run the Security Translation Wizard for whatever translations of security and permissions you need on the new users so that they can also access resources in the source domain. Then, after that, you would want to run the User Account Migration Wizard to move over local groups. Then run the User Account Migration Wizard again to move over the service accounts that might be running on the forest domain.

Then, finally you would want to migrate the domain controllers over. However, you cannot use the Active Directory Migration Tool to move over domain controllers. If it's a Windows 2000 domain controller, you'll have to demote it, and then bring it on as a member server to the new domain; or if it's a Windows NT 4.0 backup domain controller, you will have to either upgrade that to Windows 2000 in the target domain, or you will have to rebuild that Windows NT 4.0 backup domain controller, and then put it in as a member server in the new domain.

Jason: The next question: Why is a two-way trust needed, versus only a one-way trust?

Tuanh: It depends on what kind of migration you're talking about. In an intraforest migration, we don't actually have to create any trusts, because it's automatically a Kerberos transitive trust. So every domain in the forest is going to trust each other.

In an interforest migration, you need the two-way trust so that they can trust each other in terms of moving the objects from one domain to another; then also, one administrator having rights in the other domain, and vice versa.

Jason: Is there an option to transfer user passwords?

Curtis: No, not in the current version of the Active Directory Migration Tool. The version that's in development now will offer the ability to change passwords; but with this tool, you can change the user's password to his user name, or create a complex password, and it will place that password into a log on your domain controller.

Jason: This might be a product support question: I've upgraded my PDC to Windows 2000, and I want to upgrade my 30 BDCs in 30 different sites around the U.S. to be Windows 2000 machines. What is the best way to do it?

Tuanh: Really quick, what you would first have to do is create sites for each of the backup domain control locations, if they're all on separate sites. Then from there, you would want to upgrade each one into a Windows 2000 domain. During the upgrade process, it's going to ask you whether you want to make it a member server or a domain controller. And at that point you will choose to make it a domain controller.

Jason: How do you clear the SID history after you migrate users?

Curtis: There's an attribute for the SID history that is part of the schema in the registry settings for each user. I'm not entirely sure how you clear the SID history, because more than likely, after the migration, it won't be used anymore. You won't have to be concerned with it any more. This user can contact Microsoft support and an engineer will assist him with this question.

Jason: Should your Exchange server be migrated to Exchange 2000 when you migrate your Windows NT domain to Active Directory?

Curtis: That is completely dependent upon your environment and what you want to put in place for your company or your network. You do not have to upgrade Exchange to Exchange 2000 when you migrate or update the domain to Windows 2000.

Jason: What versions of Exchange can the wizard migrate?

Curtis: You can migrate both versions of exchange over to Windows 2000. Provided that Exchange 5.5 is at Service Pack 3 and that ADC is in place to manage user accounts. These articles address the issue you may encounter when migrating Exchange 5.5: Q297349, Q293350, Q300628, and Q297850.

Jason: This is a follow-up to a question that was asked before. The original question was: How can I enable registry access in the source domain? The follow-up says: My agent fails to install on that source domain. Does that give you a little bit more to go on?

Curtis: Not really. If you have both users, administrators for the target domain, included in the administrator's list of a source domain, this should work fine. The only other problem we see with the ADMT is if you're trying to access or move over a member server or a particular machine, and you don't have administrative rights to that machine as the administrator on the target domain, you need to add yourself or your Administrators group to the local Administrator's group on the member server in the source domain. That way you will have registry access on both domains. It's a little different when you migrate machines over. You have to be included on the local administrator's group on member servers if you're going to access the registry and have that machine reboot and join the new domain.

Jason: Should we use ADMT to move Windows 2000 Professional machines from a Windows NT 4.0 domain to a new Active Directory, or just visit each workstation and change the domain membership?

Tuanh: If you use the Computer Migration Wizard, it will actually save you time in doing so, because you have the option of choosing all of your computers at one time. It will send out the agent to the computer, disjoin the domain, restart it, and join it to the new domain. So in the interest of time, it would be a good idea.

Jason: Where do we find a list of differences between the upgrade and migration?

Tuanh: In those resources that we mentioned during the presentation, they will have definitions and examples of the difference between a domain upgrade and a restructure. Specifically, the Domain Migration Cookbook (http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/cookbook.asp) is a very good source of information.

Jason: Is there a way to keep existing passwords?

Curtis: No. At present the Active Directory Migration Tool does not allow for the user to keep his existing password.

Jason: Are any prerequisites needed to move computers' objects?

Curtis: I am not entirely sure I understand the question. If you're going to use the Computer Migration Wizard, after you get any of these wizards in place and running, all the prerequisites that we mentioned earlier in the WebCast should already be in place; the empty, global group, the registry key changes, both domains in native mode, trusts between the source and target domain — after those items are in place, you can move whatever you want to from the source domain to the target domain.

Tuanh: For the Computer Migration Wizard, like Curtis mentioned earlier, you're going to have to have the user running ADMT and the target domain as a member of the local administrator's group of that computer in order for it to work.

Jason: What tools help to migrate from Novell with or without NDS?

Tuanh: That falls outside of the scope of this presentation. We are only covering Active Directory Migration Tools. However, there are tools available out there to do so. It just doesn't fall into the scope of this presentation.

Jason: The group srcDOMAIN$$$, what kind of group is it, local or global?

Curtis: This group is a local group on the machine on the target domain. It's actually in place for auditing.

Jason: We have a couple of questions here about migrating sequence. I'm going to read a couple of them just so I make sure I cover everybody's. What are the steps to follow when performing an intraforest migration? Should you do computers first, users, or groups? Does the order of migration make a difference? Users and groups migrate okay, but the computer accounts do not reboot. Another question is: What should you migrate first, users or groups? Maybe you could speak to that a little bit.

Tuanh: Basically, in a broader scope, you always want to migrate the account domain first. So you want to first move over, global groups, and then you'll move the users with them. Or you can choose to move global groups with the memberships intact, and you can move them all over at one time. After the account domain is finished, you want to migrate over your resource domains, and that will include your file servers, print servers, and member servers. All types of computers will be associated with that particular resource domain. Finally, domain controllers will be migrated at the very end.

Jason: Next question: How are local user profiles affected by the migration?

Curtis: The local user profile is not affected if the users' machines are moved over to the new domain in the Security Translation Wizard. The Security Translation Wizard is run on those machine accounts because the local machine accounts already exist and won't change for individual users logging on to those machines. So the only effect that any user has to deal with when moving over accounts is if the accounts are roaming.

Tuanh: Basically, what you would do is migrate the user account over first. Then you would run the Security Translation Wizard so that it will take the user's new SID and replace any SID information on the local computer in the source domain.

Jason: ADC does the migration to AD from Exchange and vice versa. Why use the ADMT Exchange Wizard?

Curtis: The ADC is the Active Directory Connector, so that you can use an Exchange 5.5 Exchange server in a Windows 2000 domain so that you can create user accounts in either the Exchange server or the Active Directory domain, and to have them move or replicate back and forth between Active Directory Users and Computers and the Exchange 5.5 server. It does not do domain migration, user migration, or mailbox migration. The Active Directory Exchange Migration Wizard moves the Exchange directory from whatever domain you were running before your source domain to your Exchange server on your target domain.

Jason: Why does Windows 2000 have to be in native mode?

Tuanh: Windows 2000 native mode is the only mode that recognizes SID history. It's a new attribute in Windows 2000.

Jason: You might have answered this one already: When migrating objects, what is the recommended order?

Tuanh: You would move over global groups first, users, and then whatever in between — service accounts, local groups — then you would want to move over computers, and then domain controllers.

Jason: What is the best way to migrate users' accounts without losing their profiles?

Tuanh: It depends on what kind of profile they're talking about, but there are two types. There are roaming profiles in which, if you move over a user account, you have the option during the User Migration Wizard to translate that roaming profile. It will take the user's new SID and associate it with that user's original SID, original profile in the source domain. With local profiles, you would move a user over, and then you would run the Security Translation Wizard, again, on the computer that's in the source domain where the local profile is stored. It will change the permissions and SIDs associated with that local profile.

Jason: If you have one PDC running Windows NT 4.0, and 100 members, is it possible to migrate the users using the ADMT?

Curtis: Yes, that is possible.

Jason: Do you have a command-line interface, instead of using the wizards, that would be beneficial for scripting automating migration?

Curtis: There is a command-line utility called Clone Principal that does domain migration also. You can find more information on that through the resources we have listed here.

Jason: There are some resources on slides 25 and 26, including links to more information.

Curtis: It depends on the restructuring plan you have in place. If you're going to collapse the source domain, you have to move the accounts over. If you're going to do an interforest migration, you can clone the account, so the accounts will exist in both domains. If you're going to do intraforest, you have to move the machine accounts over to the private domain.

Jason: This seems to be a follow-up to an earlier question: The CN is not required to be the account name. In fact, if you create an account in ADUC, you do not get the CN to be the account name. So why does the migration ADMT force that change rather than using the display name? If you use ADC to populate the Active Directory, it does use the display name for the CN.

Curtis: It doesn't sound like we're talking about the same utility because the ADC does not do domain migration. All it does is create user accounts and replicate those accounts to an Exchange account. The Active Directory Migration Tool has to create the CN for these users because it's populating this user into a new forest into a new domain, and it needs to have some type of information associated with that account and register in the schema of the new forest.

This user is discussing the ADC verses the ADMT. One tool is used for creating users accounts in either Exchange or in the Users and Computers Group. Our tool, the ADMT, is used for migrating account from one domain or forest to another.

Jason: What minimum service pack is supported for Windows NT 4.0?

Curtis: The minimum service pack to use the ADMT is Service Pack 4, because Service Pack 4 understands NTFS 5.0 permissions, and is compatible with running in a Windows 2000 domain.

Jason: How do you give full trust for an interforest environment? I created a secondary DNS zone, but I'm unable to ping the domain names. However, I can access some servers on the other domain.

Curtis: That goes into support, but basically, if you can access anything in the other domain, your trust is in place. A full trust would be a two-way trust, which is nontransitive for Windows 2000 and Windows NT 4.0. So you need to have a two-way trust in place between the target and source domain to use the ADMT.

Jason: To have a mixed mode, do you need to upgrade one of your PDCs or BDCs, or can you just have a Windows 2000 Server join the domain, then make it a domain controller?

Curtis: That's actually outside the scope of the ADMT, but you cannot join a Windows 2000 domain controller to a Windows NT 4.0 domain because there cannot be two PDCs in a domain at the same time.

Jason: What is the best method to migrate: using ADMT, or the Clone Principal scripts included in the support tools? What is the main difference?

Tuanh: The main difference between the two utilities is that ADMT is a GUI interface. So it makes things easier, and you can choose more options. In the Clone Principal, it's basically a script that you have to run. So you have to really understand how scripts work, and also the command-line utilities. You'll have to know the proper syntax to get it to work properly.

Jason: This one seems to be a follow-up to an earlier question as well, related to the "unable to load Dapi.dll." They received that error, and they're actually questioning whether it's related to the ADMT tool or not. This is the Exchange translation of ADMT tool that produces this error in the log file and does not work. Are you aware of any known issues with that?

Curtis: This is a support issue that can be addressed by our Support engineers.

Jason: I do want to take just a moment to solicit some feedback from all of you. If you've been to a Microsoft WebCast before and you've seen what we've been doing here, and you like what you've seen, we would really appreciate your feedback. Even if you don't like what you've seen so far, please send that feedback in. Again, you can do that in this broadcast. You can submit it using the e-mail alias feedback@microsoft.com. If you use that alias, please include "Support WebCasts" in the subject line.

So the next question: If I move an existing DC from an old domain to the new domain as a member server, can I just run dcpromo to demote the DC and bring it in as a member server?

Curtis: Yes, but you have to demote the DC in the domain it's in originally before you bring it over to the target domain. That's part of the process of collapsing the domain, and it's covered also in the Domain Migration Cookbook.

Jason: The answer to the order question was very helpful. Where does Exchange fit into this order? How can I make sure users have access to mail and resources in both domains during the migration?

Curtis: There are two ways to make sure the users have access to mail and everything. First of all, you can make sure that the Exchange server is able to do e-mail across a trust. Before you migrate this server or its directory services to the target domain, and you want the users to gain access to e-mail, you're going to have to have SID history in place for your migrating users and a trust in place or the capability to do e-mail across a trust with Exchange. Also, when you migrate Exchange over to the target domain, your users won't notice. It should be seamless for your users to access their e-mail in both domains. After you collapse the source domain, their e-mail and everything in Exchange services should already be migrated over. During the process of migrating over resources, computers, member servers, and file servers, this is usually the time you migrate over services like Exchange, SQL, or any type of network services you had in place on the source domain.

Jason: When are closed sets required?

Curtis: Closed sets are not required during a migration. Only if you want to migrate over users and groups at the same time, do you use closed sets. They are required in intraforest migrations, but not interforest.

Jason: When is the new version available? I'm assuming they're referring to this tool?

Curtis: Right, ADMT 2.5. I have no information on when that product is going to be released. It's still in development.

Jason: If I migrated my PDC to Windows 2000 and later lost a BDC, can a Windows NT 4.0 BDC be added to a mixed-mode domain?

Tuanh: Absolutely. As long as it's still a mixed mode, then you can add Windows NT 4.0 BDCs without a problem.

Jason: Next question: Even though I have trust between the target and forest domain, I am still unable to pass the second phase of the User Account Migrating Wizard. It's prompting me to change the domain name. Is that a known issue?

Curtis: That's not a known issue. That probably falls in the line of one-on-one support. He's having a problem with, more than likely, the configuration that he has in place for using the Active Directory Migration Tool.

Jason: In which order should you migrate your domains, resource or account domains?

Tuanh: You're going to move account domains over first, and then resource domains.

Jason: Is there a wizard to migrate users' accounts from Windows NT 4.0 to Windows 2000, and also, will it copy the user's profile?

Tuanh: The user migration wizard will move over users from Windows NT 4.0 domains. Again, to move over the profiles, you would have to move over the user first, and run the Security Translation Wizard on that user or the computer that is on the source domain for the SIDs to translate over the new SIDs and replace the old SIDs referencing the local profiles on that machine.

Jason: What are the advantages to using ADMT versus Clone Principal or MoveTree?

Curtis: It all depends on your goals. The outcome you're trying to reach with these tools. The ADMT is a GUI interface that can easily be used by most users. It doesn't require any knowledge of scripting or anything of that nature. Clone Principal can only be used for interforest migration. MoveTree can only be used for intraforest migration, and MoveTree will migrate over passwords.

Jason: This one seems to be a follow-up to the question about native mode: Why does the target domain have to be in native mode?

Curtis: The target domain has to be in native mode to utilize domain local groups, group nesting, the trust with the Windows NT 4.0 domain, and SID history.

Jason: Other vendors claim to have tools that can migrate the password. How are they able to do it, and why does ADMT not have this feature? Can I write a script to extract the password from Windows NT 4.0 and feed the Active Directory?

Curtis: At this time I don't think that's possible. The security for Windows NT 4.0 is designed so that passwords are never read or transmitted over the wire, from one domain or one user or one machine to another. I am not sure if there are any other utilities out there that will migrate over user accounts and their passwords from Windows NT 4.0 to Windows 2000. I don't know if there's any type of utility that exists. I haven't seen one, in my experience with this tool.

Jason: This appears to be a follow-up to another question: How does the ADMT migration of a workstation differ from a manual visit to each tool, other than timesaving? Does it matter which one I use on workstations and the member server?

Tuanh: Again, it's basically doing the same thing. If you use the Computer Migration Wizard using Active Directory Migration Tool, it's going to disjoin the machine from the domain, restart it, and join the domain again. It basically does the same thing.

Jason: In a Windows NT 4.0 domain, can you upgrade a Windows 2000 member server to a domain controller before you upgrade the Windows NT 4.0 PDC?

Curtis: No. You cannot upgrade any Windows 2000 machines to domain controllers unless there's already a Windows 2000 domain controller in place, and the Windows NT 4.0 PDC has to be upgraded first, before you upgrade any other machines to Active Directory for Windows 2000.

Jason: What are the advantages of native mode over mixed mode?

Curtis: In reference to the Active Directory Migration Tools, the advantages are Domain Local groups, Universal groups, group nesting, and the use of SID history.

Jason: How do I get administrative groups to show up in the MMC?

Tuanh: We'll probably need more clarification on that question.

Jason: If that user wants to put in a little bit more clarifying information, we will take that during this broadcast.

Again, if you do want to submit some feedback for today's session, you can do so using the alias feedback@microsoft.com. Again, we do really appreciate the feedback. It's great to get information and help fine tune these WebCasts.

Next question: Which migration route is more graceful, upgrade and then migrate your domains into the structure you want, or migrate into a pristine domain?

Tuanh: An upgrade is going to be the least risky, and is performed the most often, and the fact that you're upgrading your primary domain controller to Windows 2000. So you're still preserving all your domain information: all your users, computer accounts, and groups are there. So it's the least risky of the two.

Jason: Should I create an OU for every group of users that I want to migrate?

Tuanh: No. OUs are used for administration purposes. So you want to put groups inside of OUs. You don't want to use OUs as a way of separating all your different groups in your domain.

Jason: The next question: If I keep the SID history, why do I need to re-ACL the resource with the Security Translation Wizard?

Curtis: You only need to do this when you move that resource over to the target domain, because it's going to come over to the target domains with a new SID, from being generated after it joins the target domain. Then you have to run the Security Account Translation Wizard. This will be the first time you run this wizard on this computer in relationship to the migration. The SID history is in place so that you can still access resources from that machine, as a user on the target domain, going across the trust to the source domain. You haven't, at this point, run the Security Translation Wizard, because it's not necessary so long as SID history is in place, and the Windows NT 4.0 or the source domain is still up and running.

After you move this machine over, migrate it over to the target domain, it gets assigned a new SID, which for all intents and purposes is a new machine to the users on your target domain. You run the Security Translation Wizard so that it will take that information that was available on that machine in the source domain, its file shares, its resources, and all things that were already in place, rights and permissions, that users have to this machine, and re-associate the users in the target domain to that machine.

Jason: Can we migrate print servers and still manage the printers attached?

Curtis: Yes. The Security Translation Wizard gives you the option to choose printers when you migrate over the resources, such as a print server. It will re-ACL or re-initialize the ACL for the users that have been migrated over from the source domain to the target domain. The only thing you will have to do at that point is, if it's necessary, physically move the printers to wherever they're going to be located after they've been moved over to the target domain. You can move over a print server along with any other resource from the source domain to the target domain and run the Security Translation Wizard so that this move will be transparent to your users during the migration.

Jason: Can I migrate users from a child domain to its parent's domain?

Tuanh: Yes. That would be an intraforest migration, and you can do that with ADMT.

Jason: That does wrap up all our questions. I just want to let everyone know, we did get a few product support questions today. If you submitted a one-on-one product support issue, it's really outside the scope of what we're able to cover in these WebCasts. So what I'd suggest you do is get on the Web, go to http://support.microsoft.com/, and submit an incident. Or you can call Microsoft Product Support Services and speak to a support professional. I'm sure they'll be able to help you.

So that does answer all the questions we have in the queue. I want to thank everyone for joining us today. I hope the information was useful to you. If you want to make a comment about topics you'd like to see covered, the interface, the slide presentation, or the questions asked, you can e-mail us at feedback@microsoft.com. Just make sure you include "Support WebCasts" in the subject line.

We hope you join us again in the near future. Thank you, and good-bye.