In this post I wanted to share a resolution to an issue I had with a client recently.  At first I thought this was going to be a difficult issue, but as luck would have it the resolution was amazingly simple if you know what to look for. 

In our situation, SharePoint is configured with multiple lists and a document library in a single site.  The documents in the library use lookup columns to the title column of all of the lists (one lookup column per list).  This allows us to relate the document as a child of a list item, like a list of Projects.  Each of the lists has a custom display form, which was created and tabs used to show a related dataview via filter of the files that belonged to that item.  Clear as mud? 

Then we heard from an executive said that he tried to password-protect a few documents but had problems.  That’s when things appeared to go downhill. 

Symptoms

These are the symptoms and issues that we saw with this behavior.

• When the document was password-protected and saved, an error was logged in the SharePoint server application log with IRM:
  • Event ID 5047: Information Rights Management (IRM): There was a problem when trying to find the enterprise Rights Management Services (RMS) server.
    There was no enterprise server registered.
    
    
• The document disappeared from the related dataview, but was still visible directly in the document library

I started investigating the IRM error, that was the main issue (which turned out to be wrong).  I was wondering why on earth a dataview filter was causing an issue with document.  Then I realized the cause of this was another symptom I had missed.  All of the document metadata properties were empty, and the content type had reset to the default content type of the library! 

Because the lookup column was blank, it wasn’t showing in the related dataview.  That answered that question, but why were the fields going blank?  Ok now we’re on to something …

Cause

Now I had a good root symptom to investigate.  It turns out that the cause of this behavior is Office!  All of the main apps do this (Word, Excel, PowerPoint).  It seems that when you are in Word/Excel, etc and click Encrypt with Password, the application assumes you want to also protect the document metadata, so it says it encrypts that as well.  The values inside the promoted associated SharePoint columns were stripped and become empty.

Resolution

So now what?  We know why, but what if I don’t want that?  First let me say that you might not want to fix this, because you are trying to protect the internals of the document content, and likely the metadata as well.  If you proceed with this fix, the metadata will remain visible.  If that’s what you want, read on…

To be clear, this behavior is BY DESIGN.  If you want to change the behavior, we need to make a change on the client PC which you can do either via an Office group policy (GPO), but I was able to verify the registry key that affects this behavior.  DISCLAIMER – do not attempt these steps unless you know what you’re doing, have registry backups, I’m not responsible for your system, etc.

Do the following:

• Start –> Run –> regedit
• Navigate to HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\common\security
  • NOTE: the 14.0 is if you have Office 2010.  Office 2007 will be 12.0, and Office 2013 will be 15.0.
  • NOTE#2: You might have to create a few keys
• Look for the property OpenXMLEncryptProperty.  If it is not there, create it as a REG_DWORD.  Set the value to 0.

You can also set this via group policy.  For more information on these settings via GPO, see the TechNet for 2013, 2010 and 2007.  It’s always good to remember to check the obvious stuff first before chasing down the less obvious more technical possible cause! 

For more information on C5 Insight or this blog entry, please Contact Us.