After reading an interesting article by Michael De Rooij, I thought it would be a good idea to put some articles that I wrote earlier back into the picture.
Lastly, I wanted to share something that I haven’t written about yet:
given that Exchange relies heavily on Active Directory, there are numerous scenarios I can think of where AD Replication might cause some (temporary) issues. One of the issues that I encounter regularly, is when you’re running a stretched DAG (across multiple AD Sites) and you’re putting a node in one site in “maintenance mode”. Whenever you run the .\StartDagServerMaintenance.ps1 script, it will – amongst other tasks – put the server’s activation policy to “blocked”. This will prevent mailbox databases to become active on that server. Like a lot of other attributes the “DatabaseCopyAutoActivationPolicy”-attribute is stored in Active Directory. Therefore, if you run the script in one AD site, Exchange Servers in other AD sites will not know about the change until AD Replication has occurred.
Running Get-MailboxServer | FL Name,*Activ* on Exchange Servers in different sites might (temporarily) show other values for that attribute:
Although the latency introduced by AD Replication is completely “expected”, it might cause some (temporary) unwanted errors like e.g. when you are trying to move an active copy of a mailbox database to a server who has recently been taken out of “maintenance mode” in another AD Site. Whilst the server where you ran the .\StopDagServerMaintenance.ps1 script might already be aware that the Activation Policy changed back to “Unrestricted”, the current Active Copy might be mounted on a server in another AD site that isn’t aware of the change yet, therefore preventing the move.
All it takes to solve this issue is either time. You either wait for replication to occur or you force replication between the involved sites.
Michael Van Horenbeeck