Background

Following on from my earlier post about the death knell for Server 2003 which is due to retire in July 2015 I provide some guidance on uplifting your Domain Controllers to either 2008 or more relevant to this post, to 2012 R2. It has been a year since 2012 R2 was released in October 2013 so you better be ready for it…are you ready, are you sure? …go on be honest, does it scare you? Change usually does. This guide will serve as a calming oasis in a sea of chaos.

To clarify at the outset, we are not bothered about upgrading member servers here, that’s a big task for even smaller organisations as any legacy services and applications running on these will need some level of remediation to work on 2012 or 2012 R2 member servers. Heck, just migrate to the latest version straight into the ‘cloud’ as a hosted solution and let the 3rd party vendor do all the hard work (then all you need is a Trust or Federation! Easy!). Just remember that member servers on an OS of 2003 Server or above will function completely fine in a pure 100% 2012 R2 AD environment (but don’t forgot about July 2015!).

NOTE: Also we are not talking about an AD migration here, this is a DIY guide to replacing all your flavour of the month Domain Controllers (Windows 2003, 2003R2, 2008 or 2008 R2) with all new shiny 2012 R2 Domain Controllers (DCs) – and then optionally uplifting your Domain &/or Forest Functional levels.

#Housekeeping

Please Please Please Please Please do some housekeeping. Clean up those stale objects (users, groups, computers, GPOs, Fwd and Rvrse DNS entries, SIDs, OUs, Sites, Trusts), clean down those global groups and lock down the number of people with privileged access. Your Security Chief (mean scary person) will thank you and your attack surface will be reduced accordingly. Honest.

Service and Application accounts in your AD often have more privileges than they actually need, they are usually classified as ‘stale objects’ as they probably haven’t been interacted with for quite a while. Identify the owners of these accounts, this is quite important as more often than not an application failure can be traced to the service account…but if you don’t know who owns/manages it the TTF is lengthened significantly.

Also use this time to document your AD structure and settings, seriously a lot organisations either 1) have no such document or even a visio diagram or 2) have the original one created as a vanilla ‘design’ back in the day but it was never updated since! Wuh? You mean you’ve actually got 30 DCs and not just 3 like it says here?!!!

Audit: The servers themselves and the Environment

Here’s your simple checklist of questions to ask yourself or information to find out:

• Are your existing physical servers fit for purpose and can they support Windows Server 2012 R2? For your server hardware do the associated 2012 version drivers exist? Consider using virtualisation as DCs in virtual environments are fully supported (Hyper-V and VMware);
• Will your AD be upgraded either 1. remotely by an in-place upgrade from Server 2003/2008 to Server 2012 R2 or 2. rebuilt from scratch 3. New hardware and built from scratch?
• Cross architecture (32 bit to 64 bit) and cross language (change in server language) in-place upgrades are not possible, these servers will need to be rebuilt;
  • If servers are running a 64 bit edition of Server 2008 or 2008 R2 they can be upgraded to 2012 R2
  • If servers are running ANY edition of Server 2003 they will have to be rebuilt or replaced
• Windows Standard editions will be upgraded to Windows Standard and Windows Enterprise editions will be upgraded to Windows Enterprise;
• What is the size of your existing NTDS.DIT? This is important as your upgraded or newly built server MUST have sufficient memory to hold the entire NTDS.DIT file in active memory, in RAM. If your NTDS.DIT is 500MB, than your available RAM after all other considerations must be minimum 500MB – ideally more;
• Note down your AD Schema version, go to a Domain Controller, run regedit and navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Parameters;
• Non Windows clients, identify them and understand how they interact with and access domain resources, sometimes they have IPs or even Hostnames hard coded somewhere within their settings. Identify and either rectify or have a plan of action;
• Network equipment that may need DNS information, check your switches, routers and firewalls and liaise with the network operators to understand the dependencies;
• 3rd Party applications, find out what if any dependency they have on AD DS and what may happen to functionality and service in the event of an upgrade. This means engaging with the 3rd party and having a plan just in case;
• Services, applications or hardware (Printers, Multifunction Devices, Logging services, Proxy/RAS/VPN Servers, IP Cameras, NAS servers, SAN storage) that relies upon Active Directory and in particular Kerberos for authentication should be logged and if needed a remedial plan of action formulated;
• Upgrades and rebuilds of DCs should be completed out of hours where possible;
• Identify your current FSMO role holders > netdom query FSMO;
• Note down your Domain and Forest Functional levels;

To be honest a lot of you will need new server hardware or new VMs, so you will be introducing 2012 R2 side by side with the existing servers. Makes it a lot easier than attempting to in-place upgrade the OS, which isn’t possible in some cases e.g. x32 and x64 2003/2003 R2 Servers CANNOT be OS upgraded to x64 2012 R2  directly.

Testing – you do have a Non Production environment, right?

