I would like to test the link between the IP office 500 and the clients exchange server for connectivity to port 25 for vmail to email transfer. Is there a test built into IP office accessed by system status or monitor or a telnet command string or something to do so in IP office ?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Testing SMTP connect to IP office 1
- Thread starter 8865
- Start date
Kyle Holladay / IPOfficeHelp.com
ACSS/ACIS/APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA
"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford
Other than a ping I do not beleive there are tests available to test SMTP.
You need to be able to telnet to port 25 ( if that is the default port)of the exchange server. and It has to be able to do SMTP relay.
If you have VM pro you could try from that machine.. if not you can try from a machine on same network..
You need to be able to telnet to port 25 ( if that is the default port)of the exchange server. and It has to be able to do SMTP relay.
If you have VM pro you could try from that machine.. if not you can try from a machine on same network..
- Thread starter
- #4
kholladay;
Reviewed your link and we are using embedded EVM , the first thing I see is that we are not connected correctly your debug references the lan port 1 [192.168.42.1] and we are connected on lan 2 , I assume that IP office is defaulted to lan 1 for email feature so even though we can ping the ip office 43.1 lan 2 the IP office is pushing email notification on lan 1 we have to swap around and get on the right page to be successful then try the debug. Strange that there were no alarms in monitor or status to indicate that lan 2 or lan 1 were faulted , trace shows the attempt as qued however. will follow-up thread as to result
Reviewed your link and we are using embedded EVM , the first thing I see is that we are not connected correctly your debug references the lan port 1 [192.168.42.1] and we are connected on lan 2 , I assume that IP office is defaulted to lan 1 for email feature so even though we can ping the ip office 43.1 lan 2 the IP office is pushing email notification on lan 1 we have to swap around and get on the right page to be successful then try the debug. Strange that there were no alarms in monitor or status to indicate that lan 2 or lan 1 were faulted , trace shows the attempt as qued however. will follow-up thread as to result
-
1
- #5
Try this;
Register:
Enter the following in the Manager > System > SMTP;
IP: 213.165.64.45
port: 587
email from address: you@gmx.com/us
server requires auth: ticked
user name; you@gmx.com or .us
password; your password
use challenge response auth: unticked
Then on the User > Voicemail > Voicemail email
enter the "to" mail address.
Also if you goto System > Systems events > Alarms
Mail will be sent if you have any alarms on the software/lines....ect.
___________________________________________
It works! Now if only I could remember what I did...
Dain Bramaged (Avaya Search tool )
______________________________________
Register:
Enter the following in the Manager > System > SMTP;
IP: 213.165.64.45
port: 587
email from address: you@gmx.com/us
server requires auth: ticked
user name; you@gmx.com or .us
password; your password
use challenge response auth: unticked
Then on the User > Voicemail > Voicemail email
enter the "to" mail address.
Also if you goto System > Systems events > Alarms
Mail will be sent if you have any alarms on the software/lines....ect.
___________________________________________
It works! Now if only I could remember what I did...
Dain Bramaged (Avaya Search tool )
______________________________________
There is a section of the document for Embedded Voicemail (EVM) as well if you scroll down however I am going to guess that they have hosted Exchange (verses on-premises) so you woulnd't have access to running any type of packet captures on the Exchange server. You can at least run the Monitor section to see if email messages are being sent.
Kyle Holladay / IPOfficeHelp.com
ACSS/ACIS/APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA
"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford
Kyle Holladay / IPOfficeHelp.com
ACSS/ACIS/APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA
"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford
- Thread starter
- #8
Gentlemen;
Thank you for your input , BAS1234 your post to build an external cloud based email did the trick we were able to determine that the IP office SMTP output was working and it also proved that the ip addressing was good as well as are lan interface and access to the internet . The customer is subscribing to a site based exchange server method and this test indicates that the SMTP link is either blocked or restricted in some way in their server. I might also add that the trace monitor for SMTP will show a wake-up , packet send , a complete successful and a snooze when finished.
Thank you for your input , BAS1234 your post to build an external cloud based email did the trick we were able to determine that the IP office SMTP output was working and it also proved that the ip addressing was good as well as are lan interface and access to the internet . The customer is subscribing to a site based exchange server method and this test indicates that the SMTP link is either blocked or restricted in some way in their server. I might also add that the trace monitor for SMTP will show a wake-up , packet send , a complete successful and a snooze when finished.
- Status
Similar threads
