Archive for September, 2009

Labeling and Watermarking in SharePoint

Wednesday, September 16th, 2009

Earlier in the week Lara discussed SharePoint’s native labeling functionality. As Lara mentioned, the biggest disadvantage of the native labeling in SharePoint is that the user has to do something to get the labels in the document. In this post, I’ll discuss how we’ve enhanced the standard labeling in SharePoint with our Document Marking for SharePoint product.

Before I get into the details, I want to give everyone a bit of background on this product. Our Document Classification desktop product, which we’ve been selling for about 4 years, has the ability to add labels and watermarks to Office documents on the desktop. Some of our customers told us they liked this functionality, but they would prefer to see this done on the server. Being the most popular platform for sharing documents we decided to build labeling and watermarking functionality into SharePoint. Our goal was to make this a completely transparent process to users. The feedback we got was that, due to compliance and organizational policy, labeling needs to be mandatory in some environments. Thus labeling and watermarking functions should be controlled via administrator policy. The user should not be responsible for inserting labels.

The Document Marking for SharePoint product allows organizations to add labels and watermarks to Office documents via policy. The label or watermark can be any fixed text, or metadata available in SharePoint. So you could add labels that include standard SharePoint metadata like the author or date of creation, or custom metadata fields such as Project name, classification etc.

The administrator defines the policy via SharePoint Information Management Policy. We’ve added two policies, one for watermarking and one for header / footer labels. The policy can be attached to a document library, or you can create a site collection policy. The example below shows a policy that will add a watermark to Microsoft Word documents. The watermark will contain the value of the column “Classification”.

The screenshot below shows an example of the Header / Footer policy. In this case, we will be adding a header and footer to Microsoft Word documents. The text inserted in the header and footer will include the fixed text “Titus Labs:” and the value of the custom column called Classification.

Once the policy has been defined for a document library all documents in the library will have the policy applied. This can include existing documents in the library, a new document added to the library or a bulk upload of documents. All this is done transparently to the user. For new documents, the policy is applied when the document is saved or uploaded to the library. If the label needs to be changed for some reason, the administrator can change the policy and the document labels are automatically updated. Once a policy is applied, the next time a document is opened the header footer and watermark will appear in the document.

Using PDF in SharePoint Document Libraries

Thursday, September 3rd, 2009

On Tuesday’s blog, we talked about limiting a user’s access to read-only when opening an Office document from SharePoint. As mentioned, Microsoft Office read only support is weak. Anyone can do a “Save As” on the document and change the content.

Generally if people want to put something in a read-only format they convert to PDF. You can’t change the document, and depending on the settings of the PDF, you may not even be able to copy the text out of the PDF. PDF is also the accepted standard for archived documents. Documents that are scanned for records retention are usually scanned into a PDF format as that is the accepted format for archiving.

If you’ve got a SharePoint portal and want to share documents with customers or partners, or you want to share documents with other employees that should only have read-only, how do you get the document in PDF format in SharePoint? For example, the legal department may be creating contracts for use by other employees in the organization. The lawyers need access to the original Microsoft Word format in order to be able to modify the contract, but other employees should only get the contract in PDF format. One alternative is to have the lawyers PDF the document on their desktop every time there is a change to the document. They could then save the PDF to the SharePoint library. The problem here is that every employee would have to have PDF conversion tools on their desktop, and this could be a very time consuming process to have to maintain the PDF.

A product we have developed, called Titus Labs PDF Control for SharePoint solves this problem by automatically creating PDF versions of Microsoft documents as the documents are added to SharePoint. The PDF conversion takes place transparently in the background, and requires no additional software on the user’s desktop. If the source document change in the future, the PDF is updated automatically; this ensures that the PDF version is always up to date.

The software is administered via SharePoint Information management policies. The PDF policy can be turned on for particular libraries. Administrators can control the permissions on both the source document and PDF in SharePoint, so that some users can access the original documents, while others can see only the PDF.

Once the policy is enabled, PDF will be automatically created for all Office documents saved or uploaded into the library. In the screenshot below, a PDF has been automatically created in the Administrative Documents library for all the saved Office documents.

Depending on the permissions of the users, they will either see all of the documents, or they may only see the PDF versions of the document. The screenshot below shows a user who only has permissions to the PDF versions in the same Administrative Documents library.

Limiting Access to Read Only in SharePoint Document Libraries

Tuesday, September 1st, 2009

Limiting Access to Read Only in SharePoint Document Libraries

We often hear from customers that they want to allow customers or partners access to documents via a SharePoint portal. They want to be able to share final documents with this audience, and typically they don’t want people to be able to change the documents. Read only versions of Microsoft Office documents are a possibility here, but there are some definite disadvantages. First let’s have a look at how Read Only access would be setup in SharePoint

First we modify the permissions of the library, or the document itself to give Read-Only access. In this case, a specific user – Charlie – has been granted read only access to the document called Acquisition Plan.

When the user Charlie signs on to the library and selects the menu of options for the Acquisition Plan document in order to see what permissions they have, they will see a very limited set of permissions. Note the user does not see the “Edit in Microsoft Office Word” option.

The user can still click on the document and open the document in Read Only mode. Note the (Read Only) beside the document name in Microsoft Word.

Though the user cannot modify this copy of the document, the user can do a “Save As” on this document and save the document with a different name. The user can then modify the document as they wish.

All the Microsoft Office applications work in the same way. As a result, most customers are not satisfied with the “Read Only” mode of Microsoft Office applications. Customers would prefer to distribute a document in a Read Only mode that cannot be modified.

Later this week in our next post we’ll examine some alternatives to the Microsoft Office Read Only mode.