Cisco Webex Hybrid Calendar Service and Exchange 2010

I was troubleshooting a Webex Hybrid Calendar setup with Exchange 2010 and initially Cisco TAC refused to support the setup stating that they see Exchange SP2 in the logs.

2019–03–25T10:19:37.007+01:00 redacted managementconnector: UTCTime=”2019–03–25 09:19:37,7" Module=”hybridservices.managementconnector” Level=”DEBUG” CodeLocation=”atlas(202)” Detail=”_get_post_request_data: {‘status’: {‘alarms’: [], ‘connectorStatus’: {u’services’: {u’onprem’: [{u’state’: u’ok’, u’version’: u’Exchange2010_SP2', u’type’: u’exchange’, u’stateDescription’: u’Exchange server ok.’, u’address’: u’https://ews.redacted.com/ews/exchange.asmx'}, {u’state’: u’ok’, u’version’: u’Exchange2010_SP2', u’type’: u’exchange’, u’stateDescription’: u’Exchange server ok.’,

However, a quick googling session took me to that discussion in a Microsoft forum where a user was asking whether there is a way to specify SP3 when querying the EWS API. The answer is no, there isn't as the version of the API was not changed with SP3 and is still reported as SP2, as answered by a Michael Mainer:

The schema version indicates the minimum server version that supports the functionality described by the schema. We didn’t add a 2010_SP3 version since the schema didn’t change.

So TL;DR if you are running Exchange 2010 SP3 you will still see SP2 being reported in the Expressway logs. Check the exact versions with you Exchange team.

Another discussion I had with TAC was about the EWSMaxSubscriptions value which we had set to 10 000 as that is the expected number of users to be enabled with Hybrid Calendar and which the Cisco deployment guide suggests to be set to 5000:

New-ThrottlingPolicy -Name “CalendarConnectorPolicy” -EWSMaxConcurrency $null -EWSPercentTimeInAD 100 -EWSPercentTimeInCAS 500 -EWSPercentTimeInMailboxRPC 300 -EWSMaxSubscriptions 5000 -EWSFastSearchTimeoutInSeconds 60 -EWSFindCountLimit 1000

This is based on my experience from a previous deployment with 20 000+ users where the connectors were stuck at 5000 until we actually bumped this value to match the number of mailboxes to which the impersonation account is trying to subscribe. So since then for me the value in the Cisco guide has been just an example based on the validation they did in their labs. TAC were insisting on having that changed to what the guide says and mentioning that:

EWSMaxSubscriptions does not specifically mean how many users can be subscribed to. It defines the maximum number of active push, pull, and streaming notification subscriptions that a user can have on a specific Client Access server at one time.

Which the more I read, the more I understand as exactly what I wrote — i.e. 10k mailboxes to look at = 10 000 EWSMaxSubscriptions 🤷🏻‍♂️.

Regardless of that I insisted that a higher than the required limitation can't and should not be a problem and if they want me to change that value they should explain how and why it is a problem. They couldn't so we moved on.

The jury is still out on the EWSMaxSubscriptions value though. At least for me. And oh boy is the MS doc about that confusing as hell. Will update as events unfold or if someone actually explains that to me as I can't be bothered to dig in that much details on the Exchange stuff.

On a side note, the actual issue I opened that TAC case is not discussed here, but it was not that interesting anyways 😀