Exchange 2013 Powershell Console funktioniert nicht mehr
Hallo liebe Community,
wir bekommen beim Aufruf der Exchange 2013 Powershell folgende Fehlermeldung:
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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 241584
Url: https://administrator.de/contentid/241584
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
8 Kommentare
Neuester Kommentar
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:
http://www.frankysweb.de/exchange-2013-abgelaufene-zertifikate-und-serv ...
Grüße Uwe
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:
- Exchange 2010 und die WinRM-Fehler
- http://blogs.technet.com/b/exchange/archive/2010/02/04/3409289.aspx
http://www.frankysweb.de/exchange-2013-abgelaufene-zertifikate-und-serv ...
Grüße Uwe
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
Grüße Uwe
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.
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
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
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.
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.