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.
Scenario:
Customer’s external (internet facing) DNS domain is: collabdomain.com
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 vcse.collabdomain.com
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 collabdomain.com zone.
The internal DNS server would serve internaldomain.local, as well as an internal version of the collabdomain.com 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.
<Policies>
<VoiceServicesDomain>collabdomain.com</VoiceServicesDomain>
</Policies>
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 — collabdomain.com. It will do the SRV record lookup on _collab-edge._tls.collabdomain.com 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 _cisco-uds._tcp.collabdomain.com 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&VoiceServicesDomain=collabdomain.com
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.