The Official RMS Team Blog

If you subscribe via RSS please be sure to update your subscription. And if you don’t subscribe, you should! You can do so here: RSS for posts.

J.C. Hornbeck | Solution Asset PM | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

System Center All Up: https://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: https://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: https://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: https://blogs.technet.com/momteam/
System Center – Service Manager Team blog: https://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Windows Intune: https://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: https://blogs.technet.com/sus/
The RMS blog: https://blogs.technet.com/b/rms/

The Forefront Endpoint Protection blog : https://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : https://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: https://blogs.technet.com/b/isablog/
The Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

[Update 10/14/2014 - We just released an updated app to the App Store (RMS sharing version 1.6) with all iOS 8 issues fixed. The update should be available to users in the next few hours.]

=====

Our users who have already upgraded to iOS 8 or using iPhone 6 are experiencing problems with the RMS sharing app for iOS.

We have found the issues and are actively working to release an update to the App Store with the fixes to support iOS 8 as soon as possible. With iOS 8, Apple made a few changes to their DNS service discovery APIs which broke our functionality. We are now testing our fixed version with iOS 8 support and will submit it to the App Store in the next few days.

We sincerely apologize for the inconvenience this caused, and for any questions or further feedback please email us to askipteam@microsoft.com

Thanks,

RMS support team

The Windows Server 2003 support lifecycle is set to expire in July 2015 so Microsoft changed the lifetime of SLCs that are issued for Windows Rights Management Services to 7150 days. This change was made to allow Windows Rights Management Services servers and clusters to continue to work after the service that is used to issue SLCs is decommissioned after the end of support of Windows Server 2003.

You can get all of the details here:

