Office 365 Status

Ihre Server "OnPremise" ü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.

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 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.

Zugriff auf Events per Office 365 Service Communications API V2 (neu)

Anfang 2016 hat Microsoft eine "neue" API als "PreView" veröffentlicht, schreibt aber zugleicht, dass der Wechsel schnell gehen kann.

...New features will only be added to the new version of the API, encouraging early adoption by legacy customers. When the General Announcement of Office 365 Service Communications API is made, the older version of the Service Communications API will begin a period of deprecation.
Quelle: https://msdn.microsoft.com/en-us/library/dn707385.aspx 

Für den Zugriff auf die neue API muss der Administrator im Azure AD erst die Application registrieren und mit Berechtigungen versehen,

Ein Beispielcode um über Office 365 Service Communications API V2 ebenfalls den Status zu ermitteln, ist noch nicht fertig.

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.

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