How to Fix Two Errors with SQL Server Reporting Services Subscription Issues
Recently, a client of ours had some specific issues with SharePoint and SQL Server Reporting Services (SSRS). The solutions were, I felt, rather cryptic. So I’m posting them here in hopes that they help others who may encounter these apparently rare issues.
The environment is pretty standard, one SharePoint 2013 Enterprise Edition web front end and a separate SQL Server 2012 Standard server. The reporting services service was started in Central Administration. And the reporting services SharePoint service application had been provisioned. These were done in accordance with Microsoft best practices.
Everything seemed to be good and fine. The SQL Server Reporting Services Content Types were available to libraries and reports were created using Report Builder. Wonderful…
It wasn’t until the client attempted to create subscriptions for reports that any problems surfaced. Basically, there were two problems:
- When creating a subscription with a SharePoint Document Library delivery extension, a delivery error occurs after selecting a Document Library. The error occurs despite using SharePoint’s navigation tools to locate the library.
- A subscription using an e-mail delivery extension can be successfully created. However, the subscription fails when attempting to deliver the email.
Initially, it appears as if these two issues were related. After all, they both had to do with subscriptions, and there seemed to be no other issues with SSRS. However, this wasn’t the case…
A Delivery Error Has Occurred
Let’s look at the first one. So here’s the problem in detail:
- When creating a subscription to a report, choose SharePoint Document Library as the Delivery Extension.
- Now for the Document Library, click the button to open the Wizard.
- Navigate and select the document library and click OK.
- Immediately receive an error!
Huh? The relevant part of the error is: “One of the extension parameters is not valid for the following reason: The delivery path is either not a SharePoint Document Library Folder or does not exist in the Share Point farm.” [Italics mine, the separating of Share from Point is not me].
Basically, you receive an error saying the library you selected doesn’t exist. But the library was found when using the wizard to browse to it. Infuriating.
So, what was the problem?
Once discovered, the solution was simple. The user attempting to create the report had two accounts in the site collection. One account was a claims account. The other account was non-claims.
Delete the non-claims report. All will be good.
Alternatively, you can also create a new user and use that user to create subscriptions.
Failure Sending Email
An email subscription has been configured.
When the subscription runs on its scheduled time, the email is not sent and the Last Results columns reports an error: “Failure sending mail. The specified string is not in the form required for an email address. Mail will not be resent.”
Okay, first things first. Of course you want to verify the email you configured the subscription for is valid. So yeah. Do that. After all, it kind of sounds like a problem with the email address.
But it’s not. Because even if the email is invalid, SharePoint still reports a successful send.
It seems only logical to check the Reporting Services Application service application in Central Administration. Check the email settings to make sure you are using a valid outbound SMTP server.
But that won’t be it either. Because when you have an invalid SMTP server configured, SharePoint provides the following detailed error message.
So what was the problem?
As a test, I created a test site collection and went through the process of configuring an identical scenario. Unfortunately, I received the same result.
As another test, I created a new web application. I DID NOT receive the same result. I received the report subscription without issue.
So the issue was isolated to the web application. More precisely, it was related to the IIS site for that web application.
In IIS, I looked at the SMTP E-mail settings for the IIS site:
Something identical to the following was configured:
As soon as I removed all SMTP E-mail settings, email subscriptions performed flawlessly.
Now here’s the somewhat odd thing: I tested all this on a new environment and I couldn’t duplicate the error. In fact, from my testing, the IIS settings for SMTP E-mail were being completely ignored.
So my suspicion is there was some other configuration on the client’s server that was instructing that web application to look and attempt to use the IIS settings first.
I haven’t investigated further at this time. Hope this helps!