Microsoft Exchange calendar states on IM and Presence
Microsoft Exchange integration with
the IM and Presence Service allows users to incorporate their calendar/meeting status in
Microsoft Outlook into their availability status on
IM and Presence. The table below shows the reachability mappings, and how
IM and Presence correlates the status of meetings (as shown in Microsoft
Outlook calendar) in the availability status of users on
IM and Presence.
Table 1 Aggregated Availability State Based on Calendar State
You must configure a Microsoft Exchange server (Microsoft Outlook) as a presence gateway for calendaring information exchange. The Exchange gateway enables the IM and Presence server to reflect the availability information (calendar/meeting status) in the availability status of the user on a per-user basis.
When you configure the presence gateway, you can use one of the following values to connect with the Microsoft Exchange server:
Windows security policy settings
Cisco Unified Presence integration with Exchange supports various authentication methods including Windows Integrated authentication (NTLM).
Cisco Unified Presence supports NTLMv1 Windows Integrated authentication only and does not currently support NTLMv2.
Some Windows network security policies allow NTLMv2 authentication only, which will prevent the integration between Cisco Unified Presence and Exchange from functioning (both WebDAV and EWS). You must verify that NTLMv2 authentication is not enabled on each Windows server running Exchange. If NTLMv2 authentication is enabled, disable the setting and reboot the server to properly apply the new security setting.
Complete the following procedure to verify the current value of NTLM authentication and if necessary, to disable NTLMv2 authentication.
Select Start > Administrative Tools > Local Security Policy on the Windows server running Exchange.
Navigate to Security Settings > Local Policies > Security Options.
Select Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers.
Verify that the Require NTLMv2 session security checkbox is not checked.
If the Require NTLMv2 session security checkbox is checked, complete the following steps:
Uncheck the Require NTLMv2 session security checkbox.
Reboot the Windows server running Exchange to apply the new security settings.
IM and Presence uses X.509 certificates for secure authentication in calendaring integration with Microsoft Exchange. IM and Presence supports SAN (Subject Alternative Name) and wildcard certificates, along with standard certificates.
SAN certificates allow multiple hostnames and IP addresses to be protected by a single certificate, by specifying a list of hostnames and/or IP addresses in the X509v3 Subject Alternative Name field.
For SAN certificates, the protected host must be contained in the list of hostnames/IP addresses in the Subject Alternative Name field.
Wildcard certificates allow a domain and unlimited sub-domains to be protected by specifying an asterisk in the domain name. Names may contain the wildcard character * which is considered to match any single domain name component. For example, *.a.com matches foo.a.com but not bar.foo.a.com.
Wildcards can be placed in the Common Name (CN) for standard certificates, and in the Subject Alternative Name for SAN certificates.
Integration with Microsoft Exchange 2003 and 2007 over WebDAV
Overview of Exchange integration over WebDAV Interface
Microsoft Exchange server (2003 and 2007 versions) support WebDav-based calendar integration.Figure 1 shows how the Microsoft Exchange server (2003 and 2007 versions) integrates with IM and Presence using the Outlook Web Access (OWA) protocol, over a WebDAV interface exposed by the Exchange server.
IM and Presence can only communicate with a single WebDav front-end Exchange server. The Exchange front-end server communicates with multiple Exchange back-end servers that you configure during the Webdav setup. Microsoft Exchange communicates with IM and Presence via a Presence Gateway configured for the Exchange server on IM and Presence.
Figure 1. Microsoft Exchange Integration with IM and Presence Architecture
Administrative roles and permissions in Exchange 2003/2007
By default in Microsoft Exchange 2003 and 2007, administrators are denied permission to sign into a user mailbox on the Exchange server. In order for IM and Presence to connect to mailbox stores on the Exchange server and query end-user calendaring data, it requires an Exchange account with special permissions, referred to as a 'receive-as' account.
Overview of Exchange integration over the EWS interface
In addition to WebDAV integration, Microsoft Exchange 2007 introduces Exchange Web Services (EWS) for calendaring integration using a SOAP-like interface to the Exchange server. For Microsoft Exchange 2010, WebDAV is no longer supported and customers can only use EWS for calendaring integration.
The Meeting Notification feature will only work if your Exchange integration is with Microsoft Exchange 2003 or 2007 over WebDAV.
Administrative roles and permissions in Exchange Server 2007/2010
Just as WebDAV access requires a special account to enable access to all users accounts, EWS requires a similar capability. EWS manages this capability by assigning a "role" to a designated account. This role has the impersonation permission.
Microsoft Exchange Server 2007
For a caller to access the email account of another user on an Exchange 2007 server, the EWS integration requires an account with Impersonation permissions. The caller impersonates a given user account using the permissions that are associated with the impersonated account instead of the permissions that are associated with the account of the caller.
The impersonated account must be granted the ms-Exch-EPI-Impersonation right on the Client Access Server (CAS) running Exchange 2007. This gives the caller the permission to impersonate a user email account using the CAS server. In addition, the caller must be granted the ms-Exch-EPI-MayImpersonate right on either the mailbox database or on the individual user objects in the directory.
Note that the Access Control List (ACL) for an individual user takes precedence over the mailbox database setting so that you can allow a caller access to all mailboxes in the database but if required, deny access on certain mailboxes in that database.
Microsoft Exchange Server 2010
Microsoft Exchange Server 2010 uses Role-Based Access Control (RBAC) to assign permissions to impersonation accounts and allow users to perform tasks specific to their function in the organization. Depending on whether the user is an administrator or super user, or an end-user, there are two primary methods to apply RBAC permissions:
Management role groups—Microsoft provides 11 default management role groups during the Exchange setup process with associated permissions specific to the role of the group. The Recipient Management and Help Desk, for example, are built-in role groups. Typically, super users who need to perform specific tasks are assigned to the relevant management role group and inherit the associated permissions. For example, a Product Support representative who needs to be able to modify the contact details of any user across the entire Exchange organization may be assigned as a member of the Help Desk management role group.
Management role assignment policies—For normal users who are not administrators or super users, management role assignment policies control which specific mailboxes such users can modify. The ApplicationImpersonation role, when assigned to the user using the New-ManagementRoleAssignment cmdlet, enables an account to impersonate users in an organization to perform tasks on behalf of the user. The scope of the role assignments are managed individually using the New-ManagementScope cmdlet, and can be filtered to target specific recipients or specific servers.
With RBAC, you do not need to modify and manage the ACL as required for Exchange Server 2007.
Presence Gateway Configuration for Microsoft Exchange Server 2007/2010 integrations
To support a large number of users (with EWS calendar
the IM and Presence Service must distribute the load of EWS traffic among multiple CAS
IM and Presence can connect to a number of CAS servers via EWS, and it uses
this round robin strategy to support the traffic load that it encounters:
The first time that a user's calendar subscription is enabled, the
user is assigned a CAS from a pool of eligible CAS hosts configured by the
The user retains the assignment until their calendar subscription
If the user’s calendar subscription fails, the user is again
assigned a CAS server from the pool of eligible CAS hosts.
Each CAS requires its own intermediate certificate so that
IM and Presence can trust the intermediate certificate chain.
This release of
IM and Presence does not support the Microsoft Exchange autodiscover
service. The autodiscover service assumes that a load-balancing mechanism is
already in place across the CAS servers.
When configuring your EWS presence gateway for Exchange
IM and Presence Administration, note the following:
You cannot deploy a mixed environment of WebDAV and EWS servers.
You must either configure a single WebDAV server or one or more EWS server
gateways but not both.
You can add, update or delete one or more EWS servers with no
maximum limit. However, the Troubleshooter on the Presence Gateway window is
designed to only verify and report status of the first 10 EWS servers that you
EWS server gateways share the credentials (Account Name and
Password) that you configure for the first EWS server gateway. If you change
the credentials for one EWS server gateway, the credentials change accordingly
on all of the configured EWS gateways.
You must restart the Cisco Presence Engine after you add,
update or delete one or more EWS servers for your configuration changes to take
effect. If you add multiple EWS Servers one after another, you can restart the
Cisco Presence Engine once to effect all your changes simultaneously.
Before you configure Microsoft Exchange integration with
IM and Presence, consult the compatibility matrix below and make sure that
you have installed and configured the required components for this integration:
Table 2 Compatibility Matrix
Install Compatible Version
Packs for Windows Server 2003 (SP2)
Packs for Windows Server 2008 (SP2)
Cisco Unified Communications Manager
Release 9.0(1), or higher
IM and Presence
Release 9.0(1), or higher
Microsoft Exchange Server 2003
Latest Service Packs for Microsoft Exchange 2003
Microsoft Exchange Server 2007
Latest Service Packs for Microsoft Exchange 2007
Microsoft Exchange Server 2010
Latest Service Packs for Microsoft Exchange 2010
2003 with Windows Server 2003 (SP2)
-- OR --
2008 with Windows Server 2008 (SP2)
User names configured in Active Directory must be identical
to those names defined in
Cisco Unified Communications Manager.
A Third-Party Certificate OR Certificate Server
One or the other of these is required to generate
Use the Cisco Unified CM IM and Presence User Options pages to configure
calendaring states on client applications.
Cisco Unified Communications Manager and IM and Presence Documentation