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:
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.
Siehe dazu auch PRTG Office 365 Status
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.
- Office 365 Service Communications API
Overview
https://msdn.microsoft.com/en-us/library/office/dn776043.aspx - Office 365 Service
Communications API
https://www.microsoft.com/en-us/download/details.aspx?id=44012
Samples Download - Using PowerShell to obtain your Tenants
Office365 Health Dashboard
http://blogs.technet.com/b/cammurray/archive/2014/09/24/using-PowerShell-to-obtain-the-office365-dashboard.aspx - View your Office 365 service health dashboard
https://portal.microsoftonline.com/servicestatus/servicestatus.aspx (nicht mehr verfügbar) - http://status.office365.com/
- https://twitter.com/office365status
- Office 365 Service
Communications API Overview
https://msdn.microsoft.com/en-us/library/office/dn776043.aspx - Office 365 APIs platform
overview
https://msdn.microsoft.com/en-us/office/office365/howto/platform-development-overview - Using PowerShell to obtain
your Tenants Office365 Health
Dashboard
https://blogs.technet.microsoft.com/cammurray/2014/09/23/using-powershell-to-obtain-your-tenants-office365-health-dashboard/ - Get Office 365 Events
https://gallery.technet.microsoft.com/Get-Office-365-Events-ae991b72
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.
- Office 365 Service Communications API
-
Arbeiten mit der Dienstkommunikations-API in
Microsoft Graph
https://docs.microsoft.com/de-de/graph/api/resources/service-communications-api-overview?view=graph-rest-1.0&preserve-view=true - MC257688 | May 21 - The Office 365
Service Communications API will soon be
available via Microsoft Graph in Beta for
Public Preview.
This API provides access to Message Center and Service Health posts for your tenant. - Microsoft 365 Roadmap ID 68720:
Microsoft Graph: Office 365 Service
Communications API availability in Microsoft
Graph
https://www.microsoft.com/de-de/microsoft-365/roadmap?searchterms=68720&filters=&searchterms=68720
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
-
PRTG Office 365 Status
Auslesen des Office 365 Dienststatus per PRTG und Management API V1 - Office 365 Service Communications API
- Office 365: ADSync Monitoring
- PRTG
- PRTG:Custom Sensor
-
Azure AD Status
https://status.azure.com/de-de/status/history/ - View the status of your
services
https://support.office.com/en-nz/article/View-the-status-of-your-services-932ad3ad-533c-418a-b938-6e44e8bc33b0 - Service Health and
Continuity
https://technet.microsoft.com/en-us/library/office-365-service-health.aspx - New Office 365 admin tools
https://blogs.office.com/2014/07/29/new-office-365-admin-tools/ - Query Office 365 Service
Communication API
https://ingogegenwarth.wordpress.com/2016/11/18/query-office-365-service-communication-api/ - Statusseite von Google Cloud
Service
https://status.cloud.google.com/