SharePoint and Acrobat X integration

!<UPDATE>!

A fix for the bug described at the end of this article has been published by Microsoft.

You can find here the related KB.

This is the scenario that refers to our particular issue:

You create a French site collection in SharePoint Foundation 2010.
You upload a .pdf file to a document library in the French site collection.
You check out and edit the file.
You try to check in the file.

It describes the issue with a French site collection but it applies to all non-english site collection.

!<UPDATE>!

In this article, I will show you how to set up the integration SharePoint 2010/Acrobat X.

About Acrobat X

This is not the porn version of Acrobat but the last drop of the Acrobat family made by Adobe.

The great thing with this version is that it comes with an ActiveX which holds a special class to deal with PDF and make the integration nicer and easier.

PDFs and SharePoint

To tell SharePoint and Internet Explorer what they must do when they see a PDF file, you must add a new mapping into the 14/TEMPLATE/XML/DOCICON.XML

but instead of using the old traditional SharePoint.OpenDocuments ActiveX, we will use a brand new feature of the new ActiveX provided by the Acrobat X.

<Mapping Key=”pdf” Value=”pdfIcon.gif”  Text=”Adobe Pro” OpenControl=”AdobeAcrobat.OpenDocuments“/>

Once this is done, you just need to make a small recycle of your Application Pools or a IISRESET.

For every PDF uploaded into a document library, you will have the PDF icon in the type column and a new item “Edit in Adobe Pro” in the ECB (Edit Control Block).

Result

Here is what you get if you have followed me until now. I made my printscreens in French, sorry for that : x

if you click on Modifier dans Acrobat Pro (Edit in Acrobat Pro),  you get the following

Let’s check out the file, modify something and check-in it back.

Common issues

“The URL you have provided could not be reached. Please verify that the URL is correct and that the network location is reachable.”

This one is WebDav related.

1. Check that the client has the WebClient Service enabled in Windows

It should be enabled by default but you never know, especially if you are working in a highly secured environment.

2. Check that the user have the Use Remote Interfaces permission.

“Acrobat cannot access the network”

I came across this issue when doing some working with Acrobat and SharePoint on a French site. Indeed, I did not have this issue on English site.

We got the official word from Microsoft, it’s a bug. They are working on a fix as I speak but they have provided us a workaround in the meantime.

So here it is, let’s the magic happens : you need to recreate 57 fields in English in order to make this working. My guess is that French is not the only buggy version so it should apply to all non-English sites.

Here is the list of fields that you must add to your list.

Content Type ID
Approver Comments
Name
Document Modified By
Document Created By
File Type
HTML File Type
Source URL
Shared File Index
Title
Template Link
HTML File Link
Is Signed
Document ID Value
Document ID
Content Type
Created
Created By
Modified
Modified By
Has Copy Destinations
Copy Source
Approval Status
URL Path
File Size
Item Type
Sort Type
Effective Permissions Mask
ID of the User who has the item Checked Out
Is Checked out to local
Checked Out To
Unique Id
Client Id
Virus Status
Check In Comment
Edit Menu Table Start
Edit Menu Table End
Server Relative URL
Encoded Absolute URL
Property Bag
Level
Is Current Version
Item Child Count
Folder Child Count
Select
Edit
UI Version
Instance ID
Order
Workflow Version
Workflow Instance ID
Source Version (Converted Document)
Source Name (Converted Document)
Document Concurrency Number
Relink
Merge
Path

Here is a script which does that.

Note that each field Hidden property is set to true in order to keep a clean interface.

If none of these fixes have helped you, fire up Fiddler and locate the call to the Copy.asmx, have a look at the HTTP Response, it might reveal some really useful information.

That’s all folks.