Why do I see two copies of my Custom List Instance in a SharePoint Site?


Introduction

 

Over my years in SharePoint development I have had the following issue occur.a couple of times.

Actually back in July 2010, I posted a blog entry which solved a problem with the Manage Content and Structure page which was related to duplicate lists in a site.

  • I create a custom List with a customised List Definition which uses a schema.xml to define the List Template
  • I create a Feature which uses the customised List Definition to create a new List Template with the <ListTemplate> feature element.
  • I configure the feature to create an Instance of the list using the <ListInstance> feature Xml element,
  • Activate the feature in a SharePoint Web, click Site Actions->View All Site Content.
  • Two instances of the list appear in the View All Content page, both reference the same SharePoint list.
    Figure below shows an example of two duplicate lists in the web.
    duplicatelistitemsinweb

 

I have then always wondered what causes this?

What is interesting is that one link points to one view and the other link points to a different view, this hint was the lead to help solve the issue.

 

Solution

 

I started the investigation by digging into the SharePoint databases now quick warning, “you should not read or edit the database, doing so will leave your SharePoint installation unsupported by Microsoft!”

However, I was very careful and did not make any changes to the database.

It was one of the tables that lead me to working out why I was having these duplicate links. This table was the BuildDependencies table. I performed a

SELECT TOP 1000 [SiteId]
      ,[DirName]
      ,[LeafName]
      ,[TargetDirName]
      ,[TargetLeafName]
      ,[DirectDependency]
      ,[DeleteTransactionId]
  FROM [BuildDependencies]
  Where [DirName] LIKE ‘sites/sitename%’

Looking through the results I could see that the list had two views one called ‘ByFeatures.asppx and the other ‘AllItems.aspx’

This was correct my List Schema had defined these two views and then it dawned on me, what if SharePoint is looking at the schema.xml to work out which list page to display in the View All Content page.

So I went into my schema.xml and low and behold there was an attribute on the <View> element called DefaultView. Now both the AllItems.aspx and ByFeatures.aspx had this set to TRUE.

listschema-defaultview

 

Eureka!

So to fix this I followed this process:-

  • Updated the schema.xml <View/> element for the AllItems.aspx view
  • Modified the DefaultView attribute and set it to FALSE
  • Redeployed the solution
  • Perform an IISRESET
  • Deactivate the Feature
  • Delete the list
  • Activate the Feature to create the list

Now I only see one instance of the list in the View All Content page.

However, there is a problem with this approach and that is you lose the data in the list!

 

To Fix Existing Lists with No data loss

So we need a way to fix the lists that have already been created, seeing as the existing lists are not fixed by the schema changes then these properties must have been copied into the content database.

So to fix existing lists do the following:-

  • Browse to the list and open up the List Settings page using the Ribbon
  • Create a new View call it what you want, make sure you set it to default
  • This will reset the Default View attribute on the other views and make the new view the default view.
  • Modify the view that should really be the default view and tick the make default view checkbox. (This doesnt appear if you have multiple views with the default view set).
  • Update the view
  • Delete any views that are not needed

You should now see only one list instance in the View All Site Content page!

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.

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

Feature Upgrade Issue: Deleted SPWebs : An error occurred while enumerating through a collection


Introduction

Recently I published a post about issues when upgrading Site Scope features in SharePoint. The issue was related to deleted Site Collections which were still in the recycle bin.

After resolving this issue I decided to do some testing with other deleted SharePoint objects. The next logical object type to delete was an SPWeb object.

Unfortunately further issues were found and the following section explains how they were found and the approach to resolve them.

 

How the Issue was Approached

The approach taken was the following:-

  • Build a Web Scoped Feature marked v1.0.0.0
  • Install the SharePoint Solution
  • Create a number of Webs and Activate the feature on those webs
  • Delete one of the Webs
  • Update the Web Scoped Feature to v2.0.0.0
  • Upgrade the SharePoint Solution to deploy the new version of the Web Scoped Feature
  • Use Install-SPFeature [FeatureName] –Force to upgrade the feature
  • Run a PowerShell command to execute the SPSite.QueryFeatures() function

The following PowerShell was run to query for Features that need to be upgraded.

 $site=Get-SPSite http://sharepoint; $site.QueryFeatures("Web", $true); 

