Cloud Monitoring

Wenn alles in der Cloud läuft, müssten Sie ja kaum noch was überwachen, denn der Betrieb wird ja durch den Anbieter bereitgestellt. Das stimmt so aber natürlich nicht und insbesondere beim Exchange Hybrid Mode sollten Sie doch den Systemen genauer auf die Finger schauen. Das hilft auch, um bei Problemen die häufigsten Fehler automatisiert auszuschließen und damit Zeit zu sparen. Auf dieser Seite möchte ich ein paar Denkanstöße geben. Die Umsetzung muss natürlich in ihrer eigenen Monitoring-Lösung erfolgen.

Lizenzen

Ohne Lizenzen geht auch in der Cloud nichts und es wäre schon peinlich, wenn für neue Benutzer keine Lizenz mehr zugewiesen werden kann oder eine Lizenz nicht verlängert wird. Daher sollten wir diese Kennzahlen im Blick behalten:

  • Lizenzauslastung
    Welche Lizenzen sind wie stark beansprucht und eigentlich sollte man immer eine Lizenz mehr haben, also tatsächlich gebraucht wird. Ansonsten funktioniert auch die automatische Zuweisung nicht.
  • Lizenzablauf
    Interessant ist natürlich auch, wann Lizenzen verlängert werden müssen bzw. wann diese auslaufen. In Office 356 können Sie und https://portal.office.com/AdminPortal/Home#/BillingNotifications hinterlegen, wer eine Mail bei anstehenden Verlängerungen bekommt. Aber Urlaub, personelle Veränderungen etc. werden hier nicht automatisch berücksichtigt. Also sollten sie den Status per Graph der Microsoft Online PowerShell regelmäßig abfragen.
  • Azure Kosten
    Azure kennt keine klassische Lizenzierung aber da es sich auch hier um "Kosten" handelt, führe ich "Azure Consumption" hier mit auf. Ein Reporting als auch Steuerung erfolgt idealerweise direkt in Azure Cost Management (https://portal.azure.com/#blade/Microsoft_Azure_CostManagement/). In Azure selbst betriebene VMs und das VPN zu Azure können Sie natürlich genauso wie On-Premises-Server behandeln und klassisch überwachen.

Netzwerk

Anwender können Dienste in der Cloud nur nutzen, wenn Sie die Cloud erreichen. Damit gibt es mehrere Faktoren, die geprüft werden können. Nicht alle Checks funktionieren in jeder Konstellation. Clients hinter einer sehr restriktiven Firewall und Proxy-Zwang können meist auch keine externe DNS-Auflösung nutzen.

  • Namensauflösung
    Wenn die Clients direkt zu Office 365 dürfen, dann könnte man z.B. die Namen "outlook.office365.com" prüfen. Er muss auflösbar sein und idealerweise zu richtigen Datacenter verweisen. .
  • Firewall/Proxy Erreichbarkeit
    Die Verbindung zu den verschiedenen Gegenstellen kann geprüft werden. Ein einfacher HTTP-Abruf einer bekannten Office 365 URL (Siehe auch End2End-HTTP) kann hier schon helfen. Aber auch oft unbeachtete Ports wie 3478/UDP (Siehe auch End2End-UDP3478) sind eine regelmäßige Überprüfung werde
  • Performance und Volumen
    Die Überwachung der Netzwerkanbindung hinsichtlich Auslastung (SNMP) und Datenvolumen (NetFlow) kann bei einer mittelfristigen Planung helfen. Interessant kann hier auch eine kontinuierliche Überwachung der Performance sein, z.B. indem Latenzzeiten von bestehenden Verbindungen oder durch synthetische Tests erfasst werden.

Bei den meisten Firmen wird es aber wohl erst einmal auf ein klassisches einfaches Auslastungsmonitoring hinauslaufen.

ADSync / GAL

Nur ganz leine Firmen kommen ohne ADSync aus. Dieser Hintergrundprozess verrichtet in den meisten Fällen seine Arbeit still und leise. Die Herausforderung ist, dass Probleme gar nicht groß auffallen und die Mail an den Admin oft überlesen wird. Die Auswirkungen kommen aber später, z.B. wenn Personen nicht auftauchen, Kennworte nicht abgeglichen werden, Mails an Verteile nicht alle vorgesehenen Empfänger erreichen uns vieles mehr. Daher ist eine Überwachung des ADSync-Prozess und beim Einsatz von Exchange auch der "Globalen Adressliste" wichtig.

  • ADSync: Last Replication Datum
    ADSync gleich in der Regel alle 30 Minuten die Änderungen ab. Diesen Prozess können Sie in der Cloud überprüfen aber auch im lokalen Eventlog sehen.
  • ADSync: Version
    Bis 2020 hat Microsoft alle jemals veröffentlichten ADSync-Versionen weiter unterstützt. Wer sich aber die Versionsgeschichte anschaut, wird alleine schon ab und an ein Update machen. ADSync macht sogar ein "SelfUpdate". Dennoch ist ein Blick auf die Version von ADSync wichtig um hier eine Blockade zu verhindern.
  • AD-Objekte und IDFIX
    ADSync kann nur so gut sein, wie die Stammdaten im lokalen Active Directory. Ungültige Domänen im UPN, doppelt vergebene SMTP-Adresse, ungültige Zeichen in verschiedenen Feldern werden von ADSync meist übergangen und landen erst nach der Korrektur in der Cloud. Nicht umsonst gibt es von Microsoft das Programm IDFix, um im Vorfeld die meisten derartigen Probleme zu korrigieren. Sinnvoll ist aber eine kontinuierliche automatische Kontrolle.
  • Exchange-GAL
    Wenn ADSync fehlerfrei synchronisiert, dann ist das noch keine Gewähr, dass auch in Exchange alles OK ist. Ich habe mit extra das Skript Compare-GAL gebaut, um die Konsistenz zu prüfen. Manchmal "sieht" ADSync nicht alle Objekte (Rechte oder OU-Filter) und Auch Administratoren legen manchmal Objekte falsch in der Cloud an. (Siehe auch Doppelpostfach mit Exchange Online)

Services

Wir sollten alle mal davon ausgehen, dass Microsoft die eigenen Dienste umfangreich überwacht. Meist funktioniert dies auch wenn manchmal ein Fehler nicht sofort erkannt wird, z.B. ein abgelaufenes Zertifikat.

We've determined that an authentication certificate has expired causing, users to have issues using the service. We're developing a fix to apply a new certificate to the service which will remediate impact. Further updates can be found under TM202916 in the admin center.
https://twitter.com/MSFT365Status/status/1224351597624537088

Manchmal ist die Meldung auf dem Twitter-Kanal https://twitter.com/MSFT365Status sogar schneller also die Statusberichte auf https://portal.office.com/adminportal/home#/servicehealth oder https://status.office365.com/ oder mittels REST-API (Siehe auch Office 365 Service Communications API). Allerdings schaut natürlich niemand kontinuierlich auf diese Seiten und einige Informationen bekommen sie auch nur nach vorheriger Anmeldung.

Dennoch ist diese Abfrage durchaus ratsam und einen passenden PRTG-Sensor gibt es auf PRTG mit Office 365

Exchange Online

Microsoft überwacht natürlich die Exchange Online Services aber als Kunde ist es dennoch hilfreich, einige eigene Kennzahlen zu erfassen. In der Exchange Online PowerShell gibt es zwar einige interessante Commandlets, die aber bei meinen letzten Kontrollen alle nicht mehr aktiv waren. Darunter fallen z.B. Get-Subscription, Get-MailFlowStatusReport und Get-HybridMailflow. Die allgemeinen Exchange Online Statusseite ist aber doch etwas unspezifisch, so dass ich durchaus einige Tests für ratsam halte, z.B.

  • EXO: Anzahl der noch nicht zugestellten Mails überwachen.
    Leider gibt es in der Cloud keine "Warteschlangen" pro Tenant aber mit "Get-MessageTrace -Status pending" gibt es durchaus ein paar Einblicke, wenn Mails hängen bleiben
  • Nachrichten in der Quarantäne
    Diese werten gerne übersehen und nach 30 Tagen gelöscht. Vielleicht macht es ja Sinn, die Anzahl mit "Get-QuarantineMessage" regelmäßig zu erfassen um Abweichungen von dem "Normalzustand" zu bemerken, z.B. wenn plötzlich sehr viele Mails dort landen.
  • Warteschlangen zur Cloud
    Wenn Sie einen On-Premises Server betreiben und Mails darüber routen, dann können sie natürlich auch die Warteschlangen zur Cloud auswerten. Die Anzahl der wartenden Mails ist dabei weniger wichtige wie das Alter der ältesten Mail oder die Zufluss und Abfluss-Rate. "Get-MailFlowStatusReport", "Get-MessageTracking"
  • Zertifikate und Verbindung
    Es ist durchaus sinnvoll auch die Gültigkeit der eigenen Zertifikate als auch der Zertifikate auf der anderen Seite zu prüfen. Störungen aufgrund abgelaufener Zertifikate kommen in den besten Familien vor.
  • Roundtrip-Sensor
    Wer es zur Perfektion treiben will, der sendet regelmäßig eine Testnachricht zwischen den Systemen hin und her und misst die Laufzeit. Eine Mail an "ungueltig@<tenantname>.onmicrosoft.com" wird in der Regel von On-Premises zur Cloud gesendet und kommt nach einigen Zwischenstationen wieder als Unzustellbar zurück. Senden Sie diese Mail aus einem Test-Postfach
  • Federation Gateway
    Für die Funktion von Free/Busy-Abfragen ist es erforderlich, dass sie ein gültiges Federation Zertifikat auf allen Servern haben und die Server die Federation-Services auch erreichen können. Eine Kontrolle der URL, des Zertifikats und generell der Federation z.B. über das Commandlet "Test-FederationTrust" ist eine gute Idee.
  • Autodiscover/EWS/MRSProxy
    Je nach Hybrid-Umgebung ist auch die Erreichbarkeit dieser Dienste zu prüfen, z.B. durch synthetische Abrufe aus dem Internet einer URL wie "https://<serverĀ“-FQDN>/ews/exchange.asmx" oder der mrxproxy.dll. Auch eine 404 -Fehler (Auth Required) zeigt aber schon, dass DNS, Zertifikat und Reverse Proxy funktionieren und EWS und der Migrationsendpunkt im Prinzip erreichbar sind.

Weitere Dienste

Sicher können Sie noch mehr Dinge überwachen und eine Überwachung ist für die ein oder andere Umgebung noch lange nicht ausreichend. Es gibt ja auch andere Kennzahlen, die in der Cloud zur Verfügung stehen und ausgewertet werden können. Man muss aber immer abwägen, wie man man hier gehen kann und gehen muss.

Ich kann mir vorstellen, diese Seite auch im andere Dienst zu erweitern.

Monitoring hat primär das Ziel die Verfügbarkeit zu überwachen. Die nächste Stufe ist dann ein "Reporting" der Erreichbarkeit über mehrere Wochen oder Monate. Natürlich könnte man noch einen Konfiguration-Check einbauen, der z.B. ablaufende Zertifikate meldet und wenn ein Skript eh schon die Konfiguration liest, könnte diese auch gleich als HTML-Datei dokumentiert werden. Ideen gibt es genug.

Weitere Links