Fehler "Zugriff verweigert", wenn versucht wird, den Exchange-Server auf localhost zu remote

8

Ich versuche, eine PowerShell-Sitzung einzurichten, um mehrere Exchange-Befehle für einen Exchange-Server auf dem lokalen Host auszuführen. Ich bekomme immer den folgenden Fehler:

%Vor%

Mein Code ist ein Copy-Paste aus dem Microsoft Technet-Artikel . Es funktioniert gegen Remote-Maschine, aber immer wenn ich die Maschine anvisiere, von der ich laufe, bekomme ich den obigen Fehler.

Was ich bisher versucht habe:

  1. Das Hilfethema about_remote_troubleshooting wurde überprüft. Nichts in Bezug auf Zugriff verweigert Fehler funktioniert.
  2. Gezielte Remote-Computer, die dieselben Anmeldeinformationen verwenden wie der Fehler Zugriff verweigert. (Ohne Problem verbunden)
  3. Überprüft, dass meine PowerShell-Sitzung als Administrator ausgeführt wird. (Es ist)
  4. Überprüft, dass die Exchange-Verwaltungsshell erfolgreich gestartet werden kann. (Es ist)
  5. Es wurde ohne Anmeldeinformationen versucht, ob das funktioniert. (Hat es nicht)
  6. Checked net use und net session , um sicherzustellen, dass ich keine merkwürdigen Mehrfachverbindungen mit denselben Anmeldeinformationen hatte. (Ich habe nichts gesehen, um das anzuzeigen)
  7. Dies wurde sowohl mit dem Skript, das Probleme verursacht, als auch mit der manuellen Eingabe der Befehle in eine Powershell-Konsole versucht. (hat die gleichen Ergebnisse in beide Richtungen. Yay für Konsistenz)
  8. Dies wurde auf mehreren Systemen versucht. (Gleiches Ergebnis überall)

Einige schnelle Hinweise:

  • Dies ist Exchange 2013, das unter Windows Server 2012 ausgeführt wird. Es handelt sich um eine grundlegende Installation, lediglich eine Testumgebung mit sehr wenig Daten und minimaler Konfiguration, die über das Installieren und Aktivieren von Remoting hinausgeht.
  • Die Anmeldeinformationen wurden für den Domänenadministrator verwendet, der auch über die erforderlichen Exchange-Berechtigungen verfügt, um alle erforderlichen Maßnahmen zu ergreifen. Das heißt, solange ich eine Maschine anvisiere, die nicht die ist, vor der ich laufe, habe ich keinerlei Probleme, und nichts ändert sich mehr an der Art, wie ich mich verbinde. Darüber hinaus handelt es sich um eine Testdomäne, bei der der Zugriff des Domänenadministrators in keiner Weise eingeschränkt oder optimiert wurde. Daher sollte er vollständigen und vollständigen Zugriff auf alles haben.

Die spezifischen Befehle, die ich eingeben möchte, sind:

%Vor%

Ist die Verbindung zum localhost so etwas, das ich tun könnte? Oder wird es einfach nicht unterstützt?

Ich bin zu diesem Zeitpunkt völlig am Ende. Jede Hilfe, selbst um mich in die richtige Richtung zu lenken, wäre sehr willkommen.

EDIT: Ich sollte hinzufügen, ich habe versucht, eine Verbindung zu diesem localhost von einem anderen Computer, mit den gleichen Befehlen wie oben, und es funktionierte ohne Problem. Also denke ich nicht, dass es sich um ein lokales Konfigurationsproblem handelt.

    
Jgraum 27.05.2015, 20:10
quelle

2 Antworten

1

Ich bin also letzte Woche über die Lösung gestolpert. Es scheint etwas mit der verwendeten Authentifizierung zu tun zu haben. Ich hatte den Parameter "-Authentication" leer gelassen, um den New-PSSession-Befehl sortieren zu lassen, welche Methode am besten wäre.

Offensichtlich ist dies die Authentifizierungsmethode "Negotiate", die Kerberos gegen einen Remote-Computer auswählt, aber NTLM andernfalls auswählt (oder zumindest das war mein beobachtetes / angenommenes Verhalten). Siehe diese Microsoft-Beschreibung von die Authentifizierungsmethoden.

Angabe einer bestimmten Authentifizierungsmethode (sowohl "Kerberos" als auch "Basic" funktionierten, "Negotiate" nicht, ich habe nicht zu viel daran herumgebastelt) löscht das Problem und erlaubte mir, mich mit der lokalen Exchange-Instanz zu verbinden.

Also eher als das:

%Vor%

Mach das:

%Vor%

Warum hat das geklappt? Ich habe keine Ahnung. Ich werde es Leuten überlassen, die mehr wissen als ich, um es zu erklären.

    
Jgraum 01.06.2015, 14:40
quelle
0

Wenn Sie nur versuchen, eine Sitzung auf demselben Computer wie Ihre aktuelle Sitzung zu erstellen, lassen Sie den URI weg.

%Vor%

Dies erstellt eine neue Sitzung auf dem lokalen Host, mit der Sie sich verbinden und nach Bedarf nutzen können.

    
TheMadTechnician 28.05.2015 02:18
quelle