Collaboration Edge (MRA) with Split DNS Domains

I recently helped one of our customers work through a split DNS domain Collab Edge MRA deployment that was quite educational.  Here are a few tidbits that I picked up.


Customer’s external (internet facing) DNS domain is:
Customer’s internal domain is:  internaldomain.local  (not resolvable externally, only served by the internal DNS server)

Expressway-E lives on the internet so it’s hostname would be

Expressway-C, CUCM, IM&P (CUP) and Unity Connection live on the internal domain, so they would be called ucm1.internaldomain.local, cup1.internaldomain.local, ucxn.internaldomain.local.

The users accounts would live in internaldomain.local (presumably the LDAP user would be user@internaldomain.local, etc.)

The external DNS server would serve the public zone.

The internal DNS server would serve internaldomain.local, as well as an internal version of the zone.

The challenge with these separate domain names is that when a user goes to login to Jabber via MRA, the service discovery process is going to fail because they are going to type in their IM address as user@internaldomain.local, and there is no _collab-edge._tls.internaldomain.local SRV record availble on the itnernet (nor could there be).

To get around this, the jabber-config.xml file can be modified to include the external domain name that Jabber should try to do service discovery against. 


Jabber must first login internally (directly on your corporate network) to pull down the jabber-config.xml that includes this policy.

With this configuration now loaded in Jabber, when the user attempts to login from outside via MRA they will still use their user@internaldomain.local credentials, but Jabber will use the specified VoiceServicesDomain — in this case —  It will do the SRV record lookup on and now be able to resolve Expressway-E and login.

In addition to the the normal _cisco-uds._tcp.internaldomain.local SRV record, Jabber needs another SRV record (on the internal DNS server) pointing to ucm1.internaldomain.local for MRA to work with the split domains.The one criticism to this method is requiring the Jabber client to login internally first, which isn’t an ideal scenario for large distributed organizations.  One method that is supposed to work around this is to prime Jabber by installing it generically and launching it from an URL:ciscojabber://provision?ServicesDomain=internaldomain.local&

This could be provided in an email and will supposedly launch Jabber so that it tries the external domain without having to ever login internally first.




Avoiding IM&P (CUP) 10.5 Cluster Upgrade Problems

Upgrade Blues

I recently had a customer upgrade to their cluster to CUCM 10.5(1) as well as their IM&P servers to 10.5(1).  They ran into an situation with the IM&P subscriber server that ended up requiring intervention from TAC to get running.  (I also noticed a number of other customers having this exact same issue.)

The symptom is that after the IM&P subscriber upgrade completes, the administrator screen goes blank when trying to login and the sync service won’t start.


The issues is caused by a CUCM LDAP sync occurring while the IM&P servers are being upgraded.  This causes all of the users assigned to subscriber IM&P servers to be unable to login.

If your server ends up in this condition, a call to TAC would be the first thing to do so that they can do a remote support session to fix the issue.

Avoiding the Problem in the First Place

Before performing a system upgrade of CUCM and IM&P, change the LDAP sync interval to a sufficiently long period to avoid having a sync occur during your upgrade window.  I’d push it out o a week or so, but make sure it isn’t going to happen during your upgrade.  This is the cause of the issues.

Upgrade CUCM and IM&P as normal

Change your LDAP sync interval back to previous values (many engineers set it to 24 hours).