Archiv für Dezember 2008
2008 goes, 2009 comes

Mit diesem Beitrag werde ich das Kapitel 2008 bei server-talk.eu schliessen. Mit durchschnittlich 300 unique Visitors pro Tag geht ein sehr gutes, aber auch anstrengendes Jahr zu Ende. Ein grosses Lob geht dabei auch an die Leute hinter den Kulissen ohne die dies alles nicht möglich gewesen wäre. Vielen Dank an Johannes (www.security-blog.eu), welcher sich vorbildlich um die ganze Technik kümmert. Auch möchte ich an dieser Stelle meine Arbeitskollegen Simeon und Arthur erwähnen, welche einen grossen Einfluss bei gewissen Themen hatten - schade dass wir nächstes Jahr nicht mehr zusammenarbeiten werden…

Nicht vergessen darf ich natürlich auch meine “besser Hälfte”. Ein riesen Dankeschön gilt meiner Freundin Carmen, die mich in den vergangenen Jahren immer wieder unterstützt und mir so viel Zeit für mein “Hobby” gelassen hat – Schatz, du bist super!

Ich wünsche euch hiermit das Beste für 2009 und hoffe, dass der “Rutsch” ins neue Jahr ein tolles Fest wird.

Bis nächstes Jahr & viele Grüsse,
Michel

2008 goes, 2009 comes

Error “A local loop was detected” mit Exchange Transport Server

Microsoft Exchange Server Logo In Migration wünschen Kunden oftmals, eigentlich meistens die Server- und Domain-Namen 1:1 zu übernehmen. In einen koexistenten Betrieb zwischen Exchange Server 2003 und 2007 kann dies in speziellen Konstellationen zu unangenehmen Effekten führen.

Was passiert, wenn zum Beispiel ein Exchange Edge Transport Server in Betrieb genommen werden soll, welcher mit den Namen MX1.domain.com installiert wurde. Der Namen lässt schnell darauf schliessen, dass dieser Name auch im externen DNS eingetragen wurde. Wenn nun dieser Name auch im Internet Connector des Exchange 2003 Front End Server eingetragen ist, fangen die Probleme an…

Sobald die Edge Transport ihren Betrieb aufnehmen und somit E-Mails auch in die Exchange Server 2003 Umgebung zustellen sollen wird im Exchange Server 2007 Queue Viewer folgende Meldung angezeigt:

554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop

Auch der Sender der E-Mail erhält eine Fehlermeldung. Der Unzustellbar-Bericht vom Postmaster enthält folgende Nachricht:

Für den Empfängerserver wurde keine Route gefunden. Wenden Sie sich an Ihren Systemadministrator.

<domain.com #5.4.4 smtp; 554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop>

Dieses Routing Problem hat den Ursprung bei SMTP Internet Connector des “alten” Front End Servers. Dort wurde im im “Delivery tab | Advanced | Fully-qualified domain name” denselben Domain Name wie beim Edge Transport, MX1.domain.com, eingetragen. Wenn man nun paar Schritte zurückgeht und ein Health Check Report des “Exchange Best Practice Analyzer”  prüft, wird der Administrator unter Umständenen schon früher auf diesen Fehler hingewiesen:

Missing FQDN in service principal name

Weitere Informationen zu dieser Konfiguration findet man im Microsoft KB 914137 . Zurück zum ursprünglichen Problem. Die Lösung des Problems ist relativ einfach. Der Domain Name im Front End Connector muss zwingend angepasst werden. Eine noch bessere Lösung wäre allerdings, wenn dieser entfernt und das Routing vollständig über die Exchange Server 2007 Infrastruktur abgehandelt würde. Dazu wird lediglich der Routing Group Connector benötigt.

Weitere Informationen

How-To: MAPILab POP3 Connector mit Exchange Server 2007

Microsoft Exchange Server LogoWelcher Exchange Server Administratoren kennt das Problem mit dem Maildownload von POP3 / IMAP4 Servern und deren Weiterleitung an die Endnutzer nicht. Exchange Server selbst, ausgenommen Small Business Edition, unterstützt diese Funktion nicht. „Brauch man auch nicht…“ könnte man meinen. Denn als Grundlage für den Betrieb eines Messaging System ist eine fixe IP-Adresse, worüber der Empfang und Versand des Mailverkehrs abgewickelt wird. Doch was, wenn dies nicht der Fall sein sollte? Es kann auch durchaus vorkommen, dass auch bei grösseren Exchangen Installationen zusätzlich Mails von externen Postfächern abgeholt werden müssen. Aus diesen Gründen wurde durch MAPILab der POP3 Connector entwickelt. Die Software holt nach einem Zeitplan Mails von den externen POP3 / IMAP4 Servern ab und verteilt diese an die definierten Empfänger im internen Microsoft Exchange Server 2007.

Installation

Den MAPILab POP3 Connector (MPC) gibt es als 64-Bit und 32-Bit Version und kann ab Windows Server 2003 ausgeführt werden. Wichtig, die Software ist nur mit Microsoft Exchange Server 2007 kompatibel, welcher gemäss Microsoft nur in der 64-Bit Version produktiv supportet ist. Für die Arbeit mit Exchange Server 2000 / 2003 muss die ältere Version MAPILab Native POP3 Connector eingesetzt werden. Folgende Vorbereitungen sind für die Installation erforderlich:

  1. MAPILab POP3 Connector Prerequisites
  2. MAPILab POP3 Connector Installation
    • Der POP3 Connector muss auf dem Exchange Server mit der Hub Transport Role installiert werden, damit der entsprechende Receive Connector ausgewählt werden kann.
    • Vor der Installation werden die Prerequisites geprüft und die der mit Sicherheit fehlende “Microsoft SQL Server Compact 3.5 SP1″ installiert.
    • Wenn alle benötigten Komponenten, .NET Framework 2.0 / MMC 3.0 / SQL Server Compact 3.5 SP1, gefunden wurden kann die Software installiert werden. Während des Setup sind keine weiteren Angaben erforderlich.
  3. MAPILab POP3 Connector First Step
    • Wird MPC gestartet (MAPILab | MAPILab POP3 Connector | MAPILab POP3 Connector) werden zunächst Angaben benötigt
      • General-Tab: Im ersten Tab müssen Informationen zu Postmaster, SMTP Receive Connector und Pfadangaben für die Queue- und Logs-Folder eingetragen werden.
      • Advanced-Tab: Im Textfeld müssen die bei Exchange als Acceped Domains eingetragenen Domains nochmals angegeben werden. Darüber sucht MPC dann die Empfänger. Weiter kann die Art und Menge des Logging definiert werden. Es empfiehlt sich hier ev. pro Tag oder mindestens pro Woche in neues File anzulegen.
      • Details-Tab: Last but not least ist ein Product-Key für den Betrieb erforderlich. MPC kann 20 Tage uneingeschränkt getestet werden
    • Ist der POP3 Connector – der Server – konfiguriert können Mailboxen für den Download konfiguriert werden. Mit “New Mailbox…” wird der Wizard gestartet. In den darauf folgenden Screens werden die üblichen Informationen wie E-Mail Adresse, Username und Passwort abgefragt. Wichtig, die Mailbox sollte hier noch nicht “enabled” werden.
    • Bevor nun die POP3 / IMAP4 Mailbox verarbeitet wird, sollte die Detail-Konfiguration vorgenommen werden. Dazu müssen die “Properties” geöffnet werden. Hauptsächlich die Tabs “Advanced” und “Schedule” verdienen dabei besonders Beachtung. Darüber wird definiert wie oft die Mailbox kontaktiert wird und was mit den Items auf dem Server passiert.
    • Wurde die Konfiguration geprüft, kann mit “Enable this mailbox for processing” die Mailbox enabled werden und gemäss Scheduler wird der Auftrag verarbeitet.

Berechtigung

Für die Installation und Konfiguration sind Zugriffsrechte eines Domain Administrators erforderlich.

Weitere Anpassungen

  • Sprache
    Der POP3 Connector kann in Englisch oder Russisch installiert werden. Die Sprache kann auch im späteren Betrieb mit “MAPILab | MAPILab POP3 Connector | Tools | Switch Language” gewechselt werden.
  • Migration
    Wenn bereits der “Native POP3 Connector” (NPC 2003) eingesetzt wurde, kann diese Konfiguration mit “MAPILab | MAPILab POP3 Connector | Tools | Import NPC 2003 Configuration” importiert werden.
  • Backup
    Sämtliche Information über Connectors und Mailboxen werden in XML-Dateien gespeichert. Diese werden im Pfad “%ProgramFiles%\MAPILab Ltd\MAPILab POP3 Connector\config\” gespeichert und bleiben auch nach einem Uninstall bestehen.
    • Connector Konfiguration: connector.xml
    • Mailbox Konfiguration: <GUID>.xml
  • Anti-Spam
    Wichtig, wenn ein Spam-Filter auf dem Exchange Server den Empfang von Spam-Mails blockt, landen diese im MAPILab “Queue\BadMail” Folder. Ein POP3 Connector kann diese Blockfunktion nicht handhaben…

Viele Informationen kann der MAPILab POP3 Connector Help entnommen werden.

Weitere Informationen

How-To: IMAP nach Exchange Server 2007 migrieren

Microsoft Exchange Server LogoBei Migrationen von Exchange Mailboxen denkt man in den meisten Fällen an eine intra-Org Migration von einem Exchange Server 2003 nach Exchange Server 2007. Bei Zeiten wo auch Google im Messaging Markt gross mitmischt, kommen auch Anforderungen für POP3/IMAP4 Migrationen auf. Da mit Exchange Server 2007 der MailMig nicht mehr mit dem Server mitgeliefert wird, hat Microsoft mit der Transporter Suite ein Tool nachgeliefert, welches auf einfache(re) Art und Weise Mailboxen von Lotus Notes, POP3 und IMAP nach Exchange Server 2007 migrieren kann. Die Software, aktuell in der Version 2007 verfügbar, kann kostenlos heruntergeladen werden. Zum Download…

Installation

Die Microsoft Transporter Suite gibt es als 32-Bit und 64-Bit Version und kann ab Windows XP ausgeführt werden. Für Migrationen einzelner Mailboxen kann durchaus eine Workstation ausreichend sein. Folgende Vorbereitungen sind für die Installation erforderlich:

  1. Microsoft Transporter Suite Prerequisites
  2. Microsoft Transporter Suite Installation
    • Bei der Installation muss nur die Komponente “Transporter for Internet Mail” ausgewählt werden. Die anderen Komponenten währen für eine Migration von IBM Lotus Domino.

Berechtigungen

Für die Migration von POP3/IMAP4 Mailboxen nach Microsoft Exchange Server 2007 mit der Transporter Suite sollte ein dedizierter Migration-Account eingesetzt werden. Dieser muss mit nachfolgenden Berechtigungen ausgestattet werden.

  1. Der Migration-Account muss Mitglied der Role “Exchange Recipient Administrator” sein. Diese Berechtigung kann in der “Exchange Management Console” (EMC), oder mittels “Exchange Management Shell” (EMS) zugewiesen werden:
    • Add-ExchangeAdministrator -Identity <MigrationAccount> -Role RecipientAdmin
  2. Dieser Migration-Account benötigt zudem das “Exchange Impersonation” Recht, welches auf einem, oder auch sämtlichen “Client Access Server” (CAS) konfiguriert wird.
  3. Die Client Access Server können zunächst mit folgendem cmdlet ausgelesen werden:
    • Get-ClientAccessServer | Select Name,Distinguishedname | fl
  4. Die konfigurierten Berechtigungen für den Migration-Account können mit diesem PowerShell cmdlet Angezeigt…
    • Get-ADPermission -Identity <ExchangeCAS> -User <MigrationAccount>
  5. … und mit Add-ADPermission konfiguriert werden:
    • Einzelner Client Access Server: Add-ADPermission –Identity <ExchangeCASDN> -User <MigrationAccount> -ExtendedRight ms-Exch-EPI-Impersonation
    • Alle Client Access Server: Add-ADPermission -Identity (Get-ExchangeServer).DistinguishedName -User (Get-User -Identity <MigrationAccount> | Select-Object).identity -ExtendedRight ms-Exch-EPI-Impersonation
  6. Die getätigteKonfiguration kann mit “Get-ADPermission” geprüft und mit der zuvor erhaltenen Ausgabe verglichen werden.

Weitere Anpassungen

  • Anpassung der “Item Size”
    Bei grossen E-Mails muss der Wert “maxRequestLength” in der Konfigurationsdatei %ProgramFiles%\Microsoft\Exchange Server\ClientAccess\exchweb\ews\web.config erhöht werden. Dies wird im Microsoft KB 953526 und 925827 detaillierter beschrieben.
  • Einsatz von Folder Mappings
    Bei unterschiedlichen Sprachen ist es notwendig, mittels %ProgramFiles%\Microsoft Transporter Tools\Config\FolderMap.xml diese entsprechend zuzuweisen. Ein Beispiel:

<Folder path = “sent-mail”>
    <Property SpecialFolder = “Sent Items”/>
</Folder>

<Folder path = “Kalender”>
    <Property SpecialFolder = “Calendar”/>
</Folder>

  • Ausnahmen / Excludings von Folders
    Mit derselben Konfigurationsdatei können auch Ordner definiert werden, welche nicht migriert werden sollen. Dies sieht dann wie folgt aus:

<Folder path = “spam-mail”>
    <Property ExcludeFolder = “true”>
</Folder>

Migration

Für eine erfolgreiche Migration ist ein CSV-Datei mit den entsprechenden Angaben erforderlich. In dieser Liste werden Source und Target Mailboxen verknüpft. Die Transporter Suite bezieht daraus zudem die Zugangsdaten des IMAP-Account. Eine solche Datei könnte wie folgt aussehen, wobei die erste Zeile vorgegeben ist:

SourceIdentity,sourceserver,SourceLoginID,SourcePassword,TargetIdentity
michel@no-spam-server-talk.eu,imap.server-talk.eu,michel,iz66!,michel@no-spam-server-talk.eu

Die “TargetIdentity” muss ein bestehender User im Active Directory sein, ansonsten wird folgende Fehlermeldung ausgegeben:

Could not locate an User in Active Directory for Source User ’smtp:nouser@server-talk.eu’. All the mailbox items belonging to this user will be ignored.

Mit der eigentlichen Migration kann nun begonnen werden.

  1. Die “Transporter Management Console For Internet Mail” starten
  2. In der Transport Suite Console mit “Actions | Add Mailboxes…” diezuvor angelegte CSV-Datei laden. Wichtig, die Passwörter werden im Konfigurationsdatei “InternetMailbox.tbin” gespeichert. Falls es beim Zugriff auf die Konfigurationsdatei zur Fehlermeldung “No mailbox records found in specified csv file” kommt, fehlen die Exchange Management Tools…
  3. Die entsprechenden Mailboxen markieren und in der der Action-Pane “Migrate Selected Mailboxes…” auswählen um den Wizard zu starten.
  4. Im ersten Screen muss angegeben werden, ob die Verbindung über SSL (empfohlen) oder einen unsicheren Kanal stattfinden soll. Diese Einstellung muss gemäss IMAP-Server konfiguriert werden. Zusätzlich wird der zuvor vorbereitete Client Access Server benötigt. In den folgenden Screens kann ein “FolderMap.xml” und ein Zeitrahmen für die Migration angegeben werden.
  5. Nachdem alle Einstellungen vorgenommen wurden, wird die Migration ausgeführt.

Viele Informationen kann der Transporter Suite Help entnommen werden. Für PowerShell Fans stehen viele weitere Möglichkeiten für die Migrations mit den cmdlets der Transporter Suite zur Verfügung.

Weitere Informationen

Windows Failover Cluster Validate Error “Found duplicate IP address”

Logo Microsoft Windows Server 2008Seit Windows Server 2008 wird bei der Installation des Failover Cluster die Hardware und Operating System Konfiguration mit dem “Cluster Validator” auf die Kompatibilität geprüft. Diese Validierung muss erfolgreich durchlaufen, damit die Konfiguration funktioniert und durch Microsoft unterstützt wird:

For the Windows Server 2008 Failover Clustering solution to be considered an officially supported solution by Microsoft Customer Support Services (CSS), the solution must meet the following criteria:

  • All hardware and software components must meet the qualifications to receive a “Certified for Windows Server 2008″ logo.
  • The fully configured solution must pass the Validate test in the Failover Clusters Management snap-in.

Weitere Informationen dazu erhält man auch im Microsoft KB 943984. Nun kann es aber vorkommen, dass im Cluster Validation Report folgende Fehlermeldung angezeigt wird:

Found duplicate IP address fe80::100:7f:fffe%12 on node ClusterNode1.company.com adapter Local Area Connection* 9 and node ClusterNode2.company.com adapter Local Area Connection

Diese Meldung bezieht sich auf das Teredo Network Interface, in diesem Beispiel „Local Area Connection 9“, wo ein Konflikt mit einer doppelten IP-Adresse besteht. Das Teredo Tunneling Protocol ist eine Methode für den Zugriff auf ein IPv6 Netzwerk, welches sich hinter einem NAT-Device befindet. Mit Teredo werden IPv6-Pakete mit UDP über IPv4 gekapselt werden. Diese Technologie wurde mit Windows Server 2008 / Windows Vista eingeführt…

