cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3212
Views
0
Helpful
10
Replies

CUPS Server domain + User domain - different? Possible?

carlnewton
Level 3
Level 3

Guys,

Is it possible within presence to fiddle the domain settings so the users are in a different domain to the server itself?

There are lots of domain settings, im not sure which does what and each time I change one something breaks. Im sure im not doing it right but before I seek out the correct way to change it I want to check what I want to do is possible.

Essentially if you build a CUPS server in DNS domain "DomainA" and have a user Jbloggs, Presence assumes the email address for them is Jbloggs@DomainA.

If you build one with DomainB it assumes Jbloggs@DomainB

Is it possible to have the server in domainA but the users displayed in DomainB?

The reason I ask is that we are trying to do an outlook integration currently - The CUPS server was put into a public domain so the email addresses appeared correctly but the outlook server is in a different, internal only domain.  Unfortunately the outlook server is not defined as FQDN within the certificate so when you try to connect CUPS to Outlook it goes off to the name you specify (E.g outlook.internaldomain.com) and looks at the cert.

This returns just "outlook" with the CN, an it is then changed - and the CUPS server tries to resolve outlook.externaldomain.com (the domain the CUPS server is actually in)

This fails as the DNS server its configured with does not have a Zone for the externaldomain so no addres resolution takes place and the whole lot falls down.

If I can configure the CUPS server in the internaldomain but keeps the users in the externaldomain the problem will go away.

Exchange administrators refuse to reconfigure the outlook cert with FQDN and DNS administrators refuse to configure a zone for externaldomain.

Thanks in advance!

10 Replies 10

Thanks Michael, I've had a read of that and I do understand it - however, I still have questions on it.

2) Does the SIP domain has to match the DNS domain?

Answer: Yes, it has to match the DNS domain in most of the scenarios. 2) Does the SIP domain has to match the DNS domain?
Answer: Yes, it has to match the DNS domain in most of the scenarios.

What are the other scenarios?

What we have here is the presence SIP domain and DNS domain are domainA.  The only zones the configured DNS server serves for is domainB.

This tells me there isn't a reliance on resolving user@domainA.com as the DNS server will not resolve for domainA.

Everything is working currently but to make outlook integration work the easiest solution is to change the presence server DNS domain to domainB, but we must leave the sip domain as domainA because that is the suffix of the users email addresses.

The only time I tried this myself, changing the DNS domain broke the replication between the two servers - looking at the logs, Server2's server recovery manager was still trying to poll server1@domainA.com even though we changed its DNS domain to DomainB.  The only way I could fix it was to change the domain back to DomainA.

If someone can tell me how to sucessfully change DNS domain in a replicated setup with presence 8.5 then I can test the rest myself.  I've found several pieces of Cisco documentation on how to do this, some of which simply do not work, and others which contradict what it says on the server. (e.g documentation saying "change this field in service parameters to the FQDN of server" but when you look at server parameter description in CUPS it says "this field MUST NOT be the FQDN of the server")

Any help appreciated!

If what you cared was Calendar Integration, it should be pretty simple.

CUPS use the "Mail ID" field from CUCM > User Management > End User page.  The email domain there doesn't have to be the same domain as the CUP SIP domain.  For example:

The "Mail ID" is "john.doe@cisco.com".  The SIP domain could be "test.local".

I don't see a problem here.  Could you elaborate?

Michael

carlnewton
Level 3
Level 3

Hmm ok thanks Michael.  Im sure that when I was testing in the Lab the email address according to the CUPS client followed the form of username@SIPDomain.com but I dont think the Mail ID in CUCM was populated at that time (Which it now is)

If that is the case (its drawn from CUCM Mail ID) then all I need to know is how to correctly change the DNS and SIP domain on a resillient CUPS deployment.

The doc i found for changing the domain on a CUPS server says about changing the federation routing FQDN to the desired FQDN of your server, but when you look at that service parameter description within CUPS it explicitly states in bold and capital letters that this should NOT be the FQDN of ANY server in your CUPS deployment.

I tried changing the SIP Domain and DNS domain and doing a reboot and it broke replication.  Looking at server recovery manager logs it seems the servers were still trying to contact each other using the old domain that was set, even though I'd changed the DNS domain from the CLI and SIP domain from web GUI.

Im guessing there is a special order in which I have to make changes and also some services I have to restart but I cannot find any information on this.

So if you have any information on how to properly change the domain of a resillient CUPS 8.5 deployment then that would be excellent

Thanks for all of your help

carlnewton
Level 3
Level 3

http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_0/english/install_upgrade/deployment/guide/dgcupc.html

Search for "replacing the default domain value"

Extract:

"The domain name specifies the DNS domain name of the Cisco Unified Presence server. Cisco Unified Presence automatically defaults to the domain namevalue PROXY.DOMAIN.NOT.SET. You must replace this default domain name with the DNS domain name in order for the SRM to initialize correctly in a High Availability deployment.

a. Select Cisco Unified Presence Administration > System > Service Parameters, and select the Cisco UP SIP Proxy service.

b. Configure the Federation Routing CUP FQDN with the new domain. "

IF you look at the service parameter properties from within CUPS it states:

"Federation Routing CUP FQDN:* This parameter specifies the public FQDN of the routing cisco unified presence server when federating with microsoft OCS/LCS. note: This value MUST NOT be the actual FQDN of any cisco unified presence server within the enterprise."

What you thought it was was not it was. 

#1 "Federation Routing CUP FQDN" has nothing to do with this topic.  That parameter is used for "Federation" feature.

