Well the error occurred within their 3rd party app, which I am almost convinced is home grown (They simply call it Provisioner). It appears that the app attempted to use the downed DC to provision a new mailbox and threw an error. It’s the Exchange Admins responsibility to do something about it. I think they are going to be able to exclude the DC within their app, from what I heard.
As for why Exchange is using all 5 DCs, even the DC with 0 weight and 65,000+ priority in the SRV records, I don’t know why that would happen. This Exchange blog suggests using this very method to control which DCs Exchange will use: http://blogs.technet.com/b/exchange/archive/2007/03/28/3401716.aspx When I say it’s “using” that DC, I mean that the Security Log shows logons, etc. from it, but not from any other member computers. (Of course I see entries from the other DCs.) Charlie Sullivan Sr. Windows Systems Administrator From: [email protected] [mailto:[email protected]] On Behalf Of Michael B. Smith Sent: Thursday, February 27, 2014 10:31 AM To: [email protected] Subject: RE: [NTSysADM] Maintenance Reboots of Guest VM's. Exchange queries AD for the DCs and GCs to use and at what priority. If there is a verifiable error, I am happy to bug it. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Charles Sullivan Sent: Thursday, February 27, 2014 10:25 AM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Maintenance Reboots of Guest VM's. Exchange 2010, but I believe they are behind on SPs by a couple. Actually, the command shown below was sent to us just to show that the DC was unavailable to Exchange, which really means nothing. The real error was with the application they use to provision accounts. I know just about nothing about the application (it may be home grown), but I do know that it’s not hard coded to use a particular DC. So I really should have said that this is affecting a third party app and not Exchange itself. But it’s still an example of how shutting down a DC could be a problem even when it’s not hard coded into an application. I couldn’t resist bringing this up because it happened to us so recently. This may be a very unusual occurrence, I’m not sure, but I’m bringing it up as a consideration. Charlie Sullivan Sr. Windows Systems Administrator From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Michael B. Smith Sent: Thursday, February 27, 2014 10:09 AM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Maintenance Reboots of Guest VM's. What version of Exchange? From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Charles Sullivan Sent: Thursday, February 27, 2014 9:41 AM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Maintenance Reboots of Guest VM's. Speaking of AD, we not only reboot but automatically shut down one of our 5 DCs twice weekly in order to (VMware) clone it for DR purposes. This can take up to 3 hours or more, depending on how busy the host server is. This DC has no FSMO roles, but all of our DCs are Global Catalog servers. By the way, we only have one site/domain and it’s high connectivity between all of the DCs and they provide no services besides AD. We are using SRV records weight and priority to keep AD traffic away from the DC that is cloned twice a week. I bring this up because although we’ve been doing this for about 6 months, this week one of the Exchange Admins complained that he got this error message while the DC was down: [PS] C:\Windows\system32>Get-ImapSettings -identity hubcas01 An Active Directory error 0x51 occurred when trying to check the suitability of server '-identity'. Error: 'Active directory response: The LDAP server is unavailable.' I have noticed in the Security Logs on that DC in the past that despite the control via SRV records, the Exchange servers keep using that DC (along with the others). The only other computer names I see in the logs are the other DCs, so the SRV method seems to work for everything but Exchange. It will be up to the Exchange Admins to get their servers to not use that DC, but my point is that sometimes bringing down a DC can cause problems even when it shouldn’t in theory. So that this doesn’t turn into a thread about cloning DC VMs – 1. No, we do not turn on the cloned DC. We do bring it up on an isolated VLAN dedicated to DR testing when necessary. 2. The DC (Windows 2008 R2) needs to be shut down for the cloning, otherwise the AD database and probably some other stuff will be messed up. We have tested this. I can even clone SQL servers and get everything intact, but not DCs. Charlie Sullivan Sr. Windows Systems Administrator From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Webster Sent: Thursday, February 27, 2014 7:41 AM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Maintenance Reboots of Guest VM's. In the "real" world, I have never seen a XenApp/TS/RDS environment where the servers were not rebooted on a scheduled basis. I have seen daily, weekly, monthly and everything in between reboot schedules. It really depends on the apps installed on the servers and how crappy the apps are. Usually the daily reboots are caused by an apps or combination of apps that eat memory and never release it and the server wil suffer some type of memory exhaustion necessitating the reboot schedule. In the AD world I also participate in, IF the DCs are nothing but DCs AND apps are not hard coded to a specific DC or groups of DCs, then DCs can be restarted as needed or required. If the DCs run other functions like file server, SQL server, Exchange server, terminal server, etc etc etc, then it can be a real pain to get the time or approval to restart a DC. The project I am on now, the in-house devs have unfortunately hard-coded specific DCs (and for some apps the DC name AND IP address) in some of their web apps. Those DCs can only be restarted during the monthly approved maintenance period. Thanks Carl Webster Consultant and Citrix Technology Professional http://www.CarlWebster.com<http://www.carlwebster.com/> ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of John Matteson <[email protected]<mailto:[email protected]>> Sent: Thursday, February 27, 2014 6:07 AM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Maintenance Reboots of Guest VM's. I’m not looking to reboot systems just for the heck of it either. But I’ve heard SA’s go “Nope, no way, nada, niet, don’t reboot for anything no way no how”, even after OS level patching. And there have been the people on the other side of that fence that say to treat it like you would a physical server. I’m trying to get a feel for what happens in the real world, not the theoretical world of test labs and sales meetings. John M. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ken Schaefer Sent: Tuesday, February 25, 2014 5:18 PM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Maintenance Reboots of Guest VM's. We don’t reboot servers just for the sake of rebooting servers. Cheers Ken From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of John Matteson Sent: Tuesday, 25 February 2014 11:35 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [NTSysADM] Maintenance Reboots of Guest VM's. I’m trying to get some straight information on doing maintenance reboots of virtual systems. Some people I’ve talked to say yes, others say no. I’ve been doing systems admin work for a long time now, but only recently have had to get up close and personal with VM’s on ESX hosts. Yes? No? Why or why not? Learning new stuff is a good thing. John M.