KB2853958 - Server Licensor Certificate Duration for Windows RMS Extended to 7150 Days (https://support.microsoft.com/kb/2853958)

J.C. Hornbeck | Knowledge Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

System Center All Up: https://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: https://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: https://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: https://blogs.technet.com/momteam/
System Center – Service Manager Team blog: https://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Windows Intune: https://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: https://blogs.technet.com/sus/
The AD RMS blog: https://blogs.technet.com/b/rmssupp/

The Forefront Endpoint Protection blog : https://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : https://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: https://blogs.technet.com/b/isablog/
The Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

2799251 - Installing Active Directory Rights Management Services fails with error ID 204(https://support.microsoft.com/kb/2799251)

J.C. Hornbeck | Knowledge Engineer | Management and Security Division

Get the latest System Center news on Facebook and Twitter:

System Center All Up: https://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: https://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: https://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: https://blogs.technet.com/momteam/
System Center – Service Manager Team blog: https://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Windows Intune: https://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: https://blogs.technet.com/sus/
The AD RMS blog: https://blogs.technet.com/b/rmssupp/

The Forefront Endpoint Protection blog : https://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : https://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: https://blogs.technet.com/b/isablog/
The Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

The the olden days, as my kids call it, RMS v1 had an SLC with a two year validity. Hence it needed to be renewed every two years (renewing an SLC nowadays requires a workaround). When you provision an AD RMS server (either fresh or upgrading from v1) the SLC is given a lifetime validity of over 250 years. Thus in AD RMS there is no mechanism for renewing the SLC.

If the above paragraph is true then how would one have an expired SLC in AD RMS? How would this expired SLC manifest itself? I’ll partially answer the former question and delve into the latter.

The only expired AD RMS SLC issues I’ve encountered stem from an upgraded RMS v1 environment. The appearance of the issue is subtle.

Issue appears:

At some point in the RMS v1 lifetime the SLC was created and a two year countdown to expiration began. Any SLC renewal reset the two year timer. AD RMS is added and the RMS v1 cluster is updated (so we thought). However, in some cases, the SLC is not updated. So the two year expiration countdown is still, well, counting down.

Expiration day arrives and most folks don’t notice at first. Unless a user gets a new RAC or CLC, creating protected content works fine. Any protected content for which one already has a valid license is good. Only in instances where a new use license is generated or new RAC needed does one start seeing errors.

New content use licenses issued from the expired SLC RMS server are correctly tagged as invalid by the client. Protected content may not be accessed. I don’t recall the exact errors the user receives but I do remember they were nothing unusual. Nothing in the error messages made me suspect anything out of the ordinary.

As a few day passes more existing (and valid) licenses expire and more folks get new ones and these invalid licenses don’t open the content. On the surface we just find a few more users complaining that they can’t get to content. All this licensing stuff is happening underneath and we don’t really notice that part.

Troubleshooting:

Getting a client-side trace give us our first hint. However this is small and easily missed clue. In the heavily edited snippet from one such failed client log there’s the arrow pointing to the issue.

[msdrm]:+DRMGetSignedIssuanceLicense               
[msdrm]:DRMGetSignedIssuanceLicense Args...
  <SNIP>
[msdrm]:-DRMGetSignedIssuanceLicense HR=8004cf58   

The DRMGetSignedIssuanceLicense return is the key error. E_DRM_INVALID_CLIENT_LICENSOR_CERTIFICATE (0x8004CF58)

From a server-side trace or opening protected content in notepad and digging through the XML we find the root cause.

<SECURITYLEVEL name="Server-Version" value="5.2.3790.134" />
<SECURITYLEVEL name="Server-SKU" value="RMS 1.0" />
<OBJECT type="Server-Licensor-Certificate">
<FROM>2003-02-05T00:00</FROM>
<UNTIL>2012-07-13T22:37</UNTIL>

Looking at the selected items above (cherry picked from the XML in trace output) several things are of note. This is an AD RMS cluster yet the "Server-Version" is v1. More importantly the the from/until date range is expired. This is an expired SLC.

Resolution:

This appears to bring us back to the main question. The question of how does an AD RMS SLC expire? Better yet, how do I fix it?

Once again, my friend and our RMS guru, Jason had the answers. The cause of this is what Jason dubbed the “half baked upgrade.” The steps to fix this issue is exactly as Jason described in that post.

Prerequisites:

• AD RMS Service account password.
• AD RMS cluster key password.*
• Have a machine we can temporarily add the AD RMS role onto (joining the existing cluster).
• Have a user account that is
  • a local administrator on the new AD RMS server
  • an enterprise administrator, and
  • a sysadmin on the SQL instance hosting the AD RMS databases.
• Back up the RMS databases.

* No matter how positive you are that you know the RMS cluster key password you don’t. The most common way to get into this situation is not knowing the cluster key password when attempting the initial upgrade from RMS v1 to AD RMS. It would be prudent to just reset the cluster key password to what you think it already is before you do any of the other steps. It’s really easy.

Steps to fix:

1. Export the AD RMS server certificate.
2. Export the AD RMS server trusted publishing domain (TPD) certificate.
3. Edit the ADRMSFileVersion value in the DRMS_ClusterPolicies table of the DRMS_Config database (screenshots on this step below).
4. Add the AD RMS role to the new server, adding it to the existing cluster.

One the “upgrade” is successful you may remove the role from the temporary cluster member added.

Poking around the AD RMS management console I found the “Change Service Account” wizard. Looking though this wizard it came across to me as what we use to change the account, but I wasn’t sure about updating the existing one.

Digging around my RMS lab and going through some resources I found the answer. The “Change Service Account” wizard is the answer. It updates all the needed items. I’ve written it up on the wiki so check it out!

AD RMS How To: Change the RMS Service Account Password

With the recent Windows 8 RTM I wanted to pull together a list of IRM related fixes. These are fixes for both the client and Office.

Here are some notes about this information.

• This is not a complete list. I may have missed some. However these are the fixes I encounter in my life as an RMS support person.
• The list assumes the latest service pack version is installed on the OS. I am not going to call out any fixes for Windows 7 RTM or Windows XP SP2, and etc.
• Earlier this year the v2 rights management client was released. I’ll refer to the v1 client as MSDRM and v2 as MSIPC.

Office 15 adds the MSIPC client on Windows Vista, Windows 7, and Windows 8. There is no separate install needed and there are no fixes needed.

I’ll be making this information a Wiki post and will maintain it there. I’ll add that link when I get it done.

In earlier blog entries I pointed out two separate cases of the 500 errors when trying to get to the RMS server.

1. SharePoint 2010 and IRM Integration
2. AD RMS Server Returns IIS 500 Errors

Both the earlier instances had a common cause – the client SSL settings in IIS. In this new case we have a whole new symptom and cause, with the 500 error playing a key role.

Check out the wiki entry, AD RMS Console - "You cannot access the AD RMS administration service at this time" for all the details!

The client will report some error. The AD RMS server side is quiet. You have to dig into the IIS server logs on the AD RMS server to find the clue.

In my SharePoint specific post (link below) we have errors similar to the following.

GET /_wmcs/certification/servicelocator.asmx - 443 <snip> 500 0 64 453

So, I am linking to my own earlier blog post with the following caveat. Go to the “The Cause” section and see if the SSL settings on the RMS server are the cause of the 500 returns.

SharePoint 2010 and IRM Integration – now with applicability to other RMS issues.

In my opinion this is a purely cosmetic “issue.” In one place do you readily see the old servers referenced anywhere. It does not affect the functionality of the RMS infrastructure. Yet some feel this is important enough to open a support case and fix.

AD RMS How To: Remove Obsolete Servers From the RMS Database