Intermittent Scan to email funcitonality
-
@ajstringham said:
Usually scanning to email fails due to DNS issues. It has trouble resolving the mail servers using SMTP. Can you post your SMTP server settings, within reason? Check your DNS settings though. That's what I see most often.
It has worked for 2 years. been on the ERL for 6 months. DNS is unchanged. it works both by DNS name and by IP. It also fails by IP and DNS name. DNS is not the problem.
To ensure DNS is not the problem I have changed all of the units to use the IP though.
-
@JaredBusch said:
@ajstringham said:
Usually scanning to email fails due to DNS issues. It has trouble resolving the mail servers using SMTP. Can you post your SMTP server settings, within reason? Check your DNS settings though. That's what I see most often.
It has worked for 2 years. been on the ERL for 6 months. DNS is unchanged. it works both by DNS name and by IP. It also fails by IP and DNS name. DNS is not the problem.
To ensure DNS is not the problem I have changed all of the units to use the IP though.
What are you using for email? Are you on an on-premise Exchange, or are you on Office365?
-
@ajstringham said:
What are you using for email? Are you on an on-premise Exchange, or are you on Office365?
On premise Exchange 2010. Nothing has been changed on the email server prior to the failure. Since then I have modified the receive connectors a few times for testing.
-
Just changed it back to use authenticated and it worked again. This is what keeps happening. It works then fails then works then fails.
-
Are they all on the same switch?
-
@Dashrender said:
Are they all on the same switch?
@JaredBusch said:
The three units that are located in the Branch offices have suddenly all started failing to send emails
-
OK so no, not on the same switch.
Can you look at verbos logs on the VPN endpoint at the location where the Exchange server is to see if you are seeing the traffic destine for Exchange? Are there any new errors?
-
@Dashrender I rule out the tunnels being a problem because the branch office all use RDP in to a RdS server all day long and have zero drops or failures.
-
While I'd love to think that, each protocol does its own thing.. SMTP and RDP who knows, I've seen stranger things happen.
-
Check firewall rules. That's the only other thing I can think of. If it's not DNS, and other services are having no issues over the VPN, check the firewall. See if it's blocking it for some odd reason. Even add a manual exception if you have to.
-
@ajstringham said:
Check firewall rules. That's the only other thing I can think of. If it's not DNS, and other services are having no issues over the VPN, check the firewall. See if it's blocking it for some odd reason. Even add a manual exception if you have to.
It works sometimes. That is not a firewall rule to me, but I have looked. There are no rules that would block port 25 being applied to this IP. Even if their was, they would make the NAS not work also. Here is a screenshot of the NAS and the HP in one location. One works one does not.
Note the IP, they are both in the same place. sitting right next to each other in fact. Yet one works everytime (NAS) while the other only works sometimes (HP).
-
The HP Event log shows the servier is unavailable. Yet it is obviously available because the NAS works.
-
The router does have a rule to block SMTP unless it is bound for 10.202.1.14
I can watch the allow stats increment when I send a successful email from the NAS and on the rare times that the HP sends. But when the HP fails, the Deny rule does not change. It is not being hit.
-
For troubleshooting, I also created an new allow rule on the Windows firewall of the exchange server. Again should not be relevant because the NAS works, but still.
Not showing each tab, but basically allow all port 25 from any remote IP to any local IP.
-
The receive connectors allow the entire remote subnet at the moment. I originally had it set to the various printer's specific IP.
I move the networks between auth and anon as needed when testing.
-
Ok, I am thinking that you need to see if there is a firmware update for the printers. Can you get us the firmware it's on, and we'll see if it's on the latest version? Maybe it's a bug that got worked out.
-
@ajstringham said:
Ok, I am thinking that you need to see if there is a firmware update for the printers. Can you get us the firmware it's on, and we'll see if it's on the latest version? Maybe it's a bug that got worked out.
All printers are now on current firmware as of last week. HP support already went down that route. Sorry for not mentioning that already. They were only one rev behind anyway.
-
@JaredBusch said:
@ajstringham said:
Ok, I am thinking that you need to see if there is a firmware update for the printers. Can you get us the firmware it's on, and we'll see if it's on the latest version? Maybe it's a bug that got worked out.
All printers are now on current firmware as of last week. HP support already went down that route. Sorry for not mentioning that already. They were only one rev behind anyway.
Hmmm....I can't remember. Did you run a continuous ping test against it when you were testing SMTP? Could you have some bad JetDirect cards?
-
Yes, I had a ping 10.202.10.20 -t running from the mail server for the last 5 days.
-
@Dashrender asked earlier about them being on the same switch. Could there be a middleman networking device killing the connection somewhere? An L3 switch or something similar?
