See comments inline below.... > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Ayers, Diane > Sent: Tuesday, October 15, 2002 9:50 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [ActiveDir] AD Migration paths (divesting forests) > > Rick: > > Thanks for the information. Much appreciated. A few questions for the > masses... > > * Although our forest is native mode, we still have a number of NT 4.0 > "resource domains" the contain most of our resources (no users) in the > source forest. All of these resources that are moving to the new forest > will be moved into AD. Once the user is migrated to the new forest, will > SID history flow down to the resource domains that trust the source AD > domain? This will be critical to the users if we migrate the users > accounts first. > SIDHistory is going to be your friend here. It will maintain your access to 'legacy' domains as well.
> * SID history and Exchange: Once the users are migrated, if their
> mailboxes are still in the source forest, will SID history allow access to
> the legacy mailbox? My thinking is around that the user and mailboxes
> should be migrated at the same time. If we do migrate the users and
> their mailboxes, there may still be "resource" mailboxes they may need to
> access during the transition. The source is still in Exchange mixed mode
> today but by time we will be doing the actually migration, we should be
> all E2K.
>
I don't THINK SidHistory is going to help here.... But, I may be
wrong. If it does, we've been going to WAAAY too much work.
Believe me when I tell you that if you CAN move the user and the
assosciated mailbox at the same time it will be much more seamless to the
user. Otherwise, remember that I said in my earlier post that ADMT left the
disabled user account in the source? This is your salvation if the mail
cannot come across at the same time. We ran into an issue where the
Exchange could not come across until the users were across (I think it was
an excuse from the Exchange team as they weren't ready - it's clearly not a
technical issue!).
What you do in the case where your user comes across bu the mail is
still in another forest is to use that disabled account. It is still
attached to the mailbox. Through the Exchange AD U&C snap-in, add the user
in the new forest (you have a trust, so this is not a problem) and give the
user in the new forest (I can't remember the 3 perms - clear the top one,
check the 2nd one, and check the bottom 2 - one will be to Associate
External Account).
> * E2K to E2K migration. A lot of ven-duhs have E5.5 to E2K migration
> tools, there is not much E2K to E2K migration tools. Are there any best
> practices / tools around e2K to E2K migrations?
>
I'll leave this one to the much more expert Exchange folks......
> Diane
>
> -----Original Message-----
> From: Rick Kingslan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 14, 2002 9:09 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] AD Migration paths (divesting
> forests)
>
> 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>>
