PowerShell to Restart SharePoint Farm Windows Services


Introduction

One of the steps that I suggest when deploying upgrades to SharePoint solutions is before you do a Solution upgrade restart all the SharePoint related services.

So in a SharePoint 2010 Farm that would be:-

  • SharePoint Administration Service
  • SharePoint Timer Service
  • World Wide Web Publishing Service
  • IIS Admin Service
  • Web Analytics Service
    The reason is that certain processes (i.e. SharePoint Timer Service) can lock assemblies and cause solution deployment to fail.

However this step is a pain in the ass when you have a more than one server!

To help ease the pain here is a PowerShell script which will loop through all the servers on the farm (ignore the database servers) and restart the appropriate services.

The great thing about this script is it will also ensure that services that are required to be running are also running such as the SharePoint Administration Service!

The Script

param
(
	[Parameter(Mandatory=$false, HelpMessage='-ServiceNames Optional, provide a set of service names to restart.')]
	[Array]$ServiceNames=@("SharePoint 2010 Timer","SharePoint 2010 Administration","IIS Admin Service","World Wide Web Publishing Service")
);

Write-Host "Attempting to get SharePoint Servers in Farm" -ForegroundColor White;
$farm = Get-SPFarm;
$servers = $farm.Servers;
Write-Host "Found" $servers.Count "Servers in Farm (including database servers)" -ForegroundColor White;
foreach($server in $servers)
{
	if($server.Role -ne [Microsoft.SharePoint.Administration.SPServerRole]::Invalid)
	{
		Write-Host "Attempting to restart services on" $server.Name -ForegroundColor White;
		foreach($serviceName in $ServiceNames)
		{
			$serviceInstance = Get-Service -ComputerName $server.Name -Name $serviceName -ErrorAction SilentlyContinue;
			if($serviceInstance -ne $null)
			{
				Write-Host "Attempting to restart service" $serviceName ".." -ForegroundColor White -NoNewline;
				try
				{
					$restartServiceOutput="";
					Restart-Service -InputObject $serviceInstance;
					Write-Host " Done!" -ForegroundColor Green;
				}
				catch
				{
					Write-Host "Error Occured: " $_.Message;
				}
			}
		}
	}
}

Notice you can extend the Services that are restarted by adding/removing service names to the array parameter $ServiceNames.

Hope that helps.

How we deployed SharePoint WSP Solutions without downtime


 

Introduction

As your SharePoint environment grows and more solutions are built on the platform it becomes critical to the business. Often it gets to the level that the business is very reluctant to allow SharePoint to be unavailable. This makes it difficult to plan application deployments which generally cause downtime.

Recently, I have been working on an environment which was in use globally and therefore the window for taking down the SharePoint farm is very small.

With that in mind I thought I’d share the process that I now use to deploy SharePoint WSP solutions without any downtime to the SharePoint farm. There are going to be times where you cannot avoid downtime, certain SharePoint object model calls cause all the server to recycle their application pools.

In order for deployments to be executed with no downtime there are a few requirements. There are infrastructure requirements as well as following a process.

 

Farm Configuration Requirements

In order to deploy SharePoint solutions there must be at least two SharePoint Servers configured as Web Front Ends. These web front ends are running the Web Application Service instance.

The next step is to ensure that these servers are being load balanced, either using software load balancing such as Windows Network Load Balancing (NLB) or using hardware load balancers such as the F5 Network’s BIG IP.

The F5 Network’s BIG IP configuration guide can be found here.

Without either the load balancers or the two web front ends then you are not going to be able to prevent downtime.

Regarding the load balancers, they must be configured so that when a server is down then no traffic is directed to that server.

At one client this required a bit more thought. The client used the F5 Network BIG IP load balancers unfortunately the load was not balanced as Round Robin balancing was being used.

Also the method to detect whether a server was down did not work. The way that the load balancers tested that a server was available was by using a low level call into IIS looking for an HTTP status of 200. This meant that as long as IIS up then the server was up and it would receive requests,  even if SharePoint was failing for some reason.

This was fixed by using a cURL script which allows Windows Authentication to be used to call into SharePoint. The script would then look for a particular text string in the page. As long as this was found then the server is up and available.

The last tweak to the load balancers were configured to use Observed dynamic balancing. The following article by Don MacVitte gives a great overview of the different types of load balancing.

Observed load balancing, balances the load by using a number of metrics, this snippet from the article explains in more detail:-

Observed: The Observed method uses a combination of the logic used in the Least Connections and Fastest algorithms to load balance connections to servers being load-balanced. With this method, servers are ranked based on a combination of the number of current connections and the response time. Servers that have a better balance of fewest connections and fastest response time receive a greater proportion of the connections. This Application Delivery Controller method is rarely available in a simple load balancer., including the response time from each server.

 

