More RMS survival tips and tricks from the mind of "The Uwe".

Thanks to Uwe Wizovsky, my German brother from another mother, for todays ADRMS survival tips.

HiHo,

Tip 1: Faster is better.

I recently had a strange issue with a customer. We were seeing a performance issue (very slow response when trying to obtain the service location) with RMS/ADRMS when the customer had more than one RMS Server and were using some sort of hardware or software based Network Load Balancer (NLB). In this particular case, the time to open a document took about 60 seconds.

You will see in the server-side debug trace something like this on the
server:

00000186             4.22554255          [6812] 2011-08-22T08:37:50:0659 -
Looking for service CertificationService at Url
https://rmsfqdn/_wmcs/Certification/Server.asmx       

00000187             29.99968147       [6812] 2011-08-22T08:38:16:0440 -
+Microsoft.DigitalRightsManagement.Core.DrmsEventMonitor.DrmsMonitorHandler   

00000245             46.95108414       [6812] 2011-08-22T08:38:33:0378 - Looking
for service CertificationService at Url https://rmsfqdn
/_wmcs/Certification/Server.asmx      

00000246             59.99934769       [6812] 2011-08-22T08:38:46:0441 -
+Microsoft.DigitalRightsManagement.Core.DrmsEventMonitor.DrmsMonitorHandler

 

What could be causing this is that the RMS nodes have difficulties resolving themselves over the NLB and are hitting some kind of loop.

The easiest way to resolve this is to modify the hosts file on each RMS node to point the RMSFQDN to 127.0.0.1.

The file is located by default here C:\Windows\System32\drivers\etc.

 

The hosts file should look like this afterwards in addition to all other overrides you have entered there:

127.0.0.1              RMS.Domain.com
(this is just the placeholder for your own FQDN)

After this, it should be much faster

===========================================================================================

Tip 2: Fighting Back: The story of Internet Explorer's hostile takeover.

 Group policy preferences (GPP) for IE 8 leading to Platform Policy Violation. (0x8004CF79) E_DRM_PLATFORM_POLICY_VIOLATION

If you have a Windows 2008 R2 DC that you use for group policy editing, and you define group policy preferences for IE 8 on it, for your Windows 7clients, you might see the following in a debug trace on the client:

 

00000117            
0.16121127          [3696]
[msdrm]:+DRMActivate - uLangID=1055,wszServer=(null),uFlags=17,DRM_ACTIVATE_MACHINE
DRM_ACTIVATE_SILENT
              

00000118            
0.16212843          [3696]
[msdrm]:wszServer = (null),wszUserID = (null),wszUserType = (null)
       

00000119            
0.16233264          [3696]
[msdrm]:-DRMActivate HR=0      

00000120            
0.37295800          [3696]
[msdrm]:RMActivate.exe HR = 8004cf79 

This means that RMActivate.exe fails with a platform policy violation and that you are not able to use RMS on this machine.

In order to resolve this, you will have to install SP1 on the Windows 2008 R2 DC and create a complete new policy to define your GPP for IE.

All users affected will have to get a new profile created for them, as the changes done by the “old” policy cannot be undone otherwise. Ouch!

===========================================================

Hope this helps.

-Uwe