SharePoint Foundation 2010 and Rights Management


For the record, the following links were what helped point me in the right direction, however as you will find, not everything in here is correct.  I do believe they are good for reference, and to get a good idea of the inner-workings of AD RMS, SharePoint 2010 and IRM:

After doing a LOT of research on this issue I came to a conclusion; Microsoft SharePoint 2010 (all versions) support IRM out of the box, however, the free version (and I cannot speak to the paid versions) DOES NOT contain the Office Document Protectors by default, nor does SharePoint look anywhere near where Microsoft tells you that it looks when registering your custom IRM protector!  I believe that part of the misunderstanding as of this writing is that Microsoft simply copied over a bulk of the documentation used for IRM in SharePoint 2010 from an earlier version (SharePoint 2007).  Come to find out, this was the root cause of the problem I was having, but we will get back to that.

The Setup (basics)

After configuring Active Directory Rights Management Services, the next step is to download and install SharePoint Foundation 2010.  This is a pretty simple process, only really involving the prerequisites and hitting “next” a lot picking the defaults (in our example).  Once SharePoint is installed, you will need to enable Information Rights Management (IRM) at the SharePoint Management Console level, and then you will actually control what document or list libraries have IRM applied and the extent of the permissions on EACH library.  However in order for those options to work, SharePoint must be set to use your current AD RMS server, but I’ll leave the details to all of the documentation that is out there.  It is pretty simple and errors generally point to a misconfiguration of AD RMS, DNS, or incorrect registration (or no registration) of the SCP for RMS.

Once IRM is setup at the server (or server farm level), then just create your SharePoint site(s).  Once created, all the documentation out there for SharePoint 2010 implies that setting the document library settings to use rights management should “just work”.  However I found out very quickly that by checking the box in the library settings that would not allow me upload documents that could not be rights managed, that nothing would upload.  Nothing.  Uncheck that box, uploads work, but no rights are applied!  From here it was back to ensuring that AD RMS was working properly, that IRM was registered in Active Directory, but still I was getting the same problem, SharePoint was not seeing any documents types that would work with IRM.  I began to research even more and found one blog post on TechNet that mentioned although Microsoft stated SharePoint 2010 (including Foundation) would work with IRM/RMS it wouldn’t work out of the box the same way that the full (paid) versions do.  Unfortunately it did not go into any detail about how to make it work, just that it should work, but didn’t come with the needed components that would allow it to work.

The Plot Thickens

Armed with the knowledge that SharePoint Foundation 2010 does not include the needed components that we need in order to actually use the Microsoft Office document protectors (as that is all Microsoft specifies will work with SP 2010), it was simple enough to find several others that utilized the Microsoft Office File Format Protectors in order to actually build the dll’s from Microsoft-provided source code and then install them into WSS 3.0.  Following the directions in the “Extend WSS 3.0 to Protect…” link above I installed Visual Studio 2010 (full version, but as a trial) to the server as I needed to build it as x64 bit AND ensure that the components were correctly registered on the server.  Unfortunately building the dll’s locally and moving them out to the server does not register the dll’s like we need, and manually registering them did not work, thus the install of VS 2010 on the server and just building the projects register the dll’s.  Now that I had made sure IRM was setup in SP, and now I had the dll’s registered on the server, my hope was that this should work.  Restarting IIS, attempting to upload a document was still telling me that it was not IRM-compatible. ARGH!

Back to research.  Things still were not working as I had anticipated, Microsoft Office document types (new and old) would not upload to SharePoint when I forced IRM protection to only allow documents that could be protected to be uploaded.  I had followed the other posts from Microsoft’s site, on How to: Register an IRM Protector and that even references SharePoint 2010, and goes into detail about the location of the registry keys at: HKLMSOFTWAREMicrosoftShared ToolsWeb Server Extensions<protector name> and HKLMSOFTWAREMicrosoftShared ToolsWeb Server  Extensions12.0.  everything was in its place, nothing was working.  So on to more documentation!  I parsed through (probably for the third time at this point) the MS documentation on Information Rights Management in SharePoint Foundation and decided that I wanted to go through their sample as I MUST be missing something in the code, or just not understanding something correctly when I hit another roadblock.  The Sample: Creating Custom IRM Protectors shows a fair bit of code (not all of it), and mentions that the “SampleDocProtector” code sample can be found  in the ECM Starter Kit in the SharePoint 2010 SDK.  Unfortunately after downloading the SDK and looking in the ECM Started Kit, it was not in there…What the what!?  Ok, so I re-routed my search and was able to find that there was also an ECM Starter Kit in the SharePoint 2007 SDK. This might have been a good indicator that in fact Microsoft was a bit behind in their documentation, however I know this is not the first time I was pointed one place and had to go elsewhere, so I didn’t think much more about it.  My main goal here was to see their sample project and see exactly how it was building/registering itself with SharePoint (as there was also mention that it included a .reg file for registering the protectors and I hoped it would be something different than what the MS documentation was telling me).  No dice.  It was exactly what I expected.

