Link to home
Create AccountLog in
Avatar of Gavin Thompson
Gavin ThompsonFlag for United Kingdom of Great Britain and Northern Ireland

asked on

Exchange 2010 - DC/GC change not reflected

Hi All,

We have a scenario (which I'm trying to get away from, hence this post) whereby one of our Exchange 2010 servers (the first one to be installed, as it happens) is also a DC/GC, and is aware of itself and ONLY itself if you look in EMC>Server Configuration>properties of the server (all other Exchange servers added since can see ALL DC/GCs).

I've gone into Server Configuration>Modify Configuration Domain Controller and specified another DC/GC, as we want to demote the Exchange server from being a DC, and it shows in the Modify Configuration Domain Controller box correctly, but it's been an hour, and it still shows only the Exchange server itself in the properties of said Exchange server.

I don't want to demote the Exchange server from being a DC until I KNOW that it won't look for itself, and we can't really afford to restart services/reboot during production hours.

Am I worrying unnecessarily?
Avatar of Manpreet SIngh Khatra
Manpreet SIngh Khatra
Flag of India image

If you want immidiate affect you should restart the ADtopology service. This wouldnt affect the Database as the Information Store or System attendant shouldnt be affected.

- Rancy
Avatar of Gavin Thompson


Even though the server in question is a DC and is pointing to itself?

Unfortunately, when Exchange is installed on a DC, it severely restricts your ability to do anything to the underlying DC role of that box unless and until Exchange is removed. It is right of you to check this information, because if you demote that server while Exchange is installed, you will break Exchange!

This is one of the reasons Microsoft does not recommend installing Exchange on a DC -- not to mention the chaotic disaster recovery in the event of a failure.

Restarting topology services is not something which is going to be of very much help; even if Exchange finds another DC to make use of, the underlying security model of the system changes at the point of demotion back to a member server, and Exchange can't cope with it.

You will need to migrate all of the Exchange roles elsewhere, remove Exchange, demote, then re-install Exchange and migrate back. For cleanliness, and because it's not a lot of work, it would be worth formatting and re-installing a base Windows Server install after the demotion.

One Question though ... any specific reasons now your trying to find a way out as compare dto the insatllation ?

- Rancy
Well, there is more information on my other thread here:

But the general gist is that when I started at the company, we had inherited an Exchange 2010 setup that was unsupported by Microsoft (2 x multi-role servers in a DAG, with the CAS array being piggy-backed onto the DAG vIP, and one of the Exchange servers being a DC), and it started causing us issues (failover not working correctly, etc), so we took the decision to move away from that into a supported scenario.


Avatar of tigermatt
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Thanks for the comments thus far, guys.

We are indeed in the process of moving to a separate, NLB'ed CAS array, and will also be creating a brand new DAG and swinging the newer of our 2 existing DAG members (the non-DC) across into it, either that or just straight up create the new DAG and use Move Mailbox to get the mailboxes across (there are only 60 or so mailboxes).

I can't help but think that a lot of the issues described on my other thread are at least partially attributed to the fact that this particular Exchange server is also a DC, and causes a lot of authentication issues for Exchange when it is rebooted (as mentioned on the other thread, if we were to switch over the active db copies to the other DAG member manually, all works fine, yet if the Exchange DC is rebooted and a failover occurs, even though the DAG fails over the active db copies correctly, Outlook clients can't connect to the mbx databases - bearing in mind the Exchange/DC is also a CAS server too).
Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
I'm almost there with the CAS array... Have built a NLB cluster, and have switched over to it just now, pointing the DNS record to the cluster vIP. All seems ok. Will update further when I have more info.
CAS array *seems* to function OK.

I tested DAG functionality again, after telling ALL of our Exchange servers to point to a specific DC/GC, and got the following results:

Switchover - Everything works fine, the databases flick over correctly, and Outlook clients remain connected.

Failover - Still the same issue as before. The databases flick over correctly, but Outlook disconnects and prompts for credentials (if Outlook is restarted, it will fail to connect to the mailbox). It stays like this until the OTHER DAG member is rebooted, causing the original server to become the failover cluster master again.

**Edited - Forgot to mention that, if I look in Server Configuration > Properties of the server > System Settings > Active Directory servers, all of the servers EXCEPT the one which is a DC are seeing ALL DC/GC's within the domain. The one which is a DC can only see itself, even though I set all servers to use a specific DC, as I mentioned above.**

I'm just going to go ahead and start planning a new DAG, then swing the non-problematic mailbox server over to it.
Ok, here's what we plan to do - I'd very much appreciate it if one of you experts could cast your eye over it and confirm that I'm thinking straight!

Option 1

