Cisco Jabber for Windows 9.1.x Installation and Configuration Guide
Deployment Options
Downloads: This chapterpdf (PDF - 2.07MB) The complete bookPDF (PDF - 3.87MB) | Feedback

Deployment Options

Contents

Deployment Options

Learn about options for deploying Cisco Jabber for Windows.

On-Premises Deployments

An on-premises deployment is one in which you set up, manage, and maintain all services on your corporate network.

Product Modes

For all deployments, the user's primary authentication is to a presence server. You must provision users with instant messaging and presence capabilities as the base for your deployment. You can then provision users with additional services, depending on your requirements.

Full UC

To deploy full UC, you enable instant messaging and presence capabilities. You then provision users with devices for audio and video in addition to voicemail and conferencing capabilities.

Cisco Jabber for Everyone (IM Only)

To deploy Cisco Jabber for Everyone, you enable instant messaging and presence capabilities. You can optionally provision users with desk phone devices that they can control with the client.

Diagram with Cisco Unified Presence

The following diagram illustrates the architecture of an on-premises deployment that includes Cisco Unified Presence:

Figure 1. On-Premises architecture



The following are the services available in an on-premises deployment:
Presence

Users can publish their availability and subscribe to other users' availability through Cisco Unified Presence.

Instant Messaging

Users send and receive instant messages through Cisco Unified Presence.

Audio Calls

Users place audio calls through desk phone devices or on their computers through Cisco Unified Communications Manager.

Video

Users share their screens and place video calls through Cisco Unified Communications Manager.

Voicemail

Users send and receive voice messages through Cisco Unity Connection.

Conferencing
Integrate with one of the following:
Cisco WebEx Meeting Center

Provides hosted meeting capabilities.

Cisco WebEx Meetings Server

Provides on-premises meeting capabilities.

For information about contact sources in on-premises deployments, see Directory Service in On-Premises Deployments.

Diagram with Cisco Unified Communications IM and Presence

The following diagram illustrates the architecture of an on-premises deployment that includes Cisco Unified Communications IM and Presence:

Figure 2. On-Premises architecture



The following are the services available in an on-premises deployment:
Presence

Users can publish their availability and subscribe to other users' availability through Cisco Unified Communications IM and Presence.

Instant Messaging

Users send and receive instant messages through Cisco Unified Communications IM and Presence.

Audio Calls

Users place audio calls through desk phone devices or on their computers through Cisco Unified Communications Manager.

Video

Users share their screens and place video calls through Cisco Unified Communications Manager.

Voicemail

Users send and receive voice messages through Cisco Unity Connection.

Conferencing
Integrate with one of the following:
Cisco WebEx Meeting Center

Provides hosted meeting capabilities.

Cisco WebEx Meetings Server

Provides on-premises meeting capabilities.

For information about contact sources in on-premises deployments, see Directory Service in On-Premises Deployments.

Cloud-Based Deployments

A cloud-based deployment is one in which Cisco WebEx hosts services. You manage and monitor your cloud-based deployment with the Cisco WebEx Administration Tool.

Cloud-Based Diagram

The following diagram illustrates the architecture of a cloud-based deployment:

Figure 3. Cloud-Based architecture



The following are the services available in a cloud-based deployment:
Contact Source

The Cisco WebEx Messenger service provides contact resolution.

Presence

The Cisco WebEx Messenger service lets users can publish their availability and subscribe to other users' availability.

Instant Messaging

The Cisco WebEx Messenger service lets users send and receive instant messages.

Conferencing

Cisco WebEx Meeting Center provides hosted meeting capabilities.

Hybrid Cloud-Based Diagram

The following diagram illustrates the architecture of a hybrid cloud-based deployment:

Figure 4. Hybrid cloud-based architecture



The following are the services available in a hybrid cloud-based deployment:
Contact Source

The Cisco WebEx Messenger service provides contact resolution.

Presence

The Cisco WebEx Messenger service lets users can publish their availability and subscribe to other users' availability.

Instant Messaging

The Cisco WebEx Messenger service lets users send and receive instant messages.

Conferencing

Cisco WebEx Meeting Center provides hosted meeting capabilities.

Audio Calls

Users place audio calls through desk phone devices or on their computers through Cisco Unified Communications Manager.

Video

Users share their screens and place video calls through Cisco Unified Communications Manager.

Voicemail

Users send and receive voice messages through Cisco Unity Connection.

On-Premises Service Connections

Learn how Cisco Jabber for Windows can discover and connect to services in on-premises deployments.

Connection Settings

Users set the presence server address in the Connection Settings window. Cisco Jabber for Windows can then connect to the presence server to authenticate users and retrieve service profiles.

Related References

Bootstrap File

You can specify the presence server address during installation with the following argument: ADDRESS.

The installation program then saves the presence server address to a bootstrap file. Cisco Jabber for Windows gets the presence server address from the bootstrap file when it starts. It can then connect to the presence server to authenticate users and retrieve service profiles.

Related References

