Using a Non-Exchange Server as an Exchange 2013 DAG File Share Witness

In my recent article on installing an Exchange Server 2013 Database Availability Group I gave the example of using a Windows Server 2012 server that is not installed as an Exchange server as the file share witness for the DAG.

In this article I will take a more detailed look at the requirements for that scenario.

To begin with, this is what you would likely see if you tried to use a Windows Server 2012 server as the file share witness after a default installation of the operating system.

exchange-2013-dag-fsw-01

The task was unable to create the default witness directory on server [your server name]. Please manually specify a witness directory.

If you take that advice and specify a witness directory you will still receive an error.

exchange-2013-dag-fsw-02

The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server [your server name].

Unable to access file shares on witness server [your server name]. 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: The network path was not found.

At this point you have two options for proceeding.

  1. You can remove the newly created DAG (since it has just been created and doesn’t yet have members), fix the requirements I’m about to list below, and then create the DAG again; or
  2. Fix the requirements below and run Set-DatabaseAvailabilityGroup to correct the DAG configuration.

For this example I’ll be taking the second approach, but you can choose either one.

There are three requirements we need to meet:

  • The Exchange Trusted Subsystem group in Active Directory must be added to the local Administrators group on the server that will be the file share witness
  • The File Server feature (FS-FileServer) must be installed on the file share witness
  • File and Print Sharing must be allowed through the Windows Firewall if the firewall is enabled

So, first add the Exchange Trusted Subsystem group to local Administrators on the file share witness.

exchange-2013-dag-fsw-03

Next, install the FS-FileServer feature by running the following command in PowerShell.

PS C:\> Add-WindowsFeature FS-FileServer

Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             Success        {File and iSCSI Services, File Server}

Finally, check the Windows Firewall is configured to allow File and Printer Sharing.

exchange-2013-dag-fsw-04

Note: the File and Printer Sharing step may not need to be manually performed, as it appears that Exchange may enable it automatically anyway. However given that it is a requirement I still perform the manual step anyway.

If you’re following the second approach as I am you can now run Set-DatabaseAvailabilityGroup to fix the file share witness configuration for the DAG.

[PS] C:\>Set-DatabaseAvailabilityGroup E15DAG -WitnessServer E15FSW -WitnessDirectory C:\FSW_E15DAG

If successful then you will may or may not see the file share witness directory depending on whether you manually specified it.

  • if you did not manually specify the file share witness directory then a directory of C:\DAGFileShareWitnesses will be created automatically, however it will remain empty until you add DAG members
  • if you did specify a witness directory then it will not be created until there are DAG members, after which time it will also have the witness folder added

exchange-2013-dag-fsw-07

When you have all of those requirements met and you’re recreating the DAG from scratch then the DAG will be successfully created. However at the moment you will still see the following error:

exchange-2013-dag-fsw-05

The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server [your server name].

This error is a bug, as it was in Exchange Server 2010 under the same scenario. Until the bug is corrected in a future update you can refer to the DAG task log files in C:\ExchangeSetupLogs\DAGTasks.

A successful DAG creation will have log entries similar to this:

new-databaseavailabiltygroup started on machine E15MB1.
[2013-02-07T12:11:51] new-dag started
[2013-02-07T12:11:51] commandline:         $scriptCmd = {& $wrappedCmd @PSBoundParameters }

[2013-02-07T12:11:51] Option 'Name' = ''.
[2013-02-07T12:11:51] Option 'WitnessServer' = 'E15FSW'.
[2013-02-07T12:11:51] Option 'WitnessDirectory' = 'C:\FSW_E15DAG'.
[2013-02-07T12:11:51] Option 'WhatIf' = ''.
[2013-02-07T12:11:51] The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server E15FSW.
[2013-02-07T12:11:51] New-DatabaseAvailabilityGroup passed the initial checks.
[2013-02-07T12:11:52] New-DatabaseAvailabilityGroup completed successfully.
new-databaseavailabiltygroup explicitly called CloseTempLogFile().

An unsuccessful DAG creation will have log entries similar to this:

new-databaseavailabiltygroup started on machine E15MB1.
[2013-02-07T11:57:43] new-dag started
[2013-02-07T11:57:43] commandline:         $scriptCmd = {& $wrappedCmd @PSBoundParameters }

[2013-02-07T11:57:43] Option 'Name' = ''.
[2013-02-07T11:57:43] Option 'WitnessServer' = 'E15FSW'.
[2013-02-07T11:57:43] Option 'WitnessDirectory' = ''.
[2013-02-07T11:57:43] Option 'WhatIf' = ''.
[2013-02-07T11:58:06] The operation wasn't successful because an error was encountered. You may find more details in log file "C:\ExchangeSetupLogs\DagTasks\dagtask_2013-02-07_11-57-43.908_new-databaseavailabiltygroup.log".
[2013-02-07T11:58:06] WriteError! Exception = Microsoft.Exchange.Management.Tasks.DagFswUnableToBindWitnessDirectoryException: The task was unable to create the default witness directory on server E15FSW.exchange2013demo.com. Please manually specify a witness directory.
   at Microsoft.Exchange.Management.Common.FileShareWitness.Initialize()
   at Microsoft.Exchange.Management.SystemConfigurationTasks.NewDatabaseAvailabilityGroup.InternalValidate()

