- Cisco Employee,
We are getting a number of TAC cases where customers are setting up single inbox feature (unified messaging) with where they try to reply to or forward a voicemail via Outlook e-mail and receive an NDR message in return. First let me try to explain why this will fail the way it does and then try to supply some direction for your Exchange admins to make this work in your current environment.
Why this fails:
It is basic mail routing/addressing. When you have single inbox setup on CUC, part of that setup is a CUC SMTP DOMAIN. Typically this should not match your corporate mail domain. This is now documented here...
It is usually just the hostname of the CUC server out of the box but some like to change it to something that resembles and actual domain. For our purposes here, we will use CUCSMTPDOMAIN.ORG for example. For the corporate domain, we will use CORP.COM for example. Let's go over the scenario.
UserA on CUC sends a voicemail to UserB. This voicemail arrives on UserB's Outlook via the Single Inbox Synch. We would expect the UserB to use VMO or TUI to reply to the voicemail in a CUC environment but many users whom have come from a Unity system to a CUC system via migration don't realize this is the method preferred and used the simple reply/forwards via Outlook while on Unity previously. This no longer works in CUC. This is why. When UserA on CUC sends the voicemail to UserB on CUC, it will be addressed as FROM UserA@ CUCSMTPDOMAIN.ORG and will arrive in the Outlook of UserB with the same FROM address. If the UserB uses VMO or TUI for reply/forward, the message will send without incident. If UserB uses Outlook e-mail client to reply or forward, a NDR will be generated and the message send will fail. Why is this? When you use VMO, it talks directly to CUC where UserA@ CUCSMTPDOMAIN.ORG will be resolved and delivered correctly. If VMO is not used, Outlook talks to the corporate Exchange server where it has no clue what or where CUCSMTPDOMAIN.ORG is or whom resides there. Thus the NDR is generated when attempting this. It's a simple matter of not being able to resolve the user you are trying to reply to because you are talking to Exchange on the corporate domain and telling it to deliver a message to a domain is can't resolve. From the NDR, you can see it typically talks about a lack of an MX record or the like or not being able to resolve the address. From the customer interactions I have had, there seems to be a few fixes for this I wanted to share here. Granted TAC is not responsible for configuring a corporate Exchange environment for this but at least this might help your Exchange admins figure out what to do to fix the issue. This is not a step-by-step fix.
In the exchange 2010 environment you have to setup an “internal relay domain” and point it to route the mail destined for that domain to the unity connection server.
For Exchange 2003 you need to create a connector with the address space of the destination domain and have it route to the unity server.
There may be some additional configurations, depending on what you want to happen once the mails are delivered to the CUC users but I will point you to a very nice post here from David Hailey to fill in that info. It also has more details as to why these messages are treated differently depending on method of reply and forward.
I hope this helps anyone struggling with this issue with our new feature. Just keep in mind, using VMO and/or TUI to reply will take care of this as it was the intended method with CUC. At the same time, I see that in previous Unity deployments, users used Outlook reply/forward all the time and would like to continue having the ability after being migrated to CUC Single Inbox.
I would add this as well since this is getting really good traffic on the forums.
It explains a bit more what the behavior is and why, without installing the VMO client, UM forwarding/replying etc. will not work like old Unity UM did.
Please feel free to comment or add to this post.