PDF – The White Pages

Adding PDF Icon or Creating a Site From Template triggers Prompt for Download In SharePoint 2010

Published October 5, 2010

In a previous article, I wrote about the fact that with Microsoft SharePoint 2010, the default behaviour for handling PDF files is to prompt for download instead of opening them directly in the browser. In it, I mentioned how to change this behaviour, both at the application level, and where necessary at the library level.

I recently ran into a case where neither approach fixed the problem. SharePoint continued to prompt for download even though the BrowserFileHandling property was set to permissive at both the application and at the library level. I registered a support call with Microsoft and was told that they’ve seen this, and were working on it, and there was no expected date for an answer.

I decided to do some further experimenting, and found that I was actually running into two different things that caused this. The environment had both, so it made troubleshooting a real treat.

1. Adding the PDF icon to the front end server causes prompting for download

It’s been standard procedure since SharePoint 2007 to manually add in the PDF icon to display PDF documents, as described here. Every time that I do so, SharePoint starts prompting for download instead of opening in the browser. I as yet have no idea why,but it’s repeatable. UPDATE – This has been solved – see below.

2. Creating a site from a custom site template causes prompting for download

With the PDF icon uninstalled,the browser behaviour is correct on all sites in the site collection. If you then create a site template from an existing site with a library, and then use that template to create a new site, you will experience the prompting behaviour on any documents saved to that library. This is NOT true for any new libraries created in the site. You can also run the PowerShell script that I previously posted to reset the properties of the libraries, and they will behave properly.

For the record, the environment that I was working on this problem with was Search Server Express 2010, which is essentially the same as SharePoint Foundation plus the Search features from SharePoint Server.

Both of these problems are quite annoying, and I suspect I’ll be updating this post as I learn more, or as I hear back from Microsoft.

UPDATE

I’ve put together a solution that can be installed on a farm and activated at the site collection level. It’s essentially an event receiver that fires whenever a new web (subsite) is created and it sets all of the lists to Permissive. It works fine for me, and for at least one customer, and I provide it to you here with no warranties express or implied…. If anyone is interested in the code, let me know, but it’s only about 5 lines.

UPDATE – OCT 15 2010

The pdf icon problem has been solved. I’ve been back and forth with Microsoft on this and we wound up exchanging DOCICON.XML files. They sent me back one that worked, and the suggestion was that I change the icon file name to pdf16.gif to accommodate it. However, I noticed that there was an additional attribute in their file, OpenControl=””. I added that to the Mapping tag for my PDF extension, did an IISReset, and the problem was solved. For the record, the complete tag will look like:

With pdf16.gif being whatever the name of your pdf icon file is.

Microsoft also confirmed the problem with the custom site templates that I created the solution for above. It’ll have to do until a fix is available.

UPDATE – JAN 3 2011

Reader Christoffer von Sabsay has notified me that this bug has been fixed in the December 2010 Cumulative Update Pack for SharePoint Foundation. For a list of the fixes in this CU, and to request them, go to http://support.microsoft.com/kb/2459108. My event receiver workaround should NOT be required after applying this and you should remove it upon doing so.

20 Comments

How to Index PDF Files with SharePoint Foundation 2010

Published September 23, 2010

SharePoint uses iFilters to index its files. Filters for most common file types are included out of the box with most versions of SharePoint. The big notable exception is an iFilter for PDF files. This is because Adobe won’t let Microsoft redistribute any of their code. It’s so bad that Microsoft can’t even include a PDF icon with SharePoint, you have to go out, download it, and set it up yourself. This has been true since the early days of SharePoint.

One of the things that you must do when you configure SharePoint to index PDF files is that you must tell the indexer that PDF is a valid file type. That’s easy enough to do from within the Shared Service Provider (for 2007) or the Search Service Application (for 2010), but the free versions of SharePoint, WSS and SharePoint Foundation don’t come with these tools.

It has always been possible to do this with WSS with a little bit of registry editing (and it’s supported by Microsoft), but that’s no longer true with SharePoint Foundation. That hack just doesn’t work with it. So what’s the answer? Well, as it turns out, the solution isn’t just adequate, it’s quite a bit better. The solution is to Install Search Server Express 2010.

Search Server Express is pretty simply a (only slightly) scaled back version of the Search Service applications that you get when you install SharePoint Server 2010. They are virtually the same architecturally and you get many of the features that you get with Server 2010. You also get a few other SharePoint Service applications, most notably, the Secure Store Service. And if you’re a Foundation user,it aligns up with your licensing agreement because it’s free.

So essentially,you get a much better search engine, with more capability for free. I can’t see a down side here. You don’t already need Foundation installed to install SSE, so in the future, whenever called upon to install SharePoint Foundation, I’ll be going straight to Search Server Express.

6 Comments

Opening PDF Files in SharePoint 2010

Published May 14, 2010

If you’ve installed SharePoint 2010, you may have noticed a change in behaviour of any PDF files that you may have stored. Previously, they would open directly in the browser, but now the user is prompted to save the file to the disk. This is due to a new security feature in IE8 that SharePoint 2010 respects. In order to allow the old behaviour, you must set the browser file handling options to “permissive” as opposed to “strict”.

This change is done at the application level. First, navigate to Manage Web Application within Central Admin, select the application in question, and choose General Settings on the ribbon.

Once in the settings screen, scroll down and find the section for Browser File Handling, and change it to permissive.

It goes without saying that this is less secure, but if you trust your PDF files, you should be good to go. Of course,as always,no warranties, express or implied…

Thanks to Mike Hacker’s Blog where I originally came across this.

UPDATE – SEPT 7 2010

I just ran across a case where this does not fix the problem. PDFs and all file types including HTML were prompting the user for download. This was not consistent, as it was happening in some libraries and not others. As it turns out, it’s a bit of a bug, and document libraries will not always inherit the browser handling attribute.

You can test this by running the following Powershell:

$site = Get-SPSite(“https://mysitecollection")
$web = $site.OpenWeb("/MyWeb")
$list = $web.GetList("https://myweburl/LibraryName")
$list.browserfilehandling

If it returns “Strict”, then you have a problem. The good news is, you can set it:

$list.browserfilehandling = “Permissive” ;
$list.update();

You should probably loop through your entire site collection and set this value to be safe. The powershell to do this can be found on Nerdtastics Tips, which is where I found the fix in the first place.

UPDATE – SEPT 10 2010

As opposed to hunting through your sites to find the problems, I wrote the below PowerShell script that take the URL for the site collection as an argument, and sets the permissive flag on any lists set to strict.

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
$siteURL = $args[0]
$webname = $args[1]
$site = Get-SPSite($siteURL)

foreach ($web in $site.AllWebs) {
    Write-Host "Inspecting " $web.Title
    foreach ($list in $web.Lists) {
        if($list.browserfilehandling -eq "Strict") {
            Write-Host "Changing " $list.Title
            $list.browserfilehandling = "Permissive";
            $list.update();
            $site.url,
            $list.title,
            $list.browserfilehandling
        }
    }
}

UPDATE – OCT 5 2010

I’ve run into more situations where this doesn’t solve the problem. I created a new post describing them here.

18 Comments