Nun aber wieder zurück zum Windows Failover Cluster. Ein Problem mit doppelter IP Adresse kann entstehen, wenn die Server von gleichen Images installiert und automatisch der Cluster NetFT Adapter mit derselben MAC Adresse erstellt wurde. Im Validator Report wird dies als Fehler hervorgehoben, da ein Failover Cluster  immer eindeutige IP-Adressen erfordert. Damit die Validation erfolgreich abgeschlossen werden kann, gibt es zwei Möglichkeiten. Zunächst sollte das Feature Failover Cluster entfernt und wieder neu installiert werden. Bringt dies keine Abhilfe besteht die Möglichkeiten den Teredo Adapter zu deaktivieren.

Methode 1) Re-Install Failover Cluster

Wie Roles und Features im Server Manager installiert werden können, sollte soweit jedem klar sein. Ein unter Umständen schnellerer Weg ist über die Command Prompt und ServerManagerCMD. Damit lässt sich ebenfalls der Failover Cluster entfernen und neu installieren:

  • Uninstall: ServerManagerCmd -remove Failover-Clustering
  • Install: ServerManagerCmd -install Failover-Clustering

Wichtig, Sysprep ist nicht supported, wenn das Failover Cluster Feature bereits installiert wurde. In einem solchen Fall hat der Virtuelle Cluster Adapter (NetFT) bei sämtlichen Nodes die gleiche MAC Adresse. Die NetFT Konfiguration wird bei der Installation des Failover Cluster Feature aufgrund der MAC einer der physikalischen NICs erstellt.

Methode 2) Disable Feature via Command line

Zunächst mit “Run as Administrator” (Windows UAC) einen “Command Prompt” öffnen. Mit den einzelnen Befehlen “netsh interface teredo set state disabled” kann das Teredo Interface deaktiviert werden. Dies sieht dann wie folgt aus:

C:\Windows\System32\ netsh
netsh> interface
netsh interface> teredo
netsh interface teredo> set state disabled
Ok.

Methode 3) Disable Feature via Registry

Mit “Run as Administrator” einen Registry Editor öffnen. Dies kann auch durch einen bereits als Administrator geöffneten Command Prompt und “regedit” gemacht werden.

Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
Entry: DisabledComponents
Type: DWORD
Value: 8 (Hexadecimal)

Nach einem Neustart des Servers ist Teredo nicht mehr aktiv.

Methode 4) Disable Device im Device Manager

Wurde das Feature deaktiviert und die Validation schlägt noch immer fehl, kann das Interface auch noch im Device Manager deaktiviert werden. Dazu muss der Device Manager (Server Manager | Diagnostics | Device Manager) geöffnet werden. Mittels “View | Show hidden devices” wird das “Teredo Tunneling Pseudo-Interface” bei den Network Adapters angezeigt. Dieses Interface kann nun deaktiviert werden. Allerdings, deaktiviert diese Vorgehensweise nicht die dazugehörige Logik und kann daher zu einem späteren Zeitpunkt zu Problemen führen. Die Variante mittels Command Line oder Registry sollte daher zuvor ausgeführt werden.

Methode 5) Disable IPv6

Last but not least eine weitere Lösung… Da das Problem den Ursprung bei IPv6 hat, kann IPv6 mittels Registry Key auch komplett sauber deaktiviert werden.

Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
Entry: DisabledComponents
Type: DWORD
Value: 0xffffffff (Hexadecimal) / 4294967295 (Decimal)

Diese Einstellung deaktiviert sämtliche IPv6 Komponenten, ausgenommen das “IPv6 Loopback Interface”. Im HOST File sollte die Zeile “::1 localhost” ausgeklammert, oder entfernt werden. Optional kann nun auch noch das “Internet Protocol Version 6 (TCP/IPv6)” in den Connection Properties des Network and Sharing Center abgewählt werden.

Allerdings ist dies kein von Microsoft empfohlener Weg. IPv6 sollte nur im „Notfall“ deaktiviert werden. Bei sämtlichen Anpassung kann / muss “Validate a Configuration” nach einem Server Reboot erneut ausgeführt werden. Der Fehler “Found duplicate IP address” sollte nun allerdings nicht mehr auftreten und der Failover Cluster kann installiert werden. 

Weitere Informationen

Disclaimer

Bevor die Registry bearbeitet wird, sollte ein Backup erstellt und vergewissert werden, dass bei einem Problem ein Restore der Registry durchgeführt werden kann. Die unkorrekte Verwendung eines Registry-Editor kann schwerwiegende Probleme verursachen, die eine Neuinstallation des Betriebssystems erforderlich macht. Die Anpassung erfolgt auf eigene Verantwortung.

  • Microsoft KB 141377: Differences between Regedit.exe and Regedt32.exe
  • Microsoft KB 322756: How to back up and restore the registry in Windows