Deployment Process

SharePoint Deployment Without Downtime Diagram Process

With these infrastructure requirements in place it is possible to deploy solutions without downtime.

For SharePoint 2010 deployments, PowerShell is the tool of choice when deploying SharePoint Solutions.

Once you have the farm configured correctly then you will need to deploy the solutions through the SharePoint 2010 Management Shell.

So generally I login onto the server through Remote Desktop, copy over the solution file(s) into a folder such as c:\install\[solutionname]\[solutionversion].

Once the files are copied over:

  • Start SharePoint 2010 Management Shell
  • Change Directory to where the SharePoint solution (.wsp) are found.
    • cd c:\install\[solutionname]\1.0\

    The approach that I take is to use PowerShell variables where I can. This helps reduce the amount of typing and there are less mistakes made.

  • Create a variable to the current folder
  • $curdir = gl;
  • Create a variable for the solution’s filename
  • $solutionname = "MySolution.wsp”
  • Add the solution
  • Add-SPSolution –LiteralPath $curdir\$solutionname

Next is the important part, the solution has been added to the Configuration database and the next step is to deploy the solution to the servers. To ensure that there is no downtime, we will ensure that the deployment only occurs on one machine at a time.

Depending on the type of solution being deployed there are a few additional attributes that you may have to specify to the Install-SPSolution command.

However the most important attribute we need to remember is the –Local attribute this will only ensure that the solution deployment will only occur on the local server.

Other attributes include:-

  • WebApplication – this will deploy the solution to a specific Sharepoint Web Application
  • GacDeployment – this option allows a solution which contains .NET assemblies to be installed in to the GAC to be installed.
  • CasPolicies – this option allows a solution which contains code access security policies for the assemblies / web parts to be deployed.

Once the Install-SPSolution command has been run then the solution deployment success needs to be checked. This can also be achieved using PowerShell.

   $checkSolution = Get-SPSolution $solutionname;   $checkSolution.LastOperationalDetails;  

When this has been executed an output such as the following will be displayed for the local server.

sharepoint_solution_lastoperationdetails

The process now has to wait until the SPSolution.LastOperationDetails call returns back that the deployment is successful.

Once the deployment has completed, I now restart IIS and the SharePoint Timer Job Service using the following PowerShell.

 Restart-Service sptimerv4;   iisreset;   

The installation of the SharePoint solutions will have caused IIS to restart and therefore the server will not have responded to the load balancer. Provided that the load balancer has been configured correctly the server should no longer be processing requests to clients and therefore there is no loss of service.

Depending on configuration of the load balancers, the time it takes for a server to start responding to requests will based on a setting called ramp up time.

The slow ramp up time is the time the load balancer will wait after the server has come back online before it starts sending all requests to the server. This gives the server time to get back on its feet and processing those requests.

Once the server is back online, the SharePoint solution process can be repeated for each of the other SharePoint Servers.

 

Deployment Gotchas

Although this approach will for most cases work there are a few gotchas that you need to watch out for. In some of these occasions all SharePoint WFEs will have their application pools restarted.

Currently these are:-

  • SPWebConfigModification – its a good practice to apply changes to the web.config files for an IIS Web Application using the SharePoint SPWebConfigModification object. This will ensure that any settings required in the web.config for your solution will be applied. This reduces the likelihood of an issue with the solution due to down to missing configuration. Also if new servers are added to the farm then their web.config files wil be setup correctly. This will save you lots of time if you ever have to do a disaster recovery exercise!
  • SharePoint Field Controls – if your solution includes a new custom SharePoint field. Then this will not be available until all SharePoint servers have been updated. This can be more of a problem when for example you are using something like Telerik’s RadEditor control and are performing an upgrade. When these type of deployments are being made then its best to inform the users that the application will not be available. At least the rest of the SharePoint farm is up and running!

Note: As more issues are found then this section will be updated.

Deployment Script

The final deployment script is as follows:-

  cd c:\install\[solutionname]\[versionnumber];   $curdir=gl;   $solutionname=”SolutionName.wsp”;   Add-SPSolution –LiteralPath $curdir\$solutionname;   Install-SPSolution –Local –Identity $solutionname –GACDeployment –CASPolicies;   $checksolution = Get-SPSolution $solutionname;   $checksolution.LastOperationalDetails;   

 

Finally

I hope that you find this useful and would love to hear about your experience and approach to deployment of SharePoint solutions.

Querying for Feature Upgrades error: The site with id cannot be found


Introduction

I am involved in a large project which is creating a large number of SharePoint webs. The webs content and configuration are being modified using Features and Feature Upgrades.

