Dude, Where’s my CDR/Archiving/QoE Data?

Recently I had to troubleshoot a strange case where a recently OCS Archiving + Monitoring server (collocation of these 2 roles is supported) was not collecting any data. I was monitoring the data through the use of this neat Resource Kit tool:

ArchivingCDR Reporter (ArchivingCDRReporter.exe, ArchivingCDRReporter_Config.xml)
This reporting tool has built-in SQL queries to retrieve and view information from the Archiving and Call Detail Records (CDR) Backend. The tool enables the user to view Office Communications Server 2007 usage reports based on the Archiving and CDR tables.

Everything seemed to be pretty well configured, Archiving and Monitoring were enabled both at the forest level and pool level, as explained in Deploying Monitoring Server and Deploying Archiving Server.

The Operating System was Windows Server 2008 R2, but since all the steps from KB982021 had been followed, that version of OS is fully supported.

So, I had to stop for a while and think… Looking at the archiving and monitoring architecture in Office Communications Server 2007 R2 may help a little bit:

Since no data was being delivered to the DB server and the connection between the OCS Archiving + Monitoring server was OK, maybe the problem had to do with the Messaging Queuing (MSMQ) service.

In fact, the Application event log of the server had a couple of error events related with MSMQ:

The Message Queuing service rejects incoming messages when it is unable to check whether the sender is allowed access to the queue for sending messages. In this case, the queue affected is OCS-ARCH-MON\private$\lcslog, but note that an event might not be issued every time this problem occurs.
To perform this access check, Message Queuing needs access to the TokenGroupsGlobalAndUniversal attribute of the sender's user object. Only users with domain administration permissions can add members to the Windows Authorization Access Group, which is allowed access to the TokenGroupsGlobalAndUniversal attribute, in one of two ways:
1) For best security practice, add only the computer accounts that need access to the TokenGroupsGlobalAndUniversal attribute to the Windows Authorization Access Group. The domain administrator will repeat this operation for other Message Queuing computers that require the permission, manually adding the relevant accounts to the Windows Authorization Access Group.
2) As a less secure practice, add the Authenticated Users group to the Windows Authorization Access group. This grants every authenticated user, including the Message Queuing service on any computer, access to the TokenGroupsGlobalAndUniversal attribute for all users, and requires no further manual administration.

I followed the suggested recommendation of adding the MSMQ computer accounts (OCS Frontend, OCS Archiving + Monitoring) to the Windows Authorization Access Group (located in the Builtin container).

After that, in order to correct the problem, you must restart the MSMQ service on the Archiving + Monitoring server (this will also restart the OCS services). On the OCS Frontend you must also restart the MSMQ service, the QoE Agent Service and also the Frontend service. Restarting both servers will also do the trick.