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.

SSIS: The module containing "%1" cannot be located, even though it is registered.

Last weekend our SQLServer 2005 server was migrated to a new domain. On the Monday morning, all our scheduled SISS packages started failing.

The errors indicated that all the transform tasks within the package were failing with a "The module containing "%1" cannot be located, even though it is registered." error. The only thing that had changed between Friday and Monday was the AD migration. A quick test of some of the packages confirmed that they ran on my local machine but not on the server.

Initially I suspected permissioning problem. I logged in using the new domain account of SQLAgent and used DTSRunUI to test one of the failing packages. The package failed with the same error as the scheduled job. I then logged in using the old SQLAgent account and re-ran the package. It failed with the same error. OK then, maybe it wasn't permissioning after all. I opened the dtsx file in a text editor and looked for one of the transform components:

<component id="97" name="Data Conversion 1" componentClassID="{C3BF62C8-7C5C-4F85-83C3-E0B6F6BE267C}" description="Data Conversion" localeId="-1" usesDispositions="true" validateExternalMetadata="True" version="0" pipelineVersion="0" contactInfo="Data Conversion;Microsoft Corporation;Microsoft SqlServer v9; (C) 2005 Microsoft Corporation; All Rights Reserved; http://www.microsoft.com/sql/support;0">

I copied the class ID and did a search in the registry.

I checked the path and discovered that the PipelineComponents directory was missing. A quick search found it in a nearby directory. With all the messing around on the server it looks like a slip of the mouse had moved the directory. Once restored, everything started working again.

In hindsight the problem was simple but it took some time for me to look beyond permissions and pick the physical package apart. Once I did that the problem was solved in minutes.

Lesson learned!

MSMQ Private versus Public queues

It's time again to change AD domains and migrate users and servers. From previous experience this has always been a painful process. At the moment I'm looking at MSMQ. In the past I've created queues as public. My reasoning being that public queues are more accessible than private queues and having them visible on AD is a good thing, right?

Well, no. Given the appropriate permissions you can access private queues from remote machines as readily as public queues. The main differentiators between public and private is that public queues are published on the AD domain, are browsable and can use MQ routing. All my applications use point to point connections and I don't MQ routing at this point. By not using these features, public queues have become more of a negative than a positive, especially with this domain move imminent.

The moral of the story is unless you have specific need of routing or managing the queues through AD, private queues are the way to go.

This technet article provides a more in depth description of the differences.