Subscribe to Windows IT Pro
June 13, 2000 08:49 AM

The Active Directory Migration Tool

Windows IT Pro
InstantDoc ID #8958
Rating: (1)

ADMT, however, requires that you create a trust from ALLFOLKS to FIRST and another trust from FIRST to ALLFOLKS, then include your ALLFOLKS administrative account in the FIRST domain controllers' local Administrators group. I've found that many functions won't work on member servers in the source domain unless I take the extra step of placing the target domain's Domain Admins group into the member server's local Administrators group.

ADMT starts out in a standard Microsoft Management Console (MMC) window, but all of ADMT's tasks work as wizards and are pretty self-explanatory. The User Migration Wizard tells ADMT to copy user accounts to the target domain. Try this task (space prevents me from walking you through it), and you'll notice a few things.

First, ADMT has a test mode. In test mode, ADMT runs through the User Migration Wizard, doing everything except actually writing out the user accounts.

Second, although ADMT calls itself a migration tool, it's more of a "gradual account movement" tool. What I mean is this: ADMT doesn't move the user accounts from FIRST to ALLFOLKS—it copies them. The difference is significant. After you use ADMT, every user has both an old FIRST account and a new ALLFOLKS account. So, if you realize a couple of weeks later that something has gone terribly awry, you can just tell users to log on with their old accounts.

Third, apparently ADMT can't copy passwords when it copies user accounts. Instead, it must assign initial passwords to the new user accounts in the target domain. Users must log on with those passwords the first time, then immediately change them. ADMT lets you choose to either set the initial password equal to the username or have ADMT create a complex password for the new user account. ADMT then stores the new passwords in a text file, from which you can retrieve them and pass them on to the users.

After Moving Accounts
Now that you've copied the user accounts from FIRST and SECOND to ALLFOLKS, you want to take my suggestion and make the move a nice, gradual one that you can easily back out of if necessary. After the users have their new accounts, you'll need to tell the appropriate file and print servers about the new accounts. For example, you might have a large share on a server in FIRST that the people with user accounts in FIRST can get to, but you also want those users' new ALLFOLKS accounts to be able to access the old shares on FIRST. (Eventually, you'll move that share's server from the FIRST domain to the ALLFOLKS domain, so providing this accessibility is just an interim step.) In other words, if Oliver has a FIRST account that gives him read and write access to some share on a member server in FIRST and now he has an ALLFOLKS account, we want ADMT to tell that member server in FIRST to add Oliver's ALLFOLKS account to its share so that the ALLFOLKS account has read and write access to the share. ADMT uses the Security Translation Wizard to accomplish this task. This wizard can not only add the new target domain accounts to share permission lists but can also recreate user rights, NTFS permissions, user profiles, and local group memberships for the new ALLFOLKS account so that it has all the old account's abilities.

Consider how big a job it is to find all the share permissions, NTFS permissions, user rights, and the like that refer to Oliver's old FIRST account to be able to duplicate those attributes for his new ALLFOLKS account. Tracking down those attributes might be a slow process over the network, so ADMT remotely installs programs called agents to the servers that you direct ADMT to translate security settings for. In my experience, however, the process of remotely installing agents can cause a bit of trouble: My source domain's member servers often rejected ADMT's attempt to remotely install its agent unless I placed the target domain's Domain Admins group into the source domain's local Administrators group. Then, the agent installed fine.

ADMT does much more than I have room to tell you about, but I've explained its basic functions. I urge anyone charged with a Win2K migration to download ADMT today and play around with it.

Related Content:

ARTICLE TOOLS

Comments
  • Anonymous User
    8 years ago
    Dec 26, 2004

    I have a NT 4.0 domain and a new Server with Windows Server 2003.

    I want to migrate the Users and computer accounts from the NT domain to the Windows Server 2003 Active Directory.

    Active Directory on the server is in "Windows 2000 mixed mode". When I run the Active Directory Migration Tool v2 I get the error "The target domain is not native mode." I've tried raising it to Native Mode but then it is no longer able to access the NT domain.

    Any suggestions on how to migrate the users and accounts?

  • Paul
    9 years ago
    Nov 11, 2003

    Hello,

    We have bought a new server to replace our old (hardware) SBS2000 server.

    Can you offer an suggestions on how to recreate the old server on the new?

    The old server is running SBS2k (AD,ISA,exchange,file server) I see that the Active Directory Migration Tool can create all the accounts on the new server, but does that also create the exchange mail boxes, move all the mail across, create the same directory shares + permissions + files & the ISA configuration on the new server?

    Can you point me to some tools that will make this run smoothly with as little downtime as possible?

    Thanks in advance,

  • John
    10 years ago
    Dec 10, 2002

    can you put the same password to the admin account for both machine??
    you must verify you are an admin in the other domain, i think there is something in the mmc to change ...

  • Dan
    11 years ago
    Jun 22, 2001

    I have just setup a new network with Win2k as the server. I need to get all of my user information from a Windows NT 4 server, located on another domain. There is a trust relationship between both domains, and I've verified it both ways, but when I run ADMT, I get an error that it cannot proceed becuase I am not an administrator on the other domain, however, I clearly am. Could you give me help on how to proceed?

  • Paul Williams
    12 years ago
    Dec 01, 2000


    I need assistance with the topic Mark Minasi discussed in Inside Out: "The Active Directory Migration Tool" (July 2000). We're trying to migrate a Windows NT 4.0 domain to a Windows 2000 domain using the Active Directory Migration Tool (ADMT). However, the tool fails to migrate the SIDs. Whether we select the check box to migrate the SIDs or leave the check box blank, ADMT still passes on a message saying that the SIDs will not be migrated.

    Also, when we try to migrate a computer, the agents are dispatched, but they fail to run on the remote computer and indicate that access is denied. The article mentions that you can run the agents by hand, but the article doesn't provide any other details about the process.

You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.