Presence Server Discovery

Cisco Jabber for Windows can automatically discover either Cisco Unified Presence or Cisco Unified Communications IM and Presence if you do not specify the presence server address during installation.

When the client launches for the first time, it retrieves the presence server type from the bootstrap file.
  • The bootstrap file contains the settings you specify during installation.
  • You set the presence server type as the value of the TYPE argument during installation. In on-premises deployments, the value must be CUP.
To discover the presence server, the client must first determine the domain. It attempts to retrieve the domain from the following locations, in order of priority:
  1. Environment variable: USERDNSDOMAIN
  2. Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Domain
  3. Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DhcpDomain

After it finds the domain, the client gets the presence server address from the Domain Name Server (DNS).

When the client gets the presence server address, it connects to the presence server and then caches the address of the presence server.

If a redirect occurs to another server in the cluster, the client caches the address of the presence server to which it connects, not the address of the server before the redirect.

DNS SRV Records

Cisco Jabber for Windows retrieves the _cuplogin._tcp SRV record from the Domain Name Server (DNS) to lookup either Cisco Unified Presence or Cisco Unified Communications IM and Presence.

Notes:
  • You must add this SRV record to the DNS server on the presence server domain.
  • Cisco Jabber for Windows uses port 8443 to connect to Cisco Unified Presence.
  • Cisco Jabber for Windows supports weight and priority in SRV records.

The following is an example SRV record:

_cuplogin._tcp.domain SRV 0 1 8443 cup_server.domain

Connect to Available Services

The client connects to available services after it retrieves the service profiles.
  • If the profile contains conferencing settings, the client connects to the conferencing service.
  • If the profile contains voicemail settings, the client connects to the voicemail service.
  • If the profile contains settings for Cisco Unified Communications Manager, the client does the following:
    • Retrieves the device list for the user.
    • Retrieves the device configuration from the TFTP server.
    • Registers with Cisco Unified Communications Manager.

Cloud-Based Service Connections

Learn how Cisco Jabber for Windows can discover and connect to services in cloud-based deployments.

Connection Settings

Users set Cisco WebEx as the value of the Server type property in the Connection Settings window. Cisco Jabber for Windows can then connect to the Cisco WebEx Messenger service to authenticate users and retrieve configuration and services.

Related References

Bootstrap File

You specify WebEx as value of the TYPE argument during installation.

The installation program then saves that value to a bootstrap file. Cisco Jabber for Windows gets the value from the bootstrap file when it starts. It can then connect to the Cisco WebEx Messenger service to authenticate users and retrieve configuration and services.

Related References

Connect to Available Services

After the client connects to the Cisco WebEx Messenger service, users get instant messaging and presence capabilities and contact resolution. Users can also get conferencing capabilities if you enable hosted conferencing with Cisco WebEx Meeting Center.

In hybrid cloud-based deployments, the client gets the connection details for on-premises services. You specify the connection details with the Cisco WebEx Administration Tool.
  • If the deployment includes Cisco Unity Connection, the client connects to the voicemail service.
  • If the deployment includes Cisco Unified Communications Manager, the client does the following:
    • Retrieves the device list for the user.
    • Retrieves the device configuration from the TFTP server.
    • Registers with Cisco Unified Communications Manager.

Directory Service in On-Premises Deployments

Cisco Jabber for Windows searches the directory to add contacts and to resolve contacts and phone numbers. To successfully deploy Cisco Jabber for Windows in an on-premises deployment, you should understand the directory infrastructure of the environment into which you plan to install the client. You can then choose a contact source that is most suited to that environment.

This section explains the different contact sources you can choose and what, if any, configuration you must perform to deploy Cisco Jabber for Windows with each contact source.

Configure Directory Integration with On-Premises Servers

When you set up an on-premises deployment, you should configure Cisco Unified Communications Manager to do both of the following:
  • Synchronize with the directory server.
  • Authenticate with the directory server.

Synchronizing with the directory server replicates contact data from your directory to Cisco Unified Communications Manager.

Enabling authentication with the directory server lets Cisco Unified Communications Manager proxy authentication from the client to the directory server. In this way, users authenticate with the directory server, not with Cisco Unified Communications Manager or a presence server.

See Configuring Cisco Unified Communications Manager Directory Integration for more information about configuring directory integration.

See the Server Setup Guide for instructions on configuring directory integration for on-premises deployments.

Contact Sources

You can use either of the following as the contact source for an on-premises deployment:

Enhanced Directory Integration

Enhanced Directory Integration (EDI) is an LDAP-based contact source.

Cisco Unified Communications Manager User Data Service

Cisco Unified Communications Manager User Data Service (UDS) is a contact source on Cisco Unified Communications Manager.

Enhanced Directory Integration

EDI uses native Microsoft Windows APIs to retrieve contact data from the directory service.

The following are the default settings for on-premises deployments with EDI:
  • Cisco Jabber for Windows integrates with Active Directory as the contact source.
  • Cisco Jabber for Windows automatically discovers and connects to a Global Catalog.
Domain Name Retrieval

Cisco Jabber for Windows retrieves the fully qualified DNS domain from the USERDNSDOMAIN environment variable on the client workstation.

After Cisco Jabber for Windows gets the DNS domain, it can locate the Domain Name Server and retrieve SRV records.

In some instances, the value of the USERDNSDOMAIN environment variable does not resolve to the DNS domain that corresponds to the domain of the entire forest. For example, when an organization uses a sub-domain or resource domain. In this case, the USERDNSDOMAIN environment variable resolves to a child domain, not the parent domain. As a result, Cisco Jabber for Windows cannot access information for all users in the organization.

If the USERDNSDOMAIN environment variable resolves to a child domain, you can use one of the following options to enable Cisco Jabber for Windows to connect to a service in the parent domain:

  • Ensure that the Global Catalog or LDAP server can access all users in the organization.
  • Configure your DNS server to direct Cisco Jabber for Windows to a server that can access all users in the organization when Cisco Jabber for Windows requests a Global Catalog or LDAP server.
  • Configure Cisco Jabber for Windows to use the FQDN of the parent domain.
    Specify the FQDN of the parent domain as the value of the PrimaryServerName parameter in your Cisco Jabber for Windows configuration as follows:
    <PrimaryServerName>parent-domain-fqdn</PrimaryServerName>
    See the Directory Connection Parameters topic for more information.
Related References
Directory Server Discovery
Cisco Jabber for Windows can automatically discover and connect to the directory server if:
  • The workstation on which you install Cisco Jabber for Windows is on the Windows domain.
  • Cisco Jabber for Windows can retrieve the address of the directory server from a DNS SRV record.
Directory Server SRV Record
Global Catalog _gc._msdcs._tcp.domain.com
Domain Controller

LDAP-based directory servers

_ldap._msdcs._tcp.domain.com
Default Server Connection

The client connects to a Global Catalog by default. The Global Catalog holds primary directory attributes for all users in your Microsoft Windows domain forest.

If required, you can use the ConnectionType parameter to configure the client to connect to a Domain Controller instead of a Global Catalog.


Note


Default ports are as follows:
  • Global Catalog: 3268
  • Domain Controller: 389

LDAP Directory Servers

Cisco Jabber for Windows supports LDAP directory servers such as OpenLDAP. See the list of supported directory servers in the Directory Servers topic.

You must use specific configurations to integrate with OpenLDAP and Active Directory Lightweight Directory Service (AD LDS) or Active Directory Application Mode (ADAM). See the Directory Server Configuration Examples section for more information and configuration examples.

Primary and Secondary Servers

You can specify server names and port numbers of directory servers for manual access.

Configure the client to connect to a primary and secondary server with the following parameters:
  • PrimaryServerName
  • ServerPort1
  • SecondaryServerName
  • ServerPort2

Each time the client starts, it attempts to connect to the primary server. If the primary server is not available, the client attempts to connect to the secondary server. If the connection to the secondary server is successful, the client keeps the connection to the secondary server until the next restart.

Directory Authentication
Default Configuration

By default, the client uses Generic Security Service API (GSS-API) to authenticate with the directory server. GSS-API leverages the system authentication mechanism. In a Microsoft Windows environment, GSS-API lets you connect to the directory server using Integrated Windows Authentication.

The following XML snippet shows the default configuration for directory authentication:
<UseWindowsCredentials>1</UseWindowsCredentials>
<UseSSL>0</UseSSL>
<UseSecureConnection>1</UseSecureConnection>
This configuration specifies that the client:
  • Uses Windows credentials.
  • Does not use SSL.
  • Uses GSS-API.
Use Windows Credentials

By default, the client authenticates with the directory server with the user's Microsoft Windows credentials.

In certain scenarios, it is not possible to authenticate with the directory server with the users' Microsoft Windows credentials. In this case, you can do one of the following:
  • Use an anonymous bind.
  • Specify a well-known or public set of credentials in the client configuration with the following parameters:
    • ConnectionUsername
    • ConnectionPassword
    Important:

    The client transmits and stores these credentials as plain text. Using these parameters is not a secure method of authenticating with the directory server.

    You should only specify a connection username and password in the client configuration if your directory server requires you to use credentials other than the user's Microsoft Windows credentials.

Use GSS-API or Simple Authentication
The UseSecureConnection parameter lets you do one of the following:
  • Use GSS-API, which is the default setting.
  • Use simple authentication.
Simple authentication lets you connect to the directory server using simple binds, as in the following example configuration:
<UseWindowsCredentials>0</UseWindowsCredentials>
<UseSSL>0</UseSSL>
<UseSecureConnection>0</UseSecureConnection>
<ConnectionUsername>username</ConnectionUsername>
<ConnectionPassword>password</ConnectionPassword>
This configuration specifies that the client:
  • Does not use Windows credentials.
  • Does not use SSL.
  • Uses simple authentication.
  • Uses custom credentials.
