As a part of a datacenter switchover process, administrators run Stop-DatabaseAvailabilityGroup to stop DAG members in the failed datacenter. This cmdlet is responsible for updating the stoppedMailboxServers attribute of the DAG object within Active Directory.
When this command is run and multiple AD sites are involved, the command attempts to force AD replication between the sites so that all AD sites are aware of the stopped mailbox servers. This allows us to bypass issues that can arise when non-default replication times are used on AD site replication connections.
In many cases, not only are the Exchange severs in the primary datacenter failed, but so are the supporting domain controllers for that AD site. There may also be scenarios where the remote site where the command is being executed has no network connectivity to domain controllers in the primary site. When this occurs, Stop-DatabaseAvailabilityGroup fails with the following error:
[PS] C:\>Stop-DatabaseAvailabilityGroup -ActiveDirectorySite Exchange-B -ConfigurationOnly:$TRUE -Identity DAG
Confirm Are you sure you want to perform this action? Stopping Mailbox servers for Active Directory site "Exchange-B" in database availability group "DAG". [Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): a WARNING: Active Directory couldn't be updated in Exchange-B site(s) affected by the change to 'DAG'. It won't be completely usable until after Active Directory replication occurs. An error caused a change in the current set of domain controllers. + CategoryInfo : NotSpecified: (0:Int32) , ADServerSettingsChangedException + FullyQualifiedErrorId : 3647E7F3
If this error occurs as a result of issuing Stop-DatabaseAvailbilityGroup when known connectivity issues exist to domain controllers in the site hosting the Exchange servers that are being stopped, the error can be safely ignored. When domain controllers come back up in the primary datacenter normal Active Directory replication will handle populating this attribute on those domain controllers and other safeguards exist in the product not necessitating this attribute be updated for the solution to function.
Datacenter Activation Coordination Series:
Part 1: My databases do not mount automatically after I enabled Datacenter Activation Coordination (http://aka.ms/F6k65e) Part 2: Datacenter Activation Coordination and the File Share Witness (http://aka.ms/Wsesft) Part 3: Datacenter Activation Coordination and the Single Node Cluster (http://aka.ms/N3ktdy) Part 4: Datacenter Activation Coordination and the Prevention of Split Brain (http://aka.ms/C13ptq) Part 5: Datacenter Activation Coordination: How do I Force Automount Concensus? (http://aka.ms/T5sgqa) Part 6: Datacenter Activation Coordination: Who has a say? (http://aka.ms/W51h6n) Part 7: Datacenter Activation Coordination: When to run start-databaseavailabilitygroup to bring members back into the DAG after a datacenter switchover. (http://aka.ms/Oieqqp) Part 8: Datacenter Activation Coordination: Stop! In the Name of DAG... (http://aka.ms/Uzogbq) Part 9: Datacenter Activation Coordination: An error cause a change in the current set of domain controllers (http://aka.ms/Qlt035)
I'm glad you appreciated it.
I've found that the Stop-DatabaseAvailabilityGroup cmdlet would finish successfully without -ConfigurationOnly switch if DCs in the primary datacenter are also not accessible. TechNet actually says "The ConfigurationOnly parameter must be used when the DAG member servers are offline, but Active Directory is up and accessible in the primary datacenter."
I'm not sure what your question or comment is about. When using stop-dag, with or without the -configurationonly switch, if domain controllers in the primary site are not accessible this error will occur.