Um die Remotewebseite des SBS 2011 und insbesondere den Outlook Web Access (OWA) bzw. den Remote Zugang via TS-Web-Gateway richtig nutzen zu können braucht man ein vertrauenswürdiges Zertifikat.  Um dieses zu erhalten kann man sich natürlich der Dienste einer bekannten öffentlichen CA bedienen. Abhängig von den Zertifikaten die man braucht kann das aber recht teuer werden. Insbesondere bei Zertifikaten mit mehreren Domains (subject alternate domains) kostet das gleich mehrere hundert Euro. Für Testsysteme aber auch für Unternehmen die sicherstellen können, dass alle zugreifenden Systeme dem eigenen Zertifikat vertrauen kann man sich ein Zertifikat mit mehreren Domains auch selbst erstellen.

Manche fragen sich nun vielleicht warum ich ständig diese Zertifikate mit mehreren Domains erwähne. Die Begründung ist recht simpel – weil es viele brauchen (ohne es zu wissen). Nahezu jedes Exchange System das ich kenne ist autoritär für mehr als eine Domain und oft werden auch mehrere (unterschiedliche) als Sendeadressen verwendet. Damit ist es notwendig, dass der Exchange Server auch ein gültiges Zertifikat für die alternativen Domains besitzt. Essentiell wird es wenn man z. B. ein Active Sync Gerät verwendet um die Mails eines Kontos abzurufen welches nicht durch die primäre Domain abgedeckt ist.

So nun aber zu den notwendigen Schritten am Beispiel eines SBS 2011 (Enterprise CA):

Zuerst erstellt man sich eine Textdatei mit folgendem Inhalt – wobei das Subject und die DNS Namen unter SAN natürlich anzupassen sind – weitere Details zu Folgeoptionen findet man ggf. auch hier: http://support.microsoft.com/kb/931351

Die soeben erstellte Datei wird in meinem Fall in request.inf (das .inf ist wichtig!) umbenannt.

certreq -new request.inf certnew.req

certreq -submit certnew.req certnew.cer

certreq -accept certnew.cer

Nachdem das Zertifikat erstellt wurde muss es noch installiert werden:

Um über einen SBS 2011 Server (oder jeden beliebigen anderen Exchange Server) Mails direkt empfangen zu können und auf die Outlook Web Access (OWA) Webseite zugreifen zu können, ist es notwendig ein paar Einstellungen an der eigenen Domain vorzunehmen. Wichtig hierbei ist, dass der Hoster der Domain (in meinem Fall domainfactory) die Möglichkeit bietet die DNS Einstellungen der Domain zu ändern.

In meinem Beispiel werde ich eine DynDNS Adresse als Ziel verwenden. Für den Produktiven Einsatz würde ich empfehlen, eine statische IP bei seinem ISP zu beantragen.

Für den Mailempfang ist es wichtig die so genannten MX Einträge der Domän zu ändern. Für den Zugriff auf die OWA Schnittstelle habe ich bei mir einen neuen CNAME Eintrag erstellt (remote.fragmichnicht.de) und diesen Ebenfalls auf meine dyndns Adresse eingestellt:

Bietet der Hoster die Möglichkeit bei den MX Einträgen Prioritäten vorzugehen, würde ich empfehlen den MX Eintrag des Hosters stehen zu lassen aber mit einer geringeren Priorität zu konfigurieren. So werden die Mails (je nach Hoster) bei einem Ausfall (oder reboots) des eigenen Servers zwischengespreichert und danach zugestellt.

Im Laufe der Installation eines SBS 2011 empfiehlt dieser, dass man die Ports 25, 80, 443 und 987 auf der Firewall öffnet. Da ich keine Webseite unverschlüsselt online stellen werde und auch mein CompanyWeb nicht öffentlich machen möchte, werde ich nur Port 25 und Port 443 öffnen. Auf einem normalen Router ist das in wenigen Sekunden erledigt. Auf einer Firewall wie der Astaro muss man hier etwas mehr Zeit investieren. Das einfache öffnen der Ports bringt nicht den gewünschten Erfolg.

Zuerst navigieren wir im Admin Interface auf Network Security – NAT und wechseln dann auf den Reiter DNAT/SNAT:

Hier klicken wir auf New NAT rule und konfigurieren diese wie folgt:

Traffic Destination ist: External (WAN) (Address).

Die Destination “Exchange” muss man ggf. selbst anlegen. In meinem Fall ist das ein Link auf den SBS 2011. Der Rest sollte bei jedem identisch sein.

Für den Port 25 (SMTP) muss eine ähnliche Regel angelegt werden – Traffic Source ist hier natürlich SMTP:

Manchmal ist es notwendig Mailboxen aus einer bestehenden Exchange 2010 oder SBS 2011 Umgebung zu exportieren.

Benötigte Komponenten

Um den Export vornehmen zu können müssen ein paar Bedingungen erfüllt sein. Da Clientsoftware auf einem Server meiner Meinung nach nichts zu suchen hat, verwende ich hierfür immer meine Admin Workstation:

• Exchange 2010 SP1 (ist beim SBS 2011 schon dabei)
• Outlook 2010 x64 (seit SP1 nicht mehr notwendig)
• Exchange Management Tools

Import & Export Rechte