We are using PowerShell to process the Feature Upgrades using Chris O’Brien’s excellent SharePoint Feature Upgrade Kit.

One of the issues that we started to see during testing was when looking for Features which are scoped at the Site Collection using the SPWebApplication object’s QueryFeatures(SPFeatureScope, Boolean) function.

The following PowerShell was being used:-

$webapp = Get-SPWebApplication http://dev.itsp.local;
$webapp.QueryFeatures("Site",$true);

When this code was run in SharePoint 2010 Management Console the following error was displayed.

An error occurred while enumerating through a collection:
The site with the id f6f2e2bb-46bf-4c46-995e-65055512114e could not be found..
At line:1 char:22 + $webapp.QueryFeatures <<<< ("Site",$true); + CategoryInfo
: InvalidOperation: (Microsoft.Share...esultCollection:SPFeatureQueryResultCollection) [],
RuntimeException + FullyQualifiedErrorId : BadEnumeration

Investigation

Investigation started by looking at whether this error could be reproduced on other SharePoint environments which it could. Further testing was performed using different SharePoint builds including SharePoint 2010 Service Pack 1 and Cumulative Updates from June 2011 to December 2011.

The cause of the error seems to be when you have a site collection that has been deleted from SharePoint but had a feature that needs to be upgraded.

Looking in the Content Database for the Web Application revealed a entry in the AllSites table which looked like this:-

contentdb_deletedsiteentry

Reminder: Accessing the SharePoint databases is not supported by Microsoft and should not be performed in a production environment.

The row in the database has a column called Deleted which has a status of 1.

Using the Get-SPSite cmdlet the Site Collection could not be found. However, a colleague reminded me that there is a Get-SPDeletedSite. This returns back site collections that are found in the site collection recycle bin. The command returned a site collections that had been deleted a few weeks ago.

There is a function, Remove-SPDeletedSite but while this removes the site collection so it cannot be accessed via Get-SPDeletedSite, the error still occurs and the record is still found in the Content Database.

The issue seems to be down to the way that the SPWebApplication.QueryFeatures function works and does not filter the site collections which have been deleted and hence the error occurs.

Solution

Currently there is no fix for this issue that I am aware of. However, all is not lost and a workaround was possible by a few additional lines of PowerShell.

$webapp = Get-SPWebApplication http://dev.itsp.local;
$webapp.Sites | ForEach-Object {$queryFeatureResults += $_.QueryFeatures("Site",$true)};

This PowerShell command will enumerate through all the SPSite in the Web Application and call the same function but on each Site Collection. This gets around the problem with the QueryFeature() function finding the deleted site collection.

queryfeature-foreach-withresult

PowerShell to Detect Web Configuration Modification jobs


Introduction

Over the past few months I have been working on some automated SharePoint deployment scripts using Team Foundation Server and the TFS build service. As the development became more complex so did the scripts. One of the problems we had to work around was activating a number of features at the same time.

The deployment reinstalls five SharePoint solution packages, uninstalling and reinstalling all of the Features which are packaged in the solutions. Now some of these features perform custom tasks using feature receivers. For example making changes to the web.config using SPWebConfigModfications. However, one of the problems with modifying web.config using feature receivers is that if they are run on a multi server SharePoint farm then the modifications are performed using a timer job.

When you try and activate two features, one after the other, which perform the web configuration modifications you get the following error message:-

"A web configuration modification is already running"

This kills the deployment script!

Thus we needed to find a way to detect whether a web configuration modification job is in progress.

Understanding the process was made more dificult as the development machine was part of a single server SharePoint farm. With single server farms, when aa SPWebConfigModification is applied to a SPWebApplication then the modification is executed in a different manner and occurs immediately.

Anyway, after some digging about using Reflector I found an SPJobDefinition which looked like the web config modification timer job and say down and wrote the following PowerShell script.

Solution

To be able to detect whether a web config modification is running we need to see if a timer job is active.

The timer job that performs the web config modification has the name “job-webconfig-modification”.

To detect whether a web configuration is pending or running.  As web configuration operations occur against a web application. Therefore using the SPWebApplication’s SPWebService property which has two collections relating to the timer service:-

  • JobDefinitions – this contains the jobs that are pending to be run
  • RunningJobs – this contains the jobs that are currently running

Detecting whether a web configuration modification is in progress, we need to check those two collections for our “job-webconfig-modification” timer job.

The following PowerShell function, IsWebConfigModificationJobPendingOrRunning, is used to check whether a Web Configuration operation is taking place. The function takes a SPWebApplication as a parameter and returns true if the web configuration modification operation is running.

 


