We recently upgraded our exchange environment to 2007. We are running SQL server 2005 and SSRS 2005, with no immediate plans to upgrade to 2008.However, we've just found that subscriptions from our SSRS reports are no longer working. On examining the logs, our IT guys advise that exchange 2007 will no longer translate an alias (ie Active Directory network ID) into the users mailbox, and returns an error to SSRS.They are continuing to look and see if there's a setting they can change in exchange, but don't have a lot of hope. They also advise this is a known issue with the two systems.We know that a workaround is to change the SSRS default settings so that users can edit the 'To:' field when setting up a subscription. However, we work in a prison environment and these reports are dealing with prisoner info. We are understandably quite leery about letting users set up subscriptions that can be emailed to any valid email address, both internal and external. While we could potentially block the sql sender address on the exchange server and prevent them getting outside, our preferred option - if it's a possibility - is to change the SSRS settings so the 'To:' field defaults to their mailbox rather than the network ID. Our SSRS guy with admin privileges on the server has never had to use them, so he's not that familiar with these settings.Have any of you run into this problem, and did you resolve it without upgrading to SQL2008, or allowing your users editing privileges on the 'To:' field?I'm after some ideas on ways to work around this problem, and hope you can help! :)

Hi,For this issue, please post it on the SQL server forum to get the support.http://www.microsoft.com/communities/newsgroups/default.mspxThanksAllen

I posted this initially in the SSRS forum, and I was advised there by an MSFT Moderator that it was an exchange setting, and to post it here- http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/3dc7ac17-a4ac-4334-a416-cfaa9fcd297bNow, would someone please answer the question, instead of bouncing me back and forth between exchange and SQL?

Hi,Before going on, I would like to give my understanding on this issue:The client send a request to subscribe the information from the SSRS, then the SSRS give the response to the client via Exchange server 2007. Is that right? If not, could you please describe the process how does this work for your system? This can help us understand this issue more clearly in order to the provide the solution.ThanksAllen

On Fri, 9-Oct-09 00:10:23 GMT, numbatau wrote:>We recently upgraded our exchange environment to 2007. We are running SQL server 2005 and SSRS 2005, with no immediate plans to upgrade to 2008.>>However, we've just found that subscriptions from our SSRS reports are no longer working. On examining the logs, our IT guys advise that exchange 2007 will no longer translate an alias (ie Active Directory network ID) into the users mailbox, and returns an error to SSRS.>hange in exchange, but don't have a lot of hope. They also advise this is a known issue with the two systems.>>We know that a workaround is to change the SSRS default settings so that users can edit the 'To:' field when setting up a subscription. However, we work in a prison environment and these reports are dealing with prisoner info. We are understandably quite leery about letting users set up subscriptions that can be emailed to any valid email address, both internal and external. While we could potentially block the sql sender address on the exchange server and prevent them getting outside, our preferred option - if it's a possibility - is to change the SSRS settings so the 'To:' field defaults to their mailbox rather than the network ID. Our SSRS guy with admin privileges on the server has never had to use them, so he's not that familiar with these settings.>on the 'To:' field?>>I'm after some ideas on ways to work around this problem, and hope you can help! :) Is the problem that the SQL server is sending the email using SMTP andthe recipient address isn't a complete SMTP address?e.g. SQL sends the message using "RCPT TO:" instead of the correct"RCPT TO:"If that's the case I think you can resolve this by modifying theReceive Connector to supply a default domain name:set-receiveconnector "connector-name" -defaultdomain "domain.com"Exchange 2007 is just conforming to updated RFCs that require the useof a complete SMTP email address.---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP

Hi,After working with the Jin Chen to do the research on this issue since I am not familiar with the SSRS, I suspect the issue is caused by the Receive Connector.By default, Exchange 2007 couldn't resolve the alias to the mailbox user for the SMTP communication. Thus, we need to set the defaultdomain value to your email address.For this configuration, you can implement it based on the Rich's suggestion.ThanksAllen

Is the problem that the SQL server is sending the email using SMTP andthe recipient address isn't a complete SMTP address?e.g. SQL sends the message using "RCPT TO:" instead of the correct"RCPT TO:"If that's the case I think you can resolve this by modifying theReceive Connector to supply a default domain name:set-receiveconnector "connector-name" -defaultdomain "domain.com"Exchange 2007 is just conforming to updated RFCs that require the useof a complete SMTP email address.---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP thanks Rich, I'll pass it on to the exchange admins and see what they say. I assume Microsoft never released a patch of any sort for SSRS2005 when the email RFCs were updated? So that it complied?