Failing e-mail subscriptions in reporting services

Hi.

For two full -and stiff- days I have been trying to overcome this error; "Failure sending mail: The filename, directory name, or volume label syntax
is incorrect. Mail will not be resent", when subscribing to reports in repor
ting services.

I have read just about every post/blog/article remotely related to mailing through subscription in reporting services but none has helped me in my quest for succes.

So here's a summary of the efforts made so far:

1: I have setup a local SMTP server to relay from Reporting Services, since the remote SMTP server needs to be handed credentials .

  • I have verified that the local SMTP is functioning by telnet'ing through it.
  • Furthermore I have pieced together a lille C# program which also successfully can get relayed through the local SMPT.

So I do no expect the problem to relate to the local SMTP-server.

2: I have succesfully been able to deliver subscribed reports to a filshare

So I do not expect the problem to relate to setting up - and executing - timed subscriptions.

3: I have setup Reporting Services to deliver mails in the local pickup directory, through configuration manager.

  • I have instructed Reporting Services to deliver mails to the same directory, used by the local SMTP server, by hand editing the <SMTPServerPickupDirectory> tag in RSReportServer.config.
  • I have also ensured that <SendUsing> is 1 (for local)
  • Furthermore I have ensured that the <From> tag is supplied with same mail used from telnet and set <SendEmailToUserAlias> to false (and supplied the mail, when setting up a subscription).

But I have not been succesfull in getting anything from reporting services into the pickup (or queue) folders of my SMTP-server.

4: I have :

  • tried to vary my usage of service-account both in Reporting services and in the local SMTP server.
  • I have tried to send subscribed mails with link, without link, with reports of different formats.

But still no luck.

5: I saw a post claiming there might be a race condition between reporting services delivering and SMTP fetching from the same folder.

  • Even though I have turned off the SMTP-service nothing arrives at the pickup folder

I therefore see no reason for suspecting race condition to be the culprit.

So what is left?? What am I missing?

Oh yeah, the setup:

Windows server 2008r2 with SQL server 2008r2 running a Enterprise edition of Reporting Services in native mode side by side with a local SMTP server (set up through IIS6.0 and verified in IIS 7) on a vmWare box with Active directory.

I sincerely hope any of you could assist me in finding the cause for all my troubles since I'm to deliver this system Tuesday

Should any additional information be needed I stand available from now until delivery or the problem is solved :-)

Kind Regards

The struggeling Dane


  • Edited by The_Grateful Saturday, October 13, 2012 11:24 AM
October 13th, 2012 11:22am

Hi,

I'm actually struggling with this exact error at the moment, and have a similar configuration to you.

Wondering if you've been able to resolve the issue and meet your deadline - and could therefore shed some light on how you fixed it!

Many Thanks,

Zach

Free Windows Admin Tool Kit Click here and download it now
October 16th, 2012 11:37am

Hi,

If you log to your SSRS box via RDP and ping the SMTP box from there, do you get the proper IPv4 address?

I had a similar issue in the past, when my SSRS box tried to ping the SMTP server it always returned its IPv6 address instead of the IPv4 one.

My network admin changed network settings on SSRS (to return IPv4 first) and everything started working as expected.

October 16th, 2012 1:41pm

Hi Sebastian,

Thanks for the reply - I've just pinged the SMTP server from our SSRS server, and am getting an IPv4 back...

Free Windows Admin Tool Kit Click here and download it now
October 16th, 2012 3:10pm

Please, post the SSRS log file right after your email subscription fails.

It's usually found under C:\Program Files\Microsoft SQL Server\(instance)\Reporting Services\LogFiles

October 16th, 2012 3:13pm

Everything I've read online suggests SSRS isn't finishing writing the file before it tries to send it, but I've no idea how to work around that.

From the Log:

10/16/2012-13:49:09:: e ERROR: Error sending email. System.IO.FileNotFoundException: The filename, directory name, or volume label syntax is incorrect.

   at ReportingServicesCDOInterop.MessageClass.Send()
   at Microsoft.ReportingServices.EmailDeliveryProvider.EmailProvider.Deliver(Notification notification)
notification!WindowsService_39!9dc!10/16/2012-13:49:09:: e ERROR: Error occured processing subscription 0829e418-509b-4358-8cf3-b86c9f7e2563: Failure sending mail: The filename, directory name, or volume label syntax is incorrect.
Mail will not be resent.


