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.

Advertisements

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.