Veröffentlicht am 25-03-2019

Cisco Webex Hybrid Calendar Service und Exchange 2010

Ich habe ein Problem mit einem Webex Hybrid Calendar-Setup mit Exchange 2010 behoben, und Cisco TAC weigerte sich anfangs, das Setup zu unterstützen, dass Exchange SP2 in den Protokollen angezeigt wird.

2019–03–25T10: 19: 37.007 + 01: 00 geänderter Managementconnector: UTCTime = ”2019–03–25 09: 19: 37,7" Modul = "hybridservices.managementconnector" Ebene = "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'Adresse ': u'https: //ews.redacted.com/ews/ exchange.asmx '}, {u'state': u'ok ', u'version': u'Exchange2010_SP2 ', u'typ': u'exchange ', u'stateDescription': u'Exchange Server ok. ',

Bei einer kurzen Googlingsitzung kam ich jedoch zu dieser Diskussion in einem Microsoft-Forum, in dem ein Benutzer gefragt wurde, ob SP3 beim Abfragen der EWS-API angegeben werden kann. Die Antwort lautet nein. Die Version der API wurde nicht mit SP3 geändert und wird weiterhin als SP2 gemeldet, wie von einem Michael Mainer beantwortet:

Die Schemaversion gibt die minimale Serverversion an, die die durch das Schema beschriebene Funktionalität unterstützt. Wir haben keine 2010_SP3-Version hinzugefügt, da sich das Schema nicht geändert hat.

SO TL; DR Wenn Sie Exchange 2010 SP3 ausführen, wird immer noch SP2 in den Expressway-Protokollen angezeigt. Überprüfen Sie die genauen Versionen mit Ihrem Exchange-Team.

Eine andere Diskussion, die ich mit TAC hatte, betraf den Wert von EWSMaxSubscriptions, den wir auf 10 000 gesetzt hatten, da dies die erwartete Anzahl von Benutzern ist, die mit Hybrid Calendar aktiviert werden soll.

New-ThrottlingPolicy -Name .Name "CalendarConnectorPolicy" -EWSMaxConcurrency $ null -EWSPercentTimeInAD 100 -EWSPercentTimeInCAS 500 -EWSPercentTimeInMailboxRPC 300 -EWSMaxSubscriptions 5000 -EWSFastSearchTimeoutInSondsFeed

Dies basiert auf meinen Erfahrungen aus einer früheren Bereitstellung mit mehr als 20.000 Benutzern, bei denen die Connectors bei 5000 hängen blieben, bis dieser Wert tatsächlich auf die Anzahl der Mailboxen eingestellt wurde, für die das Identitätswechselkonto zu abonnieren versucht Der Leitfaden sollte als ein Beispiel betrachtet werden, das auf der Validierung basiert, die sie in ihren Laboren vorgenommen haben. TAC bestand darauf, dass sich das geändert hat, was der Leitfaden sagt, und erwähnte:

EWSMaxSubscriptions bedeutet nicht ausdrücklich, wie viele Benutzer abonniert werden können. Sie definiert die maximale Anzahl aktiver Push-, Pull- und Streaming-Benachrichtigungsabonnements, die ein Benutzer gleichzeitig auf einem bestimmten Clientzugriffsserver haben kann.

Je mehr ich lese, desto mehr verstehe ich als genau, was ich geschrieben habe - d. H. 10k-Mailboxen zum Anschauen = 10 000 EWSMaxSubscriptions.

Unabhängig davon bestand ich darauf, dass eine höhere als die geforderte Begrenzung kein Problem sein kann und sollte, und wenn sie möchten, dass ich diesen Wert ändert, sollten sie erklären, wie und warum es ein Problem ist. Sie konnten nicht so weitermachen.

Die Jury ist jedoch noch nicht auf den Wert von EWSMaxSubscriptions eingestellt. Zumindest für mich. Und oh Mann, ist der MS-Doc über diese verwirrende Hölle. Wird bei Ereignissen aktualisiert.

In einer Randnotiz wird das eigentliche Problem, das ich mit dem TAC-Fall angesprochen habe, hier nicht erörtert, aber es war sowieso nicht so interessant

Siehe auch

Auswahl einer zukunftssicheren Infrastruktur für Ihre Smart City-BereitstellungMarshall Woburn II Bluetooth-Lautsprecher BEWERTUNGWeb 101 Die wichtigsten Fragen, die Sie als Entwickler wissen sollten!Sind IT-Zertifizierungen ausreichend? Oder brauchst du einen Abschluss?Der neugierige Fall von Phantom-UhrenSie sagten