SharePoint 2013 Preview Unboxing Part 1

The SharePoint 2013 Preview was released today, and I have had an opportunity this evening to load it up into a virtual environment and check it out.  I conducted this task as a virtual unboxing, to experience the SharePoint 2013 Preview installation process.  I recorded a screencast of this unboxing, and have published this on YouTube to share:

I couple of the key notes include:

  • Read the hardware and software requirements guide on TechNet – there are some big requirements particularly around RAM.
  • The download for the server edition of SharePoint 2013 is over 2GB in size, about double the size of the SharePoint 2010 cumulative updates.
  • I had to restart a couple of times during the pre-requisite installer, not a huge issue.
  • I get to a point in Part 1 where I am about to load Central Admin and my new site collection, and the main troubles that I will show in Part 2 is around the performance of my virtual enviornment, with RAM and disk IO being major problems.

Overall, the process was fairly successful, and I will have second part to release soon which will show further details.

Unexpected error has occurred accessing /_layouts/termstoremanager.aspx

Came across an interesting issue in a test environment where our test user and I couldn’t access the Term Store Manager, and were getting the “unexpected error has occurred” message.

A quick look at the ULS logs showed the message:

System.InvalidOperationException: The Taxonomy feature (Feature ID "73EF14B1-13A9-416b-A9B5-ECECA2B0604C") has not been activated.

To find out the missing feature, I used PowerShell to interrogate it:

Get-SPFeature -Identity 73EF14B1-13A9-416b-A9B5-ECECA2B0604C

DisplayName                    Id                                       Scope
-----------                    --                                       -----
TaxonomyFieldAdded             73ef14b1-13a9-416b-a9b5-ececa2b0604c     Site

I couldn’t find the TaxonomyFieldAdded feature in the list of Site Collection Features in the browser (nor do I ever recall seeing it in the past). I went back to my friend PowerShell and tried:

Enable-SPFeature -Identity "TaxonomyFieldAdded" -Url http://testsite

A refresh of …/layouts/termstoremanager.aspx and the page loaded as expected.

Generate Multiple Views on SharePoint Lists or Libraries

I was having a weird problem with a list we had migrated, and one of the unusal characteristics was that this list had about 50 different views.

To try and replicate the issue with another list, I wanted to create 50 views very quickly.

Here is how I did it in PowerShell:

$w = Get-SPWeb
$l = $w.Lists["Documents"]
$maxViews = 50
for ($viewCount=0;$viewCount -lt $maxViews;$viewCount++)
	# $null prevents flooding the screen with view information
	# Clone Method Parameters: Name, Row Limit, Paged, Make Default View
	$null = $primaryView.Clone(($primaryView.Title + " " + $viewCount) , 30, $true, $flase)

The script worked like a charm in creating the views, however didn’t help me resolve the issue I had with my list.

Disable SharePoint Mobile View with PowerShell

A client recently had a request to disable the mobile view feature of SharePoint 2010. Fortunately, Jeremy Thake has written an excellent article on this already – How We Did It – Mobile View. We tested the second option and decided to go with that approach. The only problem was that I wasn’t keen on editing 10 web.config files.

Again, PowerShell comes to the rescue! I discovered that we could make web.config changes with the SharePoint object model, and therefore have all configurations updated at once. Special thanks to Farhan Faiz for his blog entry: SharePoint 2010: PowerShell script to add in web.config.

$webApp = Get-SPWebApplication
$configMod = New-Object Microsoft.SharePoint.Administration.SPWebConfigModification
$configMod.Path = "configuration/system.web"
$configMod.Name = "browserCaps"
$configMod.Sequence = 0
$configMod.Type = 0
$configMod.Value = "<browserCaps> </browserCaps>"
$configMod1 = New-Object Microsoft.SharePoint.Administration.SPWebConfigModification
$configMod1.Path = "configuration/system.web/browserCaps"
$configMod1.Name = "result"
$configMod1.Sequence = 0
$configMod1.Type = 0
$configMod1.Value = "<result type=""System.Web.Mobile.MobileCapabilities, System.Web.Mobile, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a""/><filter>isMobileDevice=false</filter>"

Broken Profile Pictures in My Site

I was presented with an interesting issue this week, when internally we were set to roll out My Sites across the organisation.  The only problem was, all the profile pictures were not displaying correctly on our profile pages.


The first thing to check was if the pictures existed correctly in the User Photos library ( and sure enough they were there.


When viewing the properties LThumb version, it was displaying correctly,


Interestingly, the URL on the properties of the image as:

Notice the “_w” – this appears to be a preview image, and not the image itself.  So back to the User Photos library to find the correct URL of the LThumb photo to be:

And when accessed in Internet Explorer, it renders as a broken image.


What is even more interesting is that the photo with the same URL works fine in Firefox (as well as Chrome and Safari)


A further test of the MThumb and SThumb versions of the photo render correctly in Internet Explorer.  At this point SharePoint is ruled out as being the issue, and it appears that Internet Explorer is having a problem with the pictures.

The next check is to compare the differences between the broken and working pictures.  A close examination of the original, LThumb (left) and MThumb (right) show the difference in the bit depth.


After opening and resaving the file locally on the file system, the file opened correctly in Internet Explorer.  These pictures were originating from Active Directory, and after a bit of digging around, we discovered that the guys uploading these pictures into AD had put them in as a GIF format with a reduced bit depth for getting them below 10KB in size (required for inserting the images into AD).  They had also saved them as a JPG before uploading them.

Strangely enough, Outlook and Lync were displaying these pictures without a problem.  What is even stranger is that the process SharePoint uses to create the medium and small thumbnails seems to have no problem either.  The Large version is clearly just a copy of whatever is being held in AD.

A colleague pointed out that it was probably a security feature of Internet Explorer that it detected that the file extension (JPG) was different to the header information in the file (GIF) and thus refusing to display it. 

This makes perfect sense, and once explained to the AD guys, they are  now busy re-converting everyone’s photos to the correct format.