Most of you won’t. Tough ask then, to make changes in Live. Well, try to mock up some kind of non-prod environment and make it as life like as possible – then try some testing. However such a vanilla environment won’t reflect reality so prepare for the worst and have a clear roll back plan.

Gotcha’s:

Updates to locally installed application services for monitoring or optimisation – make sure the product you use for monitoring/optimisation has a 2012 compatible version/pack available for example SCOM, Nagios, Foglight

Security products locally installed – e.g. Anti-Virus, Software Firewall products – make sure your security vendor(s) have a 2012 compatible version/upgrade available and ideally available to push out via your software deployment service.

Applications will fail to authenticate and will require remediation – some services running elsewhere in your organisation may fail to authenticate or work once you introduce 2012 R2 Domain Controllers or when you switch off all the legacy 2003 or 2008 ones. Plan for this.

Check for hardcoded host name usage – I’ve seen many organisations throughout the transitions and migrations I have completed where 3rd party services/applications are provided the hostname or IP address of specific DC’s in order to function. When these DC’s are no longer DC’s the application or service simply fails to function as before.

Domain-joined clients cover several versions of the Windows OS (NT4.0, 2000 Server, Server 2003, Server 2008, Server 2008 R2, Windows 7, Windows XP, Windows 8, Windows 8.1 ) all of which should continue to function as is EXCEPT NT 4.0 and 2000 Server – these 2 simply cannot communicate securely within a pure 100% 2012 R2 Active Directory service.

When you come to demote the old DCs do not accidentally tick the box “This is the last Domain Controller in the Domain” cos if you do then you’re in a whole heap of doo-dah. If that happens, please don’t call me. Pretty please.

File Replication Services (FRS) is fully depreciated in Server 2012 R2 so you better be rid of it prior to uplifting. The replacement is DFS Replication, see my brief guide HERE on how to do this.

What Will or Might break…

This list is by no means comprehensive but should give you some idea of what you need to watch out for:

• DNS – no internal or external DNS resolution. In other words you won’t be able to check if Murray is losing (again!)
• DHCP – clients drop of like lemmings of a cliff (oh how i loved that game!)
• Printers – users love to print. They get angry when they cannot. I’m a user too, I get ANGRY when i cannot print my Marvel superhero pics
• Network Devices – network stuff, that dark art of magicy wizardly stuff. Make sure a wizard is at hand to fix stuff
• Clients cannot authenticate – uh-oh, the big chiefs PA cannot log in this morning. BIG PANIC. IT staff hide out next door in Krispy Kreme (yum!)

The actual Process…how to Uplift to 2012 R2

Finally, what you actually came here to read. Phew, after all that nonsense upstairs. This is HOW and WHAT you need to do:

1. Get Change Approval and engage with all key stakeholders (CTO, CIO, IT Consultants/Architects, Senior Management, Application owners, Service Line Managers etc.). As stated before, finding out who application and service owners are is critical, both to engage them and keep them informed of the process.

2. Have a Roll Back plan, a method that states the steps to get back to before the next step i.e. as if you never started this.

3. Ensure good and verified backups of existing DCs have been taken, verify any offsite backups and ensure they can be restored without errors if needed

4. Replace/Upgrade/Uplift any existing Server Hardware and older OS (2008, 2008 R2 only) with 2012 R2

5. Add in all new servers with 2012 R2 installed that you may need. Join to your existing Domain as Domain members. Let then just chill out, before battle commences for takeover

6. Jump onto one of the new 2012 R2 servers. Add the AD DS Server Role, this will run AD Prep > SCHEMA Update (the bit that scares you all) > Domain Prep and part of that process is adding this as a new DC. After the update check your AD Schema version, go to a Domain Controller, run regedit and navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Parameters

7. Add in some DNS Role servers and allow DNS to replicate (your network has DNS as AD integrated right?! IF using BIND or other DNS Service then you have more work to do in your planning and testing stages)

8. Check that your newly introduced 2012 DCs are fully replicating, use REPLMON and check the event log for errors. In fact check both the System and Application event logs and filter for Warning, Critical, Error events.

9. Test your Apps and Services while 2012 R2 Domain Controllers are running at same time as your old ones

10. If you built new servers then transfer FSMO roles > Move-ADDirectoryServerOperationMasterRole -MyNewServer “Old Role Holder” -OperationMasterRole 0,1,2,3,4

11. Migrate any other roles and services running on existing DCs e.g. DNS, DHCP, CS, AD RMS to new DCs

12. Close down all ‘legacy’ Domain Controllers in a phased approach, always watching for service failures anywhere across your environments. It’s useful to make your Helpdesk aware and to relay any unusual incidents through to you on the Day After the Night Before

13. Pat yourself on the back, it all works nicely. Good job.

All these steps can either take an evening or many months to complete. That depends on the size and complexity of your infrastructure.

Supportability

No good using 2012 R2 if your nice support engineers don’t know PowerShell. Teach them, send them to a course or call me for some quick-fire lessons!

If you spot any errors, have any suggestions, tips or improvements please comment to let me know.