Create a Custom Installer

This topic describes how to create a customized Cisco Jabber installer file.

  • Use Microsoft Orca to create custom installers:
    • Use CiscoJabberProperties.mst file to transform CiscoJabberSetup.msi
    • User will not see “email address” window on first login
  • MSI Transformation can be used to modify the following:
    • SERVICES_DOMAIN: Set to domain for login service (WebEx, Cisco Unified CM or CUP)
    • VOICE_SERVICES_DOMAIN: Set to domain used for discovering remote access infrastructure
    • AUTHENTICATOR: Set to authentication service name if service discovery is not used or fails
    • TFTP: Cisco Unified CM TFTP address if service discovery is not used or fails

Use Microsoft Orca to create custom installers. Microsoft Orca is available as part of the Microsoft Windows SDK for Windows 7 and .NET Framework 4. You must have the default transform file to modify the installation package with Microsoft Orca. Download the Cisco Jabber administration package from Cisco.com. Copy CiscoJabberProperties.mst from the Cisco Jabber administration package to your file system.

To create a custom installer, use a transform file. Transform files contain installation properties that you apply to the installer. The default transform file lets you specify values for properties when you transform the installer. You should use the default transform file if you are creating one custom installer.

Methods of Installation

This topic describes the installation options for Cisco Jabber for Windows.

You can use the Cisco Jabber installation package in the following ways:

  • Use the command line with arguments.
  • Run the MSI manually.
  • Create a custom installer.
  • Deploy with a group policy.

Use the following command to pass configuration information to the installation process:

  • msiexec.exe /i CiscoJabberSetup.msi argument=value

Cisco Jabber for Windows provides an MSI installation package that can be used in the following ways:

  • Command Line: Specify arguments in a command line window to set installation properties. Choose this option if you plan to install multiple instances.
  • Run the MSI Manually: Run the MSI manually on the file system of the client workstation, and then specify connection properties when you start the client. Choose this option if you plan to install a single instance for testing or evaluation purposes.
  • Create a Custom Installer: Open the default installation package, specify the required installation properties, and then save a custom installation package. Choose this option if you plan to distribute an installation package with the same installation properties.
  • Deploy with Group Policy: Install the client on multiple computers in the same domain.

The following describes the command syntax to install Cisco Jabber for Windows using the command line with arguments:

msiexec.exe /i CiscoJabberSetup.msi /quiet CLEAR=1

CLEAR=1 deletes any existing bootstrap file and /quiet specifies a silent installation. The other options are as follows:

  • PRODUCT_MODE=Phone_Mode sets the client to phone mode.
  • AUTHENTICATOR=CUCM sets Cisco Unified Communications Manager as the authenticator. Other options are CUP and WEBEX.
  • TFTP=1.2.3.4 sets 1.2.3.4 as the IP address of the TFTP server that hosts the client configuration. Other options are the hostname and FQDN.

To deploy Cisco Jabber with Group Policies, install Cisco Jabber for Windows using the Microsoft Group Policy Management Console (GPMC) on Microsoft Windows Server. To install Cisco Jabber for Windows with Group Policy, all computers or users for which you plan to deploy Cisco Jabber must be in the same domain.

For more information go to Cisco Jabber 10.6 Deployment and Installation Guidehttp://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/10_6/CJAB_BK_C56DE1AB_00_cisco-jabber-106-deployment-and-installation-guide.html.

Troubleshoot DNS SRV Entries

This topic shows how to verify and troubleshoot configured Cisco User Data Service (UDS) SRVs.

Verify that the DNS SRV entries can be resolved:

To ensure that the DNS server is configured correctly and responds with the correct DNS SRV entries, use a client computer and verify that the client uses the same DNS server as the Cisco Jabber client that you are troubleshooting. Open a command prompt and enter nslookup.

Set the nslookup type to DNS SRV entries with the command set type= srv. Use the previously configured DNS entry and add the service _cisco-uds and the protocol _tcp—for example, _cisco-uds._tcp.cisco.com. The DNS server should now respond with all DNS SRV entries that are configured on the DNS server for this particular service. Verify the response and ensure that the priority, weight, port, and the svr hostname are configured correctly, and that the svr hostname can be resolved to the IP address of the Cisco Unified Communications Manager servers.

DNS SRV Priorities and Weights

This topic describes the priorities and weights of the DNS SRVs.

The DNS SRV entries are configured on a DNS server:

_service._protocol.domain TTL  class SRV priority weight port target
_cisco-uds._tcp.cisco.com               3600 IN    SRV 10       60     8443 cucm1.cisco.com
_cisco-uds._tcp.cisco.com               3600 IN    SRV 10       20     8443 cucm2.cisco.com
_cisco-uds._tcp.cisco.com               3600 IN    SRV 10       20     8443 cucm3.cisco.com
_cisco-uds._tcp.cisco.com               3600 IN    SRV 20       0      8443 cucm4.cisco.com
  • The first three records all have priority 10. The weight value is used to determine which server to contact:
    1. cucm1.cisco.com will be used 60% of the time.
    2. cucm2.cisco.com and cucm3.cisco.com will each be used 20% of the time.
  • If all three nodes with priority 10 are down, the record with priority 20 will be used, which is cucm4.cisco.com.

A DNS SRV entry contains the following parameters:

  • _service: This parameter is the name of the service, and it begins with an underscore, for example, _cisco-uds, _sip, or _ldap.
  • _protocol: This parameter is the transport protocol of the service and must start with an underscore—for example, _tls, _tcp, or _udp.
  • Domain: This parameter is the domain name for which this record is valid—for example, cisco.com.
  • TTL: This parameter is the TTL and defines how long the resolved record can be stored in the cache.
  • Class: This parameter is the standard DNS class field (this parameter is always IN).
  • Priority: This parameter is the priority of the target host. A lower value indicates a more preferred priority. The range is 0 to 65535.
  • Weight: This parameter is a relative weight between 0 and 65535 for records with the same priority.
  • Port: This parameter is the port on which the service is found.
  • Target: This parameter is the hostname of the machine that is providing the service.

In the example in the figure, for the service _cisco-uds._tcp.cisco.com, are four DNS SRV entries in the enterprise DNS server. The first three records share the same priority level 10. The last DNS SRV entry has a priority of 20. Cisco Jabber will use the first three DNS SRV entries, because the lower priority is more preferred. For entries with the same priority (value 10 in the example), the entry weight is used to determine which entry should be used. Weight values allow an administrator to configure load balancing. In the example in the figure, cucm1.cisco.com will be used 60 percent of the time, and the servers cucm2.cisco.com and cucmm3.cisco.com will each be used 20 percent of the time.

Service Records

This topic describes the DNS SRVs for Cisco Jabber.

  • Internal DNS server must resolve:
    • _cisco-uds._tcp.example.com
    • _cuplogin._tcp.example.com
  • External DNS server must resolve:
    • _collab-edge._tls.example.com
    • Use FQDN as hostname in the SRV record.
  • Control the load distribution with:
    • Priority
    • Weight

You deploy multiple DNS SRVs in different locations in your enterprise DNS structure.

You can provision the _cisco-uds SRV on internal name servers so the client can discover services. This record provides the location of Cisco Unified Communications Manager version 9 and higher. In an environment with multiple Cisco Unified Communications Manager clusters, you must configure the Intercluster Lookup Service (ILS). ILS enables the client to find the home cluster of the user and discover services.

Note

You should use the FQDN as the hostname in the SRV.

The following is an example of the _cisco-uds SRV:

_cisco-uds._tcp.cisco.com     SRV service location:
          priority       = 10
          weight         = 10
          port           = 8443
          svr hostname   = pub-hq. collab10x.cisco.com

You must provision the _collab-edge SRV on external name servers as part of the configuration for Cisco TelePresence Video Communication Server Expressway (Cisco VCS-E) mobile and remote access. You must use the FQDN as the hostname in the SRV. The client requires the FQDN to use the cookie that the Cisco VCS-E server provides.

The following is an example of the _collab-edge SRV:

collab-edge._tls.cisco.com   SRV service location:
          priority       = 10
          weight         = 10
          port           = 8443
          svr hostname   = vcse.cisco.com

Cisco UDS SRV

This topic describes the call flow when using Cisco User Data Service (UDS) SRVs.

This image illustrates how the client uses the Cisco UDS SRV:

In deployments with Cisco Unified Communications Manager version 9 and higher, the client can automatically discover services and configuration with the SRV _cisco-uds:

  1. The client queries the domain name server for SRVs.
  2. The name server returns the _cisco-uds SRV.
  3. The client locates the home cluster of the user. As a result of automatically locating the home cluster of the user, the client can retrieve the device configuration for the user and automatically register telephony services.
Note

In an environment with multiple Cisco Unified Communications Manager clusters, you must configure the Intercluster Lookup Service (ILS). ILS enables the client to find the home cluster of the user.

  1. The client retrieves the user service profile. The user service profile contains the addresses and settings for Cisco Unified Communications Services and client configuration. The client also determines the authenticator from the service profile.
  2. The client signs the user into the authenticator.

Service Discovery: Operating Mode

This topic describes how Cisco Jabber discovers the operating mode.

Cisco Jabber also discovers the operating mode:

  • When the domain is known, Cisco Jabber can discover the operating mode.
  • Cisco Jabber sends the following service discovery requests:
Priority Service HTTP Request or DNS SRV
1 WebEx Messenger HTTP CAS lookup
2 Unified Communications Manager 9.x or newer _cisco-uds._tcp.<domain>.com
3 Cisco Unified Presence 8.x _cuplogin._tcp.<domain>.com
4 Collaboration Edge _collab-edge._tls.<domain>.com
  • Depending on the answer, Cisco Jabber knows where it is located and how to reach the authenticator server.
  • The highest-priority returned record is used for the service discovery process.
  • Cisco Jabber performs all queries, regardless of the reply.

The _cisco-uds service record provides the location of Cisco Unified Communications Manager version 9.0 and higher. The client can retrieve service profiles from Cisco Unified Communications Manager to determine the authenticator. This setting enables the client to discover the home cluster of the user. As a result, the client can automatically get the device configuration of the user and register the devices. This mode also supports mixed product modes. You can easily deploy users with full Unified Communications, IM only, or phone mode capabilities.

The _cuplogin service record provides the location of Cisco Unified Presence and sets Cisco Unified Presence as the authenticator. This setting supports deployments with Cisco Unified Communications Manager and Cisco Unified Presence version 8.x.

The _collab-edge service record provides the location of Cisco TelePresence Video Communication Server Expressway (Cisco VCS-E). The client can retrieve service profiles from Cisco Unified Communications Manager to determine the authenticator. This mode is used for deployments in which Cisco VCS-E is configured for mobile and remote access.

Locating Services with SRVs

The following steps describe how the client locates services with SRVs:

  1. The client host computer or device establishes a network connection and receives the address of a DNSname server from the DHCP settings.

  1. The client issues an HTTP query to a Connect Authentication Service (CAS) URL for the Cisco WebEx Messenger service. This query enables the client to determine if the domain is a valid Cisco WebEx domain.

  1. The client queries the name server for the following SRVs in order of priority: _cisco-uds, _cuplogin, and _collab-edge.

  1. The client caches the results of the DNS query to load on subsequent launches.

In addition to querying the DNS server for SRVs to locate available services, the client sends an HTTP query to the CAS URL for the Cisco WebEx Messenger service. This request enables the client to determine cloud-based deployments and authenticate users to the Cisco WebEx Messenger service.

When the client receives a domain from the user entry, it appends that domain to the following HTTP query:

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

That query returns an XML response that the client uses to determine if the domain is a valid Cisco WebEx domain. If the client determines that the domain is a valid Cisco WebEx domain, it prompts users to enter their Cisco WebEx credentials. The client then authenticates to the Cisco WebEx Messenger service and retrieves the configuration and Cisco Unified Communications Services that are configured in Cisco WebEx Org Admin. If the client determines that the domain is not a valid Cisco WebEx domain, it uses the results of the query to the DNS name server to locate an available service.

Service Discovery: Domain

This topic describes how Cisco Jabber discovers the service domain.

Service discovery must first discover the domain:

  • Option 1
    1. Client prompts end user to enter user ID with domain.
    2. Mail address or Jabber ID (JID)
    3. Client uses the domain portion to resolve the service type.
    4. This information is cached for future logins.
  • Option 2
    1. Administrator provides client domain information.
    2. User is not prompted.
    3. Use command line option or create customized MSI installer.

Before Cisco Jabber can send a DNS request, Cisco Jabber must know the service domain. Cisco Jabber can use the default method to determine the service domain, where the user is simply prompted to enter the user ID with the domain. The domain is used to send a DNS request and discover the services.

The automated option is to use a command line option during Cisco Jabber installation. The more scalable solution is to customize the MSI installer file of Cisco Jabber and to distribute the software with a software distribution system. When the user logs in for the first time, the domain is already known by the client, and there is no prompt to enter the domain. In combination with SSO, you can suppress the prompt for the username and password as well.

Cisco Jabber Service Discovery

This topic describes the benefits of Cisco Jabber service discovery.

Enables Cisco Jabber to automatically acquire client configuration:

  • Unified Communications services domain
  • Operating mode (on-premises, cloud, or hybrid)
  • Operating location (inside or outside corporate network)
  • Home cluster in multicluster environment

Enhances end user experience:

  • No prompt to ask for configurations
  • Reduces support calls due to misconfiguration

Cisco Jabber cross-platform initiative:

  • Windows, Mac OSX
  • iOS and Android

To make Cisco Jabber rollouts easy to execute, Cisco Jabber discovers its services based on DNS SRVs. Depending on the DNS answer, the client knows if it is located inside or outside of the enterprise and also if it connects to a cloud or on-premises solution.

After receiving DNS information, Cisco Jabber can connect to the appropriate system—for example, Cisco Unified Communications Manager—and download its configuration file including information about all controllable devices. Depending on the mode, the client registers with Cisco Unified Communications Manager (phone-only and softphone mode) or with Cisco Unified Communications IM and Presence Service (deskphone mode).

Because Cisco Jabber has service discovery, there is no need to configure any device settings on the client for login.

Cisco Unified Communications IM and Presence Service Services

This topic describes the Cisco Unified Communications IM and Presence Service services.

Activate the necessary services on Cisco Unified Communications IM and Presence Service.

  • In Cisco Unified IM and Presence Serviceability, choose Tools > Service Activation.

Review the service description and enable only the required services instead of simply enabling all services to optimize the resource utilization. When not configured or configured incorrectly, some services stop after a short time.

Database and administrative services are as follows:

  • Cisco AXL Web Service: Cisco AXL Web Service is enabled by default on all cluster nodes. Cisco recommends that you always leave the service activated on the IM and Presence database publisher node. This service communicates with Cisco Unified Communications Manager to exchange database information.
  • Cisco Bulk Provisioning Service: If you use the BAT to administer users, you must turn on this service.

Performance and monitoring service is as follows:

  • Cisco Serviceability Reporter: The service only generates reports on the publisher node even if you turn on the service on other nodes.

IM and Presence services are as follows:

  • Cisco SIP Proxy and Cisco Presence Engine: Activate these services on all nodes in the cluster to enable presence functionality.
  • Cisco XCP Text Conference Manager: Turn on this service if you deploy the chat feature on Cisco Unified Communications IM and Presence Service. The permanent chat feature requires an external database. If you enable the permanent chat feature, you must also configure an external database before starting the Text Conference Manager service. The Text Conference Manager service will not start if the permanent chat feature is enabled and an external database is not configured.
  • Cisco XCP Web Connection Manager: Turn on this service if you integrate XMPP-based API web clients with IM and presence—for example, Cisco Jabber Messenger for the Web, which works with any web browser.
  • Cisco XCP Connection Manager: Turn on this service if you integrate XMPP clients with Cisco Unified Communications IM and Presence Service.
  • Cisco XCP SIP Federation Connection Manager: Turn on this service if you deploy a federation over SIP—for example, to a Microsoft Lync domain.
  • Cisco XCP XMPP Federation Connection Manager: Turn on this service only if you deploy a federation over the XMPP protocol to another Cisco Unified Communications IM and Presence Service domain or any other XMPP domain.
  • Cisco XCP Message Archiver: Turn on this service if you deploy the compliance feature on IM and Presence. If you turn on the Message Archiver before you configure an external database, the service will not start.
  • Cisco XCP File Transfer Manager: Turn on this service if you need a support for managed file transfer.
  • Cisco XCP Directory Service: Turn on this service if you integrate XMPP clients on IM and Presence with an LDAP directory. If you turn on the Directory Service before you configure the LDAP contact search settings for third-party XMPP clients, the service will start and then stop again.
  • Cisco XCP Authentication Service: Turn on this service if you integrate XMPP clients with IM and presence.