And obviously a successully created DAG will be visible in the Exchange Admin Center after the task completes.

exchange-2013-dag-fsw-06

For more on Exchange Server 2013 Database Availability Groups check out the article series that begins here.

About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Find Paul on Twitter, LinkedIn or Google+, or get in touch for consulting/support engagements.

Comments

  1. Hi Paul,

    I have been following your installation guide for installing exchange 2013 and setting up a DAG group.
    The posts were very helpful, thanks you. I’m having an issue with the file share witness it’s failed and I’ve tried to bring it on line but keep getting errors. I have deleted it and tried adding a new one but get the below error. Can you help please?

    [PS] C:\Windows\system32>Set-DatabaseAvailabilityGroup DAG-2013 -WitnessServer WSUS -WitnessDirectory C:\FSW_DAG-2013
    WARNING: The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server
    WSUS.
    WARNING: File share \\WSUS.domain.local\DAG-2013.domain.local already exists, however directory ‘C:\FSW_DAG-2103′ is
    different from witness directory ‘C:\FSW_DAG-2013′. Until this problem is corrected, the database availability group
    may have increased vulnerability to failures. To correct this problem, delete existing the file share and use the
    Set-DatabaseAvailabilityGroup cmdlet to retry the operation.
    A server-side database availability group administrative operation failed. Error File share witness resource
    ‘\\WSUS.domain.local\DAG-2013.domain.local’ couldn’t be brought online. The current state is ‘Failed’..
    + CategoryInfo : InvalidArgument: (:) [Set-DatabaseAvailabilityGroup], DagTaskFileShar…OnlineException
    + FullyQualifiedErrorId : 7E3F5A17,Microsoft.Exchange.Management.SystemConfigurationTasks.SetDatabaseAvailabilityG
    roup
    + PSComputerName : ext01.domain.local

    • “directory ‘C:\FSW_DAG-2103′ is different from witness directory ‘C:\FSW_DAG-2013′”

      2103 vs 2013

      Looks like at some stage you’ve made a typo in the folder path.

  2. Hi Paul,

    I’m installing Fresh Exchange 2013 on my organization, and this article is very helpful to me to setup the new exchange organization….Thnx

  3. hi Paul,

    I read most of your exchange 2013 articles but I do have a question about this one.
    On which server do you run the following command: Set-DatabaseAvailabilityGroup E15DAG -WitnessServer E15FSW -WitnessDirectory C:\FSW_E15DAG

    do i need to run this on all servers ( whitness, and both the mailbox server or.. ).

    2nd question ( perhaps of limit ):
    I have 1 dc and 2 exchange 2013 with all the roles installed. According to you posts it is not possible ( i could misread it ) to have a DAG and use High availability if both the roles have been installed on the exchange 2013 servers. Is this correct?

    • Any server. In fact any workstation or server with the Exchange management shell available. Only needs to be run once.

      Exchange 2013 multi-role servers can be DAG members. The DAG/multi-role issue was more with Exchange 2010 where people wanted to use NLB for load balancing their CAS array. You couldn’t do that if the servers were also DAG members (NLB and Failover Clustering don’t mix).

      In Exchange 2013 that is still the case but I wouldn’t recommend anyone bother trying to use NLB with Exchange 2013 anyway as now DNS round robin can be used as the “poor man’s” load balancing if they can’t afford a hardware or virtual load balancer.

      • Exacly what I needed to know. Thanks for all your posts.

        FYI I am recommending your articles in enterprise environments in the Netherlands ;-)

  4. I got this error “The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server” during the creation of the Dag. And again after I set the IP Address for the DAG. I have an error in the logs regarding the contact of the second server when I added it to the DAG (didn’t have an IP set yet). But that is the are the only error I see in the log. What would be the best way to verify the DAG creation and the functionality of the the FSW?

  5. Hi Paul

    when using a non exchange server as the FSW how much space does the FSW require?
    1xdatabase size
    1.5xdatabase size or something a lot smaller?

    Thanks

  6. ManlyTuab says:

    Hi Paul and everybody
    I had 2 server exchange 2013 multi role (2 nic on a exchange) and DAG.
    when 1 in 2 server had mounted database then force stop this server then database dismount. Database cannot mount on that server (other)
    Ex: i have exchange1 and exchange2 and DAG was installed
    exchange1 had mounted all database, when exchange1 force stop and it cannot start then database cannot mount on exchange2.
    I was installed incorrect DAG? and fix this error?

  7. Hi Paul,

    I learned a lot of things from your articles. I am facing a problem. I have a DAG and two member servers.
    The problem is that DAG witness directory is empty. There is no any folder in witness directory. Is there any configuration issue. There was a folder in witness directory some time ago. But now witness directory is completely empty. In EAC it shows DAG and active servers in it. Can you please guide? Also I am unable to purge database logs from both servers through windows server backup. The process is successful but it is not purging the log files.

    Thanks

    Anees

  8. Peter Nørredal says:

    Hi All
    We have deployed an Exchange 2013 DAG with 1 DC, 1 server as FSW server, and 2 MBX servers in this DAG 2013.

    All is running smootly, but we need a second DC in this setup.

    Is it possible (and recommended) to install/promote the FWS server to act as a second DC, after the DAG2013 has been deployed and is running ?

    Or should we just install a new server and promote this as a second DC ?
    Thanks

    /Peter

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.