SQL Server

How to Install SQL Server on a Read-Only Domain Controller (RODC)

The official Microsoft documentation says it's not possible, but with a little ingenuity and poor judgment, we can get SQL Server to run on an RODC.

Mike Wolfe

May 18, 2022 • 5 min read

Let's just start with the caveats.

Officially, Microsoft does not recommend installing SQL Server on a domain controller of any kind:

For security reasons, we recommend that you do not install SQL Server on a domain controller.

For read-only domain controllers, Microsoft goes further, flat out saying it's not even possible:

• SQL Server Setup cannot create security groups or provision SQL Server service accounts on a read-only domain controller. In this scenario, Setup will fail.

That's all well and good, but there are some situations where it is perfectly reasonable to have a read-only domain controller host an instance of SQL Server.

When Is This Ever a Good Idea?

One common example is a business with a central office and many smaller satellite offices, such as a community bank with an operations center and retail branches.

The operations center might have two dedicated servers: one that acts as the primary domain controller and the other that hosts a Standard Edition of SQL Server. Let's assume the branch offices only have about a dozen workstations.

In this scenario, a read-only domain controller (RODC) provides some insurance for when the primary domain controller is unreachable. A SQL Server Express install acting as a subscriber in a replication scheme provides similar performance and reliability benefits on the database side.

Paying for hardware and licensing of two servers for a dozen workstations is overkill.

This is just one example where installing a SQL Server instance on an RODC machine makes sense.

What's Really Stopping You?

For me, the problem was that the SQL Server setup application could not create a local security group to host the SQL Server Browser Service.

The SQL Server setup app was looking for a local user group named SQLServer2005SQLBrowserUser$MyServerName where "MyServerName" is the name of the server where you are trying to install SQL Server. Note that the "2005" in the name is hard-coded: it's the same for SQL Server 2016 and 2019 (and likely all versions of SQL Server 2005 and later).

The key, then, is to manually create the required user group before attempting the SQL Server installation.

Step-By-Step Instructions

I can't guarantee these will work for you, as I'm not sure how consistent and widespread this situation is. Please understand what you are doing before executing any of the steps below.

In my examples, I'm using the following hard-coded values that you will need to change:

mydomain.com: the Active Directory domain
ops-center-dc: the primary domain controller
branch-dc: the read-only domain controller (RODC)

Open Active Directory Users and Computers (ADUC)
Create a new group:
- Group name: SQLServer2005SQLBrowserUser$branch-dc
- Group name (pre-Windows 2000): {same as above}
- Group scope: (o) Domain local
- Group type: (o) Security
- [OK]
Force the replication of the Active Directory objects to the RODC
- From an admin cmd prompt:
  repadmin /replicate branch-dc.mydomain.com ops-center-dc.mydomain.com DC=mydomain,DC=com /readonly

Additional/Optional (?) Steps

When I got this working on my RODC a few years ago, there were several other things that I tried. I don't think they were important or necessary steps, but I could be very wrong about that.

In the interest of saving you some potential frustration, I will list them here now. I recommend that you ignore them initially. You can always come back and try these steps later if your install is still not working.

Create a Group Managed Service Account

I followed the guidance in this official Microsoft documentation, Getting Started with Group Managed Service Accounts. Read the article carefully for full instructions. For the sake of this example, let's assume I used the following PowerShell command to create the gMSA:

New-ADServiceAccount -name SqlBrowser -DNSHostName SqlBrowser.mydomain.com -PrincipalsAllowedToRetrieveManagedPassword "Read-only Domain Controllers"

NOTE: the "Read-only Domain Controllers" is a custom group of computers created within Active Directory; it is not a built-in group.

Add the gMSA to the Browser User Group

Open Active Directory Users and Computers (ADUC)
Double-click to open the Properties window of the SQLServer2005SQLBrowserUser$branch-dc group
Go to the "Members" tab
Click [Add...] > SqlBrowser$ -> [Check Names] -> [OK]

Set the gMSA as the Browser Service User Account

You can do this during the initial setup using the undocumented /BROWSERSVCUSERNAME flag from the command line when running a silent install of SQL Server: /BROWSERSVCUSERNAME=MyDomain\SqlBrowser$

You can do this after setup by editing the SQL Server Browser Service in the Services application:

SQL Server Browser: MyDomain\SqlBrowser$

If, when trying to start the service, you get this error message, "The service did not start due to a logon failure," then perform the following steps:

Double-click the service to open its Properties window
Switch to the "Log On" tab
Log on as:
(o) This account: MyDomain\SqlBrowser$
Password: {leave blank}
Confirm password: {leave blank}
Click [OK]
Start the service

Do not use the [Browse…] button to find the account name. Simply type it exactly as it appears above (including the trailing $ sign). The password fields are left blank because these are group Managed Service Accounts (gMSA) and Active Directory manages the account passwords behind the scenes.

Will This Work for You?

Maybe?

Both times this solved my problem I was attempting to install a named instance of SQL Server. I'm not sure if that is meaningful or just coincidence.

Honestly, I don't do SQL Server installations that often. I do a handful of installs every time a version of SQL Server goes out of support, which is about every three years or so. Keep that in mind, as I have no idea how widespread a problem this is. However, a form of this solution has worked for me on two separate occasions several years apart.

What I do know is that I spent the better part of three full days figuring out how to make this all work. If I can save somebody some of that time and frustration–including future me–then this article will have been worth it.