locked
Problems with KB2584066 & Office 2010 RMS RRS feed

  • Question

  • Hi everybody,

    we have a quite big RMS deployment which worked perfectly until 2 days ago. While we were performing some tests, we noticed that we were not able to protect any document (the very eloquent RMS error message appeared "An unexpected error has occurred while trying to restrict permission to your document. Contact your administrator for assistance"); suddenly the problem became widespread... And we were getting calls from lots of users.

    Since we did not see any error on the AD RMS logs and servers Event Viewer, we focused on the clients and related updates.

    After some tests, we identified  the Office 2010 Security Update KB2584066 as the source of the problem. When this update is installed, it is impossible to protect any document or email with RMS, as the "unexpected error" occurs; by removing it, Office starts working correctly.

    The problem appeared on both Windows XP and Windows 7 Enterprise (32-bit) machines, with Office 2010 Professional Plus (32-bit).

    As a temporary workaround we removed this patch from the WSUS, but we hope that Microsoft prepares a fix as soon as possible.

    Is someone else experiencing the same problem?

    Wednesday, September 21, 2011 8:22 AM

Answers

  • The problem is with the RMS URLs.

    If you have a certification or licensing URL that contains a :443 you will have problems.

    Office tries to match up CLC certificates with RACs by matching up the RMS URL embedded in those certs. If the certification cert has a :443, but the licensing cert doesn't then you'll hit this error.

    I've fixed (err...worked around) this for a few customers recently, and the Office team is actively pursuing a fix.

    I like to fix (ahem..work around) this issue by permanently fixing the ADRMS install so they dont have to worry about string comparisons within office. The upside is that once you do this procedure you don't have to worry about this problem that has been around since Office 2003. The downside is that you will need to write a logon script that removed all of your users %localappdata%\Microsoft\DRM\*.drm files so they can re-bootstrap, AND you will most likely need to Archive and recreate your RMS Templates if you are using them. If this sounds like a good trade off for a faster solution then follow along. Otherwise call support and see what other options exist.

    Tip: If you want to test to see if this is your issue simply go into the users %localappdata%\Microsoft\DRM folder and edit the GIC-...file. Remove any:443 that is in there and save it. Try the application again. If it works...thats the problem. If it doesn't, it's probably something else.

    1.) Go to the ADRMS server and open the ADRMS console.

    2.) Right Click on the Server name, and go to Properties.

    3.) Go to the 'SCP' tab and remove the SCP.

    Skip to step 7 if you already have an extranet URL and your licensing URLs don't contain a :443.

    4.) Go to the Cluster URLs tab, and check the box for 'Extranet URLs'

    5.) Put the word 'test' in each of these and hit apply.

    6.) Uncheck the 'Extranet URLs' box, and hit Apply, then OK.

    ---------------------------------------------------------------------------

    7.) Close the ADRMS Console

    8.) Re-open the ADRMS console

    9.) Right Click on the server name>Properties>SCP Tab, and register the SCP.

    - Check your RMS settings now and make sure that no :443 exists in any of the cluster URLs.

    10.) Go to Regedit and create this key. (on each server)

    HKLM/Software/Microsoft/DRMS (on 2008 you may have a 2.0 key under here..use that instead)
    Reg_Sz:GICURL
    Value: https://rms.domain.com/_wmcs/certification/certification.asmx

    11.) Go to an Administrative command prompt and issue an IISRESET command. (on each server)

    12.) Go to client PC and delete the %localappdata%\Microsoft\DRM folder.

    13.) Close all office apps.

    14.) Try again.

     

    Note if you have templates do the following.

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

    1.) Go to RMS server

    2.) Go to templates section and archive all your templates by right clicking and choosing the archive option.

    3.) Click on each template and choose Copy, to create a copy.

    4.) Rename the new templates with a slightly different name. (You can't have two templates with the same name).

    5.) Right click on the new template and choose to Distribute the template.

    6.) Push these out to your users.

     

    The last option is to wait for this issue to be fixed, and actually to open a support case to make sure you are notified as soon as it is fixed (bug issues are free). If you do the steps above, it won't matter either way because you won't be affected by any of the problems that require a fix.

    Hope this helps.

    Jason Tyler






    Tuesday, October 4, 2011 8:58 PM

