If you’re setting up Exchange 2013 in a lab, you may have a requirement to use a domain controller as a File Share Witness (FSW) host. Obligatory disclaimer: While this is definitely not recommended practise in a production environment, and may have undesirable results, it will probably work. I highly doubt Microsoft support this, though I have been unable to find any concrete evidence on it (frankly, it’s such terrible practise they shouldn’t have to publicise advice against it). If you can come up with a method to avoid following this guide in production, I implore you to do so.
The File Share Witness is used as the winning vote when your DAG has an even number of hosts – the same principle as the quorum drive in a Failover Cluster. This is a file server that all DAG members can read and write (but cannot be a DAG member for obvious reasons). If you just try to create a DAG and use a domain controller as a FSW, you’ll get this error message:
Checking the log file gives the following access denied message, which is less than helpful:
[2013-04-23T23:15:32] WriteError! Exception = System.Management.ManagementException: Access denied
at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementScope.InitializeGuts(Object o)
at System.Management.ManagementScope.Initialize()
at Microsoft.Exchange.Management.Common.WmiWrapper.TryGetSystemDrive(String computerFqdn)
at Microsoft.Exchange.Management.Common.FileShareWitness.Initialize()
at Microsoft.Exchange.Management.SystemConfigurationTasks.NewDatabaseAvailabilityGroup.InternalValidate()
What’s happening here is that the Exchange server is trying to create a file share on the FSW host, in this case E15DC1. In order to allow this functionality on a domain controller, you must add it to the Exchange Trusted Subsystem group. This is an Active Directory group used internally by Exchange for reading/writing this share, amongst other things. Typically it will only contain Exchange Servers, but go ahead and add your file share witness host to it as well:
Now comes the bit that makes the security part of me cringe. Exchange Trusted Subsystem (i.e. your Exchange servers) need to be able to create shares on this server and read/write them. As a domain controller has no local security groups, you need to apply this change directory-wide. Add Exchange Trusted Subsystem to your Administrators group:
What you’ve done here is made every Exchange server a domain admin. This means that anything running in the context of an Exchange server computer’s user account (E15MB1$, E15MB2$, etc.) has full rights over the domain.
After giving your DC a reboot (to update its security group membership), **Exchange Trusted Subsystem **will be able to create shares on it, and your DAG will be able to be created successfully:
Add some member servers and Bob’s your uncle. Did I mention don’t do this in production?
Comments/questions
There's no commenting functionality here. If you'd like to comment, please either mention me (@[email protected]) on Mastodon or email me. I don't have any logging or analytics running on this website, so if you found something useful or interesting it would mean a lot to hear from you.