RODC install issues

In certain areas of your expanded perimeter, installing an RODC has good security benefit.  There are some issues that can occur when installing an RODC.  It mostly has to do with the way AD works, but it is important to note.

Issue 1)  Don't create the site before you add the DC.

In a recent RODC setup, we decided to "jump the gun" and add the site to sites and services before setting up the RODC.  The problem with this is that you have to log in as a domain admin before you can promote a server.  This act causes AD to pick a DC from the next closest site (since the site you setup doesn't have one yet) and add it's DNS records to the site.  Once this is done, you are at the mercy of AD weights and priorities to determine which logon server you will use. 

This article has more detail on the AD Locator process. The solution is to go through DNS and delete the appropriate records for the incorrect DC.   

Issue 2)  Be mindful of which passwords are allowed to replicate

Only passwords that are explicitly allowed and not explicitly denied are allowed to replicate.  By default, the policy is quite restrictive, and with good reason.  You are probably deploying an RODC in a semi-trusted segment.  You probably don't want your schema admin password to be cached out there.  There are tools built in to AD to help you figure out who is authenticated to the RODC, and to allow you to test a user to see if the password would allowed to be cached.  You can also pre-populate passwords.  This is all done via the AD user and computers snap-in.

Issue 3)  Configuring Site Link Costs

Remember to change the costs of the site links!  If you want AD to always choose your RODC (unless it is unavailable), configure the site link cost appropriately. 

Issue 4)  Cached DC

Once the DC Locator process runs, the result is cached on the machine.  If you run into any of issues 1/2/3, you may be authenticating against the wrong DC.  Fixing the issue at the server level doesn't solve the problem because the result is already cached.

You can check to see what DC is cached using the nltest command.  You may have to copy the executable from a DC to a non-dc machine.

nltest /DSGetDC:<domain name>

To update the result, you can use

nltest /DSGetDC:<domain name> /FORCE

Issue 5) Use Azure data disks for the AD DS files

This issue is Azure specific, but probably a good location where you would want to deploy an RODC. 

See this article

Although you shouldn't have an issue when you deploy an RODC, it is good to follow the best practices outlined.