chibisuke
Goto Top

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:
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.
Im Lauf der Diagnose und nach manchen Versuchen schlug der Fehler auch hin und wieder auf folgendes um
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
brachten allesamt keinen Erfolg.

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
Danach nahm er noch mal die Konfiguration des Powershell VD unter die Lupe, und siehe da...
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
..., 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...
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"):  
neu anlegen...
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
[...]
wodurch die benötigte Basic-Authentifizierung wieder eingetragen wurde, sowie anschließendes Abschalten des SSL-Zwangs:
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~

Content-Key: 145070

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

Ausgedruckt am: 29.03.2024 um 05:03 Uhr

Mitglied: Yasty25
Yasty25 14.07.2010 um 15:37:44 Uhr
Goto Top
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
Mitglied: Chibisuke
Chibisuke 14.07.2010 um 16:38:50 Uhr
Goto Top
Hi Rocco,

ich durfte während der wochenlangen Recherche wegen unserem Server leider schon feststellen dass es für die WinRM-Fehler 1001 Ursachen und ebenso viele Lösungsansätze gibt...
Haste die leicht zu findenden Vorschläge (HTTPS Listener, IIS-Erweiterung etc) schon durchprobiert?

Bei den Auth-Methoden kann ich nur das weitergeben was mir der Futzi von M$ gesagt hat, und der meinte eindeutig dass diese Felder eben nicht leer sein dürfen... Wobei ich immer noch den Verdacht habe dass die Optionsangaben in Powershell und IIS-Konsole auseinanderdriften und nur für Verwirrung sorgen <_<
Mitglied: tray-park
tray-park 20.01.2011 um 12:42:48 Uhr
Goto Top
Hi,

einfach genial!

Vielen Dank für die Rettung.

Grüße

Tray
Mitglied: Chibisuke
Chibisuke 20.01.2011 um 19:41:55 Uhr
Goto Top
Hi Tray,

freut mich dass es dir geholfen hat face-smile War bei euch auch das Powershell VD schuld?

Übrigens sei noch angemerkt dass wir uns etwa einen Monate nach dieser Aktion doch noch dazu entschlossen haben erst mal wieder auf Ex2007 zurückzugehen, es lief einfach nicht wirklich rund. Ex2010 scheint mal wieder zur Kathegorie der "kein MS-Produkt vor SP1" zu gehören...
Mitglied: aktony
aktony 09.05.2011 um 15:58:32 Uhr
Goto Top
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.
Mitglied: teetrinker
teetrinker 01.02.2012 um 09:32:10 Uhr
Goto Top
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
Mitglied: Chibisuke
Chibisuke 01.02.2012 um 21:31:58 Uhr
Goto Top
Hi teetrinker,

freut mich dass es geholfen hat. face-smile Rein Interesse halber, waren's auch die Auth-Methoden? Und habt ihr die SPs für Exchange drauf?
Bin nur neugierig ob sich seit SP0 was getan hat oder WinRM immer noch so eine Zicke ist. Vor allem da einer unserer Kunden demnächst von Ex07 auf 2010 migrieren will...
Mitglied: 105068
105068 13.02.2012 um 12:30:02 Uhr
Goto Top
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
Mitglied: Chibisuke
Chibisuke 13.02.2012 um 17:55:34 Uhr
Goto Top
N'Abend sempai (interessanter Name face-smile ),

kann dir da leider auf Anhieb nicht weiter helfen, wie weiter oben schon erwähnt haben wir uns kurz nach dem Vorfall wieder von Ex2010 verabschiedet... Rein vom Fehler her klingt das für mich aber eher nach DNS-Problemen.

Wär vielleicht doch besser einen eigenen Frage-Thread dafür aufzumachen, hier wird das zu leicht übersehen.

€dit: gerade gesehen, hast du ja bereits getan. Sorry dass ich dir nicht weiterhelfen kann.

~Chibi~
Mitglied: teetrinker
teetrinker 13.02.2012 um 18:13:29 Uhr
Goto Top
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
Mitglied: atroX87
atroX87 10.09.2012 um 14:53:00 Uhr
Goto Top
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
Mitglied: HilFi2000
HilFi2000 13.05.2013 um 22:44:15 Uhr
Goto Top
Danke atroX!!!!!

genau so war es auch bei mir!

Traurig das man nicht mal mehr dem BPA vertrauen kann...
Da hätte ich den Fehler nie vermutet. Was rauchen die bei MS eigentlich??? face-smile
Mitglied: tray-park
tray-park 14.05.2013 um 09:13:57 Uhr
Goto Top
iJoints face-smile
Mitglied: Genzo
Genzo 26.06.2013 um 19:08:29 Uhr
Goto Top
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
Mitglied: Chibisuke
Chibisuke 27.06.2013 um 19:12:12 Uhr
Goto Top
Hi Genzo,

schön zu hören dass es geholfen hat face-smile Wobei ich es etwas seltsam finde dass MS die Problematik nach 3 Jahren und ebenso vielen Service Packs wohl immer noch nicht in den Griff bekommen hat...
Naja, klopfen auf Holz *Kopf hau* dass wir das Theater nicht noch mal kriegen. Wir satteln gerade (wieder) auf 2010 um, dieses mal allerdings unter Server 2012, was wieder ganz andere Nebenwirkungen hat... Aber nach dem Desaster damals kommt uns keine Exchange-Version vor dem ersten SP mehr ins Haus.

Wünsche eine Stress-freie Restwoche und schönen Urlaub ;)

~Chibi
Mitglied: Genzo
Genzo 28.06.2013 um 07:44:16 Uhr
Goto Top
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 face-wink)

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
Mitglied: moonghost
moonghost 01.06.2015 um 08:43:20 Uhr
Goto Top
Hallo,

das hat mir jetzt den Allerwertesten gerettet. Vielen vielen Dank für diese SUPER-Anleitung.

Allerdings muss man nach Eingabe aller Befehle auch noch einen iisreset durchführen.

Danke noch mal.

Gruß

moonghost
Mitglied: Chibisuke
Chibisuke 01.06.2015 um 20:16:12 Uhr
Goto Top
Hey moonghost,

einerseits schön zu hören dass es mal wieder jemandem geholfen hat, andererseits einfach nur traurig dass das Problem immer noch auftreten kann...
Naja, M$ halt...

Schönen Abend noch ^^
Mitglied: Citytow
Citytow 30.11.2015 um 12:45:49 Uhr
Goto Top
Mahlzeit Jungs,

"Get-PowerShellVirtualDirectory |fl " funktioniert bei mir nicht, habe EX10 mit R2 2012 face-sad

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 ?
Mitglied: Chibisuke
Chibisuke 30.11.2015 um 18:08:35 Uhr
Goto Top
N'Abend City,

hast du eventuell Zeile 10 übersehen und das 2. PS-Snap-in nicht importiert? Wäre jetzt spontan das Erste das mir einfällt.