Carefully consider using the Copy-SPSite command

The Copy-SPSite command was introduced in SharePoint 2013. The TechNet description states that the command “Makes a copy of a site collection.” Administrators should carefully understand when to use Copy-SPSite and what impact the usage might have.


In the past years, I have seen SharePoint customers using Copy-SPSite for various occasions:

  • Duplicating Sites from a template, to provision Site Collections
  • Using Copy-SPSite to rename Site Collections in SharePoint 2013 (Todd's Blog Post)
  • Moving Sites as an alternative to Move-SPSite

I have been supporting multiple customers suffering from issues caused by the (improper) use of the Copy-SPSite command. The intention of this blog post is to create awareness of known issues after using the CopySPSite command and for Administrators to carefully use it.

Potential problems after using Copy-SPSite

Examples of issues that have been reported by customers to Microsoft Support:

    • OneDrive Sync Client might fail syncing content from sites that have been duplicated using Copy-SPSite.
    • There is an issue with deleted items in Recycling Bins within duplicated sites created using Copy-SPSite.
    • Third Party Backup/Restore Tools as well as Microsoft DPM is failing restoring content from duplicated sites.
    • Third Party Migration Tools might fail migrating content from farms, that have duplicated sites created using Copy-SPSite.
    • Exporting content using Export-SPWeb is going to fail if sites that have been duplicated using Copy-SPSite are within the same content database:


"These columns don't currently have unique values."

This is a common indicator, that you are affected by problems resulting from Copy-SPSite.
Check the following image, that shows how the Copy-SPSite command impacts Export-SPWeb Operation:

These columns dont have unique values


Copy-SPSite is causing duplicated GUIDs within the site(s) that have been created by the command. The Site Collection ID is going to be unique, Web and List GUIDs won't. This is most likely causing the issues mentioned above.

Possible Workarounds

Consider one of the following options as a possible workaround. Carefully read and understand the impact, test in a production clone to verify the solution. Contact Microsoft Premier Support or a Microsoft Partner if you need additional guidance or advisory.

Proper Copy-SPSite usage
Delete the source site after using Copy-SPSite

Copy site to a different content database
Use the Copy-SPSite -DestinationDatabase parameter to copy the site to another content database within the web application. This Workaround should be considered as short term only. This still might cause you problems in the future, as duplicate GUIDs remain within the farm.

Export/Import affected sites to generate new GUIDs
1. Move affected duplicated sites in a seperate content database within the web application using Move-SPSite
2. Export the moved site using Export-SPWeb
3. Import it into a new site using Import-SPWeb. This is going to eleminate duplicate GUIDs by generating new ones.
4. Delete the source site that was moved to the seperate content database (see 1.)

Update (April 20th, 2017)

Good News! The December 2016 CU for SharePoint 2013 fixes the issue that occurs while using the Export-SPWeb operation on sites that have been created using the Copy-SPSite operation.
See: December 13, 2016, update for SharePoint Foundation 2013 (KB3128007). Thank you Torsten for sharing this information!


Please be aware, that you should carefully consider using Copy-SPSite. This command should only be used for special operations. Avoid using Copy-SPSite as a Site Provisioning technique, as this would cause your farm being victim of problems that might not be visible right away, but cause problems in the future. There are known issues/bugs, therefor try to avoid using the command in daily operation. Regarding the known issues, you should only use Copy-SPSite in circumstances where long term GUID duplication can be avoided by deleting source sites after using the command.

Final Note

I hope this article helps you prevent having problems during SharePoint operation.
Please share your experiences in the comments. Any feedback or additions for this post is highly welcome.

Thank you for rating this article if you liked it or it was helpful for you.

Comments (8)

  1. Hi Christian,

    very interesting info.


  2. Hi Chris,
    thanks for the info!

  3. Great article! Didn’t know all if these limitations. Thumb up!

    1. Thank you Torsten for this information!
      (The Export-SPWeb Operation can now be used for sites, that have been created by using Copy-SPSite)

  4. Very Useful information , Thanks a lot.

  5. Hello,

    Very interesting read, thanks a lot for the great article. Do you know if any additional problems were solved with cumulative updates besides the Export-SPWeb operation?
    I have a scenario where I want to split a 200gb content database into several site collections on their own dbs. The scenario is explained here:

    Could you advise on the best option to accomplish this?

    In general, in this scenario, what would be the best approach to:
    1 – Quicky migrate large amounts of data (I have cases of 50 GB in a single document library) to a new site collection?
    2 – Preserve workflow history (something possible with Copy-SPSite approach, not possible using a 3rd party migration tool)
    3 – Avoid duplicate GUIDs in content databases. Not sure this is a problem with different content databases (if is for sure in the same content db).
    4 – Quickly have users to start working on the migrated site collection (I believe this is key since migration tools as Sharegate for example take a very long time to migrate large amounts of data).


    1. Hi Miguel!
      If I would have to deal with the task you need to complete, I’d prefer using a third-Party tool. Copy-SPSite would not be my first choice when it comes to reducing the overall size of a Site Collection. Even though Copy-SPSite is a good option for creating a (temporary) copy of a Site within another Content Database (in this use case the source Site Collection is deleted afterwards, so there won’t be duplicate ID issues), you’ll still have to deal with partial deletion/reorganization of content, in order to shrink the size of the site. How would you want to achieve that? I’d personally try to avoid working with Export/Import, as this is not the most robust way to move content of sites. In my experience it is okay for easy structured content, but you should strongly test export and import actions before triggering it against your productive content.
      This is what 3rd Party Tools typically can do very good, giving the admin the choice to granularly skip unnecessary content (define certain number of versions) and to reorganize content to a new structure where necessary.

      A good cutover plan is one of the most important part in this kind of reorganizations. Make sure to find out how long it takes to move/rearrange/shrink the content, therefor you need to do proper test migrations to be able to define the right approach for this. I personally would try to avoid users having to work at source and destination at the same time. You clearly need to communicate where important content can be accessed from during the migration.

      Hope this helps for the moment!

Skip to main content