Office 365 Status

Achtung: Mein Skript funktioniert nicht mehr. Microsoft hat im den September 2019 die alte "Office Discovery Service API" API abgeschaltet. Auch die zwischenzeitlich bereitgestellte Office 365 Management API wird durch Graph abgelöst.

Ein kurzer Überblick über die APIs:

API

Status

Office Discovery Service API (Nutzbar von 2015-2019)

Abgeschaltet

Office 365 Management API

We'll be retiring the legacy version of the Service Communications API beginning December 17, 2021
https://docs.microsoft.com/en-us/office/office-365-management-api/office-365-service-communications-api-reference

Für meinen Tenant wurde die API am 4. Jan 2022 abgeschaltet

Abgeschaltet

Graph Service health and communications

OK

Für die beiden letzten APIs müssen Sie eine Azure App Registration mit Berechtigungen anlegen:

Ihre Server On-Premises überwachen Sie natürlich und bekommen Bescheid, wenn etwas nichts geht. In der Cloud überwacht Microsoft die Dienste und zeigt ihnen einen Status an. Aber wie integrieren Sie die Office 365 Statusanzeige in ihre eigene Monitoring-Lösung? Das ist Thema auf dieser Seite.

Für die Anzeige des Status reicht es nicht "Benutzer" zu sein. Lauf API-Beschreibung müssen Sie "Globaler Administrator" oder ein Partner mit delegierten Administratorrechten sein. "Dienstadministrator" reicht nicht aus.

Einen Status zum AzureAD, insbesondere Ausfälle des Authentifizierungsdienstes finden Sie auf https://status.azure.com/de-de/status/history/

Status im Browser

Wenn Sie sich als Administrator an Office 365 anmelden, dann sehen Sie den aktuellen Status prominent auf der Startseite:

Im Dienststatus ist die Anzeige natürlich noch etwas ausführlicher:

Im alten Admin Center war der Status direkt auf dem Dashboard sichtbar:

Hier ist gut zu sehen, das zu dem Zeitpunkt der SharePoint und Exchange-Service beeinträchtigt waren. Nun bin ich kein Admin, der dauernd den Webbrowser  geöffnet und erst recht in Office 365 angemeldet stehen lässt. Ich überwache aber die Firmenserver und hier würde ich gerne diesen Status einbinden.

Status per Admin App

Für Office 365 gibt es auch mittlerweile eine Smartphone App, die sowohl der Status anzeigt aber auch im Mitteilungsfenster entsprechende Meldungen wiedergibt: Hier am Beispiel der verschiedenen Apps.

  • Apple IOS
  • Android
  • Windows Phone

Microsoft erlaubt es so einen Administrator immer über aktuelle Probleme mit seinem Tenant informiert zu sein.

Zugriff auf Events per Manage.Office.com

Wenn Sie all diese Informationen automatisiert abfragen wollen, dann sollten sie die Graph API oder die Office 365 Service Communications API nutzen.

Ein Beispielcode zur Abfrage des Office 365 Status finden Sie auf Office 365 Service Communications API

Zugriff auf Events per Office 365 Service Communications API (alt)

Hinweis:
Dieses Kapitel beschreibt die erste "Office 365 Service Communications API" https://msdn.microsoft.com/library/office/dn776043.aspx. Diese wird zukünftig aber von einer neuen Version (https://msdn.microsoft.com/en-us/library/dn707386.aspx) abgelöst, die etwas anders funktioniert.

Natürlich könnte ich nun wie bei einigen anderen Sensoren mit PowerShell die Webseite abfragen und wie bei früheren BTX-Programmen den Bildschirm "abgreifen". Das muss aber nicht sein, das Office 365 auch hierfür entsprechende Schnittstellen anbietet. Diese sind natürlich erst nach erfolgreicher Anmeldung zugänglich. Allerdings reicht dazu nicht einfach ein HTTP-Get mit entsprechenden Anmeldedaten. Wir müssen zuerst uns ein Token besorgen, mit dem dann alle weiteren Zugriffe auf diese API abgesichert werden. Aber auch das ist recht einfach machbar, wie das folgende Beispiel zeigt:

# Anmeldedaten sammeln
$cred = get-credential
# JSON Anfrage formulieren
$jsonPayload = (`
   @{ UserName=$cred.Username; `
      password=$cred.GetNetworkCredential().password;} `
   | convertto-json).tostring()
# Anmeldecookie anfordern
$cookie = (invoke-restmethod `
      -contenttype "application/json" `
      -method Post `
      -uri "https://api.admin.microsoftonline.com/shdtenantcommunications.svc/Register" `
      -body $jsonPayload).RegistrationCookie

$jsonPayload = (@{lastCookie=$cookie;locale="en-US";preferredEventTypes=@(0,1)} `
   | convertto-json).tostring()
$events = (invoke-restmethod `
      -contenttype "application/json"  `
      -method Post  `
      -uri "https://api.admin.microsoftonline.com/shdtenantcommunications.svc/GetEvents"  `
      -body $jsonPayload)

