The Surly Admin

Importing Sharepoint Sites

This is the follow-up to the Export-Sharepoint Sites post early this week.

It’s great that we can export a Sharepoint site now, and even get a nice report giving us document counts which we’ll need to validate that the import has worked correctly.  But now we need to do the import, and we want it to be as easy as possible, and here’s how I did it.

Recap

First I want to recap the steps we’ll need to accomplish to have a successful import:

1. Successfully Export the site – we need Export-SPSite.PS1 for this.
2. Create a new site at the location we desire
3. Import the site into the new location.
4. Get document counts so we can compare to the

Since step #1 has already been completed we now need to work on steps #2 and #3.

Site Template Fun

When doing my original testing, and running these commands manually I ran into an interesting problem with Importing the site files and configurations.  You see, when using Import-SPWeb, the website/collection you are importing to has to be created using the same Site Template that the original was created with.  So I had to delete my test site, recreate it with the right template then import my files.  That meant the challenge now was doing the same thing scriptomatically.  So I checked Get-Member with the Get-SPWeb cmdlet and there were a couple of promising properties available:  WebsiteTemplate and WebsiteTemplateID.  By the way, see this website for the different templates and their names.

Quick check of WebsiteTemplate gave me “STS”.  Which was good, but only half of the name, I needed to be able to get the number too (notice that with the template name STS there are 3 templates:  Team, Blank and Document (0, 1 and 2 respectively).  Checking WebsiteTemplateID and I got a 1.  This was the first red flag, believe it or not.  I know on my Sharepoint site pretty much all of the sites were created using the Team template.  First thought was maybe Powershell is offsetting the numbers by 1 so I could just subtract 1 and make it work.  But that was just a guess, so I had to test it.  Created a test site and used the Blank template, then check WebsiteTemplateID again and I got a 1.  Uh oh.

Not one to be deterred, I decided to try the two field anyway and just see what happened.  This is where something interesting happened–interesting good.  I created the site using New-SPWeb and it failed on my attempt to use those two fields (turns out it was a simple syntax error where I typed something wrong) but the interesting part was Sharepoint went ahead and created the site anyway–without any template assignment.  I immediately saw some potential here, and decided to run the Import-SPWeb on my template-less site and see what happens.

Turns out it imported perfectly.  The command ran without any error and when I navigated to the site on my web browser everything was just fine.  I even check some document counts and it all came out just fine.  And suddenly this script become much easier.

Where’s The Code?

Enough talk, let’s get to the code!

$Site = Get-Content $ImportPath\site.txt
$NewSite = $Site.Replace($Search,$ReplaceWith)

$NewWebParameters = @{
   AddToQuickLaunch = $AddToQuickLaunch
   AddToTopNav = $AddToTopNav
   UseParentTopNav = $UseParentTopNav
}
New-SPWeb -Url $NewSite @NewWebParameters

Here I read in the site.txt file that the Export-SPSite.ps1 script created, and just holds the URL for the old site.  I use the information I got from $Search and $ReplaceWith parameters and do a simple string replace to construct the new site name.  Now, I wanted to give the script a lot of flexibility to control how the new site will look and field–and integrate–into your new Sharepoint server.  It’s not a perfect system, though.  While the new site that we create will have the proper settings as far as the Quick Launch and Top Navigation bar go it won’t do anything for any sub-sites that may exist.  To give that flexibility, I added the 3 parameters from the New-SPWeb cmdlet, AddToQuickLaunch, AddToTopNav and UseParentTopNav to the Import-SPSite script.  Then we can just create a hashtable with those switches in it and splat it onto the New-SPWeb cmdlet.

Import-SPWeb -Identity $NewSite -Path $ImportPath\site.cmp

This one is pretty straight forward, use the NewSite variable we created and the ImportPath that was specified in parameters.  That’s really it.  I added some error checking to make sure the site doesn’t already exist (that would be bad!) and to make sure the ImportPath has the necessary Site.TXT file in it.  Since Export-SPSite names the export files the same (Site.CMP) we don’t have to do any discovery there.  Also added the code to do the document counts in there to create another report after the import where you can compare the “before” and “after” reports to make sure everything went over.  Why wouldn’t it?  If you don’t have full permissions to everything, it won’t export it in the first place.

Potential Uses

As I said in the Export-SPSite post, the purpose of these scripts was to help me with moving these Sharepoint sites to the IT department that is handling the divested companies IT.  Hopefully they will find it useful, but at the very least they will have standard Powershell/Sharepoint export files that they can use, along with a simple CSV file with document counts to assist in the validation steps they’ll need to do.

But it doesn’t have to be used that way, does it?  What if you ran the script on all of the top-level sites on Sharepoint?  You’d have a pretty decent backup, one you could import the site you needed and restore individual files.  Not exactly a granular level backup–something Backup Exec has been doing for many years now–but certainly a very decent backup that will cost you–or your client–absolutely nothing.  Unless you wanted to send me some cookies.  I love cookies.

Chocolate chip.

Download

Click here for the Import-SPSite Source Code

February 28, 2013 - Posted by Martin9700 | PowerShell | Import-SPWeb, Sharepoint