When I look back at the projects I’ve been a part of for the past few years, I’ve found that I average at least three to four domain and/or forest upgrades a year. This isn’t too big of a surprise for me because most Microsoft products depend on Active Directory in some shape or form. Whenever I talk to a client about a domain or forest upgrade, I try to articulate the careful planning required when undergoing such an upgrade even though the actual upgrade itself is less than ten mouse clicks. Depending on the client, I find that some are and some are not receptive to review a complete inventory list of applications within the environment even though I believe it’s extremely important. With that being said, I’m all for doing due diligence for this upgrades and I almost always push back if I’m told to just blindly do it. Now that I’ve put forward my 2 cents about domain and forest upgrades, as the title suggests, this post will be a walk through of rolling back an upgrade.
First and foremost, the following are two links that I used to demonstrate this rollback and please note that as detail as I would like to be, you can find more information about the steps in the links:
Reference links:
Recovering Your Active Directory Forest - http://technet.microsoft.com/en-us/library/cc757662(WS.10).aspx
Appendix A: Forest Recovery Procedures - http://technet.microsoft.com/en-us/library/cc781218(WS.10).aspx
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
The environment I will be using consists of the following:
Domain Controllers: 2
Domain Controller Names: DC1 and DC2
Domain Controller Build: Windows Server 2003 R2 64-bit
Service Pack: 2
Number of forests: 1
Number of domains: 1
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Before I proceed, I would like to note that this recovery process will demonstrate the recovery of only ONE domain controller which holds the FSMO roles and the second domain controller in the environment will be removed from the domain through metadata cleanup. More information as to why can be found in the reference links above but to quickly outline why, it’s because of the steps required to recover the domain will not work if you try to recover a 2nd domain controller. Also note that simply performing an authoritative restore of the Active Directory database on, say, DC1 then a non authoritative on DC2 will NOT work.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Backing up Active Directory
The first step you should complete prior to actually upgrading the domain and forest is to perform a backup of Active Directory. To do so, log onto your domain controllers and perform a system state backup. I always prefer to backup all of the domain controllers in the domain / forest in case there is ever a problem with one of the backups.
Start up NTBackup on your domain controller and select the System State from the list of items to be backed up:
Once you’ve defined the path and selected the System State proceed with the backup:
Upgrade Domain and Forest Functional Level
Once you’ve backed up your domain controllers, proceed with upgrading the domain:
Restoring Active Directory
Now that we've upgraded the domain, proceed with restoring the Active Directory database as per the following steps:
Prior to actually proceeding to restore the System State that was backed up, we will need to restart the domain controller in Directory Services Restore Mode either locally or remote. Locally is done by simply hitting F8 during start up while for remote, we’ll need to edit the start up options in the boot.ini file:
To force the domain controller to restart in Directory Services Restore Mode simply append the following to the end of the boot.ini file:
/SAFEBOOT:DSREPAIR
... which will change your boot.ini file to look something like this:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003 Enterprise x64 Edition" /noexecute=optout /fastdetect /SAFEBOOT:DSREPAIR
Once the changes have been completed, proceed with rebooting the domain controller:
If you have access to the console, you’ll notice that once the domain controller begins to start up, the wallpaper will look different:
Wait for the boot up process to complete and you’ll be able to remote desktop to the domain controller:
It’s important to note that you will need to login with the Active Directory Restore Mode password and if for some reason you need to have forgotten it, use the following KB article to reset it: http://support.microsoft.com/kb/322672.
Once you’ve successfully logged in, you’ll be promopted with the following warning/informational message:
One of the first things I do once I successfully get into the domain controller is to remote the /SAFEBOOT:DSREPAIR switch from the boot.ini file:
Once you’ve completed the change to the boot.ini file, continue with restoring the the backed up System State to the domain controller:
Note that since we’ll only be recovering 1 domain controller for the domain prior to the domain and forest upgrade, we’ll need to select the last option:
When restoring replicated data sets, mark the restored data as the primary data for all replicas.
Once the backup is complete, click on the Close button and remember to select Yes when asked to reboot:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Warning
It’s important to note that we make sure the other domain controllers are not on the network even if it is rebooted into Directory Services Restore Mode or we’ll see a lot of Event ID: 1030 errors logged in the Application logs:
Another problem that you may encounter if you’ve accidentally left the other domain controllers on is when you try to browse the UNC path: \\domain.com and then receive the following error:
\\domain.com is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.
You were not connected because a duplicate name exists on the network. Go to System in Controll Planel to change the computer name and try again.
Don’t worry too much about the NTDS Replication (Event ID: 2087) errors because they reference this domain controller’s inability to replicate to the other domain controllers within the domain:
Active Directory could not resolve the following DNS host name of the source domain controller to an IP address. This error prevents additions, deletions and changes in Active Directory from replicating between one or more domain controllers in the forest. Security groups, group policy, users and computers and their passwords will be inconsistent between domain controllers until this error is resolved, potentially affecting logon authentication and access to network resources.
Source domain controller:
DC2
Failing DNS host name:
5fb9ecdd-a78e-4067-8299-0ce9fef9c076._msdcs.contoso.local
NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur. To log all individual failure events, set the following diagnostics registry value to 1:
Registry Path:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC Client
User Action:
1) If the source domain controller is no longer functioning or its operating system has been reinstalled with a different computer name or NTDSDSA object GUID, remove the source domain controller's metadata with ntdsutil.exe, using the steps outlined in MSKB article 216498.
2) Confirm that the source domain controller is running Active directory and is accessible on the network by typing "net view \\<source DC name>" or "ping <source DC name>".
3) Verify that the source domain controller is using a valid DNS server for DNS services, and that the source domain controller's host record and CNAME record are correctly registered, using the DNS Enhanced version of DCDIAG.EXE available on http://www.microsoft.com/dns
dcdiag /test:dns
4) Verify that that this destination domain controller is using a valid DNS server for DNS services, by running the DNS Enhanced version of DCDIAG.EXE command on the console of the destination domain controller, as follows:
dcdiag /test:dns
5) For further analysis of DNS error failures see KB 824449:
http://support.microsoft.com/?kbid=824449
Additional Data
Error value:
11004 The requested name is valid, but no data of the requested type was found.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Removing Global Catalog settings
Remove the Global Catalog role from the domain controller:
Raising the value of available RID pools
Reference Link: http://technet.microsoft.com/en-us/library/cc781218(WS.10).aspx#RaiseRIDPool
As per the link above, the following are instructions on raising the value of the available RID pools:
Use the following procedure to raise the value of the relative ID (RID) pools that the RID operations master will allocate after that domain controller is restored. By raising the value of the available RID pools, you can ensure that no domain controller allocates a RID for a security principal that was created after the backup that was used to restore the domain. The following procedure applies to domain controllers that run Windows Server 2003 or Windows Server 2008.
To raise the value of available RID pools
1. At the command prompt, change directories to the folder that contains the Windows Support Tools, type the following command, and then press ENTER:
ldp
2. Click Connection, click Connect, type the name of the server on which you want to raise the RID pool, and then click OK.
3. Click Connection, click Bind, type your administrative credentials, and then click OK.
4. Click View, click Tree, and then type the following distinguished name path:
CN=RID Manager$,CN=System,DC=<domain name>
This account has an attribute named rIDAvailablePool. This attribute value maintains the global RID space for an entire domain. The value is a large integer with upper and lower parts. The upper part defines the number of security principals that can be allocated for each domain (0x3FFFFFFF or just over 1 billion). The lower part is the number of RIDs that have been allocated in the domain. To view both parts, in Ldp.exe use the Large Integer Converter command in the Utilities menu.
· Sample Value: 4611686014132422708 (Insert in Large Integer Calculator in the Utilities menu of Ldp.exe)
· Low Part: 2100 (beginning of the next RID pool to be allocated)
· Upper Part: 1073741823 (total number of RIDs that can be created in a domain)
When you increase the value of the large integer, you increase the value of the low part. For example, if you add 100,000 to the sample value of 4611686014132422708 for a sum of 4611686014132522708, the new low part is 102100. This indicates that the next RID pool that will be allocated by the RID master will begin with 102100 instead of 2100.
5. Click Browse, and then click Modify.
6. Add 100,000 to the current rIDAvailablePool value, and then type the sum into Values.
7. In Dn, type cn=RID Manager$,cn=System,dc=<domain name>.
8. In Edit Entry Attribute, type rIDAvailablePool.
9. Select Replace as the operation, and then click Enter.
10. Click Run to run the operation.
-----------
***Call Modify...
ldap_modify_s(ld, 'CN=RID Manager$,CN=System,DC=contoso,DC=local',[1] attrs);
Modified "CN=RID Manager$,CN=System,DC=contoso,DC=local".
-----------
Once the rIDAvailable attribute value has been updated, you can repeat the step above that lists the attribute’s value to confirm the changes:
Seizing FSMO roles
As we’ll be recovering the domain controller that already holds the FSMO roles, we can safely skip this step as outlined in the reference links.
Metadata Cleanup
Since DC2 will not be recovered and should not be brought back online, we’ll need to manually remove it from Active Directory as per the following instructions:
How to remove data in Active Directory after an unsuccessful domain controller demotion: http://support.microsoft.com/kb/216498
Once you’ve successfully removed the metadata, proceed with removing the orphaned object in Active Directory Sites and Services:
Clean up DNS
This step is optional but I prefer to manually comb through the DNS zones to ensure that all of the references to DC2 have been removed and if they’re still there, proceed to remove it manually.
Resetting the computer account password of the domain controller
Reset the krbtgt Account Password
Once you’ve successfully reset the domain controller’s password, proceed with resetting the krbtgt account’s password:
Make sure reset the password twice.
Enable Global Catalog
Now that we’ve completed the steps outlined above, proceed with enabling the domain controller as a Global Catalog server:
From here on, we should have successfully rolled back the domain and forest functional level:
The last step outlined in the reference links suggests to speed up replication cross domains. In this example, we only have 1 domain which is the root but if you have to do this in a multi-domain environment, proceed with the following steps:
The following are ways to speed up the process of adding the global catalog to the domain controller in the root domain:
- Ideally, the domain controller in the root domain should be a replication partner of the restored domain controllers in the nonroot domains. If so, confirm that the Knowledge Consistency Checker (KCC) has created the corresponding repsFrom object for the source domain controller and partition in the root domain controller. You can confirm this by running the repadmin /showreps /v command.
- If there is no repsFrom object created, create this object for the configuration partition. This way, the domain controller in the root domain can determine which domain controllers in the nonroot domain have been deleted. You can do this with the following commands:
repadmin /options DSA +Disable_NTDSCONN_XLATE
repadmin /add ConfigurationNamingContext DestinationDomainController SourceDomainControllerCNAME
repadmin /options DSA -Disable_NTDSCONN_XLATE
The format for the SourceDomainControllerCNAME is:
sourceDCGuid._msdcs.<root domain>
For example, the repadmin /add command for the configuration partition of the contoso.com domain could be:
repadmin /add cn=configuration,DC=contoso,DC=com DC01 937ef930-7356-43c8-88dc-8baaaa781cf6._msdcs.dDSP17A22.contoso.com - If the repsFrom object is present, try to sync the domain controller in the root domain with the domain controller in the nonroot domain as follows:
repadmin /sync DomainNamingContext DestinationDomainController SourceDomainControllerGUID
Where DestinationDomainController is the domain controller in the root domain and SourceDomainController is the restored domain controller in the nonroot domain. - The root domain DNS server should have the alias (CNAME) resource records for the source domain controller. Ensure that the parent DNS zone contains delegation resource records (name server (NS) and host (A) resource records) for the correct domain controllers (the domain controllers that have been restored from backup) in the child zone.
- Make sure that the domain controller in the root domain is contacting the correct Key Distribution Center (KDC) in the nonroot domain. To test this, at the command prompt, type the following command, and then press ENTER:
run nltest /dsgetdc:<nonroot domain name> /KDC
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hope this gives anyone who may not have rolled back a domain upgrade an idea of what it looks like.
No comments:
Post a Comment