Blog Archives

Word document properties in Record Center

Doing some work with a SharePoint 2010 Record Center and there is a curious omission.  SharePoint can read the properties of a Word document and pre-fill library column metadata.  These standard columns (Author, Keywords etc) work out of the box on any document library except for those created in the Record Center.

This had me scratching my head for a while, until I found this posting from Eric Schupps which explains that the Document Parser is switched off by default in Record Center.

To fix, a quick PowerShell script.

$site = Get-SPSite -Identity ""
$web = $site.OpenWeb()
$web.ParserEnabled = $true

BTW, it is worth following Eric Schupps, aka the SharePoint Cowboy as he is a regular speaker at SharePoint conferences and groups. Can’t miss him. Always wears a big ten gallon hat. I’m not sure which American state he is from, I think it might be Illinois.

Site Definitions not available in Powershell

Here is an interesting little quirk.  I was recently setting up some installation scripts which would roll in a Site Definition, then tried to create a Site Collection from the newly installed Site Definition.  And no matter what I tried, PowerShell would not see the newly installed Site Definition.

If I looked at the list of available Site Templates in the UI, the new Site Template was there and I could create it.

Thanks to Steve Clement on this one, as it seems there is some odd kind of caching going on.  The Powershell context only sees the SharePoint site template list at the point at which the object is created, which means our new site template does not appear.

Steve has a solution involving a new PowerShell plug-in which effectively recycles the SharePoint context.  I’ll have a play with that in a while, but for now, I split the process into two separate scripts, one which installs the solutions and the other which creates the Site Collection.

So, want to install a Site Template via PowerShell and create a Site Collection base don it in one single script?  Out of the box, it seems, you can’t.

Resizing Thumbnails in the Asset Library

Just been working on a project to create a searchable archive of images.  The SharePoint 2010 Asset Library features a very nice automatic thumbnail generation feature, which works even if the source file is something that a web browser doesn’t traditionally handle, like a .TIF.  The Asset Library also has a very nice preview feature, which is available if you upload an image and then rollover it with the mouse.

My idea was to present this thumbnail to the users when they were searching.  The images are scanned pages from books, so ensuring that they had the right page would be important.  Solution seemed obvious, present the auto-generated thumbnail as a sort of preview (the full sized image was far too big, and besides, would have a bandwidth overhead if I resized them.

The problem was that the thumbnails were, by default, quite small and the detail that the users needed to verify they had the right image was too small, so I wondered if it were possible to increase the default thumbnail size.

This being SharePoint, the answer is a) of course, b) tricky to find and c) really easy to implement.

First up, the Asset Library and the Picture Library are sort of the same, but not.  This post has some excellent pointers on the differences, especially if you are migrated.  However, the class we are dealing with is SPPictureLibrary.

SPPictureLibrary has several properties.  First off, you will immediately jump on ThumbnailSize.  This would be a mistake.  When you upload an image into an Asset Library, it shows a thumbnail preview.  The size of this thumbnail preview is determined by the ThumbnailSize property.

The Preview image shown by the rollover is not controlled by the ThumbnailSize property.  The preview size is controlled by two properties, WebImageWidth and WebImageHeight. By default for a picture library, these values are set to 320px and 200px respectively.  You can update the values using a console app or Powershell script – I’m not sure whether you could do it in a List Definition as I have’t tried it.  The following script will set the Preview to 1000px high or 750px wide, which ever is the smaller for the image.  I don’t think it scales images up if they are smaller than these parameters.

$url = "%YOUR_URL%"
$listName = "%YOUR_LIBRARY_NAME%"
$web = Get-SPWeb $url
$list = web.Lists[$listName]
$list.WebImageWidth = 1000
$list.WebImageHeight = 750

Try to keep the ratio between Width and Height to 4:3  (so 320/200, 640/400, 1000/750).  The standard Preview view on the mouse rollover will resize the image to keep within its internal boundaries and therefore won’t “break” any layout.

Migrating Master Pages from MOSS 2007 to SharePoint 2010

I’ve mentioned before that I am doing a complex migration from MOSS 2007 to SharePoint 2010 and I came across an absolute doozy of an issue over the last couple of days. I doubt anyone else will come across this, but it worth noting, if not just for my sanity, but also in case it crops up somewhere else.

The source 2007 site was a publishing site with a heavily customised Master Page. The Master Page containing some controls in it for navigation and so on – unfortunately the source code for these controls were written in Visual Studio 2005 and deployed, well, somehow. I rebuilt the controls in VS2010 and a nice WSP for deployment.

There remains the problem of getting it to work in the new environment. The old control would not work, giving the SharePoint Screen of Death. No problem, I don’t need it anyway. I copied the old 2007 Master Page, uploaded it into 2010 and worked on it with SharePoint Designer to run the new control. All is hunky dory.

Until we come to roll out. Plan was to do a migration via Attach Database, then put my new Master Page into the system, flip over to it and all is well.

The migration goes OK, the site pops up with the expected Master Page error, I go into SPD to upload the new custom MP, check it in, requires Approval so open the page in the browser and…

Error. The Approval page still uses the old, failing, MP.

I can change the MP using the GUI but I can’t flip it to the new Master page because it hasn’t been Approved and I can’t Approve it because that relies on a Master Page that fails.

OK, so off to Powershell I go and Approve the page in the back end. Back to the Change Master Page page and my custom MP either does not appear in the dropdown or gives me a warning that it is set for SharePoint v4 (2010) and not the v3 (2007) UI that we are keeping.

The problem is this. If you upload a Master Page to the Master Page Gallery, the UI Version is automatically set to v4 – SharePoint 2010. This is a problem if you are using the v3 GUI – either the new MP will not appear for selection and if it does, it is set to v4. You can’t change this because your Master Page is faulty and you can’t get to the List through the browser. The value is not available in SPD to change.

