Exchange 2010 und die WinRM-Fehler
Havarierter Exchange 2010 auf Server 2008 R2 std wurde nach längerer Eigenrecherche zusammen mit dem MS-Support wieder zum Laufen gebracht
Hi Leute,
nach knapp einem Monat Suche und Tests in eigener Sache und anschließendem Einschalten des Microsoft Supports läuft unser Exchange 2010 endlich wieder komplett so wie er soll.
Von Clientseite lief nach Erstkonfiguration alles bestens, erst als mal was an einem der 5 Konten angepasst werden sollte fiel auf dass weder die Exhange Konsole noch die Shell funktionierten.
Der Server schmiss einem jeweils immer nur folgende Meldung an den Kopf:
Im Lauf der Diagnose und nach manchen Versuchen schlug der Fehler auch hin und wieder auf folgendes um
Die üblichen Lösungsvorschläge von MSXFAQ, dem Exchange Team Blog und anderen Webseiten, unter anderem
Irgendwann reichte es und wir schalteten den MS Support ein. Der werte Herr ratterte erst mal sämtliche (selbst leicht zu findenden) Ansätze durch die ich schon die Wochen zuvor versucht hatte, aber was soll's, kann ja immer sein dass man was übersehen hat.
Danach ging das Rumprobieren los. Es wurden Systemlogs angefordert, Configdateien von Exchange und dem IIS bearbeitet und ersetzt, das Exchange Update Rollup 3 sowie ein Sicherheitsupdate für Server 2008 (KB978542) deinstalliert und sogar unser Antiviren-Server (Trendmicro WFBS) musste dran glauben und wurde vom System gekratzt. Doch nichts davon zeigte die gewünschte Wirkung, Shell und Konsole verweigerten weiterhin den Dienst, nur die Meldung änderte sich gelegentlich.
Mir schwante schon langsam dass MS bald den "nicht supportet"-Joker auspacken und sich aus dem Fall zurückziehen würde (unser Server liegt beim RAM deutlich unter den empfohlenen 8-12GB...), doch dann hatte der Supportler die entscheidende Idee!
Da die Exchange Shell ja nicht wollte versuchte er zunächst die entsprechenden CMDlets in der "normalen" Powershell zugänglich zu machen, was klappte.
Danach nahm er noch mal die Konfiguration des Powershell VD unter die Lupe, und siehe da...
..., wie in Zeile 7 und 8 zu sehen waren die Authentifizierungsmethoden leer!
Der Rest ging vergleichsweise flott von statten, das marode Powershell VD löschen...
neu anlegen...
wodurch die benötigte Basic-Authentifizierung wieder eingetragen wurde, sowie anschließendes Abschalten des SSL-Zwangs:
Danach ließen sich Exchange Konsole und Shell wieder bedienen und es blieben nur noch einige kleinere Sachen die wir selber beheben konnten.
Hoffe mal dass der Bericht auch anderen nützt die ein ähnliches Problem mit Exchange 2010 haben, im Lauf der Recherchen habe ich schon gemerkt dass WinRM-Fehler nicht allzu selten sind...
MfG
~Chibi~
Hi Leute,
nach knapp einem Monat Suche und Tests in eigener Sache und anschließendem Einschalten des Microsoft Supports läuft unser Exchange 2010 endlich wieder komplett so wie er soll.
Von Clientseite lief nach Erstkonfiguration alles bestens, erst als mal was an einem der 5 Konten angepasst werden sollte fiel auf dass weder die Exhange Konsole noch die Shell funktionierten.
Der Server schmiss einem jeweils immer nur folgende Meldung an den Kopf:
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.
Der WinRM-Client hat einen Status in Bezug auf einen HTTP-Serverfehler (500) empfangen, aber der Remotedienst hat keine anderen Informationen zur Fehlerursache bereitgestellt.
Die üblichen Lösungsvorschläge von MSXFAQ, dem Exchange Team Blog und anderen Webseiten, unter anderem
- HTTP(S) Listener von WinRM überprüfen
- die WinRM-IIS-Erweiterung de- und neu installieren mit anschließendem winrm quickconfig
- Im IIS-Manager sicherstellen dass für das Powershell virtual directory die Module kerbauth und WSMan als Systemeigen/lokal und mit richtigem Pfad eingerichtet sind
- die SSL-Einstellungen für das Powershell VD überprüfen
Irgendwann reichte es und wir schalteten den MS Support ein. Der werte Herr ratterte erst mal sämtliche (selbst leicht zu findenden) Ansätze durch die ich schon die Wochen zuvor versucht hatte, aber was soll's, kann ja immer sein dass man was übersehen hat.
Danach ging das Rumprobieren los. Es wurden Systemlogs angefordert, Configdateien von Exchange und dem IIS bearbeitet und ersetzt, das Exchange Update Rollup 3 sowie ein Sicherheitsupdate für Server 2008 (KB978542) deinstalliert und sogar unser Antiviren-Server (Trendmicro WFBS) musste dran glauben und wurde vom System gekratzt. Doch nichts davon zeigte die gewünschte Wirkung, Shell und Konsole verweigerten weiterhin den Dienst, nur die Meldung änderte sich gelegentlich.
Mir schwante schon langsam dass MS bald den "nicht supportet"-Joker auspacken und sich aus dem Fall zurückziehen würde (unser Server liegt beim RAM deutlich unter den empfohlenen 8-12GB...), doch dann hatte der Supportler die entscheidende Idee!
Da die Exchange Shell ja nicht wollte versuchte er zunächst die entsprechenden CMDlets in der "normalen" Powershell zugänglich zu machen, was klappte.
PS C:\Users\Administrator> add-PSSnapin Microsoft.Exchange.Management.PowerShell.Support
PS C:\Users\Administrator> Get-PSSnapin
[...]
Name : Microsoft.Exchange.Management.PowerShell.Support
PSVersion : 1.0
Description : Support Tasks for the Exchange Server
PS C:\Users\Administrator> add-pssnapin Microsoft.Exchange.Management.PowerShell.E2010
PS C:\Users\Administrator> Get-PowerShellVirtualDirectory |fl
CertificateAuthentication : False
RequireSSL : False
Name : PowerShell (Default Web Site)
InternalAuthenticationMethods : {}
ExternalAuthenticationMethods : {}
LiveIdSpNegoAuthentication : False
WSSecurityAuthentication : False
LiveIdBasicAuthentication : False
BasicAuthentication : False
DigestAuthentication : False
WindowsAuthentication : False
MetabasePath : IIS://ServerFQDN/W3SVC/1/ROOT/PowerShell
Path : C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell
Server : Server
InternalUrl : http://ServerFQDN/powershell
ExternalUrl :
AdminDisplayName :
ExchangeVersion : 0.10 (14.0.100.0)
DistinguishedName : CN=PowerShell (Default Web Site),CN=HTTP,CN=Protocols,CN=Server,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Firma,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Firma,DC=local
Identity : Server\PowerShell (Default Web Site)
Guid : c54a7d7c-5068-42ff-a0d2-37ec5bd886a1
ObjectCategory : Firma.local/Configuration/Schema/ms-Exch-Power-Shell-Virtual-Directory
ObjectClass : {top, msExchVirtualDirectory, msExchPowerShellVirtualDirectory}
WhenChanged : 13.11.2009 12:41:07
WhenCreated : 13.11.2009 12:41:07
WhenChangedUTC : 13.11.2009 11:41:07
WhenCreatedUTC : 13.11.2009 11:41:07
OrganizationId :
OriginatingServer : ServerFQDN
IsValid : True
Der Rest ging vergleichsweise flott von statten, das marode Powershell VD löschen...
PS C:\Users\Administrator> Remove-PowerShellVirtualDirectory -identity 'Server\PowerShell (Default Web Site)'
Bestätigung
Möchten Sie diese Aktion wirklich ausführen?
Das virtuelle Windows PowerShell-Verzeichnis "PowerShell (Default Web Site)" auf Server "Server" wird entfernt.
[J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "J"):
PS C:\Users\Administrator> New-PowerShellVirtualDirectory
Cmdlet New-PowerShellVirtualDirectory an der Befehlspipelineposition 1
Geben Sie Werte für die folgenden Parameter an:
Name: PowerShell
Name Server
---- ------
PowerShell (Default Web Site) Server
PS C:\Users\Administrator> Get-PowerShellVirtualDirectory|fl
CertificateAuthentication : False
RequireSSL : True
Name : PowerShell (Default Web Site)
InternalAuthenticationMethods : {Basic}
ExternalAuthenticationMethods : {Basic}
LiveIdSpNegoAuthentication : False
WSSecurityAuthentication : False
LiveIdBasicAuthentication : False
BasicAuthentication : True
DigestAuthentication : False
WindowsAuthentication : False
[...]
PS C:\Users\Administrator> Set-PowerShellVirtualDirectory -Identity 'Server\PowerShell (Default Web Site)' -RequireSSL:$false
PS C:\Users\Administrator> Get-PowerShellVirtualDirectory|fl
CertificateAuthentication : False
RequireSSL : False
Name : PowerShell (Default Web Site)
InternalAuthenticationMethods : {Basic}
ExternalAuthenticationMethods : {Basic}
[...]
Danach ließen sich Exchange Konsole und Shell wieder bedienen und es blieben nur noch einige kleinere Sachen die wir selber beheben konnten.
Hoffe mal dass der Bericht auch anderen nützt die ein ähnliches Problem mit Exchange 2010 haben, im Lauf der Recherchen habe ich schon gemerkt dass WinRM-Fehler nicht allzu selten sind...
MfG
~Chibi~
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 145070
Url: https://administrator.de/knowledge/exchange-2010-und-die-winrm-fehler-145070.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
20 Kommentare
Neuester Kommentar
Hallo,
als ich deinen Artikel gesehen habe, hatte ich die Hoffnung das ich mein Consolen Connection Problem lösen könnte. Leider hat es bei mir nicht geklappt.
Übrigens: Die Authentifizierungsmethode bei 7 und 8 sind STANDARDMÄßIG leer. Habe hier noch einen funktionierenden Server, da ist es auch so. Daran kanns also nicht liegen.
Gruß Rocco
als ich deinen Artikel gesehen habe, hatte ich die Hoffnung das ich mein Consolen Connection Problem lösen könnte. Leider hat es bei mir nicht geklappt.
Übrigens: Die Authentifizierungsmethode bei 7 und 8 sind STANDARDMÄßIG leer. Habe hier noch einen funktionierenden Server, da ist es auch so. Daran kanns also nicht liegen.
Gruß Rocco
Ich hatte das gleiche problem na mehreren test und versuchen habe ich den server neu aufgesetzt und alle updates nach und nach installiert.
Beim ersten mal als ich das ding aufsetzte lief der Exchange server und dann als ich die letzten updates zog nicht mehr.
na allen updates lief er nur nach diesem nicht mehr.
Update for Rights Management Services Client for Windows Server 2008 x64 Edition (KB979099)
das heist ich habe jetzt den server zurück gesetzt und nun zeigt er neue updates an die vorher nicht da waren.
Essential ist das einzige was ich noch nicht installiert habe was vieleicht noch in frage kämme.
doch so leuft er bis jetzt super.
Beim ersten mal als ich das ding aufsetzte lief der Exchange server und dann als ich die letzten updates zog nicht mehr.
na allen updates lief er nur nach diesem nicht mehr.
Update for Rights Management Services Client for Windows Server 2008 x64 Edition (KB979099)
das heist ich habe jetzt den server zurück gesetzt und nun zeigt er neue updates an die vorher nicht da waren.
Essential ist das einzige was ich noch nicht installiert habe was vieleicht noch in frage kämme.
doch so leuft er bis jetzt super.
Hallo Chibisuke
vielen Dank für Deinen Beitrag. Hat mir nach wochenlanger Suche und vielen Versuchen endlich den entscheidenden Hinweis geliefert.
Musste danach noch die web.config unter C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell mit einer älteren Version aus einem Backup ersetzen und jetzt läuft alles wieder.
Also nochmals danke!
Gruss
teetrinker
vielen Dank für Deinen Beitrag. Hat mir nach wochenlanger Suche und vielen Versuchen endlich den entscheidenden Hinweis geliefert.
Musste danach noch die web.config unter C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell mit einer älteren Version aus einem Backup ersetzen und jetzt läuft alles wieder.
Also nochmals danke!
Gruss
teetrinker
Hi,
vielen Dank für die super Anleitung leider hat das bei mir nicht geholfen .... ich bekomme jetzt folgende Meldung:
Der WinRM-Client kann die Anforderung nicht verarbeiten, weil der Servername nicht aufgelöst werden kann.
Ich dreh noch am Rad .... Wäre Top wenn jmd. eine Idee hätte.
Gruß
Sempai
vielen Dank für die super Anleitung leider hat das bei mir nicht geholfen .... ich bekomme jetzt folgende Meldung:
Der WinRM-Client kann die Anforderung nicht verarbeiten, weil der Servername nicht aufgelöst werden kann.
Ich dreh noch am Rad .... Wäre Top wenn jmd. eine Idee hätte.
Gruß
Sempai
Hallo Chibisuke
die Frage von sempai hat mich daran erinnert, dass Du noch kleine Zusatzfragen hattest.
Was es letztlich genau war, kann ich Dir nicht sagen. Nur dass ich alle anderen 'Lösungen' aus dem Netz probiert hatte und erst Dein Eintrag geholfen hat.
Was ich Dir aber sagen kann, die SPs und sonstigen Updates waren alle drauf.
Ich habe Exchange 2010 selber im Einsatz und es ist auch bei einigen Kunden installiert. Läuft überall ohne Schwierigkeiten!
Dieses eine Mal war es eindeutig eine Fehlmanipulation des Kunden, der sämtliche Zertifikate gelöscht hatte. Danach trat das Problem auf.
Sonst nicht die geringsten Problemel Habe mir schnell an den Kopf gefasst (Touch wood!)
Gruss und nochmals danke
teetrinker
die Frage von sempai hat mich daran erinnert, dass Du noch kleine Zusatzfragen hattest.
Was es letztlich genau war, kann ich Dir nicht sagen. Nur dass ich alle anderen 'Lösungen' aus dem Netz probiert hatte und erst Dein Eintrag geholfen hat.
Was ich Dir aber sagen kann, die SPs und sonstigen Updates waren alle drauf.
Ich habe Exchange 2010 selber im Einsatz und es ist auch bei einigen Kunden installiert. Läuft überall ohne Schwierigkeiten!
Dieses eine Mal war es eindeutig eine Fehlmanipulation des Kunden, der sämtliche Zertifikate gelöscht hatte. Danach trat das Problem auf.
Sonst nicht die geringsten Problemel Habe mir schnell an den Kopf gefasst (Touch wood!)
Gruss und nochmals danke
teetrinker
Hi
Muss auch mal eben meinen Senf dazu geben. Habe grad Blut und Wasser geschwitzt, als ich dieselbe Meldung erhalten habe.
Bei mir war das Problem der BPA (Bestpracticeanalyzer) der der meinung war, mal solle doch im IIS den MSExchangePowershellAppPool lieber als ApplicationPoolIdentity laufen lassen, anstatt localsystem.
Gesagt getan, im ersten Moment läuft auch noch alles (scheint sich erst später zu aktualisieren und danach gibt es keinen lokalen Zugriff mehr per Exchangeconsole mit der besagten Fehlermeldung)
Vieleicht solltet ihr das zuerst prüfen bevor ihr das Verzeichnis löscht und neu erstellt.
Grüße atroX
Muss auch mal eben meinen Senf dazu geben. Habe grad Blut und Wasser geschwitzt, als ich dieselbe Meldung erhalten habe.
Bei mir war das Problem der BPA (Bestpracticeanalyzer) der der meinung war, mal solle doch im IIS den MSExchangePowershellAppPool lieber als ApplicationPoolIdentity laufen lassen, anstatt localsystem.
Gesagt getan, im ersten Moment läuft auch noch alles (scheint sich erst später zu aktualisieren und danach gibt es keinen lokalen Zugriff mehr per Exchangeconsole mit der besagten Fehlermeldung)
Vieleicht solltet ihr das zuerst prüfen bevor ihr das Verzeichnis löscht und neu erstellt.
Grüße atroX
Auch wenn dieser Thread schon etwas älter ist... 1000 Dank!!!! Ich hatte genau dasselbe Problem auf einem SBS 2011 beim Kunden und war schon kurz davor bei MS nen Call aufzumachen, da "stolpere" ich über diesen "Erfahrungsbericht"! Der Hammer! Ist so schön detailliert und genau beschrieben, dass es eher ne Anleitung ist. Die anderen Hinweise, welche man so über Google findet hatte ich auch schon durch - brachte alles nichts oder nur Teilerfolge!
Um es kurz zu machen: Vielen, vielen Dank! Du hast meine Woche und - viel wichtiger - meinen Urlaub gerettet!!!
Gruß
Genzo
Um es kurz zu machen: Vielen, vielen Dank! Du hast meine Woche und - viel wichtiger - meinen Urlaub gerettet!!!
Gruß
Genzo
Hallo Chibisuke!
Ich denke das Problem ist der BPA. Wir haben den Kunden von einem Mitbewerber übernommen und der hatte das Tool auf dem SBS 2011 im Einsatz. Als es dann nach Wochen nicht mehr weiter ging kam unsere Firma ins Spiel...
Auch bei diesem Server war im IIS MSExchangePowershellAppPool als ApplicationPoolIdentity am laufen, anstatt localsystem. Der BPA war von unserem Mitbewerber installiert worden - ich selbst habe das Tool noch nie genutzt )
Das Umstellen auf Localsystem brachte bei mir aber nur einen Teilerfolg (zusammen mit einer Exchange SP2 Installation). Der Entscheidende "heisse" Tip war das Neuanlegen der Powershell-Virtualdirectory!!! Traurig, dass dieser Bug im BPA immer noch vorhanden zu sein scheint!
Dir ebenfalls ein schönes Wochenende!
Genzo
Ich denke das Problem ist der BPA. Wir haben den Kunden von einem Mitbewerber übernommen und der hatte das Tool auf dem SBS 2011 im Einsatz. Als es dann nach Wochen nicht mehr weiter ging kam unsere Firma ins Spiel...
Auch bei diesem Server war im IIS MSExchangePowershellAppPool als ApplicationPoolIdentity am laufen, anstatt localsystem. Der BPA war von unserem Mitbewerber installiert worden - ich selbst habe das Tool noch nie genutzt )
Das Umstellen auf Localsystem brachte bei mir aber nur einen Teilerfolg (zusammen mit einer Exchange SP2 Installation). Der Entscheidende "heisse" Tip war das Neuanlegen der Powershell-Virtualdirectory!!! Traurig, dass dieser Bug im BPA immer noch vorhanden zu sein scheint!
Dir ebenfalls ein schönes Wochenende!
Genzo
Mahlzeit Jungs,
"Get-PowerShellVirtualDirectory |fl " funktioniert bei mir nicht, habe EX10 mit R2 2012
hat jemand ne Idee ?
"Get-PowerShellVirtualDirectory |fl " funktioniert bei mir nicht, habe EX10 mit R2 2012
Get-PowerShellVirtualDirectory : Die Benennung "Get-PowerShellVirtualDirectory" wurde nicht als Name eines Cmdlet,
einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des
Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1
+ Get-PowerShellVirtualDirectory |fl
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-PowerShellVirtualDirectory:String) , CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
hat jemand ne Idee ?