We are configuring MRA with different internal and external domain name. internal domain is abc.local and external domain is abc.com
Exp C ,CUCM and IMP are in abc.local domain and Exp E is in abc.com domain. users using email@example.com to login to jabber .
So we created external SRV records . (_collab-edge._tsl.abc.com) . in internal DNS server we created _cisco-uds._tcp.abc.local.
From what I know , we need to create _cisco-uds._tcp.abc.com record in internal DNS as well .
The problem is since we cant add abc.com zone (it will affect the existing ERP setup ) we cannot create _cisco-uds._tcp.abc.com in our DNS server .
Is there any workaround for this ?
Solved! Go to Solution.
Will this configuration work with 2 different domain? Like the example above, abc.local for internal and abc.com for external.
I know that this is an old post but running into similar situation.
Aneesh, just like you said -
internal = abc.local
external = abc.com
not allowed to publish (create zone) of one into another side
The problem is you have to use abc.com from outside for collab-edge discovery. Expressway-C will use _cisco-uds._tcp.abc.com to look for internal services on behalf of the client.
Tested creating Pinpoint Subdomain and Jabber uses that for discovery but was not sure if it is still supported by TAC even though all the planning guides talk about pinpoint subdomain.
Did you find answer/solution for this?
You can try creating the records just for Jabber as shown below:
dnscmd . /zoneadd _cisco-uds._tcp.domain.com. /dsprimary
dnscmd . /recordadd _cisco-uds._tcp.domain.com. @ SRV 10 0 8443 cucm1.domain.com
dnscmd . /recordadd _cisco-uds._tcp.domain.com. @ SRV 20 0 8443 cucm2.domain.com
Hopefully you are able to sign certs from an external CA for domain.local.
The issue is that the business does not allow to create a zone for the outside domain internally - If the domains are:
internal = abc.local
external = abc.com
Cannot create abc.com zone internally. The alternative is to create a sub-domain zone, for example "mra.abc.com" zone. This way the internal would be authoritative for the sub-domain and the external would stay authoritative for the main domain and there would no disruption on the production systems that are on the main domain abc.com. The SRV would be
It seems to work on a lab but not sure if it was acceptable solution. Any ideas?
You are correct. Jabber will use the UDS domain as the discovery domain. All you need to do as you have done is to host abc.com internally and then point the cisco-uds SRV to mra.abc.com. Once Jabber gets the response for cisco-uds srv query, it will then use the mra.abc.com as the service discovery domain
That is exactly how we tested it; we were not sure if it was supported by TAC. It seems as though it is ok as long servicedomain is used in the jabber-config.xml.
Thanks for all the help,
This is supported by TAC, I have done this for two customers now and supporting another one with the same setup
Don't forget to rate helpful post
Thanks Ayodeji. Your posts in this discussion and another one have been of great help in understanding this situation.
I have a question - Why can't we have collab-edge SRV on abc.com while the uds is on mra.abc.com?
We should be able to do this using the VoiceServiceDomain configuration key, that will point to mra.abc.com while the services domain can remain as abc.com (as mentioned in http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide_chapter_010.html#CJAB_TK_U6868975_00 , although I find inconsistencies in the example give here)
I may have understood it wrong, but this is how it should work:-
Login using firstname.lastname@example.org and do not get uds SRV in abc.com, but are able to find collab-edge SRV that points to exp.abc.com
Query uds/collab-edge SRV in abc.com and do not get a response, but due to voiceservicesdomain configured as mra.abc.com query for uds again in mra.abc.com domain. uds SRV record exists on the internal name server for mra.abc.com domain pointing to cucm.mra.abc.com.
Please help me understand if this is wrong.
You are correct and this is the old way of doing the deployment.
However in newer versions of jabber you dont need servicesdomain. This is because Jabber will extract the uds domain found in the UDS discovery and ue it the discovery domain.
So in newer deployments, having UDS and collab-edge SRV records in the same domain is a necessity then.
That would mean that even though internal name server can't be authoritative for the abc.com, we would need to create a subdomain - say mra.abc.com on both external and internal and then create the respective SRVs?
I see that you have added a response to Abdu's explanation "All you need to do as you have done is to host abc.com internally" - but I think abdu mentioned "Cannot create abc.com zone internally". I think we would just need to create a zone for "mra.abc.com" on internal DNS and have A record for CUCM and SRV for cisco-uds in mra.abc.com pointing to the cucm. On external DNS too we will have mra.abc.com, with SRV for collab-edge and A record for exp-E.
No, you cant do that how will jabber find the UDS domain?
The first thing jabber does is query for collab-edge SRV query using abc.com
Next is the public DNS will return the FQDN of your expressway server
Next Jabber will perform edge_config query proxied through expressway-e
expresway-e will send request to expressway-c and then expressway see will perform edge provisioning. Part of this task by expressway-c will be to perform a cisco-uds SRV query against the abc.com domain. Because at this point this is your discovery domain. When this is done, The internal DNS server with abc.com will then return the names of the UDS servers configured for the cisco-uds srv query eg xxx.mra.abc.com.
Now Jabber gets this and change its service discovery domain to mra.abc.com
So you need to host abc.com internally.
Dont forget to rate helpful posts!
Thanks for sharing the flow. I understand that.
I believe that the problem was that abc.com can't be hosted on internal domain, as it can break other forwarding relationship. If we could have hosted abc.com internally as well as externally, I believe there would have been lesser problems. But as Abdu mentioned "Cannot create abc.com zone internally" and "not allowed to publish (create zone) of one into another side", is the issue.
Referencing the dns configuration document (see the excerpt attached) http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide.pdf
"Support of the fixed pinpoint subdomain has been replaced in later versions of Cisco Jabber by the support of the new VoiceServicesDomain configuration key.
Example configuration using Service Discovery to replace pinpoint subdomains:
• Internal DNS authoritative for : example.local
• External DNS authoritative for : example.com
Create a zone on both the internal and external DNS server for cisco-uc.example.com
So what is being asked to do is to create a zone for "cisco-uc.example.com" and not host example.com first on internal DNS and then make cisco-uc as a child to example.com, as this has the potential of disrupting the DNS structure.
With VoiceServicesDomain set to mra.abc.com (or cisco-uc.example.com in Cisco document), shouldn't the UDS domain be mra.abc.com and not abc.com? Also, with VoiceServicesDomain set as mra.abc.com, wouldn't the MRA client also query for collab-edge SRV in mra.abc.com?
"The client performs a Domain Name System (DNS) SRV record query for _collab-edge._tls.<domain>. This implies that when the domain from the login user ID is different than the domain from the Expressway E, you must use the voice service domain configuration. Jabber uses this configuration in order to discover the Collaboration Edge and the UDS"
Apologies, If I have misunderstood, but I believe the crux of the problem is that abc.com can't be hosted internally.
My point is this, however you do it either by creating a zone for the external domain or hosting it intenrally, that domain needs to be available because when you set your ServicesDomain (again you dont need voiceservicesdomain), all your query both internally and externally will be done against it.
I have done this a few times now and all the times, the external domain has been hosted internally. I have not used zones as you mentioned.
Honestly best approach is using both Services Domain and Voice Service Domain for different domain for internal and external.
If your Internal Domain is Internal.Domain
And External Domain is External.Domain
You should use configuration URL and or include the "Voice Service Domain" for Internal.Domain.
Changing a customers DNS environment by hosting the External Domain internally could be wide impacting (especially if it doesnt exist)
First of all there is a difference between services domain and voice services domain and it is good to know when you should use which one. Try and do some research and you may know why all you need is services domain and not voice service domain.
Secondly, even when you set your services domain to example.com, your expressway-c will still need to run a DNS SRV query for that domain as part of Jabber discovery process, hence you still need to be able to do a lookup for _cisco-uds.example.com in your internal DNS.