Hi
I am in an interesting situation while implementing an Exchange solution following a given high level design.
A new Exchange environment is being built with 3 Exchange servers all of which are multi-role servers. There are 2 domain controllers in the domain. There are NO other servers in the domain as this is going to be a resource forest deployment.
I need to configure a DAG and add all three Exchange servers as the DAG members. The high level solution design by client was based on the understanding that FSWs were not required for odd number node DAGs and as such the design has no provision for a separate FSW.
The above assumption/understanding is incorrect and a DAG does need an FSW configured and cannot be created without specifying an FSW, regardless of whether it will have even number of nodes or odd (this is obviously not even known to Exchange at the time of creating the DAG).
It will not be possible to provision a separate server for the DAG that is not a DC and is not an Exchange server. Therefore, it seems I am stuck between making one of the below choices.
1. Specify one of the multi-role Exchange servers as the FSW.
This will work and will not even need adding the "Exchange Trusted Subsystem" to local administrators as the server is an Exchange server.
Speaking against this option, it seems obviously dumb to add a DAG member as an FSW for the same DAG, thus allowing one machine to have 2 votes in the DAG.
Speaking in favour of this option, it seems OK as the FSW has no real function in an odd number of nodes DAG because it is only ever consulted in case of a tie between the voting members (mailbox servers) which, by design, cannot happen in our design due
to 3 node DAG. For all practical purposes it is non-existent. (Whether or not this remains true in case of a datacentre switchover scenario in which DAG members are forcibly temporarily evicted to create quorum is something to think about).
OR
2. Specify one of the domain controllers as the FSW
Speaking against this option, it is a violation of Microsoft recommendations. It also requires adding "Exchange Trusted Subsystem" to the "Administrators" group for the domain as there are no local accounts and groups on the DCs so "Exchange Trusted
Subsystem" can only be added to the "Administrators" group for the domain. This gives "Exchange Trusted Subsystem" more permissions than were intended. How much of a risk this is, it is something to think about and would like your views on it.
Speaking in favour of this option, it is arguably more acceptable having making a DAG member an FSW in the same DAG. It is still a separate server that for all intents and purposes perform all the functions a member server FSW would perform.
I know this is going to be a tight one as both options are not following the best practises but getting a separate server to be added to the resource forest just to act as the FSW will prove difficult. There is a change control and design review process involved so the arguments to go with one of the above options will need to be carefully constructed by me.
I would like your views on this please to see whether one of the above solutions is acceptable and why.
Many thanks
Mohsin.
Best regards Mohsin Abbas MCP, MCTS My Blog: http://blog.mohsinabbas.com/ Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.