minimalwerk
Goto Top

Exchange 2013 Powershell Console funktioniert nicht mehr

Hallo liebe Community,

wir bekommen beim Aufruf der Exchange 2013 Powershell folgende Fehlermeldung:

New-PSSession : [server2.gral.local] Beim Verbinden mit dem Remoteserver "server2.gral.local" ist folgender Fehler 

aufgetreten: Der WinRM-Client kann die Anforderung nicht verarbeiten. Der Inhaltstyp der HTTP-Antwort vom Zielcomputer kann nicht ermittelt werden. Der Inhaltstyp fehlt oder ist ungültig. Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting". 

In Zeile:1 Zeichen:1 

+ New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ... 

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

+ CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin 

   gTransportException 

+ FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed

zuerst dachte ich, dass dies mit einem fehlerhaften Update auf CU5 in Verbindung stehen würde. Jedoch besteht dieses Problem auch noch nachdem das Backup mit dem Stand SP1 erfolgreich eingespielt wurde. Siehe auch meinen Beitrag unter: Exchange 2013 CU5 fehlgeschlagen (Probleme mit Bindings und IPRanges ?)

folgende Seite zur Fehlerbehebung habe ich bereits bearbeitet:

http://social.technet.microsoft.com/Forums/de-DE/bc843147-e60a-46c4-b00 ...

Dies hilft uns jedoch nicht weiter. Wir haben nirgends eine gleiche Installation auf die wir zurück greifen können. Und da das Backup des Vortages korrekt läuft vermute ich, dass dieser Powershell Fehler schon was länger exisitiert. Benutzt habe ich diese schon eine ganze Weile nicht mehr.

hat hier jemand einen Lösungsvorschlag?


LG, Frank

Content-Key: 241584

Url: https://administrator.de/contentid/241584

Ausgedruckt am: 19.03.2024 um 09:03 Uhr

Mitglied: colinardo
colinardo 23.06.2014 aktualisiert um 13:48:46 Uhr
Goto Top
Hallo Frank,
warum dazu dann einen weiteren Thread aufmachen ?

Checke zuerst mal die Authentifizierungseinstellungen der virtuellen Exchange-Verzeichnisse, vor allem das des powershell-Verzeichnisses im IIS: http://technet.microsoft.com/de-de/library/gg247612%28v=exchg.150%29.as ...
Wenn diese stimmen, mach mal ein IISRESET /noforce auf der Kommandozeile. Wenn das auch nichts hilft, gehe mal in die Anmeldeinformationsverwaltung und lösche dort Alle hinterlegten Credentials (nicht wundern, aber das kann tatsächlich mit dem Fehlverhalten zu tun haben hatte ich hier schon 2 mal in Beiträgen)

Ansonsten:
Zertifikat abgelaufen ?:
http://www.frankysweb.de/exchange-2013-abgelaufene-zertifikate-und-serv ...

Grüße Uwe
Mitglied: minimalwerk
minimalwerk 23.06.2014 aktualisiert um 13:50:18 Uhr
Goto Top
Zitat von @colinardo:
Hallo Frank,
warum dazu dann einen weiteren Thread aufmachen ?

Hallo Uwe,

weil der andere Thread im Grunde ja eher etwas mit dem CU5 zu tun hatte und das Problem gelöst wurde. Dachte hier ist dieses separate Problem dann besser aufgehoben und zudem übersichtlicher.

Zitat von @colinardo:
Checke zuerst mal die Authentifizierungseinstellungen der virtuellen Exchange-Verzeichnisse, vor allem das des
powershell-Verzeichnisses im IIS: http://technet.microsoft.com/de-de/library/gg247612%28v=exchg.150%29.as ...
Wenn diese stimmen, mach mal ein IISRESET auf der Kommandozeile. Wenn das auch nichts hilft, gehe mal in die
Anmeldeinformationsverwaltung und lösche dort Alle hinterlegten Credentials (nicht wundern, aber das kann
tatsächlich mit dem Fehlverhalten zu tun haben hatte ich hier schon 2 mal in Beiträgen)


Exchange 2010 und die WinRM-Fehler

Grüße Uwe

Ok, werde ich nachher mal testen. Danke erstmal für die schnelle Antwort face-smile
Mitglied: minimalwerk
minimalwerk 27.06.2014 um 09:47:03 Uhr
Goto Top
leider hat hier nichts geholfen :/
In der Anmeldeinformationsverwaltung waren gar keine Credentials aufgeführt. Die Authentifizierungseinstellungen hatten ich anhand deines ersten Links verglichen. Alles so wie es sein sollte. Einen iisreset habe ich trotzdem einmal durchgeführt.

Den zweiten Link habe ich auch einmal studiert^^ Wie dort beschrieben habe ich die CMDlets über die normale Powershell zugänglich gemacht. Das klappte soweit auch. Die Einstellungen welche ich mit "Get-PowerShellVirtualDirectory |fl" bekam sahen aber korrekt aus. Nichts desto trotz habe ich wie beschreiben die Powershell VD gelöscht und neu erstellt. Server auch einmal neu gestartet.

Etwas hat sich aber jetzt geändert. Am Afang bekam ich den Fehler in der Powershell 3x hinter einander angezeigt. Nun habe ich den Fehler 5x in der Console stehen. Oh man, ich weiß nicht weiter :/

LG
Mitglied: colinardo
colinardo 27.06.2014 aktualisiert um 09:57:49 Uhr
Goto Top
Da es ja laut deinem letzten Thread nur ein Testsystem ist, ist hier vermutlich beim Update irgendetwas schief gelaufen (können wir hier leider nicht alles sehen). Fakel nicht lang rum, und setzt die Kiste ordentlich neu auf, und mach vom jetzigen Zustand ein Backup. Und verschiebe die Fehlersuche mit dem Backup (in einer VM) auf einen späteren Zeitpunkt wenn du nicht im Stress bist.

Grüße Uwe
Mitglied: minimalwerk
minimalwerk 27.06.2014 um 12:36:00 Uhr
Goto Top
so wirds gemacht. Danke für deine Hilfe!!!

LG
Mitglied: borstelix
borstelix 10.09.2015 um 15:49:09 Uhr
Goto Top
Hallo an alle!

Dieser Thread ist nun schon 1 Jahr alt, aber ich habe nun ein ähnliches Problem:

Unter dem Link www.administrator.... ist der Aufruf der Exchange-cmdlets in der normalen PS beschrieben. Das klappt auch soweit. nur nach "Get-PowerShellVirtualDirectory |fl" listet er nicht die Parameter des VD's auf, sondern bricht mit folgender Fehlermeldung ab.

Get-PowerShellVirtualDirectory : Der Verzeichniseintrag für die Internetinformationsdienste (IIS) kann nicht erstellt w
erden. Fehlermeldung: Zugriff verweigert
. HResult = -2147024891
Bei Zeile:1 Zeichen:31
+ Get-PowerShellVirtualDirectory <<<<  |fl
    + CategoryInfo          : NotInstalled: (xxx-EXCHANGE\Po...fault Web Site):ADObjectId) [Get-PowerShellVirtualDirec
   tory], IISGeneralCOMException
    + FullyQualifiedErrorId : E1791F82,Microsoft.Exchange.Management.SystemConfigurationTasks.GetPowerShellVirtualDire


Hier scheinen nun die Rechte nicht zu stimmen. Obwohl ich die Rechte der virtuellen Verzeichnisse im IIS nach den Vorgaben der Technet-Seite kontrolliert habe, insbesondere dieses Verzeichnis für die Powershell.

Ursache für meine Fehlersuche war der fehlende Zugriff auf die Exchange-Verwaltung, welche sich in folgendem Fehler manifestiert:

"Der WinRM-Client hat einen HTTP-Statuscode "303" vom Remote-WS-Verwaltungsdienst erhalten.

Auch diese Meldung scheint auf ein Rechteproblem zu deuten. Bei meiner Suche nach der Fehlerursache finde ich einige Seiten, die sich mit dem Problem WinRM beschäftigen, aber leider brachten mich alle bisherigen Ansätze, die ich aus diesen Seiten ziehen konnte, nicht wirklich weiter. Alles scheint soweit i.O. zu sein.

Hatte einer von Euch schon mal dieses Problem, insbesondere diesen Fehler 303 und wenn ja, gibt es auch eine weniger radikale Lösung wie das Neuaufsetzen des EX 2010

VG Andreas
Mitglied: colinardo
colinardo 10.09.2015 aktualisiert um 17:38:37 Uhr
Goto Top
Hallo Andreas,
bitte nutze den Exchange Management Troubleshooter:
Resolving WinRM errors and Exchange 2010 Management tools startup failures

Grüße Uwe

p.s. das nächste mal bitte eine neue Frage erstellen. Das Kapern von Threads sehen wir hier im Sinne des TOs nicht so gerne. Danke.
Mitglied: borstelix
borstelix 14.09.2015 um 07:48:55 Uhr
Goto Top
Hallo Uwe,

erst mal Danke für die Info. Damit werde ich mich in den nächsten Stunden mal auseinandersetzen.

Sorry für das "entern", face-wink

VG

Andreas