After a lot of faffing, the solution I found is this.

1. Using Powershell, change the MasterPage Url to default.master (or something other than your current MP, but still v3).
2. Go into the Master Page Gallery and edit the new custom Master Page item you added and set the UI Version to 3 (not both 3 and 4, but 3).
3. Back into Powershell and change the MasterPage Url to your new custom Master Page.

It will all work now.

The key fact to take away is that by default in SharePoint 2010, any Master Page uploaded to the Gallery is set to v4 even if your site is running as v3.

Quota Templates in Powershell

I’m currently working on a few migration type things and need to set up some quota templates.  The actual sizes of those templates is TBA, so I figure a set of quick Powershell functions will help me set them up as an when I need them.

The majority of the code is from Ryan Dennis at, though I believe he built on work from Gary LaPointe.  But then, doesn’t everyone?

function New-SPQuotaTemplate {
    This advanced function creates a new Site Quota Template.
    C:\PS>New-SPQuotaTemplate -Name "Custom" -StorageMaximumLevel 2GB -StorageWarningLevel 1GB -UserCodeMaximiumLevel 100 -UserCodeWarningLevel 75
    This example creates an SP Quota Template called Custom with a maximum size of 2GB and a warning size of 1GB. Sandboxed solutions are limited to 100, with a warning level of 75.
    C:\PS>New-SPQuotaTemplate -Name "Custom" -StorageMaximumLevel 4GB -StorageWarningLevel 3GB
    Name: New-SPQuotaTemplate
    Author: Ryan Dennis
    Last Edit: 4/27/2012
    Keywords: Quota Template, Quotas and Locks
	Modified By: Mike Landers, 02/04/2013
#Requires -Version 2.0
# Instantiate an instance of an SPQuotaTemplate class #
Write-Verbose "Instantiating an instance of an SPQuotaTemplate class"
$Quota = New-Object Microsoft.SharePoint.Administration.SPQuotaTemplate
# Set the Properties #
Write-Verbose "Setting properties on the Quota object"
$Quota.Name = $Name
$Quota.StorageMaximumLevel = $StorageMaximumLevel
$Quota.StorageWarningLevel = $StorageWarningLevel
$Quota.UserCodeMaximumLevel = $UserCodeMaximumLevel
$Quota.UserCodeWarningLevel = $UserCodeWarningLevel
# Get an Instance of the SPWebService Class #
Write-Verbose "Getting an instance of an SPWebService class"
$Service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
# Use the Add() method to add the quota template to the collection #
Write-Host "Adding the $($Name) Quota Template to the Quota Templates Collection" -foreground Green
# Call the Update() method to commit the changes #
Write-Host "Quota Template $Name added successfully" -foreground Green

function Get-SPQuotaTemplate {
 This advanced function retrieves a SharePoint Site Quota Template.
 C:\PS>Get-SPQuotaTemplate -Name "Custom"
 This example retrieves a SharePoint Quota Template called Custom in the current farm.
 This example retrieves all SharePoint Quota Templates in the current farm.
 Name: Get-SPQuotaTemplate
 Author: Ryan Dennis
 Last Edit: 5/10/2012
 Keywords: Quota Template, Quotas and Locks
$Templates = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.QuotaTemplates
if ($Name)
 $Templates | Where-Object {$_.Name -eq $Name}

function Remove-SPQuotaTemplate {
 C:\PS>Remove-SPQuotaTemplate -Name "Custom"
 This example removes a SharePoint Quota Template called Custom in the current farm.

$Templates = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.QuotaTemplates
$TemplateCheck = $Templates | Where-Object {$_.Name -eq $Name}
if ($TemplateCheck -ne $null)
   	Write-Host "`nFound Template $Name" -foreground Green
	$Service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
	$Template = $Service.QuotaTemplates[$Name]
	Write-Host "Deleting Template $Name" -foreground Green
	Write-Host "Template $Name deleted successfully`n" -foreground Green
    Write-Host "`nTemplate $Name does not exist, no changes made`n" -foreground Red

Disallowed Updates on creating a Web Application

Hit an unusual one when creating Web Applications on a Farm.  Despite having gone through the process without any problems on two other farms, one particular (existing) setup fell over on every single Web Application I tried to create.  It manifested itself in an IE unable to connect to server error, but when you go into General Settings the following error is shown.


Not entirely sure what the cause is, but the fix is quite simple.

Log onto the Central Admin machine using Remote Desktop Connection, open a SharePoint 2010 Management Shell and run the following script:

$w=GetSPWebApplication <%WEBAPPURL%>


You can now go into General Settings and carry on as normal.

Extracting WSPs from MOSS

Currently in the middle of a MOSS 2007 -> SharePoint 2010 migration and there is a lot of cruft in the existing configuration.  I think that a lot of it can be removed, but you never actually know until you have migrated successfully.  Since time is of the essence and I could waste of lot it rewriting WSP files and solutions that aren’t needed, it is much more useful to try extracting the existing solutions out of SharePoint.  I had done this many moons ago as part of an upgrade from SP1, but it required a Console App and some custom code.  Thankfully, the MOSS farm was on SP2 and the server had Powershell installed.  A swift Googling led me to the following Powershell script:

Start-Transcript "c:\wsp\transcript.txt"
$solutions = [Microsoft.SharePoint.Administration.SPFarm]::Local.Solutions;
foreach ($solution in $solutions) {
   $solution.SolutionFile.SaveAs("c:\wsp\" + $solution.Name);


Which works perfectly.  So massive hat tip to Ben Leach.

PowerShell is swiftly becoming one of the best things Microsoft ever did.