Diane, Though our situation is not exactly similar (we plan on retiring the old forest once we're finished), it is similar enough that I can talk authoritatively about what we did and how our rate of success has been.
Firstly, we created an empty root forest with a single child domain (it has changed since then - more domains) and created a trust between the source domain and the target child. Knowing that it was important to retain our investment in Group Policy, we used FAZAM 2000 to migrate the GPOs. We had all but eliminated our Windows NT 4.0 BDCs in our old environment, so the legacy issues did not cause us any concern in the new forest. We moved instantly to a Native mode domain which left us a bit more open for the Groups/User/Computer migration. Each of the security principals were migrated to the new forest/domain using ADMT version 2.0 (key to retaining Passwords of migrated users! More on this momentarily). Users were migrated with options set to disable the source, enable the target, fixup the target group memberships (as the Global and Local Domain groups had already been moved) and to enable SID history. We have the need to retain access to resources in the old domain/forest until it is retired. Computers are moved across and the Security on the machine is migrated or changed to make it consistent with the domain that it is joining. An agent is dispatched to the machine and it operates on the machine locally. It is important to know that the Domain Admin or some higher level user must have access to the %systemroot\admin$ administrative share for the agent to be able to work. This certainly is not a problem on most systems, but there always seems to be a few that find out how to remove your access to their machine. It's also important to note that ADMT is more targeted at the Windows NT migrations. Because of this, WINS and NetBIOS is used heavily - even in a pure Windows 2000 environment. If all of a sudden you can't see a given DC, set of machines, etc - it's a WINS/NetBIOS thing. ADMT doesn't even think of using DNS - doesn't even know what it is. Just a pointer to be aware of. As a sidebar, if you use roaming profiles, you'll find the rate of success with the computers much higher. Local profiles had a tendency to cause us some issues (security fixup and the system recognizing the user profile on login) to the point where on most machines it became our MO to just manually join the machine to the target domain and copy the user profile to the intended directory. In the long run, it caused less time and less headaches - especially when dealing with laptops (mainly because if we gave them notice that we were migrating the laptop that night, the user would take it home anyway. This would occur even if we told them 5 minutes before they packed up to leave! Endusers...... :/ ) With ADMT v 2.0, you now get the option to migrate the passwords of your users as well. This requires creating a crypto-key on the system in which ADMT is being installed (in the source domain) and installing the key on a machine that is a DC in the source. You will indicate this machine in the field (persistent field - doesn't have to be reset each time) and the key will be leveraged to migrated the password. This has worked quite well for us in moving ~15,000 users, computers, groups, etc. from one forest/domain to another. If you have any questions, don't hesitate to ask. Rick Kingslan - Microsoft Certified Trainer MCSE+I on Windows NT 4.0 MCSE on Windows 2000 MVP [Windows NT/2000 Server] "Any sufficiently advanced technology is indistinguishable from magic." --- Arthur C. Clarke > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 14, 2002 9:40 PM > To: [EMAIL PROTECTED] > Subject: [ActiveDir] AD Migration paths (divesting forests) > > Our company is divesting part of the organization into a separate company. > That means we need to split our AD forest into two separate forest. We > have an sense of how we are going to do it but one question I have is the > sequence. > > We are going to build the new forest (both forests are empty root, single > domain) and set up an external trust between the two main domains. One > plan has us migrating resources such as workstations, servers, etc to the > new forest maintaining ACLs, etc to the resources and then migrate > accounts towards the end. The second plan has us migrating the accounts > first and using SID history to maintain access to legacy resources until > they are migrated to the new domain. Both plans seem to work technically > but we are not sure of "best practices" as far as the migration. A recent > talk at MEC suggested the later as opposed to the former. > > Since we have not gone through this before in our organization, I was > hoping that folks that have gone through this might shed some light... > > Diane
<<attachment: winmail.dat>>
