Author / Simon Doy

Unknown's avatar

Posts by Simon Doy

I am an avid SharePoint enthusiast who works as an Independent SharePoint Consultant based in Leeds, United Kingdom. I am one of the organisers of the Yorkshire SharePoint User Group in the United Kingdom. I have been designing and building SharePoint solutions since 2006.
by Simon Doy

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.

by Simon Doy

Introducing the SharePoint Cache Refresh Framework


 

Introduction

 

Although a SharePoint developer should try their best to use the tools that SharePoint provides inevitably the client will ask for something that needs some custom code! Over the last few years the customer has demanded that the code be fast, reliable and scalable.

When this happens one of the first things you start to think about is performance.  Hand in hand with performance is caching so that you can reduce the number of expensive operations.

However, when you cache data you get into scenarios where users make a change but they are not reflected immediately. The users then start complaining because the cache has become stale.

There are a few solutions:-

  • Restart IIS / OWS Timer Service to flush the cache (not practical)
  • Decrease the lifetime of the cache object (increase the number of expensive ops)
  • Use Cache Dependencies to flush the cache

The last option is the best as it supports options when data is being shared across multiple application domains however it doesn’t help when you have a number of servers in your SharePoint farm.

This is why I built the framework. The framework allows you to control the caching of objects across the SharePoint Farm.

The way it works is pretty straightforward and it comes with a small API to allow you to use it in your solutions.

 

Solution Overview

 

The framework is made of a few components:-

  • Cache Configuration SharePoint List to manage the configuration
  • Cache Configuration Refresh Timer Job to perform the cache update
  • Cache Configuration Manager – API to manage the Cache Refresh Configuration
  • Cache Refresh PowerShell Cmdlets to administrate the framework
  • Base Classes for Managing Configuration Objects

The way that the framework work is that an object is cached with a dependency to a particular file on the server’s file system. This uses .NET built in CacheDependencies which run a file watcher against the file. When the file being watched is modified a callback occurs and the cache item is removed from the HTTPRuntime.Cache.

The Cache Refresh Framework provides a method using SharePoint Timer Jobs to run a process which modifies these files across all SharePoint Servers in a farm. This flushes the object from the Cache on each of the servers in the farm so that next time they load the object it is loaded from the Data Access Layer / Storage Mechanism rather than the Cache.

The framework supports multiple cache profiles so that you can group objects to be refreshed together or target them differently.

The following section explains some usages and the process in more detail.

 

Usage

 

The framework can be used to allow caching of objects such as:-

  • Configuration items
  • Navigation items
  • XML elements
  • Plain Old C# Objects (POCO)
  • Data Transfer objects (DTOs)

A common example is:-

  • A user of the system makes a change to the configuration.
  • The SharePoint Application calls into the Cache Refresh Framework tell it to refresh a particular Cache Configuration
  • The Cache Refresh Framework gets the Cache Configuration and runs the timer job for that configuration on all servers in the SharePoint farm using the SharePoint Farm Timer Service.
  • Each server runs the actual job which modifies a file
  • The Cache Dependency picks up the change to the file and flushes the cache
  • The next time the application gets that object it get its from the data access layer rather than the cache.

SharePoint Cache Refresh Framework Diagram

 

 

Deployment, Configuration, How To Examples

 

The framework has been uploaded to Codeplex as the SharePoint Cache Refresh Framework Project and there are a number of guides which cover:-

These can be found in the Documentation Section

 

Finally

 

Currently the framework is an alpha release, so there might be some issues with it, so please don’t try it on your production environment without plenty of testing. There are some known issues and I will look to improve the framework and fix those issues as they are found. However, I am excited about getting the framework out there and getting feedback on it.

If you have any problems, or find bugs then report them on the SharePoint Cache Refresh Framework site using the Issue Tracker forum.

If you have any ideas for additional functionality then please add a Discussion item.

Finally, please let me know if you find it useful and how you have used it!

Thanks

Simon