As a result of the simple bind, the client transmits the credentials in the payload of the bind request in plain text.
Use SSL
Enable SSL in directory server connections with the UseSSL parameter. You can use SSL to encrypt credentials if you use simple authentication, as in the following example configuration:
<UseWindowsCredentials>0</UseWindowsCredentials>
<UseSSL>1</UseSSL>
<UseSecureConnection>0</UseSecureConnection>
<ConnectionUsername>username</ConnectionUsername>
<ConnectionPassword>password</ConnectionPassword>
This configuration specifies that the client:
  • Does not use Windows credentials.
  • Uses SSL.
  • Uses simple authentication.
  • Uses custom credentials.
As a result, the client uses SSL to encrypt the credentials in the client configuration.
Important:

You can use SSL with a Global Catalog, Domain Controller, or other LDAP directory server.

The SSL connection certificate must be present:
  • In the Microsoft Windows certificate store.
  • On the directory server to which the client connects.
To establish an SSL connection, the server presents the client with the certificate. The client then validates the certificate from the server against the certificate in the store on the client computer.

Note


Default protocols and ports for SSL connections are as follows:
Global Catalog
  • Protocol: TCP
  • Port number: 3269
Domain Controller
  • Protocol: TCP
  • Port number: 636

Attributes on the Directory Server

You must index attributes on your directory server so that Cisco Jabber for Windows can resolve contacts.

If you use the default attribute mappings, ensure the following attributes are indexed:
  • sAMAccountName
  • telephoneNumber
    Additionally, ensure you index the following attributes for secondary number queries:
    • otherTelephone
    • mobile
    • homePhone

    Note


    By default secondary number queries are enabled in Cisco Jabber for Windows. You can disable secondary number queries with the DisableSecondaryNumberLookups parameter.


  • msRTCSIP-PrimaryUserAddress You should index msRTCSIP-PrimaryUserAddress for intradomain federation only.

Because the client connects to a Global Catalog server by default, you must ensure that all attributes reside on your Global Catalog server. You can replicate attributes to a Global Catalog server using an appropriate tool such as the Microsoft Active Directory Schema snap-in.

Replicating attributes to your Global Catalog server generates traffic between Active Directory servers in the domain. For this reason, you should replicate attributes to your Global Catalog server at a time when network traffic can handle extra load.

If you do not want to replicate attributes to a Global Catalog server, you can configure Cisco Jabber for Windows to connect to a Domain Controller. However, the client queries single domains only when it connects to a Domain Controller.

Predictive Search
When Cisco Jabber for Windows performs a predictive search, it issues a query using Ambiguous Name Resolution (ANR). This query disambiguates the search string and returns results that match the attributes that are set for ANR on your directory server.
Important:

You must configure your directory server to set attributes for ANR if you want the client to search for those attributes.

See the following Microsoft documentation for more information on ANR:
  • Ambiguous Name Resolution for LDAP in Windows 2000
  • LDAP Referrals, see the Ambiguous Name Resolution section
  • Common Default Attributes Set for Active Directory and Global Catalog
Contact Photo Retrieval
Retrieval Methods
Cisco Jabber for Windows retrieves and displays contact photos with the following methods:
URI substitution

Cisco Jabber for Windows dynamically builds a URL to contact photos with a directory attribute and a URL template.

To use this method, set the following values in your configuration file:
  1. Specify true as the value of the PhotoUriSubstitutionEnabled parameter.
  2. Specify a directory attribute to use as a dynamic token as the value of the PhotoUriSubstitutionToken parameter; for example,
    <PhotoUriSubstitutionToken>sAMAccountName</PhotoUriSubstitutionToken>
  3. Specify the URL and the dynamic token as the value of the PhotoUriWithToken parameter; for example,
    <PhotoUriWithToken>http://staffphoto.example.com/sAMAccountName.jpg</PhotoUriWithToken>

With the example values in the preceding steps, the sAMAccountName attribute might resolve to msmith in your directory. Cisco Jabber for Windows then takes this value and replaces the token to build the following URL: http://staffphoto.example.com/msmith.jpg.

Binary objects

Cisco Jabber for Windows retrieves the binary data for the photo from your database.

To use this method to retrieve contact photos, specify the attribute that contains the binary data as the value of the PhotoSource parameter in the configuration; for example,
<PhotoSource>jpegPhoto</PhotoSource>
PhotoURL attribute

Cisco Jabber for Windows retrieves a URL from a directory attribute.

To use this method to retrieve contact photos, specify the attribute that contains the photo URL as the value of the PhotoSource parameter in the configuration; for example,
<PhotoSource>photoUri</PhotoSource>
Refreshing Contact Photos

This section describes a limitation that currently exists if you use the URI substitution method or binary object method to retrieve contact photos from your directory.

When Cisco Jabber for Windows retrieves contact photos from the directory, it caches those photos in the following location on the users' file systems: %USER_PROFILE%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Photos