Free Windows Admin Tool Kit Click here and download it now
October 16th, 2012 3:21pm

I kind of remember that if you create the notification for yourself, it won't work. You'll have to use the reporting service account to create the notification.

October 16th, 2012 5:17pm

Hi,

Please open rsreportserver.config on the SSRS box and provide us the value of SMTPServerPickupDirectory parameter.

If there's something, check that SQL Server Report Service has full rights on that folder.

If that parameter is empty, please create a folder, give full rights to SSRS service on it, then change rsreportserver.config appropiately, you'll

have to bounce SSRS afterwards

Free Windows Admin Tool Kit Click here and download it now
October 16th, 2012 5:41pm

Hi all.

Sorry for the late return.

@Zach: No, I didn't manage to get it to work. I ended up programming some smelly code creating a report and dumping it to a share. Afterwards I could take the newly created report and mail it in code also. Ended up in approx. 4 hours of coding just because I couldn't solve the original problem.

@Zach: I'm not sure if the problem is related to race conditions (trying to send before write is completed) because then the mail should exist in the pickup-folder when the SMTP-service is stopped. This I have tried and no mails arive to the pickup folder.

@Perry: I'm not sure if I'm understanding correctly. But here's how I do (as the customer would):

Open Report Manager -> go to my subscriptions -> Edit an existing subscription -> adjusting the time -> hit ok. Await the time hit refresh and sees the error.

@Sebastian:

I have verified that the external SMTP server is returning a proper ip4 header. The internal isn't reachable from the outside, its just relaying.

Here's the relevant sections of rsreportserver.config.

<Extension Name="Report Server Email" Type="Microsoft.ReportingServices.EmailDeliveryProvider.EmailProvider,ReportingServicesEmailDeliveryProvider"> <MaxRetries>3</MaxRetries> <SecondsBeforeRetry>900</SecondsBeforeRetry> <Configuration> <RSEmailDPConfiguration> <SMTPServer></SMTPServer> <SMTPServerPort></SMTPServerPort> <SMTPAccountName></SMTPAccountName> <SMTPConnectionTimeout></SMTPConnectionTimeout> <SMTPServerPickupDirectory> C:\inetpub\mailroot\Pickup </SMTPServerPickupDirectory> <SMTPUseSSL></SMTPUseSSL> <SendUsing>1</SendUsing> <SMTPAuthenticate></SMTPAuthenticate> <From>user@domain.net</From> <EmbeddedRenderFormats> <RenderingExtension>MHTML</RenderingExtension> </EmbeddedRenderFormats> <PrivilegedUserRenderFormats></PrivilegedUserRenderFormats> <ExcludedRenderFormats> <RenderingExtension>HTMLOWC</RenderingExtension> <RenderingExtension>NULL</RenderingExtension> <RenderingExtension>RGDI</RenderingExtension> </ExcludedRenderFormats> <SendEmailToUserAlias>False</SendEmailToUserAlias> <DefaultHostName></DefaultHostName> <PermittedHosts></PermittedHosts> </RSEmailDPConfiguration> </Configuration> </Extension>

As can be seen the SMTPServerPickupDirectory isn't empty. And the user account setup as service account in report services configuration manager is setup with full rights to do anything to the folder. The same account is used to logon to the following services; sql server agent, sql server reporting services and sql server integration service.

So I'm not sure what to do in order to eliminate the smelly code.

Any suggestions?

R

October 19th, 2012 1:05am

I think it's just worth a try.

Login as the reporting service account, then do the same steps.

Free Windows Admin Tool Kit Click here and download it now
October 19th, 2012 3:14am

Hi The_Grateful,

Based on the error message, there are several suggestions for your reference:

  • Make sure the email sender user has the Write permission on the target folder.
  • Add a relay for the email sender user account.
  • In the RSReportServer.config file, verify that <UrlRoot> is set to the report server URL address.
  • Set DefaultHostName to the Domain Name System (DNS) name or IP address of the SMTP server.

Hope this helps.

Regards,
Mike Yin

October 19th, 2012 9:36am

Hi again.

@Perry: I created a new account for the reporting services services-account (the former were the Built-in network service). Gave the new account write-permissions at the pickup-folder. Logged in with the new account, created a subscription and experienced exactly the same...

