08-26-2014 12:13 AM - edited 03-18-2019 03:19 AM
Hi ,
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 user@abc.local 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 ?
Aneesh Abraham
Solved! Go to Solution.
06-17-2017 04:46 PM
There a different scenarios to how you utilize voice services domain and service domain... regardless if the external domain is different than the internal domain, and the end users are logging on via their @external domain, and internal DNS only has records for the internal domain, than yes voice service domain should reflect internal domain.. I have tested this in the lab already. Your method works of course but that involves adding external domain entries in an internal dns which for some companies is a no go..
06-18-2017 10:24 PM
Here is what we did successfully for the customer, a few months ago:-
a) External domain example.com was configured as voice services domain.
b) All the internal SRV records and A records (for UDS discovery) were configured in internal domain, internal.domain (which was also the domain name configured on the CUCM, etc).
c) On the internal name server, a forward lookup zone (just the forward lookup zone, without making the internal name server authoritative for external domain) external.domain was created with following SRV records
example.com |
cisco-uds |
tcp |
10 |
10 |
86400 |
8443 |
CUCM.internal.domain |
d) Internally users login as user@internal.domain. Since the voice services domain is set as example.com, UDS discovery is done in this domain, and because of the forward lookup zone created in c), the service discovery completes.
e) Externally, users login as user@internal.domain, get the collab-edge SRV in example.com domain (because of the configured voice services domain). Expressway-C then does UDS discovery in example.com domain using the forward lookup zone created in c).
Configuring voice services domain will force the clients to do service discovery in that domain itself. Ayodeji is right in saying "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".
06-20-2017 11:58 PM
+5 Sheetanshu
06-20-2017 11:54 PM
Hellohova,
Let me try and clarify a few things
1. Services_domain is used for service discovery
2. voice_services_domain is only required in Hybrid case when your service domain is different to your WebEx Messenger domain
3. When internal domain differs from external domain and users login via external domain, your services domain cannot be your internal domain. Jabber will not work this way when its outside of the organization. The reason is simply that Jabber will do a service discovery against that domain which is not publicly routable,hence discovery will fail.
You may have tested in lab as you mentioned, but I am sure your lab environment can route both internal and external domains. But this will not work in reality.
4. Finally all companies that wants to leverage the MRA solution to improve collaboration are or need to be fully aware how it works. There is no such thing as "no go". This is how it works, there are no alternatives. Your internal domain must have a way to route requests for external domain when dealing with multiple domains as we often have. I have done this for a few customers and no one has said no no.
09-08-2014 02:49 PM
I should probably read the docs before posting it (sigh). :)
Anyways, were you able to set the Voiceservicedomain key? The link that Ayodeji posted shows you how to do this.
09-07-2014 06:44 PM
You can definitely add this as a new zone on your internal DNS server. Ensure your inter name server is the authoritative server for this zone. Contrary to what most of us think, DNS zones doesnt necessarily need to be the same as your AD domains. Your DNS server can server queries for any zones you define in it. This doesnt mean you are adding a domain, you are just adding a new zone for which your name server will serve queries for. By default when you enable DNS role on your DC, your DNS server automatically becomes the authoritative server for the domain (which is essentially a zone on your DNS server)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide