Domain Rebuild Checklist

[TC-1927]

Hello

 

I'm rebuilding our domain over the summer, and I'm just trying to work out what will inevitably go wrong.

 

I've got the new domain up and running and have tested moving shares/server roles/users and all the other fun stuff.

 

We're rebuilding all workstations on site - the image for which is nearly done - and just joining staff laptops to the new domain as and when they come in.

 

I've got most of the software sorted and ready to put into GPOs on the new domain.

 

Both servers are backed up nightly at the moment so if it goes totally t1ts up then I can roll back.

 

Any cautionary tales/words of warning to share?

 

Thanks!

[Oaktech]

Have you got records of all of your groups/access permissions just incase things don't go across successfully.

[TC-1927]

We're starting from scratch with permissions really as there aren't really any in place at the moment apart from staff/pupil groups! Going to put our current (approx 1TB) staff share on a temporary network drive and tell everyone they've got six weeks to copy what they need. It's been migrated from server to server since the school was built so it's time for a refresh in that department.

 

As I say, tested moving user areas and fileshares across and all seems happy.

[GC75]

If joining your new server as an additional domain controller, make sure Sysvol is shared and replicating via typing net share on a cmd prompt before moving any FSMO roles, I remember a few years ago a job I was on at a school where this became a major problem and ended up having to create a brand new domain to resolve it as we didn't have a lot of time to spend on troubleshooting it. If it doesn't happen straight away just wait it out and I'm sure it will be good to go.

 

If you use Sophos Enterprise Manager, uninstall it completely from your old server before installing on the new one as I've experienced problems with it creating the database installing on the same domain. Uninstalling saves these type of headaches.

 

Robocopy is a great tool to move data from one server to another, if your security groups/permissions are the same it can take them across with it and also if it gets interrupted for whatever reason, run it again and it will pick up where it left off. When doing this in the school holidays, I've setup the script to run it and kicked it off as I've walked out the door, next day everything is there waiting for you, so saves your time with that running out of hours especially if you have a lot of data.

 

Housekeeping the data is good, I know nobody wants to do it, but it's always a good time to think about it with a brand new server.

 

When you are happy with the setup, use an external hard drive to do a complete backup of the server, including a Bare Metal Recovery (BMR) backup. I actually have a full backup run every single evening in the early hours to go alongside our online backup, better to be safe then sorry is my way of thinking.

 

Finally testing, testing, testing is the best thing you can do before everybody wants to start using it, make sure all your permissions/GPOs do as you want them to etc.

Edited June 24, 2015 by GC75

[pete]

Hmm,

 

In terms of "what're you likely to forget..."

 

Anything that uses LDAP/Kerberos/Samba to talk to AD (especially copiers, which are usually running Samba).

NTP on switches and other hardware if your DCs are moving IPs.

Undocumented systems* that rely on your infrastructure but no-one told you.

Shorten DHCP leases nearer to the switchover if you're taking the opportunity to play jenga with where services come from as well.

 

*building controls, boilers, lift alarms/status, CCTV.....