1.      Create new mailbox server (let's call it DAGmember2
2.      Create new DAG (let's call it DAG2) and add new mbx server as a member (needs File Share Witness – is it ok to use a CAS/HT server that is part of a W-NLB cluster as the FSW?)
3.      Move active database copies from EXCH1 (also the DC) to DAGmember1 (both exist in DAG1 at this time)
4.      Remove database copies from EXCH1
5.      Remove EXCH1 from DAG1
6.      Remove DAGmember1 from DAG1 and collapse DAG
7.      Add DAGmember1 to DAG2
8.      Create database copies on DAGmember2 and sync
9.      Test failover
10.      Remove Exchange roles from EXCH1
11.      Test failover again


Option 2

1.      Create new mailbox server (DAGmember2) and create new mailbox databases
2.      Create new DAG (DAG2) and add DAGmember2 as a member (needs File Share Witness – is it ok to use a CAS/HT server that is part of a W-NLB cluster as the FSW?)
3.      Use Move Mailbox tools (exact method TBA) to move mailboxes from DAG1 databases into DAG2 databases
4.      Once confirmed that no mailboxes remain in DAG1 databases, delete databases and remove EXCH1 from DAG1
5.      Remove DAGmember1 from DAG1 and collapse DAG
6.      Add DAGmember1 to DAG2
7.      Create database copies on DAGmember1 and sync
8.      Test failover
9.      Remove Exchange roles from EXCH1
10.      Test failover again


1.      Ensure that ALL Exchange servers are set to use a DC/GC other than EXCH1
2.      Demote EXCH1 from being a DC via DCPROMO.EXE
3.      Clean up metadata within AD for EXCH1
4.      Test failover again

Am I missing anything obvious or vital??

Thanks in advance

There is very little between the two options.
Both achieve the same result, only doing a database migration rather mailbox migration involves less work and hopefully no downtime.
Obviously the only thing to be wary of is CAS Array, and ensure that all clients are across, but I wouldn't have a problem with either method.

With regards to the FSW, being a member of a WLNB setup shouldn't be a problem as long as you reference the server directly and not the NLB.

Update - CAS array functionality has been transferred over to a pair of W-NLB clustered CAS/HT servers, and appears to be working ok.

I am now in the process of creating a new DAG and moving mailboxes across, so that Exchange can be removed from the one original server that's left, so that it can also be demoted as a DC.

Thanks for the update. Let us know the outcome!

So far so good...

Yesterday, I performed option 1 as above, and apart from a small amount of downtime when moving the live mailbox server out from the old DAG and into the new DAG, due to the databases dismounting, everything seems fine!

I've tested a switchover, a failover, and rebooted the server that's an Exchange/DC as well, all with zero effect on users. DAG functionality seems to be as expected, and the new DAG isn't relying on the Exchange/DC server.

So next step is to remove Exchange from the old server completely, and demote as a DC.

Thanks for all your help guys, again, I will update as progress happens.
Ok, quick update... I removed Exchange from the old server completely and powered it down yesterday... DAG failover tested OK, which is great...

However, I noticed a couple of strange things.

- When removing Exchange from the old server, I moved the Offline Address Book to one of the new DAG members, which completed with no errors. This morning, Outlook clients are getting a send/receive error when trying to download the OAB (0x8004010F), which states that the 'object cannot be found'. I've forced it to update via EMS, and pushed it out to the CAS servers too (also via EMS), but the error persists.

- Something weird with the CAS array... On Monday night, I had created new Veeam jobs for each Exchange VM that we have, completely forgetting that it takes longer for the first instance to run, which resulted in the backup of the CAS servers running during production hours... When CAS1 was being backed up, it was temporarily unavailable (due to Veeam freeze/snapshot process, I assume), and Outlook clients instantly got 'Trying to connect' messages. They stayed this way until CAS1 became available again. When I tested the CAS array functionality before, all seemed well. Could there be a problem with CAS2?

Any ideas?

Many thanks

CAS Array on its own has no availability options. Therefore unless you moved the CAS array host name to point at the other server, the behaviour you have seen is what I would expect. While you can have multiple servers in the array (by default all CAS role servers in the site are members) the array host name can only point at one place. DNS doesn't give any service awareness.

On the OAB subject - ensure that you have the valid servers set as locations in the OAB configuration. If you are using web and public folders, then ensure the public folder exists and the correct public folder store is set on each mailbox database.

Thanks, Simon.

So even though I've created a W-NLB cluster of 2 CAS servers, and the DNS entry for the CAS array points to the VIP for the W-NLB cluster, there is no high availability of CAS servers?

I've got a walkthrough to follow on recreating the OAB completely, as I tried multiple troubleshooting steps on it yesterday, to no avail.


I was referring to the CAS Array only. Nothing to do with any kind of load balancing.
Although Windows NLB is a pretty poor solution which I find doesn't work reliably. The Exchange product group have also stopped recommending the use of WNLB.

Apologies, been on annual leave.

So, even with the poor solution that is W-NLB, assuming that everything is configured correctly, if the CAS Array DNS entry points to the VIP of the W-NLB cluster, if one CAS server is rebooted, the other should carry on servicing clients seamlessly?

OAB issue is sorted, had to rebuild it from scratch.


That is what is supposed to happen in theory.
A reboot should cause it to direct all traffic to the second node, although a service failure would not.

Thanks, Simon.

Any idea why, then, if I reboot one of our new CAS servers, the WNLB cluster seems to flick over correctly to the other node, yet Outlook clients get a "Trying to connect" message for a while, and then a "Disconnected" status? They can only connect again once the other server comes back up fully.


There has to be something that isn't pointing to the virtual IP address.
RPC CAS Array, EWS, Autodiscover etc.

Thanks, Simon.

How can I check all these, please?