PRTG – Office 365 Status überwachen [veraltet]
Dieses Skript wird nicht weiter aktualisiert
Update 27.02.2022: Da mich immer wieder Meldungen erreichen, dass das Skript in Zwischenzeit nicht mehr funktioniert: PRTG hat die Funktion dieses Skripts in Zwischenzeit in den eigenen Funktionsumfang aufgenommen, deshalb werde ich dieses hier nicht mehr aktualisieren. Bitte stellt eure Sensoren entsprechend um. Folgende Sensoren gibt es aktuell für Microsoft 365 Services:
- Microsoft 365 Service Status Sensor | PRTG Manual (paessler.com)
- Microsoft 365 Service Status Advanced Sensor | PRTG Manual (paessler.com)
Update 22.12.2019: In einigen Konstellationen ist für TLS 1.2 in Windows eine Anpassung der Registry notwendig. Wenn das bei euch der Fall ist, setzt die Keys auf dem Beitrag Enable TLS 1.2 in Windows (Zumindest Keys 1 & 3).
Update 14.12.2019: Und jetzt habe ich auch den Link zum Github Repository (https://github.com/debold/PRTG-O365Monitoring), wo das Skript heruntergeladen werden kann, hinzugefügt.
Update 13.12.2019: Habe das Skript aktualisiert, so dass TLS 1.2 forciert wird. Bitte mal testen!
Update 11.12.2019: Heute hatte ich mehrere Meldungen über Fehler beim Abruf der Daten von Office365. Ich habe die Version auf Github aktualisiert, so dass genauere Fehlermeldungen ausgegeben werden – bitte die neue Version verwenden. Damit sollte man der Ursache einfacher auf die Spur kommen. Und: Ich überarbeite die Seite die nächsten Tage mal, die Oberfläche von AzureAD hat sich so geändert, dass mal wieder kaum ein Screenshot noch stimmt …
Update 01.10.2018: Habe ein Beispiel für die Parameter des Skripts hinzugefügt, der Abschnitt war ungenau.
Update 04.02.2018: So, der Artikel ist nun mit den Screenshots des neuen Admin-Portals aktualisiert und die Freischaltung der App wurde mit aufgenommen. Falls ihr noch was findet, was nicht funktioniert, hinterlasst bitte einen Kommentar.
Update 28.01.2018: Der Artikel ist nicht mehr ganz aktuell und muss auf das neue Admin-Portal angepasst werden. Die Schritte gehen soweit noch, allerdings scheint eine Authentifizierung der App erforderlich zu sein. In den Kommentaren hat Daniel (Danke dafür) beschrieben, wie das geht. Ich werde den Artikel in den nächsten Wochen aktualisieren … bitte noch etwas Geduld …
Mit PRTG von Paessler lassen sich schnell und einfach kleine bis mittlere Netzwerke überwachen (kostenlose Testversion bzw. 100er Freeware Version gibt es hier). Vom Ping über WMI, SNMP bis hin zu eigenen Skripten kann über viele Wege das Monitoring von Geräten und Diensten geschehen. Nun kam schon häufiger die Frage auf, wie man denn Office 365 überwachen kann. Da es sich hier um eine Sammlung verschiedener Dienste handelt, die auf tausenden von Servern gehostet werden – zu denen wir natürlich nicht den passenden Zugriff haben – ist das Ganze nicht trivial. Zum Glück stellt Microsoft eine API bereit, mit deren Hilfe wir wunderbar den Status der abonnierten Dienste eines Tenants auslesen können. Nachfolgend wird beschrieben, wie eben diese Überwachung in PRTG eingerichtet werden kann.
Die Einrichtung in PRTG ist denkbar einfach. Man nehme die nachfolgende ZIP Datei (PRTG_O365Monitoring), in der ein Power Shell Skript und eine .OVL Datei enthalten sind. Ladet euch die aktuelle Version des Skripts von Github herunter und legt die Dateien an folgenden Orten ab:
| Datei | Ort | Beschreibung |
|---|---|---|
| Get-Office365Status.ps1 | <PRTG Installationspfad>\Custom Sensors\EXEXML | Das ist das Power Shell Skript, das die Anfrage an Office 365 macht und das Ergebnis als XML an PRTG zurück liefert. |
| custom.office365.state.ovl | <PRTG Installationspfad>\lookups\custom | Das ist eine Lookup Definition, die die numerischen Rückgabewerte des Skripts in verständliche Status umwandelt und in PRTG anzeigt.
Wichtig: Die Lookup Definitionen werden nur durch einen Neustart des Core Service, oder über den Menüpunkt Setup/System Administration/Administrative Tools/Load Lookups eingelesen und angewandt. |
Nun erstellt man einen neuen Sensor vom Typ “EXE/Skript Advanced” auf einem beliebigen, passenden Gerät (es werden keine Geräteeigenschaften verwendet). Folgende Einstellungen sind im Sensor noch zu machen:
| Einstellung | Beschreibung |
|---|---|
| Sensor Name | Der Anzeigename des Sensort, etwa “Office 365 Tenant Health” |
| EXE/Script | Hier muss das Skript “Get-Office365Status.ps1” ausgewählt werden |
| Parameters | Hier müssen 3 tenantspezifische Infos rein. Wie man an diese Infos kommt, ist weiter unten erklärt.
ClientID – ID der Azure “Anwendung” mit deren Hilfe wir die Informationen auslesen Das sollte dann etwa so aussehen: -ClientID Meine_Client_ID -ClientSecret Mein_Kennwort -TenantIdentifier Meine_Tenant_ID |
Der weitaus aufwändigere Teil (bis auf das Erstellen des Skripts – aber das habe ja ich übernommen) ist es, Office 365 bzw. Azure dazu zu überreden, uns doch seine Infos preis zugeben. Die folgende Anleitung zeigt alle notwendigen Schritte:
| Login auf https://portal.office.com und Aufruf von Azure AD |  |
| Hier den Punkt “App-Registrierungen” auswählen |  |
| Neue Anwendung hinzufügen |  |
| Nun die notwendigen Informationen für die Erstellung der App-Registrierung eingeben. Der Name dient nur der Identifikation des Service im Portal, darf also frei gewählt werden.
Als Anwendungstyp muss Web-App/API ausgewählt werden. Die Anmelde-URL muss auch gefüllt werden, muss allerdings nicht auf eine reale Adresse verweisen. Ich benutze dafür in der Regel https://office365health.mytenant.onmicrosoft.com, wobei mytenant durch den eigenen Tenant Namen ersetzt werden muss. |  |
| Nachdem die App-Registrierung fertig gestellt wurde, wird in der Übersicht die Anwendungs-ID angezeigt.
Diese verwenden wir im Skripts als: ! ClientID |  |
| Nun klickt man die neu angelegte App-Registrierung an und öffnet die Einstellungen. |  |
| Unter dem Punkt Schlüssel muss nun ein neuer Sicherheitsschlüssel erstellt werden, der für die Authentifizierung gegenüber Azure genutzt wird. Nach der Eingabe einer Beschreibung und des Ablaufzeitraums kann der Eintrag gespeichert werden.
Achtung: Nach dem Speichern wird der Schlüsselwert ein einziges Mal angezeigt. Verlässt man diese Seite, kann der Schlüssel nicht wieder angezeigt werden und es muss ein neuer erstellt werden. Der Schlüssel wird hier verwendet als: ! ClientSecret |  |
| Nun fehlt noch die Berechtigung, auf die Office 365 Service Informationen zuzugreifen. Dazu muss eine neue Berechtigung hinzugefügt werden. |  |
| Als API wird Office 365 Management APIs gewählt, die erforderliche Berechtigung, die wir benötigen, nennt sich Read service health information for your organization. |  |
| Nun benötigen wir noch die ID des Azure AD. Diese finden sich in den Eigenschaften des Azure AD. Der richtige Eintrag ist dort unter Verzeichnis-ID zu finden.
Im Skript wird die ID verwendet als: ! TenantIdentifier |  |
| Nun fehlt noch ein wichtiger Punkt: Die neue App muss einmalig authorisiert werden. Dazu muss eine spezielle URL aufgerufen und die Abfrage dort bestätigt werden:
https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&client_id=ClientID Dabei muss ClientID durch die oben erstellte ID ersetzt werden. Achtung: Nach der Abfrage wird man ggf. auf seine Redirect-URL weitergeleitet. Diese mussten wir oben angeben, allerdings existiert diese Seite ja gar nicht. Damit kann eine 404-Fehlerseite erscheinen – das ist in Ordnung! Die Authorisierung funktioniert trotzdem. |  |
Ein paar wichtige Infos zum Betrieb des Skripts:
- Auf der PRTG Probe muss min. Power Shell 3.0 oder höher installiert sein. Mit Windows Server 2008 R2 wurde Version 2 ausgeliefert, kann aber durch Installation des Windows Management Framework (aktuell Version 5) nachgerüstet werden
- Die Power Shell Execution Policy auf der Probe sollte auf “RemoteSigned” stehen. Dazu den folgenden Befehl auf der Power Shell 32 Bit ausführen:
Set-ExecutionPolicy RemoteSigned -Force
- Kommt immer noch eine Meldung, dass das Skript nicht signiert wurde, dann auch wirklich die 32 Bit Version der Power Shell ausführen. Ja, die heißt auch so 🙂
- Nach 2 Jahren ist die Gültigkeit der Anwendungsdaten hinfällig, dann muss ein neues ClientSecret erstellt werden
Und falls ihr den Link zum Download nicht gefunden habt: Die aktuelle Version findet ihr immer auf Github unter https://github.com/debold/PRTG-O365Monitoring.
Viel Spaß beim Monitoren.
Für Fragen, Probleme oder Anregungen gerne einen Kommentar hinterlassen.
Hallo! Erst einmal vielen Dank für das Skript, echt genial! Ich habe noch eine kleine Verbesserung die in meiner eigenen Infrastruktur aufgetreten ist. PRTG läuft bei uns mit einem eigenen Service-User. Hat man sich noch nie mit diesem User auf dem PRTG-Server angemeldet und den Internet Explorer gestartet, so meckert das Skript mit der folgenden Meldung:
Der Antwortinhalt kann nicht analysiert werden, da das Internet Explorer-Modul nicht verfügbar ist,
oder die Konfiguration beim ersten Start von Internet Explorer ist nicht abgeschlossen. Geben Sie den
UseBasicParsing-Parameter an, und wiederholen Sie den Vorgang.
2 Lösungsmöglichkeiten:
–> 1. Mit dem User anmelden auf dem PRTG-Server und der Internet Explorer 1x starten (eher nicht empfohlen)
–> 2. Im PS-Skript bei Zeile 109 (Invoke-Webrequest) den Parameter -UseBasicParsing anfügen. Fertig.
Hallo PlayOrDie. Danke für das detaillierte Feedback. Ich habe die vorgeschlagene Änderung in das Skript eingebaut, konnte es jetzt noch nicht testen, werde ich aber demnächst noch nachholen.
Hallo sorry,
ich nochmal weil ich vergessen habe etwas zu erwähnen. Ich der “lookup” Datei hat sich auch noch einen Fehler eingeschlichen. Die “ID” ist von “bechtle.office365.state” in “custom.office365.state” umzubenennen. Danach die Lookups in den Administrativen Werkzeugen neuladen und dann klappts auch 🙂
Na ja, da war ich mal wieder mit mir selbst uneins, wie ich das benennen soll. Habe ich aber auch angepasst. Danke.
Hello Marc,
I tried your script, but my output is:
What is my mistake?
Ollie
Exchange Online
11
custom.office365.state
Skype for Business
5
custom.office365.state
Mobile Device Management for Office 365
0
custom.office365.state
Identity Service
0
custom.office365.state
Office 365 Portal
0
custom.office365.state
Office Subscription
0
custom.office365.state
Planner
0
custom.office365.state
Power BI
0
custom.office365.state
Rights Management Service
0
custom.office365.state
SharePoint Online
0
custom.office365.state
Sway
0
custom.office365.state
Yammer Enterprise
9
custom.office365.state
Issue found,
Core needs to be restarted after copy of ovl file!
Awesome script!
Thanks Ollie! Good to see, that it works for you. After adding a lookup file, PRTG needs to reload the lookup repository. That can either be done by restarting the core service (as you did), or by hitting “Load Lookups” within PRTG, found under Setup/System Administration/Administrative Tools. I’ll add that to the description, so thanks for the hint there.
Hi Marc,
In my search on azure/o365 monitoring i also found this page:
https://www.accyotta.com/blogs/Knowledge-Nuggets/prtg-office-365-get-hitched-by-acc
But unfortunately, this guy isn’t as helpfull as you, and does not share any info how he did this.
Could you have a look? would be nice if you could implement this as well in your script!
Well now you got me … 😉
I just took a look and thought by myself: “That doesn’t look too complicated…”, and now you got me sitting here and scripting it.
Great idea, rather easy to do (already got it up and running), just give me a couple of days for finetuning and testing. I’ll post a new blog entry, as it is finished. Stay tuned, we’ll have it by the weekend, I hope.
Would be great again 🙂
I knew it would trigger something!
Hi Marc,
thanks for sharing this script. In addition to your great manual I like to add that I had to execute the following Powershell commands on Windows Server 2012R2 to be able to overcome authorization errors:
Unblock-File -Path “C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-Office365Status.ps1”
Unblock-File -Path “C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-PRTGO365Licenses.ps1”
Hallo erstmal und Vielen Dank für das Script.
Habe das Ganze wie beschrieben eingerichtet und habe immer den Fehler “Error retrieving data” erhalten.
Erst als ich der neu erstellen Applikation expliziten Zugriff auf die Berechtigungen gegeben habe, hat die Anfrage funktioniert.
Der Zugriff für die neue Applikation ist in diesem MS Artikel beschrieben:
https://msdn.microsoft.com/office-365/get-started-with-office-365-management-apis
“Office 365 tenant admin consent
Now that your application is configured with the permissions it needs to use the Office 365 Management APIs, a tenant admin must explicitly grant your application these permissions in order to access their tenant’s data by using the APIs. To grant consent, the tenant admin must log in to Azure AD, using the following specially constructed URL, where they can review your application’s requested permissions. This step is not required when using the APIs to access data from your own tenant.
https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&client_id={your_client_id}&redirect_uri={your_redirect_url }”
War dieses Vorgehen bei Erstellung des Scripts noch nicht nötig?
Können Sie Ihre Anleitung entsprechend anpassen für zukünftige Einrichtungen?
Falls dies bereits irgendwo enthalten sein sollte und ich es überlesen habe, bitte ich um Entschuldigung.
Hallo Philipp,
das explizite Setzen der Berechtigungen habe ich eigentlich in der Anleitung drin … steht in der Tabelle unter “Nun fehlt noch die Berechtigung, auf die Office 365 Service Informationen zuzugreifen…”. Hast du diese Schritte ausgeführt, oder hat sich diese Option in Zwischenzeit geändert? Azure ändert sich doch relativ oft, deshalb kann es auch gut sein, dass auch hier etwas passiert ist. Vielleicht kannst du das noch einmal prüfen und Feedback geben?
Gruß,
Marc
Hello, Thanks for this nice post! I’m trying to implement in our infrastructure but the sensor is not working. I get the followinf error in PRTG : XML: The returned XML does not match the expected schema. (code: PE233) — JSON: The returned JSON does not match the expected structure (Invalid JSON.). (code: PE231)
In the sensor settings, when you have to specify your parameters, I presume the the format is : -ClientID=XXXX -ClientSecret=XXX -TenantIdentifier=XXX
Another question, I can’t see in the sensor settings where we specify the lookup file to use…
Thanks for your help!
Fred
The command line mention by Frank solved my issue: Unblock-File -Path „C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-Office365Status.ps1“
Thanks a lot for this!
Perfect, so your lookup should work now, too. You needn’t specify the file, as it is done by the sensor itself.
I had a sentence about the blocking of downloaded script files in another post, just copied it over to help future readers 🙂
Thanks for your feedback.
Hallo,
ich bekomme leider nur ein “Error authenticating”.
PRTG ist ziemlich neu für mich und ich denke es liegt an der Eingabe der Parameter.
-ClientID:”anfangleerzeichenrest” -ClientSecret:”XXX” -TenantIdentifier:”XXX”
Bei der ClientID ist ein Leerzeichen zwischen den “Nummern”. Evtl. hier der Fehler?
Könntet Ihr mir bitte helfen?
Danke!
mfg
Alex
Hallo Alex,
eigentlich sollten in der ClientId (meiner Meinung nach) keine Leerzeichen enthalten sein. In den PRTG Parametern kannst du das aber mit einfachen Anführungszeichen durchaus machen, wie in folgendem Beispiel zu sehen:
-ClientId '000a0000-aa00-0000-a0a0-aa00a0aa0000' -ClientSecret 'xxxxxx11111xxx11xxxxx111xx11=' -TenantIdentifier '000b0000-bb00-0000-b0b0-bb00b0bb0000'So setze ich die Parameter in meinen Installationen und da funktioniert das einwandfrei. Und da hatte ich bisher auch noch keine Leerzeichen in den Parametern, technisch funktionieren würde es so allerdings.
Gruß,
Marc
Ich bekomme den selben Fehler
Bitte auch mal den Kommentar von Daniel prüfen.
Schau dir bitte mal den Kommentar von Daniel an, er hat noch eine Authentifizierung der App gemacht und es hat funktioniert.
Hi I’m trying the script but, after inserting the credentials, I’ll recive the following error:
1
Error authenticating
I’m sure the keys are correct with the correct format, maybe some redirect URL for auth has been changed since the build?
Thanks
Please take a look at Daniel’s comment, he has resolved the problem. I’ll update the post accordingly.
Hallo Marc,
Läuft dein Script noch mit der aktuellen Version?
Ich musste, da sich das Dashboard geändert hat, zuerst alles ein bisschen verstehen…
leider erhalte ich aber Error retrieving data im prtg…
Hupps, falsche PRTG Seite… Ich wollte eigentlich zum Tenant Script schreiben…
Hallo Marc,
Man muss die Applikation noch als Tenant Admin bestätigen mit folgender URL
https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&client_id={your_client_id}&redirect_uri={your_redirect_url }
Dabei wird die oben erstellte URL benötigt.
Danke für die Info, das könnte tatsächlich auch der Grund für die Fehler bei den anderen Kommentaren sein. Ich werde mir mal etwas Zeit nehmen (müssen), um die Anleitung für das neue Admin-Portal zu überarbeiten.
This work perfectly, many thanks indeed – its exactly what I needed!!!
Hallo Marc,
Danke für das nette script. Leider habe ich irgendwie probleme mit der Aktivierung des Link im Tenant.
https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&{your_client_id}&redirect_uri={your_redirect_url}
wenn ich hier die clientid und redirect_url angebe bekomme ich das Abfrage Fenster wie in deiner Anleitung. Ich klicke auf Annehmen und es kommt eine 404 Seite mit dem Hinweis das die url {your_redirect_url} nicht erreichbar / verfügbar ist.
ich verzweifle gerade ein wenig 🙁
Hallo Markus,
kein Problem. Nach der Genehmigung möchte dich Microsoft auf deine Redirect-URL umleiten – die gibt es allerdings nicht (brauchen wir nicht, muss aber bei der Einrichtung angegeben werden). Deshalb ist die 404-Meldung völlig in Ordnung. Die Freischaltung funktioniert trotzdem. Ich passe den Artikel entsprechend an.
Hi Marc,
ich dachte das dann mein PE233 Fehler weg ist. Leider bekomme ich den Sensor nicht auf Grün gestellt.
Derzeit bekomme ich den gleichen Fehler wie oben Frederic:
error in PRTG : XML: The returned XML does not match the expected schema. (code: PE233) — JSON: The returned JSON does not match the expected structure (Invalid JSON.). (code: PE231)
Aktiviere bitte im Sensor mal die Option “Write EXE result to disk”, schau auf dem PRTG Server nach der Datei, in der die Ausgabe des Sensors gespeichert wird und schau dir mal den Inhalt an. Vielleicht gibt dir das eine Idee, was das Problem sein könnte. Falls du nicht weiter kommst, schick mir die Datei bitte mal per Mail (Adresse steht im Impressum).
das war ein gute Tip! Ich hab mal wieder den Wald vor lauter Bäume nicht gesehen und einen Parameter Fehler gemacht. Statt -ClientSecret hatte ich -SecretKey verwendet. Wurde direkt in der Log Datei angezeigt.
Nun läuft es. Danke 🙂
Tolle Anleitung und tolles Script.
leider bekomme ich den Fehler:
XML: Das zurückgelieferte XML entspricht nicht dem erwarteten Schema. (Code: PE233) — JSON: Das zurückgelieferte JSON entspricht nicht der erwarteten Struktur (Invalid JSON.). (Code: PE231)
Hallo Mirko,
die Fehlermeldung weist darauf hin, dass wohl ein nicht abgefangener Fehler im Skript aufgetreten ist. Bitte aktiviere in PRTG mal das Speichern der Sensor-Ausgabe und schau dir diese auf dem PRTG Server an. Dort sollte dann eine etwas aussagekräftigere Fehlermeldung drin sein – damit kommst du dem Fehler sicher besser auf die Spur.
Hallo Marc,
leider funktioniert der Sensor nicht.
Es gibt folgende Fehlermeldung :
XML: Das zurückgelieferte XML entspricht nicht dem erwarteten Schema. (Code: PE233) — JSON: Das zurückgelieferte JSON entspricht nicht der erwarteten Struktur (No mapping for the Unicode character exists in the target multi-byte code page). (Code: PE231)
kannst du mir bitte helfen?
Mit fG
Peter
Hallo Peter,
bitte auch erst mal im Sensor einschalten, dass das Sensor-Resultat auf die Platte geschrieben wird und dann den Inhalt der Datei anschauen. Da steht dann wahrscheinlich auch eine genauere Fehlermeldung drin, die von PRTG ist noch nicht sehr aussagekräftig. Kannst du dann auch gerne hier posten und wir schauen gemeinsam drüber …
Hallo Marc
habe das gleiche Problem:
XML: Das zurückgelieferte XML entspricht nicht dem erwarteten Schema. (Code: PE233) — JSON: Das zurückgelieferte JSON entspricht nicht der erwarteten Struktur (No mapping for the Unicode character exists in the target multi-byte code page). (Code: PE231)
Ich habe da ein bisschen gesucht, es hat etwas mit dem Skript und der digitalen Signatur zutun. Wenn ich das Skript in der Konsole starte ohne es vorher digital zu signieren erhalte ich folgendes:
PS C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML> .\Get-Office365Status.ps1
.\Get-Office365Status.ps1 : Die Datei “C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-Office365Status.ps1” kann nicht geladen werden. Die Datei
“C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\Get-Office365Status.ps1” ist nicht digital signiert. Sie könnend dieses Skript im aktuellen System
nicht ausführen. Weitere Informationen zum Ausführen von Skripts und Festlegen der Ausführungsrichtlinie erhalten Sie in “about_Execution_Policies” unter
“http://go.microsoft.com/fwlink/?LinkID=135170”..
In Zeile:1 Zeichen:1
+ .\Get-Office365Status.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : Sicherheitsfehler: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess
Nach der Signierung läuft das Skript in der Konsole durch nach dem ich die entsprechenden Zugangsdaten eingebe.
Dynamics 365 for Operations
0
custom.office365.state
Dynamics 365
6
custom.office365.state
Exchange Online
7
custom.office365.state
Microsoft Intune
9
custom.office365.state
Skype for Business
7
custom.office365.state
Microsoft Teams
0
custom.office365.state
Mobile Device Management for Office 365
0
custom.office365.state
OneDrive for Business
0
custom.office365.state
Identity Service
0
custom.office365.state
Office 365 Portal
0
custom.office365.state
Office Subscription
0
custom.office365.state
Planner
0
custom.office365.state
Power BI
7
custom.office365.state
Azure Information Protection
0
custom.office365.state
SharePoint Online
7
custom.office365.state
Social Engagement
0
custom.office365.state
Microsoft StaffHub
0
custom.office365.state
Sway
0
custom.office365.state
Yammer Enterprise
0
custom.office365.state
Was aber immer noch nicht funktioniert ist der Aufruf des Skripts über PRTG. Dort gibt es immer noch die Meldung mit dem XML Fehler. In der LOG Datei steht folgendes:
& : Fehler bei der AuthorizationManager-šberprfung.
In Zeile:1 Zeichen:138
+ … l.Utility};&’C:\Program Files (x86)\PRTG Network Monitor\custom senso …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : Sicherheitsfehler: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess
Das kann ich aber nicht ganz nachvollziehen. Da die gleichen Daten in der Konsole funktionieren.
Wie sieht denn der Aufruf im Sensor aus? Einfache alle drei Keys hintereinander weg schreiben?
Gruß
Michael
Hallo Michael,
immer wenn eine Fehlermeldung mit der “Execution Policy” kommt, dann hängt es … an der Execution Policy 😉
Wenn du ein Script aus dem Internet herunterlädst, dann speichert sich das Windows in der Datei. Wenn du sie später aufrufst, überprüft er dieses Kennzeichen und behandelt die Datei dann besonders. Das kannst du beheben, indem du
* Über Rechtsklick auf die ps1-Datei / Eigenschaften / die Datei “zulässt”
* Die ps1-Datei per PowerShell Befehl “Unblock-File” entsperrst
* Die Execution Policy auf Remote Signed (dann aber auch “Unblock”) oder Unrestriced stellst
Da PRTG alle PowerShell Befehle in der 32-Bit Variante startet, prüfe bitte mal die Fehlermeldung, wenn du explizit auch die 32-Bit Version der Powershell startest (= Windows PowerShell (x86)). Dort musst du die Execution Policy nämlich separat von der 64-Bit Variante setzen. Wenn das Skript dort geht, sollte es auch in PRTG gehen.
Hallo Mark
so, ich hab das jetzt noch einmal getestet. In der PowerShell x86 funktioniert das Skript ohne Probleme. Wenn ich jetzt das ganze unter PRTG ausführe erhalte ich jetzt einen authenticating Error. Also muss da der Fehler sein.
Wie muss der Syntax im PRTG bei Parameter aus sehen? Aktuell ich die drei Abschnitte jeweils so “Client ID Azure” “Schlüssel” “Azure ID” getrennt.
Gruß
Michael
Jetzt habe ich das Problem verstanden 😉
Schau mal, ich habe oben in den Text ein Beispiel für die Parameter eingetragen, schau mal, ob dir das weiterhilft.
Hi Marc,
dein Skript funktioniert wunderbar – vielen Dank dafür.
Bei den Ergebnissen verlassen wir uns jedoch auf die Checks von Microsoft.
Wir würden gerne die Ladezeit verschiedener Seiten z.B. Sharepoint, Onedrive etc. testen, allerdings scheitere ich hier an der Authentifizierung. Beim Aufruf der Seite via Powershell werde ich an login.microsoftonline.com weitergeleitet, eine HTTP Authentifizierung klappt dabei nicht.
Ich habe versucht das auch über die für diesen Check registrierte App und damit verbundenen Tokens zu realisieren, aber ich bekomme über den Webrequest keine Seite ausgeliefert.
Hast Du zufällig eine Idee, wie das machbar ist, damit wir die Responsezeiten im PRTG tracken können?
Die Zeitmessung ist nicht das Problem, ich muss nur irgendwie den Download der Webseite via Powershell o.ä. hinbekommen.
VG,
Max
Hi Max,
mit dem Thema habe ich mich auch schon das ein oder andere Mal auseinandergesetzt, aber bisher noch keine “ordentliche” Lösung gefunden. Problem ist, dass die “Basic Authentication” von den meisten Diensten nicht mehr wirklich unterstützt wird und du somit die “Modern Authentication” anhand von Formularen usw. nachbauen müsstest. Mit dem HTTP Transaction Sensor und den Google Chrome Dev Tool (F12 drücken) komme ich da eigentlich schon relativ weit, aber das ist nicht ganz trivial und ändert sich auch regelmäßig. Da lohnt sich meiner Meinung nach der Aufwand nicht, das bis ins Letzte durchzuarbeiten, da die Request Parameter und die Antworten mannigfaltig sind. Über ProwerShell hast du da wahrscheinlich ähnliche Herausforderungen.
Also kurz und knapp: Da habe ich im Moment leider keine brauchbare Antwort drauf, sorry. Vorerst würde ich mich auf das Health Dashboard von MS verlassen, machen viele andere Tools ja auch so.
Gruß,
Marc
Hi Marc,
besten Dank für das Script und die super Anleitung. Das hat auch bestens funktioniert. Woran ich erst mal scheiterte war das ich die Permissions auf der App noch vergessen habe zu granten. Also die Persmissions vergeben ist das eine und danach muss man ja noch den Button Grant permission klicken.
Das nur als feedback falls jemand anders da auch ansteht 🙂
Gruss
Many
Danke für die Info. Leider ändert sich die Oberfläche bei Office 365 regelmäßig. Muss die Anleitung mal wieder aktualisieren 🙂
[…] the proper functioning of office365 I had to find a solution for that. So I found this post : https://www.team-debold.de/2016/07/22/prtg-office-365-status-ueberwachen/ from Marc’s IT BLOG I followed the procedure with google translate and now my prtg monitor […]
Hallo Marc! Wir haben nach Anleitung PRTG und die App Registration konfiguriert. Status ist “OK”. Allerdings sehen wir keine Grafiken (nur leere Boxen) und als Value wird “0 (configured lookup custom…)” ausgegeben.
Hallo Kai,
das sieht fast so aus, als hättest du die OVL-Datei nicht an den richtigen Platz gelegt, oder die Lookups nicht neu geladen. Kannst du das mal prüfen?
Hallo Marc.
Danke für die Anleitung.
Die Einrichtung hat problemlos funktioniert und der Sensor lief nun schon länger einwandfrei.
Doch seit heute früh liefert der Sensor, resp. das Script die Fehlermeldung “Error retrieving data” zurück. Ich vermute eine allgemeine Störung bei Office 365, aber allenfalls haben sie auch grundsätzlich was an der Authentifizierung geändert.
Falls jemand eine Lösung dafür hat, immer her damit.
Danke für die Info, muss ich mir anschauen. Da es jetzt schon einige Reaktionen der Art gibt, scheint sich tatsächlich irgendwo etwas geändert zu haben … sobald ich genaueres weiß, gibt’s hier ein Update.
Ich habe mir gerade einmal einen Sensor eingerichtet und er funktioniert einwandfrei. Evtl. war es tatsächlich eine vorübergehende Diensteinschränkung, oder aber dein ClientSecret ist abgelaufen? Der Fehler erscheint, wenn der Aufruf der Webrequest fehlschlägt. Ich habe die Version auf Github aktualisiert, dass die genaue Fehlerbeschreibung mit ausgegeben wird. Bitte mal mit der Version testen.
Hallo Marc!
Seit heute funktioniert die Abfrage über das API plötzlich nicht mehr.
Ich erhalte nur noch “error retrieving data” retour.
Die App-Berechtigung in Azure ist nach wie vor aktiv und genehmigt.
Hat sich hier was geändert?
Danke für die Info, muss ich mir anschauen. Da es jetzt schon einige Reaktionen der Art gibt, scheint sich tatsächlich irgendwo etwas geändert zu haben … sobald ich genaueres weiß, gibt’s hier ein Update.
Ich habe mir gerade einmal einen Sensor eingerichtet und er funktioniert einwandfrei. Evtl. war es tatsächlich eine vorübergehende Diensteinschränkung, oder aber dein ClientSecret ist abgelaufen? Der Fehler erscheint, wenn der Aufruf der Webrequest fehlschlägt. Ich habe die Version auf Github aktualisiert, dass die genaue Fehlerbeschreibung mit ausgegeben wird. Bitte mal mit der Version testen.
Hello!
Big fan of your script!
However after the last PRTG update of the server it broke for us with the simplle error “Error Retrieving Data” in PRTG.
Is this something you also have seen or have any pointer on what to look for?
Thanks for the info. Since you’re not the only one reporting this issue, I need to take a deeper look. As soon as I have further information, I’ll update here.
I checked the sensor by creating a new one and it worked perfectly. Either it really was an outage, or your client secret may have expired? I added some lines to the code on github to show a more detailed error message. Maybe that can help narrow down the problem.
Hi Marc – your script has been working perfectly for ages until yesterday!!
I’ve renewed the client secret and updated to the latest version of your script but still getting this error. You’ll see from my comment below on Mike’s post, I’m not sure where in the script I can add the line to enforce TLS1.2 – Any other ideas? i’d love to get this working again if I can! Thanks in advance!
Hallo Marc,
mit der neuen Version deines Scripts erhielt ich die Fehlermeldung “the underlying connection was closed unexpected error on send”. Dies passierte auf einem Server mit älterer PS Version (4.0), auf meinem Rechner mit PS 5.1 funktionierte alles wunderbar.
Konnte das Problem dann durch einfügen folgender Zeile lösen:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Dadurch wird die Verwendung von TLS 1.2 festgelegt für den invoke-webrequest Befehl.
Offenbar lassen sich die MS URLs nur noch mit TLS 1.2 korrekt abrufen.
Vielen Dank für das Debuggen und die Korrektur. Ich habe das in mein Skript eingebaut, neue Version ist auf GitHub verfügbar. Bitte mal testen, ob es so funktioniert 🙂
Hallo Mike,
vielen Dank! Jetzt funktioniert es bei mir auch wieder…
Hi Mike
Can you tell me where we can insert this line into the script please? I tried but Powershell doesn’t like the syntax so I’m guessing I’m doing something wrong.
Thanks
Hello Marc,
Have the same problem that the other users here. The message appear is the next one:
Error retrieving data (The underlying connection was closed: An unexpected error occurred on a send.)
Have you any solution for this?.
Thank and best regards,
Ángel.
I’ve updated the script to force TLS 1.2. Get it from GitHub and try again, please. Feedback welcome 🙂
I uploaded an updated version of the script to GitHub. Please check, if that solves your problem.
Ein Link zum Github Skript wäre noch hilfreich
Na da hast du wohl Recht … ich dachte, den hätte ich schon drin. Ist jetzt im Artikel enthalten, aber auch hier nochmal: https://github.com/debold/PRTG-O365Monitoring.
Danke für die Info!
Hallo
Gibt es mit der Version 1.4 bereits eine Lösung für das Problem mit der Fehlermeldung “The underlying connection was closed: An unexpected error occurred on a send)”? Muss ich wirklich TLS 1.0 aktivieren?
Gruss
Hallo,
nein, du musst TLS 1.0 definitiv NICHT aktivieren. Microsoft akzeptiert ausschließlich TLS 1.2, also wird TLS 1.0 aktivieren nichts bringen. So wie es aussieht, sind nur ältere Betriebssysteme betroffen (ab Windows Server 2012 R2 sollte TLS 1.2 im Standard aktiviert sein), oder aber solche, die über einen Proxy, der kein TLS 1.2 unterstützt angebunden sind. Es gibt einige Schalter, die man betätigen kann, dass Windows TLS 1.2 spricht, ich schreibe dazu gleich einen separaten Post. Aber Steve hat wohl einen RegKey, der bei ihm geholfen hat, vielleicht kannst du den mal testen.
Hi Marc
Many thanks for uploading the new version however, I’m still getting the same issue – Error Retrieving Data (The underlying connection was closed: An unexpected error occurred on a send).
Any ideas?
Thanks
I had the same issue on the server that hosts my PRTG install, but running the script on my Win 10 laptop worked fine.
I added the two reg fixes from this Microsoft Link and rebooted, after that it worked fine.
https://docs.microsoft.com/en-us/security/solving-tls1-problem
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32
Thanks
Steve
Steve – many thanks, this has sorted it out and i’m getting data again!!
Thanks for sharing this Marc, super useful!
I’ve got this attached to a sensor but was wondering if you know of any way to filter out channels with ‘Operational’ or ‘0’ values on a map?
Cheers!
Hi Declan,
I don’t know of a way to do something like that on a map. Only way I could imagine was to use a representation like a table for warning and error states only. That would filter out any state that represents a GOOD state. But I don’t know, if that would fit your needs.
Hallo,
ich habe versucht dein Script zum laufen zu bekommen. Habe das Problem beim Registrieren der APP:
https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&client_id=f97dab2c-51ca-****-****-63fef38d72f7
Es kommt bei mir sofort nen Redirect zur Ziel-URL ohne die Abfrage ob ich was genehmigen möchte, was mache ich falsch?
Hallo Fabian,
die Vorgehensweise hat sich mittlerweile geändert, die Registrierung muss jetzt innerhalb der Berechtigungszuweisung gemacht werden. Dort, wo du die Berechtigung für das Skript in Office 365 hinzufügst, gibt es dann einen Knopf “Grant Admin Consent …”. Das macht das gleiche, was man früher über diese URL machen musste. Ich schreibe gerade eine aktualisierte Version der Anleitung, dort steht es dann auch richtig drin.
Moin Marc,
danke für den Tipp – das hat funktioniert!
Netter Kontakt – gerne wieder 😉
Hello Marc,
do you think the script is broken due to the change from Microsoft from manage.office.com to the general graph-API?
https://practical365.com/moving-office365-service-communications-api-graph/
Would be great to hear from you.
kind regards
Sebastian
PRTG has integrated sensors for Microsoft 365 monitoring, so I no longer maintain this script. Please make use of the built-in sensors. Thank you.
Hi,
The script worked fine until recently, we got the error : Error retrieving data (The remote server returned an error: (403) Forbidden.)
PRTG has integrated sensors for Microsoft 365 monitoring, so I no longer maintain this script. Please make use of the built-in sensors. Thank you.
Error authenticating (Der Remoteserver hat einen Fehler zur�ckgegeben: (401) Nicht autorisiert.)
Hallo, erst ein Mal danke für das Script, ich komme aber leider nicht mehr weiter :/
PRTG kann in Zwischenzeit nativ Microsoft 365 überwachen, deshalb aktualisiere ich das Skript nicht mehr. Bitte auf diese Sensoren umstellen. Danke.