Your ads will be inserted here by
Easy Ads.
Please go to the plugin admin page to set up your ad code.
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.
Your ads will be inserted here by
Easy Ads.
Please go to the plugin admin page to set up your ad code.
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.
Your ads will be inserted here by
Easy Ads.
Please go to the plugin admin page to set up your ad code.
Please note this can also be “fixed” by going to SharePoint 2010 Central Administration > Application Management > Manage Web Applications. Select the row of your web application. Click General Settings in the ribbon. Scroll down to Browser File Handling and select Permissive. Click Ok
However, if you don’t want to change that setting for security concern reasons, you can just update the MIME options for the file extension “png” or the file that is messing with your conversion of JPEG. Under the powershell SharePoint management an as administrator you would run something like this:
$webApp = Get-SPWebApplication “http://YOURSITE.domain”
If ($webApp.AllowedInlineDownloadedMimeTypes -notcontains “application/png”)
$webApp.AllowedInlineDownloadedMimeTypes.Add(“application/png”)
$webApp.Update()
You can always have your AD team to update the pictures in AD like this blog suggests (which is the root cause) but in our case with thousand of users in AD and with processes that cannot be changed it made more sense to adjust the application to the business process and not the other way around.
Good luck!