So I realize that this article is about two years too late, but the question still comes up from time to time, so I figured that I might as well post it.
Situation: You find yourself in a quandary without the use of a third party tool from AvePoint, Metalogix, Quest, Tzunami and your organization just merged with another… and you’ve got site data that you need to move. Sure, sounds easy, but it’s a pretty rough job that requires planning.
Courses of action that you might proceed down:
- First option that comes to mind would be to perform a content migration through the attaching of content databases onto a dev server in a separate web application on the destination domain, and proceeding to restore database schema permissions to the content databases so that the farm can access the data properly. This works pretty well with the exception that if you have sites that overlap sites that already exist when you’re beginning your movement of sites from the dev environment to the production environment. Additionally, all user permissions need to be reassigned – so you end up running through stsadm in a batch script fashion.
- Second option that comes to mind is to use Gary Lapointe’s export and import files stsadm extension. These extensions go above and beyond what the out of the box stsadm tool provides and fulfills several other purposes outside the scope of this article. Using these extensions for exporting document libraries and lists, you’re able to perform a content deployment method without having to write any of your own code. Additionally, there are extensions that allow for exporting a list or document libraries schema so that you’re able to recreate site columns and content types within the destination list. The only potential issue that would arise would be recreating or migrating all site permissions.
- Third option with potential for small organizations – save site as template with content. Unfortunately this can only grow so big before it becomes unwieldy and templates stop working.
- The fourth option, which to me seems to be the easiest as long as you’re dealing with a fairly vanilla SharePoint installation that doesn’t have customized site definitions, is to follow the approach of using standard stsadm tools and a bit of elegant batch file hacking.
c:%12hive%bin> stsadm -o export –url http://<webApp>/sites/<siteCollection>/<siteName> –filename <nameOfFile>.cmp -includeusersecurity -versions 4 -nofilecompression
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
This will take the site, keep all versions and the sites’ security as well as dump the files without compressing into a cab – for extremely large sites, cabs don’t work 😦
Next, you’d go in and create the shell on the new site collection…
c:%12hive%bin> stsadm -o createsite –url http://<webApp>/sites/<siteCollection> –ownerlogin <domain><user> -owneremail <emailAddress>
or if creating a site…
c:%12hive%bin> stsadm –o createweb –url http://<webApp>/sites/<siteCollection>/<site>
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
Then you’d import the new site to that site (DO NOT go to the previously created site and choose a template).
c:%12hive%bin> stsadm -o import –url http://<webApp>/sites/<siteCollection> –filename <nameOfFile>.cmp -includeusersecurity -updateversions 1 -nofilecompression
or if creating within the context of a site (rather than site collection)
c:%12hive%bin> stsadm –o import –url http://<webApp>/sites/<siteCollection>/<site> –filename <nameOfFile>.cmp –includeusersecurity –updateversions 1 -nofilecompression
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
The details of import and export are available at:
http://technet.microsoft.com/en-us/library/cc262465.aspx
After you’ve done that, you’ll probably want to add yourself as the owner to that site collection (if you’re importing into a site collection, else you can skip this)…
c:%12hive%bin> stsadm -o siteowner –url http://<webApp>/sites/<siteCollection> –ownerlogin <domain><user>
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
The details of site owner are available at:
http://technet.microsoft.com/en-us/library/cc262637.aspx
Next, you’ll want to ensure that the security groups are how you want them – moving them from one site collection to another through a site isn’t always as pretty as you might hope. Sometimes it’s best to go in and re-create them in the new site collection rather than bringing over what was old, using them as a reference before toasting them.
Lastly, you’ll need to migrate the user permissions from domain A to domain B.
To do this, again, pretty trivial, just a little stsadm’ing. I’d recommend creating a spreadsheet in Excel and then exporting it to a text file to run as a batch so that you end up with something like this:
c:%12hive%bin>stsadm -o migrateuser -oldlogin <domainA><user1> -newlogin <domainB>TempUser –ignoresidhistory
c:%12hive%bin>stsadm –o migrateuser –oldlogin <domainB>TempUser -newlogin <domainB><user1>
This method takes the user, reassigns them to a temporary user and then the TempUser is migrated to the user account in the new domain. This is not always necessary, however I’ve come across a few instances where using a TempUser is recommended to ensure that the migration occurs properly.
Reference: http://technet.microsoft.com/en-us/library/cc262141.aspx
If you’re getting stuck, and need to don’t mind looking inside your database to see what’s going on, check out Todd Klindt’s article “A few notes abouT STSADM –o migratuser”.
Happy Migrating!
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
0 replies on “Migrating a site between domains”
So… in using the export/import method, I got an error message that stated the source and destination farms were different versions. Ideas on how to get around that (can’t go patching them)…
LikeLike
Shanif – for the imports and exports to work, the destination farm must be at the same patch level or greater than the source farm. Unfortunately there’s no easy way around this.
LikeLike
Standard warning for stsadm -o export from TechNet:
“You cannot save a workflow, alerts, features, solutions, or Recycle-Bin state by using the export operation.”
http://technet.microsoft.com/en-us/library/cc706866.aspx
LikeLike
Sharepoint server does not accept SID history and it required to run the command “stsadm -migrateuser” on the server to enable the migrated user to access the sharepoint site.
Can Quest Tools do this automatically instead of running the command on SharePoint server?
LikeLike