Witness Server Warning Message When Using Certain Database Availability Group Tasks

  • Article

Recently, some customers reported that when they create a DAG, they get a warning message that states the following:

The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server <ServerName>.

In these cases, the customer’s intended witness server was not an Exchange 2010 server.  As documented in TechNet, if the witness server you specify isn't an Exchange 2010 server, you must add the Exchange Trusted Subsystem (ETS) universal security group (USG) to the local Administrators group on the witness server. These security permissions are necessary to ensure that Exchange can create a directory and share on the witness server as needed.

After some inspection, the customers confirmed that, contrary to the error message, the ETS USG was a member of the local administrators group on their intended witness server.  Moreover, even though this warning appeared, there were no ill effects in functionality.  The directory and share on the witness server were created as needed, the file share witness cluster resource was online, and the DAG passed all replication health checks.

After hearing about this, I went to my lab to test this, and I was able to reproduce the issue.  I added the ETS USG to the local administrators group on my witness server (a Windows 2008 file server) and ran New-DatabaseAvailabilityGroup, specifying my witness server.  I received the same warning message, and verified that despite the message, all was perfectly healthy with the DAG, and there were no permission problems, witness server or cluster problems or other issues.

Even though it appeared as though this warning message could be safely ignored, I wondered why we were getting it in the first place.  So I went digging into the source code to find out.

Let me describe what is happening and why you, too, can safely ignore the warning message.

During various DAG-related tasks that configure witness server properties (namely, New-DatabaseAvailabilityGroup, Set-DatabaseAvailabilityGroup and Restore-DatabaseAvailabilityGroup), the code is actually checking to see if the witness server is a member of the Exchange Trusted Subsystem USG.

As you may know, there is no requirement that the witness server be a member of the ETS USG.  Nonetheless, the code for these tasks does check for this, and if it finds that the witness server is not a member of the ETS USG, it issues a warning message.

Unfortunately, to confuse things even more, the warning message says:

The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server <ServerName>.

It says nothing about the witness server not being a member of the ETS USG, even though the code is checking for that.  Instead, it makes it appear as though the permission perquisites have not been satisfied, even though they actually have.

But, even though the message does not pertain to the actual check that failed, that does not make this a string bug.  This is a code bug, as there is no requirement that the witness server be a member of the ETS USG.  Thus, the code should not be checking for this condition.  If this bug is fixed and the check is removed, the string will be removed with it. Unless and until that happens, if you are seeing this warning message when you are using any of the above-mentioned tasks, and you have verified that the ETS USG is a member of the local administrators group on your witness server, then you can likely safely ignore the warning message. You should run Test-ReplicationHealth to verify the health of the DAG once members have been added to it.

Because we are doing this check in code, you can of course add the witness server to the ETS group, and also make the ETS group a member of the local administrators group on the witness server, and all of these tasks will complete without this warning message. But, don't do that in production because (1) it is not needed and (2) it gives the witness server way more permissions than it should ever have (unless of course, the witness server is an Exchange 2010 server).