The result of the script displayed the following:-

 $site.QueryFeatures("Web",$true);  An error occurred while enumerating through a collection: Unable to access web scoped feature (Id: f41cc668-37e5-4743-b4a8-74d1db3fd8a4) because it references  a non-existent or broken web (Id: 3bd828cf-b747-4111-b888-5953b0d9aaa3) on sit e 'http://dev.itsp.local'.  Exception: System.ArgumentException: Value does not  fall within the expected range.    at Microsoft.SharePoint.SPWebCollection.get_Item(Guid id)    at Microsoft.SharePoint.SPFeatureEnumeratorBase.GetCachedWeb(SPSite site, Gu id webId, Guid featureId). At line:1 char:20 + $site.QueryFeatures >> ("Web",$true)     + CategoryInfo          : InvalidOperation: (Microsoft.Share...esultCollec    tion:SPFeatureQueryResultCollection) [], RuntimeException     + FullyQualifiedErrorId : BadEnumeration 

 

Solution

The approach to solving this issue was not to write a workaround but to run a script which checks for deleted SPWeb objects in the site collection.

 $site = Get-SPSite http://sharepoint; $site.RecycleBin | ?{$_.ItemType -eq "Web"}; 

The script will display the SharePoint Web Objects that have been deleted and are still found in the site collections recycle bin.

The deleted SPWeb objects can be removed from the recycle bin using the following PowerShell command.

 $site = Get-SPSite http://sharepoint;  $deletedWebs = $site.RecycleBin | ?{$_.ItemType -eq "Web"}; $deletedWebs | % {$site.RecycleBin.Delete($_.Id)} 

This will delete the SPWeb objects from the recycle bin and the Feature Upgrade process can continue.

Please be careful when running this script! Only run it when you know that none of the SharePoint Web sites are not needed!

 

Anyway hope that helps!

Content Subscriber Timer Job Error “A content type failed to be syndicated: System.Xml.Schema.XmlSchemaValidationException”


Introduction

We are using SharePoint’s Managed Metadata Service Application’s Content Type Hub model to manage the Content Types and Site Columns.

I’d highly recommend the following Technet Article for more information, Plan to share terminology and content types

Anyway, the approach to adding new metadata to the Content Types is using Feature Upgrading which has been interesting and has caused a few problems, which I have blogged about in the past.

Whilst researching the different options for the upgrade process I stumbled over a problem when using PowerShell to add a field to the Site Collection. This problem really only appears when you are using the Field within a Content Type that is being published to other site collections as part of a Content Type Hub.

The PowerShell worked and the Site Column was successfully created using the method. SPFieldCollection.AddFieldAsXml() function. However, when it came to pushing the changes out to the other site collections using the Managed Metadata’s Content Type Subscriber timer job the following errors were logged to the SharePoint ULS Log:-

  • “The element ‘FieldTemplate’ in namespace ‘urn:deployment-manifest-schema’ has invalid child element ‘Field’ in namespace ‘http://schemas.microsoft.com/sharepoint/’. List of possible elements expected: ‘Field’ in namespace ‘urn:deployment-manifest-schema’.”
  • “Received an error message from import: The element ‘FieldTemplate’ in namespace ‘urn:deployment-manifest-schema’ has invalid child element ‘Field’ in namespace ‘http://schemas.microsoft.com/sharepoint/’. List of possible elements expected: ‘Field’ in namespace ‘urn:deployment-manifest-schema’.. The recommendation is:”
  • “A content type failed to be syndicated: System.Xml.Schema.XmlSchemaValidationException: The element ‘FieldTemplate’ in namespace ‘urn:deployment-manifest-schema’ has invalid child element ‘Field’ in namespace ‘http://schemas.microsoft.com/sharepoint/’. List of possible elements expected: ‘Field’ in namespace ‘urn:deployment-manifest-schema’.    “

Investigation

The investigation started by looking at the process of adding the field to SharePoint.

The process being used is as follows:-

  • Load a SharePoint Elements file which has fields defined in it.
  • An example of the element.xml file is shown below
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

<Field ID="{38384FAD-5BF2-42D6-9243-5BE95F17E5FD}" Type="Text" Name="ITSPFieldName" StaticName="ITSPFieldName" DisplayName="iThink SharePoint Field" Description="Field does something" Group="iThink SharePoint Site Columns" />

