• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint Online
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Videos
    • Interview Videos
    • How To Guide Videos
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Exchange Server / Using a Non-Exchange Server as an Exchange Database Availability Group File Share Witness

Using a Non-Exchange Server as an Exchange Database Availability Group File Share Witness

February 7, 2013 by Paul Cunningham 30 Comments

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.

1
2
3
4
5
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.

1
[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:ExchangeSetupLogsDAGTasks.

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

1
2
3
4
5
6
7
8
9
10
11
12
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:

1
2
3
4
5
6
7
8
9
10
11
12
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:ExchangeSetupLogsDagTasksdagtask_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.

Exchange Server DAGs, Database Availability Group, Exchange 2013, File Share Witness, High Availability, Mailbox Server

Comments

  1. Mike R says

    May 25, 2021 at 10:35 pm

    This article help me resolve a problem with OWA and ECP authentication after adding servers to a DAG. The witness server did not have the Exchange Trusted Subsystem as local admin. I followed the procedure and resolved my issue. thanks!

    Reply
  2. APP says

    February 1, 2017 at 6:53 pm

    Can I put DAG witness folder on DFS Share?
    Any recommended redundancy option for DAG witness server?

    Reply
    • Paul Cunningham says

      February 2, 2017 at 2:13 pm

      I think the correct answer is no. But even if you could, there’s no advantage, and it only adds complexity (now you’ve got a DFS share to manage instead of just a regular file share).

      The FSW itself doesn’t need to be 100% available. You can patch and reboot the server, for example, without harming the DAG. It’s only required when the cluster needs to make a decision about quorum.

      Reply
  3. Kavindu says

    June 8, 2016 at 5:39 pm

    One of my client has two Exchange 2013 CU 9 nodes and a DAG configured. But they have used only single network adapter for each server for server communication and Mailbox replication. They are planing to go for a DR site and we have installed Additional Domain Controller & One Exchange 2013 CU 9 server in DR Site. This is a different IP Subnet and this is separated from PR in Active Directory Sites and services. ALL PR and DR servers are virtual servers (Hyper-V). In DR Exchange server also we have used only one network adapter.

    But when we trying to add new Exchange 2013 (DR ) Node to the DAG, it gave below error.

    A server-side database availability group administrative operation failed. Error The operation failed. CreateCluster errors may result from incorrectly configured static addresses. Error: An error occurred while attempting a cluster operation. Error: Cluster API failed: “AddClusterNode() (MaxPercentage=100) failed with 0x5b4. Error: This operation returned because the timeout period expired”. [Server: xxxx-02.xx.lk]

    Then after a lot of research i have disabled below parameters from all network adapters. (Hosts & guests)

    IPv4 Checsum Offload Disabled
    Large Send Offload Ver. 2 (ipV4) Disabled
    Large Send Offload Ver. 2 (ipV6) Disabled
    TCP Checksum Offload (ipv4) Disabled
    TCP Checksum Offload (ipv6) Disabled
    UDP Checksum Offload (ipv4) Disabled
    UDP Checksum Offload (ipv6) Disabled

    I have configured a witness server and a share in primary site and secondary witness server in DR site and also a additional IP for DR.

    Now when we trying to add new Exchange 2013 node it will successfully added to the DAG but show as “not operational”. (DAG settings) and also it will dismount the only database in the server.

    Please help me to sort this out.

    Thanks.

    Reply
  4. Jamie says

    April 10, 2016 at 1:14 pm

    Hi Paul,

    I’m running Exchange 2013 CU 11 on 2012 R2 as is my DC which I’m hosting my File Share Witness on. I’ve tried creating the DAG and configuring FSW through the EAC and EMS and I get the same errors when I take a MBX server offline.

    File share witness resource ” failed to arbitrate for the file share ‘\homelab-dc01.homelab.localAR-EXCHDAG.homelab.local’. Please ensure that file share ‘\homelab-dc01.homelab.localAR-EXCHDAG.homelab.local’ exists and is accessible by the cluster.

    The FSW shows online in my Failover Cluster Manager. I’ve assigned the Administrators group and the AR-EXCHDAG object Full Access on NTFS and Share permissions. Confirmed the Exchange Trusted Sub System is a member of Administrators as well. I’m not sure what else may be happening.

    Reply
  5. Wade wellborn says

    February 24, 2016 at 4:21 am

    I am having the exact issues as Josh is having. We have two exchange servers and a witness server. The witness server failed and was replaced. Now when I try to reset the witness using set-databaseavailabilitygroup we also get 0x533 error this user cant sign in because the account is currently disabled. We haven’t been able to bring the witness and quorum back online due to this. Any feed back greatly appreciated.
    Thanks!

    Reply
    • Paul Cunningham says

      February 24, 2016 at 1:56 pm

      Which version and CU of Exchange?

      Reply
      • Wade wellborn says

        February 25, 2016 at 9:12 am

        It was exchange 2013 Version 15.0 (Build 1076.9). cu 8
        I then installed CU 11 on both nodes and still have the same problem.
        The error code was ‘0x533’ (‘This user can’t sign in because this account is currently disabled.’). when I try to bring the witness server online using Set-DatabaseAvailabilityGroup or through the failover cluster manager snap in.
        It was working before the witness server failed and had to be replaced.
        IT was set up same as the first time. Do you have any suggestions.
        Thanks

        Also by the way great article.

        Reply
  6. Josh says

    January 4, 2016 at 4:23 pm

    Paul,

    I’m really happy to see this article is helping lots to many people out there and you continue to monitor the replies.
    I have a DAG setup with 2 Exchange servers. I have a separate non-exchange server as the FSW. However I’m getting this error:

    This user can’t sign in because this account is currently disabled.

    I’ve added the Exchange Trusted Subsystem to the Local Administrators group on the FSW server. I’ve checked the Share for the Exchange servers and it’s pointing to the share on the FSW.

    I have just found one oddity however:

    [PS] C:Windowssystem32>cluster dag.domain.com res
    Listing status for all available resources:

    Resource Group Node Status
    ——————– ——————– ————— ——
    Cluster IP Address Cluster Group EXCHANGE01 Online
    Cluster Name Cluster Group EXCHANGE01 Online
    File Share Witness (\wsp01.domain.comdag.domain.com) Cluster Group EXCHANGE01 Failed

    [PS] C:Windowssystem32>cluster dag.domain.com /quorum
    Witness Resource Name Path Type
    ——————— ——————————————— ——–
    (Node Majority) Majority

    [PS] C:Windowssystem32>

    [PS] C:Windowssystem32>cluster dag.domain.com res “File Share Witness” /priv

    System error 5007 has occurred (0x0000138f).
    The cluster resource could not be found.

    [PS] C:Windowssystem32>

    The cluster dag.domain.com /quorum should return more information than that I’m guessing?

    I’m hoping for any assistance you can offer.

    Thanks!

    Reply
  7. Kevin says

    December 31, 2015 at 3:59 am

    Hi,

    I was wondering if Exchange 2013 supports Windows 2012’s Continues availability File share feature to host the FSW?

    Thanks.

    Reply
    • Paul Cunningham says

      December 31, 2015 at 6:34 am

      Any Windows file share should work, but I see no benefit in clustering the FSW. It doesn’t need to be highly available, and it only adds complexity if you have to manage a cluster for it.

      Reply
  8. Nicholas says

    November 23, 2015 at 8:53 pm

    Thank you very much for these information’s, My environment ( MS Exchange 2013 ) I have 2 CAS Servers and 2 Mailbox , and DAG work fine, I install Third CAS Server completely , My Question : How can I Add New CAS Server in CAS array .

    Reply
    • Paul Cunningham says

      November 23, 2015 at 9:26 pm

      All you need to do is configure it the same as the other two CAS and add it to your load balancer pool.

      Reply
  9. Brandon Nolan says

    January 14, 2015 at 5:12 pm

    Paul-

    Thanks again for an awesome article. I recently had to remove a 2013 cu6 server from a DAG and found an additional permission that was needed for the removal. Check out the article I posted regarding my findings.

    http://technicalmeander.com/2015/01/13/quick-note-on-permissions-for-file-share-witness-in-exchange-2013/

    Reply
  10. Kashif says

    August 31, 2014 at 2:43 pm

    Thank you very much for writing this detailed article. I have created a test setup using VMware workstation. One DC server 2012 R2, One exchange 2013 SP1 (DC client, server 2012 R2), One more server 2012 R2 DC client as witness. Total three VMs, everything works fine, a folder is created automatically for DAG “DAGFileShareWitnesses” and another sub folder inside with the name of witness full fqdn. Until this point everything seems OK but this sub folder is empty, there are no files of database. Or this is normal ? I am a bit confused here. This test setup is going to be implemented at a client site so just wanted to make sure it works. Thanks for all the help.

    Reply
    • Paul Cunningham says

      August 31, 2014 at 10:54 pm

      There’s no database files stored in the FSW directory. At most you’ll see a couple of text files. Not unusual to see nothing though.

      Reply
  11. Peter Nørredal says

    May 23, 2014 at 3:45 pm

    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

    Reply
  12. Anees says

    April 28, 2014 at 9:27 pm

    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

    Reply
  13. ManlyTuab says

    April 21, 2014 at 12:02 am

    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?

    Reply
  14. Matt says

    March 14, 2014 at 6:46 pm

    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

    Reply
  15. Andrea B says

    February 11, 2014 at 4:44 am

    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?

    Reply
    • Paul Cunningham says

      February 11, 2014 at 3:33 pm

      I don’t understand your question. Have you read the article above? It explains why that error appears and what to do about it.

      Reply
  16. andre says

    February 2, 2014 at 8:46 pm

    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?

    Reply
    • Paul Cunningham says

      February 2, 2014 at 9:37 pm

      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.

      Reply
      • Andre says

        February 2, 2014 at 11:11 pm

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

        FYI I am recommending your articles in enterprise environments in the Netherlands 😉

        Reply
  17. Pravin says

    September 13, 2013 at 6:27 pm

    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

    Reply
  18. Barry says

    March 20, 2013 at 9:37 pm

    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:Windowssystem32>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.localDAG-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.localDAG-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

    Reply
    • Paul Cunningham says

      April 2, 2013 at 9:30 pm

      “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.

      Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Changes in Microsoft 365 Apps Channels and Why You Should Care
  • A New Tool to Manage Exchange-related Attributes Without Exchange Server
  • Microsoft Launches Group Ownership Governance Policy
  • Making the Case for Identity Governance in Azure Active Directory
  • Prepare an Office 365 migration plan assessment using PowerShell

Copyright © 2022 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland