Ex2013: EMS funktioniert nicht mehr

[jeremy 10]

Hallo,

 

seit kurzem habe ich das Problem, dass die EMS auf dem Exchange nicht mehr funktioniert.

EAC, OWA, AES etc. funktionieren einwandfrei.

 

Beim Aufruf der EMS kommt:

AUSFÜHRLICH: Verbindung mit <server>.<domäne>.<tld> wird hergestellt.

New-PSSession : [<server>.<domäne>.<tld>] Beim Verbinden mit dem Remoteserver "<server>.<domäne>.<tld>" ist

folgender Fehler aufgetreten: [ClientAccessServer=<server>,BackEndServer=<server>.<domäne>.<tld>,RequestId=04615f29

-968a-42bf-9033-3c2b7dc4eaac,TimeStamp=03.02.2017 15:40:50] [FailureCategory=Cafe-SecureChannelFailure]  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 : -2144108477,PSSessionOpenFailed

 

Das Problem besteht seit einem Reboot. Im EvtLog konnte ich keine relevante Einträge finden.

Die Einstellungen der virtuellen Verzeichnisse habe ich überprüft, auch hier keine Auffälligkeiten.

 

Es sind alle Funktionen betroffen die eine RemoteShell verwenden.

 

WinRM QuickConfig bzw. ALLE WinRM-Befehle bringen:

C:>winrm quickconfig

Der WinRM-Dienst wird auf diesem Computer bereits ausgeführt.

WSManFault

 

Message = Der WinRM-Client hat eine Anforderung an den Remote-WS-Verwaltungsdienst gesendet und eine Antwort erhalten, in der gemeldet wurde, dass die angeforderte 

HTTP-URL nicht verfügbar ist. Diese Meldung wird normalerweise von einem HTTP-Server zurückgegeben, der das WS-Verwaltungsprotokoll nicht unterstützt.

 

Fehlernummer:  -2144108269 0x80338113

Der WinRM-Client hat eine Anforderung an den Remote-WS-Verwaltungsdienst gesendet und eine Antwort erhalten, in der gemeldet wurde, dass die angeforderte 

HTTP-URL nicht verfügbar ist. Diese Meldung wird normalerweise von einem HTTP-Server zurückgegeben, der das WS-Verwaltungsprotokoll nicht unterstützt.

C:>

 

Momentan fehlt mir der Ansatz wo ich noch suchen könnte.

Ich bin für jeden Tipp dankbar :-)

 

jeremy

bearbeitet 3. Februar 2017 von jeremy

[Nobbyaushb 1.471]

moin,

 

was wurde zuletzt geändert?

 

Nichts ist die falsche Antwort.

 

Zum Start mal hier:

http://www.msxfaq.de/windows/winrm.htm

 

;)

[DocData 85]

Falsche PowerShell Version. PoSh 5 oder WMF 5 instaliert? Oder nicht unterstütztes .NET Framework.

[Dr.Melzer 191]

was wurde zuletzt geändert?

 

Nichts ist die falsche Antwort.

 

 

Aus Sicht des Antwortenden ist "nichts" auf die Frage was geändert wurde durchaus eine richtige Antwort. Oft gibt es kein Wissen über eventuelle Änderungen und selbst mir ist es schon passiert, dass ich, ohne es wahrzunehmen, eine Änderung vorgenommen habe. Selbstverständlich hätte ich Stein und Bein geschworen, dass ich nichts geändert habe. ;-)

[Nobbyaushb 1.471]

Aus Sicht des Antwortenden ist "nichts" auf die Frage was geändert wurde durchaus eine richtige Antwort. Oft gibt es kein Wissen über eventuelle Änderungen und selbst mir ist es schon passiert, dass ich, ohne es wahrzunehmen, eine Änderung vorgenommen habe. Selbstverständlich hätte ich Stein und Bein geschworen, dass ich nichts geändert habe. ;-)

Der TO hat ja noch gar nicht geantwortet - ich habe nur vorgegriffen :D

 

:cool:

[Dr.Melzer 191]

Der TO hat ja noch gar nicht geantwortet - ich habe nur vorgegriffen :D

 

Das macht die Sache nicht besser, weil du damit dem TO ein negatives Verhalten unterstellst, welches er wahrscheinlich gar nicht an den Tag legen würde. ;-)

 

Besser einfach ohne vor zu greifen die Antwort auf die Frage abwarten. Dann weiter sehen. :-)

[jeremy 10]

Zunächst mal Danke für die Antworten.

 

Nun, es gibt tatsächlich keine dokumentierte Änderungen in letzter Zeit, abgesehen von Änderungen am Exchange selbst (Postfächer, Verteiler, Transport etc.) und natürlich Windows-Updates.

Die letzten relevanten Änderungen wurden von mir im Oktober 2016 durchgeführt; die Installation von CU14 und .NET 4.6.1.

Auf dem Server ist schon seit längerem WMF 4 installiert.

Es hat auch alles bis zu jenem Neustart funktioniert.

 

Die Dienste WWW-Publishingdienst und Windows-Remoteverwaltung laufen.

In der Firewall sind eingehend aktiviert: Windows-Remoteverwaltung 5985 und WWW-Dienste 80.

 

Danke für den Link, Norbert. Es funktioniert leider kein einziger WinRM-Befehl mehr. Ebensowenig Enable-PSRemoting.

 

Ebenfalls seit dem Neustart wird im AppLog Event 1309 protokolliert und zwar jedesmal wenn die EMS gestartet wird.

Hier würde ich auch die Ursache vermuten.

Ich selbst hatte das Vergnügen noch nicht, hab aber schon gehört dass es Erstrebenswerteres gibt als ein defektes .NET :-(

 

Protokollname: Application

Quelle:        ASP.NET 4.0.30319.0

Datum:         02.02.2017 09:52:13

Ereignis-ID:   1309

Ereigniscode: 3005 

Ereignismeldung: Es ist eine unbehandelte Ausnahme aufgetreten. 

Ausnahmetyp: NullReferenceException 

Ausnahmemeldung: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

Anforderungs-URL: https://mail.<DOMÄNE>.de:443/owa/auth/logon.aspx?url=https://mail.<DOMÄNE>.de/owa/PowerShell-LiveID&reason=0 

Anforderungspfad: /owa/auth/logon.aspx 

bearbeitet 4. Februar 2017 von jeremy

[Nobbyaushb 1.471]

Deinstalliere mal das .net 4.6.1

 

Danach die Exchange-Dienste neu starten (oder den ganzen Server)

 

Nachtrag: hier der Link zu dem Blog von meinem Freund Jeff:

http://www.expta.com/2016/02/how-to-uninstall-net-framework-461.html

 

Offiziell soll es gehen..

 

Hast du schon mal die Inst vom CU15 in Betracht gezogen? Damit sollte es gehen.

http://blog-schulenburg.de/index.php/kategorie-als-blog/87-exchange-build-nummern

 

;)

bearbeitet 4. Februar 2017 von Nobbyaushb

[jeremy 10]

Die Anleitung von Jeff Guillet kannte ich schon.

Bei "...Exchange will need to recompile all of its .NET assemblies...." habe ich durchaus Bedenken. Vor allem wenn dies ausgehend von einem "defekten" System geschieht und man bei Exchange nicht mit Snapshots arbeiten sollte.

Bei sowas fällt mir immer Alan Shepard ein: "Dear Lord, please don't let me f**k up." ;-)

 

Könnte eine Reparatur, wie in Update#2 von Jeffs Anleitung für .NET 4.5.2 empfohlen, nicht auch bei mir helfen?

Sollte ja eigentlich nur die Installation wiederholen und demzufolge zumindest nicht mehr beschädigen als schon ist.

 

Das CU15 würde ich in diesem Zustand eher nicht installieren wollen.

[DocData 85]

Ich musste das schon ein paar Mal machen. Wenn die Mühle danach hinüber ist > /DisasterRecovery.

[jeremy 10]

