(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren

Die drei häufigsten Konfigurationsprobleme beim Exchange Management Pack

 

Letztes Änderungsdatum des Themas: 2005-08-19

Mit dem Exchange Server 2003 Management Pack können Sie die Leistung, Verfügbarkeit und Sicherheit von Microsoft® Exchange Server 2003 überwachen. Bei Ereignissen mit direkter Auswirkung auf die Serververfügbarkeit werden Warnmeldungen ausgegeben. Ereignisse, die keine Maßnahmen erfordern, werden gefiltert. Nach dem Importieren des Exchange Management Packs beginnt die Überwachung der Server mit Exchange in der Umgebung. Allerdings müssen bestimmte Skripts konfiguriert werden. Möglicherweise werden während der Konfiguration Fehler ausgegeben, von denen Sie nicht wissen, wie sie zu beheben sind. In diesem Artikel werden drei der am häufigsten auftretenden Konfigurationsprobleme beschrieben, deretwegen Microsoft-Kunden uns um Unterstützung bitten. Bevor wir jedoch zu den eigentlichen Problemen kommen, sehen wir uns an, wie ein Server mit Exchange für die Überwachung vorbereitet wird.

Bei der Bereitstellung des Exchange Management Packs werden die meisten Konfigurationsaufgaben automatisch von Microsoft Operations Manager (MOM) ausgeführt. MOM ermittelt im Hintergrund die Server mit Exchange in der Umgebung und überträgt die im Management Pack enthaltenen Regeln mithilfe von Push auf diese Server. Durch einige dieser Regeln wird die aktuelle Konfiguration des Servers auf bestimmte Attribute überprüft. Möglicherweise werden auch weitere Regeln aufgerufen, um die Änderungen vorzunehmen, die zur Vorbereitung des Servers für die Überwachung erforderlich sind. Sobald die Ausführung der Regeln beginnt, werden in der MOM-Verwaltungskonsole Ereignisse angezeigt, an denen der laufende Prozess abzulesen ist. Später werden weitere Ereignisse angezeigt, in denen Sie aufgefordert werden, die erforderlichen Schritte zum Abschluss der von MOM begonnenen Konfiguration auszuführen.

Zu diesem Zeitpunkt führen Sie den Konfigurations-Assistenten des Exchange Management Packs aus, der Sie bei den abschließenden Konfigurationsänderungen unterstützt, die erforderlich sind, damit MOM die Exchange-Funktionalität wie Postfachverfügbarkeit, Nachrichtenübermittlung oder Dienste uneingeschränkt überwachen kann. Es kann leider auch vorkommen, dass Sie den Assistenten nicht ausführen können, weil bei der von MOM durchgeführten Vorbereitung ein Fehler aufgetreten ist.

Ein Problem, das uns beim Support für das Exchange Management Pack gelegentlich begegnet, besteht darin, dass die Konfiguration für die Überwachung eines Servers mit Exchange nicht abgeschlossen werden kann. Dieses Problem kann darauf zurückzuführen sein, dass Daten, die normalerweise bei der Bereitstellung des Management Packs automatisch veröffentlicht werden, fehlen. Im Folgenden wird erläutert, warum es dazu kommt und worauf Sie achten müssen, wenn dieses Problem auftritt.

Im Konfigurations-Assistenten wird möglicherweise folgender Fehler angezeigt:

Fehler: Das Postfachzugriffskonto auf dem Computer <Servername> kann nicht konfiguriert werden. Diese Konfiguration kann erst erfolgen, nachdem das Exchange-MOM-Ereignis 9986 von MOM registriert wurde.

Im Folgenden wird das Ereignis 9986 erläutert und beschrieben, wann es auftreten sollte. Außerdem werden einige Gründe angeführt, warum es möglicherweise nicht auftritt. Eine der ersten auf einem Exchange-Back-End-Server ausgelösten Regeln ist der Test der Postfachverfügbarkeit. Durch das dieser Regel zugeordnete Skript wird überprüft, ob die Registrierungsdaten vorhanden sind, durch die dieser Test möglich wird. Im Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExMPLS werden die verschlüsselten Anmeldeinformationen des Domänenkontos gespeichert, das für den Zugriff auf Postfächer für die Überwachung auf jedem Server mit Exchange verwendet wird. Dieses Postfachzugriffskonto (Mailbox Access Account, MAA) muss über die Berechtigung zum Anmelden bei den Testpostfächern verfügen, da MOM bei der Anmeldung die Anmeldeinformationen dieses Kontos verwendet, also seine Identität annimmt. Wenn die Registrierungsdaten fehlen, wird durch diese Regel ein Ereignis generiert, das eine weitere Regel auslöst. Diese bewirkt die Veröffentlichung des fehlenden Schlüssels zum Speichern der Anmeldeinformationen.

Zum Veröffentlichen des Schlüssels benötigen Exchange-Server "Helfer" in Form von DCOM-Objekten (Distributed COM, verteiltes COM), die als Ergänzung zu den Veröffentlichungsregeln installiert werden. Das DCOM-Objekt für die Veröffentlichung des Registrierungsschlüssels, in dem die Anmeldeinformationen des Postfachzugriffskontos gespeichert werden, wird im Rahmen des Exchange Server 2003-Setups installiert. Für frühere Versionen von Exchange installiert MOM die Hilfsobjekte nach Bedarf, sie können jedoch auch manuell installiert werden. Die Veröffentlichungsregel ruft das DCOM-Objekt auf, um die erforderlichen Daten auf dem Server zu veröffentlichen.

Wenn sich DCOM und das Hilfsobjekt wie erwartet verhalten, wird der Registrierungsschlüssel ExMPLS erstellt. Beim Veröffentlichen der Daten wird das Ereignis 9986 generiert, und der Konfigurations-Assistent sollte für den Server ausgeführt werden können. Der Assistent schreibt dann die Anmeldeinformationen des Postfachzugriffskontos in verschlüsselter Form in den Registrierungsschlüssel. Sie müssen auch keine Bedenken haben, Sie könnten das Ereignis übersehen, denn es gibt eine Regel, die täglich zur Überprüfung ausgeführt wird und das Ereignis 9986 generiert, wenn die Daten bereits erfolgreich veröffentlicht wurden.

Wenn die Veröffentlichung fehlschlägt, werden durch die Regel Ereignisse generiert, die in der MOM-Verwaltungskonsole angezeigt werden, um den Administrator auf den Fehler aufmerksam zu machen. Fehler können durch fehlende oder fehlerhafte DCOM-Objekte oder durch falsch konfigurierte DCOM-Berechtigungen verursacht werden. Bei fehlenden oder fehlerhaften DCOM-Objekten, die als Teil des Exchange Management Packs installiert wurden, kann sich die Problembehandlung als schwierig erweisen. Falls das Ereignis 9986 in Ihrer Umgebung nicht generiert werden kann, wenden Sie sich an den Microsoft-Kundendienst. Weitere Informationen zum Untersuchen und Lösen von Problemen mit den Standardeinstellungen für DCOM-Berechtigungen finden Sie im Microsoft Knowledge Base-Artikel 274696, Da die Standardzugriffsberechtigungen in dem Dcomcnfg.exe-Tool geändert worden sind, funktionieren nicht Aktionen wie Such, dem Ziehen und Ablage.

Nachdem das Ereignis 9986 generiert wurde, können Sie den Konfigurations-Assistenten ausführen, um die Umgebung für die Überwachung von Exchange zu konfigurieren. Vom Konfigurations-Assistenten werden das Postfachzugriffskonto sowie die Testkonten und -postfächer (Agentkonten und -postfächer) erstellt. Diese Konten werden für das MAPI-Anmeldeskript und das OWA-Anmeldeskript zum Überwachen der Exchange-Server verwendet.

Das MAPI-Anmeldeüberprüfungsskript wird vom Exchange Management Pack ausgeführt, um zu überprüfen, ob der Postfachspeicher bereitgestellt ist und sich Microsoft Office Outlook®-Benutzer erfolgreich anmelden können. In diesem Skript werden die Anmeldeinformationen des Postfachzugriffskontos verwendet, um die Anmeldung auszuführen und das Testpostfach (ServernameMOM) zu öffnen. Auch bei den Skripts zum Überprüfen des Nachrichtenflusses wird die MAPI-Anmeldung zum Senden und Empfangen von Nachrichten verwendet. Die Anmeldung bei dem Server, auf dem Exchange ausgeführt wird, wird im Exchange-System-Manager im Abschnitt Anmeldungen im Ordner Postfachspeicher angezeigt. Dort sollte das Testpostfach angezeigt werden. Beachten Sie, dass das Postfachzugriffskonto das für die Anmeldung verwendete Microsoft Windows®-Konto ist.

Fehler im MAPI-Anmeldeskript gehören zu dem am häufigsten auftretenden Fehlern. Es können verschiedene Fehlermeldungen angezeigt werden, u. a. MAPI_E_NOT_FOUND, MAPI_E_LOGON_FAILED und MAPI_E_NOT_INITIALIZED. Weitere Informationen zu häufigen Ursachen für diese Fehlermeldungen finden Sie unter "Fehler bei Berechtigungen und beim Verzeichniszugriff" im Exchange Server Management Pack-Handbuch für MOM 2005.

Wenn MAPI-Anmeldefehler auftreten, führen Sie alle in diesem Abschnitt beschriebenen Schritte zur Problembehandlung aus, da die Probleme mehrere Gründe haben können und nach der Lösung eines Problems möglicherweise das eigentlich zugrunde liegende Problem erkennbar wird. Weitere Informationen zu MAPI-Fehlern finden Sie im Microsoft Knowledge Base-Artikel 238119, Liste der numerischen MAPI-Ergebniscodes.

Außerdem sollten Sie überprüfen, ob das Postfachzugriffskonto über volle Postfachrechte für das für den MAPI-Anmeldetest verwendete Postfach verfügt. Ob das Postfachzugriffskonto über die erforderliche Berechtigung verfügt, können Sie überprüfen, indem Sie Outlook als Postfachzugriffskonto öffnen. Öffnen Sie dann das Testpostfach. Wählen Sie dazu Datei, Öffnen, Ordner eines anderen Benutzers und anschließend das Testpostfach aus. Nun sollte der Posteingang des Testkontos angezeigt werden. Falls Sie das Postfach nicht öffnen können, öffnen Sie Active Directory-Benutzer und -Computer, und überprüfen Sie die Eigenschaften des Testpostfachs. Klicken Sie auf Exchange – Erweitert, und klicken Sie dann auf Postfachberechtigungen. Dort sollte das Postfachzugriffskonto aufgeführt sein, und es sollte über die Berechtigungen Vollständiger Postfachzugriff, Postfachspeicher löschen und Lesen verfügen.

Sollten Sie weiterhin Probleme beim Öffnen des Testpostfachs haben, stellen Sie sicher, dass keines der von MOM verwendeten Postfächer (Postfachzugriffskonto und Testpostfächer) ausgeblendet ist. Wenn die Konten in der globalen Adressliste (GAL) ausgeblendet sind, können sie weder vom MAPI-Anmeldeskript noch von den Skripts zum Überprüfen des Nachrichtenflusses verwendet werden. Wenn die Konten nicht ausgeblendet sind, Sie sich jedoch trotzdem nicht bei Outlook anmelden können, ist es u. U. hilfreich zu ermitteln, wie die Konten erstellt wurden. Die Art und Weise, in der die Konten erstellt wurden, z. B. mithilfe des Konfigurations-Assistenten, manuell oder mithilfe eines Bereitstellungsprodukts eines Drittanbieters, gibt möglicherweise Aufschluss darüber, warum Sie sich nicht bei Outlook anmelden können.

Führen Sie als weiteren Test eine Windows-Anmeldung auf dem Server mit Exchange aus, und verwenden Sie dazu die Anmeldeinformationen des Postfachzugriffskontos. Öffnen Sie den Exchange-System-Manager, und erweitern Sie nacheinander Administrative Gruppen, Server und alle weiteren Knoten, bis Sie auf der linken Seite Postfächer auswählen können. Wird auf der rechten Seite die Liste der Postfächer angezeigt? Wenn die Liste nicht angezeigt wird, ist dem Postfachzugriffskonto möglicherweise die Berechtigung Status des Informationsspeichers anzeigen verweigert worden. Sie können die nachfolgend beschriebenen Schritte in der ADSI-Bearbeitung (ADSI Edit) ausführen, um einen Drilldown zu den Eigenschaften des Servers auszuführen. Klicken Sie auf die Registerkarte Sicherheit (siehe Schritt 10 weiter unten). Wählen Sie das Postfachzugriffskonto aus, und führen Sie in der Liste der Berechtigungen einen Bildlauf nach unten durch. Stellen Sie sicher, dass Status des Informationsspeichers anzeigen die Berechtigung Zulassen geerbt hat. Ist jedoch die geerbte Berechtigung Verweigern vorhanden, überprüfen Sie die Eigenschaften von CN=Servers, CN=Ihre administrative Gruppe und CN=Administrative Groups, um diese Berechtigung zu finden.

Führen Sie in der ADSI-Bearbeitung die folgenden Schritte aus, um nach der expliziten Verweigerung zu suchen:

  1. Öffnen Sie die ADSI-Bearbeitung.
  2. Klicken Sie im linken Bereich unter Konsolenstamm mit der rechten Maustaste auf ADSI-Bearbeitung.
  3. Wählen Sie Verbinden mit aus.
  4. Wählen Sie im Fenster Verbindungseinstellungen im Abschnitt Verbindungspunkt die Option Bekannten Namenskontext auswählen aus, und wählen Sie dann im Dropdownmenü den Eintrag Konfiguration aus. Klicken Sie auf OK.
  5. Klicken Sie im Fenster Konsolenstamm zum Erweitern auf das Pluszeichen neben Konfiguration.
  6. Klicken Sie zum Erweitern auf das Pluszeichen neben CN=Configuration, DC=.
  7. Erweitern Sie CN=Services.
  8. Erweitern Sie CN=Microsoft Exchange.
  9. Markieren Sie CN=<Name Ihrer Organisation>, und klicken Sie dann auf Eigenschaften.
  10. Klicken Sie auf die Registerkarte Sicherheit.
  11. Suchen Sie nach dem Postfachzugriffskonto, und stellen Sie sicher, dass dieses für Senden als oder Empfangen als nicht die Berechtigung Verweigern aufweist.

Stellen Sie in der ADSI-Bearbeitung auch sicher, dass Senden als und Empfangen als nicht auf der Ebene der administrativen Gruppe oder für den Exchange-Server verweigert wurden.

Probleme mit dem Active Directory®-Verzeichnisdienst können auch zu zeitweiligen Fehlern des MAPI-Anmeldeüberprüfungsskripts führen. Die MAPI-Anmeldung verursacht einen Fehler, wenn nicht auf einen Domänencontroller zugegriffen werden kann oder der Domänencontroller nicht rechtzeitig antwortet. Starten Sie den Exchange-Systemaufsichtsdienst, wenn dieser noch nicht gestartet wurde. Überprüfen Sie die Konfiguration für die Agentpostfächer, und korrigieren Sie ggf. Fehler in der Konfiguration. Vergewissern Sie sich, dass auf die Domänencontroller in der Domäne zugegriffen werden kann und Benutzer sich mithilfe von Outlook anmelden können.

Sie können zur Problembehandlung auch die Protokollierung auf dem Server mit Exchange aktivieren. Fügen Sie auf dem Server mit Exchange den folgenden Registrierungsschlüssel (vom Typ DWORD) hinzu, und legen Sie den Wert auf 1 fest:

\\HKLM\Software\Microsoft\Exchange MOM\DebugLS

noteAnmerkung:
Denken Sie daran, den Wert auf 0 festzulegen, wenn Sie die Protokollierung wieder deaktivieren möchten.

Beenden Sie den MOM-Dienst auf dem Server mit Exchange, und starten Sie ihn neu. Achten Sie darauf, dem Postfachzugriffskonto vollständige Rechte für %systemdrive% zu erteilen. Andernfalls werden keine aussagekräftigen Informationen in der Datei ExMPLS_LOG.txt protokolliert. Entziehen Sie die Rechte anschließend unbedingt wieder.

Warten Sie, bis das MAPI-Anmeldeüberprüfungsskript ausgeführt wird (über Nacht), und suchen Sie nach einer Datei namens ExMPLS_LOG.txt auf dem Laufwerk %systemdrive%. Diese Protokolldatei ist häufig nützlich für die Problembehandlung im Zusammenhang mit der MAPI-Anmeldung.

Sollten Sie nach der Ausführung der beschriebenen Schritte weiterhin Probleme mit der MAPI-Anmeldung haben, wenden Sie sich für die weitere Problembehandlung an Microsoft Customer Service and Support (CSS).

Ein weiteres Problem, mit dem unsere Kunden mitunter konfrontiert sind, betrifft die Anmeldeüberprüfungsskripts für Microsoft® Office Outlook® Web Access 2003 und Microsoft Outlook® Mobile Access. Im Exchange Management Pack werden mehrere Regelgruppen unter der Regelgruppe Überwachen von Verfügbarkeit und Status bereitgestellt, die Tests von synthetischen Anmeldungen umfasst. Durch diese Regelgruppen wird eine Postfachanmeldung mittels einer unserer Mobilitätstechnologien wie Outlook Web Access, Outlook Mobile Access oder Exchange ActiveSync simuliert. Aufgrund der Komplexität des synthetischen Anmeldevorgangs werden in MOM gelegentlich Fehler gemeldet, die auf eine fehlgeschlagene Anmeldung hindeuten, obwohl die Anmeldung bei Outlook Web Access mithilfe von Internet Explorer u. U. möglich ist. Ein häufig auftretender Fehler aus dieser Kategorie ist der folgende:

Description:

OWA Logon Failed.

URL:undefined

Cannot measure OWA availability. Unexpected error.

Auf diesem Server können keine virtuellen Exchange-Server und kein virtuelles Verzeichnis (SSL-aktiviert) gefunden werden, um eine gültige URL zu bilden. Versuchen Sie, die URL im Registrierungsschlüssel für benutzerdefinierte URLs anzugeben. (Detaillierte Anweisungen finden Sie im Konfigurationshandbuch.)

Auf den ersten Blick scheint es, als ob bei der Anmeldung der virtuelle Exchange-Server nicht gefunden werden konnte und die Anmeldung daher fehlgeschlagen ist. Allerdings wissen Sie, dass ein virtueller Exchange-Server vorhanden ist. Und Sie verwenden Outlook Web Access täglich, um Ihre E-Mails abzurufen, wenn Sie nicht im Büro sind. Also, was steckt wirklich hinter diesem Fehler? Der wichtige Hinweis im oben genannten Fehler ist die zurückgegebene URL, also Undefined. Damit Sie besser verstehen, was hier passiert, beschäftigen wir uns zunächst einmal damit, wie der synthetische Anmeldevorgang bei Outlook Web Access funktioniert.

Der Vorgang wird durch das Anmeldeüberprüfungsskript für Outlook Web Access eingeleitet. Das Skript umfasst zwar zahlreiche Tasks, seine wichtigsten Aufgaben sind jedoch die folgenden:

  • Es aktiviert einen Verweis auf das Automatisierungsobjekt OWAAvailability, das an objOwa zurückgegeben wird.
  • Es liest den folgenden Registrierungsschlüssel und ruft die Werte der Zeichenfolgen CustomURL und BEAccount ab: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange MOM\FEMonitoring\<Front-End-Servername>
  • Es übergibt den Postfachnamen und ggf. gefundene Werte für CustomURL an objOwa.OWALogon.
  • Es protokolliert die Ergebnisse (Erfolg oder Fehler) in der MOM-Operatorkonsole.

Für die Skriptfunktion OWALogon sind drei Parameter zulässig, nämlich BEMailbox für das Postfach, bei dem die Anmeldung ausgeführt werden soll, ein Timeoutwert und die URL. Die Funktion kann mehrfach aufgerufen werden, je nachdem, wie viele benutzerdefinierte URLs in der Registrierung gefunden werden. Der erste Aufruf erfolgt immer mit dem Wert NULL für die URL, womit letztlich https://localhost getestet wird. Die folgenden Aufrufe erfolgen in einer Schleife und dienen zum Testen der benutzerdefinierten URLs. An dieser Stelle ist der erste Aufruf mit der URL NULL von Interesse.

Die Skriptfunktion OWALogon ist für die Übergabe der empfangenen Argumente an das Automatisierungsobjekt objOwa.OWALogon zuständig, das die Routinearbeit übernimmt. Da nicht alle drei Argumente übergeben wurden (und der Wert für die URL NULL bleibt), muss objOwa.OWALogon als Erstes eine Methode aufrufen, durch die eine URL zum Testen erstellt wird. Diese Methode mit dem Namen GetExchangeURL gibt die URL des angegebenen Postfachs zurück. Wenn jedoch GetExchangeURL die URL des Postfachs nicht ermitteln kann, wird NULL zurückgegeben und somit der oben genannte unerwartete Fehler protokolliert.

Nachdem Sie nun wissen, warum der Fehler protokolliert wird, verstehen Sie auch, warum die Zeile URL:undefined ein wichtiger Hinweis war. Wie der Fehler besagt, konnte die URL nicht ermittelt werden, wodurch es zu dem Fehler kam. Nun ist es an der Zeit für eine eingehendere Betrachtung von GetExchangeURL.

Als wir uns diesen Code zum ersten Mal anschauten, waren wir schockiert angesichts all der Arbeit, die die Entwickler in diese Methode steckten. Eigentlich muss doch einfach nur https://localhost zurückgegeben werden, oder? Nun, pauschal lässt sich diese Frage nicht beantworten. Wie sieht es z. B. aus, wenn mehrere virtuelle Exchange-Verzeichnisse oder -Server vorhanden sind, die jeweils unter einer eigenen URL veröffentlicht wurden (Stichwort Hosting)? Wir müssen wissen, zu welchem virtuellen Server das Postfach gehört, um sicher sein zu können, dass die richtige URL getestet wird. Also können wir nichts voraussetzen, sondern müssen die richtige URL für das Testpostfach erstellen können. Eine detaillierte Beschreibung des gesamten GetExchangeURL-Vorgangs würde hier den Rahmen sprengen, allerdings sollen die wichtigsten Schritte kurz angesprochen werden.

  • Abrufen der primären SMTP-Adresse des Testpostfachs   Hierbei handelt es sich um eine einfache LDAP-Suche (Lightweight Directory Access Protocol) nach dem Testpostfach mit samAccountName. Anschließend wird das proxyaddress-Attribut gelesen und analysiert, um die mit SMTP: beginnende Adresse zu finden. (Beachten Sie die Großbuchstaben; nicht primäre Adressen werden in Kleinbuchstaben angegeben.) Dieser Wert wird anschließend analysiert, um den Domänennamen zu ermitteln. Führen Sie zum Testen dieses Schritts die folgende LDAP-Suche aus, und überprüfen Sie, ob das Testpostfach zurückgegeben wird:
    (&(objectClass=user)(objectCategory=person)(samAccountName=testmailbox))
  • Suchen nach dem virtuellen Verzeichnis   Weitere LDAP-Suchvorgänge. Diese werden nicht detailliert beschrieben, weil sie recht allgemein und uninteressant sind. Das Endergebnis ist eine Abfrage nach allen virtuellen HTTP-Servern auf dem Front-End-Server.
    (&(objectCategory=msExchProtocolCfgHTTPVirtualDirectory)(folderPathname=MBX))
  • Prüfen der SMTP-Domäne des virtuellen Verzeichnisses   Überprüfen Sie den virtuellen Server, um festzustellen, ob das msExchDefaultDomain-Attribut vorhanden und festgelegt ist (standardmäßig ist es nicht festgelegt). Wenn dies der Fall ist, überprüfen Sie, ob es der primären oder nicht primären SMTP-Domäne des Postfachs entspricht. Wenn msExchDefaultDomain nicht festgelegt ist, überprüfen Sie, ob die primäre SMTP-Adresse des Postfachs mit der primären SMTP-Domäne der Standardempfängerrichtlinie übereinstimmt. Beispiel: Wenn das Testpostfach durch eine benutzerdefinierte Richtlinie mit @it.contoso.com gekennzeichnet wurde, die Standardempfängerrichtlinie jedoch so konfiguriert ist, das mit @contoso.com gekennzeichnet wird, tritt ein Fehler auf.
    importantWichtig:
    In den meisten Fällen, die wir bei Microsoft CSS bearbeiten, ist dies die Ursache dafür, dass GetExchangeURL NULL zurückgibt.
  • Überprüfen, ob SSL für das virtuelle Verzeichnis aktiviert ist   Überprüfen Sie, ob die Metabase-Eigenschaft IIS://localhost/W3SVC/1/root/Exchange/AccessSSLFlags vorhanden ist. Diesen Wert können Sie mithilfe des Tools Metabase Explorer im Internet Information Services (IIS) Resource Kit überprüfen. Weitere Informationen zu diesem und anderen Tools im IIS Resource Kit finden Sie im Knowledge Base-Artikel 840671, Die IIS 6.0 Resource Kit Tools. Weitere Informationen zur AccessSSLFlags-Eigenschaft finden Sie unter AccessSSLFlags Metabase Property (IIS 6.0) im Abschnitt "IIS 6.0 Reference" des IIS 6.0 Operations Guide (in englischer Sprache).
  • Überprüfen des Werts von "secureBindings"   Rufen Sie die Metabase-Eigenschaft IIS://localhost/W3SVC/1/secureBindings ab, und analysieren Sie diese. Wenn die secureBindings-Eigenschaft mit :<portNumber> (:443) beginnt, ist der virtuelle Server auf Alle nicht zugewiesen festgelegt, sodass die URL dann auf https://localhost festgelegt wird. Wenn die Eigenschaft nicht mit einem Doppelpunkt (":") beginnt, lesen Sie die diesem Port zugewiesene IP- Adresse aus. Anschließend wird diese IP-Adresse mithilfe eines WMI-Aufrufs von Win32_NetworkAdapterConfiguration überprüft, und die zurückgegebene IPAddress-Eigenschaft wird mit der in der secureBindings-Eigenschaft enthaltenen IP-Adresse verglichen. Gibt es eine Übereinstimmung, legen Sie die URL auf https://ipaddress fest. Wenn keine Übereinstimmung gefunden wird, wird NULL zurückgegeben. Sie können hier wieder Metabase Explorer verwenden, um anzuzeigen, auf welchen Wert die Eigenschaft festgelegt ist. Wenn die Eigenschaft mit einer IP-Adresse beginnt, können Sie mithilfe von WBEMTest die Win32_NetworkAdapterConfiguration-Klasse abfragen und die IPAddress-Eigenschaft überprüfen. Weitere Informationen zur secureBindings-Eigenschaft finden Sie unter SecureBindings Metabase Property (IIS 6.0) im Abschnitt "IIS 6.0 Reference" des IIS 6.0 Operations Guide (in englischer Sprache). Weitere Informationen zur Verwendung von WBEMTest finden Sie unter Scripting Eye für den GUI Guy.

Wenn Sie die oben genannten Punkte überprüft haben, jedoch trotzdem nicht feststellen können, warum GetExchangeURL NULL zurückgegeben hat, bietet Microsoft CSS ein Tool namens OWACheck an, das bei der Behebung dieses Problems ausgesprochen hilfreich sein kann. Wenn Sie dieses Tool und weitere Unterstützung bei der Problembehandlung benötigen, wenden Sie sich an CSS.

Weitere Informationen hierzu finden Sie in den folgenden Ressourcen:

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft