Cisco recommends the use of different SMTP domains for each Unity Connection node or high availability (HA) pair. This is required when using Digital Networking via the SMTP infrastructure (using a Smarthost) or when using Speechview. This allows routing in the SMTP infrastructure to route correctly to all of the different Cisco Unity Connection nodes or HA pairs.
Upon initial configuration of Unified Messaging or Single Inbox in Unity Connection, the sender's email address on voicemails that are synchronized to a user's inbox reflects the Unity Connection SMTP address/domain rather than the corporate email address/domain as seen in Figure 1.
In this configuration, the corporate email addresses are, by default, <username>@ucdemolab.com. Also, the Unity Connection SMTP domain is configured as CUC1.ucdemolab.com so users in the CUC node has SMTP addresses of <username>@CUC1.ucdemolab.com. This SMTP domain originates from the Unity Connection configure as seen below in Figure 2.
In this guide, an Exchange e-mail policy will be configured that will mask the Unity Connection SMTP addresses with the user's corporate e-mail addresses. Essentially, this will allow Microsoft Exchange to present the corporate e-mail address when messages are received/synchronized with a sender address of the Unity Connection SMTP address. The Unity Connection SMTP address information will be replaced with the information stored in Microsoft Exchange for the corporate user.
This document specifically walks though these steps on a Unity Connection 9.1 with an Exchange 2010 Single Inbox integration however the steps should be the same for any version of Cisco Unity Connection supporting Single Inbox and all versions of Microsoft Exchange, including Exchange 2013. While some of the interfaces may look different, the concepts of how to accomplish these tasks remain the same.
Masking Unity Connection SMTP Addresses
Do not use this process for masking Unity Connection SMTP addresses within Exchange if you are using or planning to use Digital Networking (multiple Cisco Unity Connection locations) using a SMTP smarthost. If you use a SMTP smarthost for Digital Networking, messages that are routed from one location to another will be delivered directly to the user's Exchange mailbox rather than to the user's Unity Connection mailbox.
This caveat does not occur when using Digital Networking without an SMTP smarthost. Also, this caveat does not occur in single-node or single high-availability pair deployments.
The Unity Connection team is investigating how to resolve this problem when using Digital Networking with a smarthost.
Step 1 - Check Existing User Configuration
Open the Exchange Management Console. Looking at a sample user's "E-Mail Addresses" in their properties pane, we can see that we have one SMTP address listed as seen in Figure 3. This is the corporate email address for the user.
The following steps will walk through the process of associating the corporate e-mail address with the Cisco Unity Connection SMTP address generated by Unity Connection.
Step 2 - Accepted Domain
2.1 - Check Existing Accepted Domains
The Unity Connection SMTP domain has to be added as an "Accepted Domain". By default, there should be a single accepted domain as seen in Figure 4. If you have already added other accepted domains they will be listed here.
2.2 - Create a New Accepted Domain
Right-click in the blank space below the default accepted domain and select "New Accepted Domain...". A new window will appear. Enter a name or description for the new accepted domain in the "Name" field and then enter the Unity Connection SMTP domain into the "Accepted Domain" field. In this example, the SMTP domain is CUC1.ucdemolab.com. Be sure to select "Internal Relay Domain" as seen in Figure 5.
If you do not select Internal relay domain and opt to use a smart host for intrasite networking, replication between nodes will NOT function. Be sure to select "Internal Relay Domain" as the type.
Once the new accepted domain is created, the new e-mail address policy can be created. Click "New" to finish the creation of the Accepted Domain.
Step 3 - E-mail Address Policies
3.1 - Check Existing E-mail Address Policies
To create an e-mail address policy, select "Hub Transport" from the "Organization Configuration" menu and browse to the "E-mail Address Policies" tab. There should be only one default policy listed as seen in Figure 6. If other e-mail polices have been configured previously, they will be listed here.
3.2 - Start New E-mail Address Policy Process
Right-click in the blank space below the default e-mail address policy and select "New E-mail Address Policy..." A new window will appear. Provide the new e-mail address policy a name or description. The second field allows for the policy to specific Organizational Units (OU) or container. The final section allows for limiting the e-mail policy to only certain types of users. Please see Figure 7 for an example.
The following pages allow for more granular application of the e-mail address policy if OU/container or recipient types.
Press "Next" to continue.
3.3 - E-mail Address Policy Conditions
The Conditions page, as seen in Figure 8, allows for applying the e-mail address policy by using attributes in the Active Directory schema. It allows the administrator to apply the policy based on State ore Province, Department, or Company. If these fields aren't granular enough, and administrator can use one of the 15 custom attributes that are built in, by default, to the Active Directory schema. The schema attribute would need to be populated before the email address policy could be applied but it would allow for the application of the policy based on the information that is populated into the customer attribute. For example, with this deployment, we could populate Custom Attribute 1 with the Unity Connection SMTP domain of the specific user's Unity Connection server. Some users would have CUC1.ucdemolab.com and other users may have CUC2.ucdemolab.com and so on and so forth.
In that scenario, there would be multiple e-mail address policies created; one for each Unity Connection node or HA pair that is deployed. In this example, there is only one Unity Connection node so there is no need to apply such conditions. Once the conditions are defined (if any at all) click "Next".
3.4 - Create Corporate E-mail Address Pattern
Once on the E-mail address page, you will see a blank window with no entries. Click the "Add..." button and a new window will appear as seen in Figure 9.
Under the "E-mail address local part" section, you can select from a pre-defined list of options such as alias (i.e. username). Other formats such as <first name>.<last name> format could be selected as well. Later there will be an example of modifying or creating a custom local part for an e-mail address.
In order to create the association between the corporate e-mail address and the Cisco Unity Connection SMTP address two address patterns must be defined. Create the corporate e-mail pattern first. As seen in Figure 9 the FQDN will be filled in by default with the corporate domain when the window is opened. Typically, this is the desired domain and all that is required to create the pattern. Click "OK".
After creating the corporate e-mail address pattern, click on "Add..." again to add another pattern. When the new window appears, select the "Browse" button next to "Select the accepted domain for the e-mail address" and select the accepted domain that was created in one of the step 3. Figure 10 illustrates how this would look. Once finished defining the pattern, click "OK".
3.6 - Information Regarding E-mail Address Pattern
As seen in Figure 11, the e-mail address patterns will be listed in the order they were created. Whichever pattern was created first will be in bold type. This is the "default" or "reply" address for the E-mail Address Policy. Essentially, this pattern will mask the other patterns that are created within the E-mail Address Policy. In most cases the corporate pattern will be the reply pattern to mask the Unity Connection SMTP address.
In Figure 11, a 3
rd pattern was added to illustrate how to customize a pattern. The pattern is a modifiable text field that can be selected with the cursor and edited manually. In this example, a <firstname>.<lastname> pattern was created. This could be modified by removing the period/dot between the first and last name if so desired.
Once all the patterns are defined, select "Next" to continue.
3.7 - Applying the New E-mail Address Policy
The next screen allows the administrator to choose when to apply the new E-mail Address Policy. The default selection is "Immediately" and in most cases is the desired option. Once the Schedule is defined, select "Next" and on the following window click "New" to apply the policy.
Step 4 - Verifying E-Mail Address Policy Creation
4.1 - Verify New E-Mail Address Priority
The new E-mail Address Policy should be listed as a numerical priority with the default policy being listed as "Lowest". Given the new policy has a numerical priority, it will be applied instead of the default policy. See Figure 13 for reference.
4.2 - Check User's E-Mail Addresses
Now, examine the same user that was examined in step 1 and there should now be multiple e-mail addresses listed in the "E-Mail Addresses" tab. If there is still only a single E-Mail Address listed then the new E-Mail Address Policy was either not applied or the conditions or filters that were defined as part of the policy removed the user as a recipient that the filter would apply to.
Once the user has the desired e-mail addresses defined, the next step will be to test the policy and make sure it applies successfully to users' voicemail messages as they are synchronized with Exchange.
Step 5 - Verify Operation
At this point the user can test the operation of the policy by leaving another voicemail for the user. Please note that previous voicemails won't be affected by the new policy so a new message will need to be generated and synchronized into Exchange. Upon synchronization, the email should appear to originate from the user's corporate e-mail account as seen in Figure 15. There should no longer be any reference to the Unity Connection SMTP address, which in this example is CUC1.ucdemolab.com.