Um Mailboxen exportieren und importieren zu können benötigt man ein spezielles Recht (welches per default keinem Benutzer zugeordnet ist). Die Zuordnung erfolgt wie alle weiteren Behle auch in der Exchange Management Shell.

New-ManagementRoleAssignment –Role “Mailbox Import Export” –User AD\ExAdmin

Export einer Mailbox

Der einfachste Vorgang ist das exportieren einer einzigen Mailbox. Hierfür reicht ein simpler Powershell Befehl:

New-MailboxExportRequest -Mailbox User01 -FilePath "\\adminpc\export\User01.pst”

Wichtig: Der Pfad zu den Exportdateien muss ein UNC Pfad sein, der für das System auch erreichbar ist!

Export aller Mailboxen

Ein klein wenig komplexer, aber dank PowerShell noch immer recht einfach, wird das exportieren aller vorhandenen Mailboxen auf dem System:

foreach ($i in (Get-Mailbox)) { New-MailboxExportRequest -Mailbox $i -FilePath "\\adminpc\export\$($i.Alias).pst” }

Status des Exports

Bei größeren Exports will man natürlich auch wissen, wie weit der Fortschritt der einzelnen Schritte ist. Diesen kann man sich mit nachfolgendem Befehl anzeigen lassen:

Get-MailboxExportRequest | Get-MailboxExportRequestStatistics

Import einer Mailbox

Daten die man exportiert hat will man natürlich auch wieder importieren. Das erreicht man mit folgendem Befehl.

New-MailboxImportRequest –Mailbox User01 –FilePath "\\adminpc\export\User01.pst”

Massenimport von Mailboxen

Natürlich gibt es via Powershell auch einen Weg viele Mailboxen auf einen Schlag zurück zu spielen. In meinem Beispiel ist es notwendig, dass die exportierten Dateien den Namen der Mailbox tragen UND das die neuen Mailboxen den gleichen Namen haben! Verwendet man die Exportsyntax von oben, dann ist zumindest mal die erste Bedingung erfüllt.

dir \\10.10.10.10\path_to_pst\*.pst | %{ New-MailboxImportRequest -Mailbox $_.BaseName -FilePath $_.FullName }

Gibt es ein *.pst File in dem Ordner für welchen das System keine Mailbo findet, dann erhält man diese rote Fehlermeldung. Das ist aber nicht weiter problematisch – in meinem Fall gibt es diesen Benutzer in der neuen Umgebung bewußt nicht mehr…

Aufräumen

Nachdem die Aufträge durch sind ist es wichtig, die fertigen Requests wieder aus der Exchange Request Liste zu entfernen (auch wenn Sie auf completed stehen, bleiben sie dort stehen!). Erledigt wird das wieder mit einem einfachen PowerShell Befehl:

Get-MailboxExportRequest -Status Completed | Remove-MailboxExportRequest

Update

12.06.2011:

• Import Syntax angepasst und um einen Massenupdate erweitert
• Outlook aus den benötigten Komponenten gelöscht

22.06.2011:

Ich hatte tatsächlich vergessen den Teil zum aufräumen der Requests im Exchange Request System vergessen zu erwähnen. Danke für den Hinweis Nils.

Im aktuellen Newsletter (der sehr zu empfehlen ist) von ERNW wird das Thema over-the-air-Erzeugung von Master Encryption keys zwischen Blackberry Server und Handheld analysiert. Der Artikel geht dabei sehr detailiert auf die Funktionsweise und die verwendeten Mechanismen zum sicheren Austausch des Schlüsselmaterials ein. Das Fazit der Bewertung fällt dabei “pro” RIM aus:

(…) Die Erzeugung von Master Encryption Keys zur Inbetriebnahme von BlackBerry-Geräten und für das automatische Update von Master Encryption Keys zwischen BlackBerry-Geräten und dem BlackBerry Enterprise Server (BES) wird aufgrund der vorliegenden Untersuchung als sicher im Sinne aktueller Sicherheitsstandards bewertet. (…)

Neben dem reinen Austausch des Schlüsselmaterials gibt der Artikel auch weitere Hinweise wie die Policy des BES zu konfigurieren ist um einen sicheren Betrieb sicherstellen  zu können:

• aktivieren der “Content Protection” um die auf dem BlackBerry gespeicherten Daten (Schlüssel) zu schützen
• setzen der Policy “Content Protection Strength IT-Policy” auf “stronger” um einen 283-bit langen ECC-Schlüssel zu erzwingen
• aktivieren des Passwortschutzes mit der Policy “Password Required IT-Policy” (sonst macht die Content Protection wenig Sinn )
• setzen der “Minimum Password Length IT-Policy” auf einen sicheren Wert – der Artikel empfiehlt hier zwölf Zeichen – dies dürfte jedoch in wenigen Umgebungen bei den Benutzern Zuspruch finden

Zusätzlich zu dem Artikel des ERNW lege ich jedem auch noch die Untersuchungen des Frauenhofer Institutes ans Herz. Diese Untersuchung deckt alle Teile mit Ausnahme der Over-the-air-aktivierung ab und sollte daher als Basis jeder guten BES Konfiguration verwendet werden.

Frauenhofer SIT 2006

Frauenhofer SIT 2008 (deutlich hilfreicher als das 2006er Dokument)