RE: [ActiveDir] AD Migration paths (divesting forests)
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 t
RE: [ActiveDir] AD Migration paths (divesting forests)
Roger: Thanks for the tip. Unfortunately, approx numbers are 4,000-5,000 users/workstations over most of the state and maybe 500 - 1,000 GB of data (swag) so the "weekend approach" doesn't work for us. We are going to have to do a staged migration and maintain business process during the transition. Diane -Original Message- From: Roger Seielstad [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 4:46 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] AD Migration paths (divesting forests) We have traditionally done a single, full migration - workstations, servers and accounts all at once. It tends to make for long weekends, but you only touch each client machine once. -- Roger D. Seielstad - MCSE Sr. Systems Administrator Inovis - Formerly Harbinger and Extricity Atlanta, GA > -Original Message- > From: Ayers, Diane [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 14, 2002 10: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 > List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] AD Migration paths (divesting forests)
We have traditionally done a single, full migration - workstations, servers and accounts all at once. It tends to make for long weekends, but you only touch each client machine once. -- Roger D. Seielstad - MCSE Sr. Systems Administrator Inovis - Formerly Harbinger and Extricity Atlanta, GA > -Original Message- > From: Ayers, Diane [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 14, 2002 10: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 > List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
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 <>
