ITPIP
asked on
Scan to email over WAN exchange 2010
We have a user that is in a remote office and scans to our email server, we had his printer smtp pointed to our wan but since moving to from exchange 2003 to exchange 2010 it is no longer working.
His scanner says it is sent successfully but it never gets to his mailbox.
Any ideas?
His scanner says it is sent successfully but it never gets to his mailbox.
Any ideas?
Adam Brown
In Exchange 2010, create a new receive connector and configure it with the IP address of the scanner or IP that the Scanner is using publicly if it's going over the Internet and not through a VPN. http://zahirshahblog.com/2010/08/14/14-august-2010-1624/ has some more specific info.
As long as the user is sending to an internal mailbox and not sending to anyone external, you shouldn't need to do anything. Email from a remote server is the same, whether it is a scanner or a mail server.
An additional Receive Connector would only be required if sending to external recipients.
I would expect it is being blocked or dropped by an antispam tool. Do the messages appear in Message Tracking?
Simon.
An additional Receive Connector would only be required if sending to external recipients.
I would expect it is being blocked or dropped by an antispam tool. Do the messages appear in Message Tracking?
Simon.
ASKER
The printer is not on our network, but sending to our internal exchange server. I've checked our spam tools and no logs of the email arriving. The current set up on the printer is the SMTP is set to our WAN IP using port 465, the document will scan and say successful but email never arrives. If I change the SMTP port on the printer to 25 it says SMTP error and fails.
I set up the connector mentioned by acbrown but that didn't seem to make a difference. Is there a way to specify what port remote IP's use for the receive connector? I see a place to change for internal IP's but nothing for remote.
I also do not see the messages in message tracking.
I set up the connector mentioned by acbrown but that didn't seem to make a difference. Is there a way to specify what port remote IP's use for the receive connector? I see a place to change for internal IP's but nothing for remote.
I also do not see the messages in message tracking.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Are you using an external provider to filter your email?
You do not need to change anything to have Exchange accept the email, if Exchangeis accepting email driectly from other servers. This is just another email server sending email.
Instead of looking at the Exchange connector configuration (which is a waste of time) you need to look at what Exchange is doing with the message.
Simon.
You do not need to change anything to have Exchange accept the email, if Exchangeis accepting email driectly from other servers. This is just another email server sending email.
Instead of looking at the Exchange connector configuration (which is a waste of time) you need to look at what Exchange is doing with the message.
Simon.
ASKER
Sembee our set up is a SonicWall ES that we manage then an encryption relay then to exchange. I have checked all three and I cannot see the message actually hitting any of them after being sent from the printer.
Unfortunately the user left for the day I haven't been able to do much testing since the first comments. I will follow up tomorrow.
Thanks for all the help!
Unfortunately the user left for the day I haven't been able to do much testing since the first comments. I will follow up tomorrow.
Thanks for all the help!
Just point the scanner at your MX record host name, nothing else should be required. If you are using an appliance you might have to white list it to ensure it doesn't get blocked, but that is all. Don't add in more complexity than you need to.
Simon.
Simon.
ASKER
Tested this morning after making changes suggested by acbrown2010 and everything is working.
Thanks for the help everyone.
Thanks for the help everyone.