consolidating 10 domains to 1

  • 51 Views
  • Last Post 20 hours ago
MatCollins posted this 5 days ago

hi guys,

there is a new task coming to me which is to migrate resources from 10 domain to a single one and remove the domains after. basically i know how the stuff work but i wanted to check one more time with you experts. domains are belong to a forest and fully trusted. also now, each domain has a site which cover the users in that domain. (geographical distributed) 

here are the main duties i wrote that i believe i need to do:

1.create destination domain and ou hierarchy (based on previous domains)

2.assign permissions to those new ous

3.editing domain controller and domain policy

4.migrate computers from one domain to the destination domain.

5.make sure those compujters are authenticating at the correct dc and site

6.migrate users with sid history enabled

7.remove dc and domain

8. go to next domain

 

am i missing something? also i welcome all opinions towards this migration and tips you might find useful

regards

Order By: Standard | Newest | Votes
SmitaCarneiro posted this 5 days ago

I would add a few more steps.

Have a good project manager to help you co-ordinate this.

Good communication to your stakeholders is of the essence.

Set up a test domain that is a replica of your new greenfield one.

Test all your steps thoroughly before you do a migration to the production one.

Especially test your servers and applications, and make sure you have a good set of testers.

 

 

 

Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy

www.itap.purdue.edu

 

 

 

show

geezup posted this 5 days ago

Make sure you migrate all the gpos as well. Don't forget the fizmo roles 2 are forest based so make sure you have them in the proper places. 



Sent from my iPhone


On Nov 13, 2017, at 7:38 AM, Carneiro, Smita A. <carneiro@xxxxxxxxxxxxxxxx> wrote:















I would add a few more steps.

Have a good project manager to help you co-ordinate this.

Good communication to your stakeholders is of the essence.

Set up a test domain that is a replica of your new greenfield one.

Test all your steps thoroughly before you do a migration to the production one.

Especially test your servers and applications, and make sure you have a good set of testers.

 

 

 

Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy

www.itap.purdue.edu

 

 

 

show

amulnick posted this 5 days ago

I'm surprised you'll be able to mash 10 domains down to one and keep the same settings.  i.e. domain policy, domain controller policy etc.  How are you planning to handle those settings that collide? 
I do agree you'll really want a great test environment and PM.  I'm not sure I agree you'll want to migrate GPO as is, vs. creating new based on requirements.  You may find that many of the legacy GPO were created based on requirements that may no longer be required.  
Al


show

SmitaCarneiro posted this 5 days ago

One of the things we are finding out as we migrate is how many un-needed objects we have that have accumulated over the years. GPOs, shares….

 

Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy

www.itap.purdue.edu

 

 

 

show

barkills posted this 5 days ago

Your set of steps doesn’t call out the customer impacting points. It also has missed group migration--that should happen at the same time as you do user migration.

 

As written, you have the following impacts:

-At #4. At minimum 1 reboot for each computer, but you probably will need 2-3 reboots to ensure GPOs are all firing. You’ll have some number of failed computer

trust relationship error messages (which can have many different causes), which you should have a clear customer message for.

-At #7. Your users haven’t been told to start using their “new” user account, so at #7, they will have problems.

 

It’s worth noting that you can move #6 forward to happen before #4. To do tell users to start using the new account before their computer has been migrated, you

either need:

-to have a dual set of ACLs on all server resources

-to have a dual set of user accounts in all groups

 

If you don’t want to be dependent on sidHistory forever, you may want to ditch that on #6. I advise not using sidHistory—it’s essentially technical debt that

you won’t ever pay.



Presuming you are using a tool which does reACLing at the time of computer migration, you should do #6 before #4. This is especially true if you decide not to

do sidHistory.

 

Brian

 

show

ken posted this 5 days ago

Also, do you have anything that relies on the old domains that also needs to be migrated?

DNS host names/shortcuts/etc. for applications?

DFS-R based file shares?

Windows based DHCP servers that are authorised in AD?

AD-integrated PKI?

Etc.

 

show

kbatlive posted this 20 hours ago

A few other items to identify; hopefully you won’t have them.

 

But you have reviewed Microsoft’s migration documentation?  They is much information there that will be quite

useful.

 

Are you moving the application servers (assumption there are app servers)

Or clustered servers (and any clustered apps on them)

SPN’s for those app servers

Any non-windows app servers (using SSL/Kerberos from their home forest and a PKI in that forest)

Re-iterate what KenS mentioned…PKI? SCEP? NDES?

Radius for wireless devices?

VPN?

Duplicate IP address space?

Backup software that is domain specific (i.e. can’t be restored to a different domain) – legal hold items?

 

Simple things will come back to cause issues…same group names (or user IDs) or computer names or email addresses

(user  portion of address) or any number of DNS name collisions

                “maint” (oh so many of those users and computers and printers)

                “accounting” or “HR” or similar names most companies have

If you can use prefixes or suffixes, that may alleviate some name collisions during migrations…

 

But when the time comes…

Find the “simplest” domain to start in

Start the migration, figure out your lessons learned…

And adjust your migration plan from there for the next domain

 

Expect it will take longer (& cost more) than planned

Expect issues that are not uncovered until during/after migrations

 

 

show

Close