$events.Events `
   | select {$_.AffectedServiceHealthStatus.InternalName},{$_.AffectedServiceHealthStatus.status},status

$_.AffectedServiceHealthSt $_.AffectedServiceHealthSt Status
atus.InternalName                         atus.status
-------------------------- -------------------------- ------
Exchange                                            1 Service restored
Exchange                                            1 Post-incident report p...
Lync                                                1 Post-incident report p...
Exchange                                            1 Post-incident report p...
Exchange                                            1 Post-incident report p...
Lync                                                1 Service restored
Lync                                                1 Service restored
SharePoint                                          5 Post-incident report p...
Lync                                                1 Service restored
Lync                                                1 Service restored
Lync                                                1 Service degradation
Exchange                                            1 Post-incident report p...
SharePoint                                          5 Service restored
Exchange                                            1 Service restored
Exchange                                            1 Service restored
Lync                                                1 Service restored
Exchange                                            1 Post-incident report p...
Exchange                                            1 Service restored
Exchange                                            1 Service degradation
MobileDeviceManagement                              5 Service restored
Intune                                              5 Service restored
MobileDeviceManagement                              5 Service restored
Intune                                              5 Service restored
Intune                                              5 Service restored
OSDPPlatform                                        5 Service restored
OSDPPlatform                                        5 Service restored
Intune                                              5 Service restored
Intune                                              5 Service restored
MobileDeviceManagement                              5 Service restored

Der numerische Status ist wie folgt definiert:

AffectedServiceHealthStatus : {@{InternalName=SharePoint; ServiceFeatureStatus=System.Object[]; ServiceName=SharePoint Online; Status=2}} 

5 is No Issues
4 is Investigating
3 is Extended Recovery
2 is Restoring Service
1 is Degraded

Aber es ist auch gut zu sehen, dass für verschiedene Produkte mehrere Einträge vorliegen. Also habe ich mir das für Exchange einmal genauer angeschaut:

$events.events `
   | ? { `
         $_.AffectedServiceHealthStatus.InternalName -eq "Exchange"} `
   | select LastUpdatedTime,status,StartTime,EndTime

LastUpdatedTime     Status              StartTime           EndTime
---------------     ------              ---------           -------
29.04.2016 23:19:10 Service restored    21.04.2016 19:00:00 29.04.2016 23:00:00
09.05.2016 20:12:12 Post-incident re... 22.04.2016 19:00:00 03.05.2016 19:55:00
03.05.2016 06:13:54 Post-incident re... 23.04.2016 15:54:00 26.04.2016 01:30:00
05.05.2016 14:59:00 Post-incident re... 21.04.2016 19:00:00 29.04.2016 16:30:00
13.05.2016 03:25:23 Post-incident re... 25.04.2016 01:51:00 09.05.2016 17:30:00
06.05.2016 18:39:49 Service restored    05.05.2016 22:00:00 06.05.2016 01:40:00
13.05.2016 16:57:32 Service restored    06.05.2016 23:00:00 13.05.2016 00:00:00
13.05.2016 02:41:39 Post-incident re... 12.05.2016 14:00:00 12.05.2016 17:20:00
12.05.2016 21:07:32 Service restored    12.05.2016 13:00:00 12.05.2016 18:45:00
15.05.2016 05:57:52 Service degradation 13.05.2016 19:00:00

Interessant ist hier also nur der Event, der noch keine "EndTime" hat. Entsprechend kann die Abfrage dann vereinfacht werden

$events.Events `
   | ?{$_.EndTime -eq $null} `
   | select {$_.AffectedServiceHealthStatus.InternalName},{$_.AffectedServiceHealthStatus.status},status

$_.AffectedServiceHealthSt $_.AffectedServiceHealthSt Status
atus.InternalName                         atus.status
-------------------------- -------------------------- ------
Lync                                                1 Service degradation
Exchange                                            1 Service degradation

Damit erhalten wir einfach die Liste der Dienste, die aktuell einen Fehler haben. Diese Liste kann man zählen und damit die Anzahl der Probleme erhalten. Interessanter finde ich aber, wenn man alle Dienste hat und einfach deren aktuellen als Wert übergibt.

Eine Liste der "Events" ist mir aber nicht ausreichend, da hier nur die Events und Services enthalten sind, die gerade einen Fehler habe. Interessanter finde ich hier dann schon die Liste der Services:

$Serviceenpoints = (invoke-restmethod `
   -contenttype "application/json"  `
   -method Post  `
   -uri "https://api.admin.microsoftonline.com/shdtenantcommunications.svc/GetServiceInformation"  `
   -body $jsonPayload)
}

$Serviceenpoints 

FeatureNames                            ServiceName
------------                            -----------
{Sign-in, E-Mail and calendar access... Exchange Online
{Sign-In, Administration}               Identity Service
{Portal, Administration, Purchase an... Office 365 Portal
{Audio and Video, Federation, Manage... Skype for Business
{Provisioning, SharePoint Features, ... SharePoint Online
{Yammer Components}                     Yammer Enterprise
{Mobile Device Management}              Mobile Device Management
{Planner}                               Planner
{Sway}                                  Sway

Diese Liste kann ich nun weiter verwenden, um die ermittelten Statusmeldungen auf die ServiceEndpoints zu mappen.

Wer es noch genauer haben will, kann natürlich zu jeden ServiceEndpoint noch das einzelne "Feature" aufschlüsseln und dazu die einzelnen Statusmeldungen (Anzahl) und Schweregrad ermitteln.

DirSync Status

Neben dem "Dienststatus gibt es in Office 365 aber noch andere Datenquellen, die erfasste werden können, z.B. den DirSync Status.

 

Diese Informationen lassen sich mit der Azure AD-Powershell recht einfach ermitteln.

Zukunft MSGraph

Immer mehr Dienste und Informationen werden über Microsoft Graph bereitgestellt. Eine Status-API ist schon länger in Beta und wurde im Mai 2021 als Preview.

Message Center

Über das gleiche Skript könnte auch nebenbei das Message Center mit ausgelesen werden um so neue Meldungen z.B. per Mail an einen Admin weiter zu reichen

Weitere Links