All posts by Gregor Reimling

Exchange 2010 – OWA Fehler Timeout

Nachdem die Grundkonfiguration abgeschlossen ist, wurde der erste Anmeldeversuch über OWA an den Server versucht, leider ohne Erfolg. Folgende Fehlermeldung erscheint:

OWA version: 14.0.639.21

Exception
Exception type: Microsoft.Exchange.Data.Storage.ReadTopologyTimeoutException

Nach einiger Recherche habe ich den Tipp gefunden, die AD-Site-Topolgy im Hinblick auf doppelte oder sich überschneidende IP-Subnetze überprüfen und ggf. bereinigen. Was die AD-Site-Topolgy angeht, ist der Exchange 2010 hier sehr empfindlich.

Nachdem ich die Bereinigung durchgeführt habe, verlief ein erneuter Test mit Zugriff auf OWA problemlos. (siehe auch http://social.technet.microsoft.com/Forums/en/exchange2010/thread/fcae38b3-655a-409d-8dc3-506fce0256a4)
Exception message: The process failed to read the Exchange topology in the allotted time

Exchange 2010 – IIS Fehlermeldung Verwaltungskonsole

Beim öffnen der Verwaltungskonsole auf dem Exchange 2010 kam es unter dem Punkt Serverkonfiguration -> ClientAccess zur folgenden Fehlermeldung:

Microsoft.Exchange.Management.Metabase.IISGeneralCOMException:

Um den Fehler zu bereinigen muss die Gruppe Exchange 2010 “Exchange Trusted Subsystem” Lokale Administratorenrechte auf allen Exchange Servern innerhalb der Organisation haben. Ob dieser Fehler mit einer anderen Lösung zu bereinigen ist, habe ich derzeit noch nicht in Erfahrung bringen können.

Exchange 2010 – Erstkonfiguration

Zunächst wurde dem Hubtransport-Server unter der Verwaltungskonsole erlaubt, anonyme Verbindungen anzunehmen um sicherzustellen, dass Mails von unbekannten Absendern akzeptiert werden. Nächster Schritt war die Aufnahme des E2010 in den vorhanden Sendeconnector von E2007. Danach wurde ein Postfach auf den neuen Exchange Server verschoben. Weitere Konfigurationsschritte folgen.

Exchange 2007 – Zertifikat anfordern

  1. Management-Shell Exchange als Administrator öffnen
  2. New-ExchangeCertificate -GenerateRequest -SubjectName “c=DE, o=domain, cn=oldmail.domain.de” -DomainName oldmail.domain.de, owa,servername, server.domain.de, autodiscover.domain.de, autodiscover.domain.de, -IncludeAutodiscover -PrivateKeyExportable $true -Path c:newe2007cert.req
  3. Die Anforderung an die Zertifizierungsstelle einsenden
  4. Das signierte Zertifikat als Base64-Datei speichern
  5. Zertifikat importieren Import-ExchangeCertificate -Path c:newe2007certsigniert.cer
  6. Zertifikat einschalten Enable-ExchangeCertificate
    -Thumbprint <fingerabdruck des Zertifikats>
    -Services SMTP,IMAP,POP,UM,IIS
  7. Dienste mit dem Zertifikat verknüpfen und aktivieren Enable-ExchangeCertificate
    -Thumbprint <fingerabdruck des Zertifikats>
    -Services SMTP,IMAP,POP,UM,IIS

Somit die Zeritifkatsanforderung und Aktivierung abgeschlossen, dass Zertifikat ist ab sofort auf den angewendeten Services gültig

Exchange 2007 Migration zu Exchange 2010

Nachdem der neue Mail-Server aufgesetzt wurde, sind heute einige Vorbereitungen zur Migration getroffen worden.

1. Die OWA-Url von Exchange 2007 wurde auf oldmail.domain.de geändert und ein neues Zertifikat dafür ausgestellt mit dem Befehl New-ExchangeCertificate -GenerateRequest -SubjectName “c=DE, o=domain, cn=oldmail.domain.de” -DomainName oldmail.domain, owa, mailserver, mailserver.domain.de, autodiscover.domain.de, autodiscover.domain.de,  -PrivateKeyExportable $true -Path c:newe2007cert.req generiert.

2. Nachdem die Anforderung von der Zertifizierungsstelle genehmigt wurde, ist das Zertifikat mit import-exchangecertificate eingefügt und auf die Standarddienste zugelassen.

Somit ist gewährleistet, dass User deren Postfach noch auf dem alten Server laufen, dennoch auf Ihre Mails über OWA zugreifen können. Der nächste Schritt ist die Installaton von Exchange 2010. Aufgrund der kleinen Umgebung und der geringen Auslastung habe ich mich dazu entschieden, alle Rollen auf einem Server zu installieren.

Hier nun einige Screenshots von der Installation:

Installationsauswahl Exchange Setup

Nachdem die Installationsschritte durchgeführt wurden, werden die Vorrausetzungen geprüft. Dabei traten einige Fehler auf, siehe folgendes Bild.

Exchange 2010 Abschliessende Überprüfung
Exchange 2010 Abschliessende Überprüfung

Hauptsächlicher Kritikpunkt war das Fehlen des Microsoft Filter Pack, welches anschließend nach installiert wurde. Außerdem musste der Startmodus von “NetTcpPortSharing” auf Automatisch gesetzt werden.

Nachdem diese Konfigurationseinstellung vorgenommen wurde, sah die erneute Prüfung nun ok aus und alle Konfigruationseinstellungen wurden übernommen und installiert. Wenn das Setup erfolgreich abgeschlossen wird, schau das ganze folgedermaßen auch

E2010 Erfolgreiche Installation

1. Start der Exchange Verwaltungskonsole

Exchange 2010 Verwaltungskonsole

Dies war der Abschluss der Installation des Exchange 2010. Nun müssen die Konfigurationseinstellungen vorgenommen werden, unter anderem muss außerdem der Forefront Security for Exchange installiert, die Postfächer verschoben und die Zertifikate geprüft werden.

DHCP IPv6 Adressraum eingerichtet

Um die Diagnose der fehlerhaften DA-Konnektivität weiter einzuschränken und als Ursache die Link-Localen IPv6 Adressen fc80 auszuschließen wurde ein neuer IP-Adressbereich im DHCP eingerichtet.

Dieser verteilt nun aus dem Unique Local Unicast fd IP-Adressen:

DHCP Konfiguration IPv6 Adressraum

Um einen privaten Adressbereich zu erstellen, habe die Site http://www.simpledns.com/private-ipv6.aspx aufgerufen, auf der, nach jeder Aktualisierung ein anderer, zufallsbasierte IPv6 Bereich angezeigt wird.

Bei meinem Aufruf sah das ganze so aus:

Direct Access – Fehlerdiagnose

Die Funktionalität Direct Access ist für unser Firmennetz leider noch nicht realisiert.

Die Konfiguration erfolgte nach dem Step-by-Step Guide vom 18.10.09. Bei Überprüfung der Konfiguration wurde leider festgestellt, dass der Client zwar erkennt, dass er sich ausserhalb des Domänennetzwerks befindet, aber keine Verbindung dorthin aufbauen kann.

Zur Rate wurde der Direct-Access-Troubleshoot-Guide gezogen, mit diesem konnte der Fehler, vermutlich, auf fehlende IPv6Adressen im Domänennetzwerk eingegrenzt werden, allerdings lässt sich derzeit nicht erkennen, warum die Server (Basis 2008) keine 6to4-Adressen haben.

Zunächst wurde der Host überprüft und die IPv6-Unterstützung auf diesem aktiviert und konfiguriert, ohne Erfolg.

Auf dem Client lässt sich in der Firewal auch keine IPSec-Richtlinie erkennen. Ob die Verbindung zwischen Client und Server auf IP-Basis nicht zustande kommt oder wegen fehlender DNS-Auflösung ist nicht nachvollziehen. Im internen Netzwerk erreicht der DA-Server die DNS-Server nicht über die 6to4-Adresse.

Derzeit ist der Fehler nicht nachvollziehbar und Bedarf wohl doch noch einiger Zeit.

VMware VM – Partition verkleinern mit robocopy

Aufgrund einer Fehlkonfiguration wurde dem Exchange Server zuviel Speicherplatz zugewiesen. Um diesen Fehler zu bereinigen und nur den notwendigen Speicherplatz zur Verfügung zu stellen wurde die Partition verkleinert.

Für mich, hat sich als schnellster und elegantester Weg der mit robocopy dargestellt.

  1. Weitere Partition mit der benötigen Größe anlegen
  2. Den Exchange Server abschalten
  3. Booten von der Server 2008 CD
  4. Computerreparaturoptionen
  5. mit diskpart die partition erstellen und formatieren
  6. danach robocopy quelle (D:) ziele (F:) /Mir /copyall (Mir bewirkt eine Spiegelung und copyall kopiert die Sicherheitsberechtigungen mit)
  7. danach alte partition über den vsphere client aus der VM-Konfiguration löschen
  8. vmdk. editieren und gleichen Namen der vorherigen Partition eingeben
  9. Mit VSphere Client Partition importieren
  10. VM neustarten und Eventlogs auf mögliche Fehler überprüfen

Bei mir hat der Vorgang einwandfrei geklappt und es kam zu keinen Fehlern im Betrieb. Die alte Partition werde ich noch ein paar Tage erhalten, bevor diese endgültig gelöscht wird.

NTP-Konfiguration

Aufgrund eines Exchange-Fehlers (Zugriff auf die Postfächer war, nach Anmeldung, nicht möglich) wurde festgestellt, dass die Zeit der Server asynchron zueinander sind. Um diesen Fehler in den Griff zu bekommen und nich einfach nur eine Bereinigung durchzuführen, wurde die NTP-Konfiguration überarbeitet.

Die Server F1NaLWEB1 und F1NaLWDA1 synchronisieren mit der Zeitquelle 0.de.pool.ntp.org, 1.de.pool.ntp.org & 2.de.pool.ntp.org, konfiguriert nach dem Artikel http://support.microsoft.com/kb/816042/de. Der WDC1 wiederum synchronisiert mit den beiden genannten Servern. Die restlichen Server empfangen Ihre Zeit vom DC.

Nachdem auf allen Server der W32Time Dienst neugestartet wurde, liefen die Server wieder synchron. Um ein Zugriff auf die Mailpostfächer zu ermöglichen, mussten allerdings noch der Microsoft Exchange-Informationsspeicher und Microsoft Exchange Active Directory-Topologiedienst gestartet werden.

NTP-Konfiguration

Server-Migration auf 64Bit

Aufgrund der Anforderungen von Exchange und Sharepoint 2010 nach einer homogenen Architektur wird die Serverlandschaft sukzessive auf 64Bit angehoben. Zunächst wurde der SQL-Server neu aufgesetzt, siehe vorherigen Post. Dabei wurde Server 2008 64Bit und SQL Server 2008 64Bit installiert. Bei der Konfiguration muss den SQL-Tools allerdings mitgeteilt werden, dass diese jetzt auf einer 64Bit Plattform laufen.