One of the most attractive features (my opinion) of Exchange 2010 is the ability to provide high-availability for all 4 server roles by using just 2 actual machines. There are definitely some caveats, like the fact that you need a hardware load-balancer to distribute inbound request to the CAS and HT roles, but I think we’ll see a lot more adoption of high-availability using a collocated CAS/HT/MBX in the smaller or midsize business space with this model.
The 2010 DAG feature is similar to 2007’s CCR in that it requires a file share witness. Since your two Exchange servers are part of the DAG, neither can actually be a witness. In this case you’ll need a 3rd server to act as the file share witness which would normally be another Exchange server, but again, we only have two here. In my lab the only other server I had was a domain controller so I decided to use that as my FSW instead of standing up another server. When I ran through DAG wizard I received the following errors.
Warning: Specified witness server DC.DELHI.ORG is not an Exchange server, or part of the Exchange Servers security group.
Warning: Insufficient permissions to access file shares on witness server ‘DC.DELHI.ORG’. 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
The DAG is still created, but really doesn’t have the FSW ability at this point. I recommend deleting it. The first warning is also a little misinformative because the problem actually lies in the Exchange Trusted Subssytem group permissions, not the Exchange Servers security group. You can follow these steps to get your DC to act as FSW:
Add your domain controller’s computer account to Exchange Trusted Subsystem group in AD.
Add the Exchange Trusted Subsystem group to the Builtin\Administrators group of the domain.
Obviously the second change isn’t ideal and if you’re going to use the DAG features I’d really recommend putting your FSW folder on something other than a DC, but it’s necessary in this case.
At this point go ahead and try to create your DAG again. This time it should succeed.
I also found that if I created the folder on the DC ahead of time and then ran the DAG wizard it would fail because the folder and share permissions were not correct. The best action here is to not create the FSW folder or share ahead of time and just let the cmd-let take care of the hard work.
----------------------------------------------------------------------------------------
3 comments:
Your method grants unnecessary permissions, It's a myth and it's been busted. Only the second permission needs to be granted...
http://www.thecabal.org/2009/12/busting-the-exchange-trusted-subsystem-myth/
Devin, Harish is placing his witness share on a domain controller. Domain controllers do not have local user accounts or groups for that matter. This is why you need to add your domain controller to the trusted subsystem, as you cannot add the Exchange Trusted Subsystem to the local administators group.
It was such a valuable information. Thank you for sharing.
web development company in Bangalore | Website Design Company in Bangalore | user experience design firms india| ux design firms in bangalore
Post a Comment