#2 The domain name you changed from CLI has nothing to do with this topic.  That is for the Operating System (Linux) instead of the application (CUPS).

#3 The SIP domain you were seeing in the log (username@SIPDomain.com) is for SIP routing only, it's not the email address for Exchange server.  e.g. if the "Mail ID" was "username@MailDomain.com" and the SIP domain was "SIPDomain.com", you'll see the URI as "username@MailDomain.com@SIPDomain.com".  This is expected and worked as designed.

If the "Mail ID" in CUCM was blank, CUPS will assume the "Mail ID" to be the username.  This is OK and it should work in most of the cases.

So, in summary, the calendar feature didn't work for some reason.  But none of the things above was the cause of the problem.  You should look at PE (Presence Engine) logs to see why it didn't work.  Open a TAC case if needed.

Michael

Hi Michael,

I dont think I'm explaining myself correctly.  The long and short of it now is that my CUP servers (2 of them running CUP 8.5 in High availability) are currently in DomainA.  I need to change the DNS Domain to be in DomainB (And so from the first document you posted, I will also need to change the SIP domain to DomainB)

I tried to do this by changing the DNS domain from the CLI on both servers, and changing the service parameters for the SIP proxy service to reflect DomainB instead of DomainA.

I restarted the CUP servers and they were in the correct domain.  However, the HA information showed that HA was not up and working.

I looked at the SRM (Server recovery manager) logs that are responsible for the HA synchronisation.  In here there were lots of errors saying that it could not contact the peer server in DomainA.

So basically I change from DomainA to DomainB But the SRM is still trying to talk to its peer server in DomainA.  This tells me I have missed something regarding the change of domain.

I found the document for CUP 8.5 deployment that has a section on "changing the domain" that says:

"The domain name specifies the DNS domain name of the Cisco Unified Presence server. Cisco Unified Presence automatically defaults to the domain namevalue PROXY.DOMAIN.NOT.SET. You must replace this default domain name with the DNS domain name in order for the SRM to initialize correctly in a High Availability deployment."

It then says, for instructions on that section:

"Configure the Federation Routing CUP FQDN with the new domain."

Since the problem I am having is that the SRM is not initialising correctly in my high availability deployment then I assumed that it might be something to do with that.  However, As stated, When I look at that service parameter description from the CUP Server it disagrees with the Cisco Doc that you should set it to the FQDN of your server, or indeed that it has anything at all to do with the SRM (server recovery manager):

"Federation Routing CUP FQDN:* This parameter specifies the public FQDN of the routing cisco unified presence server when federating with microsoft OCS/LCS. note: This value MUST NOT be the actual FQDN of any cisco unified presence server within the enterprise."

What I need to know is only how to sucessfully change the DNS Domain value for CUPS in a high availability deployment.  I Need to change the domain name of the CUPS server so that it suffixes the correct domain to the outlook SSL certificate for calendaring to work.  Presently the outlook server is in DomainB, the CUPS server is in domainA.  When you try to setup the outlook server in the CUPS configuration, it gets the outlook SSL cert which lists only the HOSTNAME (and not the FQDN) of the exchange server.

As such, CUPS then suffixes its own DNS domain to the exchange servers hostname, and changes the address you have entered to that entry; which cannot be resolved because the exchange server is not in the same domain as the CUPS server; and because of this setting up the outlook SSL certificate fails.  If I change the CUPS domain from DomainA to DomainB then it will suffix the correct domain and resolve the address sucessfully and hopefully complete integration.

Well, first thing first.  WHY you want to change the domain?

The word "domain" is generic and could mean different things in different places.  So I need to understand what your tried to acheive by changing the domain?

Are you trying to get some feature/function worked or just for costmetic purpose?  Why do you think changing the domain will make the feature worked?

Thanks!

Michael,

When you try to set up the exchange server from the admin GUI of CUPS, it asks you for a few parameters.

Presence gateway type: EWS

Description - OurExchange

Presence Gateway: FQDN of Exchange server

Account Name: xxx

Password: Xx

When you hit save, it then goes off to the outlook server and retrieves the SSL certificate for it.  It then looks at the CN in the cert, and if it doesnt match the "Presence Gateway" It changes the presence gateway to match the CN of the certificate to make sure everything is secure.

The exchange cert in our case only lists the CN As the HOSTNAME of the exchange server, not the FQDN.

So, it changes the presence gateway to only the hostname.  Cups then suffixes its own domain to the end of that hostname and tries again to reach the presence gateway.

Because the CUPS server is not in teh same domain as the exchange server, the address resolution fails and the whole process falls down.

I see.

So the ultimiate problem is on the certificate.

It's just the nature of SSL/TLS that the target (destination) you tried to connect to has to match with the common name in the certificate.  If the Exchange certificate has hostname as the common name, changing the domain (or SIP domain) on CUPS side won't fix the problem.  It will fail eventually even if you can get CUPS admin page populate the correct FQDN of Exchange.

The right solution is to generate a certificate with Exchange FQDN in it.  This can easily be done with the 'makecert' utility from Microsoft.  For example:

makecert -r -pe -n "CN=www.yourserver.com" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -cy authority

Then install the cert on IIS (for the Exchange).  Restart IIS with command "iisreset".

The whole process takes less than 10 minutes and is generally not instrusive.

For more details, take a look at http://www.amazon.com/Deploying-Unified-Presence-Michael-HouTong/dp/0557039533

Michael

makecert -r -pe -n "CN=www.yourserver.com" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -cy authority

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: