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.

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!

Useful Visual Studio External Tools


Introduction

I have been meaning to document this for a while. Every time I set up a new machine I have to check the configuration of my Visual Studio external tools.

External Tools? If you don’t know what I am talking about then take a look at the image below.

image

Currently I have the following External Tools:-

  • Create GUID – this allows me to quickly get a new GUID when creating all those SharePoint resources, including Content Types, List Schemas, Feature Receivers etc.
  • Get Public Key Token – this uses the .Net Framework Signing Tool (sn.exe) to get the Public Key token, although with the new SharePoint tools in Visual Studio this isn’t needed so much there are always those odd occasions.
  • Get Full Assembly Name – This is used lots particularly when having to hack together various SharePoint Xml files or Entity Framework resource connection strings. I can’t take credit for this one, Sahil Malek – http://blah.winsmarts.com/2009-12-SharePoint_Productivity_Tip_of_the_day.aspx), did all the hard work.
  • Get IIS Web Application Information – This saves me so much time when debugging code especially, feature receivers, application page, web part code. The tool will display a list of all the Web Applications and there Process ID (PID).

Setting up the Tools

Create GUID Tool

First of all locate the Guidgen Tool which should be found in your Windows SDK folder. The path will depend on the Windows Version you are running, this one is for Windows 2008 R2. “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\”

  • The GUID Generator application can be found in the bin subfolder
  • Full Path: “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\guidgen.exe”
  • Now you have the path, fire up Visual Studio

clip_image002

  • Click Tools->External Tools
  • Click Add
  • Title: Generate GUID
  • Command: : “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\guidgen.exe”
  • Click Apply

clip_image004

When this tool is used then the following window will popup:-

clip_image006

Get Public Key Token Tool

This retrieves the public key token for the assembly that is associated to the file that is open in Visual Studio.

To setup the tool do the following:-

  • Get the Path to the SN.exe tool which is found in the .Microsoft SDK Path
  • “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe”
  • From Visual Studio
  • Click Tools->External Tools
  • Click Add
  • Title: Get Public Key Token
  • Command: : “C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe”
  • Attributes: -Tp $(TargetPath)
  • Check “Use Output Window”
  • Click Apply

clip_image008

When the External Tool is used then the following output will appear in Visual Studio’s Output Window

clip_image010

Get Full Assembly Name Tool

This tool is excellent and saves me lots of time when you need the full Assembly Name for all the numerous SharePoint development tasks.

The setup of the tool comes from Sahil Malek (http://blah.winsmarts.com/2009-12-SharePoint_Productivity_Tip_of_the_day.aspx).

  • Fire up Visual Studio
  • Click Tools->External Tools
  • Click Add
  • Title: Get Full Assembly Path
  • Command: PowerShell
  • Arguments: -command “[System.Reflection.AssemblyName]::GetAssemblyName(\”$(TargetPath)\”).FullName”
  • Check “Use Output Window”
  • Click Apply

clip_image012

The output for this tool is as follows:-

clip_image014

Get IIS Web Application Info

This tool is great for getting information on the Web Server Application Pools. This is great if you need to debug a particular Web Application Pool Process.

  • Fire up Visual Studio
  • Click Tools->External Tools
  • Click Add
  • Title: Get IIS WP Info
  • Command: “c:\windows\system32\inetsrv\appcmd.exe”
  • Arguments: list WP
  • Check “Use Output Window”
  • Click Apply

clip_image016

The Output for this tool is as follows:-

clip_image018

Conclusion

I hope you find some of those tools useful, I would love to hear about any that you use.

Creating List Instance: Object Reference not set to an instance of an object


Introduction

This one is a bit of an old issue but some of my posts are just to remind me of a time that I got stuck in the past. Also if it helps someone else then great.

It is possible to create a feature which creates an instance of a SharePoint List when its activated. However, sometimes you only want a list to be created on the Root Web of a site collection.

Issue

Well the XML for specifying a ListInstance as a feature has an attribute called RootWebOnly which I thought I could use to only allow the ListInstance to be created on the RootWeb.

Unfortunately when you do that you get a message like the following in your SharePoint ULS Logs when the feature is activated:-

Feature Activation: Threw an exception, attempting to roll back. Feature ‘FeatureName’(ID: ‘xxxxxxxx-xxxx-xxxx-xxxxxxxx). Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.SharePoint.SPListInstanceElement.ElementActivated(SPFeaturePropertyCollection props, SPSqlCommand sqlcmdAppendOnly, SPWebApplication webApp, SPSite site, SPWeb web, Boolean fForce)
at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionListInstances(SPFeaturePropertyCollection props, SPSite site, SPWeb web, Boolean fForce)
at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionElements(SPFeaturePropertyCollection props, SPWebApplication webapp, SPSite site, SPWeb web, Boolean fForce)
at Microsoft.SharePoint.SPFeature.ProvisionElements(SPFeaturePropertyCollection props, SPWebApplication webapp, SPSite site, SPWeb web, Boolean fForce)
at Microsoft.SharePoint.SPFeature.Activate(SPSite siteParent, SPWeb webParent, SPFeaturePropertyCollection props, Boolean fForce)

The offending Feature ListInstance element is below:-

 1: <?xmlversion="1.0" encoding="utf-8"?>
 2: <Elements
 3: xmlns="http://schemas.microsoft.com/sharepoint/">
 4: <ListInstance
 5: Id="AListId"
 6: Title="A List"
 7: Description="A List 
 8: Description”
 9: Url="Lists/ListUrlHere"
 10: OnQuickLaunch="FALSE"
 11: RootWebOnly=”TRUE”
 12: FeatureId="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx"
 13: TemplateType="45100"></ListInstance>
 14: </Elements>

Solution

To fix the feature activation remove the RootWebOnly=”TRUE” from your ListInstance element manifest file and instead move the RootWebOnly=”TRUE” into your List’s schema.xml.

To ensure that the list is only provisioned at the root web of the site collection change the Feature.xml to use Scope=”Site”

Update:

Thanks to Dennis who picked up my mistake in this post which stated that the RootWebOnly attribute should be moved to the feature.xml.

Issue with Updating SharePoint Publishing Page Layouts and Ghosting


Introduction

This post has come about due to some challenges when upgrading a publishing site page layout.

Before we delve into the issues I best explain how the Page Layouts are setup. The page layouts are all contained within a feature called “Company.Intranet.Publishing” which are deployed to the folder:

SharePointRoot\Template\Features\Company.Intranet.Publishing\PageLayouts.

Each of the page layouts are deployed into the master page gallery (/_catalogs/masterpages) using a Module. The page layouts are deployed as uncustomised or ghosted files.

The fact these resources are deployed as ghosted files is very important as you will see in the next section.

Finally the feature is deployed using the SharePoint Solution framework as a single SharePoint WSP using WSP Builder.

What do you mean by Ghosted / UnCustomised files?

There has been quite a lot of information published about this and the following are good resources:-

My understanding is that a ghosted file is where the binary content is actually stored on the file system of the server and a pointer to that binary content is held in the content database. If a user modifies the content of a page layout in a site collection by a tool such as SharePoint Designer then a copy of that binary content is taken from the file system and merged along with the changes made by the user and stored in the content database.

Hence when you retrieve an uncustomised file its binary content is being pulled from the content database.

Why are Ghosted / Uncustomised files preferred?

Recently at the SharePoint Best Practices conference, Eric Shupps and Rob Foster did a great presentation on Fine Tuning and Optimising SharePoint Performance. One of the key points in improving performance is to ensure that files are ghosted/uncustomised for the following reasons:-

  • Ghosted files all point to a single file and hence they all point to the same binary content. This means only one file needs to be cached and the load on the database is significantly reduced.
  • Actually Unghosted files cannot be cached within a BlobCache. Unghosted files are therefore slower to load and render (10% slower on average) than a ghosted file.

Upgrading Page Layouts

The method used to upgrade page layouts is simply by redeploying the files through an updated wsp solution file. We have also been careful through training and guidance with users to ensure that page layouts are not edited through SharePoint Designer.

Therefore if a change to a page layout is required, then the page layout is updated within the feature directory using Visual Studio and the WSP solution file is rebuilt.

The solution is then ready to be updated using the command:-

stsadm –o upgradesolution –filename [solutionname.wsp] –name [solutionname.wsp] –allowgacdeployment –allowcaspolicies –immediate

The change to the page layout is then reflected within the SharePoint site.

Why are my changes are not seen?

More history, our last deployment required that we tidied up the page layout’s title and description.

One of the problems with using a Module to deploy files within a feature is that with SharePoint 2007 it is difficult to make changes to existing files deployed by a module without resorting to code. Any changes to the filenames or properties that are deployed by the Module are not reflected until the file is deleted from the site collection.

As there were not that many site collections, we took the decision not to write any code and we modified the page layout titles and descriptions through the SharePoint UI.

Unfortunately when we did our next release into our testing environment the changes to the page layout markup were not seen within the site.

After checking that the page layouts were being deployed correctly to the the WFE’s file system we started thinking of the reason. Finally I thought it must be due to unghosting of the files.

Normally you can use SharePoint Designer to revert page layouts to their site definition. So I fired up SharePoint Designer and browsed to the /_catalogs/masterpages document library but could see that the Page Layouts were not customised.

I started to search for tools to find out which files are customised. The legendary Gary LaPointe (@glapointe) came to the rescue.

If you don’t deploy Gary LaPointe STSADM tools on your Production/UAT environments then I plead with you that you start to do so as soon as possible. Time and time again I have been in a bind and Gary’s STSADM commands have got me out of trouble.

The commands that saved the day this time are:-

The commands give a lot of flexibility, though I will warn you that you need to be a bit careful as you could quickly reghost all the files within your site collection if you are not careful.

I performed the following command:-

stsadm –o gl-enumghostedfiles –url http://sharepointsite.domain.com/

This displayed a list of files that were unghosted. Funnily enough all the page layouts that we had modified and changed their Title and Description fields had become unghosted!

Once we had a list of the unghosted page layouts we could reghost each of them in turn using the command:-

stsadm –o gl-reghostfile –url http://sharepointsite.domain.com/_catalogs/masterpage/RandomPageLayout.aspx –Scope File

This command would reghost each of the files, there were occasions where the page layout reghosting would fail, using the –force option for the gl-reghostfile would ensure that the page was ghosted.

Now looking at the site the page layouts had been updated and reflected the changes that had been deployed by the update solution.

Hope that helps!

Unable to create a page based on a Publishing Page Layout


Introduction

This issue reared its head a few weeks ago. One of my clients has a pretty heavily customised Intranet which uses custom site definitions with feature stapling etc.

I have advised them to use separate site collections to help keep their site collections secure but with the main advantage being that they can use separate content databases for each site collection. This is to help ensure that they don’t get large 100Gb databases and issues with SQL Server locking.

Anyway, recently we started seeing an issue where the various contributors to the site (who were not site collection admins) could not create a page using the normal site settings->create page.

They had contribute rights but would get the error message:-

“The list does not exist”

 

Solution

So I started thinking about what the problem could be. The list does not exist message was being displayed before a page has been created and as soon as the user clicked Site Settings->Create a Page.

When you create a page you get a list of page layouts to choose from. So that brought me to checking that the master page gallery was there. I thought maybe someone had deleted the list or a feature had not been activated properly.

The list was there but no permissions were set, ah I thought that will be it.

I added the [Site Name] Members and [Site Name] Owners groups giving the Owners group Contributor permissions and the Members group Reader permissions.

The users could now create page successfully.

The reason that the problem was happening is that as part of the site collection creation process the content managers were being good and cleaning up the unused out of the box publishing SharePoint groups.

These groups include the following:-

  • Approvers
  • Designers
  • Hierarchy Managers
  • Quick Deploy Users
  • Restricted Readers
  • Style Resource Readers

However, this process was removing all the permissions from the master page gallery and hence any users who which were not site collection admins could not access the list.

The next step to this solution is write a Feature Receiver to clean up the SharePoint groups and clean up the permissions, this should help make things easier and ensure that users can start using the site as soon as its setup.

That will have to wait for a further blog post though.