Hallo Kim,

Hier klappt die Abfrage nicht, Fehlermeldung: Der Zugriff wurde verweigert. Um dieses Problem zu lösen, überprüfen Sie Ihre Zugangsdaten für Windows-Systeme in den Einstellungen des Geräts. (Code: PE095)

das wird daran liegen, dass PRTG versucht mit den hinterlegen Zugangsdaten sich an dem Server, welcher ja nicht Mitglied der Domäne ist, anzumelden. Was nicht funktioniert. D.h. du müsstet

1. Das Skript dahingehen überarbeiten, dass du Benutzername + Passwort übergeben kannst.
2. Mit Hilfe der rübergegebenen Credentials muss der Aufruf Invoke-Command (Zeile 245) erweitert werden.
3. In der Regel nutzt man hierfür einen dediziertes Benutzerkonto, welches Mitglied der Gruppe „Administrators“ ist. D.h. du musst zusätzlich den TokenFilter in der Registry deaktivieren.

Ansonsten gerne per E-Mail über die Adresse im Impressum melden.

Gruß,
Daniel

Hallo Daniel,

auch wenn der letzte Beitrag schon etwas her ist, versuche ich es hier einmal. Eventuell hast du ja einen Tipp für mich.

Folgende Szenarien:
Nr1:
PRTG Probe und  NSP Intranet.Rolle stehen im lokalen LAN (gleiches Subnetz gleiche Domain). GW-Rolle steht dediziert in der DMZ.

Hier können wir das Skript gegen die Intranet Rolle erfolgreich ausführen -> Abfrage via Service Account mit den benötigten Benutzerrechten

Nr2:
PRTG Probe steht im LAN, GW-Server und Intranet Rolle auf einem Server Installiert, Server steht in der DMZ  Standalone.

Hier klappt die Abfrage nicht, Fehlermeldung: Der Zugriff wurde verweigert. Um dieses Problem zu lösen, überprüfen Sie Ihre Zugangsdaten für Windows-Systeme in den Einstellungen des Geräts. (Code: PE095)

Abfrage via lokalen User (Testweise mit dem Administrator, sollte ja alle Rechte haben). Benutzergruppen NoSpamProxy Configuration Administrators NoSpamProxy Monitoring Administrators.

Die DMZ FW kann ausgeschlossen werden.

Eventuell noch eine Idee was beachtet werden muss?

Viele Grüße
Kim

Hallo Adrian,
nein, der Sensor muss auf den Server mit der NSP Intranet.Rolle zeigen. Dort werden die entsprechenden Informationen verwaltet und auch gespeichert. Die Gateway Rolle ist noch nur dafür da die Interaktion durchzuführen.

Gruß,
Daniel

Hallo Daniel, nein der Gateway-Server steht in der DMZ – die Intranet-Rolle ist im Lokalen Netz – ebenfalls der PRTG Server. Der Sensor muss doch auf die Gateway Rolle zeigen oder?

Danke & Gruß
Adrian

Hallo Adrian,
du hast den (virtuellen) Windows Server mit der Intranet Rolle von NSP in der DMZ stehen. Habe ich das richtig verstanden?

Gruß,
Daniel

The access has been denied. To resolve this issue, check your Credentials for Windows Systems in the device settings. (code: PE095)

die Zugangsdaten sind aber 100% richtig und in der Firewall wird auch nichts blockiert hinsichtlich DMZ.

Der Gatewayserver ist mit IP eingerichtet und die Parameter stehen so wie oben beschrieben beim Sensor hinterlegt.

Vieleicht hat jemand eine Idee ?

Vielen Dank !

Hallo David,
zuerst im Sensor in PRTG unter den Einstellungen den Paramater „Ergebnis speichern“ aktivieren. Im Anschluss den Sensor manuell starten und warten bis erneut der Fehler ausgegeben wird. Danach in die beiden Logfiles des Sensors ein Blick werfen. In der Regel sind dort weitere Informationen zu finden. Wenn du nicht weiter kommst, darfst du mir gerne die Logfiles per E-Mail (siehe Impressum) zu kommen lassen.

Unabhängig davon habe ich meine Test-Instanz von NSP auf Version 14.0.5 aktualisiert und meinen Sensor getestet. Ich konnte diesbezüglich keine Probleme feststellen. Nichts desto trotz habe ich heute eine neue Version des PowerShell Skripts veröffentlicht.

Gruß,
Daniel

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)

Hi Daniel,

Vielen Dank für Deine schnelle Reaktion!

Ja, es ist ein eingehender Sendekonnektor. Mit der geänderten Version Deines Skriptes wird er nicht mehr erfaßt und das Problem ist damit verschwunden. Ich sende Dir trotzdem gleich noch Screenshots des Konnektors.

Vielen Dank nochmal für Deine Arbeit an dem Skript! Ich finde es sehr nützlich.

Einen schönen Tag noch!
Björn Wunschik

Hallo Björn,
wünsch dir ebenfalls ein gutes neues Jahr.

Viele Dank für den Hinweis. Ich habe versucht das Ganze bei mir nachzustellen. Ich habe so eben eine Anpassung hochgeladen. Bitte damit nochmals testen.

Ist der Konnektor bei dir unter im Command Center unter Configuration -> E-Mailing -> Inbound send Connectors? Darfst mir auch gerne ein paar anonyme Screenshots per E-Mail (siehe Impressum) zu schicken. Somit kann ich es einfacher nachstellen.

Gruß,
Daniel

Vielen Dank für die Arbeit! Allerdings bin ich mit dem neuen Skript in ein Problem gelaufen, das vielleicht auch für andere relevant sein könnte.

Ich habe unseren NSP vor Weihnachten auf die aktuelle 14.0.2 gehoben und heute das aktualisierte Skript in unser PRTG eingebaut. Beim Update des NSP auf die 14 wird ein neuer O365-Konnektor angelegt ( https://docs.nospamproxy.com/Server/14/Suite/de-de/Content/update-information/14/changes-and-recommendations-version-14.htm ganz unten ) und mein PRTG ist jetzt der Meinung, das zum Konnektor gehörende Zertifikat sei seit 738521 Tagen abgelaufen. Dieser automatisch angelegte Konnektor ist nicht bearbeitbar, ich kann ihm kein Zertifikat zuordnen und sehe auch nicht, ob da überhaupt ein Zertifikat gebunden ist.

Meine „Lösung“ des Problems bestand jetzt erst mal darin, im PRTG die Limits für diesen Channel zu deaktivieren.

Einen schönen Tag noch!
Björn Wunschik

Hallo Nico,
ich konnte inzwischen das Problem nachstellen und die Ursache beheben. Es steht seit heute eine Neue Version des Skripts bereit.

Gruß,
Daniel

Hallo Nico,
welche 14er Version von NoSpamProxy kommt bei dir zum Einsatz? Damit ich das bei mir Nachstellen kann.

Gruß,
Daniel

Hallo Stefan,
Es gibt inzwischen zwei Versionen des PowerShell Skripts – für NSP v13.x und v14.x. Welche Version kommt bei dir zum Einsatz?
Welche Parameter hast du in das Feld Parameter des Sensors eingetragen?
Heißt das Gerät in PRTG gleich dem Namen des Servers?

Gruß,
Daniel

Hallo Frank,
in die von dir genannte Funktion habe ich mich auf den ersten Blick verliebet. 😉 Diese stammt aus dem PowerShell Skript von Thomas Stensitzki (siehe Link im Beitrag).

Bezüglich der notwendigen PRTG Probes habe ich mich evtl. ungenau ausgedrückt. Bei uns im Unternehmensnetzwerk wird natürlich Zusatzsoftware auf Servern vermieden wo es geht. Dazu gehört auch solch ein relatives kl. Tool wie eine PRTG Probe. WinRM ist bei uns nicht nur für PRTG im Einsatz sondern auch für divesee administrative Aufgaben. D.h. die Löcher sind bereits in (Gateway) Firewalls gebohrt.

Den PRTG HTTP Push Sensor hat bei meinen Überlegungen auch eine Rolle gespielt. Habe ich aber schlussendlich aus mehreren Grünen verworfen.:
a) Meine Arbeitszeit dafür war knapp bemessen, da es nicht geplant war, den Sensor einzuführen.
b) Die Kommunikationsrichtung (Server -> PRTG PRobe) ändert sich . D.h. es wären diverse Anpassungen an unseren Firewalls notwendig.
c) Wir nutzen bereits WinRM auf unseren Windows Servern für administrative Tätigkeiten. Damit sind die notwendigen Löcher schon vorhanden und funktioniert sofort.

Den KB-Artikel zu den Windows Performance Counter habe ich mir zu erst angesehen. Allerdings ist eine Differenzierung pro Gateway Rolle damit nicht möglich. Daher habe ich mich für einen separaten Sensor entschieden, wo ich per Parameter definieren was erfasst werden soll.

Wie immer führen viele Wege nach Rom…

Viele Grüße,
Daniel

Guten Abend Herr Jäschke,
vielen Dank für die Blumen. Die Idee/Grundlage stammt wie im Beitrag geschrieben von Thomas Stensitzki. Ich habe das sozusagen um unsere Bedürfnisse ergänzt/erweitert.

Das Verlinken in ihrem Forum geht natürlich in Ordnung. Bin ich sehr gespannt, wie sich dies entwickelt. 🙂
Weitere Beitäge sind natürlich geplant. Allerdings weniger zu NoSpamProxy. 😉

Viele Grüße,
Daniel Wydler

Ich nehme ihr Posting mal zum Anlass mal zu schauen, was wir vielleicht ins Produkt einbauen können.

NoSpamProxy hat aber schon heute Windows Performance Counter . Siehe auch https://www.nospamproxy.de/de/knowledge-base/windows-performance-counter-mit-prtg-abfragen/ . Die könnte man noch leichter und direkt per PRTG abfragen..

Aber beim Thema Monitoring ist ja eh nie fertig.

es freut mich sehr zu sehen, dass Sie Ihre Arbeit und Ihr erarbeitet Wissen mit der Öffentlichkeit teilen.
Ich freue mich schon drauf Ihr Skript in meiner Testumgebung auszuprobieren 🙂

Außerdem habe ich mir die Freiheit genommen Ihren Beitrag in unserem Forum zu verlinken (https://forum.nospamproxy.com/showthread.php?tid=17). Es ist ein hervorragendes Beispiel was mit dem NSP unter der Haube alles möglich ist.

Ich freue mich schon auf weitere Beiträge von Ihnen. 🙂

Mit freundlichen Grüßen,
Jan Jäschke

Produktmanager der Net at Work GmbH