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.
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
Users can publish their availability and subscribe to other users' availability through Cisco Unified Presence.
Users send and receive instant messages through Cisco Unified Presence.
Users place audio calls through desk phone devices or on their computers through Cisco Unified Communications Manager.
Users share their screens and place video calls through Cisco Unified Communications Manager.
Users send and receive voice messages through Cisco Unity Connection.
Cisco WebEx Meeting Center provides hosted meeting capabilities.
For information about contact sources in on-premises deployments, see Directory Service in On-Premises Deployments.
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.
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.
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.
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.
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.
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.
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:
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:
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.
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:
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.
Encryption and SSL
By default, the client encrypts all data over the network, including authentication and query data. The UseSecureConnection parameter lets you enable or disable encryption.
You can use SSL for connections to your directory with the
UseSSL parameter. You can use SSL with a
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.
Default protocols and ports for SSL connections are as follows:
Port number: 3269
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:
Additionally, ensure you index the following attributes for secondary number queries:
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.
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.
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
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.
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,
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,
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
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.
To enable integration with UDS, perform the following steps:
Create your directory source in Cisco Unified Communications Manager.
Synchronize the contact data to Cisco Unified Communications Manager.
After the synchronization occurs, your contact data resides in Cisco Unified Communications Manager.
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.
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:
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,
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
All contact photos must follow the format of the URL you specify as the value of PhotoUriWithToken.
You can set service parameters for UDS on Cisco Unified Communications Manager.
Open the Cisco Unified CM Administration interface.
Select System > Enterprise Parameters.
The Enterprise Parameters Configuration window opens.
Locate the User Data Service Parameters section.
UDS Service Parameters
Set values for the following service parameters to configure
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.
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:
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
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.
Set the value of the UseSIPURIToResolveContacts parameter to true.
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.
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:
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.
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 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.
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.
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, or session persistence, lets Cisco AnyConnect Secure Mobility Client recover from session disruptions and re-establish sessions.
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 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.
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.
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.
Import a root certificate from the CA to the ASA.
Generate an identity certificate for the ASA.
Use the ASA identity certificate for SSL authentication.
Configure a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP).
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 :