@DocData: Die Aussicht auf DesasterRecovery macht mir gleich Mut ;-)

 

netfx_setupverifier.exe hat schon mal keinen Fehler um .NET gefunden.

Dass es den Server 2008 R2 als Windows 7 erkennt ist, denke auch, aufgrund der selben OS-Basis nicht so tragisch.

 

[02/05/17,13:12:46] Beginning of new SetupVerifier error logging session

[02/05/17,13:12:46] Build created on October 26, 2016

[02/05/17,13:12:46] For more information about repairing the .NET Framework, see http://support.microsoft.com/kb/2698555 and http://go.microsoft.com/fwlink/?LinkID=246062

[02/05/17,13:12:46] Activity log file location: C:\Users\<USER\AppData\Local\Temp\setupverifier_main_02-05-17_13.12.46.txt

[02/05/17,13:12:46] Error log file location: C:\Users\<USER>\AppData\Local\Temp\setupverifier_errors_02-05-17_13.12.46.txt

[02/05/17,13:12:46] Windows build version from registry: 7601.23572.amd64fre.win7sp1_ldr.161011-0600

[02/05/17,13:12:46] Detected operating system: Windows 7 (x64)

[02/05/17,13:12:46] Windows directory: C:\Windows

[02/05/17,13:12:46] System directory: C:\Windows\system32

[02/05/17,13:12:46] Program Files directory: C:\Program Files (x86)

[02/05/17,13:12:46] Common Files directory: C:\Program Files (x86)\Common Files

[02/05/17,13:13:46] ****ERROR**** Process 'change user /execute' exited with return code 1

[02/05/17,13:13:46] SetupVerifier exiting with return value 0

[MurdocX 952]

Exchange 2013 mit CU15 und Net 4.6.2 wird problemlos und ohne Querverweise unterstützt. Net 4.6.1 hingegen bei CU14 u. CU15 nicht so einfach.

 

Exchange Server-Unterstützbarkeitsmatrix | technet

https://technet.microsoft.com/de-de/library/ff728623(v=exchg.150).aspx

[Nobbyaushb 1.471]

Moin,

 

das CU15 kompiliert die -net neu, daher der Tipp.

 

Ich würde die DB´s wegkopieren für den Fall mit RecoverServer

 

Ich nicht so schlimm und dauert auch nicht lange, letztes Mal mit kopieren 1h gebraucht - kommt natürlich drauf an, wie groß die DB´s sind.

 

Kopieren dauert meist länger als der ganze Rest.

 

;)

[jeremy 10]

Ich zweifle langsam, dass es am .NET liegt.

Hab jetzt mal eine Reparaturinstallation von .NET 4.61 durchgeführt und nachfolgend KB3146717 nochmal installiert: Keine Änderung

Danach .NET 4.6.2 und nachfolgend KB3146717 installiert: Keine Änderung

Alle Installationen sind fehlerfrei durchgelaufen, ebenso der anschließende Reboot.

 

Das CU15 kann ich auf die Schnelle nicht installieren. Allerdings glaube ich auch nicht, dass das dann die Probleme beseitigt.

 

Mglw. liegt es an WinRM, schließlich entsteht der Fehler bei New-PSSession.

Im Windows-Remote-Management Log tauchen Fehler mit der ID 142 auf: "Fehler bei WSMan-Vorgang "CreateShell". Fehlercode: 2150858819".

Ich würde die DB´s wegkopieren für den Fall mit RecoverServer

Ich nicht so schlimm und dauert auch nicht lange, letztes Mal mit kopieren 1h gebraucht - kommt natürlich drauf an, wie groß die DB´s sind.

Kopieren dauert meist länger als der ganze Rest.

Hm, die Installation der CU hat bei mir bislang immer ca 3 Std. gedauert.

Wir haben 5 DB mit insg. ca. 800 GB.

bearbeitet 5. Februar 2017 von jeremy

[NorbertFe 2.035]

Hast du genügend Ressourcen? Dann wäre eventuell eine Parallele Installation und postfachverschiebung eine Option.