</Elements>

 
  • Load the file into PowerShell using the Get-Content Cmdlet
  • Get a reference to the Content Type Hub using Get-SPSite
  • Get the <Field /> element
  • Add a field using the <Field />element and the Site Collection’s Root Web Fields property and AddFieldAsXml() function

Here is a snippet of the PowerShell script that was being executed to do the above:-

$contenttypehub = Get-SPSite -Identity http://sharepoint/hub;
[xml]$elementFile = Get-Content .\myelement.xml;
$fieldXml = $elementFile.Elements.Field[0];
$addedFieldName = $contenttypehub.RootWeb.Fields.AddFieldAsXml($fieldXml.OuterXml);
if($addedFieldName -ne $null)
{
Write-Host "Added Field with InternalFieldName: " $addedFieldName;
}
else {
Write-Warning "Failed to Add Field with Xml: " $fieldXml.OuterXml;
}

Once the script has run then the field is created and is available for assigning to the Content Type. The field is added to the Content Type successfully. However as mentioned previously when the Content Type Subscriber Hub Timer job is run then the errors are displayed about the Field’s SchemaXml .

So what’s going wrong?

Well after examining the Field’s SchemaXml property, I could see the issue.

The field’s schema was displayed using the following script:-

$fieldName = "FOSScannedDocumentId";
$contenttypehub = Get-SPSite -Identity http://sharepoint/hub;
$checkField = $contenttypehub.RootWeb.Fields | ?{$_.InternalName -like $fieldName};
$checkField.SchemaXml;

The output of the command showed the Field’s Schema Xml had an added Element as shown below:-


<Field ID="{38384FAD-5BF2-42D6-9243-5BE95F17E5FD}" Type="Text" Name="ITSPFieldName" StaticName="ITSPFieldName" DisplayName="iThink SharePoint Field" Description="Field does something" Group="iThink SharePoint Site Columns"  xmlns="
http://schemas.microsoft.com/sharepoint/" />

So what was happening, well PowerShell is being well behaved and adding the namespace attribute from the parent <Elements> node to this child node. Unfortunately SharePoint is not expecting this additional attribute as part of the Field’s SchemaXml and it causes the validation of the Xml to fail. Hence the XmlSchemaValidationException.

Solution

The solution was to modify the string being passed into the AddFieldFromXml() function.

This was achieved by modifying the script to remove the xmlns attribute :-


$removeNamespaceString = 'xmlns="http://schemas.microsoft.com/sharepoint/"';
[xml]$elementFile = Get-Content .\myelement.xml;
$fieldXml = $elementFile.Elements.Field[0];
$fieldXmlString = $fieldXml.OuterXml.Replace($removeNamespaceString, "");
$addedFieldName = $contenttypehub.RootWeb.Fields.AddFieldAsXml($fieldXmlString);

This script will find the string with attribute name of xmlns and replace it with a blank string.

Now, when the Field is added using this fixed version of the <Field/> element the Content Type Subscription timer job completes successfully!

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 &amp;amp;lt;&amp;amp;lt;&amp;amp;lt;&amp;amp;lt; (&amp;quot;Site&amp;quot;,$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 &quot;IsWebConfigModificationJobPendingOrRunning() Enter&quot;;

$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 &quot;*job-webconfig*&quot;};
$webConfigRunningJobs = $webApp.WebService.RunningJobs
| Where-Object {$_.Name -like &quot;*Web.Config*&quot;};

#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 &quot;Array&quot;)
{
$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 &quot;Array&quot;)
{
$webConfigRunningJobCount = webConfigRunningJobs.Count;
}
else
{
$webConfigRunningJobCount = 1;
}
}

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

Write-Host &quot;IsWebConfigModificationJobPendingOrRunning() Exit : $bRunning&quot;;
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 &quot;http://sharepoint&quot;;
$spfeature = &quot;Feature1&quot;;

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

if($checkspfeatureactivation -eq $null)
{
Write-Host &quot;Activating Feature: &quot; $spfeature.Name &quot; Scope: &quot; $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 &quot;Waiting for Web Config Job to be Completed&quot;;
$configJobRunning = IsWebConfigModificationJobPendingOrRunning $SharePointWebApp;
}while ($configJobRunning);

}
else
{
Write-Host &quot;Feature Already Activated: &quot; $spfeature.Name &quot; Scope: &quot; $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.