More Dead Ends

At this point I had burned a lot of time, reinstalled SharePoint Foundation 2010 several times, and still couldn’t get as much as an error to show up in the event logs, SharePoint logs, IIS, anywhere!!  According to each application, everything was operating normally.  I installed Office 2010 Pro Plus on the server to ensure that the AD RMS client on the server had been activated and everything was accessible (and everything worked great using AD RMS in Office, but IRM in SP was still doing the same thing!).  I brought Nolan into the game at this point since I had been looking at this and reading up on it for days, all pointing back to that fact that it should “just work”.  We decided to try a few things that I had tried previously with some different twists, but no matter how we sliced it, the problem was the same, same error, and no matter how verbose the logs in SharePoint, we really weren’t able to discern what the problem actually was.  Enter the nightmare of the impatient, Process Monitor.

One of These Things Is Not Like the Other

Our first run of procmon was really to find out what was happening with SharePoint and where it was having a problem.  Our assumption was that there was a problem with SharePoint or the custom dll’s from Microsoft.  After a few hours of digging, re-digging and searching, we had another thought: what if we are looking for the wrong thing, instead of looking for what was wrong, we needed to look at what WASN’T happening.  Sure enough within minutes we were able to figure out that Microsoft’s documentation was incorrect and instead of registering the IrmProtectors in the registry under the HKLMSOFTWAREMicrosoftShared ToolsWeb Server Extensions12.0 we needed to register them at: HKLMSOFTWAREMicrosoftShared ToolsWeb Server Extensions14.0.  The problem was that all of the processes and everything that was happening with SharePoint, that it was not looking under the 12.0 sub key and was only looking at 14.0.  Once we made that change, restarted IIS, everything worked!!  To clean things up a bit, I searched the registry for the GUID’s of the Mso and Opc protectors (from the MS code that we built on the server) and changed the registration of the dll’s to point to a C:Protectors folder where I copied the two dll’s to, and in addition for older MS Documents types to work (.doc, .xls, .ppt), you will also need to create a subfolder from where the dll’s are located named 1033, and place the provided templates (look in the templates folder of the project MsoIrmProtector) in there.  If you do not then you’ll get the same error when attempting to upload those older document types to SharePoint Foundation 2010 if the library requires only IRM-protectable documents.


For those of you that got lost in the novel above or just want a quick answer:

  1. Install and configure AD RMS
  2. Install and configure SharePoint Foundation 2010
  3. Configure IRM at the SP server/farm level
  4. Install VS 2010 (of export all the needed registry keys for the registration if you want to take the time) – and build the projects (ensuring they are set to use x64 if needed)
  5. Add in the registry keys under the HKLMSOFTWAREMicrosoftShared ToolsWeb Server  Extensions14.0
  6. Restart IIS
  7. Test to ensure that at least the newer MS document types are working (.docx, .xlsx, etc.)
  8. If things work, continue, if not, troubleshoot any errors (look in event logs, SharePoint logs, etc.)
  9. Copy the dll’s from the project files to a more desired location (i.e.: CProtectors)
  10. Copy the templates in the MsoIrmProtectors project to a subfolder of the dll’s location (i.e.: C:Protectors1033)
  11. Adjust the following Default keys to match the location in #9 above:               
    2. HKEY_CLASSES_ROOTCLSID{81273702-956F-4CBD-9B16-43790558EE29}InprocServer32
  12. Restart IIS
  13. Test to ensure all MS Office documents types supported are working.
  14. If you have a server farm, it would make more sense to actually create a setup project in Visual Studio and use that to create an installer that will make the changes needed for your environment instead of installing VS on each server, etc.


If you have any additional input, or need more information/assistance please contact us at Intrinium and we would be glad to help!  All the information needed is contained above in the article or one of the associated links.  I would highly recommend reading through the links and getting a solid understanding of AD RMS and IRM in SharePoint 2010 before even starting on this type of project.  And, as always, do this in a test environment and ensure that you have a full backup of all data before doing ANYTHING to a server.  If you choose to do this in a production environment, proceed with caution and only use AD RMS if you have the proper licenses!

Pin It on Pinterest

Share This