Zero Byte Attachments in Email Subscriptions

I had an issue a while back with RS 2000 where we would get a Zero Byte attachment when hitting a Lotus Notes server.  This ended up being corrected in KB 872774. So, when I was assigned a case with a similar description, but this time with RS 2005 SP3, my first question was “Are we hitting a Lotus Notes Email Server?”.  The answer was Yes.  It also turned out to be affecting every attachment type except for MHTML.

When we hit issues with emails, and we suspect the issue to be with the Email Server itself, we can enable the SMTP Drop Folder to see what the actual generated email looks like before we send it onto the email server.  This involves the SMTPServerPickupDirectory and SendUsing keys within the rsreportserver.config file.

Configuring a Report Server for E-Mail Delivery
https://msdn.microsoft.com/en-us/library/ms159155.aspx

We want to set the SMTPServerPickupDirectory to a local path to the Report Server.  (i.e. C:\Temp\Emails).  We also want to change the SendUsing key from 2 to 1.  This will generate the EML files to the directory specified.  These can be opened in Outlook Express.

Well that’s not good.  The attachment is actually zero’d out in the raw email.  That rules out the email server.  So, lets go back to the RS Log and bump it up to Verbose output.

ReportingServicesService!chunks!e!6/17/2009-16:53:09:: v VERBOSE: ### ChunkWriteStream - Closed! id=6b235fc9-5263-43df-8fc9-434c066c32c5, name='RenderingInfo_PDF'
ReportingServicesService!chunks!e!6/17/2009-16:53:09:: v VERBOSE: ### ID=6b235fc9-5263-43df-8fc9-434c066c32c5, Length=96284, CompressedLength=70420, TimeCompressing=162, TimeUncompressing=0, Ratio=0.731378, Buffering=1, Permanent=False
ReportingServicesService!session!e!6/17/2009-16:53:09:: v VERBOSE: Finished serializing report
ReportingServicesService!library!e!6/17/2009-16:53:09:: v VERBOSE: Transaction commit.
ReportingServicesService!session!e!6/17/2009-16:53:09:: v VERBOSE: Saved report snapshot to session in a background thread. Key=MyDomain\Adam;thnsonmxaghj14v5al2zfpih;/Reports/MyFolder/MyReport;<Parameters />
ReportingServicesService!library!e!6/17/2009-16:53:09:: v VERBOSE: Transaction rollback.
ReportingServicesService!emailextension!4!06/17/2009-16:53:09:: Email successfully sent to "adam@myserver.com" adam@myserver.com

Based on this, we know that the attachment was generated and the email was sent.  The EML file was generated.  From that I can make an assumption that the issue is in the process of generating the EML file.  We use CDO to generate the email.  Typically this is going to come down to a content /encoding issue.

If we look at the Process Monitor output at the time the email was being generated we see the following:

We see “HKLM\System\CurrentControlSet\Control\Nls\CodePage” and for 20127 the data is blank.  Here is what this key looks like on my machine:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage]
"10000"="c_10000.nls"
…

"20127"="c_20127.nls"

Here is what it looked like for the server in question:

"10000"="c_10000.nls"
"10001"=""
…
"20108"=""
"20127"=""

On the bad server, there were actually a ton of blank entries in this key.  That doesn’t look good.  We exported this key from a working machine, and then imported it to the failing machine.  Restarted the Reporting Services Windows Service, and then tested the email again.  This time the attachments were correct.

NLS stands for National Language Support.  These files are used to create consistent, globalized Windows User experiences.  The fact that we had one missing that was trying to referenced caused the attachment to not be MIME encoded properly due to the lack of the codepage.

I did a few quick searches and found that there are some tools out there that will go through and either clear or blank out these entries to try and speed windows up.  I’m not sure that that is what happened in this case as we came into the picture too late.  If you run into this type of issue, you can restore the values.  If it continues to recur, I would recommend using Process Monitor to determine what is clearing these values out.  Although you would need to know about when it is occurring.

Adam W. Saxton | Microsoft SQL Server Escalation Services