SharePoint | Peter Heydon ~ Personal Space

The failed SharePoint blog experiment

It is almost a year since I launched my dedicated SharePoint blog, www.HeySharePoint.com. Alas, I had strong momentum for about six months but was unable to gain traction. I don’t want to use the term “competitive”, but there are a lot of people blogging about SharePoint. This is not a bad thing, as it shows the strength of the community behind this great product. It just makes it harder to get heard.

One of what I thought would be a great drawcard to HeySharePoint.com would be a weekly newsletter aggregating the top Tweets of the week for SharePoint. I tried to promote this as best I could but couldn’t obtain lift off. In the last few months Twitter has updated their API, completely breaking my interface which collated the data. I do intend on bringing this back and making it available on this site, however won’t be publishing it on a weekly basis as I was on HeySharePoint.com (you can see a sample of the results over there). If anyone would be interested in receiving a weekly email, please leave me a comment on this post.

So, I have decided to indefinitely halt any further work on HeySharePoint.com, but will leave the content there for as long as I can. I intend to get back into blogging, however I have had a slight career shift, now focusing on a SharePoint pre-sales role that I am really excited about. I intend to write from a less technical perspective as I have in the past, and add less SharePointy stuff as well.

For everyone who has left their kind words and found this blog to be useful, thanks for your readership, and I hope that you find future content as equally as helpful.

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 http://portal.company.com
$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 http://portal.company.com
$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=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a""/><filter>isMobileDevice=false</filter>"
 
$webApp.WebConfigModifications.Add($configMod)
$webApp.WebConfigModifications.Add($configMod1)
$webapp.Update()
$webapp.Parent.ApplyWebConfigModifications()
$webapp.WebConfigModifications.Clear()

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 (http://mysite.company.com/User%20Photos) 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:
http://mysite.company.com/User%20Photos/Profile%20Pictures/_w/DOMAIN_pheydon_LThumb_jpg.jpg

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:

http://mysite.company.com/User%20Photos/Profile%20Pictures/DOMAIN_pheydon_LThumb.jpg

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.