################################################################################################
#Function: IsWebConfigModificationJobPendingOrRunning
#Description: Checks to see if a web configuration job is pending or in progress
################################################################################################
function IsWebConfigModificationJobPendingOrRunning([Microsoft.SharePoint.Administration.SPWebApplication] $webApp)
{
Write-Host "IsWebConfigModificationJobPendingOrRunning() Enter";

$bRunning=$false;
try
{
$webConfigPendingJobCount = 0;
$webConfigRunningJobCount = 0;

#if there is only one job returned then array is not created
$webConfigPendingJobs = $webApp.WebService.JobDefinitions |
Where-Object {$_.Name -like "*job-webconfig*"};
$webConfigRunningJobs = $webApp.WebService.RunningJobs
| Where-Object {$_.Name -like "*Web.Config*"};

#if there is only one job returned then array is not created - check to see if an object has been returned
#check to see if its an array if not then presume its a job.
if($webConfigPendingJobs -ne $null)
{
if($webConfigPendingJobs.GetType().BaseType.Name -eq "Array")
{
$webConfigPendingJobCount = webConfigPendingJobs.Count;
}
else
{
$webConfigPendingJobCount = 1;
}
}

#if there is only one job returned then array is not created - check to see if an object has been returned
#check to see if its an array if not then presume its a job.
if($webConfigRunningJobs -ne $null)
{
if($webConfigRunningJobs.GetType().BaseType.Name -eq "Array")
{
$webConfigRunningJobCount = webConfigRunningJobs.Count;
}
else
{
$webConfigRunningJobCount = 1;
}
}

Write-Host "Found " $webConfigPendingJobCount " Pending Jobs and " $webConfigRunningJobCount " Running Jobs";
if(($webConfigPendingJobCount -gt 0) -Or ($webConfigRunningJobCount -gt 0))
{
$bRunning=$true;
}
else
{
$bRunning=$false;
}
}
catch
{
Write-Error "IsWebConfigModificationJobPendingOrRunning Exception: $_ ";
}

Write-Host "IsWebConfigModificationJobPendingOrRunning() Exit : $bRunning";
return $bRunning;
}

 

Example Script

The script below shows part of the deployment script. This would be used  to loop through an array of feature names, check their scope and activate them. The script waits until the feature has activated and checks that there are no web configuration modification jobs running.

$SharePointWebApp = Get-SPWebApplication "http://sharepoint";
$spfeature = "Feature1";

$checkspfeatureactivation = Get-SPFeature -WebApplication $SharePointWebApp
-Identity $spfeature -ErrorAction SilentlyContinue;

if($checkspfeatureactivation -eq $null)
{
Write-Host "Activating Feature: " $spfeature.Name " Scope: " $spfeature.Scope;
Enable-SPFeature -Identity $spfeature -Url $SharePointWebApp.Url -Confirm:$false;

#check that web config job mod not running, wait if it is
do{
Start-Sleep -Seconds 2;
Write-Host "Waiting for Web Config Job to be Completed";
$configJobRunning = IsWebConfigModificationJobPendingOrRunning $SharePointWebApp;
}while ($configJobRunning);

}
else
{
Write-Host "Feature Already Activated: " $spfeature.Name " Scope: " $spfeature.Scope;
}

 

I hope that helps someone who is having similar problems, I hope to add a bit more about the deployment process that I have been developing in later blog posts.

Please leave comments if you need any help or there are any problems.

Here are the actual PowerShell scripts as txt files.

Save typing when Manipulating SharePoint Solution Files in PowerShell


 

Introduction

 

One of the things that annoyed me with PowerShell and SharePoint are the following commands:-

  • Add-SPSolution
  • Update-SPSolution
  • Actually anything that requires a –LiteralPath parameter

Don’t get me wrong I think that using PowerShell to admin SharePoint is fantastic but these commands bug me because they require a full path to work correctly. Unfortunately you don’t seem to be able to use the full stop (or period) to represent the current directory.

So you cannot do something like this:-

Add-SPSolution .\mysharepoint.wsp;

Instead you need to do this:-

Add-SPSolution c:\thisisareallylongpath\release1\section2\mysharepoint.wsp

Solution

Anyway, that got me thinking surely there is a better way and I can save myself some typing.

The solution is to use the command Get-Location.

So instead you can do this:-

$curdir = Get-Location;
Add-SPSolution–LiteralPath $curdir”\mysharepoint.wsp”;

Actually there is a PowerShell Alias called gl which is a shortcut for the Get-Location command.

So the shortest version in terms of saving your typing fingers is this:-

$curdir = gl;
Add-SPSolution –LiteralPath $curdir”\mysharepoint.wsp”;

Really hope that helps save you some time, also love to hear any other alternatives, there is bound to be an even better way of doing this.