Microsoft is shifting focus on Load Balancing solutions. During TechEd 2010 in Berlin it was announced that Windows Network Load Balancing (NLB) is no longer recommended (but still supported) and that the recommendation will be to use a hardware load balancer.

Another new recommendation is to use combined Exchange server with all three Server Roles, i.e. Hub Transport, Client Access and Mailbox Server Role when possible.

When using a Database Availability Group (DAG) you have to use a server outside the DAG as a File Share Witness (FSW). Normally an Exchange 2010 Hub Transport Server is recommended for FSW usage, but when using a two node DAG each with three Server roles an additional Hub Transport Server might not be available.

Any Windows server in the domain can be used a an FSW since it is nothing more than a (small) file share where to files are stored. For example, in this scenario a fileserver is used as an FSW. The only requirement is to add the domain group “Exchange Trusted Subsystem” to the local administrators group of the server.

The Witness Server and the Witness Directory are a property of the DAG and can be changed using the Exchange Management Shell or the Exchange Management Console. In the Management Shell just use the following command:

Set-DatabaseAvailabilityGroup –Identity <<DAG_Name>> -WitnessServer <<ServerName>> -WitnessDirectory <<Directory on disk>>

Or if you prefer to use the Exchange Management Console, select the DAG, open the properties and change the Witness Server and the Witness Directory:

The DAG properties will now be changed. When turning off one node of the two-node DAG the FSW will be activated on the fileserver FS01 as can be seen on the local disk of the FS01 server:

Now we have a two node DAG where each node has three Server Roles and the File Share Witness stored on a Fileserver.

Using a Domain Controller as an FSW is sometimes “recommended” as well, it even happens in the standard Exchange 2010 official training (10135 – Configuring, Managing and Troubleshooting Microsoft Exchange Server 2010). From a security perspective this is not a good idea. Usable in a lab environment but not in a production environment as can be read in Devin Ganger’s blogpost: http://www.thecabal.org/2009/12/busting-the-exchange-trusted-subsystem-myth/