Monday, March 28, 2011

SQL Report Server - The report server has encountered a configuration error

It's been a week of niggling problems since our SQL Server 2005 machine was migrated to a new domain. In this instance we have a report server hosted on a separate machine which hasn't been migrated yet. A number of reports on the machine have subscriptions set up. On the Monday after the migration, they all started to fail.




Firstly, I had a look in the log file. For me the log files were located here:
C:\Program Files\Microsoft SQL Server\MSSQL.1\Reporting Services\LogFiles
Digging through the overly verbose log information I found the following error. The job was failing due to an authorisation issue. I've highlighted the relevant part of the error.

ReportingServicesService!library!4!03/21/2011-20:56:09:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The report server has encountered a configuration error. See the report server log files for more information.,
AuthzInitializeContextFromSid: Win32 error: 110;
Info: Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The report server has encountered a configuration error. See the report server log files for more information.
ReportingServicesService!library!4!03/21/2011-20:56:09:: i INFO: Initializing EnableExecutionLogging to 'True' as specified in Server system properties.
ReportingServicesService!emailextension!4!03/21/2011-20:56:09:: Error sending email. Microsoft.ReportingServices.Diagnostics.Utilities.RSException: The report server has encountered a configuration error. See the report server log files for more information. ---> Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The report server has encountered a configuration error. See the report server log files for more information.
Running the reports manually worked, it was just the subscriptions that had the problem. In my case the report server back end was hosted on the database server that had been migrated so I focused my attention on that server.

When a new subscription is created, a SQL Agent job is created with GUID.



Not exactly user friendly but it was enough for me to narrow down that the root of the problem lay with SQL Agent.


The SQL Agent service account was in the local admins group so I assumed that should give it the carte-blanche needed to run unrestricted. Using Computer Management and looking at the Local Users and Groups I found a cluster of SQLServer related groups.




One group in particular was of interest to me, the SQLServer2005SQLAgentUser$(machinename)$MSSQL. It contained the old SQL Agent service account but not the new account. Adding the new service account fixed the problem.




After some additional research, I discovered that if I had modifed the service accounts using the SQL Server configuration manager rather than through the SCM, the new service account would have been automatically added to this group.


Yet another lesson learned.

No comments:

Post a Comment