This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(96, 27%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Hi everyone, a new domain controller was added to our environment recently and I seem to be getting the following error now when viewing distribution groups in the admin console.
I did identify a firewall problem that was preventing this Exchange server from communicating with the new DC which has now been resolved, but this error persists. Some articles I've found suggest that restart the IIS or restarting the Exchange server might resolve this, but I wanted to post here for further direction. Anything I can do to troubleshoot that won't take the Exchange server offline?
Regards,
Adam Tyler
Well, restarting the DSAccess service may fix it but that is about the same as restarting all the Exch Services. I would give it a bounce. Any other errors in the event logs right now?
Thanks @Andy David - MVP . I opened a sev 1 case with Microsoft too just to double check that I haven't made a mistake with this Domain Controller. So far event logs look pretty good and Active Directory looks healthy.
Some more information is that I am also still in the process of finishing an Exchange 2010 to 2016 migration. All mailboxes have been moved, I am just dealing with the last mail relay items before I remove databases and finally uninstall Exchange 2010. Furthermore before yesterday all of our Domain Controllers ran Windows Server 2012 R2 and our Domain/Forest functional level is 2008 R2.
The new DC I added runs Windows Server 2019. I did confirm that it was compatible with our current domain and forest functional level, but I am concerned there is some incompatibility with Exchange 2010 that I didn't consider prior to adding the DC.
Regards,
Adam Tyler
Exchange 2010 doesn't supported with Windows Server 2019 DC: Supported Active Directory environments. From the screenshot that you provided, we can know this issue may related with Exchange server system requirements.
I would suggest you uninstall the new DC now. You could reinstall it after uninstall Exchange 2010.
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Thanks @KyleXu-MSFT , stressful day yesterday. I did confirm before deploying this Domain Controller that it was compatible with both the Forest/Domain functional level, but I must have missed this Exchange 2010 issue.
I'm curious at this point if uninstalling the 2019 Domain Controller is enough. I suspect that simply promoting a system to a 2019 DC may have made a schema or other AD partition change that is irreversible?
It's extremely frustrating, I had Microsoft on the line yesterday with $500 support case and my engineer couldn't speak to this at all. It's also strange that it would impact the Exchange 2016 functionality? I realize I am still hybrid 2010 and 2016, but...
Anyway, we are basically ready to uninstall Exchange 2010. All mailboxes are moved and I've dealt with the last items still relaying off of 2010. Final step is just to remove the public folder and mailbox databases, then go through uninstall. I think I still have some arbitration mailboxes on 2010 that need to be moved.
I was able to solve this Exchange admin console issue yesterday. I've asked Microsoft to assist me in identifying the root cause, I made two changes and I am not sure which did it.
Out of characters, will continue in separate post....
first change I made was running this command:
set-exchangeserver Exchange2016Svr -StaticDomainControllers DC03.domain.local -StaticGlobalCatalogs DC03.domain.local -StaticConfigDomainController DC03.domain.local
DC03.domain.local being a 2012 R2 GC and FSMO role owner.
This didn't initially help and Microsoft support told me I had to restart the server for it to take affect. Before doing so they had me run an IISRESET which just made the problem worse. Now you couldn't bring any information up on users or groups when navigating the Exchange Admin console. I was concerned that rebooting the server would cause further disruption. At this point mail was still working for the most part.
The second change I made was to reconfigure AD sites and services. Out of the three domain controllers in the site where Exchange is located, I configured both the 2012 R2 DCs to be the preferred bridge head servers for IP and forced replication throughout the organization. I observed the KCC create replication links between all domain controllers to support that change.
Shortly after these two changes, the Exchange admin console started functioning and the output of Get-AdServerSettings showed DC03.domain.local as being used for DefaultConfigurationDomainController, DefaultGlobalCatalog, DefaultPreferredDomainControllers, DefaultConfigurationDomainControllersForAllForests, and DefaultGlobalCatalogsForAllForests.. Which was not the case prior to the Set-ExchangeServer command and AD Sites and Services changes.
Continued.....
So things are functional for now, but I am not sure what the best course of action is moving forward. I also don't know what fixed this issue, the Set-ExchangeServer command or the AD sites and Services change. Additionally, if you run a Get-ADServerSettings against the Exchange 2010 server the 2019 Domain Controller is still listed as DefaultGlobalCatalog, DefaultConfigurationDomainController, DefaultPreferredDomainControllers..
I'd hate to demote the 2019 DC prior to getting Exchange 2010 pointed somewhere else. Perhaps running the same Set-ExchangeServer command against 2010 is the best option and allowing those changes take affect. Perhaps doing that would allow me to complete the decommission process of Exchange 2010 while the new DC is still online.
I'm not sure, but at this point it doesn't appear that Microsoft has any idea either. Based on my experience with their support thus far.
If all need user mailboxes have been migrated. I would suggest you try to uninstall the Exchange 2010. About the arbitration mailboxes, you could recreate them on the Exchange 2016.
If you could uninstall Exchange 2010, then you could rerun prepare command on your Exchange 2016. After that, have a check whether you could access ECP successfully now.
Any update about this thread now?
Not much more to share at this point. The environment has been stable since the original rukus. I've moved the arbitration mailboxes and discovery mailboxes from 2010 to 2016. Next step is to actually remove the databases from 2010 and uninstall it.
I'm in the process of creating an isolated clone of the environment in an attempt to re-create this problem. Will post back here with information as I have it.
Regards,
Adam Tyler
Update, last night I completed the removal of Exchange 2010 from our environment and for the first time since introducing this new domain controller actually restarted our stand alone Exchange 2016 server. I plan to run the following command soon to remove the hard coded domain controller from the Exchange config and will monitor the behavior. Hopefully the original problem doesn't persist.
set-exchangeserver Exchange2016Svr -StaticDomainControllers $null -StaticGlobalCatalogs $null -StaticConfigDomainController $null
I wouldnt demote the 2019 DC if the 2010 Exch Server is going away. If things are working, I would keep what you have and get the 2010 server out of there as soon as you can
You can always hard code the 2010 server against that 2012 DC as well if you havent already .
Thanks @Andy David - MVP . I tend to agree with you. Take a look at the end of this thread. We are on 2010 RU32..
Based on the real world experience (from thread), it looks like a DC running 2019 isn't a death sentence if you have Exchange 2010 in the environment. Wondering why things go so strange for us. I also don't want to leave the DCs hard coded in Exchange for an extended period. Will be easier to discuss with support and troubleshoot if Exchange 2010 was gone, I agree.
Regards,
Adam Tyler