DFS Using Domain Alias

Active Directory replication isn't ready yet, and your new domain controller isn't a domain controller unless 13516 is logged and sysvol and netlogon will be shared (sysvol replication has finished). Here are a few steps to take:

• With NSLookup, check if your new DC can resolve the domain name, itself, and the old DC. Check both forward and reverse lookup
• Run repadmin /kcc
• Wait a few minutes
• Run repadmin /syncall
• Wait a few minutes
• If event id 13516 is not logged, run dcdiag and post the output. Also post any error messages that occur performing these steps.

You have three different problems here.

1. You have one server acting as a Domain Controller and an Exchange server at the same time. This is bad. This isn't the cause of your problem, but you should be aware that this is not how you should have this configured. Exchange and AD should be installed on separate servers that are dedicated to each role.

2. You had an unexpected shutdown on the Exchange server. This could be a power outage, or any other unclean shutdown. In Server 2008 R2 SP1 and Windows Server 2012, DFS-R will not resume replication automatically on unclean shutdowns. The error message that you've posted tells you the exact command to bring replication of the volume back online. Microsoft has released guidance for when and how to enable auto-recovery so that you don't need to mess with the wmic command each time you have an unclean shutdown. Domain Controllers are one instance where auto-recovery should always be enabled. Do this.

3. Your Exchange/DC and FSMO-holding DC haven't replicated sysvol in longer than the MaxOfflineTimeInDays threshold - this is called Content Freshness Protection in DFS terminology. You will have to determine which server's SYSVOL share has the most up to date information and use it as the authoritative source for replication and follow this document to resume replication.

In short - restart replication on the Exchange/DC server with the wmic command in the error message. Then, configure auto-recovery to prevent this in the future, then force an authoritative replication of sysvol to get the replication group running again.