Jump to content

Ex2013: EMS funktioniert nicht mehr


Direkt zur Lösung Gelöst von jeremy,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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 von jeremy
Link zu diesem Kommentar

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. ;-)

Link zu diesem Kommentar

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:

Link zu diesem Kommentar

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.
Anforderungspfad: /owa/auth/logon.aspx 
bearbeitet von jeremy
Link zu diesem Kommentar

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 von Nobbyaushb
Link zu diesem Kommentar

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.

Link zu diesem Kommentar

@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
Link zu diesem Kommentar

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.

 

;)

Link zu diesem Kommentar

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 von jeremy
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...