Friday, March 19, 2010

Manually create FileWitness Share

When creating the DAG in Exchange 2010, Microsoft recommends that the FSW is located on a HUB server in the environment. One of the reasons is that these servers are the Exchange owners, and the Exchange admins have full control. It is recommended to place the FSW share in a third location or in the primary location.

To provide failover functionality to the FSW, you can use file cluster, Force cluster @File Share Witness and Force Quorum Guidance or the old and no longer recommended method of DNS CNAME.

At one of my customers, we have placed the FSW on a file cluster, since this gives us the full
redundancy in the case of a datacenter failure. The customer has two datacenters, but they are in a single site.

And Microsoft recommends you to add the Exchange Trusted Subsystem group in the local admin group of the server holding the FSW. But this might not be compliant to security rules. This is as far as I have understood just so the set-databaseavailability command can create the folder and shares.

To pre-create the FSW share you need the following:

- Create a folder etc. D:\FilesWitness\DAGNAME
- Give the owner permission to Exchange Trusted Subsystem
- Give the Exchange Trusted Subsystem Full Control (NTFS)
- Share the folder with the following DAGNAME.FQDN (If you try a different share name, it won't work. This is somehow required)
- Give the DAGNAME$ computeraccount Full Control (Share)

When you've done this, you can run the
set-databaseavailabilitygroup -witnessserver CLUSTERSERVER - witnessdirectory D:\Filewitness\DAGNAME

You'll get the following warning message:
WARNING: Specified witness server Cluster.fqdn is not an Exchange server, or part of the Exchange Servers security group.WARNING: Insufficient permission to access file shares on witness server Cluster.fqdn. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the set-databaseavailabilitygroup cmdlet to try the operation again. Error: Access is denied

This is expected, since the cmdlet tries to create the folder and share, but don't have the permissions to do this.
When this is done, the FSW should be configured correct. To verify this, the following files should be created:

- VerifyShareWriteAccess- Witness

This should do the trick, and the FSW is ready to work, and follow the active datacenter.
There could be a slightly drawback with using a file cluster as FSW. If the file cluster gets in a split brain scenario, then the Exchange solution could get affected. A result of this could be two active database servers on the same database, resulting in corrupt data. But this is theoretically, and in special circumstances.


No comments: