Drei Gründe für Fehler in der Exchange 2010-Verwaltungskonsole

Exchange Server 2010 ist ein komplexes Produkt, und es können eine Reihe technischer Probleme auftreten. Überraschenderweise ist eines der häufigsten Probleme, auf die Administratoren stoßen, ein Fehler in der Exchange 2010-Verwaltungskonsole. Lassen Sie uns herausfinden, warum die Konsole möglicherweise nicht mehr funktioniert und wie sie behoben werden kann.

1. Verbindungsprobleme

Das Exchange-Verwaltungskonsole (EMC) hat sich seit Exchange Server 2007 stark verändert. In Exchange 2007 weist die Konsole relativ wenige Abhängigkeiten auf. In Exchange 2010 sieht es jedoch ganz anders aus. Jede EMC-Sitzung wird als Remotesitzung behandelt, auch wenn Sie die Konsole lokal auf einem Exchange 2010-Server öffnen. Wenn die Konsole keine Verbindung zum “Remote” Exchange-Server herstellen kann, wird wahrscheinlich eine Fehlermeldung angezeigt (Abbildung 1).
Verbindungsfehler führen häufig zu einem Ausfall der EMV.
Abbildung 1. Verbindungsfehler führen häufig zum Ausfall der Exchange-Verwaltungskonsole.
Die EMV ist im Wesentlichen ein grafisches Frontend für die Exchange Management Shell (EMS), die auf PowerShell basiert. Wenn Sie die EMV öffnen, öffnet die Konsole daher eine Remote-PowerShell-Verbindung. In diesem Fall wirken drei Hauptmechanismen: Internetinformationsdienste (IIS), WinRM und Web Services for Management (WS-Management).
Um Probleme wie das oben beschriebene zu lösen, überprüfen Sie zunächst, ob die Standardwebsite ist auf allen Ihren Exchange-Servern verfügbar. Der in Abbildung 1 gezeigte Fehler wurde ausgelöst, als ich den IIS-Manager öffnete und den auswählte Standardwebsite und geklickt Halt.
Das Stoppen der Standardwebsite kann zwar einen EMV-Fehler auslösen, die Konsole kann jedoch auch fehlschlagen, wenn die Standardwebsite ausgeführt wird. Wenn irgendetwas den Zugriff auf die Standardwebsite verhindert, hat dies die gleichen Auswirkungen auf die EMC wie das Stoppen der Site.
Damit die EMC eine Remote-PowerShell-Sitzung einrichten kann, WinRM muss in der Lage sein, über TCP-Port 80 mit IIS zu kommunizieren. Wenn sich auf oder vor Ihrem Exchange-Server eine Firewall befindet, die den HTTP-Verkehr blockiert, ist die Firewall möglicherweise die Ursache des Problems. Denken Sie daran, dass nicht nur Clientzugriffsserver HTTP-Verkehr empfangen können müssen. Alle Exchange 2010-Server müssen über TCP-Port 80 für WinRM zugänglich sein.

2. Probleme mit der Site-Umleitung

Die Standortumleitung ist eine weitere häufige Ursache für einen Fehler in der Exchange 2010-Verwaltungskonsole. Einige Administratoren versuchen, ihren Clientzugriffsserver (CAS) so zu konfigurieren, dass eingehende HTTP-Anforderungen automatisch in das virtuelle OWA-Verzeichnis umgeleitet werden.
Bei falscher Ausführung verhindert diese Art der Umleitung effektiv, dass der HTTP-Verkehr die Standardwebsite erreicht, was zu einem EMV-Fehler führt. Das Erzwingen der Umleitung des HTTP-Datenverkehrs auf Ihren Clientzugriffsservern kann sich auch auf ActiveSync und Outlook Anywhere auswirken.

3. Authentifizierungsprobleme

Die EMV kann auch aufgrund eines Authentifizierungsfehlers ausfallen. Wenn eine Remote-PowerShell-Sitzung eingerichtet wird, wird IIS verwendet Kerberos um die Verbindung zu authentifizieren. So seltsam es auch scheinen mag, Kerberos funktioniert nur dann ordnungsgemäß, wenn das virtuelle PowerShell-Verzeichnis es als natives Modul behandelt.
Um dies zu testen, rufen Sie den IIS-Manager auf und navigieren Sie zu Websites -> Standardwebsite -> PowerShell. Doppelklicken Sie anschließend auf Module Scrollen Sie dann durch die Liste der Module, bis Sie suchen KERBAUTH. Dieses Modul sollte auf zeigen C: Programme Microsoft Exchange Server Bin und es sollte als aufgeführt werden Einheimisch Modul (Abbildung 2).
Das Kerberos-Authentifizierungsmodul muss als Native aufgeführt sein.
Abbildung 2. Das Kerberos-Authentifizierungsmodul muss als Native aufgeführt sein.
Wenn das Kerberos-Authentifizierungsmodul als aufgeführt ist Gelang es Modul eher als ein Einheimisch Modul, weil das Modul direkt von der Standardwebsite verwendet wird. Wenn Sie die auswählen Virtuelles Standardverzeichnis Container und doppelklicken Sie auf Module Symbol sollten Sie nicht siehe KERBAUTH aufgelistet.
Wenn das Modul ist In der Liste müssen Sie festlegen, für welche virtuellen Verzeichnisse das Modul erforderlich ist. Anschließend müssen Sie das Modul von der Standardwebsite entfernen und direkt auf die virtuellen Verzeichnisse anwenden, für die es erforderlich ist. Exchange 2010 fügt automatisch das hinzu Kerberos-Authentifizierung Modul zu den virtuellen Verzeichnissen, wo erforderlich. Daher sollte dieses spezielle Problem nur auftreten, wenn der Server eine Nicht-Exchange-Website hostet, die die Kerberos-Authentifizierung verwendet.
Wie Sie sehen, gibt es eine Reihe möglicher Ursachen für einen EMV-Fehler. Wenn keine der von mir beschriebenen Techniken das Problem behebt, überprüfen Sie die Bindungen für die Standardwebsite, um sicherzustellen, dass die HTTP-Bindungen nicht entfernt wurden. Die EMV kann nicht funktionieren, wenn IIS nur Bindungen für HTTPS (SSL) enthält.
ÜBER DEN AUTOR: Brien Posey ist ein achtmaliger Microsoft MVP mit zwei Jahrzehnten IT-Erfahrung. Bevor er freiberuflicher technischer Redakteur wurde, arbeitete Brien als CIO in einer nationalen Kette von Krankenhäusern und Gesundheitseinrichtungen. Er war auch als Netzwerkadministrator für einige der größten Versicherungsunternehmen des Landes und für das Verteidigungsministerium in Fort Knox tätig.

Similar Posts

Leave a Reply