Roland Serman’s Blog

Just another weblog

Using PowerShell to backup SharePoint 2010 Site Collections

Here is a handy script I use for backing up all of my SharePoint site collections. Many thanks to Todd Klindt for providing the bulk of it in a one liner.  I had to make a few tweaks, most notably the “-limit all” and the .Replace for https://.&#160; Make sure to replace anything in <> with your own values.

Add-PsSnapin Microsoft.SharePoint.PowerShell

Get-SPWebApplication | Get-SPSite -limit all  | foreach {
    $FilePath = \\">\\">\\<ServerName>\<ShareName>\;
    $ext = $_.Url.Replace("http://", "").Replace("https://", "").Replace("/","-").Replace(":","-") +".bak";
    write-host $ext
    Backup-SPSite -Identity $_.Url -Path $FilePath$ext -Force

Check out Todd’s blog, he has a lot of good info, including similar script to backup webs.


Profile Sync Timeouts

I recently had to open a ticket with Microsoft because of problems getting the Profile Sync service to successfully sync with Active Directory.  In doing so, it was recommended that I modify a few of the timeouts associated with the service.  For the most part, none of these should need to be tweaked unless you have a large AD environment, and need to process large LDAP datasets.

We ended up modifying 3 different parameters:

  • ImportConnAsyncTimeout
  • FIMWebClientTimeOut
  • LdapConnectionTimeout

Don’t quote me on this, but this is my understanding of what each of the three values control:

ImportConnAsynctimeout: This timeout is when you click the Populate button on the editdsserver.aspx page, and SharePoint enumerates the domains/OU’s and then presents them on the page.  the default time out value is 30 seconds.

FIMWebClientTimeOut: After selecting what you plan to sync, and clicking the OK button on the editdsserver.aspx page, SharePoint then goes into the FIM service and create/edits the management agent.  The default timeout for this is ~16.6 minutes, due to large OU structures and the amount of data that is collected.

LdapConnectionTimeout: This is the timeout for the actual Directory Connection, the default for this is 30 seconds.

Below I’ve provided the powershell commands utilized to actually modify the parameters:


$upaAppProxy = Get-SPServiceApplicationProxy | ? {$ -like ‘User Profile Service Proxy’}

$upaAppProxy.ImportConnAsyncTimeout = 60 //This value is in seconds



$upaApp = Get-SPServiceApplication | ? {$ -like ‘User Profile Service’}

$upaApp. FIMWebClientTimeOut = 300000 //This value is in milliseconds



$upaAppProxy = Get-SPServiceApplicationProxy | ? {$ -like ‘User Profile Service Proxy’}

$upaAppProxy.LdapConnectionTimeout = 60 //This value is in seconds


Configure Kerberos for SharePoint 2010


Below I’ve outlined at a minimum what is required to setup Kerberos authentication for SharePoint 2010.  Ensure you replace everything surrounded by <> with the appropriate variable. With any luck I didn’t miss anything.


  1. Configure DNS for each Load Balanced Web Application
  2. Configure each Web Application to run under a unique Application Pool Identity.
  3. Set the appropriate SPN’s on the service accounts as so:
    1. SetSPN -S HTTP/<NSN>:<Port> <Domain\FSA>
    2. SetSPN -S HTTP/<NSN>:<Port> <DOMAIN\FSA>
    3. SetSPN -S HTTP/<URL1NBN> <DOMAIN\AppPl1A>
    4. SetSPN -S HTTP/<URL1> <DOMAIN\AppPl1A>
    5. SetSPN -S HTTP/<URL1>:<Port> <DOMAIN\AppPl1A>
    6. SetSPN -S HTTP/<URL2NBN> <DOMAIN\AppPl2A>
    7. SetSPN -S HTTP/<URL2> <DOMAIN\AppPl2A>
    8. SetSPN -S HTTP/<URL2>:<Port> <DOMAIN\AppPl2A>

SQL Server (DB)


SQL Analysis Services


SQL Reporting Services


Trust for Delegation

Configure Trust for Delegation for the service accounts and computer objects for all servers, and service accounts that you’ve set service principal names for.

IIS Config (Borrowed from Saurabh Sing)

In IIS 7/7.5 you have to also modify the applicationhost.config file (found at %systemroot%\system32\inetsrv\config\) to enable Kernel mode authentication, and to enable the application pool’s Identity, by adding the following: “useKernelMode="true" useAppPoolCredentials="true"” to the security portion of the applicationhost.config file as so:




         <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />




Configure SRS to answer via SSL

modify the rsreportserver.config with the following:

<Add Key="SecureConnectionLevel" Value="2"/>



Configure SRS to use Kerberos

Ensure the following exists in the rsreportserver.config file:



<RSWindowsNegotiate />

<RSWindowsKerberos />

<RSWindowsNTLM />






SharePoint: Trusting non Public Certificate Authority

I had to do the following to get SharePoint to connect to SQL Reporting Services via SSL when using an untrusted Certificate Authority.  Keep in mind, just because the server trusts the authority, SharePoint DOES NOT!

Add-PSSnapin Microsoft.SharePoint.PowerShell

$rootca = New-Object System.Security.Cryptography.x509Certificates.x509Certificate2(“d:\Admins\Certs\CACertClass3.cer”)

New-SPTrustedRootAuthority –Name “CACert Class 3 Root” –Certificate $rootca


<NSN> = Netbios Server Name

<Port> = TCP port used for the service

<URL1NBN> NetBios name for the first Web Application

<URL1> = FQDN for the first Web Application

<URL2NBN> NetBios name for the second Web Application (such as My Sites)

<URL2> = FQDN for the second Web Application (such as My Sites)

<FSA> = Farm Service Account

<AppPl1A> = Application Pool account for Web Application 1

<AppPl2A> = Application Pool account for Web Application 2

<SQLSvc> = SQL DB Engine Service Account

<SQLASSvc> = SQL Analysis Service Account

<SQLRSSvc> = SQL Reporting Service Account

<SQLSrv> = SQL Server FQDN

<SQLSrvNBN> = SQL Server Netbios Name

<SQLRptSrv> = SQL Reporting Server FQDN

<SQLRptSrvNBN> = SQL Reporting Server NetBIOS Name

Host Header based Site Collections & Database Sync Errors

As we painfully discovered this month, if you’re getting DB sync errors, (Event ID 5555, 5553) you cannot detach, and reattach to resolve the sync problem.

Basically what we discovered was with most stsadm commands there is an option -hostheaderwebapplicationurl, which does not exist for stsadm -addcontentdb.

After opening a ticket with Microsoft, we did the following to resolve our database sync problems.

1. stsadm -o sync deleteolddatabases 1

2. Restarted the timer service on all servers in the farm.

So anyway, if you go the other route of:

stsadm -o preparetomove

stsadm-o deltecontentdb

stsadm -o addcontentdb

And you have host based site collections residing in their own database you will have no means of reattaching them.  I spent several hours in a support call with Microsoft in the middle of the night trying to get these reattached, and ultimately had to rebuild the affected sites, and restore from backup.

List Site Owners for All Site Collections

Here’s a Powershell script I’ve managed to piece together that will output all Site Collection Owners (Not Site Collection Administrators) into either a csv or xml file.  In our SharePoint deployment we’re more of a service provider, hosting multiple web applications each containing one to many site collections, and we were looking for an easy way to determine who the site owners were for every site so that we could send notification prior to maintenance windows etc.  I’ve been working on this in my spare time over the past few weeks, feel free to leave any suggestions, I know it’s a bit convoluted.

#Generates a list of all site collections across all Web Applications,
#and outputing them into an array

$sitepath = New-Object System.Collections.ArrayList
$output=stsadm -o enumzoneurls
foreach-object -process {$y=stsadm -o enumsites -url $_.Default;$sites=[xml]$y;$sites.Sites.Site}|
foreach-object -Process {$sitepath=$sitepath + $_.Url}
$sitepath | Write-Output

#Define Output file, and labels

$filename = AllSiteUsers.csv
Write-Output “Site Collection,Title,Group,UserID,Email Address” | Out-File $filename -Append

#Loops through all site collections generating a list of Site Owners

foreach ($object in $sitepath) {
$site=new-object Microsoft.SharePoint.SPSite($object)
$groups = $web.groups | ? {$_.Name -match “^.*Owners” }
foreach($group in $groups)
foreach($user in $group.users)
Write-Output “$($object),$web,$($group.Name),$user,$($user.Email)” | Out-File $filename -Append

#Converts the csv ouput to XML

Import-Csv AllSiteUsers.csv | Export-Clixml AllSiteUsers.xml

How To Schedule a Windows Powershell Script

I take no credit for this, I found it at posted by hstagner.

Basically all you need to do is create a batch file that calls your Powershell script and schedule the batch file.  Your batch file should contain something similar to the following:

powershell -command "& 'MyScript.ps1' "

SharePoint Powershell Warm Up Script

I take no credit for this, I found it at Kirk Hofer’s blog, and thought I would share it as well.

#-Running on machine with WSS/MOSS
#-C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN in path

function get-webpage([string]$url,[System.Net.NetworkCredential]$cred=$null)
$wc = new-object net.webclient
if($cred -eq $null)
$cred = [System.Net.CredentialCache]::DefaultCredentials;
$wc.credentials = $cred;
return $wc.DownloadString($url);

#This passes in the default credentials needed.  If you need specific stuff you can use something else to
#elevate basically the permissions.  Or run this task as a user that has a Policy above all the Web Applications
#with the correct permissions
$cred = [System.Net.CredentialCache]::DefaultCredentials;
#$cred = new-object System.Net.NetworkCredential(“username”,”password”,”machinename”)

[xml]$x=stsadm -o enumzoneurls
foreach ($zone in $x.ZoneUrls.Collection) {
[xml]$sites=stsadm -o enumsites -url $zone.Default;
foreach ($site in $sites.Sites.Site) {
write-host $site.Url;
$html=get-webpage -url $site.Url -cred $cred;

Host Header Site Collections over SSL

We’ve been working condensing the number of web applications that we’re hosting, and have turned to Host Header based site collections.  Doing so over http is quite simple, but since we only host sites via SSL I ran into a few things that I couldn’t really find documented anywhere, and thought I’d share.

The first thing we discovered is that if you use a random port when creating your Web Application you will receive the following error every time you try to create a host header site collection:

“The port specified for the new host header site does not match any known bindings in the specified Web Application.  The new site will not be accessible if the Web Application is not extended to an IIS Web Site serving this port.”

This being said the host header site collection works, but if you try to restore content to it you receive the same error.  What I found was that if you create your web application as and then change the alternate access mapping setting the default to and intranet as you can create any number of host header based site collections error free.

Once your web application is created, creating the host header based site collection is quite simple, you just run the following:

Create Site

stsadm -o createsite -url -ownerlogin DOMAIN\username -owneremail -sitetemplate STS#1 -hostheaderwebapplicationurl

Create Site in New DB

stsadm -o createsiteinnewdb -url -ownerlogin DOMAIN\username -owneremail -sitetemplate STS#1 -hostheaderwebapplicationurl -databaseserver -databasename WSS_Content-HHSite1

Note: you can use either -hostheaderwebapplication or -hhurl for the switch, both work, but currently (with SP1 installed) if you do a stsadm -help createsite it comes back with -hostheaderwebapplicationurl as the switch.

Once the site collection has been created, you now need to setup the SSL host header.  This is rather simple as well, you just open a command prompt and navigate to C:\inetpub\adminscripts (or wherever you’ve placed your inetpub directory) and run the following command:

adsutil.vbs set /w3svc/[identifier]/SecureBindings [IP address]:443:[host header name]

So in example above of having the web app as and the hosted site as being you’d run the following:

adsutil.vbs set /w3svc/123456789/SecureBindings

Note: You seperate each host header with a space.

You also need to ensure that you have a wildcard cert applied to IIS vserver that will cover all Host based site collections that you’re hosting on the associated web application.

DR Backup/Restore of SharePoint Farm

Farm Preparation

Before you can successfully backup and restore via the catastrophic backup/restore method you must ensure that your Alternate Access Mapping for the Default is set to the http://url:randomport, as seen below.


Note: This is required if you have multiple Web App’s utilizing SSL, but seems to work fine without doing this if you only have a single Web App.

Backup the IIS Metabase

Logon to the each of the WFE’s as the Farm Admin/Setup User account and run the following command to backup the IIS metabase:

iisback.vbs /backup /e <PASSWORD>

Catastrophic Farm Backup

Now we’re ready to perform the catastrophic farm backup. You can do this one of two ways, either via STSADM as so: stsadm.exe –o backup –directory <UNC Path> -backup full (example stsadm.exe –o backup –directory \\ServerName\ShareName -backupmethod full)

Or you can perform the backup via Central Admin’s Operations tab as shown below:


Insure to check ‘Farm’ which should highlight and check everything, and then click ‘Continue to Backup Options’.


Select ‘Full’, and then enter the UNC path of your backup location and click ‘OK’.

Remove SharePoint Servers from the Farm

Once the backup is completed, you are ready to remove all the servers from the farm, remove each server one at a time, removing the server that hosts Central Admin last via the ‘SharePoint Products and Technologies Configuration’ wizard.

Create a New SharePoint Farm

1. Starting with whatever server will host Central Admin, create a new farm using the ‘SharePoint Products and Technologies Configuration’ wizard. During the setup make sure you name the SharePoint Config database something different, because when you attempt to restore the entire farm, it will not allow you to overwrite and existing database. Also, choose the same port for Central Admin as you used previously for http access.

2. Add all remaining servers to the farm one at a time.

Now that all servers are in the farm, there are few steps you must complete prior to restoring the farm backup. The following services must be started on the appropriate servers, Excel Calculations Services, Office SharePoint Server Search, and Windows SharePoint Services Search.

1. Start Excel Calculations Services.

2. Start Office SharePoint Server Search, like so:


3. Now you need to start the Windows SharePoint Services Search like so:

Note: You need to use a different name for the Search Database than what was used previously.


4. You may now start any other services on which ever servers you would like, but it is not needed at this point. These three must be completed in order run the restore.

Restore From Farm Backup

You can either restore via stsadm with the following command:

stsadm.exe –o restore –directory <UNC Path> -restoremethod new

Ex: stsadm.exe –o restore –directory \\ServerName\ShareName -restoremethod new

Or if you’re restoring to a new database server/instance:

Stsadm –o restore –directory <UNC Path> -restoremethod new –newdatabaseserver <servername>

Ex: stsadm.exe –o restore –directory \\ServerName\ShareName -restoremethod new -newdatabaseserver

You can also use Central Admin, which I highly recommend if you’re restoring to a new database server/instance, simply because you can verify every setting before continuing, as you’ll see below.

1. From the Operations tab of Central Admin, select ‘Restore from Backup’.

2. Enter the UNC path to the backup, and click ‘OK’.


3. Select the backup that you’d like to use, and then click ‘Continue Restore Process’.


4. Check ‘Farm’, which should check and highlight everything, and then click ‘Continue Restore Process’.


5. From this screen, you define the Login name and passwords for all of the Application Pools, as well as Web App URL’s, Database Server, database name, and db directory. There are three sections to this screen.

a. The fist, make sure that ‘Farm’ is selected, and that ‘New Configuration’ is selected.


b. The next section can be quite long depending on how many application pools you have. Here you need to verify the username and password for each application pool, like so.


c. Finally, you need to verify all URL’s, database server names, database names, and database file locations, and make any necessary changes.


6. Once you’re comfortable that all the information is correct click ‘OK’, and wait for the restore to complete.

Once the restore completes successfully there are a couple additional tasks you have to complete manually before your SharePoint farm will be ready for user access.

1. Set all of your Alternate Access Mappings. The restore only restores the Default mapping, so if you had any additional mappings you will have to manually add them like so:


2. Now you need to configure which IP address each IIS vserver will listen on, as well as add the necessary Cert if the site will use SSL.

3. Finally, for all sites that use SSL you will have to run the following command:

adsutil.vbs set /w3svc/[identifier]/SecureBindings “[IP Address]:443:[host header name]”

example: adsutil.vbs set /w3svc/1234567890/SecureBindings “”

At this point your farm should be completely functional.