We are running Windows 2012 R2 AD DS and have built out an environment here in our corporate office for a new site. One of the builds is an AD Server. We need to take the environment offline including the new AD server for 1-2 weeks to ship it to our new location. 

We know taking the AD server offline will cause our existing AD infrastructure to belch for awhile but don't completely know ramifications when we bring server back online.  Will it just download changes to the AD environment since taken offline or will it reload the entire AD DB since it was offline for an extended period?  Is this a safe method or would it be better to DCPromo it and bring back online as a DC at our new site.  What are the concerns with this process?

Look forward to replies.

• Edited by DDNDAVID 7 hours 26 minutes ago

Hi,

This is a recommended practice. If remote sites does not have enough bandwidth available, we usually install AD DS before shipping it to remote site. 1-2 weeks is safe period. Just check your tombstone period. You should not shutdown the server beyond the tombstone life time. You don't need to worry about anything.

Once the domain controller is up it will contact another domain controller in the domain and replicate the changes.

Perform the following procedures:

• Determine the anticipated length of the disconnection. 
• Determine the tombstone lifetime for the forest.
• Determine the maximum safe-disconnection period by subtracting a generous estimate of the end-to-end replication latency from the tombstone lifetime. Either find the latency estimate in the design documentation for your deployment or request the information from a member of your design or deployment team. 
• If the anticipated time of disconnection exceeds the maximum safedisconnection period, make a decision about whether to extend the tombstone lifetime. To change the tombstone lifetime, see Determine the tombstone lifetime for the forest and change the value in the tombstoneLifetime attribute.
• If the estimated time of disconnection does not exceed the maximum safe disconnection time, proceed with preparations for disconnection.
• View the Current Operations Master Role Holders to determine whether the domain controller is an operations master role holder.
• Transfer the Domain-Level Operations Master Roles, if appropriate.
• Transfer the Schema Master, if appropriate. 
• Transfer the Domain Naming Master, if appropriate.
• If you use File Replication Service (FRS) to replicate SYSVOL, you can decrease the time required to update SYSVOL when the domain controller is restarted by performing a preliminary registry update on the server. For instructions, see Prepare a domain controller for nonauthoritative SYSVOL restart (http://go.microsoft.com/fwlink/?LinkID=122831). This procedure is not necessary if you use Distributed File System (DFS) Replication.
• Enable Strict Replication Consistency, if necessary. If strict replication consistency is not enabled on the domain controller that you are disconnecting, use this command-line procedure to enable strict replication consistency on specific domain controllers or on all domain controllers in the forest.
• Synchronize Replication with All Partners. Update the domain controller with the latest changes just before you disconnect it.
• Verify Successful Replication to a Domain Controller for the domain controller that you are disconnecting.
• Label the domain controller with the date and time of disconnection and the maximum safe-disconnection period.

Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection

https://technet.microsoft.com/en-us/library/cc816924%28v=ws.10%29.aspx