This site is the convergence point of three prior Sharepoint sites.
Those prior sites were:
- the UWWI Roadmap site https://share.u.washington.edu/sites/NonAcademic/CAC/Project/CollabApps/sl/uwwi
- the MS Collaborative Applications blog site
- the Windows Infrastructure Team site
The convergence of these sites is possible because of a significant milestone for the UW Sharepoint service. That milestone is that there is a suggested cost for that service (which is pending an official announcement).
The process by which these sites converged is technical interesting, and is the topic of this blog post.
Generally speaking, you can export (backup to file) and re-import any Sharepoint site–MOSS or WSS–using special stsadm commands. And in fact, in this instance this is a convergence of two MOSS sites and one WSS site.
One special issue was that the Sharepoint server hosting the old sites was in a different domain. When this is the case, you must either choose to translate security references or drop your security configuration, and recreate it after the import. The translate security functionality has some gotchas. It is a per-user operation which means you’ve got to get a list of all the users. That can easily be done by running the export command once and looking at the log file. Another gotcha is that when you run it to convert say nebula2\user to netid\user it converts *every* instance of nebula2\user in that sharepoint farm to netid\user. This might be very disruptive. A final gotcha is that if the target user you want to convert to has logged in to the source Sharepoint farm, or if they’ve been granted permissions, then the operation can cause destructive behavior or error.
An example of the security translation command is:
stsadm -o migrateuser -oldlogin DOMAIN\user -newlogin DOMAIN\user [-ignoresidhistory]
The combination of these security translation issues left me thinking it was less work to just reconfigure security after the import . Fortunately, the blog site was on it’s own server in the same domain as the UW Sharepoint server, so it didn’t have any of these issues.
An example of the backup/export command I used is:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm -o export -url http://viewpoint.cac.washington.edu/blogs/ms-collab -filename c:\finaltry\ms-collab.cmp -includeusersecurity
An example of the import command I used is:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o import -url https://sharepoint.washington.edu/windows -filename c:\temp\ms-collab.cmp -includeusersecurity
The import command will fail if you are not importing to a site with the same site template as the site which you exported from. This is a very important gotcha for when you are trying to converge several Sharepoint sites into one.
And in fact, this site template restriction was a problem for this convergence. The roadmap and wit sites listed above were both from the team site template, whereas the blog site was from the blog template.
To handle this, I decide that the blog site had more content which was harder to manually reproduce via another method, so I went with a blog template, and only imported that site via this method.
For the roadmap site, there were other issues. That site was a subsite of a larger MSCA site collection, and some of the content in the roadmap site had some cross-site lookups to data in that larger MSCA site collection. Those were minimal, and I decided that I could lose those lookups and convert that data to something more static. However, the roadmap site was fortunate in that it was basicallly just two lists. So I exported both lists to a spreadsheet, recreated the custom lists (i.e. recreated columns etc), then copy and pasted the info, massaging the cross-site lookup data slightly.
Finally, there was the wit team site which had a lot of internal documentation. I opted to create a subsite for that, limiting the access to it to internal team members. However, if the goal truly had been to converge, I could have exported all the documents and uploaded them.
So for two of the sites, I used an adhoc approach because it was good enough and was the least cost. However, there are other methods you can use when an adhoc approach isn’t acceptable.
http://www.sharepointnutsandbolts.com/2007/10/stsadm-export-content-deployment.html has a very detailed comparison of ways to move Sharepoint content around that document some of these other approaches.