All replies

  • Hi

    Have you had a chance to run the IRMcheck tool on the workstations?


    Blog Link: http://blogs.cyquent.ae | Follow us on Twitter: @cyquent | ADRMS Wiki Portal: Technet Wiki

    Wednesday, September 21, 2011 11:26 AM
  • Hi Adnan,

    yes I did; there's nothing strange (except an error because IRMCheck is outdated and is not able to detect the Office 2010 installation), and I don't see any difference between the IRMCheck reports, no matter if the patch is installed or not.

    Thanks

     

    Wednesday, September 21, 2011 11:42 AM
  • Hi

    We have exactly the same problem!

    After uninstalling KB2584066 it works again.

    Are there any update on this issue?

    Thx

    J0fe

    Thursday, September 22, 2011 2:27 PM
  • Hi J0fe,

    no updates yet, I think Microsoft is the only one who can help us on that.

     

    From our tests, we discovered that in another RMS environment the update is not causing any issue. The only difference is that the clients use a 64-bit operating system (Windows 7 Enterprise x64).

     

    Please let us know if you discover something.

    Thursday, September 22, 2011 2:44 PM
  • I just ran into this problem today.  Wish I found this forum earlier.  I spent about two hours search for the error and finally started process of elimination steps.  Luckily I test RMS every month so it was easy to uninstall the office updates for this month till I found the one causing the problem. 

    As for a fix, like I mentioned earlier I spent a few hours just trying to find something about the error and did not find this till after I got it resolved.  So at this time I don't believe there is a fix out there. 

    I did pass this on to my manager when questioned and told him that there are known issues with the patch and maybe it is related to RMS due to the digital signature.

     

    http://support.microsoft.com/kb/2584066

    http://technet.microsoft.com/en-us/security/bulletin/ms11-073
     

    Known issues with this security update

    If you install this update and open a form with a digital signature, InfoPath may crash.

    Microsoft is researching this problem and will post more information in this article when the information becomes available.

    Thursday, September 22, 2011 6:18 PM
  • Hi Guys,

     

    Thanks this post helped me alot! We rely heavily on IRM in our business and been battling now for a week to figure out what was wrong! Removed the update and all is working perfectly again. Any feedback from MS when this problem will be resolved?

     

    Thanks

    Shaun

    Friday, September 23, 2011 12:39 PM
  • Hi,

    We have experienced the same problems with KB2584066 and ADRMS. What we have seen is that is works after uninstalling the patch on those who has got their Office 2010 with SP1 integrated. But on those who has been patched with SP1 (WSUS) is not working anymore. I have tried to uninstall Office 2010 and all patches is also uninstalled during the process, and reinstalled Office 2010 with SP1 integrated without luck.

    Is there any update to this ?

    We really need MS to take action on this.

    /M 

    Monday, September 26, 2011 7:50 AM
  • Experiencing problem here, removing kb2584066 does not fix, however our office 2010 was rolled out prior to sp1, and sp1 distributed later via SCCM.

    Issue also occurs on terminal server (2008) with office 2010 also.

    Monday, September 26, 2011 9:17 AM
  • For those who are experiencing the issue even after removing the update, please try to protect the document with different credentials. This could help to identify the issue with an account we used during the tests.
    Monday, September 26, 2011 10:09 AM
  • Hi All,

    What i found is that the update is installed for each setion of office, so if you have viso and office 2010 installed you have to un-install the update under both locations, not just under office proffesional 2010, if you have project you need to remove it from there too and so on and so forth. So just check that out.

     

    Thanks

     

    Shaun

    Monday, September 26, 2011 10:34 AM
  • We have found that add remove programs and uninstall KB2584066 does not fix the issue, but either of these 2 commands DOES resolve:

    “C:\Program Files\Common Files\microsoft shared\OFFICE14\oarpmany.exe" /removereleaseinpatch "{90140000-0011-0000-0000-0000000FF1CE}" "{EEB4DDD0-08EA-4787-BDAB-D38D67A35CD5}" "1033" "0"

     (First Guid is Office 2010, the second is the patch to remove)

    or

    Msiexec /I {90140000-0011-0000-0000-0000000FF1CE} MSIPATCHREMOVE={EEB4DDD0-08EA-4787-BDAB-D38D67A35CD5} /qb

    or use /qn instead of /qb for fully silent

    Either of these methods can be distributed via sccm, unfortunately requires reboot, but has fixed all ours for now - guess we wait for a new version of the security patch!


     

     

    Monday, September 26, 2011 3:16 PM
  • The problem is with the RMS URLs.

    If you have a certification or licensing URL that contains a :443 you will have problems.

    Office tries to match up CLC certificates with RACs by matching up the RMS URL embedded in those certs. If the certification cert has a :443, but the licensing cert doesn't then you'll hit this error.

    I've fixed (err...worked around) this for a few customers recently, and the Office team is actively pursuing a fix.

    I like to fix (ahem..work around) this issue by permanently fixing the ADRMS install so they dont have to worry about string comparisons within office. The upside is that once you do this procedure you don't have to worry about this problem that has been around since Office 2003. The downside is that you will need to write a logon script that removed all of your users %localappdata%\Microsoft\DRM\*.drm files so they can re-bootstrap, AND you will most likely need to Archive and recreate your RMS Templates if you are using them. If this sounds like a good trade off for a faster solution then follow along. Otherwise call support and see what other options exist.

    Tip: If you want to test to see if this is your issue simply go into the users %localappdata%\Microsoft\DRM folder and edit the GIC-...file. Remove any:443 that is in there and save it. Try the application again. If it works...thats the problem. If it doesn't, it's probably something else.

    1.) Go to the ADRMS server and open the ADRMS console.

    2.) Right Click on the Server name, and go to Properties.

    3.) Go to the 'SCP' tab and remove the SCP.

    Skip to step 7 if you already have an extranet URL and your licensing URLs don't contain a :443.

    4.) Go to the Cluster URLs tab, and check the box for 'Extranet URLs'

    5.) Put the word 'test' in each of these and hit apply.

    6.) Uncheck the 'Extranet URLs' box, and hit Apply, then OK.

    ---------------------------------------------------------------------------

    7.) Close the ADRMS Console

    8.) Re-open the ADRMS console

    9.) Right Click on the server name>Properties>SCP Tab, and register the SCP.

    - Check your RMS settings now and make sure that no :443 exists in any of the cluster URLs.

    10.) Go to Regedit and create this key. (on each server)

    HKLM/Software/Microsoft/DRMS (on 2008 you may have a 2.0 key under here..use that instead)
    Reg_Sz:GICURL
    Value: https://rms.domain.com/_wmcs/certification/certification.asmx

    11.) Go to an Administrative command prompt and issue an IISRESET command. (on each server)

    12.) Go to client PC and delete the %localappdata%\Microsoft\DRM folder.

    13.) Close all office apps.

    14.) Try again.

     

    Note if you have templates do the following.

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

    1.) Go to RMS server

    2.) Go to templates section and archive all your templates by right clicking and choosing the archive option.

    3.) Click on each template and choose Copy, to create a copy.

    4.) Rename the new templates with a slightly different name. (You can't have two templates with the same name).

    5.) Right click on the new template and choose to Distribute the template.

    6.) Push these out to your users.

     

    The last option is to wait for this issue to be fixed, and actually to open a support case to make sure you are notified as soon as it is fixed (bug issues are free). If you do the steps above, it won't matter either way because you won't be affected by any of the problems that require a fix.

    Hope this helps.

    Jason Tyler






    Tuesday, October 4, 2011 8:58 PM
  • Hi Jason,

    thank you for your reply. I did a quick test by modifying the GIC file (removing any :443), and it actually solved the problem.

     

    I don't think we will apply the workaround as with thousands of workstations, we do not want to mess around in the environment. We hope the patch will be released soon.

     

    ps: the ":443" port in the URL is suggested by default during the RMS setup.


    Wednesday, October 5, 2011 7:49 AM
  • Correct.

    Whether or not ADRMS puts a :443 in the URL shouldn't matter, and if you have MOSS/Sharepoint or Exchange 2010 in your environment integrated with ADRMS you will notice that neither of those applications were affected by this update, because they don't care what the URL is, as long as they can connect to it.

    The problem is in the way Office compares strings to do certificate matching. In the Office code https://rms.domain.com:443/_wmcs/ doesn't match https://rms.domain.com/_wmcs/ even though techically they resolve to the same location and in most other applications are considered equal.

    If all strings were stripped of the :443 before comparison the steps I mentioned above would not be required. The steps above are really just a way to force your URLs past the Office string comparison code. Its a 'set it, and forget it' workaround. :)

    Wednesday, October 5, 2011 2:32 PM
  • The problem is with the RMS URLs.

    If you have a certification or licensing URL that contains a :443 you will have problems.

    Office tries to match up CLC certificates with RACs by matching up the RMS URL embedded in those certs. If the certification cert has a :443, but the licensing cert doesn't then you'll hit this error.

    I've fixed (err...worked around) this for a few customers recently, and the Office team is actively pursuing a fix.

    I like to fix (ahem..work around) this issue by permanently fixing the ADRMS install so they dont have to worry about string comparisons within office. The upside is that once you do this procedure you don't have to worry about this problem that has been around since Office 2003. The downside is that you will need to write a logon script that removed all of your users %localappdata%\Microsoft\DRM\*.drm files so they can re-bootstrap, AND you will most likely need to Archive and recreate your RMS Templates if you are using them. If this sounds like a good trade off for a faster solution then follow along. Otherwise call support and see what other options exist.

    Tip: If you want to test to see if this is your issue simply go into the users %localappdata%\Microsoft\DRM folder and edit the GIC-...file. Remove any:443 that is in there and save it. Try the application again. If it works...thats the problem. If it doesn't, it's probably something else.

    1.) Go to the ADRMS server and open the ADRMS console.

    2.) Right Click on the Server name, and go to Properties.

    3.) Go to the 'SCP' tab and remove the SCP.

    Skip to step 7 if you already have an extranet URL and your licensing URLs don't contain a :443.

    4.) Go to the Cluster URLs tab, and check the box for 'Extranet URLs'

    5.) Put the word 'test' in each of these and hit apply.

    6.) Uncheck the 'Extranet URLs' box, and hit Apply, then OK.

    ---------------------------------------------------------------------------

    7.) Close the ADRMS Console

    8.) Re-open the ADRMS console

    9.) Right Click on the server name>Properties>SCP Tab, and register the SCP.

    - Check your RMS settings now and make sure that no :443 exists in any of the cluster URLs.

    10.) Go to Regedit and create this key. (on each server)

    HKLM/Software/Microsoft/DRMS (on 2008 you may have a 2.0 key under here..use that instead)
    Reg_Sz:GICURL
    Value: https://rms.domain.com/_wmcs/certification/certification.asmx

    11.) Go to an Administrative command prompt and issue an IISRESET command. (on each server)

    12.) Go to client PC and delete the %localappdata%\Microsoft\DRM folder.

    13.) Close all office apps.

    14.) Try again.

     

    Note if you have templates do the following.

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

    1.) Go to RMS server

    2.) Go to templates section and archive all your templates by right clicking and choosing the archive option.

    3.) Click on each template and choose Copy, to create a copy.

    4.) Rename the new templates with a slightly different name. (You can't have two templates with the same name).

    5.) Right click on the new template and choose to Distribute the template.

    6.) Push these out to your users.

     

    The last option is to wait for this issue to be fixed, and actually to open a support case to make sure you are notified as soon as it is fixed (bug issues are free). If you do the steps above, it won't matter either way because you won't be affected by any of the problems that require a fix.

    Hope this helps.

    Jason Tyler






    You are the boss ... love you
    Thursday, November 10, 2011 2:48 PM
  • Has a patch for this been issued yet?

     

    This is a major pain in the neck.


    good night and good luck
    Saturday, February 4, 2012 9:38 AM
  • I'm eager to hear of a patch as well. This is causing me a major headache.
    Thursday, February 16, 2012 2:53 AM
  • Hello Guys,

    I had the same problem as mentioned above, therefore I performed Jason's workaround. Since then I'm getting the error "Cannot use this feature without credentials" when a user attempts to protect a document. I'm not even hitting the authentification prompt of the Active Directory...

    I cleaned the clients PC (delete the %localappdata%\Microsoft\DRM folder) and restartet both server and clients.

    Did somebody experience similar problems? Appreciate any help.

    Thanks,

    Marc


    EDIT: I found the problem: My RMS installation was configured to require User certificates for establishing the SSL-connection - It seems that such a configuration does not work without registering the 443 port in the SCP.
    • Edited by marc__ Monday, February 20, 2012 2:02 PM
    Monday, February 20, 2012 1:53 PM
  • Hello all,  has this incident had a case opened with Microsoft?   Does any one know the ID?

    So I can chase it up.

    I have sat here now for 4 months with if broken.

    product is almost a waste of money as we cannot reset all client encrypted docs.

    Monday, February 20, 2012 4:33 PM
  • You don't need a case ID to call into support. Just ask to speak to someone from the RMS support team. We know about the issue. :)

    Any member of the RMS team should be able to get you going, and if it is in fact this issue, then you won't be charged for the incident anyways.

    I'll look forward to hearing from you, and getting you up and running again.

    In the meantime, I'll make sure that when the final fix is ready and public that it is posted to this thread.

    Jason Tyler


    UPDATE: FYI. If you just want to know when the fix will be available, then you don't need a case. I will post it here once it is publicly available. Just subscribe to this thread. If you want to workaround the issue, then you can open a case and we (the RMS team) will assist you with that.

    Monday, February 20, 2012 5:22 PM
  • Glad to hear you resolved it.

    Thanks.

    Jason

    Monday, February 20, 2012 5:23 PM
  • Hey guys,

    another question: Why did nobody refer to the existing hotfix KB2596996 which is also addressed in http://social.technet.microsoft.com/Forums/en-GB/rms/thread/0ee59b53-bbf2-4376-bf94-500b17884423 ? Has anyone here experiences how stable the fix is?

    I did install it on a test machine and at a first glance it seems working.

    Kind regards,

    Marc


    • Edited by marc__ Thursday, February 23, 2012 5:55 PM
    Thursday, February 23, 2012 5:54 PM
  • Just replied. ;)
    Thursday, February 23, 2012 6:13 PM
  • As discussed, apparently the fix has been released.

    As promised, here is a link.

    http://support.microsoft.com/kb/2597941/EN-US/

    Thanks.

    Please provide feedback on whether or not this fix corrects the issue you are having.

    Jason


    Wednesday, February 29, 2012 1:07 PM
  • I'm experiencing an issue: Since I installed the fix, our templates are not displayed in the Office Products anymore.

    So far I ran some unsucessful tests:

    - Creating a new template after installing the fix

    - Set the Registry Key "AdminTemplatePath" also in the "Wow6432Node" (I use a 32-bit Office Version on a 64-bit Windows)

    - Ensured that the template's xml-files were copied to the client

    But none of my ideas showed any effect. Is there anyone having the same troubles?

    Regards,

    Marc

    • Proposed as answer by Irakli Jojua Tuesday, March 20, 2012 6:54 AM
    Monday, March 5, 2012 3:18 PM
  • Jason Tyler,

    hotfix package works fine on all office 2010 versions.

    thanks.

    Tuesday, March 20, 2012 10:48 AM
  • Install hot fix - office2010-kB2597941

    Link - http://support.microsoft.com/kb/2597941/en-us

    Thanks,

    Dilan Manjula.

    Thursday, July 19, 2012 5:51 AM
  • I have office 2010 office professional SP1 on my machine and when I tried to install  the KB2597941 and it is showing not found any product installed in this machine to patch.

    Please suggest or should I reinstall the office and install it once again.


    Amit Singh |Project Consultant (System center)

    Wednesday, January 13, 2016 11:24 AM