After Cisco Jabber for Windows caches a contact photo, it does not retrieve that photo again from the directory. If you update contact photos in your directory, users do not automatically get those updated contact photos. Users must exit Cisco Jabber for Windows and then manually delete the folder that contains the cached photos on their file systems.

Cisco Unified Communications Manager User Data Service

UDS is a REST interface on Cisco Unified Communications Manager that provides contact resolution. You synchronize contact data into Cisco Unified Communications Manager from a directory server. Cisco Jabber for Windows then automatically retrieves that contact data directly from UDS.
Important:

A known issue in UDS exists on versions of Cisco Unified Communications Manager lower than 8.6.2. This known issue prevents successful contact resolution. As a result, Cisco Jabber for Windows supports UDS on Cisco Unified Communications Manager version 8.6.2 or later.

Related References
Enable Integration with UDS

To enable integration with UDS, perform the following steps:

Procedure
    Step 1   Create your directory source in Cisco Unified Communications Manager.
    Step 2   Synchronize the contact data to Cisco Unified Communications Manager.

    After the synchronization occurs, your contact data resides in Cisco Unified Communications Manager.

    Step 3   Provision users with CCMCIP profiles on Cisco Unified Presence or Cisco Unified Communications IM and Presence.

    The client requires a CCMCIP profile that contains the primary Cisco Unified Communications Manager server address. The client uses the CCMCIP profile to locate Cisco Unified Communications Manager and resolve contacts with UDS.

    Step 4   Specify UDS as the value of the DirectoryServerType parameter in your configuration file.
    The following is an example configuration where UDS is the directory server type:
    <Directory>
     <DirectoryServerType>UDS</DirectoryServerType>
    </Directory>
    Step 5   Configure the client to retrieve contact photos with UDS.
    The following is an example configuration for contact photo retrieval:
    <PhotoUriWithToken>http://server_name.domain/%%uid%%.jpg</PhotoUriWithToken>

    Contact Photo Retrieval

    UDS dynamically builds a URL to contact photos with a directory attribute and a URL template.

    To resolve contact photos with UDS, you specify the format of the contact photo URL as the value of the PhotoUriWithToken parameter. You also include a %%uid%% token to replace the contact username in the URL, for example,
    <PhotoUriWithToken>http://server_name.domain/%%uid%%.jpg</PhotoUriWithToken>

    UDS substitutes the %%uid%% token with the value of the userName attribute in UDS. For example, a user named Mary Smith exists in your directory. The value of the userName attribute for Mary Smith is msmith. To resolve the contact photo for Mary Smith, Cisco Jabber for Windows takes the value of the userName attribute and replaces the %%uid%% token to build the following URL: http://staffphoto.example.com/msmith.jpg

    Restriction:

    All contact photos must follow the format of the URL you specify as the value of PhotoUriWithToken.

    Set UDS Service Parameters

    You can set service parameters for UDS on Cisco Unified Communications Manager.

    Procedure
      Step 1   Open the Cisco Unified CM Administration interface.
      Step 2   Select System > Enterprise Parameters.

      The Enterprise Parameters Configuration window opens.

      Step 3   Locate the User Data Service Parameters section.

      UDS Service Parameters
      Set values for the following service parameters to configure UDS:
      Parameter Description
      Enable All User Search Allows searches for all users in the directory.
      User Search Limit Limits the number of users returned in a query.
      Number of Digits to Match Specifies the number of digits to match when users search for phone numbers.
      Tip   

      To resolve PSTN numbers, you should set the value as equal to the number of digits in the PSTN numbers. For example, if the PSTN numbers have 10 digits, set the value to 10.

      Contact Resolution with Multiple Clusters

      For contact resolution with multiple Cisco Unified Communications Manager clusters, you should synchronize all users on the corporate directory to each Cisco Unified Communications Manager cluster. You should then provision a subset of those users on the appropriate Cisco Unified Communications Manager cluster.

      For example, your organization has 40,000 users. 20,000 users reside in North America. 20,000 users reside in Europe. Your organization has the following Cisco Unified Communications Manager clusters for each location:
      • cucm-cluster-na for North America
      • cucm-cluster-eu for Europe
      In this example, you should synchronize all 40,000 users to both clusters. You then provision the 20,000 users in North America on cucu-cluster-na and the 20,000 users in Europe on cucm-cluster-eu.

      When users in Europe call users in North America, Cisco Jabber for Windows retrieves the contact details for the user in Europe from cucu-cluster-na.

      When users in North America call users in Europe, Cisco Jabber for Windows retrieves the contact details for the user in North America from cucu-cluster-eu.

      Directory Configuration Parameters

      By default, you do not need to configure Cisco Jabber for Windows to connect to the directory service. If you install Cisco Jabber for Windows on a workstation that is registered to an Active Directory domain, Cisco Jabber for Windows automatically discovers the directory service and connects to a Global Catalog in the domain.

      You can create custom configurations for LDAP services that include the following:
      • Attribute mappings
      • Connection settings
      • Query settings
      • Contact photo resolution
      • Domain federation

      Contact Photo Formats and Dimensions

      To achieve the best result with Cisco Jabber for Windows, your contact photos should have specific formats and dimensions. Review supported formats and optimal dimensions. Learn about adjustments Cisco Jabber for Windows makes to contact photos.

      Contact Photo Formats

      Cisco Jabber for Windows supports the following formats for contact photos in your directory:
      Important:

      Cisco Jabber for Windows does not apply any modifications to enhance rendering for contact photos in GIF format. As a result, contact photos in GIF format might render incorrectly or with less than optimal quality. To obtain the best quality, you should use PNG format for your contact photos.

      Contact Photo Dimensions


      Tip


      The optimum dimensions for contact photos are 128 pixels by 128 pixels with an aspect ratio of 1:1.


      The following table lists the different dimensions for contact photos in Cisco Jabber for Windows:
      Location Dimensions

      Audio call window

      128 pixels by 128 pixels

      Invitations and reminders, for example:
      • Incoming call windows
      • Meeting reminder windows

      64 pixels by 64 pixels

      Lists of contacts, for example:
      • Contact lists
      • Participant rosters
      • Call history
      • Voicemail messages

      32 pixels by 32 pixels

      Contact Photo Adjustments

      Cisco Jabber for Windows adjusts contact photos as follows:
      Resizing

      If contact photos in your directory are smaller or larger than 128 pixels by 128 pixels, Cisco Jabber for Windows automatically resizes the photos. For example, contact photos in your directory are 64 pixels by 64 pixels. When Cisco Jabber for Windows retrieves the contact photos from your directory, it resizes the photos upwards to 128 pixels by 128 pixels.


      Tip


      Resizing contact photos can result in less than optimal resolution. For this reason, you should use contact photos that are 128 pixels by 128 pixels so that Cisco Jabber for Windows does not automatically resize them.


      Cropping

      Cisco Jabber for Windows automatically crops non-square contact photos to a square aspect ratio, or an aspect ratio of 1:1 where the width is the same as the height.

      Portrait orientation

      If contact photos in your directory have portrait orientation, Cisco Jabber for Windows crops 30 percent from the top and 70 percent from the bottom.

      For example, if contact photos in your directory have a width of 100 pixels and a height of 200 pixels, Cisco Jabber for Windows needs to crop 100 pixels from the height to achieve an aspect ratio of 1:1. In this case, Cisco Jabber for Windows crops 30 pixels from the top of the photos and 70 pixels from the bottom of the photos.

      Landscape orientation

      If contact photos in your directory have landscape orientation, Cisco Jabber for Windows crops 50 percent from each side.

      For example, if contact photos in your directory have a width of 200 pixels and a height of 100 pixels, Cisco Jabber for Windows needs to crop 100 pixels from the width to achieve an aspect ratio of 1:1. In this case, Cisco Jabber for Windows crops 50 pixels from the right side of the photos and 50 pixels from the left side of the photos.

      Rounding

      Cisco Jabber for Windows rounds the corners of contact photos after retrieving them from your directory.

      Domain Federation

      Domain federation lets Cisco Jabber for Windows users communicate with users in other domains or with users in the same domain who use client applications other than Cisco Jabber for Windows.

      Interdomain Federation

      Interdomain federation enables Cisco Jabber for Windows users in an enterprise domain to share availability and send instant messages with users in another domain.

      • Cisco Jabber for Windows users must manually enter contacts from another domain.
      • Cisco Jabber for Windows supports federation with the following servers:
        • Microsoft Office Communications Server
        • Microsoft Lync
        • IBM Sametime
        • XMPP standard-based environments such as Google Talk
        • AOL Instant Messenger
      You configure interdomain federation for Cisco Jabber for Windows on Cisco Unified Presence or Cisco Unified Communications IM and Presence. See the following documentation for more information:
      • Cisco Unified Presence: Integration Guide for Configuring Cisco Unified Presence Release 8.6 for Interdomain Federation
      • Cisco Unified Communications IM and Presence: Interdomain Federation for IM and Presence Service on Cisco Unified Communications Manager

      Intradomain Federation

      Intradomain federation enables users within the same domain to share availability and send instant messages between Cisco Unified Presence and Microsoft Office Communications Server, or Microsoft Live Communications Server, or other presence server.

      Intradomain federation allows you to migrate users to Cisco Unified Presence or Cisco Unified Communications IM and Presence from a different presence server. For this reason, you configure intradomain federation for Cisco Jabber for Windows on the presence server. See the following documents for more information:
      • Cisco Unified Presence: Integration Guide for Configuring Partitioned Intradomain Federation for Cisco Unified Presence Release 8.6 and Microsoft LCS/OCS
      • Cisco Unified Communications IM and Presence: Partitioned Intradomain Federation for IM and Presence Service on Cisco Unified Communications Manager
      Configure Intradomain Federation

      In addition to configuring intradomain federation on the presence server, you might need to specify some configuration settings in the Cisco Jabber for Windows configuration files.

      To resolve contacts during contact search or retrieve contact information from your directory, Cisco Jabber for Windows requires the contact ID for each user. Cisco Unified Presence uses a specific format for resolving contact information that does not always match the format on other presence servers such as Microsoft Office Communications Server or Microsoft Live Communications Server.

      Procedure
        Step 1   Set the value of the UseSIPURIToResolveContacts parameter to true.
        Step 2   Specify an attribute that contains the contact ID that Cisco Jabber for Windows uses to retrieve contact information as the value of the SipUri parameter. The default value is msRTCSIP-PrimaryUserAddress.
        Step 3   Specify any text that prefixes each contact ID as the value of the UriPrefix parameter.

        The prefix is any text that exists before the username in the contact ID.

        For example, you specify msRTCSIP-PrimaryUserAddress as the value of SipUri. In your directory the value of msRTCSIP-PrimaryUserAddress for each user has the following format: sip:username@domain.


        The following XML snippet provides an example of the resulting configuration:
        <Directory>
          <UseSIPURIToResolveContacts>true</UseSIPURIToResolveContacts>
          <SipUri>non-default-attribute</SipUri>
          <UriPrefix>sip:</UriPrefix>
        </Directory>
        Related References
        Intradomain Federation Example

        This topic provides an example of intradomain federation contact resolution using the SipUri, UseSIPURIToResolveContacts, and UriPrefix parameters.

        In this example, your configuration has the following settings:
        • The value of the SipUri parameter is msRTCSIP-PrimaryUserAddress.
        • The value of the UseSIPURIToResolveContacts parameter is true.
        • The value of the UriPrefix parameter is sip:.
        • The directory contains sip:msmith@domain.com as the value of the msRTCSIP-PrimaryUserAddress attribute for a user named Mary Smith.
        Cisco Jabber for Windows connects to your directory to resolve contact information
        1. Your presence server passes msmith@domain.com to Cisco Jabber for Windows.
        2. Cisco Jabber for Windows appends sip: to msmith@domain.com and then queries your directory.
        3. sip:msmith@domain.com matches the value of the msRTCSIP-PrimaryUserAddress attribute.
        4. Cisco Jabber for Windows retrieves contact information for Mary Smith.
        Cisco Jabber for Windows users search for Mary Smith

        Cisco Jabber for Windows removes the prefix of sip: from sip:msmith@domain.com and gets the contact ID of msmith@domain.com.

        Single Sign-On (SSO) Deployments

        You can enable single sign-on (SSO) in certain deployment scenarios.

        Learn what SSO capabilities are available and review login flows to understand how client authentication works in an SSO deployment.

        Cloud-Based SSO

        In cloud-based deployments, Cisco Jabber for Windows supports SSO with the Cisco WebEx Messenger service.

        The following steps describe the login flow for cloud-based SSO after users start Cisco Jabber for Windows:
        1. Cisco Jabber for Windows sends a login request to the Cisco WebEx Messenger service.
        2. The Cisco WebEx Messenger service redirects Cisco Jabber for Windows to the domain where your identity provider resides.
        3. Cisco Jabber for Windows follows the redirect and requests a login token from the identity provider.
        4. The identity provider gives a login token to Cisco Jabber for Windows.
        5. Cisco Jabber for Windows passes that login token to the Cisco WebEx Messenger service.
        As a result, Cisco Jabber for Windows authenticates with the Cisco WebEx Messenger service.
        The following diagram illustrates the login flow for cloud-based SSO:
        Figure 5. Cloud-Based SSO Login Flow




        Note


        The identity provider must be Security Assertion Markup Language (SAML) compliant. Cisco Jabber for Windows has been tested with, and supports, the following products as identity providers:
        • PingFederate
        • Microsoft Active Directory Federation Services (ADFS)
        • CA SiteMinder
        • Oracle Access Manager

        Enable Cloud-Based SSO

        You specify arguments during installation to enable Cisco Jabber for Windows for SSO in cloud-based deployments.

        Related References

        Cisco AnyConnect Deployments

        Cisco AnyConnect refers to a server-client infrastructure that enables Cisco Jabber for Windows to connect securely to your corporate network from remote locations such as Wi-Fi networks or mobile data networks.

        The Cisco AnyConnect environment includes the following components:
        Cisco Adaptive Security Appliance (ASA)

        Provides a service to secure remote access.

        Cisco AnyConnect Secure Mobility Client

        Establishes an secure connection to Cisco Adaptive Security Appliance from the user's computer.

        Cisco Jabber for Windows supports secure remote access with the following:
        • Cisco AnyConnect Secure Mobility Client 2.5
        • Cisco AnyConnect Secure Mobility Client 3.1

        Cisco AnyConnect Deployment Considerations

        Cisco Adaptive Security Appliance provides a flexible architecture that can meet the needs of many different deployments. It is beyond the scope of this document to provide end-to-end deployment procedures. Rather, the purpose of this section is to provide information that you should consider when deploying Cisco Adaptive Security Appliance and Cisco AnyConnect Secure Mobility Client for Cisco Jabber for Windows.

        You should refer to the configuration guides for Cisco Adaptive Security Appliance to obtain task-based information on installing and configuring ASA.

        NAT Rules

        As part of the configuration process for ASA, you should also configure Network Address Translation (NAT) rules to support Cisco AnyConnect Secure Mobility Client. If you do not configure NAT rules, Cisco AnyConnect Secure Mobility Client cannot communicate with ASA.

        The Configuring Network Object NAT topic provides detailed instructions for configuring NAT rules.

        Session Parameters

        You can configure ASA session parameters to improve performance for secure connections. For the best user experience, you should configure the following ASA session parameters:
        Datagram Transport Layer Security (DTLS)

        DTLS is an SSL protocol that provides a data path that prevents latency and data loss.

        Auto Reconnect

        Auto reconnect, or session persistence, lets Cisco AnyConnect Secure Mobility Client recover from session disruptions and re-establish sessions.

        Idle Timeout

        Idle timeout defines a period of time after which ASA terminates secure connections, if no communication activity occurs.

        Dead-Peer Detection (DTD)

        DTD ensures that ASA and Cisco AnyConnect Secure Mobility Client can quickly detect failed connections.

        Group Policies and Profiles

        You should use the ASA Device Manager (ASDM) to create group policies, client profiles, and connection profiles. Create your group policies first and then apply those policies to the profiles. Using the ASDM to create profiles ensures that Cisco AnyConnect Secure Mobility Client downloads the profiles after it establishes a connection to ASA for the first time. The ASDM also lets you manage and maintain your policies and profiles in a central location.

        See the Cisco AnyConnect Secure Mobility Client Administrator Guide for instructions on creating policies and profiles with the ASDM.

        Trusted Network Detection

        Trusted Network Detection is a feature that automates secure connections based on user location. When users leave the corporate network, Cisco AnyConnect Secure Mobility Client automatically detects that it is outside the trusted network and then initiates secure access.

        You configure Trusted Network Detection on ASA as part of the client profile. See the Trusted Network Detection topic for more information.

        Related References
        Tunnel Policies
        Tunnel policies configure how Cisco AnyConnect Secure Mobility Client directs traffic over a secure connection and include the following:
        Full Tunnel Policy

        Lets you send all traffic over the secure connection to the ASA gateway.

        Split Tunnel Policy

        Enables you divide traffic based on destination subnets to send some traffic over the secure connection and other traffic over the non-secure connection.

        Split Include Policy with Network ACL

        Enables you to restrict secure connections based on destination IP addresses. For example, in an on-premises deployment, you can specify the IP addresses for Cisco Unified Communications Manager, Cisco Unified Presence, your TFTP server, and other servers to restrict the secure connection only to Cisco Jabber for Windows traffic.

        Split Exclude Policy

        Allows you to exclude certain traffic from the secure connection. You can allow Cisco Jabber for Windows traffic over the secure connection and then exclude traffic from specific destination subnets.

        Related References

        Set Up Certificate-Based Authentication

        Cisco recommends that you use certificate-based authentication for negotiating a secure connection to ASA from Cisco AnyConnect Secure Mobility Client.

        ASA supports certificates issued by standard Certificate Authority (CA) servers such as Cisco IOS CA, Microsoft Windows 2003, Windows 2008R2, Entrust, VeriSign, and RSA Keon. This topic gives you a high-level procedure for setting up ASA for certificate-based authentication. See the Configuring Digital Certificates topic in the appropriate ASA configuration guide for step-by-step instructions.

        Procedure
          Step 1   Import a root certificate from the CA to the ASA.
          Step 2   Generate an identity certificate for the ASA.
          Step 3   Use the ASA identity certificate for SSL authentication.
          Step 4   Configure a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP).
          Step 5   Configure the ASA to request client certificates for authentication.

          What to Do Next

          After you set up certificate-based authentication on ASA, you must distribute client certificates to your users. You can use one of the following methods with :
          • Group Policy on Microsoft Windows Server.
          • SCEP on Microsoft Windows Server.

          Distribute Certificates with Group Policy

          You can use Group Policy on Microsoft Windows Server to distribute certificates.

          To distribute certificates with Group Policy, you should do the following:
          • Install the Microsoft Group Policy Management Console (GPMC) on Microsoft Windows Server.
          • Ensure all computers or users to which you plan to distribute certificates are in the same domain.

          For more information, see the appropriate Microsoft documentation. The Deploy Certificates by Using Group Policy topic provides instructions.

          Distribute Certificates with SCEP

          You can use Simple Certificate Enrollment Protocol (SCEP) on Microsoft Windows Server to securely issue and renew certificates for client authentication.

          To distribute certificates with SCEP, you must install the SCEP module on Microsoft Windows Server. See the following topics for more information:
          • ASA 8.X: AnyConnect SCEP Enrollment Configuration Example
          • Simple Certificate Enrollment Protocol (SCEP) Add-on for Certificate Services