I had someone e-mail me today about a little known *secret* regarding the RMS logging database. They asked if there was a way to make it smaller, and pick what things you want logged.
Well, one answer is you can make it *really* small by turning off logging completely through the RMS Admin console (it is just a check box)…but maybe you need some bare-bones info for reporting. I don’t recommend this if you need to do any type of reporting.
Well in the DRMS_Logging database, there is a table called DRMS_Log_Filter. If you look in this database, you can turn on, or off things that are logged. If the item is set to 1, it gets logged. If it is set to 0, it doesn’t (or a NULL gets logged for that value anyways). Pretty simple.
Note**: Make sure you restart the logging service, and issue an IISReset after making changes.**
So, how do you know what you can safely turn on and off? Well…I’m not going to tell you, because as soon as I tell you to turn it off, you will probably need it, but I can at least tell you what they do, and you can make your own decision.
HostMachineName – Pretty self explanatory. This will be the name of whatever server executed the action you are looking at. Probably pretty important to leave on, since if you have more than 1 RMS server in your cluster, and one of them keeps failing, you’ll want to know which one it is.
HostMachineRequestID – The ID of the request. Probably not very important for the average human. You aren’t going to look at the RequestID and suddenly find the problem you’ve been having with your server.
RequestTime – Again. Pretty self-explanatory. Should you keep it? Its up to you. I probably would, so if Joe Shmoe is telling me he never opened a particular piece of content, I can tell him what time he did, and hope he has an alibi.
RequestPath – This is what .asmx file they were hitting to make the request. This probably isn’t so important, because the next value pretty much tells you what file they were hitting.
RequestType – This tells you what type of request it was. If they were getting their RAC you’ll see Certification.Certify. If they were getting their publishing license (a.k.a. CLC) you’ll see GetClientLicensorCert, and if they are just getting an EUL for a piece of content you will see AcquireLicense. You want to keep this turned on. NOTE: You may see one a few GetLicensorCert entries, but that is just another server in your cluster asking for the SLC.
RequestUserAddress – Another one you probably want to keep. It tells you the IP address that the person trying to obtain whatever they were trying to obtain is coming from. NOTE: If your licensing pipeline is setup for anonymous access (i.e. for trusting TUDs or Passport) you won’t get this.
RequestUserAgent – A potentially useful value. It will tell you if they were using the Rights Management Client, or (hopefully) some third-party tool.
AuthenticatedState – My *guess* would be that this tells you if the user was authenticated or not. It is a True or False return. I suppose if your licensing pipeline is setup for anonymous only, this may return false.
SecureConnectionState – If they used HTTP or HTTPS. Some people use HTTP internally, and HTTPS for extranet access. There are other ways to figure this out, but why not keep it?
AuthenticatedID – This is going to give you the DOMAIN\USERNAME of whoever authenticated. Like I said. If you are trusting Passport or some third-party TUD, this may be blank.
SuccessOrFailure – This is definitely an important one if you do log checking. If you see joeschmoe has 500 Failures, you probably want to find out whats going on.
ReceivedXRMLDocument – This is the big blob of data that the client sent to the server. It’s going to have the info from their RAC, as well as the Publishing License (PL) of the content the person was trying to open. Do you need this info? Not really. It would help to determine whether or not the user was even in the list of people with rights in the PL, but other than that most people don’t even look at it. It’s a toss up, it takes up alot of space, and is really only going to be useful for deep forensics.
IssuedXRMLDocument – This is either going to be the RAC, CLC, or EUL that was issued to the client. Do you need it? Probably not. Another one that sucks up space, and you’ll probably never use.
MetaData – Probably a good one to keep. It tells you who the owner of the piece of conent that the user was trying to open is.
ErrorInformation – This is another toss up. I would keep it, because I have access to the source code, and its going to tell me where it failed in the source. Would 99% of regular admins use it? Probably not. If you called into support, I’d probably have you turn it back on if I needed it.
LogCreateTime – Pretty self explanatory. It may be a bit different than the RequestTime value, because by the time MSMQ gets it to you, depending on the number of requests, it may take a while.
Now I will tell you this about IssuedXRMLDocument and ReceivedXRMLDocument, they *do* have their uses for forensic type work.
If you ever want to match up a document that was opened with *who* opened it you can figure this out using that data.
Let’s say you have a word document that has been RMS protected. If you open that document with notepad and look at the headers you will see a value called <ID type=”MS-GUID”> followed by a big long ugly GUID. If you search the two aforementioned fields (actually they are s_IssuedXRML and s_ReceivedXRML) in the DRMS_Log_Master table for a match, you can find every person that tried to open that piece of content, and what the results were. Pretty cool, aye?
Maybe I’ll write a code snippet that makes the hunt easier, but I wouldn’t want to ruin the fun for all of you SQL coders.
Also kudos to the Microsoft SCOE (Security Center of Excellence) team for actually documenting this stuff in one place within the walls of Microsoft. Now…the information is *public*. Weeeeeeeeeee!