Vielleicht ist dem ein oder anderen schon einmal aufgefallen, dass es oftmals eine Weile dauert, bis die Exchange Management Console (EMC) oder auch die Exchange Management Shell (EMS) vollständig geöffnet ist.

Dies liegt häufig daran, dass beim Öffnen von mmc’s und der Powershell Authenticode Technologie zum Einsatz kommt und in diesem Fall Microsoft die MMC Snap-Ins und die Powershell Module digtial signert hat. Da hier Zertifikate zum Einsatz kommen, möchte Windows beim Start der Werkzeuge prüfen, ob diese ggfs. gesperrt worden sind und eine Sperrliste bei Microsoft herunter laden.

In den meisten Unternehmen haben allerdings Server keinen direkten Internet-Zugriff und darüber hinaus kommen oft auch Proxy-Server zum Einsatz, welche eine Authentifizierung erfordern. Es wird vom Server versucht, die Sperrliste herunter zu laden, was natürlich nicht funktioniert denn:

Es ist einerseits kein Proxy eingetragen und es besteht auch keine direkte Internetverbindung.

Die längeren Startzeiten resultieren aus dem Warten auf den Timeout.

Es ist sicher nicht ratsam, einem Server ohne Einschränkungen den Internetzugriff zu gestatten. Es wäre daher wünschenswert, dem Server lediglich die Möglichkeit zu geben, die entsprechende Sperrliste herunter zu laden.

Ein Beispiel:

Ein Unternehmen dom.local hat einen Proxy Server, welcher das Surfen nur mit Authentifizierung gestattet. Auf den Servern ist kein Proxy eingetragen und die Server können keine direkte Internetverbindung herstellen.

Der Admin startet z.B. die Exchange Powershell (EMS) , folgender Effekt ist zu sehen:

Hier ist warten angesagt …. Erst nach einiger Zeit kommt der Prompt und es können Eingaben gemacht werden.

Wenn man währenddessen den Traffic in einem Netzwerkscanner beobachtet, ist schön zu sehen, dass der Server versucht, den Namen crl.microsoft.com aufzulösen:

Es handelt sich hierbei um einen Sperrlistenverteilerpunkt der Microsoft CAs im Internet.

Da der interne DNS diesen im Regelfall nicht auflösen kann, kommt es zum Timeout -> Start der Powershell / Managementconsole verzögert sich.

Ein Lösungsansatz :

Da das Surfen nur über Proxy mit Authentifizierung gestattet ist, kann die Sperrliste nicht heruntergeladen werden. Auch den Proxy Server am Server im Internet-Explorer einzutragen bringt hier nichts, da die Powershell oder die MMCs nicht die Einstellungen des IE für die Internetverbindung verwenden, sondern die Einstellungen der Windows-HTTP-Dienste (WinHTTP).

Abhilfe kann wie folgt geschaffen werden :

1) eine Ausnahme im jeweiligen Proxy-Server erstellen, sodass die URL crl.microsoft.com von den Servern ohne Authentifizierung erreicht werden kann

2) den Proxy Server für die Windows-HTTP-Dienste (WinHTTP) im enstsprechenden System eintragen

um den Proxy Server für WinHTTP einzutragen kommt das Tool Netsh zum Einsatz. Am einfachsten ist es, wenn man den Proxy im Internet Explorer mit den lokalen Ausnahmen einträgt und dann diese Einstellungen via Netsh als WinHTTP-Proxy in das System importiert:

danach einfach den Proxy wieder aus dem IE entfernen.

Besonders wichtig ist hierbei die Ausnahmen richtig zu setzen, da sonst alle HTTP-Anforderungen über den Proxy verschickt würden, was nicht wünschenswert ist und zu Fehlern führen kann ! Daher müssen alle lokalen Adressen und Verbindungen über die Ausnahmen eingetragen sein.

Im Beispiel wurde der gesamte Namensraum *.dom.local (lokale Windows Domäne) von der Proxy-Verarbeitung ausgenommen.

Mit den oben beschriebenen Schritten ist gewährleistet, dass

a) der Proxy nur für das System zur Verfügung steht         und

b) da keine Authentifizierung eingetragen ist, nur die URLs erreicht werden können welche keine Authentifizierung erfordern, hier : crl.microsoft.com

Die Startzeiten der EMC und EMS verkürzen sich dadurch spürbar.

Hinweis: Es gibt diverse andere MMCs auch von anderen Herstellern die solche Sperrlisten anfordern. Dazu einfach in einem Paketscanner beim Öffnen die Netzwerkzugriffe checken und die URL für den Sperrlistendownload analog freischalten. Dann klappts auch mit dem schnellen Öffenen der Konsole 🙂

Weitere Hinweise gibt es auch in diesem Artikel bei Microsoft : http://technet.microsoft.com/de-de/library/bb430772.aspx

oder auch : sender based routing

Wenn in Unternehmen die Email-Domains und DNS-Dienste über externe Provider implementiert sind, ergeben sich meist Anforderungen den Email-Nachrichtenfluss ein- und ausgehend über den entsprechenden Provider zu schleusen. Gerade wenn keine festen IP-Adressen vorhanden sind und es keine Möglichkeit gibt die MX-Einträge der Email-Domains auf eigene Ressourcen zeigen zu lassen, ist es erforderlich, alle Nachrichten über den Provider zu versenden.

In Microsoft Exchange 2010 SP1 (und auch früheren Versionen) gibt es keine einfache Möglichkeit mit Boardmitteln Nachrichten anhand Ihres Absenders an unterschiedliche Smarthosts zu Verteilen.

ein Beispiel:
ein Unternehmen besitzt mehrere Email-Domains :   MusterFirma.de    und     MusterCorp.com

Beide Domains sind bei unterschiedlichen Providern gehostet, welche eingehende Nachrichten per SMTP an den Exchange Server weiterleiten. Auf die Mailsysteme der beiden Provider zeigen auch die DNS MX-Records der Domains.

Wenn es nun erwünscht ist, dass mit beiden Domains Email verschickt werden soll, muss der Administrator den ausgehenden Mailfluss aufsplitten:

– Wenn im Absenderfeld @musterfirma.de steht, sende diese Nachrichten über den Smarthost des Providers A

– Wenn im Absenderfeld @mustercorp.com steht, sende diese Nachrichten über den Smarthost des Providers B

Um dies umzusetzen gibt es grundsätzlich 3 Möglichkeiten:

1) Ein Tool eines Drittanbieters auf dem Exchange-System installieren

2) Ein Mailsystem mit der Möglichkeit zum Sender-based-Routing vorschalten und alle ausgehenden Mails darüber leiten

3) Einen eigenen Transportagenten für Exchange programmieren

Möglichkeit 1)

Drittanbieter bieten Tools an, welche das Sender-based-Routing direkt auf dem Exchange Server übernehmen. Dazu ist es erforderlich, auf den Exchange HUB-Transport Servern das entsprechende Tool zu installieren. Danach kann über die gewohnten Send-Connectoren die Aufsplittung gemacht werden.  Besonders interessant ist auch die Möglichkeit, das Mailrouting anhand von ActiveDirectory Gruppen zu implementieren.

Besonders gute Erfahrungen habe ich mit dem Tool ExSBR der Firma messageconcept GmbH gemacht :

http://www.messageconcept.net/de/produkte/exsbr/

Möglichkeit 2)

Um Kosten zu sparen kann man ein vorgelagertes Mailsystem zum Beispiel mit einem freien Linux-System und Postfix (Debian/Ubuntu…) implementieren.

als Einstieg: http://www.debian.org/  und  http://www.postfix.org/docs.html sowie http://www.3d4x.ch/swift/senderbased.html

Ein solches System kommt im Regelfall mit sehr wenig Ressourcen zu Recht und übernimmt die Aufsplittung des Mailflusses. Für Exchange ist dieses transparent, lediglich der send-Connector für die Internet-Mails muss auf dieses System umkonfiguriert werden. Wenn man virtualisiert hat, ist dieses System prädestiniert virtualisiert zu werden.

Nachteil: Es gibt ein weiteres System, das man Warten, Patchen und Überwachen muss. Weiterhin sind größere Exchange-Umgebungen durchaus auch hochverfügbar implementiert (DAG/CAS-Arrays..). Es sollte darauf geachtet werden, dass dann auch das vorgelagerte System entsprechend ausfallsicher gestaltet ist, um keinen Single-Point-of-Failure zu riskieren.

-> Was nützt die hoch-verfügbarste Exchange Landschaft, wenn das kleine Mail-Routing-System ausgefallen ist.

Möglichkeit 3)

Wenn entsprechende Entwickler-Fähigkeiten vorhanden sind, kann man auch eigene Transportagenten schreiben. Einen Einstieg findet man bei Microsoft an folgender Stelle : http://technet.microsoft.com/de-de/library/bb125012.aspx

Hinweis:  Im Kontext des sender-based-routing ergibt sich auch manchmal die Anforderung, dass User in Microsoft Outlook oder anderen Email-Clients zusätzlich in die Lage versetzt werden sollen, die Absender Email-Adresse im Client auszuwählen. Zu diesem Thema gibt es demnächst einen Artikel, einfach wieder reinschauen !