PRTG – Office 365 Status überwachen

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 … Office 365 mit PRTG überwachen

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. Man lege 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
ClientSecret – Das dazu passende „Kennwort“
TenantIdentifier – Die GUID des Office 365 Tenants

Das sollte dann etwa so aussehen:

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  Azure AD
Hier den Punkt „App-Registrierungen“ auswählen  App-Registrierungen
Neue Anwendung hinzufügen  App-Registrierungen
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.

 Erstellen
Nachdem die App-Registrierung fertig gestellt wurde, wird in der Übersicht die Anwendungs-ID angezeigt.

Diese verwenden wir im Skripts als: ! ClientID

 App-Registrierungen
Nun klickt man die neu angelegte App-Registrierung an und öffnet die Einstellungen. 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

Schlüssel
Nun fehlt noch die Berechtigung, auf die Office 365 Service Informationen zuzugreifen. Dazu muss eine neue Berechtigung hinzugefügt werden. API
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. Zugriff aktivieren
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

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

 App-Authorisierung

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:
  • 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

Viel Spaß beim Monitoren.

Für Fragen, Probleme oder Anregungen gerne einen Kommentar hinterlassen.

41 Gedanken zu „PRTG – Office 365 Status überwachen

  1. playordie Antworten

    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.

    • Marc Autor des BeitragsAntworten

      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.

  2. playordie Antworten

    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 🙂

    • Marc Autor des BeitragsAntworten

      Na ja, da war ich mal wieder mit mir selbst uneins, wie ich das benennen soll. Habe ich aber auch angepasst. Danke.

  3. Ollie Antworten

    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

  4. Ollie Antworten

    Issue found,
    Core needs to be restarted after copy of ovl file!

    Awesome script!

    • Marc Autor des BeitragsAntworten

      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.

    • Marc Autor des BeitragsAntworten

      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.

  5. Frank Antworten

    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“

  6. Philipp Antworten

    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.

    • Marc Autor des BeitragsAntworten

      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

  7. Frédéric Antworten

    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

  8. Frédéric Antworten

    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!

    • Marc Autor des BeitragsAntworten

      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.

  9. Alex Antworten

    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

    • Marc Autor des BeitragsAntworten

      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

    • Marc Autor des BeitragsAntworten

      Schau dir bitte mal den Kommentar von Daniel an, er hat noch eine Authentifizierung der App gemacht und es hat funktioniert.

  10. Max Antworten

    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

    • Marc Autor des BeitragsAntworten

      Please take a look at Daniel’s comment, he has resolved the problem. I’ll update the post accordingly.

  11. Daniel Antworten

    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…

    • Daniel Antworten

      Hupps, falsche PRTG Seite… Ich wollte eigentlich zum Tenant Script schreiben…

    • Marc Autor des BeitragsAntworten

      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.

  12. Martin Antworten

    This work perfectly, many thanks indeed – its exactly what I needed!!!

  13. Markus Antworten

    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&amp;{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 🙁

    • Marc Autor des BeitragsAntworten

      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.

      • Markus Antworten

        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)

        • Marc Autor des BeitragsAntworten

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

          • Markus

            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 🙂

  14. Mirko Antworten

    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)

    • Marc Autor des BeitragsAntworten

      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.

  15. Peter Voloshin Antworten

    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

    • Marc Autor des BeitragsAntworten

      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 …

  16. Michael Antworten

    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-šberprfung.
    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

    • Marc Autor des BeitragsAntworten

      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.

      • Michael Antworten

        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

        • Marc Autor des BeitragsAntworten

          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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.