"GetSystemInfo" pre-delivery vs. WMRMChallenge.RevInfo in WMRM 10.1.2 RRS feed

  • Question

  • My team provides hosted Microsoft DRM services for various customers.  The majority of these customers use pre-delivered licenses.  In WMRM, there are two methods for doing pre-delivery of licenses:


    1.       Using RMGetLicense.GetLicenseFromURL(header, URL).  This will compose a challenge and post it to the URL, and in the URL end-point you can fish out the “challenge” parameter and load it into WMRMChallenge

    2.       Using RMGetLicense.GetSystemInfo.  You can take this system info string, and then skip the WMRMChallenge object by setting the necessary properties directly on the WMRMLicGen object.


    A few weeks ago, several of our customers noticed that their end-users were getting redirected to http://support.microsoft.com/kb/919589.  This is due to missing revocation data, and there are steps detailed at http://msdn2.microsoft.com/en-us/library/bb263347.aspx for how to add this information.


    This works fine for customers that are using RMGetLicense.GetLicenseFromURL; however, for people using RMGetLicense.GetSystemInfo, there’s no challenge argument available, so there’s nothing to load into the WMRMChallenge object.  This means we can’t get values for the WMRMChallenge.RevInfo or WMRMChallenge.RevInfoPresent properties.


    In this case, we can only get WMRMLicGen.SupportedCRLs, so our call to WMRMResponse.AddRevocationData has parameters of ["", WMRMLicGen.SupportedCRLs, false].  And this doesn’t seem to solve the issue mentioned in http://support.microsoft.com/kb/919589; when an end-user installs a license created this way, they run into the problem mentioned in the article.


    Is there any solution for customers who are using the GetSystemInfo method of pre-delivery to get the necessary RevInfo and RevInfoPresent properties?  Or should we suggest that these customers either (1) live with a sub-optimal experience or (2) rework their code to use the GetLicenseFromURL method?  Thanks in advance.

    Friday, July 20, 2007 11:28 PM


  • We found that if we set the third parameter in WMRMResponse.AddRevocationData() to 1 (i.e., true) in the case where we can't get "RevInfo" or "RevInfoPresent", then it works.  The license response is sometimes larger than it needs to be (e.g., the response might contain revocation lists that don't apply to the client app), but we avoid the security alert, and there aren't any errors on license acquisition, so this seems like a fine solution.


    Thursday, July 26, 2007 2:32 AM