CRM Organization Import Issue and SSRS MaxRequestLength

When importing an organization to CRM 2011 we came across an error during the import wizard process which was causing the import to fail:

14:54:33| Info| PublishReportsFromDatabase: Creating report in Reporting Services. ReportId: 9f973403-bc84-e111-88bc-0050569e0001, Name: INVOICE PAYMENTS
14:54:34| Error| Error while updating organization information: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Crm.Reporting.RuntimeReportServer.UploadReport(String path, Byte[] reportDefinition, String name, String description, Boolean overwriteExistingReport)
at Microsoft.Crm.Reporting.RuntimeReportServer.UploadReport(SRSReport report, String reportNameOnSrs, String name, String description, Boolean isSharedReport, Boolean overwriteExistingReport)
at Microsoft.Crm.Setup.Server.Utility.ReportsUtility.OrganizationPublishReportsScaleGroup(IDbCommand command, Uri reportingUrl, String orgUniqueName, Boolean ignoreCustomReportsFailure, Boolean publishOnlyCustomReports)
at Microsoft.Crm.Tools.Admin.DBImportHelper.RePublishReports(IDbCommand command, Guid organizationId, String organizationUniqueName, Uri reportUrl)
at Microsoft.Crm.Tools.Admin.ImportOrganizationInstaller.UpdateOrganizationInfo(Guid organizationId, OrganizationGroupsInfo organizationInfo, String organizationFriendlyName, String organizationUniqueName, Uri reportServerUrl, Int32 PercentUpdateOrganization, ICollection`1 users)

This was not an upgrade of any sort – just simply a CRM migration to a new environment so there were no versioning differences from a CRM perspective. While the error above is lacking much detail, it did give us enough to begin troubleshooting. We could clearly see that this issue was occurring with a report titled “Invoice Payments” but knew nothing else. After obtaining a copy of the report’s RDL file, we didn’t notice anything wrong in particular with the way the report was written but did think it was rather large for an RDL file – nearly 5MB – there were quite a few embedded images.

We decided to attempt uploading the report directly into SSRS and were met with a much more helpful error message – “Maximum request length exceeded”. What this was telling us rang a bell with what we noticed earlier regarding the RDL file size. By default, SSRS has a limit on the report file size that it will allow to be imported. This limit is 4MB but can be increased by doing the following:

Open the web.config of the Report Manager (%\Program Files\Microsoft SQL Server\MSSQL.X\Reporting Services\ReportManager) and find the “executionTimeout” setting. It should look something like this:

On this line, add the maxRequestLength attribute with the value (in KB) needed to upload the report. This value is not in here by default. It should now look like this (this shows a 10MB limit):

Save the file and then repeat these steps in the web.config of the Report Server (%\Program Files\Microsoft SQL Server\MSSQL.X\Reporting Services\ReportServer). Once both files have been modified and saved, restart the SSRS service.

Following this change, we were able to upload the RDL to SSRS directly to verify that the change worked and then subsequently were able to complete the organization import for CRM without issue.

CRM 2011: The Item ‘/SharedReports/5.0.xxxx/MSCRM_FetchDataSource’ cannot be found

Installation of the Microsoft Dynamics CRM Reporting Extensions formally known as the SSRS Data Connector (Still in on the installation media in same folder) is necessary so that CRM and SQL servers can communicate over the kerboros double hop issue when using to seperate servers.

The error below was received because a SQL Server was replaced the SSRS Data Connector was not added back in.

This key is the word ITEM cannot be found. This simply means the SSRS data connector cannot find the original reports. It turns out the report databases that support SSRS were completely removed, disgarded when the SQL server was rebuilt, so the CRM reports were now missing. (Note: Custom Reports would have been deleted and cannot be restored using this procedure. A backup of the ReportDB\ReportTempDB would be required, with a repair of SSRS to get those reports working again).

In order to fix this, remove and reinstall Reporting Extensions first, then run the command line tool from the crm server directory C:\program files\Microsoft Dynamics CRM\Tools\  to recreate/republish the reports by typing the following command :

publishreports ORGNAME  – Organization name of the CRM Installation Missing Reports

Once completed, issue an IISRESET on the crm server. Then navigate back into CRM report section and run/find your missing reports! There are several other topics covered on this blog around SPNs and Service Accounts that could also be an issue if your reports are not working. Take a look! Enjoy.

Fixing CRM 2011 Reporting Issues with SPNs

A best practice is to install CRM using service accounts. Most administrators will do the same for SQL Server.  Many of the warnings about SPN’s during the install are igorned users. Many DBA’s will change the SQL service accounts after installation which will also cause issues.
CRM 2011 offers a new service called the Sandbox processing service. Failure to set the special SPN for this service while trying to run custom reports created with the report wizard will result in RS failure message.
Let’s make sure your CRM Server it setup in AD to allow delegation on the second tab.








Next, check the SPN for the CRM server so that it has HTTP using the following command:
setspn -L ( crm service account)
Look for http/servername and http/servername.FQDN you will need both.
To set them if missing:
setspn -A http/crmservername domainname\crmservice account
setspn -A http/ domainname\crmservice account

To view use the setspn -L with the service account name to see http has been set. (See screenshot below)

Now, on to the secret spn for the sandbox service..

setpsn -A MSCRMSandboxService domainname\crmsandbox service account

Once that has been completed on the CRM server, now head over to the SQL Server and check the service accounts for SQL. Let’s assume they are running under a SQL Service Account. IF the SQL service accounts were specified during the original install, the SPNs were created automatically. If not…

setspn -L domainname\sql service account to see the spns.

Again, you should see the 2 entries one with FQDN for MSSQLSvc. If not,
setspn -A MSSQLSvc/ domainname\sql service account
setspn – A MSSQLSvc/ domainname\sql service account

to review, setspn -L domainname\sql service account should now show the correct SPN’s. You must have domain priviledges to set the SPN’s and if you have multiple AD machines it will take time to replicate the changes across.