Kategorie: Windows

  • Exchange 2010 Beta Test als Single Server Installation

    Dies ist ein kurzer Erfahrungsbericht/Anleitung, wie man die Betaversion von Exchange Server 2010 zu Hause (DSL-Router mit NAT) in einer virtuellen Testumgebung installiert und für den direkten Empfang und das direkte Senden von E-Mail konfiguriert.
    Natürlich sollte man solch eine Konfiguration nicht in einer Produktivumgebung einsetzen. Eine Veröffentlichung eines Exchange Servers im Internet sollte immer über einen ISA Server geschehen. Zumal es sich bei einem DSL-Anschluss in der Regel um dynamische IP-Adressen handelt. Selbst wenn man eine quasi statische IP-Adresse von Kabeldeutschland hat, verweigern viele Mailserver die Annahme von Mails, die von einem Server mit einer IP aus einem dynamischen Adresspool kommt. Aber hier geht es ja nur um einen Test der Beta Version von Exchange 2010 in einer Testumgebung.

    Im Netz bin ich über einen Bericht mit den Neuerungen im Exchange Server 2010 gestolpert. Dieser Bericht hat mich so neugierig gemacht, dass ich mir gleich zu Hause das ISO Image der 360 Tage Trial Version von Exchange 2010 heruntergeladen habe.
    Ein erster Versuch, die Vorabversion von Windows Server 2008 R2 für die Installation zu nehmen, schlug fehl. Aber auf einem aktuellen Windows Server 2008 lief die Installation relativ problemlos. Zuvor wurde noch eine Testdomäne auf einem weiteren Windows Server 2008 R2 aufgesetzt, die nötigen Rollen und Features, die Exchange 2010 voraussetzt, installiert und dann das Hauptsetup gestartet.

    Um Exchange 2010 richtig testen zu können, habe ich bei meinem Domainhoster für eine bisher nicht verwendete Domain einen neuen Hostrecord mit der IP-Adresse unseres DSL-Anschusses angelegt. Danach wurde noch ein MX Record erstellt, der auf den zuvor angelegten Hosteintrag zeigt.

    Um Exchange mitzuteilen, für welche Domains Exchange zuständig ist, wurde in der Exchange Mangement Konsole unter den Organisationseinstellungen,  Hub Transport, ein neuer Eintrag bei den Accepted Domains erstellt. Hier wurde die oben im DNS konfigurierte Domain eingetragen (Abb. 1).

    Konfiguration der Accepted Domains
    Konfiguration der Accepted Domains (Abb. 1)

    Nun ging es ans Testen.

    Zuerst der Versuch, von Extern eine Mail an Exchange 2010 zu schicken. Kurze Zeit nach dem Absenden kam die Mail mit folgender Fehlermeldung zurück: #< #5.7.1 SMTP; 530 5.7.1 Client was not authenticated> #SMTP#

    In der Standardkonfiguration von Exchange 2010 können also nur authentifizierte User eine Mail bei Exchange 2010 einwerfen. Im Blog des Exchange Server Teams wird gezeigt, wie man mit einer Einstellung erreichen kann, dass Exchange 2010 alle Mails aus dem Internet annimmt.
    In der Exchange Server Managementkonsole sind unter „Server Konfiguration“„Hub Transport“ die Eigenschaften des „Default Receive Connectors“ aufzurufen und unter dem Tab „Permission Groups“ der fehlende Haken bei Anonymous Users zu setzten (Abb.2).

    Koniguration des Default Receive Connectors (Abb. 2)
    Konfiguration des Default Receive Connectors (Abb.2)

    Ein erneuter Test mit der neuen Outlook Web Access Oberfläche von Exchange 2010 zeigt, dass nun Mails von „Extern“ ankommen.

    Als nächtes wurde versucht, eine Mail aus Exchange 2010 an eine „externe“ Mailadresse zu senden. Es zeigte sich aber, dass dies ebenfalls mit den Grundeinstellungen von Exchange 2010 nicht funktioniert. Stichwort für das Senden ist hier „Send-Connector“. Der entscheidende Hinweis kommt ebenfalls aus dem Blog des Exchange Server Teams.  In der Management Konsole von Exchange 2010 ist unter den „Organisationseinstellungen“, unter „Hub Transport“ auf dem Tab „Send Connectors“ ein neuer Send Connector anzulegen. Hier kann man nun einen beliebigen Namen angeben. Als Typ wählt man nur Internet aus. Auf der nächsten Seite des Assistenten fügt man nun einen Eintrag in die Adressliste hinzu. Diese Liste beinhaltet die Adressen, für die der Send Connector konfiguriert ist. Der Einfachheit halber kann man hier einfach ein * als Wildcard benutzen. So gilt der Send Connector für alle Adressen (Abb. 3).

    Konfiguration des Send-Connectors
    Konfiguration des Send-Connectors (Abb. 3)

    Nachdem der Send Connector erstellt wurde, funktioniert nun auch das Versenden von E-Mail aus dem Exchange Server 2010.

    Der für mich wichtigste Unterschied zu Exchange 2007 ist das neue Outlook Web Access (OWA) von Exchange 2010. Endlich werden andere Browser gegenüber dem Internet Explorer nicht mehr benachteiligt. Dies merkt man vor allem bei der Kalenderansicht und bei den nun vorhandenen Kontextmenüs unter Firefox (Abb. 4).

    Outlook Web Access 2010 mit Firefox (Abb. 4)
    Outlook Web Access 2010 mit Firefox (Abb. 4)

  • Data Protection Manager 2007 Backup von Exchange Server 2007 funktioniert nach Exchange 2007 Service Pack 1 nicht mehr

    Nach dem ServicePack 1 für den Microsoft Exchange Server 2007 funktionierte das Backup des Exchange Mailboxclusters mit dem Microsoft System Center Data Protection Manager 2007 (DPM) nicht mehr.

    Die Ereignisanzeige zeigte folgende Fehlermeldung:

    Beschreibung: Das Replikat von Speichergruppe First Storage Group auf Mailboxserver1 ist nicht mit der geschützten Datenquelle konsistent. Alle Schutzaktivitäten für die Datenquelle scheitern, bis das Replikat mit Konsistenzprüfung synchronisiert wird. Sie können Daten aus vorhandenen Wiederherstellungspunkten wiederherstellen, aber neue Wiederherstellungspunkte können erst erstellt werden, wenn das Replikat konsistent ist. (ID 3106)
    Fehler bei der Datenkonsistenzprüfung für LOGS von Speichergruppe First Storage Group auf Mailboxserver1 (ID 30146 Details: Unknown error (0xfffffdfe) (0xFFFFFDFE))
    Empfohlene Aktion: Entweder sind die Datenbankdateien beschädigt, oder die ordnungsgemäßen Versionen folgender Dateien fehlen.
    Wurde der Exchange-Server kürzlich aktualisiert, kopieren Sie die Dateien von diesem Server auf den DPM-Server.
    eseutil.exe
    ese.dll

    Der DPM benutzt die Dateien eseutil.exe und ese.dll, um die Konsistenz des Backups der Exchangeserver Mailboxdatenbanken zu überprüfen. Diese Dateien sind kein Bestandteil des DPM. Sie müssen aber in ein Verzeichnis des Data Protection Managers kopiert werden, damit der DPM die Exchange Backups überprüfen kann. Die Versionen dieser Datein müssen mit der Version des Exchangeservers übereinstimmen. Das Servicepack 1 des Exchangeserver 2007 bringt auch neue Versionen der eseutil.exe und ese.dll Dateien mit. Die Dateiversionen dieser Dateien, die sich auf dem DPM befanden, waren nach dem Exchange 2007 SP1 nicht mehr kompatibel mit der neuen Exchange Version. Ein einfaches Kopieren der neuen SP1 Versionen von eseutil.exe und ese.dll vom Exchangeserver auf den Data Protection Manager scheiterte daran, dass der Exchangeserver ein 64bit-System ist und der Data Protection Manager ein 32bit-System. Da Microsoft die eseutil.exe und ese.dll Dateien nicht explizit zum Download anbietet, war zunächst guter Rat teuer. Woher sollte man jetzt eine 32bit-Version von eseutil.exe und ese.dll bekommen? Extra eine 32bit-Testversion von Exchange Server 2007 mit Service Pack 1 zu installieren erschien mir als zu umständlich.

    Im Technet Blog fand ich den Hinweis, dass die Service Pack 1 Versionen der eseutil.exe und ese.dll Dateien in den Microsoft Exchange Server 2007 Management Tools 32-Bit enthalten sind, die man bei Microsoft downloaden kann. Diese wurden dann auf einem Testserver installiert und die dort enthaltenen neueren SP1 Versionen von eseutil.exe und ese.dll,

    eseutil_ese_on_exchange

    wurden dann auf den DPM Server kopiert.

    ese_on_dpm

    Von nun an funktionierte das Data Protection Manager 2007 Backup von Exchange Server 2007 wieder.

    dpm_nach_neuer_ese

    Die Microsoft Exchange Server 2007 Management Tools 32-Bit entpuppten sich beim Setup als 32bit Exchangeserver, was die Downloadgröße schon erahnen lies. Bei der Installation sollte man deshalb darauf achten, dass nur die Management Tools ausgewählt sind.

    setup_exchange_sp1_managementtoolsl1

  • Die Windows Eingabeaufforderung per Eintrag im Explorer-Kontextmenü in einem bestimmten Ordner öffnen

    Obwohl dies an diversen Stellen im Netz zu finden ist, hier noch einmal, weil ich jedes Mal Google bemühen muss.

    Windows Registry Editor Version 5.00
    [HKEY_CLASSES_ROOT\Directory\shell\OpenNew]
    @ = "Eingabeaufforderung"
    [HKEY_CLASSES_ROOT\Directory\shell\OpenNew\Command]
    @="cmd.exe /k cd %1"

    Alles in eine Textdatei mit der Endung .reg einfügen, abspeichern und ausführen. Und schon hat man dem Kontextmenü des Explorers einen CMDHere Eintrag hinzugefügt. Ab sofort kann man mit diesem Eintrag die Windows Eingabeaufforderung (Kontextmenüeintrag: Eingabeaufforderung) in einem bestimmten Verzeichnis öffnen.

    Wer es genauer wissen will, kann sich folgenden Artikel in der KnowledgeBase von Microsoft anschauen:
    How to start a command prompt in a folder in Windows Server 2003, Windows XP, and Windows 2000