SBS 2011 Migration - Active Directory replication is taking longer than expected

If you encounter this message during setup: “Active Directory replication is taking longer than expected”, do this:

Active Directory replication is taking longer than expected. You can choose whether to continue waiting.
If you choose not to wait, the migration may fail. Unless you are sure that replication is working correctly, it is recommended that you continue waiting.
Do you want to wait for the replication to finish? (Yes/No)
Most Common Cause: You will only get this dialog after the SBS setup has waited for 25 minutes and the new server has not been able to properly contact the source DC to initialize the file replication service (FRS), this is preventing the new server from becoming a domain controller. Clicking No on this dialog will almost certainly mean a failed setup. The source server is most likely in journal wrap or having FRS issues.
Resolution Summary: Correct the FRS issues on the source server, do not reboot the new server or close down the setup, leave the popup dialog open while you troubleshoot, once the FRS issues are corrected on the source server, you can open a command prompt on the new server by using Shift-F10 and restart the Netlogon and FRS services, then confirm that SYSVOL and NETLOGON are shared on the new server by using NET SHARE, only then you should click Yes to continue waiting, after 5 minutes the setup will go on.

Understanding Write Cache Policy

The cache controller writes a block of data to cache memory, which is much faster than writing to the physical disk. The cache controller sends an acknowledgement of data transfer completion to the host system. 


Write-Back Versus Write-Through
In write-through caching, the controller sends a data transfer completion signal to the host system when the disk subsystem has received all the data in a transaction. 


In write-back caching, the controller sends a data transfer completion signal to the host when the controller cache has received all the data in a transaction. The controller then writes the cached data to the storage device when system activity is low or when the write buffer approaches capacity. The cached data is not written to the storage device immediately. 


The risk of using write-back cache is that the cached data can be lost if there is a power failure before it is written to the storage device. This risk is mitigated by using a BBU on selected PERC 6 controllers. 


Write-back caching has a performance advantage over write-through caching. 


NOTE: 
The default cache setting is write-back caching.  


NOTE: 
Certain data patterns and configurations perform better in a write-through cache policy.  




Conditions Under Which Write-Back is Employed
Write-back caching is used under all conditions in which the battery is present and in good condition. 


Conditions Under Which Write-Through is Employed
Write-through caching is used under all conditions in which the battery is missing or in a low-charge state. Low-charge state is when the battery is not capable of maintaining data for at least 24 hours in the case of a power loss. 


Conditions Under Which Forced Write-Back With No Battery is Employed
Write-Back mode is available when the user selects Force WB with no battery. When Forced Write-Back mode is selected, the virtual disk is in Write-Back mode even if the battery is not present