Translate this site using Windows Live Translator:
Fixing your half-baked ADRMS upgrade - Post Mortem - RMS: Protecting Your Assets. - Site Home - TechNet Blogs

RMS: Protecting Your Assets.

The Protecting 'My' Asset Disclaimer: This is my 'un-official', 'in my spare time', 'use at your own risk', all things RMS (Rights Management Services), IRM (Information Rights Management), IPP (Information Protection Pla

Fixing your half-baked ADRMS upgrade - Post Mortem

Fixing your half-baked ADRMS upgrade - Post Mortem

  • Comments 1
  • Likes

I've had a few customers call me recently that for whatever reason, they ended up with a half-baked upgrade. By half-baked, I mean that your DRMS_Logging database, and your logging components do not get updated. By *upgrade* I mean from RMS V1 to ADRMS on Windows 2008 (Not RMS V1 service pack upgrade).

You'll know if you are in this state because your DRMS logging database will only contain 3 tables (Log_Filter, Log_Detail, and Log_Master) instead of 13 new tables (BadQueueDataLog, Certificate, CertificateType, ErrorDescription etc..).

There are a couple reasons that your ADRMS upgrade could end up in this state, but I'll give you two of them.

WARNING: MAKE SURE YOU HAVE A BACK-UP OF YOUR SLC, AND TPD CERT BEFORE DOING *ANYTHING*.

1.) You've done an in-place upgrade, and did not complete the entire process. Once you do an in-place upgrade (installing 'over the top of' 2003) there are some extra steps that need to be completed that are written in 'red' after the upgrade. If you haven't completed these steps, your logging components will not be upgraded.

2.) You did a join upgrade, and used the wrong private-key password. Normally this will result in an error, but can get you into a half-baked state so *make sure when you are doing a join upgrade that you *know* your private-key password. Don't guess. (The developers are looking at this issue, and may change the order in which we alert the user, so nothing gets updated if the wrong password is used).

Anyways, what happens when you get ino this state is that your DRMS_Config database gets updated, but nothing else does. Unfortunately, the next time you try to upgrade, nothing happens. You'll probably also see this error in your event log:

Source: Active Directory Rights Management
EventID: 70
Task Category: Logging

"The Active Directory Rights Management Services (AD RMS) logging services could not write to the AD RMS logging database. It will try to write the last message to the AD RMS logging database. All other messages will not be read from the Message Queuing until the AD RMS logging database is available."

(Then a whole buch of code you probably don't care about.)

Before, you fall on the floor screaming "why me?!?" like an olympic skater that just met the heavy end of a steel pipe, here is what is happening.

During the upgrade ADRMS looks at a value called ADRMSFileVersion in the DRMS_ClusterPolicies table of the DRMS_Config database to see if the upgrade has already been done. If the value is set to 5.2.3790.300 it say "Hey this is old, and I need to upgrade all of my databases", if it is newer (I don't know the exact value right now), it won't upgrade.

So..to trick ADRMS into thinking it needs to upgrade everything again, remove the ADRMS role from the machine, set that value in the database to 5.2.3790.300 and then add the role back. This should force the ADRMS installation to act as if it were upgrading a 2003 install, and create all necessary upgrade steps. Easy Peasy.

Love and kisses,

-Jason

Comments
  • Great stuff, Jason, as always- thanks!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment