Archive for the 'SharePoint' Category

SharePoint IRM Issue Opening Documents

Published
by
Steve
on October 21, 2009
in Information Technology and SharePoint
. 0 Comments

Ok, I’m still learning about Windows Rights Management Services (RMS) and SharePoint Information Rights Management (IRM) and the configuration black art that it is … so … precision and accuracy of the solution below is not guaranteed.

Problem
A document library configured with information rights management protection will not display the contents of Office documents after they’re originally created/uploaded.  When you try and open, for example, a Word document from the IRM protected SharePoint library all you see is this:

image

Solution
SharePoint IRM and Windows RMS require that the user’s email address be present for both the user account (AD account or local account) AND for the user’s SharePoint profile.

The reason why the email attribute is so important goes something like this: RMS uses the email address to uniquely identify each user and the first time a user tries to protect content, RMS will provision a client certificate from the RMS server.  So, I guess this infers that without the email attribute, RMS can’t get a certificate for the user and, therefore, doesn’t know if the user can legitimately see the document and, therefore, does not show the document just in case?  Make sense?

Anyway, I had seen/heard somewhere that the email attribute must be present for the user’s Active Directory account.  So, I ensured that my test user had an AD email attribute.  But things still didn’t work (i.e. blank documents as above).  Then, on a call with Microsoft Product Support, we were told that when using SharePoint Information Rights Management (which uses RMS), the user’s SharePoint profile must also have an email address for the “Work  e-mail” attribute as shown here:

image

After ensuring this e-mail attribute was set then, voila, things started working with IRM protected SharePoint document libraries.  If your environment is using Active Directory and the user’s AD “E-mail” attributes contain email addresses, then using SharePoint profile import will automatically import the email addresses for the SharePoint user profiles.

Technorati Logo , , ,

SharePoint Document Management - Folder Discontent

Published
by
Steve
on June 16, 2009
in SharePoint
. 7 Comments

A large number of organizations still live in shared folder hell, plagued by the following issues:

  • Documents are scattered deep and wide in a vast hierarchy of folders across many shared folder locations.

  • Duplicate content is everywhere.

  • Organizational records become buried amongst the shared folders and are overlooked by information management policies that govern things such as the record’s retention policy.

  • Security holes are common because access rights are not propagated to sub-folders leaving sensitive content exposed.

  • In many cases, a shared folder hierarchy represents an department’s or an organization’s content taxonomy.  A document’s presence in a shared folder hierarchy is implicitly “tagged” with metadata being the names of the folders in the hierarchy.  Problem is, when the document is copied or moved, the metadata (i.e. the names of the folders) does not travel with the document.

  • Finding information can be a time consuming and costly endeavour.  Yes, costly; see “The high cost of not finding information”.

It’s obviously a no brainer to move those organizations from shared folders to a document management system.  And many companies are either using (or thinking about using) SharePoint as a document management solution.

You might think that using SharePoint 2007 as a document management system will cure all the shared folder ills that I highlighted above.  Wrong.  SharePoint 2007 has a core performance limitation that will require you to use folders (or indexed views) when the number of documents in a single view starts to exceed 2000.  The same applies to SharePoint lists.

Tests show that the performance of libraries starts tanking as the number of documents/items in a library view approaches and exceeds 2000.  The recommended way to avoid the performance degradation trap is to create folders within libraries to break down the documents into sub-2000 document folders.  The TechNet article “Plan for software boundaries (Office SharePoint Server)” talks in detail about this performance limitation and how to deal with it using folders.  It very clearly states that folders are “critical for scaling“.  So, unfortunately, if you expect to store more than 2000 documents in a library you’re faced with either:

  1. Using folders in a document library and having to deal with many of the same problems as dealing with server-based shared folders.

  2. Using indexed views (views that used indexed columns).  Helps improve performance for libraries with 2000+ documents but performance is not as good as using folders.

  3. Using multiple document libraries that store no more than 2000 documents.

Options 2 (indexed views) and 3 (multiple document libraries) may alleviate the need to use folders.  However they potentially force you to deviate from your information architecture (IA) by using multiple libraries and views that do not conform to IA requirements for the organization and presentation of content.  Those options can also introduce additional administrative overhead managing the many libraries, views, and indexed columns.

Ultimately, if an organization needs to store many thousands of documents in SharePoint 2007 they will likely have to break down the libraries into hierarchies of sub-folders.  And now you’re back to square one dealing with folder hell.  Will the next version of SharePoint address the performance limitation and eliminate the need for folders?

Technorati Logo , , ,

Bad Behavior has blocked 76 access attempts in the last 7 days.