@Yin:

    • Returning to the built-in network service account. It has write permissions (actually full-permissions) for the pickup- and queue-folders.
    • The local smtp is set up as relay with anonymous access (since it delivers credentials for the external SMTP), so there would be no need for a particular user-account, right?
    • The UrlRoot is setup as the external ip for the reportserver; http://External-IP:80/ReportServer
  • I had't paid attention to this before, but just to make sure: I should provide informations about the local SMTP-server?

Regards

Free Windows Admin Tool Kit Click here and download it now
October 19th, 2012 10:59am

Is the firewall open between your SSRS and your SMTP servers?

Log to SSRS via RDP, then open a DOS prompt.

Try the following

telnet <your smtp server> 25

If you get a blank screen then SMTP port is open

If you get a connection error, then you know the cause...

October 22nd, 2012 12:22pm

Hi Sebastian.

I'm gratefull You persists troubleshooting the problem.

But as described I'm able to mail from the server - which have the SSRS and the local SMTP (relay) - through TELNET. I by the way use port 587 to avoid being junked.

So the firewall isn't the problem either.

Think I have to call MS, to get a fix in stead of the smelly code.

Regards

Free Windows Admin Tool Kit Click here and download it now
October 22nd, 2012 9:29pm

Hi The_Grateful,

Thanks for your posting.

By default, SSRS uses port 25 for the E-mail delivery. Since you are using prot 587, please specify 587 for the <SMTPServerPort> element in the RSReportServer.config file.

Regards,
Mike Yin

October 23rd, 2012 12:59am

Well... that may explain your issue.

SSRS expects to communicate to SMTP via TCP port #25, not #587.

As Mike Yin explained below, there's a parameter to configure SMTP port to non-standard values (like yours)

Free Windows Admin Tool Kit Click here and download it now
October 23rd, 2012 12:21pm

Hi both.

Sorry for the late, late, late reply, but quite frankly I'm getting frustrating about this issue.

I have tried to change the port number  in the reportserver.config, but to no avail.

And, to me, that seems logical since, when using a local SMTP-server as relay, all the reportserver needs to do is to deliver mails in a dropfolder. The local SMTP-server then observes the arriving file and relay the mail throught the appropriate port.

Regards

The gratefull

October 31st, 2012 8:27am

Hi all.

Just for the sake of completeness...

I contacted Microsoft regarding this issue.

They requested specific informations, using logs from Reporting services, procmon etc, config files and so forth. From this information they discovered a fault in the settings within the DB;

"So the report server windows service tries to create a  file

' C:\Windows\System32\                                                                                                             C:\inetpub\mailroot\Pickup

                                                                                              \1be4.47c7204e.eml'"

Meaning the email-delivery extension tried to write to a illegal path. Not that I had supplied a illegal path, but somehow two paths were stored in the same variable in the DB.

So within one working day they supplied me with simple solution:

  • Create a new folder for the email-delivery extension to deliver to.
  • Setup the email-delivery extension to deliver mails there.
  • Restart SSRS and execute a subscription.

When successfull, alter back to the previous setting.

Et Voila...... it works.

So no troubles with the SMTP (or ports) but simply a "fluke" accident.

I would never have thougth this could happen and consequently wouldn't be able to solve it my

Free Windows Admin Tool Kit Click here and download it now
November 7th, 2012 10:24am

Hi  The_Grateful,

I am glad to hear that the issue has been resolved. Thanks for your valuable sharing. I believe more community members who face with the same problems will benefit from this thread.

Regards,
Mike Yin

November 8th, 2012 1:23am

Hello The_Grateful,

Even I am facing the same problem and I have done the changes mentioned by you, still I am getting the error. Could you please provide the screens where you had done the changes and please provide the Microsoft email id or calling number so that I can talk to them and get resolved the issue.

The report is getting generated and saving in the specified file system when "Windows File share" is selected. Please help.

Thanks,

Vanishree KS

Free Windows Admin Tool Kit Click here and download it now
April 10th, 2013 5:08am

Hi all,

Was having the exact same issue as this. It came down to having the trailing \ at the end of the path in the pickup directory.

So the path should read - c:\inetpub\mailroot\Pickup\ 

As soon as I added the trailing slash mail started to flow.

Ensure that SendUsing is 1 (for local service) and SMTPAuthenticate is set to 2 (for NTLM auth) in your RSReportserver.config file.

August 17th, 2015 9:19pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics