cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11228
Views
13
Helpful
13
Replies

Jabber MRA with mixed WebEx cloud and CWMS deployment

gsykes
Level 1
Level 1

Hi all,

We have a situation where we have a historic WebEx cloud deployment, including a small number of users that used WebEx connect.

Since implementing a CSR10 platform, we now have an in-house presence and IM server, and we've also deployed Jabber MRA.  We've also deployed WebEx Meeting Server internally.

The issue we have is that we still want to keep our WebEx cloud service for certain users, to ensure they are guaranteed resource availability, as we have only 50 ports of CWMS.

By keeping our domain alive on WebEx however, we seem to be breaking the automatic service discovery capability of Jabber MRA, as the client finds our domain on WebEx connect and tries to authenticate with that.

Is there a way of configuring the client to ignore WebEx connect or does anyone have any other suggestions as to how best to deal with this?

As a footnote MRA is working when we use the manual set up.  The problem is only around auto service discovery.

Kind Regards, Glen

1 Accepted Solution

Accepted Solutions

Do you have your WebEx Messenger domain active and in use? If you are not using Messenger in the cloud any more I would suggest to raise a ticket with WebEx team to disable your domain (ie. you've migrated to full on-premise solution). We've done the same just to have a lot less administration overhead with Jabber Clients. Now our users are able to simply use default Jabber without any customization.

If you are using both, I'm sure only way is to get this solved is to get Service Configuration URL working.

View solution in original post

13 Replies 13

rheadon
Cisco Employee
Cisco Employee

Hi Glen,

You have two ways to configure Jabber:

1) Exclude WEBEX from service discovery.  Your WebEx users will have to have a build with this disabled, or be given instructions on how to manually configure Jabber.  If they are already using Jabber, their settings will have migrated.

Service Discovery Exclude Services

You can exclude one or more services (such as CUP, CUCM or WEBEX) from Cisco Jabber service discovery. You can exclude services to prevent Cisco Jabber from discovering a service that you do not want Cisco Jabber to use. For example, you can exclude services if users sign into their Cisco Jabber client on a Cisco Webex Messenger domain, but you want to provision them with phone mode only.

2) You can configure Jabber to specify which DNS domain to use to discover the network services.

Voice Services Domain

You can specify the DNS domain, where the _cisco-uds, _cuplogin and _collab-edge DNS SRV records are deployed, to be a different value than the services domain that is used by Cisco Jabber to discover Cisco WebEx Messenger. Defining different domains assists the deployment of Cisco Expressway Mobile and Remote Access into existing hybrid deployments.
Both are set via the bootstrap or URL provisioning.
Search for ServiceDiscoveryExcludedServices and VoiceServicesDomain in the Installation and Configuration guide:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/JABW_BK_C4C679C9_00_cisco-jabber-for-windows-97.pd…
Rob.

Thank you Robert,

Option 1 would be our first preference, although this seems to apply only to the Windows client where we configure this parameter in the MSI file.

Is there a similar method to configure service discovery preferences for the mobile clients?

If we go with Option 2, I assume that the specific domain we use for service discovery does not have to be the same as the domain used to identify the user?

Kind Regards, Glen

There is an option to configure service domain parameters for other clients with configuration URL, check this slide...

Jiri

I have the same issue, i will try to add policy to exclude webex and update the form

Bryan Geoghan
Level 1
Level 1

I'm having issues with the URL to exclude WebEx from being used as an authenticator for Jabber for iPhone....even with the URL specifying to exclude WebEx, it is still attempting to authenticate to the WebEx cloud. The Jabber client even shows, "Enter your username and password for WebEx Messenger". Any ideas? Running 10.5 of Jabber

Do you have your WebEx Messenger domain active and in use? If you are not using Messenger in the cloud any more I would suggest to raise a ticket with WebEx team to disable your domain (ie. you've migrated to full on-premise solution). We've done the same just to have a lot less administration overhead with Jabber Clients. Now our users are able to simply use default Jabber without any customization.

If you are using both, I'm sure only way is to get this solved is to get Service Configuration URL working.

It transpired that our domain had not been disabled properly on the WebEx cloud.  We revisited this and now service discovery is working perfectly.

Thanks to everyone for their valuable advice.

Bryan Geoghan
Level 1
Level 1

We did have the WebEx team disable the WebEx Messenger domain or at least they have said it has been completed.

When we launch Jabber on the iPhone using the config URL to exclude WebEx, it is still attempting to authenticate to the WebEx Connect cloud service and fails because we have no users provisioned there.

The config URL I am using looks like this, but it seems to ignore the exclude WebEx portion...

ciscojabber://provision?ServicesDomain=abc.com&VoiceServicesDomain=cisco-uc.abc.com&ServiceDiscoveryExcludedServices=WEBEX

Anyone else have any issues with this? In the logs, it just shows this:

-- 2015-01-06 17:11:16.977 INFO [8b85000] - [service-discovery][getDomain] Getting 'domain'
-- 2015-01-06 17:11:16.977 INFO [8b85000] - [service-discovery][getConfigValue] Getting servicesDomain from ConfigFeatureSet
-- 2015-01-06 17:11:16.977 INFO [8b85000] - [service-discovery][getValue] ServiceDiscoveryConfigStore: getValue() found no value mapped to key: servicesDomain
-- 2015-01-06 17:11:16.978 INFO [8b85000] - [service-discovery][getDomain] Domain is set to: abc.com
-- 2015-01-06 17:11:16.978 INFO [8b85000] - [service-discovery][getVoiceServicesDomain] Getting VoiceServicesDomain from ConfigFeatureSet
-- 2015-01-06 17:11:16.978 INFO [8b85000] - [service-discovery][getConfigValue] Getting VoiceServicesDomainfrom ConfigFeatureSet
-- 2015-01-06 17:11:16.978 INFO [8b85000] - [service-discovery][getValue] ServiceDiscoveryConfigStore: getValue() found no value mapped to key: VoiceServicesDomain
-- 2015-01-06 17:11:16.978 INFO [8b85000] - [service-discovery][getVoiceServicesDomain] Retrieved VoiceServicesDomain: cisco-uc.abc.com
-- 2015-01-06 17:11:16.978 INFO [8b85000] - [service-discovery][getExcludedServicesList] Getting ServiceDiscoveryExcludedServices from ConfigFeatureSet
-- 2015-01-06 17:11:16.979 INFO [8b85000] - [service-discovery][getConfigValue] Getting ServiceDiscoveryExcludedServices from ConfigFeatureSet
-- 2015-01-06 17:11:16.979 INFO [803b000] - [csfunified.telemetry.TelemetryServiceController][processEvent] TelemetryServiceController processing Command: label: UpdateString
-- 2015-01-06 17:11:16.980 INFO [8b85000] - [service-discovery][getValue] ServiceDiscoveryConfigStore: getValue() found no value mapped to key: ServiceDiscoveryExcludedServices
-- 2015-01-06 17:11:16.980 INFO [8b85000] - [service-discovery][getExcludedServicesList] Retrieved ServiceDiscoveryExcludedServices:
-- 2015-01-06 17:11:16.980 INFO [803b000] - [service-discovery][getValue] ServiceDiscoveryConfigStore: getValue() found no value mapped to key: TelemetryEnabled
-- 2015-01-06 17:11:16.980 INFO [8b85000] - [service-discovery][getConfigValue] Getting RemoteAccess from ConfigFeatureSet

priyank.kiran
Level 4
Level 4

Great post and responses, thanks!

I am looking to do something similar for a customer of mine, except there is no CWMS involved. They would like to migrate from Jabber in the Cloud (WebEx Messenger) to Jabber On-premise.

Are there any good links/documents that walks through this specific scenario and perhaps also addresses some of the gotchas and 'things to watch' when performing this kind of migration?

Regards,

Priyank

My engineering and IT teams are in the same scenario, we had an unused WebEx Messenger service on our primary domain, and we've asked for WebEx Support to deactivate it.

They claim that they've done so, but when I launch Jabber on any device outside the FW, it wants to authenticate against WebEx Messenger instead of our MRA/CollabEdge/IM&P environment.

From the experience of the people in this thread, how long does it take for the records for WebEx Messenger to dissapear from the Internet? 6 hours? 12? 24? 48 hours? For us, we were told that WebEx Messenger was deactivated 24 hours ago.

If I'm just being impatient, I'm happy to wait longer if someone tells me to do so.

To echo what Priyank said, is there any document out there that shows a process to get this done?

Other than launching Jabber and waiting for it to display the wrong service, is there some other test that I can run to validate that WebEx Messenger is/isn't active on my domain?

I'm also having a hard time finding the service exclusion URL syntax in the documentation, can someone point me in that direction as well?

Thanks everyone!

Michael,

Our client we did the Jabber implementation for put in the request to the WebEx team over like 3 months ago and they still have not completed it. They said that it should be disabled, but the request that Jabber does to validate if the client's domain is a WebEx Connect domain is still receiving a response that makes Jabber think they are a valid domain. The client went ahead is using the configuration URL to block WebEx as an authenticator.

The URL should look like this: ciscojabber://provision?Servicesdomain=company.com&ServiceDiscoveryExcludedServices=WEBEX

I struggled with this URL for awhile even though I had it right. If you have already attempted the initial sign in where it asks your for your username with domain, then this URL will not work after that. You have to remove Jabber on your mobile, reinstall, and then launch it with this URL the first time or before you attempt the initial login.

Cisco TAC did provide a good way to test if the WebEx Connect cloud service is disabled.

Jabber is determining that the domain ‘company.com’ is a WebEx domain via the following HTTP query:

http://loginp.webexconnect.com/cas/FederatedSSO?org=company.com

As you can see, the errorcode 7 is being returned. This means that the domain is considered active for IM&P by WebEx, although it is not using SSO. If you compare this with a query on a domain that is definitely not within WebEx (http://loginp.webexconnect.com/cas/FederatedSSO?org=bogus.biz), you will see that the errorcode of 1 is returned instead. This is what Jabber is looking for in order to consider the domain an on-prem domain instead of WebEx.

HI Bryan, thnks so much for your comments above. This help me solve problem with Jabber MRA Iphone/IPad login and searching contacts and call direct with phone services under contacts information. thanks a lot!

Now I'll waiting until Webex Account Manager disable our Webex Message IM thats brings to us serious problems.

Todd Hebert
Level 5
Level 5

Same situation here.  Had to open a ticket with WebEx to let them know we were deploying Expressway and using Jabber internally.  Jabber does a services discovery and always checks WebEx Connect first before looking elsewhere, even if your users plug in username@yourdomain.com as the username, it still defaults to WebEx connect first.  Once this was disabled we were able to give our users the same experience on and off the domain with Jabber (except desktop sharing of course!).  As for your comment on WebEx cloud being more stable, we had cloud services and were single threaded with out MeetingPlace and WebEx Cloud node at HQ.  We wanted more reliability so we deployed CWMS on-premise with a Split DNS MDC model.  Timing was incredible and just when I finished deploying CWMS our HQ site lost power (which was when we discovered our generator was not working properly), so our WebEx Cloud service was not working because our nodes at HQ were down.  Guess what, CWMS was still online at our DR site and we were able to get a webex up and running to discuss the recovery as power was restored to HQ.  So we got AWAY from cloud service for more reliability.