Monitoring Server generates error when viewing reports

  • Article

<Update May 11, 2009 - Thomas Binder was kind enough to point out this troubleshooter on Technet that one of his partners used to solve their problems>  

I had a question last week about my Monitoring Server setup and while we did not get all issues resolved, Windows 2008 and IIS7 involves a learning curve. My entire topology is Windows 2003 R2 which I am thankful for as setup has been rather straight forward but it then limits my ability to share experiences for your Windows 2008 issues. One thing I will share is that IIS7 looks to require that a certificate be requested and imported via its interface and not simply be installed on the system by choosing to import the cert when you requested it via the CA website. We didn’t dig too far once it was working but if you have information to share please share if we missed something.

This post is a result of connecting to the system after about 2 weeks of not touching it, never a good thing with VMs and sure enough when I went to confirm the Devices PSTN report I faced an error – (I made a bulleted list to reduce the amount of space it took up)

  • An error has occurred during report processing. (rsProcessingAborted)
  • Cannot impersonate user for data source ‘QMSDB’. (rsErrorImpersonatingUser)
  • Logon failed. (rsLogonFailed)
  • For more information about this error navigate to the report server on the local server machine, or enable remote errors.

Looking at SQL 2005 I noticed my databases weren’t started, scratch that, Monitoring was started but not Group Chat, Archiving, or my pool backend. Needing those I started them and then started the SQL Server Agent (honest – I started any non-disabled SQL service) but that didn’t fix it, so I went to the SQL Server event viewer and didn’t find enough to help there. So I paused and opened a report again, this time noticing it prompted for my credentials and then I remembered the annoying issue with LCS/OCS/OCSR2 setup for service accounts – they are not exempt for account expiration. Sure enough if you change the properties for the user object to never expire password, it works.

Notes per the fact I had to enable/disable this to confirm the error messages and behavior. First, opening the Monitoring Report url on the SQL Server where I have Monitoring installed, the errors improve – The user’s account has expired. Second, to reproduce this I selected the Account Expiration attribute with a date in the past, turns out that field doesn’t get set back to none when you change the password expiration check box – this is what happens when you try to reproduce something in a less than systematic approach.

TomL LCSKid