Exchange Fragen & Antworten: Erfolg der DAGs

  • Artikel

Eine gute Idee, Verwendung von Datenbank-Verfügbarkeit Gruppen ist, insbesondere, da Sie kopieren und an mehreren Speicherorten zu speichern, aber die Probleme bei der Adressierung mind.

Henrik Walther

Adressierung Conundrum

Frage: Wir Exchange 2010 bereitgestellt und alle Postfachserver hoch verfügbare Datenbank Verfügbarkeit Gruppen (DAGs) vorgenommen. Dinge sind in guter Form, und alles funktioniert wie erwartet, außer eine kleinere Details.

Wenn eine Person, die eine von einem Mitarbeiter mit einem Postfach befindet sich in einem DAG gesendete Nachricht empfängt, sendet wiederum eine andere Nachricht an einen Mitarbeiter oder einen Empfänger in einer anderen Organisation, der Internet-Nachrichtenkopfzeile von der empfangenen Nachricht zeigt, dass der Postfachserver über eine APIPA-Adresse z. B. 169.254.5.133 konfiguriert wurde. Wir verwenden statische IP-Adressen für alle unsere 2010 Exchange Server so, dass wir nicht verstehen, warum es als eine APIPA-Adresse angezeigt wird (siehe Abbildung 1 ). Können Sie uns enlighten?

A: Hierbei handelt es sich um eine interessante Frage. Die sehr kurze Antwort darauf lautet, dass es nur auftritt, wenn Exchange 2010 Postfachserver vorgenommen wurden ein oder mehrere DAGs mit hoher Verfügbarkeit und DAG-Funktionalität auf der Windows-Failover-Cluster (WFC)-Komponente basiert. Dieses Verhalten mit Postfachservern, die nicht Teil einer DAG nicht angezeigt werden.

Let’s näher an was geschieht hier. Die WFC-Komponente in Windows Server 2008 R2 erwartet, dass Anwendungen, die WFC – wie z. B. SQL, Exchange und Dateiserver – um Clusterressourcen in einer bestimmten Weise zu suchen. Die Anwendung sollte Auffinden der richtigen Informationen über einen DNS-Server eine Verbindung zu einer Clusterressource herstellen.

Dies wird als ein (Client Access Point, CAP) bezeichnet. Ein CAP besteht aus einem NetBIOS-Namen und IP-Adressressourcen. In Windows Server 2008 R2 Wenn der Server dynamische Updates unterstützt, ist die CAP-Informationen im DNS registriert nach der Clientzugriffspunkt in den WFC online geschaltet wird.

Leider sind Anwendungen, die den DNS-Schritt überspringen und direkt an einen Clusterknoten mit den ersten Netzwerkadapter in der Liste Datenbindung stattdessen eine Verbindung herstellen. Standardmäßig ist der erste Netzwerkadapter, die Liste der Bindung aus Microsoft Failover Cluster virtuelle Adapter (siehe Abbildung 2 ). Dieser Adapter wird mit eine APIPA-Adresse konfiguriert.

Figure 1 An APIPA address in an Internet header

Abbildung 1 eine APIPA-Adresse in einem Internet-Header

Figure 2 The Microsoft Failover Cluster Virtual Adapter

Abbildung 2 Der Microsoft-Failovercluster virtuelle Adapter

Also zu erraten, welche Anwendung nicht DNS verwendet, zu suchen und eine Ressource im Cluster verbinden? Schon erraten: Exchange-2010 (und auch Exchange 2007).

Wie können wir diese kleines Ärgernis beheben? Glücklicherweise ist dies einfach mit Hilfe des ein kleines Tool bekannt als Nvspbind, die Sie herunterladen können, von der MSDN Code Gallery: Code.msdn.Microsoft.com/nvspbind. Nvspbind wurde speziell für das Ändern von Netzwerkbindungen in einer Befehlszeile entwickelt.

Überprüfen Sie die Bindungsreihenfolge der Adapter auf dem Server Let’s. Führen Sie nvspbind.exe/o Ms_tcpip. Wie Sie sehen können, in Abbildung 3 ist Local Area Connection * 9 (die Microsoft Failover Cluster virtuelle Adapter entspricht) zuerst aufgeführt.

Figure 3 Viewing a binding order list using nvspbind

Abbildung 3 Anzeigen einer Bestellung Bindungsliste Nvspbind mithilfe von

Als Nächstes müssen wir Local Area Connection * 9 der Liste nach unten zu verschieben. Führen Sie den folgenden Befehl aus:

nvspbind.exe /- “Local Area Connection* 9” ms_tcpip

Figure 4 Moving Local Area Connection* 9 down the binding order list

Abbildung 4 Verschieben Local Area Connection * 9 unten Reihenfolge Bindung

Wie Sie sehen können, in Abbildung 4 wurde Local Area Connection * 9 der Bindung Reihenfolge Liste nach unten verschoben. Versuchen Sie nun eine neue e-Mail-Nachricht senden. Der Internet-Header sollte nun die tatsächliche IP-Adresse des Servers angezeigt (siehe Abbildung 5 ).

Figure 5 An Internet header showing the real IP address of the mailbox server

Abbildung 5 An Internet-Header mit die wahren IP-Adresse des Postfachservers ein

Manuelle Kopien

Frage: Wir einfach wird die 2010 von Exchange-Servern bereitgestellt. Wir beabsichtigen, DAGs zu verwenden, um unsere Postfachdatenbanken hoch verfügbar zu machen. Wir Planen für acht Kopien jedes Postfachdatenbank. Jede Postfachdatenbank haben Kopien auf drei physischen Standorten. Für Datenbanken von ca. 500 GB pro wir. Wegen eingeschränkter Bandbreite zu einem physischen Standorten erwarten wir eine Zeit lang Ausgangswerten. Daher sind stattdessen wir Fragen Wenn wir irgendwie manuell die Datenbankdateien an einen Remotestandort mit einem USB-Laufwerk kopieren können?

A: Ja, können Sie es auf diese Weise als auch mit einer unterstützten Methode. Eine Offlinedatenbank manuell kopieren möchten, deaktivieren Sie die Umlaufprotokollierung für die entsprechenden Datenbanken. Zu diesem Zweck ausgeführt:

Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $false

Dann Aufheben der Bereitstellung von Datenbanken verwenden:

Dismount-Database MDB01 -Confirm $false

Kopieren Sie die Datenbank und alle Protokolldateien an einem zweiten Ort, z. B. ein USB-Laufwerk.

Klicken Sie nach Abschluss des Kopiervorgangs Bereitstellen der aktiven Datenbank kopieren erneut mit:

Mount-Database MDB01

Verbinden Sie nun die USB-Speicher auf dem Server, der host für der Datenbank, und kopieren Sie die Datenbank-und Protokolldateien auf den gleichen Pfad wie die auf dem Quellserver an, von dem die Dateien kopiert wurden.

Fügen Sie nun die Datenbankkopie, die mithilfe der Add-MailboxDatabaseCopy - SeedingPostponed-Parameter. Der eigentlichen Befehl würde wie folgt aussehen:

Add-MailboxDatabaseCopy -Identity MDB01 -MailboxServer E2K10EX04–SeedingPostponed

Beachten Sie, dass es ist kein Ausgangswert Prozess, da die EDB-Datei und die zugehörigen Protokolldateien bereits vorhanden sind. Schließlich aktivieren Sie Umlaufprotokollierung erneut verwenden:

Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $true

Reisende

Frage: Wir sind Exchange 2010 ausgeführt und haben wir viele “ Reisende ” stark von der Outlook Web-Anwendung oder OWA (was verwendet Outlook Web Access aufgerufen werden) abhängig sind. Diese Benutzer können nicht auf OWA anmelden, wenn Ihr Kennwort abgelaufen ist. Wir haben auch gefunden, neue Mitarbeiter, für den das-Konto auf “ Benutzer Kennwort bei der nächsten Anmeldung ändern muss ” gesetzt wurde, wenn das Benutzerkonto, das zuerst erstellt wird (siehe Abbildung 6 ), können sich anmelden auf OWA Zugreifen, bevor Sie das Kennwort mithilfe anderer Mechanismen ändern.

