NBX V3000 voice mail issue - emails not getting sent.

[Dooky]

I have a user that is having issue with receiving emails when a voicemail is left.

We have many other users that this works for.

It also seems this user was working but is now not.

I have checked the settings but do not see a problem.

Need suggestions as to what to look at to see why emails are not forwarding.

We do eventually get a message that says

"The message cannot be delivered at this time."

[merlin215]

This may be tough to read so cut and paste it into a notpad file and then you can edit it a little better !!!!!

Solution Class: 3KB51
Problem    Voicemail ports lockup and system crashing
Problem    Offsite email notification not delivering to one or all email domains
Problem    Email Notification unable to send email to customers own domain email only - others OK
Problem    Voicemail ports hang up
Problem    Netset not responding
Fact       No tasks suspended on CLI
Fact       SuperStack 3 NBX
Fact       NBX 100
Fact       NetSet
Fact       NBX Voicemail
Fact       Offsite Notify
Cause      DNS server not properly responding with MX record detail for email notifications, which causing vm ports to lockup and system to crash.
Fix         Some customer-provided DNS servers (internal DNS servers) my not be configured to respond in a way the NBX expects for MX record queries, resulting in these symptoms for some customers.       NOTE: Microsoft recently (October 2008) changed the way their DNS software responds to query for security reasons, and this may affect existing NBX customers who have their own internal DNS and mail server.  If you are an existing NBX customer who had email notification working to your own internal email server using your own DNS server, and email notifications suddenly do not get sent to your email users, but the NBX can still send email to other email domains, you have likely been affected by the recent Microsoft change. We recommend you skip to the bottom and use an external DNS server with  a NAT translation in your router.  Follow these simple steps to confirm if your DNS server is properly responding to the NBX:  Premise.  User has notification set to send email notification to <A href="mailto:misterbig@cox.net">misterbig@cox.net</A>  [  ]  Make sure your PC is configured to use the same DNS server IP as is set in NetSet system settings[  ]  From your PC at the DOS prompt type  the following to elicit a DNS server response.  You type the text in bold print (nslookup, set type=mx, and cox.net)  C:\>nslookupDefault Server:  mboqip2.ne.3com.comAddress:  151.104.25.103  > set type=mx> cox.netServer:  mboqip2.ne.3com.comAddress:  151.104.25.103  Non-authoritative answer:cox.net MX preference = 100, mail exchanger = mx.west.cox.netcox.net MX preference = 100, mail exchanger = mx.east.cox.net  mx.west.cox.net internet address = 68.6.19.3mx.east.cox.net internet address = 68.1.17.3>  [  ]  In the above reply, you can see that there are TWO responses for MX preference, meaning two separate mail servers we could use to send email for cox.net users.  This response has both the names (mx.west.cox.net and mx.east.cox.net) as well as the IP addresses of these mail servers (68.6.19.3 and 68.1.17.3).  When you perform this step at the PC DOS prompt, you must at least see one "MX exchanger={servername}" as a minimum response.  If you don't see an MX response, this DNS server is not properly set up to return MX records and cannot be used with the NBX.  Consult your DNS server administrator or ISP for an alternate DNS server IP address to use.  [  ] If the issue is intermittent (can send offsite email notification to some email users but not others), test each failing email account in this manner.  A DNS server may reply correctly for some email address domains for MX query, but not for others.  Again, this is a DNS server issue if there is no "mail exchanger=" in the reply  [  ]  If you do see a proper DNS "mx exchanger=" in the DNS reply, and at least one MX exchanger IP address is given (above would be 68.6.19.3), type exit to get out of nslookup, then type:  C:\ telnet 68.6.19.3 25      (notice we put "space 25" after the IP address, to indicate port 25 SMTP mail port)  to see if from your PC's subnet (should be on the same subnet as the NCP for accurate test results) if you can open a mail server connection from the DOS prompt.  If you get a "connection could not be opened" error, this is the problem of why the NBX cannot send email notification - there is some firewall or routing issue within your network.  The NCP MUST be able to open a telnet port 25 (SMTP) mail connection to every email server for every email address that any user is trying to send email notification to.  A proper response would be something like:  "220 Cox.net mail server ready, proceed with data entry" which would indicate proper connection. (Type quit to exit)  [  ]  If the DNS replies with an MX exchanger={servername} but does not also reply with the IP address, you must do a separate DNS lookup for Host Address of the servername given for this recipients mail server.  To do this, exit the nslookup, and again do another nslookup, this time do NOT specify type = mx, and enter the name of the mail server returned in the first DNS reply, for example:  C:\>nslookupDefault Server:  mboqip2.ne.3com.comAddress:  151.104.25.103  > mx.east.cox.netServer:  mboqip2.ne.3com.comAddress:  151.104.25.103  Non-authoritative answer:Name:    mx.east.cox.netAddress:  68.1.17.3  >  [  ]  Once we get the actual IP address of the mail server for the email account, exit the nslookup, and test if a mail connection can be made by typing   telnet 68.1.17.3 25  (don't forget the "space 25" after the IP address to indicate it is a mail connection.  Again, you should get the "220 Server ready" or similar message indicating you are connected with the mail server.     If you are unable to do get the proper DNS server reply, or are unable to open a telnet port 25 session from your PC at the DOS prompt, on the same subnet as the NCP, using the same DNS IP address in your PC as configured in the NCP, the problem is with your DNS server for mx record configuration, or with your firewall / router as to unable to open port 25 connections.  If you are able to use the PC DOS prompt and both get proper DNS reply and open an SMTP port 25 telnet session, for a particular email account, but the NBX is not sending email to this same account, you will need to get a network trace (SMS NetMon, Ethereal, or Packet Grabber) and examine where the problem lies beyond the DOS prompt simulation.  Nearly all NBX Offsite email notification problems are due to either improper DNS server configuration for MX records or that telnet port 25 connections are not allowed from your network.   NOTE:  It is a fairly common problem where the NBX can send email notificaiton to other email accounts but not to the customer's own email domain.  This is due to DNS server misconfiguration for their own domain's MX record as we've just described. It can be tricky to get the customer's own DNS server to properly respond with the MX exchanger server name and IP correctly.  It usually requires a DNS expert if the first attempts at configuring an MX record internally do not respond correctly.  ANOTHER way around this is to set the NBX to use an EXTERNAL DNS server (one from your internet provider).  Again you may see the same symptom where the NBX can send email to other email domains but not their own if that email server is in-house.  The reason this time is that the public DNS server responds with a PUBLIC IP address for the MX query, and the NBX is not able to ping or open an SMTP (telnet port 25) connection from inside the network directly to the OUTSIDE IP address, because of either a routing limitation or firewall blocking SMTP outbound connections.  So if using an EXTERNAL DNS server with NBX, and the customer has an INTERNAL mail server, the simplest fix is to add a NAT translation so that if you try to PING the outside IP address received by the MX query using the internet providers DNS above, the customer routers will translate the outside IP to the corresponding INSIDE IP and allow you to PING or open SMTP connections from inside to the outside IP address after NAT.  Here's a sample syntax to add a NAT translation on your Cisco router: (note this may not be correct for all customers and should only be performed by the Network Admin)  ip nat outside source static 69.91.155.191 10.10.20.5  this command in effect allows internal hosts to ping or otherwise open an SMTP mail connection to the mail server host address of 10.10.20.5 when they use 69.91.155.191 public address they receive from the MX query using the DNS server of their internet provider  ALTERNATE SOLUTION:  Some customers have opted to use the NBX UME tool.  It is a PC based unified messaging solution. 

[Dooky · Accepted solution]

Thanks.

I found that the Offsite Notification was not turned on for specfic group the user was assigned.

[merlin215]

Always the simple things that get us . Nice job .