There was a need to create a sandbox site for end-user training. This would allow all the new content editors to get a hands-on experience during training without compromising the staging environment. We have a virtual server that’s used for development, but didn’t want to people playing with our stuff. The solution was to create a new web application with an empty site collection on the dev server using an alternate port number.
Working on the Destination Server
To start, a new web application was created on the destination server. The new web application was created through Central Administration on the destination server.
Under the Application Management tab
Create or extend Web application below the SharePoint Web Application Management section
Create a new a new Web application
The Create New Web Application page pretty much defaults everything you need to create your new site if your servers are on the same domain. Here we customized the Description and the Port to something that would be easy for people to remember like 9999. The Database Name was also customized to WSS_Content_9999 to get rid of that nasty GUID and make it easier to manage. You can also specify a Search Server, generally in dev the same machine.
Next, because content deployment is so sketchy with SharePoint we want to create an Empty Site. This is different than a New Site Collection with a Blank Site template. To create an Empty Site on your new application you will need to use the STSADM utility.
Open a command line prompt and navigate to C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN
Run the following command:
stsadm -o createsite -url http://yoursite:9999/ -owneremail your@email.com -ownerlogin DOMAINuser
This will create an Empty Site Collection making the Content Deployment much smoother.
Back in Central Administration make sure you select the new web application you just created by clicking on Site collection list under the SharePoint Site Management section under Application Management. You can change your Web Application using the menu in the upper right corner.
Select Web application general settings under the SharePoint Web Application Management section. It’s very important that all of these settings match the Originating Site! In our case the Maximum upload sizes didn’t match and the entire content deployment job failed after 1.5 hours because a single PDF was too big…ouch.
In Central Administration under the Operations tab make sure your destination server can accept content deployment jobs.
Select Content deployment settings under the Content Deployment section. The setting on this page should be:
Accept incoming content deployment jobs
Import server as the name of your server
Export server as the name of your server
Connection security is your preference
Temporary files C:WINDOWSTEMPContentDeployment by default. See below for more details.
Reporting is your preference…ours was 20
Working on the Source Server
Now that you have your empty site setup on the destination server it’s time to create the content deployment job that will create a copy of the site.
On the source server go to Central Administration and select the Operations tab. Click Content deployment paths and jobs under the Content Deployment section.
First you will need to create a new path. Click New Path on the Mange Content Deployment Paths and Jobs page. These are the settings used:
- Name and Description – We used the Source and Destination server names and ports. Source Web application is what you are copying; Source site collection is usually / URL of the Destination Central Administration Server – We used http://desitinationservername:portnumber/ which yields this warning – You have specified a URL that begins with http://. Communication to this URL will not be secure and can be intercepted by malicious users. We were o.k. with this because it’s on our domain.
- Authentication Information – Connect by using the application pool account
- Destination Web application – http://desitinationservername:emptysiteportnumber/ (e.g. http://desitinationservername:9999/)
- Destination Site Collection – /
- User Names – We checked Deploy user names
- Security Information – We selected All
Next you will need to create a New Job. On the Manage Content Deployment Paths and Jobs page click New Job. This will bring you to the Edit Content Deployment Job page where you define your job settings. Here’s what was used:
- Name and Description – We wanted a full deploy so it looked something like this – Full Deploy SourceServer 80 to DestinationServer 9999
- Path – Select the content deployment path you just created
- Scope – We wanted a full deploy so Entire site collection was selected
- Frequency – In our case it was on demand only so nothing was scheduled
- Deployment Options – We wanted a full deploy so Deploy all content, including content that has been deployed before was selected
- Notification – (optional)
- Preparing for Deployment
So, your empty site is setup and your deployment job is created. It’s time to deploy, right? Well that’s what we thought. Not so much.
When we ran job by selecting the Run Now option on the Full Deploy SourceServer 80 to DestinationServer 9999 menu, it bombed out within 17 minutes. Once you start the job the status will change to Preparing soon after if you refresh the page the status will update to Running. You can then click on Running and it will bring you to a Content Deployment Report page that will postback updates as the job is running and give you errors that occur along the way.
We got all kinds of nifty ambiguous errors, one in particular was interesting – Unknown compression type in a cabinet folder.
Apparently SharePoint creates a ton of cabinet files in C:WINDOWSTEMPContentDeployment on both servers. Looking at the free disk space on the source server revealed that during content deployment the drive was reaching capacity!
Observing the drive space on both servers during content deployment revealed that job requires more than twice the unused space as the size of the site. In our case the site is close to 3GB, so around 8GB of free space was needed before the job succeeded!
Well, needless to say we needed to do some cleaning of the C:WINDOWSTEMPContentDeployment directory on both machines before deployment. Unfortunately, we couldn’t delete the cab files on the source server that were just created by the job. WFT? It turns out SharePoint was hanging onto the files with the Windows SharePoint Services Timer service OWSTIMER.EXE. Restarting the service using computer management freed up the files so that we could remove them before starting a new content deployment job.
This issue could be unique to our setup but it’s worth mentioning in case you run across the same thing.
Deployment…finally
After cleaning up the temp dirs of both the source and destination server and making sure all the site settings match, we ran the job again. Success! Looking at the details there were still crazy warnings like A Web Part or Web Form Control type could not be found, or is not registered as safe. The Web Part will still be exported and User or group 122 cannot be resolved. It succeeded, however, after 1 hour and 47 minutes and 2799 MB’s of content.
Looking at the drive space once again because of curiosity, it was discovered the cabinet files on the source server we automatically cleaned up but huge log files remained in C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12LOGS. This is because we have the Number of log files set high on the Diagnostic Logging page under Logging and Reporting section under Operation in Central Management.
The cabinet files stilled remained on the destination server and were locked by the Windows SharePoint Services Timer service.
Summary
SharePoint content deployment to a different server on the same domain is pretty easy once you check a few things. Make sure you create an Empty Site Collection on the destination server, which is different that a Site Collection with a blank template. When your site has been created make sure it matches all the settings of the source site paying close attention to file sizes.
Create your content deployment paths and jobs on the source server. Generally the basic settings will suffice. When you’re ready to deploy make sure you have more than twice the amount of disk space compared to the site size available on both servers.
Hope this helps anybody that experiences similar issues.