Share via

Minimizing Risk During AD Upgrades

  • Article

So you need to upgrade your AD domains and forests to W2K8 or W2K8R2 DCs to take advantage of new cool features. But your concerned about what's going to break once you begin introducing new DCs.

Fortunately, we have lots of documentation available regarding changes in the OS which should help customers determine up front the changes and therefore what may break. I previously blogged on this topic. https://blogs.technet.com/b/glennl/archive/2009/08/21/w2k3-to-w2k8-active-directory-upgrade-considerations.aspx. Do review these resources as they describe known issues that should be addressed for applicability in your environments.

First and foremost, we encourage you to test your applications and their coexistence with DCs running W2K8 or W2K8 R2 in a lab environment. You should also engage the vendors of your applications to ensure they have validated their applications running on servers in domains that run W2K8 or W2K8 R2 DCs. See our Upgrading AD domains Technet portal for our official guidance on planning and executing on domain upgrades. https://technet.microsoft.com/en-us/library/cc731188(WS.10).aspx

You may be saying to yourself, how can I test all my applications when I don't have a complete inventory or the staff or facilities (robust lab) with which to perform thorough adequate testing? This is a big problem for IT shops unfortunately. If you cannot or don't plan to thoroughly test all your applications in a lab environment prior to upgrading, then this blog is for you. 

As you read this, keep in mind the intent is not to help your efforts to identify application compatibility, and infact may hinder them. The intent is to offer methodology for a controlled deployment of and consumption of up-level DC resources. This approach is not for everyone, and if your applications are communicating over standard protocols NETAPI, LDAP, and NSPI, there shouldn’t be any issues outside of new constraints and known compatibility issues already documented in my blog and elsewhere.

The idea behind the following approach is to allow you to promote a new W2K8/W2K8R2 DC into your W2K3 domain and keep it temporarily hidden/isolated from computers and applications. This will give you the ability to methodically and systematically perform application testing over time to identify and rectify application compatibility issues. Again, if you don't have a thorough inventory of the applications leveraging DC resources, then this approach arguably provides no value. 

The focus of this strategy is targeted at the introduction of a new DC itself and not the needed preparatory steps required prior to deploying the W2K8 DC. We have guidance on testing Schema extensions here.

Hiding and isolating DCs involves a number of strategies, the more of which are performed, the better 'hidden' the DC from the general population of computers and applications.

1) Build a new logical AD site with site link to datacenter site. Configure the subnet for this site to the IP address of the yet to be promoted W2K8 DC. e.g., 192.168.14.231/32. Yes you can use a 32 bit mask to identify and associate a subnet to a site in AD.

2) Add DnsAvoidRegisterRecords to the registry of the yet to be promoted W2K8 server. The only records you absolutely must register are the host record and the cname record. All the rest of the records are there for clients to find DCs. So, if you don't register them, you effectively hide the DC from the most common method of discovery. You will want to register site specific SRV records so the yet to be promoted DC will register records for its temporary site. **important** Many customers have process issues resulting in subnets not being properly associated with sites in AD. The affected clients, then must use the fallback siteless SRV records to find DCs. Preventing their registration by this yet to be promoted W2K8 server will maintain the ability to control its 'advertising' its resources through DNS record registration.

3) Don't point the yet to be promoted W2K8 server to WINS. A less common way DCs are discovered is through a DCs registration of a WINS <1C> record. Don't point the DC to a WINS server and this record will not get registered by the server after promotion.

4) Consider putting the DC onto a separate VLAN. This may be overkill, but it will prevent the DC from being discovered through subnet broadcasts.

5) Prepare your forest and domain using ADPREP, then promote your first W2K8 DC into the temporary site. Since the DC will register its host record and cname record and site specific records only, it is discoverable by the other DCs for AD/SYSVOL replication purposes, but is otherwise hidden/isolated from clients/servers/applications on your network.

Systematically test computers/application usage and coexistence with W2K8 DCs.

1) For applications running on Windows that find DCs through DCLocator, move the application servers into the temporary site....during a maintenance window of course.

a) Add SiteName string value to netlogon\parameters registry key on the application servers and set it to the temporary site name. SiteName overrides DynamicSiteName written by the dclocator algorithm. Basically you are telling the computer what site it belongs to without having to change/create subnet configuration in AD.

b) change the secure channel of the application server to the W2K8 DC using nltest /sc_reset:domain\dcname

c) wait until Kerberos tickets expire, or reboot the application server, then have the application owner perform functionality testing.

1) now if the scenario is more complex...client connects to application, which impersonates client to access resources on backend servers, then you will want to do a,b,c on client and backend systems to make the testing as realistic as possible.

2) For LDAP applications running on Windows that use the domain A record to find a DC, add a host file entry on the application server pointing the domain A record to the W2K8 DC

a) wait until kerberos tickets expire, or reboot the application server, then have the application owner perform functionality testing.

3) For LDAP applications not running on Windows, identify the mechanism they use to find a DC/LDAP server...probably configured in the application itself…then provide it with the DC A record or domain A record, or SRV record to be used to find the W2K8 DC.

a) execute on a test matrix to ensure application functionality.

4) General authentication and ticket processing through the W2K8 DC. Work with business unit managers (aka..guinea pigs) to put their machines into the temporary site (SiteName reg value) and have them perform their normal business functions for a while....tests their machine and locally installed apps ability to use the new DC for auth and queries.

Remove Isolation and 'introduce' the W2K8 DC to the masses

Once you are satisfied that you have done adequate testing and have resolved app compat issues or created GPOs to relax DC settings to work with app compat issues, it is time to remove the isolation strategies.

1) remove SiteName from any systems it was added to.

2) remove the host file entry from any systems it was added to.

3) remove the DnsAvoidRegisterRecords value on the W2K8 DC.

4) point the DC to WINs if you have WINS deployed.

5) re-IP the DC if it was put on an isolated VLAN

6) move the DC into the production site and retire the temporary site/sitelink/subnet

Comments

  • Anonymous
    September 24, 2013
    Glenn - Does this isolation strategy apply for W2k8R2 to W2k12 AD upgrade?  Thx.

  • Anonymous
    July 16, 2014
    You look at Windows Server 2012 R2 and you tell yourself: "that would be nice if I could leverage

  • Anonymous
    September 03, 2015
    Yes it does, check out http://rietveld-ict.nl/create-hidden-active-directory-site-application-testing-purposes/ to use this strategy by using GPO function.

  • Anonymous
    February 05, 2016
    Three lines of code to confine a domain controller to a specific site. Great for testing.