Figure 6 User must change password at next logon enabled

Abbildung 6 Benutzer muss Kennwort bei der nächsten Anmeldung aktiviert ändern

Wir haben mit diesem Ärgernis Leben worden, da wir von Lotus Domino zu Exchange 2003 vor vielen Jahren verschoben. Wissen Sie, wie wir dies beheben können?

A: Gute Zeitmessung für diese Frage. Beginn des Exchange-Teams sowie Exchange 2010 SP1 in SP3 für Exchange 2007 planen Sie beschlossen, den Mangel zu beheben melden Sie sich bei OWA, wenn das Kennwort eines Benutzers abgelaufen ist oder das Benutzerkonto festgelegt wurde, um Benutzer muss Kennwort bei der nächsten Anmeldung ändern. Diese waren mit OWA Password Reset Tool. Hierbei handelt es sich um ein IIS 7-Modul, das erkennt abgelaufenen Kennwörter und Benutzer zu einer Änderung brandneue Kennwort Seite umgeleitet.

Figure 7 The Outlook Web App 2010 forms-based authentication logon page

Abbildung 7 The Outlook Web App 2010 formularbasierte Authentifizierung Anmeldeseite

Let’s finden in Aktion dürfen wir? Der Benutzer versucht, sich bei OWA 2007 anmelden oder 2010 mithilfe der Anmeldeseite formularbasierte Authentifizierung (FBA) wie in Abbildung 7 . Der Benutzer wird nun zum neuen Kennwort ändern, im angezeigten Seite Abbildung 8 umgeleitet. Er benötigen, geben Sie das aktuelle Kennwort als auch ein neues, und klicken Sie dann auf die Schaltfläche Absenden.

Figure 8 The Outlook Web App 2010 Change Password page

Abbildung 8 The Outlook Web App 2010 Kennwortänderung Seite

Nun wird das Kennwort geändert, und der Benutzer kann sich mit dem neuen Kennwort anmelden. Einfacher und benutzerfreundlicher, WAHR?

Bedenken Sie, dass die Kennwortänderung Seite nach der Installation von SP3 für Exchange 2007 oder Exchange 2010 SP1 standardmäßig aktiviert ist nicht. Sie müssen dies für einen Registrierungsschlüssel aktivieren. Genauer gesagt, müssen Sie für jeden Exchange 2007 oder Exchange 2010 Client Access Server (CAS) melden, und starten den Registrierungs-Editor.

Navigieren Sie im Registrierungs-Editor zu: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA. Hier müssen Sie einen neuen REG_DWORD-Schlüssel mit dem Namen ChangeExpiredPasswordEnabled erstellen. Aktivieren Sie diese durch den Datenwert auf “ 1 ” festlegen, wie in der Abbildung 9 .

Figure 9 The registry key required to enable Change Password for OWA

Abbildung 9 die Registrierungsschlüssel zum Aktivieren von OWA-Kennwortänderung erforderlich

Jetzt können der Reisende melden OWA, unabhängig davon, ob Ihr Kennwort ist abgelaufen, oder geändert werden muss.

_**Henrik Walther*****ist ein Microsoft Certified Master: Exchange 2007 und Exchange-MVP mit mehr als 15 Jahren Erfahrung im IT-Bereich. Er arbeitet als eine Technologie Architekt ForTimengoConsulting (ein Microsoft Gold Certified Partner in Dänemark) und als Autor technischer Artikel für Biblioso Corporation.(US-Unternehmen, der spezialisiert ist verwaltete Dokumentations-und Lokalisierungsdienste).V-henwal@microsoft.com-können Sie Walther e-mail. * _

Verwandter Inhalt