This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
" } } $BodyText = $BodyText.Replace("@{","") $BodyText = $BodyText.Replace("}","'n") $MailMessage = New-Object System.Net.Mail.Mailmessage $MailMessage.From = '[email protected]' $MailMessage.To.Add('[email protected]') $MailMessage.Subject = "Exchange 2010 Database Sizes" $MailMessage.IsBodyHtml = $True $MailMessage.Body = $BodyText $SmtpClient = New-object System.Net.Mail.SmtpClient $SmtpClient.Host = 'exserver1.contoso.com' $SmtpClient.Send($MailMessage)
Mit derselben Technik können Sie auch Skripts schreiben, um Nachrichten zu erstellen und zu senden, die Berichte über verschiedenste Aspekte des Systems geben (wobei Sie nicht auf Exchange beschränkt sind, da immer mehr Komponenten über PowerShell zugänglich sind) oder sonstige Ordnungsfunktionen durchführen. Beispielsweise können Sie den stolzen Besitzern neuer Postfächer eine Nachricht senden, um sie im E-Mail-System willkommen zu heißen und Sie über die Umgebung zu informieren, beispielsweise darüber, wo Sie weitere Informationen finden, Probleme melden, Programme herunterladen, interne Websites aufrufen kann usw. Ein solches Skript müsste neue Postfächer in einer Schleife aufspüren, indem es das Erstellungsdatum überprüft, und dann mit ähnlichen Befehlen wie im vorstehenden Code eine Nachricht zusammenstellen. Alternativ können Sie auch die Möglichkeiten von Cmdlet-Erweiterungs-Agents nutzen (siehe http://technet.microsoft.com/de-de/ library/dd335067.aspx) und ihren eigenen Code hinzufügen, sodass beim Aufruf eines Cmdlets zusätzliche Aktionen durchgeführt erden. Beispielsweise können Sie eine Erweiterung für das Cmdlet New-Mailbox erstellen, sodass nach dem Anlegen eines neuen Postfachs automatisch eine Nachricht zu ihm gesandt wird.
157
Die ExchangeVerwaltungsshell
Hilfreicher Code für die Exchange-Verwaltungsshell
Kapitel 3
Die Exchange-Verwaltungsshell
PowerShell im ausführlichen Modus Normalerweise führt die Exchange-Verwaltungsshell alles aus, was Sie von ihr verlangen, ohne Ihnen einen Hinweis auf die Verarbeitung zu geben, die dabei im Hintergrund abläuft. Wenn Sie z.B. die Anweisung geben, ein neues Postfach zu erstellen, dann wird entweder das Postfach erstellt oder es tritt ein Fehler auf, der die Ausführung des Befehls abbricht. Wenn das Problem beim Benutzer liegt, z.B. ein Syntaxfehler oder der Versuch, etwas Sinnloses zu tun, z.B. ein Postfach in einer Datenbank zu erstellen, die es gar nicht gibt, dann können Sie es einfach beheben und einen erneuten Versuch wagen. Manchmal aber müssen Sie genau nachvollziehen, was die Exchange-Verwaltungsshell tut, um einem Problem auf die Spur zu kommen. Vielleicht brauchen Sie Informationen für den Microsoft-Support, damit die Mitarbeiter dort herausfinden können, was in Ihrer Exchange-Bereitstellung schiefläuft, vielleicht aber wollen Sie einfach nur genau wissen, was passiert, wenn Sie einen Befehl ausführen. In jedem Fall können Sie bei einem Befehl den Parameter -Verbose angeben, damit PowerShell Informationen darüber ausgibt, was genau bei der Verarbeitung geschieht. Abbildung 3.14 zeigt einen Teil der Ausgabe, wenn das Cmdlet New-MailboxDatabase eine neue Postfachdatenbank erstellt. Hieran können Sie ablesen, dass die Exchange-Verwaltungsshell den Kontext überprüft, in dem sie ausgeführt wird, einen globalen Katalogserver sucht, die Autorisierung über die rollenbasierte Zugriffssteuerung prüft und nachschaut, ob die Postfachdatenbank bereits existiert. Abbildg. 3.14
Ausführliche Ausgabe in PowerShell
Festlegen von Sprachwerten Es gibt viele Cmdlets in der Exchange-Verwaltungsshell, in der Sie übersetzte oder lokalisierte Werte für Zeichenketten verwenden können. Beispielsweise können Sie beim Erstellen von E-Mail-Infos Text für verschiedene Sprachen angeben. Das Gleiche gilt auch für Nachrichtenklassifizierungen, Aufbewahrungstags usw. Die Frage lautet jedoch, wie Exchange entscheidet, ob ein lokalisierter Wert angezeigt wird oder nicht. Im Allgemeinen gilt die im Folgenden geschilderte Vorgehensweise. Jedem Postfach sind ein oder mehrere Sprachwerte zugewiesen. Wie dies geschieht, erfahren Sie in Kapitel 6. Welche Sprachen einem Postfach zugeordnet sind, können Sie mit folgendem Befehl herausfinden: Get-Mailbox –Identity <mailbox> | Select Languages
158
Ausführungsrichtlinien
Die Sprachen, die das Postfach unterstützt (oder besser gesagt, die der Benutzer des Postfachs spricht), werden im Format des internationalen Codes für Sprachen angegeben. Dabei steht z.B. DE-DE für das in Deutschland gesprochene Deutsch, DE-AT für österreichisches und DE-CH für schweizerisches Deutsch. Der erste Schritt besteht darin, zu ermitteln, welche Sprachen dem Postfach zugeordnet sind. Anschließend sieht Exchange nach, ob es lokalisierte Werte in einer der betreffenden Sprachen gibt, und wenn dies der Fall ist, wird dem Client dieser lokalisierte Wert zur Verfügung gestellt. Zuerst wird nach einer genauen Übereinstimmung zwischen Sprache und Land (z.B. DE-AT) gesucht, und wenn das nicht zu einem Ergebnis führt, nach einer Übereinstimmung nur mit der Sprache (DE). Sind einem Postfach mehrere Sprachen zugeordnet (z.B. DE-DE und DE-CH), nimmt Exchange die erste Übereinstimmung in der Reihenfolge, in der die Sprachen aufgeführt sind. Gibt es keine Übereinstimmungen, wird der Standardwert verwendet, bei dem es sich gewöhnlich um die Sprache handelt, die zur Installation des Servers genommen wurde. Sowohl OWA als auch Outlook 2010 unterstützen lokalisierte Werte für Funktionen wie E-Mail-Infos. Bei älteren Versionen oder anderen Clients muss das nicht der Fall sein.
Ausführungsrichtlinien Die Exchange-Verwaltungsshell ist sehr leistungsfähig, und mit einigen wenigen Cmdlets haben Sie schon eine große Kontrolle über viele Objekte in Exchange. Das wirft die Frage auf, wie Sie die Möglichkeiten der Benutzer einschränken, diese Shellbefehle einzusetzen. Eine erste Schutzmaßnahme bietet die rollenbasierte Zugriffssteuerung. Wie Sie bereits wissen, haben die Benutzer nur Zugriff auf die Cmdlets und Parameter, die in ihrer jeweiligen Rolle verfügbar sind. Aber auch wenn Sie vertrauenswürdigen Benutzern die Rollen zuweisen, die sie für ihre Arbeit brauchen, möchten Sie nicht, dass sie aus dem Internet heruntergeladene oder aus anderen Quellen stammende Skripts ausführen. Zusätzlichen Schutz bieten Ausführungsrichtlinien, die die Bedingungen festlegen, unter denen PowerShell Dateien zur Ausführung lädt. Vier Richtlinie stehen zur Verfügung: Restricted, AllSigned, RemoteSigned und Unrestricted. Mit dem Cmdlet Set-ExecutionPolicy legen Sie fest, welche Richtlinie auf einem Server gilt. Der Standard ist RemoteSigned, was Sie mithilfe von Get-ExecutionPolicy überprüfen können. In diesem Modus erlaubt die Exchange-Verwaltungsshell die Ausführung aller lokal erstellten Skripts. Die Cmdlets in dem Skript müssen dabei natürlich dem Benutzer, der es aufruft, über seine Rolle zur Verfügung stehen. Tabelle 3.2 führt die möglichen Ausführungsrichtlinien und ihre Auswirkungen auf die Sicherheit auf. Wenn Sie versuchen, ein Skript auszuführen, das nicht den Richtlinien gehorcht, meldet PowerShell, dass das Skript nicht geladen werden kann. Um Skripts zu signieren, verwenden Sie das Cmdlet SetAuthenticodeSignature, aber dazu müssen Sie zunächst ein gültiges Zertifikat erwerben. Dieses Zertifikat können Sie selbst generieren oder von einem kommerziellen Anbieter wie VeriSign beziehen. Weitere Informationen darüber, wie Sie Zertifikate erstellen und auf Skripts anwenden, finden Sie unter http://technet.microsoft.com/de-de/library/bb125017.aspx.
159
Die ExchangeVerwaltungsshell
Welche Sprachen werden unterstützt?
Kapitel 3 Tabelle 3.2
Die Exchange-Verwaltungsshell
PowerShell-Ausführungsrichtlinien Ausführungsrichtlinie
Bedeutung
Restricted
Es können keine Skripts ausgeführt werden, nicht einmal solche, die von einem vertrauenswürdigen Herausgeber signiert sind.
AllSigned
Die Exchange-Verwaltungsshell führt alle Skripts aus, die von einem vertrauenswürdigen Herausgeber digital signiert sind.
RemoteSigned
Die Exchange-Verwaltungsshell führt alle lokal erstellen Skripts aus. Nicht signierte Skripts, deren Ursprung außerhalb des Systems liegt (die also z.B. aus dem Internet heruntergeladen wurden), können nicht ausgeführt werden.
Unrestricted
Die Exchange-Verwaltungsshell führt alle Skripts aus. Dieser Modus sollte nur für Testumgebungen verwendet werden.
VORSICHT Offensichtlich ist es ein katastrophaler Fehler, einen Exchange Server-Computer mit der Ausführungsrichtlinie Unrestricted zu betreiben. Sofern Sie keinen sehr guten Grund dafür haben, sollten Sie nicht von der Standardeinstellung abweichen. Um zu einer anderen Richtlinie zu wechseln, verwenden Sie in Exchange Server 2010 das Cmdlet Set-ExecutionPolicy: Set-ExecutionPolicy –ExecutionPolicy Unrestricted
Der Übergang zu einer anderen Richtlinie tritt unmittelbar in Kraft. Testen Sie alle Änderungen, die Sie vornehmen wollen, bevor Sie sie in der Produktion einführen, da dadurch möglicherweise Skripts funktionsunfähig werden können, auf die andere Anwendungen angewiesen sind. Die Ausführungsrichtlinien gelten jeweils für den Server, auf dem sie eingerichtet sind, allerdings wird diese Einstellung in der Systemregistrierung gespeichert, sodass es möglich ist, sie über eine Gruppenrichtlinie auf sämtliche Server der Organisation zu übertragen. Dazu müssen Sie eine Gruppenrichtlinie aufstellen, die den Wert von ExecutionPolicy auf den gewünschten Wert setzt. Den zuständigen Registrierungsschlüssel finden Sie unter: HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft\PowerShell
Da die Einstellung für die Ausführungsrichtlinie in der Systemregistrierung abgelegt wird, verweigert Windows jeden Versuch, den Wert zu ändern, wenn Ihr Konto nicht über das Recht zur Bearbeitung der Registrierung verfügt.
Test-Cmdlets In Exchange Server 2010 finden Sie eine Reihe von Test-Cmdlets, mit denen Sie verschiedene Aspekte des Systems auf ihre Funktionsfähigkeit überprüfen können. Eingeführt wurden diese Cmdlets schon in Exchange Server 2007, doch wurden sie aktualisiert, um auch die Neuerungen von Exchange Server 2010 zu berücksichtigen. Beispielsweise beschwert sich Test-SystemHealth nicht mehr, wenn die Umlaufprotokollierung aktiviert ist, da diese Funktion in Exchange Server 2010 ganz andere Auswirkungen hat, vor allem, wenn es von Datenbanken mehrere Kopien gibt. Diese Cmdlets müssen Sie nur dann ausführen, wenn Sie den Verdacht haben, dass ein Server nicht die erwartete Leistung zeigt, oder wenn es Hinweise auf Probleme gibt, z.B. Beschwerden der Benutzer über die lange Antwortzeiten bei der Verwendung eines Onlineclients. Einige dieser Cmdlets, z.B. Test-MailFlow, werden auch von Microsoft Systems Center Operations Manager bei der Überwachung von Exchange Server-Computern eingesetzt. Wie bei vielen anderen Cmdlets können Sie auch hier den Parameter -Verbose hinzufügen, um mehr Einzelheiten darüber zu sehen, was bei der Verarbeitung des Befehls geschieht. 160
Test-Cmdlets
Das Cmdlet Test-SystemHealth dient dazu, die Konfiguration eines Exchange Server-Computers zu überprüfen. In einem ersten Schritt sieht es auf der Website von Microsoft nach, ob es irgendwelche Aktualisierungen der Konfigurationsdaten und -einstellungen gibt, die berücksichtigt werden müssen. Anschließend untersucht der Befehl die Systemeinstellungen, um offensichtliche Fehler oder Abweichungen von dem zu fanden, was nach Meinung von Microsoft die geeigneten Einstellungen für einen Exchange Server-Computer in der Produktion sind. Zu einem großen Teil sind das die Einstellungen, die Exchange Best Practice Analyzer vorschlägt. Den Befehl, dessen Ausführung Sie in Abbildung 3.15 sehen, können Sie wie folgt interaktiv aufrufen: Test-SystemHealth Abbildg. 3.15
Ausführen von Test-SystemHealth
Standardmäßig werden die Anmeldeinformationen des Kontos, unter dem Sie den Befehl ausführen, auch zum Zugriff auf Exchange verwendet. Wenn Sie Anmeldeinformationen ausdrücklich angeben wollen, können Sie sie im Parameter -ExchangeCredentials übergeben. Außerdem ist es möglich, im Parameter ADCredentials ein anderes Active Directory-Konto für die Anmeldung am Server anzugeben. In beiden Fällen können Sie die erforderlichen Anmeldeinformationen mit Get-Credential abrufen. Wenn das Cmdlet Test-SystemHealth mögliche Probleme feststellt, macht es nähere Angaben dazu. Abbildung 3.15 zeigt die Ausgabe dieses Befehls auf einem Server mit mehreren Rollen, der auf VMware ausgeführt wird. Die angezeigten Probleme sind nicht besonders ernst, erfordern aber, dass sich ein Administrator darum kümmert, damit sie nicht dazu führen, dass die verschiedenen Serverfunktionen nicht mehr richtig funktionieren. Wenn Test-SystemHealth viele Probleme aufdeckt, kann es sehr umständlich sein, die Einzelheiten auf dem Bildschirm zu lesen. In einem solchen Fall können Sie jedoch auch wie folgt den Namen einer Ausgabedatei angeben: Test-SystemHealth –OutFileLocation 'C:\Temp\Test-SystemHealth.log'
Dabei werden eine Übersichtsdatei im Textformat mit Angaben über die durchgeführten Tests und eine XML-Datei mit sehr viel mehr Einzelheiten über die Überprüfungen und deren Ergebnisse erstellt. Anhand dieser Dateien können Sie Probleme im System aufspüren. Bis jetzt ist mir noch kein Grund dafür untergekommen, die Ausgabe zu unterdrücken, da die Supportmitarbeiter genau solche Daten benötigen, um Probleme zu lösen.
161
Die ExchangeVerwaltungsshell
Test-SystemHealth
Kapitel 3
Die Exchange-Verwaltungsshell
Test-ServiceHealth Das Cmdlet Test-ServiceHealth ermittelt, ob alle Windows-Dienste, von denen Exchange abhängig ist, verfügbar sind. Diese Überprüfung wird für jede auf dem Server installierte Rolle durchgeführt. Die Ausgabe sieht wie folgt aus: Test-ServiceHealth Role : Mailbox Server Role RequiredServicesRunning : True ServicesRunning : {IISAdmin, MSExchangeADTopology, MSExchangeIS, MSExchangeMailboxAssistants, MSExchangeMailSubmission, MSExchangeRepl, MSExchangeRPC, MSExchangeSA, MSExchangeSearch, MSExchangeServiceHost, MSExchangeThrottling, MSExchangeTransportLogSearch, W3Svc, WinRM} ServicesNotRunning : {} Role : Client Access Server Role RequiredServicesRunning : True ServicesRunning : {IISAdmin, MSExchangeAB, MSExchangeADTopology, MSExchangeFBA, MSExchangeFDS, MSExchangeMailboxReplication, MSExchangeProtectedServiceHost, MSExchangeRPC, MSExchangeServiceHost, W3Svc, WinRM} ServicesNotRunning : {} Role : Hub Transport Server Role RequiredServicesRunning : True ServicesRunning : {IISAdmin, MSExchangeADTopology, MSExchangeEdgeSync, MSExchangeServiceHost, MSExchangeTransport, MSExchangeTransportLogSearch, W3Svc, WinRM} ServicesNotRunning : {}
Test-MAPIConnectivity Das Cmdlet Test-MAPIConnectivity überprüft, ob MAPI-Clients (Messaging Application Programming Interface) Kontakt mit einer Datenbank aufnehmen können. Dazu meldet es sich an einem Postfach in der Datenbank an und versucht, eine Liste der Elemente im Posteingang abzurufen. Ist kein Postfach angegeben, verwendet das Cmdlet das Systempostfach in der Zieldatenbank. Der folgende Befehl stellt einen Kontakt zu meinem Postfach her. In der Ausgabe wird die Wartezeit (oder Latenz, daher Latency) in »Ticks« angegeben. In diesem Fall betrug sie elf Millisekunden. Wenn ein Verbindungsversuch nicht innerhalb von zehn Sekunden zu einer Antwort führt, bricht Exchange ihn ab. Bei Bedarf können Sie dieses Zeitlimit ändern, aber wenn nach zehn Sekunden noch keine Antwort eintrifft, ist das ein sicheres Zeichen dafür, dass ein Server unter einer enormen Belastung steht. Test-MAPIConnectivity –Identity '[email protected]' RunspaceId Server Database Mailbox Result Latency
162
: : : : : :
8795186d-ef1e-4f19-a4aa-f8d8d9967e9f London-EX1 VIP Data Redmond, Tony Success 00:00:00.0114335
Error Identity IsValid
: : : True
Wenn Sie den Parameter -MonitoringContext hinzufügen und auf $True setzen, erhalten Sie auch Informationen über einschlägige Systemereignisse und Leistungsindikatoren des Systemmonitors, die sonst nicht angezeigt werden. Administratoren können Test-MAPIConnectivity einsetzen, um zu überprüfen, ob ein Server ordnungsgemäß funktioniert und innerhalb annehmbarer Zeiträume auf Benutzeranforderungen reagiert. Mit dem folgenden Onlineskript können Sie die Erreichbarkeit aller Datenbanken auf einem Server testen und sich die Wartezeit auf die Verbindung in Millisekunden anzeigen lassen. Test-MAPIConnectivity –Server 'ExServer1' | % {Write-Host "Database:" $_.Server "\" $_.Database "Result:" $_.Result "Milliseconds:" $_.Latency.Milliseconds $_.Error}
Test-ReplicationHealth Das Cmdlet Test-ReplicationHealth wurde in Exchange Server 2007 SP1 eingeführt, um das korrekte Funktionieren der fortlaufenden Clusterreplikation und der fortlaufenden Standbyreplikation zu prüfen. In Exchange Server 2010 wurde dieser Befehl erweitert, sodass Sie mit ihm jetzt sämtliche Gesichtspunkte der Protokollreplikation innerhalb einer Datenbankverfügbarkeitsgruppe testen können. Wenn Sie den Befehl ausführen, geben Sie einen Postfachserver an, der Mitglied einer Datenbankverfügbarkeitsgruppe ist: Test-ReplicationHealth –id ExServer1 Server -------ExServer1 ExServer1 ExServer1 ExServer1 ExServer1 ExServer1 ExServer1 ExServer1 ExServer1 ExServer1 ExServer1 ExServer1 ExServer1 ExServer1 ExServer1
Check -------ClusterService ReplayService ActiveManager TasksRpcListener TcpListener DagMembersUp ClusterNetwork QuorumGroup FileShareQuorum DBCopySuspended DBCopyFailed DBInitializing DBDisconnected DBLogCopyKeepingUp DBLogReplayKeepingUp
Result -------Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed Passed
Error -------
163
Die ExchangeVerwaltungsshell
Test-Cmdlets
Kapitel 3
Die Exchange-Verwaltungsshell
Test-ExchangeSearch Das Cmdlet Test-ExchangeSearch überprüft, ob die Inhaltsindizierung und die Suche ordnungsgemäß funktionieren. Bei diesem Test können Sie die Postfachdatenbank oder das Postfach angeben, das Sie überprüfen möchten. Exchange erstellt einige einfache Elemente in der Zieldatenbank, schaut nach, ob sie indiziert wurden, und räumt dann wieder auf, indem es die Testdaten entfernt. Elemente wie PDFs oder andere Sonderformate, die zur Indizierung einen IFilter benötigen, werden nicht überprüft. Um die Suchfunktion in einer Postfachdatenbank zu überprüfen, verwenden Sie den Befehl wie folgt, wobei als Zielpostfach das Systempostfach in der betreffenden Datenbank genommen wird: Test-ExchangeSearch –MailboxDatabase 'VIP Data'
Der Test eines bestimmten Postfachs läuft wie folgt ab: Test-ExchangeSearch –Identity '[email protected]' Database ----------DB2
Server ------ExServer2
Mailbox --------DSimpson
ResultFound ------------True
SearchTime -----------2
Error -------
Test-OWAConnectivity Das Cmdlet Test-OWAConnectivity prüft, ob Zugriff auf die Anwendung OWA besteht. Diesen Test können Sie allgemein für einen Clientzugriffsserver durchführen oder für einen bestimmten URL. Um zu überprüfen, ob für alle von OWA auf einem Clientzugriffsserver verwendeten virtuellen Verzeichnisse eine Verbindung möglich ist, gehen Sie folgendermaßen vor: Test-OWAConnectivity –ClientAccessServer ExServer4 ClientAccessServer MailboxServer URL Scenario Result Latency (ms) Error ------------------ ------------- ----------- ------- ----------ExServer4.contoso. ExServer4. https://ExServer4. Logon Success 112.66
Um dagegen zu prüfen, ob für einen bestimmten URL Verbindung besteht (gewöhnlich für den URL, der für den Zugriff auf OWA verwendet wird), ändern wir den Befehl wie folgt ab. Wir übergeben die Anmeldeinformationen des Benutzerpostfachs, das für den Test verwendet werden soll. Dieses Postfach muss sich auf einem Postfachserver im selben Active Directory-Standort befinden wie der Clientzugriffsserver. Außerdem geben wir an, dass bei diesem Test alle SSL-Zertifikate ohne nähere Untersuchung akzeptiert werden sollen. Das kann notwendig sein, wenn Sie die OWA-Verbindung überprüfen, nachdem Sie einen neuen Clientzugriffsserver eingerichtet haben. Wenn Sie später die erforderlichen Zertifikate installiert haben, können Sie deren korrektes Funktionieren überprüfen, indem Sie auf den Parameter -TrustAnySSLCertificate verzichten. Test-OWAConnectivity –URL https://ExServer2.contoso.com/owa -MailboxCredential (Get-Credential contoso\TRedmond) -TrustAnySSLCertificate
164
Test-Cmdlets
Das Cmdlet Test-ECPConnectivity ist neu in Exchange Server 2010. Es prüft, ob über einen angegebenen Clientzugriffsserver eine Verbindung zur Exchange-Systemsteuerung (Exchange Control Panel, ECP) möglich ist. Dabei erfolgen eine Testanmeldung am Systempostfach und anschließend ein Aufruf des Exchange-Webdienstes, um sicherzustellen, dass die Exchange-Systemsteuerung korrekt funktioniert. Das Ergebnis wird als Erfolg oder Fehler gemeldet, wobei zusätzlich die Wartezeit des Aufrufs angegeben wird. Eine lange Wartezeit, wie Sie im folgenden Beispiel angezeigt wird, ist immer ein Anlass zur Sorge, es sei denn, es handelt sich um den ersten Versuch, nach dem Starten des Servers auf die Exchange-Systemsteuerung zuzugreifen. In diesem Fall kann es sein, dass die Anwendung erst innerhalb der Internetinformationsdienste »warmlaufen« muss. Führen Sie den Test dann mehrmals durch und sehen Sie nach, ob sich die Wartezeit beim Zugriff auf die Exchange-Systemsteuerung verkürzt. Wenn nicht, müssen Sie nachforschen, ob der Server und die Anwendung normal funktionieren, indem Sie sich als Benutzer an der Exchange-Systemsteuerung anmelden. Test-ECPConnectivity –Identity ExServer1 CasServer --------ExServer1 ExServer1
LocalSite ---------Dublin Dublin
Scenario ---------Logon WebServiceCall
Result -------Success Success
Latency(MS) ----------237.70 0.00
Error -----
Test-MRSHealth Das Cmdlet Test-MRSHealth wurde in Exchange Server 2010 neu eingeführt und überprüft, ob der Postfachreplikationsdienst (Mailbox Replication Service, MRS) auf einem Clientzugriffsserver korrekt funktioniert. Getestet werden drei Aspekte, nämlich ob der Dienst überhaupt läuft, ob er auf einen RPC-Ping reagiert und ob er nach Verschiebeanforderungen in Warteschlangen Ausschau hält. In dem folgenden Beispiel prüfen wir, ob der Postfachreplikationsdienst auf dem Server ExServer2 läuft. Die Ergebnisse zeigen, dass alles in Ordnung ist. Test-MRSHealth –Identity ExServer2 Check : ServiceCheck Passed : True Message : Der Postfachreplikationsdienst wird ausgeführt. Identity : ExServer2 IsValid : True Check : RPCPingCheck Passed : True Message : Der Postfachreplikationsdienst reagiert auf RPC-Ping. Serverversion: 14.0.682.0 caps:01. Identity : ExServer2 IsValid : True
165
Die ExchangeVerwaltungsshell
Test-ECPConnectivity
Kapitel 3
Die Exchange-Verwaltungsshell
Check : QueueScanCheck Passed : True Message : Der Postfachreplikationsdienst untersucht MDB-Warteschlangen auf Aufträge. Alter des letzten Suchvorgangs: 00:08:49.1792211. Identity : ExServer2 IsValid : True
Testen der POP3- und IMAP4-Anbindung Die Cmdlets Test-POP3Connectivity und Test-IMAP4Connectivity überprüfen, ob die Dienste für POP3 und IMAP4 normal ausgeführt werden und ob ein Postfach Nachrichten erstellen und über diese Protokolle senden kann. Der grundlegende Befehl, um mit den Anmeldeinformationen eines Benutzerkontos eine Überprüfung auf einem bestimmten Clientzugriffsserver durchzuführen, lautet folgendermaßen: Test-IMAP4Connectivity –ClientAccessServer ExServer1 –MailboxCredential (Get-Credential Contoso\TRedmond) CasServer --------ExServer1
LocalSite ---------Dublin
Scenario ----------Test IMAP4 C...
Result -------Success
Latency(MS) ----------385.62
Error -------
Um zu überprüfen, ob auch für POP3-Verbindungen alles in Ordnung ist, verwenden Sie TestPOP3Connectivity mit der identischen Syntax.
Testen der E-Mail-Übermittlung Das Cmdlet Test-MailFlow prüft, ob das Absenden, der Transport und die Zustellung von E-Mails reibungslos funktionieren. Bei diesem Test können Sie vom System erstellte Nachrichten von einem Postfachserver an einen anderen, an eine bestimmte Postfachdatenbank oder an eine Remoteadresse senden lassen. Die Testnachrichten enthalten die Anforderung einer Übermittlungsbestätigung, sodass Exchange eine Möglichkeit hat, um die komplette Zustellzeit zu bestimmen. Bei einem erfolgreichen Test wird in der Ausgabe die Gesamtdauer der gesamten Operation in Sekunden angegeben. Um ganz allgemein die Zustellung von Nachrichten von einem Postfachserver zu überprüfen, melden Sie sich an dem Server an und geben einfach Test-MailfFlow ein. Exchange nimmt dann Verbindung mit dem Systempostfach in den Datenbanken auf dem Server auf und versucht darüber Nachrichten zu senden. Eine bessere Methode besteht darin, Exchange die verfügbaren Postfachserver finden und als Ziele für den Test verwenden zu lassen. Dazu gehen Sie folgendermaßen vor: Test-MailFlow –AutoDiscoverTargetMailboxServer TestMailflowResult MessageLatencyTime IsRemoteTest
166
: Success : 00:00:02.4773026 : True
Test-Cmdlets
Wenn Sie Probleme mit einem bestimmten Server haben, können Sie ihn als Zielserver angeben:
Bei diesem Test können Sie auch noch präziser vorgehen und überprüfen, ob die E-Mail-Übermittlung und -Zustellung in einer bestimmten Postfachdatenbank richtig funktionieren: Test-MailFlow –TargetDatabase 'VIP Mailboxes'
Bei den bis jetzt vorgestellten Befehlen gingen Testnachrichten nur zwischen den Systempostfächern in den überprüften Datenbanken hin und her. Sie können jedoch auch die E-Mail-Zustellung zu einer Remoteadresse prüfen. Geben Sie dazu in Exchange eine SMTP-Adresse an, an die dann eine Testnachricht wie die in Abbildung 3.16 gesendet wird. Test-MailFlow –TargetEmailAddress '[email protected]' Abbildg. 3.16
Eine vom Cmdlet Test-MailFlow gesendete Testnachricht
Es kann vorkommen, dass Exchange Tests in Remotedomänen als Fehlschlag meldet, wenn die erfolgreiche Zustellung der Nachricht nicht bestätigt werden kann. Das wiederum kann daran liegen, dass der Remoteserver zu lange braucht, um eine Übermittlungsbestätigung zu senden, oder dass das externe E-Mail-Sytem solche Bestätigungen überhaupt nicht liefert. Wenn Sie dagegen eine lokale SMTP-Adresse als Zielpostfach angeben, werden Sie höchstwahrscheinlich eine Erfolgsmeldung bekommen, da die gesamte Verarbeitung innerhalb derselben Exchange-Organisation stattfindet. Sollte der Test innerhalb der Organisation fehlschlagen, ist das ein Zeichen dafür, dass in Ihrem Transportsystem ein sehr ernstes Problem vorliegt. Die Einstellung, die festlegt, bei welcher Wartezeit ein Test als »Erfolg« und bei welcher als »Fehlschlag« gewertet wird, können Sie im Parameter -ErrorLatency ändern. Für lokale Tests beträgt die Standardeinstellung 15 Sekunden, für Remotetests 180. Wichtig ist auch der Parameter -ExecutionTimeOut, der angibt, wie lange Exchange insgesamt wartet, bevor der Test abgebrochen wird. Die Standardeinstellung beträgt 240 Sekunden, aber es ist möglich, dass ein Remoteserver länger braucht, um zu antworten.
167
Die ExchangeVerwaltungsshell
Test-Mailflow –TargetMailboxServer 'ExServer1'
Kapitel 3
Die Exchange-Verwaltungsshell
Welche Einschränkungsmöglichkeiten haben wir? Wenn Sie sich nicht daran stören, in einer Befehlszeilenumgebung zu arbeiten, ist die Exchange-Verwaltungsshell ein hervorragendes Werkzeug, um Verwaltungsaufgaben in Exchange zu erledigen. Falls es keine Möglichkeiten gäbe, diesen Zugriff zu beschränken, könnte jemand in der Exchange-Verwaltungsshell gewaltigen Schaden an der Exchange-Organisation ausrichten, indem er beispielsweise mit einer einzigen Codezeile sämtliche Postfächer in einer Datenbank entfernt. Offensichtlich dürfen nur die Personen, die die Organisation in ihrem gesamten Umfang bearbeiten müssen, in der Lage sein, solche drastischen Maßnahmen durchzuführen. Traditionell werden solche Einschränkungen über Berechtigungen und Rechte gesteuert. Exchange Server 2010 verfolgt jedoch einen anderen Ansatz, nämlich die rollenbasierte Zugriffssteuerung. Alle Administratoren müssen solide Grundkenntnisse darin mitbringen, und das ist auch der Punkt, um den wir uns als Nächstes kümmern werden.
168
Rollenbasierte Zugriffssteuerung
Kapitel 4
Rollenbasierte Zugriffssteuerung
In diesem Kapitel: Grundlagen der rollenbasierten Zugriffssteuerung
171
Rollen
174
Bereiche
177
Rollengruppen
179
Rollenzuweisung
182
Zuweisungsrichtlinien
189
Verbesserungen bei der rollenbasierten Zugriffssteuerung in Service Pack 1
191
Rollen in der Exchange-Systemsteuerung
200
Zurechtfinden in der rollenbasierten Zugriffssteuerung
200
Andere Verwaltungswerkzeuge
201
169
Kapitel 4
Rollenbasierte Zugriffssteuerung
Vom technischen Standpunkt aus gesehen ist die Einführung von Datenbankverfügbarkeitsgruppen die bemerkenswerteste Neuerung in Exchange Server 2010, doch die am weitesten reichenden Auswirkungen auf alle Teile des Produkts hat das neue Berechtigungsmodell auf der Grundlage der rollenbasierten Zugriffssteuerung. Von allen neuen Elementen ist es daher gerade diese neue Form der Zugriffssteuerung, die Administratoren unbedingt beherrschen müssen. Im Großen und Ganzen geht es bei der rollenbasierten Zugriffssteuerung darum, den Zugriff auf Systeme und Daten so zu beschränken, dass Administratoren und Benutzer jeweils nur die Möglichkeiten haben, die sie zur Erledigung ihrer Aufgaben brauchen. Mit anderen Worten, sie bekommen nur Zugriff auf die Informationen, die sie wirklich benötigen, und nicht auf einen Haufen Daten, die sie nichts angehen. Die rollenbasierte Zugriffssteuerung ist kein neues Prinzip, und sie wurde auch schon in anderen Betriebssystemen und Anwendungen wie HP-UX, Linux, Oracle, SAP R/3 usw. implementiert. In früheren Versionen von Exchange wurden Windows-Zugriffsssteuerungslisten (Access Control Lists, ACLs) herangezogen, um den Benutzern und Administratoren die erforderlichen Berechtigungen für ihre Aufgaben zu gewähren. Zugriffssteuerungslisten sind eine wirkungsvolle Möglichkeit, um Berechtigungen in gut strukturierten Umgebungen zu verwalten, die sich nicht so leicht ändern. Windows selbst und viele der Anwendungen, die unter diesem Betriebssystem ausgeführt werden, fallen in diese Kategorie. Exchange ist jedoch viel dynamischer und umfasst in sehr großen Bereitstellungen Hunderttausende von Objekten. In einer solchen dynamischen Umgebung mit so vielen Objekten die Zugriffssteuerungslisten immer auf dem neuesten Stand zu halten, ist eine echte Herausforderung. Die Erfahrung in der Praxis hat gezeigt, dass Änderungen an Zugriffssteuerungslisten häufig falsch vorgenommen werden, dass die Listen selbst schwer verständlich und daher auch schwer zu korrigieren sind, wenn etwas schiefgeht. Außerdem kann es bei Softwareaktualisierungen und Patches zu Störungen kommen. Ein weiteres Problem besteht darin, dass sich das herkömmliche Modell, in dem Berechtigungen für Objekte erstellt, aktualisiert und festgelegt werden, häufig nicht so gut in die aufgabenorientierte Umgebung einer Anwendung wie Exchange übertragen lässt. Dort muss sich das Berechtigungsmodell auch für Situationen eignen, in denen z.B. das Supportpersonal das Kennwort eines Benutzers zurücksetzen können muss, ohne aber gleichzeitig in der Lage zu sein, andere Einstellungen des Benutzerkontos zu ändern. Die rollenbasierte Zugriffssteuerung bietet präzise Steuerungsmöglichkeiten, wie sie für solche Situationen erforderlich sind. Es kann zwar durchaus sein, dass Probleme auftreten, wenn sich Administratoren in die rollenbasierte Zugriffssteuerung einarbeiten und von dem früheren Berechtigungsmodell zum neuen wechseln, doch bei Microsoft ist man der Ansicht, dass die Einführung des neuen Modells in Exchange auf lange Sicht die Verwaltung vereinfacht. Außerdem sollte die rollenbasierte Zugriffssteuerung die Arbeit für Administratoren enorm erleichtert, da sie nicht mehr täglich mit Zugriffssteuerungslisten hantieren müssen. Stattdessen weisen Administratoren den Benutzern die Fähigkeiten, die sie zur Erfüllung ihrer Aufgaben benötigen, dadurch zu, dass sie die Benutzer zu Rollengruppen hinzufügen. Die erforderliche Pflege der Zugriffssteuerungslisten erledigt die rollenbasierte Zugriffssteuerung im Hintergrund. Den Einfluss, den die rollenbasierte Zugriffssteuerung auf alle Teile von Exchange Server 2010 ausübt, kann man unmöglich übersehen. Es bedarf eines 300-Seiten-Buches, um alle Aspekte dieses neuen Modells ausführlich zu beschreiben. In diesem Kapitel versuche ich daher gar nicht erst, das Thema umfassend zu behandeln, sondern stelle die Grundlagen vor, sodass Sie mit der Arbeit beginnen können. Darüber hinaus ermuntere ich Sie dazu, nachzuforschen, wie Sie die rollenbasierte Zugriffssteuerung am besten einsetzen können, um sich die Verwaltung Ihrer Organisation zu erleichtern.
170
Grundlagen der rollenbasierten Zugriffssteuerung In Erklärungen von Microsoft über die rollenbasierte Zugriffssteuerung in Exchange Server 2010 wird häufig ein Dreieck gezeigt, um die Beziehungen zwischen Rollen, Rollengruppen, Bereichen und Zuweisungen darzustellen (siehe Abbildung 4.1). Abbildg. 4.1
Das Dreieck der rollenbasierten Zugriffssteuerung
Bereich (die Objekte, die eine Rolle bearbeiten kann)
Rollenzuweisung (die Verbindung zwischen allen anderen Komponenten)
Rolle (was getan werden kann)
Rollengruppe (wer etwas tun kann)
Die Hauptelemente der in Exchange Server 2010 implementierten rollenbasierten Zugriffssteuerung sind: 쐍 Verwaltungsrolle Eine Zusammenstellung von Rolleneinträgen, die bestimmen, welche Cmdlets und Parameter ein Benutzer ausführen darf. 쐍 Verwaltungsrollengruppe Ein Behälter für mehrere Verwaltungsrollen, die zusammengenommen einem Benutzer erlauben, eine Rolle auszuüben, z.B. die Empfängerverwaltung. Exchange Server 2010 enthält einen Standardsatz von Verwaltungsrollengruppen, doch können Sie auch eigene Gruppen für Situationen definieren, die durch die Standardgruppen nicht abgedeckt werden. 쐍 Verwaltungsrollenzuweisung Die Möglichkeit, eine Verwaltungsrolle einem einzelnen Benutzer oder den Mitgliedern einer Rollengruppe (universelle Sicherheitsgruppe) zuzuweisen. 쐍 Verwaltungsrollen-Zuweisungsrichtlinien Verwaltungsrollengruppen sind vor allem dazu gedacht, Administratoren die Gelegenheit zu geben, Aufgaben wie die Empfängerverwaltung durchzuführen. Die Möglichkeiten der Benutzer, mit persönlichen Daten umzugehen, wird durch Rollenzuweisungsrichtlinien gesteuert. Im Lieferzustand bringt Exchange Server 2010 eine Standardrollenzuweisungsrichtlinie mit, die festlegt, wie Benutzer die Informationen in ihren Profilen (Telefonnummern, Anzeigename usw.) und die Mitgliedschaft in Verteilergruppen ändern können. Wenn ein Postfach erstellt oder auf Exchange Server 2010 verschoben wird, so wird den Benutzern automatisch die Standardrollenzuweisungsrichtlinie zugewiesen, sofern nicht ausdrücklich eine andere Richtlinie in Kraft gesetzt wird. Für ein Postfach kann immer nur eine Zuweisungsrichtlinie auf einmal gelten. 171
Rollenbasierte Zugriffssteuerung
Grundlagen der rollenbasierten Zugriffssteuerung
Kapitel 4
Rollenbasierte Zugriffssteuerung
쐍 Verwaltungsrollenbereich Die Menge der Objekte, mit der eine Verwaltungsrolle arbeiten kann. Eine Rolle wie Organization Management hat als Bereich die komplette Organisation, da ein Benutzer mit dieser Rolle sämtliche Objekte in der gesamten Organisation bearbeiten können muss. Andere Rollen dagegen sind auch einen kleineren Bereich wie z.B. eine Organisationseinheit in Active Directory beschränkt, um eine Feinsteuerung der Verwaltungsmöglichkeiten zu erlauben, z.B. die Einschränkung auf die Postfächer einer bestimmten Region. 쐍 Verwaltungsrolleneinträge Die Einträge gewähren den Zugriff auf bestimmte Cmdlets, um einen Benutzer in die Lage zu versetzen, genau umrissene Aufgaben zu erledigen. Beispielsweise erlaubt der Zugriff auf das Cmdlet New-Mailbox einem Benutzer, neue Postfächer zu erstellen. Es ist auch möglich, Rolleneinträge auf bestimmte Parameter eines Cmdlets zu beschränken. Eine andere Möglichkeit, um sich eine Vorstellung von der rollenbasierten Zugriffssteuerung zu verschaffen, besteht darin, sie aus dem Blickwinkel der Aufgaben zu betrachten, die ein Administrator oder Endbenutzer in Exchange erfüllen muss. Um die Rechte zuzuweisen, die diese beiden Personengruppen für ihre Arbeit benötigen, werden bei der rollenbasierten Zugriffssteuerung folgende zwei Methoden angewendet: 쐍 Administratoren und andere besondere Benutzer, die betriebliche Aufgaben an Exchange ServerComputern durchführen müssen, erhalten die dazu erforderlichen Rechte über die Mitgliedschaft in den passenden Rollengruppen, wobei jede Rollengruppe aus einer Anzahl von Rollen besteht. Um einem Administrator die Berechtigung für irgendeine Tätigkeit zu gewähren, müssen Sie ihm einfach nur die passende Verwaltungsrolle zuweisen, indem Sie ihn in die entsprechende Rollengruppe aufnehmen. HINWEIS Die Rollengruppe Organization Management hat die umfassendsten Berechtigungen, da darin praktisch alle anderen in Exchange verfügbaren Rollen enthalten sind (mit wenigen Ausnahmen). 쐍 Benutzer müssen nicht in Rollengruppen aufgenommen werden, um mit Exchange umgehen zu können, da der Zugriff auf ihre Daten (Postfächer und Postfacheinstellungen) über die Standardrollenzuweisungsrichtlinie gesteuert wird. Das ist ein langer und komplizierter Name für »Standardeinstellungen«. Bevor wir uns im Einzelnen ansehen, was Rollen, Zueisungen und Richtlinien bedeuten, gebe ich Ihnen in Tabelle 4.1 eine Grundlage für das Folgende. In dieser Tabelle sind verschiedene Aufgaben, die unterschiedliche Mitarbeiter in einer Exchange-Organisation erledigen müssen, zusammen mit der Rollengruppe aufgeführt, die den Zugriff auf die jeweils erforderlichen Berechtigungen gewährt. Tabelle 4.1
172
Erforderliche Rollengruppen für verschiedene Aufgaben Aufgabe
Erforderliche Rollengruppe
Bemerkungen
Ich möchte der allmächtige Manager der gesamten Exchange-Organisation sein.
Organization Management
Manche Rollen müssen ausdrücklich delegiert werden, bevor selbst Mitglieder der Gruppe Organization Management eine Aufgabe ausführen können. Da beste Beispiel dafür ist die Rolle Mailbox ImportExport, die ausdrücklich einem Konto zugeordnet werden muss, damit der betreffende Benutzer Zugriff auf die Cmdlets für den Import und Export von Postfächern bekommt.
Grundlagen der rollenbasierten Zugriffssteuerung
Erforderliche Rollengruppen für verschiedene Aufgaben (Fortsetzung) Aufgabe
Erforderliche Rollengruppe
Bemerkungen
Ich möchte alle Objekte in der Exchange-Situation einsehen können, muss aber nichts bearbeiten.
View-Only Organization Management
Inhaber dieser Rolle können Einzelheiten über Konfigurationsobjekte (Server, Connectors usw.) und Empfänger in der gesamten Organisation einsehen.
Ich möchte Postfächer und Verteilergruppen bearbeiten.
Recipient Management
Mitglieder dieser Rollengruppe können jegliche E-Mail-aktivierten Objekte (außer öffentliche Ordner) erstellen, bearbeiten und löschen.
Ich möchte den Benutzern helfen, die Einstellungen ihrer Postfächer zu pflegen.
Help Desk
Die Rollengruppe Help Desk enthält die Rollen User Options und View-Only Recipients. In einigen Unternehmen kann diese Zusammenstellung die Effektivität des Supportpersonals einschränken, weshalb die Möglichkeit besteht, Rollengruppen zu bearbeiten und ihnen weitere Rollen hinzuzufügen, um die Möglichkeiten der Gruppenmitglieder zu erweitern.
Ich möchte die Konfigurationseinstellungen des Exchange Server-Computers verwalten.
Server Management
Mitglieder dieser Rollengruppe sind nicht in der Lage, auch Empfängerobjekte zu verwalten, es sei denn, sie sind gleichzeitig Mitglieder der Rollengruppe Recipient Management. Es ist möglich, Änderungen vorzunehmen und die Verwaltungsmöglichkeiten der Mitglieder dieser Rollengruppe auf einzelne Server oder Datenbanken zu beschränken.
Ich möchte Discoverysuchen durchführen und Beweissicherung durchführen können.
Discovery Management
Diese Rollengruppe erlaubt den Mitgliedern auch die Verwaltung der Vorgänge, mit denen Postfächer aus rechtlichen Gründen eingefroren werden.
Ich muss öffentliche Ordner verwalten können.
Public Folder Management
Mitglieder dieser Gruppe können die Verwaltungskonsole für öffentliche Ordner verwenden (die über die Toolbox der Exchange-Verwaltungskonsole zugänglich ist), um öffentliche Ordner zu verwalten.
Ich muss verschiedene Aspekte der Aufbewahrung von Daten in der Organisation verwalten können.
Records Management
Diese Rollengruppe erlaubt ihren Mitgliedern, die Administratorüberwachung, die Nachrichtenverfolgung, Journale, Aufbewahrungsrichtlinien und -tags, Nachrichtenklassifikationen und Transportregeln zu verwalten.
Ich muss die Unified-Messaging-Server verwalten und Objekte wie Wählpläne erstellen können.
UM Management
Diese Rollengruppe erlaubt Administratoren, die Anwendung Exchange Unified Messaging zu verwalten (falls sie in der Organisation bereitgestellt ist).
Nachdem Sie nun eine gewisse Vorstellung davon haben, wie sich die rollenbasierte Zugriffssteuerung auf die Arbeit von Administratoren auswirkt, und Sie die formalen Definitionen der verschiedenen Begriffe kennen, mit denen wir es zu tun bekommen, sehen wir uns an, was diese verschiedenen Elemente in der Praxis bedeuten.
173
Rollenbasierte Zugriffssteuerung
Tabelle 4.1
Kapitel 4
Rollenbasierte Zugriffssteuerung
Rollen Exchange Server 2010 SP1 enthält 69 integrierte Rollen für den Großteil der Aufgaben, die Administratoren und Benutzer in Exchange-Organisationen durchführen müssen. Die meisten davon sind für administrative Aufgaben da, z.B. für die Pflege von Adresslisten und die Verwaltung öffentlicher Ordner, doch gibt es auch einige wenige Rollen (die alle mit My beginnen), mit denen Benutzern Rechte zur Verwaltung ihrer Postfacheinstellungen und anderer Optionen eingeräumt werden. Um sich eine vollständige Liste der Rollen anzeigen zu lassen, verwenden Sie folgenden Befehl: Get-ManagementRole
Im Grunde genommen besteht eine Rolle aus den Cmdlets und Parametern, die Exchange den Inhabern der Rolle zu verwenden erlaubt. Beispielsweise umfasst die Rolle Message Tracking sechs Cmdlets, die Sie brauchen, um Nachrichtenverfolgungsprotokolle durchsuchen zu können. Das können Sie sich wie folgt anzeigen lassen: Get-ManagementRoleEntry 'Message Tracking\*' Name ------Set-ADServerSettings
Role ----Message Tracking
Get-Recipient
Message Tracking
New-OrganizationRelationship
Message Tracking
Write-AdminAuditLog
Message Tracking
Get-MessageTrackingReport
Message Tracking
Get-Mailbox
Message Tracking
Search-MessageTrackingReport Set-OrganizationRelationship Get-MessageTrackingLog
Message Tracking Message Tracking Message Tracking
Get-ExchangeServer
Message Tracking
Get-DomainController
Message Tracking
Parameters --------------{ConfigurationDomainController, Confirm, Debug,. {Anr, BookmarkDisplayName, Credential, Debug, {DeliveryReportEnabled, DomainNames, Name} {Comment, Confirm, Debug, DomainController, {BypassDelegateChecking, Debug, DetailLevel, {Anr, Arbitration, Archive, Credential, Database, {BypassDelegateChecking, Confirm, Debug, {DeliveryReportEnabled, Identity} {Debug, DomainController, End, ErrorAction, {Debug, Domain, DomainController, ErrorAction, {Credential, Debug, DomainName, ErrorAction,
Die Erläuterungen über die Beziehung zwischen der Exchange-Verwaltungsshell und der rollenbasierten Zugriffssteuerung in Kapitel 3, »Die Exchange-Verwaltungsshell«, sollten deutlich gemacht haben, wie Cmdlets für Benutzer zugänglich gemacht und während der Initialisierung in die Verwaltungsshell geladen werden. Wenn ein Benutzer durch die Mitgliedschaft in einer Rollengruppe z.B. die Rolle Message Tracking innehat, lädt die Shell die zugehörigen elf Cmdlets und die verfügbaren Parameter, damit sie in der Sitzung zur Verfügung stehen (bei Exchange Server 2010 ohne SP1 sehen Sie nur sechs Cmdlets).
174
Die Bezeichnungen der Rolleneinträge bestehen aus dem Namen der Rollengruppe und des Cmdlets. Wenn Sie wie im vorstehenden Beispiel in dem Befehl Get-ManagementRoleEntry ein Sternchen als Jokerzeichen verwenden, weisen Sie Exchange an, alle Cmdlets auszugeben, die der Rollengruppe zugewiesen sind. Um Informationen über ein bestimmtes Cmdlet zu erhalten, z.B. die zulässigen Parameter, müssen Sie den Namen des Cmdlets angeben: Get-ManagementRoleEntry 'Move Mailboxes\Get-Recipient' | Format-List
Mit Get-ManagementRole können Sie ermitteln, welchen Rollen ein bestimmtes Cmdlet zugewiesen ist. Um beispielsweise alle Rollen aufzulisten, die mit Set-Mailbox Postfacheinstellungen ändern können, geben Sie Folgendes ein: Get-ManagementRole -cmdlet 'Set-Mailbox'
Begrenzen des Zugriffs durch Rollenzuweisungsrichtlinien Mit Rollenzuweisungen beschränken Sie den Zugriff präzise bis auf einzelne Parameter eines Cmdlets. Damit können Benutzer daran gehindert werden, bestimmte Datenelemente zu ändern. Beispielsweise erlaubt die standardmäßige Rollenzuweisungsrichtlinie den Benutzern, über die Exchange-Systemsteuerung ihre Kontaktinformationen zu ändern, aber nicht ihren Anzeigenamen. Um herauszufinden, welche Rollenzuweisung hierfür verantwortlich ist, können Sie z.B. nach den Zuweisungen, die die Nutzung des Cmdlets Set-User zur Änderung der Mobiltelefonnummer steuern (eines der Datenelemente, die die Benutzer gemäßt der Standardrollenzuweisungsrichtlinie ändern dürfen): Get-ManagementRole -Cmdlet Set-User -CmdletParametersMobilePhone| Get-ManagementRoleAssignment -GetEffectiveUsers -Delegating $False | Where-Object {$_.Effectiveusername -ne "All Group Members"} | Format-Table Role, RoleAssigneeName, EffectiveUserName
Sehen wir uns diesen Code genauer an. Im Einzelnen geschieht dabei Folgendes: 쐍 Er sucht nach allen Rollen, die den Zugriff auf die Eigenschaft MobilePhone über Set-User erlauben. 쐍 Er letiet diese Rollen an Get-ManagementRoleAssignment weiter, um eine Liste der Benutzer zurückzugeben, denen der Zugriff über eine Rollenzuweisung delegiert wurde. (Wenn Sie den Parameter -Delegating auf $True setzen, erhalten Sie eine Liste aller Benutzer, die den Zugriff an andere delegieren können.) 쐍 Er filtert die Liste, um »All Group Members« zu entfernen, da wir nur einzelne Benutzer sehen möchten. 쐍 Er gibt die Rolle, den Namen der Rolle und den Namen des Benutzers aus. Die Ausgabe sieht wie folgt aus: Role ---Mail Recipients Mail Recipients Mail Recipients
RoleAssigneeName ---------------Organization Management Organization Management Help Desk Level 2 Support
EffectiveUserName ----------Administrator Halstead, Dean Ruth, Andy
175
Rollenbasierte Zugriffssteuerung
Rollen
Kapitel 4
Rollenbasierte Zugriffssteuerung
Mail Recipients Mail Recipients Mail Recipients User Options User Options MyContactInformation
EMEA Help Desk EMEA Help Desk APJ Help Desk Organization Management Organization Management Default Role Assignment Policy
Pelton, David Smith, John Akers, Kim Administrator Redmond, Tony All Policy Assignees
VORSICHT Zurzeit ist es mit der rollenbasierten Zugriffssteuerung nur möglich, die Verwendung von Cmdlets einzuschränken, die Daten schreiben (also mit New- oder Set- beginnen). Einschränkungen für Get-Cmdlets, mit denen die Benutzer die Eigenschaften von Objekten abrufen, lassen sich dagegen nicht festlegen. Das bedeutet, dass Benutzer, die Einschränkungen unterliegen, dennoch alle Daten über ein Objekt lesen können, auch wenn sie nicht alle oder gar keine seiner Attribute ändern dürfen. Insidertipp: Beschränken des Zugriffs auf Remove-Mailbox
In manchen Organisationen sieht man es nicht gern, wenn Exchange-Administratoren in der Lage sind, ein Postfach und das zugrunde liegende Active Directory-Konto mit dem Befehl Postfach entfernen in der Exchange-Verwaltungskonsole oder mit dem Cmdlet Remove-Mailbox in der Verwaltungsshell zu entfernen. Manchmal gilt das Gleiche auch für Remove-MailContact, aber die größte Sorge bereitet die Möglichkeit, ein Benutzerkonto aus Active Directory entfernen zu können. Da es in Exchange nicht möglich ist, einen Rolleneintrag aus den vorgefertigten Rollen zu entfernen, können Sie dieses Problem nicht einfach dadurch lösen, dass Sie Remove-Mailbox aus der Rolle herausnehmen. Stattdessen müssen Sie dafür sorgen, dass niemand außer Organisationsadministratoren Zugang zur Rolle Mail Recipient Creation hat, da nur diese Rolle die Verwendung von Remove-Mailbox erlaubt. Mit dem folgenden Code können Sie überprüfen, wem der Zugriff auf Mail Recipient Creation delegiert wurde, damit Sie diese Delegierung wieder rückgängig machen können: Get-ManagementRoleAssignment -Role "Mail Recipient Creation" –Delegating $False | Remove-ManagementRoleAssignment
Erstellen von Rollen für bestimmte Aufgaben Es ist durchaus möglich, dass Sie in Ihrer Umgebung eine neue Rolle für bestimmte Aufgaben benötigen. Wenn Sie eine neue Rolle erstellen, müssen Sie folgende Regeln beachten: 쐍 Benutzerdefinierte Rollen müssen als untergeordnete Rollen einer der integrierten Rollen erstellt werden. Es ist nicht möglich, sie auf der Grundlage einer anderen benutzerdefinierten Rolle zu erstellen. 쐍 Eine untergeordnete Rolle kann nicht mehr Rechte umfassen als ihre übergeordnete Rolle. 쐍 Unter den Cmdlets in einer Rolle muss es zu jedem Set- und Remove- ein entsprechendes GetCmdlet geben. Die Rolle MyProfileInformation, die Benutzern erlaubt, ihre persönlichen Kontaktdaten in der Exchange-Systemsteuerung zu ändern, enthält z.B. Einträge für das Cmdlet Get-Mailbox, mit dem die aktuellen Daten abgerufen werden können, sowie Set-Mailbox und Set-User, mit denen sie sich ändern lassen. Wenn Sie sich die Rolleneinträge für Set-Mailbox und Set-User im Einzelnen anschauen, sehen Sie, dass die Verwendung der Parameter auf eine Auswahl von Eigenschaften wie Anzeigename, Vorname usw. eingeschränkt ist.
176
Nehmen wir als Beispiel an, dass unser Supportpersonal in der Lage sein soll, die persönlichen Angaben zu Empfängern zu ändern, da wir nicht wünschen, dass die Benutzer dies in der Exchange-Systemsteuerung selbst tun. Als Erstes müssen wir uns überlegen, welche integrierte Rolle wir als Vorlage nehmen. Zur Auswahl stehen MyProfileInformation und Mail Recipients, da beide den Zugriff auf die Benutzereigenschaften erlauben. In diesem Beispiel leiten wir unsere selbst gestaltete Rolle von Mail Recipients ab: New-ManagementRole –Name 'Help Desk User Updates' –Parent 'Mail Recipients'
Die integrierte Rolle Mail Recipients umfasst eine sehr große Anzahl von Cmdlets, die wir den Inhabern der neuen Rolle nicht zur Verfügung stellen wollen, weshalb wir alle Cmdlets bis auf Get-Mailbox entfernen. Es ist einfacher, anschließend die wenigen Cmdlets, die wir benötigen, wieder hinzuzufügen, als die Rolle in ihrem Urzustand zu bearbeiten. Get-ManagementRoleEntry –Identity 'Help Desk User Updates\*' | Where {$_.Name –ne 'Get-Mailbox'} | Remove-ManagementRoleEntry –Confirm:$False
Jetzt können wir der neuen Rolle die gewünschten Cmdlets hinzufügen und dabei die Parameter angeben, die wir dafür jeweils erlauben. Das Supportpersonal soll mehrere verschiedene Benutzereinstellungen ändern können, weshalb wir insgesamt den Zugriff auf sechs Cmdlets erlauben müssen (fünf zusätzlich zu dem einen, das wir noch in der Rolle belassen haben). Manchmal müssen Sie auch ein bisschen herumprobieren, bis Sie ganz genau bestimmt haben, welche Cmdlets notwendig sind. Add-ManagementRoleEntry 'Help Desk User Updates\Set-Mailbox' –Parameters Identity, DisplayName, SimpleDisplayName Add-ManagementRoleEntry 'Help Desk User Updates\Get-User' Add-ManagementRoleEntry 'Help Desk User Updates\Set-User' –Parameters Identity, FirstName, LastName, Initials, Office, Phone, MobilePhone, Department, Manager Add-ManagementRoleEntry 'Help Desk User Updates\Get-CASMailbox' Add-ManagementRoleEntry 'Help Desk User Updates\Set-CASMailbox' –Parameters Identity, IMAPEnabled, OWAEnabled, OWAMailboxPolicy
Mit dem folgenden Befehl können wir jetzt prüfen, ob die selbst erstellte Rolle HelpDesk User Updates die richtigen Cmdlets und Parameter umfasst: Get-ManagementRoleEntry 'Help Desk User Updates\*' | Format-List
Wenn die Überprüfung zu unserer Zufriedenheit ausfällt, können wir die neue Rolle jetzt den betreffenden Benutzern zuweisen.
Bereiche Alle Rollen haben einen Bereich, über den Exchange bestimmt, auf welche Objekte die Rolleninhaber zugreifen können. Den Bereich einer Rolle können Sie so ganz präzise einstellen, von den Objekten in einer einzelnen Organisationseinheit über eine Gruppe bestimmter Benutzer zu dem gesamten Inhalt des Exchange-Konfigurationscontainers. Mit Bereichen können Sie Benutzer auch auf die Verwaltung eines bestimmten Servers oder einer Gruppe von Servern einschränken. Exchange Server 2010 SP1 definiert einen neuen Bereich, mit dem auch die Einschränkung des Zugriffs auf eine bestimmte Datenbank möglich ist. Mehr darüber erfahren Sie im Abschnitt »Verbesserungen bei der rollenbasierten Zugriffssteuerung in Service Pack 1« weiter hinten in diesem Kapitel. 177
Rollenbasierte Zugriffssteuerung
Bereiche
Kapitel 4
Rollenbasierte Zugriffssteuerung
Im folgenden Beispiel sehen wir uns den Bereich der Rolle Move Mailboxes an, die es ermöglicht, Postfächer von einer Datenbank zur anderen zu verschieben: Get-ManagementRole 'Move Mailboxes' | Format-List *Scope* ImplicitRecipientReadScope ImplicitRecipientWriteScope ImplicitConfigReadScope ImplicitConfigWriteScope
: : : :
Organization Organization OrganizationConfig OrganizationConfig
Am wichtigsten davon sind die impliziten Schreibbereiche (Implicit...WriteScope), da sie die Objekte beschreiben, die die in der Rolle enthaltenen Cmdlets ändern können. Da wir beim Verschieben von Postfächern in der Lage sein müssen, das Postfach auf der neuen Position zu ändern, umfasst der Empfängerschreibbereich die gesamte Organisation. Wie Sie außerdem sehen, hat die Rolle die Fähigkeit, Informationen in der Organisationskonfiguration zu lesen, damit wir als Ziel für den Verschiebevorgang jede beliebige Datenbank in der Organisation auswählen können. Wenn Sie eine neue Rolle erstellen, muss sie einer vorhandenen Rolle untergeordnet sein. Dabei erbt sie automatisch den Bereich der übergeordneten Rolle, sofern Sie keinen anderen festlegen. Wie dies geschieht, sehen wir uns in Kapitel 5, »Exchange-Verwaltungskonsole und Exchange-Systemsteuerung«, genauer an. Dort besprechen wir, wie Sie eine neue Rolle erstellen, mit der Benutzer ihre eigenen Verteilergruppen ändern können, ohne dabei gleichzeitig die Fähigkeit zu erlangen, neue Gruppen anzulegen. Sie können neue Bereiche zusammen mit neuen Gruppen erstellen, doch ist es eine bessere Technik, einen Bereich einfach zu definieren, sodass er für mehrere Rollen zur Verfügung steht. Dazu gibt es in Exchange das Cmdlet New-ManagementScope. Durch Bereiche können Sie Rollen auf einzelne Server, Organisationseinheiten oder die Mitglieder einer Verteilergruppe einschränken. Mit dem folgenden Befehl erstellen Sie beispielsweise einen neuen Bereich, der die Verteilergruppe Company Officers umschließt. Für einen solchen Zweck können Sie sogar auf eine dynamische Verteilergruppe zurückgreifen. New-ManagementScope –Name 'Company Officers' –RecipientRestrictionFilter {MemberOfGroup –eq "cn=Company Officers,ou=Exchange Users,dc=contoso,dc=com"} Get-ManagementScope 'Company Officers' RecipientFilter
: MemberOfGroup -eq 'CN=Company Officers,OU=Exchange Users,Dc=contoso,dc=com' ScopeRestrictionType : RecipientScope Exclusive : False ExchangeVersion : 0.10 (14.0.100.0) Name : Company Officers DistinguishedName : CN=Company Officers,CN=Scopes,CN=RBAC,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com Identity : Company Officers ObjectClass : {top, msExchScope}
Sobald Sie einen Bereich erstellt haben, können Sie ihn mit -CustomConfigWriteScope (für Bereiche, die Server und Datenbanken umfassen) und -CustomRecipientWriteScope (für Bereiche auf der Grundlage bestimmter Empfänger) zuweisen.
178
Rollengruppen Rollen können einzeln oder als Gruppe zugewiesen werden. Zwar bieten Rollen die Möglichkeit zur präzisen Steuerung der verschiedenen Aufgaben für einen typischen Exchange-Administrator, doch wäre es viel zu aufwändig, Aufgaben mithilfe von einzelnen Rollen zu erlauben. Rollengruppen bieten eine bequeme Möglichkeit, um die erforderlichen Rollen für allgemeiner gefasste Aufgaben wie »Postfachsuche« zusammenzufassen, anstatt die elf einzelnen Rollen zuzuweisen, die dafür ansonsten erforderlich wären. Es ist sehr viel einfacher, die Zuweisung einer einzelnen Rollengruppe zu verwalten als die von elf verschiedenen Rollen, und außerdem sinkt die Gefahr von Fehlern und Sicherheitsproblemen, wenn sich Administratoren für die rollenbasierte Zugriffssteuerung auf Rollengruppen verlassen. Den Benutzern weisen Sie dadurch Rollen zu, dass Sie sie zu Mitgliedern einer Rollengruppe machen. Eine Rollengruppe beschreibt allgemeinere Aufgaben, die bestimmte Arten von Administratoren durchführen sollen. Wer im Support arbeitet, muss z.B. in der Lage sein, Informationen über Empfänger einzusehen und zu ändern, aber wahrscheinlich soll er nicht an Sendeconnectors und Transportregeln herumpfuschen dürfen. Die für den Support definierte Rollengruppe umfasst alle Rollen (und damit den Zugriff auf alle Cmdlets), die für die Arbeit in dieser Rolle erforderlich sind – aber keine weiteren. Rollengruppen gehören zu den Grundlagen der rollenbasierten Zugriffssteuerung in Exchange Server 2010. Wenn Sie sich die vorgefertigten Rollengruppen (und die von Ihnen erstellen) ansehen möchten, geben Sie folgenden Befehl ein: Get-RoleGroup
Hinter den Kulissen wird jede Rollengruppe durch eine universelle Sicherheitsgruppe in der Active Directory-Organisationseinheit Microsoft Exchange Security Groups dargestellt (siehe Abbildung 4.2). Diese Gruppen sind gekennzeichnet, sodass Exchange weiß, dass sie für die rollenbasierte Zugriffssteuerung verwendet werden. Wenn es nötig ist, werden bei der Installation eines ersten Exchange Server 2010-Computers in einer Organisation die vorhandenen Zugriffssteuerungslisten von Exchange Server 2007 in eine Rollengruppe kopiert, die dann die Verwaltung verbliebener Computer mit der alten Version übernehmen kann. Abbildg. 4.2
Die universellen Sicherheitsgruppen für die rollenbasierte Zugriffssteuerung
179
Rollenbasierte Zugriffssteuerung
Rollengruppen
Kapitel 4
Rollenbasierte Zugriffssteuerung
Der Hauptunterschied zwischen den universellen Sicherheitsgruppen für die rollenbasierte Zugriffssteuerung und anderen universellen Sicherheitsgruppen besteht darin, dass Sie die Rollengruppen (und damit standardmäßig auch die zugrunde liegenden Sicherheitsgruppen) in der Exchange-Verwaltungskonsole, -Verwaltungsshell und -Systemsteuerung verwalten können. Die in Abbildung 4.2 gezeigte universelle Sicherheitsgruppe Super Help Desk Users gehört nicht zu denen, die bei der Installation von Exchange Server 2010 für die rollenbasierte Zugriffssteuerung angelegt werden. In Ihrer Exchange-Umgebung werden Sie sie nicht sehen, da Exchange sie bei mir erstellt hat, nachdem ich eine neue Rollengruppe für meine Organisation angelegt habe. Das zeigt, dass es eine 1:1-Beziehung zwischen Rollengruppen und universellen Sicherheitsgruppen gibt. Insidertipp: Delegieren von nicht standardmäßig zugewiesenen Rollen
Benutzer in der Rollengruppe Organization Management haben nicht nur die Zugriff auf die große Mehrheit der in einer Organisation definierten Rollen, sondern auch die Möglichkeit, die Rollen zu delegieren, die sie standardmäßig nicht innehaben. Ein gutes Beispiel für eine Rolle, die die Mitglieder der Gruppe Organization Management nicht haben, die ihnen aber delegiert werden kann, ist Mailbox Import Export. Dafür, dass diese Rolle den Mitgliedern von Organization Management nicht zugewiesen ist, gibt es einen einfachen Grund: Der Inhalt von Benutzerpostfächern sollte gegen unnötigen Zugriff geschützt sein. Daher müssen Sie einen bewussten Schritt ausführen, um Zugriff auf die Postfächer zu gewähren, bevor Sie in der Lage sind, die Cmdlets zum Importieren und Exportieren von Postfachdaten auszuführen. Den Rollen liegen zwar universelle Sicherheitsgruppen zugrunde, doch ist es ein Irrtum zu glauben, Sie könnten einfach in der Konsole Active Directory-Benutzer und -Computer Benutzerkonten zu den Sicherheitsgruppen hinzufügen, um Rollen zuzuweisen. Hinter den Kulissen merkt sich Exchange, welche Rollen zugewiesen wurden, und einen Benutzer zu einer universellen Sicherheitsgruppe hinzuzufügen, reicht dazu nicht aus, sondern kann zu unvorhersehbaren Ergebnissen führen. Die Rollen Organization Management und Delegated Setup nehmen einen Sonderstatus ein, da ihnen neben den Exchange-Berechtigungen auch Active Directory-Zugriffssteuerungslisten zugewiesen sind, um Aufgaben wie die Installation von Servern durchführen zu können. Die überwiegende Mehrzahl der Aufgaben, die Benutzer mit Rollen zur Verwaltung der verschiedenen Aspekte von Exchange durchführen, unterliegt der rollenbasierten Zugriffssteuerung, sodass dafür keine Zugriffssteuerungslisten zugewiesen werden müssen. In Kapitel 3 erfahren Sie mehr darüber, wie die rollenbasierte Zugriffssteuerung einschränkt, welche Cmdlets einem Benutzer in einer Sitzung der Exchange-Verwaltungsshell zur Verfügung stehen. Weitere Informationen
Informationen über die standardmäßigen Rollengruppen und Rollenzuweisungen in Exchange Server 2010 finden Sie auf http://technet.microsoft.com/de-de/library/dd638077.aspx. Rollengruppen und -zuweisungen werden sich mit der Zeit ändern, wenn Microsoft die rollenbasierte Zugriffssteuerung durch Service Packs und neue Versionen von Exchange ändert. Jede Rollengruppe umfasst eine Reihe verschiedener administrativer Rollen, die eine Feinsteuerung für die Zuweisung von Aufgaben erlauben. Die Namen der Rollengruppen beschreiben die Aufgaben, die die jeweiligen Mitglieder durchführen können. Für Exchange Server 2010 hat sich Microsoft das Ziel gestellt, einen Satz von Rollengruppen bereitzustellen, die für die Bedürfnisse der meisten Kunden
180
ausreichen, aber wenn dieser Satz für Ihre Umgebung nicht ideal geeignet ist, können Sie eine Rollengruppe auch ändern (indem Sie z.B. einzelne Aufgaben herausnehmen oder hinzufügen) oder eine ganz neue Rollengruppe erstellen. Um zu dem Beispiel der Rolle Help Desk zurückzukehren: Vielleicht wünschen Sie sich, dass das Supportpersonal Einsicht in die Nachrichtenwarteschlangen nehmen kann, um eine Nachrichtenverfolgung durchzuführen. In diesem Fall können Sie der Gruppe Help Desk die Rollen Transport Queue und Message Tracking hinzufügen. Es ist auch möglich, Benutzern oder Gruppen eine bestimmte Rolle zuzuweisen, ohne sie in eine Rollengruppe aufzunehmen. Wie bereits erwähnt, rät Microsoft jedoch von einer solchen Vorgehensweise ab, da dies zu einer solchen Vervielfachung der Rollenzuweisungen führt, dass sie sich nur noch schwer überwachen und verwalten lassen. Insidertipp: Delegierung in Exchange Server 2007
Der Wechsel von dem in Exchange Server 2007 verwendeten Modell für die delegierte Verwaltung zur rollenbasierten Zugriffssteuerung in Exchange Server 2010 bringt es mit sich, dass Sie die Delegierungen überprüfen müssen, die in einer Organisation für Exchange Server 2007 in Kraft waren. Das ist notwendig, damit Benutzer, denen eine gewisse Form des Zugriffs gewährt worden war (z.B. Administratoren mit reiner Leseberechtigung), in die richtigen Rollengruppen aufgenommen werden, sodass sie so weiterarbeiten können wie vor der Bereitstellung von Exchange Server 2010. Beachten Sie, dass es das Cmdlet Get-ExchangeAdministrator, mit dem Sie in Exchange Server 2007 Einblick in die Zuweisungen von Exchange-Administratoren nehmen konnten, in Exchange Server 2010 nicht mehr gibt.
Erstellen einer neuen Rollengruppe Da wir jetzt die Beziehungen zwischen Rollen, Rollengruppen und Zuweisungen kennen, ist es an der Zeit, uns einen Eindruck davon zu machen, wie wir eine neue Rollengruppe erstellen können und was dabei geschieht. Als Erstes sollten wir uns dabei immer überlegen, ob wir die neue Rollengruppe wirklich benötigen. Das allgemeine Vorgehen läuft wie folgt ab: 1. Schreiben Sie auf, was für eine neue Rollengruppe Sie benötigen und warum keine der mitgelie-
ferten für diesen Zweck ausreicht. Es ist immer besser, eine der Standardrollengruppen zu verwenden, da die Einführung neuer Rollengruppen die Verwaltung der Organisation komplizierter macht. 2. Erstellen Sie die neue Rollengruppe mit dem Cmdlet New-RoleGroup und weisen Sie ihr die Rollen zu, die sie umfassen soll. 3. Nehmen Sie Benutzer in die neue Rollengruppe auf. In vielen Unternehmen gibt es eine Abteilung für den internen Support, die Zugriff auf bestimmte Funktionen benötigt, um ihre Aufgaben erledigen zu können. In dem folgenden Beispiel erstellen wir eine neue Rollengruppe mit den erforderlichen Rollen für die Supportaufgaben der Ebene 2. New-RoleGroup 'Help Desk Level 2' –Roles 'Message Tracking', 'Mail Recipients', 'Move Mailboxes' –Members '[email protected]', '[email protected]' –ManagedBy '[email protected]', '[email protected]' –Description 'This group is used by Level 2 support personnel'
181
Rollenbasierte Zugriffssteuerung
Rollengruppen
Kapitel 4
Rollenbasierte Zugriffssteuerung
Wenn Sie eine neue Rollengruppe erstellen, müssen Sie ihr mindestens eine Rolle zuweisen. Falls Sie keinen Bereich angeben, übernimmt die Rollengruppe den Standardbereich der darin enthaltenen Rollen, der gewöhnlich die ganze Organisation umfasst. Wie bereits erwähnt erstellt Exchange zusammen mit der neuen Rollengruppe auch eine universelle Sicherheitsgruppe in der Active Directory-Organisationseinheit Microsoft Exchange Security Groups. Die im Parameter -ManagedBy angegebenen Benutzer dürfen die Gruppe verwalten, sind aber nicht selbst Mitglieder der Gruppe und füllen auch nicht die darin enthaltenen Rollen aus. Benutzer, die Sie nicht gleich beim Erstellen der Rollengruppe darin aufnehmen, können Sie später mit Add-RoleGroupMember hinzufügen. Zum Entfernen von Benutzern aus der Gruppe dient Remove-RoleGroupMember. Die Benutzer, die Sie zu Mitgliedern der Rollengruppe machen, werden automatisch auch in die zugehörige Sicherheitsgruppe aufgenommen. Add-RoleGroupMember –Identity 'Help Desk Level 2' –Member 'Tony Redmond' Remove-RoleGroupMember –Identity 'Help Desk Level 2' –Member 'Tony Redmond'
In dem zuvor gezeigten Beispiel erstellt Exchange außerdem drei Rollenzuweisungen für die drei im Cmdlet New-RoleGroup angegebenen Rollen. Dabei wird die Namenskonvention Rollenname-Rollengruppenname verwendet, sodass sich Rollenzuweisungen wie Mail Recipients-Help Desk Level 2 ergeben. Die drei Rollenzuweisungen können Sie sich wie folgt mithilfe von Get-ManagementRoleAssignment ansehen: Get-ManagementRoleAssignment –RoleAssignee "Help Desk Level 2"
Rollenzuweisung Wir haben jetzt Folgendes definiert: einen Bereich, der angibt, auf welche Objekte eine Rolle Zugriff hat; eine Rolle, die festlegt, welche Cmdlets und Parameter ihren Inhabern zur Verfügung stehen; und Rollengruppen, die uns dabei helfen, zu bestimmen, wer was tun darf. Rollenzuweisungen bilden nun den »Klebstoff«, der die rollenbasierte Zugriffssteuerung zusammenhält, denn sie verknüpfen die Rollen und ihre Bereiche mit den Benutzern und Gruppen. Um zu sehen, welche Rollenzuweisungen in Ihrer Organisation bereits vorhanden sind, geben Sie Folgendes ein: Get-ManagementRoleAssignment
Exchange Server 2010 SP1 enthält 176 Rollenzuweisungen. Geordnet sind sie nach dem Namen der Rollengruppe, sodass Sie z.B. jeweils alle Rollen in der Gruppe Organization Management zusammen finden, alle Rollen in Hygiene Management, in Discovery Management, in Move Mailboxes usw. Da Organization Management die umfassendste und funktionsreichste Gruppe ist, enthält sie natürlich auch die meisten Rollenzuweisungen. Am unteren Ende der Liste stehen die Rollen in der Standardrollenzuweisung, die von Exchange beim Erstellen eines Postfachs automatisch dem Benutzer zugeteilt wird. Zu diesen Zuweisungen gehören MyBaseOptions und MyContactInformation, die erforderlich sind, damit ein Benutzer seine eigenen persönlichen Angaben in der Exchange-Systemsteuerung bearbeiten kann. Ganz am Ende der Liste stehen benutzerdefinierte Rollenzuweisungen. Rollenzuweisungen sind nach dem Schema Rolle-Rollengruppe benannt, was zu Namen wie Message Tracking-Records Management oder Transport Queues-Organization Management führt. Wenn Sie sich eine bestimmte Rollenzuweisung genauer ansehen möchten, übergeben Sie ihren Namen im Cmdlet Get-ManagementRoleAssignment:
182
Rollenzuweisung
User AssignmentMethod Identity EffectiveUserName AssignmentChain RoleAssigneeType RoleAssignee Role RoleAssignmentDelegationType CustomRecipientWriteScope CustomConfigWriteScope RecipientReadScope ConfigReadScope RecipientWriteScope ConfigWriteScope Enabled RoleAssigneeName IsValid ExchangeVersion Name
: contoso.com/Microsoft Exchange Security Groups/Server Management : Direct : Exchange Servers-Server Management : All Group Members : : RoleGroup : contoso.com/Microsoft Exchange Security Groups/Server Management : Exchange Servers : Regular : : : Organization : OrganizationConfig : Organization : OrganizationConfig : True : Server Management : True : 0.11 (14.0.550.0) : Exchange Servers-Server Management
Die rollenbasierte Zugriffssteuerung geht nach einem anderen Prinzip vor als die herkömmlichen Sicherheitsberechtigungen, bei denen das Betriebssystem jeweils diejenige mit den stärksten Einschränkungen verwendete. Hier dagegen werden die Benutzer mit den kombinierten Möglichkeiten aller Rollen versehen, denen sie zugewiesen sind, sodass sie alle von den Rollen abgedeckten Aufgaben ausführen können. Überlegen Sie, was passiert, wenn Sie ein Konto zu einem Domänenadministrator machen: Das Konto erhält in der Domäne schlagartig enorme Befugnisse. Die Möglichkeiten eines solchen Kontos unterscheiden sich sehr stark von denen »normaler« Benutzerkonten. Was aber passiert, wenn Sie ein Konto zu einer Rollengruppe hinzufügen? Es erhält die Möglichkeit, die in den Rollen dieser Gruppe festgelegten Cmdlets auszuführen. Wenn Sie das Konto weiteren Rollengruppen hinzufügen, bekommt er nach und nach Zugriff auf weitere Cmdlets, bis es schließlich auf dem Niveau der Gruppe Organization Management ankommt – die im Grunde genommen ein Behälter für fast alle in Exchange verfügbaren Rollen ist. Sie sehen also, dass die Rollen aufeinander aufbauen, um ein sehr flexibles Grundgerüst dafür zu bilden, dass alle Benutzer die ihnen zugewiesenen Aufgaben erledigen können. Es gibt zwar keinen Mechanismus, um jemanden aktiv daran zu hindern, etwas Bestimmtes zu tun, doch trotzdem bilden die aufeinander aufbauenden Rollenzuweisungen eine präziser zu steuernde Sicherheitsmaßnahme als die früheren Autorisierungsverfahren auf der Grundlage von Exchange-Zugriffssteuerungslisten.
183
Rollenbasierte Zugriffssteuerung
Get-ManagementRoleAssignment –Identity 'Exchange Servers-Server Management' | Format-List
Kapitel 4
Rollenbasierte Zugriffssteuerung
Insidertipp: Steuern der Rollenzuweisung
Mit jeder Rollenzuweisung erhält ein Benutzer die Autorisierung zur Verwendung bestimmter Cmdlets und Parameter. Welche Cmdlets und Parameter er insgesamt nutzen darf, wird durch die Gesamtheit der Rollen bestimmt, die er innehat. Da Benutzer mit jeder Rollenzuweisung auf mehr Cmdlets zurückgreifen dürfen, sollten Sie immer nur genau die Rollen zuweisen, die Sie ihnen auch wirklich gewähren möchten, da Sie ansonsten Gefahr laufen, dass die Benutzer gewisse Cmdlets und Parameter nur deshalb ausführen dürfen, weil Sie ihnen eine Rolle erteilt haben, die sie eigentlich gar nicht brauchen. Wie wir bereits gesehen haben, können Sie Rollen auch maßschneidern, indem Sie ihnen einzelne Cmdlets hinzufügen oder entziehen. Es ist auch möglich, eine Rollengruppe nach den eigenen Bedürfnissen anzupassen, indem Sie Rollenzuweisungen hinzufügen oder herausnehmen, um den Mitgliedern der Gruppe mehr oder weniger Funktionen zur Verfügung zu stellen.
Bestimmte Bereiche für Rollengruppen Wie wir bereits gesehen haben, besteht in Exchange die Möglichkeit, einer Rollengruppe einen Bereich zuzuweisen. Dadurch schränken Sie die Möglichkeiten der Gruppenmitglieder zur Verwaltung von Objekten auf den festgelegten Bereich ein. Meistens wird als Bereich eine Organisationseinheit in Active Directory festgelegt, sodass die Benutzer mit einer Rolle dieses Bereichs nur auf die Objekte in dieser Organisationseinheit zugreifen können. Um einen Bereich festzulegen, haben Sie drei Möglichkeiten: 쐍 RecipientOrganizationalUnitScope Mit diesem Parameter geben Sie ausdrücklich eine Organisationseinheit in Active Directory an. 쐍 CustomRecipientWriteScope Erstellen Sie mit New-ManagementScope einen Verwaltungsbereich und geben Sie dabei mit diesem Parameter eine Organisationseinheit in Active Directory an. Dies ist die zu bevorzugende Vorgehensweise, wenn Sie den Bereich mehrfach verwenden möchten. Dadurch können Sie dem Bereich auch einen für Menschen bequemer lesbaren Namen geben, der leichter verständlich ist als der Name der Organisationseinheit. 쐍 Datenbankname In Exchange Server 2010 SP1 können Sie beim Erstellen eines neuen Bereichs auch den Namen einer Datenbank angeben. Nehmen wir einmal an, eine große Organisation verfügt über eine verteilte Supportabteilung mit einzelnen Teams in den verschiedenen Regionen, die jeweils den Benutzern vor Ort helfen sollen. Wahrscheinlich wollen Sie nicht, dass das amerikanische Supportpersonal die Benutzer in Europa verwaltet und umgekehrt. In diesem Fall können Sie zwei verschiedene Rollengruppen für den amerikanischen und den europäischen Support erstellen und mit den entsprechenden Bereichen versehen, sodass die Mitglieder jeweils nur Zugriff auf die Benutzer haben, für die sie auch wirklich zuständig sind. Fehlerbehebung: Es ist nicht möglich, einer bestehenden Rollengruppe mit Set-RoleGroup einen Bereich hinzuzufügen
Mit dem Cmdlet Set-RoleGroup können Sie einer Gruppe nicht im Nachhinein einen Bereich hinzufügen. Wenn Sie einer bereits vorhandenen Gruppe nachträglich einen Bereich zuweisen müssen, rufen Sie mit Get-ManagementRoleAssignment die Einzelheiten über sämtliche Rollenzuweisungen dieser Gruppe ab und leiten diese Informationen an Set-ManagementRoleAssignment weiter, um für die einzelnen Zuweisungen neue Bereiche anzugeben. Betrachten Sie dazu das folgende Beispiel:
184
Fehlerbehebung: Es ist nicht möglich, einer bestehenden Rollengruppe mit Set-RoleGroup einen Bereich hinzuzufügen Get-ManagementRoleAssignment –RoleAssignee 'Help Desk Level 2' | Set-ManagementRoleAssignment –RecipientOrganizationalUnitScope 'contoso.com/Exchange Users'
Im folgenden Beispiel erstellen wir eine neue Rollengruppe, deren Bereich auf die Verwaltung aller europäischen Postfächer der Organisation eingeschränkt ist. New-RoleGroup 'European Help Desk' –Roles 'Message Tracking', 'Mail Recipients', 'Move Mailboxes' –Members '[email protected]', '[email protected]' –ManagedBy '[email protected]', '[email protected]' –Description 'This group is used to manage European mailboxes' –RecipientOrganizationalUnitScope 'contoso.com/EMEA Mailboxes'
Alternativ können wir auch zuvor einen Verwaltungsbereich definieren, der die betreffende Organisationseinheit umfasst, und ihn dann im Cmdlet New-RoleGroup angeben. New-ManagementScope –Name 'European Mailboxes' –RecipientRoot 'contoso.com/Exchange Mailboxes/EMEA' –RecipientRestrictionFilter {RecipientType –eq "UserMailbox} New-RoleGroup 'European Help Desk' –Roles 'Message Tracking', 'Mail Recipients', 'Move Mailboxes' –Members '[email protected]', '[email protected]' –ManagedBy '[email protected]', '[email protected]' –Description 'This group is used t to manage European mailboxes' –CustomRecipientWriteScope 'European Mailboxes'
Weitere Informationen
Informationen darüber, wie Sie datenbankweite Bereiche definieren und einsetzen, finden Sie im Abschnitt »Datenbankweite Bereiche« weiter hinten in diesem Kapitel.
Besondere Rollen Zu den Rollen in der Rollengruppe Organization Management gehören auch die fünf folgenden Sonderrollen, die delegiert werden müssen, bevor sie verwendet werden können: 쐍 ApplicationImpersonation Dies ist eine Sonderrolle, die hauptsächlich für Dienstkonten gedacht ist, damit diese in der Lage sind, zur Erledigung bestimmter Aufgaben die Identität eines Benutzers anzunehmen. 쐍 Mailbox Import Export Diese Rolle erlaubt einem Benutzer, Daten in Postfächer zu importieren oder daraus zu exportieren. 쐍 Mailbox Search Diese Rolle erlaubt einem Benutzer, den Postfachinhalt zu durchsuchen. Sie ist der Rollengruppe Discovery Management zugewiesen, die aber standardmäßig leer ist und erst mit Mitgliedern versehen werden muss, bevor solche Suchvorgänge durchgeführt werden können. 쐍 Support diagnostics Diese Rolle gewährt den Zugriff auf Diagnose-Cmdlets wie Test-ReplicationHealth, die dazu gedacht sind, dass Supportmitarbeiter von Microsoft oder anderen Stellen Diagnoseinformationen von einem Exchange Server-Computer oder einer Organisation abrufen können. Diese Rolle ist standardmäßig keinem Benutzer zugewiesen.
185
Rollenbasierte Zugriffssteuerung
Rollenzuweisung
Kapitel 4
Rollenbasierte Zugriffssteuerung
쐍 Unscoped role management Diese Rolle ermöglicht es, Rollen ohne Bereich zu erstellen und zu verwalten. Solche Rollen werden dazu verwendet, um auf benutzerdefinierte Skripts und Cmdlets zuzugreifen. Die Rolle ist standardmäßig keinem Benutzer zugewiesen, kann aber von den Mitgliedern der Rollengruppe Organization Management Benutzern delegiert werden. Dass in dieser Liste die Rolle enthalten ist, die Benutzern den Import und Export von Postfachdaten erlaubt, mag Sie vielleicht überraschen. Das ist jedoch durchaus gerechtfertigt, wenn Sie daran denken, dass diese Fähigkeit nur ausdrücklich bestimmten Einzelpersonen zugewiesen sollte, die sie auch wirklich benötigen. Schließlich wollen Sie auf keinen Fall, dass irgendein Benutzer versehentlich die Möglichkeit bekommt, die Daten im Postfach eines anderen Benutzers zu exportieren. Wenn ein solcher Zugriff tatsächlich erforderlich ist, können Sie diese Rolle einem Benutzer wie folgt zuweisen: New-ManagementRoleAssignment –Role 'Mailbox Import Export' –User 'Darren.Parker@ contoso.com'
Es ist meistens bequemer, die Rolle einer Sicherheitsgruppe zuzuweisen, da die Verwaltung von Gruppenmitgliedschaften gewöhnlich leichter ist als die Rollenzuweisungen zu einzelnen Benutzern. Dabei müssen Sie eine universelle Sicherheitsgruppe verwenden und keine universelle oder dynamische Verteilergruppe. New-ManagementRoleAssignment –Role 'Mailbox Import Export' –SecurityGroup 'Mailbox Import-Export Team'
Nachdem die Rolle zugewiesen ist, können ihre Inhaber die Option Postfach exportieren in der Exchange-Verwaltungskonsole und die Cmdlets Export-Mailbox und Import-Mailbox (Exchange Server 2010) bzw. New-MailboxImportRequest und New-MailboxExportRequest (Exchange Server 2010 SP1) in der Exchange-Verwaltungsshell verwenden. In der SP1-Version der Exchange-Verwaltungskonsole werden Ihnen keine Optionen für den Import und Export von Postfächern angeboten, da Microsoft keine Zeit mehr gehabt hat, den Konsolen-Assistenten für diese Aktionen auf die Verwendung der in SP1 eingeführten neuen Cmdlets umzuschreiben. Benutzer, denen die Rollen zugewiesen worden sind, müssen die Exchange-Verwaltungskonsole bzw. -shell neu starten, um eine Aktualisierung der Daten für die rollenbasierte Zugriffssteuerung zu erzwingen, sodass die neue Zuweisung in Kraft tritt. Weitere Informationen
In Kapitel 14, »Nachrichtenhygiene«, finden Sie weitere Informationen über die in SP1 neu eingeführten Cmdlets für den Import und Export von Postfächern.
Rollen ohne Bereiche Wenn Sie maßgeschneiderte Rollen für Verwaltungszwecke erstellen möchten, sind Rollen ohne Bereich ein wichtiges Thema. Ich nehme an, dass die Bereitstellungsteams diesem Gebiet zu Anfang nur wenig Aufmerksamkeit schenken, wenn sie noch damit kämpfen, die rollenbasierte Zugriffssteuerung in einem Unternehmen überhaupt erst umzusetzen. Doch wenn sich die Administratoren mit der Zeit an diese neue Form der Zugriffssteuerung gewöhnen, ist es sehr wahrscheinlich, dass die Möglichkeit, nach eigenem Gusto gestaltete Rollen zu erstellen und zuzuweisen, sie fasziniert.
186
Die Grundidee hinter benutzerdefinierten Rollen ohne Bereich besteht darin, einen Mechanismus bereitzustellen, mit dem Administratoren Rollengruppen, einzelnen Benutzern und universellen Sicherheitsgruppen Zugriff auf Nicht-Exchange-Cmdlets und Windows PowerShell-Skripts gewähren können. Nehmen wir beispielsweise an, Sie haben einige PowerShell-Skripts geschrieben, mit denen zur Berichterstellung Daten aus Exchange abgerufen werden können. Nun möchten Sie den Mitarbeitern im Support Zugriff auf diese Skripts gewähren, sodass sie die betreffenden Berichte erstellen können. Ein weiterer Grund, um eine benutzerdefinierte Rolle zu erstellen, besteht darin, dass Sie Zugriff auf eine Fähigkeit erteilen möchten, die zur Erledigung einer bestimmten Arbeit notwendig ist, ohne gleichzeitig auch den Zugriff auf eine bestimmte Rolle oder ein Cmdlet zu gewähren. So kann es beispielsweise sein, dass Sie den Supportmitarbeitern zwar erlauben möchten, Postfächer zu erstellen, dies aber nur in einer bestimmten Organisationseinheit, nach einer strukturierten Namenskonvention und nach einer bestimmten Anweisung für die Einrichtung der Postfacheinstellungen. Das können Sie erreichen, indem Sie ein Skript mit der gesamten Geschäftslogik schreiben, die zum Erstellen der Postfächer nötig ist, und den betreffenden Benutzern Zugriff auf dieses Skript geben. Die Supportmitarbeiter, die die benutzerdefinierte Rolle innehaben, können das Skript ausführen, das Cmdlet New-Mailbox aber in keiner anderen Weise verwenden. Als Erstes müssen Sie die Fähigkeit, Rollen ohne Bereiche zu erstellen, einem Konto delegieren. Diese Fähigkeit wird nicht standardmäßig erteilt, nicht einmal Konten in der Rollengruppe Organization Management. Allerdings können die Konten in dieser Gruppe die Rolle Unscoped Role Management sich selbst und anderen Konten mit dem Cmdlet New-ManagementRoleAssignment delegieren. Der folgende Befehl weist die Rolle einer universellen Sicherheitsgruppe namens Exchange Admins zu, die es natürlich geben muss, bevor Sie versuchen, sie mit einer Rolle zu verknüpfen: New-ManagementRoleAssignment –Role 'Unscoped Role Management' –SecurityGroup 'Exchange Admins'
Wenn das Konto, das Sie verwenden, Mitglied der Gruppe Exchange Admins ist, können Sie jetzt Verwaltungsrollen der obersten Ebene ohne Bereich erstellen. Denken Sie daran, dass Sie Ihre Sitzung der Exchange-Verwaltungsshell aktualisieren müssen, nachdem Ihnen die Rolle Unscoped Role Management zugewiesen wurde, damit die rollenbasierte Zugriffssteuerung Ihnen den Parameter -UnscopedTopLevel für das Cmdlet New-ManagementRole zur Verfügung stellen kann. Wenn Sie dies nicht tun, meldet die Shell einen Fehler, wenn Sie das Cmdlet ausführen und dabei den Parameter -UnscopedTopLevel zu übergeben versuchen. New-ManagementRole –Name 'Exchange Admin Scripts' –UnscopedTopLevel Name -------Exchange Admin Scripts
RoleType -------UnScoped
Die Verwaltungsrolle ist leer und muss jetzt mit Angaben über die Skripts versehen werden, die Sie den Inhabern der Rolle zur Verfügung stellen möchten. Die Skripts müssen Sie auf jedem Server in das Standardverzeichnis für Remoteskripts kopieren (\Program Files\Microsoft\Exchange Server\V14\RemoteScripts\). Dadurch, dass die Skripts hier platziert werden und nicht im standardmäßigen Skriptverzeichnis, führen Sie eine deutliche Trennung zwischen den lokal und den über das Netzwerk auszuführenden Skripts herbei. Anschließend können Sie für jedes Skript einen Rolleneintrag hinzufügen: Add-ManagementRoleEntry 'Exchange Admin Scripts\DBReportMail.PS1' –Type Script –UnscopedTopLevel
187
Rollenbasierte Zugriffssteuerung
Rollenzuweisung
Kapitel 4
Rollenbasierte Zugriffssteuerung
Dieser Befehl verknüpft das Skript DBReportMail.ps1 mit der benutzerdefinierten Rolle, sodass die Inhaber der Rolle es ausführen können. Die Rolle wiederum weisen wir den Benutzern, die das Skript brauchen, auf die übliche Weise zu: New-ManagementRoleAssignment –Role 'Exchange Admin Scripts' –User 'Help Desk'
Nach dieser Zuweisung können die Benutzer das Skript das nächste Mal ausführen, wenn Sie sich an der Exchange-Verwaltungsshell anmelden.
Zu welchen Rollengruppen gehöre ich? Eine einfache Frage, die Administratoren häufig stellen, lautet, zu welchen Rollengruppen sie selbst – oder jemand anders – zugewiesen sind. Die Angaben über die Zuweisungen finden sich in den Mitgliedschaftsinformationen der einzelnen Rollengruppen, weshalb Sie dort nachforschen müssen, um zu bestimmen, über welche Rollen ein Benutzer verfügt. In dem folgenden Beispiel führen wir das Cmdlet Get-RoleGroup aus und leiten die Ausgabe an Where-Object weiter, um nach Einträgen in den Mitgliederlisten einer Rollengruppe zu suchen, die eine Teilübereinstimmung mit dem Benutzernamen »Redmond« aufweisen. Get-RoleGroup | Where-Object {$_.Members –Like '*Redmond*'} | Format-List Name, Members Name : Organization Management Members : {contoso.com/Exchange Users/Redmond, Eoin P, contoso.com/Exchange Users/ Redmond,Tony, contoso.com/Users/Administrator} Name : Discovery Management Members : {contoso.com/Exchange Users/Redmond, Tony, contoso.com/Users/Administrator}
Die Ausgabe zeigt, dass unter den Mitgliedern der Rollengruppen Organization Management und Discovery Management eine Teilübereinstimmung mit »Redmond« gefunden wurde. Anschließend können wir die zurückgegebenen Mitgliedschaftsinformationen genauer untersuchen, um die Benutzer zu finden, für die wir uns interessieren. Wenn Sie jedoch nur sehen wollen, welche Benutzer Inhaber einer bestimmten Rolle sind, ist GetManagementRoleAssignment das richtige Cmdlet. In dem folgenden Beispiel rufen wir die Liste der Benutzer ab, denen die Rolle Mailbox Import Export zugewiesen ist: Get-ManagementRoleAssignment –Role 'Mailbox Import Export' | Format-Table Role AssigneeName, RoleAssignmentDelegationType, RoleAssigneeType RoleAssigneeName ---------------Organization Management Administrator
RoleAssignmentDelegation ----------------------DelegatingOrgWide Regular
TypeRoleAssigneeType ------------------RoleGroup User
Hier werden zwei verschiedene Arten von Zuweisungen angezeigt: 쐍 Mitglieder der Rollengruppe Organization Management dürfen den Zugriff auf die Rolle Mailbox Import Export delegieren, haben selbst aber nicht die Berechtigungen eines regulären Inhabers dieser Rolle.
188
쐍 Das Administratorkonto ist regulärer Rolleninhaber, und zwar aufgrund einer ausdrücklichen Zuweisung. Da das Administratorkonto gewöhnlich Mitglied der Rollengruppe Organization Management ist, können sich Administratoren selbst die Rolle Mailbox Import Export zuweisen. Das Cmdlet Get-ManagementRoleAssignment ist sehr nützlich, um herauszufinden, wer was mit einem Objekt anstellen kann. Nehmen wir beispielsweise an, Sie möchten herausfinden, wer Schreibzugriff auf verschiedene Objekte hat: 쐍 Auf ein bestimmtes Benutzerpostfach: Get-ManagementRoleAssignment –WritableRecipient "Akers, Kim" –GetEffectiveUsers
쐍 Auf ein Serverobjekt: Get-ManagementRoleAssignment –WritableServer 'ExServer1' -GetEffectiveUsers
쐍 Auf eine Postfachdatenbank oder eine Datenbank für öffentliche Ordner: Get-ManagementRoleAssignment –WritableDatabase 'DB1'
Wenn Sie den Parameter -GetEffectiveUsers angeben, werden alle Benutzer zurückgegeben, die das Objekt indirekt durch die Mitgliedschaft in Rollengruppen und universellen Sicherheitsgruppen bearbeiten können. Ohne diesen Parameter werden nur die Rollengruppen, Benutzer und universellen Sicherheitsgruppen angezeigt, denen die Rolle direkt zugewiesen ist.
Zuweisungsrichtlinien Bis jetzt haben wir uns nur die direkte Zuweisung von Rollen zu Rollengruppen angesehen, bei der die Benutzer durch ihre Mitgliedschaft in der Gruppe die Berechtigungen erhalten, um Verwaltungsvorgänge wie die Anzeige von Transportwarteschlangen oder die Durchführung von Discoverysuchvorgängen zu erledigen. Jedes System zur rollenbasierten Zugriffssteuerung braucht jedoch auch eine Standardrichtlinie, um den Benutzern einen Satz von grundlegenden Funktionen zur Verfügung zu stellen. In Exchange Server 2010 gibt es Rollenzuweisungsrichtlinien, mit denen den Benutzern bestimmte Tätigkeiten erlaubt werden können, die in früheren Versionen nur für Administratoren zur Verfügung standen. Wenn ein neues Postfach erstellt wird, erhält es automatisch die standardmäßige Rollenzuweisungsrichtlinie (Default Role Assignment Policy), die eine Reihe von Rollen eigens für Endbenutzer umfasst. Tabelle 4.2 führt die Rollen auf, die von dieser Standardrichtlinie abgedeckt werden. HINWEIS Endbenutzerrollen unterscheiden sich von Verwaltungsrollen darin, dass sie sich nur auf die für die Endbenutzer relevanten Daten auswirken, z.B. auf persönliche Angaben oder Informationen über die Verteilergruppen, zu denen sie gehören. Verwaltungsrollen haben dagegen einen weit umfassenderen Bereich und betreffen auch die Daten anderer Benutzer sowie andere Komponenten von Exchange. Jedes Postfach kann nur jeweils eine einzige Rollenzuweisungsrichtlinie haben, allerdings können Sie verschiedenen Postfächern oder Gruppen von Postfächern auch unterschiedliche Richtlinien zuteilen. Mit dem folgenden Befehl können Sie erkennen, welche Rollen die Standardrollenzuweisungsrichtlinie umfasst: Get-ManagementRoleAssignment -RoleAssignee 'Default Role Assignment Policy' 189
Rollenbasierte Zugriffssteuerung
Zuweisungsrichtlinien
Kapitel 4
Rollenbasierte Zugriffssteuerung
Wenn Sie prüfen wollen, welche Rollen einem bestimmten Benutzer über eine Richtlinie zugeteilt werden, können Sie statt des Richtliniennamens den Namen dieser Person angeben: Get-ManagementRoleAssignment -RoleAssignee 'Akers, Kim' Tabelle 4.2
Benutzerrollen in der Standardrollenzuweisungsrichtlinie Rolle
Verwendung
Standardmäßig aktiviert
MyBaseOptions
Grundlegende Option, um den Benutzern den Zugriff auf die Exchange-Systemsteuerung zu erlauben
Ja
MyContactInformation
Ermöglicht den Endbenutzern, ihre Telefon- und Kontaktinformationen zu ändern.
Ja
MyProfileInformation
Ermöglicht den Endbenutzern, ihren Vornamen, Nachnamen, die Initialen und den Anzeigenamen zu ändern.
Nein
MyVoiceMail
Erlaubt den Endbenutzern, ihre Voicemailoptionen (z.B. Begrüßungen) zu verwalten.
Nein
MyTextMessaging
Erlaubt den Endbenutzern, ihre Optionen für Textnachrichten zu verwalten.
Nein
MyDistributionGroupMembership
Erlaubt den Endbenutzern, ihre Mitgliedschaft in Verteilergruppen zu verwalten (Gruppen anzeigen, Gruppen verlassen, neuen Gruppen beitreten).
Ja
MyDistributionGroups
Erlaubt den Endbenutzern, neue Gruppen zu erstellen und deren Mitgliedschaften zu verwalten.
Nein
Sie können jede einzelne dieser Rollen aus der Standardzuweisungsrichtlinie entfernen, sodass die entsprechenden Funktionen für die Benutzer in der Exchange-Systemsteuerung nicht mehr verfügbar sind, beispielsweise die Optionen für Textnachrichten: Remove-ManagementRoleAssignment 'MyTextMessaging-Default Role Assignment Policy'
Wie wir auf den kommenden Seiten bei der Besprechung der Exchange-Systemsteuerung noch sehen werden, können Administratoren die Standardzuweisungsrichtlinie auch so ändern, dass den Benutzern weitere Optionen zur Verfügung stehen. Darüber hinaus ist es auch möglich, eine eigene Rollenzuweisungsrichtlinie zu erstellen und auf ausgewählte Benutzer anzuwenden, sodass diese Zugriff auf andere Funktionen haben als »Standard«-Benutzer. Um eine neue Rollenzuweisungsrichtlinie anzulegen und zum Standard zu machen, gehen Sie folgendermaßen vor: Set-RoleAssignmentPolicy 'New End-User Default Role Assignment Policy' –IsDefault
Rollenzuweisungsrichtlinien weisen Sie beim Erstellen oder Aktivieren von Postfächern mit NewMailbox bzw. Enable-Mailbox zu. Bei einem bestehenden Postfach können Sie mit Set-Mailbox die Richtlinie wechseln. Diese Zuweisungen nehmen Sie ausdrücklich vor, während die Zuweisung der Standardrichtlinie stillschweigend erfolgt. Eine ausdrückliche Zuweisung hat immer Vorrang vor einer stillschweigenden. Um einem Postfach ausdrücklich eine Richtlinie zuzuweisen, gehen Sie wie folgt vor: Set-Mailbox –Identity 'David Jones' –RoleAssignmentPolicy 'VIP Users'
190
Manchmal ist es erforderlich, eine Richtlinie auf eine bestimmte Gruppe von Benutzern anzuwenden. Nehmen wir beispielsweise an, dass Sie in einer einzigen Niederlassung versuchsweise Unified Messaging einführen möchten. Die Benutzer in dieser Filiale sollen in der Lage sein, ihre Voicemaileinstellungen in der Exchange-Systemsteuerung zu ändern. Da die Voicemailoptionen in der Standardrichtlinie nicht aktiviert sind, erstellen Sie eine neue Richtlinie, weisen darin die Voicemailoptionen zu (und alle anderen Rollen, die die Benutzer benötigen, z.B. um ihre Kontakt- und sonstigen persönlichen Informationen in der Exchange-Systemsteuerung zu ändern) und aktivieren die Richtlinie dann für die Postfächer in der gewünschten Niederlassung. Dazu verwenden Sie die folgenden Befehle: New-RoleAssignmentPolicy –Name 'VoiceMail Pilot Users' New-ManagementRoleAssignment –Role 'MyBaseOptions' –Policy 'VoiceMail Pilot Users' New-ManagementRoleAssignment –Role 'MyVoiceMail' –Policy 'VoiceMail Pilot Users' New-ManagementRoleAssignment –Role 'MyProfileInformation' –Policy 'VoiceMail Pilot Users' New-ManagementRoleAssignment –Role 'MyContactInformation' –Policy 'VoiceMail Pilot Users' Get-Mailbox –Filter {Office –eq 'Chicago'} | Set-Mailbox –RoleAssignmentPolicy 'VoiceMail Pilot Users'
Wenn sich die Benutzer das nächste Mal an der Exchange-Systemsteuerung anmelden, gilt für sie die neue Rollenzuweisungsrichtlinie.
Verbesserungen bei der rollenbasierten Zugriffssteuerung in Service Pack 1 Da der Übergang von dem älteren Berechtigungsmodell zur rollenbasierten Zugriffssteuerung in Exchange Server 2010 einen grundlegenden Wechsel darstellt, dürfte es nicht überraschen, dass Microsoft noch einige Verbesserungsmöglichkeiten gefunden hat, die in Exchange Server 2010 SP1 nachgeliefert wurden. Dabei wurde die Benutzeroberfläche zur Verwaltung der rollenbasierten Zugriffssteuerung in der Exchange-Systemsteuerung vollständig überholt. Änderungen an den Funktionen traten in vier Kategorien auf: 1. Datenbankweite Bereiche 2. Unterstützung für geteilte Active Directory-Berechtigungen 3. Bereitstellung einer Reihe von Berichten zur rollenbasierten Zugriffsssteuerung im Exchange Best
Practices Analyzer 4. Validierungsregeln für die rollenbasierte Zugriffssteuerung
Die radikale Umgestaltung der Benutzeroberfläche in der Exchange-Systemsteuerung, die jetzt einen umfassenderen Zugriff auf Rollen, Rollengruppen und Rollenzuweisungen bietet, können Sie auch als eine fünfte Kategorie von Verbesserungen ansehen. In den folgenden Abschnitten sehen wir uns diese Gebiete nacheinander an.
191
Rollenbasierte Zugriffssteuerung
Verbesserungen bei der rollenbasierten Zugriffssteuerung in Service Pack 1
Kapitel 4
Rollenbasierte Zugriffssteuerung
Verwalten von Rollengruppen in der ExchangeSystemsteuerung Alles, was wir bisher über die Verwaltung von Rollen, Rollengruppen und Rollenzuweisungen in der Exchange-Verwaltungsshell gesagt haben, gilt auch noch in Exchange Server 2010 SP1. Jetzt allerdings können wir die täglichen Aufgaben zur Verwaltung der rollenbasierten Zugriffssteuerung auch in der Exchange-Systemsteuerung durchführen. Um Ihnen die neue Oberfläche vorzuführen, sehen wir uns an, wie sich damit verschiedene häufig auftretende Aufgaben lösen lassen. Als erste Aufgabe betrachten wir die Erweiterung der Rollengruppe Help Desk, sodass deren Mitglieder die ActiveSync-Richtlinien verwalten können. In der der SP1-Version der Exchange-Systemsteuerung besteht Zugriff auf diese Richtlinien. Als Erstes müssen wir wissen, welche Rollen den Zugriff auf die Cmdlets für die Bearbeitung der ActiveSync-Richtlinien erlauben. Eine solche Richtlinie wird mit dem Cmdlet New-ActiveSyncMailboxPolicy erstellt, weshalb wir auf dem folgenden Wege die Rollen finden können, die solche Tätigkeiten zulassen: Get-ManagementRole –Cmdlet 'New-ActiveSyncMailboxPolicy' Name ------Recipient Policies
RoleType -------RecipientPolicies
Die Ausgabe zeigt, dass wir der Rollengruppe Help Desk die Rolle Recipient Policies zuweisen müssen, damit ihre Mitglieder ActiveSync-Richtlinien bearbeiten können. Als Nächstes öffnen wir die Exchange-Systemsteuerung mit einem Konto, das Mitglied der Rollengruppe Organisation Management ist, und wechseln im Abschnitt Benutzer und Gruppen zur Registerkarte Administratorrollen (siehe Abbildung 4.3). An der Beschreibung der Rollengruppe Help Desk können wir ablesen, dass ihr standardmäßig zwei Rollen zugewiesen sind, nämlich User Options und View-Only Recipients. Damit können die Mitglieder der Gruppe Help Desk Empfänger einsehen und Postfacheinstellungen ändern. Klicken Sie auf Details, um sich die derzeitigen Eigenschaften der Rollengruppe Help Desk anzusehen. Weiter unten in dem daraufhin angezeigten Dialogfeld kommen Sie zum Abschnitt Rollen, in dem die beiden zurzeit in der Gruppe vorhandenen Rollen aufgeführt werden. Klicken Sie auf Hinzufügen, um sich den Satz der möglichen Rollen anzeigen zu lassen, die Sie der Rollengruppe hinzufügen können (siehe Abbildung 4.4). In dieser Liste werden alle Rolle aufgeführt, die Exchange kennen, allerdings bieten einige davon auch Zugriff auf Funktionen, die in der Exchange-Systemsteuerung gar nicht zur Verfügung stehen. Beispielsweise ermöglicht die Rolle Database Availability Groups Administratoren, die Server und Datenbanken einer Datenbankverfügbarkeitsgruppe zu verwalten, was aber nur in der Exchange-Verwaltungskonsole oder -Verwaltungsshell möglich ist, nicht aber in der Exchange-Systemsteuerung, die keine Oberfläche dafür aufweist. Das Gleiche gilt auch für Rollen wie Edge Subscriptions, Email Address Policies und Mailbox Import Export. Natürlich können Sie auch diese Rollen einer Rollengruppe hinzufügen, allerdings müssen Sie dabei daran denken, dass die Benutzer die durch diese Rollen erlaubten Cmdlets nur in der Verwaltungskonsole und der Verwaltungsshell nutzen können.
192
Verbesserungen bei der rollenbasierten Zugriffssteuerung in Service Pack 1
Anzeigen von Rollengruppen in der SP1-Version der Exchange-Systemsteuerung
Abbildg. 4.4
Hinzufügen einer Rolle zu einer Rollengruppe
Rollenbasierte Zugriffssteuerung
Abbildg. 4.3
193
Kapitel 4
Rollenbasierte Zugriffssteuerung
Um die Aufgabe zu Ende zu führen, führen Sie einen Bildlauf nach unten durch, bis Sie die Rolle Recipient Policies finden. Klicken Sie darauf, um sie zu markieren, und klicken Sie anschließend auf Hinzufügen und dann auf OK, um das Dialogfeld zu schließen und zu den Eigenschaften der Rollengruppe Help Desk zurückzukehren. In der Liste der enthaltenen Rollen sollte jetzt auch Recipient Policies aufgeführt sein. Klicken Sie auf Speichern, um die Definition der Rollengruppe zu aktualisieren, und kehren Sie zur Exchange-Systemsteuerung zurück. Alle Benutzer, die Mitglieder der Rollengruppe Help Desk sind, können das nächste Mal, wenn Sie die Exchange-Systemsteuerung starten, auf ActiveSyncRichtlinien zugreifen. Bestehende Rollengruppen lassen sich jetzt in der Exchange-Systemsteuerung auf sehr einfache Weise erweitern. Als nächstes Beispiel wollen wir eine neue Rollengruppe für das Supportpersonal der Ebene 2 in einem bestimmten Wirtschaftsraum erstellen (in diesem Beispiel für die als EMEA [Europa, Middle East, Africa] zusammengefassten Gebiete Europa, Naher Osten und Afrika). Die IT-Manager in diesem Bereich haben entschieden, dass ihre erfahrensten Supportmitarbeiter in der Lage sein sollen, ein breiteres Spektrum an Verwaltungsaufgaben durchzufügen, u.a. auch Postfachsuchvorgänge und die Aktualisierung von Postfachinformationen. Dazu wird eine neue Rollengruppe benötigt, denn wir müssen die Fähigkeiten der Mitglieder dieser Gruppe auf die Bearbeitung von Objekten in einer bestimmten Organisationseinheit beschränken. Dazu müssen wir den Bereich der Rollengruppe, der standardmäßig die gesamte Organisation umfasst, auf die Organisationseinheit einschränken. Um unser Ziel zu erreichen, haben wir zwei Möglichkeiten. Wir können eine Rollengruppe von Grund auf neu erstellen oder aber eine vorhandene auswählen, die bereits viele der Merkmale der gewünschten Gruppe aufweist, und diese als Grundlage für unsere neue Gruppe kopieren. Wenn Sie schon damit vertraut sind, welche Funktionen durch welche in Exchange vorhandenen Rollen verfügbar gemacht werden, möchten Sie die neue Rollengruppe wahrscheinlich lieber ohne Vorlage erstellen. Anderenfalls ist es sicher am besten, eine vorhandene Gruppe, deren Berechtigungen denen der gewünschten neuen Rollengruppe möglichst nahe kommen, zu kopieren. Dazu markieren Sie sie im Abschnitt Rollengruppen der Exchange-Systemsteuerung und klicken auf Kopieren. Anschließend geben Sie der Kopie einen neuen Namen, der ihren Zweck angibt. Welche Methode Sie auch immer wählen, so gelangen Sie doch schließlich an den Punkt, an dem Sie wie in Abbildung 4.5 gezeigt die Eigenschaften der neuen Rollengruppe bearbeiten müssen. Neben den Rollen, die der Gruppe zugewiesen werden, ist das Wichtigste hier der Schreibbereich, der auf contoso.com/EMEA gesetzt ist. Mit anderen Worten, die Mitglieder dieser Rollengruppe können zwar Informationen über Objekte einsehen, die auch anderswo in Active Directory gespeichert sind, doch erstellen und ändern können sie Objekte nur in der Organisationseinheit EMEA. Da es in der Exchange-Systemsteuerung nicht möglich ist, neue Postfächer anzulegen, können die Mitglieder dieser Rollengruppe nur die Eigenschaften vorhandener Postfächer in der Organisationseinheit EMEA ändern. Außerdem sind sie in der Lage, neue Gruppen zu erstellen, aber nur, wenn deren Standardspeicherort die Organisationseinheit EMEA ist. Weitere Informationen
In Kapitel 5 erfahren Sie, wie Sie einen Standardspeicherort für Gruppen festlegen. Nachdem Sie eine Rollengruppe mit allen erforderlichen Rollen versehen haben, können Sie Mitglieder hinzufügen. Sobald Sie auf Speichern klicken, werden die neue Rollengruppe und die zugrunde liegende Sicherheitsgruppe erstellt und den Benutzern zugewiesen, die Sie als Mitglieder festgelegt haben.
194
Verbesserungen bei der rollenbasierten Zugriffssteuerung in Service Pack 1
Erstellen einer neuen Rollengruppe in der Exchange-Systemsteuerung
Rollenbasierte Zugriffssteuerung
Abbildg. 4.5
Datenbankweite Bereiche In Exchange Server 2010 können Sie Bereiche erstellen, um den Verwaltungszugriff auf bestimmte Empfänger und Server zu beschränken. Es zeigte sich jedoch, dass diese zwei Arten von Bereichen für die Bedürfnisse vieler Kunden nicht ausreichten, weshalb in SP1 als dritte Möglichkeit hinzukam, Datenbanken oder Gruppen von Datenbanken als Bereiche festzulegen. HINWEIS Nur Server mit SP1 (oder höher) berücksichtigen datenbankweite Bereiche. Wenn Sie daher solche Bereiche verwenden möchten, können Sie das nur tun, nachdem Sie alle Ihre Postfachserver auf SP1 aktualisiert haben. Um einen datenbankweiten Bereich zu erstellen, definieren Sie einen neuen Verwaltungsbereich auf der Grundlage einer Datenbankliste oder eines Datenbankfilters. Eine Datenbankliste enthält die durch Kommata getrennten Namen der einzelnen Datenbanken, die Sie in den Bereich einschließen möchten, und eignet sich zur Definition, wenn Sie den Verwaltungszugriff auf einen festen Satz von Datenbanken einschränken möchten, der sich wahrscheinlich nur selten ändert. Mit dem folgenden Befehl erstellen Sie z.B. einen Bereich, der den Zugriff auf die beiden angegebenen Datenbanken einschränkt: New-ManagementScope –Name 'CEO Databases' –DatabaseList 'CEO-Database1, CEO-StaffDatabase'
195
Kapitel 4
Rollenbasierte Zugriffssteuerung
Ein Datenbankfilter legt eine Bedingung fest, die Exchange bei der Ermittlung der gewünschten Datenbanken heranzieht. Diese Vorgehensweise eignet sich vor allem dann, wenn sich der Umfang des Bereichs an einen schwankenden Satz von Datenbanken anpassen können muss. Voraussetzung dafür ist natürlich, dass Sie einen Filter erstellen können, der stets die richtigen Datenbanken bezeichnet. In dem folgenden Beispiel setzen wir einen Filter ein, der alle Datenbanken mit dem Präfix DUB auswählt: New-ManagementScope –Name 'Dublin Databases' –DatabaseRestrictionFilter {Name –Like 'DUB-*'}
Wenn Sie einen datenbankweiten Bereich erstellen, gewähren Sie den Zugriff auf Cmdlets zur Bearbeitung von Datenbanken, z.B. Set-MailboxDatabaseCopy. Beachten Sie dabei, dass sich manche Operationen sowohl mit einem datenbank- als auch mit einem serverweiten Bereich steuern lassen, während andere eine bestimmte Art von Bereich voraussetzen. Mit einem datenbankweiten Bereich können Sie beispielsweise die Fähigkeit, Postfächer mit New-Mailbox anzulegen und mit Move-Mailbox zu verschieben, auf eine Zieldatenbank einschränken. Ein serverweiter Bereich ist hier sinnlos, da die Postfachdatenbanken nicht an bestimmte Server gebunden sind. Insidertipp: Filtern nach anderen Eigenschaften als dem Datenbanknamen
Meistens werden zur Filterung die Namen von Datenbanken herangezogen, es ist aber auch möglich, nach anderen Eigenschaften zu filtern, z.B. nach der Datenbankbeschreibung. Für Filter, die nicht auf dem Datenbanknamen beruhen (sondern z.B. auf Eigenschaften wie der Beschreibung oder dem definierten Namen), ist es erforderlich, die betreffenden Eigenschaften diszipliniert zu pflegen, da der Bereich sonst nicht die gewünschten Datenbanken umschließt. Datenbankweite Bereiche funktionieren nur auf Servern mit Exchange Server 2010 SP1 oder höher. Im Abschnitt »Grundlagen von Verwaltungsrollenbereichfiltern« der Exchange-Hilfe finden Sie eine vollständige Liste aller Eigenschaften, die Sie in Datenbankfilter aufnehmen können.
Umsetzen eines Modells mit geteilten Berechtigungen Der Zugriff auf Active Directory-Objekte erfolgt mithilfe von Cmdlets, die den Admistratoren und Benutzern über ihre jeweiligen Rollengruppen zur verfügbar gemacht werden. Damit Exchange selbst aber diesen Zugriff bereitstellen kann, werden zwei sehr wichtige Sicherheitsgruppen eingesetzt: 쐍 Die Gruppe Exchange Trusted Subsystem erlaubt Exchange-Diensten und -Cmdlets, Objekte zu bearbeiten, die sich im ausschließlichen Besitz von Exchange befinden, z.B. Server, Connectors und besondere Eigenschaften eigens für E-Mail-aktivierte Objekte. 쐍 Die Gruppe Exchange Windows Permissions erlaubt Exchange-Diensten und -Cmdlets, Objekte zu bearbeiten, die häufig der Steuerung durch Active Directory-Administratoren unterliegen, z.B. Benutzer- und Gruppenobjekte. Bei der standardmäßigen Exchange-Installation wird Exchange Trusted Subsystem zu einem Mitglied der Gruppe Exchange Windows Permissions gemacht, damit die Dienste und Cmdlets von Exchange Vollzugriffe auf sämtliche Inhalte von Active Directory haben. In vielen Unternehmen stellt die
196
Zusammenlegung der Verwaltungsberechtigungen für Exchange und Windows in einem Sicherheitsmodell, nach dem Administratoren sowohl Exchange als auch Active Directory steuern können, kein Problem dar, vor allem wenn ohnehin nicht deutlich zwischen diesen beiden Verwaltungsbereichen unterschieden wird. Es gibt jedoch Unternehmen, die diese beiden Gruppen von Administratoren klar voneinander trennen. Die Bedürfnisse solcher Firmen kann die normale Implementierung der rollenbasierten Zugriffssteuerung in Exchange Server 2010 nicht erfüllen. Auch in Exchange Server 2010 SP1 bleibt das Modell der gemeinsamen Verwaltung der Standard. Eine deutliche Trennung zwischen Exchange und Windows müssen Sie ausdrücklich einrichten. Bei Bedarf können Sie eines von zwei verschiedenen Modellen mit geteilten Berechtigungen einsetzen, wobei das eine auf Active Directory-Berechtigungen basiert und das andere auf der rollenbasierten Zugriffssteuerung. Das Modell der geteilten Active Directory-Berechtigungen weist die strengeren Einschränkungen auf, da hierbei die Fähigkeit zur Bearbeitung von Sicherheitsprinzipalen komplett aus Exchange entfernt wird. Das zweite Modell für geteilte Berechtigungen ist zu bevorzugen. Dabei schränken Sie die Berechtigungen zum Erstellen und Bearbeiten von Sicherheitsprinzipalen (z.B. Benutzerkonten) mithilfe der rollenbasierten Zugriffssteuerung auf wenige Konten ein, die Sie zu Mitgliedern einer entsprechenden Rollengruppe machen. Außerdem ermöglicht das Modell für geteilte Berechtigungen auf der Grundlage der rollenbasierten Zugriffssteuerung den Exchange-Administratoren, in Active Directory mit Exchange-spezifischen Objekten wie Verteilergruppen zu arbeiten. Wenn Sie das Modell der geteilten Active Directory-Berechtigungen nutzen möchten, müssen Sie die entsprechende Option beim Ausführen des Setupprogramms zur Installation der Exchange Server 2010-Organisation auswählen. Das können Sie sowohl in der grafischen Benutzeroberfläche von Setup tun (siehe Abbildung 4.6) als auch beim Ausführen von Setup.com zur Vorbereitung von Active Directory auf Exchange. Starten Sie dazu Setup.com mit den folgenden Parametern an einer Befehlszeile mit erhöhten Berechtigungen: C:> Setup /PrepareAD /ActiveDirectorySplitPermissions:True
Es ist möglich, zum normalen Berechtigungsmodell zurückzukehren, indem Sie Setup erneut ausführen, um die Änderungen an den Gruppen und Rollenzuweisungen rückgängig zu machen. Dazu verwenden Sie folgenden Befehl: C:> Setup /PrepareAD /ActiveDirectorySplitPermissions:False
Hinter den Kulissen wird die Trennung dadurch vollzogen, dass die Gruppe Exchange Trusted Subsystem aus der Gruppe Exchange Windows Permissions herausgenommen wird. Da alle Exchange Server-Computer Mitglieder von Exchange Trusted Subsystem sind, führt das dazu, dass die Exchange Server-Computer keine Active Directory-Objekte mehr bearbeiten können. Änderungen an solchen Objekten sind dann nur möglich, wenn Code (z.B. ein Cmdlet) von einem Konto mit ausreichenden WindowsBerechtigungen zur Aktualisierung von Active Directory ausgeführt wird. Des Weiteren werden die Rollenzuweisungen geändert, sodass Exchange-Administratoren nicht mehr die Möglichkeit haben, bestimme Tätigkeiten durchzuführen, z.B. neue E-Mail-aktivierte Konten anzulegen.
197
Rollenbasierte Zugriffssteuerung
Verbesserungen bei der rollenbasierten Zugriffssteuerung in Service Pack 1
Kapitel 4 Abbildg. 4.6
Rollenbasierte Zugriffssteuerung
Die Setupoption zum Anwenden des Modells geteilter Active Directory-Berechtigungen auf Exchange
Um das Modell geteilter Berechtigungen auf der Grundlage der rollenbasierten Zugriffssteuerung einzurichten, müssen Sie in Setup keine Änderungen vornehmen. Stattdessen erstellen Sie eine neue Rollengruppe mit den Konten, die Sicherheitsprinzipale bearbeiten dürfen, und weisen die Rollen zum Erstellen von Empfängern und Sicherheitsgruppen und zur Verwaltung von Mitgliedschaften zu. Die Mitglieder dieser neuen Rollengruppe sind in der Regel die Active Directory-Administratoren. Außerdem fügen Sie noch die Möglichkeit zum Delegierung von Rollenzuweisungen hinzu, damit die Mitglieder der neuen Gruppe ihre Rollen auch auf andere Benutzer übertragen können. Anschließend entfernen Sie die bisherigen Rollenzuweisungen, die Benutzer in die Lage versetzen, z.B. neue Postfächer zu erstellen, sodass nur noch die Mitglieder der neuen Gruppe solche Tätigkeiten durchführen können. Insidertipp: Eine Testorganisation als Ausgangspunkt
In der Exchange-Dokumentation finden Sie alle notwendigen Informationen, um ein Modell geteilter Berechtigungen entweder auf der Grundlage von Active Directory-Berechtigungen oder der rollenbasierten Zugriffssteuerung aufzubauen. Unter anderem erfahren Sie auch, wie Sie eine Organisation mit der RTM-Version von Exchange Server 2010 bei der Bereitstellung von SP1 auf das ausgewählte Modell umstellen können. Wie alle anderen Vorgänge, die mit Berechtigungen zu tun haben, erfordert auch dieser sorgfältige Planung und Tests. In einem ersten Schritt müssen Sie das Modell daher in einer Testorganisation ausprobieren, um herauszufinden, ob es tatsächlich Ihre Bedürfnisse befriedigt. Außerdem gebietet es der gesunde Menschenverstand, sich vor jeglichen Änderungen an der Organisation mit den Active Directory-Administratoren zusammenzusetzen, um das optimale Berechtigungsmodell für die Sicherheits-, Betriebs- und Geschäftsbedürfnisse zu bestimmen. Drittens müssen Sie sicherstellen, dass die Änderungen, die Sie an den Berechtigungen vornehmen, keine Störungen in anderen Anwendungen hervorrufen, die mit Exchange in Beziehung stehen, z.B. Systeme zur Kontenbereitstellung und zur Identitätsverwaltung.
198
Berichte zur rollenbasierten Zugriffssteuerung in Exchange Best Practices Analyzer Inzwischen sollten Sie von der Wichtigkeit der rollenbasierten Zugriffssteuerung für Exchange überzeugt sein. Weil sie so wichtig ist, wäre es gut, ihren Zustand in der Organisation auch in Exchange Best Practices Analyzer (ExBPA) analysieren und einen Bericht über die Probleme ausgeben zu können, die noch gelöst werden müssen. Vielleicht fragen Sie sich, wieso eine Analyse der rollenbasierten Zugriffssteuerung in Exchange Best Practices Analyzer vor Version SP1 nicht möglich war. Die Antwort ist einfach: Es gab noch nicht genügend Erfahrungswerte aus der Praxis, die Belege für empfehlenswerte Vorgehensweisen oder mögliche Probleme lieferten, und daher war es nicht möglich, Regeln für ExBPA zu erstellen, um Probleme aufzuspüren und Empfehlungen auszusprechen. ExBPA meldet unter anderem folgende Probleme: 쐍 Fehlende Container für die rollenbasierte Zugriffssteuerung (ein sehr grundlegendes Problem) 쐍 Fehlende vorgefertigte Rollentypen und Rollentypen (möglicherweise wurden sie von einem Administrator gelöscht, der mit den Cmdlets zur rollenbasierten Zugriffssteuerung herumgespielt hat) 쐍 Mehrere Standardrollenzuweisungsrichtlinien Für Probleme wie die folgenden werden Warnungen ausgegeben: 쐍 Für eine bestimmte Rollengruppe gibt es keine Zuweisung. 쐍 Die Rollengruppe Organization Management ist leer. (Wer verwaltet die Organisation?) 쐍 Es gibt keine Standardrollenzuweisungsrichtlinie. (Ohne sie können die Benutzer nicht auf die Exchange-Systemsteuerung zugreifen.) 쐍 In der Standardrollenzuweisungsrichtlinie fehlt die Rolle MyBaseOptions. (Die Benutzer können ihre Postfacheinstellungen nicht ändern.) 쐍 Einige Postfächer verfügen nicht über die Standardrollenzuweisungsrichtlinie. (Die betroffenen Benutzer können ihre Postfacheinstellungen nicht ändern.) 쐍 Es gibt einen exklusiven Bereich ohne Rollenzuweisungen. (Das kann Probleme beim Datenzugriff verursachen.) Das sind die häufigsten Probleme, die bei der rollenbasierten Zugriffssteuerung auftreten, weshalb diese Liste einen guten Ausgangspunkt für Verbesserungen darstellt. Mit zunehmenden Erfahrungen beim Einsatz der rollenbasierten Zugriffssteuerung in Produktionsumgebungen kommen wahrscheinlich noch andere Probleme ans Licht, die in zukünftige ExBPA-Berichte aufgenommen werden.
Validierungsregeln für die rollenbasierte Zugriffssteuerung Die Validierungsregeln hat Microsoft vor allem für die eigene Online-Hostingumgebung aufgestellt. Im Grunde genommen handelt es sich um datengesteuerte Regeln, die von Microsoft festgelegt wurden, nicht geändert werden können und genau vorschreiben, wie sich die rollenbasierte Zugriffssteuerung unter ganz bestimmten Umständen zu Verhalten hat. Das beste Beispiel für ihre Anwendung in der Enterprise Edition von Exchange ist die Steuerung des Zugriffs auf Ressourcenpostfächer über die Exchange-Systemsteuerung. Wenn Sie das Postfach für einen Konferenzraum öffnen, möchten Sie seinen Kalender einsehen und vielleicht Terminüberschneidungen lösen, aber in der Benutzeroberfläche
199
Rollenbasierte Zugriffssteuerung
Verbesserungen bei der rollenbasierten Zugriffssteuerung in Service Pack 1
Kapitel 4
Rollenbasierte Zugriffssteuerung
der Exchange-Systemsteuerung gibt es außerdem eine Reihe von Elementen, die für ein Raumpostfach keinen Sinn haben. Beispielsweise möchten Sie wahrscheinlich keine ActiveSync-Daten verwalten, da in dem Raumpostfach keine mobilen Geräte verwendet werden. Die Validierungsregeln, die in Exchange Server 2010 SP1 ausgeführt werden, entfernen daher einige der Oberflächenelemente für »normale« Postfächer. Die meisten Administratoren werden sich nicht einmal bewusst machen, dass es diese Validierungsregeln gibt, und sich auch nicht weiter darum kümmern, dass Microsoft sie in dem Produkt implementiert hat. Es ist jedoch gut zu wessen, was dafür sorgt, dass sich die Benutzeroberfläche an verschiedene Postfachtypen anpasst. Damit ist jetzt ein weiteres großes Mysterium unserer Zeit entschleiert.
Rollen in der Exchange-Systemsteuerung Neben einem Link in der Toolbox, der zur Exchange-Systemsteuerung führt, weist die Exchange-Verwaltungskonsole keine Benutzeroberfläche für den Umgang mit Rollen, Rollengruppen, -zuweisungen und -richtlinien auf. Alle Aspekte der rollenbasierten Zugriffssteuerung, die mit Endbenutzern (und deren Rollen) zu tun haben, werden in der Exchange-Systemsteuerung abgewickelt, und für alle anderen müssen Sie auf die Exchange-Verwaltungsshell zurückgreifen. Der Grund dafür mag daran liegen, dass Microsoft die Exchange-Verwaltungskonsole als Werkzeug für häufig vorkommende Routineaufgaben ansieht, wohingegen die Definitionen von Rollen oder Rollengruppen wahrscheinlich nicht sehr häufig geändert werden müssen. Wenn sich der Entwurf von Microsoft bewährt, wird in den meisten Bereitstellungen einfach der Standardsatz von Definitionen akzeptiert und niemals geändert. In der Exchange-Systemsteuerung von Exchange Server 2010 können Administratoren Rollen zu Benutzern zuweisen und die Standardrollenzuweisungsrichtlinie anpassen.
Zurechtfinden in der rollenbasierten Zugriffssteuerung Die Arbeitsweise eines Administrators in einer kleinen Exchange-Umgebung wird sich durch die rollenbasierte Zugriffssteuerung wahrscheinlich kaum ändern. Wenn Sie gewohnt sind, sich mit dem Administratorkonto anzumelden, um alle möglichen Aufgaben durchzuführen, können Sie das nach wie vor tun, denn dieses Administratorkonto ist standardmäßig Mitglied der Rollengruppe Organization Management und hat daher den vollständigen Lese- und Schreibzugriff auf sämtliche Objekte in der Exchange-Organisation, ebenso wie es in Active Directory praktisch alles tun kann. Die Konsequenzen und die Nützlichkeit der rollenbasierten Zugriffssteuerung zeigen sich mehr in großen Umgebungen, in denen häufig eine präzisere Steuerung für Administratorrollen erforderlich ist. Insidertipp: Ein guter Ratschlag
Sie können zwar bis ins Extreme genau festlegen, was jemand tun darf, doch Microsoft gibt den guten Ratschlag, auf besondere Rollenzuweisungen zu einzelnen Benutzern zu verzichten, da die Sicherheitsumgebung dadurch zu kompliziert wird und sich vor allem angesichts der Personalfluktuation nur schwer verwalten lässt.
200
Wenn Sie damit anfangen, die Exchange-Implementierung der rollenbasierten Zugriffssteuerung zu verwenden, kann es kompliziert sein, sich in den Beziehungen zwischen Rollen, Rollengruppen, Rollenzuweisungen, Bereichen und Benutzern zurechtzufinden. Am besten ist es, sich Zeit zu nehmen und damit vertraut zu machen, wie die einzelnen Komponenten zusammenspielen, bevor Sie Änderungen an den Standardzuweisungen vornehmen oder ihre eigenen Rollengruppen und Zuweisungen nach dem Bedarf in Ihrer Organisation hinzufügen. Lernen Sie auf einem Testserver die rollenbasierte Zugriffssteuerung kennen. Probieren Sie einige der Befehle aus, die wir in diesem Abschnitt vorgestellt haben, um sich mit den Prinzipien und ihrer Umsetzung in Exchange Server 2010 vertraut zu machen. Mit der Zeit wird das Bild klar werden.
Andere Verwaltungswerkzeuge Exchange schmückt sich auch noch mit anderen Verwaltungswerkzeugen, mit denen Administratoren viel Zeit verbringen werden. Es ist daher wichtig, dass wir uns nicht nur mit dem neuen rollenbasierten Autorisierungsmodell vertraut machen, das jetzt den Zugriff der Administratoren auf die verschiedenen Teile des Produkts bestimmt, sondern auch mit der Exchange-Verwaltungskonsole und der Exchange-Systemsteuerung. Als Nächstes sehen wir uns daher die Exchange-Verwaltungskonsole und die vielen Möglichkeiten an, die sie für die Benutzerverwaltung bietet.
201
Rollenbasierte Zugriffssteuerung
Andere Verwaltungswerkzeuge
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Kapitel 5
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
In diesem Kapitel: Die Exchange-Verwaltungskonsole
205
Freigaberichtlinien
226
Zertifikatverwaltung
229
Die Exchange-Systemsteuerung
234
Grundlegende Aufgaben für Benutzer in der Exchange-Systemsteuerung
237
Administratoraufgaben in der Exchange-Systemsteuerung
247
Gruppenverwaltung in der Exchange-Systemsteuerung
257
Diagnosemöglichkeiten für Exchange Server-Computer
270
Was wird verwaltet?
272
203
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Es ist alles andere als sinnvoll, ein E-Mail-System zu unterhalten, wenn niemand darüber kommunizieren kann. Um das möglich zu machen, müssen Sie zunächst die Werkzeuge kennenlernen, mit denen Sie die verschiedenen Objekte des Systems verwalten können. Microsoft wurde früher nicht ganz zu Unrecht dafür kritisiert, dass sich Exchange nur schwer verwalten ließ, was größtenteils daran lag, dass zur Aktivierung oder Verwaltung einzelner Funktonen schlecht dokumentierte und altertümliche Registrierungseinstellungen verwendet werden mussten. Außerdem haben viele Kunden nach Verwaltungsmöglichkeiten für verschiedene Arten von Administratoren gefragt – vom lokalen Administrator, der nur bestimmte Aufgaben auf einem einzigen Server ausführt, über das interne Supportpersonal bis zum Organisationsadministrator. Wenn Sie in Exchange Server 2003 oder 2007 jemandem die Möglichkeit geben wollten, Benutzereigenschaften zu ändern, z.B. Angaben über den Arbeitsplatz, dann mussten Sie ihm Zugriff auf die komplette Verwaltungskonsole geben. Abgesehen davon war es kompliziert, Berechtigungen für die Arbeit mit Exchange zu gewähren und zu verwalten. Das war gefährlich, denn dadurch konnte es vorkommen, dass unerfahrene Benutzer versehentlich wichtige Daten änderten. Es gab auch keine Möglichkeit, in den Verwaltungswerkzeugen die Vorgänge auf einem Exchange Server-Computer zu überwachen. Das Verwaltungsmodell, das den früheren Versionen von Exchange zugrunde lag, führte dazu, dass die Administratoren viel zu viel Zeit für banale Aufgaben aufwenden mussten, damit die ExchangeOrganisation funktionsfähig blieb, statt sich um produktivere Dinge zu kümmern. Neben der Investition in den PowerShell-Remotezugriff und die dramatische Vermehrung der Cmdlets, die in der Exchange-Verwaltungsshell zur Verfügung stehen, hat Microsoft in Exchange Server 2010 einen dreifachen Ansatz zur Verwaltung eingeführt: 1. Die Exchange-Verwaltungskonsole ist für hauptberufliche Administratoren gedacht, die Zugriff
auf die ganze Palette der Möglichkeiten benötigen, um sämtliche Aspekte einer Organisation zu bearbeiten. Das Konzept und die Umsetzung der Verwaltungskonsole für Exchange sollte jedem vertraut sein, der jemals versucht hat, einen Exchange Server-Computer zu unterhalten. 2. In Microsoft Exchange Server 2010 wurde mit der Exchange-Systemsteuerung eine neue webgestützte Komponente für Personen eingeführt, die im Rahmen ihrer Haupttätigkeit auch hin und wieder Exchange-Verwaltungsaufgaben wahrnehmen müssen und daher nur Zugriff auf bestimmte Objekte benötigen. Beispielsweise trifft das auf das Supportpersonal zu, das sich um die Pflege von Benutzerkonten kümmert. Die Exchange-Systemsteuerung ist eng mit der rollenbasierten Zugriffssteuerung und dem neuen Zugriffsmodell verknüpft, das wir im Abschnitt »Automatisch generierte PowerShell-Befehle« weiter hinten in diesem Kapitel besprechen. Der große Vorteil des rollenbasierten Ansatzes besteht darin, das sich die Autorisierung an den Aufgaben orientiert, die die Benutzer durchführen, und nicht an den zugrunde liegenden Active Directory-Objekten, auf die sich die Aufgaben beziehen. Es ist einfacher, ein Verständnis für solche Rollen zu entwickeln und Einzelpersonen die richtigen Rollen zuzuweisen, als sich mit komplizierten Active Directory-Berechtigungen herumschlagen zu müssen. 3. Um Einstellungen zu ändern, die keinerlei Auswirkungen auf den Systembetrieb oder die Leistung haben, sollten sich die Benutzer nicht an den Administrator oder das Supportpersonal wenden müssen. In Exchange Server 2010 stehen über OWA (Outlook Web App) jetzt weit mehr durch die Benutzer einstellbare Optionen zur »Selbstbedienung« zur Verfügung als früher. Beispielsweise können die Benutzer jetzt selbst Verteilergruppen beitreten oder sich daraus entfernen, sofern dies in den Gruppeneigenschaften zugelassen ist. In diesem Kapitel sehen wir uns die Änderungen an, die an der Exchange-Verwaltungskonsole in Exchange Server 2010 vorgenommen worden sind, und beschäftigen uns mit der Exchange-Systemsteuerung, bevor wir uns im nächsten Kapitel um die verschiedenen Arten von Postfächern und Gruppen kümmern. 204
Die Exchange-Verwaltungskonsole In Exchange gab es schon immer eine Verwaltungskonsole. Die erste Generation enthielt das Programm ADMIN, die zweite den Exchange-System-Manager, und in Exchange Server 2007 wurde die Exchange-Verwaltungskonsole eingeführt. Sowohl der Exchange-System-Manager als auch die Exchange-Verwaltungskonsole sind MMC-Snap-Ins (Microsoft Management Console). Für andere Elemente seiner grafischen Oberfläche, z.B. die vielen Assistenten zum Erstellen und Konfigurieren von Objekten, nutzt die Exchange-Verwaltungskonsole ausführlich Microsoft .NET Windows Forms.
Änderungen an der Konsole in Exchange Server 2010 Für Administratoren, die an Exchange Server 2007 gewöhnt sind, stellt die Version der Exchange-Verwaltungskonsole in Exchange Server 2010 (siehe Abbildung 5.1) im Großen und Ganzen vertrautes Terrain dar. Sie ist anders aufgebaut als der Exchange-System-Manager von Exchange Server 2003, aber unmittelbar verständlich, da die verschiedenen Objekte, die in einer Exchange-Organisation verwaltet werden müssen, logisch aufgeteilt sind. Manchmal müssen Sie überlegen, wo eine bestimmte Einstellung untergebracht sein könnte, aber im Allgemeinen lassen sich die verschiedenen Elemente schnell finden. Abbildg. 5.1
Die Verwaltungskonsole von Exchange Server 2010
205
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Die Exchange-Verwaltungskonsole
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Die Informationen über eine Exchange-Konsole sind von oben nach unten in die folgenden Hauptbereiche gegliedert: 쐍 Organisationskonfiguration Hier haben Administratoren Zugriff auf Einstellungen, die die ganze Organisation betreffen. Beispielsweise richten Sie hier E-Mail-Adressrichtlinien ein und erstellen neue E-Mail-Adressen für Empfänger oder neue Transportregeln für sämtliche ausgehenden Nachrichten. Außerdem ist dies die Stelle, an der Sie Datenbankverfügbarkeitsgruppen (und die zugehörigen Datenbankkopien) verwalten. 쐍 Serverkonfiguration Hier können Administratoren die Konfiguration von Postfach-, Clientzugriffs- und Hub-Transport-Servern bearbeiten, z.B. die von Exchange verwendeten Zertifikate. Wenn in Ihrer Organisation Unified Messaging verwendet wird, erfolgt hier auch die Konfiguration der UM-Server. Beispielsweise richten Sie in diesem Abschnitt die Sende- und Empfangsconnectors von Hub-Transport-Servern ein und legen fest, wie die Dateien für das Outlook-Offlineadressbuch durch die Clientzugriffsserver verteilt werden. 쐍 Empfängerkonfiguration Hier können Administratoren mit allen Arten von E-Mail-aktivierten Empfängern arbeiten: Postfächer (auch verknüpfte, Raum- und Gerätepostfächer) und Kontakte (einschließlich E-Mail-Benutzer). In diesem Abschnitt der Verwaltungskonsole erstellen Sie auch Verschiebeanforderungen. Das ist die neue Methode, um Postfächer innerhalb einer ExchangeOrganisation oder von einer Exchange-Organisation zu einer anderen zu verschieben. 쐍 Toolbox Wie in Exchange Server 2007 bietet dieser Abschnitt der Verwaltungskonsole Zugriff auf verschiedene Hilfsprogramme von Microsoft, die außerhalb der Konsole ausgeführt werden. Den Inhalt dieses Werkzeugkastens beschreiben wir ausführlicher in Kapitel 15, »Die ExchangeToolbox«. 쐍 Postfach Vollständige Gesamtstruktur Die Aufnahme von Exchange-Gesamtstrukturen in die Exchange-Verwaltungskonsole ermöglicht es, bis zu zehn Exchange-Organisationen von einer Stelle aus zu verwalten. Eine Exchange-Gesamtstruktur ist nichts anderes als eine Exchange-Organisation, die zu einer Active Directory-Gesamtstruktur gehört, wobei eine Active Directoy-Gesamtstruktur immer nur eine Exchange-Gesamtstruktur beherbergen kann. Dank dieser Änderung können Sie in der Exchange-Verwaltungskonsole gleichzeitig sowohl Objekte einer lokalen Exchange-Organisation als auch einer Organisation in einer Hostingumgebung bearbeiten. In Exchange Server 2010 verfügt die Verwaltungskonsole unter anderem über die folgenden bemerkenswerten Neuerungen: 쐍 Die Funktion zur Organisationsintegrität bietet Administratoren eine Momentaufnahme der entscheidenden Daten (Postfächer, Server usw.) über die Organisation. 쐍 Es ist möglich, ein Protokoll der während einer Konsolensitzung ausgeführten PowerShellBefehle zu erstellen und zur späteren Durchsicht zu exportieren. 쐍 Befehle können für eine ausgewählte Gruppe von Objekten ausgeführt werden, es ist also nicht mehr nötig, die Objekte einzeln zu markieren und zu ändern. 쐍 Die Diagnoseebene für Exchange-Komponenten kann in der Konsole festgelegt werden. In Exchange Server 2007 mussten Sie dazu auf die Verwaltungsshell zurückgreifen. 쐍 Es gibt Benutzeroberflächen für neue Funktonen wie Datenbankverfügbarkeitsgruppen und die Verbindungsprüfung in der Toolbox. 쐍 Die Benutzeroberfläche zum Erstellen und Verwalten von Speichergruppen wurde entfernt. 쐍 Links zu Ressourcen aus der Exchange-Community helfen Administratoren, externe Hilfe und Informationen über das Produkt zu finden.
206
쐍 Es gibt noch verschiedene weitere Aktualisierungen und Verbesserungen (und einige Korrekturen von Fehlern). Beispielsweise können Sie beim Erstellen eines neuen Postfachs einen Benutzerprinzipalnamen (User Principal Name, UPN) aus den in der Active Directory-Gesamtstruktur bekannten UPN-Suffixen zuweisen. TIPP
Mit Get-UserPrincipalNameSuffix können Sie feststellen, welche Suffixe vorhanden
sind. Insidertipp: Hinter den Kulissen
Hinter den Kulissen sind an der Exchange-Verwaltungskonsole die folgenden beiden wichtigen Änderungen vorgenommen worden: 쐍 Erstens stützt sich die Exchange-Verwaltungsshell wie alle anderen Verwaltungskomponenten auf den PowerShell-Remotezugriff und muss daher beim Start Verbindung mit einem Exchange Server 2010-Computer aufnehmen. Wenn die Konsole keine PowerShell-Remotesitzung aufbauen kann, ist sie auch nicht in der Lage, Active Directory zu erreichen, um Exchange-Konfigurationsdaten abzurufen. 쐍 Zweitens gründen sich alle Berechtigungen in Exchange jetzt auf die rollenbasierte Zugriffssteuerung. Die Exchange-Verwaltungskonsole prüft, zu welchen Rollen der Benutzer gehört, der die sie gestartet hat, und zeigt dann nur die für diese Rollen zulässigen Optionen an. Diese Neuerungen sind jedoch mit einer Leistungseinbuße erkauft worden, weshalb die Version der Verwaltungskonsole in Exchange Server 2010 nicht so schnell startet wie ihr Gegenstück in Exchange Server 2007. Da sämtliche Daten durch eine PowerShell-Remotesitzung geschleust werden müssen, verlangsamt das auch häufig die Aktualisierung des Bildschirms oder der Datenabruf, wie die entsprechende Meldung in der linken unteren Ecke des Konsolenfensters anzeigt. In SP1 hat Microsoft die Startgeschwindigkeit der Exchange-Verwaltungskonsole durch Vorabladen von PowerShell, optimierte Verwendung der rollenbasierten Zugriffssteuerung und neue Cmdlets wie Get-OrganizationHealth zur Beschleunigung des Abrufs von Active Directory-Daten erhöht, aber die Leistung ist immer noch geringer als in Exchange Server 2007. Die Exchange-Verwaltungskonsole enthält jetzt auch eine interessante neue Funktion, mit der Administratoren E-Mails an Benutzer senden können. Bevor Sie sie nutzen können, müssen Sie auf dem Computer, auf dem die Verwaltungskonsole ausgeführt wird, jedoch einen E-Mail-Client einrichten. Auf einer Arbeitsstation ist das wahrscheinlich kein Problem, aber auf einem Server ist es möglicherweise nicht akzeptabel. Wie alle anderen Bestandteile von Exchange ist auch die Verwaltunskonsole mehrsprachig und zeigt ihre Oberfläche in der Sprache an, die in Windows für das ausführende Konto ausgewählt wurde. Bevor Sie eine bestimmte Sprache auswählen können, müssen Sie jedoch das entsprechende Exchange-Sprachpaket auf dem Computer installieren. Steht die ausgewählte Sprache nicht zur Verfügung, wird Exchange standardmäßig in Englisch angezeigt. In mehrsprachigen Umgebungen sollten Sie auf allen für die Verwaltung genutzten Arbeitsstationen und Servern denselben Satz von Sprachen installieren. Die meisten Unternehmen installieren in einer solchen Situation einfach das gesamte Exchange-Sprachpaket, um Zugriff auf alle möglichen Sprachen zu haben. Dafür ist ein wenig mehr an Speicherplatz erforderlich, doch abgesehen davon wird der Server dadurch nicht zusätzlich belastet. Die Sprachpakete enthalten lokalisierte Zeichenketten, die nur bei Bedarf verwendet werden.
207
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Die Exchange-Verwaltungskonsole
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Ein veränderter Ansatz gegenüber Exchange Server 2003 Wenn Sie von Exchange Server 2003 auf Exchange Server 2010 aktualisierten, können Sie einen großen Unterschied in der Art und Weise erkennen, in der Exchange mit Active Directory-Objekten umgeht. E-Mail-aktivierte Empfänger sind Active Directory-Objekte und werden in Active DirectoryBenutzer und -Computer angezeigt, und in Exchange Server 2003 waren Sie es gewohnt, Empfänger über diese Konsole zu verwalten. In Exchange Server 2003 mussten Sie ständig zwischen den beiden Verwaltungsprogrammen wechseln: Empfängereigenschaften haben Sie in Active Directory-Benutzer und -Computer festgelegt und geändert, während die Verwaltung Exchange-spezifischer Objekte wie Server und Connectors über den Exchange-Server-Manager erfolgte. Natürlich konnte auch der Exchange-Server-Manager auf die in Active Directory-Benutzer und -Computer erstellten Objekte zugreifen (sonst wären Sie niemals in der Lage gewesen, Postfächer zu verwalten), aber diese Beziehung war eher sekundär und außerdem nur zum Lesen geeignet. Mit der Ersetzung des Exchange-Server-Managers in Exchange Server 2007 hat Microsoft eine grundlegende Änderung vorgenommen, um sämtliche Funktionen, die die Exchange-Verwaltungskonsole zur vollständigen Verwaltung E-Mail-aktivierter Empfänger benötigt, an einer Stelle zusammenzuführen. Die PowerShell-Cmdlets, die den Verwaltungskonsolen von Exchange Server 2007 und 2010 zugrunde liegen, enthalten sämtlichen Code, der zur Bearbeiten der Active Directory-Objekte erforderlich ist, und die Exchange-Administratoren verfügen über die notwendigen Berechtigungen zur Aktualisierung von Active Directory. Da Sie jetzt alles von einer Konsole aus erledigen können, bietet Exchange eine klarere und einfachere Verwaltungsumgebung. Die Administratoren müssen nicht mehr von einer Konsole zur anderen wechseln, um ihre Arbeit zu erledigen. Ein anderer Vorteil besteht darin, dass jetzt sauber zwischen Administratoren für Active Directory und für Exchange unterschieden werden kann. In kleinen Organisationen werden beide Aufgaben häufig von denselben Personen ausgeführt, aber eine solche Trennung der Verwaltungsverantwortung ist in umfangreichen Umgebungen sehr wichtig. Dieser neue Ansatz bedeutet, dass Exchange keinen Add-In-Code für Active Directory-Benutzer und -Computer mehr installiert, sodass Sie von dort aus nicht mehr in der Lage sind, Benutzer, Kontakte und Gruppen für E-Mail zu aktivieren und neue Postfächer zu erstellen. Zwar können Sie in Active Directory-Benutzer und -Computer weiterhin Gruppen erstellen, aber sie dort nicht für E-Mail aktivieren. Außerdem ist es nicht möglich, von dieser Konsole aus dynamische Verteilergruppen zu erstellen. Die Exchange-Objekte werden jedoch weiterhin in Active Directory-Benutzer und -Computer angezeigt, und Sie können dort die allgemeinen Active Directory-Eigenschaften ändern, nicht aber die Exchange-spezifischen. TIPP Um sich die Trennung zwischen den beiden Konsolen deutlich zu machen, denken Sie daran, dass alle über das Cmdlet Set-User zugänglichen Eigenschaften in Active DirectoryBenutzer und -Computer verwaltet werden können, alle über die Cmdlets für Exchange-Empfänger wie Set-Mailbox und Set-DistributionGroup zugänglichen dagegen in der Exchange-Verwaltungskonsole. Abbildung 5.2 zeigt ein gutes Beispiel für die Trennung der Verantwortungsbereiche in der Praxis. Active Directory-Benutzer und -Computer kann eine Liste aller Empfänger in einer Organisationseinheit anzeigen, sodass Sie die Kontakte, Verteilergruppen und Benutzer sehen können. Zu den Verteilergruppen gehören sowohl E-Mail-aktivierte Verteiler- und Sicherheitsgruppen als auch »abfragebasierte Verteilergruppen«, wie dynamische Verteilergruppen in Active Directory genannt werden (so 208
hießen diese Gruppen auch in Exchange, als sie in Exchange Server 2003 eingeführt wurden). Diese Objekte sind zwar sichtbar, aber Sie haben keinen Zugriff auf ihre Eigenschaften. Die Exchangebezüglichen Informationen, die früher aufgrund des von Exchange in der Konsole installierten AddIn-Codes in Active Directory-Benutzer und -Computer verfügbar waren, werden jetzt nicht mehr bereitgestellt. Abbildg. 5.2
Dynamische Verteilergruppen in Active Directory-Benutzer und -Computer
Verwalten von Exchange Server 2010- und Exchange Server 2007-Objekten Wie in Kapitel 2, »Installation von Microsoft Exchange Server 2010«, gesagt, versieht Exchange Objekte wie Postfächer und Connectors mit einer Versionsnummer, anhand derer die Verwaltungswerkzeuge erkennen können, ob Sie ein Objekt bearbeiten können oder nicht. Zur Verwaltung eines Objekts sollten Sie immer noch die Konsole der Version verwenden, mit der Sie es erstellt haben. Falls sie nicht mehr zur Verfügung steht, können Sie im Allgemeinen die neueste Version der Verwaltungskonsole nehmen, da sie wahrscheinlich rückwärtskompatibel mit den älteren Versionen ist. Eine Vorwärtskompatibilität für Objekte, die sich von einer Version zur anderen radikal ändern können, ist in Software nur sehr selten anzutreffen. Es gibt jedoch einige Ausnahmen von dieser allgemeinen Richtlinie, denn einige Änderungen sind zu gravierend, um rückwärtskompatiblen Code zu erstellen: 쐍 Postfachdatenbanken von Exchange Server 2007 können Sie zwar in der Verwaltungskonsole von Exchange Server 2010 anzeigen, aber nicht verwalten, da Exchange Server 2010 keinerlei Kenntnisse über die Speichergruppen hat, an die die Datenbanken der früheren Version gebunden waren. 쐍 Mit der Verwaltungskonsole von Exchange Server 2010 können Sie Exchange Server 2007-Postfächer nicht für Unified Messaging aktivieren oder deaktivieren. Auch die Verwaltung von mobilen Geräten, die mit Postfächern auf Exchange Server 2007-Computern synchronisiert werden, ist nicht möglich. Das liegt an den Änderungen, die in Exchange Server 2010 an Unified Messaging und ActiveSync vorgenommen wurden. 209
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Die Exchange-Verwaltungskonsole
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
쐍 Die Warteschlangenanzeige von Exchange Server 2010 kann keine Verbindung zu einem HubTransport-Server mit Exchange Server 2007 aufnehmen, um Informationen über Nachrichten in dessen Warteschlangen abzurufen. 쐍 Aufgrund der veränderten Struktur und der stark erweiterten Möglichkeiten können Exchange Server 2010-Transportregeln nur in der Verwaltungskonsole dieser Version angezeigt werden. 쐍 Postfachserver mit Exchange Server 2010 weisen ganz andere Eigenschaften auf als ihre Vorgänger, denn einerseits müssen sie jetzt auch in Datenbankverfügbarkeitsgruppen eingesetzt werden können, während andererseits einige veraltete Eigenschaften (z.B. für Speichergruppen) entfernt wurden. Daher können Postfachserver mit Exchange Server 2007 und 2010 jeweils nur über ihre eigene Version der Verwaltungskonsole bearbeitet werden. 쐍 Auch wenn die Daten ähnlich erscheinen mögen, können Sie von Exchange Server 2010 aus keine Nachrichtenverfolgung für Exchange Server 2007 durchführen und umgekehrt. Stattdessen müssen Sie die Nachrichtenverfolgung erst auf den Servern einer Version durchführen und dann ggf. zu denen der anderen wechseln, um den Vorgang abzuschließen. Bei der Verwendung der Verwaltungskonsole von Exchange Server 2010 für ältere Objekte können noch weitere kleinere Unstimmigkeiten auftreten. Im Zweifelsfall sollten Sie die Version des Verwaltungswerkzeugs einsetzen, mit dem Sie das betreffende Objekt erstellt haben.
Starten der Exchange-Verwaltungskonsole Wie die Exchange-Verwaltungsshell basiert auch die Verwaltungskonsole von Exchange Server 2010 auf dem PowerShell-Remotezugriff und der rollenbasierten Zugriffssteuerung. Wenn die Konsole startet, nimmt sie Kontakt mit einem Server auf, um eine PowerShell-Remotesitzung zu initialisieren. Gewöhnlich wählt sie dabei den Computer aus, auf dem sie ausgeführt wird, sofern darauf auch Exchange Server 2010 läuft, allerdings können Sie auch einen anderen Server auswählen, indem Sie auf den Stammknoten der lokalen Exchange-Organisation rechtsklicken, um die Eigenschaften aufzurufen. Dort können Sie erkennen, mit welchem Server die Konsole zurzeit verbunden ist, und können sich zwischen der automatischen Verbindung mit einem Server oder der manuellen Auswahl eines bestimmten Servers entscheiden (siehe Abbildung 5.3). Nachdem die Verwaltungskonsole eine PowerShell-Remotesitzung eingerichtet hat, ruft sie die Daten ab, mit denen sie ihre Benutzeroberfläche füllt. Das können Sie daran erkennen, dass unten links in der Konsole die Meldung Aktualisieren: wird ausgeführt eingeblendet wird. Während der Initialisierung führt die Verwaltungskonsole die Cmdlets aus, die Informationen über die Organisation, die Server usw. abrufen (und die nach den Rollen des Kontos, unter dem die Konsole läuft, zugelassen sind), und füllt so seinen Cache mit wichtigen Daten über die Exchange-Organisation. Wenn der Benutzer später die einzelnen Knoten öffnet, führt die Konsole noch weitere Cmdlets aus, um Informationen über die betreffenden Objekte zu gewinnen. Wenn der Benutzer beispielsweise unter Serverkonfiguration auf Clientzugriff klickt, führt die Konsole Cmdlets wie Get-OWAVirtualDirectory, Get-OABVirtualDiretory und Get-ActiveSyncVirtualDirectory aus. Bewegt er sich zum Abschnitt Empfängerkonfiguration, wird der folgende Befehl gegeben, um Angaben über alle E-Mail-aktivierten Empfänger einzuholen. Die Anzahl der aus Active Directory abzurufenden Objekte ist beschränkt, die Objekte werden aber noch sortiert. Get-Recipient -PropertySet ConsoleLargeSet -ResultSize '500' -SortBy DisplayName -RecipientType 'DynamicDistributionGroup', 'UserMailbox','MailContact', 'MailUser','MailUniversalDistributionGroup','MailUniversalSecurityGroup', 'MailNonUniversalGroup' 210
Die Exchange-Verwaltungskonsole
Auswählen eines Servers für die Exchange-Verwaltungskonsole
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Abbildg. 5.3
Wenn die Verwaltungskonsole nicht auf den Server zugreifen kann
Es kann vorkommen, dass die Exchange-Verwaltungskonsole nicht in der Lage ist, auf einen Server zuzugreifen, um Daten abzurufen. Wie wir wissen, sind für den PowerShell-Remotezugriff komplizierte Verbindungen erforderlich, bevor Befehle erfolgreich ausgeführt werden können. Daran sind das Netzwerk, die Windows-Remoteverwaltung, die Internetinformationsdienste (IIS) und Active Directory beteiligt. Wenn es dabei zu Störungen kommt, kann die Exchange-Verwaltungskonsole keine Daten anzeigen. Außerdem ist es möglich, dass Verzögerungen von mehreren Minuten auftreten, in denen die Konsole nicht reagiert. Das geschieht häufiger in Organisationen mit Exchange Server-Computern älterer Versionen. In diesem Fall sehen Sie Fehlermeldungen der folgenden Art: Der Task konnte keine Verbindung mit IIS auf dem Server 'cas1.contoso.com' herstellen. Stellen Sie sicher, dass der Server vorhanden und von diesem Computer aus erreichbar ist: Der RPC-Server ist nicht verfügbar. Der Befehl 'Get-OwaVirtualDirectory' wurde ausgeführt.
Microsoft ist über dieses Problem informiert und arbeitet daran. Zum Initialisierungsvorgang gehört es auch, die RBAC-Rollenzuweisungen für den Benutzer abzurufen. Um die Exchange-Verwaltungskonsole nutzen zu können, sollte ein Benutzer über eine Verwaltungsrolle verfügen, da seine Möglichkeiten in der Konsole sonst stark eingeschränkt sind. Die Verwaltungskonsole greift auf die RBAC-Metadaten zu, die sie in ihrem Cache aufbewahrt, um dem Benutzer die Optionen anzuzeigen, die für ihn verfügbar sind. Hat ein Benutzer beispielsweise die Rolle View-Only Management, kann er keine Änderungen an den Objekten vornehmen. In der Verwaltungskonsole werden dadurch Felder grau angezeigt. Außerdem ist jedes unerreichbare Feld durch ein kleines, gelbes Schlosssymbol gekennzeichnet (siehe Abbildung 5.4). 211
Kapitel 5 Abbildg. 5.4
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Eingeschränkter Zugriff auf die Exchange-Verwaltungskonsole
Es ist sinnvoll, eine maßgeschneiderte Benutzeroberfläche auf der Grundlage der jeweiligen Rolle eines Benutzers zusammenzustellen, um ihm den Ärger zu ersparen, wenn er versucht, eine Aufgabe auszuführen, für die er nicht die erforderlichen Berechtigungen hat. Selbst solche angepassten Konsolen werfen jedoch Fragen auf. So kann es vorkommen, dass die Benutzer sich fragen, wieso ihre Version der Konsole anders aussieht als die eines Kollegen (oder von dem abweicht, was sie in Büchern oder online gelesen haben). Nachdem die RBAC-Daten bei der Initialisierung der Konsole geladen wurden, bleiben sie jedoch statisch. Wenn eine Änderung an der Rolle des Benutzers vorgenommen wird, spiegelt sich dies in der Konsole erst dann wieder, wenn sie erneut geladen wird und die veränderten RBAC-Informationen aus Active Directory in ihren Cache lädt.
Zugriff der Konsole auf die Exchange-Daten Die Exchange-Verwaltungskonsole ist vollständig auf Active Directory angewiesen. Während einer Sitzung liest und schreibt sie Daten über Objekte, die sie aus dem Container der Microsoft ExchangeOrganisation im Konfigurationsnamenskontext abruft. Andere Daten stammen aus Postfachdatenbanken und den Datenbanken für öffentliche Ordner, aber die Quelle der meisten Informationen, die in der Konsole angezeigt werden, ist Active Directory. Die in Active Directory enthaltenen Informationen sind statisch und spiegeln keine Änderungen in Echtzeit wieder, denn das würde zu ständigen Replikationsanforderungen führen, um mit den Statusänderungen für Exchange-Objekte Schritt zu halten. Selbst wenn Active Directory mit der Replikation nachkommen könnte, würde diese übermäßige Aktivität das Netzwerk überfluten und produktivere Tätigkeiten behindern. Die Abhängigkeit von Active Directory ist der Grund dafür, dass die
212
Exchange-Verwaltungsshell manchmal flüchtige Daten ausgibt, die Sie in der Konsole niemals zu sehen bekommen. Beispielsweise können Sie sich mit dem Cmdlet Get-MoveRequestStatus ansehen, bis zu welchem Prozentsatz der Verschiebevorgang für ein Postfach abgeschlossen und wie hoch die augenblickliche Rate der Datenübertragung zwischen Quell- und Zielserver ist – Einzelheiten, die Sie in der Konsole niemals zu Gesicht bekommen. In der Exchange-Verwaltungskonsole wird der Status einer Verschiebeanforderung vom Start über »wird ausgeführt« bis zum Abschluss angezeigt, aber nur, wenn Sie die Anzeige aktualisieren. Insidertipp: Abrufen der neuesten Informationen
Da Ihnen die Exchange-Verwaltungskonsole im Grunde genommen nur eine statische Momentaufnahme der Objekte zeigt, die Sie sich ansehen, sollten Sie vor jeder Änderung die Anzeige aktualisieren, um sicherzugehen, dass sie auch die jüngsten Informationen haben und keine veralteten Daten. Wenn Sie beispielsweise die Anzeige der Postfächer aktualisieren, werden auch neu hinzugefügte Postfächer sichtbar, und geänderte Postfächer – die etwa auf einen anderen Server verschoben wurden oder die ein Archiv erhalten haben – werden mit ihrem neuen Status dargestellt. Ein weiteres Beispiel dafür, wie ärgerlich die Abhängigkeit von Active Directory sein kann, ist die Tatsache, dass die Exchange-Verwaltungskonsole bei der Auflistung der Postfächer nicht anzeigt, wie viel Speicherplatz sie jeweils einnehmen. Im Gegensatz zu den anderen Postfacheigenschaften, die dargestellt werden, wird der Speicherbedarf nicht in Active Directory vorgehalten. Um diese Angabe anzuzeigen, müsste die Exchange-Verwaltungskonsole den Informationsspeicherdienst aufrufen, um die Speicherdaten für die einzelnen Postfächer zu ermitteln. In einer kleinen Installation, in der sich alle Postfächer in derselben Datenbank befinden, mag dieser Zusatzaufwand akzeptabel sein, aber versuchen Sie sich einmal die Auswirkungen auf die Leistung auszumalen, wenn Daten über 30 Postfächer abgerufen werden müssen, die in 15 verschiedenen Datenbanken auf zehn Servern verteilt sind. Die Exchange-Verwaltungskonsole zeigt an, wie viel Speicher ein einzelnes Postfach zurzeit einnimmt, wenn Sie sich dessen Eigenschaften ansehen (siehe Abbildung 5.5). Gewöhnlich tritt eine kurze, aber merkliche Verzögerung auf, während diese Angabe abgerufen wird, da das zugrunde liegende Cmdlet Get-Mailbox auf die Active Directory-Informationen eines Domänencontrollers in der Domäne des Benutzers zugreifen muss, um sicherzustellen, dass die Informationen auf dem neuesten Stand sind. Der Umweg über einen bestimmten Domänencontroller verhindert, dass veraltete Informationen von einem globalen Katalogserver abgerufen werden. Außerdem verwendet die Konsole das Cmdlet GetMailboxStatistics, um Informationen vom Informationsspeicher abzurufen. Insgesamt werden also die beiden folgenden Befehle eingesetzt: Get-Mailbox –Identity 'Akers, Kim' –ReadFromDomainController Get-MailboxStatistics –Identity 'Akers, Kim'
In Abbildung 5.5 können Sie auch eine Änderung erkennen, die in Exchange Server 2010 SP1 vorgenommen wurde: Postfach und persönliche Archive eines Benutzers können jetzt in zwei verschiedenen Datenbanken untergebracht werden. HINWEIS Unter Umständen können Sie in den Postfacheigenschaften erkennen, dass die letzte Anmeldung von einem Konto aus geschah, das sich nicht im Besitz des Postfachs befindet. Das kann vorkommen, wenn sich ein anderer Benutzer mithilfe delegierter Berechtigungen daran angemeldet hat.
213
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Die Exchange-Verwaltungskonsole
Kapitel 5 Abbildg. 5.5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Postfacheigenschaften mit dem zurzeit genutzten Speicherplatz
Zwei wichtige Einstellungen bestimmen, wie die Exchange-Verwaltungskonsole Daten anzeigt. Die erste betrifft den Domänencontroller, von dem die Konsole die Konfigurationsdaten liest. Während der Initialisierung wird automatisch ein Domänencontroller des aktuellen Standorts ausgewählt, doch können Sie die Konsole anweisen, einen anderen Controller zu verwenden. Dazu rechtsklicken Sie auf den Knoten Organisationskonfiguration, klicken auf die Option Konfigurationsdomänencontroller ändern (siehe Abbildung 5.6) und wählen dann den gewünschten Domänencontroller aus. Abbildg. 5.6
214
Auswählen eines Konfigurationsdomänencontrollers für die Exchange-Verwaltungskonsole
Natürlich können Sie die Active Directory-Konfiguration auch mit Get-ExchangeServer abrufen (der Parameter Status ist erforderlich, damit die Verwaltungsshell diese Information von Active Directory abfragt) und den bevorzugten Domänencontroller mit Set-ExchangeServer auswählen: Get-ExchangeServer –Identity 'ExServer1' –Status Set-ExchangeServer –Identity 'ExServer1' -DomainController 'dc1.contoso.com'
Die zweite Einstellung legt fest, wie viele Objekte die Verwaltungskonsole im Ergebnisbereich höchstens anzeigt. Aus Leistungsgründen ist die Anzahl der von Active Directory abgerufenen Daten auf 1000 Objekte beschränkt. In kleinen Installationen kann dieser Wert wahrscheinlich so bleiben, denn selbst damit sollte es möglich sein, in der Konsole alles anzuzeigen, was es in der Organisation zu sehen gibt. Bei größeren Installationen sieht die Situation jedoch anders aus, da es dort vorkommen kann, dass Sie mehr als 1000 Objekte anzeigen lassen möchten. Wenn Sie beispielsweise 10.000 Postfächer auf einem Postfachserver unterhalten, stellt die Begrenzung auf 1000 Objekte schon eine Einschränkung dar. Um diese Einstellung zu ändern, wählen Sie im Aktionsbereich (dem Bereich am rechten Rand der Konsole, in dem mögliche Optionen für das markierte Objekt angezeigt werden) Die Anzahl der maximal anzuzeigenden Objekte ändern aus und geben den gewünschten Wert an (siehe Abbildung 5.7). Auch der Empfängerbereich wirkt sich auf die Anzeige der Daten in der Konsole aus. Diese Einstellung bestimmt die Größe des »Netzes«, das in Active Directory ausgeworfen wird, um Empfängerinformationen für die Anzeige in der Konsole abzurufen. Standardmäßig werden alle Exchange-Objekte in der Gesamtstruktur dargestellt. In sehr großen Organisationen ist es jedoch unmöglich, sich sämtliche Empfänger in der Gesamtstruktur anzusehen. Unter anderem wird dadurch die Maximalzahl der Objekte überschritten, und der Abruf einer solchen Menge würde darüber hinaus zu lange dauern. Daher können Sie einen Filter festlegen, indem Sie die Konsole anweisen, nur die Benutzer einer bestimmten Organisationseinheit anzuzeigen. Je nach Ihrer Active Directory-Struktur kann das eine sehr wirkungsvolle Methode sein, um sich auf die Benutzer in einer bestimmen Niederlassung, einem Land oder einer Region zu konzentrieren. Wenn Sie sämtliche E-Mail-aktivierten Objekte in einer einzigen Organisationseinheit unterbringen, hilft Ihnen dieser Filter natürlich auch nicht weiter, sodass Sie doch nur wieder sämtliche Empfänger abrufen. Das unterstreicht, wie wichtig es ist, sich vor Beginn der Bereitstellung genau zu überlegen, wie Sie E-Mail-aktivierte Objekte in Active Directory speichern möchten. Abbildg. 5.7
Ändern der Maximalzahl von angezeigten Objekten in der Echange-Verwaltungskonsole
215
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Die Exchange-Verwaltungskonsole
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Ändern der Spalten in der Konsole Wie in jeder MMC können Sie auch hier mit der Option Spalten hinzufügen/entfernen des Menüs Ansicht die Spalten ändern, die beim Zugriff auf die verschiedenen Arten von Objekten angezeigt werden. Abbildung 5.8 zeigt, wie Sie dabei vorgehen. Ausgangspunkt sind die Standardspalten Anzeigename, Alias, Organisationseinheit, Empfängertypdetails und Primäre SMTP-Adresse. Sofern Sie die Anzeige der Verwaltungskonsole nicht auf einem sehr großen Bildschirm maximieren, können Sie gewöhnlich nur die ersten drei dieser Spalten sehen, aber wenn genügend Platz vorhanden ist, zeigt die Konsole alle an. HINWEIS Häufig interessiert sich ein Administrator auch dafür, in welcher Datenbank sich ein Postfach befindet, weshalb wir die Spalte Datenbank zu der Liste hinzugefügt und an dritter Stelle angeordnet haben. Manche Administratoren bevorzugen noch andere Arrangements, z.B. die Anzeige der Spalte Abteilung, sodass Sie auf deren Spaltenkopf klicken und die Postfächer nach Abteilungen ordnen können. Sie können eine Sortierung nach jeder beliebigen Spalte vornehmen, indem Sie auf deren Spaltenkopf klicken. Je nachdem, ob Sie mit der Organisations-, der Server- oder der Empfängerkonfiguration arbeiten, zeigt die Verwaltungskonsole unterschiedliche Arten von Objekten an, weshalb auch jeweils verschiedene Spalten zu sehen wind. Wenn Sie sich z.B. in der Organisationskonfiguration befinden und sich Einzelheiten über die Postfachserver ansehen, stehen Spalten zur Anzeige der Eigenschaften von Postfachservern zur Verfügung. Abbildg. 5.8
Auswählen von Spalten zur Anzeige in der Exchange-Verwaltungskonsole
Automatisch generierte PowerShell-Befehle Jedes Mal, wenn ein Assistent der Exchange-Verwaltungskonsole einen Befehl ausführt, zeigt er – wie in Exchange Server 2007 – den zugrunde liegenden PowerShell-Code an, den Sie dann mit (Strg)+ (C) kopieren können, um ihn später wiederzuverwenden. Auf diese Weise lernen Administratoren die Exchange-Verwaltungsshell zu nutzen und die Exchange-Cmdlets zu beherrschen, um selbst Skripts zur Automatisierung häufig vorkommender Verwaltungsaufgaben zu schreiben. 216
Microsoft hat diese Möglichkeit in Exchange Server 2010 erweitert und die Befehlsprotokollierung der Exchange-Verwaltungsshell auch auf andere Stellen ausgedehnt, an denen Befehle ausgeführt werden, z.B. die Änderung der Eigenschaften eines Objekts. In Abbildung 5.9 wird ein Postfach zur Bearbeitung markiert. Sobald Sie ein Feld ändern, zeigt die Konsole in der linken unteren Ecke des Eigenschaftendialogfelds für das Postfach ein kleines Shellsymbol an. Wenn Sie darauf klicken, sehen Sie den Code, den die Konsole ausführt, um die Änderung vorzunehmen. In diesem Code können Sie erkennen, dass Exchange den kanonischen Namen (Domäne und Konto) des Postfachs als Identitätsparameter bevorzugt. Der kanonische Name ist der definierte Name des Objekts in Active Directory und garantiert eindeutig, weshalb Exchange ihn vermutlich verwendet. Die meisten Administratoren verwenden beim Schreiben von Code für die Verwaltungsshell den Alias, den Anzeigenamen oder die SMTP-Adresse zur Bezeichnung von Postfächern, da diese Namen gewöhnlich schneller einzugeben und leichter erkennbar sind. Abbildg. 5.9
Anzeigen des PowerShell-Codes zur Bearbeitung eines Postfachobjekts
Diese Möglichkeit können Sie noch mit einer anderen neuen Funktion der Verwaltungskonsole von Exchange Server 2010 kombinieren, nämlich der Bearbeitung mehrerer Objekte oder Massenbearbeitung. In der früheren Version der Konsole konnten Sie immer nur ein Objekt markieren und bearbeiten, wohingegen Massenbearbeitungen (z.B. um die Postanschrift sämtlicher Benutzer zu ändern, da Ihre Firma in ein anderes Bürogebäude umgezogen ist) nur in der Verwaltungsshell möglich waren. Das war zwar auch eine schöne Gelegenheit, um seine Fähigkeiten im Schreiben von Skripts einzuüben, aber eine nervtötende Angelegenheit. Abbildung 5.10 veranschaulicht dies. Wir markieren in der Exchange-Verwaltungskonsole drei Postfächer und klicken dann im Aktionsbereich auf Eigenschaften. Die Konsole zeigt das übliche Eigenschaftendialogfeld für Postfächer an, füllt die bearbeitbaren Felder aber mit <current values> aus, um anzuzeigen, dass diese Felder in den einzelnen markierten Objekten möglicherweise unterschiedliche Werte haben. Jetzt können Sie neue Werte eingeben und auf das Shellsymbol klicken, um sich den 217
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Die Exchange-Verwaltungskonsole
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Code anzusehen. Auch in diesem Beispiel lernen wir wieder etwas darüber, wie die Verwaltungsshell hinter den Kulissen funktioniert, denn hier können wir erkennen, wie eine Liste von Eingabewerten zur Verarbeitung durch die Shell angegeben wird (jedes Postfach wird mit seinem kanonischen Namen bezeichnet). Außerdem sehen wir, dass wir das Cmdlet Set-User verwenden müssen und nicht Set-Mailbox, um die Adress- und Telefoneigenschaften zu ändern, denn dies sind die Eigenschaften des Active Directory-Benutzerobjekts und nicht die des Postfachs. Wenn wir uns die geänderten Eigenschaften ansehen wollen, um zu überprüfen, dass sie korrekt übernommen wurden, müssen wir daher auch Get-User verwenden statt Get-Mailbox. Abbildg. 5.10
Anzeigen des PowerShell-Codes für die Massenbearbeitung von Postfächern
Nachdem Sie auf OK geklickt haben, um fortzufahren, weist die Konsole Sie darauf hin, dass die Änderungen auf mehrere Objekte angewendet werden. Diese zusätzliche Warnung soll Administratoren daran hindern, Fehler zu begehen, und zeigt an, wie viele Objekte geändert werden. Vielleicht haben Sie ja versehentlich 3000 Objekte markiert, die Sie in Wirklichkeit gar nicht alle ändern wollen!
Verwenden von Befehlsprotokollen der Verwaltungsshell Die Verwaltungskonsole kann auch die Einzelheiten sämtlicher Shellbefehle erfassen, die während einer Sitzung ausgeführt werden. Das ist für viele Zwecke sehr nützlich, z.B. um die Administratorbefehle auf sensiblen Systemen zu überwachen und um einen vollständigen Bericht an Microsoft oder eine andere Supportorganisation zu senden, in dem alle zur Reproduktion eines Problems erforderlichen Befehle enthalten sind. Anhand der in dem Protokoll erfassten Informationen können Sie auch ablesen, wie Exchange-Cmdlets funktionieren und korrekt formatierte Werte als Parameter zu übergeben sind. Die Erfassung der Befehle im Shellprotokoll ist standardmäßig aktiviert. 218
Um sich die Einträge im Befehlsprotokoll anzusehen, klicken Sie im Menü Ansicht auf Befehlsprotokoll der Exchange-Verwaltungsshell anzeigen. Die Konsole blendet dann ein weiteres Fenster ein, in dem alle aufgezeichneten Befehle zu sehen sind (siehe Abbildung 5.11). Hier könne Sie die Protokollierung ein- und ausschalten , die Inhalte des Protokolls in eine kommagetrennte Textdatei schreiben, ein vorhandenes Protokoll löschen usw. Abbildg. 5.11
Anzeigen der Einträge im Befehlsprotokoll der Verwaltungsshell
Abbildung 5.11 zeigt, wie die Protokollierung der Shellbefehle erfolgt. Die Angaben über die ShellCmdlets und Parameter werden im Hintergrund erfasst. Das Befehlsprotokoll bietet einen interessanten Einblick in die Abläufe der Verwaltungskonsole und zeigt, wie eng sie mit der Verwaltungsshell verknüpft ist. Sie können hier eine Menge Fingerzeige dazu finden, wie Sie Shellbefehle formulieren und wie Sie den Cmdlet-Parametern die passenden Werte übergeben. In diesem Fall können wir erkennen, dass die folgenden Schritte ausgeführt wurden: 1. Es werden zwei Postfächer gleichzeitig bearbeitet (der verwendete Befehl ist im unteren Bereich der
Befehlsansicht zu erkennen). Die Exchange-Verwaltungskonsole aktualisiert ihre Ansicht dann mit: Get-Recipient -PropertySet ConsoleLargeSet -ResultSize '1000' -SortBy DisplayName -RecipientType 'UserMailbox' 2. Der Administrator wechselt dann vom Postfachknoten unter Empfängerkonfiguration zu Verteiler-
gruppen, weshalb die Konsole von Active Directory Angaben über die Verteilergruppen abrufen muss. In Exchange Server 2010 SP1 wird hierfür anderer Code verwendet als in der RTM-Version, da die Konsole jetzt das Cmdlet Get-OrganizationalUnit aufruft, was schneller geht als die früher verwendeten Aufrufe. Get-OrganizationalUnit -IncludeContainers -Identity 'contoso.com' –SingleNodeOnly
219
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Die Exchange-Verwaltungskonsole
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
3. Der Administrator erstellt eine neue dynamische Verteilergruppe. Dazu legt er auch einen Filter
an, mit dem Exchange die Gruppenmitgliedschaft bestimmt. Mit der Vorschaufunktion sieht sich der Administrator an, ob der bereitgestellte Filter zur korrekten Gruppenmitgliedschaft führt (der Filter wird im Parameter -RecipientPreviewFilter am Ende des Befehls übergeben). Get-Recipient -ResultSize Unlimited -PropertySet ConsoleSmallSet -RecipientTypeDetails RemoteUserMailbox,RemoteRoomMailbox,RemoteEquipmentMailbox, RemoteSharedMailbox,MailUser,UserMailbox,LinkedMailbox,SharedMailbox,LegacyMailbox, RoomMailbox,EquipmentMailbox,PublicFolder,MailContact,MailForestContact, MailUniversalDistributionGroup,MailUniversalSecurityGroup,MailNonUniversalGroup, DynamicDistributionGroup -OrganizationalUnit 'contoso.com/Exchange Users' -RecipientPreviewFilter '(&(st=Berlin) 4. Wenn der Filter korrekt funktioniert, fährt der Administrator fort, um die neue dynamische Ver-
teilergruppe zu erstellen. Bei der Instanzierung verwendet der Filter eine der besonderen bedingten Eigenschaften. Weitere Informationen über dynamische Verteilergruppen erhalten Sie in Kapitel 6, »Verwalten von E-Mail-aktivierten Empfängern«. New-DynamicDistributionGroup -Name 'German Users' -RecipientContainer 'contoso.com/ Exchange Users' -IncludedRecipients 'MailboxUsers' -ConditionalStateOrProvince 'Berlin','Germany' -OrganizationalUnit 'contoso.com/Exchange Users' -Alias 'GermanUsers' 5. Als Nächstes wechselt der Administrator zum Knoten Organisationskonfiguration. Dadurch muss
die Verwaltungskonsole die Anzeige der Daten aktualisieren, was die Ausführung einer Reihe von Cmdlets zum Abrufen von Komponenten auf Organisationsebene erfordert, z.B. Postfachdatenbanken und Datenbanken öffentlicher Ordner (in Exchange Server 2010 befinden sich diese Objekte nicht mehr wie in früheren Versionen auf der Server-, sondern auf der Organisationsebene). 6. Der Administrator wechselt zum Knoten Hub-Transport und ändert die Eigenschaften eines Sendeconnectors. Das erste Cmdlet ruft die Eigenschaften des Connectors ab, sodass sie angezeigt werden können, das zweite ändert die Eigenschaft MaxMessageSize auf 20 MB, und das dritte aktualisiert die Connectorangaben in der Anzeige der Konsole. Beachten Sie, dass im dritten Fall der global eindeutige Bezeichner zur Identifizierung des Connectors verwendet wird, während in den ersten beiden Cmdlets der Anzeigename herangezogen wird. Get-SendConnector -Identity 'To Internet' Set-SendConnector -MaxMessageSize '20 MB (20,971,520 bytes)' -Identity 'To Internet Get-SendConnector -Identity 'ee1a81fc-7427-4191-8677-5a091a2d0a16'
Die neuen Funktionen der Massenbearbeitung und des Befehlsprotokolls eröffnen Administratoren neue Möglichkeiten, um die Exchange-Verwaltungsshell besser zu verstehen und für ihre eigenen Zwecke zu nutzen.
220
Die Exchange-Verwaltungskonsole
Um Namenskonventionen sollten Sie sich schon kümmern, wenn Sie den Plan für die Bereitstellung erarbeiten. In Kapitel 2 sind wir bereits auf Namenskonventionen für Server eingegangen. Es ist wichtig, dass ein Server einen Namen bekommt, der sinnvoll ist und seinen Zweck widerspiegelt, da das für Administratoren die Verwaltung der Organisation erleichtert. Es gibt jedoch noch andere wichtige Objekte, über deren Benennung Sie sich Gedanken machen müssen: 쐍 Benutzerpostfächer Schon seit vielen Jahren bevorzuge ich das Format Nachname, Vorname, da es die Schreibweise in Telefonbüchern nachahmt und man sich in globalen Adresslisten leichter in umfangreichen Benutzergruppen mit demselben Nachnamen (wie Müller oder Smith) zurechtfindet. Diese Konvention eignet sich auch für multinationale Unternehmen, die Vorkehrungen für Nachnamen nicht im europäischen Stil treffen müssen. Um dieses Thema kümmern wir uns eingehender in Kapitel 6. 쐍 Raum- und Gerätepostfächer Bei den meisten Unternehmen tragen die Räume bereits Bezeichnungen, sodass es Sinn hat, diesem bereits vorhandenen System zu folgen. Bei mehreren Gebäuden sollten Sie dem Raumnamen eine Gebäudebezeichnung voranstellen. Den Konferenzraum 2-120 in Gebäude V2 können Sie beispielsweise V2-2-120 nennen. Gewöhnlich sind die Benutzer mit den Gebäudenamen gut vertraut, sodass Sie sich für die Namen der Raumpostfächer ruhig einen solchen für Außenstehende unverständlichen Buchstaben- und Zahlensalat erlauben dürfen. 쐍 Verteilergruppen Im Idealfall sollten allgemeine Verteilergruppen in ihrem Namen den Zweck widerspiegeln (»Exchange 2010-Interessentenliste«), während die Namen der Gruppen für bestimmte Arten der geschäftlichen Kommunikatoin die Geschäftsgruppe und den Zweck angeben sollten (»Finanzabteilung_Planungsgruppe«). Gesunder Menschenverstand und Beratung mit dem Gruppenbesitzer über den Zweck der Gruppe sollten zu einem vernünftigen und leicht verständlichen Gruppennamen führen. 쐍 E-Mail-aktivierte Kontakte Für diese Objekte sollten Sie die gleiche Namenskonvention verwenden wie für Benutzerpostfächer. 쐍 Öffentliche Ordner Folgen Sie hier dem gleichen Ansatz wie für Verteilergruppen. Widerstehen Sie vor allem der Versuchung, rätselhafte Namen zu vergeben. Es ist schon kompliziert genug, sich in einer Hierarchie öffentlicher Ordner zurechtzufinden, ohne dass Sie dem Verständnis der Benutzer noch ein zusätzliches Hindernis in den Weg stellen. 쐍 Datenbankverfügbarkeitsgruppen Diese Objekte sind nur für Administratoren sichtbar, aber es ist dennoch wichtig, Namen zu vergeben, die den Zweck dieser Gruppen anzeigen. 쐍 Datenbanken Anders als in früheren Versionen müssen die Datenbanken in Exchange Server 2010 Namen aufweisen, die innerhalb der gesamten Organisation eindeutig sind. Auch in früheren Versionen erhielten die Datenbanken einen eindeutigen Namen, aber dabei wurde der Name der Speichergruppe mit dem der Datenbank kombiniert. Da es jetzt keine Speichergruppen mehr gibt, müssen Sie jeder Datenbank einen Namen zuweisen, der für sich allein genommen in der Organisation eindeutig ist. Am einfachsten ist es, Namen zu verwenden, die angeben, welche Postfächer in der Datenbank vorhanden sind. Beispielsweise könnte das der Abteilungsname sein, wenn Sie die Postfächer nach Abteilungen gliedern. Manche Unternehmen geben auch die Postfachgröße im Namen an, sodass die Administratoren wissen, wo sie ein neues Postfach eines bestimmten Typs und einer bestimmten Größe unterbringen müssen. Beispielsweise kann UK Sales-1GB die Datenbank für Benutzer bezeichnen, die in der britischen Verkaufsabteilung arbeiten und deren Postfächer 1 GB umfassen. Beschreibende Namen sind sicherlich eine gute Sache, aber es ist immer schwieriger, sich vernünftige Namen dieser Art auszudenken, wenn Sie erst ein-
221
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Namenskonventionen
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
mal 20 bis 30 Datenbanken zu verwalten haben. In Kapitel 8, »Exchange auf dem Weg zur Hochverfügbarkeit«, finden Sie eine ausführlichere Erörterung darüber, wie Sie Datenbanken in umfangreichen Umgebungen benennen können. 쐍 Connectors Messagingconnectors sollten Namen tragen, die deutlich ihren Zweck und die Art des darüber übertragenen Datenverkehrs angeben, z.B. »SMTP zu Internet« oder »SMTP zu Lotus Notes«. Insidertipp: Stellen Sie Benennungsrichtlinien nicht nachträglich auf!
Tappen Sie nicht in die Falle, zuerst einen Haufen Objekte zu erstellen und dann rückwirkend eine Benennungsrichtlinie darauf anzuwenden. Es ist furchtbar mühselig, alle Objekte einzeln durchzugehen und umzubenennen. Nehmen Sie sich stattdessen möglichst früh die Zeit dafür, sich für eine Namenskonvention zu entscheiden, und teilen Sie diese Konvention mit einigen Beispielen angereichert allen Administratoren mit, die die Berechtigung dafür haben, Objekte in der Organisation anzulegen.
Organisationsstatusdaten Wenn Sie auf den Stamm der Organisation klicken, zeigt die Exchange-Verwaltungskonsole einige Statistiken über die Organisation an, z.B. die Anzahl der Datenbanken, Benutzer, Server usw. (siehe Abbildung 5.12). Bevor diese Informationen angezeigt werden können, müssen sie erst gesammelt werden. Das ist eine neue Funktion von Exchange Server 2010. Die Datenerfassung rufen Sie auf, indem Sie im Aktionsbereich Organisationsstatusdaten auswählen oder am unteren Rand des Informationsbildschirms auf die Option für den Zugriff auf die neuesten Daten klicken. In beiden Fällen wird ein Assistent gestartet, um Informationen über die Organisation zu erfassen. Abbildg. 5.12
222
Statistiken zum Organisationsstatus in der Exchange-Verwaltungskonsole
Als Erstes liest der Assistent die Konfigurationsdaten aus der Datei ExBPA.StayingInformed.Config.xml. Seit 2006 setzt Microsoft das Programm Exchange Best Practice Analyzer (ExBPA) ein, um Organisationen dabei zu helfen, ihre Infrastruktur mit dem zu vergleichen, was Microsoft an Vorgehensweisen empfiehlt. Grob gesagt, sammelt ExBPA Daten, vergleicht sie anhand eines Satzes von Regeln, um mögliche Probleme aufzuspüren, und gibt dann Empfehlungen für den Umgang mit diesen Problemen aus. Der Assistent zum Erfassen der Organisationsstatusdaten ruft die entsprechenden Informationen nur ab, versucht aber auf keine Weise, sie zu analysieren. Stattdessen speichert Exchange die Daten mit Set-OrganizationConfig in Active Directory. Die Erfassungsphase dauert am längsten, da der Assistent auf Informationen über Server und Datenbanken zugreifen, die Postfächer zählen und dann berechnen muss, für wie viele Postfächer Enterprise-Clientzugriffslizenzen (Client Access Licence, CAL) erforderlich sind. Tabelle 5.1 führt auf, welche Postfachfunktionen von einer Standard-Zugriffslizenz abgedeckt sind und welche eine Enterprise-Lizenz benötigen. Denken Sie daran, dass die Lizenzen additiv sind: Die Enterprise-CAL umfasst auch sämtliche Funktionen, die durch die Standard-CAL lizenziert werden, selbst wenn Sie nach wie vor beide Arten von Lizenzen erwerben müssen. Insidertipp: Haben Sie Geduld: Das Zählen von Postfächern kostet Zeit
Die langwierigste Teilaufgabe dieses Vorgangs ist das Zählen der Postfächer, das in großen Organisationen viele Minuten dauern kann. Das ist ein Beispiel für eine Funktion, die sich schnell und einfach vorführen lässt, in einer Produktionsumgebung aber ewig zu dauern scheint. Wenn der Assistent einige Daten nicht erfassen kann (da z.B. eine Postfachdatenbank nicht bereitgestellt ist), zeigt er dies mit einem Ausrufungszeichen an. Tabelle 5.1
Benötigte Lizenzen für die verschiedenen Funktionen Funktion
Standard-CAL erforderlich
Standard-E-Mail-Funktionen für Outlook, OWA und andere Clients, einschließlich Kalender, Journal, Notizen und Kontakte
X
Erweiterte ActiveSync-Richtlinien für mobile Geräte Journale auf Datenbankbasis
Enterprise-CAL erforderlich
X X
Journale auf selektiver Basis (benutzerweise oder nach anderen Kriterien)
X
Unified Messaging
X
Beibehaltungsrichtlinien (wenn sie mit persönlichen Tags eingerichtet werden)
X
Persönliche Archive
X
Anhalten der Aufbewahrungszeit und Einfrieren von Postfächern aus rechtlichen Gründen
X
Discoverysuchvorgänge über mehrere Postfächer hinweg
X
Informationsschutz, z.B. Verschlüsselung von Journal- und Transportregeln, Outlook-Schutzregeln und Suche nach geschützten Inhalten
X
Verwendung von Forefront Protection 2010 für Exchange zum Schutz gegen Viren und Spam
X
223
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Die Exchange-Verwaltungskonsole
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
In Abbildung 5.13 können Sie erkennen, dass die gesammelten Daten als Eigenschaften des Attributs msExchOrgnizationSummary für das Stammobjekt der Exchange-Organisation gespeichert werden. Diese Daten können Sie mit dem Cmdlet Get-OrganizationConfig abrufen, doch da sie in einem Array gespeichert sind, müssen Sie die Werte erst extrahieren, bevor Sie sie verwenden können. Am einfachsten geht das, indem Sie die Werte in einer Variable speichern und dann die Daten abrufen, die Sie benötigen. Jeder der einzelnen Werte ist mit einem bestimmten Offset im Array gespeichert. Um beispielsweise die Anzahl der Standard-CALs zu ermitteln, gehen Sie wie folgt vor: $Config = Get-OrganizationConfig $Cals = $Config.OrganizationSummary[10].Value Abbildg. 5.13
In Active Directory gespeicherte Organisationsdaten
Die Gesamtzahl der Postfächer in der Organisation rufen Sie folgendermaßen ab: $Mbx = $Config.OrganizationSummary[5].Value
Dynamische Verteilerlisten haben den Offset 3, Standardverteilerlisten Offset 4 usw. Denken Sie daran, dass die Organisationsdaten nur unmittelbar nach ihrer Erfassung Gültigkeit haben und sich mit der Zeit ändern können. Daher sollten Sie die Daten aktualisieren, bevor Sie sie als Grundlage für eine Entscheidung heranziehen.
224
Die Exchange-Verwaltungskonsole
Daten sind nur dann gut, wenn sie auch korrekt erfasst wurden. Leider gab es bei der Art und Weise, wie Organisationsstatusdaten gesammelt wurden, in der ursprünglichen Version von Exchange Server 2010 erhebliche Fehler, denn die Berechnung der erforderlichen Enterprise-CALs war mangelhaft. Wie Sie wahrscheinlich wissen, sind Enterprise-CALs additiv, das heißt, Sie zahlen einen Aufschlag zu einer Standard-CAL, um Zugriff auf weitere Exchange-Funktionen wie die Archivierung zu bekommen. Bei der Ermittlung der erforderlichen Enterprise-CALs wird sicherlich einiges richtig gemacht, z.B. werden Discoverysuch-, Raum- und Gerätepostfächer nicht mitgezählt, aber es treten auch Fehler auf. Beispielsweise geht der Ermittlungsvorgang davon aus, dass für jedes Postfach mit der standardmäßigen ActiveSync-Richtlinie eine Enterprise-Clientlizenz erofrderlich wäre. Außerdem wird das Postfach mitgezählt, das zur Installation von Exchange verwendet wird, obwohl es nur zu Verwaltungszwecken dient und lediglich aufgrund des Aufbaus der rollenbasierten Zugriffssteuerung E-Mail-aktiviert ist. Microsoft hat das Problem erkannt und den Code zur Bestimmung der Enterprise-CALs in SP1 geändert. Der Bericht ist jetzt korrekt und versorgt Administratoren mit nützlichen Daten.
Verwalten mehrerer Organisationen In allen vorherigen Exchange-Konsolen konnten Sie nur eine Organisation verwalten. Manche Unternehmen betreiben jedoch mehrere Organisationen in verschiedenen Active Directory-Gesamtstrukturen, wofür es verschiedene Gründe geben kann. Vielleicht möchte das Unternehmen bestimmte Gruppen von Benutzern einer bestimmten Exchange-Version zuordnen, vielleicht möchte es die Trennung zwischen verschiedenen Sicherheitskontexten aufrecht erhalten oder eine ethische Firewall zwischen den verschiedenen Teilen der Firma einrichten, vielleicht hat es aber zusammen mit dem Erwerb anderer Firmen auch verschiedene Exchange-Implementierungen gewonnen. Es ist nicht weiter schwierig, mehrere Exchange-Organisationen (aller Versionen) über die Remotedesktopverbindung zu verwalten. Allerdings wird es noch einfacher, wenn in einer einzigen Konsole Zugriff auf sämtliche Exchange-Organisationen besteht. Der Exchange-Verwaltungskonsole können Sie eine weitere Exchange Server 2010-Organisation (oder eine Exchange-Gesamtstruktur) hinzufügen, indem Sie im linken Bereich auf den Microsoft Exchange-Stamm klicken und im Aktionsbereich Exchange-Gesamtstruktur hinzufügen auswählen. Da Sie Informationen freigeben und administrative Tätigkeiten ausführen, die Objekte in der anderen Exchange-Organisation betreffen, muss eine Active Directory-Vertrauensstellung oder Verbundvertrauensstellung zwischen den beiden Gesamtstrukturen vorhanden sein, bevor Sie die Organisationen verbinden können. Außerdem müssen Sie über ein Konto mit den notwendigen Berechtigungen zur Verwaltung der anderen Exchange-Organisation verfügen (im Idealfall über ein Konto mit der Rolle Organisation Management). Wenn Sie die Kontoinformationen zwischen den Gesamtstrukturen synchronisieren, kann es möglich sein, überall dasselbe Konto zu verwenden. Abbildung 5.14 zeigt diesen Vorgang. Sie werden gebeten, einen Anzeigenamen für die andere Organisation anzugeben (einen Namen, der für Sie sinnvoll ist) und den vollqualifizierten Domänennamen (FQDN) eines Exchange Server-Computers, der PowerShell über das Netzwerk ausführt und im Grunde als Gateway in die Organisation fungiert. Wenn Sie Anmeldung mit Standardanmeldeinformationen aktivieren, verwenden Sie die Anmeldeinformationen des Kontos, mit dem Sie sich angemeldet haben. Wenn nicht, müssen Sie Anmeldeinformationen für ein administratives Konto in der anderen Organisation beibringen.
225
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Nützliche Informationen für Administratoren – wenn Sie SP1 haben
Kapitel 5 Abbildg. 5.14
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Hinzufügen einer neuen Exchange-Gesamtstruktur zur Exchange-Verwaltungskonsole
Sobald die Verbindung hergestellt ist, werden die Einzelheiten der anderen Organisation in der Exchange-Verwaltungskonsole angezeigt, sodass Sie im Rahmen der Rolle, die Sie in dieser Organisation innehaben, mit den Objekten arbeiten können. Wenn Sie einen reinen Lesezugriff haben, können Sie die Objekte also nur einsehen, aber nicht ändern.
Freigaberichtlinien Freigaberichtlinien sind der Mechanismus, mit dem Exchange Server 2010 steuert, wie die Benutzer Daten organisationsübergreifend freigeben können. In ihrer ersten Implementierung in Exchange Server 2010 ist die Freigabe auf Kalender- und Kontaktinformationen und auf Organisationen beschränkt, zwischen denen eine Verbundvertrauensstellung besteht. Eine solche Vertrauensstellung kann mit dem Cmdlet New-OrganizationRelationship erstellt werden. Für einen Verbund zweier Exchange-Organisation ist die Bereitstellung von Microsoft Federation Gateway erforderlich, das als vertrauenswürdiger Makler zwischen den beiden Organisationen fungiert und sicherstellt, dass Daten auf sichere Weise zwischen ihnen übertragen werden können. Microsoft Federation Gateway gehört zur Serverrolle Active Directory-Verbunddienste, die auf einem Computer mit Windows Server 2008 installiert werden kann. Nachdem das geschehen ist, können Sie mit dem Assistenten für eine neue Verbundvertrauensstellung oder mit New-FederationTrust die nötige Verbindung mit der anderen Organisation herstellen. Ausführliche Anleitungen dazu, wie Sie den Assistenten und das Cmdlet verwenden, finden Sie in der Hilfe zu Exchange Server 2010. Weitere Informationen
Hinweise zur Bereitstellung der Active Directory-Verbunddienste erhalten Sie unter http://technet. microsoft.com/de-de/library/dd727938(WS.10).aspx. 226
In Exchange Server 2010 SP1 können Sie außerdem eine Freigaberichtlinie vorschreiben, die bestimmt, wie Benutzer Kalenderdaten (aber keine Kontakte) für Empfänger im Internet freigeben. Möglicherweise erweitert Microsoft die Freigaberichtlinien in Zukunft, sodass sich damit noch mehr Aspekte der Freigabe steuern lassen. Weitere Informationen über dieses Thema finden Sie in Kapitel 10, »Clients«. Der Zugriff auf Freigaberichtlinien besteht im Abschnitt Postfach des Knotens Organisationskonfiguration der Exchange-Verwaltungskonsole. Exchange stellt eine Standardfreigaberichtlinie zur Verfügung, die jedoch leer ist und vom Administrator mit Einzelheiten über die Organisation gefüllt werden muss, für die die Benutzer Daten freigeben können sollen. Die Standardfreigaberichtlinie ist allen Postfächern zugewiesen. Wenn Sie unterschiedliche Möglichkeiten zur Freigabe wünschen, können Sie in einer Organisation mehrere Freigaberichtlinien erstellen und verschiedenen Gruppen von Postfächern zuweisen. Beispielsweise können Sie die Standardfreigaberichtlinie leer lassen und eine andere erstellen, um die Freigabe für eine oder mehrere andere Organisationen oder für Benutzer im Internet zu ermöglichen, und diese Richtlinie dann den Benutzern zuweisen, die ihre Daten freigeben dürfen. Der Assistent für neue Freigaberichtlinien (siehe Abbildung 5.15) wird aufgerufen, wenn Sie auf Neue Freigaberichtlinie klicken. Die Richtlinie besteht aus dem SMTP-Domänennamen der Organisation, für die Sie Daten freigeben möchten, und einem Paar von Aktionen, die den Grad der Datenfreigabe für diese Domäne festlegen. Welche Möglichkeiten für die Datenfreigabe zur Verfügung stehen, können Sie in Tabelle 5.2 ablesen. Abbildg. 5.15
Assistent für neue Freigaberichtlinien
227
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Freigaberichtlinien
Kapitel 5 Tabelle 5.2
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Möglichkeiten zur Datenfreigabe in Freigaberichtlinien Freigabe
Einstellungen
Verbundorganisation
Kalenderfreigabe nur mit Frei/Gebucht-Informationen Kalenderfreigabe mit Frei/Gebucht-Informationen sowie Betreff und Speicherort Kalenderfreigabe mit Frei/Gebucht-Informationen sowie Betreff, Speicherort und Nachrichtentext Freigeben von Kontakten Kalenderfreigabe nur mit Frei/Gebucht-Informationen, Freigeben von Kontakten Kalenderfreigabe mit Frei/Gebucht-Informationen sowie Betreff und Speicherort, Freigeben von Kontakten Kalenderfreigabe mit Frei/Gebucht-Informationen sowie Betreff, Speicherort und Nachrichtentext, Freigeben von Kontakten
Internetkalender
Kalenderfreigabe nur mit Frei/Gebucht-Informationen Kalenderfreigabe mit Frei/Gebucht-Informationen sowie Betreff und Speicherort Kalenderfreigabe mit Frei/Gebucht-Informationen sowie Betreff, Speicherort und Nachrichtentext
Machen Sie sich bewusst, dass eine Freigaberichtlinie aus Einträgen für mehrere Domänen zusammengesetzt sein kann, denen jeweils andere Aktionen zugewiesen sein können. Damit können Sie auch eine Freigaberichtlinie erstellen, die wie das Beispiel in Abbildung 5.16 aussieht. Abbildg. 5.16
Einzelheiten einer Freigaberichtlinie mit mehreren Einträgen
Nachdem Sie die Domänen und Aktionen definiert haben, gibt Ihnen der Assistent die Möglichkeit, die Richtlinie ausgewählten Postfächern zuzuweisen. Das müssen Sie zu diesem Zeitpunkt jedoch noch nicht tun, sondern können sie jederzeit einem oder mehreren Postfächern zuweisen. Dazu können Sie wie folgt das Cmdlet Set-Mailbox verwenden: Set-Mailbox –Identity 'Akers, Kim' –SharingPolicy 'Sharing policy for Internet calendars'
228
Zertifikatverwaltung X.509-Zertifikate sind für den Betrieb von Exchange sehr wichtig, da sie die Grundlage der sicheren SSL-Kommunikation (Secure Sockets Layer) zwischen Client und Server bilden. Darunter fällt auch die (mit TLS [Transport Layer Security] gesicherte) SMTP-Übertragung für den Austausch von E-Mails zwischen Servern. Zertifikate werden auch für einen Verbund mehrerer Exchange-Organisationen eingesetzt. Sie bestätigen, dass ihre Inhaber diejenigen sind, die sie zu sein vorgeben, und werden eingesetzt, um sichere Kanäle zur Datenübertragung einzurichten. In Exchange Server 2010 können Sie drei verschiedene Arten von Zertifikaten verwenden: 쐍 Selbst signierte Zertifikate. Sie werden von der Anwendung erstellt, die sie auch zu verwenden wünscht, und sind nicht von einer Zertifizierungsstelle signiert. Da es keinen Zertifikatpfad gibt, in dem eine vertrauenswürdige Zertifizierungsstelle erwähnt wird, müssen andere Anwendungen oder Computer einem solchen Zertifikat nicht zwangsläufig vertrauen. 쐍 Zertifikate, die von einer Windows-Zertifizierungsstelle herausgegeben wurden (von den Windows-Zertifikatdiensten) 쐍 Zertifikate von einem kommerziellen SSL-Anbieter wie Thawte oder VeriSign Tabelle 5.3 gibt einen Überblick über die verschiedenen Protokolle, die Exchange zur Kommunikation verwendet, und zeigt, welche Zertifikate zur Absicherung dieser Verbindungen jeweils erforderlich sind. Wie Sie sehen, sind Drittanbieterzertifikate äußerst nützlich und ein absolutes Muss, um die externe Kommunikation abzusichern. Wenn Sie für die externe Kommunikation einen Reverseproxyserver in einem Umkreisnetzwerk platzieren, sind für die sichere Datenübertragung zwischen diesem Server und Exchange ebenfalls Zertifikate erforderlich. Tabelle 5.3
Protokolle und erforderliche Zertifikate Serverrolle
Protokolle
Erforderlicher Zertifikattyp
Clientzugriff
OWA Exchange-Webdienste Outlook Anywhere ActiveSync POP3 und IMAP4 AutoErmittlung
Drittanbieter (empfohlen) oder Windows-PKI (Public-KeyInfrastruktur). Die Zertifikate müssen den FQDN des Servers und die URLs der Anwendungen enthalten, z.B. von Outlook Anywhere, Outlook Web App oder Office Communications Server.
Postfach
Outlook (MAPI) OWA (HTTPS)
Selbst signiert
Unified Messaging
Keine
Selbst signiert
Hub-Transport
SMTP über TLS
Drittanbieter (empfohlen) oder Windows-PKI. Für die interne Kommunikation zwischen Hub-Transport-Servern reichen selbst signierte Zertifikate aus. Die Zertifikate müssen den FQDN des Servers und den Domänennamen enthalten.
Edge-Transport
SMTP über TLS
Drittanbieter (empfohlen) oder Windows-PKI. Die Zertifikate müssen den FQDN des Servers und den Domänennamen enthalten.
Bei der Installation auf einem Server erstellt Exchange automatisch ein selbst signiertes Zertifikat, damit der Server mit anderen Servern und Clients in der Organisation kommunizieren kann. Diesem Zertifikat vertrauen automatisch jedoch nur andere Exchange Server-Computer in der Organisation. Die selbst signierten, von Exchange erstellten Zertifikate enthalten im Feld für den alternativen
229
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Zertifikatverwaltung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Antragstellernamen (Subject Alternate Name, SAN) den Namen und den FQDN des Servers und sind fünf Jahre lang gültig. Die größte Vorteile selbst signierter Zertifikate besteht darin, dass sie kostenlos sind. Sicherheitswarnungen: Einschränkungen für selbst signierte Zertifikate
Ein selbst signiertes Zertifikat kann für die gesamte Exchange-Kommunikation innerhalb der Firewall dienen. Auch einige externe Verbindungen sind möglich (OWA und ActiveSync), nachdem das Zertifikat in den Speicher für vertrauenswürdige Stammzertifikate auf dem Clientcomputer kopiert wurde. Auf manchen mobilen Geräten ist das jedoch nicht zulässig, weshalb sie für diese Clients keine selbst signierten Zertifikate verwenden können. Außerdem lassen sich mit solchen Zertifikaten keine Outlook Anywhere-Verbindungen absichern. Outlook 2003 und 2007 akzeptieren »stillschweigend« selbst signierte Zertifikate für die externe Kommunikation und zeigen bei der Verbindung mit einem Exchange Server 2010-Computer daher keine Fehlermeldungen an. Outlook 2010 ist jedoch vorsichtiger und meldet dem Benutzer ein mögliches Problem (siehe Abbildung 5.17). Abbildg. 5.17
Outlook 2010 zeigt ein Problem mit einem selbst signierten Zertifikat an
Aufgrund der Einschränkungen im Funktionsumfang und der langfristig schwierigen Verwaltung werden selbst signierte Zertifikate meistens nur in Testumgebungen sowie in Bereitstellungen verwendet, in denen kein externer Clientzugriff auftritt. Die Windows-Zertifikatdienste stellen eine Infrastruktur für öffentliche Schlüssel (Public Key Infrastructure, PKI) bereit, in der Organisationen ihre eigenen Zertifikate veröffentlichen können. Diese Zertifikate lassen sich leichter verwalten, da Sie in einer vollständigen Windows-PKI die Herausgabe, Erneuerung und Sperrung der Zertifikate steuern können. Bevor die Zertifikate eingesetzt werden können, um sichere Verbindungen zu ermöglichen, müssen sie im Speicher für vertrauenswürdige Stammzertifikate der Computer installiert werden, die nicht zu Active Directory gehören und mit Exchange kommunizieren müssen. Zertifikate der Windows-PKI lassen sich leichter verwalten als selbst signierte Zertifikate und sind ebenfalls kostenlos, weshalb sie für kleine und mittelgroße Umgebungen eine akzeptable Lösung darstellen. An den bisherigen Erörterungen können Sie schon ablesen, dass die beste Lösung für fast alle Umgebungen die Verwendung kommerzieller Zertifikate von einem renommierten, vertrauenswürdigen Drittanbieter ist, der die Verantwortung für die Ausstellung der Zertifikate übernimmt und ihre Gül-
230
tigkeit sicherstellt. Diese Zertifikate sind natürlich teurer, weisen aber den großen Vorteil auf, dass die Zertifizierungsstellenzertifikate des Herausgebers gewöhnlich bereits im Speicher für vertrauenswürdige Stammzertifikate auf den Clientcomputern installiert sind, sodass Sie nicht erst manuell irgendwelche Zertifikate installieren müssen, bevor Sie mit einem Gerät Verbindung aufnehmen können. Die Verwaltungskonsole von Exchange Server 2007 enthielt keine Benutzeroberfläche für den Umgang mit Zertifikaten, weshalb Sie dazu immer auf die Verwaltungsshell zurückgreifen mussten. Sofern Sie mit der Nomenklatur und den Parametern für Zertifikate vertraut waren, stellte das kein Problem dar, doch wenn Sie nicht häufig mit Zertifikaten zu tun hatten, konnte das ziemlich nervtötend sein. In Exchange Server 2010 gibt es nun eine Benutzeroberfläche, in der Sie die Zertifikate auf den Servern einsehen können, und Assistenten, um neue Zertifikate zu erstellen und den Exchange-Diensten (OWA, ActiveSync usw.) zuweisen können. Klicken Sie auf den Knoten Serverkonfiguration und wählen Sie einen Server aus, um zu sehen, welche Zertifikate ihm zugewiesen sind. In dem Beispiel von Abbildung 5.18 erkennen Sie ein selbst signiertes Zertifikat, also eines, das Exchange bei der Serverinstallation automatisch erstellt hat. Abbildg. 5.18
Anzeigen der auf einem Server installierten Zertifikate
Für den Umgang mit Zertifikaten haben Sie die folgenden Möglichkeiten: 쐍 Den Zertifikten Dienste zuweisen Mit dieser Option können Sie einem Zertifikat einen oder mehrere Dienste zuweisen. Der Assistent, den Sie in Abbildung 5.19 sehen, zeigt Ihnen an, welche Dienste das ausgewählte Zertifikat bereits nutzen, und ermöglicht Ihnen, es noch anderen Diensten zuzuweisen. Der einzige Dienst, den Sie in diesem Beispiel noch zuweisen können, ist Unified Messaging. 쐍 Exchange-Zertifikat erneuern Mit dieser Option erneuern Sie ein selbst signiertes Zertifikat um weitere fünf Jahre und weisen es erneut den Diensten zu, die das bestehende Zertifikat bereits nutzen. Clients müssen das erneuerte Zertifikat importieren, damit keine Warnmeldungen über möglicherweise nicht vertrauenswürdige Verbindungen angezeigt werden.
231
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Zertifikatverwaltung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
쐍 Neues Exchange-Zertifikat Damit können Sie eine Anforderung erstellen, die später an eine Zertifizierungsstelle von Windows oder eines kommerziellen Drittanbieters gesendet wird. Das eigentliche Zertifikat erstellt dann anhand der im Assistenten eingegebenen Erfordernisse diese Zertifizierungsstelle. Um es in Exchange einzufügen, verwenden Sie die Option Ausstehende Anforderung abschließen. Dabei geben Sie Exchange den Namen der Zertifikatdatei an, sodass sie importiert werden kann. 쐍 Exchange-Zertifikat importieren Diese Option wird verwendet, wenn ein Unternehmen über allgemeine Zertifikate verfügt, die auch für andere Dienste neben Exchange verwendet werden. Wenn Sie hier den Namen der Zertifikatdatei und den privaten Schlüssel angeben, importiert Exchange das Zertifikat. Abbildg. 5.19
Zuweisen eines Zertifikats zu Diensten
Die Option Neues Exchange-Zertifikat öffnet einen Assistenten (siehe Abbildung 5.20), der die Erfordernisse für das neue Zertifikat zusammenträgt und eine Zertifikatanforderung in Form einer verschlüsselten Datei zur Vorlage bei einer Zertifizierungsstelle erstellt (siehe Abbildung 5.21). Wenn das neue Zertifikat zur Verfügung steht, können Sie es mit der Option Ausstehende Anforderung abschließen in Exchange importieren und den gewünschten Diensten zuweisen. Die Bereitstellung und Verwendung von Zertifikaten zu planen, ist eine komplizierte Aufgabe. Sie müssen sich darüber im Klaren sein, wie Zertifikate erstellt und verwaltet werden, welche Dienste auf Zertifikate angewiesen sind, welche Funktionen die Zertifikate bereitstellen müssen, welche Bedürfnisse andere Anwendungen haben und wie Sie die Ausgaben für kommerzielle Zertifikate dadurch verringern können, dass Sie nur Zertifikate für mehrere Hostnamen erwerben. Bevor Sie irgendetwas bereitstellen, sollten Sie sich mit all diesen Aspekten vertraut machen und genau planen, wie Sie Ihren Bedarf erfüllen können.
232
Zertifikatverwaltung
Festlegen der Erfordernisse mit dem Assistenten für neue Zertifikate
Abbildg. 5.21
Abschließen des Assistenten für neue Zertifikate
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Abbildg. 5.20
233
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Weitere Informationen
Hilfreiche Informationen zu diesen Themen bietet Microsoft auf TechNet. Eine weitere gute Quelle ist das Buch Microsoft Exchange Server 2010 Best Practices von Sigfried Jagott und Joel Stidley (Microsoft Press, 2010).
Die Exchange-Systemsteuerung Die Exchange-Systemsteuerung ist eine browsergestützte Verwaltungsschnittstelle für verschiedene Zwecke: 쐍 Benutzerselbstverwaltung Die vereinfachte Verwaltungsoberfläche macht es möglich, dass auch Benutzer, die keine Kenntnisse und Erfahrungen in Exchange-Verwaltung mitbringen, viele der alltäglichen Aufgaben durchzuführen, die in früheren Exchange-Versionen so zeitraubend für die Administratoren waren. Die Benutzer können jetzt ihre Postfächer an ihre eigenen Bedürfnisse anpassen, ohne einen Administrator bitten zu müssen, ihr Active Directory-Konto oder ihre Postfacheinstellungen in der Exchange-Verwaltungskonsole zu ändern. Diese Möglichkeit allein nimmt Exchange schon viel von seinen Schrecken und Verwaltungskosten. 쐍 Delegierung von Aufgaben an ausgewählte Mitarbeiter In der Exchange-Systemsteuerung sind eine Reihe von Aufgaben möglich, die Sie auf ausgewählte Mitarbeiter übertragen können. Beispielsweise kann das Supportpersonal hier Benutzerkonten und Gruppen pflegen, während die Rechtsabteilung Discoverysuchvorgänge vornehmen und Postfächer einfrieren kann. 쐍 Schnittstelle für besondere Aufgaben Die Exchange-Verwaltungskonsole ist der Ausgangspunkt für eine Menge unterschiedlicher Verwaltungsaufgaben, enthält bietet aber nicht den Zugriff für alle Tätigkeiten, die ein Exchange-Administrator möglicherweise ausführen muss. Die Exchange-Systemsteuerung umfasst auch Benutzeroberflächen für Aufgaben wie die Verwaltung von Rollen und Rollengruppen und den Umgang mit ActiveSync-Geräterichtlinien, für die Sie in der Verwaltungskonsole keine Möglichkeiten haben. 쐍 Multi-Tenant-Verwaltung Angesichts ihrer webgestützten Natur lässt sich die Exchange-Systemsteuerung leichter als Verwaltungswerkzeug für Kunden bereitstellen, die Exchange-Hostingdienste wie Microsoft Business Productivity Online Services (BPOS) nutzen. Zugriff auf die Exchange-Systemsteuerung erhalten Sie über ihr virtuelles Verzeichnis, indem Sie im Browser den URL in der Form https://<Servername>.
234
Die Exchange-Systemsteuerung
Wie die Exchange-Verwaltungsshell greift auch die Exchange-Systemsteuerung auf die rollenbasierte Zugriffssteuerung zurück, um den Benutzern nur die Optionen für die Aufgaben anzuzeigen, die auszuführen ihre Rolle erlaubt. Mit anderen Worten, die Exchange-Systemsteuerung passt die Anzeige der möglichen Optionen an die Rolle des Betrachters an. Administratoren in der Rollengruppe Organization Management sehen alle Optionen und können mit Benutzerdaten arbeiten, Benutzer mit der Standardrolle sehen dagegen nur einen Bruchteil der Optionen und haben lediglich Zugriff auf die eigenen Daten. Wenn Sie die für Hostingumgebungen gedachte Version der Exchange-Systemsteuerung verwenden, finden Sie darin eine Benutzeroberfläche, in der Administratoren Transportregeln erstellen können. Es ist sehr ansprechend, Verwaltungsaufgaben erledigen zu können, ohne zuvor entsprechende Software installieren zu müssen, aber in lokalen Bereitstellungen können Sie die Exchange-Systemsteuerung nicht für die Verwaltung von Transportregeln einsetzen. Bei Microsoft geht man davon aus, dass es in Hostingumgebungen einfachere Anforderungen an Dinge wie Transportregeln gibt und die jetzige Version der Exchange-Systemsteuerung zum Konstruieren und Bereitstellen von einfachen Transportregeln ausreicht. Mit dem Transportregelassistenten der Exchange-Verwaltungskonsole können Sie jedoch Regeln aus einer weit umfangreicheren Menge von Prädikaten und Bedingungen erstellen und bearbeiten. Außerdem besteht dabei die Möglichkeit, ein Skript für die automatisierte Bereitstellung über die Exchange-Verwaltungsshell erstellen zu lassen. Daher eignet sich die Exchange-Verwaltungskonsole besser für die Bedürfnisse lokaler Bereitstellungen. Im Laufe der Zeit wird sich Microsoft einen Eindruck von den tatsächlichen täglichen Bedürfnissen von Hostingumgebungen machen können. Möglicherweise wird es dann Änderungen an der Exchange-Systemsteuerung geben, um die darin enthaltenen Verwaltungsmöglichkeiten für Regeln an die der Konsole anzupassen.
Änderungen an der Exchange-Systemsteuerung in Service Pack 1 In Exchange Server 2010 SP1 hat Microsoft die Exchange-Systemsteuerung erheblich verbessert. Neben einer allgemeinen Überarbeitung und einer verbesserten Leistung, die es auch für OWA gab (unter anderem wurde die Breadcrumbnavigation eingeführt, die es den Benutzern ermöglichte, sich an den gewählten Optionen entlang zurückzubewegen), wurde der für Administratoren verfügbare Funktionsumfang stark erweitert. Jetzt können auch folgende Dinge verwaltet werden: 쐍 Journal- und Transportregeln 쐍 ActiveSync-Geräterichtlinien (auch über die Exchange-Verwaltungskonsole zu bearbeiten) und Gerätezugriffsregeln (nur über die Exchange-Systemsteuerung zu verwalten) 쐍 Einfrieren von Postfächern aus rechtlichen Gründen 쐍 Raumpostfächer 쐍 Rollengruppen und Rollenzuweisungen (siehe Kapitel 4, »Rollenbasierte Zugriffssteuerung«) 쐍 Allgemeine Überwachungsberichte 쐍 Gruppennamensrichtlinien 쐍 Konten ohne Exchange-Postfach 쐍 Persönliche Tags zur Kennzeichnung von Elementen für die Aufbewahrung 쐍 Unified-Messaging-Optionen (falls UM bereitgestellt ist) 235
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Sie sehen nur die Aufgaben für Ihre Rolle
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Kleinere Ergänzungen sind u.a. die Möglichkeit, Gruppen in der globalen Adressliste auszublenden und Verteilergruppen in Sicherheitsgruppen umzuwandeln. Die weitere Verwaltung dieser Sicherheitsgruppen erfolgt jedoch wie bei allen anderen. Beachten Sie, dass Verteilergruppen in der Exchange-Systemsteuerung als »öffentliche Gruppen« bezeichnet werden. In Exchange Server 2010 können Sie das Design der Exchange-Systemsteuerung nicht ändern, wie es bei OWA möglich ist. Zu den häufigsten Vorschlägen von Administratoren für neue Optionen gehört die Möglichkeit, das Erscheinungsbild der Seiten durch das Hinzufügen von Firmenlogos oder das Einbetten neuer Optionen anpassen zu können. Möglicherweise wird sich Microsoft in einem zukünftigen Release darum kümmern.
Überblick über die Exchange-Systemsteuerung Die Exchange-Systemsteuerung ist eine ASP.NET-Anwendung, die Sie in jedem Browser öffnen können, der auch die Premiumversion von OWA unterstützt. In anderen Browsern können Sie die Exchange-Systemsteuerung möglicherweise auch ausführen, aber nicht unbedingt alle Aufgaben erledigen. Beispielsweise ist Firefox 3+ auf Windows vollständig geeignet, funktioniert zur Anzeige der Exchange-Systemsteuerung auf einer Linux-Plattform aber nicht so gut. Hinter den Kulissen wird die Exchange-Systemsteuerung als virtuelles IIS-Verzeichnis auf einem Clientzugriffsserver implementiert. Exchange installiert dieses virtuelle Verzeichnis automatisch, wenn Sie einem Server die Clientzugriffsrolle hinzufügen. Wie die Einstellungen für das virtuelle OWA-Verzeichnis werden auch die für die Exchange-Systemsteuerung in Active Directory und der IIS-Metabasis gespeichert und können mit folgenden Cmdlets bearbeitet werden: 쐍 New-ECPVirtualDirectory Wird vom Exchange-Setupprogramm verwendet, um das neue virtuelle IIS-Verzeichnis für die Exchange-Systemsteuerung zu erstellen. Es ist höchst unwahrscheinlich, dass Sie diesen Befehl jemals außerhalb des Setupprogramms verwenden werden. 쐍 Set-ECPVirtualDirectory Legt die Eigenschaften des virtuellen ECP-Verzeichnisses fest, z.B. für die Benutzerauthentifizierung. 쐍 Get-ECPVirtualDirectory Ruft die Werte der Eigenschaften des virtuellen ECP-Verzeichnisses ab. 쐍 Remove-ECPVirtualDirectory Entfernt ein virtuelles ECP-Verzeichnis. 쐍 Test-ECPConnectivity Prüft, ob die Exchange-Systemsteuerung normal funktioniert und von Webclients erreicht werden kann. In der ursprünglichen Version von Exchange Server 2010 mussten Sie sich zur Verbindung mit der Exchange-Systemsteuerung mit einem Konto anmelden, das über ein Postfach auf einem Exchange Server 2010-Computer verfügt. Jedes Konto, mit dem Sie Verwaltungstätigkeiten innerhalb von Exchange durchführen wollten, musste also E-Mail-aktiviert sein, damit Exchange ihm über die rollenbasierte Zugriffssteuerung die erforderlichen Rollen zuweisen konnte. Die Exchange-Systemsteuerung nutzte das OWA-Autorisierungsmodul, das zur Autorisierung von Konten mit Exchange-Postfächern gedacht war. Es gab also irgendeine technische Verbindung zwischen Exchange-Systemsteuerung und OWA. TIPP Die Exchange-Systemsteuerung zeigt immer nur maximal 500 Objekte auf einmal an. Wenn es mehr als 500 Postfächer, Gruppe oder andere Arten von Objekten gibt, müssen Sie das Objekt, mit dem Sie arbeiten wollen, dadurch auswählen, dass Sie einen Teil seines Namens in das Suchfeld eingeben, sodass die Exchange-Systemsteuerung nur die damit übereinstimmenden Elemente anzeigt.
236
Grundlegende Aufgaben für Benutzer in der Exchange-Systemsteuerung Wenn Sie die Exchange-Systemsteuerung öffnen (siehe Abbildung 5.22), können Sie auswählen, was Sie verwalten möchten: Ihr eigenes Konto, einen anderen Benutzer, oder sonstige Elemente der Organisation, auf die Sie laut Ihrer Rolle Zugriff haben. Über die Auswahl Mich kann ein Benutzer die Einstellungen für sein eigenes Postfach einsehen und ändern. Außerdem kann er Gruppen beitreten und verlassen und Informationen über die Gruppen abrufen, in denen er Mitglied ist. Ferner besteht Zugriff auf die Einstellungen für Junk-E-Mail-Filter. Die Auswahl zwischen Mich, Meine Organisation und Anderer Benutzer wird nur Administratoren angezeigt (Benutzern, die irgendeiner Administratorrolle zugewiesen sind). Über den Eintrag Meine Organisation erhalten Sie Zugriff auf Verwaltungsobjekte wie Discoverysuchvorgänge, Transport- und Journalregeln sowie Rollenzuweisungen. Mit Anderer Benutzer können Sie die Einstellungen für die Postfächer anderer Benutzer ändern. Abbildg. 5.22
Auswählen des Verwaltungsbereichs in der Exchange-Systemsteuerung
Über die rollenbasierte Zugriffssteuerung wird festgelegt, welche Optionen die Benutzer sehen, wenn sie die Exchange-Systemsteuerung öffnen. Die Optionen, die Einstellungen für das Postfach eines anderen Benutzers zu bearbeiten, werden beispielsweise nur dann angezeigt, wenn der Benutzer zur Rollengruppe Recipient Management gehört. Daher können Sie festlegen, welche Optionen ein Benutzer zu sehen bekommt, indem Sie seine Rollenzuweisung ändern. Weitere Informationen
Das Exchange-Team hat in seinem Blog auf http://msexchangeteam.com/archive/2010/03/04/ 454148.aspx einen Artikel veröffentlicht, der gut beschreibt, wie die Exchange-Systemsteuerung die rollenbasierte Zugriffssteuerung nutzt. Gehen Sie dazu auf folgende Weise vor: 1. Ermitteln Sie, welche Cmdlets für eine bestimmte Tätigkeit erforderlich sind. Wie wir aus Kapitel 4
wissen, werden die Benutzer zu Rollengruppen zugewiesen, um ihnen die notwendigen Berechtigungen zur Ausführung bestimmter Aktionen zu geben. Die Rollengruppen umfassen Rollen, die bestimmen, welche Cmdlets und Parameter ein Benutzer mit dieser Rolle ausführen darf. Als Erstes suchen Sie daher in der Web.config-Datei im Verzeichnis \Program Files\Microsoft\Exchange Server\ V14\ClientAccess\ecp\Reporting nach dem Eintrag für die Funktion, die uns interessiert. Dort sind die zugehörigen Cmdlets aufgeführt.
237
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Grundlegende Aufgaben für Benutzer in der Exchange-Systemsteuerung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
2. Führen Sie Get-ManagementRole aus, um die Rollen zu finden, die den Zugriff auf das gewünschte
3.
4.
5.
6.
7.
Cmdlet erlauben. Manche Cmdlets sind nur in einer einzigen Rolle zulässig, andere dagegen in mehreren. Führen Sie Get-ManagementRoleAssignment aus, um herauszufinden, welche Rollen den Benutzern zugewiesen sind, deren Zugriff auf die Exchange-Systemsteuerung wir anpassen möchten. Vergleichen Sie die Ausgabe des Cmdlets mit den Rollen, die Sie in Schritt 2 ermittelt haben, um die Rollen und Rollengruppen einander zuordnen zu können. Dazu ist es erforderlich, dass Sie eine Vorstellung von der Funktionsweise von Exchange haben. Wenn es nicht auf Anhieb klappt, können Sie sich nach dem Prinzip von Versuch und Irrtum an das richtige Ergebnis herantasten. Erstellen Sie mit New-ManagementRoleAssignmentPolicy eine neue Rollenzuweisungsrichtlinie als Ersatz für die bestehende Standardrichtlinie. Alle grundlegenden Optionen, die ein Benutzer in der Exchange-Systemsteuerung sieht, werden ihm durch die in der Standardzuweisungsrichtlinie enthaltenen Rollen zur Verfügung gestellt. Entfernen Sie aus der Rollenzuweisungsrichtlinie die Rollen für die Optionen, die die Benutzer in der Exchange-Systemsteuerung nicht sehen sollen, und fügen Sie die Rollen für die gewünschten Optionen hinzu. Damit die Benutzer ihre Kontaktinformationen einsehen und ändern können, müssen Sie beispielsweise die Rolle MyContactInformation aufnehmen. Die Optionen, die Sie entfernen möchten, können sich auch in einer der grundlegenden Rollen befinden. Erstellen Sie mit New-ManagementRole eine Kopie der Rolle und geben Sie die vorhandene Version als deren übergeordnete Rolle an. Jetzt können Sie die neu erstellte Rolle bearbeiten und alle Cmdlets für unerwünschte Optionen daraus entfernen. Anschließend fügen Sie die neue Rolle der in Schritt 4 erstellten Zuweisungsrichtlinie hinzu. Ihnen liegt jetzt eine neue Rollenzuweisungsrichtlinie mit den erforderlichen Rollen vor, um den Benutzern die gewünschten Optionen anzuzeigen, ohne ihnen die zu zeigen, die wir ihnen vorenthalten wollen. Um die Änderungen in Kraft zu setzen, weisen Sie die Rollenzuweisungsrichtlinie mit Set-Mailbox den gewünschten Benutzern zu. Wenn sie das nächste Mal die Exchange-Systemsteuerung öffnen, wird die Oberfläche anhand der neuen Rollen angepasst, sodass nur das zu sehen ist, was der Benutzer auch sehen soll.
Das scheint alles ziemlich kompliziert zu sein, da so viele Schritte durchzuarbeiten sind und Sie sich darüber im Klaren sein müssen, dass Rollen letzten Endes aus einer Liste der Cmdlets bestehen, die für den Zugriff auf bestimmte Funktionen erforderlich sind, und dass Rollen für Endbenutzer über eine Richtlinie zugewiesen werden. Die Exchange-Systemsteuerung in Exchange Server 2010 SP1 macht alles sehr viel einfacher, da Sie hier die gesamte Arbeit in der Browseroberfläche vornehmen können, ohne auf die Verwaltungsshell zurückgreifen zu müssen. Allerdings ist es gut, die Prinzipien zu verstehen und zu wissen, was hinter den Kulissen vor sich geht. Die meisten Benutzer werden über die Optionsauswahl von OWA auf die Exchange-Systemsteuerung zugreifen. Abbildung 5.23 zeigt die grundlegende Ansicht, die Benutzer ohne besondere Berechtigungen erhalten. Darin können sie nur ihre persönlichen Postfacheinstellungen wie z.B. die Telefonnummer ändern.
238
Grundlegende Aufgaben für Benutzer in der Exchange-Systemsteuerung
Grundlegende Ansicht der Exchange-Systemsteuerung für Benutzer
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Abbildg. 5.23
Auf den einzelnen Bildschirmen werden die verschiedenen Optionen angezeigt, die die Benutzer bearbeiten können, z.B. die zum Erstellen einer automatischen Signatur (siehe Abbildung 5.24). Die anderen Optionen auf diesem Bildschirm betreffen das Leseverhalten, das Format für neue Nachrichten (der Standard ist HTML) und die Schriftart für den Nachrichtentext. Außerdem können Sie auswählen, ob in Nachrichtenheadern die Von- und BCC-Header angezeigt werden sollen. Das Von-Feld ist nützlich, wenn Sie Nachrichten für andere Benutzer verfassen. Allerdings können Sie Nachrichten nicht mit dem S/MIME-Steuerelement von OWA verschlüsseln, wenn dieses Feld im Nachrichtenheader angezeigt wird. Neben dem Bildschirm E-Mail stehen in der Rubrik Einstellungen noch die folgenden zur Verfügung: 쐍 Rechtschreibung Hier haben Sie die Wahl, neue Nachrichten vor dem Senden einer Rechtschreibprüfung zu unterziehen und können außerdem festlegen, dass Wörter in Großbuchstaben und Wörter mit Ziffern dabei ignoriert werden. Wählen Sie außerdem aus, welches Wörterbuch (also welche Sprache) OWA für die Rechtschreibprüfung verwenden soll. 쐍 Kalender Legen Sie die Tage und Stunden der Arbeitswoche fest und geben Sie an, welche automatische Verarbeitung Exchange an Ihrem Kalender vornehmen soll (beispielsweise können Sie automatisch neue Besprechungsanforderungen im Kalender platzieren lassen). Es gibt hier auch die nützliche Option Hilfe bei der Behandlung von Problemen beim Kalender, über die ein Benutzer seine Kalenderprotokolle an Microsoft senden kann, um Hilfestellung zu erhalten. In diesem Abschnitt richten die Benutzer auch ihre SMS-Einstellungen ein.
239
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
쐍 Allgemein Hier entscheiden Sie, ob die Empfängerangaben in neuen Nachrichten anhand der globalen Adressliste oder anhand Ihrer Kontakte aufgelöst werden sollen. Außerdem können Sie hier eine OWA-Version für sehbehinderte Benutzer auswählen. 쐍 Regional Wählen Sie Sprache sowie das Datums- und Uhrzeitformat für das Postfach aus. Dabei können Sie nur aus den installierten Sprachen auf dem Clientzugriffsserver auswählen, mit dem die Exchange-Systemsteuerung verbunden ist. 쐍 Kennwort
Hier legen Sie ein neues Kennwort für Ihr Windows-Konto fest.
쐍 S/MIME Hier können Sie das S/MIME-Steuerelement herunterladen, mit dem OWA ausgehende Nachrichten verschlüsselt und digital signiert. Abbildg. 5.24
Verfügbare Postfacheinstellungen in der Exchange-Systemsteuerung
Viele dieser Benutzereinstellungen waren in früheren Versionen in OWA verfügbar. Wenn Sie in OWA 2010 die Anzeige der Optionen auswählen, wird die Browsersitzung zu einer angepassten Version der Exchange-Systemsteuerung umgeleitet, die nur die Benutzeroptionen anzeigt.
240
Grundlegende Aufgaben für Benutzer in der Exchange-Systemsteuerung
Regeln sind ein Thema für sich. Ein Satz von Regeln gehört zu Exchange und wird auch dort verwaltet, der andere Satz gehört zu Outlook. Die Regelfunktion von Outlook erweckt den Anschein, als ob sie die von Exchange anschließt, da der Regel-Editor von Outlook schon immer überlegen und mit einem größeren Funktionsumfang gesegnet war als die Version, die bei Exchange für die Verwendung in OWA mitgeliefert wurde. Die Überlegenheit betrifft aber in Wirklichkeit nur die Benutzeroberfläche für die Regeln. Hinter den Kulissen führt Exchange den Großteil der Verarbeitung für eingehende Elemente durch und lässt Outlook nur noch die Schritte tun, die auf dem Client ausgeführt werden müssen. Insidertipp: Getrennte Regelfunktionen
Es gibt gute Gründe dafür, dass Exchange seine eigene Regelfunktion umfasst, denn ansonsten würde Benutzern, die einen anderen Client als Outlook verwenden, keine Regelverarbeitung zur Verfügung stehen. Allerdings wirkt es uneinheitlich und ist auch nicht gerade wirtschaftlich, zwei Regelsätze nebeneinander zu betreiben. Exchange kann keine Regel bearbeiten, die sich im Besitz von Outlook befindet, und umgekehrt, und versucht daher, die beiden Regelsätze zu synchronisieren. Eine weitere Quelle der Irritation kann der Unterschied bei der Anwendung clientseitiger und serverseitiger Regeln sein. Die Verwendung einer clientseitigen Regel deutet stillschweigend an, dass eine Aktion erforderlich ist, die nur auf dem Client ausgeführt werden kann, wohingegen serverseitige Regeln unabhängig von jedem Clienteingriff auf dem Server ausgeführt werden können. Das Ergebnis der serverseitigen Regelverarbeitung gilt für alle Clients und für alle Elemente, die zunächst die serverseitige Verarbeitung durchlaufen müssen, bevor sie von clientseitigen Regeln verarbeitet werden. Ein Beispiel für die serverseitige Verarbeitung ist die Beseitigung von JunkE-Mail. Exchange bereinigt den E-Mail-Datenstrom und entfernt Spam, bevor die Nachrichten an Clients weitergeleitet werden. Eine clientseitige Regel ist dagegen z.B. eine, die überprüft, ob irgendeine eingehende Nachricht das Wort »wichtig« im Betreff aufweist, und diese E-Mail dann in einen besonderen Ordner verschiebt. Ein weiteres Beispiel ist eine Regel, die eine Benachrichtigung ausgibt, wenn eine Nachricht von einem bestimmten Benutzer eintrifft. Meine Lieblingsregel ist diejenige, die den Versand aller ausgehenden Nachrichten (bis auf die mit Wichtigkeit Hoch) um zwei Minuten verzögert, sodass der Absender noch die Gelegenheit hat, rettend einzugreifen, wenn eine Nachricht falsch adressiert ist, nicht über den richtigen Anhang verfügt oder in einer Aufwallung der Gefühle verfasst wurde und daher einige unpassende Wörter enthält. Solche Regeln können nicht auf dem Server ausgeführt, sondern müssen von Outlook verarbeitet werden. Exchange und Outlook verarbeiten die Nachrichten anhand aller anwendbaren Regeln. Dabei nimmt Exchange die gesamte Regelverarbeitung vor, die auf dem Server möglich ist. Ist anschließend noch eine clientseitige Verarbeitung erforderlich, legt Exchange im Ordner Deferred Actions eine besondere Nachricht an. Diese »Nachricht über verzögerte Aktionen« (Deferred Action Message, DAM) teilt Outlook mit, dass der Abschluss der Verarbeitung noch aussteht. Outlook liest die DAMs, sobald Exchange sie erstellt, und führt die entsprechenden Aktionen aus. Wenn Outlook offline war und sich während dieser Zeit DAMs angesammelt haben, werden sie bei der nächsten Initialisierung des Clients aufgelöst. Von diesen Aktivitäten bekommen Sie nie etwas zu sehen, da der Ordner und die Nachrichten in jeglicher Clientansicht verborgen sind. Lediglich mit einem Debuggingwerkzeug wie MFCMAPI können Sie sie sichtbarmachen.
241
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Posteingangsregeln
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
In früheren Versionen von Exchange haben die Benutzer Regeln in Outlook und OWA verwaltet. Das ist in Exchange Server 2010 nach wie vor der Fall. Die große Neuerung besteht darin, dass sie ihre serverseitigen Regeln jetzt in der Exchange-Systemsteuerung erstellen, ändern und löschen können. Auch Administratoren können Regeln für Benutzer in der Exchange-Systemsteuerung und -Verwaltungskonsole verwalten. Früher hatten Administratoren keinerlei Zugriff auf Benutzerregeln, sodass die Benutzer selbst dafür verantwortlich waren. Der Zugriff über die Exchange-Systemsteuerung erfolgt über die Registerkarte Posteingangsregeln des Abschnitts E-Mail organisieren. Hier werden alle serverseitigen Regeln angezeigt, die zurzeit als ausgeblendete Elemente im Postfachstamm gespeichert sind (siehe Abbildung 5.25). Auf die von Outlook ausgeführten clientseitigen Regeln haben Administratoren jedoch nach wie vor keinen Zugriff. Bei der Auswahl von Bedingungen für eine neue Regel bietet die Exchange-Systemsteuerung ebenso wie der Regelassistent von Outlook ausreichende Möglichkeiten. Um eine Regel aufzustellen, müssen Sie sich über vier grundlegende Aspekte im Klaren sein: Nach welchen Kriterien muss der Server in neuen Nachrichten Ausschau halten, um zu bestimmen, ob eine Regel darauf angewendet werden soll? Welche Maßnahme soll getroffen werden? Gibt es irgendwelche Ausnahmen von der Regel? Soll Exchange die Verarbeitung anderer Regeln aussetzen, nachdem eine bestimmte Regel ausgeführt wurde? In der Exchange-Systemsteuerung können Sie die Regeln nach Prioritäten anordnen. Damit lässt sich auf einfache Weise festlegen, welche Regel die wichtigste ist und in welcher Reihenfolge die anderen verarbeitet werden sollen. Abbildg. 5.25
242
Anzeigen von Postfachregeln
Es gibt zwar einige Benutzer, die eine Reihe verzwickter und komplizierter Regeln aufstellen, um ihren Posteingang ausführlich zu gliedern, doch die große Mehrheit ist mit wenigen einfachen Regeln zufrieden, die Nachrichten je nach Absender oder Thema in verschiedene Ordner verschiebt. Ein anderes einfaches Kriterium für eine solche Sortierung ist etwa die Frage, ob eine E-Mail direkt oder als Kopie (CC) an den Benutzer gegangen ist. Benutzer, die besonders ausgefeilte Regeln erstellen möchten, sind mit den Möglichkeiten von Outlook wahrscheinlich besser bedient, aber für die grundlegenden Regeln, die die Mehrheit der Benutzer verwendet, bietet sich auch die Exchange-Systemsteuerung als geeignetes Werkzeug an. Wie Sie in Abbildung 5.26 sehen, teilt die Exchange-Systemsteuerung die Regeldefinition in drei Hauptabschnitte auf. In Dropdownlisten finden Sie die verfügbaren Bedingungen für die einzelnen Abschnitte, und mit der Postfach- und Gruppenauswahl können Sie bei Bedarf Namen angeben. Die Regel in diesem Beispiel ist sehr einfach gehalten: Alle Nachrichten, die im Betreff oder im Text ein bestimmtes Wort enthalten, sollen in einen festgelegten Ordner verschoben werden, es sei denn, es kommt auch das Wort »Fehlschlag« vor. Außerdem wird verlangt, keine weitere Verarbeitung mehr auf die Nachricht anzuwenden, was auch nur logisch ist, denn sobald die E-Mail durch diese Regel in den richtigen Ordner verschoben worden ist, gibt es nichts, was wir dort mit einer anderen Regel noch ausrichten wollten. Abbildg. 5.26
Erstellen einer neuen Posteingangsregel
Hinter den Kulissen sind Regeln jedoch weit komplizierter, als dieses einfache Beispiel ahnen lässt. Einen Eindruck davon können Sie bekommen, wenn Sie sich die vielen Parameter der Cmdlets NewInboxRule und Set-InboxRule ansehen, die steuern, welche Kriterien und Aktionen festgelegt werden.
243
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Grundlegende Aufgaben für Benutzer in der Exchange-Systemsteuerung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Nehmen wir als Beispiel eine völlig triviale Regel, die in Betreff und Nachrichtentext nach dem Wort »Hello« sucht, den Status auf »Gelesen« setzt und die weitere Verarbeitung abbricht. Der Code dafür sieht wie folgt aus: New-InboxRule 'Stop Hello spam' –Mailbox '[email protected]' –BodyContainsWords 'Hello' –SubjectContainsWords 'Hello' –StopProcessingRules $True –MarkAsRead $True
Sicherheit geht vor: Einschränkungen für Administratoren
Administratoren können für Benutzer zwar einfache Regeln wie die vorstehende einrichten, aber keine Regeln erstellen, die Elemente von einem Ordner in einen anderen verschieben, nicht einmal innerhalb eines Postfachs. Schließlich sollten Administratoren nicht einmal wissen, welche Ordner es in einem Benutzerpostfach gibt. Daher wäre es inkonsequent und außerdem eine potenzielle Sicherheitslücke, wenn sie für einen Benutzer eine Regel erstellen könnten, durch die Elemente verschoben werden, und das womöglich noch ohne Wissen des Benutzers. Stellen Sie sich nur einmal vor, ein Administrator könnte eine Regel für das Postfach eines Geschäftsführers erstellen, die alle neuen Nachrichten mit einem bestimmten Schlüsselbegriff in einen Ordner des Administratorpostfachs verschiebt! Um eine Regel für Ihr Postfach zu erstellen, die Nachrichten nach dem Eintreffen in einen bestimmten Ordner verschiebt, können Sie natürlich auch die Exchange-Verwaltungsshell verwenden. Die folgende Regel sucht beispielsweise nach Nachrichten, die an eine bestimmte Gruppe gesendet wurden (identifiziert anhand ihrer SMTP-Adresse), und verschiebt sie in einen Order. Die Angabe dieses Ordners erfolgt in einem Schema, das die Eindeutigkeit garantiert, allerdings nicht gerade die Einfachheit der Anwendung. Mit Get-MailboxFolder -Recurse | Format-List Name, Identity können Sie sich eine Liste der Ordner in Ihrem Postfach ansehen. New-InboxRule -Name "Exchange Discussion Group messages" -SentTo '[email protected]' -MoveToFolder "contoso.com/Users/Akers, Kim:\Inbox\Exchange Discussions"
Die zuletzt hinzugefügte Spitze wandert automatisch an die Spitze der Prioritätsreihenfolge. Mit GetInboxRule können Sie Angaben über die Regeln für ein bestimmtes Postfach abrufen. Die Regeln werden dabei in der Reihenfolge der Priorität aufgeführt. Get-InboxRule –Mailbox '[email protected]' | Format-List
Wie bereits erwähnt, unterhalten Exchange und Outlook jeweils einen eigenen Satz von Regeln für ein Benutzerpostfach. Wenn Sie über die Exchange-Systemsteuerung oder -Verwaltungsshell eine Posteingangsregel zu ändern versuchen, warnt Exchange Sie vor möglichen Problemen, denn wenn Sie fortfahren, löscht Exchange alle Outlook-spezifischen Regeln, speichert also nur diejenigen, die es selbst kennt (also diejenigen, die in der Exchange-Systemsteuerung angezeigt werden). Bei Microsoft ist man sich darüber im Klaren, dass diese Situation inakzeptabel ist, und man hat Besserung in zukünftigen Versionen gelobt. In der Zwischenzeit sollten Sie für die Arbeit mit Posteingangsregeln stets denselben Client verwenden, da jeder Versuch einer Regelverwaltung mit verschiedenen Werkzeugen zu einem Desaster führen kann.
244
Grundlegende Aufgaben für Benutzer in der Exchange-Systemsteuerung
Häufig müssen sich Administratoren von Benutzern anhören, dass eine gesendete E-Mail niemals zugestellt worden ist. Es kann hin und wieder durchaus vorkommen, dass Exchange aufgrund irgendwelcher Probleme versagt und Nachrichten nicht ausliefert, aber in den meisten Fällen liegt der Grund für eine fehlende Zustellung einfach in einem Benutzerfehler. Meistens sind die E-Mails dann nicht richtig adressiert gewesen (an die falsche Person gesendet), wurden in eine Warteschlange gestellt, um sie zu einem späteren Zeitpunkt zu senden, oder nur im Entwurfsordner gespeichert und nicht abgeschickt. Es ist zwar schön für einen Administrator, wenn er schließlich die Ursache des Problems herausfindet, aber das kann auch viel Zeit kosten. Über Übermittlungsberichte (siehe Abbildung 5.27) können die Benutzer Exchange selbst abfragen, um zu ermitteln, was mit einer gesendeten Nachricht geschehen ist. Dabei suchen die Benutzer selbst oder ein Administrator nach einer bestimmten Nachricht und lassen einen umfassenden Bericht erstellen, der genau erklärt, was vorgefallen ist. Abbildg. 5.27
Zusammenstellen eines Suchvorgangs für einen Übermittlungsbericht
Benutzer können Übermittlungsberichte (an einigen Stellen der Oberfläche auch als Zustellungsberichte bezeichnet) für die von ihnen selbst gesendeten Nachrichten erstellen lassen, sofern sie einen der folgenden Clients verwenden: 쐍 OWA Der Zugriff auf die Option Übermittlungsberichte erfolgt, indem Sie eine Nachricht markieren, mit der rechten Maustaste darauf klicken und dann Übermittlungsbericht öffnen auswählen. 쐍 Outlook 2010
Der Zugriff auf die Übermittlungsberichte erfolgt im Backstage-Bereich.
쐍 Exchange-Systemsteuerung verfügbar.
Hier sind Übermittlungsberichte im Abschnitt E-Mail organisieren
245
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Übermittlungsberichte
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Wenn die Benutzer einen anderen Client verwenden, muss der Administrator für sie einen Übermittlungsbericht erstellen. Um mit der Suche zu beginnen, klicken Sie auf Übermittlungsberichte und geben die Grundparameter für die Suche an: 쐍 Legen Sie fest, ob nach Nachrichten gesucht werden soll, die der Benutzer empfangen hat, oder nach solchen, die er gesendet hat. 쐍 Geben Sie als Suchbegriff die Wörter an, die in der Betreffzeile vorkommen sollen. Die Exchange-Systemsteuerung führt die Suche durch und zeigt alle Nachrichten, die die Bedingungen erfüllen, im Ergebnisbereich unterhalb der Suchkriterien an (siehe Abbildung 5.28). Um Einzelheiten zu sehen, wählen Sie eine der Nachrichten aus (siehe Abbildung 5.29). Abbildg. 5.28
Suchergebnisse für einen Übermittlungsbericht
Abbildg. 5.29
Anzeige der Einzelheiten eines Übermittlungsberichts
246
Wenn ein Benutzer einer Nachricht nachspürt, ist er mit einem Clientzugriffsserver verbunden und daher nicht auf die Übermittlungsinformationen auf dem Server beschränkt, auf sich sein Postfach zurzeit befindet. Er kann selbst dann einen Übermittlungsbericht für eine Nachricht erstellen, wenn das Postfach zu einer anderen Datenbank auf dem anderen Server verschoben wurde oder wenn die Datenbank auf einem anderen Server der Verfügbarkeitsgruppe bereitgestellt wurde.
Administratoraufgaben in der Exchange-Systemsteuerung Wenn ein Benutzer durch die Mitgliedschaft in einer Rollengruppe einige zusätzliche Verwaltungsmöglichkeiten gewonnen hat, sieht er beim Start der Exchange-Systemsteuerung zusätzliche Optionen für die durch die Rollengruppe erlaubten Cmdlets und Parameter. Abbildung 5.30 zeigt die Oberfläche, die eine Benutzerin in der Rollengruppe Recipient Management sieht. Neben den Optionen für die Bearbeitung der persönlichen Einstellungen für das eigene Postfach stehen ihr auch Möglichkeiten zur Verwaltung der Organisation zur Verfügung, die ihr den Zugriff auf weitere Objekte gestatten. Abbildg. 5.30
Benutzeroberfläche der Exchange-Systemsteuerung mit zusätzlichen Optionen aufgrund der Mitgliedschaft in einer Rollengruppe
Mitglieder der Rollengruppe Recipient Management dürfen mit Postfächern, Gruppen und Kontakten arbeiten. Dabei können sie neue Gruppen und Kontakte erstellen, aber keine neuen Postfächer, sondern können nur die Eigenschaften der bereits vorhandenen bearbeiten. Der Grund dafür ist, dass beim Erstellen eines neuen Postfachs meistens auch ein Active Directory-Konto angelegt werden 247
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Administratoraufgaben in der Exchange-Systemsteuerung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
muss. Microsoft hatte nicht mehr genügend Zeit, um bei der Entwicklung die vielen verschiedenen Aspekte auszuarbeiten, die beim Erstellen neuer Konten zu beachten sind, z.B. die Auswahl der Organisationseinheit, delegierte Verwaltung usw. In den ersten Builds von Exchange Server 2010 war es auch in der Exchange-Systemsteuerung möglich, Postfächer zu erstellen, aber diese Funktion wurde wieder entfernt, als sich die damit einhergehenden Probleme zeigten. Zurzeit können Sie neue Postfächer nur in der Exchange-Verwaltungskonsole oder -Verwaltungsshell anlegen, aber es sollte nicht überraschen, wenn diese Funktion in einer kommenden Version der Exchange-Systemsteuerung wieder auftaucht. Insidertipp: Wer verwendet die Exchange-Systemsteuerung?
Die Exchange-Systemsteuerung ist für Verwaltungsmitarbeiter gedacht, die nicht alle Interna der Exchange-Organisation in der Vielschichtigkeit angezeigt bekommen müssen, wie sie manchmal in der Exchange-Verwaltungskonsole zu sehen sind. Daher überrascht es nicht, dass erfahrene Administratoren die Exchange-Systemsteuerung nur selten nutzen. Es gibt zwar Optionen für Rollen und Übermittlungsberichte, die nicht in der Verwaltungskonsole zu finden sind, sodass die Administratoren dafür auf die Exchange-Systemsteuerung zurückgreifen müssen (oder die Verwaltungsshell). Für Angestellte wie etwa Supportmitarbeiter, die nicht unbedingt viel Erfahrung in der Exchange-Verwaltung haben müssen, bedeutet es jedoch eine große Erleichterung, dass sie für Aufgaben wie die Änderung von Gruppeneigenschaften, z.B. für die Nachrichtengenehmigung, nicht mehr die Verwaltungskonsole oder die Verwaltungsshell heranziehen müssen. Wie bereits erwähnt, ist es in der Exchange-Systemsteuerung aufgrund der komplizierten Natur der zugrunde liegenden OPATH-Filter jedoch nicht möglich, dynamische Verteilergruppen zu erstellen oder zu pflegen.
Übermittlungsberichte von Administratoren Benutzer können selbst Übermittlungsberichte erstellen, brauchen dazu aber manchmal Hilfe. Möglicherweise wissen sie nicht einmal, dass es so etwas gibt und dass sie sich selbst darum kümmern können, weshalb sie sich mit Hilferufen an den Support wenden: »Ich habe jemandem in einem anderen Unternehmen eine Nachricht zu einem wichtigen Vertrag geschickt, und jetzt muss ich unbedingt wissen, warum diese E-Mail nie angekommen ist!« Der Support kann dem Benutzer erklären, wie er seine eigenen Suchvorgänge durchführen kann, aber manchmal ist es einfacher, das für ihn zu erledigen. Administratoren können für andere Benutzer Übermittlungsberichte erstellen, wenn sie zu einer der folgenden drei Rollengruppen gehören: 쐍 Organization Management 쐍 Recipient Management 쐍 Records Management Sie können einzelnen Benutzern und Gruppen die Möglichkeiten zum Erstellen von Übermittlungsberichten für andere gewähren, indem Sie ihnen die Rolle Message Tracking zuweisen. Mit dem folgenden Befehl weisen Sie diese Rolle beispielsweise der Sicherheitsgruppe Central Help Desk zu. Jeder Benutzer, der Mitglied dieser Gruppe ist, kann Übermittlungsberichte für andere Benutzer erstellen, sofern er über eine andere Rolle oder Rollengruppe wie etwa View-only Organization auch die erforderlichen Rechte hat, um Informationen über diese anderen Benutzer einzusehen. New-ManagementRoleAssignment "Message Tracking and Delivery Reports" –Role "Message Tracking" –SecurityGroup 'Central Help Desk' 248
Bevor Sie beginnen, sollten Sie wissen, woher die Daten stammen, die in einem Übermittlungsbericht angezeigt werden. Exchange unterhält mehrere Nachrichtenverfolgungsprotokolle und spürt darin der Weitervermittlung der E-Mails vom Verlassen des Postfachs über den Informationsspeicher, den HubTransport-Server usw. nach, bis die Nachricht Exchange über einen Connector verlässt oder an die Empfängerpostfächer ausgeliefert wird. Solche Protokolle gibt es schon seit vielen Exchange-Versionen und dienten den Administratoren dazu, Nachrichten zu verfolgen und das E-Mail-Aufkommen sowie die Verwendungsmuster zu analysieren. In Exchange Server 2010 wurde die Nutzungsmöglichkeit dieser Daten noch erweitert, sodass die Benutzer nun der Weitervermittlung ihrer eigenen Nachrichten in den Übermittlungsberichten nachspüren können. Administratoren haben nach wie vor die Möglichkeit, die Nachrichtenverfolgungsprotokolle im Verfolgungsprotokoll-Explorer einzusehen, der sich in der Toolbox der Exchange-Verwaltungskonsole befindet, und für manche Zwecke wie die Datenverkehrsanalyse und die Fehlersuche ist das auch der geeignete Weg. Eine vollständige Beschreibung des Verfolgungsprotokoll-Explorers und der zugrunde liegenden Cmdlets finden Sie in Kapitel 15. Übermittlungsberichte sind vor allem deshalb nützlich, weil Administratoren die Aufgabe, Einzelheiten über das Voranschreiten einer Nachricht zu ermitteln, an andere delegieren und die Ergebnisse dann an die Person senden kann, die eine Bestätigung der ordnungsgemäßen Verarbeitung angefordert hat. Eine solche Bestätigung umfasst jedoch nur den Bereich, über den Exchange Bericht erstatten kann, ist also auf die Grenzen der Organisation beschränkt, da Exchange nichts über das weitere Schicksal einer Nachricht herausfinden kann, nachdem sie in ein fremdes E-Mail-System oder sogar ein anderes Exchange-System mit einer früheren Version übergegangen ist. Obwohl Exchange die Nachrichtenverfolgungsprotokolle vieler Wochen aufbewahren kann, decken Übermittlungsberichte nur die letzten zwei Wochen ab, da Exchange die besonderen Indizes für die Suchvorgänge nur so lange beibehält. Fehlerbehebung: Für ein verschobenes Postfach ist kein Übermittlungsbericht verfügbar
Da Nachrichtenverfolgungsprotokolle jeweils für einen bestimmten Server unterhalten werden, treten nach dem Verschieben eines Postfachs von einem Server auf den anderen Probleme beim Erstellen von Übermittlungsberichten auf. Für Nachrichten, die nach dem Verschiebevorgang gesendet oder empfangen wurden, können Übermittlungsberichte erstellt werden, da sich die Verfolgungsprotokolle mit den entsprechenden Informationen auf demselben Server befinden. Wenn Sie jedoch versuchen, einen Übermittlungsbericht für eine Nachricht anzufordern, die vorher gesendet oder empfangen wurde, werden Sie keinen Erfolg haben, da die dazu benötigten Daten fehlen. Mit zwei Konfigurationseinstellungen können Sie steuern, welche Daten in Übermittlungsberichte aufgenommen werden. Die Betreffprotokollierung bestimmt, ob Sie bei der Suche den Nachrichtenbetreff sehen können. Natürlich ist es sehr viel einfacher, eine bestimmte Nachricht zu finden, wenn Sie den Betreff kennen und in den Suchergebnissen auch vorfinden. Die Betreffzeilen von Nachrichten werden auf Postfach- und Hub-Transport-Servern protokolliert. Wenn Sie die Erfassung dieser Daten unterbinden möchten, müssen Sie dies mit den Cmdlets Set-MailboxServer und Set-TransportServer tun. Die Einstellung gilt jedoch nur jeweils für einen einzigen Server. Wenn Sie sie für alle Server in der Organisation vornehmen möchten, müssen Sie zunächst die Liste sämtlicher Postfachoder Hub-Transport-Server abrufen und dann als Eingabe für das entsprechende Cmdlet verwenden, wie das folgende Beispiel zeigt: Get-TransportServer |Set-TransportServer –MessageTrackingLogSubjectLoggingEnabled $False
249
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Administratoraufgaben in der Exchange-Systemsteuerung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Insidertipp: Vertrauliche Informationen und die Protokollierung der Betreffzeile
In manchen Unternehmen wird die Betreffprotokollierung aus Gründen des Datenschutzes deaktiviert, da Administratoren sonst Informationen sehen könnten, die der Absender lieber nicht weitergeben wollte. Stellen Sie sich vor, ein Administrator nimmt im Postfach des Generaldirektors eine Suche vor, um einen Übermittlungsbericht zu erstellen, und stößt dabei auf eine Nachricht an den Finanzdirektor mit der Betreffzeile »Fusion mit Fabrikam AG«. Damit hat er wahrscheinlich etwas aufgespürt, von dem er nichts wissen sollte. Durch die Deaktivierung der Betreffprotokollierung werden Administratoren sicherlich daran gehindert, in Übermittlungsberichten und bei der Nachrichtenverfolgung über vertrauliche Informationen zu stolpern, aber dadurch wird es auch sehr viel schwieriger, Nachrichten in einem Bericht zu finden. Unter dem Strich ist es wahrscheinlich am besten, die Betreffprotokollierung eingeschaltet zu lassen und darauf zu vertrauen, dass sich die Administratoren der Konsequenzen bewusst sind, wenn sie ohne Autorisierung nach vertraulichen Informationen schnüffeln. Die Lesestatusverfolgung bestimmt, ob der Wechsel des Nachrichtenstatus von »ungelesen« zu »gelesen« angezeigt wird. Clients ändern den Status, wenn ein Benutzer eine neue Nachricht öffnet oder wenn sie eine bestimmte Zeit lang im Vorschaubereich angezeigt wurde (wie lange, kann auf dem Client festgelegt werden). In Exchange Server 2010 ist die Lesestatusverfolgung standardmäßig ausgeschaltet. Wenn Sie den Status im Bericht sehen wollen, müssen Sie diese Funktion wie folgt aktivieren: Set-OrganizationConfig –ReadTrackingEnabled $True
Die Lesestatusverfolgung wird organisationsweit eingerichtet. Wenn Sie diese Funktion aktivieren, verfolgt Exchange daher den Lesestatus in sämtlichen Postfächern der Organisation nach. Für bestimmte Benutzer wie Geschäftsführer oder Personen in besonderen Vertrauensstellungen ist das jedoch nicht unbedingt geeignet, weshalb Sie diese Funktion für ausgewählte Benutzer auch wieder ausschalten können: Set-Mailbox –Identity 'Samantha Smith' –MessageTrackingReadStatusEnable $False
Einfache Benutzer können nur nach dem Verbleib der Nachrichten suchen, die sie selbst gesendet haben, während Administratoren ein Postfach auswählen können, das durchsucht werden soll. Die Suchvorgänge zum Erstellen von Übermittlungsberichten werden im Abschnitt E-Mail organisieren auf der Registerkarte Übermittlungsberichte vorgenommen. Außerdem können die Benutzer in OWA einen Übermittlungsbericht für eine ausgewählte Nachricht anzeigen lassen, indem sie im Ordner Gesendete Elemente bzw. Posteingang mit der rechten Maustaste auf die gewünschte Nachricht klicken und Übermittlungsbericht öffnen auswählen. Bei empfangenen E-Mails können sie auch auf die im Header angezeigte Schaltfläche Aktionen klicken und die Aktion dort auswählen. Von Benutzern erstellte Übermittlungsberichte für eingehende Nachrichten zeigen nur Informationen an, die die Zustellung zum eigenen Postfach betreffen. Beispielsweise kann ein Benutzer darin ablesen, ob eine Gruppe erweitert wurde, um die Nachricht an sein Postfach zu adressieren, oder ob sie nach der Auslieferung an sein Postfach noch mit einer Regel verarbeitet wurde. Nicht sichtbar sind dagegen alle Aspekte, die mit der Zustellung der Nachricht zu anderen Empfängern zu tun haben. Um auch Übermittlungsberichte für Nachrichten an andere Benutzer erstellen zu können, müssen Sie als Verwaltungsbereich Meine Organisation auswählen und zum Abschnitt E-Mail-Steuerelement wechseln. Dort können Sie auf der Registerkarte Übermittlungsberichte die Suchkriterien eingeben.
250
Als Erstes müssen Sie dabei das Postfach angeben, das durchsucht werden soll, gefolgt von den Nachrichtenempfängern (für ausgehende Nachrichten) oder den Personen, die E-Mails an das Postfach gesendet haben. Außerdem müssen Sie die Wörter vermerken, die im Betreff vorkommen sollen. Ging die Nachricht an einen externen Empfänger oder wurde sie von einem externen Absender empfangen, geben Sie dessen SMTP-Adresse ein. Es ist nicht unbedingt erforderlich, Suchbegriffe für die Betreffzeile einzugeben, doch wird das die Geschwindigkeit des Suchvorgangs steigern und auch die Ergebnisse verbessern. Wenn Sie die Suche ausführen, schlägt Exchange in seinen Nachrichtenverfolgungsprotokollen nach und zeigt alle E-Mails an, die mit den Kriterien übereinstimmen (siehe Abbildung 5.31). Abbildg. 5.31
Ergebnisse einer Suche zum Erstellen eines Übermittlungsberichts
Hinter den Kulissen ruft die Exchange-Systemsteuerung das Cmdlet Search-MessageTrackingReport auf und übergibt ihm die vom Benutzer festgelegten Suchparameter. In Kürze werden Sie auch erfahren, wie Sie Suchvorgänge direkt in der Exchange-Verwaltungsshell durchführen. Da die Übermittlungsberichtsuchen von Clientzugriffsservern durchgeführt werden, muss als Erstes der Kontakt mit einem solchen Server am Standort hergestellt werden. Wenn wir an Nachrichten interessiert sind, die von einem bestimmten Postfach gesendet wurden, beginnt der Clientzugriffsserver die Suche auf dem Postfachserver, der zurzeit die Datenbank mit dem entsprechenden Postfach beherbergt. Bei Nachrichten von einem externen Sender beginnt die Suche dagegen auf dem Hub-Transport-Server des Standorts, da dies der erste Eintrittspunkt für die Nachricht ist. Nachdem der Ausgangspunkt für die Suche bestimmt ist, nimmt Exchange Kontakt mit dem Protokollsuchdienst auf dem betreffenden Server auf und fragt ihn anhand der Suchkriterien ab. Wird eine Nachricht gefunden, kann ihr Weg von einem Server zum anderen bis zum Endpunkt verfolgt werden. Das kann entweder die Auslieferung in einem Postfach oder das Verlassen der Organisation über einen Connector sein. Die Clientzugriffsserver fragen dann die Hub-Transport- und Postfachserver ihres Standorts ab, erfassen die Daten und senden sie an den anfordernden Server zurück. Alle während des Suchvorgangs gesammelten Daten werden dann formatiert und dem Benutzer in der Exchange-Systemsteuerung (siehe Abbildung 5.32) oder Exchange-Verwaltungsshell angezeigt. Sie können die Liste der zusammengestellten Übermittlungsberichte durchsuchen und diejenigen auswählen, die Ihnen vielversprechend erscheinen. Wenn Sie auf ein Element der Liste klicken, zeigt die Exchange-Systemsteuerung grundlegende Informationen über die Nachricht an, darunter die komplette Aufstellung sämtlicher Empfänger, die Anzahl der Empfänger und die Anzahl erfolgreicher Zustellvorgänge. Einen vollständigen Bericht über alle bekannten Schritte, die die Nachricht vom Absenden über die Verarbeitung im Transportsystem bis zur endgültigen Auslieferung durchlaufen hat, erhalten Sie, indem Sie auf einen der Empfänger klicken. Der Übermittlungsbericht, den Sie in Abbildung 5.32 sehen, bezieht sich beispielsweise auf eine Nachricht an eine umfangreiche Empfängergruppe mit insgesamt 62 Mitgliedern.
251
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Administratoraufgaben in der Exchange-Systemsteuerung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
TIPP Bei allen Gruppen muss Exchange zuerst die Mitgliedschaft auflösen, bevor eine Nachricht weitergeleitet werden kann. Daher werden in Übermittlungsberichten die Mitgliederlisten aller Gruppen aufgeführt, an die die Nachricht ging, und das gilt auch für dynamische Verteilergruppen. Die Exchange-Systemsteuerung zeigt bis 30 Empfänger auf einmal an. Wenn Sie eine Nachricht also an mehr als 30 Empfänger schicken, müssen Sie die Empfängerliste durchsuchen, um die Person finden, an der Sie interessiert sind, bevor Sie die Einzelheiten des Berichts für dieses Postfach einsehen können. Abbildg. 5.32
Anzeige eines Übermittlungsberichts für eine Nachricht an eine umfangreiche Verteilergruppe
Abbildung 5.33 zeigt, welche Art von Informationen die Supportabteilung gewinnen kann, um Anfragen von Benutzern zu beantworten. In diesem Bericht sehen wir eine Liste der Empfänger einer Nachricht und einen kurzen Überblick über den jeweiligen Zustand der E-Mail. Eine Nachricht wurde innerhalb der Organisation erfolgreich ausgeliefert, die andere jedoch weitergeleitet, da sie an einen externen Empfänger adressiert war. Wenn wir auf den Eintrag für den externen Empfänger klicken, können wir nähere Angaben zu der Übertragung einsehen und bestätigen, dass sie erfolgreich von der eigenen Organisation an die E-Mail-Domäne des Empfängers gesandt wurde. Was anschließend mit der Nachricht geschah, entzieht sich unserer Kenntnis, aber wir können dem Benutzer zumindest versichern, dass von unserer Seite aus alles den richtigen Weg gegangen ist.
252
Administratoraufgaben in der Exchange-Systemsteuerung
Bestätigen der korrekten Weiterleitung einer Nachricht an ihren endgültigen Bestimmungsort
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Abbildg. 5.33
Nachdem Sie sich davon überzeugt haben, dass die Nachricht erfolgreich zugestellt wurde, können Sie auf den in der deutschen Version fälschlicherweise Voicemail aktivieren genannten Link klicken (im Original Email this link, also eigentlich Bericht per E-Mail senden), um eine Kopie an den Benutzer zu schicken, der die Bestätigung der korrekten Auslieferung angefordert hat. Gleichzeitig können Sie das Gefühl der tiefen Befriedigung genießen, da Sie einem Benutzer beweisen konnten, dass das E-Mail-System tatsächlich funktioniert – zumindest in diesem Fall. Durch die Einführung von Übermittlungsberichten in Exchange Server 2010 können Sie jetzt zwei wichtige Fragen klären, die immer wieder von Benutzern gestellt werden: Ist die Nachricht, die ich gesendet habe, wirklich am Ziel angekommen? Warum habe ich eine bestimmte Nachricht nicht erhalten? Wenn Sie ausführlichere Informationen über den Weg gewinnen wollen, den eine Nachricht genommen hat, verwenden Sie den Verfolgungsprotokoll-Explorer aus der Toolbox der Exchange-Verwaltungskonsole (mehr dazu erfahren Sie in Kapitel 15).
253
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Erstellen von Übermittlungsberichten mit der Exchange-Verwaltungsshell Um die Suchvorgänge für Übermittlungsberichte auszuführen, verwendet Exchange hinter den Kulissen das Cmdlet Search-MessageTrackingReport. Um beispielsweise das Postfach von Samantha Smith nach Nachrichten von Tony Redmond zu durchsuchen, wird ein Befehl wie der im Folgenden gezeigte eingesetzt. Anders als bei Protokollsuchen zur Nachrichtenverfolgung können Sie hier keinen Datumsbereich angeben. Suchvorgänge für Übermittlungsberichte umspannen grundsätzlich die vergangenen zwei Wochen. Beachten Sie bei diesem Befehl noch folgende zwei Punkte: Erstens geben Sie mit dem Parameter -ByPassDelegateChecking an, dass Sie nicht Ihr eigenes Postfach durchsuchen. Dabei sind Sie darauf angewiesen, dass Sie die entsprechenden Rollen innehaben, um den Übermittlungsbericht generieren lassen zu können. Zweitens teilen Sie Exchange mit dem Parameter -ResultSize mit, dass Sie alle übereinstimmenden Nachrichten finden möchten. Wenn Sie diesen Parameter weglassen, werden bis zu 1000 Einträge zurückgegeben. Search-MessageTrackingReport –Identity 'Smith, Samantha' –Sender 'Redmond, Tony' –Subject 'Exchange' –ByPassDelegateChecking –ResultSize Unlimited | Select FromDisplayName, Subject, SubmittedDateTime FromDisplayName ---------------------Redmond, Tony Redmond, Tony Redmond, Tony
Subject ---------For you to review (Exchange) Exchange design document Exchange Budget for 2010
SubmittedDateTime -------------------2/10/2010 4:44:48 PM 2/10/2010 11:49:06 AM 2/10/2010 11:15:49 AM
Jeder Benutzer kann einen Suchvorgang in seinem eigenen Postfach durchführen, um einen Übermittlungsbericht zu erstellen. Dazu wird dieselbe Syntax verwendet. Geben Sie den Bezeichner des Postfachs an, lassen Sie aber den Parameter -ByPassDelegateChecking weg. Jede der Nachrichten, die bei der Suche zurückgegeben wird, weist einen eindeutigen Bezeichner in der Eigenschaft MessageTrackingReportId auf. Mithilfe dieses Wertes können Sie die Einzelheiten eines ausgewählten Übermittlungsberichtes abrufen. Das kann etwas kompliziert werden, wenn Sie viele Übermittlungsberichte vorliegen haben. Ganz allgemein gehen Sie aber genauso vor wie im folgenden Beispiel. Dort suchen wir als Erstes nach allen Nachrichten, die ein Benutzer an eine Verteilergruppe gesendet hat. Der dafür erforderliche Befehl sieht dem aus dem vorherigen Beispiel sehr ähnlich, allerdings suchen wir hier nach Nachrichten von einem Postfach an einen bestimmten Empfänger (die SMTP-Adresse der Verteilergruppe): Search-MessageTrackingReport –Identity 'Tony Redmond' –Recipients 'E14InterestList' –ByPassDelegateChecking –ResultSize Unlimited
Exchange ruft alle Übermittlungsberichte ab, die mit den Suchkriterien übereinstimmen. Da wir an Informationen über einen bestimmten Empfänger interessiert sind, müssen wir die Daten über den Empfänger aus sämtlichen Berichten der Liste herausfiltern. Dazu verwenden wir eine ForEachSchleife, die die Ausgabe des Suchvorgangs verarbeitet: ForEach {Get-MessageTrackingLog –Identity $_.MessageTrackingReportId –ByPassDelegateChecking –DetailLevel Verbose –RecipientPathFilter '[email protected]' –ReportTemplate RecipientPath}
254
Dieser Code durchsucht die Übermittlungsberichte auf alle Angaben, die den im Parameter -RecipientPathFilter angegebenen Empfänger betreffen. Auch hier verwenden wir wieder die SMTP-Adresse zur Bezeichnung des Empfängers. Die Ausgabe ist nicht so hübsch wie in der Exchange-Systemsteuerung, aber sie zeigt, was geschehen ist, um die Nachricht zum Empfänger zu bekommen. Weitere Informationen
Weitere Informationen über Übermittlungsberichte finden Sie im Blog der Exchange-Entwicklungsgruppe unter http://mxexchangeteam.com/archive/2010/01/13/453792.aspx. Transport- und Journalregeln
In Exchange Server 2010 SP1 können Sie Transport- und Journalregeln in der Exchange-Systemsteuerung erstellen und bearbeiten. Alle Prädikate, Bedingungen und Ausnahmen für die Regeln, die in der Verwaltungskonsole zur Verfügung stehen, sind auch in der Exchange-Systemsteuerung zugänglich. Manche Benutzer kommen mit der Exchange-Systemsteuerung besser zurecht, und es ist auf jeden Fall ein Vorteil, dass Sie die Exchange-Verwaltungswerkzeuge nicht auf einer Arbeitsstation installieren müssen, nur um Regeln bearbeiten zu können. Das ist vor allem für die Hostingversion von Exchange von Bedeutung, da Administratoren die Regeln für ihre Organisation in einem solchen Umfeld über HTTPS verwalten können. Bei lokalen Bereitstellungen gehe ich davon aus, dass die Transport- und Journalregeln in den meisten Fällen weiterhin in der Verwaltungskonsole bearbeitet werden, weil dies das Werkzeug ist, das schon früher dafür benutzt wurde und weil es besser dokumentiert und den Administratoren, die mit Regeln arbeiten ist, vertrauter ist.
Ausführen der Exchange-Systemsteuerung ohne Exchange-Postfach In Exchange Server 2010 SP1 können Sie auch Konten ohne Exchange-Postfach Zugriff auf die Exchange-Systemsteuerung erteilen. Die Sicherheitsrichtlinien vieler Unternehmen verbieten es, dass Administratoren zur Verwaltung von Computern ihre persönlichen Konten heranziehen (also die Konten, die Sie für den Zugriff auf E-Mails und andere Anwendungen verwenden). Das Ziel besteht darin, in Administratoren ein Bewusstsein dafür zu schaffen, dass sie in Umgebungen mit erhöhten Rechten arbeiten. Sie sollen klar zwischen ihrer Arbeit als Systemadministrator und ihrer Arbeit als normaler Benutzer trennen. In Exchange Server 2010 ist jedes Administratorkonto zwangsweise E-Mail-aktiviert, sodass Unternehmen, die auf die angesprochene Trennung der Aufgabengebiete Wert legen, zwei Konten für Administratoren einrichten müssen, ein normales und eines mit Administratorberechtigungen. In SP1 ist die rollenbasierte Zugriffssteuerung so erweitert worden, dass Administratoren auch nicht E-Mail-aktivierte Konten zu Rollengruppen hinzufügen können. Abbildung 5.34 zeigt, wie das Konto Computeradministrator zum Mitglied einer Rollengruppe gemacht wird. Solche nicht E-Mail-aktivierten Konten können Sie zu einflussreichen Rollengruppen wie Organization Management hinzufügen, aber auch zu eingeschränkteren wie Help Desk.
255
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Administratoraufgaben in der Exchange-Systemsteuerung
Kapitel 5 Abbildg. 5.34
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Aufnehmen eines nicht E-Mail-aktivierten Kontos in eine Rollengruppe
Um die Exchange-Systemsteuerung zu öffnen, meldet sich der Benutzer wie üblich an und gibt den URL https://<Servername>/ECP ein. Da er kein Postfach hat, wird jeder Versuch, OWA zu nutzen, mit dem höflichen Hinweis beendet, dass Exchange kein Postfach für dieses Konto finden kann. Verwalten der Postfacheinstellungen eines anderen Benutzers
Wenn Sie die Postfacheinstellungen eines anderen Benutzers bearbeiten, zeigt die Exchange-Systemsteuerung oben auf der Seite eine Warnleiste an, die auf diesen Umstand aufmerksam macht. Selbstverständlich sollten Administratoren nur so lange am Postfach eines anderen Benutzers angemeldet sein, wie es notwendig ist, um die jeweiligen Aufgaben zu erledigen. Die Warnleiste ist eine deutliche Erinnerung daran, dass der Administrator anschließend das Fenster schließen muss, um die Verbindung der Exchange-Systemsteuerung zu diesem Postfach wieder zu trennen. Damit ein Administrator das Postfach eines anderen Benutzers öffnen kann, muss ihm der Vollzugriff darauf gewährt worden sein. Weitere Informationen darüber erhalten Sie in Kapitel 6.
256
Gruppenverwaltung in der Exchange-Systemsteuerung Verteilergruppen sind schon seit langer Zeit ein grundlegender Bestandteil von Messagingystemen. In Exchange war es üblich, dass Administratoren Gruppen in der jeweiligen Verwaltungskonsole erstellen und bearbeiten konnten (worunter vor allem auch die Handhabung der Mitgliedschaft zählt), während Benutzer über Clients wie Outlook Zugriff auf die Gruppen haben. Der Umgang mit Gruppen beschränkt sich für Benutzer jedoch meistens darauf, Informationen darüber einzusehen, und nur die wenigsten haben irgendeinen Grund, die Gruppenmitgliedschaft zu bearbeiten. Früher wurde dies hauptsächlich in Outlook erledigt. Solange die Gruppe zur selben Domäne gehört wie das Konto, das sie zu bearbeiten versucht, ist Outlook ein brauchbares Hilfsmittel, aber wenn Outlook in einer Umgebung mit mehreren Domänen keine Verbindung mit einem Domänencontroller aufnehmen kann, der eine beschreibbare Kopie der Gruppe enthält, treten Schwierigkeiten auf. Durch die Verlegung des Codes für Gruppenänderungen vom Postfach- zum Clientzugriffsserver wurde dieses Problem in Exchange Server 2010 gelöst (sofern der betreffende Benutzer nomineller Besitzer der Gruppe ist). Da Outlook von Haus aus kein Werkzeug der Verwaltung von Verzeichnissen ist, haben viele Unternehmen eigene Webportale auf der Grundlage von LDAP angelegt, in denen Benutzer Gruppen erstellen, verwalten und löschen können. Solche Portale gibt es häufig in Umgebungen, in denen mehrere E-Mail-Systeme auf ein gemeinsames Verzeichnis zugreifen. Die Exchange-Systemsteuerung bietet zwei verschiedene Ansichten von Gruppen: Benutzer haben Zugriff auf »öffentliche« Gruppen, die sie entweder selbst besitzen (sie sind also registrierte Verwalter der Gruppe) oder deren Mitglied sie sind. Dagegen können Administratoren Gruppen für die gesamte Organisation erstellen, verwalten und löschen. Neben den unterschiedlichen Bezeichnungen in der Exchange-Systemsteuerung gibt es noch einige feine Unterschiede zwischen den beiden Arten. Eine öffentliche Gruppe ist für Endbenutzer sichtbar, es gibt jedoch in Exchange noch andere Gruppen, die die Benutzer nie zu sehen bekommen: 1. Gruppen, die in den Exchange-Adresslisten als ausgeblendet markiert sind und daher nicht in der
globalen Adressliste erscheinen. Diese Gruppen werden Endbenutzern niemals angezeigt. 2. Dynamische Verteilergruppen. Die Mitgliedschaft in diesen Gruppen wird durch die OPATH-Fil-
ter bestimmt, die das Transportsystem jedes Mal auswertet, wenn eine Nachricht an eine solche Gruppe seine Kategorisierungskomponente durchläuft. Endbenutzer können die OPATH-Bilder weder bearbeiten noch einsehen (und wahrscheinlich wollen sie das auch gar nicht), weshalb es nicht sehr sinnvoll wäre, diese Gruppen in der Exchange-Systemsteuerung anzuzeigen. 3. Raumlisten. Dabei handelt es sich um Verteilergruppen, deren Mitglieder sich ausschließlich aus Raumpostfächern zusammensetzen. Sie werden von Outlook 2010 verwendet, damit die Benutzer beim Planen einer Besprechung leichter einen geeigneten Konferenzraum finden können. Da diese Gruppen jedoch nur internen Zwecken dienen, ist es nicht sinnvoll, sie von Benutzern bearbeiten zu lassen, weshalb sie in der Exchange-Systemsteuerung ausgeblendet sind. Raumlisten werden ausführlicher in Kapitel 6 besprochen. In der Exchange-Systemsteuerung können Administratoren nicht mit sämtlichen Gruppen arbeiten, und es stehen ihnen auch nicht sämtliche Eigenschaften zur Verfügung, die es in Exchange sonst für Gruppen gibt. Teilweise liegt das daran, dass sich die Exchange-Systemsteuerung in Exchange Server 2010 SP1 erst im zweiten Entwicklungsstadium befindet und Microsoft noch nicht so viel Zeit und
257
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Gruppenverwaltung in der Exchange-Systemsteuerung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Arbeit dafür aufgewendet hat, sie mit einem ebenso reichhaltigen Satz von Möglichkeiten auszustatten wie die Verwaltungskonsole oder -shell. Allerdings ist die Exchange-Systemsteuerung ohnehin nur als Oberfläche für die häufigsten Verwaltungsaufgaben gedacht, sodass sie auch in naher Zukunft nicht die Möglichkeiten bieten wird, die Exchange-Administratoren für ihre kompliziertesten Aufgaben benötigen. Das Thema Verteilergruppen sehen wir uns im nächsten Kapitel ausführlicher an. Dort erfahren Sie, wie Sie sie in der Exchange-Verwaltungskonsole und -shell bearbeiten können.
Definieren eines Standardspeicherorts für Gruppen und einer Gruppenbenennungsrichtlinie Wenn Sie Administratoren und Benutzern beim Erstellen von Gruppen freie Bahn lassen, werden wahrscheinlich alle möglichen Arten von Gruppennamen verwendet. Es ist jedoch wichtig, dass Gruppen über sinnvolle Namen verfügen, über die die Benutzer schnell die richtige Gruppe finden können, an die Sie eine Nachricht senden müssen. Zwecke, für die Gruppen erstellt werden, können wir kaum einschränken – dies reicht von Gruppen, die die Organisationsstruktur widerspiegeln (die Mitglieder einer Abteilung) über die Benutzer einer Ebene (alle leitenden Angestellten) bis hin zu banalen Gemeinsamkeiten, an denen aber reges Interesse besteht (die Betriebsfußballmannschaft). Allerdings können wir dafür sorgen, dass diese Gruppen einer Namenskonvention folgen, sodass die Benutzer sie in der globalen Adressliste logisch geordnet vorfinden. In Exchange Server 2010 SP1 haben Administratoren die Möglichkeiten, zwei wichtige Aspekte der Gruppenerstellung über die Exchange-Systemsteuerung zu beeinflussen: 쐍 Der Active Directory-Speicherort, an dem neue Gruppen erstellt werden 쐍 Die Benennungsrichtlinie, die auf neue Gruppen angewendet wird Wenn Sie eine neue Gruppe in der Exchange-Sytemsteuerung erstellen, wird sie in der Organisationseinheit Users platziert. Dies hat den Vorteil, dass diese Organisationseinheit garantiert vorhanden ist, da es sich um eine der Standardorganisationseinheiten handelt, die bei der Installation von Active Directory erstellt werden. Nur wenige Administratoren löschen Organisationseinheiten ohne guten Grund, aber wenn Sie Users entfernen, dann können Benutzer in der Exchange-Systemsteuerung keine Gruppen mehr erstellen. Für die Exchange-Verwaltungskonsole und die Verwaltungsshell gilt diese Einschränkung nicht, denn dort können Sie selbst angeben, welche Organisationseinheit Sie verwenden möchten. Insidertipp: Festlegen der Organisationseinheit einer neuen Gruppe
Administratoren haben darum gebeten, festlegen zu können, wo neue Gruppen erstellt werden. In Exchange Server 2010 SP1 können Sie den Speicherort für alle Gruppen angeben, die innerhalb der Organisation angelegt werden. Dazu verwenden Sie einen Befehl wie den folgenden: Set-OrganizationConfig -DistributionGroupDefaultOU 'contoso.com/Exchange Groups'
Solange Sie keinen anderen Ort angeben, erstellt Exchange neue Gruppen weiterhin innerhalb der Organisationseinheit Users.
258
Als Speicherort für neue Gruppen können Sie in der Exchange-Systemsteuerung nur eine einzige Organisationseinheit für die gesamte Organisation angeben. Diese Holzhammerlösung mag in kleinen Umgebungen gut funktionieren, bietet aber für große Organisationen, in denen es angebracht wäre, die Gruppen auf mehrere Organisationseinheiten zu verteilen, nicht genug Flexibilität. Tausende von Gruppen in eine einzige Organisationseinheit zu packen ist nicht unbedingt die bestmögliche Vorgehensweise, aber andererseits ist es durchaus verständlich, dass Microsoft diesen Ansatz gewählt hat, denn um den Benutzern zu erlauben, den Speicherort einer neuen Gruppe selbst festzulegen, müsste ihnen die Organisationsstruktur von Active Directory in der Exchange-Sytemsteuerung zugänglich gemacht werden, und das ist etwas, was niemand ernstlich will. Es bleibt Ihnen also nichts anderes übrig, als die Gruppen, die die Benutzer angelegt haben, anschließend in die geeignetste Organisationseinheit zu verschieben. Durch einen solchen Verschiebevorgang werden die Gruppenbesitzer nicht daran gehindert, die Gruppen zu verwalten, und auch die anderen Benutzer können die Gruppen weiterhin in der globalen Adressliste sehen. Keine Benennungsrichtlinie kann ausnahmslos verhindern, dass Benutzer neuen Gruppen dumme oder unpassende Namen geben. Es wäre unvernünftig zu erwarten, dass eine intelligente Richtlinie Gruppennamen analysieren könnte, um ihren Wert zu bestimmen, denn das würde ein hohes Maß an künstlicher Intelligenz und viel Wissen über die Unternehmenskultur erfordern. Was in einem Unternehmen ein alberner Name wäre, ist in einem anderen möglicherweise die Codebezeichnung für ein neues Spitzenprodukt. Die Gruppenbenennungsrichtlinien in der Exchange-Systemsteuerung dienen zu nichts anderem, als dafür zu sorgen, dass neue Gruppen durch passenden Präfixe oder Suffixe in der globalen Adressliste deutlich zu erkennen sind. Diese Richtlinie gilt für die Gruppen, die Benutzer mithilfe der Exchange-Systemsteuerung anlegen, wird aber nicht auf solche angewendet, die Administratoren in der Exchange-Systemsteuerung oder in der Verwaltungskonsole erstellen. In der Verwaltungsshell können Administratoren den Parameter IgnoreNamingPolicy angeben: New-DistributionGroup –Name 'Senior Executives' –Type Security –IgnoreNamingPolicy –SAMAccountName 'SeniorExec' –OrganizationUnit 'contoso.com/Groups'
HINWEIS Eine Gruppenbenennungsrichtlinie gilt für die gesamte Organisation. Sie können keinen feineren Anwendungsbereich auf der Grundlage der Geschäftsstruktur oder von Filtern festlegen. Um eine Gruppenbenennungsrichtlinie für die Organisation festzulegen, öffnen Sie die ExchangeSystemsteuerung, wählen Meine Organisation verwalten, klicken auf Benutzer und Gruppen und dann auf Verteilergruppen. Die Option zum Erstellen der Benennungsrichtlinie finden Sie unter der Gruppenliste. Wenn bereits eine solche Richtlinie definiert ist, werden Einzelheiten dazu hier angezeigt. Klicken Sie auf Bearbeiten, um die Richtlinie zu ändern. Daraufhin sehen Sie den Bildschirm aus Abbildung 5.35, in dem Sie die gewünschten Präfixe und Suffixe für neue Gruppen auswählen und Wörter angeben können, die nicht in Gruppennamen auftreten dürfen. Das können z.B. jegliche ungeeigneten Wörter sein, die beleidigend wirken oder sich aus anderen Gründen nicht für geschäftliche Zwecke eignen. Als Präfix oder Suffix können Sie einen Text angeben oder ein Active Directory-Attribut auswählen oder beide Varianten in beliebiger Reihenfolge kombinieren. Wenn später ein Benutzer eine Gruppe erstellt, wird der Wert eingefügt, den das Attribut im Konto dieses Benutzers aufweist. Weist das Attribut keinen Wert auf, trägt Exchange dafür auch nichts in den Gruppennamen ein.
259
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Gruppenverwaltung in der Exchange-Systemsteuerung
Kapitel 5 Abbildg. 5.35
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Festlegen einer Gruppenbenennungsrichtlinie für die Organisation
Zur Bezeichnung von Gruppen werden besonders häufig Präfixe verwendet, da dadurch alle Gruppen gesammelt in der globalen Adressliste erscheinen. Die Richtlinie in Abbildung 5.35 verlangt ein Präfix aus drei Teilen: dem Text GRP- gefolgt von einem Active Directory-Attribut, nämlich der Abteilung, und schließlich einem Leerzeichen. Wenn ein Benutzer also als Gruppennamen Benutzer Dublin angibt und sein Abteilungsattribut den Wert Admin aufweist, ergibt sich also der Gruppenname GRP-Admin Benutzer Dublin. Weist das Konto des Benutzers keinen Wert für Abteilung auf, bleibt der Gruppenname GRP- Benutzer Dublin. Wenn Benutzer eine Gruppe erstellt haben, weist die Exchange-Systemsteuerung sie in einem Popupfenster wie dem aus Abbildung 5.36 auf die Auswirkungen der Benennungsrichtlinie hin. Abbildg. 5.36
260
Ein Benutzer wird auf die Auswirkungen der Gruppenbenennungsrichtlinie hingewiesen.
Nachdem Sie die gewünschte Kombination aus Text und Active Directory-Attributen für Ihre Gruppennamen ausgewählt haben, klicken Sie auf Speichern, um die neue Richtlinie in den Organisationseinstellungen zu schreiben. Exchange legt die Gruppenbenennungsrichtlinie in der Eigenschaft DistributionGroupNamingPolicy der Organisationskonfiguration ab. Zugriff auf diese Eigenschaft (im folgenden Listing mit DG... abgekürzt, in der tatsächlichen Ausgabe jedoch als DistributionGroup... genannt) haben Sie mit dem Cmdlet Get-OrganizationConfig: Get-OrganizationConfig | Select Distr* DGDefaultOU -------------------------contoso.com/Exchange Users
DGNameBlockedWordsList ---------------------{Cake, Pizza}
DGNamingPolicy ----------------------------GRP-
TIPP Es ist zwar möglich, die Gruppenbenennungsrichtlinie mit Set-OrganizationConfig zu ändern, aber einfacher und weniger fehleranfällig geht das in der Exchange-Systemsteuerung. Gruppennamen, die aufgrund einer Richtlinie zusammengestellt wurden, sind zumindest in dem Sinne nützlich, dass die Gruppen in der globalen Adressliste gut geordnet sind. Trotzdem muss ein Administrator die Gruppennamen immer noch überprüfen und möglicherweise korrigieren, um ihnen einen gefälligeren Klang zu geben. Wenn Ihre Benutzer jedoch daran gewöhnt sind, mit computergeeigneten, aber nicht unbedingt benutzerfreundlichen Gruppennamen umzugehen, brauchen Sie womöglich nichts mehr zu ändern.
Erstellen neuer Gruppen Das Erstellen von Gruppen läuft in der Exchange-Systemsteuerung ziemlich einfach ab. Abbildung 5.37 zeigt die grundlegenden Elemente einer Gruppe, die gerade mit Mitgliedern gefüllt wird. Dabei können Sie folgende Informationen eingeben: 쐍 Gruppenname (erforderlich) Eine organisationsweite Gruppenbenennungsrichtlinie kann ein Präfix oder Suffix beisteuern, dass das neue Objekt als Gruppe kennzeichnet. Der Name ist beschreibend und sollte deutlich machen, wer die Nachrichten erhält, die an die Gruppe gesendet werden. Gruppennamen müssen eindeutig sein. 쐍 Gruppenalias (erforderlich) Ein Alias zur Bezeichnung der Gruppe. Es wird empfohlen, die Aliase sämtlicher Objekte eindeutig zu halten, allerdings ist es nicht zwingend erforderlich, dass auch Gruppenaliase eindeutig sind. 쐍 Beschreibung Beschreibender Text, der den Zweck der neuen Gruppe angibt. Diese Erläuterungen werden den Benutzern angezeigt, wenn sie sich in der globalen Adressliste die Gruppeneigenschaften ansehen. 쐍 Besitz Eine Liste der Besitzer (mindestens einer), die die Eigenschaften der Gruppe verwalten dürfen, vor allem auch die Mitgliedschaft. Die Exchange-Systemsteuerung fügt den Benutzer, der die Gruppe erstellt hat, automatisch als Besitzer hinzu. 쐍 Mitgliedschaft Eine Liste der E-Mail-aktivierten Objekte, die an die Gruppe gesendete Nachrichten erhalten. Die Verwalter der Gruppe werden als Mitglieder hinzugefügt.
261
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Gruppenverwaltung in der Exchange-Systemsteuerung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
쐍 Mitgliedschaftsgenehmigung Eine Reihe von Eigenschaften, die steuern, einer Gruppe ohne Eingreifen eines Administrators beitreten oder sie verlassen zu können: 왍 Die Eigenschaft MemberJoinRestriction gibt an, wie ein Endbenutzer einer Gruppe beitreten kann. 왍 Die Eigenschaft MemberDepartRestriction gibt an, wie ein Endbenutzer eine Gruppe verlassen kann. Abbildg. 5.37
Erstellen einer neuen Gruppe in der Exchange-Systemsteuerung
HINWEIS Dieselben Werte werden auch verwendet, um Anforderungen zum Beitreten zu einer Gruppe oder zum Verlassen zu steuern: 쐍 Open (Offen) Ein Endbenutzer kann der Gruppe jederzeit beitreten oder sie verlassen, ohne dazu eine besondere Erlaubnis zu benötigen.
쐍 Closed (Geschlossen) Die Mitgliedschaft ist gesteuert, sodass kein Benutzer der Gruppe von sich aus beitreten oder sie selbstständig verlassen kann. Dies muss durch den Administrator erfolgen. 쐍 ApprovalRequired (Besitzergenehmigung) Ein Endbenutzer kann einen Antrag auf Mitgliedschaft in der Gruppe stellen. Diese Anforderung leitet Exchange an die Gruppenverwalter weiter, von denen einer zustimmen muss, um den Benutzer in die Gruppe aufzunehmen.
Nachdem Sie eine Gruppe erstellt haben, können Sie sie in der Exchange-Systemsteuerung oder der Exchange-Verwaltungsshell um erweiterte Elemente wie E-Mail-Infos ergänzen. 262
Erstellen von Sicherheitsgruppen in der ExchangeSystemsteuerung Der Standardtyp für neue Grupen ist eine E-Mail-aktivierte, universelle Verteilergruppe. Wenn Sie eine E-Mail-aktivierte Sicherheitsgruppe benötigen (die einen Sicherheitsprinzipal enthalten darf), müssen Sie dies beim Erstellen der Gruppe angeben (siehe Abbildung 5.38). Dies ist eine in Exchange Server 2010 SP1 neu eingeführte Funktion, und nur Administratoren können Sicherheitsgruppen anlegen (wenn Benutzer, die keine Administratoren sind, Gruppen erstellen, ist dieses Kontrollkästchen deaktiviert). Es ist nicht möglich, dass Benutzer einer Sicherheitsgruppe ohne Eingreifen eines Administrators beitreten oder sie von sich aus verlassen, und diese Einschränkung ist nur logisch. Eine Sicherheitsgruppe ist schließlich ein Sicherheitsprinzipal, der den Zugriff auf eine Ressource beschränken soll. Wenn sich Benutzer unbeaufsichtigt selbst Zugang zu einem solchen Sicherheitsprinzipal gewähren könnten, wäre das eine alles andere als sichere Situation. Abbildg. 5.38
Erstellen einer Sicherheitsgruppe
Da dem Cmdlet Set-DistributionGroup die erforderlichen Fähigkeiten fehlen, können Sie eine einmal erstellte E-Mail-aktivierte Verteilergruppe mit keinem der Verwaltungswerkzeuge von Exchange nachträglich zu einer Sicherheitsgruppe machen. Dies ist nur möglich, indem Sie die Eigenschaften der Gruppe in Active Directory-Benutzer und -Computer ändern.
263
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Gruppenverwaltung in der Exchange-Systemsteuerung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Benutzer und Gruppen Die vielleicht interessanteste Verwaltungsfunktion, die die Exchange-Systemsteuerung für viele Unternehmen bietet, ist die Tatsache, dass Benutzer darüber erkennen können, welchen Gruppen sie angehören und welche Gruppen es noch gibt, sowie die Möglichkeit, Gruppen selbstständig und ohne Eingreifen eines Administrators beizutreten oder sie zu verlassen. In der Exchange-Systemsteuerung können die Benutzer Folgendes tun: 쐍 Die öffentlichen Gruppen einsehen, zu denen sie gehören 쐍 Die Mitgliedschaft der öffentlichen Gruppen ändern, für die sie als Verwalter registriert sind 쐍 Gruppen in ihrem eigenen Besitz löschen 쐍 Neue Gruppen erstellen 쐍 Offenen Gruppen anderer Besitzer beitreten und sie wieder verlassen Wie alles andere in der Exchange-Systemsteuerung hängt auch die Fähigkeit der Benutzer, die Aufgaben auszuführen, von der standardmäßigen Rollenzuweisungsrichtlinie ab (siehe Abbildung 5.39). Jedes Exchange-Postfach verfügt über eine Rollenzuweisungsrichtlinie, die regelt, welche Cmdlets zur Arbeit mit Objekten wie Gruppen der Benutzer verwenden darf. Zu Anfang weist jedes Postfach nur die Standardrichtlinie auf (Default Role Assignment Policy), aber Sie können nach Bedarf neue Richtlinien erstellen und den Postfächern zuweisen. Abbildg. 5.39
264
Die standardmäßige Rollenzuweisungsrichtlinie
Wenn die Exchange-Systemsteuerung gestartet wird, untersucht sie die dem Postfach zugewiesene Rollenzuweisungsrichtlinie, um herauszufinden, welche Benutzeroberfläche angezeigt werden muss. Abbildung 5.39 zeigt die Rollenzuweisungen in der Standardrichtlinie, die festlegen, was der Benutzer mit Gruppen tun kann. Wie Sie sehen, gehört zu den in dieser Richtlinie erfassten Rollen auch MyDistributionGroupMembership, sodass die Exchange-Systemsteuerung dem Benutzer ermöglicht, ihre eigene Mitgliedschaft in Gruppen einzusehen und zu ändern. Das Kontrollkästchen für MyDistributionGroups ist dagegen nicht aktiviert, weshalb diese Rolle den Benutzern nicht über die Richtlinie zugewiesen wird und die Exchange-Systemsteuerung auch keine Benutzeroberflächenelemente zum Erstellen neuer Gruppen anzeigt. Wenn Benutzer sich den Abschnitt Gruppen der Exchange-Systemsteuerung ansehen, sehen sie aufgrund dieser Richtlinie nur eine Liste von Gruppen mit der Überschrift Öffentliche Gruppen, denen ich zugehöre (siehe Abbildung 5.40). Das sind die Gruppen, in denen der Benutzer Mitglied ist. Gehört er zu sehr vielen Gruppen, kann er über die Funktion Suchgruppen (im Original Search groups, also eigentlich Gruppen suchen) diejenige finden, mit der er arbeiten möchte. Abbildg. 5.40
Anzeige öffentlicher Gruppen in der Exchange-Systemsteuerung
In Abbildung 5.41 sehen Sie, wie die Eigenschaften einer Gruppe in der Exchange-Systemsteuerung angezeigt werden. Die Mitgliedschaft unterliegt der Kontrolle durch den Administrator. Das können Sie daran sehen, dass Beitrittsanfragen automatisch abgelehnt werden. Die Eigenschaft MemberJoin-
265
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Gruppenverwaltung in der Exchange-Systemsteuerung
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Restriction steht also auf Closed. Um diese Eigenschaft und die für das Verlassen der Gruppe zu ändern, können Sie die Eigenschaften der Gruppe in der Verwaltungskonsole ändern (auf der Registerkarte Mitgliedschaftsgenehmigung) oder mithilfe des Cmdlets Set-DistributionGroup: Set-DistributionGroup –Identity 'SharePoint Interest List' –MemberJoinRestriction 'ApprovalRequired' –MemberDepartRestriction 'Open' Abbildg. 5.41
Anzeigen der Gruppeneigenschaften
Das Prinzip selbstwartender Gruppen, die sich auf diese Eigenschaften stützen, wird ausführlicher in Kapitel 6 erläutert.
Zulassen der Gruppenerstellung durch Benutzer Wenn Sie den Benutzern das Erstellen von Gruppen erlauben, indem Sie die Rolle MyDistributionGroups in die Richtlinie Default Role Assignnment Policy aufnehmen, zeigt sich sofort ein Unterschied, wenn Benutzer in der Exchange-Systemsteuerung den Abschnitt Gruppen öffnen. Wie Sie in Abbildung 5.42 sehen, zeigt die Exchange-Systemsteuerung dank der neuen Rolle eine weitere Liste von Gruppen unter der Überschrift Öffentliche Gruppen, die ich besitze an. Dazu gehören auch Steuerelemente, um neue Gruppen anzulegen und die vorhandenen zu ändern. Die in dieser Liste aufgeführten Gruppen sind diejenigen, für die der Benutzer als Verwalter registriert ist. Um herauszufinden, wer der Verwalter einer Gruppe ist, sehen Sie sich deren Eigenschaften in der Exchange-Verwaltungskonsole an oder verwenden das Cmdlet Get-DistributionGroup.
266
Gruppenverwaltung in der Exchange-Systemsteuerung
Darstellung der Exchange-Systemsteuerung nach Zuweisung der Rolle MyDistributionGroups
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Abbildg. 5.42
Mit dem folgenden Beispielcode können wir ermitteln, wer als Verwalter der Gruppe CEO Staff fungiert. Wie das Ergebnis zeigt, sind es zwei Benutzer, und wenn diese beiden Benutzer die ExchangeSystemsteuerung verwenden, sehen sie in der Liste der Gruppen, die sie besitzen, auch CEO Staff. Get-DistributionGroup –Identity 'CEO Staff' | Format-Table ManagedBy ManagedBy --------------{contoso.com/Exchange Users/Redmond, Tony, contoso.com/Exchange Users/CEOSupport Admin}
Wenn Ihnen diese Konstellation nicht behagt, können Sie die Richtlinie wieder ändern und die Fähigkeit zum Erstellen neuer Gruppen daraus entfernen.
Folgen der Gruppenerstellung durch Benutzer Bevor Sie Benutzern das Erstellen von Gruppen erlauben, müssen Sie sich über die Konsequenzen einer solchen Entscheidung klar werden: 쐍 Gewöhnlich erstellen Benutzer neue Gruppen ohne rechte Planung und häufig vor allem auch, ohne zunächst nachzusehen, ob es schon eine vergleichbare Gruppe gibt. Außerdem ist es unwahrscheinlich, dass die Benutzer einer Namenskonvention folgen. Das kann dazu führen, dass schließlich doppelte Gruppen überall über die globale Adressliste verteilt sind. In Exchange Server 2010 SP1 haben Sie die Möglichkeit, eine Benenungsrichtlinie für Gruppen vorzusehen.
267
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
쐍 Benutzer werden hin und wieder die Mitgliedschaft einer Gruppe ändern, ansonsten aber nicht viel zur Gruppenverwaltung beitragen. Wenn Benutzer die Organisation verlassen, bleiben verwaiste Gruppen zurück. Das führt zu vielen veralteten und unerwünschten Zombiegruppen, die in der globalen Adressliste verbleiben, bis ein Administrator sie löscht. 쐍 Benutzer können zwar E-Mail-aktivierte universelle Gruppen erstellen, aber keine E-Mail-aktivierten universellen Sicherheitsgruppen. Wenn ein Benutzer so etwas benötigt, kann er zunächst eine normale Gruppe erstellen und dann den Administrator bitten, daraus nachträglich eine Sicherheitsgruppe zu machen. 쐍 Beachten Sie auch den Active Directory-Speicherort für die von Benutzern erstellten Gruppen. Weitere Informationen darüber, wie Sie eine standardmäßige Organisationseinheit für neue Gruppen festlegen, finden Sie im Abschnitt »Definieren eines Standardspeicherorts für Gruppen und einer Gruppenbenennungsrichtlinie« weiter vorn in diesem Kapitel. Je größer die Organisation, umso schwerwiegender werden diese Probleme. Wenn Sie den Benutzern in einer kleinen Organisation erlauben, ihre eigenen Gruppen anzulegen, können Sie sich sehr leicht immer darüber informiert halten, was in der globalen Adressliste vor sich geht. Etwas ganz anderes ist es jedoch, wenn Sie 100.000 Benutzern gestatten, Gruppen selbst zu erstellen, und sie schließlich mit 250.000 zusätzlichen Gruppen in der Adressliste zu kämpfen haben. Die Benutzer werden dann Probleme haben, Empfänger in der Adressliste zu finden, und auch der Download des Offlineadressbuchs dauert länger und länger. Noch schlimmer aber ist die Vorstellung, regelmäßig Zehntausende von unerwünschten oder unbenutzten Gruppen ausmisten zu müssen.
Verwalten, aber nicht erstellen! Die standardmäßige Rollenzuweisungsrichtlinie von Exchange Server 2010 greift nicht fein genug, um Benutzer daran zu hindern, selbst Gruppen zu erstellen, und ihnen gleichzeitig zu erlauben, ihre eigenen Gruppen zu verwalten. Allerdings können Sie eine eigene angepasste Verwaltungsrolle erstellen und zur Standardrichtlinie hinzufügen, um die bisherige Rolle für die Gruppenverwaltung zu ersetzen. Die neue Verwaltungsrolle basiert auf der alten, allerdings entfernen wir daraus die Cmdlets, mit deren Hilfe wir neue Gruppen erstellen können. Was bleibt, sind die Cmdlets, die den Benutzern ermöglichen, vorhandene eigene Gruppen zu ändern. Um eine neue Verwaltungsrolle zu erstellen und in die Standardzuweisungsrichtlinie aufzunehmen, gehen Sie wie folgt vor: 1. Definieren Sie eine neue Verwaltungsrolle auf der Grundlage von MyDistributionGroups. New-ManagementRole –Name MyGroupsMaintain –Parent MyDistributionGroups 2. Entfernen Sie das Cmdlet New-DistributionGroup aus der neuen Verwaltungsrolle. Die anderen
Cmdlets für Verteilergruppen (z.B. Add-DistributionGroupMember, mit dem Sie einen Empfänger zu einer Gruppe hinzufügen) verbleiben in der Rolle. Remove-ManagementRoleEntry MyGroupsMaintain\New-DistributionGroup –Confirm:$False 3. Entfernen Sie die Rolle MyDistributionGroups von der Richtlinie Default Role Assignment Policy.
Der erste Befehl speichert einen Zeiger auf die unerwünschte Rollenzuweisung in einer Variable, der zweite entfernt die Zuweisung aus der Richtlinie. $OldAssignment = Get-ManagementRoleAssignment –RoleAssignee 'Default Role Assignment Policy' –Role 'MyDistributionGroups' Remove-ManagementRoleAssignment $OldAssignment –Confirm:$False 268
Gruppenverwaltung in der Exchange-Systemsteuerung
nimmt sie den Platz von MyDistributionGroups auf, mit dem Unterschied, dass die Benutzer darüber keinen Zugriff auf das Cmdlet New-DistributionGroup haben und somit auch keine neuen Gruppen erstellen können. New-ManagementRoleAssignment –Name 'MyGroupsMaintain-Default Role Assignment Policy' –Role MyGroupsMaintain –Policy 'Default Role Assignment Policy' 5. Abschließend überprüfen wir, ob die neue Rolle in die Standardzuweisungsrichtlinie aufgenom-
men wurde. Wie Sie sehen, ist MyDistributionGroups nicht mehr in der Richtlinie enthalten. Get-ManagementRoleAssignment –RoleAssignee 'Default Role Assignment Policy' | Select Name, Role Name ------MyDistributionGroupMembership-Default Role Assign... MyBaseOptions-Default Role Assignment Policy MyContactInformation-Default Role Assignment Policy MyTextMessaging-Default Role Assignment Policy MyVoiceMail-Default Role Assignment Policy MyProfileInformation-Default Role Assignment Policy MyGroupsMaintain-Default Role Assignment Policy
Role ---MyDistributionGroupMembership MyBaseOptions MyContactInformation MyTextMessaging MyVoiceMail MyProfileInformation MyGroupsMaintain
Nachdem wir uns vergewissert haben, dass die richtigen Rollenzuweisungen in Kraft sind, können wir die Exchange-Systemsteuerung öffnen, um nachzusehen, ob die Änderungen an der Standardzuweisungsrichtlinie auch ihre Auswirkungen zeigen. Abbildung 5.43 zeigt den Zustand, den wir erwarten dürfen. Der Benutzer kann alle Gruppen sehen, die er besitzt, und die Gruppenmitgliedschaft verwalten, Angaben zu Gruppen ändern und sogar Gruppen löschen. Wenn Sie den Bildschirm aber mit dem vor der Richtlinienänderung vergleichen (siehe Abbildung 5.42), wird Ihnen auffallen, dass die Option Neu nicht mehr zur Verfügung steht – der Benutzer kann also keine neuen Gruppen mehr erstellen. Vielleicht möchten Sie auch die Möglichkeit entfernen, Gruppen löschen zu können, um zu verhindern, dass die Benutzer fatale Fehler begehen und Sie die dankenswerte Aufgabe erhalten, eine umfangreiche Verteilergruppe rekonstruieren zu müssen. Entfernen Sie dazu einfach das Cmdlet Remode-DistributionGroup auf die gleiche Weise wie New-DistributionGroup (in Schritt 2 der Anleitung). Weitere Informationen
Wenn Sie nicht selbst an den Mechanismen von Rollen, Zuweisungen und Richtlinien herumbasteln möchten, können Sie auch ein Skript nutzen, das Microsoft veröffentlicht hat und das die Arbeit für Sie übernimmt. Sie finden es im Exchange-Blog auf http://msexchangeteam.com/. Suchen Sie dort nach ManageGroupManagementRole.ps1, laden Sie es herunter und führen Sie es aus, um die notwendigen Anpassungen vorzunehmen.
269
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
4. Nehmen Sie die neue angepasste Verwaltungsrolle in die Standardzuweisungsrichtlinie auf. Dort
Kapitel 5 Abbildg. 5.43
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Die Auswirkungen einer geänderten Rollenzuweisungsrichtlinie
Diagnosemöglichkeiten für Exchange Server-Computer Es gab schon immer die Möglichkeit, für die verschiedenen Komponenten auf einem Exchange ServerComputer Diagnosemöglichkeiten mit unterschiedlicher Ausführlichkeit einzurichten. Von Exchange Server 4.0 bis Exchange Server 2003 haben Sie dazu in der Verwaltungskonsole die gewünschte Komponente ausgewählt (z.B. MSExchange ActiveSync) und dann den angestrebten Detaillierungsgrad angegeben. Sobald Sie einen neuen Grad auswählen, gibt Exchange beim Schreiben der Ereignisse in das Anwendungsprotokoll entsprechend mehr oder weniger Einzelheiten aus. Dieser Mechanismus funktionierte sehr gut, bis Exchange Server 2007 herauskam und die Administratoren feststellen mussten, dass die neue Verwaltungskonsole dieser Version keine grafische Benutzeroberfläche für Diagnoseeinstellungen mehr aufwies, sodass sie den Detaillierungsgrad über PowerShell einstellen mussten. Um z.B. eine ausführliche Diagnoseprotokollierung mit dem Grad High für Speicher öffentlicher Ordner einzurichten, mussten Sie Folgendes eingeben: Set-EventLogLevel "MSExchangeIS\9001 Public\General" –Level High
Mit Exchange Server 2007 SP2 hat Microsoft das Problem gelöst und der Exchange-Verwaltungskonsole eine Möglichkeit hinzugefügt, um die Diagnoseeinstellungen als Servereigenschaften bearbeiten zu können (siehe Abbildung 5.44). Auch in Exchange Server 2010 bestehen noch beide Möglichkeiten.
270
Diagnosemöglichkeiten für Exchange Server-Computer
Einrichten der Diagnoseprotokollierung auf dem Server
Exchange-Verwaltungskonsole und ExchangeSystemsteuerung
Abbildg. 5.44
Wie Tabelle 5.4 zeigt, gibt es in Exchange fünf Protokolliergrade, die jeweils bestimmen, bis zu welcher Ebene Ereignisse von der Anwendung aufgezeichnet werden. Kritische Ereignisse und solche mit der Ebene 0 werden stets in das Ereignisprotokoll geschrieben, Ereignisse einer höheren Ebene nur dann, wenn der entsprechende Protokolliergrad gewählt ist. Tabelle 5.4
Protokolliergrade in Exchange Server 2010 Protokolliergrad
Beschreibung
Experte
Äußerst ausführlich: Exchange zeichnet praktisch alles auf, was es tut.
Hoch
Sehr ausführlich: Exchange protokolliert alle Ereignisse der Ebenen 5 und geringer.
Medium
Ziemlich ausführlich: Exchange protokolliert alle Ereignisse der Ebenen 3 und geringer.
Niedrig
Mäßig ausführlich: Exchange protokolliert alle Ereignisse der Ebenen 1 und geringer.
Niedrigster
Nur kritische Ereignisse und Fehler der Ebene 0 werden erfasst. Dies ist der Standardprotokolliergrad für alle Exchange-Dienste.
VORSICHT Seien Sie vorsichtig, wenn Sie den Protokollierungsgrad auf Ausführlich oder sogar noch höher setzen. Exchange schreibt dann fröhlich eine Vielzahl von Ereignissen in das Protokoll und stellt Ihnen ungeheure Mengen an Diagnoseinformationen zur Verfügung, doch dabei laufen Sie Gefahr, den Wald vor Bäumen nicht mehr zu sehen, sodass Ihnen wichtige Informationen in dem Wust an Daten entgehen. Haben Sie den Protollierungsgrad erhöht, um einem Problem auf zu Spur zu kommen, sollten Sie ihn nach Abschluss der Fehlerbehebung wieder auf Niedrigster zurücksetzen, um zu verhindern, dass das Anwendungsprotokoll mit einer überbordenden Anzahl von Ereignissen vollgestopft wird.
271
Kapitel 5
Exchange-Verwaltungskonsole und Exchange-Systemsteuerung
Mit Get-EventLogLevel können Sie den Protokolliergrad ermitteln, der zurzeit für einen Server eingestellt ist. Bei diesem Cmdlet können Sie keine Filter angeben. Um zu überprüfen, ob die Grade für alle Komponenten richtig eingestellt sind, ist es am einfachsten, die Ausgabe in eine Textdatei umzuleiten, die sich leichter untersuchen lässt: Get-EventLogLevel –Server ExServer1 > C:\Temp\EventLevels.txt
Was wird verwaltet? Wir haben jetzt alle Exchange-Verwaltungswerkzeuge kennengelernt – die Exchange-Verwaltungsshell, die Exchange-Verwaltungskonsole und die Exchange-Systemsteuerung – und uns auch einige Einzelheiten der Objekte angesehen, die Sie darin verwalten können. Jetzt ist es Zeit, uns um die Objekte zu kümmern, die ein Messagingsystem erst zum Leben erwecken, nämlich die Postfächer.
272
Verwalten von E-Mailaktivierten Empfängern
Kapitel 6
Verwalten von E-Mailaktivierten Empfängern
In diesem Kapitel: Grundlegende Überlegungen
274
Namenskonventionen für Postfächer
275
Erstellen von neuen Postfächern
277
Entfernen und Deaktivieren von Postfächern
302
E-Mail-Adressrichtlinien
307
Discoverysuchpostfächer
316
Einrichten von Postfachberechtigungen
319
Verteilergruppen
327
Nachverfolgung der Gruppenbenutzung
340
Dynamische Verteilergruppen
340
Moderierte Empfänger
349
E-Mail-aktivierte Kontakte
356
Ressourcenpostfächer
358
Daten, überall Daten
369
273
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Nun, da wir die zur Verwaltung von Exchange verfügbaren Werkzeuge gemeistert haben, können wir damit beginnen, einige Postfächer, Gruppen und Kontakte einzurichten, und uns überlegen, wie wir diese Objekte verwalten. In Microsoft Exchange Server 2010 wurde eine Reihe von Änderungen vorgenommen, zum Beispiel in Bereichen wie moderierte Empfänger, doch es gibt noch einige grundlegende Themen, mit denen wir uns zuerst befassen müssen. Beginnen wir zunächst mit dem Benennen von Postfächern, damit Administratoren wie Benutzer die gewünschten Kommunikationspartner finden können.
Grundlegende Überlegungen Die erfolgreiche Bereitstellung von Exchange hängt nicht von der Anzahl der Postfächer im Unternehmen ab. Bevor Sie nun auf die Schnelle irgendwelche Postfächer anlegen, sollten Sie einige Richtlinien dafür festlegen, ohne dass Postfächer erstellt und wieder entfernt werden müssen. In der Praxis haben sich bei der Postfachverwaltung die folgenden wichtigen Punkte bestätigt: 쐍 Anwendungen benötigen keine Postfächer. Einige Administratoren halten es für eine gute Idee, Anwendungen, die Nachrichten erstellen und senden müssen – für gewöhnlich, indem sie eine Textnachricht an einen SMTP-Server senden –, Postfächer zuzuweisen. Anwendungen benötigen für diesen Zweck keine Postfächer, da sie Nachrichten erstellen und an einen SMTP-Server senden können, der die Nachrichtenübermittlung von anonymen Absendern unterstützt. Die einfachste Methode, die E-Mail-Übermittlung für Anwendungen zu unterstützen, ist die Verwendung des PICKUP-Verzeichnisses (siehe Kapitel 13, »Das Exchange-Transportsystem«). Wenn Sie dennoch Postfächer für Anwendungen anlegen, dann stellen Sie sicher, dass der Zugriff auf die damit verbundenen Konten eingeschränkt ist. 쐍 Die Tatsache, dass es verschiedene Arten von Postfächern gibt, hat einen Grund. Auch wenn die Verwendung »normaler« Postfächer für Ressourcen (wie Räume und Geräte) auf den ersten Blick akzeptabel zu sein scheint, verfolgt Exchange mit der Differenzierung zwischen verschiedenen Postfachtypen einen Zweck. Ressourcenpostfächer sind an deaktivierte Windows-Konten gebunden, Benutzerpostfächer hingegen nicht. Wenn Sie normale Postfächer für Ressourcen verwenden, erzeugen Sie eine potenzielle Sicherheitslücke. Achten deshalb darauf, beim Anlegen eines Postfachs immer den richtigen Postfachtyp zuzuweisen. 쐍 Postfächer sollten nicht ewig aufrechterhalten werden. Auch wenn einige Inhalte im Postfach eines scheidenden Mitarbeiters von gewissem Interesse sein können, so schwindet dieses jedoch mit der Zeit, und die meisten Inhalte solcher Postfächer sind nach drei Monaten ohnehin nutzlos. Sicher gibt es auch hier Ausnahmen, etwa bei Postfächern von Führungskräften, deren Inhalte zum Beispiel im Falle einer Klage zur Informationsbeschaffung für ein Gerichtsverfahren relevant sein könnten. Nichtsdestoweniger sollten Sie Richtlinien darüber vereinbaren, wann Postfächer gelöscht werden können, und sicherstellen, dass alte Postfächer und alte Windows-Konten nicht über ihr »Verfallsdatum« hinaus bestehen. HINWEIS Alte Postfächer und Konten stellen ein Sicherheitsrisiko dar, das von Hackern ausgenutzt werden kann. Manche Unternehmen verschieben daher alle Postfächer ehemaliger Mitarbeiter in eine gesonderte Datenbank, sodass sie eine Gruppe bilden und sich somit von aktiven Postfächern unterscheiden. 쐍 Prüfen Sie die Postfächer regelmäßig. Schließlich möchten Sie nicht mehr für Clientzugriffslizenzen an Microsoft zahlen als nötig. Clientzugriffslizenzen werden anhand der Anzahl von Postfächern berechnet, woraus folgt, dass auch unnötige Postfächer Geld kosten. Sie sollten daher die 274
im Unternehmen bestehenden Postfächer wenigstens alle sechs Monate prüfen und alle unbenutzten entfernen. Es ist ein Leichtes, eine Liste aller Postfächer in eine Datenbank zu übernehmen und sich anzeigen zu lassen, wann der jeweils letzte Zugriff erfolgt ist, um mögliche unbenutzte Postfächer aufzuspüren. So können Sie sich zum Beispiel mit dem folgenden Befehl Einzelheiten aller Benutzerpostfächer in eine Datenbank holen und nach dem jeweils letzten Zugriffsdatum ordnen lassen. Auch andere Informationen, die auf ein unbenutztes Postfach hinweisen, etwa die Anzahl der Objekte im Postfach, werden dabei berücksichtigt. Der folgende Bericht zeigt, dass etwa zwei Monate zwischen dem aktuellsten und dem ältesten Zugriff liegen. Es liegt nahe, dass die Postfächer, auf die innerhalb von zwei Monaten nicht zugegriffen wurde, nicht mehr benötigt werden. Get-Mailbox –Database DB1 –RecipientTypeDetails UserMailbox | Get-MailboxStatistics | Sort-Object LastLogonTime | Format-Table DisplayName, LastLogonTime, ItemCount, TotalItemSize DisplayName LastLogonTime ItemCount ----------------------------------Holm, Michael 5/20/2010 12:08:43 PM 81 Chen, Jacky 5/21/2010 10:46:29 AM 33 Palma, Tude 5/26/2010 4:23:28 PM 34 Ruth, Andy (Sales VP) 5/26/2010 5:24:37 PM 1089 Smith, Samantha 5/26/2010 5:40:33 PM 57
TotalItemSize ------------170.3 MB (178,611,937 bytes) 161 KB (164,888 bytes) 41.07 MB (43,064,720 bytes) 145.9 MB (153,019,826 bytes) 60.79 MB (63,744,292 bytes)
Mit diesen Punkten im Hinterkopf können wir nun damit beginnen, einige Postfächer anzulegen und zu verwalten.
Namenskonventionen für Postfächer Auch wenn die E-Mail-Adressrichtlinien es Ihnen erlauben, verschiedene Muster für SMTP-Adressen zu definieren und anzuwenden, bietet Exchange Server 2010 keine Richtlinien, um das Erstellen von Anzeigenamen zu steuern. Dieser Anzeigename ist das Attribut, das Exchange zum Sortieren von Objekten in der globalen Adressliste und in der Exchange-Verwaltungskonsole sowie für Empfänger und Autoren in Nachrichtenheadern verwendet. Tabelle 6.1 listet die Attribute für die verschiedenen von Exchange genutzten Namen oder Namenskomponenten auf, die im Verzeichnisdienst Active Directory gespeichert werden. Das Standardmuster für Anzeigenamen lautet % g%s – mit anderen Worten, erster Name
275
Verwalten von E-Mailaktivierten Empfängern
Namenskonventionen für Postfächer
Kapitel 6 Tabelle 6.1
Verwalten von E-Mail-aktivierten Empfängern
Postfachattribute und -namen Attribute
Bedeutung
Alias
Eindeutiger Name für das Objekt
Name
Vollständiger Name des Objekts, der sich aus dem Vor- und Nachnamen zusammensetzt
FirstName (Vorname)
Vorname des Benutzers
LastName (Nachname)
Nachname des Benutzers
DisplayName (Anzeigename)
Name, der zum Sortieren der globalen Adressliste und für andere Anzeigezwecke verwendet wird (z.B. in der Verwaltungskonsole und in Nachrichtenheadern)
DistinguishedName (definierter Name)
Name, der zur Identifizierung des Objekts in Active Directory dient
PrimarySMTPAddress (Erste SMTP-Adresse)
Erste SMTP-E-Mail-Adresse (häufig nach dem Schema Vorname.Nachname@Domäne)
UPN (User Principal Name)
Benutzerprinzipalname, also der Name eines Benutzers im E-Mail-Format, der zur Anmeldung an einem Windows-Server dient; entspricht für gewöhnlich der ersten SMTP-E-Mail-Adresse.
Die Verwaltungskonsole berücksichtigt auch landesspezifische Aspekte; so werden zum Beispiel namensbezogene Felder neu angeordnet, um sprachenspezifische Namenskonventionen widerzuspiegeln. Welche Felder beim Erstellen neuer Objekte angezeigt und in welcher Reihenfolge sie angeordnet werden, hängt von der gewählten Sprache ab. So zeigt die Verwaltungskonsole beispielsweise in der französischen Version kein Feld für Namensinitialen an. Wenn Sie dagegen Benutzer in der chinesischen Version anlegen, werden die Felder in der Reihenfolge Nachname, Initialen und Vorname angezeigt, also genau der Reihenfolge, die auch einige Unternehmen, deren gesamte Verwaltung auf Englisch basiert, bevorzugen. Sie können diese Reihenfolge jedoch nicht für andere Landesversionen erzwingen, da die Anordnung in der Verwaltungskonsole fest programmiert ist. Insidertipp: Anwenden einer anderen Namenskonvention
Auch wenn die Reihenfolge für die Namenskonventionen in der Verwaltungskonsole fest programmiert ist, ist es möglich, eine Konvention zu ändern. Um eine andere Namenskonvention anzuwenden, gehen Sie folgendermaßen vor: 쐍 Lassen Sie die Verwaltungskonsole die Postfächer und Kontakte wie gewohnt anlegen und ändern Sie anschließend den Anzeigenamen. 쐍 Erstellen Sie Postfächer und andere E-Mail-aktivierte Empfänger mithilfe von Shellskripts, sodass Sie die volle Kontrolle über das Format der Anzeigenamen haben. Möglicherweise möchten Sie bestimmte Postfächer nicht nach der Konvention »Nachname, Vorname« benennen, zum Beispiel, wenn es sich um Discoverysuchpostfächer handelt. Solche Fälle können dann durch eine Ausnahmeregelung abgedeckt werden. Abbildung 6.1 zeigt eine globale Adressliste, deren Postfächer nach der Konvention »Nachname, Vorname« benannt sind. Wie Sie sehen, weisen einige der Einträge zusätzliche Informationen auf, um Personen gleichen Namens besser voneinander unterscheiden zu können. Es ist üblich, Abteilungsnamen, Wohnorte oder Berufsbezeichnungen hinzuzufügen, um den Benutzern das Auffinden der gewünschten Person zu erleichtern.
276
Erstellen von neuen Postfächern
Eine vorbildlich geordnete globale Adressliste
Verwalten von E-Mailaktivierten Empfängern
Abbildg. 6.1
Einige Unternehmen bevorzugen eine gesonderte Namenskonvention für Verteilergruppen, sodass die Benutzer sofort wissen, ob sie eine Nachricht an eine Gruppe von Personen oder an einen einzelnen Empfänger schicken. Die E-Mail-Info-Funktion von Exchange Server 2010 hilft hier weiter. Sie kann einen Benutzer entweder darauf hinweisen, dass er gerade dabei ist, eine Nachricht an eine große Gruppe von Empfängern zu senden, oder einen maßgeschneiderten Tipp anzeigen, um den Zweck der jeweiligen Gruppe zu erläutern. Eine Lösung besteht darin, den Gruppennamen bestimmte Buchstaben als Präfix voranzustellen. So könnten Sie zum Beispiel »VG:« als Präfix verwenden, sodass die Namen Ihrer Gruppen dann beispielsweise »VG: Marketing-Abteilung« oder »VG: IT-Abteilung« lauten. Der Vorteil dieser Vorgehensweise liegt darin, dass sämtliche Gruppen gesammelt an einer Stelle in der globalen Adressliste zu finden sind. Andere führen diesen Ansatz noch weiter und nutzen als Präfix »##«, sodass alle Gruppen am Anfang der globalen Adressliste platziert werden. Das Ergebnis sind Bezeichnungen wie »## Marketing-Abteilung«. Die zweite Methode funktioniert zwar ebenfalls, ist aber nicht so benutzerfreundlich wie die erste.
Erstellen von neuen Postfächern Ein neues Postfach mit der Exchange-Verwaltungskonsole zu erstellen, ist einfach. Klicken Sie auf die Option Neues Postfach, und die Verwaltungskonsole startet den entsprechenden Assistenten, um die zur Erstellung des Postfachs benötigten Informationen zu sammeln. Abbildung 6.2 zeigt die Startseite des Assistenten. Exchange Server 2010 bietet die folgenden Postfachtypen: 쐍 Benutzerpostfächer Standardpostfächer von Exchange mit vollem Funktionsumfang. Die Exchange-Verwaltungskonsole kann ein Postfach in einer beliebigen Datenbank des Unternehmens erstellen. 쐍 Raumpostfächer Postfächer für Konferenzräume, sodass Benutzer diese Räume per Kalenderanforderung für Besprechungen buchen können.
277
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
쐍 Ressourcenpostfächer Postfächer für Geräte (wie Projektoren, Kommunikationsgeräte oder Whiteboards), die ggf. von Benutzern für eine Besprechung reserviert werden müssen. 쐍 Verknüpfte Postfächer Postfächer, die in einer separaten, vertrauenswürdigen Gesamtstruktur mit einem Benutzerkonto verknüpft sind. Mit dem Assistenten zum Erstellen eines Postfachs können Sie jeden der genannten Postfachtypen anlegen. Abbildg. 6.2
Anlegen eines neuen Postfachs mithilfe des entsprechenden Assistenten in der Exchange-Verwaltungskonsole
Am häufigsten begegnen Administratoren bei der Einrichtung von Postfächern mithilfe des Assistenten der Exchange-Verwaltungskonsole folgenden Problemen: 쐍 Es kann kein eindeutiger Alias oder kein eindeutiger UPN bereitgestellt werden. Der Assistent prüft erst beim Versuch, das neue Postfach zu erstellen, ob die dem Alias oder dem UPN zugewiesenen Werte bereits durch ein bestehendes Active Directory-Objekt genutzt werden, und zeigt dann eine Fehlermeldung ähnlich der in Abbildung 6.3 gezeigten an. Die Verwaltungskonsolen in Exchange Server 2003 und 2007 füllen das Alias-Feld beide mit einem vorgeschlagenen Wert, der sich aus einem Hintergrundaufruf von Active Directory ergibt. Aus irgendeinem Grund zwingt das von Exchange Server 2010 verwendete Sicherheitsmodul Microsoft dazu, diesen Aufruf zu entfernen, sodass der Administrator einen eindeutigen Alias festlegen muss. Das Problem lässt sich jedoch leicht lösen – blättern Sie einfach im Assistenten zurück und geben Sie einen eindeutigen Alias ein. Dennoch kann dies frustrierend sein, da es unmöglich ist, zu wissen, welcher Alias eindeutig ist, wenn man nicht vorher in Active Directory nachgesehen hat. Möglicherweise verfügt Ihr Unternehmen über Richtlinien, die das Erstellen neuer Aliase regeln und Ihnen helfen, den richtigen Wert zu finden.
278
Erstellen von neuen Postfächern
Fehler beim Erstellen eines Postfachs: doppelter Benutzerprinzipalname entdeckt.
Verwalten von E-Mailaktivierten Empfängern
Abbildg. 6.3
Das Erstellen von Postfächern im Rahmen der Unternehmensrichtlinien
Bevor wir uns im Detail ansehen, wie Sie mithilfe des Assistenten ein neues Postfach anlegen, ist es wichtig, sich vor Augen zu führen, dass dies nur ein kleiner Teil des gesamten Vorgangs zum Einstellen eines neuen Mitarbeiters darstellt, der unter anderem die folgenden Aufgaben umfasst: 쐍 Bereitstellung personaltechnischer Voraussetzungen Zuweisung einer Mitarbeiternummer, Eintragung im Personalverwaltungssystem, Erstellung eines Namensschilds, Anmeldung für eine Unternehmenskreditkarte usw. 쐍 Bereitstellung der IT-Anbindung Ermöglichen des Zugangs zu Betriebssystemen (möglicherweise werden neben Windows noch andere Betriebssysteme im Unternehmen genutzt), Anwendungen wie E-Mail und Webspeicher oder Dokumentverwaltungssysteme; Zuweisung mobiler Geräte und Bereitstellung von Sicherheitstokens oder -schlüsseln für den VPN-Zugriff auf das Firmennetzwerk über das Internet. 쐍 Bereitstellung des Arbeitsplatzes Zuweisung eines Büroarbeitsplatzes sowie benötigter Arbeitsmittel einschließlich PC und Drucker. Viele Großunternehmen verfügen über ausgefeilte Workflow-Anwendungen, die zahlreiche dieser Aufgaben übernehmen. Ein ähnlicher Arbeitsablauf existiert in der Regel, um beim Ausscheiden eines Mitarbeiters sämtliche Bereitstellungen wieder aufzuheben. Da die Einstellung eines neuen Mitarbeiters so komplex sein und die Arbeit mit vielen verschiedenen Anwendungen erfordern kann, ist es sinnvoll, sich zu überlegen, wie sich das Erstellen eines Exchange-Postfachs am besten in diesen Vorgang aufnehmen lässt. Soll beispielsweise ein Schritt in den Workflow eingebunden werden, in dem automatisch ein Postfach erstellt wird, dessen Merkmale (wie Kontingent, Personalarchiv und Speicherungsrichtlinien) je nach Status und Personalnummer des Mitarbeiters voreingestellt werden, oder soll eine Anforderung erstellt und per E-Mail an die Support-Abteilung gesendet werden? 279
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
HINWEIS Dieses Problem existiert in Exchange Server 2010 SP1 nicht, da Microsoft hier Code zum Assistenten für das Erstellen eines neuen Postfachs hinzugefügt hat, der bewirkt, dass basierend auf den Namenseigenschaften des Postfachs ein eindeutiger Alias errechnet wird. Falls gewünscht, können Sie diesen automatisch generierten Alias jedoch auch anpassen, um bestimmten Namenskonventionen gerecht zu werden. 쐍 Es kann kein Kennwort für ein neues Konto bereitgestellt werden, das den Anforderungen von Windows gerecht wird. Wenn Sie ein Kennwort eingeben, das die Windows-Richtlinien nicht erfüllt (zum Beispiel eines, das den Namen des Benutzers enthält), ist der Assistent beim Versuch, ein neues Postfach anzulegen, nicht in der Lage, ein neues Konto zu erstellen. 쐍 Unbeabsichtigte Auswahl von Funktionen, die eine Enterprise-Lizenz erfordern. Funktionen wie Richtlinien für verwaltete Ordner und Archivpostfächer erhöhen die Anzahl von EnterpriseLizenzen, die Ihr Unternehmen benötigt. Zwar weist der Assistent darauf hin, dass diese Funktionen Enterprise-Lizenzen erfordern, doch übersieht man diese Hinweise leicht (oder versteht möglicherweise nicht, welche Konsequenzen die Wahl der Funktionen hat, denn nicht jedem Administrator ist der Kostenunterschied zwischen Standard- und Enterprise-Lizenzen klar). Im Gegensatz zu den anderen Fällen verhindert die Auswahl einer Funktion, die eine Enterprise-Lizenz erfordert, nicht das Erstellen des Postfachs. Der Assistent ist eine prima Sache, solange Sie nur eine Hand voll Postfächer zu erstellen haben. Sobald sich die Anzahl aber erhöht, ist es an der Zeit, die Feinheiten der verwendeten Cmdlets zu meistern, besonders, wenn Sie die Postfacherstellung in einen anderen Vorgang einbinden müssen, etwa in den des Personalwesens zur Einführung eines neuen Mitarbeiters in die Firma. Wie in vielen Fällen bildet der Code, den die Exchange-Verwaltungskonsole zum Ausführen einer Aktion bereitstellt, eine gute Grundlage. Im Folgenden sehen Sie den Code, der nötig ist, um ein neues Postfach mit einem neuen Windows-Konto zu erstellen. Tabelle 6.2 zeigt die gängigsten Parameter für genau diesen Zweck. Wie Sie später noch sehen werden, nutzen andere Postfachtypen wie Raum- oder Gerätepostfächer andere Parameter: New-Mailbox -Name 'Eoin P. Redmond' -Alias 'epr' -UserPrincipalName '[email protected]' -SamAccountName 'epr' -FirstName 'Eoin' -Initials 'P' -LastName 'Redmond' -Password 'System.Security.SecureString' -ResetPasswordOnNextLogon $True -Database 'DB1'
Da dieser Code aus der Exchange-Verwaltungskonsole kopiert wurde, enthält er 'System.Security. SecureString' als Kennwortwert. Wenn Sie ein Skript zum Erstellen neuer Postfächer erstellen, können Sie das Cmdlet ConvertTo-SecureString verwenden, um einen vorgegebenen Wert in eine passende sichere Zeichenfolge für das Kennwort umzuwandeln: -Password (ConvertTo-SecureString 'Exchange2010!' –AsPlainText –Force)
Das Anlegen eines Postfachs ist nur der Anfang des Vorgangs, ein voll funktionsfähiges Postfach einzurichten. Der hier gezeigte Code nutzt beispielsweise nicht die Möglichkeiten, Postfachkontingente zuzuweisen, eine Moderation für das Postfach einzurichten, ActiveSync- oder OWA-Richtlinien anzuwenden oder Archivpostfächer zu erstellen. All diese Einstellungen lassen sich entweder direkt beim Erstellen des neuen Postfachs mithilfe des Cmdlets New-Mailbox oder direkt danach mithilfe von Set-Mailbox aktivieren. Darüber hinaus bietet Exchange Server 2010 eine Reihe neuer Cmdlets zum Ändern von Einstellungen wie Sprache und regionale Optionen sowie für automatische Antworten und Kalenderoptionen. Lesen Sie dazu den Abschnitt »Ändern von Postfacheinstellungen« weiter hinten im Kapitel, um mehr zu diesem Thema zu erfahren.
280
Erstellen von neuen Postfächern
Eigenschaften zum Erstellen eines neuen Postfachs mit New-Mailbox. Eigenschaft
Verwendung
Erforderlich
Name
Name des Postfachs
N
Alias
Eindeutiger Bezeichner für das Postfach. Dieser Wert darf keine Sonderzeichen enthalten.
J
UserPrincipalName (UPN, Benutzerprinzipalname)
Ein Bezeichner für das Postfach im SMTP-Format
J
FirstName (Vorname)
Vorname des Postfachbesitzers
N
Initials (Initialen)
Initialen des Postfachbesitzers
N
LastName (Nachname)
Nachname des Postfachbesitzers
N
DisplayName (Anzeigename)
Anzeigename für das Postfach in der globalen Adressliste und im Nachrichtenheader. Wird er weggelassen, erstellt Exchange einen Anzeigenamen anhand der für die Verwaltungskonsole eingestellten Sprache. So stellen englische Sprachvarianten Anzeigenamen aus dem Vor- und Nachnamen zusammen.
N
Password (Kennwort)
Kennwort für das Windows-Konto. Wird es weggelassen, fragt Exchange nach einem Kennwort für das neue Konto.
J
ResetPasswordOnNextLogon
Gibt an, ob der Benutzer veranlasst werden soll, sein Windows-Kennwort bei der nächsten Anmeldung zurückzusetzen
J
Database (Datenbank)
Datenbank, in der das neue Postfach erstellt wird
N
OrganizationalUnit (Organisationseinheit)
Active Directory-Organisationseinheit, in der das neue Windows-Konto erstellt wird. Wird diese Eigenschaft weggelassen, verwendet Exchange die Standardorganisationseinheit.
N
ActiveSyncMailboxPolicy
Der Name der ActiveSync-Richtlinie, die auf das neue Postfach angewendet werden soll. Wird er weggelassen, wendet Exchange die ActiveSync-Standardrichtlinie an.
N
Archive (Archiv)
Zeigt an, ob ein Archivpostfach erstellt wird
N
ManagesFolderMailboxPolicy
Der Name der Richtlinie für verwaltete Ordner, die auf das Postfach angewendet werden soll
N
Soll ein Postfach für ein bereits bestehendes Windows-Konto erstellt werden, verwendet die ExchangeVerwaltungskonsole das Cmdlet Enable-Mailbox, um ein neues Postfach anzulegen und es dem gewählten Windows-Konto zuzuordnen. Der Code ist in diesem Fall sehr viel einfacher, da das Windows-Konto bereits über mehrere festgelegte Eigenschaften verfügt, die Sie ansonsten selbst bereitstellen müssten. Alles, was Sie für das neue Postfach angeben müssen, ist eine neue Identität, ein Alias und eine Zieldatenbank: Enable-Mailbox -Identity 'contoso.com/Exchange Mailboxes/Akers,Kim' -Alias 'KAkers' -Database 'DB2'
Sobald das neue Postfach angelegt ist, wendet Exchange die zugehörige E-Mail-Adressrichtlinie an, um eine passende E-Mail-Adresse für das Postfach zu generieren, und aktualisiert Active Directory mit diesem Wert. Einzelheiten darüber, wie Sie E-Mail-Adressrichtlinien festlegen, finden Sie im Abschnitt »E-Mail-Adressrichtlinien« weiter hinten im Kapitel.
281
Verwalten von E-Mailaktivierten Empfängern
Tabelle 6.2
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Abschließen der Postfacheinrichtung Sie haben jetzt ein neues Postfach, doch ist es alles andere als vollständig. Zahlreiche verschiedene Operationen können bei einem neuen Postfach durchgeführt werden, bevor Sie es endgültig fertig an den Besitzer übergeben. Zu den möglichen Aufgaben zählen folgende: 쐍 Hinzufügen des neuen Postfachs zu Verteilergruppen. Zum Beispiel: Add-DistributionGroupMember -Identity 'Sales Executives' -Member 'Akers, Kim' -BypassSecurityGroupManagerCheck
쐍 Aktualisieren der Postfacheigenschaften, sodass das neue Postfach mithilfe der Abfragen gefunden werden kann, die zur Festlegung der Mitgliedschaft in dynamischen Verteilergruppen notwendig sind. Im folgenden Beispiel weisen wir einem der benutzerdefinierten Attribute einen Wert zu: Set-Mailbox -CustomAttribute1 'Sales' -Identity 'Akers, Kim'
쐍 Festlegen weiterer Postfacheigenschaften, die über den Assistenten für das Erstellen eines neuen Postfachs nicht zugänglich sind. Viele der Eigenschaften, die man mit einem Postfach verbindet, werden mithilfe des Cmdlets Set-User festgelegt statt mit Set-Mailbox, da sie nicht zum Postfach, sondern zum grundlegenden Active Directory-Benutzerobjekt gehören. Im folgenden Beispiel aktualisieren wir eine Reihe von Eigenschaften mithilfe von Set-User, um die Verzeichnisinformationen für das neue Postfach bereitzustellen. Einige andere Beispiele für Postfacheigenschaften (Spracheinstellungen usw.), die Sie ggf. ändern möchten, behandeln wir weiter hinten im Kapitel. Set-User -City 'Sydney' -Company 'Contoso' -CountryOrRegion 'Australia' -Department 'Sales' -Manager 'Redmond, Tony' -Office 'Sydney' -Phone '8170-19944' -Title 'VP APJ' -Identity ' Akers, Kim'
쐍 Einrichten eines persönlichen Archivs für das Postfach (dies kann gleich beim Erstellen geschehen, doch einige Administratoren ziehen es vor, damit zu warten, bis der Benutzer ein Archiv anfordert). Enable-Mailbox –Archive –Identity 'Akers, Kim'
Es kann eine Weile dauern, bis alle Eigenschaften eines neuen Postfachs eingerichtet sind. Aus diesem Grund nutzen viele Administratoren ein Skript zum Erstellen neuer Postfächer und verwenden den Assistenten nur in Einzelfällen. Solche Skripts können sehr einfach sein (eine Ansammlung von einzeiligen Verwaltungsshell-Befehlen), aber auch sehr vielschichtig sein, indem sie z.B. von Identitätsbereitstellungs- oder Personalverwaltungssystemen mit Mitarbeiterinformationen gespeist werden und die nötigen Befehle ausgeben, um ein funktionstüchtiges Postfach zu erstellen.
Erstellen neuer Raum- und Gerätepostfächer Der Code zum Erstellen eines neuen Raumpostfachs ist der gleiche wie der für die Erstellung eines Benutzerpostfachs, außer dass wir den Parameter -Room verwenden, um es als Raumpostfach zu kennzeichnen: New-Mailbox -Name 'Conference Room A' -Alias 'Confa' -OrganizationalUnit 'contoso.com/Exchange Mailboxes' -UserPrincipalName '[email protected]'
282
-SamAccountName 'Confa' -FirstName 'Conference' -Initials '' -LastName 'Room A' -Database 'DB1' –Room
Auch der Code für neue Gerätepostfächer ist der gleiche, erfordert den Parameter -Equipment, um das Postfach als Gerätepostfach auszuweisen: New-Mailbox -Name 'Projector Conference A' -Alias 'ProjConfA' -OrganizationalUnit 'contoso.com/Exchange Mailboxes' -UserPrincipalName '[email protected]' -SamAccountName 'ProjConfA' -FirstName 'Projector' -Initials '' -LastName 'Conference A' -Database 'DB1' –Equipment
Raum- und Gerätepostfächer werden mit deaktivierten Windows-Konten erstellt. Es empfiehlt sich, diese Konten in einer eigenen Organisationseinheit unterzubringen. Auch ist es eine Überlegung wert, diese Postfächer ihrer eigenen Datenbank zuzuweisen, um sie klar von den regulären Postfächern abzugrenzen.
Postfachbereitstellungs-Agent und Datenbankzuweisung Exchange Server 2010 umfasst einen Postfachbereitstellungs-Agent, der dazu dient, neue Postfächer zu den verfügbaren Datenbanken zuzuweisen. Der Postfachbereitstellungs-Agent gehört zum Standardsatz der in Exchange Server 2010 verfügbaren Cmdlet-Erweiterungs-Agents. Seine Aufgabe besteht darin, nach neuen Postfacherstellungsanforderungen zu suchen, die keine Datenbank für das neue Postfach angeben. Sobald er eine solche Anforderung entdeckt, sucht er nach intakten Datenbanken innerhalb desselben Active Directory-Standorts, in dem sich auch der Server oder die Arbeitsstation mit den Exchange-Verwaltungstools befindet, und überspringt dabei alle Datenbanken, die ausdrücklich von der Bereitstellung ausgeschlossen (dauerhaft oder vorübergehend) sind. Als intakt gilt eine Datenbank, die online und betriebsfähig ist. Der Postfachbereitstellungs-Agent ist nicht sonderlich intelligent und wählt daher die Datenbank für das neue Postfach zufällig aus dem Pool an verfügbaren Datenbanken aus. VORSICHT Falls Sie ein Postfach für ein Konto erstellen möchten, das zu einem Remotestandort gehört, müssen Sie zuvor eine Verbindung zu einem Server des gewünschten Standorts herstellen, denn ansonsten wird das Postfach in einer Datenbank des lokalen Standorts erstellt. Der Postfachbereitstellungs-Agent berücksichtigt bei der Auswahl einer Zieldatenbank nicht die aktuelle Anzahl von Postfächern, die sich bereits darin befinden. Wenn Sie Exchange erlauben, verfügbaren Datenbanken Postfächer zuzuweisen, werden Sie die Belastung vermutlich von Zeit zu Zeit neu verteilen müssen, indem Sie die Postfächer verschieben. Wie viele Postfächer den einzelnen Datenbanken zugewiesen sind, können Sie mithilfe eines einfachen Verwaltungsshellbefehls herausfinden. Allerdings kann die Ausführung in einem großen Unternehmen einige Zeit in Anspruch nehmen, da zum Zählen der Postfächer jede Datenbank angesprochen werden muss: Get-Mailbox | Group-Object database | Sort Count -Descending | Format-Table Count, Name –AutoSize Name ----
Count -----
283
Verwalten von E-Mailaktivierten Empfängern
Erstellen von neuen Postfächern
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
DB3 IT Department DB1 DB2 VIP Data Sales
252 222 217 210 117 101
Anhand dieser Information können Sie einige Postfächer auf Datenbanken umverteilen, die nicht so stark ausgelastet sind, oder einige Datenbanken von der automatischen Bereitstellung ausnehmen, sodass sie keine neuen Postfächer akzeptieren. Wenn Sie die Exchange-Verwaltungskonsole zum Erstellen eines neuen Postfachs nutzen und Exchange erlauben, eine Datenbank für das neue Postfach zu wählen (siehe Abbildung 6.4), dann zeigt sich die Tatsache, dass das neue Postfach auf einem Remoteserver erstellt wird, lediglich in einer kurzen Verzögerung, die bei einem lokalen Postfach nicht auftreten würde. Es gibt zwei Optionen, um zu steuern, welche Datenbanken für die automatische Bereitstellung verfügbar sind. Die eine (IsExcludedFromProvisioning) dient dazu, eine Datenbank dauerhaft von der Bereitstellung auszuschließen, die andere (IsSuspendedFromProvisioning) nimmt eine Datenbank vorübergehend von der Bereitstellung aus. Wird eine dieser beiden Optionen auf True gesetzt, so wird die Datenbank von der Bereitstellung ausgeschlossen und verbleibt in diesem Status, bis die jeweilige Option wieder auf False gesetzt wird. Beide Optionen haben den praktischen Effekt, dass Exchange daran gehindert wird, eine Datenbank für die Bereitstellung zu nutzen. Der Unterschied zwischen ihnen besteht in der Dauer der Bereitstellungsblockierung. »Excluded« (ausgeschlossen) bedeutet: »Verwende diese Datenbank nie für die Bereitstellung«, während »suspended« (gesperrt) bedeutet: »Verwende diese Datenbank so lange nicht für die Bereitstellung, bis ich dir etwas anderes sage.« Sehen wir uns an, welche Umstände es erfordern können, dass eine Datenbank von der Bereitstellung ausgeschlossen wird. Abbildg. 6.4
Festlegen einer Datenbank für ein neues Postfach
Wahrscheinlich möchten Sie eine Datenbank dauerhaft von der Postfachbereitstellung ausschließen, wenn sie für einen bestimmten Zweck reserviert ist. So möchten Sie beispielsweise eine Datenbank mit höheren Kontingenten einer bestimmten Klasse von Benutzern, die einer bestimmten Abteilung angehören, zuordnen. Vielleicht beschließen Sie aber auch, neue Postfächer bestimmten Datenbanken manuell zuzuweisen, anstatt die automatische Postfachbereitstellung zu nutzen. In beiden Fällen können Sie einen Befehl wie den folgenden nutzen, um die Datenbank von der Bereitstellung auszuschließen:
284
Erstellen von neuen Postfächern
Ein vorübergehender Ausschluss ist angezeigt, wenn einer Datenbank für einen gewissen Zeitraum keine neuen Postfächer zugewiesen werden sollen, z.B. weil sie aus Platzgründen auf eine neue Festplatte verschoben werden soll und Sie ihr erst wieder weitere Postfächer zuweisen möchten, wenn mehr Speicher verfügbar ist. In solchen Fällen können Sie die Bereitstellung mit einem Befehl wie dem folgenden vorübergehend blockieren: Set-MailboxDatabase –Identity 'DB1' –IsSuspendedFromProvisioning $True
Sobald Sie der Datenbank dann wieder automatisch neue Postfächer zuweisen lassen möchten, setzen Sie die Option zurück auf $False. Set-MailboxDatabase –Identity 'DB1' –IsSuspendedFromProvisioning $False
Im Gegensatz zu anderen in Active Directory gespeicherten Eigenschaften wird das Ändern einer Option zum Aus- oder Einschließen einer Datenbank für die automatische Bereitstellung sofort vom Postfachbereitstellungs-Agent registriert und umgesetzt. Mit der Exchange-Verwaltungskonsole erstellte Datenbanken für neue Postfächer werden standardmäßig für die automatische Bereitstellung zugeteilt. Datenbanken, die für die automatische Bereitstellung verfügbar gemacht werden, sind damit gleichzeitig mögliche Zieldatenbanken für das Verschieben von Postfächern und das Einrichten persönlicher Archive, sofern die Ziele für diese Operationen nicht durch Administratoren festgelegt werden. Mit anderen Worten, wenn Sie beim Verschieben eines Postfachs oder beim Erstellen eines persönlichen Archivs keine Zieldatenbank festlegen, wählt der Postfachbereitstellungs-Agent ein Ziel aus der Liste der verfügbaren Datenbanken. Tests in SP1 ergaben, dass Exchange in der Regel sowohl für das Hauptpostfach als auch das Archiv dieselbe Datenbank wählt, selbst wenn keine bestimmte Zieldatenbank festgelegt wird. Auch wenn ein Postfach mit Archiv mithilfe des Befehls New-MoveRequest verschoben wird, bringt der Postfachreplikationsdienst das Primär- und das Archivpostfach zusammen in einer automatisch gewählten Zieldatenbank unter. Wenn Sie eine neue Datenbank über die Exchange-Verwaltungskonsole erstellen, können Sie festlegen, dass sie dauerhaft oder vorübergehend von der Bereitstellung ausgeschlossen wird, indem Sie beim Ausführen des Cmdlets New-MailboxDatabase die weiter oben beschriebenen Optionen setzen. Anders als die manuelle Auswahl durch einen Administrator bringt das automatische Zuweisen von Postfächern zu Datenbanken unter anderem das Problem mit sich, dass der Besitzer eines neuen Postfachs oft nicht weiß, an wen er sich notfalls wenden kann. Jahrelang war es gängige Praxis, die Postfächer von Mitarbeitern derselben Arbeitsgruppe zusammen in derselben Datenbank zu speichern, um so die für den Nachrichtenaustausch zwischen Arbeitsgruppenmitgliedern nötigen Systemressourcen so gering wie möglich zu halten. Durch Fortschritte in der Technologie hat dieses Prinzip an Bedeutung verloren. Exchange Server 2010 hat die Einzelinstanzspeicherung in Datenbanken eliminiert, während Exchange Server 2007 sämtliche Nachrichten durch einen Hub-Transport-Server zwingt, selbst wenn sie für Empfänger in derselben Datenbank bestimmt sind. Dennoch ist es sinnvoll, die Postfachplatzierung als mehr zu betrachten als nur eine einfache Verteilung über verfügbare Datenbanken hinweg, und nicht sämtliche Entscheidungen einem Computer zu überlassen, sondern auch Administratoren eine gewisse Kontrolle darüber zu lassen.
285
Verwalten von E-Mailaktivierten Empfängern
Set-MailboxDatabase –Identity 'VIP Mailboxes' –IsExcludedFromProvisioning $True
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Fehlerbehebung: Es wurde kein gültiges Postfach gefunden und die Postfacherstellung ist fehlgeschlagen
Sie können auch versehentlich zu weit gehen und alle verfügbaren Datenbanken von der automatischen Bereitstellung ausschließen. In diesem Fall wird die Fehlermeldung aus Abbildung 6.5 angezeigt, sobald der Postfachbereitstellungs-Agent nach Datenbanken sucht und feststellt, dass keine verfügbar ist. Abbildg. 6.5
Keine Datenbanken verfügbar
Die Lösung hierfür ist einfach: Setzen Sie entweder die entsprechende Option für eine Datenbank zurück, um sie wieder verfügbar zu machen, oder wechseln Sie zurück zur Seite Postfacheinstellungen und wählen Sie eine Datenbank aus. Durch das explizite Auswählen einer Datenbank teilen Sie dem Postfachbereitstellungs-Agent mit, dass er keine Auswahl vornehmen muss, wodurch die Fehlermeldung vermieden wird.
Sprachen und Ordner Sobald das Sprachpaket auf dem Clientzugriffsserver installiert ist, können die Benutzer OWA in ihrer bevorzugten Sprache ausführen, indem sie die entsprechende Option in den Postfacheinstellungen wählen. Administratoren hingegen können die Exchange-Verwaltungskonsole nur in der Sprache ausführen, die bei der Windows-Installation verwendet wurde. Es ist wichtig, dass Sie das Sprachpaket auf allen Clientzugriffsservern installieren, sodass die Benutzer auf ihre bevorzugte Sprache zurückgreifen können. Es ist verwirrend für einen Benutzer, wenn er bei dem einem Clientzugriffsserver Deutsch nutzen kann, jedoch bei einem anderen Clientzugriffsserver desselben Standorts (vielleicht
286
sogar einen innerhalb desselben Arrays) OWA nur in Englisch vorfindet, was der Standardeinstellung entspricht, wenn kein Sprachpaket verfügbar ist. Ein weiterer wichtiger Punkt ist, dass das OWAAnmeldefenster die auf dem Server installierte Standardsprache verwendet. Selbst dann, wenn ein Benutzer Deutsch als bevorzugte Sprache gewählt hat, sieht er ein Anmeldefenster in Englisch, sofern nicht Deutsch als Standardsprache auf dem Server installiert ist oder als unterstützte Browsersprache vom Benutzer festgelegt wurde. Beim Erstellen eines Postfachs werden eine Reihe von Eigenschaften in Active Directory festgelegt, die notwendig sind, um das Konto für E-Mail zu aktivieren. Exchange erstellt das eigentliche Postfach erst dann in der zugewiesenen Datenbank, wenn der Benutzer sich zum ersten Mal bei dem Postfach anmeldet oder wenn eine Nachricht an das neue Postfach gesendet werden muss. An diesem Punkt erstellt Exchange die verschiedenen besonderen Ordner, die es benötigt, um E-Mails zu verarbeiten, wie »Posteingang«, »Gesendete Objekte« und »Gelöschte Objekte«. Wählt der Benutzer eine andere Sprache für OWA, stellt das Sprachpaket die übersetzten Zeichenfolgen bereit, um diese Ordner in OWA anzuzeigen. Die Inhalte der Ordner bleiben davon jedoch unberührt. Wählt ein Benutzer zum Beispiel Polnisch als bevorzugte Sprache, so trägt der Posteingang den Titel »Skrzynka odbiorcza,«, »Gesendete Objekte« wird zu »Elementy wyslane« und »Gelöschte Objekte« zu »Elementy usunite,«, während die Ordnernamen bei einem Wechsel zu Portugiesisch »A Receber«, »Itens Enviados« und »Itens Eliminados« lauten. Der einzige Ordner, der einem Sprachenwechsel hartnäckig widersteht, ist der Suchordner »Ungelesene E-Mails«. Wenn Sie beispielsweise unter Französisch beginnen, behält er ab sofort immer den Namen »Courrier non lu« bei, egal, wie viele Sprachen Sie beim Starten von OWA verwenden. Verwendet ein Postfach OWA in mehreren Sprachen, so vermerkt Exchange dies in den Spracheigenschaften des Postfachs: Get-Mailbox –Identity JSmith | Select Languages Languages --------
Die Sprachen werden nach dem jeweiligen Zugriff auf der linken Seite der Liste ergänzt, sodass hier ersichtlich wird, dass Portugiesisch zuletzt von diesem Postfach verwendet wurde und zuvor die Sprachen Polnisch, Englisch (UK), Englisch (Irland), Französisch und Englisch (US). Die ursprüngliche Sprache für ein Postfach ergibt sich aus dem installierten Gebietsschema des Servers, auf dem das Postfach erstellt wurde. Falls diese Einstellung inkorrekt ist oder Sie eine andere Sprache vorziehen, können Sie dies mithilfe des Cmdlets Set-Mailbox entsprechend ändern. Um zum Beispiel das Postfach eines Benutzers mit dem Namen Geert Camelbeke auf Niederländisch umzustellen, geben Sie Folgendes ein: Set-Mailbox –Identity'Camelbeke, Geert' –Languages 'nl-NL'
Outlook und andere Clients, die lokal auf PCs laufen, übernehmen die Regions- und Zeitzoneneinstellungen vom PC und verwenden sie zur Darstellung von Elementen der Benutzerschnittstelle, etwa für die Zeitzone eines Kalenders. Abbildung 6.6 zeigt OWA in Polnisch und die Exchange-Systemsteuerung in Niederländisch. Das Layout der Clientschnittstellen entspricht dem der deutschen Version, nur die Sprachzeichenfolgen, Variablen und lokalen Einstellungen, wie etwa das Datumsformat, unterscheiden sich.
287
Verwalten von E-Mailaktivierten Empfängern
Erstellen von neuen Postfächern
Kapitel 6 Abbildg. 6.6
Verwalten von E-Mail-aktivierten Empfängern
OWA und die Exchange-Systemsteuerung in Polnisch und Niederländisch
Insidertipp: Wechseln der Sprache
Ein OWA-Benutzer kann leicht zwischen verschiedenen Sprachen hin- und herwechseln, sofern die Sprachpakete auf dem Clientzugriffsserver installiert und verfügbar sind. Einige Werte lassen sich hiervon allerdings nicht beeindrucken. Wenn Sie OWA beispielsweise mit Französisch starten und dann zu Englisch wechseln, werden alle Standardordner ordnungsgemäß übersetzt (»Inbox«, »Sent Items« und »Deleted Items«), während die Namen von Suchordnern nicht geändert werden. So bleibt zum Beispiel der Ordnername »Courrier non lu« erhalten, obwohl er eigentlich »Unread Mail« lauten sollte. Hierbei handelt es sich um einen bekannten Fehler, der auch in Exchange Server 2010 SP1 nicht behoben wurde. Als serverabhängige Onlineanwendung verfolgt OWA einen anderen Ansatz. Bei jedem Start prüft OWA, ob die Zeitzone und die bevorzugte Sprache für ein Postfach bei der Anmeldung eines Benutzers eingestellt sind, und zeigt dann ein Fenster an, in dem der Benutzer diese Einstellungen wählen kann, sofern sie fehlen. Sie können verhindern, dass der Benutzer dieses Dialogfeld sieht (und somit auch mögliche Anrufe beim Support), indem Sie das virtuelle OWA-Verzeichnis mit einem Standardsprachcode versehen. So legt beispielsweise der folgende Befehl Englisch (Irland) als OWA-Standard-
288
sprachcode sowohl für die Clientsprache als auch für den bei der Anmeldung und in Dialogfeldern verwendeten Text fest. Der Standardwert für diese Einstellung ist 0, weshalb das Fenster für die Sprachauswahl Benutzern angezeigt wird, die keine bevorzugte Sprache für ihr Postfach festgelegt haben. Set-OWAVirtualDirectory –Identity 'OWA (default web site)' –DefaultClientLanguage 6153 –LogonAndErrorLanguage 6153
Weitere Informationen
Eine vollständige Liste der möglichen Regionalcodes finden Sie in TechNet. Es hat Sinn, dieselbe Einstellung auf alle Clientzugriffsserver im Unternehmen anzuwenden. Um auch einen Remoteserver einzuschließen, geben Sie den Namen des Servers bei der Nennung der Website mit an: Set-OWAVirtualDirectory –Identity 'ExServer2\OWA (default web site)' –DefaultClientLanguage 6153 –LogonAndErrorLanguage 6153
Indem Sie einen Standardsprachcode für das virtuelle OWA-Verzeichnis festlegen, erlauben Sie den Benutzern zwar, sich anzumelden, ohne von OWA zur Wahl der bevorzugten Sprache aufgefordert zu werden, jedoch ist diese Lösung unvollständig, weil so das Postfach nicht mit einer Zeitzoneneinstellung konfiguriert wird. Dies stellt kein Problem dar, solange alle Postfächer die für den Server festgelegte Standardzeitzone übernehmen, es kann jedoch Schwierigkeiten verursachen, sobald ein Server Postfächer mit verschiedenen Zeitzonen beherbergt. Ein weiterer Punkt ist, dass der Benutzer möglicherweise aufgefordert wird, eine Sprache zu wählen, wenn er über OWA auf die Exchange-Systemsteuerung zugreift, weil Exchange nicht ermitteln kann, welche Zeitzone dem Postfach zugeteilt ist. Es ist daher sehr viel sinnvoller, das Ganze zu vervollständigen und mithilfe des Cmdlets Set-MailboxRegionalConfiguration einen vollständigen Satz von Regionseinstellungen für ein Postfach vorzunehmen. Mit dem folgenden Beispielcode richte ich mein Postfach so ein, dass es irisches Englisch als Postfachsprache und die zugehörige Zeitzone sowie das passende regionale Datums- und Zeitformat verwendet: Set-MailboxRegionalConfiguration –Identity 'Tony Redmond' –Language 'en-IE' –TimeZone 'GMT Standard Time' -DateFormat 'dd/MM/yyyy' –TimeFormat 'H:mm'
Insidertipp: Achten Sie bei Datums- und Uhrzeitformaten auf Groß- und Kleinschreibung
Achten Sie auf das verwendete Datums- und Uhrzeitformat, da Exchange Einstellungen zurückweist, wenn sie nicht zur gewählten Zeitzone oder zur erforderlichen Maske passen. Groß- und Kleinbuchstaben sind hier wichtig. So wird beispielsweise das Format »d/M/YY« als gültiges Datumsformat für das Gebietsschema »en-IE« zurückgewiesen, während das Format »d/M/yy« akzeptiert wird. Die Exchange-Verwaltungskonsole zeigt Ihnen zusammen mit der Fehlermeldung die korrekten Werte an. Alternativ können Sie die Exchange-Systemsteuerung nutzen, um die regionalen Optionen für ein Postfach festzulegen (siehe Kapitel 5, »Exchange-Verwaltungskonsole und Exchange-Systemsteuerung«), dann mithilfe des Cmdlets Get-MailboxRegionalConfiguration die in die Postfacheigenschaften geschriebenen Werte prüfen und sie anschließend beim Erstellen anderer Postfächer replizieren.
289
Verwalten von E-Mailaktivierten Empfängern
Erstellen von neuen Postfächern
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
PST-Dateien: Ein Kapitel für sich
Beachten Sie, dass Exchange die Spracheinstellung einer PST-Datei (Personal Storage) nicht übernimmt, wenn Sie mithilfe des Cmdlets Import-Mailbox Inhalte daraus in ein neues Postfach importieren. So weist etwa eine PST-Datei, die zusammen mit der französischen Version von Outlook verwendet wurde, französische Ordnernamen auf. Wenn Sie nun Import-Mailbox verwenden, um die Elemente aus der PST-Datei in ein neues Postfach zu importieren, das auf einem englischsprachigen Exchange Server-Computer erstellt wurde, legt Exchange Ordner mit englischen Namen an, bevor es die Daten aus der PST-Datei importiert. Auf diese Weise erhalten Sie zwei Sätze von Ordnern, einen französischen und einen englischen. Aus diesem Grund ist es am besten, Exchange explizit mitzuteilen, was die bevorzugte Sprache für das Postfach sein soll, bevor Sie irgendwelche Daten darin importieren. Exchange Server 2007 bietet den Parameter -TemplateInstance für das Cmdlet New-Mailbox. Dieser Parameter weist Exchange an, Werte eines bestehenden Objekts zu kopieren, um damit ein neues Objekt zu erstellen, und bildet somit eine nützliche Methode, um sicherzustellen, dass die Eigenschaften des neuen Objekts korrekte Werte zugewiesen bekommen. Microsoft hat diesen Parameter in Exchange Server 2010 entfernt. Jegliche Skripts, die sich auf die Erstellung von Postfächern anhand von Vorlagen stützen, müssen somit angepasst werden, damit sämtliche benötigten Werte sowie Richtlinien bei der Erstellung neuer Postfächer korrekt angewendet werden.
Ändern von Postfacheinstellungen Exchange Server 2010 enthält einen Satz neuer Cmdlets, der es Administratoren erlaubt, Eigenschaften von Postfächern abzufragen und festzulegen. Sie können sich dies als administrative Zugriffsmöglichkeit auf die Optionen vorstellen, die den Benutzern zur Konfiguration ihrer Postfächer in Outlook oder OWA zur Verfügung stehen. Diese Eigenschaften sind als versteckte Elemente im Stammverzeichnis von Benutzerpostfächern gespeichert und waren in vorherigen Versionen von Exchange für Administratoren nicht zugänglich. Tabelle 6.3 listet die Postfacheinstellungen auf, die durch Administratoren geändert werden können, sowie die dafür verwendeten Cmdlets. Tabelle 6.3
290
Cmdlets für die Postfachkonfiguration. Zweck
Cmdlets
Ändern regionaler Voreinstellungen (Sprache, Datumsformat, Zeitzone)
Get-MailboxRegionalConfiguration Set-MailboxRegionalConfiguration
Ändern der Einstellungen für automatische Antworten
Get-MailboxAutoReplyConfiguration Set-MailboxAutoReplyConfiguration
Ändern der Kalendereinstellungen des Postfachs und Anpassen der Verarbeitung eingehender Anforderungen durch den Kalenderassistenten
Get-MailboxCalendarConfiguration Set-MailboxCalendarConfiguration Get-CalendarProcessing Set-CalendarProcessing
Auflisten oder Hinzufügen von Postfachordnern
Get-MailboxFolder New-MailboxFolder
Erstellen von neuen Postfächern
Cmdlets für die Postfachkonfiguration. (Fortsetzung) Zweck
Cmdlets
Ändern allgemeiner Postfacheinstellungen
Get-MailboxMessageConfiguration Set-MailboxMessageConfiguration
Ändern der Einstellungen für die Rechtschreibprüfung
Get-MailboxMessageConfiguration Set-MailboxMessageConfiguration
Ändern der Junk-E-Mail-Einstellungen
Get-MailboxMessageConfiguration Set-MailboxMessageConfiguration
Bevor Sie versuchen, die Eigenschaften eines Postfachs abzufragen oder einzustellen, sollten Sie sicherstellen, dass Sie die notwendigen Zugriffsrechte für das Postfach besitzen. Das Cmdlet Add-MailboxPermission kann folgendermaßen verwendet werden: Add-MailboxPermission –Identity 'John Smith' –User 'Europe Help Desk' -AccessRights FullAccess
Postfächer übernehmen eine Standardregionalkonfiguration auf der Grundlage der Sprach- und Landeseinstellungen des Servers, auf dem sie erstellt wurden. Läuft auf Ihrem Server zum Beispiel Exchange in der US-englischenVersion mit der entsprechenden Zeitzone, übernimmt jedes Postfach, das Sie auf diesem Server erstellen, automatisch diese Einstellungen zusammen mit anderen dazugehörigen Einstellungen wie Datums- und Zeitformat. Die Benutzer können diese Einstellungen über einen Client ändern, indem Sie zum Beispiel die Optionen zur Sprachauswahl nutzen, die OWA bei der ersten Postfachanmeldung bereitstellt. Um die regionalen Einstellungen eines Postfachs auszulesen, geben Sie zum Beispiel Folgendes ein: Get-MailboxRegionalConfiguration –Identity 'John Smith'
Das Cmdlet Set-MailboxRegionalConfiguration erlaubt es Ihnen, die Regionaleinstellungen zu ändern. Im folgenden Beispiel legen wir Sprache, Zeitzone und Datumsformat für das Postfach fest: Set-MailboxRegionalConfiguration –Identity 'John Smith' –Language 'Es-es' –TimeZone 'Eastern Time Zone' –DateFormat 'dd-mmm-yyyy'
Get-MailboxAutoReplyConfiguration/Set-MailboxAutoReplyConfiguration ermöglicht die Abfrage bzw. Einstellung der Einstellungen für automatische Antworten. Welche Postfächer einer Datenbank diese Funktion gerade aktiviert haben und bis zu welchem Datum, können wir zum Beispiel mit dem folgenden Befehl herausfinden: Get-Mailbox –Database 'VIP Data' | Get-MailboxAutoReplyConfiguration | Where {$_.AutoReplyState –eq 'Scheduled'} | Select MailboxOwnerId, EndTime MailboxOwnerId --------------contoso.com/Exchange Users/Akers, Kim
EndTime -----------11/18/2010 2:00:00 AM
Wenn Sie sich sämtliche gespeicherten Daten eines Postfachs über diese Funktion auflisten lassen, können Sie auch den Text sehen, den der Benutzer als automatische Antwort für interne und externe Empfänger erstellt hat:
291
Verwalten von E-Mailaktivierten Empfängern
Tabelle 6.3
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Get-MailboxAutoReplyConfiguration –id 'Kim Akers'
292
AutoReplyState EndTime ExternalAudience ExternalMessage
: : : :
InternalMessage
:
StartTime MailboxOwnerId Identity AutoReplyState EndTime ExternalAudience ExternalMessage
: : : : : : :
Scheduled 11/18/2010 2:00:00 AM Known <style type="text/css" id="owaTempEditStyle"> <style type="text/css" id="owaParaStyle"> I am away and will reply when I return. /div> <style type="text/css" id="owaTempEditStyle"> <style type="text/css" id="owaParaStyle"> I am away and am not able to reply. Please contact Phyllis Harris, my assistant, at +1 650 561 4136, who may be able to help you. Phyllis is also available at [email protected]. 1/14/2010 2:00:00 AM contoso.com/Exchange Users/Akers, Kim contoso.com/Exchange Users/Akers, Kim Scheduled 11/18/2010 2:00:00 AM Known <style type="text/css" id="owaTempEditStyle"> <style type="text/css" id="owaParaStyle"> I am away and will reply when I return. /div>
InternalMessage
StartTime MailboxOwnerId Identity
: <style type="text/css" id="owaTempEditStyle"> <style type="text/css" id="owaParaStyle"> I am away and am not able to reply. Please contact Phyllis Harris, my assistant, at +1 650 561 4136, who may be able to help you. Phyllis is also available at [email protected]. : 1/14/2010 2:00:00 AM : contoso.com/Exchange Users/Akers, Kim : contoso.com/Exchange Users/Akers, Kim
Sie können auch eine neue automatisch generierte Antwort für einen Benutzer festlegen, der in Urlaub gegangen ist und vergessen hat, es anderen mitzuteilen. In diesem Fall aktivieren Sie die Funktion für automatische Antworten, legen ein Zeitlimit fest und erstellen gesonderte Nachrichten für interne und externe Empfänger. Des Weiteren weisen Sie Exchange an, automatische Antworten nur an externe Kontakte zu senden, die dem Postfachbesitzer bekannt sind. Set-MailboxAutoReplyConfiguration -Identity 'Kim Akers' -StartTime '12/10/2010 19:30' -AutoReplyState Enabled -EndTime '12/15/2010 07:00' –InternalMessage 'Kim Akers is on vacation and will respond to your message after she returns on December 15' –ExternalMessage 'Kim Akers is on vacation' –ExternalAudience 'Known'
Um diese Funktion für einen Benutzer zu deaktivieren, geben Sie Folgendes ein: Set-MailboxAutoReplyConfiguration –Identity 'Kim Akers' –AutoReplyState Disabled
Mit den Cmdlets Get-MailboxCalendarConfiguration/Set-MailboxCalendarConfiguration können Sie Kalendereinstellungen abfragen und festlegen. So bewirkt beispielsweise der folgende Befehl, dass der Kalender die Zeitzone von Greenwich verwendet und den Arbeitstag um 8:30 Uhr beginnt. Set-MailboxCalendarConfiguration -Identity 'John Smith' –WorkingHoursTimeZone 'GMT Standard Time' -WorkingHoursStartTime 08:30:00
Das Cmdlet Set-CalendarProcessing dient dazu, festzulegen, wie der Kalenderassistent im Postfach eingehende Kalenderanforderungen verarbeitet. Wenn Sie über die Exchange-Verwaltungskonsole auf die Postfacheigenschaften zugreifen, dann finden Sie die entsprechenden Einstellungen auf der Registerkarte Kalendereinstellungen. Ebenso ist der Zugriff über die Exchange-Verwaltungsshell möglich. So legen Sie zum Beispiel mit dem folgenden Befehl die erste und vierte der in Abbildung 6.7 gezeigten Einstellungen fest. Set-CalendarProcessing –Identity 'Redmond, Tony' –RemoveForwardedMeetingNotifications $True –ProcessExternalMeetingMessages $True
293
Verwalten von E-Mailaktivierten Empfängern
Erstellen von neuen Postfächern
Kapitel 6 Abbildg. 6.7
Verwalten von E-Mail-aktivierten Empfängern
Ändern der automatischen Kalendereinstellungen eines Postfachs.
Benutzer können diese Einstellungen im Bereich Automatische Verarbeitung der OWA-Optionen ändern (mehr dazu in Kapitel 10, »Clients«). Das Cmdlet Set-CalendarProcessing kann jedoch noch viel mehr, als nur den eingeschränkten Satz der in der Exchange-Verwaltungskonsole verfügbaren Eigenschaften zu bearbeiten, besonders bei Ressourcenpostfächern. Weitere Informationen finden Sie in der Exchange-Hilfe. Mithilfe der Cmdlets Get-MailboxFolder and New-MailboxFolder können Sie eine Liste der Ordner eines Postfachs ausgeben und neue Ordner anlegen. Dabei können Sie wählen, ob Sie sich nur Ordner der obersten Ebene oder alle Ordner anzeigen lassen oder aber nach Informationen über einen bestimmten Ordner und dessen Unterordner suchen möchten. Der Befehl zum Abrufen einer vollständigen Liste eines Postfachs sieht folgendermaßen aus: Get-MailboxFolder -Identity 'John Smith\'–Recurse -MailFolderOnly
Um einen neuen Ordner mit dem Namen »Exchange Server 2010« in der obersten Ebene des Postfachs anzulegen, geben Sie Folgendes ein: New-MailboxFolder -Parent 'John Smith' -Name 'Exchange Server 2010'
Mit Get-MailboxMessageConfiguration und Set-MailboxMessageConfiguration können Sie allgemeine Eigenschaften eines Postfachs abrufen und festlegen. So können Sie Exchange zum Beispiel anweisen, eine automatische Signatur an jede ausgehende Nachricht anzuhängen, und auch den entsprechenden Text festlegen: Set-MailboxMessageConfiguration -Identity 'John Smith' -AutoAddSignature $True –SignatureText 'From the desk of John Smith'
294
Mit Get-MailboxSpellingConfiguration und Set-MailboxSpellingConfiguration lassen sich Eigenschaften abfragen und festlegen, die steuern, wie ein Benutzer die Rechtschreibprüfung für seine Nachrichten nutzt. Im folgenden Beispiel wird Exchange angewiesen, die Rechtschreibprüfung auf jede Nachricht anzuwenden, bevor diese gesendet wird, Wörter zu ignorieren, die eine Kombination aus Zahlen und Großbuchstaben enthalten (in der Regel technische Begriffe), und das finnische Wörterbuch zu verwenden: Set-MailboxSpellingConfiguration –Identity 'John Smith' –CheckBeforeSend $True -IgnoreMixedDigits $True –IgnoreUpperCase $True –DictionaryLanguage 'Finnish'
Mit Get-MailboxJunkEmailConfiguration und Set-MailboxJunkEmailConfiguration können Sie Eigenschaften abfragen und festlegen, die die Junk-E-Mail-Einstellungen eines Benutzers steuern. Die wichtigsten dieser Eigenschaften sind die Listen für vertrauenswürdige und blockierte Absender. Beide Eigenschaften können mehrere Werte enthalten, weshalb Sie sie zunächst in einer Variable ändern müssen, bevor Sie die jeweilige Eigenschaft mit neuen Werten aktualisieren. Um beispielsweise die Domäne cohowinery.com in die Liste der blockierten Absender aufzunehmen, geben Sie Folgendes ein: $List = Get-MailboxJunkEMailConfiguration –Identity 'John Smith' $List.BlockedSendersAndDomain += 'cohowinery.com' Set-MailboxJunkEMailConfiguration –Identity 'John Smith' –BlockedSendersAndDomain $List.BlockedSendersAndDomain
Selbstverständlich können die Benutzer diese Einstellungen in Outlook oder OWA wieder überschreiben, nachdem Sie irgendwelche ihrer Postfacheinstellungen geändert haben. Falls Sie Ihrem Konto Zugriffsrechte auf ein Postfach eingeräumt haben, sollten Sie sicherstellen, sie nach der Anpassung aller benötigten Regionaleinstellungen wieder aufzuheben. Im folgenden Beispiel nutzen wir das Cmdlet Remove-MailboxPermission, um die vollen Zugriffsrechte für das bearbeitete Postfach wieder vom Konto »Europe Help Desk« zu entfernen. Remove-MailboxPermission -Identity 'John Smith' -User 'Europe Help Desk' -AccessRights FullAccess
Massenerstellung von Postfächern Die Methoden zum Erstellen neuer Postfächer reichen von einmaligen Operationen bis hin zu ausgefeilten Skripts zum Anlegen hunderter oder Tausender neuer Postfächer im Rahmen einer Unternehmensfusion. Einige Firmen verwenden gesonderten Code, um die Postfacherstellung in den Eingliederungsvorgang für neue Mitarbeiter aufzunehmen, während andere sich damit begnügen, neue Postfächer bei Bedarf bei den Administratoren anzufordern. Mehrere Postfächer über die ExchangeVerwaltungskonsole zu erstellen, macht nicht sonderlich viel Spaß, da das Durchklicken der zahlreichen Seiten des Assistenten für die Erstellung neuer Postfächer nach einigen Durchgängen zu einer ermüdenden und lästigen Aufgabe wird. Wenn Sie also mehr als nur eine Hand voll neuer Postfächer erstellen müssen, lohnt es sich, ein wenig Zeit zu investieren, um diesen Vorgang mithilfe von Verwaltungsshell-Code bis zu einem gewissen Grad zu automatisieren. Der weiter hinten gezeigte Code übernimmt einen Großteil der Arbeit, indem er zuerst Daten über die neuen Postfächer aus einer CSV-Datei liest, dann einige Cmdlets zum Erstellen des jeweiligen Postfachs aufruft, das neue Postfach einer Verteilergruppe zuweist, die Active Directory-Attribute für das neue Konto und schließlich die Regionaldaten des Postfachs aktualisiert. 295
Verwalten von E-Mailaktivierten Empfängern
Erstellen von neuen Postfächern
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Er stellt außerdem sicher, dass die Namenskonvention Nachname, Vorname für die Postfachnamen verwendet wird. Im Gegensatz zu Skripts, die Sie eventuell in Exchange Server 2007 verwendet haben, muss bei dieser Version keine Datenbank festgelegt werden, da der Postfachbereitstellungs-Agent jedes Postfach einer Datenbank zuweist. Aber selbstverständlich wäre es ein Leichtes, die Eingabedatei so anzupassen, dass sie eine Datenbank angibt, und das Skript so zu ändern, dass der Datenbankname mithilfe des Parameters -Database im Befehl New-Mailbox übergegeben wird. Die CSV-Eingabedatei entspricht der aus Abbildung 6.8. Die erste Zeile der Datei enthält die Feldüberschriften zur Referenzierung der über das Cmdlet Import-CSV geladenen Arraydaten. Angenommen, das Skript heißt Bulk-Mailbox-Load.ps1 und die Eingabedatei Users.csv, dann geben wir Folgendes ein: C:> .\Bulk-Mailbox-Load.PS1 Users.CSV Abbildg. 6.8
Prüfen einer CSV-Datei, die als Eingabe für das Massenladen mehrerer Postfächer dient
Der Code lautet wie folgt: ## Import von Daten aus der CSV-Eingabedatei und Speichern der Datei in der Variable 'data' $Data = Import-CSV $args[0] $CurrentDate = "Created on " + (Get-Date) ForEach ($i in $Data) { ##Umwandeln des Kennworts von einfachem Text in eine sichere Zeichenfolge $PW = ConvertTo-SecureString $i.Password -AsPlainText –Force ## Festlegen einiger benötigter Variablen $UPN = $i.FirstName + "." + $i.LastName + '@' + $i.FQDN $FullName = $i.LastName + ', ' + $i.FirstName $Alias = $i.LastName + $i.FirstName ## Erstellen des neuen Postfachs New-Mailbox -Password $PW -UserPrincipalName $UPN -Name $FullName -OrganizationalUnit $i.OU -Database $i.Database -Alias $Alias -FirstName $i.FirstName -LastName $i.LastName ## Hinzufügen des neuen Postfachs zur Verteilergruppe Add-DistributionGroupMember -Identity $i.DL -Member $UPN ## Festlegen einiger Active Directory-Attribute für das neue Postfach Set-User -Identity $UPN -Office $i.Office -Company $i.Organization -Phone $i.Phone -Title $i.Title -Notes $CurrentDate ## Festlegen der Regionaleinstellungen des Postfachs einschließlich Sprache und Zeitzone Set-MailboxRegionalConfiguration -Identity $UPN –Language $i.Language –TimeZone $i.TimeZone }
296
Das Skript ist beileibe nicht perfekt und muss angepasst werden, bevor Sie es in einer Produktionsumgebung einsetzen können. So möchten Sie vielleicht noch weitere Postfach- oder Benutzerkontoeigenschaften einfügen oder den Schritt zum Hinzufügen zu einer Verteilergruppe entfernen, weil Sie dynamische Verteilergruppen haben, die neue Postfächer automatisch anhand ihres Büros, ihrer Datenbank oder anderer Kriterien aufnehmen. Vielleicht möchten Sie ActiveSync- oder OWARichtlinien für die neuen Postfächer festlegen oder verschiedene Speicherkontingente zuweisen. Das Schöne an der Exchange-Verwaltungsshell und Windows PowerShell im Allgemeinen ist, dass es sehr leicht ist, diese Änderungen vorzunehmen und so ein für Ihr Unternehmen geeignetes Massenladeskript zu erstellen.
Festlegen von Kontingenten Drei Postfacheigenschaften in Kombination steuern das für ein Postfach verfügbare Kontingent: 쐍 IssueWarningQuota Dieser Wert legt fest, ab wann Exchange dem Benutzer Warnnachrichten senden soll, dass er bald sein Postfachkontingent überschreiten wird. In der Regel bewegt sich dieser Wert zwischen 10 und 20 MB unter dem Wert, von dem an der Benutzer keine E-Mails mehr versenden kann. 쐍 ProhibitSendQuota Dieser Wert legt fest, ab wann Exchange den Benutzer daran hindern soll, neue Nachrichten zu senden. Wenn ein Benutzer von seinem Postfachkontingent spricht, bezieht er sich für gewöhnlich auf diesen Wert. Postfachkontingente können je nach Installation und Arbeitsfeld des Benutzers enorm variieren. So kommt ein Fabrikarbeiter vielleicht schon mit 50 MB aus, um interne Mitteilungen und Ankündigungen zu erhalten, während eine Führungskraft eines kommunikationsintensiven Unternehmens ein Postfachkontingent von 10 GB benötigt. Die meisten Benutzer in großen Unternehmen verfügen über ein Postfachkontingent zwischen 100 und 500 MB. Dies kann sich mit der Zeit ändern, etwa wenn ältere Versionen durch Exchange Server 2010 ersetzt werden und Unternehmen die Vorteile der Nutzung günstigerer Speicheroptionen erkennen. In der Tat haben sich in einigen Firmen, die bereits mit Exchange Server 2010 arbeiten, Postfachkontingente zwischen 5 und 10 GB etabliert. 쐍 ProhibitSendReceiveQuota Dieser Wert legt fest, ab wann Exchange den Empfang neuer Nachrichten im Postfach ablehnen soll. Nachrichten, die danach ankommen, werden zum Absender zurückgeschickt, zusammen mit einer Fehlermeldung, dass das Zielpostfach voll ist. In der Regel ist dieser Wert zwischen 100 und 200 MB höher angesiedelt als der von ProhibitSendQuota, um bestimmte Situationen abzufedern, zum Beispiel Abwesenheit durch Urlaub, in denen Benutzer ihre Postfächer unbeabsichtigt nahezu voll werden lassen. Dieser durch den Unterschied zwischen den Werten ProhibitSendQuota und ProhibitSendReceiveQuota entstehende Puffer ermöglicht somit, dass das Postfach weiterhin neue Nachrichten empfangen kann, bis der Benutzer wieder an seinen Arbeitsplatz zurückgekehrt ist und überholte Objekte aus dem Postfach löscht, sodass es wieder voll funktionsfähig ist. Anhand eines Zeitplans, der in der für jede Postfachdatenbank festgelegten Eigenschaft QuotaNotificationSchedule gespeichert wird, benachrichtigt Exchange die Benutzer, wenn sie entweder kurz davor stehen, ihr Postfachkontingent zu überschreiten, oder es bereits überschritten haben: Get-MailboxDatabase –Identity 'DB1' | Format-List Name, QuotaNotificationSchedule Name
: DB1
297
Verwalten von E-Mailaktivierten Empfängern
Erstellen von neuen Postfächern
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
QuotaNotificationSchedule : {So.1:00-So.1:15, Mo.1:00-Mo.1:15, Di.1:00-Di.1:15, Mi.1:00-Mi.1:15, Do.1:00-Do.1:15, Fr.1:00-Fr.1:15, Sa.1:00-Sa.1:15}
Sobald ein neues Postfach über die Exchange-Verwaltungskonsole oder die Exchange-Verwaltungsshell angelegt wird, übernimmt es seine Kontingenteinstellungen von der Datenbank, in der es erstellt wurde. Somit gilt zum Beispiel für jedes Postfach, das in der in Abbildung 6.9 gezeigten Datenbank erstellt wurde, dass es ab einem Wert von 1,9 GB Warnhinweise erhält, ab 2 GB (dem Postfachkontingent) nicht mehr in der Lage ist, neue Nachrichten zu senden, und ab 2,3 GB keine weiteren E-Mails mehr empfangen kann. Hierbei handelt es sich um die Werte, die den in Exchange Server 2010 erstellten Datenbanken für neue Postfächer standardmäßig zugewiesen werden. Sollten sich diese Werte nicht für Ihre Installation eignen, müssen Sie die Datenbankeigenschaften aktualisieren, um die gewünschten Werte einzustellen. Anschließend müssen Sie bereits in der Datenbank vorhandene Postfächer eventuell überprüfen, um festzustellen, ob deren Kontingente angepasst werden müssen. Abbildg. 6.9
Anzeigen der Standardspeicherkontingente einer Postfachdatenbank
Nachdem Sie ein Postfach erstellt haben, können Sie ihm individuelle Kontingente zuweisen, um den jeweiligen geschäftlichen Anforderungen gerecht zu werden. Um Kontingente mithilfe der Verwaltungskonsole anzupassen, wählen Sie das betreffende Postfach aus, zeigen seine Eigenschaften an, klicken auf die Registerkarte Postfacheinstellungen, markieren Speicherkontingente und klicken auf Eigenschaften (Abbildung 6.10). Deaktivieren Sie das Kontrollkästchen Standardwerte für Postfachdatenbank verwenden, um die drei Kontingentfelder zu aktivieren. Sie können einem Postfach auch mithilfe des Cmdlets Set-Mailbox neue Kontingentwerte zuweisen: Set-Mailbox –Identity 'Redmond, Tony' –UseDatabaseQuotaDefaults $False –IssueWarningQuota 500MB –ProhibitSendQuota 520MB –ProhibitSendReceiveQuota 540MB
298
Erstellen von neuen Postfächern
Festlegen des Speicherkontingents für ein Postfach
Verwalten von E-Mailaktivierten Empfängern
Abbildg. 6.10
Kontingentwerte lassen sich in KB, MB oder GB ausdrücken. Mit einem einzeiligen Verwaltungsshell-Befehl können Sie einer ganzen Gruppe von Postfächern dasselbe Kontingent zuweisen, beispielsweise allen Postfächern einer Organisationseinheit: Get-Mailbox –OrganizationalUnit 'contoso.com/Exchange Users' | Set-Mailbox –UseDatabaseQuotaDefaults $False –IssueWarningQuota 500MB –ProhibitSendQuota 520MB –ProhibitSendReceiveQuota 540MB
Auf dieselbe Art und Weise ist es möglich, jedem Mitglied einer Verteilergruppe dasselbe Kontingent zuzuweisen. So lautet zum Beispiel der Befehl, den Mitarbeitern der IT-Abteilung die benötigten Kontingente zu gewähren, folgendermaßen: Get-DistributionGroupMember –Identity 'IT Department' | Set-Mailbox –UseDatabaseQuotaDefaults $False –IssueWarningQuota 985MB –ProhibitSendQuota 1GB –ProhibitSendReceiveQuota 1.1GB
Um zu prüfen, ob die richtigen Kontingente vergeben wurden, wenden Sie folgenden Befehl an: Get-Mailbox –Identity 'Redmond, Tony' | Select *quota* ProhibitSendQuota ProhibitSendReceiveQuota RecoverableItemsQuota RecoverableItemsWarningQuota UseDatabaseQuotaDefaults IssueWarningQuota
: : : : : :
2.949 GB (3,166,699,520 bytes) 3 GB (3,221,225,472 bytes) unlimited unlimited False 2.93 GB (3,145,728,000 bytes)
299
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
RulesQuota ArchiveQuota ArchiveWarningQuota
: 64 KB (65,536 bytes) : 50 GB (53,687,091,200 bytes) : 45 GB (48,318,382,080 bytes)
Wie Sie sehen, umfasst Exchange noch verschiedene andere Kontingenteinstellungen für Postfächer. Die Einstellungen RecoverableItemsQuota and RecoverableItemsWarningQuota funktionieren in etwa wie die Einstellungen ProhibitSendQuota and IssueWarningQuota, steuern aber, welche Datenmenge ein Postfach im Ordner für wiederherstellbare Elemente (dem Papierkorb) speichern kann. Standardmäßig erlaubt Exchange Server 2010 eine unbegrenzte Datenmenge im Papierkorb. Die Einstellung RulesQuota beschränkt die Menge an Regeldaten, die ein Postfach enthalten darf, wobei 64 KB der Standardwert ist. Die Einstellungen ArchiveQuota und ArchiveWarningQuota steuern, wie viele Daten sich in einem zugehörigen Archiv befinden dürfen. Exchange erlaubt auch für das Archiv standardmäßig eine unbegrenzte Menge, sodass das Kontingent im obigen Beispiel auf ein Limit von 50 GB gesetzt wurde (was immer noch mehr als genug ist). Abschätzen der Datenbankgröße
Für die Planung ist es wichtig zu erkennen, dass die einfache Berechnung (Anzahl der Postfächer * Kontingent) = Datenbankgröße auf der Festplatte höchstwahrscheinlich nicht zu einem realistischen Ergebnis führt. Es gibt noch weitere Faktoren, die es zu berücksichtigen gilt, wenn es darum geht, die voraussichtliche Größe einer Datenbank zu ermitteln. 1. Ein Kontingent steht für einen Maximalwert, der einem Postfach zugewiesen wird. Sofern sein
Kontingent nicht besonders klein bemessen ist, wird ein Benutzer einige Zeit benötigen, um es auszuschöpfen. Ein 2-GB-Kontingent ist möglicherweise erst nach zwei Jahren erreicht. 2. Der Papierkorb benötigt zusätzlichen Speicher in der Datenbank. Wenn Sie es den Benutzern erlauben, gelöschte Elemente 21 Tage lang aufzubewahren, verbrauchen Sie damit bis zu 10% an zusätzlichem Speicher. Dieser Speicher wird nicht vom Kontingent des Benutzers abgezogen. 3. Persönliche Archive beanspruchen weiteren Speicherplatz, wenn sie in derselben Datenbank untergebracht werden wie das zugehörige primäre. 4. Des Weiteren gibt es innerhalb der Datenbank Leerraum. Dabei handelt es sich um Datenbankseiten, deren ehemaliger Inhalt gelöscht wurde und die nun zur Wiederverwendung durch Exchange verfügbar sind, um neue Elemente und Anhänge zu speichern. Zwar arbeitet Exchange sehr effizient, wenn es um die Wiederverwendung gelöschter Seiten geht, allerdings liegt es in der Natur des E-Mail-Verkehrs, dass ständig neue Objekte eintreffen, von denen einige gelöscht und andere aufbewahrt werden. Aufgrund dieser ständigen Veränderungen kommt es auch zu einer stetigen Fluktuation von Datenbankseiten, sodass schätzungsweise weitere 10% des Postfachumfangs von Leeraum eingenommen werden. Es gibt eine bessere Methode, um die voraussichtliche maximale Größe einer Datenbank zu ermitteln, sodass diese auf einer Festplatte mit ausreichend Speicherplatz platziert werden kann. Schlagen Sie 20% auf die ursprüngliche Kalkulation auf, um die voraussichtliche Datenbankgröße zu berechnen: (Anzahl der Postfächer * Kontinent) * 1,2 = Datenbankgröße auf der Festplatte Neu festgelegte Kontingente sind nicht unmittelbar aktiv, da der Speicher zuerst seine zwischengespeicherten Daten über Postfacheinstellungen aktualisieren muss. Der Cache wird alle zwei Stunden aktualisiert, sodass Sie möglicherweise so lange warten müssen, bis die neuen Kontingenteinstellungen greifen. Sie haben die Möglichkeit, die Registrierungseinstellung Reread Logon Quotas Interval
300
anzupassen, um häufigere Cacheaktualisierungen dieser Daten zu erzwingen – allerdings auf Kosten der Systemressourcen (ein Aktualisierungsintervall von fünf Minuten ist definitiv keine gute Idee, während eine Stunde ein akzeptabler Wert ist). Dieser DWORD-Wert wird in Sekunden angegeben (der Standardwert beträgt 7.200 Sekunden bzw. zwei Stunden). Die Höhe dieses Wertes hängt von anderen Werten ab, die steuern, wie oft Exchange Informationen aus Active Directory abruft. Eine weitere Möglichkeit besteht darin, den Informationsspeicherprozess neu zu starten, um eine Cacheaktualisierung zu erzwingen. Diese Vorgehensweise eignet sich jedoch eher für einen Test- und weniger für einen Produktionsserver. Weitere Informationen
Informationen über das Ändern der Werte der Registrierungseinstellung Reread Logon Quotas Interval finden Sie unter http://technet.microsoft.com/library/bb684892(EXCHG.80).aspx. TIPP Kalkulieren Sie außerdem zusätzlichen Festplattenspeicher ein, um den zu erwartenden Datenzuwachs, zum Beispiel über das nächste Jahr hinweg, unterbringen zu können oder vorübergehenden Speicherplatz für Aktivitäten wie das Verschieben von Postfächern oder die Offline-Datenbankwartung zur Verfügung zu haben.
Was ist in einem Postfach? Nachdem Sie den Postfächern Kontingente zugewiesen haben, beginnen die Benutzer damit, ihre Postfächer mit verschiedenen Objekten zu füllen. Mithilfe des Cmdlets Get-MailboxStatistics erhalten Sie eine Momentaufnahme dessen, was sich in einem Postfach befindet, und erfahren, um welche Arten von Objekten es sich dabei handelt: Get-MailboxStatistics –Identity 'Redmond, Tony' | Select DisplayName, ServerName, Database, LastLogonTime, ItemCount, DeletedItemCount, AssociatedItemCount, TotalItemSize, TotalDeletedItemSize DisplayName ServerName Database LastLogonTime ItemCount DeletedItemCount AssociatedItemCount TotalItemSize TotalDeletedItemSize
: : : : : : : : :
Redmond, Tony ExServer1 DB1 12/30/2010 4:31:28 AM 38176 8281 52 2.247GB (2,412,430,212 bytes) 26.81 MB (28,112,322 bytes)
Unter anderem finden wir hier folgende interessante Informationen: 쐍 ItemCount ist die Gesamtanzahl von Objekten, die sich in den Ordnern des Postfachs befinden. Die Zahl unter TotalItemSize zeigt die durch den Speicher berechnete Gesamtgröße dieser Objekte an. 쐍 DeletedItemCount zeigt die Gesamtzahl von Objekten im Papierkorb an, TotalDeletedItemSize die Gesamtgröße dieser Objekte.
301
Verwalten von E-Mailaktivierten Empfängern
Erstellen von neuen Postfächern
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
쐍 AssociatedItemCount bezieht sich auf versteckte Objekte, die von Exchange und Outlook zum Speichern von Konfigurationsdaten des Postfachs genutzt (und manchmal auch FAI-Nachrichten genannt) werden. Wenn Sie beispielsweise eine Postfacheinstellung über OWA ändern, so wird diese Information in ein verstecktes Objekt innerhalb des Postfachs geschrieben. Die Anzahl solcher zugehöriger Objekte variiert von Postfach zu Postfach und hängt von der Aktivität des jeweiligen Benutzers ab, bewegt sich aber üblicherweise zwischen 10 und 60. Je neuer ein Postfach ist, desto niedriger ist diese Zahl, je länger es in Gebrauch ist, desto höher fällt sie gewöhnlich aus. Mithilfe des Cmdlets Get-MailboxStatistics können Sie außerdem Daten über sämtliche Postfächer in einer Datenbank oder auf einem gesonderten Server abrufen. Das zweite Beispiel schreibt die Ausgabe im CSV-Format in eine Datei, die Sie mit Microsoft Excel oder Microsoft Access öffnen und für Berichtszwecke nutzen können. Get-MailboxStatistics –Database 'DB1' Get-MailboxStatistics –Server 'ExServer1' | Export-CSV 'C:\Temp\Mailboxes.CSV'
Wenn Sie Get-MailboxStatistics zusammen mit dem Parameter -Server auf einem Server verwenden, der Datenbankkopien einer Datenbankverfügbarkeitsgruppe enthält, wird Ihnen eine Fehlermeldung angezeigt, dass die Datenbankkopien nicht geladen oder nicht verfügbar sind. Das liegt daran, dass das Cmdlet diese Datenbanken nicht öffnen kann, um Postfachdaten zu lesen, da sie auf eine besondere Art geladen werden, die eine Replikation erlaubt, andere Arten von Zugriffen jedoch blockiert.
Entfernen und Deaktivieren von Postfächern Auch Postfächer bestehen nicht ewig, und irgendwann einmal werden Sie einige davon aus Exchange entfernen, gewöhnlich dann, wenn ein Mitarbeiter das Unternehmen verlässt. Vielleicht möchten Sie ein Postfach auch nach dem Weggang eines Mitarbeiters noch eine Zeit lang aufbewahren, sodass die Inhalte nicht sofort verloren sind und noch eine gewisse Zeit für andere Personen oder aus rechtlichen Gründen verfügbar bleiben. Die Verwaltungskonsole hält zwei Optionen für das Entfernen von Postfächern bereit: Sie können ein Postfach entweder deaktivieren oder entfernen. Wenn Sie ein Postfach deaktivieren, entfernt Exchange sämtliche Eigenschaften aus dem zugrunde liegenden Windows-Benutzerkonto in Active Directory, das den Benutzer mit dem Postfach verknüpft. Die Inhalte des Postfachs werden aus seiner Datenbank gelöscht, nachdem die Aufbewahrungsfrist für gelöschte Postfächer abgelaufen ist. Hat Exchange ein Postfach einmal aus einer Datenbank gelöscht, können Sie es später lediglich aus einer Sicherung wiederherstellen. Der entsprechende Verwaltungsshell-Befehl zum Deaktivieren eines Postfachs lautet folgendermaßen: Disable-Mailbox –Identity 'Redmond, Tony'
Wenn Sie ein Postfach entfernen, so wird dieses nicht nur für die Löschung nach Ablauf der Aufbewahrungsfrist gekennzeichnet, sondern Sie entfernen damit auch das Windows-Benutzerkonto aus Active Directory. Der von der Verwaltungskonsole verwendete Verwaltungsshell-Befehl lautet folgendermaßen: Remove-Mailbox –Identity 'Redmond, Tony'
Wie bei deaktivierten Postfächern bewahrt Exchange auch die Inhalte von entfernten Postfächern so lange in deren ursprünglichen Datenbanken auf, bis ihre Aufbewahrungsfrist abgelaufen ist. Wenn
302
Sie möchten, können Sie die sofortige Löschung des Benutzerkontos in Active Directory sowie der Postfachinhalte durch Exchange erzwingen, indem Sie den Parameter -Permanent auf $True setzen: Remove-Mailbox –Identity 'Redmond, Tony' –Permanent $True
Bevor Sie ein Postfach deaktivieren oder entfernen, warnt die Verwaltungskonsole Sie vor den Konsequenzen dieses Schritts. Obwohl das Ergebnis wahrscheinlich nicht gut aussehen würde, haben Sie die Möglichkeit, ein Postfach wieder mit einem Active Directory-Konto zu verknüpfen, solange es in der Datenbank verfügbar ist. Besitzt das Postfach ein persönliches Archiv, werden Sie in dem Warnhinweis auch darauf aufmerksam gemacht. Insidertipp: Zukunftssicherung mit Remove-Mailbox und Remove-StoreMailbox
Exchange Server 2010 SP1 enthält immer noch das Cmdlet Remove-Mailbox, jedoch darüber hinaus das neue Cmdlet Remove-StoreMailbox, und Microsoft wird in den nächsten Releaseversionen verstärkt Wert auf die beiden folgenden Aspekte legen: 쐍 Remove-Mailbox sollte verwendet werden, um ein Active Directory-Konto für den Benutzer zu entfernen und das Postfach für die Löschung nach Ablauf der Aufbewahrungsfrist zu kennzeichnen. 쐍 Remove-StoreMailbox ist zu verwenden, wenn Sie das Postfach umgehend aus seiner Datenbank entfernen möchten. Tatsächlich ersetzt dieses neue Cmdlet Remove-Mailbox mit den Parametern -Permanent und -StoreMailboxIdentity. Doch warum für eine Aufgabe ein neues Cmdlet erstellen, wenn man sie bereits mit einem vorhandenen lösen kann? Die Antwort lautet, dass das neue Cmdlet Administratoren praktisch dazu zwingt, sich klar für die dauerhafte Löschung eines Postfachs zu entscheiden. Bei Remove-Mailbox kann es leicht passieren, dass der Parameter -Permanent übersehen wird und Postfächer folglich bis zum Ende ihrer Aufbewahrungsfrist in der Datenbank verbleiben. Der Zweck von Remove-StoreMailbox erklärt sich dagegen von selbst. Dieses Cmdlet erleichtert außerdem Überwachungsaufgaben, da der entsprechende Mitarbeiter dann einfach nur nach allen Einsätzen von Remove-StoreMailbox zu suchen braucht, anstatt sich durch sämtliche Instanzen von Remove-Mailbox zu kämpfen, um festzustellen, ob der Parameter -Permanent verwendet wurde.
Erneutes Verbinden von Postfächern Sobald Exchange die Verbindung für ein Postfach trennt, nachdem entweder Disable-Mailbox oder Remove-Mailbox ausgeführt worden ist, schreibt es das aktuelle Datum und die aktuelle Uhrzeit in die Eigenschaft DisconnectDate des Postfachs. Von diesem Zeitpunkt an beginnt die Aufbewahrungsfrist zu laufen. Die Aufbewahrungsfrist für gelöschte Postfächer ist eine Eigenschaft einer Postfachdatenbank und kann von den standardmäßigen 30 Tagen abweichen. So kann es zum Beispiel sein, dass Sie Postfächer für verschiedene Gruppen von Mitarbeitern aus rechtlichen Gründen unterschiedlich lange aufbewahren möchten. Dies erreichen Sie ganz einfach, indem Sie die Mitarbeiterpostfächer jeweils in Datenbanken mit unterschiedlichen Aufbewahrungsfristen platzieren. Mit dem folgenden Befehl können Sie sich die zurzeit eingestellte Aufbewahrungsfrist für gelöschte Postfächer aller Datenbanken des Unternehmens anzeigen lassen: Get-MailboxDatabase | Select Name, MailboxRetention
303
Verwalten von E-Mailaktivierten Empfängern
Entfernen und Deaktivieren von Postfächern
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Das Ändern der Aufbewahrungsfrist ist ein Fall für Set-MailboxDatabase. Um beispielsweise eine Postfachaufbewahrungsfrist von 60 Tagen für die Datenbank VIP Data festzulegen, geben wir den folgenden Befehl ein: Set-MailboxDatabase –Identity 'VIP Data' –MailboxRetention 60
Im Bereich Getrenntes Postfach des Knotens Empfängerkonfiguration werden alle derzeit getrennten Postfächer aller geladenen Datenbanken eines Servers aufgelistet (Abbildung 6.11). Die ExchangeVerwaltungskonsole verwendet einen Befehl wie den folgenden, um Informationen über getrennte Postfächer abzurufen: Get-MailboxStatistics -Server 'ExServer1.contoso.com' | Filter-PropertyNotEqualTo DisconnectDate Abbildg. 6.11
Anzeigen einer Liste aller getrennten Postfächer
Wenn Sie noch einen anderen Server überprüfen müssen, wählen Sie Mit Server verbinden im Aktionsbereich und geben den Namen des gewünschten Servers ein. Bei der Untersuchung der Datenbanken gibt die Verwaltungskonsole möglicherweise Meldungen über Fehler aus, die eine Anzeige aller getrennten Postfächer verhindern. So gibt es zum Beispiel keine Möglichkeit, Postfachinformationen aus einer Datenbank abzurufen, die nicht geladen ist. Manchmal dauert es ein wenig, bis ein deaktiviertes oder entferntes Postfach in der Liste der getrennten Postfächer angezeigt wird. Ein Grund dafür kann sein, dass Active Directory den Status des Postfachs noch nicht auf den von der Verwaltungskonsole genutzten Domänencontroller repliziert hat, ein anderer, dass der Informationsspeicher noch kein Trennungsdatum in die Eigenschaften des Postfachs geschrieben hat, sodass dieses durch den Filter rutscht, den die Verwaltungskonsole zum Auffinden getrennter Postfächer verwendet. Wenn Sie bemerken, dass ein getrenntes Postfach noch nicht in der Liste erscheint, können Sie Exchange mithilfe des Cmdlets Clean-MailboxDatabase veranlassen, nach getrennten Postfächern in einer Datenbank zu suchen:
304
Entfernen und Deaktivieren von Postfächern
Anschließend können Sie die Datenbank prüfen, um zu sehen, ob sich etwas verändert. Ich gehe gewöhnlich folgendermaßen vor: Get-MailboxStatistics –Database 'DB1' | Where {$_.DisconnectDate –ne $Null} | Select DisplayName, DisconnectDate DisplayName ----------Smith, Tony (IT)
DisconnectDate -------------5/26/2010 5:56:13 PM
Haben Sie ein getrenntes Postfach gefunden, das Sie wieder online bringen möchten, können Sie im Aktionsbereich auf Verbinden klicken, um den Assistenten zum Verbinden von Postfächern aufzurufen (Abbildung 6.12), der Sie dann durch die notwendigen Schritte führt. Abbildg. 6.12
Der Assistent zum Verbinden von Postfächern
Der Assistent bietet zwei Methoden zum erneuten Verbinden von Postfächern: 1. Sofern das ursprüngliche Active Directory-Konto noch existiert, können Sie mithilfe der Option
Entsprechender Benutzer das Originalkonto finden und auswählen. 2. Falls Sie das ursprüngliche Active Directory-Konto gelöscht haben, entweder mithilfe von Remove-
Mailbox oder durch separates Löschen nach dem Deaktivieren des Postfachs, können Sie mithilfe der Option Vorhandener Benutzer ein Active Directory-Konto zum Verbinden des Postfachs wählen. Dabei kann es sich um eine neues Konto handeln, das Sie für den ursprünglichen Postfachbesitzer anlegen, oder um ein völlig anderes Konto. Das Konto darf jedoch nicht bereits mit einem anderen Postfach verbunden sein; wenn Sie auf Durchsuchen klicken, um nach verfügbaren Konten zu suchen, werden nur diejenigen angezeigt, die nicht mit einem Postfach verknüpft sind. Die einzige weitere Bedingung ist die Vergabe eines eindeutigen Alias. 305
Verwalten von E-Mailaktivierten Empfängern
Clean-MailboxDatabase –Identity 'DB1'
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Die Verwaltungskonsole nutzt das Cmdlet Connect-Mailbox zum erneuten Verbinden eines Postfachs. Wie Sie im folgenden Beispiel sehen, verwendet die Verwaltungskonsole einen global eindeutigen Bezeichner (GUID), um das Postfach in der Datenbank zu finden. Das gewählte Active DirectoryKonto wird im Parameter -User festgelegt. Connect-Mailbox -Identity '50e2778f-e8ae-40d7-9dd8-bb22a101e8e5' -Database 'DB1' -User 'contoso.com/AJR' -Alias 'AJR'
Die Verwaltungskonsole scheint global eindeutige Bezeichner zu bevorzugen, da sie die genaueste Methode darstellen, ein Exchange-Objekt zu identifizieren. Sie können jedoch auch den Anzeigenamen verwenden, um das wieder zu verbindende Postfach zu finden. Wenn Sie den Namen nicht genau kennen, können Sie das Cmdlet Get-MailboxStatistics wie zuvor beschrieben auf die entsprechende Datenbank anwenden. Connect-Mailbox –Identity 'Redmond, Tony' –Database 'DB1' –Alias AJR
Der Postfach-GUID ist nützlich, wenn Sie ein Postfach vor Ablauf seiner Aufbewahrungsfrist aus einer Datenbank löschen möchten. Mit dem folgenden Code durchsuchen Sie eine Datenbank nach einem bestimmten Postfach, speichern dessen GUID in einer Variable und entfernen dann die Inhalte mithilfe von Remove-Mailbox. Beachten Sie außerdem die Verwendung des Parameters -StoreMailboxIdentity in diesem Befehl. $Mbx = Get-MailboxStatistics –Database 'DB1' | Where {$_.DisplayName –eq 'Redmond, Tony'}
Wenn Sie Postfachinhalte auf diese Art löschen, können Sie sie später bei Bedarf nur mithilfe einer Sicherung wiederherstellen. Insidertipp: Vermeiden von Fehlern
Vielleicht sind Sie jetzt etwas besorgt wegen des Potenzials für Fehler, zum Beispiel wenn ein Administrator Remove-Mailbox verwendet, statt ein Postfach zu deaktivieren, und dann entdeckt, dass er gerade das Active Directory-Konto des Benutzers gelöscht hat. Um solche Probleme zu vermeiden und sicherzustellen, dass Postfächer so lange wie nötig erhalten bleiben, haben sich viele Unternehmen die folgende einfache Vorgehensweise zu eigen gemacht: 1. Deaktivieren Sie das betreffende Windows-Konto, um weitere Zugriffe darauf zu unterbinden. 2. Verhindern Sie die Anzeige des Postfachs in der globalen Adressliste. 3. Ändern Sie die SMTP-E-Mail-Adresse, um sie ungültig zu machen und zu verhindern, dass
neue Nachrichten im Postfach ankommen. 4. Legen Sie eine passende automatische Antwort für das Postfach fest, sodass jeder, der eine
E-Mail an die neue SMTP-Adresse sendet, darüber informiert wird, dass sie nicht gelesen wird. 5. Behalten Sie das Postfach bis zu 90 Tage online und zugänglich.
Eine Zeitspanne von 45 bis 60 Tagen ist in der Regel ausreichend, um zu entscheiden, ob die Postfachinhalte noch benötigt werden. Wird das Postfach nicht mehr gebraucht, können Sie gefahrlos sowohl das Konto als auch das Postfach löschen.
306
E-Mail-Adressrichtlinien E-Mail-Adressrichtlinien definieren das Format von E-Mail-Adressen, die Exchange für E-Mail-aktivierte Objekte erstellt. Das Zusammenspiel zwischen E-Mail-Adressrichtlinien und den für ihre Verwaltung und Anwendung zuständigen Cmdlets ersetzt die in Exchange Server 2000 und 2003 etablierte Verarbeitung durch die Empfängerrichtlinien und den Empfängeraktualisierungsdienst. Im Gegensatz zu früheren Versionen werden die E-Mail-Adressrichtlinien in Exchange Server 2010 einheitlich und unmittelbar angewendet, da die Verwaltungskonsole und die zugrunde liegenden VerwaltungsshellCmdlets zum Erstellen und Aktualisieren E-Mail-aktivierter Empfänger dieselbe Geschäftslogik aufrufen. Die einzige Möglichkeit, Exchange daran zu hindern, eine E-Mail-Adressrichtlinie auf ein Objekt anzuwenden, besteht darin, es explizit davon auszuschließen: Set-Mailbox –Identity 'David Pelton' –EmailAddressPolicyEnabled $False
Die Auswirkung einer E-Mail-Adressrichtlinie zeigt sich, sobald ein neues E-Mail-aktiviertes Objekt erstellt oder angepasst wird oder nachdem ein Administrator eine Richtlinie so geändert hat, dass sich ein neuer E-Mail-Adresstyp oder ein neues E-Mail-Adressformat ergibt. Nach der Erstinstallation von Exchange sehen Sie im Bereich Hub-Transport des Knotens Organisationskonfiguration eine neue Richtlinie mit dem Namen Default Policy. Diese Standardrichtlinie erstellt E-Mail-Adressen aus dem Alias des Objekts sowie der SMTP-Domäne der Exchange-Organisation und wird so lange auf jedes E-Mail-aktivierte Objekt angewendet, bis eine andere E-Mail-Adressrichtlinie mit einer höheren Priorität erstellt wird. So erhält beispielsweise ein Objekt mit dem Alias TR in der Organisation contoso.com die SMTP-Adresse [email protected]. Hinter den Kulissen wendet jede E-Mail-Adressrichtlinie einen Empfängerfilter an, um zu ermitteln, welche Objekte in ihren Gültigkeitsbereich fallen. Folglich muss die Standard-E-Mail-Adressrichtlinie über einen äußerst groben Empfängerfilter verfügen, da sie auf jedes Objekt anwendbar sein muss, für das Exchange keine andere passende E-Mail-Adressrichtlinie finden kann. Der Empfängerfilter der Standard-E-Mail-Adressrichtlinie ist daher sehr einfach gestrickt, da er so ziemlich alles abfängt. Einzelheiten über diese Richtlinie können Sie sich mit dem Cmdlet Get-EmailAddressPolicy anzeigen lassen: Get-EmailAddressPolicy –Identity 'Default Policy' | Select Name, *Filter*, *Exch* Name RecipientFilter LdapRecipientFilter LastUpdatedRecipientFilter RecipientFilterApplied RecipientFilterType ExchangeVersion
: : : : : : :
Default Policy Alias -ne $null (mailNickname=*) Alias -ne $null True Precanned 0.1 (8.0.535.0)
Der Empfängerfilter stellt sicher, dass alle Empfänger erfasst werden, die einen Alias haben. Anstelle eines benutzerdefinierten Filters, der darauf ausgelegt ist, eine bestimmte Gruppe von Empfängern auszuwählen, kommt hier ein in Exchange vordefinierter Filter zum Einsatz. Mit dem Thema vordefinierte und benutzerdefinierte Filter befassen wir uns später, wenn es darum geht, wie beide Arten
307
Verwalten von E-Mailaktivierten Empfängern
E-Mail-Adressrichtlinien
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
für dynamische Verteilergruppen eingesetzt werden. (Mehr dazu finden Sie im Abschnitt »OPATHAbfragen« weiter hinten im Kapitel.) Die LDAP-Version (Lightweight Directory Access Protocol) des Filters ermöglicht es, den Empfängeraktualisierungsdienst auf Computern mit Exchange Server 2003 auszuführen, sodass die Richtlinie richtig interpretiert und genutzt werden kann, um Objekten, die auf diesen Servern erstellt werden, korrekte E-Mail-Adressen zuzuweisen. Die Exchange-Version erlaubt es dagegen nur Servern mit Exchange Server 2007 oder höher, die Richtlinie zu verarbeiten. Veraltete, mit Exchange Server 2003 erstellte E-Mail-Adressrichtlinien umfassen lediglich LDAPbasierte Filter, und nicht die von Exchange Server 2007 und 2010 verwendeten Empfängerfilter. E-Mail-Adressrichtlinien mit einer Exchange Server 2003 entsprechenden Versionsnummer können Sie folgendermaßen lokalisieren: Get-EmailAddressPolicy | Where {$_.ExchangeVersion –Like '*6.5*'} | Select Name, *Filter*
HINWEIS Sämtliche veralteten Richtlinien müssen aktualisiert oder entfernt werden. Leider können Sie dafür nicht den Assistenten verwenden, da die Exchange-Verwaltungskonsole den Versuch, eine alte E-Mail-Adressrichtlinie zu ändern, mit einer Fehlermeldung quittiert. Sie haben zwei Möglichkeiten, mit veralteten Richtlinien zu verfahren, die Sie in Exchange Server 2010 anwenden möchten: 쐍 Löschen Sie die alte E-Mail-Adressrichtlinie und erstellen Sie sie mithilfe des Assistenten in Exchange Server 2010 neu. Auch wenn dieser Ansatz sicherstellt, dass die resultierende Richtlinie für Exchange Server 2010 maßgeschneidert ist, sollten Sie so lange nichts löschen, bis Sie sicher sind, dass eine neue funktionierende Richtlinie verfügbar ist. 쐍 Aktualisieren Sie die bestehende E-Mail-Adressrichtlinie mithilfe des Cmdlets Set-EmailAddressPolicy. Zu diesem Zweck müssen Sie den zur Richtlinie gehörigen Empfängerfilter umformulieren. So weist etwa die alte LDAP-Richtlinie den Filter (mailNickname=*) auf, während die entsprechende vordefinierte Abfrage AllRecipients lautet. Um also die Richtlinie zu aktualisieren und den von Exchange Server 2010 benötigten Empfängerfilter einzubinden, geben Sie den folgenden Befehl ein: Set-EmailAddressPolicy –Identity 'Default Policy' –IncludedRecipients 'AllRecipients' –ForceUpgrade
Natürlich ist es einfach, einen Filter zu aktualisieren, der nach allen Empfängern sucht, besonders, wenn die entsprechenden Befehle in Hilfedateien und Büchern dokumentiert sind. Mehr Arbeit erfordert es, einen benutzerdefinierten LDAP-Filter in einen passenden Empfängerfilter umzuwandeln. Wie Sie benutzerdefinierte Filter erstellen, erfahren Sie in Kürze.
Priorität von E-Mail-Richtlinien In einem Unternehmen können mehrere E-Mail-Adressrichtlinien existieren (siehe Abbildung 6.13). Es ist im Allgemeinen ratsam, die Menge der verwendeten E-Mail-Adressrichtlinien auf ein Minimum zu reduzieren, da es mitunter schwierig sein kann, nachzuvollziehen, wo E-Mail-Adressen ihren Ursprung haben, besonders, wenn die Richtlinien sich auf unterschiedliche Empfängereigenschaften beziehen.
308
Jeder Richtlinie wird ein bestimmter Platz in einer Prioritätenrangfolge zugewiesen. Soll eine Richtlinie auf ein Objekt angewendet werden, durchsucht Exchange die Richtlinien anhand dieser Rangfolge, um die jeweils geeignete Richtlinie mit der höchsten Priorität zu finden. Die erste benutzerdefinierte E-Mail-Richtlinie, die Sie in Ihrem Unternehmen erstellen, erhält automatisch die Priorität 1, während die Standardrichtlinie auf die Priorität »niedrigste« herabgestuft wird, um sicherzustellen, dass jegliche benutzerdefinierte E-Mail-Adressrichtlinie Vorrang erhält. Abbildg. 6.13
Die nach Priorität aufgelisteten E-Mail-Adressrichtlinien eines Unternehmens
Erstellen einer neuen E-Mail-Adressrichtlinie Exchange funktioniert auch dann durchaus zufriedenstellend, wenn nichts anderes als die StandardE-Mail-Adressrichtlinie festgelegt wird, denn da jedem neuen Objekt ein eindeutiger Alias zugewiesen wird, ist sichergestellt, dass auch die resultierende E-Mail-Adresse eindeutig ist. Die meisten Unternehmen verwenden jedoch unterschiedliche Konventionen für das Generieren von E-Mail-Adressen, die über alle E-Mail-Systeme der Firma hinweg genutzt werden. Durch die Möglichkeit benutzerdefinierter E-Mail-Adressrichtlinien, die sich entweder nur auf einen Teil oder auf das gesamte Unternehmen anwenden lassen, bietet Exchange die Flexibilität, jederzeit passende E-Mail-Adressen erstellen und anwenden zu können. E-Mail-Adressrichtlinien generieren standardmäßig Adressen im SMTP-Format, Sie können jedoch auch Adressen für zahlreiche andere E-Mail-Systeme wie Lotus Notes oder Novell GroupWise einrichten. Klicken Sie im Aktionsbereich auf Neue E-Mail-Adressrichtlinie. Exchange startet den Assistenten zum Erstellen einer neuen E-Mail-Adressrichtlinie (siehe Abbildung 6.14).
309
Verwalten von E-Mailaktivierten Empfängern
E-Mail-Adressrichtlinien
Kapitel 6 Abbildg. 6.14
Verwalten von E-Mail-aktivierten Empfängern
Erstellen einer neuen E-Mail-Adressrichtlinie
Benennen Sie zunächst die Richtlinie und entscheiden Sie, auf welche Objekte sie angewendet werden soll. Der Gültigkeitsbereich lässt sich auf drei Arten festlegen: 1. Sie können eine Organisationseinheit in Active Directory wählen, die Exchange als -Stammver-
zeichnis für die Suche nach passenden Objekten verwenden wird. Wenn Sie das Feld für den Empfänger leer lassen, wendet Exchange die Richtlinie auf alle passenden Objekte im Unternehmen an. In diesem Fall haben wir eine Organisationseinheit mit dem Namen IT gewählt, da wir hier eine E-Mail-Adressrichtlinie für Mitglieder der IT-Abteilung erstellen. 2. Sie können die Richtlinie auf ausgewählte Empfängertypen von Postfächern über Gruppen bis hin zu Ressourcenpostfächern beschränken. 3. Im zweiten Fenster des Assistenten können Sie zusätzliche Kriterien festlegen, die Exchange bei der Suche nach dem angegebenen Zielobjekt berücksichtigen soll (siehe Abbildung 6.15). In diesem Beispiel haben wir uns dafür entschieden, eines der 15 benutzerdefinierten Attribute für E-Mailaktivierte Objekte zu verwenden und festzulegen, dass nach allen Objekten gesucht werden soll, die in CustomAttribute6 die Zeichenfolge IT aufweisen. Die hier verfügbaren Kriterien entsprechen denen, die Sie auch bei dynamischen Verteilergruppen nutzen (mehr dazu im Abschnitt »Dynamische Verteilergruppen« weiter hinten im Kapitel) – mit einer Ausnahme: Sie können eigene LDAPbasierte Abfragen nur mit den im Assistenten verfügbaren Objekteigenschaften erstellen. In der Praxis stellt dies jedoch keine Einschränkung dar, da die hier vorhandenen Eigenschaften mehr als genügend Flexibilität bieten.
310
E-Mail-Adressrichtlinien
Festlegen der Kriterien für eine neue E-Mail-Adressrichtlinie
Verwalten von E-Mailaktivierten Empfängern
Abbildg. 6.15
Der nächste Schritt im Assistenten besteht darin, zu entscheiden, welches E-Mail-Adressformat die Richtlinie für die anhand der Suchkriterien gefundenen Objekte erstellen soll. Sie können eine oder mehrere E-Mail-Adressen hinzufügen lassen. So soll vielleicht eine benutzerfreundliche Adressversion wie [email protected] und eine andere für interne Weiterleitungszwecke erstellt werden. Dies ist eine recht gängige Praxis in Firmen, die mehrere E-Mail-Systeme unterhalten und mit FrontEnd-Servern arbeiten, um den Strom von E-Mails aus dem Internet zu filtern und anschließend die Nachrichten an die passenden Hub-Transport-Server der jeweiligen Empfänger-E-Mail-Systeme weiterzuleiten. Sinnvoll ist diese Vorgehensweise auch, wenn jeder Mitarbeiter einer Firma standardmäßig sowohl eine benutzerfreundliche E-Mail-Adresse für externe Zwecke als auch eine für interne Zwecke zugeteilt bekommen soll. So könnte die eine Adresse [email protected] lauten und die andere [email protected]. Die erste Variante eignet sich gut für Visitenkarten, während die zweite einige interne Informationen enthält, die nicht für betriebsfremde Personen bestimmt sind. Fusionen, Akquisen und Umfirmierungen bilden weitere Situationen, in denen mehrere E-MailAdressen erforderlich sein können. TIPP E-Mail-Adressrichtlinien sind dazu geeignet, diese und andere Situationen reibungslos zu bewältigen. Das Einzige, worum Sie sich im Vorfeld kümmern müssen, ist die Erstellung eines Eintrags für jede akzeptierte Domäne, die Sie für E-Mail-Adressen nutzen möchten. Wenn Sie beispielsweise die Domänen contoso.com und contoso-europe.com verwenden möchten, so müssen Exchange beide als akzeptierte Domänen bekannt sein, bevor sie für E-Mail-Adressen genutzt werden können. Die Domäne, die Sie bei der Installation von Exchange verwenden, fällt nicht unter diese Regelung, da der Vorgang der Bekanntmachung als akzeptierte Domäne Teil des Installationsprozesses ist.
311
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Abbildung 6.16 zeigt die Optionen, die für das Festlegen des E-Mail-Adressformats verfügbar sind. Sie reichen für Adressen, die aus englischen oder deutschen Vor- und Zunamen bestehen, völlig aus, können jedoch zu Schwierigkeiten bei Namen aus anderen Sprachen führen. Anderssprachige Versionen von Exchange bieten Alternativen an, darunter die Möglichkeit, mithilfe der in Tabelle 6.4 aufgelisteten Variablen eine benutzerdefinierte Maske für die Adresse einzurichten. Hierzu können Sie die ExchangeVerwaltungsshell nutzen, indem Sie die Maske entweder beim Erstellen einer neuen E-Mail-Adressrichtlinie (mit New-EmailAddressPolicy) konfigurieren oder eine bestehende E-Mail-Adressrichtlinie mithilfe von Set-EmailAddressPolicy anpassen. Abbildg. 6.16
Festlegen des Adressformats für E-Mail-aktivierte Objekte
Tabelle 6.4
Maskenvariablen für E-Mail-Adressrichtlinien
312
Variable
Wert
%g
Vorname
%i
Mittelinitiale
%s
Nachname
%d
Anzeigename
%m
Exchange-Alias
%xs
Verwendet »x« Buchstaben des Nachnamens. Wenn z. B. der Nachname Schmitt lautet und die Variable %2s, fügt Exchange »Sc« ein.
%xg
Verwendet »x« Buchstaben des Vornamens. Wenn z. B. der Vorname »Ariane« lautet und die Variable %3g, fügt Exchange »Ari« ein.
Den soeben erläuterten Verwaltungsshell-Befehl zum Erstellen der neuen E-Mail-Adressrichtlinie sehen Sie im folgenden Beispiel. Der Filter bewirkt, dass die Richtlinie auf jeden Benutzer angewendet wird, der über ein Postfach verfügt. Das in Abbildung 6.16 gewählte E-Mail-Adressformat wird mit dem Parameter -EnabledEmailAddressTemplate festgelegt. New-EmailAddressPolicy -Name 'IT Department' -RecipientContainer 'contoso.com/IT' -IncludedRecipients 'MailboxUsers' –ConditionalCustomAttribute6 'IT' -Priority '1' -EnabledEmailAddressTemplates 'SMTP:%g.%[email protected]'
Den resultierenden Filter, der in der Richtlinie gespeichert wird, sehen Sie im folgenden Beispiel. Es handelt sich dabei immer noch um einen vordefinierten Filter, da er auf einem eingeschränkten Satz von Eigenschaften basiert. Name RecipientFilter
: IT Department : ((CustomAttribute6 -eq 'IT') -and (RecipientType -eq 'UserMailbox')) LdapRecipientFilter : (&(extensionAttribute6=IT)(objectClass=user) (objectCategory=person)(mailNickname=*) (msExchHomeServerName=*)) LastUpdatedRecipientFilter : ((CustomAttribute6 -eq 'IT') -and (RecipientType -eq 'UserMailbox')) RecipientFilterApplied : True RecipientContainer : contoso.com/IT RecipientFilterType : Precanned ExchangeVersion : 0.1 (8.0.535.0)
Der Filter entspricht erwartungsgemäß unseren Eingaben im Assistenten und sucht nach allen Postfächern, deren Eigenschaft CustomAttribute6 den Wert IT aufweist und die in der Organisationseinheit IT (oder einer beliebigen untergeordneten Organisationseinheit) gespeichert sind.
Erstellen von E-Mail-Adressrichtlinien mit benutzerdefinierten Filtern Ist der Assistent nicht in der Lage, einen hinreichend exakten Filter für eine E-Mail-Adressrichtlinie zu erstellen, so können Sie mithilfe des Cmdlets New-EmailAddressPolicy eine E-Mail-Adressrichtlinie mit einem benutzerdefinierten Filter anlegen. In diesem Fall gelten dieselben Syntaxregeln wie beim Einrichten von Empfängerfiltern für dynamische Verteilergruppen, sodass Sie also sehr flexible Filter zusammenstellen können. Nehmen wir zum Beispiel an, Sie möchten eine E-Mail-Adressrichtlinie ausschließlich für Postfachbenutzer in der Zweigstelle in Dublin einrichten. Dazu könnten Sie mithilfe von New-EmailAddressPolicy zuerst die neue Richtlinie erstellen und sie dann sofort mithilfe von Update-EmailAddressPolicy anwenden. Damit Exchange aber den hier für die Vorlage der primären SMTP-Adresse (@dublin.contoso.com) verwendeten Wert akzeptiert, müssen Sie diese Domäne zuerst als akzeptierte Domäne für das Unternehmen anlegen. New-EmailAddressPolicy –Name 'Dublin Office Users' –RecipientFilter {Office –eq 'Dublin' –and RecipientTypeDetails –eq 'UserMailbox'}
313
Verwalten von E-Mailaktivierten Empfängern
E-Mail-Adressrichtlinien
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
–EnabledPrimarySMTPAddressTemplate 'SMTP:@dublin.contoso.com' Update-EmailAddressPolicy –id 'Dublin Office Users'
Im Gegensatz zu den bisher betrachteten E-Mail-Adressrichtlinien verfügen auf diese Weise erstellte Richtlinien über einen benutzerdefinierten Empfängerfilter. Allerdings können Sie solche Richtlinien später nicht mehr mithilfe des Assistenten der Verwaltungskonsole ändern. Müssen Sie den Empfängerfilter im Nachhinein anpassen, ist dies nur möglich, indem Sie einen neuen Empfängerfilter über den Befehl Set-EmailAddressPolicy erstellen. Es lohnt sich, einen Blick auf eine benutzerdefinierte E-Mail-Adressrichtlinie zu werfen, um sich den Unterschied zwischen benutzerdefinierten und »gewöhnlichen« Richtlinien klarzumachen. Ein Blick auf die Einzelheiten der soeben erstellten Richtlinie zeigt, dass Exchange den passenden LDAP-Filter generiert hat und dass der Filtertyp (RecipientFilterType) nun Custom lautet, der Filter also benutzerdefiniert ist. Get-EmailAddressPolicy –Identity 'Dublin Office Users' | Select Name, *Filter* Name RecipientFilter 'UserMailbox') LdapRecipientFilter
: Dublin Office users : (Office -eq 'Dublin' -and RecipientTypeDetails -eq
: (&(physicalDeliveryOfficeName=Dublin) (objectClass=user)(objectCategory=person)(mailNickname=*) (msExchHomeServerName=*)(msExchRecipientTypeDetails=1)) LastUpdatedRecipientFilter : (Office -eq 'Dublin' -and RecipientTypeDetails -eq 'UserMailbox') RecipientFilterApplied : True RecipientFilterType : Custom
Festlegen der Priorität einer E-Mail-Adressrichtlinie Sobald Sie eine neue E-Mail-Adressrichtlinie erstellen, erhält sie automatisch die höchste Priorität. Dies ist jedoch oft nicht korrekt, da Richtlinien, die anhand von gezielten Kriterien zugewiesen werden, in der Regel vor sämtlichen allgemeinen oder Standardrichtlinien zur Anwendung kommen sollen. Sie können der neuen E-Mail-Adressrichtlinie daher die richtige Priorität zuordnen, indem Sie sie auswählen und im Aktionsbereich auf Priorität ändern klicken (Abbildung 6.17). Abbildg. 6.17
Ändern der Priorität einer E-Mail-Adressrichtlinie
Anschließend können Sie einen Wert innerhalb des angegebenen Bereichs zuweisen. Sind zum Beispiel drei benutzerdefinierte Richtlinien verfügbar, können Sie eine Priorität zwischen 1 und 3 wählen, bei sechs Richtlinien zwischen 1 und 6 usw. Der Wert »niedrigste« steht nicht zur Auswahl, da er für die Standardrichtlinie reserviert ist. Nachdem Sie eine neue Priorität gewählt haben, verschiebt 314
Exchange die Richtlinie an die richtige Position und ordnet die anderen Richtlinien entsprechend an. Der entsprechende Verwaltungsshell-Befehl lautet: Set-EmailAddressPolicy –Identity 'IT Department' -Priority '1'
Nachdem Sie die Priorität einer Richtlinie angepasst haben, sollten Sie im Aktionsbereich auf Anwenden klicken, um Exchange dazu zu bringen, nach Objekten zu suchen, die in den Gültigkeitsbereich der Richtlinie fallen, und neue E-Mail-Adressen für sie zu erstellen (falls noch keine vorhanden sind). Anschließend werden die neuen E-Mail-Adressen zu den Hauptadressen für die jeweiligen Objekte, während alle vorherigen Adressen aufbewahrt werden, sodass Exchange auch Nachrichten, die dorthin gesandt wurden, weiterhin zustellen kann. Sie können festlegen, ob Exchange die neue E-Mail-Adressrichtlinie sofort anwenden oder auf einen passenden Zeitpunkt dafür warten soll. Im letzteren Fall legt die Verwaltungskonsole eine Pause ein und führt den Befehl erst zum festgelegten Zeitpunkt aus. Eine neue E-Mail-Adressrichtlinie auf Tausende von Objekten anzuwenden, kann lange dauern, zahlreiche Active Directory-Transaktionen nach sich ziehen und darüber hinaus aufgrund der großen Zahl an Aktualisierungen im Verzeichnis einen vollständigen Offlineadressbuch-Download für sämtliche Clients notwendig machen. Es empfiehlt sich daher, benötigte E-Mail-Adressrichtlinien im Rahmen einer Bereitstellung frühzeitig anzulegen, und so die Auswirkungen einer umfassenden Aktualisierung später in der Produktion zu vermeiden. Manchmal ist es unumgänglich, eine große Anzahl von Empfängern zu ändern, um sicherzustellen, dass sie E-Mail-Adressen des richtigen Typs erhalten. Die E-Mail-Adressrichtlinie, die wir im vorherigen Beispiel für die IT-Abteilung erstellt haben, kommt nur bei Empfängern zur Anwendung, die in der Organisationseinheit IT gespeichert sind. Exchange wendet die neu erstellte Richtlinie auf die Empfänger an, die sich bereits in der Organisationseinheit befinden. Wenn wir jedoch zu einem späteren Zeitpunkt weitere Empfänger hinzufügen (die vielleicht zwischenzeitlich der IT-Abteilung beigetreten sind), müssen wir deren Adressen anpassen. Sie können diesen Vorgang mit einem Befehl wie dem folgenden über die Verwaltungsshell starten. Beachten Sie jedoch, dass das Cmdlet UpdateEmailAddressPolicy keine Möglichkeit bietet, einen bestimmten Zeitpunkt für die Änderung einzustellen. Falls Sie dies aber möchten, können Sie die Ausführung des Cmdlets mit einem passenden Zeitplanungsprogramm steuern. Update-EmailAddressPolicy -Identity 'IT Department'
Virtuelle Listenansicht für Exchange-Adresslisten Exchange Server 2010 bietet die neue virtuelle Listenansicht für Adresslisten. In Active Directory gibt es diese seit Windows Server 2003 ebenfalls, und zwar für Suchvorgänge. Die virtuelle Listenansicht ermöglicht es Anwendungen – wie etwa Verzeichnisdiensten –, Clientanforderungen, die sehr große Ergebnissätze generieren, rationeller zu verarbeiten, indem sie sie in die Lage versetzt, eine Teilmenge des Gesamtergebnisses anzuzeigen, ohne dazu alle passenden Einträge abrufen zu müssen. Wenn Sie beispielsweise Active Directory nach allen Empfängern in einem großen Unternehmen durchsuchen, so enthält der Ergebnissatz wahrscheinlich Tausende von Einträgen. Die virtuelle Listenansicht ermöglicht es der Anwendung, zuerst nur die erste Gruppe von passenden Einträgen (zum Beispiel 100) zu durchsuchen und mit der nächsten Gruppe erst dann fortzufahren, wenn der Client weitere Daten benötigt. Exchange Server 2010 nutzt die virtuelle Listenansicht, um einen ökonomischeren Zugriff auf die Empfängerdatensätze zu ermöglichen.
315
Verwalten von E-Mailaktivierten Empfängern
E-Mail-Adressrichtlinien
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Exchange setzt standardmäßig das Attribut IsAddressListPagingEnabled in der Organisationskonfiguration, um anzuzeigen, dass die Nutzung der virtuellen Listenansicht möglich ist. Sie können dieses Attribut folgendermaßen überprüfen: Get-OrganizationConfig | Select IsAddressListPagingEnabled
Ist es auf True gesetzt, verwendet Exchange die virtuelle Listenansicht im Cmdlet Get-Recipient. Die Exchange-Verwaltungskonsole macht extensiven Gebrauch von diesem Cmdlet, um Empfängerdaten abzurufen und Einzelheiten über Postfächer, Verteilergruppen usw. anzuzeigen. Auch wenn es wahrscheinlich niemals nötig sein wird, können Sie die virtuelle Listenansicht deaktivieren, indem Sie Disable-AddressListPaging ausführen. In diesem Fall nimmt Exchange das Verhalten von Exchange Server 2007 an und ruft nur vollständige Ergebnissätze ab, wodurch sich Suchvorgänge länger hinziehen können. Um das Attribut wieder zurückzusetzen, führen Sie Enable-AddressListPaging aus. Hierdurch wird nicht nur das Attribut IsAddressListPagingEnabled zurück auf True gesetzt, sondern es werden auch die vordefinierten Systemadresslisten wie »Alle Räume« und »Alle Empfänger« neu erstellt. Somit können Sie mit diesem Cmdlet auch diese Adresslisten reparieren, sollten sie einmal beschädigt werden. Hinter den Kulissen wird das Attribut IsAddressListPagingEnabled durch einen Boole'schen Wert namens msExchAddressListPagingEnabled des Objekts msExchOrganizationContainer repräsentiert.
Discoverysuchpostfächer Discoverysuchpostfächer dienen als Ablage für die Metadaten, welche die Discoverysuchvorgänge sowie die hierdurch aus den Benutzerpostfächern generierten Ausgaben steuern. Discoverysuchpostfächer können keine E-Mails empfangen. Bei der Installation von Exchange Server 2010 werden zwei unterschiedliche Arten von Discoverysuchpostfächern angelegt. Das erste ist das Discoverysuchpostfach für Metadaten, das Informationen über abgeschlossene und laufende Suchvorgänge enthält. Erst wenn dieses Postfach mit dem festen Namen SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} online und verfügbar ist, können Discoverysuchen durchgeführt werden. Es wird als Vermittlungspostfach angelegt und lässt sich mit dem folgenden Befehl finden: Get-Mailbox –Arbitration
Die zweite Art ist ein Discoverysuchpostfach, das dazu dient, die im Rahmen von Discoverysuchen kopierten Objekte zu speichern, sodass später zur Prüfung von berechtigten Benutzern darauf zugegriffen werden kann. Ein einzelnes Discoverysuchpostfach wird bei der Installation angelegt und ist für alle Mitglieder der Rollengruppe Discovery Management zugänglich. Diese Benutzer sind berechtigt, auf das Standard-Discoverypostfach zuzugreifen, um dessen Inhalte prüfen zu können. Wenn Sie weitere Discoverysuchpostfächer erstellen, müssen Sie den Konten, die diese Postfächer für Postfachsuchen nutzen sollen, eine Vollzugriffsberechtigung einräumen. Wie im Folgenden erklärt, können Sie nach Bedarf weitere Discoverysuchpostfächer anlegen. Discoverysuchpostfächer werden in der Verwaltungskonsole angezeigt, sodass Sie ihre Eigenschaften einsehen (siehe Abbildung 6.18) und andere postfachspezifische Operationen wie das Verschieben zwischen Datenbanken vornehmen können. Das Kontrollkästchen Exchange-Adresslisten ausblenden sollte aktiviert sein, denn indem Sie die Anzeige von Discoverysuchpostfächern in der globalen Adressliste unterdrücken, vermeiden Sie, dass Benutzer versuchen, E-Mails an diese Postfächer zu schicken.
316
Discoverysuchpostfächer
Eigenschaften des Standard-Discoverysuchpostfachs
Verwalten von E-Mailaktivierten Empfängern
Abbildg. 6.18
Sie können sämtliche Discoverysuchpostfächer im Unternehmen mithilfe der Verwaltungsshell finden, indem Sie den folgenden Befehl verwenden: Get-Mailbox –RecipientTypeDetails DiscoveryMailbox Name ---DiscoverySearchMailbox... EMEA Legal Searches
Alias ----DiscoverySearchMa... EMEASearches
ServerName ---------ExServer1 ExServer2
ProhibitSendQuota ---------------50 GB (53,687,091,200 bytes) 50 GB (53,687,091,200 bytes)
Beachten Sie, dass es sich bei dem unter ServerName angezeigten Server nicht um den Host des Postfachs handelt, sondern um den der Datenbank, in der das Postfach ursprünglich erstellt wurde. Um den Server zu finden, der zurzeit als Host für das Discoverysuchpostfach fungiert, müssen Sie zuerst den Datenbanknamen mithilfe von Get-Mailbox abrufen und dann den aktuellen Server mit GetMailboxDatabase. Bei der Installation von Exchange werden die Standard-Vermittlungspostfächer in der Organisationseinheit Users der Stammdomäne erstellt. Aus diesem Grund müssen Sie, sofern Sie nicht bei der Stammdomäne angemeldet sind, möglicherweise den korrekten Active Directory-Gültigkeitsbereich festlegen, um diese Postfächer zu finden. Set-ADServerSettings -ViewEntireForest $True Get-Mailbox –Arbitration
317
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Erstellen zusätzlicher Discoverysuchpostfächer Exchange erstellt das Standard-Discoverysuchpostfach in der Postfachdatenbank des ersten Exchange Server 2010-Postfachservers, den Sie bereitstellen. Das mag für kleinere Bereitstellungen akzeptabel sein, kann sich jedoch bei größeren Unternehmen als problematisch erweisen, in denen der durch eine Discoverysuche generierte Datenumfang sehr groß sein kann, sowohl was die Anzahl von Objekten als auch was den benötigten Speicher betrifft. Speicher sollte allerdings kein Problem darstellen, da dem Discoverysuchpostfach standardmäßig ein Kontingent von 50 GB zugeteilt wird. Bedenken Sie jedoch, dass der Postfachserver, auf dem die Datenbank mit dem Discoverysuchpostfach gespeichert ist, viel leisten muss, um die Objekte zu kopieren, die bei einer Suche zutage gefördert werden. Werden beispielsweise 10.000 Objekte gefunden, die zusammen 6 GB an Speicher einnehmen, muss der Server in der Lage sein, die Arbeitslast zu bewältigen, die mit dem Kopieren und Speichern dieser Objekte einhergeht. Die Arbeitslast setzt sich zusammen aus den während der Suche verbrauchten CPU-Ressourcen sowie dem notwendigen Speicher für die gefundenen Objekte und den Transaktionsprotokollen, die beim Erstellen der gefundenen Objekte im Discoverysuchpostfach generiert werden. Eine Suche wird unter Umständen mehrere Male durchgeführt, bis die endgültigen Informationen erfasst sind, wobei der Server jedes Mal belastet wird. Aus diesem Grund müssen Sie sich über folgende Punkte Gedanken machen: 1. Die Anzahl der im Unternehmen erstellten und verfügbaren Discoverysuchpostfächer.
In der Regel reicht in kleinen Firmen eines aus, es kann jedoch sinnvoll sein, auf unterschiedlichen Servern eine Reihe von Discoverysuchpostfächern zu erstellen, die dann von verschiedenen Teams für Suchvorgänge genutzt werden können. 2. Der Standort der Discoverysuchpostfächer. Idealerweise sollten sich die durchsuchten Postfächer, die Benutzer, die den Suchvorgang durchführen, und die Datenbank, die als Host für das Zieldiscoverysuchpostfach dient, am selben Standort befinden, da so der Bedarf an erweiterten Netzwerkverbindungen zum Suchen, Speichern und Überprüfen von Informationen entfällt. In jedem Fall müssen Sie sicherstellen, dass der Server, der die Datenbank mit dem Discoverysuchpostfach enthält, über genügend Kapazitäten verfügt, um die durch Suchvorgänge entstehende Belastung bewältigen zu können. Benutzer, die der Rollengruppe Discovery Management angehören, dürfen Suchvorgänge durchführen. Zum Erstellen einer Suchanforderung gehört unter anderem die Auswahl des Discoverysuchpostfachs, welches das Ergebnis der Suche enthalten soll. Da sie möglicherweise große Mengen an Daten aufnehmen müssen, die bei einer Suche anfallen, verfügen Discoverysuchpostfächer standardmäßig über ein Speicherkontingent von 50 GB. Nachdem die Daten eines Suchvorgangs erfasst wurden, müssen die Benutzer vollen Zugriff auf das Discoverysuchpostfach erhalten, um es öffnen und auf die Suchergebnisse zugreifen zu können. Wie Sie dies erreichen, erfahren Sie im Abschnitt »Verwalten der Vollzugriffsberechtigung« weiter hinten im Kapitel. Sie können weitere Discoverysuchpostfächer einrichten, indem Sie das Cmdlet New-Mailbox mit der Option -Discovery verwenden: New-Mailbox 'Legal Action Discovery Mailbox' –UserPrincipalName '[email protected]' –Discovery
Wenn Sie versuchen, eine Postfachdatenbank mit Discoverysuchpostfächern zu löschen, gibt Exchange eine Fehlermeldung zurück, die besagt, dass Sie die enthaltenen Postfächer zuerst verschieben müssen, bevor Sie die Datenbank entfernen können. Verschieben Sie das Discoverysuchpostfach mit dem Cmdlet New-MoveRequest und das Discoverysuchpostfach für Metadaten mit der Verwal-
318
tungskonsole. Der Grund für die Aufteilung dieser Operationen zwischen der Verwaltungsshell und der Verwaltungskonsole liegt darin, dass in der Verwaltungskonsole nur das Discoverysuchpostfach für Metadaten angezeigt wird, nicht aber das eigentliche Discoverysuchpostfach. Der folgende Beispielbefehl verschiebt das Discoverysuchpostfach in eine andere Datenbank: New-MoveRequest -Identity 'SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}' -TargetDatabase 'DB1'
TIPP Stellen Sie nach dem Anlegen eines neuen Discoverysuchpostfachs sicher, dass Sie den Gruppen, die auf die darin enthaltenen Suchergebnisse zugreifen müssen, eine Vollzugriffsberechtigung einräumen. Standardmäßig hat das Administratorkonto Zugriff auf das StandardDiscoverysuchpostfach, jedoch müssen auch alle anderen Personen, die damit arbeiten müssen, eine entsprechende Zugriffsberechtigung erhalten.
Einrichten von Postfachberechtigungen Die Möglichkeit, die Verarbeitung von Nachrichten in einem Postfach zu steuern, stellt schon seit langem eine grundlegende Funktion von E-Mail-Systemen dar. Exchange ermöglicht es Ihnen, den Benutzern einen unterschiedlichen Grad der Kontrolle über Postfächer einzuräumen, um zu steuern, wie Nachrichten an ein Postfach übermittelt werden, wer E-Mails von einem anderen Postfach aus bzw. im Auftrag eines Postfachbesitzers senden darf (hier gibt es einen Unterschied) und wer die volle Kontrolle über ein Postfach hat. Diese Einstellungen lassen sich durch Ändern der Postfacheigenschaften vornehmen, entweder über die Einstellungen für die E-Mail-Übertragung oder durch Zuweisen unterschiedlicher Active Directory-Berechtigungen, um anderen Konten den Zugriff auf das Postfach zu ermöglichen.
Einstellungen für die E-Mail-Übertragung Die Exchange-Verwaltungskonsole bietet in der Registerkarte Nachrichtenübermittlungseinstellungen der Postfacheigenschaften den Punkt Zustellungsoptionen. Wenn Sie deren Eigenschaften aufrufen, bieten sich Ihnen die drei folgenden Möglichkeiten (siehe Abbildung 6.19): 쐍 Erstens können Sie die Berechtigung Senden im Auftrag von vergeben. Dadurch wird es einem anderen Benutzer ermöglicht, eine Nachricht im Auftrag eines Postfachbesitzers zu senden. Exchange weist hierbei deutlich darauf hin, dass die entsprechende Nachricht durch einen Benutzer im Auftrag eines anderen erstellt wurde. Somit unterscheidet sich diese Nachrichten klar von solchen, die mit der Berechtigung Senden als verschickt werden. Outlook-Benutzer können dieselbe Berechtigung auf andere Benutzer übertragen. Diese Möglichkeit der E-Mail-Übertragung wird zum Beispiel häufig von Sekretariatsmitarbeitern genutzt, die andere Benutzer bei deren Arbeit unterstützten. TIPP Bevor Sie von einer neu eingestellten Zugriffsberechtigung Gebrauch machen, sollten Sie etwa eine Stunde abwarten, bis Exchange seinen Informationsspeicher-Cache mit Informationen aus Active Directory aktualisiert hat. Die Berechtigung Senden als lässt sich erst anwenden, nachdem sie dem Speicher bekannt ist.
319
Verwalten von E-Mailaktivierten Empfängern
Einrichten von Postfachberechtigungen
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
쐍 Festlegen einer Weiterleitungsadresse Sie können Exchange anweisen, eingehende Nachrichten an ein anderes Postfach weiterzuleiten. Optional können Sie außerdem dafür sorgen, dass Kopien der eingehenden E-Mails sowohl an das ursprüngliche Empfängerpostfach als auch an das Weiterleitungspostfach gesendet werden. 쐍 Festlegen der maximalen Anzahl von Empfängern Sie können die Anzahl der Empfänger beschränken, an die ein Benutzer Nachrichten senden darf. Eine Gruppe zählt hierbei als einzelner Empfänger. Diese Einstellung hat Vorrang vor jeglichen Einstellungen für Empfängergrenzwerte auf Hub-Transport-Servern. Abbildg. 6.19
Ändern der Einstellungen für die E-Mail-Übertragung
Der entsprechende Verwaltungsshell-Befehl für die Anwendung dieser Einstellungen lautet: Set-Mailbox -Identity 'Redmond, Tony'-ForwardingAddress 'CEO Executive Assistant' -GrantSendOnBehalfTo 'CEO Executive Assistant' –RecipientLimits 500
Wenn Sie die Berechtigung Senden im Auftrag von mehreren Postfächern gleichzeitig einräumen müssen, können Sie einfach eine Liste der betreffenden Postfächer an den Parameter -GrantSendOnBehalfTo übergeben: Set-Mailbox –Identity 'Redmond, Tony' –GrantSendOnBehalfTo 'CEO Executive Assistant', 'Pelton, David', 'Akers, Kim'
Neben Postfächern können Sie die Berechtigung, Nachrichten im Auftrag eines anderen Benutzers zu senden, auch Verteilergruppen, dynamischen Verteilergruppen und E-Mail-aktivierten Kontakten gewähren. Dies müssen Sie über die Verwaltungsshell erledigen, da die Verwaltungskonsole diese Option für diese Empfängertypen nicht bietet: Set-DistributionGroup –Identity 'Legal Department' –GrantSendOnBehalfTo 'Pelton, David'
320
Der Unterschied zwischen »Senden im Auftrag von« und »Senden als« Der Unterschied zwischen den Optionen Senden im Auftrag von und Senden als liegt im Grad der Identitätsübernahme beim Senden einer Nachricht. Bei Senden im Auftrag von wird klar, dass Inhalte im Auftrag einer anderen Person gesendet werden, und diese Option eignet sich, wenn hervorgehoben werden soll, dass ein Benutzer einen anderen bei der Bearbeitung von dessen E-Mails unterstützt. Bei Senden als hingegen erhält der Empfänger keinen gesonderten Hinweis darauf, dass zum Beispiel Sie die Nachricht gesendet haben, da diese offenbar von der Person oder Einrichtung stammt, die Sie repräsentieren. In der Regel kommt die Option Senden als bei funktionalen Postfächern zum Einsatz, die von ganzen Benutzergruppen verwendet werden, etwa bei einem Postfach zur Bearbeitung von Supportanfragen. Hinter den Kulissen transportiert Exchange bei der Option Senden im Auftrag von lediglich einige zusätzliche Informationen im Nachrichtenheader, sodass Clients den Namen des Benutzers anzeigen können, der die Nachricht tatsächlich verfasst hat, wenn diese vom Empfänger gelesen wird. Im Gegensatz dazu benötigt ein Benutzer bei der Option Senden als die Active Directory-Berechtigung, eine Nachricht mit der Identität eines anderen Benutzers zu senden. Normalerweise wird die Berechtigung Senden als mithilfe eines Assistenten der Verwaltungskonsolen zugewiesen. Wählen Sie zuerst das Postfach, dem Sie die Berechtigung zuweisen möchten, und anschließend im Aktionsbereich die Option Berechtigung »Senden als« verwalten. Im folgenden Dialogfeld des Assistenten können Sie die Benutzer auswählen, die das Postfach repräsentieren sollen (siehe Abbildung 6.20). Sie können während einer Sitzung im Assistenten so viele Benutzer hinzufügen und löschen wie nötig. Exchange speichert Berechtigungen im Cache, wobei es bis zu einer Stunde dauern kann, bis eine neue Berechtigung aktiv ist. Darüber hinaus müssen die Benutzer, denen die Berechtigung zugewiesen wird, eine neue Clientsitzung starten, bevor sie Nachrichten im Auftrag des Postfachs senden können. Abbildg. 6.20
Zuweisen der Berechtigung »Senden als« für ein Postfach
321
Verwalten von E-Mailaktivierten Empfängern
Einrichten von Postfachberechtigungen
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Der Vorgang der Nachrichtenübermittlung mit der Berechtigung Senden als unterscheidet sich von Client zu Client. Wird in OWA eine Nachricht im Auftrag eines anderen Benutzers gesendet, so taucht im Nachrichtenheader kein Hinweis auf den Namen des ursprünglichen Verfassers auf (siehe Abbildung 6.21). Die Option Senden als erlaubt es Ihnen also praktisch, E-Mails mit der Identität eines anderen Benutzers zu versenden. Abbildg. 6.21
Eine im Auftrag des Help Desks versandte Nachricht
Selbstverständlich können wir die Berechtigung Senden als einem Konto auch über die Verwaltungsshell zuweisen. Mit dem folgenden Code räume ich meinem Konto die Berechtigung für ein anderes Konto ein. Es werden definierte Namen verwendet, um die beiden Konten zu bezeichnen. Es ist wichtig, dass diese Werte korrekt eingegeben werden, da jegliche Abweichung – auch Leerzeichen zwischen Vor- und Nachname – dazu führt, dass die Verwaltungsshell das betreffende Active Directory-Objekt nicht finden kann. Add-AdPermission –Identity '[email protected]' –ExtendedRights 'Send-As' –User '[email protected]'
Um die Berechtigung wieder aufzuheben, verwenden Sie einen Befehl wie den folgenden: Remove-ADPermission -Identity '[email protected]' -User '[email protected]’ -InheritanceType 'All' -ExtendedRights 'Send-As' -ChildObjectTypes $Null -InheritedObjectType $Null -Properties $Null
Verwalten der Vollzugriffsberechtigung Indem Sie einem Postfach die Berechtigung Senden als zuweisen, ermöglichen Sie es dessen Besitzer zwar, mit der Identität eines anderen Benutzers zu agieren, gewähren ihm allerdings neben dem Recht, Nachrichten zu erstellen und zu senden, keinen weiteren Zugriff auf die Postfachinhalte. Um ein anderes Postfach öffnen und dessen Inhalte einsehen zu können, ist eine Vollzugriffsberechtigung erforderlich. Ein Beispiel für eine Situation, in der ein Benutzer diese Möglichkeit benötigt, ist die Durchführung von Discoverysuchen, da Exchange die Ausgabe solcher Suchvorgänge in (für jede
322
Suche einzeln ausgewählten) Discoverysuchpostfächern ablegt, die von dem betreffenden Benutzer zur Überprüfung geöffnet werden müssen. Dazu muss dieser jedoch zuerst von einem Administrator eine Vollzugriffsberechtigung für das Discoverysuchpostfach erhalten. Wie wir in diesem Kapitel bereits erfahren haben, kann ein Unternehmen, das mit Exchange arbeitet, über mehrere Discoverysuchpostfächer verfügen. Wählen Sie zuerst das Postfach, dem Sie die Berechtigung zuweisen möchten, und anschließend Berechtigung »Vollzugriff« verwalten im Aktionsbereich. Die Exchange-Verwaltungskonsole startet einen Assistenten (siehe Abbildung 6.22), in dem Sie die Konten und Gruppen auswählen können, welche die Berechtigung benötigen. Beachten Sie, dass sich die Sicherheitsgruppen Exchange Server und Exchange Trusted Subsystem bereits in der Liste der Benutzer und Gruppen befinden. Dies stellt sicher, dass Exchange auf die Discoverysuchpostfächer zugreifen kann, um Ergebnisse darin zu speichern. Abbildg. 6.22
Verwalten der Vollzugriffsberechtigung für ein Postfach
Hinter den Kulissen: Wenn die Verwaltungskonsole Berechtigungen zuweist
Hinter den Kulissen übernimmt das Cmdlet Add-MailboxPermission die Zuweisung. Um es anzuwenden, müssen Sie den Namen des Postfachs übergeben, dem Sie die Vollzugriffsberechtigung zuweisen möchten. Sie können dazu jeden der gültigen Bezeichner verwenden. Wenn die Verwaltungskonsole Berechtigungen zuweist, verwendet sie dazu den vollständigen definierten Namen des Postfachs. Dies hat den Vorteil, dass Sie absolut sicher sein können, mit dem richtigen Postfach zu arbeiten, was natürlich wichtig ist, wenn es um die Zuweisung von Berechtigungen geht. Der Nachteil ist, dass Sie bei der Eingabe von definierten Namen sehr sorgfältig sein müssen, da diese recht lang und komplex sein können (so ist zum Beispiel der definierte Name des Standard-Discoverysuchpostfachs ziemlich lang).
323
Verwalten von E-Mailaktivierten Empfängern
Einrichten von Postfachberechtigungen
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Wenn Sie andere Discoverysuchpostfächer anlegen, geben Sie ihnen höchstwahrscheinlich weniger obskure und somit leichter einzugebende Namen. Im folgenden Beispiel gewähren wir den Mitgliedern der Gruppe Discovery Management die Berechtigung FullAccess, also Vollzugriff, für ein neues Discoverysuchpostfach: Add-MailboxPermission -Identity 'CN=Legal Action Discovery Mailbox,CN=Users,DC=contoso,DC=com' -User 'CONTOSO\Discovery Management' -AccessRights 'FullAccess'
Um mehreren Postfächern oder Gruppen Berechtigungen zuzuweisen, müssen Sie den Befehl AddMailboxPermission mehrfach anwenden. Nachdem alle Berechtigungen für das Postfach zugewiesen sind, können wir sie wie im Folgenden gezeigt überprüfen. Die Ausgabe entspricht unseren Erwartungen. Die Gruppe Discovery Management befindet sich in der Liste der Berechtigungen, und noch einem weiteren Konto mit dem Namen »LegalTeam« wurde Zugriff eingeräumt. Sobald ein Benutzer über eine Vollzugriffsberechtigung verfügt, kann er das Postfach in OWA öffnen. Get-Mailbox –Identity 'Legal Action Discovery Mailbox' | Get-MailboxPermission | ? {$_.AccessRights –Like "FullAccess"} | Sort-Object Deny | Format-Table User, AccessRights, Deny, IsInherited –AutoSize User ---CONTOSO\Exchange Servers CONTOSO\Discovery Management CONTOSO\LegalTeam CONTOSO\Enterprise Admins CONTOSO\Domain Admins CONTOSO\Organization Management
AccessRights -----------{FullAccess} {FullAccess} {FullAccess} {FullAccess} {FullAccess} {FullAccess}
Deny ---False False False True True True
IsInherited -----------True False False True True True
Abgesehen von der Notwendigkeit, auf Inhalte von Discoverysuchpostfächern zuzugreifen, gibt es noch weitere Situationen, in denen die Vollzugriffsberechtigung üblicherweise zum Einsatz kommt, etwa, wenn sich mehrere Benutzer ein funktionales Postfach teilen. Wollen Sie beispielsweise einer Gruppe von Benutzern erlauben, ein Supportpostfach zu öffnen, sodass sie die an die Supportabteilung gerichteten Fragen einsehen können, so müssen Sie allen betreffenden Benutzern die Vollzugriffsberechtigung für das Postfach zuweisen. Die Möglichkeit, eine Zugriffsberechtigung einer ganzen Gruppe statt einzelnen Benutzerkonten zuweisen, erleichtert diesen Vorgang natürlich enorm. Insidertipp: Was bedeutet Vollzugriff wirklich?
Die Vollzugriffsberechtigung erlaubt es dem betreffenden Benutzer, sämtliche Inhalte eines Postfachs einzusehen, Nachrichtenentwürfe zu erstellen und zu speichern und dem Postfach weitere Inhalte hinzuzufügen. Sie berechtigt ihn allerdings nicht dazu, die Identität des Postfachs zu übernehmen und Nachrichten darüber zu senden. Auf diese Weise wird verhindert, dass eine Person auf ein gemeinsam genutztes Postfach zugreift und es zum Beispiel dazu nutzt, beleidigende oder unangemessene Nachrichten zu versenden, die so nicht auf den tatsächlichen Urheber zurückgeführt werden können. Der Begriff »Vollzugriff« wird häufig mit der Vorstellung verbunden, man könne mit dieser Berechtigung das entsprechende Postfach genauso nutzen wie dessen Besitzer. Um jedoch auch Nachrichten unter der Identität des jeweiligen Postfachs versenden zu können, wird zusätzlich die Berechtigung Senden als benötigt.
324
Bedenken Sie, dass der Informationsspeicher Berechtigungen für Postfächer zwischenspeichert, um die Leistung zu verbessern. Das bedeutet, dass es bis zu zwei Stunden dauern kann, bis eine Berechtigungsänderung (auf Vollzugriff oder Senden als) für ein Postfach in Kraft tritt. Leider gibt es nur zwei Möglichkeiten, dieses Problem zu umgehen. Sie können entweder den Informationsspeicherdienst neu starten, um eine Aktualisierung des Cachespeichers zu bewirken, oder Sie können das Intervall zwischen den Aktualisierungen verkürzen. Bei der ersten Lösung werden alle Clients dazu gezwungen, die Verbindung zu trennen, was sich während des Arbeitstages nicht unbedingt empfiehlt. Die zweite fordert dem Server zusätzliche Ressourcen für die Cache-Aktualisierung ab. Auch wenn einige Administratoren mit einer Verkürzung des Cacheintervalls auf 15 bis 20 Minuten gute Erfahrungen gemacht haben, so ist doch keine der beiden genannten Optionen sonderlich attraktiv. Daher ist es möglicherweise am besten, Geduld zu beweisen und zu warten, bis Exchange die geänderten Berechtigungen registriert hat, oder die Berechtigungen, falls möglich, zu einem Zeitpunkt zu aktualisieren (zum Beispiel Mitternacht), an dem sich die durch das Zwischenspeichern erzwungene Verzögerung nicht auf die Benutzer auswirken kann. Weitere Informationen darüber, wie Sie den Registrierungseintrag Reread Logon Quotas Interval ändern, um das Cacheintervall anzupassen, lesen Sie unter http://technet.microsoft.com/de-de/library/ bb684892(EXCHG.80).aspx.
Senden von Nachrichten im Auftrag anderer Benutzer Falls Sie das Senden von Nachrichten im Auftrag anderer Benutzer ermöglichen wollen, sollten Sie das Feld Von der Client-Benutzerschnittstelle aktivieren, sodass die Benutzer das Postfach wählen können, von dem aus sie eine Nachricht senden möchten. In OWA können Sie dieses Feld in den E-Mail-Einstellungen aktivieren, indem Sie auf der Registerkarte E-Mail im Abschnitt Nachrichtenformat auf das Kontrollkästchen Absender immer anzeigen klicken. Falls Sie das Steuerlement S/MIME heruntergeladen haben, wird eine Warnung angezeigt, dass bei Verwendung dieser Option keine S/MIMENachrichten gesendet werden können. Das liegt daran, dass S/MIME auf der Basis von persönlichen digitalen Signaturen arbeitet, die nicht gemeinsam genutzt oder durch andere Benutzer neu verwendet werden können. Wenn Sie also eine Nachricht im Auftrag eines anderen Benutzers senden, können Sie keine digitale Signatur darauf anwenden oder sie verschlüsseln. Sobald das Feld Von aktiviert ist, kann der Benutzer das E-Mail-Konto wählen, von dem aus er seine Nachricht senden möchte, indem er auf den Menüpfeil rechts neben der Beschriftung klickt. Er bekommt eine Dropdownliste angezeigt, in der sein eigenes Konto an erster Stelle steht (siehe Abbildung 6.23), und kann dann die Option Andere E-Mail-Adresse wählen, woraufhin das OWA-Dialogfeld Zur Kontoauswahl angezeigt wird, in dem ein anderes Postfach gewählt werden kann. Alternativ kann in das Von-Feld auch direkt der Name eines E-Mail-aktivierten Empfängers eingegeben werden, in dessen Auftrag E-Mails gesendet werden dürfen. Wird ein Postfach gewählt, für das der Benutzer keine Berechtigung zum Senden von E-Mails hat, gibt OWA eine Fehlermeldung aus und sendet die Nachricht nicht ab. Antwortet ein Empfänger auf eine Nachricht, die im Auftrag eines anderen Benutzers gesendet wurde, so sendet Exchange die Antwort an das Postfach des Benutzers, in dessen Namen die Nachricht verschickt wurde.
325
Verwalten von E-Mailaktivierten Empfängern
Einrichten von Postfachberechtigungen
Kapitel 6 Abbildg. 6.23
Verwalten von E-Mail-aktivierten Empfängern
Auswählen eines Postfachs, in dessen Auftrag eine Nachricht gesendet werden soll
Der Vorgang zur Aktivierung des Feldes Von, um Nachrichten im Auftrag anderer Benutzer senden zu können, unterscheidet sich je nach verwendeter Outlook-Version, sodass es sich empfiehlt, einen Blick in die Dokumentation Ihrer Version zu werfen. Möglicherweise steht die Option in anderen E-MailClients nicht zur Verfügung.
Öffnen der Postfächer anderer Benutzer Sobald Sie die Vollzugriffsberechtigung für ein anderes Postfach erhalten haben, können Sie es Ihrem Outlook-Profil hinzufügen, sodass es neben Ihrem eigenen Postfach geöffnet wird. Um die beiden Postfächer deutlich voneinander zu trennen, können Sie alternativ ein separates Profil anlegen, das mit dem neuen Zielpostfach verbunden ist, und es beim Öffnen von Outlook auswählen. OWA verwendet keine Profile, bietet jedoch drei Möglichkeiten, auf die Inhalte eines anderen Postfachs zuzugreifen: 쐍 Öffnen Sie nur den Ordner Posteingang des anderen Postfachs. Diese Option eignet sich vor allem für Personen, die auf Nachrichten in einem gemeinsam genutzten Postfach für eine bestimmte Funktion (z.B. den Support) zugreifen müssen. Um die Option auszuwählen und den Postfachnamen in den Posteingangsordner einzufügen (mit (Ctrl) + (K) können Sie den Namen des gewünschten Postfachs prüfen), sodass er in der normalen Ordnerliste erscheint, gehen Sie folgendermaßen vor: 1. Öffnen Sie Ihr Postfach wie gewohnt in OWA, rechtsklicken Sie auf das Stammverzeichnis
Ihres Postfachs und wählen Sie Posteingang eines anderen Benutzers öffnen. 2. Nun können Sie den Namen des anderen Postfachs in das gleichnamige Dialogfeld eingeben. 3. Falls Sie über die entsprechende Berechtigung verfügen, zeigt OWA das andere Postfach und dessen Posteingangsordner in der Ordnerliste Ihres eigenen Postfachs an.
326
Verteilergruppen
allen weiteren OWA-Sitzungen erhalten. Um den Posteingangsordner des anderen Postfachs wieder zu entfernen, müssen Sie ihn auswählen und auf die Option Ausblenden klicken. 쐍 Öffnen Sie das gesamte Postfach des anderen Benutzers. Diese Option erlaubt Ihnen vollständigen Zugriff auf alle Ordner des fremden Postfachs einschließlich Archivordnern und eignet sich zum Beispiel für Mitarbeiter, die eingehende Nachrichten für einen anderen Benutzer überwachen und bearbeiten, oder für Personen, die Discoverysuchen durchführen und das Discoverysuchpostfach öffnen müssen, um auf die Suchergebnisse zuzugreifen. Diese Art von Zugriff erfolgt einmalig und bleibt nicht für folgende OWA-Sitzungen erhalten, sodass Sie das Postfach des anderen Benutzers jedes Mal neu öffnen müssen. Klicken Sie dazu auf den Menüpfeil neben dem Namen Ihres Postfachs ganz rechts auf dem Bildschirm und geben Sie den Namen des zu öffnenden Postfachs in das Dialogfeld Anderes Postfach öffnen ein. Bei der Eingabe versucht OWA, den Postfachnamen anhand der zuvor verwendeten E-Mail-Adressen zu vervollständigen. Sie können den Anzeigenamen, den Alias oder die SMTP-Adresse des zu öffnenden Postfachs eingeben und Ihre Eingabe mit (Ctrl) + (K) validieren. Bestätigen Sie dann mit OK. Falls Sie über die entsprechende Berechtigung verfügen, erhalten Sie vollständigen Zugriff auf alle Ordner des Postfachs und die darin enthaltenen Objekte. 쐍 Binden Sie den Namen des zu öffnenden Postfachs in den URL ein, den Sie zum Aufrufen von OWA verwenden. Diese Variante der zuvor beschriebenen Möglichkeit erlaubt es Ihnen, direkt auf das gewählte Postfach zuzugreifen, ohne den Umweg über Ihr eigenes Postfach gehen zu müssen. Hängen Sie einfach die SMTP-Adresse des Postfachs an den URL an, den Sie im Browser eingeben. Wenn Sie zum Beispiel normalerweise https://webmail.contoso.com/owa eingeben, können Sie das Postfach für [email protected] öffnen, indem Sie stattdessen https://webmail.contoso.com/owa/[email protected] schreiben. Postfachüberwachung
Sie können die Tätigkeiten eines Benutzers (auch eines Administrators) überwachen, der das Postfach eines anderen Benutzers öffnet, indem Sie die Überwachung für das Postfach aktivieren. Dadurch werden Einzelheiten über Aktionen wie das Löschen von Objekten, das Leeren des Papierkorbs usw. erfasst. Außerdem können Sie die Aktionen von Postfachbesitzern überwachen, während diese an ihrem eigenen Postfach angemeldet sind. Die Aktivierung der Postfachüberwachung kann sich als sinnvoll etwa für Postfächer von Mitgliedern der Geschäftsführung oder Personen in ähnlichen Positionen erweisen, beispielsweise, wenn zur Einhaltung gesetzlicher Vorschriften die Bereitstellung von Daten erforderlich wird. Administratoren können dann Überwachungsberichte über die Verwaltungsshell ausführen, um Informationen über die Aktionen aller Benutzer abzurufen, die das Postfach verwendet haben, und diese Berichte dann an die zuständige Stelle zur Überprüfung schicken.
Verteilergruppen Jede Exchange-Organisation enthält Verteilergruppen, wobei die größten Bereitstellungen in der Regel Zehntausende von Gruppen umfassen. Es ist sicher nützlich, viele verschiedene Empfänger über eine allgemeine Adresse erreichen zu können, jedoch werden Verteilergruppen selten so gut gepflegt wie Postfächer und liegen meist noch im Verzeichnis herum, obwohl sie schon lange nicht
327
Verwalten von E-Mailaktivierten Empfängern
4. Die Option zum Öffnen des Eingangsordners eines anderen Benutzers bleibt dauerhaft in
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
mehr benutzt werden. Bis 2010 war ich bei Hewlett-Packard beschäftigt und selbst zu diesem Zeitpunkt konnte ich noch Gruppen mit dem Namen Windows 2000 Launch Team und Windows NT Forum – beides Artefakte aus früherer Arbeit – in der globalen Adressliste finden. In Windows gibt es vier verschiedene Arten von Gruppen, Exchange hat jedoch nur für zwei davon Verwendung: universelle Gruppen und dynamische oder abfragebasierte Gruppen. Universelle Gruppen sind überall in der Gesamtstruktur verfügbar, da ihre Mitgliederliste auf globalen Katalogservern veröffentlicht wird. Für Exchange bedeutet dies, dass garantiert jedes Mitglied der Gruppe Nachrichten erhält, die an die Gruppe gesendet werden, da jeder Hub-Transport-Server die Mitgliedschaft der Gruppe auf dieselbe Art aufgliedern kann, wenn er Nachrichten an die Gruppe weiterleitet. Universelle Gruppen können Sicherheitsprinzipale enthalten und als Grundlage für die Zugriffssteuerung und Kommunikation dienen und sind somit sehr nützliche Objekte. Der Exchange-Empfängertyp für E-Mail-aktivierte universelle Gruppen lautet MailUniversalDistributionGroup, sofern die Gruppe nicht als Sicherheitsgruppe erstellt wird – in diesem Fall ist sie vom Typ MailUniversalSecurityGroup. Wie andere Exchange-Objekte haben Gruppen eine Versionsnummer, die anzeigt, unter welcher Exchange-Version sie erstellt (oder zuletzt geändert) wurden. Falls Sie Gruppen haben, die unter vorherigen Exchange-Versionen erstellt wurden, so werden deren Versionsnummern auf Version 14 aktualisiert, wenn Sie das erste Mal irgendwelche Metadaten (keine Mitgliedschaften) mit Exchange Server 2010 bearbeiten. Eine neue Verteilergruppe umfasst noch keine Mitglieder. Um sie sinnvoll nutzen zu können, müssen Sie ihr zuerst Mitglieder hinzufügen, und die Verwaltung der Gruppenmitgliedschaft stellt eine Daueraufgabe für die Gruppenbesitzer dar. Dynamische Verteilergruppen haben hier die Nase vorn, da ihre Mitgliederlisten jedes Mal, wenn die Gruppe in einen E-Mail-Header eingefügt wird, durch das Transportsystem ausgewertet werden. Eine dynamische Verteilergruppe besitzt keine Mitgliederliste wie die einer normalen Verteilergruppe, sondern arbeitet mit einer OPATH-Abfrage, die das Transportsystem in Active Directory ausführt, um die aktuelle Gruppenmitgliedschaft zu ermitteln. E-Mail-aktivierte Objekte werden anhand ihrer Active Directory-Eigenschaften zu dynamischen Verteilergruppen hinzugefügt bzw. daraus entfernt. Wird beispielsweise eine Abfrage nach allen in Texas ansässigen Benutzern mit einem Exchange-Postfach durchgeführt, dann sendet das Transportsystem eine Kopie einer an diese Gruppe adressierten Nachricht an alle Benutzer in Active Directory, deren Staat- oder Provinzattribut »Texas« lautet. Der Vorteil dynamischer Verteilergruppen besteht darin, dass ihre Mitgliederliste immer die aktuellen in Active Directory verfügbaren Informationen widerspiegelt. Dies ist aber auch gleichzeitig ihr Nachteil, denn wenn Sie Active Directory nicht mit den korrekten Daten versorgen, kann eine Abfrage nicht die erwartete oder gewünschte Mitgliederliste zurückgeben. Im Hinblick auf unser Beispiel kann eine Abfrage, um alle Personen in einem bestimmten Land zu finden, nur dann erfolgreich sein, wenn das Länderattribut aller zu findenden Active DirectoryObjekte denselben Wert aufweist. Anders herum ausgedruckt, muss sie fehlschlagen, wenn Administratoren beim Einrichten der Benutzerkonten unterschiedliche Schreibweisen für ein Land wählen. »US« und »U.S.« sind zwei komplett unterschiedliche Werte, ebenso wie »UK«, »U.K« und »United Kingdom«. Da die Mitgliederlisten dynamischer Verteilergruppen nur bei Bedarf evaluiert und nicht durch Verknüpfungen mit anderen Active Directory-Objekten repräsentiert werden, können diese Gruppen keine Sicherheitsprinzipale enthalten. Da wir nun den Unterschied zwischen normalen und dynamischen Verteilergruppen kennen, werden wir uns erst weiter hinten in diesem Kapitel wieder mit dieser Thematik befassen.
328
Hinter den Kulissen speichert Windows die Mitgliederlisten für Verteilergruppen als Satz von Rückwärtszeigern auf die Objekte, die die Mitglieder der Gruppe repräsentieren. Bei diesen Objekten kann es sich um E-Mail-aktivierte Konten, Kontakte, öffentliche Ordner oder andere Gruppen handeln. Technisch gesehen wird die Mitgliederliste in einem einzelnen, mehrwertigen Attribut mit dem Namen Member gespeichert, das die Zeiger enthält. Abbildung 6.24 zeigt die Mitgliederliste einer Gruppe, einmal in der Verwaltungskonsole (links) und einmal im ADSI-Editor (rechts). In der Vergangenheit führte die Art und Weise, wie Active Directory Gruppenmitglieder in einem einzigen, mehrwertigen Attribut speicherte, in der Praxis zu einer Beschränkung der Anzahl von Objekten, die einer Gruppe angehören durften. Diese Einschränkung wurde mit der Einführung der verknüpften Wertereplikation in Windows Server 2003 entfernt, und Sie können nun weit mehr als 5.000 Mitglieder in einer Gruppe unterbringen. Allerdings kann das Verwalten der Mitglieder bei sehr großen Gruppen wirklich mühselig sein, und die meisten Administratoren versuchen daher, die Mitgliederanzahl einer Gruppe möglichst unter 1.000 zu halten. Exchange Server 2010 ermöglicht es Benutzern, Gruppen über die Exchange-Systemsteuerung beizutreten bzw. sie wieder zu verlassen, was die Administratoren ein wenig entlastet. Abbildg. 6.24
Anzeigen der Gruppenmitglieder in der Verwaltungskonsole und im ADSI-Editor
329
Verwalten von E-Mailaktivierten Empfängern
Verteilergruppen
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Raumlisten Einen passenden Konferenzraum für eine Besprechung zu finden, ist manchmal kein leichtes Unterfangen. Exchange Server 2010 versucht, diese Aufgabe mithilfe von Raumlisten zu erleichtern. Hierbei handelt es sich um Verteilergruppen, deren Mitglieder sich komplett aus Raumpostfächern zusammensetzen und durch eine besondere Eigenschaft gekennzeichnet sind, damit Outlook 2010 (der einzige Client, der zurzeit Raumlisten verarbeiten kann) erkennt, dass es die Raumlistengruppe verwenden kann. Raumlistengruppen sollen den Benutzern helfen, das gesamte Angebot an verfügbaren Räumen innerhalb eines Unternehmens zu durchforsten. Dies ist von besonderer Bedeutung in großen Unternehmen, in denen möglicherweise Hunderte von Räumen über verschiedene Gebäude und an unterschiedlichen Orten verstreut sind. In diesem Fall können Sie eine Raumliste für jedes Firmengebäude erstellen. Weniger interessant ist diese Option natürlich für kleinere Unternehmen mit nur einem oder zwei Konferenzräumen. Um eine Raumlistengruppe zu erstellen, haben Sie zwei Möglichkeiten: 쐍 Erstellen Sie in der Exchange-Verwaltungskonsole eine Verteilergruppe wie gewohnt und kennzeichnen Sie sie mithilfe der Verwaltungsshell als Raumliste. 쐍 Erstellen Sie in der Exchange-Vewaltungsshell eine Verteilergruppe und kennzeichnen Sie sie gleich als Raumliste. Um eine neue Raumliste mit der Verwaltungsshell zu erstellen, verwenden Sie wie gewohnt das Cmdlet New-DistributionGroup, schließen aber den Parameter -RoomList ein: New-DistributionGroup –Name 'HQ Conference Rooms' –OrganizationalUnit 'contoso.com/Groups' –RoomList
Um eine bestehende (mit der Verwaltungskonsole erstellte) Gruppe zu kennzeichnen, verwenden Sie das Cmdlet Set-DistributionGroup: Set-DistributionGroup –Identity 'Building 2 Rooms' –RoomList
Nachdem Sie die Raumlistengruppen erstellt haben, können Sie als deren Mitglieder Raumpostfächer hinzufügen. Die Verwaltungskonsole kennzeichnet Raumlistengruppen mit einem besonderen Symbol, damit Sie wissen, dass Sie nur Raumpostfächer darin aufnehmen dürfen. Wenn Sie versehentlich versuchen, ein normales Postfach hinzuzufügen, erhalten Sie die in Abbildung 6.25 gezeigte Fehlermeldung. Outlook 2010 verwendet Raumlistengruppen zur Planung von Besprechungsterminen. Der Raumlistenfinder erlaubt es dem Benutzer, eine bestimmte Raumlistengruppe auszuwählen (zum Beispiel die mit den Räumen des Gebäudes, in dem die Besprechung stattfinden soll). Outlook lädt dann die Raumpostfächer der Gruppe und ruft die Verfügbarkeitsdaten für die entsprechenden Räume ab, um dem Benutzer anzuzeigen, wann die Räume frei sind. Er kann dann den am besten geeigneten Raum wählen und für die Besprechung hinzufügen. Mögliche Beschränkungen durch die Ressourcenbuchungsautomatik bleiben von dieser Option unberührt (mehr dazu im Abschnitt »Verarbeiten von Besprechungsanforderungen nach der Richtlinie« weiter hinten im Kapitel); sie bietet lediglich eine einfachere Möglichkeit für die Benutzer, einen passenden Konferenzraum für eine Besprechung zu finden.
330
Verteilergruppen
Fehler beim Füllen einer Raumlisten-Verteilergruppe
Verwalten von E-Mailaktivierten Empfängern
Abbildg. 6.25
Abbildung 6.26 zeigt eine Raumlistengruppe in Aktion. Wie Sie sehen, ist in der Dropdownliste Raumliste anzeigen die Liste Konferenzräume ausgewählt. Dadurch werden sämtliche enthaltenen Räume angezeigt, und der Benutzer kann dann den Raum auswählen, den er gerne buchen möchte. Abbildg. 6.26
Verwenden einer Raumliste in Outlook 2010.
331
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Gruppenbesitzer Einer neuen Gruppe weist Exchange das zum Erstellen verwendete Konto als Gruppenbesitzer zu. Das ist nicht von großer Bedeutung, wenn die Gruppenmitgliedschaft immer von Administratoren verwaltet wird. Es kann jedoch sinnvoll sein, einzelnen Benutzern das Recht zur Gruppenverwaltung zu übertragen. In früheren Versionen von Exchange war Outlook als einziges Werkzeug für diesen Zweck geeignet. Wenn Sie eine Gruppe besitzen, können Sie sie in Outlook in der globalen Adressliste auswählen und ihre Mitgliederliste aktualisieren (siehe Abbildung 6.27). Dies war in früheren ExchangeVersionen nicht immer möglich, besonders, wenn Ihr Konto sich in einer anderen Domäne befand als derjenigen, der die Gruppe angehörte. Abbildg. 6.27
Ändern der Gruppenmitgliedschaft über Outlook
Wie in Kapitel 5 erläutert, können Sie die Standardrollenzuweisungsrichtlinie so anpassen, dass auch Benutzer die Gruppenmitgliedschaft über die Exchange-Systemsteuerung verwalten können. In diesem Fall müssen Sie unter Umständen auch Gruppen aktualisieren, um den Benutzern Besitzrechte einzuräumen. Dies können Sie leicht erledigen, indem Sie eine Gruppe auswählen, ihre Eigenschaften anzeigen und auf die Registerkarte Gruppenmitgliedschaft klicken. Sie können dann Benutzer als Gruppenbesitzer hinzufügen oder entfernen. Im Gegensatz zu Exchange Server 2003 und 2007 können Sie jedoch keine Gruppe als Besitzer einer anderen Gruppe hinzufügen. Dieses neue Verhalten ist der Einführung der rollenbasierten Zugriffssteuerung als zentrale Autorisierungsinstanz für sämtliche Aktionen in Exchange Server 2010 geschuldet. Durch das Kanalisieren von Autorisierungsanforderungen durch die rollenbasierte Zugriffssteuerung wird sichergestellt, dass ein Benutzer, der versucht, eine Gruppenmitgliederliste zu ändern, auch dazu berechtigt ist. Die rollenbasierte Zugriffssteuerung lässt die Zuweisung der Gruppenverwaltung zu einer anderen Gruppe in Exchange Server 2010 (einschließlich SP1) nicht zu und besteht darauf, dass jeder Benutzer, der eine Gruppe verwalten können soll, individuell als Gruppenverwalter aufgelistet wird. Abbildung 6.28 zeigt, dass die Gruppe Exchange Server 2010-Interessentenliste von drei Benutzern verwaltet wird.
332
Verteilergruppen
Anzeigen der Gruppenbesitzer
Verwalten von E-Mailaktivierten Empfängern
Abbildg. 6.28
Alternativ können Sie das Cmdlet Set-DistributionGroup verwenden, um die Verwaltungsliste einer Gruppe zu ändern. Die Eingabe für den Parameter -ManagedBy ist eine durch Komma getrennte Auflistung von Bezeichnern für die Postfächer der Benutzer, die Sie zu Gruppenverwaltern ernennen möchten. Bei den Bezeichnern kann es sich um E-Mail-Adressen, Namen, Aliase oder sogar definierte Namen handeln. Dabei ist es egal, welches Format Sie verwenden, solange Exchange den jeweiligen Gruppenbesitzer eindeutig identifizieren kann. Auch wenn Sie einer Gruppe viele verschiedene Verwalter zuordnen können, so ist es in der Regel am besten, diese Zahl auf zwei bis sechs zu begrenzen, da alles, was darüber hinaus geht, Verwirrung stiften kann, zum Beispiel wenn mehrere Verwalter versuchen, die Gruppenmitgliederliste zur selben Zeit zu ändern. Set-DistributionGroup –Identity 'Exchange Server 2010-Interessentenliste' -BypassSecurityGroupManagerCheck -ManagedBy 'Administrator', 'Andrews, Ben (IT)', 'Peled, Yael (IT)'
Mit einem Befehl wie dem folgenden können Sie prüfen, ob der Gruppe die richtigen Besitzer zugewiesen wurden: Get-DistributionGroup –Identity 'Exchange Server 2010 Interest List' | Select Name, ManagedBy | Format-List
333
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Aufgliedern von Gruppen Exchange gliedert die im Nachrichtenheader enthaltenen Mitgliederlisten von Gruppen auf, wenn die E-Mails einen Hub-Transport-Server passieren. Die Standardeinstellung bewirkt, dass jeder HubTransport-Server eine Gruppe aufgliedern darf, Sie können diese Aufgabe aber auch einem bestimmten Server übertragen (siehe Abbildung 6.29). Dies hat jedoch den Nachteil, dass sämtliche an die Gruppe adressierten Nachrichten nur so lange weitergeleitet werden können, wie der Server online ist, wodurch sich eine mögliche Quelle für Fehler (oder Verzögerungen) innerhalb Ihrer Messagingumgebung ergibt. Abbildg. 6.29
Abbildung: 6.29: Festlegen eines Aufgliederungsservers für eine Gruppe
Wenn ein Hub-Transport-Server eine Gruppe aufgliedert, erstellt er im Speicher eine Liste der einzelnen Gruppenmitglieder, die er nutzt, um eine Nachricht über die günstigste Route zu senden. Die aufgegliederte Mitgliederliste wird nicht zum Nachrichtenheader hinzugefügt, da sich so die Größe der Nachricht erhöhen würde. Jede Adresse erweitert den Header um 1 bis 2 KB, weshalb es wenig Sinn hat, diese zusätzliche Last mit aufzunehmen, zumal einige Gruppen Tausende von Mitgliedern haben können. TIPP Indem Sie nur den Gruppennamen im Header belassen, erlauben Sie dem Empfänger, auf die Nachricht zu antworten, wobei Exchange sie an die aktuelle Mitgliederliste weiterleiten wird. Auf diese Weise wird außerdem verhindert, dass Antworten an nicht vorhandene Adressen gesendet werden.
334
Verteilergruppen
Eine geschützte Gruppe ist eine Gruppe, an die nur bestimmte Benutzer Nachrichten senden dürfen. Wie bereits erläutert, können Sie die Nachrichtemoderation für geschützte Gruppen verwenden, aber Sie können auch festlegen, von wem eine Gruppe Nachrichten akzeptiert. Abbildung 6.30 zeigt die grundlegende Vorgehensweise. Markieren Sie die Gruppe und rufen Sie ihre Eigenschaftenseite auf. Wechseln Sie zur Registerkarte Nachrichtenübermittlungseinstellungen, wählen Sie die Option Einschränkungen für die Nachrichtenzustellung und klicken Sie auf Eigenschaften. Anschließend können Sie die Benutzer auswählen, die Nachrichten an die Gruppe senden dürfen, sowie diejenigen, die explizit blockiert werden sollen. Abbildg. 6.30
Einschränken der Postfächer und Gruppen, die Nachrichten an eine Gruppe senden dürfen
Genau denselben Schritt können Sie in der Exchange-Verwaltungsshell mithilfe des Cmdlets Set-DistributionGroup durchführen. Set-DistributionGroup -Identity 'contoso.com/Exchange Users/Sales Executives' -BypassSecurityGroupManagerCheck -AcceptMessagesOnlyFromSendersOrMembers 'Ruth, Andy', 'Akers, Kim', 'Sales Executives'
Wie Sie sehen, habe ich in beiden Fällen dafür gesorgt, dass die Mitglieder der Gruppe ebenfalls Nachrichten an die Gruppe senden dürfen. Es ist natürlich denkbar, dass Sie eine Sicherheitsgruppe einrichten, um eine bestimmte Ressource zu schützen, und verhindern möchten, dass die Gruppenmitglieder Nachrichten an die Gruppe senden können. In den meisten Fällen ist es jedoch wünschenswert, den Mitgliedern das Senden von Nachrichten an die Gruppe zu erlauben.
335
Verwalten von E-Mailaktivierten Empfängern
Geschützte Gruppen
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Jeder nicht berechtigte Benutzer, der versucht, Nachrichten an die geschützte Gruppe zu senden, erhält einen Unzustellbarkeitsbericht (DNS-Fehlercode 5.7.1) wie den in Abbildung 6.31. Verwendet der Benutzer einen Client, der E-Mail-Infos verarbeiten kann, bekommt er überdies einen Hinweis angezeigt, dass er keine Nachrichten an die Gruppe senden darf. Versucht er es dennoch, so blockiert Exchange die Nachricht. Es bleibt zu hoffen, dass der Hinweis im Unzustellbarkeitsbericht deutlich genug ist, sodass jeder Benutzer, der ihn erhält, versteht, warum die Zustellung fehlgeschlagen ist, und davon absehen wird, beim internen Support nachzufragen. Abbildg. 6.31
Unzustellbarkeitsbericht für eine Nachricht, die an eine eingeschränkte Gruppe gesendet wurde
Dieselbe Fehlermeldung wird angezeigt, wenn ein externer Benutzer versucht, Nachrichten an eine Verteilergruppe zu senden, die eine Authentifizierung des Absenders erfordert. Gruppen in Exchange Server 2010 erfordern standardmäßig eine Absenderauthentifizierung, das heißt, dass der Absender dem Unternehmen bekannt sein muss, bevor der Hub-Transportdienst die eingehenden Nachrichten an die Gruppe weiterleitet. Falls Sie externen Benutzern (die vielleicht einer anderen Exchange-Organisation Ihrer Firmengruppe angehören) erlauben möchten, Nachrichten an eine Gruppe zu senden, so können Sie die Authentifizierungsanforderung aufheben, indem Sie unter Einschränkungen für die Nachrichtenzustellung das Kontrollkästchen Authentifizierung aller Absender anfordern für die Gruppe deaktivieren oder den folgenden Befehl geben: Set-DistributionGroup –Identity 'Exchange Server 2010 Interest List' -RequireSenderAuthenticationEnabled $False
336
Verteilergruppen
In früheren Büchern über Exchange habe ich die Aussage getroffen, dass die Verwaltung von Gruppen einige Probleme für Administratoren birgt, besonders in großen Unternehmen, in denen es ständig Anfragen von Benutzern gibt, die in Gruppen ein- und wieder daraus austreten oder wissen möchten, warum sie eine bestimmte Gruppe nicht finden, warum sie keine Nachricht an eine Gruppe senden können oder wer die Mitglieder einer Gruppe sind. Exchange Server 2010 hat diesbezüglich immer noch einige Defizite (wie schwer kann es schon sein, irgendeine Benutzerschnittstelle zu erstellen, mit deren Hilfe ein hübsch formatierter Bericht über die Mitglieder einer Gruppe ausgegeben werden kann?). Die Situation hat sich jedoch durch die Einführung von E-Mail-Infos (mehr dazu in Kapitel 12, »Postfachunterstützungsdienste«) verbessert, da diese helfen, zu verhindern, dass Benutzer Nachrichten an sehr große Gruppen oder selbstwartende Gruppen senden, und es Ihnen als Administrator erlauben, die Einstellungen einer Gruppe so vorzunehmen, dass die Benutzer über die Exchange-Systemsteuerung der Gruppe selbstständig beitreten und auch wieder daraus austreten können. Wie Sie in Abbildung 6.32 sehen, können Sie die Gruppe auch folgendermaßen konfigurieren: 쐍 Offen Exchange akzeptiert anstandslos alle Anforderungen von Benutzern, einer Gruppe beizutreten oder sie wieder zu verlassen. Universelle Sicherheitsgruppen können nicht als offen eingerichtet werden, da sie auch einen Sicherheitsprinzipal enthalten, der den Zugriff auf Ressourcen steuert. Abbildg. 6.32
Festlegen der Benutzer, die einer Gruppe beitreten dürfen
쐍 Geschlossen Nur die Gruppenbesitzer dürfen Mitglieder zur Gruppe hinzufügen oder daraus entfernen. Dies ist die Standardeinstellung und sollte für jede universelle Sicherheitsgruppe so festgelegt sein. 쐍 Besitzergenehmigung Benutzer können eine Anforderung stellen, einer Gruppe beitreten zu dürfen, diese wird jedoch nur dann ausgeführt, nachdem ein Gruppenbesitzer zugestimmt hat. Der Zustimmungsprozess ähnelt dem für moderierte Gruppen.
337
Verwalten von E-Mailaktivierten Empfängern
Selbstwartende Gruppen
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Selbstverständlich können Sie diese Einstellungen auch über die Verwaltungsshell vornehmen: Set-DistributionGroup –Identity 'Sales Executives' –MemberJoinRestriction 'Closed' –MemberDepartRestriction 'Open' –AcceptMessagesOnlyFromDLMembers 'Sales Executives' –Notes 'The Sales Executive group is restricted' –ManagedBy 'Andrews, Ben (IT)'
In diesem Fall legen wir die Optionen für die Gruppe Sales Executives so fest, dass die Mitgliederliste für neue Mitglieder geschlossen ist (Besitzer können immer neue Mitglieder hinzufügen), Austrittsgesuche automatisch akzeptiert werden und nur Gruppenmitglieder Nachrichten an die Gruppe senden dürfen. Zu guter Letzt wird ein Hinweis hinzugefügt, dass die Gruppe eingeschränkt ist. Er ist sichtbar, wenn sich die Benutzer die Eigenschaften der Gruppe über die globale Adressliste anzeigen lassen.
Anzeigen der Gruppenmitglieder Nachdem Sie einer Gruppe Mitglieder hinzugefügt haben, stellt sich als Nächstes die Frage, wie sichergestellt werden kann, ob auch die richtigen Mitglieder hinzugefügt wurden. Es ist ein Leichtes, die Mitgliederliste einer kleinen Gruppe zu überprüfen, indem Sie mit Outlook oder OWA einen Blick in die Gruppeneigenschaften werfen. Dieser Ansatz schlägt jedoch fehl, sobald eine Gruppe mehr als 50 Mitglieder umfasst, da sich die Benutzerschnittstelle nicht zum Durchsuchen großer Gruppen eignet. Es wäre daher schön, eine Schaltfläche zu haben, die eine formatierte Liste der Gruppenmitglieder ausgibt, doch kein Client bietet diese Option bislang, ebenso wenig wie die ExchangeSystemsteuerung und die -Verwaltungskonsole. Wenn Sie also eine Liste der Gruppenmitglieder benötigen, dann müssen Sie sie mithilfe der Verwaltungsshell erstellen. Mit dem folgenden einzeiligen Befehl können Sie die Mitglieder einer Gruppe abrufen, zwei Eigenschaften auswählen und die Ausgabe in einer Textdatei speichern: Get-DistributionGroupMember –Identity 'Sales Executives' | Select Name, DisplayName > C:\TEMP\Sales.txt
Alternativ können Sie die Ausgabe mithilfe des Cmdlets Export-CSV in eine CSV-Datei umleiten, die Sie dann in Excel weiterbearbeiten können, um das Erscheinungsbild des Berichts etwas attraktiver zu gestalten. Manchmal müssen Sie auch schnell herausfinden, wie viele Mitglieder in einer Verteilergruppe sind. Dazu können Sie folgendermaßen vorgehen: (Get-DistributionGroupMember –Identity 'Sales Executives').Count
Manche Unternehmen sind wenig begeistert von der Tatsache, dass Outlook die Mitglieder einer Gruppe so leicht preisgibt. Sie würden die Benutzer gerne daran hindern, die Gruppenmitglieder zu sehen – sei es über die globale Adressliste oder durch Aufgliedern der Mitgliederliste einer Gruppe, nachdem diese dem Nachrichtenheader hinzugefügt wurde. Beispiele für Gruppen, deren Mitgliederanzeige häufig durch die Administratoren unterdrückt werden soll, sind inoffizielle Teams der Geschäftsleitung, externe Berater oder Mitglieder von Vorstandsausschüssen. Es ist möglich, Zugriffssteuerungslisten für Gruppen einzurichten, um nur ausgewählten Benutzern Zugriff zu gewähren. Diese Lösung ist jedoch mit Ausnahme weniger Gruppen verwaltungstechnisch schwer zu steuern. Ein besserer Ansatz besteht darin, eine Platzhalter-Verteilergruppe zu erstellen, die auf die tatsächliche Verteilergruppe verweist, wobei Letztere in der globalen Adressliste nicht ange-
338
zeigt wird. In Abbildung 6.33 sehen wir eine Gruppe mit dem Namen GRP-Supergeheime Gruppe, die den Benutzern in der globalen Adressliste angezeigt wird. Wenn diese dann einen Blick in die Mitgliederliste werfen wollen, sehen sie einen Hinweis auf GRP-Echte geheime Gruppe. Diese Gruppe ist jedoch verborgen, sodass die Benutzer sie zwar als Mitglied einer anderen Gruppe sehen können, aber keinen Aufschluss über die tatsächlichen Mitglieder erhalten. Abbildg. 6.33
Unterbinden der Anzeige von Gruppenmitgliedern
Die Verwendung einer dynamischen Verteilergruppe stellt eine noch bessere Lösung dar, da kein Client jemals die Mitglieder einer dynamischen Gruppe preisgibt. Sie können die 15 für E-Mail-aktivierte Objekte verfügbaren benutzerdefinierten Attribute ausschöpfen, um Werte zuzuweisen, die dann von den Filtern der dynamischen Gruppen verwendet werden. Auf diese Weise könnten Sie zum Beispiel E-Mail-aktivierte Kontakte für die externen Berater erstellen, deren Mitgliedschaft sie verbergen möchten, und »ExBer« für eines der benutzerdefinierten Attribute angeben. Die Vorstandsausschüsse wiederum erhalten ein anderes Attribut usw. Dies ist ein äußerst sinnvoller Ansatz, da er sich leicht mithilfe der vorhandenen Verwaltungswerkzeuge (Verwaltungskonsole und -shell) umsetzen lässt und sich nicht auf irgendwelche dubiosen Methoden wie das Bearbeiten von Zugriffssteuerungslisten stützt, die durch eine Änderung in zukünftigen Windows- oder Exchange-Versionen beeinträchtigt werden könnten. Insidertipp: Zusätzliche Steuermöglichkeiten in Outlook 2010
Outlook 2010 hat eine zusätzliche Beschränkung für moderierte Gruppen eingeführt (Gruppen, die eine Zustimmung erfordern, bevor Nachrichten an sie gesendet werden können). Wenn Sie eine moderierte Gruppe in einen Nachrichtenheader einfügen, darauf rechtsklicken und Gruppe aufgliedern wählen, weigert sich Outlook, die Adressen der einzelnen Gruppenmitglieder in den Nachrichtenheader einzufügen.
339
Verwalten von E-Mailaktivierten Empfängern
Verteilergruppen
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Nachverfolgung der Gruppenbenutzung Gruppen lassen sich leicht erstellen, bilden eine leistungsfähige Methode, um Nachrichten an mehrere Empfänger gleichzeitig zu versenden, und sind relativ leicht zu warten. Der einzige Nachteil besteht darin, dass sie häufig weit über ihr »Verfallsdatum« hinaus in Active Directory verweilen. So ist es zum Beispiel üblich, Gruppen anzulegen, um die Kommunikation für ein bestimmtes Ereignis oder einen besonderen Zweck zu erleichtern. Eine solche Gruppe wird in der Zeit vor dem jeweiligen Termin rege genutzt, danach allerdings »verstaubt« sie ungenutzt in der globalen Adressliste, und zwar so lange, bis ein Administrator entscheidet, dass sie nicht mehr genutzt wird, und sie aus dem Verkehr zieht. Dieses Szenario wirft zwei Fragen auf. Erstens: Woran erkennt man, ob Gruppen noch genutzt werden? Zweitens: Was ist mit Gruppen zu tun, die nicht mehr genutzt werden? Name [email protected] [email protected] [email protected] [email protected]
Count ----12 11 9 1
Es gibt viele Möglichkeiten, diesen Code als Grundlage zu verwenden. So können Sie beispielsweise die Nutzung innerhalb eines bestimmten Datumsbereichs prüfen oder Daten in einem Formular ausgeben, die Sie im Laufe der Zeit von allen Hub-Transport-Servern anfordern, um einen unternehmensweiten Überblick zu erhalten. Da wir nun wissen, wie wir die Benutzung von Gruppen überprüfen können, sind wir in der Lage, uns die Gruppen in der globalen Adressliste anzusehen und diejenigen herauszufiltern, die niemand mehr verwendet. Wurde eine Gruppe über einige Monate hinweg nicht genutzt, ist es an der Zeit, sie etwa einen Monat lang aus der globalen Adressliste zu entfernen – oder wenigstens darin zu verbergen –, um zu sehen, ob irgendjemand sie vermisst. Tritt dieser Fall nicht ein, können Sie die Gruppe getrost löschen.
Dynamische Verteilergruppen Immer den Überblick über sämtliche Mitarbeiter zu behalten, ist in großen Unternehmen im Allgemeinen recht schwierig, weshalb auch so viel in Personalsysteme investiert wird. Vor derselben Herausforderung stehen auch Messagingadministratoren und Supportmitarbeiter, die sehr viel Zeit damit verbringen, die Mitglieder von Gruppen zu verwalten, da ständig neue Mitarbeiter in die Firma kommen, andere sie verlassen und wieder andere neue Rollen und Pflichten übernehmen. Wie soeben erläutert, kann das Einrichten und Verwalten großer Verteilergruppen für Exchange-Adminstratoren zur regelrechten Plage werden. Dynamische Verteilergruppen bieten eine Lösung für dieses Problem. Die Zusammensetzung solcher Gruppen beruht auf einer Abfrage, die Exchange in Active Directory ausführt, um jedes Mal, wenn eine Nachricht an eine Gruppe gesendet wird, die aktuelle Mitgliederliste zu ermitteln. Der Erfolg von dynamischen Verteilergruppen steht und fällt damit, wie akkurat die Daten in Active Directory sind. Eine dynamische Verteilergruppe funktioniert korrekt, wenn Nachrichten stets an die richtigen Empfänger geleitet werden, und das können Sie auch erwarten, wenn die Eigenschaften der E-Mail-
340
aktivierten Objekte konsequent gepflegt werden. Sind die Daten inkonsistent oder werden sie nicht konsequent verwaltet, kann es zu einigen »Überraschungen« kommen, wenn das Transportsystem die Gruppe aufgliedert, um eine Nachricht an sie zu senden. Es sollte auch nicht unerwähnt bleiben, dass dynamische Verteilergruppen auf Hub-Transport-Servern eine höhere Arbeitslast verursachen als normale Gruppen. Anstatt nur die Gruppenmitglieder zu lesen, sobald eine Nachricht weitergeleitet wird, muss der Hub-Transport-Server zusätzliche Verarbeitungsschritte durchführen, um die Abfrage zur Ermittlung der Gruppenmitglieder auszuführen, bevor eine Nachricht weitergeleitet werden kann. Die meisten Abfragen sind einfach und können schnell ausgeführt werden, vor allem mit der heutzutage verwendeten leistungsstarken Servertechnologie. Es ist jedoch auch möglich, Abfragen zu erstellen, die Tausende von Empfängern zurückgeben (zum Beispiel »Alle Benutzer in den Vereinigten Staaten«), was im Zuge der Nachrichtenverarbeitung zu einer gewissen Belastung führt. Allerdings ist es unwahrscheinlich, dass solche Gruppen häufiger als ein paar Mal am Tag genutzt werden, und das sollte keinen Server allzu sehr strapazieren. Für den Benutzer besteht der einzige Unterschied zwischen einer normalen und einer dynamischen Gruppe darin, dass er die Mitgliederliste einer dynamischen Gruppe nicht einsehen kann, wenn er über die globale Adressliste einen Blick in die Gruppeneigenschaften wirft. Dynamische Gruppen umfassen keine Sicherheitsprinzipale, weshalb man sie nicht verwenden kann, um Objekte zu schützen. Abgesehen von diesen kleineren Unterschieden erscheinen dynamische und normale Gruppen sehr ähnlich.
OPATH-Abfragen Hinter den Kulissen sieht es anders aus: Immer wenn ein Hub-Transport-Server eine Nachricht verarbeitet, die an eine dynamische Verteilergruppe adressiert ist, verwendet er eine in den Gruppeneinstellungen gespeicherte Abfrage, um Active Directory zu durchsuchen und die Gruppenmitglieder zu einer Liste von Adressen aufzugliedern, die der Abfrage entsprechen. Abfragen werden im OPATH-Format gespeichert. Frühere Versionen nutzten LDAP-Abfragen, OPATH ist jedoch die Standardabfragesyntax für Windows PowerShell, weshalb Exchange Server 2007 es als Standard übernommen hat. Eine dynamische Verteilergruppe speichert ihre Abfrage in der Eigenschaft MSExchQueryFilter, wo Sie ähnliche Angaben wie die folgenden finden können: ((RecipientType –eq 'UserMailbox' –and Department –eq 'Sales') –and –not (Name –like 'SystemMailbox{*'))
Die Abfrage sucht nach allen Postfächern, deren Eigenschaft Department den Wert Sales aufweist. Der letzte Teil der Abfrage schließt Systempostfächer aus. Es ist klar, dass diese Abfrage nur dann funktioniert, wenn der Wert der Eigenschaft Department immer korrekt ist – sie wird Postfächer, die zur der Abteilung »Sales« gehören, nicht finden, wenn dieser Wert nicht oder nicht korrekt angegeben wurde. Mit anderen Worten: Erwarten Sie nicht, dass dynamische Verteilergruppen »wissen«, mit was oder wem der Transportdienst Kontakt aufnehmen soll, denn diese Abfragen funktionieren nur mit präzisen Daten. Falls Sie bislang mit Exchange Server 2003 gearbeitet haben, verfügen Sie vielleicht noch über einige der älteren LDAP- und abfragebasierten Verteilergruppen. Sie können diese Gruppen mithilfe des Cmdlets Set-DynamicDistributionGroup auf dynamische Verteilergruppen aktualisieren, indem Sie den Parameter -ForceUpgrade verwenden. Hierdurch wird die Version der Gruppe aktualisiert und
341
Verwalten von E-Mailaktivierten Empfängern
Dynamische Verteilergruppen
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
damit kompatibel mit Exchange Server 2010, und die alte LDAP-Abfrage wird in das OPATH-Format übertragen. Sowohl Abfragen im LDAP- als auch im OPATH-Format werden in den Gruppeneigenschaften gespeichert, um die Abwärtskompatibilität sicherzustellen und zu gewährleisten, dass die Abfrage auch von Exchange Server 2003-Transport-Servern verstanden wird: Set-DynamicDistributionGroup –Identity 'Old Exchange 2003 Users' –ForceUpgrade
TIPP Abfragen für dynamische Verteilergruppen verfügen über einen bestimmten Gültigkeitsbereich, der festlegt, welche Active Directory-Objekte bei der Auswertung der Abfrage berücksichtigt werden sollen. Dieser Gültigkeitsbereich ist in der Eigenschaft RecipientContainer der Abfrage gespeichert. Es ist wichtig, den Gültigkeitsbereich korrekt festzulegen, da er sich stark darauf auswirkt, welche Objekte die Abfrage zurückgibt, und damit auch darauf, wer an die Gruppe adressierte Nachrichten erhält. Ist der Gültigkeitsbereich zu eng bemessen, werden unter Umständen gar keine Objekte gefunden, was dazu führt, dass eine Nachricht an niemanden übermittelt wird, ist er dagegen zu großzügig eingestellt, kann es passieren, dass eine Nachricht an zehntausende Postfächer gesendet wird, obwohl sie nur für wenige Empfänger gedacht war. Möglicherweise kann das Cmdlet die LDAP-Abfrage nicht ins OPATH-Format übertragen werden, besonders dann, wenn Sie eine maßgeschneiderte LDAP-Abfrage für Exchange Server 2003 erstellt haben. In diesen Fall gibt Exchange eine Fehlermeldung zurück und Sie müssen eine neue dynamische Verteilergruppe für Exchange Server 2010 erstellen, um die ältere Gruppe zu ersetzen.
Erstellen neuer dynamischer Verteilergruppen Sie können vorgefertigte oder benutzerdefinierte OPATH-Abfragen für dynamische Verteilergruppen erstellen. Vordefinierte Abfragen werden zwar am häufigsten verwendet, sind jedoch auch am stärksten eingeschränkten, da sie auf begrenzten Kriterien basieren. Der Vorteil vordefinierter Abfragen besteht darin, dass sie sich leicht mithilfe eines Assistenten der Verwaltungskonsole einrichten lassen, der OPATH-Abfragen für Sie erstellt. Da sie auf einem eingeschränkten Satz von Kriterien basieren, sind vorgefertigte Abfragen auf Leistung ausgelegt. Benutzerdefinierte Abfragen sind dagegen flexibler, weil Sie hierbei praktisch Ihre eigene OPATH-Abfrage erstellen und über die Verwaltungsshell zur Gruppe hinzufügen. Andererseits sind benutzerdefinierte Abfragen schwerer zu erstellen und zu warten und laufen meist ein wenig langsamer als vordefinierte Abfragen. Bevor Sie den Assistenten starten, sollten Sie sich die Zeit nehmen, drei entscheidende Merkmale der neuen Gruppe festzulegen: 쐍 Gültigkeitsbereich der Abfrage Active Directory kann nur Empfänger im Gültigkeitsbereich der Abfrage zurückgeben. Der Gültigkeitsbereich umfasst entweder eine Organisationseinheit mit ihren Unterordnern oder die gesamte Organisation. Wollen Sie gezielt Empfänger aus verschiedenen Organisationseinheiten (oder Domänen) aufnehmen, müssen Sie gesonderte Verteilergruppen für jede der betreffenden Organisationseinheiten anlegen und diese Gruppen dann in einer übergeordneten Gruppe miteinander kombinieren. 쐍 Empfänger Sie können alle Arten von E-Mail-aktivieren Empfängern einschließen oder nur einen bestimmten Typ, etwa Empfänger mit Exchange-Postfächern. 쐍 Auswahlkriterien Vordefinierte Abfragen ermöglichen des Ihnen, nach folgenden Active Directory-Eigenschaften zu filtern:
342
Dynamische Verteilergruppen
왍 Firma (Organization) 왍 Benutzerdefinierte Attribute (CustomAttribute1 bis CustomAttribute15) Sie können mehrere Werte für die in den Kriterien enthaltenen Eigenschaften angeben. So können Sie beispielsweise nach Benutzern in den Abteilungen Sales und Marketing suchen, die in der Firma Coho oder Coho Winery arbeiten. Der Assistent führt Sie durch die Auswahl der gewünschten Kriterien sowie der Werte für etwaige Filter. Abbildung 6.34 zeigt den Satz von Eigenschaften, der für vordefinierte Filter zur Verfügung steht. HINWEIS Sie müssen Werte angeben, die Exchange zur Überprüfung nutzen kann. In diesem Fall möchten wir Benutzer finden, die in Irland ansässig sind. Es ist recht ungewöhnlich, dass die Eigenschaft Country (Land/Region) hierfür nicht zur Verfügung steht, da man eigentlich annehmen müsste, dass diese Eigenschaft eine der am häufigsten verwendeten ist. Microsoft hat sie jedoch nicht ausgewählt, weshalb wir stattdessen die Eigenschaft StateorProvince (Bundesland/ Kanton) verwendet haben. Damit die Gruppe auch erwartungsgemäß funktioniert, müssen wir ihr natürlich die gesuchten Werte übergeben. Abbildg. 6.34
Festlegen der Filterbedingungen für eine dynamische Verteilergruppe
Die Schaltfläche Vorschau unten rechts in Abbildung 6.34 ist äußerst nützlich, da sie es Ihnen erlaubt, zu testen, wie effektiv die von Ihnen erstellten Filter arbeiten. Enthält Active Directory die korrekten Werte, sollten Sie zu einem ähnlichen Ergebnis wie dem in Abbildung 6.35 kommen.
343
Verwalten von E-Mailaktivierten Empfängern
왍 Bundesland oder Kanton (StateorProvince) 왍 Abteilung (Department)
Kapitel 6 Abbildg. 6.35
Verwalten von E-Mail-aktivierten Empfängern
Anzeigen des Ergebnisses eines Filters
TIPP Es empfiehlt sich, die mithilfe des Filters gefundene Liste von Empfängern noch einmal durchzusehen, um sicherzugehen, dass nur die richtigen Empfänger enthalten sind. Sind die in Active Directory eingegebenen Daten fehlerhaft oder unvollständig, ist das größte Problem beim Auffinden von Empfängern mithilfe von Filtern ein falscher Gültigkeitsbereich. Denken Sie daran, dass der von Exchange generierte Filter bei einer bestimmten Organisationseinheit in Active Directory mit der Suche beginnt und Objekte ausschließlich an dieser Stelle sowie in untergeordneten Organisationseinheiten findet. Wenn Sie keine Organisationseinheit angeben, durchsucht er die gesamte Organisation. Sobald Sie sich vergewissert haben, dass der Filter die richtigen Ergebnisse zutage fördert, können Sie den Assistenten abschließen und Exchange die dynamische Verteilergruppe erstellen lassen (siehe Abbildung 6.36). Abbildg. 6.36
344
Fertigstellen der neuen dynamischen Verteilergruppe im Assistenten
Beim Speichern der neuen Gruppe erstellt Exchange eine OPATH-Abfrage und legt sie sowohl im OPATH- als auch im LDAP-Format ab. Sie können sich diese Abfragen mit dem Cmdlet Get-DynamicDistributionGroup ansehen.
Erstellen dynamischer Gruppen mit benutzerdefinierten Filtern Sie können über die Verwaltungskonsole keine dynamische Verteilergruppe erstellen, die auf einem benutzerdefinierten Filter basiert. Dazu müssen Sie das Cmdlet New-DynamicDistributionGroup in der Verwaltungsshell nutzen, um gewünschte OPATH-Abfrage einzurichten. Der folgende einzeilige Befehl erstellt zum Beispiel eine Gruppe mit einem Empfängerfilter, der sämtliche Mitarbeiter der Firma Contoso einschließt: New-DynamicDistributionGroup -Alias 'ContosoDynamicDL' -Name 'Contoso Company Users' –IncludedRecipients 'MailboxUsers' -RecipientContainer 'contoso.com' -OrganizationalUnit 'contoso.com/Groups'-Managedby 'Administrator'
Diesen nicht sonderlich komplexen Filter hätten Sie auch leicht mit dem Assistenten erstellen können. Beachten Sie, dass der Parameter -RecipientContainer festlegt, aus welchen Bereichen von Active Directory Objekte in die dynamische Verteilergruppe aufgenommen werden. In diesem Fall geben wir das Stammverzeichnis der Domäne contoso.com an, was zur Folge hat, dass sämtliche Objekte an dieser Stelle eingeschlossen werden. Nach dem Erstellen der neuen dynamischen Verteilergruppe können Sie mithilfe des Befehls Get-DynamicDistributionGroup nachsehen, ob ein vorgefertigter oder ein benutzerdefinierter Filter angewendet wird: Get-DynamicDistributionGroup –Identity 'Contoso Company Users' | Format-List Display-Name, RecipientFilterType, RecipientFilter, LDAPRecipientFilter DisplayName RecipientFilterType RecipientFilter
LdapRecipientFilter
: Contoso Company Users : Precanned : ((RecipientType -eq 'UserMailbox') -and (-not(Name -like 'SystemMailbox{*')) -and (-not(Name -like 'CAS_{*')) -and (-not(RecipientTypeDetailsValue -eq 'MailboxPlan')) -and (-not(RecipientTypeDetailsValue -eq 'DiscoveryMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'ArbitrationMailbox') )) : (&(objectClass=user)(objectCategory=person) (mailNickname=*)(msExchHomeServerName=*)(!(name=System Mailbox{*))(!(name=CAS_{*)) (!(msExchRecipientTypeDetails=16777216)) (!(msExchRecipientTypeDetails=536870912)) (!(msExchRecipientTypeDetails=8388608)))
Obwohl wir diese dynamische Verteilergruppe über die Verwaltungsshell erstellt haben, sieht sie wie eine vordefinierte Abfrage aus, ähnlich den mithilfe des Assistenten erstellten Filtern. Der Grund dafür ist, dass Exchange Filter bei der Erstellung so weit wie möglich optimiert. Die Überprüfung ergibt diesem Fall, dass es sich um einen vordefinierten Filter handelt, da er ausschließlich Eigenschaften aus dem Satz bedingter Eigenschaften verwendet, auf dem vordefinierte Filter basieren. Wie 345
Verwalten von E-Mailaktivierten Empfängern
Dynamische Verteilergruppen
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Sie wissen, stehen Ihnen bei der Erstellung dynamischer Verteilergruppen in der Verwaltungskonsole für die Filterung folgende bedingte Eigenschaften zur Verfügung: 쐍 ConditionalDepartment 쐍 ConditionalCompany 쐍 ConditionalStateOrProvince 쐍 Die 15 benutzerdefinierten Attribute (ConditionalCustomAttribute1 bis ConditionalCustomAttribute15) Wozu besondere bedingte Eigenschaften?
Es gibt einen Grund dafür, dass es diesen Satz an besonderen bedingten Eigenschaften gibt: Eine dynamische Verteilergruppe ist ein Empfängerobjekt. Sie können Eigenschaften für Empfängerobjekte festlegen, wozu auch die Eigenschaften zählen, die Sie eventuell bei der Erstellung eines Filters einsetzen möchten. Die Verwechslungsgefahr beim Definieren der Eigenschaften für die Gruppe an sich und der Eigenschaften, die der Filter zum Zusammenstellen der Gruppenmitgliedschaft nutzt, ist offensichtlich. Daher haben die Entwickler von Exchange die besonderen Filtereigenschaften hinzugefügt, um den Unterschied zwischen einer Gruppen- und einer Filtereigenschaft deutlich zu machen. Sollte der Satz an besonderen Eigenschaften für den zu erstellenden Filter nicht ausreichen, haben Sie die Möglichkeit, einen benutzerdefinierten Filter mit anderen Eigenschaften von Empfängerobjekten zu erstellen und ihn in der Eigenschaft RecipientFilter zu speichern. Beachten Sie, dass Sie einen benutzerdefinierten Filter nicht mit einem vordefinierten Filter kombinieren können. Die Faustregeln für das Erstellen von Filtern für dynamische Verteilergruppen lauten daher folgendermaßen: 쐍 Vordefinierte Filter lassen sich am leichtesten erstellen, allerdings sind Sie dabei auf einen begrenzten Satz an besonderen bedingten Eigenschaften beschränkt: Set-DynamicDistributionGroup –Identity 'UK Employees' –ConditionalStateOrProvince 'England', 'Wales', 'Scotland' –ConditionalCompany ''Contoso', 'Contoso UK', –ConditionalCustomAttribute1 'Employee' –IncludedRecipients 'MailboxUsers'
In diesem Beispiel gibt der Filter, den Exchange zum Aufbau der dynamischen Verteilergruppe verwendet, ein Ergebnis mit den folgenden Kriterien zurück: Sämtliche Konten aus England, Wales oder Schottland, die zur Firma Contoso oder Contoso UK gehören und unter ConditionalCustomAttribute1 den Wert Employee aufweisen. Sobald ein Filter mehrere Werte für eine Eigenschaft überprüfen muss, ist dies ein Hinweis darauf, dass es bei der Eingabe der Postfachdaten in gewisser Hinsicht an Richtlinien fehlt. Dynamische Verteilergruppen bieten zwar einerseits eine großartige Möglichkeit, mit stark fluktuierenden Adressdaten umzugehen, aber andererseits kann der Transportdienst sie oft nur langsam anhand von Active Directory auflösen, wenn mehr als einige hundert Adressen als Ergebnis zurückgegeben werden oder Sie zahlreiche Bedingungen hinzufügen. Dies ist einer der Fälle, in denen eine einfachere Lösung die bessere ist. 쐍 Wie im vorherigen Beispiel gezeigt, können Sie eine dynamische Verteilergruppe so einschränken, dass Nachrichten nur an bestimmte Empfängertypen gesendet werden, indem Sie den Parameter -IncludedRecipients festlegen. Sie können dann einen oder mehrere der folgenden Werte wählen: AllRecipients, MailboxUsers, Resources, MailContacts, MailGroups, MailUsers und sogar None (also eine Art von Anti-Option). 346
쐍 Reicht ein vordefinierter Filter nicht aus, können Sie eine Filterabfrage aufgrund einer breiteren Auswahl an Empfängereigenschaften erstellen und sie in der Eigenschaft -RecipientFilter speichern. Sie können Eigenschaften miteinander kombinieren und so auch einen komplexen Filter ganz nach Ihren Bedürfnissen erstellen: -RecipientFilter {Company –eq 'Contoso' –and Office –eq 'Dublin' –and Department ne 'Sales' –and ServerName –eq 'ExServer1' –and CustomAttribute15 –eq 'Employee'}
쐍 Vordefinierte und benutzerdefinierte Filter lassen sich in einer dynamischen Verteilergruppe nicht kombinieren. Zur Verdeutlichung wollen wir eine dynamische Verteilergruppe erstellen, die besonders für Administratoren nützlich ist. In vorherigen Versionen von Exchange war es üblich, Benutzer serverweise zu verwalten. Es ist daher sinnvoll, eine dynamische Verteilergruppe zu haben, die Nachrichten an alle Empfänger mit einem Postfach auf einem bestimmten Server sendet, damit wir sie über wichtige Ereignisse wie Serverabschaltungen für geplante Wartungsaufgaben oder Ähnliches unterrichten können. Den Befehl zum Erstellen einer neuen dynamischen Verteilergruppe mit einem Empfängerfilter, der alle Postfächer auf einem Exchange Server-Computer einschließt, sehen Sie im Anschluss. In diesem Fall müssen wir einen benutzerdefinierten Filter anwenden, da ServerName nicht zu den besonderen Eigenschaften zählt, die in vordefinierten Filtern verwendet werden. New-DynamicDistributionGroup -Name 'Mailboxes on ExServer1' -Alias MbxSvr1 -RecipientContainer 'contoso.com' -OrganizationalUnit Groups -RecipientFilter {ServerName -eq 'ExServer1'}
Dieser Code funktioniert ausgezeichnet in Exchange Server 2007, stellt jedoch ein Problem für Exchange Server 2010 dar, da nicht vorhersehbar ist, welcher Exchange Server 2010-Computer als Host für ein Postfach dient. Schließlich ist die Bindung zwischen Datenbank und Server aufgrund der Einführung von Datenbankverfügbarkeitsgruppen (siehe Kapitel 8, »Exchange auf dem Weg zur Hochverfügbarkeit«) aufgelöst worden. Die mit dem gezeigten Code erstellte dynamische Verteilergruppe funktioniert zwar in Exchange Server 2010, es gibt jedoch keine Garantie dafür, dass wir mit den gewünschten Empfängern kommunizieren können, wenn die Datenbank mit den entsprechenden Postfächern auf einen anderen Server umgeschaltet wurde. Wir müssen daher eine dynamische Verteilergruppe erstellen, die Nachrichten an sämtliche Postfächer in einer Datenbank sendet, statt an sämtliche Postfächer auf einem Server. Dies gestaltet sich ein wenig schwieriger, da Exchange verlangt, dass statt eines einfachen Anzeigenamens der vollständige definierte Name der Zielpostfachdatenbank als Teil des Filters übergeben wird. Vermutlich soll dadurch sichergestellt werden, dass immer die richtige Datenbank verwendet wird. Wie auch immer, der Befehl zum Erstellen einer neuen dynamischen Verteilergruppe, die Nachrichten an die Postfächer in der Datenbank VIP Mailboxes adressiert, lautet folgendermaßen: New-DynamicDistributionGroup –Name 'VIP Mailboxes' –Alias 'VIPList' –RecipientContainer 'contoso.com' –OrganizationalUnit 'Exchange Groups' –RecipientFilter {(RecipientType –eq 'UserMailbox' –and Database –eq "CN=VIP Mailboxes,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Administrative Groups,CN=contoso,CN=Microsoft Exchange,CN=Services, CN=Configuration,DC=contoso,DC=com")}
347
Verwalten von E-Mailaktivierten Empfängern
Dynamische Verteilergruppen
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Die Tatsache, dass wir den vollständigen definierten Namen für die Zielpostfachdatenbank verwenden müssen, macht den Befehl etwas komplizierter, da die definierten Namen jeglicher ExchangeObjekte einige entwicklungshistorisch bedingte Elemente enthalten, die den Namen länger machen als nötig. Um den vollständigen definierten Namen einer Postfachdatenbank zu ermitteln, können Sie das Cmdlet Get-MailboxDatabase wie folgt anwenden. Wenn die Befehle ausgeführt werden, enthält die Variable $DN den definieren Namen. Vergewissern Sie sich, dass Sie den exakten Wert im Filter verwenden und keine zusätzlichen Leerzeichen zwischen den Komponenten des definierten Namens vorhanden sind. $DB = Get-MailboxDatabase –Identity 'VIP Mailboxes'; $DN = $DB.DistinguishedName
Bevor Sie jedoch die neue Gruppe erstellen, können Sie die Wirksamkeit des Filters testen, indem Sie ihn an das Cmdlet Get-Mailbox übergeben. Funktioniert er mit diesem Cmdlet, so funktioniert er auch als benutzerdefinierter Empfängerfilter für eine dynamische Gruppe: Get-Mailbox –Filter {(RecipientType –eq 'UserMailbox' –and Database –eq "CN=VIP Mailboxes,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Administrative Groups,CN=contoso,CN=Microsoft Exchange,CN=Services, CN=Configuration,DC=contoso,DC=com")}
Sobald die neue Gruppe erstellt ist, können Sie ihre Eigenschaften einschließlich des benutzerdefinierten Filters in der Verwaltungskonsole überprüfen (siehe Abbildung 6.37). Abbildg. 6.37
Prüfen eines benutzerdefinierten Filters für eine dynamische Verteilergruppe
Es gibt kein Gegenstück zum Cmdlet Get-DistributionGroupMember, um die Mitglieder einer dynamischen Verteilergruppe aufzulisten. Sie können sich die Gruppenmitglieder mit der Vorschauoption der Verwaltungskonsole anzeigen lassen oder den Filter wie zuvor beschrieben an die Cmdlets Get-Mailbox oder Get-Recipient übergeben, um den Empfängersatz zu generieren. Bei Bedarf können Sie die Ausgabe beider Cmdlets zur leichteren Überprüfung in einer Textdatei speichern. 348
Moderierte Empfänger
Der in der Verwaltungskonsole gezeigte Filter wurde von Exchange angepasst, um einige besondere Empfängertypen auszuschließen. Die Schaltfläche Vorschau funktioniert hier ebenso wie bei vordefinierten Filtern, sodass Sie die Richtigkeit Ihres benutzerdefinierten Filters testen können. Sie können einen benutzerdefinierten Empfängerfilter für eine dynamische Verteilergruppe nicht mithilfe der Verwaltungskonsole bearbeiten. Hierzu müssen Sie einen neuen Empfängerfilter erstellen und die Gruppe mit dem Cmdlet Set-DynamicDistributionGroup aktualisieren.
Moderierte Empfänger Exchange Server 2010 ermöglicht Ihnen die Moderation von Postfächern, Kontakten und Verteilergruppen. Ist die Moderation aktiviert, muss jede an den betreffenden Empfänger adressierte Nachricht zuerst eine besondere Phase durchlaufen, in deren Verlauf die Nachricht angenommen oder abgelehnt wird. Abgelehnte Nachrichten werden an den Absender zurückgeschickt, angenommene Nachrichten an den ursprünglichen Empfänger zugestellt. Die Moderation wird innerhalb des Transportdienstes als eine Art Regel auf Nachrichten angewandt, nachdem diese durch den Speichertreiber eines Postfachservers übermittelt wurden. Eine Moderation ist beispielsweise dann sinnvoll, wenn bestimmte Postfächer (wie die von Mitgliedern der Geschäftsleitung) geschützt werden sollen, indem eine Überwachung der Kommunikation durch eine andere Person – etwa einen Administrator – erfolgt. Sie eignet sich auch, um externe Kontakte zu schützen, die zwar in der globalen Adressliste veröffentlicht werden, zu denen jedoch bestimmte Mitarbeiter der Firma keinen Kontakt aufnehmen können sollen. Da Gruppen häufig dazu genutzt werden, um Themen zu diskutieren und Informationen bekannt zu geben, die für viele Personen von großem Interesse sind, bilden sie die offensichtlichsten Kandidaten für eine Moderation. Deshalb sehen wir uns auch als Erstes an, wie Gruppen geschützt werden, um zu verdeutlichen, wie die eben beschriebene Möglichkeit funktioniert. Viele Unternehmen nutzen Verteilergruppen als komfortable Methode zur Kommunikation mit größeren Gruppen von Personen. Es ist eine äußerst praktische Angelegenheit, eine Nachricht an mehrere Menschen gleichzeitig senden zu können, doch manchmal müssen Sie dabei sicherstellen, dass nur geeignete Inhalte an große Verteilergruppen geschickt werden. Die Moderation bietet hier eine wirkungsvolle Möglichkeit, um festzulegen, welche Postfächer und Gruppen neue Nachrichten an eine Gruppe senden dürfen. Abbildung 6.38 zeigt die Eigenschaften einer Gruppe, bei der die Moderation gerade aktiviert wird. In diesem Fall haben wir eine Gruppe erstellt, um die Diskussion über Exchange Server 2010 zu erleichtern. Es kann vorkommen, dass Mitglieder einer Gruppe unangemessene Nachrichten an die Gruppe senden (zum Beispiel Werbung für Produkte oder Dienstleistungen). Damit die Diskussion nicht vom Thema abschweift, ernennen wir einen Moderator, der sämtliche Nachrichten, die an die Gruppe gesendet werden, überprüft. Wie Sie im Beispiel weiter hinten sehen, können wir auch einige Absender von der Moderation ausnehmen, sodass deren Nachrichten stets ohne Überprüfung an die Gruppe gesendet werden. Da sich die IT-Abteilung mit Exchange Server 2010 vermutlich am besten auskennt, lassen wir zu, dass Messagingadministratoren ihre Nachrichten direkt an die Gruppe schicken. Des Weiteren stellen wir die Eigenschaften so ein, dass nur interne Benutzer benachrichtigt werden, wenn ihre Nachrichten abgelehnt wurden. Benachrichtigungen dieser Art an jeden zu versenden, ist keine gute Idee, da Spammer dadurch eine Bestätigung erhalten, dass sie eine Nachricht an eine gültige E-Mail-Adresse gesendet haben.
349
Verwalten von E-Mailaktivierten Empfängern
Insidertipp: Änderungen an den Empfängertypen für benutzerdefinierte Filter
Kapitel 6 Abbildg. 6.38
Verwalten von E-Mail-aktivierten Empfängern
Festlegen der Moderationseigenschaften für eine Gruppe
Der Verwaltungsshellcode, mit dem Sie die genannten Eigenschaften zur Moderation von Nachrichten an eine Gruppe konfigurieren können, lautet wie folgt: Set-DistributionGroup –Identity 'Exchange Server 2010 Interest List' –ModerationEnabled $True –ModeratedBy 'Peled, Yael (IT)' –ByPassModerationFromSendersOrMembers 'Messaging Administrators' -ByPassNestedModerationEnabled $True –SendModerationNotifications Internal
Beachten Sie den Parameter -ByPassNestedModerationEnabled. Wird er auf $True gesetzt, so unterliegen sämtliche untergeordneten Gruppen, die ebenfalls eine Moderation erfordern, der Entscheidung des Moderators der Gruppe, an die die Nachricht adressiert ist. Mit anderen Worten, wenn Sie eine Nachricht an eine Gruppe mit dem Namen Investmentgenehmigungen schicken, in der eine weitere Gruppe mit dem Namen Verwaltungsausschuss enthalten ist, so sendet Exchange die Nachricht zuerst an den Moderator der Gruppe Investmentgenehmigungen. Erteilt dieser seine Zustimmung, prüft Exchange, ob die Moderation für untergeordnete Gruppen aktiviert ist. Falls ja, übermittelt Exchange die Nachricht an die nicht zur inneren Gruppe gehörenden Empfänger der Verteilergruppe Investmentgenehmigungen und sendet eine Genehmigungsanforderung an den Moderator der Gruppe Verwaltungsausschuss, der diese dann annehmen oder ablehnen kann. TIPP Um größere Verzögerungen bei der Übermittlung von Nachrichten zu vermeiden (und die Moderatoren zu entlasten), empfiehlt es sich, die verschachtelte Moderation nur auf besonders schützenswerte Gruppen anzuwenden.
350
Nachdem Sie die Moderation für eine Gruppe aktiviert haben, zeigt Exchange den Benutzern automatisch eine E-Mail-Info an, sobald sie eine Nachricht an diese Gruppe adressieren. Der Warnhinweis klärt den Benutzer darüber auf, dass seine Nachricht unter Umständen nicht sofort zugestellt wird, weil sie zuerst zur Genehmigung einen Moderationsprozess durchlaufen muss, bevor sie endgültig übermittelt werden kann (siehe Abbildung 6.39). Abbildg. 6.39
E-Mail-Info mit Warnhinweis auf eine moderierte Gruppe
TIPP Die Moderation wurde in Exchange Server 2010 neu eingeführt, weshalb diese Option nicht funktioniert, wenn ein Server mit einer älteren Version die Gruppenmitgliedschaft aufgliedert. Um dieses Problem zu umgehen, können Sie die Eigenschaften moderierter Gruppen so einstellen, dass diese immer von einem Hub-Transport-Server mit Exchange Server 2010 aufgegliedert werden. Weitere Informationen darüber, wie Sie explizit einen Hub-Transport-Server für die Gruppenaufgliederung angeben, finden Sie im Abschnitt »Gruppen aufgliedern« weiter vorne im Kapitel. Insidertipp: Aktivieren der Moderation für dynamische Verteilergruppen
Eine Moderation ist auch für dynamische Verteilergruppen möglich, lässt sich jedoch für diese Gruppen nicht über die Verwaltungskonsole aktivieren, da die Benutzeroberfläche diese Option nicht bietet. Sie können die Aktivierung der Moderation für dynamische Verteilergruppen über die Verwaltungsshell vornehmen, allerdings bieten die verfügbaren Parameter weniger Funktionen als bei normalen Gruppen. So ist beispielsweise die Erwägung einer Moderation von Nachrichten für untergeordnete Gruppen hinfällig, weil dynamische Verteilergruppen diese Option nicht bieten, sodass sämtliche Nachrichten, die an eine dynamische Verteilergruppe mit darin enthaltenen anderen moderierten Gruppen separate Genehmigungen für jede Gruppe erfordern. Um die Moderation für eine dynamische Verteilergruppe zu aktivieren, verwenden wir zum Beispiel folgenden Code:
351
Verwalten von E-Mailaktivierten Empfängern
Moderierte Empfänger
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Insidertipp: Aktivieren der Moderation für dynamische Verteilergruppen Set-DynamicDistributionGroup –Identity 'Sales Users' –ModerationEnabled $True –ModeratedBy 'Redmond, Tony' –ByPassModerationFromSendersOrMembers 'Sales Department' –SendModerationNotifications Internal
Abgesehen von der fehlenden Benutzerschnittstelle in der Verwaltungskonsole funktioniert die Moderation bei dynamischen Verteilergruppen genauso wie bei anderen moderierten Empfängern.
Moderationsanforderungen Moderatoren erhalten Benachrichtigungen wie die Abbildung 6.40, um Nachrichten genehmigen oder ablehnen zu können. Dieser Vorgang ist simpel und erfordert lediglich einen Mausklick des Moderators, um die Nachricht weiterzuverarbeiten. Sind mehrere Benutzer als Moderatoren für E-Mail-aktivierte Objekte ausgewiesen, sendet Exchange Kopien sämtlicher Moderationsbenachrichtigungen an alle. Der erste Moderator, der die Anforderung bearbeitet, entscheidet über das Ergebnis. Mit anderen Worten, wenn eine Moderationsanforderung an zwei Moderatoren gesendet wird und der erste die dazugehörige Nachricht genehmigt, übernimmt Exchange diese Entscheidung, selbst wenn der zweite Moderator einige Sekunden später versucht, die Nachricht abzulehnen. Sobald eine Entscheidung vorliegt, entfernt Exchange die Moderationsanforderung aus den Postfächern der anderen Moderatoren. Abbildg. 6.40
Eine Anforderung zur Genehmigung einer Nachricht an eine moderierte Gruppe gesendete
Logischerweise werden Moderatoren automatisch von der Moderation ausgenommen, da ein Moderator immer als Vertrauensperson gilt. Auch Gruppenbesitzer sind von der Moderation ausgeschlossen, denn wenn jemand eine Gruppe besitzt, so sollte er auch ungehindert Nachrichten an sie senden 352
dürfen. Weisen Sie einer Gruppe keinen Moderator zu, so übernimmt der Gruppenbesitzer automatisch diese Aufgabe und erhält Anforderungen zur Genehmigung von Nachrichten an die Gruppe. Hinter den Kulissen ist der Transportdienst dafür verantwortlich zu erkennen, wann eine Nachricht an einen moderierten Empfänger gesendet wird. In früheren Versionen von Exchange gab es keine moderierten Empfänger, weshalb keine Moderation erfolgt, sobald eine an eine Gruppe adressierte Nachricht durch einen Hub-Transport-Server mit Exchange Server 2007 verarbeitet wird. Die Lösung für dieses Problem besteht darin, die moderierte Gruppe so zu konfigurieren, dass sie immer einen -Hub-Transport-Server mit Exchange Server 2010 nutzt: Set-DistributionGroup –Identity 'Exchange Server 2010 Interest List' –ExpansionServer 'ExServer3'
Natürlich verwenden Postfächer und E-Mail-aktivierte Kontakte keine Aufgliederungsserver, sodass diese Lösung für diese Objekte nicht zur Debatte steht. Stattdessen sollte auf den Hub-Transport-Servern der Standorte, die diese Objekte enthalten, Exchange Server 2010 laufen (Hub-Transport-Server werden in der Regel vor Postfachservern bereitgestellt), wodurch das Problem behoben wird. Sobald der Kategorisierer eines Hub-Transport-Servers einen moderierten Empfänger entdeckt, leitet er die Nachricht an ein Vermittlungspostfach weiter. Hierbei handelt es sich um einen vorübergehenden Speicherort, an dem der Informationsspeicher moderierte Nachrichten so lange aufbewahrt, bis sie von jemandem weiterverarbeitet werden können. In diesem Fall verbleiben die Nachrichten so lange im Vermittlungspostfach, bis sie durch einen Gruppenmoderator, der die Genehmigungsanforderungen neben seiner regulären Post in seinem Postfach erhält, angenommen oder abgelehnt werden. Angenommene Nachrichten werden dann an die Gruppe geleitet und wie gewohnt übermittelt, während abgelehnte Nachrichten an den Absender zurückgehen. Ein Prozess mit dem Namen Information Assistant ist für die Überwachung der Nachrichten im Vermittlungspostfach sowie die Weiterleitung nach der Annahme oder Ablehnung durch den Moderator zuständig. Er sorgt außerdem dafür, dass das Vermittlungspostfach aufgeräumt bleibt, indem er alte oder verwaiste Anforderungen, die sich dort angesammelt haben, entsorgt. HINWEIS Die standardmäßige Ablauffrist für moderierte Nachrichten beträgt fünf Tage, doch dieses Intervall lässt sich in Exchange Server 2010 konfigurieren. Sobald diese Frist für eine Nachricht abgelaufen ist, sendet Exchange diese mit dem Hinweis an den Absender zurück, dass die Nachricht nicht übermittelt wurde, weil der Moderator es versäumt hat, eine Entscheidung zu fällen. Benutzer können den aktuellen Status einer Nachricht, die auf die Genehmigung durch einen Moderator wartet, zwar mithilfe von Zustellungs- oder Nachrichtenverfolgungsberichten abrufen, aber nichts tun, um die Moderatoren zur Bearbeitung zu bewegen, außer ihnen eine Nachricht zu schicken (die möglicherweise ignoriert wird) oder sie anzurufen. Exchange bietet keine besondere Warteschlange für zu moderierende Nachrichten, die ein Administrator einsehen könnte, um daraufhin einen Moderator zur Bearbeitung aufzufordern oder eine Nachricht weiterzuleiten, wenn aus irgendeinem Grund kein Moderator verfügbar ist. Darüber hinaus kann sich ein Administrator nicht beim Vermittlungspostfach anmelden, um die Verarbeitung einer zu genehmigenden Nachricht zu beschleunigen. Alles hängt von der Genehmigung durch einen Moderator ab, und wenn diese ausbleibt und eine Nachricht verfällt, kann der Moderator nichts mehr dagegen unternehmen. Die Nachricht wird dann mit dem Status »Abgelehnt« zum Absender zurückgesendet.
353
Verwalten von E-Mailaktivierten Empfängern
Moderierte Empfänger
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Nachrichten können an Empfängerlisten gesendet werden, die sowohl moderierte als auch unmoderierte Empfänger umfassen. In diesem Fall teilt der Transportdienst die Nachricht sozusagen auf und sendet umgehend eine Kopie an die nicht moderierten Empfänger. Eine gesonderte Kopie wird ans Vermittlungspostfach übermittelt, wo sie auf die Bearbeitung durch einen Moderator wartet. Eine moderierte Gruppe kann auch Untergruppen enthalten, von denen einige ebenfalls eine Moderation erfordern. Sie können dann entweder einen eigenen Moderationsvorgang für jede Gruppe erlauben oder die Gruppe so einrichten, dass eine automatische Genehmigung für alle Untergruppen erfolgt, indem Sie die Option -AutoApproveNestedDLEnabled aktivieren: Set-DistributionGroup –Identity 'Exchange Server 2010 Interest List' –AutoApproveNestedDLEnabled $True
Aufnehmen von Nachrichten ins Journal
Indem Sie die entsprechende Option aktivieren, können Sie Exchange veranlassen, die Nachrichten, die das Vermittlungspostfach durchlaufen, ins Journal aufzunehmen. Dabei werden die folgenden Stadien erfasst: 쐍 Die Genehmigungsanforderung des Vermittlungspostfachs an den Moderator. Die ursprüngliche Nachricht wird als Anhang in dieser Nachricht gespeichert. 쐍 Die an das Vermittlungspostfach übermittelte Entscheidung (Genehmigung oder Ablehnung) des Moderators. 쐍 Wird die Nachricht genehmigt, wird die an die Mitglieder der Verteilergruppe gesendete endgültige Version erfasst. Ein Vermittlungspostfach wird bei der Installation von Exchange automatisch angelegt. Abgesehen von anderen Funktionen, wie dem Speichern von Metadaten aus einer Postfachsuche, dient es zur Verarbeitung von moderierten Nachrichten für alle moderierten Objekte, sofern Sie keine zusätzlichen Vermittlungspostfächer für diesen Zweck erstellen und nutzen. Sie werden jedoch sehr wahrscheinlich keine weiteren Vermittlungspostfächer benötigen, solange Sie die Verarbeitungslast nicht über mehrere Standorte hinweg verteilen müssen, weil Sie extensiven Gebrauch von moderierten Empfängerlisten machen. Exchange nimmt keinen Lastenausgleich für moderierte Empfänger über mehrere verfügbare Vermittlungspostfächer vor. Dies müssen Sie manuell erledigen, indem Sie die Eigenschaft ArbitrationMailbox für den Empfänger aktivieren, um ihn dazu veranlassen, ein bestimmtes Vermittlungspostfach zu verwenden: Set-DistributionGroup –Identity 'Exchange Server 2010 Interest List' –ArbitrationMailbox 'ArbMbx London'
Moderierte Postfächer Viele Exchange-Bereitstellungen erfordern den Schutz von Postfächern, deren Inhalte das Unternehmen als besonders sensibel erachtet. Die Moderation bietet eine wirkungsvolle Lösung für dieses Problem, allerdings können Sie die Postfachmoderation nur über die Exchange-Verwaltungsshell realisieren. Im folgenden Beispiel richten wir eine Moderation für das Postfach des Geschäftsführers ein, wobei die eingehenden Nachrichten durch einen Assistenten der Geschäftsleitung bearbeitet werden. Wie Sie in Abbildung 6.41 sehen, wird dem Benutzer eine E-Mail-Info angezeigt, sobald er eine Nachricht an das Postfach der Geschäftsleitung adressiert. Weil das Postfach moderiert ist, zeigt
354
Exchange außerdem eine Standard-E-Mail-Info an, um den Benutzer auf mögliche Verzögerungen hinzuweisen, es ist jedoch sinnvoll, solche zusätzlichen Informationen in einer benutzerdefinierten E-Mail-Info anzugeben, um diese Tatsache klar hervorzuheben. Abbildg. 6.41
E-Mail-Infos für ein moderiertes Postfach
Wie Exchange Server 2010 E-Mail-Infos implementiert und welche Clients damit umgehen können, erfahren Sie in Kapitel 12. Aktivieren Sie mit dem folgenden Befehl die Moderation für das Postfach der Geschäftsleitung, richten eine Liste von Benutzern ein, deren Nachrichten unmoderiert eingehen dürfen, und erstellen eine benutzerdefinierte E-Mail-Info. Set-Mailbox –Identity 'CEO Mailbox' –ModeratedBy 'CEO Executive Assistant' –ModerationEnabled $True –ByPassModerationFromSendersOrMembers 'Executive Committee' –MailTip 'Nachrichten an den Geschäftsführer werden vor der Zustellung vom Chefsekretariat (851-1157) geprüft.'
Sie können die Aufgabe der Moderation nur an andere Postfächer delegieren und nicht an eine Verteiler- oder gar eine Sicherheitsgruppe. Wenn Sie die Verantwortung für die Moderation auf mehrere Benutzer übertragen möchten, müssen Sie jedes Postfach einzeln dafür festlegen: Set-Mailbox –Identity 'CEO Mailbox' –ModerationEnabled $True –ModeratedBy 'CEO Executive Assistant', 'CEO Support Team'
Zu guter Letzt können wir noch E-Mail-aktivierte Kontakte schützen. Der folgende Befehl zeigt, wie wir die Moderation auf einen E-Mail-Kontakt anwenden können, der auf einen externen Empfänger unseres PR-Büros verweist. Da wir nicht möchten, dass jeder in der Firma mit diesem Büro kommunizieren kann, aktivieren wir die Moderation und nehmen die Mitglieder der Marketingabteilung davon aus. Set-MailContact –Identity 'PR Agency' –ModeratedBy 'PR Administrator' –ModerationEnabled $True –ByPassModerationFromSendersOrMembers 'Marketing Dept'
355
Verwalten von E-Mailaktivierten Empfängern
Moderierte Empfänger
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
E-Mail-aktivierte Kontakte E-Mail-aktivierte Kontakte bieten eine komfortable Methode, externe Korrespondenten in die globale Adressliste aufzunehmen. Üblicherweise stehen Kontakte für Personen in anderen Firmen, denen eine Reihe von Benutzern regelmäßig Nachrichten senden muss. Sie dienen in der Regel dazu, die Kommunikation mit bestimmten Personen oder Dienstpostfächern externer Zulieferer (wie PR-Agenturen) zu erleichtern. Um einen neuen Kontakt zu erstellen, wechseln Sie unter Empfängerkonfiguration in den Bereich E-Mail-Kontakt und klicken im Aktionsbereich auf Neuer E-Mail-Kontakt. Der Assistent ist hierbei quasi selbsterklärend, da Sie nichts anderes tun, als ein Active Directory-Objekt zu erstellen, das einige Informationen über den Kontakt enthalten soll, vor allem die E-Mail-Adresse. Einen E-Mail-Kontakt über die Verwaltungsshell zu erstellen, ist da schon interessanter, da Ihnen hier mehr Optionen zur Verfügung stehen. Das folgende Beispiel zeigt einen Befehl zum Erstellen eines neuen E-Mail-aktivierten Kontakts. Beachten Sie, dass die E-Mail-Adresse eindeutig sein muss. New-MailContact -ExternalEmailAddress 'SMTP:[email protected]' -Name 'Jones, Jack' -Alias 'JackJones' -FirstName 'Jack' -Initials '' -LastName 'Jones' -OrganizationalUnit 'contoso.com/Exchange Contacts'
Dieser Befehl nutzt nur einen kleinen Teil der verfügbaren Parameter, um den neuen E-Mail-Kontakt zu verwalten. So können Sie beispielsweise festlegen, dass der E-Mail-Kontakt nur reine Textnachrichten bis zu einer bestimmten Größe erhalten darf. Set-MailContact –Identity 'Jones, David' –MessageFormat 'Text' –MessageBodyFormat 'Text' –MaxReceiveSize 200KB –UsePreferMessageFormat $False
Wie anderen E-Mail-aktivierten Objekten können Sie auch E-Mail-Kontakten einen Moderator zuweisen, damit sämtliche an ihn adressierte Nachrichten zuerst zur Genehmigung an einen anderen Benutzer gehen, bevor sie schließlich durch Exchange an den Kontakt übermittelt werden. Angenommen, Sie haben einen Kontakt in einer PR-Agentur, möchten aber nicht, dass jedermann in Ihrer Firma Anfragen für Interviews, neue Werbekampagnen und anderes dorthin schicken kann. In diesem Fall können Sie mit einem Befehl wie dem folgenden die Nachrichten zuerst an einen Moderator leiten. Wie Sie vielleicht schon bemerkt haben, nutze ich gerne die E-Mail-Info-Funktion (siehe Kapitel 12), um die Benutzer gleich im Vorfeld darauf aufmerksam zu machen, dass ihre Nachricht an einen Kontakt möglicherweise nicht sofort übermittelt wird. Set-MailContact –Identity 'PR Agency' –ModeratedBy 'Cook, Kevin' –ModerationEnabled $True SendModeratorNotifications 'Always' –MailTip 'Messages to the PR Agency are moderated by Kevin Cook'
Eine weitere Möglichkeit, zu verhindern, dass sämtliche Benutzer Nachrichten an einen Kontakt senden können, besteht darin, ihn so zu konfigurieren, dass Exchange nur Nachrichten von bestimmten Benutzern erlaubt. Aus verwaltungstechnischer Sicht eignet sich die Verwendung einer Gruppe hierfür am besten. Set-MailContact –Identity 'PR Agency' –AcceptMessagesOnlyFromSendersOrMembers 'PR Department' –MailTip 'Only members of the PR department are allowed to communicate with our PR agency'
356
E-Mail-aktivierte Kontakte
E-Mail-Benutzer und Kontakte gleichen sich darin, dass beide Objekttypen über externe E-MailAdressen verfügen. Es gibt jedoch einen wichtigen Unterschied: Kontakte sind in der Regel mit Personen verbunden, die keine Beziehung zu Ihrem Unternehmen haben, während E-Mail-Benutzer mit Active Directory-Konten verknüpft sind. Aus diesem Grund eignen sich E-Mail-Kontakte am besten für Personen, die außerhalb der Firma arbeiten, während E-Mail-Benutzer in der Regel die beste Wahl für interne Mitarbeiter sind. Insidertipp: E-Mail-Benutzer und Sicherheitsgruppen
Im Wesentlichen gibt es diesen Empfängertyp, um es Ihnen zu ermöglichen, auch Benutzer zur globalen Adressliste hinzuzufügen, die ein anderes E-Mail-System nutzen. Da E-Mail-Benutzer mit Active Directory-Konten verknüpft sind, sind sie auch Sicherheitsprinzipale und lassen sich daher zu Sicherheitsverteilergruppen hinzufügen, die den Zugriff auf Ressourcen ermöglichen. Sie können auch Kontakte zu Sicherheitsgruppen hinzufügen, was jedoch lediglich dazu führt, dass die Kontakte dann alle an die Gruppe gesendeten Nachrichten empfangen können. Für E-Mail-Benutzer gibt es keinen eigenen Bereich in der Verwaltungskonsole, da sie als eine Art von Kontakten behandelt werden. Klicken Sie unter Kontakte im Aktionsbereich auf Neuer E-Mail-Benutzer, um den Assistenten zum Erstellen eines neuen E-Mail-Benutzers zu starten. Wenn Sie einen neuen E-Mail-Benutzer erstellen, verknüpfen Sie ihn mit einem bestehenden Active Directory-Konto oder erstellen ein neues Konto. Im letzteren Fall müssen Sie Informationen für das Konto angeben, ähnlich wie beim Erstellen eines neuen Kontos für ein Postfach. Auf der ersten Seite des Assistenten geben Sie Informationen wie den Vor- und Nachnamen des Benutzers ein, auf der zweiten (siehe Abbildung 6.42) seine E-Mail-Adresse. Abbildg. 6.42
Anlegen eines neuen E-Mail-Benutzers
357
Verwalten von E-Mailaktivierten Empfängern
E-Mail-Benutzer
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Der Code, den die Verwaltungskonsole zum Erstellen eines neuen E-Mail-Benutzers generiert, ist dem für ein neues Postfach recht ähnlich: New-MailUser -Name 'Hamlin, Jay' -Alias 'HamlinJay' -OrganizationalUnit 'contoso.com/Users' -UserPrincipalName '[email protected]' -SamAccountName 'Hamlin' -FirstName 'Jay' -Initials '' -LastName 'Hamlin' -Password 'System.Security.SecureString' -ResetPasswordOnNextLogon $True -ExternalEmailAddress 'SMTP:[email protected]'
Wie für Kontakte sind auch für E-Mail-Benutzer Moderation und E-Mail-Info möglich. Allerdings ist die Verwaltungsshell etwas inkonsistent: So können Sie zum Beispiel mithilfe von New-MailUser keine E-Mail-Info erstellen, sondern müssen dies nachträglich über das Cmdlet Set-MailUser für einen bereits vorhandenen E-Mail-Benutzer erledigen: Set-MailUser –Identity 'Hamlin, Jay' –MailTip 'Messages sent to this address only support plain text messages'
Ressourcenpostfächer In Exchange Server 2010 und 2007 können Sie Postfächer für Räume anlegen, die dann zu Besprechungsanforderungen hinzugefügt werden können. Gerätepostfächer sind eine weitere Postfachvariante, um bestimmte Objekte zu repräsentieren (wie Whiteboards, Projektoren und Tische), die bei Besprechungen in diesen Räumen zum Einsatz kommen. Wie alle Postfächer beanspruchen auch Raum- und Gerätepostfächer Platz in Datenbanken, jedoch unterscheiden sie sich von gewöhnlichen Postfächern durch ihren Typ sowie die verfügbaren Eigenschaften. Beide Postfacharten werden unter dem Begriff Ressourcenpostfächer zusammengefasst. HINWEIS Die Windows-Konten von Ressourcenpostfächern sind deaktiviert. Um normale Benutzerkonten und Ressourcenpostfächer voneinander zu trennen, empfiehlt es sich, sie in separaten Organisationseinheiten in Active Directory zu platzieren. Niemand muss sich jemals bei einem Raum- oder Gerätepostfach anmelden, um die empfangenen Besprechungsanforderungen zu bearbeiten. Wie wir sehen werden, ist die Ressourcenbuchungsautomatik in der Lage, diese Anforderungen automatisch zu verarbeiten und Buchungen zu bestätigen oder abzulehnen, wenn jemand anderes bereits den Raum gebucht hat. Auch wenn Exchange eine nützliche Adressliste namens Alle Räume bereitstellt, die Sie zum Herausfiltern von Raumpostfächern aus der globalen Adressliste verwenden können (siehe Abbildung 6.43), ist es dennoch wichtig, eine geeignete Namenskonvention zu verwenden, um Raumpostfächer für die Benutzer klar zu kennzeichnen. Manche Unternehmen benennen ihre Räume nach Städten, andere nach Prominenten und wieder andere nach wissenschaftlichen Errungenschaften. Unabhängig davon, welche Namenskonvention Sie verwenden, müssen Sie sicherstellen, dass sie auch konsequent eingehalten wird, damit die Benutzer die Räume leicht finden können.
358
Ressourcenpostfächer
Anzeigen von Raumpostfächern in der globalen Adressliste
Verwalten von E-Mailaktivierten Empfängern
Abbildg. 6.43
Outlook und OWA können Raumpostfächer in Kalenderanforderungen einbinden. Wie in Abbildung 6.44 gezeigt, unterscheidet der OWA-Terminplanungs-Assistent klar zwischen Besprechungsteilnehmern und dem für die Besprechung ausgewählten Raum, wenn ein Benutzer eine neue Besprechung erstellt. Die Outlook-Version des Terminplanungs-Assistenten erlaubt es Ihnen, den Namen eines Raumes in die Teilnehmerliste einzutragen oder einen Raum auszuwählen, indem Sie auf Raum hinzufügen klicken. Abbildg. 6.44
Einfügen von Räumen in eine OWA-Besprechungsanforderung.
359
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Mit folgendem Befehl können Sie sich die aktuelle Liste von Raumpostfächern anzeigen lassen: Get-Mailbox –Filter {ResourceType –eq 'Room'} | Format-Table Name, Res* -AutoSize Name ---Conference Room 14341 Executive Conference Room Preston Conference Room Liffey Conference Room London Conference Room Lisbon Conference Room Longford Conference Room Leitrim Conference Room Liverpool Conference Room Leixlip Conference Room
ResourceCapacity ResourceCustom ---------------- --------------{} {} {} {} 16 {Concall} 24 {Concall} {} 24 {Concall} 50 {Whiteboard, Concall, HALO} 100 {TV}
ResourceType -----------Room Room Room Room Room Room Room Room Room Room
Festlegen von benutzerdefinierten Eigenschaften für Ressourcenpostfächer Es werden zwei Eigenschaften aufgelistet, die Sie nutzen können, um den Benutzern beim Auswählen eines geeigneten Konferenzraumes Informationen über die jeweiligen Räume zu geben. Die Eigenschaft ResourceCapacity dient dazu, die Anzahl der Personen anzugeben, die in dem Raum Platz finden. Dies hat einen rein informativen Zweck, da Exchange Besprechungsanforderungen nicht mit intelligenten Funktionen ausstattet, etwa um zu überprüfen, ob die Anzahl der angegebenen Teilnehmer die Kapazität des gewählten Raumes übersteigt. Die Eigenschaft ResourceCustom erlaubt es Administratoren anzugeben, ob etwas Besonderes in dem Raum zur Verfügung steht. Bevor Sie diese Eigenschaft mit einem Wert versehen können, müssen Sie zuerst mit dem Cmdlet Set-ResourceConfig einen Satz von benutzerdefinierten Eigenschaften für die Ressourcenkonfiguration erstellen. So definieren Sie zum Beispiel mit dem folgenden Befehl einen grundlegenden Satz verschiedener Objekte, die in einem Raum enthalten sein können: Set-ResourceConfig –ResourcePropertySchema ("Room/TV", "Room/Concall", "Room/HALO", "Room/ Whiteboard", "Room/Video", "Room/ComfortableChairs")
Sie werden bemerken, dass die Ressourcenwerte keine Leerzeichen haben dürfen. Es gibt keine Benutzeroberfläche in der Verwaltungskonsole oder in der Exchange-Systemsteuerung, um diese benutzerdefinierten Eigenschaften zu verwalten. Um sie zu ändern, können Sie entweder den kompletten Satz umschreiben oder einige Codezeilen in der Verwaltungsshell eingeben: $CurrentConfig = Get-ResourceConfig $CurrentConfig.ResourcePropertySchema+="Room/PictureWindow" Set-ResourceConfig –ResourcePropertySchema $CurrentConfig.ResourcePropertySchema
Beachten Sie, dass sich unter benutzerdefinierten Eigenschaften auch solche befinden können, die zur Unterscheidung von Gerätepostfächern dienen. Alle bisherigen Einträge weisen das Präfix Room/ auf, um Exchange darauf hinzuweisen, dass sich diese Eigenschaften ausschließlich auf Raumpostfächer
360
beziehen. Eigenschaften für Gerätepostfächer erhalten das Präfix Equipment/ und können wie beschrieben hinzugefügt werden. Ist ein Raum zum Beispiel mit dem Videokonferenzsystem Halo ausgestattet, so kann dies im Anschluss an die Ressourcenkonfiguration mithilfe der entsprechenden Eigenschaft folgendermaßen angegeben werden: Set-Mailbox –Identity 'Liverpool Conference Room' –ResourceCustom ('HALO')
Dieser Befehl überschreibt sämtliche benutzerdefinierten Eigenschaften, die für das Postfach existieren. Sind mehrere benutzerdefinierte Ressourcen in einem Raum vorhanden, so können Sie diese wie folgt angeben: Set-Mailbox –Identity 'Liverpool Conference Room' –ResourceCustom ('HALO', 'Concall')
Selbstverständlich können Sie diese Eigenschaften auch über die Verwaltungskonsole festlegen, indem Sie das Postfach auswählen und dann zur Registerkarte Ressourcen - Allgemein wechseln. Abbildung 6.45 zeigt die Auswahlliste der verfügbaren benutzerdefinierten Eigenschaften, die dem mit Set-ResourceConfig definierten Satz von Eigenschaften entspricht. Da wir ein Raumpostfach gewählt haben, hat Exchange folglich einen Filter angewendet, sodass in der Auswahlliste nur die für Raumpostfächer geltenden benutzerdefinierten Eigenschaften angezeigt werden. Abbildg. 6.45
Festlegen von benutzerdefinierten Eigenschaften für ein Raumpostfach
361
Verwalten von E-Mailaktivierten Empfängern
Ressourcenpostfächer
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Richtlinienanweisungen für die Ressourcenbuchungsautomatik Auf der Registerkarte Ressourcen - Allgemein finden Sie noch eine weitere wichtige Eigenschaft. Indem Sie die Ressourcenbuchungsautomatik aktivieren, weisen Sie Exchange an, alle eingehenden Besprechungsanforderungen für einen Raum durch diese Automatik überwachen und sie auch darüber entscheiden zu lassen, ob eine Anforderung akzeptiert wird oder nicht. Dabei entscheiden die jeweils für ein Raumpostfach eingestellten Richtlinien darüber, wie die Ressourcenbuchungsautomatik vorgeht. Jedes Raumpostfach kann über eine eigene Buchungsrichtlinie verfügen, die Sie auf der Registerkarte Ressourcenrichtlinie einsehen können. Abbildung 6.46 zeigt zwei wichtige Registerkarten des Eigenschaftendialogfelds mit Anweisungen für die Ressourcenbuchungsautomatik: Ressourceninformationen und Ressourcenrichtlinie. Abbildg. 6.46
Anzeigen der Ressourceninformationen und der Buchungsrichtlinien für ein Raumpostfach.
Auf der Registerkarte Ressourceninformationen können Sie festlegen, wie die Ressourcenbuchungsautomatik mit Objekten umgeht, die sie zum Kalender des Raumpostfachs hinzufügt. Diese Informationen werden angezeigt, sobald ein Benutzer den Kalender des jeweiligen Raums durchsucht, um einen passenden Zeitpunkt für eine Besprechung zu finden. Anhänge, Kommentare und Themen für Besprechungen werden dagegen entfernt, da sie oftmals vertrauliche Informationen enthalten, die nicht jeder sehen soll, der nach einem freien Termin sucht. Wie Sie sehen, gibt es auch eine Eigenschaft, die steuert, wie nicht kalenderbezogene Objekte verarbeitet werden, wenn sie im Postfach eingehen. Raumpostfächer haben SMTP-Adressen und können genau wie normale Postfächer E-Mails empfangen. Indem Sie Exchange anweisen, nicht kalenderspezifische Objekte zu entfernen, verhindern Sie, dass sich das
362
Postfach mit unnötigem Material anfüllt. Der Kalenderassistent lässt sich so konfigurieren, dass alte Besprechungsanforderungen und Antworten aus einem Raumpostfach gelöscht werden, Sie können aber auch eine Aufbewahrungsrichtlinie für Raumpostfächer festlegen, sodass überholte Objekte nach einer angemessenen Zeit (zum Beispiel zwei Jahre) aus den Kalendern gelöscht werden. Im unteren Teil der Registerkarte Ressourceninformationen kann der Administrator zusätzlichen Text eingeben, der dann in Benachrichtigungen über die Annahme oder Ablehnung von Besprechungsanforderungen eingefügt wird. Diese Eigenschaft wird auch häufig dazu genutzt, um den Raum zu beschreiben oder Hinweise zu geben, wie man dorthin gelangt, wenn er sich in einem jener riesigen, labyrinthartigen Gebäude befindet, wie sie bei großen Unternehmen oft zu finden sind. Das Beispiel in Abbildung 6.47 zeigt, wie der Text den Benutzern angezeigt wird. Auf der Registerkarte Ressourcenrichtlinie legen Sie Grundregeln für die Ressourcenbuchungsautomatik fest, die beim Prüfen eingehender Besprechungsanforderungen gelten sollen. Zu den grundlegenden Voraussetzungen zählt zum Beispiel, ob ein Raum auch außerhalb der normalen Arbeitszeit verfügbar ist, wie lange Besprechungen dauern dürfen (1.440 Minuten, also 24 Stunden, ist der Standardwert; da dies ganztätige Besprechungen ermöglichen würde, sollten Sie vielleicht einen niedrigeren Wert festlegen) und ob Anforderungen für wiederholte Besprechungen genehmigt werden sollen, etwa, wenn sich ein Team jede Woche zur selben Zeit trifft. Sie können zum Beispiel auch unterbinden, dass ein Raum zu weit im Voraus gebucht werden kann (180 Tage ist der Standardwert), und es so einrichten, dass Terminkonflikte bis zu einem bestimmten Grad automatisch gelöst werden. So dient die Eigenschaft Zulässiger Konfliktprozentsatz dazu, festzulegen, wie oft eine sich wiederholende Besprechung stattfinden darf, die zu Konflikten mit anderen Anforderungen führt. Wird dieser Wert beispielsweise auf 20 gesetzt, wird jede Anforderung für eine wiederkehrende Besprechung abgelehnt, wenn mehr als 20% dieser Termine einen Konflikt verursachen. Abbildg. 6.47
Eine Besprechung wird durch die Ressourcenbuchungsautomatik abgelehnt
363
Verwalten von E-Mailaktivierten Empfängern
Ressourcenpostfächer
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
Insidertipp: Gleichzeitige Belegung von Räumen
In Wahrheit ist es natürlich so, dass bei einem Terminkonflikt die ranghöhere Person ihr Meeting abhalten darf, aber da sich Exchange nicht um Unternehmenshierarchien und -politik kümmert, kann es Ihnen lediglich ermöglichen, festzulegen, ob miteinander in Konflikt stehende Besprechungsanforderungen genehmigt oder sofort abgelehnt werden, und – falls sie genehmigt werden – wie viele Konflikte (Mehrfachbelegungen) pro Zeitfenster erlaubt sein sollen. Es wäre unklug, eine unbegrenzte Anzahl von Mehrfachbelegungen zuzulassen, da dies zu ärgerlichen Situationen führen würde, in denen mehrere Teams am selben Ort zur selben Zeit erscheinen, um ihre Besprechungen abzuhalten. Eine oder zwei Mehrfachbelegungen zuzulassen, ist dagegen akzeptabel, sofern ein Mitarbeiter den Raumkalender von Zeit zu Zeit überprüft und so den Konfliktlösungsalgorithmus durch menschliche Logik ergänzt. Um einem Benutzer Zugriff auf den Kalender eines Raumpostfachs zu gewähren, weisen Sie ihm mithilfe des Cmdlets Add-MailboxPermission das entsprechende Zugriffsrecht zu. Add-MailboxPermission –AccessRights FullAccess –User 'Smith, Samantha' –Identity 'Galway Conference Room'
Anschließend kann der Benutzer den Kalender genau wie jeden anderen gemeinsam genutzten Kalender öffnen und die Einträge durchsehen, um eventuelle Terminkonflikte zu lösen (siehe Abbildung 6.48). Abbildg. 6.48
364
Zugriff auf einen Raumkalender, um Terminkonflikte zu lösen
Die Kalendereigenschaften, die sich auf die Richtlinie auswirken, lassen sich mit dem Cmdlet GetCalendar-Processing aufrufen. Beachten Sie, dass es diese Eigenschaften nicht nur für Raumpostfächer, sondern für alle Postfächer gibt. In diesem Fall sehen wir uns die Kalenderverarbeitungseigenschaften für einen Raum an: Get-CalendarProcessing –Identity 'Leixlip Conference Room' | Format-Table AutomateProcessing AllowConflicts BookingWindowInDays MaximumDurationInMinutes AllowRecurringMeetings EnforceSchedulingHorizon ScheduleOnlyDuringWorkHours ConflictPercentageAllowed MaximumConflictInstances ForwardRequestsToDelegates DeleteAttachments DeleteComments RemovePrivateProperty DeleteSubject AddOrganizerToSubject DeleteNonCalendarItems TentativePendingApproval AutomateProcessing AllowConflicts BookingWindowInDays MaximumDurationInMinutes AllowRecurringMeetings EnforceSchedulingHorizon ScheduleOnlyDuringWorkHours ConflictPercentageAllowed MaximumConflictInstances ForwardRequestsToDelegates DeleteAttachments DeleteComments RemovePrivateProperty DeleteSubject AddOrganizerToSubject DeleteNonCalendarItems TentativePendingApproval EnableResponseDetails OrganizerInfo ResourceDelegates RequestOutOfPolicy
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
AutoAccept False 180 60 True True True 0 20 True True True True True True True True AutoAccept False 180 60 True True True 0 20 True True True True True True True True True True {contoso.com/Exchange Users/Smith, Samantha} {contoso/Exchange Users/VIP-Contracts Staff}
365
Verwalten von E-Mailaktivierten Empfängern
Ressourcenpostfächer
Kapitel 6
Verwalten von E-Mail-aktivierten Empfängern
AllRequestOutOfPolicy BookInPolicy AllBookInPolicy RequestInPolicy AllRequestInPolicy AddAdditionalResponse AdditionalResponse
: : : : : : :
RemoveOldMeetingMessages AddNewRequestsTentatively ProcessExternalMeetingMessages RemoveForwardedMeetingNotifications Identity
: : : : :
False True False True This room is best suited for IT department meetings. True True False False contoso.com/Exchange Users/Leixlip Conference Room
Die Eigenschaften lassen sich mit dem Cmdlet Set-CalendarProcessing ändern. Um beispielsweise das Buchungszeitfenster auf 45 Minuten zu begrenzen und Buchungsanforderungen nur 120 Tage im Voraus zu ermöglichen, verwenden Sie folgenden Code: Set-CalendarProcessing –Identity 'Leixlip Conference Room' –MaximumDurationInMinutes 45 –BookingWindowInDays 120
HINWEIS Die in Exchange Server 2007 vorhandenen Cmdlets Get-MailboxCalendarSettings und Set-MailboxCalendarSetting werden durch Get-CalendarProcessing und Set-CalendarProcessing ersetzt. Wenn Sie also mit Skripts arbeiten, die diese Cmdlets verwenden, müssen Sie deren Code anpassen. Mithilfe von Set-MailboxCalendarConfiguration können Sie festlegen, zu welchen Zeiten ein Raumpostfach zur Verfügung steht. Zuerst wollen wir jedoch herausfinden, wie die aktuellen Einstellungen aussehen, indem wir das Cmdlet Get-MailboxCalendarConfiguration verwenden. Eine bearbeitete Version der Ausgabe sehen Sie hier: Get-MailboxCalendarConfiguration –Identity 'Leixlip Conference Room' | Format-List WorkDays WorkingHoursStartTime WorkingHoursEndTime WorkingHoursTimeZone WeekStartDay
: : : : :
Weekdays 08:00:00 17:00:00 Pacific Standard Time Sunday
Da die Buchung von Konferenzräumen stark von zeitlichen Gegebenheiten abhängt, ist es wichtig, die Zeitzone des Postfachs korrekt einzustellen, sodass sie dem Standort des Konferenzraumes entspricht. Die Standardzeitzone wird von dem Server geerbt, auf dem das Postfach erstellt wurde. In diesem Fall wissen wir, dass PST unpassend ist, da sich unser Raum in Dublin befindet, weshalb wir die Zeitzone wie folgt korrigieren: Set-MailboxCalendarConfiguration –Identity Leixlip 'Conference Room' –WorkingHoursTimeZone 'GMT Standard Time'
366
Verarbeiten von Besprechungsanforderungen nach der Richtlinie Die Eigenschaft AutomateProcessing eines Raumpostfachs steuert, wie die Ressourcenbuchungsautomatik eingehende Anforderungen innerhalb der durch die Buchungsrichtlinie des Postfachs festgelegten Struktur verarbeitet. Drei Werte sind möglich: 쐍 None
Eingehende Besprechungsanforderungen werden nicht von Exchange verarbeitet.
쐍 AutoUpdate Dies ist die Standardeinstellung für alle Postfächer (einschließlich Raumpostfächer). Sie erlaubt es dem Kalenderassistenten, vorläufige Besprechungsanforderungen in Benutzerkalendern zu platzieren, ohne dass der Benutzer hierfür tätig werden muss. Er muss die Besprechungsanforderung lediglich öffnen und darauf antworten, bevor sie genehmigt oder abgelehnt wird. 쐍 AutoAccept Dieser Wert wird eingestellt, wenn Sie die Ressourcenbuchungsautomatik für ein Raumpostfach aktivieren. Die Automatik kann eingehende Anforderungen verarbeiten und sie anhand der Richtlinie genehmigen oder ablehnen. Anforderungen, Raumpostfächer in Besprechungen einzubinden, können entweder den Richtlinien entsprechen (»in-policy«) oder nicht (»out-of-policy«). Damit die Anforderung mit den Richtlinien in Einklang steht, muss sich die Besprechung innerhalb des erlaubten Buchungszeitfensters bewegen, eine angemessene Dauer haben, nicht mit anderen Besprechungsanforderungen in Konflikt geraten usw. Tabelle 6.5 enthält eine Liste der Eigenschaften, die steuern, wie die Ressourcenbuchungsautomatik Richtlinien auf eingehende Besprechungsanforderungen anwendet. Wie diese Eigenschaften für ein Postfach angezeigt werden, sehen Sie in Abbildung 6.49. Tabelle 6.5
Eigenschaften zur Steuerung der Verarbeitung von Raumbuchungen Eigenschaft
Bedeutung
AllBookInPolicy
Bei $True werden richtlinienkonforme Buchungsanforderungen automatisch durch die Buchungsautomatik genehmigt.
AllRequestInPolicy
Bei $True werden richtlinienkonforme Buchungsanforderungen aller Benutzer vorläufig durch die Buchungsautomatik genehmigt. Die Anforderungen müssen von einem Raumbeauftragten genehmigt werden, sofern die Eigenschaft AllBookInPolicy nicht auf $True gesetzt ist.
AllRequestOutofPolicy
Steuert, ob nicht richtlinienkonforme Buchungsanforderungen genehmigt werden dürfen. Sämtliche Anforderungen dieser Art müssen von einem Raumbeauftragten genehmigt werden.
BookInPolicy
Listet alle Benutzer auf, deren Buchungsanforderungen automatisch genehmigt werden.
RequestInPolicy
Listet alle Benutzer auf, die richtlinienkonforme Buchungsanforderungen einreichen dürfen. Sämtliche Anforderungen müssen von einem Raumbeauftragten genehmigt werden.
RequestOutofPolicy
Listet alle Benutzer auf, die nicht richtlinienkonforme Buchungsanforderungen einreichen dürfen. Sämtliche Anforderungen müssen von einem Raumbeauftragten genehmigt werden.
ProcessExternalMeetingMessages
Legt fest, ob Besprechungsanforderungen von Benutzern außerhalb der Exchange-Organisation angenommen werden.
367
Verwalten von E-Mailaktivierten Empfängern
Ressourcenpostfächer
Kapitel 6 Abbildg. 6.49
Verwalten von E-Mail-aktivierten Empfängern
Anzeigen von Eigenschaften für die Buchungsrichtlinien eines Raumpostfachs.
Ein Blick auf die in Abbildung 6.49 gezeigten Eigenschaften verrät uns Folgendes: 쐍 Alle Benutzer dürfen richtlinienkonforme Buchungsanforderungen senden (AllBookInPolicy und AllRequestInPolicy sind auf $True gesetzt). Es gibt keine besonderen Einschränkungen für die Genehmigung von Anforderungen durch bestimmte Benutzer (die Eigenschaften BookInPolicy und RequestInPolicy sind beide leer). 쐍 Nicht richtlinienkonforme Anforderungen vom Postfach Assistent der Geschäftsführung sowie von meinem eigenen Postfach werden für die Genehmigung durch einen Raumstellvertreter akzeptiert (die Eigenschaft RequestOutofPolicy enthält diese Information). Die Eigenschaft ProcessExternalMeetingMessages ist über keine Benutzerschnittstelle verfügbar. Sie ist standardmäßig auf $False gesetzt, sodass Raumbuchungsanforderungen von externen Absendern ignoriert werden. Setzt man sie auf $True, wendet die Ressourcenbuchungsautomatik dieselben Richtlinien an wie für interne Anforderungen. Selbstverständlich können Sie all diese Eigenschaften auch über die Verwaltungskonsole einstellen. Möchten Sie zum Beispiel alle Besprechungsanforderungen sämtlicher Benutzer an einen Raumbeauftragten zur Genehmigung weiterleiten, dann können Sie dies mit einem Befehl wie diesem erreichen: Set-CalendarProcessing –Identity 'Leixlip Conference Room' –AllRequestInPolicy $True –AllBookInPolicy $False
368
In der Eigenschaft BookInPolicy sind keine Ausnahmen festgelegt, sodass jede Besprechungsanforderung für den Raum an den (oder die) Raumbeauftragten weitergeleitet wird. Die jeweilige Anforderung wird dann als »vorläufig« im Kalender des entsprechenden Raumes eingetragen, bis ein Beauftragter sie entweder genehmigt oder ablehnt, indem er auf die Nachricht antwortet, die ihm die Ressourcenbuchungsautomatik diesbezüglich übermittelt hat. Die Besprechung behält den Status »vorläufig«, wenn kein Beauftragter für das Postfach festgelegt wurde. Beachten Sie, dass ein Beauftragter nicht seine eigene Besprechungsanforderung genehmigen kann. Um dieses Problem zu umgehen, sollten Sie Raumbeauftragte zu der Liste von Benutzern hinzufügen, deren Besprechungsanforderungen automatisch genehmigt werden. Um einer Person ausnahmsweise zu erlauben, bei einer Besprechungsanforderung die Genehmigung durch einen Raumbeauftragten zu umgehen, setzen wir ihren Namen einfach auf die Liste unter BookInPolicy. Der folgende Befehl setzt zum Beispiel JSmith auf diese Liste. Sie können Benutzer oder Gruppen mit ihrem Name, Alias, UPN oder ihrer SMTP-Adresse angeben: Set-CalendarProcessing –Identity 'Leitrim Conference Room' –BookInPolicy JSmith
Um mehrere Benutzer oder Gruppen auf diese Ausnahmeliste zu setzen, fügen Sie einfach deren Namen durch Kommata getrennt nacheinander hinzu.
Gerätepostfächer Gerätepostfächer und Raumpostfächer gleichen sich bezüglich der Eigenschaften, die Sie ihnen zuweisen können, um eine Richtlinie zur Steuerung des Buchungsvorgangs zu erstellen, und in der Art und Weise, wie die Ressourcenbuchungsautomatik eingehende Anforderungen überwacht und verarbeitet. Mithilfe des folgenden Befehls können Sie sich alle Gerätepostfächer innerhalb Ihres Unternehmens anzeigen lassen: Get-Mailbox –Filter {ResourceType –eq 'Equipment'}
Aus der Sicht des Benutzers werden Gerätepostfächer zu Besprechungen hinzugefügt wie andere Empfänger auch. Anders als bei Raumpostfächern bietet jedoch weder OWA noch Outlook eine besondere Oberfläche, die es dem Benutzer ermöglicht, Geräte für Besprechungen auszuwählen, und es gibt auch keine Adressliste »Alle Geräte«, die Sie nach bestimmten Geräten durchsuchen können. Aus diesem Grund ist es wichtig, die Namenskonvention für Gerätepostfächer so zu wählen, dass diese in der globalen Adressliste klar von anderen Postfächern zu unterscheiden sind.
Daten, überall Daten Wir wissen jetzt, wie wir Benutzer, Gruppen und Kontakte erstellen. Nun ist es an der Zeit, zum Herzstück von Exchange vorzudringen, die Grundlagen des Informationsspeichers zu erläutern und zu erfahren, wie er unter Exchange Server 2010 weiterentwickelt wurde, um den stetig wechselnden Anforderungen der E-Mail-Kommunikation Rechnung zu tragen. Auf zum Speicher!
369
Verwalten von E-Mailaktivierten Empfängern
Daten, überall Daten
Der Informationsspeicher von Exchange Server 2010
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
In diesem Kapitel: Lang lebe Jet!
373
Maximale Datenbankgröße
374
Ein-/Ausgabe
378
Datenbankverwaltung
387
Defragmentieren von Datenbanken
415
Statistiken der Datenbanknutzung
419
Transaktionsprotokolle
421
Und nun zu etwas völlig anderem
433
371
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Die Pflege und Weiterentwicklung eines Datenbanksystems ist keine leichte technische Herausforderung, vor allem wenn die Datenbanken mit Transaktionen eines breiten Spektrums umgehen müssen, von einfachen 10-KB-Nachrichten an einen einzelnen Empfänger bis zu Nachrichten mit einem großen Verteiler (dessen einzelne Adressen im Header jeweils für sich aufgelöst werden müssen) und einer angehängten PowerPoint-Datei von 10 MB. Microsoft hat immer viel Energie in die Optimierung der ESE-Datenbank (Extensible Storage Engine), ihres Schemas und des Informationsspeichers gesteckt, sobald eine neue Version von Exchange entwickelt wurde. Eine echte Weiterentwicklung aber begann erst mit Exchange Server 2007. Vielleicht erforderte der Informationsspeicher nicht so viel Arbeit, als der Hauptkonkurrent von Microsoft noch Lotus Notes war, als es nur relativ kleine Postfächer gab und Speichermöglichkeiten viel Geld kosteten. Es reichte aus, die Hintergrundwartung des Informationsspeichers zu verbessern und einige neue Funktionen wie den Papierkorb hinzuzufügen. Heute sind der Markt jedoch anders aus, und es besteht ein echter Bedarf dafür, den Betrieb von sehr großen Postfächern zu ermöglichen – sowohl um mit billigen Onlinediensten konkurrieren zu können, als auch um dem wachsenden Bedarf von Unternehmen nach Verbesserungen auf Gebieten wie der Hochverfügbarkeit gewachsen zu sein. Wahrscheinlich hätte Microsoft auch dann viel Entwicklungsarbeit in den Informationsspeicher investiert, wenn es Google nicht gäbe, aber es kann kein Zweifel daran bestehen, dass Wettbewerb einen bemerkenswerten Einfluss auf die Innovationsbereitschaft nehmen kann. Bei der Verbesserung des Informationsspeichers in Microsoft Exchange Server 2010 hatte das Enwicklungsteam von Microsoft folgende Hauptziele vor Augen: 쐍 Es sollte eine Verbesserung der E/A-Leistung, eine Senkung der Kosten und eine Vereinfachung der Speicherung erreicht werden. Außerdem sollten Speicherarchitekten mehr Flexibilität beim Anlegen des Speicherdesigns für Exchange haben. 쐍 In Exchange Server 2010 sollten Postfächer mit 10 GB genauso gut funktionieren wie Postfächer mit 1 GB in Exchange Server 2007. 쐍 Verfügbarkeit und Ausfallsicherheit von Postfächern sollten durch verstärkten Einsatz der Replikationstechniken erhöht werden, die ihr Debut in den Funktionen zur fortlaufenden Protokollreplikation von Exchange Server 2007 hatten. Darin zeigt sich eine neue Herangehensweise an die Forderung nach Hochverfügbarkeit in diesem Produkt. Der frühere Ansatz auf der Grundlage von Einzelkopieclustern, der mit der »Wolfpack«-Technologie und Exchange Server 5.5 eingeführt wurde, wird nicht länger verwendet. Ähnliche Verbesserungen wurden auch am Transportsystem vorgenommen, um die Chance dafür zu erhöhen, dass eine Nachricht niemals verloren gehen kann, ganz gleich, welche katastrophalen Fehler auftreten. Wenn Sie sich mit dem Exchange-Informationsspeicher beschäftigen, müssen Sie vor allem die drei folgenden Hauptkomponenten betrachten: 1. Die ESE (Extensible Storage Engine), also die Datenbank-Engine, die die Inhalte von Datenban-
ken für Postfächer und öffentliche Ordner auf der Ebene einzelner Seiten gliedert. 2. Der Informationsspeicher, der ein logisches Schema zur Definition der Inhalte von Datenbanken
für Postfächer und öffentliche Ordner und zur Ordnung dieser Inhalte festlegt. 3. Die EDB und die Transaktionsprotokolle. Bei der EDB handelt es sich um die Datenbankdatei auf
der Festplatte. Die Transaktionsprotokolle zeichnen alle Änderungen auf, die an einer Seite in der Datenbank vorgenommen werden (Hinzufügungen, Aktualisierungen, Löschungen), sodass ein Datenbankfehler dadurch wieder behoben werden kann, die in den Protokollen verzeichneten Transaktionen erneut durchzuführen. Außerdem werden die Transaktionsprotokolle dazu verwendet, die Daten auf andere Server zu replizieren und die Datenbankkopien somit synchron zu
372
halten. Damit ist es möglich, schnell von einer Kopie zu einer anderen umzuschalten, um den Benutzern weiterhin einen ununterbrochenen Dienst zu bieten, falls die primäre (aktive) Datenbank ausfällt. In diesem Kapitel sehen wir uns die wichtigsten Änderungen an, die Microsoft am Exchange Server 2010-Speicher vorgenommen hat. Außerdem werfen wir auch einen Blick auf die Beweggründe, die hinter diesen Änderungen stehen.
Lang lebe Jet! In Exchange Server 2010 wird weiterhin ESE verwendet, die Exchange-Version der DatenbankEngine Jet, die auch andere Microsoft-Produkte nutzen, z.B. Access. Natürlich unterscheidet sich ESE sehr stark von anderen Jet-Datenbanken, da sie mit den Jahren hochgradig für Exchange optimiert wurde – ein Vorgang, der mit der Einführung des neuen Schemas in Exchange Server 2010 noch fortgesetzt wird. Mancher fragt sich vielleicht, wieso Microsoft als Plattform für Exchange weiterhin ESE verwendet, wenn doch mit SQL anscheinend eine geradezu perfekte, hochleistungsfähige Datenbank-Engine für Unternehmensanwendungen zur Verfügung steht. Oberflächlich gesehen, mag es eine ansprechende Vorstellung sein, die gesamte Datenbankentwicklung auf einer gemeinsamen Plattform zu vereinheitlichen, die sowohl Microsoft als auch Drittanbieter nutzen können. Bei der Entwicklung, beim Testen und im Support würde dadurch viel Geld gespart, und jeder könnte auf diese eine einzige Plattform über einen einheitlichen Satz von APIs zugreifen. Bei verschiedenen Gelegenheiten hat Microsoft schon den Aufwand dafür bestimmt, Exchange auf SQL zu übertragen, unter anderem während des gescheiterten Kodiak-Projekts, an dem vor Exchange Server 2007 gearbeitet wurde. Abgesehen von dem hohen Entwicklungsaufwand müssten zunächst eine Reihe technischer und sonstiger Fragen gelöst werden, bevor Exchange SQL nutzen könnte. Die Ansprüche an diese beiden Datenbank-Engines unterscheiden sich stark: ESE ist dafür entworfen, Nachrichtentransaktionen zu optimieren, und zwar sowohl einzeilige Nachrichten von einer Person zu einer anderen als auch Nachrichten an einen großen Verteiler mit einem Anhang von mehreren Gigabyte Größe (die beliebteste Kommunikationsform Ihrer Marketingabteilung). SQL dagegen ist darauf zugeschnitten, strukturierte Transaktionen zu handhaben, die gewöhnlich nicht sehr stark voneinander abweichen. Ist es möglich, in einer Datenbank beide Bedingungen zu erfüllen, die Leistungsfähigkeit und Skalierbarkeit zu erhalten? ESE macht es möglich, dass die Benutzer ihre eigenen Indizes (Sichten) im laufenden Betrieb erstellen, indem Sie in Outlook auf einen Spaltenkopf klicken. Daher gibt es eine ungeheure Anzahl von vorübergehenden Sichten, deren Art sich von Datenbank zu Datenbank deutlich unterscheiden kann, doch ESE kann sie alle auf elegante Weise verwalten. SQL dagegen ist nicht so anpassungsfähig. Auch hier gilt, dass SQL zwar die grundlegenden Funktionen bereitstellen könnte – aber auch dieselbe Leistung? SQL ist als Plattform für Anwendungen gedacht. Es gab zwar auch Versuche, Exchange als Plattform für verschiedene Arten von Anwendungen zu nutzen, z.B. für Workflowsysteme, aber jetzt ist Exchange einfach nur ein Nachrichtenserver. Als Stützpfeiler für die Microsoft-Produkte zur Zusammenarbeit dient jetzt nicht mehr Exchange, sondern Microsoft SharePoint (das SQL einsetzt). Wenn Exchange ebenfalls SQL nutzen würde, könnte Microsoft dann SharePoint noch genauso erfolgreich verkaufen wie heute?
373
Der Informationsspeicher von Exchange Server 2010
Lang lebe Jet!
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Sowohl um SQL als auch um Exchange als Plattform ist eine Welt von Drittanbieterprodukten gewachsen, die sehr viel zusätzlichen Nutzen bieten. Die meisten Partner, die heute Produkte für Exchange-Umgebungen anbieten, verwenden für den Zugriff auf den Speicher nicht ESE, sodass ein Wechsel zu SQL für sie kein Problem darstellen sollte. Allerdings kann es einige geben, für die sich dabei tatsächlich Probleme geben. Wahrscheinlich lassen sich diese Schwierigkeiten mit der Zeit lösen, aber sie könnten die allgemeine Annahme einer neuen SQL-gestützten Exchange-Version verzögern. Ganz abgesehen von diesen Argumenten aber stellt sich doch die Frage: Wen interessiert es überhaupt, welche Datenbank-Engine einer Anwendung zugrunde liegt, sofern Sie ihre Aufgabe erfüllt und zuverlässig eine solide, skalierbare Leistung zeigt? Fragt irgendjemand danach, welche Datenbank Google für Gmail verwendet oder Yahoo! für Zimbra? Welche Datenbank-Engine im Hintergrund läuft, sollte daher überhaupt kein Problem darstellen – zumindest, sofern Microsoft bei einem eventuellen Wechsel dafür sorgt, dass es nicht zu Funktionsverlusten kommt.
Maximale Datenbankgröße In Exchange Server 2010 hat Microsoft die empfehlenswerte Höchstgröße für Datenbanken von den 250 GB, die Administratoren in Exchange Server 2007 für das praktikable Maximum hielten, auf 2 TB hochgesetzt. Die Vergrößerung der Datenbankseiten auf 64 KB hat die theoretische Maximalgröße für Datenbanken auf den NTFS-Grenzwert angehoben (16 TB - 64 KB). Zur Sicherheit liegt das absolute Limit für eine Exchange Server 2010-Datenbank knapp unter dem theoretischen NTFS-Grenzwert, nämlich bei 16.000 GB. Im nächsten Jahrzehnt werden nur die wenigsten Kunden Datenbanken betreiben, die auch nur in die Nähe dieses Wertes kommen, vor allem angesichts der Zeit, die erforderlich ist, um eine solche Monsterdatenbank gegebenenfalls wiederherzustellen. Oberflächlich betrachtet, erscheint eine acht- bis zehnfache Vergrößerung der empfohlenen Datenbankgröße von einer Softwareversion zur nächsten erstaunlich, aber dieser große Sprung lässt sich durch drei wichtige technische Verbesserungen rechtfertigen: 쐍 Erstens sind in Exchange Server 2010 keine Sicherungen auf Bändern mehr möglich. Stattdessen müssen Sie mithilfe des Volumeschattenkopiedienstes (Volume ShadowCopy Service, VSS) Sicherungen auf Festplatten anlegen. VSS-Sicherungen erfolgen schneller und können besser mit großen Datenvolumina umgehen. Betrachten Sie als Beispiel einen Server mit zehn 1-GB-Datenbanken. Mit den schnellsten verfügbaren Bändern (heute sind das diejenigen der Klasse LTO-4) können Sie schon von Glück reden, wenn Sie eine vollständige Sicherung in zwölf Stunden schaffen. Einen Snapshot können Sie dagegen sehr viel schneller anlegen, und wenn Sie eine Kopie auf Band benötigen, die Sie außerhalb des Firmengeländes lagern, können Sie das erledigen, nachdem die VSS-Sicherung zur Verfügung steht. Da in Exchange Server 2010 die klassischen Bandsicherungen nicht mehr möglich sind, müssen Sie in der Planungsphase für die Einführung dieser Version bestimmen, wie Sie für VSS-Sicherungen vorsorgen. TIPP VSS ist nicht mehr die schnellste Möglichkeit, um eine Datenbank wiederherzustellen und wieder in der Produktion einzusetzen. Natürlich können Sie eine Datenbank aus einem Snapshot oder einer exakten Sicherungskopie wiederherstellen, aber es geht sehr viel schneller, die Datenbankverfügbarkeitsgruppen von Exchange Server 2010 zu nutzen und eine beschädigte aktive Kopie mithilfe der Hochverfügbarkeitsfunktionen durch eine der passiven Kopien zu ersetzen.
374
쐍 Exchange Server 2010 ermöglicht den Einsatz eines ausgedehnteren Replikationsmodells. Anstelle der einen Kopie, die bei der fortlaufenden Clusterreplikation und der fortlaufenden Standbyreplikation in Exchange Server 2007 möglich waren, können Sie von einer Datenbank jetzt 16 Kopien unterhalten. Zwar werden nur wenige Unternehmen tatsächlich 16 Kopien von einer Datenbank anfertigen (sofern die Geschäftsführung nicht unter Verfolgungswahn leidet), aber es ist doch schön zu wissen, dass man notfalls die Möglichkeit dazu hätte. Bei drei oder vier Kopien einer Datenbank sind Sicherungen nicht mehr so wichtig wie früher, da Sie in der Lage sind, mithilfe einer passiven Kopie eine schnellere und einfachere Wiederherstellung durchzuführen als dadurch, erst nach der aktuellsten Sicherung zu suchen. Das bedeutet jedoch nicht, dass Sie überhaupt keine Sicherungen mehr brauchen, denn gesetzliche Anforderungen und andere Bedingungen können es erforderlich machen, Sicherungskopien für die externe Lagerung anzufertigen. In Kapitel 8, »Exchange auf dem Weg zur Hochverfügbarkeit«, finden Sie eine ausführlichere Darstellung der Datenbankverfügbarkeitsgruppen und der Art und Weise, wie Exchange Server 2010 die Replikation zwischen mehreren Kopien einer Datenbank handhabt. 쐍 Auf der Ebene von ESE hat Microsoft viele Änderungen am Speicher vorgenommen, um die Leistung zu verbessern und um die Notwendigkeit von Verwaltungsvorgängen zu verringern, die sich bei großen Datenbanken oft nicht abschließen ließen. Exchange Server 2007 führt beispielsweise eine Onlinedefragmentierung während eines geplanten Wartungszeitraums durch, die gewöhnlich um Mitternacht beginnt. Je größer eine Datenbank wird, umso schwieriger wird es, alle Seiten darin zu untersuchen, um eine Onlinedefragmentierung durchzuführen. Daher wird in Exchange Server 2010 eine andere Vorgehensweise eingesetzt, um den Zusammenhalt in der Datenbank sicherzustellen. Die Defragmentierung wird jetzt ständig durchgeführt, während neue Seiten in die Datenbank einfließen. Es besteht also kein Grund mehr, diesen Vorgang in ein zeitlich beschränktes Wartungsfenster zu quetschen oder sich Sorgen wegen der Datenbankgröße zu machen. Die CPUZyklen, die zusätzlich erforderlich sind, um die Seiten gleich beim Eingang in die Datenbank zu verarbeiten, werden durch Verbesserungen an anderer Stelle wieder eingespart, vor allem bei Operationen, die früher sehr viele E/A-Vorgänge erforderten, z.B. der Indexerstellung und bei eingeschränkten Sichten. Beachten Sie, dass es nicht mehr Zeit erfordert, eine große Datenbank für die Benutzer bereitzustellen. Die Zeit für die Bereitstellung wird vor allem durch die Anzahl der Transaktionsprotokolle bestimmt, die wiedergegeben werden müssen, um die Datenbank auf den neuesten Stand zu bringen. Größere Datenbanken mögen über mehr Transaktionsprotokolle verfügen, die eingespielt werden müssen, aber unter dem Strich ist dies kaum bemerkbar. Es lassen sich auch noch andere Dinge anführen, z.B. die Korrekturen, die in Outlook 2007 SP2 vorgenommen wurden, um die Leistungsprobleme bei OST- und PST-Dateien mit mehr als 2 GB zu beheben. Ohne diese Verbesserung auf der Seite der Clients wäre es sinnlos, die Verwendung von sehr großen Datenbanken auch nur zu erwägen. Die größten bekannten Exchange-Postfächer, die heute in Produktionsumgebungen verwendet werden, liegen im Bereich von 100 GB und sind eher atypische Beispiele, doch der Einfluss von kostenlosen E-Mail-Systemen für Endverbraucher wie Gmail und Windows Live Mail, in denen Postfächer zwischen 7 und 25 GB angeboten werden, erhöht den Druck auf Exchange-Administratoren, eine ähnliche Kapazität auch für die Verwendung im Unternehmen bereitzustellen. Seit den ursprünglichen 25-MB-Kontingenten von Exchange 4.0 hat sich die Welt ein großes Stück weiterbewegt.
375
Der Informationsspeicher von Exchange Server 2010
Maximale Datenbankgröße
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Grenzwerte für Datenbanken in der Standard Edition Unsere bisherige Darstellung der maximalen Datenbankgrößen ist insofern größtenteils theoretischer Natur, als bei den meisten Bereitstellungen in der Praxis der Betrieb von Datenbanken mit mehr als einigen wenigen hundert Gigabyte gar kein Thema ist. Die Standard Edition von Exchange Server 2010 ist für kleinere Bereitstellungen gedacht, weshalb dort im Anwendungsprotokoll Informationen für Administratoren angezeigt werden, die besagen, dass es zurzeit einen Grenzwert von 1024 GB (1 TB) für Datenbanken gibt und wie groß die Datenbanken zurzeit sind. Beispielsweise können Sie im Anwendungsprotokoll die folgende Information sehen, die als Ereignis 1216 aufgezeichnet wird: Die Größe des Exchange-Informationsspeichers 'DB1' ist auf 1024 GB begrenzt. Die aktuelle physikalische Größe dieser Datenbank (der EDB-Datei) beträgt 173 GB. Wenn die physikalische Größe dieser Datenbank, abzüglich des logischen freien Informationsspeichers, den Grenzwert von 1024 GB überschreitet, wird die Bereitstellung der Datenbank regelmäßig aufgehoben.
Normalerweise müssen Sie sich wegen dieses Hinweises keine Sorgen machen, da Sie wahrscheinlich schon früh genug Maßnahmen ergreifen werden, um das Datenbankwachstum zu begrenzen, bevor die Datei 1 TB erreicht. Es sollte auch genügend Platz dafür vorhanden sein, dass sich die Postfächer innerhalb der Datenbank ausdehnen können, bevor die Einschränkung in Kraft tritt. Es ist jedoch auch möglich, die maximale Dateigröße für Datenbanken auf Computern mit Exchange Server 2010 Standard Edition auf folgende Weise zu erhöhen: 1. Ermitteln Sie den global eindeutigen Bezeichner (Globally Unique Identifier, GUID) für die
Datenbank, deren zulässige Maximalgröße Sie erhöhen möchten. Führen Sie dazu den folgenden Befehl in der Exchange-Verwaltungsshell aus: Get-MailboxDatabase | Format-Table Name, GUID – AutoSize Name ------DB1 DB2
Guid -----3a8b2dad-7f50-4168-9b17-bed403ac0230 f9d1c326-bfd0-41bd-90a5-1ac9ed4383e4
Nehmen wir an, Sie möchten die Maximalgröße von Datenbank DB2 erhöhen. Notieren Sie den zugehörigen GUID. 2. Führen Sie auf dem Postfachserver, auf dem die Datenbank zurzeit bereitgestellt ist, Regedit aus
(den Editor für die Systemregistrierung). 3. Wechseln Sie zu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\
<SERVER NAME>\Private-
376
Postfächer pro Datenbank (oder pro Server) Können wir, da die Datenbanken jetzt größer sind, mehr Postfächer darin unterbringen, und lässt Exchange Server 2010 deshalb mehr Benutzer pro Server zu als Exchange Server 2003 oder 2007? Die bisher übliche Vorgehensweise zur Beantwortung dieser Frage bestand darin, aufgrund des verfügbaren Festplattenplatzes, der E/A-Muster, der Sicherungsverfahren usw. die maximale Größe der Datenbanken zu bestimmen, die Sie unterhalten möchten, und damit wiederum zu berechnen, wie viele Postfächer einer bestimmten Kontingentgröße darin möglich sind. Beispielsweise kann eine Datenbank von 100 GB 200 Postfächer zu je 500 MB umfassen. Anschließend verteilen Sie die Datenbanken je nach verfügbarem Festplattenplatz und E/A-Kapazität auf die Server. Wie wir jedoch bald sehen werden, unterscheidet sich das E/A-Profil von Exchange Server 2010 sehr stark von dem seiner Vorgänger. Um herauszufinden, wie groß die Datenbanken sein müssen, die Sie bereitstellen wollen, können Sie zwar immer noch die Postfachkontingente mit der Anzahl der Benutzer multiplizieren, und in kleineren und mittleren Umgebungen funktioniert das durchaus, doch in den letzten Jahren sind E-MailSysteme immer vielschichtiger geworden, sodass Sie auch noch andere Faktoren berücksichtigen müssen. Um Ihre Situation genauer auszuloten, sollten Sie sich die folgenden Fragen stellen: 쐍 Gibt es irgendwelche gesetzlichen oder sonstigen Vorschriften, die die Aufbewahrung von Postfachdaten für einen bestimmten Zeitraum erfordern? 쐍 Welche Sicherungsverfahren werden im Unternehmen angewandt? Sollen in Exchange Server 2010 Datenbankverfügbarkeitsgruppen eingerichtet werden, um für eine hohe Verfügbarkeit und Datensicherheit zu sorgen? 쐍 Wie gut kommen die Benutzer mit ihren derzeitigen Postfachkontingenten klar? Reicht für die meisten das festgelegte Kontingent aus, oder gibt es häufig Anfragen nach zusätzlichem Informationsspeicherplatz? Wollen Sie, dass die Benutzer Zeit damit verbringen, um ihr Postfach aufzuräumen, damit sie ihr Kontingent nicht überschreiten? 쐍 Welche Richtlinie zur Aufbewahrung gelöschter Elemente ist in Kraft? Reicht sie aus oder muss sie erweitert werden? Wie oft müssen Sie eine Wiederherstellung von einer Sicherung durchführen, um Benutzerdaten zurückzugewinnen? 쐍 Wird die automatische Löschung von Elementen in Postfächern erzwungen? Wenn nein, sollte dies mithilfe einer Aufbewahrungsrichtlinie durchgeführt werden? 쐍 Wird zusammen mit Exchange ein Archivierungsprodukt eingesetzt? Wird dieses Produkt durch die persönlichen Archive, die in Exchange Server 2010 möglich sind, ergänzt oder ersetzt? Sollen die persönlichen Archive in derselben Datenbank gespeichert werden wie die Hauptpostfächer oder in einer anderen? 쐍 Ist es erforderlich, ein Journal zu führen? Wie oft müssen Discoverysuchvorgänge zur Beweissicherung oder zur Reaktion auf Beschwerden durchgeführt werden, bei denen E-Mails als wichtige Belege vorgewiesen werden müssen? 쐍 Hat sich das E-Mail-Verhalten der Benutzer in den letzten Jahren verändert? Senden und empfangen sie jetzt mehr E-Mails? Wie groß sind die Nachrichten im Durchschnitt? Werden Kalender und andere E-Mail-fähige Anwendungen häufiger genutzt? Diese Fragen sprechen verschiedene technische und geschäftliche Erfordernisse an und führen zu einem besseren Verständnis darüber, wie die Benutzer Daten in Postfächern nutzen. Es gibt keine einfache Formel, durch die Sie die Antworten auf diese Fragen in Zahlenwerte für die erforderliche Postfachgröße und die Menge der Datenbanken einer bestimmten Größe umwandeln könnten. Stattdessen wird am Ende eher die Erkenntnis stehen, dass Sie für die unterschiedlichen Kategorien von 377
Der Informationsspeicher von Exchange Server 2010
Maximale Datenbankgröße
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Benutzern auch einen unterschiedlichen Service anbieten müssen. Mitglieder der Geschäftsführung und andere Mitarbeiter, die für ihre Tätigkeiten stark auf E-Mail zurückgreifen müssen, haben sicherlich andere Kontingente, Aufbewahrungszeiten und Archivierungsmöglichkeiten als Fabrikarbeiter, und ihre Postfächer werden sich wahrscheinlich auch in Datenbanken auf den Servern mit der höchsten Verfügbarkeit befinden. Solche Server können sich dadurch auszeichnen, dass sie eine besondere Hardware aufweisen, von eigens dafür abgestelltem Personal verwaltet werden und mehr Zugriffsmöglichkeiten bieten (über mobile Geräte, Outlook und Outlook Web App) als diejenigen für einfache Benutzer. Insidertipp: Annahmen hinter der Kapazitätsplanung
In die Serverplanung müssen auch Faktoren wie die Verfügbarkeit, die Wiederherstellung und geschäftliche Anforderungen einfließen. Programme wie Microsoft Exchange 2010 Mailbox Server Role Requirements Calculator (http://msexchangeteam.com/archive/2010/01/22/453859.aspx) helfen Ihnen dabei, die grundlegenden technischen Voraussetzungen für Exchange Server 2010 zu ermitteln, aber anschließend müssen Sie das Ergebnis noch selbst verfeinern, indem Sie andere Bedürfnisse in die Planung einbeziehen, die sich nicht so einfach in ein Spreadsheet aufnehmen lassen. Alle Hilfsprogramme zur Größenberechnung machen stillschweigend Voraussetzungen über den Standardtyp der Clients, über das Benutzerprofil und den Anteil gleichzeitiger Vorgänge, und die Empfehlungen, die Sie erhalten, eignen sich vor allem für den Fall, dass Ihre Situation diesen Voraussetzungen möglichst nahe kommt. Wenn Ihre Benutzer dagegen ein sehr viel höheres E-Mail-Aufkommen haben, wenn Sie andere Clients verwenden als Outlook und OWA oder wenn sie weniger häufig Verbindung aufnehmen als erwartet (beispielsweise in einer Hostingumgebung mit IMAP4- und POP3-Clients und einem geringen Anteil an gleichzeitigen Benutzerverbindungen), liegen ganz andere Umstände vor, sodass Sie die Ergebnisse eines Berechnungsprogramms erst anpassen müssen, bevor sie sich für Ihre Umgebung eignen.
Ein-/Ausgabe Seit Microsoft im Jahre 1996 das Datenbankschema für Exchange entworfen hat, haben sich Art und Umfang von E-Mails dramatisch geändert. Trotzdem wurde in Exchange Server 2000, 2003 und 2007 immer noch dasselbe Schema genutzt, bei dem das Hauptaugenmerk auf wirtschaftlicher Informationsspeicherung lag und nicht auf Geschwindigkeit. Dank billigerer Informationsspeicherhardware tritt diese Konzentration auf die Informationsspeichereffizienz jetzt jedoch in den Hintergrund. Um eine Verringerung der E/A-Vorgänge zu erreichen, musste dafür gesorgt werden, dass der Informationsspeicher nicht mehr kleine, willkürlich verteilte E/A-Vorgänge zum Abruf von Daten erzwingt, sondern zusammenhängende. Der physische Leistungsunterschied zwischen diesen beiden Möglichkeiten ist so groß, dass Anwendungen, die keine willkürlichen E/A-Vorgänge mehr nutzen, in jedem Fall eine höhere Leistung und geringere E/A-Aktivität zeigen. Um diesen Wechsel zu vollziehen, wurde in Exchange Server 2010 ein neues Schema eingeführt (siehe den Abschnitt »Ein neues Datenbankschema« weiter hinten in diesem Kapitel), das weniger E/A-Vorgänge hervorruft, da es nicht mehr hauptsächlich auf das Einsparen von Speicherplatz achtet, sondern darauf, dass die Daten zusammenhängend abgelegt werden. Dies wird vor allem dadurch erreicht, dass der Inhalt eines Postfachs zusammenbleibt. Da jetzt mehr Daten direkt nebeneinander stehen, kann der Informationsspeicher sie in größeren, zusammenhängenden Blöcken lesen, anstatt viele willkürlich verteilte, kleine Abschnitte abzurufen.
378
Darüber hinaus führt das neue Schema von Exchange Server 2010 dazu, dass das Prinzip der Speicherung in einer einzigen Instanz jetzt nur noch für den Papierkorb von Exchange gilt. Vielleicht haben Sie jetzt den Eindruck, dass die Datenbanken von Exchange Server 2010 auf einen größeren Umfang anwachsen als in früheren Versionen, da die Kopien der Nachrichten in den Postfächern selbst enthalten sind. Aufgrund von anderen Änderungen am Exchange Server 2010-Informationsspeicher, z.B. der Komprimierung von Nachrichteninhalten, ist diese Schlussfolgerung jedoch nicht wahr. Der Verzicht auf die Einzelinstanzspeicherung sorgt jedoch dafür, dass mehr Transaktionsprotokolle erstellt werden, um das Einfügen der Kopien in die Tabellen des einzelnen Postfächer zu erfassen. Wenn Sie beispielsweise eine Nachricht mit einem Anhang von 10 MB an zehn Postfächer in derselben Datenbank senden, muss der Informationsspeicher mindestens zehn Transaktionsprotokolle erstellen. Sichten (oder sekundäre Indizes) sind eine sehr wertvolle Funktion für Benutzer. In Outlook können die Benutzer die Elemente innerhalb der Ordner nach verschiedenen Eigenschaften sortieren (Absender, Empfangsdatum, Betreff usw.). Jedes Mal, wenn ein Benutzer eine andere Sortierreihenfolge festlegt, erstellt der Informationsspeicher eine neue Sicht. Wenn dann neue Elemente in den Informationsspeicher gelangen, ist viel Arbeit erforderlich, um die einzelnen Sichten zu aktualisieren. Wird eine Sicht nicht genutzt, läuft sie schließlich ab und wird aus dem Informationsspeicher entfernt. Große Postfächer haben gewöhnlich viele Sichten, vor allem für die Standardordner (Posteingang, Gesendete Objekte und Gelöschte Objekte). Vielen Menschen ist es zu aufwändig, ihre E-Mails in verschiedenen Ordnern zu sortieren, und sehen einfach zu, wie sich die Nachrichten in den Standardordnern ansammeln. Maßnahmen ergreifen sie erst, wenn ihnen eine Erschöpfung ihres Kontingents droht. Dieses Verhalten führt dazu, dass die Ordner Tausende von Elementen enthalten. In früheren Versionen von Exchange rief der Informationsspeicher viele E/A-Vorgänge hervor, wenn er auf solche großen Ordner zugreifen musste. Daher empfahl Microsoft für Exchange Server 2007, dass Ordner nicht mehr als 5000 Elemente enthalten sollten. Dank der verbesserten OST-Leistung seit Outlook 2007 SP2 und den Verbesserungen am Informationsspeicher von Exchange Server 2010 liegt die neue Empfehlung von Microsoft für die Höchstzahl der Elemente in einem Ordner jetzt bei 20.000. Technisch nicht versierte Benutzer waren sich der Begrenzungen meistens gar nicht bewusst und haben den Posteingang einfach weiterhin als bequeme Ablage für sämtliche Nachrichten verwendet. Die immer weiter verbesserte Suchtechnologie von Outlook hat nach dazu beigetragen, das Problem zu verschärfen, denn die Benutzer wurden nicht mehr für eine schludrige oder völlig fehlende Ordnung bestraft, sondern konnten selbst in einem überquellenden Posteingang immer noch jedes gewünschte Elemente schnell finden. Das ineffiziente Schema und die Art und Weise, wie der Informationsspeicher Sichten erstellte, führten zusammengenommen zu einer Menge von E/A-Vorgängen. Diese Vorgänge fanden an verstreuten Stellen auf dem Datenträger statt, da die Seiten, die den Inhalt eines Postfachs enthielten, gewöhnlich nicht zusammenhängend in der Datenbank gespeichert waren. Dieser Umstand und die Seitengröße von nur 8 KB führten dazu, dass bei jeder Datenanforderung durch einen Client viele kleine E/A-Vergänge erforderlich waren. Um gegen die Konkurrenz bestehen zu können, wollte Microsoft dafür sorgen, dass sich in Exchange Server 2010 auch sehr große Datenbanken noch gut handhaben ließen. Die Verbesserungen an Exchange Server 2007 haben schon ein wenig geholfen, aber jetzt war es an der Zeit für eine Generalüberholung.
379
Der Informationsspeicher von Exchange Server 2010
Ein-/Ausgabe
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Wie ermöglicht Exchange Server 2010 umfangreiche Postfächer?
쐍 Es wird ein neues Schema verwendet, das eigens für den effizienten Umgang mit großen Postfächern entworfen wurde. 쐍 Die Seiten innerhalb des Informationsspeichers werden zusammenhängend angeordnet und nicht mehr überall in der Datenbank verstreut. 쐍 Die Seitengröße wurde von 8 auf 32 KB erhöht, damit der Informationsspeicher die Seiten in großen, zusammenhängenden Blöcken zuweisen kann, anstatt sie willkürlich in der Datenbank zu verteilen. 쐍 Anstelle viele kleiner E/A-Vorgänge an verstreuten Stellen auf der Festplatte werden wenige große, zusammenhängende Vorgänge ausgeführt. Das hat einen leicht einzusehenden Grund: Die heutigen Festplatten sind in der Lage, Daten mit einer Geschwindigkeit von 300 zusammenhängenden E/A-Operationen pro Sekunde bereitzustellen, wohingegen nur 50 E/A-Operationen an verstreuten Stellen pro Sekunde möglich sind. Da zusammenhängende Daten sechsmal schneller zur Verfügung gestellt werden können wie willkürlich verteilte, ist es einleuchtend, dass sich Microsoft bei der Entwicklung darauf konzentriert hat, die Daten im Informationsspeicher zusammenhängend abzulegen. Neben den Leistungsvorteilen ermöglicht dieser Wechsel auch eine breitere Palette von Speicherdesigns für Exchange. 쐍 Die Größe des Caches für den Informationsspeicher wurde für Postfachdatenbanken mit Kopien in Datenbankverfügbarkeitsgruppen von 20 MB auf 100 MB angehoben. Dadurch kann der Informationsspeicher mehr modifizierte Seiten im Arbeitsspeicher behalten. Die Cachegröße (im Grunde genommen die Menge der Protokolldateien ohne Commit) wird auch als Prüfpunkttiefe bezeichnet und legt fest, wie viele Daten im Cache auf den Commit warten können, um in die Datenbank auf der Festplatte geschrieben zu werden. Durch die Vergrößerung der Caches steigt die Wahrscheinlichkeit dafür, dass Exchange eine Seite noch im Arbeitsspeicher aktualisieren kann und nicht erst mit einem E/A-Vorgang von der Festplatte lesen muss. Das Anheben der Cachegröße ist jedoch auch mit Nachteilen verbunden. Beispielsweise ist mehr Zeit zum Herunterfahren erforderlich, da der Cacheinhalt erst auf die Festplatte geschrieben werden muss, und auch eine Wiederherstellung nach einem Absturz dauert länger, da mehr Transaktionen aus den Transaktionsprotokollen wiedergegeben werden müssen. Die Verbesserungen bei der Ein-/Ausgabe wiegen diese Nachteile jedoch wieder auf. 쐍 Für einige Objekttypen im Informationsspeicher wird eine Datenkomprimierung eingeführt. Um die Anzahl kleiner E/A-Vorgänge zu verringern, die im Rahmen normaler Clientvorgänge wie dem Zugriff auf Postfächer zum Senden und Empfangen von Nachrichten erforderlich sind, hat Microsoft den Zusammenhalt der Daten sowohl physisch (ESE) als auch logisch (Informationsspeicher) in drei Bereichen verbessert. Eine Aufstellung dieser Bereiche sehen Sie in Tabelle 7.1. Tabelle 7.1
380
Verbesserungen an der Ein-/Ausgabe in Exchange Server 2010 Bereich
Exchange Server 2007
Exchange Server 2010
Zusammenhalt der Seiten (ESE)
Der Zusammenhalt der Seiten in der Datenbank ist nicht sehr gut, denn die 8-KB-Seiten mit den Nachrichten und Anhängen werden willkürlich über die Datenbank verteilt. Zum Abrufen der Daten sind viele vereinzelte E/A-Vorgänge erforderlich.
Die Datenbank weist einen weit besseren Zusammenhalt auf, da 32-KB-Seiten in zusammenhängenden Bereichen angeordnet werden. Der Informationsspeicher kann die Daten in wenigen, umfassenden E/AVorgängen abrufen, die bis zu 100 Seiten umspannen können.
Ein-/Ausgabe
Verbesserungen an der Ein-/Ausgabe in Exchange Server 2010 (Fortsetzung) Bereich
Exchange Server 2007
Exchange Server 2010
Logischer Zusammenhalt (Informationsspeicher)
Die Nachrichtenheader für die einzelnen Ordner werden jeweils in einer eigenen Tabelle abgelegt. Um die Header abzurufen und den Clients zur Verfügung zu stellen, sind viele vereinzelte E/A-Vorgänge erforderlich.
Alle Header für ein Postfach werden in einem einzigen Ordner festgehalten, sodass der Informationsspeicher sie mit einem einzigen E/A-Vorgang abrufen kann.
Dynamischer Zusammenhalt (Sichten)
Der Informationsspeicher aktualisiert Sichten und Indizes jedes Mal, wenn ein neues Element hereinkommt. Das führt zu einer Menge vereinzelter E/A-Vorgänge, um die Indizes in der Datenbank stets auf dem neuesten Stand zu halten.
Der Informationsspeicher aktualisiert Sichten und Indizes nur dann, wenn der Client auf sie zugreift. Daher werden nur noch wenige umfangreiche E/A-Vorgänge dazu gebraucht.
Wie Sie sehen, wurde zur Verbesserung des Informationsspeichers die grundlegende Art und Weise aufgegeben, in der Exchange seit der ersten Version Datenbankseiten geordnet hat. In einer relativ kleinen Datenbank ist es durchaus vertretbar, neue Elemente auf den Seiten in der Datenbank zu platzieren, die gerade frei sind. Für eine Nachricht von 20 KB heißt das, dass sie auf fünf willkürlich in der Datenbank verstreuten Seiten verteilt werden kann. In der logischen Struktur kann die Datenbank diese fünf Seiten stets wiederfinden und ihre Position an den Informationsspeicher melden, sobald ein Client das betreffende Element anfordert, aber das führt gewöhnlich zu einer Menge vereinzelter E/A-Vorgänge. Die Situation hatte sich ein wenig verbessert, als Microsoft die Seitengröße in Exchange Server 2007 von 4 auf 8 KB angehoben hat, aber die interne Ordnung blieb unverändert. In Exchange Server 2010 sind die Seiten jetzt 32 KB groß, sodass ein Element mit größerer Wahrscheinlichkeit auf eine Seite passt. Noch viel wichtiger aber ist die Tatsache, dass Exchange jetzt darauf achtet, dass die Seiten, in denen ein neues Element gespeichert wird, zusammenhängend in großen Blöcken zugewiesen werden. Wenn Clients auf ein Element zugreifen müssen, wendet der Informationsspeicher eine besondere Technik an (das so genannte Gap Coalescing), um einen Bereich von Seiten in einer einzigen, umfassenden E/A-Operation zu lesen, anstatt überall in der Datenbank den einzelnen Seiten nachzujagen. Damit das möglich ist, schreibt der Informationsspeicher die Seiten natürlich auch in zusammenhängenden Blöcken. Nehmen wir an, in einem zusammenhängenden Bereich von sechs Seiten werden vier im Cache aktualisiert und müssen auf die Festplatte geschrieben werden. Exchange Server 2007 schreibt alle vier modifizierten Seiten in jeweils eigenen E/A-Vorgängen. Exchange Server 2010 dagegen überträgt in einem einzigen umfassenden E/A-Vorgang alle sechs Seiten (die modifizierten und die anderen), wobei ESE die unveränderten Seiten beim Aktualisieren der Datenbank nicht beachtet. Durch diese neue Technik wird der Gesamtbedarf an Ein- und Ausgaben in Exchange verringert und der Datendurchsatz erhöht. Für die Verringerung der Anzahl von E/A-Vorgängen ist es auch von Bedeutung, dass Sichten jetzt nur noch bei Bedarf aktualisiert werden und nicht mehr nach jeder Änderung. Dieser Wechsel führt von dem »scheibchenweisen« früheren Vorgehen, bei dem die Sichten jedes Mal beim Eingang eines neuen Elements aktualisiert wurden und sich der Informationsspeicher daher in einem Zustand ständiger Umgestaltung befand, zu einem Vorgehen »am Stück«, bei dem der Informationsspeicher nur dann eine Sicht aktualisiert, wenn der Client sie verwenden möchte. Nehmen wir an, ein Benutzer erstellt in OWA eine Sicht, um die Elemente in seinem Posteingang nach dem Absender zu ordnen wie vorgegeben nach dem Empfangsdatum. (Outlook-Clients im Onlinemodus erstellen neue Sichten auf die gleiche Weise. Im Exchange-Cache-Modus von Outlook dagegen wird die Sicht auf dem Client angelegt.) Normalerweise erstellt ein Benutzer eine solche Sicht, um nach Elementen zu
381
Der Informationsspeicher von Exchange Server 2010
Tabelle 7.1
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
suchen, die ihm von einer bestimmten Person geschickt wurden. Nun kehrt unser Benutzer aber zu der Standardsicht zurück und verwendet die Sortierung nach dem Absender die ganze folgende Woche nicht mehr. Selbst wenn der Client also keinerlei Anstalten macht, auf diese Sicht zuzugreifen, aktualisiert der Informationsspeicher sie trotzdem nur für den Fall, dass sie doch noch gebraucht wird. Das hat zwar den Vorteil, dass die Sicht dann sofort verfügbar ist, aber dafür muss der Informationsspeicher auch einen horrenden Aufwand betreiben, um alle Sichten auf dem neuesten Stand zu halten, sobald ein neues Element eintrifft. Die dazu erforderlichen Aktualisierungen führen zu einer hohen E/A-Aktivität, da die geänderten Sichten in die Datenbank zurückgeschrieben werden müssen. Der Verzicht auf diese Aktualisierungen und der Wechsel zu einem bedarfsgesteuerten Verfahren war eine sehr kluge Entscheidung, vor allem da die heutigen Server mit mehreren Prozessorkernen gut in der Lage sind, die geringe Zusatzlast für die erforderliche Neuberechnung einer Sicht zu stemmen. In dem Bemühen, die E/A-Leistung zu verbessern, hat sich Microsoft auch darum gekümmert, das Schreiben in der Datenbank reibungsloser zu gestalten. Jede Festplatte weist ihre eigenen Leistungsgrenzen auf, die beschränken, wie viele Daten sie auf einmal verarbeiten kann. Wenn Sie versuchen, zu viele Daten auf einmal auf die Platte zu schreiben, wird sie überfordert, was eine Fehlermeldung über eine Datenträgerauslastung hervorruft. Die Anwendung kann die Daten nicht so schnell schreiben, wie sie möchte, sodass der Vorgang zum Stillstand kommt, bis die Festplatte wieder weitere Daten annehmen kann und die Auslastung beseitigt ist. Um einen reibungslosen Schreibvorgang zu ermöglichen, muss die Anwendung so intelligent sein, dass sie es erkennt, wenn die Festplatte an ihre Leistungsgrenze gerät, und ihre eigenen Anforderungen zurückschraubt, sodass die Festplatte die Daten mit gleichbleibendem Tempo verarbeiten kann. Exchange Server 2010 zieht die Prüfpunkttiefe als ein Maß dafür heran, wann die Schreibvorgänge in der Datenbank gedrosselt werden müssen. Diese Vorgehensweise hat den Vorteil, auf allen Festplatten zu funktionieren. Beträgt die Prüfpunkttiefe das 1,0- bis 1,24-fache des Prüfpunktziels, begrenzt der Informationsspeicher die Anzahl der ausstehenden Schreiboperationen für jede einzelne logische Einheitennummer (Logical Unit Number, LUN) auf eins. Steigt die Prüfpunkttiefe auf mehr als das 1,25-fache des Prüfpunktziels, wird die maximale Anzahl ausstehender Schreiboperationen pro LUN erhöht, um die Drosselung zu verstärken, bis ein Gleichgewicht erreicht ist und sich der Tiefenwert wieder verringert. Die Daten der ausstehenden Schreibvorgänge verbleiben im Cache, bis sie auf die Platte geschrieben werden können. Tabelle 7.2 gibt einen Überblick über die verschiedenen E/A-Merkmale für Exchange Server 2007 und Exchange Server 2010. Die Werte zeigen, welche Auswirkungen der Wechsel von größtenteils wahllos verteilten E/A-Vorgängen zu dem zusammenhängenden Zugriff in größeren Einheiten hat. Tabelle 7.2
E/A-Merkmale von Exchange Server 2007 und 2010 im Vergleich Größe
Exchange Server 2007
Exchange Server 2010
E/A-Typ
Zufällig verteilt
Größtenteils zusammenhängend
Lese/Schreib-Verhältnis
1:1
3:2
Durchschnittliche Größe von Lesevorgängen
12 KB
52 KB
Durchschnittliche Größe von Schreibvorgängen
8 KB
60 KB
Aufgrund der Erfahrungen mit Exchange Server 2007 hat Microsoft am Informationsspeicher von Exchange Server 2010 noch weitere Optimierungen vorgenommen. So wurde die Zusammenführung von Seiten verbessert, Daten werden in größeren Blöcken mitsamt nicht modifizierten Seiten auf die 382
Festplatte geschrieben (bei diesen Seiten erfolgt dann keine Aktualisierung), die Zwischenspeicherung von Seiten ist wirkungsvoller, die Inhaltssuche besser usw. Für einige neue Speicherfunktionen wie die Datenkomprimierung entsteht zwar ein zusätzlicher Aufwand, doch unter dem Strich sollten die Kunden nach Angabe von Microsoft gegenüber Exchange Server 2007 eine Senkung der E/A-Anforderungen um 70% bemerken, wobei schon Exchange Server 2007 eine Verringerung der E/A-Vorgänge um 70% gegenüber Exchange Server 2003 mit sich brachte. Welche Verbesserung Sie tatsächlich spüren, hängt von Ihrer Hardware ab. Je nach Server- und Speicherkonfiguration, Benutzerlast und Art der Clients können Sie dabei bessere oder schlechtere Ergebnisse erzielen. In jedem Fall aber wirken sich die Änderungen, die Microsoft am Informationsspeicher von Exchange Server 2010 vorgenommen hat, positiv aus, da sie im Hinblick auf die heute üblichen großen Postfächer und Inhaltstypen durchgeführt wurden statt für die kleinen Postfächer und Nachrichten, mit denen Exchange Server 4.0 1996 umgehen musste. Insidertipp: Wann sind umfangreiche Postfächer gerechtfertigt?
In vielen Exchange-Umgebungen hatten die Postfachkontingente zu Anfang eine Größe von 50 bis 100 MB und wurden dann nach und nach auf 250 bis 500 MB heraufgesetzt, wobei einigen ausgewählten Postfächern besonders hohe Kontingente zuerkannt wurden, z.B. den Postfächern von Geschäftsführern oder anderen Benutzern, die geschäftliche Gründe für ein höheres E-Mail-Volumen oder die langfristige Aufbewahrung von Daten vorweisen können. Andere Benutzer müssen auf PST-Dateien zurückgreifen, um Nachrichten aufzubewahren, ohne die ihnen zugewiesenen Kontingente zu überschreiten. Microsoft hat Exchange Server 2010 so entworfen, das Sie darin größere Postfächer unterhalten können, was in der Praxis Postfachgrößen von 5 bis 10 GB bedeutet. Ein Kontingent von 5 KB reicht aus, um 100.000 Elemente mit einer durchschnittlichen Größe von 50 KB zu speichern. Die meisten Personen brauchen fünf Jahre, um so viel E-Mail anzusammeln, und außerdem kann es sein, dass die Rechtsabteilung der Firma es nicht so gern sieht, wenn die Benutzer so viele E-Mails hamstern. Bevor wir jetzt Hals über Kopf sämtliche Postfachkontingente auf 5 GB heraufsetzen, sollten wir uns überlegen, ob es überhaupt geschäftliche Anforderungen für derart große Postfächer gibt. In einem Unternehmen können folgende Gründe dafür vorliegen: 쐍 Verringerung der Arbeitszeit, die dadurch verschwendet wird, dass die Benutzer versuchen, ihr Kontingent nicht zu überschreiten. Welche Kosten entstehen, wenn eine dringende Nachricht nicht an ein Postfach ausgeliefert werden kann, nur weil sein Kontingent erschöpft ist? 쐍 Verzicht auf PSTs durch die Bereitstellung von Archivpostfächern. 쐍 Verzicht auf die teure Wiederherstellung gelöschter Elemente aus Sicherungen durch eine ausgedehntere Aufbewahrungszeit für gelöschte Elemente (mehr als 60 Tage). 쐍 Onlinesuchvorgänge in sämtlichen E-Mails des Unternehmens statt in der Teilmenge, die in Onlinepostfächern enthalten ist. 쐍 Schutz aller E-Mails und nicht nur der Elemente in der Exchange-Datenbank. 쐍 Bereitstellung aller Postfachinhalte für mehrere Clients (OWA und mobile Geräte können nicht auf PST-Dateien zugreifen). Erst wenn Sie gute Gründe haben, die die Einrichtung größerer Kontingente rechtfertigen, sollten Sie zu überlegen beginnen, wie Sie die erforderlichen Server und Speichermöglichkeiten für große Postfächer bereitstellen.
383
Der Informationsspeicher von Exchange Server 2010
Ein-/Ausgabe
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Bewahren des Zusammenhangs Microsoft hat dafür Sorge getragen, dass der Speicherplatz in den Datenbanken zusammenhängend zugewiesen wird. Da die Seiten nach ihrer Erstellung jedoch geändert und gelöscht werden können, ist das erst der Anfang. Da die empfohlene Datenbankgröße für Exchange Server 2010 jetzt in Terabyte zählt, kann die herkömmliche Methode, den Zusammenhang der Daten durch geplante Wartungsaktivitäten im Hintergrund sicherzustellen, offensichtlich nicht mehr funktionieren. Tabelle 7.3 zeigt die wichtigsten Änderungen in Exchange Server 2010, die dafür sorgen, dass der Zusammenhalt der Daten innerhalb der Datenbanken unabhängig von ihrer Größe erhalten bleibt. Tabelle 7.3
Änderungen bei der Datenbankwartung im Hintergrund ESE-Funktion
Exchange Server 2007 SP1 (und höher)
Exchange Server 2010
Cleanup
Gelöschte Elemente und Postfächer werden nach dem Ablauf ihrer Aufbewahrungszeit während der HintergrundOnlinewartung aus der Datenbank entfernt.
Gelöschte Elemente und Postfächer werden sofort aus der Datenbank entfernt, nachdem ihre Aufbewahrungszeit abgelaufen ist. Gelöschte Seiten werden standardmäßig mit Nullen überschrieben.
Komprimierung
Von Elementen und Postfächern befreite Seiten werden während der Onlinewartung im Hintergrund zur Wiederverwendung bereitgestellt.
Von Elementen befreite Seiten werden sofort wiederverwendet. Dieser Vorgang wird automatisch gedrosselt, um die Reaktivität der Datenbank nicht zu gefährden.
Zusammenhalt/ Defragmentierung
Bei der Wiederverwendung gelöschter Seiten wird der Datenzusammenhang nicht berücksichtigt. Die Seiten werden nach dem Zufallsprinzip wiederverwendet.
ESE analysiert die Datenbank zur Laufzeit auf den Zusammenhalt der Daten und auf freien Speicherplatz, um sicherzustellen, dass der Zusammenhalt erhalten bleibt. Auch dieser Vorgang wird automatisch gedrosselt.
Prüfsumme
Wenn für Datenbankseiten Prüfsummen eingerichtet sind, werden sie während der Hintergrundwartung kontrolliert.
Die Prüfsummen werden standardmäßig sowohl in der aktiven als auch in der passiven Datenbankkopie ständig im Hintergrund kontrolliert, um mögliche Beschädigungen sofort zu erkennen. Administratoren haben jedoch auch die Wahl, diese Prüfung während der geplanten Hintergrundwartung durchzuführen.
Im Grunde genommen überprüft der Informationsspeicher bei jeder Transaktion, ob der Datenzusammenhalt so weit wie möglich erhalten bleibt und ob der verfügbare Platz effizient genutzt wird. Wenn nötig, wird ein Hintergrundthread erstellt, um ein Problem zu lösen, z.B. um einige Seiten zu vertauschen, sodass sie näher benachbart sind oder um Platz in der Datenbank freizumachen. Alle diese Vorgänge werden automatisch gedrosselt, sodass die Hintergrundtätigkeiten niemals die Reaktion des Informationsspeichers auf Benutzeranforderungen stören. Das geschieht auf die gleiche Weise, wie die Windows-Desktopsuche die Elemente auf der Festplatte eines PCs nur dann indiziert, wenn der Computer gerade inaktiv ist. Aufgrund dieser Vorgänge weisen die Datenbanken in Exchange Server 2010 von Beginn an und während ihres ganzen Bestehens einen größeren Datenzusammenhalt auf als in den Vorgängerversionen. Für diese Laufzeitverarbeitung sind natürlich zusätzliche CPU-Ressourcen erforderlich, aber da der übliche Engpass für Exchange im letzten Jahrzehnt eher die Ein-/Ausgabe war als der Prozessor, dürfte das in den meisten Fällen kein Problem darstellen.
384
Vielleicht ist Ihnen bei der Erläuterung des verbesserten Datenzusammenhalts und der neuen Seitengröße von 32 KB in Exchange Server 2010 der Gedanke gekommen, dass in größeren Blöcken angeordnete größere Seiten die Gesamtgröße einer Datenbank auf der Festplatte erhöhen könnten. Diese Schlussfolgerung ist im Prinzip richtig, doch wird dieser Effekt durch die Einführung der Datenkomprimierung innerhalb der Datenbanken wieder ausgeglichen. Bei Microsoft ist man der Ansicht, dass diese mögliche Vergrößerung der Datenbanken durch die Komprimierung der Nachrichtenheader und des als HTML oder Text vorliegenden Nachrichtenrumpfes vollständig abgepuffert wird. Tests bei Microsoft haben gezeigt, dass eine Datenbank ohne Komprimierung um 20% größer werden kann als ihr Gegenstück in Exchange Server 2007, dass sie aber nach der Komprimierung der Daten wieder die alte Größe aufweist. Das Komprimierungsverhältnis hängt natürlich jeweils davon ab, welche Inhalte sich in einer Datenbank befinden (RTF, Text, HTML, verschiedene Arten von Anhängen). Beispielsweise sind RTF-Nchrichten bereichts komprimiert und können daher beim Schreiben in die Datenbank nicht noch weiter komprimiert werden. Outlook 2010 erstellt standardmäßig Nachrichten im HTML-Format, weshalb Datenbanken für diese Clients mehr von der Komprimierung haben als Datenbanken für ältere Clients wie Outlook 2003, bei denen das standardmäßige Nachrichtenformat vermutlich RTF ist. Die Wirksamkeit der Komprimierung ist in Exchange Server 2010 SP1 noch verbessert worden, indem die Datensätze und Tags zunächst in zusammenhängende Abschnitte auf einer Seite gepackt und erst dann komprimiert werden. Insidertipp: Anhänge werden nicht komprimiert
Die Komprimierung des Nachrichtentextes bringt sehr viel, allerdings versucht Exchange nicht, auch die Anhänge zu komprimieren. Tests, die das Exchange-Entwicklerteam durchgeführt hat, zeigten, dass sich die meisten Arten von Anhängen, die mit Nachrichten mitgesendet werden, z.B. neuere Versionen von Word-Dokumenten und Excel-Arbeitsblättern, nicht gut komprimieren lassen, da sie bereits in komprimierter Form gespeichert sind. Das Gleiche gilt auch für andere Arten von Anhängen, die Sie lieber nicht so gern per E-Mail weiterverbreitet sehen möchten, wie JPEG, PNG, MP3 und WMA. Manche älteren Formate wie das von Word 2003 lassen sich gut komprimieren, aber da diese Versionen immer schneller ersetzt werden, sinkt der Anteil der damit erstellten Anhänge am Gesamtvolumen. Es wurde daher entschieden, auf den zusätzlichen CPU-Aufwand für eine Komprimierung zu verzichten, die wahrscheinlich ohnehin nur eine marginale Verringerung der Speicheranforderungen mit sich bringen würde – und das in einer Zeit, in der die Kosten für Speicher rapide sinken. Mit der gleichen Argumentation wurde auch darauf verzichtet, Nachrichtentexte in RTF zu komprimieren. Um die Auswirkungen dieser Änderungen auf die Praxis zu bewerten, gibt es keine Möglichkeiten, als zwei Datenbanken mit denselben Testdaten zu vergleichen. Sie könnten eine Datenbank von Exchange Server 2003 nehmen und sämtliche Postfächer auf Exchange Server 2010 übertragen, um dann die Auswirkungen zu messen und als Vergleichskriterium zu verwenden. Da sich der Inhalt von E-MailDatenbanken jedoch ständig ändert, ist diese Übung nur von begrenztem Nutzen. Es kann vorkommen, dass Sie an einem Tag das eine Ergebnis bekommen und schon eine Woche später ein völlig anderes. Sicher ist, dass die Unternehmen, die Exchange Server 2010 bereitgestellt haben, noch keine massiven Abweichungen in der Datenbankgröße gemeldet haben. Das ist ein ermutigendes Zeichen. Dass die Komprimierung gerade zum jetzigen Zeitpunkt eingeführt wurde, zeigt, wie umfassend die Kernbestandteile von Exchange Server 2010 überholt wurden.
385
Der Informationsspeicher von Exchange Server 2010
Ein-/Ausgabe
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Ein neues Datenbankschema Das Schema legt fest, wie die Daten in der Datenbank physisch und logisch geordnet werden. Abgesehen von kleineren Verbesserungen hat Microsoft von Exchange Server 4.0 bis Exchange Server 2007 dasselbe Schema verwendet. In Exchange Server 2010 gab es jedoch mehrere schwerwiegende Änderungen am Schema, vor allem an der Art und Weise, wie die Inhalte von Postfächern und Ordnern geordnet werden. Vor Exchange Server 2010 wies eine Postfachdatenbank die folgende Grundstruktur auf: 쐍 Eine Postfachtabelle enthält jeweils einen Zeiger auf jedes Postfach in der Datenbank. 쐍 Eine Ordnertabelle enthält jeweils einen Zeiger auf jeden Ordner in allen Postfächern der Datenbank. 쐍 Eine Nachrichtentabelle enthält jeweils einen Eintrag für jede Nachricht in allen Ordnern der Datenbank. 쐍 Eine Anhangstabelle enthält jeweils einen Eintrag für alle Anhänge in der Datenbank. 쐍 Eine Nachrichten/Ordner-Tabelle, die für jeden Ordner unterhalten wird, führt alle Nachrichten in einem bestimmten Ordner auf. Die Nachrichten/Ordner-Tabelle für Ihren Posteingang enthält z.B. Zeiger auf alle Nachrichten in Ihrem Posteingang. Insgesamt haben Sie also vier große Tabellen, die sich alle Postfächer in der Datenbank teilen, sowie eine Reihe von Nachrichten/Ordner-Tabellen für die verschiedenen Ordner. Dieses Schema, das Sie in Abbildung 7.1 sehen, funktioniert offensichtlich, aber ESE ruft mehr E/A-Vorgänge hervor als nötig, um sich zur Beantwortung von Benutzeranforderungen durch diese Tabellen zu bewegen. Das gilt vor allem, da einige dieser Tabellen in Datenbanken mit Tausenden von Postfächern sehr groß werden können. Eine Datenbank mit 4000 Postfächern, die jeweils 150 Ordner mit 20.000 Elementen aufweisen, braucht beispielsweise eine Ordnertabelle mit 600.000 und eine Nachrichtentabelle mit 80.000.000 Zeilen. Die Nachrichten/Ordner-Tabellen sind das geringere Problem, da die Benutzer mit den Jahren den Ratschlag befolgt haben, die Anzahl der Elemente in einem Ordner unter 5000 zu halten. Abbildg. 7.1
Unterschiede zwischen dem Datenbankschema von Exchange Server 2007 und Exchange Server 2010 Datenbankweite Tabellen Postfach Exchange Server 2007
Kevin Tony Kieran Pierre
Ordner Kevin:Posteingang Tony:Entwürfe Kieran:Info Pierre:Aufgaben
Datenbankweite Tabelle
Exchange Server 2010
386
Ordnerweite Tabellen
Nachrichten
Anhänge
Nachrichten/Ordner
Kevin:M1 Kevin:M263 Kevin:M72 Tony:M62
Kevin:ZYX.DOC Kevin:JBOD.XLS Tony:Costs.PPT Pierre:Test.htm
Kevin:Posteingang:1 Kevin:Posteingang:4 Kevin:Posteingang:15 Kevin:Posteingang:77
Postfachweite Tabellen
Postfach
Ordner
Kevin Tony Kieran Pierre
Posteingang Entwürfe Postausgang Gesendete Objekte
Header MsgHeader1 MsgHeader2 MsgHeader3 MsgHeader4
Sichttabellen (eine pro Sicht) Rümpfe MsgBody1 MsgBody2 MsgBody3 MsgBody4
Kevin/Posteingang/Empfangen Msg1 Msg1774 Msg18484 Msg891
Datenbankverwaltung
쐍 Eine Postfachtabelle enthält jeweils einen Zeiger auf jedes Postfach in der Datenbank (wie zuvor). 쐍 Für jedes Postfach in der Datenbank gibt es eine Ordnertabelle. Das bedeutet zwar, dass insgesamt mehr Ordnertabellen vorhanden sind, doch ihre jeweilige Größe ist viel geringer. Bei dem zuvor angeführten Beispiel gibt es jetzt 4000 Ordnertabellen (eine für jedes Postfach) mit jeweils 150 Zeilen. 쐍 Für jedes Postfach in der Datenbank gibt es eine Headertabelle, die alle MAPI-Eigenschaften der Nachrichten im Postfach enthält (Betreff, Adressliste, Prioritätseinstellung usw.). Auch hier haben wir wiederum 4000 Headertabellen, aber die Größe dieser Tabellen wird durch die Anzahl der Elemente in den Postfächern bestimmt. In unserem Beispiel sind das etwa 20.000 Zeilen. 쐍 Eine Nachrichtenrumpftabelle für jedes Postfach in der Datenbank, die den Inhalt der Nachricht (Text) sowie die Anhänge enthält. Wiederum ergeben sich in unserem Beispiel 4000 Tabellen dieser Art, deren Größe durch die Anzahl der Elemente im Postfach bestimmt wird. 쐍 Außerdem unterhält ESE nach Bedarf Sichttabellen. Eine Sicht ist eine bestimmte Sortierung eines Ordners (beispielsweise die Sortierung des Posteingangs nach dem Empfangsdatum). In den früheren Versionen von Exchange wurden zum Füllen von Sichten sekundäre Indizes verwendet, doch in Exchange Server 2010 werden Sichten in Form von Tabellen umgesetzt. Es kann zwar viele Sichten geben (mehr als Ordner, da die Benutzer mehrere Sichten pro Ordner erstellen können), doch die Größe der Sichttabellen wird durch die Anzahl der Elemente im jeweiligen Ordner bestimmt. Zusammenfassend gesagt hat beim Speicherschema für die Datenbanken von Exchange Server 2010 ein Wechsel von Tabellen mit Daten für die gesamte Datenbank zu Tabellen für die einzelnen Postfächer stattgefunden. Dadurch kann sich ESE rationell durch die Datenbank bewegen und muss weniger E/A-Transaktionen hervorrufen. Außerdem kann Exchange Server 2010 dadurch selbst bei bis zu 100.000 Elementen pro Ordner noch ausreichend schnell auf Anforderungen von Onlineclients reagieren. Die Leistung für Clients im Exchange-Cache-Modus hängt jedoch von anderen Faktoren ab, z.B. der Geschwindigkeit der lokalen Festplatte und der Clientversion (Outlook 2007 SP2 oder höher ist am besten). Ein Nachteil besteht jedoch darin, dass es keinerlei Möglichkeiten zur Einzelinstanzspeicherung mehr gibt, da der Schwerpunkt jetzt auf Tabellen für einzelne Postfächer statt für eine gesamte Datenbank liegt. Angesichts der geringen Kosten und leichteren Verfügbarkeit von Speicherplatz hat die Einzelinstanzspeicherung jedoch an Bedeutung verloren, sodass ihr Verlust keinen Grund zur Trauer darstellt.
Datenbankverwaltung Die Datenbankverwaltung umfasst viele verschiedene Bereiche. Wir sehen uns zu Anfang die grundlegenden Dateien an, die eine Exchange-Postfachdatenbank bilden (siehe Abbildung 7.2), und gehen dann zu den Einzelheiten der Funktionsweise von Transaktionsprotokollen und anderen Dateien. In dem Verzeichnis für eine Exchange-Datenbank finden Sie vor allem die folgenden wichtigen Dateien: 쐍 Die Datenbankdatei, im Beispiel Vip.edb. Alle Tabellen und Daten, die erforderlich sind, um den Clients die Inhalte bereitzustellen, sind in der Datenbankdatei enthalten. 쐍 Das aktuelle Transaktionsprotokoll, im Beispiel E02.log. Dies ist die Protokolldatei, in die der Informationsspeicher zurzeit Transaktionsdaten schreibt. 387
Der Informationsspeicher von Exchange Server 2010
Wie Abbildung 7.1 zeigt, weist das Schema von Exchange Server 2010 folgendes Layout auf:
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
쐍 Vorherige Transaktionsprotokolle. Dies sind die restlichen Transaktionsprotokolle, die zuvor erfasste Transaktionen enthalten. Der Informationsspeicher löscht diese Protokolldateien entweder in regelmäßigen Abständen (wenn die Umlaufprotokollierung aktiviert ist) oder nach einer erfolgreichen vollständigen Sicherung. Die Gesamtmenge der Transaktionsprotokolle bildet die Grundlage für die Replikation der Daten auf andere Server, durch die die Datenbankkopien in einer Datenbankverfügbarkeitsgruppe auf dem neuesten Stand gehalten werden. In Abbildung 7.2 reicht der Satz der Transaktionsprotokolle von E0200002C6 bis E0200002C7 (Generation 710 bis 711, was anzeigt, dass das aktuelle Protokoll die Generation 712 ist). 쐍 Prüfpunktdatei, im Beispiel E02.chk. In der Prüfpunktdatei wird festgehalten, wie weit der Informationsspeicher dabei gekommen ist, protokollierte (also im Transaktionsprotokoll festgehaltene) Transaktionen in die Datenbank zu schreiben. 쐍 Reservierte Protokolle, im Beispiel E02res00001.jrs. Exchange verwendet diese Dateien, um Datenbanken zusätzlichen Platz zum Übertragen von Transaktionen aus dem Cache zu bieten, falls dies notwendig werden sollte. In SP1 wurde die Anzahl der JRS-Dateien auf zehn pro Datenbank erhöht. 쐍 Möglicherweise sind einige Daten über aktive Datenbanktransaktionen in Tmp.edb gespeichert. Diese Datei ist gewöhnlich nur wenige Megabyte groß und wird gelöscht, wenn die Bereitstellung der Datenbank aufgehoben oder der Informationsspeicherdienst beendet wird. Die Transaktionen dieser Datenbank protokolliert der Informationsspeicher in Exxtmp.log (im Beispiel E02tmp.log). Abbildg. 7.2
388
Die Dateien einer Postfachdatenbank
Da Datenbanken nicht mehr unmittelbar mit bestimmten Servern verknüpft sind (abgesehen davon, dass sie darauf betrieben werden), erfolgt die Datenbankverwaltung in Exchange Server 2010 auf der Ebene der Organisation. Abbildung 7.3 zeigt eine typische Ansicht der Exchange-Verwaltungskonsole für eine kleine Organisation. Zu sehen ist die Registerkarte Datenverwaltung. Im oberen Bereich werden die einzelnen Datenbanken aufgeführt, im unteren die Datenbankkopien. Das Vorhandensein mehrerer Kopien zeigt an, dass einige der Datenbanken zu einer Datenbankverfügbarkeitsgruppe gehören. Abbildg. 7.3
Die Registerkarte Datenbankverwaltung in der Exchange-Verwaltungskonsole
Administratoren in großen Organisationen mit Hunderten oder gar Tausenden von Datenbanken auf Servern in aller Welt können die Reaktionsgeschwindigkeit der Konsole erhöhen, indem Sie einen Filter einsetzen, sodass nur die Datenbanken angezeigt werden, um die sie sich zu kümmern haben. Klicken Sie dazu auf Filter erstellen und wählen Sie den Filter aus, den Sie verwenden möchten. Häufig wird nach Datenbanken auf einem bestimmten Server oder in einer bestimmten Datenbankverfügbarkeitsgruppe gefiltert. Sie können jedoch auch mehrere Bedingungen kombinieren, um Ihre eigenen besonderen Filterkriterien zusammenzustellen. Wenn Sie den gewünschten Filter ausgewählt haben, klicken Sie auf Filter anwenden, damit die Verwaltungskonsole die Datenbanken abruft, die Ihren Kriterien genügen. Abbildung 7.4 zeigt einen Filter, der die Datenbanken einer bestimmten Verfügbarkeitsgruppe auswählt.
389
Der Informationsspeicher von Exchange Server 2010
Datenbankverwaltung
Kapitel 7 Abbildg. 7.4
Der Informationsspeicher von Exchange Server 2010
Verwenden eines Filters zur Suche nach Datenbanken
Erstellen neuer Postfachdatenbanken Neue Datenbanken erstellen Sie im Knoten Organisationskonfiguration der Exchange-Verwaltungskonsole. Eine neue Postfachdatenbank sollten Sie immer auf dem Server erstellen, auf dem Sie ursprünglich ausgeführt werden soll, denn dadurch vermeiden Sie mögliche Fehler aufgrund von Netzwerkproblemen. Markieren Sie den Knoten Postfach unter Organisationskonfiguration und klicken Sie im Aktionsbereich auf Neue Postfachdatenbank, um den Assistenten für neue Postfachdatenbanken zu starten. In Abbildung 7.5 sehen Sie die erste Seite des Assistenten, auf der Sie einen Namen für die neue Datenbank angeben und den Server auswählen, auf dem Exchange sie ursprünglich bereitstellen soll. Der nächste Schritt besteht darin, die Speicherorte für die Datenbank- und die Transaktionsprotokolldateien auszuwählen (siehe Abbildung 7.6). Beide Speicherorte müssen sich auf Festplatten befinden, deren Laufwerksbuchstabe sich nicht ändert. Wenn Sie in der Verwaltungskonsole eine neue Postfachdatenbank erstellen, liest Exchange den Wert der Eigenschaft DataPath des Servers, auf dem die Datenbank bereitgestellt werden soll, um den Standardspeicherort für Datenbanken zu ermitteln. Diesen Wert können Sie auch mit folgendem Befehl herausfinden: Get-ExchangeServer -Identity 'ExServer1' | Select Name, DataPath Name ------ExServer1
390
DataPath -------C:\Program Files\Microsoft\ExchangeServer\V14\Mailbox
Datenbankverwaltung
Angabe von Name und Server für eine neue Postfachdatenbank
Abbildg. 7.6
Auswählen des Dateispeicherorts für eine neue Postfachdatenbank
Der Informationsspeicher von Exchange Server 2010
Abbildg. 7.5
391
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Für Testserver ist es bequem, neue Datenbanken und die zugehörigen Transaktionsprotokolle alle in einem gemeinsamen Speicherort unter dem Stammverzeichnis von Exchange abzulegen, aber für die Produktion ist diese Vorgehensweise nicht zu empfehlen. Am besten ist es, alle Datenbanken voneinander zu trennen und jeweils in ihrem eigenen Verzeichnis unterzubringen. Außerdem sollte sich das Verzeichnis zur Speicherung der Postfachdatenbanken außerhalb des Pfades C:\Program Files\Microsoft\Exchange Server befinden, da dort ausschließlich die Binärdateien des Programms und zugehörige Dateien stellen sollten. HINWEIS Die Eigenschaft DataPath eines Servers können Sie in der Exchanger-Verwaltungsshell nicht ändern, da Ihnen das Cmdlet Set-ExchangeServer keinen Zugriff darauf gewährt. Es ist jedoch möglich, im ADSI-Editor einen anderen Standardpfad anzugeben, indem Sie das Attribut MsExchDataPath für das Objekt des Exchange Server-Computers ändern. Dieses Vorgehen hat keinerlei Nebenwirkungen, aber wenn Sie sich dazu entschließen, sollten Sie auf allen Postfachservern die gleiche Änderung vornehmen. In dem Beispiel, das Sie in Abbildung 7.6 sehen, werden die Transaktionsprotokolle auf demselben Laufwerk platziert wie die Datenbank. In früheren Versionen von Exchange hätten Sie das höchstens bei einem Testsystem so gemacht, da sich ein Hardwarefehler, der die Datenbank beschädigt, dann auch auf die Transaktionsprotokolle auswirken kann, sodass Sie möglicherweise nicht mehr die Gelegenheit haben, die Daten wiederherzustellen. Auch in Exchange Server 2010 müssen Sie den Inhalt der Datenbanken gegen Verluste schützen, weshalb Sie Datenbanken und Transaktionsprotokolle auf unterschiedlichen physischen Laufwerken – nach Möglichkeit mit unterschiedlichen Controllern – unterbringen. Eine Ausnahme besteht, wenn die Datenbank zu einer Datenbankverfügbarkeitsgruppe gehört und bereits durch die Replikation geschützt ist, doch auch in diesem Fall müssen Sie die betrieblichen Umstände berücksichtigen, bevor Sie endgültig den Speicherort für die Transaktionsprotokolle festlegen. Wenn Sie beispielsweise häufig Postfächer von einer Datenbank in eine andere verschieden müssen, sollten Sie die Transaktionsprotokolle auf einem eigenen Laufwerk unterbringen, damit ausreichend Platz für die Protokolle ist, die Exchange bei dem Verschiebevorgang erstellt. Wenn Sie eine neue Postfachdatenbank angelegt haben, müssen Sie sie bereitstellen, bevor Sie sie verwenden können. In dem Dialogfeld aus Abbildung 7.6 ist das Kontrollkästchen Diese Datenbank bereitstellen aktiviert, sodass die Exchange-Verwaltungskonsole den Befehl Mount-Database ausführt, nachdem sie die neue Datenbank erstellt hat. Nach meinen Erfahrungen vor allem mit der RTM-, aber auch mit der SP1-Version von Exchange Server 2010 führt der Versuch, die neue Datenbank unmittelbar bereitstellen zu lassen, häufig zu dem folgenden Fehler: Die angegebene Datenbank konnte nicht eingebunden werden. Angegebene Datenbank: Mailbox Database 03; Fehlercode: Fehler bei Active Manager-Vorgang: Fehler bei der Datenbankaktion: Fehler bei Vorgang mit folgender Meldung: MapiExceptionNotFound: Die Datenbank konnte nicht eingebunden werden.
Die meisten Administratoren möchten die Aufgabe abschließen und mit der neuen Datenbank arbeiten können, weshalb Sie 30 Sekunden warten und sie dann bereitstellen. In SP1 wurde dieses Problem gemildert. Dort lassen sich neue Datenbanken gewöhnlich ohne Schwierigkeiten unmittelbar nach dem Erstellen bereitstellen. Das folgende Beispiel zeigt typischen Code, mit dem Sie in der Exchange-Verwaltungsshell eine neue Postfachdatenbank bereitstellen können: New-MailboxDatabase -Server 'ExServer1' -Name 'Sales' -EdbFilePath 'e:\E2010\Sales.edb' -LogFolderPath 'e:\E2010'
392
VORSICHT Der Fehler tritt vor allem dann auf, wenn der Server stark in Anspruch genommen wird (also nicht so häufig bei einem gewöhnlich nur leicht belasteten Testserver). Kurz besagt, bedeutet diese Fehlermeldung, dass Sie kurz innehalten müssen, bevor Sie mit dem Bereitstellen der Datenbank fortfahren können, damit Exchange die Zeit hat, sich selbst über die Verfügbarkeit der neuen Datenbank auf den neuesten Stand zu bringen. Um die Datenbank bereitzustellen, können Sie ca. 30 Sekunden warten (wie viel Wartezeit genau erforderlich ist, hängt von der jeweiligen Organisation ab) und dann versuchen, den Vorgang in der Exchange-Verwaltungskonsole oder -Verwaltungsshell abzuschließen. Es ist aber auch möglich, die Datenbank in dem nicht bereitgestellten Zustand zu belassen. In diesem Fall versucht Active Manager automatisch, sie nach Ablauf seines Wiederholungszeitraums (vier Minuten) bereitzustellen. In Kapitel 8, in dem es vor allem um die Funktionsweise der Datenbankverfügbarkeitsgruppen von Exchange Server 2010 geht, sehen wir uns auch Active Manager genauer an. Nachdem die Datenbank erfolgreich angelegt worden ist, können wir sie bereitstellen, sodass sie zur Aufnahme neuer Postfächer bereit ist: Mount-Database –Identity 'Sales'
Exchange weist einer neuen Datenbank kein Offlineadressbuch zu. Normalerweise ist das kein Problem, da Exchange das standardmäßige Offlineadressbuch verwendet, wenn kein anderes angegeben ist. Wenn Sie jedoch für die einzelnen Unternehmensbereiche (oder für sonstige Unterteilungen) jeweils eigene Offlineadressbücher erstellt haben, können Sie für jeden Bereich eine Postfachdatenbank erstellen und ihr das entsprechende Offlineadressbuch zuweisen. Welches Offlineadressbuch einer Datenbank zurzeit zugewiesen ist, können Sie herausfinden, indem Sie die Datenbank markieren, das Eigenschaftendialogfeld dafür aufrufen und dort auf die Registerkarte Clienteinstellungen wechseln, die Sie in Abbildung 7.7 sehen. Ist das Feld Offlineadressbuch leer, so verwendet Exchange das Standardadressbuch. Soll das nicht geschehen, klicken Sie auf Durchsuchen und wählen Sie das gewünschte Adressbuch aus. Abbildg. 7.7
Zuweisen eines Offlineadressbuchs zu einer neuen Postfachdatenbank
393
Der Informationsspeicher von Exchange Server 2010
Datenbankverwaltung
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Mit dem folgenden Befehl können Sie nach Postfachdatenbanken suchen, denen kein Offlineadressbuch zugewiesen ist. Die Datenbanken, bei denen für die Eigenschaft OfflineAddressBook ein leerer Wert zurückgegeben wird, müssen Sie aktualisieren. Get-MailboxDatabase | Select Name, OfflineAddressBook
Um alle Datenbanken, denen kein Offlineadressbuch zugewiesen ist, so zu ändern, dass sie das standardmäßige Offlineadressbuch verwenden, können Sie folgenden Befehl einsetzen: Get-Ma ilboxDatabase | Where {$_.OfflineAddressBook –eq $Null} | Set-MailboxDatabase –OfflineAddressBook '\Default Offline Address Book'
Neue Postfachdatenbanken sind unmittelbar als Zieldatenbanken für die automatische Postfachbereitstellung verfügbar. Das heißt, dass mit dem Assistenten der Exchange-Verwaltungskonsole sofort neue Postfächer darin angelegt werden können. Möglicherweise ist das jedoch gar nicht in Ihrem Sinne, vor allem wenn Sie eine neue Datenbank mit besonderen Eigenschaften erstellt haben, die eigens auf die besonderen Bedürfnisse bestimmter Benutzer zugeschnitten ist und die Sie dafür für diese Benutzer reservieren möchten. In diesem Fall können Sie die neue Datenbank von der automatischen Postfachbereitstellung ausnehmen. Wie Sie das machen, erfahren Sie in Kapitel 6, »Verwalten von E-Mail-aktivierten Empfängern«. Schließlich müssen Sie sich auch noch fragen, ob Drittanbieterprodukte Berechtigungen für den Zugriff auf die neue Postfachdatenbank benötigen. Für BlackBerry Enterprise Server von Motion müssen Sie beispielsweise die Berechtigung für den Zugriff auf die Postfächer erteilen, damit das Produkt die Postfächer mit Nachrichten für Mobilgeräte von BlackBerry aktualisieren kann. Dies alles zeigt, dass Sie zum Erstellen neuer Postfachdatenbanken Ihre eigene Checkliste aufstellen sollten, damit Sie auch alle erforderlichen Schritte durchführen, um sie für die Produktion bereitzustellen.
Aktualisieren von Postfachdatenbanken nach der Installation Wenn Sie einen Postfachserver mit Exchange Server 2010 installieren, erstellt das Setupprogramm eine Standardpostfachdatenbank und platziert sie sowie die zugehörigen Transaktionsprotokolle und den Suchkatalog in einem Verzeichnis unterhalb des Exchange-Installationsverzeichnisses. Die Datenbank erhält einen eindeutigen Namen, damit es nicht zu Konflikten mit anderen Postfachdatenbanken in der Organisation kommt, sodass sich insgesamt ein Pfad wie der folgende ergibt: C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 2136564033\Mailbox Database 2136564033.edb
Speicherort und Name der Datenbank sind für einen Produktionsserver jedoch nicht gerade ideal. Nachdem der Server vollständig eingerichtet ist und läuft, sollten Sie daher die folgenden Aufgaben durchführen, die auch für Datenbanken öffentlicher Ordner wichtig sind: 1. Benennen Sie die Datenbank um, sodass Sie der Namenskonvention Ihrer Organisation für
Datenbanken folgt. Der Name muss weiterhin eindeutig sein. Nachdem Sie sich für einen Namen entschieden haben, sollten Sie sich daher noch vergewissern, dass er nicht schon an anderer Stelle in der Organisation verwendet wird.
394
Datenbankverwaltung
kollierung deaktiviert. Wenn Sie die Umlaufprotokollierung einsetzen möchten, was vor allem dann der Fall sein mag, wenn die Datenbank innerhalb einer Datenbankverfügbarkeitsgruppe eingesetzt wird, müssen Sie sie also noch aktivieren. Nähere Informationen über die Umlaufprotokollierungen finden Sie im Abschnitt »Umlaufprotokollierung – ja oder nein?« weiter hinten in diesem Kapitel. 3. Verschieben Sie die Datenbank- und die Transaktionsprotokolldateien an einen geeigneten Ort. Sie sollten sich besser nicht auf der Festplatte befinden, auf der die Binärdateien von Exchange und andere Systemdateien installiert sind. 4. Weisen Sie der Datenbank ggf. ein Offlineadressbuch zu. Eine Datenbank umzubenennen, geht ganz einfach. Markieren Sie sie, rufen Sie ihre Eigenschaften auf und geben Sie wie in Abbildung 7.8 gezeigt den neuen Namen ein. Alternativ können Sie dazu auch das Cmdlet Set-MailboxDatabase verwenden: Set-MailboxDatabase -Identity 'Mailbox Database 2136564033'-Name 'DB2' Abbildg. 7.8
Ändern des Datenbanknamens
Die Umlaufprotokollierung können Sie auf der Registerkarte Grenzwerte des Eigenschaftendialogfelds für die Datenbank aktivieren (und wieder deaktivieren). Auch diese Eigenschaft lässt sich in der Exchange-Verwaltungsshell ändern. Damit der Informationsspeicher die Umlaufprotokollierung durchführt, muss die Bereitstellung der Datenbank aufgehoben und dann wiederhergestellt werden, weshalb Sie an der Befehlszeile die entsprechenden Befehle hinzufügen müssen: Set-MailboxDatabase –Identity 'DB4' –CircularLoggingEnabled $True Dismount-Database –Identity 'DB4' -Confirm:$False Mount-Database –Identity 'DB4'
395
Der Informationsspeicher von Exchange Server 2010
2. Bei neu erstellten Datenbanken für Postfächer und für öffentliche Ordner ist die Umlaufproto-
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Um eine Datenbank an einen geeigneteren Speicherort zu verschieben, klicken Sie mit der rechten Maustaste darauf und wählen Datenbankpfad verschieben. Daraufhin zeigt die Exchange-Verwaltungskonsole den entsprechenden Assistenten an, den Sie in Abbildung 7.9 sehen. HINWEIS Diese Operation sollten Sie nur von dem Server aus versuchen, auf dem die Datenbank zurzeit bereitgestellt ist. Wenn Sie die Verschiebung von einem Remotecomputer aus versuchen, gibt Ihnen die Verwaltungskonsole nicht die Möglichkeit, neue Verzeichnisse für die Datenbank und die Transaktionsprotokolle anzugeben. Abbildg. 7.9
Verschieben einer Postfachdatenbank an einen neuen Speicherort
Um den Verschiebevorgang durchzuführen, geben Sie einfach die neuen Speicherorte für die Datenbank und die Transaktionsprotokolle an (sie müssen sich nicht auf derselben Festplatte befinden) und klicken auf Verschieben. Die Exchange-Verwaltungskonsole teilt Ihnen mit, dass die Bereitstellung der Datenbank vorübergehend aufgehoben werden muss, bevor sie verschoben werden kann. Klicken Sie auf OK, um zu bestätigen, dass Sie den Verschiebevorgang durchführen lassen möchten. Daraufhin verschiebt Exchange alle Datenbankdateien an den neuen Speicherort und stellt die Datenbank dann erneut bereit, damit die Benutzer wieder darauf zugreifen können. Sie können Datenbanken auch mit dem Cmdlet Move-DatabasePath verschieben: Move-DatabasePath -Identity 'DB4' -EdbFilePath 'E:\Exchange\DB4\DB4.edb' -LogFolderPath 'E:\Exchange\DB4'
Es ist schwieriger, Datenbanken zu verschieben, die sich in einer Datenbankverfügbarkeitsgruppe befinden, da es mehrere Kopien geben kann, die auf allen Servern in einem gleichlautenden Speicherort platziert sein müssen. In Kapitel 8 erfahren Sie mehr über dieses Thema.
396
Wartungsaufgaben im Hintergrund Alle Datenbanken weisen interne Strukturen auf, die einen gewissen Grad an Wartung erfordern, um die logische Konsistenz zu erhalten, und Exchange bildet da keine Ausnahme. Dazu könnten Sie die Datenbank offline schalten und mit ESEUTIL neu erstellen oder ihre internen Strukturen mit ISINTEG überprüfen (Letzteres gilt für ältere Versionen von Exchange – siehe den Abschnitt »Schutz gegen übermäßiges Datenbank- und Protokollwachstum« weiter hinten in diesem Kapitel), doch dadurch würden Sie die Benutzer am Zugriff auf die Datenbank hindern. Microsoft hat Exchange für hohe Verfügbarkeit mit so geringen Ausfallzeiten wie möglich entworfen. Um die Datenbank zu optimieren und gleichzeitig den Benutzern zu erlauben, weiterhin mit ihr zu arbeiten, ist eine Onlinewartung erforderlich. In Exchange Server 2010 führt der Informationsspeicher jede Nacht elf Wartungsaufgaben durch, die in Tabelle 7.4 aufgeführt sind. Tabelle 7.4
Wartungsaufgaben im Hintergrund Aufgabe
Postfachspeicher
Speicher für öffentliche Ordner
Indizes leeren
Ja
Ja
Tombstone-Wartung durchführen
Ja
Ja
Cache für gelöschte Objekte leeren
Ja
Ja
Veraltete Inhalte öffentlicher Ordner als abgelaufen kennzeichnen
Nein
Ja
Öffentliche Ordner entfernen, die die TombstoneLebensdauer überschritten haben
Nein
Ja
Konflikte zwischen öffentlichen Ordnern lösen
Nein
Ja
Serverversionen aktualisieren
Nein
Ja
Zuverlässige Ereignistabellen bereinigen
Ja
Nein
Gelöschte Postfächer entfernen
Ja
Nein
Nach verwaisten Nachrichten suchen
Ja
Ja
Frei/Gebucht- und Offlineadressbuchordner prüfen
Nein
Ja
Der Schwerpunkt der Onlinewartung liegt auf den Inhalten, d.h., die durchgeführten Aufgaben sollen unerwünschte Inhalte aus der Datenbank entfernen oder dafür sorgen, dass die Inhalte so genau wie möglich sind. Diese Inhaltswartung dauert auch auf den größten Servern gewöhnlich weniger als eine Stunde. In früheren Versionen von Exchange wurde im Rahmen der nächtlichen Hintergrundwartung auch eine ESE-Wartung durchgeführt, um dafür zu sorgen, dass die physische Struktur der Datenbank so effizient wie möglich ist. Die ESE-Wartung ist weit E/A-intensiver als die Inhaltswartung und kann mehrere Stunden verschlingen. Dabei werden folgende Aufgaben erledigt: 쐍 Onlinedefragmentierung 쐍 Kontrolle der Seitenprüfsummen Bei der Onlinedefragmentierung werden die Seiten in der Datenbank so umgeordnet, dass sich die wirtschaftlichste Struktur ergibt. Da die Größe von Exchange-Datenbanken immer weiter anwuchs, war irgendwann der Punkt erreicht, an dem es kaum noch möglich war, die Onlinedefragmentierung innerhalb der vorgesehenen Zeit zu erledigen. Exchange Server 2010 führt die Onlinedefragmentierung daher ständig durch und nicht mehr im Rahmen der nächtlichen Wartungsarbeiten. Dieses Verhalten können Sie nicht ändern, da der Informationsspeicher genau so entworfen wurde. Im Systemmonitor können Sie die Defragmentierungsarbeiten nachverfolgen, indem Sie den Leistungsindikator MsExchange-Datenbank/Defragmentierungsasks beobachten. 397
Der Informationsspeicher von Exchange Server 2010
Datenbankverwaltung
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Auf der Registerkarte Wartung des Eigenschaftendialogfelds für eine Postfachdatenbank (siehe Abbildung 7.10) sehen Sie auch einen Hinweis auf »24 x 7 ESE-Scannen«. Das hat jedoch nichts mit der Onlinedefragmentierung zu tun, sondern steuert die Validierung der Prüfsummen durch den Informationsspeicher. Die Seitenprüfsummen sind ein Indiz dafür, ob die Inhalte einer Seite gültig sind. Um Beschädigungen zu erkennen, liest die ESE-Scanfunktion die Seiten einer Datenbank von der ersten bis zur letzten und erstellt Prüfsummen. Alle Einzelbitfehler, die der Informationsspeicher dabei auf den Seiten entdeckt, werden noch während des Scanvorgangs korrigiert. Außerdem erstellt Exchange beim Zugriff auf die Seiten einer Datenbank eine Prüfsumme, aber da nicht garantiert ist, dass im Laufe der Zeit auf sämtliche Seiten zugegriffen wird, wurde diese Neuerung eingeführt, damit auch wirklich jede Seite verarbeitet wird und damit mögliche Beschädigungen frühzeitig erkannt werden können. Abbildg. 7.10
Datenbankwartung im Hintergrund
Die Kontrolle der Prüfsummen von Datenbankseiten hat Microsoft in Exchange Server 2007 eingeführt, damit sich die Datenbanken in größerem Rahmen selbstständig warten können. In der ersten Version (Exchange Server 2007) wurden die Validierung der Prüfsummen am Ende der Hintergrundwartungsarbeiten durchgeführt. Das funktionierte zwar, störte aber die fortlaufende Replikation. Daher wurde die Prüfsummenvalidierung in Exchange Server 2007 SP1 so geändert, dass sie im Hintergrund stattfinden konnte. Auf den meisten Systemen können Seiten mit einer Geschwindigkeit von 5 MB/s oder ca. 18 GB/h verarbeitet werden, sodass es Exchange relativ leicht fällt, zumindest alle drei bis vier Tage alle Seiten in einer Datenbank durchzugehen. In Exchange Server 2010 können Sie die Prüfsummenvalidierung im Hintergrund (oder den OnlineDatenbankscan) auf zwei verschiedene Weisen durchführen lassen: 쐍 Standardmäßig werden die Postfachdatenbanken von Exchange Server 2010 kontinuierlich untersucht. Wenn der Informationsspeicher die Prüfsummenvalidierung für eine gesamte Datenbank nicht in drei Tagen abschließen kann, wird eine Warnung im Fehlerprotokoll aufgezeichnet. Inner-
398
halb einer Datenbankverfügbarkeitsgruppe wird für die passiven Datenbankkopien automatisch eine Prüfsummenvalidierung im Hintergrund durchgeführt, um sicherzustellen, dass sie nicht beschädigt sind. Das ist die beste Vorgehensweise für große Datenbanken (ab 500 GB), da dadurch die regelmäßige Überprüfung sämtlicher Seiten sichergestellt ist. 쐍 Sie können das Kontrollkästchen für den ESE-Scan im 24 7-Betrieb auch deaktivieren, um den Informationsspeicher anzuweisen, die Prüfsummenaktivierung nur als letzten Teil der Hintergrundwartung durchzuführen. Um mehr Zeit für diese Aufgabe vorzusehen, können Sie den Wartungszeitplan ändern und den Wartungszeitraum verlängern. Die Aufgaben zur Inhaltsprüfung sollten weniger als eine Stunde dauern, sodass Sie davon ausgehen können, dass der Rest des Wartungszeitraums für die Prüfsummenvalidierung zur Verfügung steht. Diese Methode wird für Datenbanken mit weniger als 500 GB empfohlen. Insidertipp: So viele Seiten und so wenig Zeit
Die Einführung der Überprüfung rund um die Uhr hat einen einfachen Grund. Bei kleinen Datenbanken ist es kein Problem, die gesamte Wartungsarbeit in einem festgelegten Zeitraum in der Nacht durchzuführen, da Exchange alle Seiten einer solchen Datenbank in der vorgesehenen Zeit verarbeiten kann. Je größer die Datenbank aber ist, umso mehr Seiten müssen untersucht werden. Der Informationsspeicher verarbeitet die Seiten nacheinander von der ersten bis zu letzten, und je mehr Seiten es werden, umso schwieriger wird es für den Informationsspeicher, die Aufgabe in dem festgelegten Wartungszeitraum abzuschließen. Daher musste Exchange an einen Wartungszyklus rund um die Uhr angepasst werden. Ein weiterer Grund besteht darin, dass Exchange Server 2010 in der Lage ist, in Datenbanken, die sich in einer Datenbankverfügbarkeitsgruppe befinden, einzelne beschädigte Seiten zu reparieren. Bei kontinuierlicher Prüfung kann Exchange solche Fehler fortlaufend ausmerzen. Weitere Informationen über die Reparatur einzelner Seiten finden Sie im Abschnitt »Inkrementelle Neusynchronisierung« von Kapitel 8. Wie die Hintergrundwartung ablaufen soll, können Sie auch in der Exchange-Verwaltungsshell festlegen. Um beispielsweise die kontinuierliche Hintergrundverarbeitung von Seitenprüfsummen zu aktivieren, legen Sie die Eigenschaften einer Postfachdatenbank wie folgt fest: Set-MailboxDatabase –Identity 'DB1' –BackgroundDatabaseMaintenance $True
Wenn Sie den Wert von BackgroundDatabaseMaintenance dagegen auf $False setzen, validiert der Informationsspeicher die Seitenprüfsummen nur während des Wartungszeitraums, der standardmäßig von 1.00 bis 5.00 Uhr morgens reicht. In Kürze werden Sie erfahren, wie Sie diesen Wartungszeitraum ändern können. Die Prüfsummenvalidierung wird automatisch gedrosselt, damit sie sich nicht störend auf die Beantwortung von Clientanforderungen auswirkt. Die entsprechenden Aktivitäten können Sie überwachen, indem Sie in der Systemregistrierung die erweiterten ESE-Leistungsindikatoren aktivieren und im Systemmonitor die Indikatoren des Objekts MSExchange-Datenbank\Defragmentierungstasks beobachten. Weitere Informationen
Mehr zu diesem Thema erfahren Sie im Artikel »Die erweiterten ESE-Leistungsindikatoren sind aktiviert« unter http://technet.microsoft.com/de-de/library/aa997394.aspx.
399
Der Informationsspeicher von Exchange Server 2010
Datenbankverwaltung
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Planen der Hintergrundwartung Die Hintergrundwartung findet während des Zeitraums statt, den Sie auf dem Server festlegen. Am besten wählen Sie dafür eine Zeit aus, in der es wenig Benutzeraktivität gibt und in der auch keine anderen Vorgänge wie z.B. Sicherungen laufen. Standardmäßig plant Exchange die Wartung zwischen 1.00 und 5.00 Uhr nachts. Die meisten Unternehmen sehen für die Hintergrundwartung einen Zeitraum von fünf bis sechs Stunden gewöhnlich ab Mitternacht vor. In Umgebungen, in denen Benutzer in verschiedenen Zeitzonen auf die Datenbanken zugreifen müssen, sodass es während des gesamten Tages zu Benutzeraktivitäten kommt, besteht die Möglichkeit, den Wartungszeitraum während der Arbeitswoche zu verkürzen und dafür am Wochenende mehr Zeit einzuräumen. Wenn der Informationsspeicher nicht alle Aufgaben in dem festgelegten Zeitraum durchführen kann, schließt er die aktuelle Aufgabe ab und fängt zu Beginn des nächsten Wartungszeitraums mit der nächsten an. Um für eine Datenbank einen eigenen Zeitplan einzurichten, rufen Sie in der ExchangeVerwaltungskonsole die Eigenschaften der Datenbank auf und gehen auf der Registerkarte Wartung wie in Abbildung 7.11 gezeigt vor. Abbildg. 7.11
Festlegen des Wartungszeitraums für eine Datenbank
Um den derzeitigen Wartungszeitplan für eine Datenbank abzurufen, können Sie auch die Cmdlets Get-MailboxDatabase bzw. Get-PublicFolderDatabase verwenden: Get-MailboxDatabase –Identity 'DB1' | Format-Table Name, MaintenanceSchedule –AutoSize Name MaintenanceSchedule DB1 {Mo.1:00-Mo.5:00, Di.1:00-Di.5:00, Mi.1:00-Mi.5:00, Do.1:00Do.5:00, Fr.1:00-Fr.5:00, Sa.1:00-Mo.12:00}
Wollen Sie ein und denselben Wartungszeitplan auf mehrere Postfach- oder Öffentliche-OrdnerDatenbanken anwenden, können Sie dazu die Cmdlets Set-MailboxDatabase bzw. Set-PublicFolderDatabase verwenden. Um beispielsweise den Wartungsraum für eine Reihe von Datenbanken auf einem Server auf 1.00 bis 7.00 Uhr morgens festzulegen, geben Sie Folgendes ein:
400
Get-MailboxDatabase –Server 'ExServer1' | Set-MailboxDatabase –MaintenanceSchedule 'So.1:00–So.7:00, Mo.1:00–Mo.7:00, Di.1:00–Di.7:00, Mi.1:00–Mi.7:00, Do.1:00–Do.7:00, Fr.1:00-Fr.7.00, Sa.1:00-Sa.7.00'
Mit dieser Syntax können Sie die vorgesehenen Zeiten für Wartungsarbeiten sehr genau festlegen. Allerdings ist die Angabe von Datum und Uhrzeit dabei etwas knifflig. Zwischen der Uhrzeit des ersten Tages und dem Datum des letzten muss ein Bindestrich stehen (1:00-Mi). Im Zweifelsfall können Sie den Wartungszeitplan auch in der Exchange-Verwaltungskonsole für eine Datenbank festlegen und sich dann das Befehlsprotokoll der Shell ansehen, um sich die Syntax anzusehen, die die Konsole zur Festlegung des Zeitplan verwendet.
Aufgaben der Inhaltswartung Nachdem wir jetzt wissen, was bei der Hintergrundwartung geschieht und wann es geschieht, können wir uns einige der Einzelheiten ansehen. Clients wie Outlook nutzen es sehr stark aus, dass der Informationsspeicher dynamische Indizes oder Sichten erstellen kann. Wenn Sie beispielsweise Ihren Posteingang lieber nach Absendern als nach Eingangsdatum sortierten möchten, fordert Outlook beim Informationsspeicher die entsprechende Sicht an. Hat der Informationsspeicher diese Sicht bereits einmal erstellt und befindet sie sich noch im Cache, erfolgt die Antwort sehr schnell, aber der Informationsspeicher ist auch in der Lage, Anforderungen nach einer ganz neuen Sicht rasch zu verarbeiten. Mit der Zeit häuft der Informationsspeicher eine große Menge von Sichten an, denn für jeden Ordner in jedem Postfach kann es mehrere Sichten geben. Verringern der Anhäufung von Datenbanksichten mithilfe von Ablaufdaten
Es ist nicht wünschenswert, sämtliche Sichten aufzubewahren, da sie schließlich alle Platz in der Datenbank verbrauchen. Außerdem kann es durchaus sein, dass eine Sicht nur einmal und dann nie wieder verwendet wird. Der Informationsspeicher weist jeder Sicht ein Ablaufdatum zu und verfolgt diese Daten in der internen Indexalterungstabelle nach. Während der Hintergrundwartung durchsucht der Informationsspeicher diese Tabelle, um Sichten zu finden, die bereits älter als 40 Tage sind, und entfernt sie dann. Wenn ein Client auf eine Sicht zugreift, wird deren Ablaufdatum natürlich zurückgesetzt. Die nächste Aufgabe ist die so genannte Tombstone-Wartung. Der Informationsspeicher führt für jeden Ordner eine Liste gelöschter Nachrichten und eine Liste von »Grabsteinen« (engl. tombstones), die angeben, dass eine Nachricht gelöscht wurde. Für replizierte Ordner, z.B. öffentliche Ordner, ist die Tombstone-Liste sehr wichtig, da sie dem Informationsspeicher sagt, welche Löschoperationen für Nachrichten er auf alle Server mit Replikaten des entsprechenden Ordners replizieren muss. Nach erfolgter Replikation kann der Informationsspeicher die Einträge in der Tombstone-Liste löschen. Bei der Hintergrundwartung wird dafür gesorgt, dass diese Listen genau sind. Während der Hintergrundwartung untersucht der Informationsspeicher alle Nachrichten mit einem Löschflag (wenn genug Zeit zur Verfügung steht, verarbeitet er den gesamten Inhalt des Zwischenspeichers für gelöschte Elemente), um zu bestimmen, ob die Aufbewahrungszeit abgelaufen ist. Wenn dies der Fall ist, wird die Nachricht aus dem Informationsspeicher entfernt (harte Löschung). Die Seiten, auf denen sie gespeichert war, werden dann zur Wiederverwendung bereitgestellt. Die
401
Der Informationsspeicher von Exchange Server 2010
Datenbankverwaltung
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Aufbewahrungszeit können Sie für Postfächer, Datenbanken und öffentliche Ordner jeweils einzeln festlegen. Zugriff auf diese Einstellungen haben Sie über die Exchange-Verwaltungskonsole und -Verwaltungsshell. Fehlerbehebung: Ich brauche eine gelöschte Nachricht
Wenn ein Client eine Nachricht löscht, setzt der Informationsspeicher ein Flag, um die Nachricht im Postfach auszublenden (eine so genannte »weiche« Löschung). Bei einer »harten« Löschung wird ein Element endgültig aus der Datenbank entfernt und kann nicht wiedergewonnen werden. Dies geschieht schließlich, wenn Exchange die Elemente entfernt, deren Aufbewahrungszeit für gelöschte Objekte abgelaufen ist. Clients können Nachrichten aus dem Zwischenspeicher für gelöschte Objekte zurückgewinnen, indem sie das Flag entfernen, sodass die Nachricht wieder im Posteingang erscheint. (Das ist im Grunde genommen das, was passiert, wenn Sie in Outlook oder OWA die Funktion zur Wiederherstellung gelöschter Objekte verwenden.) Die übliche Aufbewahrungszeit für gelöschte Objekte beträgt 14 Tage. In Exchange können Sie auch für den Inhalt in einem öffentlichen Ordner Aufbewahrungszeiträume festlegen, und zwar entweder für eine ganze Datenbank oder für einen einzelnen Ordner. Das ist für öffentliche Ordner gedacht, deren Inhalt nach einem festen Muster veraltet, wie es z.B. bei RSS-Feeds der Fall ist. Wenn Sie dafür sorgen, dass veraltete Inhalte aus einem öffentlichen Ordner entfernt werden, steuern Sie damit das Wachstum dieses Ordners. Um ein neues Alterungslimit von 365 Tagen für eine Öffentliche-OrdnerDatenbank festzulegen, gehen Sie folgendermaßen vor: Set-PublicFolderDatabase –Identity 'PFDatabase1' –ItemRetentionPeriod 365.00:00:00
Wollen Sie dagegen einem einzelnen öffentlichen Ordner einen solchen Grenzwert zuweisen, verwenden Sie den folgenden Befehl: Set-PublicFolder –Identity '\Exchange 2010\Admin Discussions' –AgeLimit '365.00:00:00' –UseDatabaseAgeDefaults $False
Es ist auch möglich, ein Alterungslimit für eine Reihe öffentlicher Ordner mit einem gemeinsamen Stammverzeichnis festzulegen. Dazu nutzen Sie die Cmdlets Get-PublicFolder und Set-PublicFolder zusammen ein: Get-PublicFolder –Identity '\Exchange 2010' –Recurse | Set-PublicFolder –AgeLimit '365.00:00:00' –UseDatabaseAgeDefaults $False
TIPP Mit dem Parameter -Recurse können Sie sich abwärts durch die untergeordneten Ordner bewegen. Die Hintergrundwartung sucht nach gelöschten öffentlichen Ordnern und Systemnachrichten, deren Aufbewahrungszeit abgelaufen ist, und entfernt sie. Außerdem hält der Informationsspeicher nach gelöschten Postfächern Ausschau, die eine Standardaufbewahrungsdauer von 30 Tagen aufweisen, und entfernt sie, wenn sie abgelaufen sind. Durch das Entfernen nicht mehr gebrauchter Ordner und Postfächer wird auch die interne Tabellenstruktur der Datenbank aufgeräumt und damit die Leistung verbessert. Die nächste Überprüfung gilt gelöschten und abgelaufenen öffentlichen Ordnern. Wenn Sie einen öffentlichen Ordner löschen, erstellt der Informationsspeicher standardmäßig einen TombstoneEintrag für ihn. Dadurch kann der Replikationsmechanismus die Löschung korrekt an die Server 402
weitervermitteln, auf denen sich Replikate befinden. Da die Replikation unter manchen Umständen nicht schnell genug abläuft, bewahrt der Informationsspeicher den Tombstone-Eintrag 180 Tage lang auf (Standardwert). Sollte die Replikation den Eintrag nicht innerhalb von 180 Tagen weitervermitteln können, dann leidet Ihre Organisation unter grundlegenden Replikationsproblemen, gegen die einige wenige fehlerhafte Tombstone-Einträge nicht ins Gewicht fallen. Während der Hintergrundwartung sucht der Informationsspeicher auch nach abgelaufenen Tombstone-Einträgen für Ordner und entfernt sie. Allerdings werden dabei innerhalb von je 24 Stunden nicht mehr als 500 Tombstone-Einträge gelöscht. Die Replikation öffentlicher Ordner ist in gewisser Hinsicht eine schwarze Kunst. Dabei können sehr leicht Konflikte auftreten, beispielsweise wenn mehrere Benutzer das gleiche Element in verschiedenen Replikaten eines öffentlichen Ordners ändern oder dasselbe Element im selben Replikat gleichzeitig speichern möchten. Wenn ein solcher Konflikt auftritt, sendet der Informationsspeicher eine Konfliktauflösungsnachricht an die Benutzer, die das Problem verursacht haben, damit sie es lösen. Menschen sind eher in der Lage zu entscheiden, welche Änderung wichtiger ist, weshalb sie den Konflikt besser lösen können. Während noch entschieden wird, was zu tun ist, behält der Informationsspeicher die verschiedenen Versionen des betroffenen Elements bei. Kommt von den Benutzern jedoch keine Antwort, untersucht der Informationsspeicher die einzelnen Elemente, die in den Konfliktfall verwickelt sind, und löst das Problem automatisch, indem er gewöhnlich die jüngste Version akzeptiert. Die nächste Wartungsaufgabe besteht darin, die Serverversionen für die öffentlichen Speicher zu aktualisieren. Bei diesem Vorgang werden die Versionsinformationen aktualisiert, die erforderlich sind, um den Systemkonfigurationsordner auf dem neuesten Stand zu halten. Für den Informationsspeicher bedeutet das keinen großen Zusatzaufwand. Bei diesem Vorgang haben Sie keinerlei Steuerungsmöglichkeiten. Der Informationsspeicher überprüft auch, ob die Systemordner mit den Frei/Gebucht-Informationen und die Dateien des Offlineadressbuchs vorhanden sind und dass es keine Duplikate gibt.
Nachverfolgen der Hintergrundwartung Der Informationsspeicher zeichnet während der Hintergrundwartung Ereignisse im Anwendungsprotokoll auf. Wie bei anderen Komponenten von Exchange bestimmt der festgelegte Detaillierungsgrad der Diagnoseprotokollierung, wie viele Informationen über die Wartungsvorgänge der Informationsspeicher in das Protokoll schreibt. Den Detaillierungsgrad legen Sie mit dem Cmdlet Set-EventLogLevel für die Eigenschaften 'MSExchangeIS\9000 Private\Background Cleanup' und 'MSExchangeIS\9001 Public\Background Cleanup' fest. Um sehr viele Informationen zu sehen, ändern Sie den Wert von Lowest auf Expert: Set-EventLogLevel –Identity 'MSExchangeIS\9000 Private\Background Cleanup' –Level 'Expert'
Nach der Übernahme der neuen Einstellungen beginnt der Informationsspeicher bei der nächsten Durchführung der Hintergrundwartung damit, die Ereignisse mit dem gewünschten Detaillierungsgrad zu protokollieren. Außer auf großen oder stark belasteten Servern laufen die meisten der Wartungsarbeiten sehr schnell ab. Die offensichtliche Ausnahme bildet die Defragmentierung im Hintergrund. Dies ist eine sehr langwierige Aufgabe, die je nach der weiteren Belastung des Servers durch andere Tätigkeiten, der Hardwarekonfiguration und der Größe der zu verarbeitenden Datenbanken mehrere Stunden in Anspruch nehmen kann. 403
Der Informationsspeicher von Exchange Server 2010
Datenbankverwaltung
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Erkennen und Isolieren von beschädigten Elementen Elemente oder Nachrichten, die in irgendeiner Form beschädigt sind (indem sie etwa einen nicht wohlgeformten Header aufweisen), neigen leider dazu, Exchange-Administratoren extreme Schwierigkeiten zu bereiten. In Exchange Server 2007 gab es erstmals die Möglichkeit, beschädigte Nachrichten im Transportsystem zu erkennen und zu isolieren. Vereinfacht gesagt: Wenn das Transportsystem eine Nachricht für beschädigt hält, isoliert es sie in einer Warteschlange, die der Administrator dann untersuchen kann, um zu entscheiden, ob die Nachricht tatsächlich ein Problem darstellt. In Exchange Server 2010 wird dieses Prinzip auch auf den Informationsspeicher angewandt, denn wenn ein Postfach beschädigte Elemente enthält und ein Client versucht, darauf zuzugreifen, kann das dazu führen, dass der Informationsspeicherprozess nicht ordnungsgemäß beendet wird. Der Informationsspeicherprozess weist mehrere Threads auf, wobei die Threads mit Postfächern verknüpft sind. Unter folgenden Umständen kommt der Informationsspeicher zu dem Schluss, dass bei einem Postfach möglicherweise ein Problem vorliegt: 쐍 Mehr als fünf Threads für dasselbe Postfach sind seit über 60 Sekunden »eingefroren«. 쐍 Ein Thread für ein Postfach stürzt ab. Da es in der Natur von Software liegt, hin und wieder abzustürzen, akzeptiert Exchange drei Abstürze innerhalb von zwei Stunden. Erst bei einer stärkeren Häufung gilt der Grenzwert für Abstürze als überschritten. Wenn der Informationsspeicher ein Postfach als problematisch einstuft, schreibt er Angaben darüber in die Systemregistrierung, nämlich den global eindeutigen Bezeichner (GUID) des Postfachs sowie den Zeitpunkt des Absturzes und die Anzahl der Vorfälle. Diese Informationen werden unter dem Stamm für die Postfachdatenbank gespeichert, die das betreffende Postfach enthält, und sind in zwei Einträgen enthalten, wobei der eine den Zeitpunkt des letzten Absturzes enthält und der andere die Anzahl der Abstürze: 쐍 HKLM\System\CurrentControlSet\Services\MSExchangeIS\Server Name\Private-{Database GUID}\QuarantinedMailboxes\{Mailbox GUID}\LastCrashTime 쐍 HKLM\System\CurrentControlSet\Services\MSExchangeIS\Server Name\Private-{Database GUID}\QuarantinedMailboxes\{Mailbox GUID}\CrashCount Wenn ein Postfach den Schwellenwert für Abstürze überschreitet oder wenn der Informationsspeicher erkennt, dass Threads durch beschädigte Inhalte blockiert werden, stellt er das Postfach in Quarantäne, sodass die normale Clientinteraktion, auch der Zugriff durch die Exchange-Postfach-Assistenten, blockiert wird. Im Anwendungsprotokoll finden Sie das Ereignis 10018, das MSExchangeIS für das problematische Postfach aufgezeichnet hat. Der Text des Eintrags enthält den definierten Namen des betroffenen Postfachs und lautet wie folgt: Das Postfach des Benutzers /o=TonyR/ou=Exchange Administrative Group (FYDIBOHF23SPDLT) / cn=Recipients/cn=TRedmond wurde isoliert. Der Zugriff auf dieses Postfach wird in den nächsten sechs Stunden auf administrative Anmeldungen beschränkt.
An ein Postfach in Quarantäne kann sich niemand anmelden, und Exchange stellt ihm auch keine Nachrichten zu (sie verbleiben in der Transportwarteschlange). Die einzige Operation, die Sie an einem Quarantänepostfach vornehmen können, besteht darin, es in eine andere Datenbank zu verschieben. Standardmäßig behält Exchange ein Postfach sechs Stunden lang in Quarantäne (21.600 Sekunden). Den Quarantänezeitraum und den Schwellenwert für Abstürze können Sie ändern,
404
indem Sie zwei neue Registrierungsschlüssel eingeben. Sie gelten jeweils für eine bestimmte Postfachdatenbank und werden bei deren Bereitstellung gelesen. Der erste Schlüssel enthält die Quarantäneperiode in Sekunden, der zweite legt den Schwellenwert für die Anzahl der Threadabstürze fest, die Exchange noch toleriert. 쐍 HKLM\System\CurrentControlSet\Services\MSExchangeIS\Server Name\Private-{Database GUID}\QuarantinedMailboxes}\MailboxQuarantineDurationInSeconds 쐍 HKLM\System\CurrentControlSet\Services\MSExchangeIS\Server Name\Private-{Database GUID}\QuarantinedMailboxes}\MailboxQuarantineCrashThreshold Insidertipp: Ein Shellbefehl zum Aufspüren von Postfächern in Quarantäne
Wahrscheinlich bemerkt der Administrator erst dann, dass sich ein Postfach in Quarantäne befindet, wenn sich der betreffende Benutzer darüber beschwert, dass er keinen Zugriff mehr darauf hat. In diesem Fall kann der Administrator durch einen Blick in die Registrierung erkennen, dass das Postfach in Quarantäne ist. In Exchange Server 2010 wurde das Cmdlet Get-MailboxStatistics so erweitert, dass Sie es jetzt auch dazu einsetzen können, Quarantänepostfächer aufzuspüren. Der folgende Befehl führt alle zurzeit in Quarantäne befindlichen Postfächer auf: Get-MailboxStatistics | Where {$_.IsQuarantine –eq $True}
Mit Hilfsprogrammen wie MFCMAPI (das Sie auf http://mfcmapi.codeplex.com/ erhalten) können Sie auf ein in Quarantäne befindliches Postfach zugreifen und alle beschädigten Elemente entfernen. Um ein beschädigtes Element als solches zu erkennen, erfordert es allerdings genaue Kenntnisse in MAPI und über die zu erwartende Gliederung der Daten, was die Fähigkeiten eines durchschnittlichen Exchange-Administrators übersteigen dürfte. SP1 bietet eine bessere Lösdung, denn hier können Sie Postfächer in Quarantäne zu einer anderen Datenbank verschieben. Das kann zwei positive Auswirkungen nach sich ziehen. Erstens können Sie das Postfach in einer Datenbank isolieren, die ruhig abstürzen darf, weil dadurch der Zugriff anderer Benutzer nicht gestört wird. Zweitens können sich manche Probleme durch das Verschieben der Datenbank lösen. Während der Postfachreplikationsdienst die Elemente vom Quell- zum Zielpostfach verschiebt, ist es durchaus möglich, dass z.B. die benannten Eigenschaften der Elemente konsolidiert oder beschädigte Elemente entfernt werden. Nähere Informationen darüber, wie das Verschieben von Postfächern vonstatten geht, lesen Sie in Kapitel 12, »Postfachunterstützungsdienste«. Der Informationsspeicher hält das betroffene Postfach in Quarantäne, bis die Quarantänedauer abgelaufen ist. Daraufhin wird das Postfach wieder freigegeben, indem die Registrierungsschlüssel für die Abstürzzeiten und -zahlen entfernt werden. Das geschieht auch, wenn die Schlüssel beim Bereitstellen der Datenbank älter als zwei Stunden sind. Der Grund für diese Maßnahme besteht darin, dass durch das Aufheben der Bereitstellung und das erneute Bereitstellen der Datenbank durchaus die zugrunde liegenden Probleme behoben worden sein können, die für den Absturz von Threads verantwortlich waren. Ein Postfach, das beschädigte Daten enthält, aus der Quarantäne zu befreien, kann natürlich wiederum zu einer Serie von Abstürzen und damit zu erneuter Quarantäne führen. Der Informationsspeicher untersucht in regelmäßigen Abständen die Postfächer, die Threadabstürze veranlasst haben. Treten innerhalb eines Zeitraums von zwei Stunden keine weiteren Abstürze auf, geht der Informationsspeicher davon aus, dass sich das Problem erledigt hat, und nimmt das Postfach aus der Quarantäneliste in der Systemregistrierung heraus. Auch ein Administrator kann ein Postfach von dieser Liste entfernen, indem er manuell den betreffenden Eintrag in der Registrierung tilgt.
405
Der Informationsspeicher von Exchange Server 2010
Datenbankverwaltung
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Fehlerbehebung: Was tun, wenn ein Postfach immer wieder in Quarantäne versetzt wird?
Wenn ein Postfach in einen Teufelskreis wiederholter Quarantäne gerät, ist das ein Zeichen dafür, dass ein schwerwiegendes Problem vorliegt. Möglicherweise können Sie es dadurch lösen, dass Sie das Postfach in eine andere Datenbank verschieben. Dabei weisen Sie Exchange an, beschädigte Elemente zu ignorieren, die während des Verschiebevorgangs bemerkt werden, sodass das Postfach anschließend so sauber ist wie möglich. Wenn das nicht funktioniert und das Postfach weiterhin Probleme verursacht, bleibt Ihnen nur noch die Möglichkeit, so viele Informationen wie möglich in eine PST-Datei zu exportieren und das Postfach zu löschen. Schlägt auch der Export aufgrund der Beschädigungen fehl, können Sie die Daten unter Umständen aus einer Datenbankwiederherstellung zurückgewinnen, wie Sie in Kapitel 9, »Sicherung und Wiederherstellung«, beschrieben wird. Dies sollten Sie jedoch wirklich nur dann tun, wenn Sie sicher sind, dass das zugrunde liegende Problem behoben wurde oder wenn Sie den Clientzugriff auf das Postfach erlauben wollen, damit der Benutzer so viele Daten wie möglich aus dem Postfach retten kann, bevor Sie es löschen und neu erstellen. Wenn in der Registrierung im Stammverzeichnis für die Datenbank der Eintrag QuantinedMailboxes nicht vorhanden ist, dann hat der Informationsspeicher in der betreffenden Datenbank noch nie ein problematisches Postfach gefunden. In einer Datenbankverfügbarkeitsgruppe repliziert Exchange die Registrierungsdaten über die Postfachquarantäne mithilfe des Failoverclusterdienstes auf andere Server, damit die Kenntnisse über problematische Postfächer auch nach einem Failover erhalten bleiben.
Sicherungen und endgültiges Entfernen Sie können dafür sorgen, dass der Informationsspeicher erst dann Elemente endgültig aus einer Datenbank entfernt, wenn erfolgreich eine Sicherung erstellt wurde. Dazu nehmen Sie im Eigenschaftendialogfeld für die Datenbank eine Einstellung vor (siehe Abbildung 7.12). Der entsprechende Befehl in der Exchange-Verwaltungsshell lautet: Set-MailboxDatabase -Identity 'Sales'-RetainDeletedItemsUntilBackup $True
Wenn diese Eigenschaft festgelegt ist, verbleiben die Elemente auch über die Aufbewahrungszeit hinaus im Papierkorb, bis eine fehlerfreie Sicherung durchgeführt wurde. Sicherlich möchten Sie nicht in die Situation geraten, dass ein Element im Papierkorb abgelaufen ist und von der Hintergrundwartung entfernt wurde und Sie es auch nicht aus einer Sicherung wiederherstellen können, weil versehentlich keine Sicherung durchgeführt wurde oder weil während des Vorgangs ein Fehler auftrat, der die Sicherung ungültig macht. Es wird empfohlen, diese Einstellung für alle Postfachdatenbanken zu aktivieren – außer für diejenigen mit Umlaufprotokollierung, die gewöhnlich für die Speicherung kurzlebiger Daten vorgesehen sind und keine so starke Absicherung gegen Datenverluste benötigen wie Benutzerpostfächer.
406
Datenbankverwaltung
Bei dieser Einstellung werden Elemente erst dann gelöscht, wenn die Datenbank gesichert wurde
Der Informationsspeicher von Exchange Server 2010
Abbildg. 7.12
Schutz gegen lange Wartezeiten Speicherdatenbanken können aus verschiedenen Gründen an einer hohen Latenz (langen Wartezeiten) leiden. Beispielsweise antwortet eine mängelbehaftete Festplatte erst nach Sekunden statt nach Millisekunden, oder ein Server weist eine hohe CPU-Belastung oder einen Engpass beim Arbeitsspeicher auf. Außerdem ist es möglich, dass ein Postfach aufgrund eines Bugs im Client oder eines anderen Problems Schwierigkeiten macht. In Exchange Server 2010 SP1 ist das neue Skript Troubleshoot-DatabaseLatency.ps1 enthalten, das Sie ausführen können, wenn ein Server überlastet zu sein scheint, um die Grundursache der erhöhten Wartezeiten herauszufinden. Um beispielsweise die Latenz der Datenbank DB1 zu prüfen, setzen Sie das Skript mit folgender Syntax ein: Troubleshoot-DatabaseLatency.ps1 –Database "DB1" -LatencyThreshold 60 -TimeInServerThreshold 10 -Quarantine $True -MonitoringContext $True
Das Skript nimmt die folgenden Parameter entgegen: 쐍 LatencyThreshold ist der Schwellenwert für die Latenz, wobei der Standardwert 70 Millisekunden beträgt. Normalerweise gibt es keinen Grund dafür, diesen Wert zu ändern, es sei denn, Sie möchten ausprobieren, welche Ergebnisse für Ihre Umgebung unter geänderten Bedingungen herauskommen, oder Sie wurden vom Microsoft-Support im Rahmen einer Fehlersuche dazu aufgefordert.
407
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
쐍 TimeInServerThreshold gibt an, wie viele Sekunden pro Minute auf die Arbeit für ein bestimmtes Postfach verwendet werden können, bevor das Postfach für die Integrität der Datenbank als gefährlich eingestuft wird. Um zu ermitteln, wie viele Sekunden tatsächlich aufgewendet wurden, wird zunächst zusammengezählt, wie viel Zeit sämtliche Threads während des vom Cmdlet GetStoreUsageStatistics verwendeten Zeitraums für Arbeiten an dem Postfach im Informationsspeicher aufgewendet haben (CPU-Zeit, Warten auf Ein-/Ausgabe und andere Operationen). Anschließend wird Gesamtzahl der Sekunden durch die Länge der Messperiode von Get-StoreUsageStatistics geteilt (10 Minuten). Standardmäßig beträgt der Schwellenwert 60 Sekunden. 쐍 Quarantine setzen Sie auf $True, wenn Sie die Postfächer, die den Server stark beanspruchen, gleich in Quarantäne versetzen lassen möchten. 쐍 MonitoringContext gibt an, ob das Skript auf einem Server läuft, der von einem System wie Microsoft System Center Operations Manager überwacht wird. In diesem Fall müssen Sie die Eigenschaft auf $True setzen, damit das Skript Ereignisse in das Anwendungsprotokoll schreibt. Wird das Problem durch ein Postfach hervorgerufen, das in einem Zeitraum von 10 Minuten mehr als einen CPU-Thread belegt, versetzt Exchange dieses Postfach in Quarantäne und belässt es während der standardmäßigen Quarantänedauer in diesem Zustand, sofern es nicht in eine andere Datenbank verschoben wird. Derselbe Mechanismus wird auch zum Aufspüren beschädigter Elemente verwendet (worüber wir bereits gesprochen haben), wobei der Absturzzähler so eingerichtet ist, dass bei drei Abstürzen sofort eine Quarantäne erfolgt. Außerdem wird ein Postfach in Quarantäne versetzt, wenn es während der Dauer von zwei Stunden dreimal in die Nähe des Grenzwerts von einem Thread in einem zehnminütigen Zeitraum kommt.
Schutz gegen übermäßiges Datenbank- und Protokollwachstum Es hat häufig Situationen gegeben, in denen die Datenbanken auf einem Postfachserver extrem stark gewachsen sind oder in denen übermäßig viele Transaktionsprotokolle angelegt wurden. Datenbanken wachsen gewöhnlich mit derselben Rate wie die in ihnen enthaltenen Postfächer. Im Grunde gilt das auch für die Transaktionsprotokolle, wobei jedoch die Generierung von Transaktionen dem Datenbankwachstum vorauseilen kann, wenn in der Datenbank noch genügend Platz ist, der von neuen Transaktionen ausgefüllt werden kann, oder wenn Tätigkeiten, durch die die Datenbank nicht vergrößert sind, z.B. Löschungen einer großen Anzahl an Postfächern, zu einer Spitze beim Wachstum der Transaktionsprotokolle führen. Wenn beispielsweise eine Datenbank gewöhnlich um 100 MB pro Monat wächst und plötzlich über Nacht um 1 GB größer wird, während gleichzeitig ein entsprechender Anstieg bei den Transaktionsprotokollen stattfindet, kann das durchaus auf berechtigte Aktivitäten zurückgehen, aber auch auf einen Softwarebug. Berechtigte Aktvitäten sind z.B. die Verschiebung vieler Postfächer in die Datenbank oder der Import von Daten aus PST-Dateien. Ein Beispiel für Softwarefehler war z.B. jener Bug, der die Übertragung von Nachrichten aus Outlook in eine Schleife eintreten ließ, sodass ständig neue Transaktionen hervorgerufen wurden. Daher müssen Sie herausfinden, ob das Datenbankwachstum auf ein Problem zurückgeht oder auf Verwaltungstätigkeiten. Ersteres kann sich als hartnäckig erweisen, sodass Sie einen Patch brauchen, um den Fehler zu beheben, Letzteres dagegen wird sich wahrscheinlich mit der Zeit wieder geben.
408
In Exchange Server 2010 SP1 stellt Microsoft zur Fehlerbehebung das Skript Troubleshoot-DatabaseSpace.ps1 bereit, das Sie auf einem Postfachserver mit übermäßigem Datenbank- oder Protokollwachstum ausführen können. Dieses Skript verfolgt einen praxisorientierten Ansatz und zieht keine voreiligen Schlüsse. Es unternimmt nichts gegen das Problem, bis der verfügbare Platz auf der Festplatte für die Datenbanken oder die Transaktionsprotokolle einen Grenzwert erreicht, bei dem abzusehen ist, dass der Platz bei derzeitigen Wachstumsrate innerhalb eines von Ihnen angegebenen Zeitraums ausgeschöpft ist. Zu diesem Zeitpunkt bestimmt das Skript, welche Postfächer für das Wachstum verantwortlich sind, und stellt sie in Quarantäne, um den weiteren Größenanstieg zu bremsen. Solange der Festplattenplatz bei der vorliegenden Wachstumsrate nicht innerhalb des angegebenen Zeitraums ausgeschöpft wird, schreibt Exchange ein Ereignis in das Anwendungsprotokoll, in dem auf die drohende Gefahr der Festplattenüberfüllung aufgrund des Datenbank- oder Protokollwachstums hingewiesen wird. Falls SCOM installiert ist, wird eine SCOM-Benachrichtigung ausgelöst. Das Skript führen Sie wie folgt aus: Troubleshoot-DatabaseSpace.ps1 –DatabaseIdentityDB1 -PercentEdbFreeSpaceThreshold 29 -PercentLogFreeSpaceThreshold 20 –HourThreshold 6 -Quarantine:$True
Es gibt folgende Parameter: 쐍 PercentEdbFreeSpaceThreshold legt den Grenzwert für den Prozentsatz an verfügbarem freien Speicher auf der Festplatte mit der Datenbank fest. Bei der Berechnung des freien Platzes berücksichtigt Exchange die noch nicht belegten Teile der Datenbank. 쐍 PercentLogFreeSpaceThreshold legt den Grenzwert für den Prozentsatz an verfügbarem freien Speicher auf der Festplatte mit den Transaktionsprotokollen fest. 쐍 HourThreshold legt fest, für wie viele Stunden der freie Platz beim fortgesetzten Datenbankoder Protokollwachstum noch reichen muss, bevor das Skript eingreift. In diesem Beispiel reagiert das Skript (indem es die Postfächer, die für das übermäßige Wachstum verantwortlich sind, in Quarantäne stellt), wenn der Festplattenplatz bei der derzeitigen Verbrauchsrate in weniger als sechs Stunden erschöpft wäre. Solange noch genügend Platz für das weitere Datenbankwachstum während des angegebenen Zeitraums vorhanden ist, zeichnet das Skript nur ein Ereignis auf und überlässt es dem Administrator, die notwendigen Maßnahmen zu ergreifen, um das weitere Wachstum zu beschränken. 쐍 Quarantine gibt an, ob das Skript Postfächer in Quarantäne stellen darf. Wenn Sie diesen Parameter auf $False setzen, versucht das Skript nicht, problematische Postfächer in Quarantäne zu versetzen.
Isolieren von Fehlern des Speichertreibers Der Speichertreiber, der auf Hub-Transport-Servern ausgeführt wird, ist eine sehr wichtige Komponente. Er stellt den Mechanismus bereit, um eingehende Nachrichten an Postfachdatenbanken zuzustellen. In Exchange Server 2010 SP1 können Sie die Verbindungen des Speichertreibers zur Zustellung von Nachrichten so einrichten, dass Exchange alle auftretenden Fehler isolieren und ihre Auswirkungen begrenzen kann. In Tabelle 7.5 sind die Grenzwerte für den Speichertreiber aufgeführt, die in Exchange Server 2010 SP1 gelten.
409
Der Informationsspeicher von Exchange Server 2010
Datenbankverwaltung
Kapitel 7 Tabelle 7.5
Der Informationsspeicher von Exchange Server 2010
Verbindungsgrenzwerte für den Speichertreiber Verbindung
Grenzwert
Vom Hub-Transportzum Postfachserver
Gleichzeitige Zustellung zu einem Postfach: Einem Postfach kann immer nur eine Nachricht auf einmal zugestellt werden. Dieser Grenzwert sorgt dafür, dass alle Postfächer in einer Datenbank mit derselben Geschwindigkeit und derselben Dienstqualität bedient werden. Gleichzeitige Zustellung zu einer Datenbank: Einer Postfachdatenbank können höchstens zwei Nachrichten gleichzeitig zugestellt werden. Dadurch wird verhindert, dass eine Datenbank die anderen Datenbanken auf demselben Server beeinträchtigt, wenn es Hardwareprobleme mit der Festplatte oder dem Festplattencontroller oder einen Softwarefehler gibt. Wenn Exchange erkennt, dass die Leistung einer Postfachdatenbank geringer ist als üblich, kann es diesen Grenzwert automatisch verringern. Gleichzeitige Zustellung zu einem Postfachserver: Einem Postfachserver können gleichzeitig höchstens 24 Nachrichten zugestellt werden. Ein Hub-Transport-Server kann Nachrichten an alle Postfachserver in seinem Standort liefern. Diese Einstellungen verhindern, dass sich ein Problem auf einem Postfachserver (z.B. eine starke Belastung) auch auf die Zustellung zu anderen Postfachservern im Standort auswirkt. Gleichzeitige Zustellung von Nachrichten an alle Postfachserver: Eine Nachricht kann nur in jeweils höchstens zwölf Ausfertigungen gleichzeitig an sämtliche Postfachserver im Standort zugestellt werden. Dadurch wird verhindert, dass beschädigte oder aufwändige Nachrichten (mit vielen umfangreichen Anhängen oder mehreren hundert Empfängern im Header) sämtliche verfügbaren Verbindungen mit Beschlag belegen und damit die Zustellung vom Hub-Transport- zu den Postfachservern im Standort verlangsamen oder zum Stillstand bringen.
Vom Postfach- zum Hub-Transport-Server
Gleichzeitige Übertragung an einen Hub-Transport-Server: Der Grenzwert für die maximale Anzahl von Verbindungen beträgt das Fünffache der Anzahl verfügbarer Prozessorkerne auf dem Postfachserver. Damit wird festgelegt, wie viele gleichzeitige Übertragungen von einem Postfachserver zu sämtlichen Hub-Transport-Servern im Standort erfolgen können. Gleichzeitige Übertragungen von einer Postfachdatenbank: Von einer Postfachdatenbank aus können gleichzeitig höchstens vier Verbindungen ausgeführt werden. Gleichzeitige Übertragungen von einem einzelnen Postfachserver: Ein Hub-Transport-Server kann höchstens zwölf gleichzeitige Übertragungen von einem einzelnen Postfachserver verarbeiten. Gleichzeitige Übertragungen an einen Hub-Transport-Server: Ein Postfachserver kann höchstens 15 gleichzeitige Übertragungen an einen einzelnen Hub-TransportServer vornehmen.
410
Vom Hub-Transportzum Postfachserver (standortweit)
Der obere Grenzwert für die Anzahl der Verbindungen von den Hub-Transport- zu den Postfachservern innerhalb eines Standorts beträgt das 20-fache der Anzahl von Prozessorkernen auf den Hub-Transport-Servern des Standorts. Wenn der Standort z.B. zwei Hub-Transport-Server mit jeweils vier Prozessorkernen umfasst, liegt der Grenzwert bei 160 Verbindungen.
Von den Postfachzu den Hub-TransportServern (standortweit)
Der obere Grenzwert für die Anzahl der Verbindungen von den Postfach- zu den Hub-Transport-Servern innerhalb eines Standorts beträgt das 5-fache der Anzahl von Prozessorkernen auf den Postfachservern des Standorts. Wenn der Standort z.B. sechs Postfachserver mit jeweils vier Prozessorkernen umfasst, liegt der Grenzwert bei 120 Verbindungen.
Das Ende von ISINTEG ININTEG ist das Wartungsprogramm für die Informationsspeicher-Integrität, das Microsoft bereitgestellt hat, um Probleme in der logischen Struktur von Exchange-Datenbanken zu beheben. (Im Gegensatz dazu befasst sich ESEUTIL mit Problemen, die physische Beschädigungen hervorrufen.) Dieses Programm war in jeder Version von Exchange vorhanden und ist auch noch in Exchange Server 2010 zu finden, doch hier ist es nur noch ein Shellprogramm, das nichts mehr tut. Für die Neutralisierung von ISINTEG in Exchange Server 2010 gibt es zwei Gründe. Erstens sind aufgrund der radikalen Schemaänderung der Datenbank Beschädigungen jetzt aus ganz anderen Gründen möglich. Der Gerechtigkeit halber müssen wir aber hinzufügen, dass viele der Ursachen für Beschädigungen in Datenbanken vor Exchange Server 2010 durch das neue Schema beseitigt wurden. Zweitens hatte man bei Microsoft einfach nicht die Zeit, ein aktualisiertes ISINTEG für Exchange Server 2010 zu erstellen. Beim vorhergehenden Schema wurden eine Menge von Tabellen auf der Ebene der einzelnen Datenbanken verwendet, sodass eine Beschädigung in einer Tabelle sämtliche Postfächer in der Datenbank beeinträchtigen konnte. In Exchange Server 2010 wurde der Schwerpunkt von Datenbank- zu Postfachtabellen verlagert, sodass Microsoft jetzt davon ausgeht, dass Beschädigungen auf Datenbankebenen nur noch sehr selten auftreten. Es ist jedoch durchaus möglich, dass früher nicht gekannte Beschädigungen auf Postfachebene vorkommen. Da die meisten Daten jetzt in Postfachtabellen gespeichert sind, reicht es jedoch einfach aus, ein Postfach von einer Datenbank zu einer anderen zu verschieben, um viele Probleme innerhalb dieser Tabellen zu bereinigen. Fehlerhafte Einträge werden auf dem Weg von der Quell- in die Zieldatenbank entfernt, und Probleme bei Sichten und Elementzählern werden behoben, wenn das neue Postfach in der Zieldatenbank erstellt wird. Angesichts dieser neuen Situation hat sich Microsoft eine andere Haltung gegenüber ISINTEG angeeignet. Anstatt ein Hilfsprogramm bereitzustellen, bei dem Sie eine Datenbank unter Umständen mehrere Stunden lang offline schalten müssen, um Wartungsarbeiten durchzuführen, hat Microsoft in Exchange Server 2010 SP1 eine Reihe neuer Cmdlets für die Postfachreparatur eingeführt. Damit können Administratoren Reparaturanforderungen für Postfächer erstellen, mit denen die gängigsten Ursachen für Beschädigungen in Sichten und Elementzählern abgedeckt werden. Das betrifft unter anderem folgende Probleme: 쐍 Beschädigungen im Suchordner (Postfach) 쐍 Unzutreffende Gesamtanzahl bei Ordnern (Postfach) 쐍 Rückgabe der falschen Inhalte in Ordnersichten (Postfach) 쐍 Replikationsstatus öffentlicher Ordner 쐍 Verifizierung der Sichten öffentlicher Ordner 쐍 Physische Beschädigungen bei öffentlichen Ordnern Die Reparatur-Cmdlets funktionieren nach einem ähnlichen Prinzip wie die für Verschiebe-, Importund Exportanforderungen. Auch hier erstellt ein Administrator eine Reparaturanforderung, die dann zur Verarbeitung durch den Informationsspeicher in eine Warteschlange gestellt wird. Der Informationsspeicher führt dann die notwendigen Reparaturen asynchron aus, während die Datenbank online bleibt, sodass sich die Benutzer nicht von ihren Postfächern abmelden müssen, während die internen Postfachstrukturen untersucht und korrigiert werden. Das Cmdlet New-MailboxRepairRequest erstellt eine Reparaturanforderung für ein Postfach, das Cmdlet New-PublicFolderDatabaseRepairRequest für eine Öffentliche-Ordner-Datenbank. Betrachten Sie dazu das folgende Beispiel: New-MailboxRepairRequest –Mailbox JSmith –CorruptionType FolderView
411
Der Informationsspeicher von Exchange Server 2010
Datenbankverwaltung
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Wenn Sie den Parameter -DetectOnly anhängen, meldet Exchange alle vorgefundenen Beschädigungen, ohne sie zu reparieren. Als weitere Beschädigungstypen für ein Postfach können Sie SearchFolder, AggregateCounts und ProvisionedFolder angeben. Dadurch werden Probleme mit Suchordnern, der Ordnerzählung und bereitgestellten Ordnern behoben. Wenn Sie mehrere gewünschte Reparaturen angeben, können Sie sie auch in einem Durchgang durchführen lassen: New-MailboxRepairRequest –Mailbox JSmith –CorruptionType FolderView, AggregrateCounts
Es ist auch möglich, alle Postfächer in einer Datenbank gleichzeitig zu überprüfen und sämtliche Fehler beheben zu lassen, die sich darin befinden: New-MailboxRepairRequest –Database DB1 –CorruptionType FolderView, SearchFolder, AggregateCounts
In Datenbanken für öffentliche Ordner können Sie nur eine Art von Beschädigung reparieren lassen, nämlich Fehler in der Replikatliste: New-PublicFolderDatabaseRepairRequest –Identity 'PFDatabase1'-CorruptionType ReplicaList
Wenn Sie eine neue Anforderung zur Postfachreparatur einreichen, gibt Exchange einen Bezeichner für die Aufgabe und den Namen des Servers zurück, der sich um die Anforderung kümmert. Dabei handelt es sich um den Postfachserver, auf dem zurzeit die aktive Kopie der Datenbank untergebracht ist. Den einzigen Beleg dafür, dass Exchange die Reparatur durchgeführt hat, finden Sie im Anwendungsprotokoll. Dort wird das Ereignis 10047 aufgezeichnet (siehe Abbildung 7.13), wenn Sie eine Reparaturanforderung auslösen, und das Ereignis 10048, wenn die Reparatur erfolgreich durchgeführt wurde und das Postfach keine Beschädigungen mehr aufweist. Beim Beginn einer Datenbankreparatur wird Ereignis 10059 protokolliert, und Ereignis 10062, wenn eine Beschädigungen gefunden und eine Korrektur vorgenommen wird (der Parameter -DetectOnly darf dazu nicht angegeben sein). Bevor alle Beschädigungen beseitigt sind und Ereignis 10048 gemeldet wird, müssen Sie unter Umständen mehrere Postfachreparaturen durchführen. Alle diese Ereignisse werden auf dem Server protokolliert, der die Reparaturanforderungen verarbeitet. Abbildg. 7.13
412
Angaben zu einer Postfachreparaturanforderung im Ereignisprotokoll
Insidertipp: Abbrechen von Reparaturaufträgen
Sie können einen Reparaturauftrag weder abbrechen noch seinen Status einsehen, aber wahrscheinlich wird Microsoft in zukünftigen Releases Vorkehrungen dafür treffen. Zurzeit besteht die einzige Möglichkeit, um eine Reparatur abzubrechen, darin, die Bereitstellung der Datenbank aufzuheben oder sie auf einen anderen Server zu verschieben. (Der Reparaturauftrag kann natürlich auch dadurch abbrechen, dass die Datenbank aufgrund eines Softwarefehlers abstürzt.) Durch solche Maßnahmen werden alle ausstehenden oder aktiven Reparaturaufträge in der Datenbank gelöscht. Damit die Leistung nicht beeinträchtigt wird, können Sie auf einem Server immer nur eine einzige Reparatur an einer ganzen Datenbank vornehmen. Allerdings lassen sich auf einem Server bis zu 100 einzelne Postfächer (in verschiedenen Datenbanken) parallel reparieren. Wenn es in einer Datenbankverfügbarkeitsgruppe Kopien der betroffenen Datenbank gibt, werden die Reparaturen an den Tabellen des Postfachs zusammen mit anderen Transaktionen an diese Kopien repliziert und im Anwendungsprotokoll auf dem Server protokolliert, auf dem die Reparatur erfolgt. Die Reparatur von Datenbanken öffentlicher Ordner läuft sehr ähnlich ab. Der einzige Unterschied besteht darin, dass die Reparatur in einer bestimmten Öffentlichen-Ordner-Datenbank stattfindet und mit dem Replikationsmechanismus für öffentliche Ordner übertragen wird. Insidertipp: Datenbankverschlüsselung
Windows Server 2008 ermöglicht den Einsatz von BitLocker, dem standardmäßigen Verschlüsselungsmechanismus für Windows. Können Sie daher Exchange-Datenbanken auf einem Gerät unterbringen, das mit BitLocker geschützt ist? Im Prinzip ist das möglich, aber dabei genießen Sie nur einen gewissen Schutz, der Unbefugte daran hindert, eine Datenbank zu kopieren und auf ein anderes System zu verlagern, wo er dann in aller Ruhe versuchen kann, in die Datenbank einzudringen und auf ihren Inhalt zuzugreifen. Der Microsoft-Support für Datenbanken, die mit BitLocker verschlüsselt sind, erfolgt nach den Richtlinien, die Sie unter http://technet.microsoft.com/de-de/library/dd421859.aspx finden. Exchange kann jedoch weiterhin Daten in Datenbanken auf mit BitLocker geschützten Geräten lesen und schreiben, da der Zugriff auf das Gerät über Windows erfolgt und Windows Zugang zu den geschützten Daten hat. Die Nützlichkeit des Schutzes in der Praxis ist jedoch zweifelhaft. Mir ist kein einziger Fall bekannt, in dem jemand eine Exchange-Datenbank gestohlen hat, um Zugriff auf Informationen zu gewinnen. Wenn jemand eine Festplatte mit Exchange-Datenbanken entwenden würde, wären die Daten darauf durch BitLocker hervorragend geschützt. Andererseits kann ich mich an viele Situationen erinnern, in denen Administratoren ihre Rechte dazu eingesetzt haben, um das Postfach eines anderen Benutzers zu öffnen und dessen Inhalte mit Outlook oder einem anderen Client zu durchsuchen. Ein solcher Zugriff lässt sich nicht dadurch verhindern, dass Sie die Datenbank auf einem verschlüsselten Laufwerk unterbringen. Außerdem enthält Windows Server 2008 (auch die R2-Version) einen Bug, durch den von Datenbankverfügbarkeitsgruppen verwendete WFC-Volumes irrtümlich als freigegebene Datenträger gemeldet werden, sodass BitLocker Festplatten mit Datenbanken von Datenbankverfügbarkeitsgruppen nicht verschlüsselt. Dieser Fehler wird in einem kommenden Service Pack hoffentlich behoben.
413
Der Informationsspeicher von Exchange Server 2010
Datenbankverwaltung
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Steuern benannter Eigenschaften Exchange stützt sich auf MAPI, und MAPI behandelt alle Aspekte von Nachrichten als Eigenschaften. Der Betreff ist eine Eigenschaft, die Empfänger sind eine Eigenschaft, Absendedatum und -uhrzeit sind Eigenschaften usw. In Exchange können bis zu 64 KB an Eigenschaften verwendet werden, die sich jeweils aus einem Namen und einem Wert zusammensetzen. Der Eigenschaftsname kann eine Zeichenkette oder ein numerischer Wert sein. Wie der Name lautet, spielt eigentlich keine Rolle, da die Eigenschaften nur für die interne Verwendung gedacht sind und nicht vom Client den Benutzern angezeigt werden. Mit einem Programm wie MFCMAPI können Sie sich die internen Eigenschaftennamen und die zugehörigen Werte ansehen. Als Client mit einem großen Funktionsumfang generiert Outlook eine Menge von Eigenschaften für Nachrichten, um die Daten festzuhalten, die für die vielen verschiedenen Funktionen erforderlich sind. MAPI teilt den verfügbaren 64-KB-Bereich von Eigenschaften in drei Abschnitte auf. Ein Teil wird für benannte MAPI-Eigenschaften verwendet (z.B. die für Outlook) und ein Teil für die Replikation, und 8 KB sind reserviert für benannte Nicht-MAPI-Eigenschaften. Ursprünglich waren Letztere für Entwickler gedacht, die in einer Nachricht auch einige anwendungsspezifische Daten speichern wollten. Wenn Sie beispielsweise eine Workflowanwendung schreiben, können Sie die von dem Programm erforderlichen Daten wie etwa den Genehmigungsstatus eines Elements als Eigenschaft des Elements übergeben. In der Anfangszeit von Exchange, als Programme wie Electronic Forms Designer zusammen mit dem Produkt ausgeliefert wurden, war das eine sinnvolle Vorkehrung. Benannte Eigenschaften führten größtenteils ein Schattendasein, bis mit Exchange Server 2000 die STM (Streaming-Datei) als ergänzende Datei zur JET-EDB-Datenbankbank eingeführt wurde. Darin wurden MIME- oder Nicht-MAPI-Daten gespeichert, die aus dem Internet in Exchange eingingen. Durch die Aufbewahrung aller MIME-Inhalte in einer eigenen Datei sollte Exchange besser damit umgehen können, wenn sie von Clients angefordert wurden. Die Komponente IMAIL verarbeitete Internetinhalte und teilte sie in die Eigenschaften auf, die in der EDB gespeichert wurden, und in den MIME-Inhalt, der in die STM wanderte. Die Eigenschaften wurden aus den üblicherweise bei einer Nachricht zu erwartenden Eigenschaften sowie allen vorhandenen X-Headern abgeleitet. Dieser Mechanismus funktionierte eine gewisse Zeit sehr gut. In Exchange Server 2007 verschwand die STM, doch IMAIL blieb erhalten, um X-Header in benannte Eigenschaften umzuwandeln. Ernste Probleme traten erst auf, als X-Header so häufig verwendet wurden, dass Exchange durch die Zuweisung dieser Header zu benannten Daten stark belastet wurde. Schließlich gibt es keinerlei Kontrolle über X-Header. Jeder kann seine eigenen X-Header nach Belieben erstellen und mit Nachrichten über das gesamte Internet senden, sodass Sie es schließlich mit Headern wie x-meineanwendungdaten zu tun bekommen. Exchange gibt sein Bestes, um diese X-Header bei der Ankunft auf einem Server zu verarbeiten und als benannte Eigenschaften zu speichern, aber dabei machte sich ein offensichtliches Problem deutlich bemerkbar: Jeder konnte eine Nachricht mit X-Headern im Umfang von 8 KB oder mehr erstellen und an einen Exchange-Empfänger senden, sodass der Informationsspeicher den Grenzwert für benannte Eigenschaften erschöpfte. In einem solchen Fall sandte Exchange alle nachfolgenden Nachrichten mit neuen X-Headern mit einer Fehlermeldung zurück, da die neuen Header nicht zu benannten Eigenschaften umgeschrieben werden konnten. Die Problembeschreibung in einem Unzustellbarkeitsbericht sah wie folgt aus: #550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: "MapiExceptionNamedPropsQuotaExceeded:16.18969:3D010000"
414
Wenn Exchange den Grenzwert für benannte Eigenschaften erreichte und überschritt, wurde das Problem auch in den Fehlermeldungen 9666, 9667, 9668 und 9669 im Anwendungsprotokoll festgehalten. Zusätzliche Probleme traten bei der Journalerstellung auf, da die Journaldatenbanken von Exchange Server 2007 mit Nachrichten aus verschiedenen Datenbanken innerhalb der Organisation umgehen mussten, die jeweils eigene benannte Eigenschaften verwenden mochten. Exchange Server 2007 speichert benannte Tabellen datenbankweise, weshalb eine einzelne Journaldatenbank sehr schnell überfordert sein kann. Schlimmstenfalls konnte ein Überschreiten des Kontingents für benannte Eigenschaften zu Problemen bei der fortlaufenden Clusterreplikation in Exchange Server 2007 führen und damit letzten Endes ein erneutes Seeding der Datenbank erforderlich machen. Eine Reihe von Lösungen wurden ausprobiert, wobei die folgenden am gängigsten waren: 쐍 Sie konnten die Systemregistrierung aktualisieren, um den Bereich für benannte Eigenschaften auf das in Exchange Server 2007 zulässige Maximum von 32 KB anzuheben. 쐍 Sie konnten den Transport-Agent HeaderFilterAgent installieren (Einzelheiten dazu finden Sie auf http://headerfilteragent.codeplex.com/Wikipage), um alle X-Header, die nicht in einer Liste mit genehmigten Headern stehen, aus eingehenden Nachrichten zu entfernen, sodass sich das Problem gar nicht erst zu einer Krise auswachsen kann. 쐍 Sie konnten Exchange dazu zwingen, den Bereich für benannte Eigenschaften zurückzusetzen, indem Sie neue Postfachdatenbanken erstellen und die Postfächer dorthin verschieben. Das waren jedoch allesamt nur kurzfristige Lösungen. Die wirkliche Lösung besteht darin, dafür zu sorgen, dass nicht mehr jeder willkürliche, unbekannte Korrespondent im Internet die Möglichkeit dazu hat, wertvolle Serverressourcen zu verbrauchen, und genau das hat Microsoft in Exchange Server 2007 SP1 RU9 (und höher) und später in Exchange Server 2010 getan. Die Lösung besteht darin, das Anlegen benannter Eigenschaften auf authentifizierte Absender und auf MAPI-Anwendungen zu beschränken, die den Regeln für die Eigenschaftenerstellung gehorchen. Außerdem speichert Exchange Server 2010 benannte Eigenschaften für ein Postfach und nicht mehr für eine ganze Datenbank. Sollte also irgendwann ein Problem mit dem Eigenschaftenkontingent auftreten, können Sie es dadurch lösen, dass Sie das Postfach in eine andere Datenbank verschieben. Durch die Verschiebeanforderung wird der Bereich für benannte Eigenschaften dieses Postfachs neu erstellt, wobei alle schleichenden Probleme wahrscheinlich gelöst werden. HINWEIS Es ist möglich, dass die strengeren Regeln von Exchange Server 2007 SP2 und Exchange Server 2010 einige vorhandene Anwendungen beeinträchtigen, die darauf angewiesen sind, X-Header-Informationen oder andere Eigenschaften zu übertragen. Wenn das der Fall ist, müssen Sie die Anwendung so umschreiben, dass sie die Eigenschaften nach den neuen Regeln mithilfe von MAPI oder Exchange-Webdiensten erstellt.
Defragmentieren von Datenbanken Wie wir bereits gesehen haben, führt Exchange Server 2010 eine fortlaufende Onlinedefragmentierung durch, um den höchstmöglichen Seitenzusammenhalt und die wirtschaftlichste Platzausnutzung in der Datenbank zu erreichen. Die Gesamtgröße der Datenbank wird durch die Defragmentierung nicht geändert, da die in diesem Vorgang freigegebenen Seiten wiederverwendet und dem Informationsspeicher verfügbar gemacht werden, um neue Elemente aufzunehmen. Eine Offlinedefragmentierung oder
415
Der Informationsspeicher von Exchange Server 2010
Defragmentieren von Datenbanken
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
einen Neuaufbau der Datenbank führen Sie durch, indem Sie die Datenbank offline schalten und dann ESEUTIL im Modus /D ausführen. Dadurch wird eine neue Kopie der Datenbank erstellt, indem alle Daten in der alten Datenbank gelesen und in die neue geschrieben werden. Je nach Systemleistung und Datenbankgröße kann eine solche Offline-Neuerstellung sehr lange dauern. Das Einzige, was Sie damit erreichen, ist jedoch nur die Freigabe ungenutzten Platzes an das Dateisystem. Bei der nicht sehr wirkungsvollen und auch nicht sehr rationellen Hintergrunddefragmentierung von Exchange Server 5.5 und Exchange Server 2000 wurde empfohlen, Datenbanken regelmäßig offline neu zu erstellen, um zu verhindern, dass sie auf absurde Größen anwachsen. Microsoft hat die Hintergrunddefragmentirung jedoch erheblich verbessert, weshalb es nur in außergewöhnlichen Umständen notwendig ist, eine Datenbank offline neu zu erstellen. Postfächer für die Studenten an Universitäten sind beispielsweise kurzlebiger als diejenigen in den E-Mail-Systemen von Unternehmen, da gewöhnlich jedes Jahr eine starke Fluktuation zu verzeichnen ist. Wenn Sie 10.000 Studentenpostfächer aus einer Datenbank löschen müssen, kann eine Neuerstellung sie erheblich verkleinern, sodass auch Sicherungen schneller ablaufen. Andererseits sind VSS-Sicherungen deutlich schneller als Bandsicherungen, weshalb die Größe der Datenbank heutzutage weniger stark ins Gewicht fällt. Sie können die Datenbank daher auch online lassen und mit neuen Postfächern füllen. Eine andere Situation, in der in früheren Versionen von Exchange eine Neuerstellung der Datenbank erforderlich war, liegt dann vor, wenn der Zeitraum für die Hintergrundwartung nicht ausreicht, um eine vollständige Defragmentierung durchzuführen, sodass die Datenbank schließlich mit unbenutzten Seiten aufgebläht ist. Da Exchange Server 2010 jedoch eine fortlaufende Onlinedefragmentierung durchführt, ist auch das kein Argument mehr, um eine Offlineneuerstellung zu rechtfertigen. Anders als in früheren Versionen von Exchange werden keine Ereignisse protokolliert, wenn die Onlinedefragmentierung beginnt und endet, und es gibt auch keine Berichte über den leeren Platz, der nach einem Defragmentierungsdurchgang in einer Datenbank zur Verfügung steht. Das ist angesichts der permanenten Natur der Onlinedefragmentierung von Exchange Server 2010 auch nur logisch, denn sie beginnt, wenn der Informationsspeicher eine Datenbank bereitstellt, und endet, wenn der Speicherdienst heruntergefahren wird. Das Fehlen der Ereignisse, die Beginn und Ende der Defragmentierung markieren, bedeutet jedoch nicht, dass Sie keinerlei Hinweise auf den Fortschritt der Defragmentierung mehr haben. Microsoft hat dem Systemmonitor eine Reihe neuer Leistungsindikatoren hinzugefügt. Starten Sie den Systemmonitor und fügen Sie MSExchange-Datenbank/ Instanzen/E/A: Datenbankleseoperationen/Sek zu dem Satz der Indikatoren hinzu, die beobachtet werden. Der Grad an Aktivität hängt von der Systemlast ab. Wenn das System nur leicht belastet ist, stellen Sie eine intensivere Wartungstätigkeit fest als zu Zeiten, in denen die Benutzer sehr aktiv sind. Mit dem Cmdlet Get-MailboxDatabase können Sie sich immer noch einen Eindruck davon verschaffen, wie viel leerer Platz in einer Datenbank zur Verfügung steht. Um Leistungseinbußen zu vermeiden gibt dieses Cmdlet normalerweise nur die statischen Informationen über eine Datenbank zurück, die in Active Directory zu finden sind. Um auch die internen Datendankdaten abzurufen, müssen wir die Exchange-Verwaltungsshell dazu zwingen, den Informationsspeicher aufzurufen. Dazu übergeben wir den Parameter -Status: Get-MailboxDatabase –Identity 'DB1' –Status | Select Name, DatabaseSize, AvailableNewMailboxSpace
Diese Überprüfung können Sie auch für sämtliche Postfachdatenbanken in der Organisation durchführen. Bis zur vollständigen Verarbeitung dieses Befehls kann einige Zeit vergehen, da die Verwaltungsshell den Status jeder einzelnen Datenbank auf sämtlichen Servern ermitteln muss. Im folgenden Beispiel rufen wir die Daten ab und sortieren sie nach der Datenbankgröße:
416
Get-MailboxDatabase –Status | Sort-Object DatabaseSize –Descending | Format-Table Name, DatabaseSize, AvailableNewMailboxSpace Name
DatabaseSize
AvailableNewMailboxSpace
-------
----------------
---------------------------
MBDatabase3
1.57 GB (1,686,175,744 bytes)
121.1 MB (126,943,232 bytes)
MBDatabase1
1.195 GB (1,283,522,560 bytes)
69.44 MB (72,810,496 bytes)
IT Department
936.1 MB (981,532,672 bytes)
6.063 MB (6,356,992 bytes)
VIP Data
856.1 MB (897,646,592 bytes)
176.1 MB (184,647,680 bytes)
MBDatabase2
736.1 MB (771,817,472 bytes)
628.4 MB (658,931,712 bytes)
Dublin Users
384.1 MB (402,718,720 bytes)
90.22 MB (94,601,216 bytes)
Sales
352.1 MB (369,164,288 bytes)
83.59 MB (87,654,400 bytes)
PR
264.1 MB (276,889,600 bytes)
108 MB (113,278,976 bytes)
Operations
264.1 MB (276,889,600 bytes)
117.5 MB (123,207,680 bytes)
Die genannte Datenbankgröße entspricht ziemlich genau der tatsächlichen Dateigröße auf der Festplatte. Die Angabe unter AvailabeNewMailboxSpace besagt, wie viel ungenutzter Platz in der Datenbank für neue Postfächer zur Verfügung steht. Wie Sie sehen, ist in jeder Datenbank ein anderer Prozentsatz an freiem Platz vorhanden, was jeweils von der Aktivität in der Datenbank abhängt. In einer Datenbank mit einem Satz von Postfächern, die über längere Zeit hinweg unverändert geblieben sind, steht ein geringerer Anteil an freiem Platz zur Verfügung als in einer Datenbank, aus der einige Postfächer zu einer anderen verschoben wurden. Besonders auffällig ist das, wenn Sie die Angaben für IT Department (0,64% frei) und MBDatabase2 (85,3% frei) vergleichen. Mit der Zeit werden sich die prozentualen Anteile an freiem Platz in den beiden Datenbanken angleichen, da Benutzeraktivitäten Platz verbrauchen. Stehen in einer Datenbank mehr als 15% Platz zur Verfügung, kann das an einer nicht vollständig abgeschlossenen Wartungsaufgabe, an einer vor kurzem stattgefundenen Löschung vieler Postfächer oder an anderen Gründen liegen. AvailableNewMailboxSpace – nur ein Richtwert
Der Wert unter AvailableNewMailboxSpace ist keine genaue Angabe für den freien Platz in der Datenbank, da dafür nur die Seiten berücksichtigt werden, die unmittelbar zur Zuweisung neuer Postfächer zur Verfügung stehen. Das betrifft nur den Platz in der Stammstruktur der Datenbank, nicht aber freie Seiten in Postfach- oder Indextabellen. Allerdings bildet dieser Wert eine gute Abschätzung dafür, wie viel ungenutzter Raum in der Datenbank verfügbar ist. Jenseits dieser internen Strukturen verwendet Exchange Server 2010 in den Datenbankdateien jeweils Dateiblöcke von standardmäßig 8 KB, um mehr Festplattenplatz von Windows anzufordern. In Exchange Server 2010 SP1 wird die Blockgröße auf 128 MB angehoben. Außerdem werden auch die Blöcke für die passiven Datenbankkopien in Datenbankverfügbarkeitsgruppen so verändert, dass sie ebenfalls 128 MB umfassen. Diese Änderung ist umfassender, als es erscheint, denn in der RTM-Version wird für passive Kopien keine feste Blockgröße verwendet. Stattdessen wächst die Datenbank dort jeweils um das mindestens erforderliche Maß. Der Wechsel zu größeren Dateiblöcken und die Gleichstellung von aktiven und passiven Kopien in dieser Hinsicht verringert die Gefahr der Fragmentierung von Datenbanken auf der Festplatte.
417
Der Informationsspeicher von Exchange Server 2010
Defragmentieren von Datenbanken
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Verwenden von ESEUTIL ESEUTIL ist ein nützliches, aber auch gefährliches Hilfsprogramm. Seine Nützlichkeit zeigt sich darin, dass Sie damit einige maschinennahe Probleme in einer Datenbank lösen können (allerdings keine grundlegenden Beschädigungen aufgrund von Hardwarefehlern). Gefährlich ist es, da manche Administratoren und Autoren behaupten, es sei eine gute Sache, ESEUTIL »nur für alle Fälle« regelmäßig für Exchange-Datenbanken auszuführen. Diese Haltung hat sich in den 1990er Jahren in den Köpfen der Verantwortlichen festgesetzt. Das war freilich zu einer Zeit, als Exchange-Datenbanken nicht so stabil und zuverlässig waren, wie sie heute sind – und zwar schon seit Exchange Server 2003. Früher bestand der Hauptgrund für den Einsatz von ESEUTIL darin, Festplattenplatz von einer Datenbank zurückzugewinnen. Exchange verhielt sich, was das Datenbankwachstum anging, wie ein Mastschwein, doch die Wiederverwendung von Seiten, die nach dem Löschen von Nachrichten freigegeben wurden, funktionierte nicht sehr gut. Es konnte gut sein, dass eine Datenbank von 10 GB (was zu jener Zeit viel war) nur 7 GB Postfachdaten enthielt. Um dem System die restlichen 3 GB an ungenutztem Speicherplatz zurückzugeben, mussten Sie die Datenbank mit ESEUTIL neu erstellen. Festplatten waren klein und teuer, weshalb es schon wichtig war, 3 GB zurückzugewinnen. Selbst wenn Sie die Datenbank über das Wochenende offline schalten mussten, um die Neuerstellung vorzunehmen, lohnte sich daher der Aufwand. Doch heute ist die Situation anders. Die Festplatten sind größer und erheblich billiger, und Exchange kann die Seiten innerhalb der Datenbanken sehr viel besser wiederverwenden. Es stimmt zwar, dass Softwarebugs gelegentlich ein übermäßiges Wachstum einer Datenbank hervorrufen, aber diese Fehler werden nach und nach ausgemerzt. Exchange wurde mit zusätzlichen Sicherheitsmaßnahmen versehen, um ein plötzliches Anschwellen der Datenbanken zu verhindern. In diesem Buch gebe ich Ihnen keine umfassende Beschreibung der Verwendung von ESEUTIL. Dieses Hilfsprogramm gibt es schon seit den Anfangstagen von Exchange, weshalb es in anderen Büchern, Blogs und auf TechNet ausführlich behandelt wird. Ich weise nur dort auf ESEUTIL hin, wo Sie das Programm wirklich benötigen, z.B. bei der Überprüfung einer Wiederherstellungsdatenbank vor der Bereitstellung (siehe Kapitel 9). Insidertipp: Keine Neuerstellung von Datenbanken mit ESEUTIL
Fazit ist, dass Sie eine Datenbank nicht mehr mit ESEUTIL neu erstellen müssen, es sei denn, Sie werden vom Microsoft-Support dazu aufgefordet. Wenn Ihnen irgendjemand weismachen will, dass es eine gute Idee wäre, in Exchange regelmäßig ESEUTIL auszuführen, um Datenbanken neu zu erstellen, sollten Sie darauf genauso reagieren wie auf die Behauptung, eine monatliche Darmspülung wäre das ideale Mittel für eine gesunde Gesichtsfarbe. Diejenigen, die eine Datenbank mit ESEUTIL neu erstellen möchten, nur um etwas Speicherplatz zurückzugewinnen, sollten bedenken, dass der aktuelle Satz der Transaktionsprotokolle durch diesen Vorgang ungültig gemacht wird. Durch die Neuerstellung wird die interne Struktur der Datenbank umgeformt, sodass keine der Transaktionen in den Protokollen mehr angewandt werden kann, wenn es notwendig werden sein sollte, Transaktionen durch Wiedereinspielen wiederherzustellen. Auf einem Standardserver ist das kein Problem, da Sie unmittelbar nach der Neuerstellung eine vollständige Datensicherung durchführen können. In einer Datenbankverfügbarkeitsgruppe liegt der Fall jedoch anders, da die Transaktionsprotokolle hier den Replikationsmechanismus für die Datenbankkopien bilden. Wenn Sie eine aktive Datenbank neu erstellen, setzen Sie sie letzten Endes zurück, sodass Sie anschließend für alle Kopien ein erneutes Seeding durchführen müssen. Das ist wirklich keine empfehlenswerte Vorgehensweise!
418
Statistiken der Datenbanknutzung Das neue Cmdlet Get-StoreUsageStatistics von Exchange Server 2010 dienst als Diagnosehilfe für Administratoren, die sich über die Speicherleistung eines bestimmtes Postfachs, einer Datenbank oder eines Servers Sorgen machen. Es ruft Daten über die Speicheraktivität für ein bestimmtes Postfach oder für alle Postfächer in einer Datenbank oder auf einem Server ab und meldet, welcher Betrag an Serverzeit während der letzten zehn Minuten für Speichervorgänge aufgewendet wurde. Das Cmdlet analysiert die Postfächer mit dem höchsten TimeInServer-Wert der letzten zehn Minuten mithilfe der in jeder Sekunde erfassten Leistungsdaten. Im folgenden Beispiel werden die Daten für die Aktivität in einer bestimmten Datenbank abgerufen. In diesem Fall sehen wir, dass der höchste Bedarf während der Stichprobe 3 vorherrschte (vor drei Minuten), da zu diesem Zeitpunkt Vorgänge für drei verschiedene Postfächer zu verzeichnen waren. Das Feld TimeInServer enthält ein relatives Maß dafür, wie stark ein Postfach einen Server beansprucht. Der Wert wird aus der Gesamtzeit berechnet, die für die Verarbeitung von synchronen und asynchronen Anforderungen eines Postfachs an den Informationsspeicher aufgewendet wird, und ist daher ein umfassendes Maß, das sämtliche einzelnen Leistungsaspekte berücksichtigt. Wenn die Tätigkeit für ein Postfach beispielsweise E/A-intensiv ist, sind die Wartezeiten für das Postfach höher, was den Wert für TimeInServer in die Höhe treibt. Auch eine starke Belastung der CPU erhöht TimeInServer, da der Informationsspeicher mehr Zeit für die Verarbeitung von Anforderungen für das Postfach aufwenden muss. Wenn Sie sich die folgenden Daten ansehen, können Sie erkennen, dass der Benutzer, der die stärkste Aktivität hervorgerufen hat, »Akers, Kim« in der vierten Stichprobe war. Für die zehnminütige Erfassungszeit liegt ihr TimeInServer-Betrag von 3235 etwa doppelt so hoch wie der des Postfachs mit dem zweithöchsten Wert. Get-StoreUsageStatistics –Database 'VIP Data' DigestCategory --------------TimeInServer TimeInServer TimeInServer TimeInServer TimeInServer TimeInServer TimeInServer TimeInServer TimeInServer TimeInServer TimeInServer TimeInServer TimeInServer
SampleId ----------0 1 1 2 3 3 3 4 5 6 7 8 9
DisplayName ---------------Mailbox – Akers,Kim Mailbox – Smith, John ... Mailbox - Online Archi... Mailbox – EMEA Help Desk. Mailbox – Ruth, Andy Mailbox – Andersen, Ch... Mailbox - Online Archi... Mailbox – Akers, Kim Mailbox – Redmond, Tony Mailbox – Shen, Alan Mailbox – Sousa, Luis Mailbox - Redmond, Tony Mailbox – Park, Dan
TimeInServer -----------485 32 0 1163 16 94 16 3235 1657 1510 391 905 297
Um Statistiken über alle Datenbanken auf einem Server zu erhalten, verwenden Sie einen Befehl wie den folgenden: Get-StoreUsageStatistics –Server 'ExServer1'
419
Der Informationsspeicher von Exchange Server 2010
Statistiken der Datenbanknutzung
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Beachten Sie, dass Exchange nur Statistiken über bereitgestellte Datenbanken zurückgibt. Datenbankkopien werden bemerkt, es werden aber keine Statistiken darüber angezeigt. Das ist sinnvoll, da die Postfächer ja auch keine Verbindungen zu diesen Kopien aufnehmen können. In der Ausgabe für eine Datenbank oder einen Server kann ein einzelnes Postfach mehrfach vorkommen. Um sich die Aktivität und ausführliche Statistiken für ein Postfach anzusehen, übergeben Sie dem Cmdlet dessen Namen: Get-StoreUsageStatistics –Identity 'Akers, Kim' DigestCategory SampleId SampleTime DisplayName TimeInServer TimeInCPU ROPCount PageRead PagePreread LogRecordCount LogRecordBytes LdapReads LdapSearches ServerName DatabaseName
: : : : : : : : : : : : : : :
TimeInServer 1 5/23/2010 2:39:10 AM Mailbox – Akers, Kim 424 79 222 0 0 975 467303 1 0 ExServer1 VIP Data
Neben dem Wert für TimeInServer werden dabei folgende Daten angezeigt: 쐍 TimeInCPU Die CPU-Zeit in Millisekunden, die für Operationen für das betreffende Postfach aufgewendet wird. Die Stichproben werden jeweils für einen Zeitraum von einer Minute aufgenommen, doch wenn der Server über mehrere Prozessoren verfügt, kann dieser Wert mehr als 60 Sekunden betragen. Der Timer ist sehr einfach gehalten und wird immer dann ausgelöst, wenn die CPU Zeit für einen Thread bereitstellt, der Operationen für das Postfach durchführt. 쐍 ROPCount Die Anzahl der Remoteoperationen (Clientoperationen), die während des Erfassungszeitraums an dem Postfach durchgeführt werden. 쐍 PageRead Die Anzahl von nicht im Cache befindlichen Seiten, die für das Postfach gelesen werden müssen. 쐍 PagePreRead Die Anzahl der Seiten, die für das Postfach vorab gelesen werden müssen. 쐍 LogRecordCount Die Anzahl der Protokolleinträge, die während des Erfassungszeitraums für dieses Postfach geschrieben werden müssen. Zusammen mit TimeInServer bietet dieser Wert einen guten Anhaltspunkt für die Menge an Aktivitäten, die der Informationsspeicher für Postfachoperationen durchführen muss. 쐍 LogRecordBytes
LogRecordCount in Bytes umgerechnet.
쐍 LDAPReads Die Anzahl asynchroner LDAP-Lesevorgänge (Lightweight Directory Access Protocol) für Postfachoperationen. 쐍 LDAPSearches Die Anzahl von LDAP-Suchvorgängen für das Postfach.
420
Die gemessenen Daten werden nach zehn Minuten gelöscht. Wenn Sie Get-StoreUsageStatistics also zehn Minuten nach der letzten Aufzeichnung von Postfachaktivitäten ausführen, werden keine Ergebnisse zurückgegeben. Waren während der letzten zehn Minuten weniger als 25 Benutzer aktiv, werden nur diese Benutzer aufgeführt.
Transaktionsprotokolle Transaktionsprotokolle sind ein grundlegender Mechanismus zur Erfassung und Aufzeichnung der Transaktionen, die in einer ESE-Datenbank vorkommen. Um die Forderungen nach Unteilbarkeit, Konsistenz, Isolation und Dauerhaftigkeit (Atomicity, Consistency, Isolation, Durability oder kurz ACID) zu erfüllen, verwendet ESE für Transaktionen einen Zwei-Phasen-Commit. Eine Transaktion ist als eine Folge von Änderungen an Datenbankseiten definiert, die ESE als eine einzelne logische Einheit betrachtet. Alle Änderungen müssen dauerhaft gespeichert werden, bevor die Transaktion abgeschlossen ist und in die Datenbank übernommen wird. Beispielsweise erfolgt das Eintreffen einer neuen Nachricht im Posteingang eines Benutzers in Form mehrerer Änderungen an verschiedenen Seiten. So kann es sein, dass der Seitenheader eine Seite einnimmt, enthält die Inhalte mehrere weitere oder dass die Nachricht an mehrere Benutzer einschließlich des Absenders geht, so dass sie in verschiedenen Ordnern der Datenbank auftaucht. Um die Transaktion speichern zu können, muss ESE sämtliche Änderungen an allen betroffenen Seiten durchführen können. Wenn das nicht möglich ist, verwirft ESE die gesamte Transaktion. Alle Transaktionen, die in einer Postfachdatenbank auftreten, werden in Transaktionsprotokollen erfasst. Das gilt auch für Systemtransaktionen im Rahmen von Aufräumarbeiten oder der Hintergrundwartung. Der Informationsspeicher hält die Transaktionen asynchron fest, um sie für einen möglichst effizienten Commit in der Datenbank bündeln zu können, weshalb es gut möglich ist, dass die Benutzer Nachrichten im Arbeitsspeicher lesen und schreiben, ohne dass der Informationsspeicher jemals auf die Festplatte zugreifen muss, um Daten abzurufen. HINWEIS Der Hauptvorteil des von Exchange verwendeten vorausschauenden Schreibens (Write-Ahead) ist ein schneller, rationeller und sicherer Datenzugriff. Es ist wichtig, dass ExchangeAdministratoren wissen, wie dies funktioniert.
Protokollsätze ESE behandelt die Transaktionsprotokolle wie ein großes logisches Protokoll, das der Informationsspeicher zur einfacheren Handhabung in einen Satz von Generationen unterteilt. Jedes Protokoll steht für eine einzelne Generation innerhalb des Protokollsatzes und wird mit einer laufenden Generationsnummer bezeichnet. Eine einzelne Nachricht, die mehrere sehr große Anhänge enthält, kann durchaus mehrere Protokolldateien umfassen. ESE kümmert sich automatisch um die Aufteilung der Daten auf die Protokolle. Wenn die Transaktion erneut in die Datenbank eingespielt werden muss, kann ESE die Daten auch wieder aus den verschiedenen Protokollen zu einer einzigen Nachricht mit Anhängen zusammenführen. Auf einem stark ausgelasteten Server fließen täglich Millionen von Transaktionen in die Protokolle, weshalb es nicht ungewöhnlich ist, wenn jeden Tag Hunderte, wenn nicht sogar Tausende von Protokollen erstellt werden.
421
Der Informationsspeicher von Exchange Server 2010
Transaktionsprotokolle
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Neben den Benutzertätigkeiten zeichnen die Transaktionsprotokolle auch Hintergrund- und Wartungsvorgänge auf, z.B. das Senden von Unzustellbarkeitsberichten, das Verschieben von Postfächern, den Import von Postfachdaten aus anderen Messagingsystemen usw. Jede Operation, durch die Daten in der Datenbank geändert werden, in sie hinein- oder aus ihr herausfließen, wird in einem Transaktionsprotokoll festgehalten. Wenn Sie abschätzen möchten, wie viele Transaktionsprotokolle ein Server am Tag aufstellt, können Sie als Faustregel 25 MB an Daten (also 25 Protokolle) pro Benutzer und pro Arbeitstag (acht Stunden) ansetzen. In seinem Blog erklärt das Exchange-Team, dass die Anzahl der pro Benutzer und Tag erstellten Protokolle je nach der Anzahl der gesendeten und empfangenen Nachrichten und deren durchschnittlicher Größe zwischen 7 und 42 schwankt. Die Zahl von 25 bildet also einen vernünftigen und auch bewährten Mittelwert. Bei dieser Faustregel wird vorausgesetzt, dass Sie die Transaktionsprotokolle wieder vom Server entfernen, indem Sie täglich vollständige Sicherungen anlegen. Insidertipp: Transaktionsprotokolle sollten 1 MB groß sein
Die Größe der Transaktionsprotokolle beträgt jetzt 1 MB, also deutlich weniger als die 5 MB, die bei allen früheren Versionen von Exchange außer Exchange Server 2007 üblich waren. Die neue Größe von 1 MB wurde gewählt, um die Replikation zwischen den Servern zu erleichtern, damit Exchange schnell alle Datenabweichungen ausbügeln kann, die aufgrund einer Unterbrechung der Replikation aufgetreten sein mögen. Die geringere Protokollgröße verringert außerdem die Wahrscheinlichkeit für Datenverluste, wenn eine Protokolldatei nicht kopiert werden kann oder aufgrund von Speicher- oder anderen Hardwarefehlern beschädigt ist. Weist eine Protokolldatei eine andere Größe auf als die vorgesehenen 1 MB, ist das ein Zeichen dafür, dass sie aus irgendeinem Grund beschädigt ist. In einem solchen Fall sollten Sie den Informationsspeicherdienst beenden und die Ereignisprotokolle, Datenbanken und Festplatten auf Fehler überprüfen. Ein Transaktionsprotokollsatz für eine Datenbank wird mit einem Präfix, gefolgt von einer achtstelligen Hexadezimalzahl bezeichnet, die die Generationsnummer des Protokolls angibt. Für eine Datenbank können vier Milliarden Protokolldateien angelegt werden, bevor der Informationsspeicher Dateinamen wiederverwenden muss. Das Präfix für die erste Datenbank auf einem Server lautet E00, das für die zweite E01, für die dritte E02 usw. Das aktuelle Protokoll für die erste Datenbank heißt also E00.log. Für die Transaktionsprotokolle aller Datenbankkopien in einer Datenbankverfügbarkeitsgruppe wird dasselbe Präfix verwendet. Es kann daher auf einem Server mehrere Protokollsätze mit demselben Präfix geben. TIPP Es besteht keine Gefahr dabei, dass die Dateien dieselben Dateinamen tragen, da die einzelnen Protokollsätze in verschiedenen Verzeichnissen untergebracht sind. Exchange kann nicht durcheinanderbringen, welches Protokoll zu welcher Datenbank gehört, da der Header eines Transaktionsprotokolls jeweils einen Bezeichner enthält, der das Protokoll mit der richtigen Datenbank verknüpft. Datenbanken für öffentliche Ordner unterhalten ihren eigenen Satz von Transaktionsprotokollen. Darum werden dieselben Arten von Transaktionen (Hinzufügungen, Änderungen und Löschungen) erfasst wie für Elemente in Postfachdatenbanken, aber sie werden separat davon geführt. Jedes Mal, wenn der Informationsspeicher startet und die Datenbanken bereitstellt, überprüft er sie auf Konsistenz. Ein Flag im Datenbankheader zeigt an, ob die Datenbank konsistent oder inkonsistent ist, was davon abhängt, ob der Informationsspeicher in der Lage war, die Datenbank beim letzten Mal ordnungsgemäß herunterzufahren und damit alle Daten aus dem Cache auf die Festplatte zu schreiben und für alle ausstehenden Transaktionen ein Commit durchzuführen. 422
Eine inkonsistente Datenbank weist ausstehende Transaktionen auf, für die der Informationsspeicher noch keinen Commit durchgeführt hat. Wenn der Informationsspeicher eine Datenbank als inkonsistent einschätzt, versucht er die ausstehenden Transaktionen im Transaktionsprotokoll zu lesen und erneut in der Datenbank wiederzugeben, damit sie konsistent wird. Dieser Vorgang wird als »weiche Wiederherstellung« bezeichnet. So etwas kommt auch heute noch hin und wieder vor, wenn auch nicht so häufig wie in früheren Versionen von Exchange. Gewöhnlich ist dies der Fall, wenn ein Software- oder Hardwarefehler zu einer abrupten Beendigung von Exchange geführt hat. In den meisten Fällen bekommen Sie gar nichts davon mit, dass der Informationsspeicher eine weiche Wiederherstellung durchführt. Dazu müssen Sie sich schon das Ereignisprotokoll ansehen, um herauszufinden, ob der Informationsspeicher nach dem Bereitstellen einer Datenbank Transaktionen wiedergegeben hat. Wenn Sie sich nicht sicher sind, ob eine Datenbank konsistent ist, führen Sie ESEUTIL mit dem Parameter /MH aus, um den Datenbankheader zu überprüfen. Um ausdrücklich sicherzustellen, dass eine Datenbank konsistent ist, haben Sie nur die Möglichkeit, entweder den Informationsspeicherdienst herunterzufahren (wodurch alle Datenbanken konsistent gemacht werden) oder die Bereitstellung einer einzelnen Datenbank in der Exchange-Verwaltungsshell oder mit dem Cmdlet Dismount-Database aufzuheben. Dabei sorgt der Informationsspeicher dafür, dass für alle ausstehenden Transaktionen in seinem Cache ein Commit ausgeführt wird, bevor er die Datenbank schließt. Auch wenn Sie eine vollständige Sicherung vornehmen, ist die Datenbank anschließend konsistent – aber nur für kurze Zeit, denn da sie online bleibt, fährt der Informationsspeicher unmittelbar danach damit fort, weitere Transaktionen zu verarbeiten. Transaktionsprotokolle sind auf zwei Weisen mit den zugehörigen Datenbanken verknüpft. Erstens schreibt ESE beim Erstellen der Datei einen eindeutigen Bezeichner (eine Signatur) in das Protokoll. Diese Protokollsignatur muss mit der Signatur der zugehörigen Datenbank übereinstimmen, damit ESE die Protokollinhalte zur Wiederherstellung von Transaktionen heranziehen kann. Zweitens zeichnet ESE den Pfad zu dem Verzeichnis mit der Datenbank im Transaktionsprotokoll auf. Die Angaben der Bezeichner und Speicherorte können Sie ermitteln, indem Sie ESEUTIL mit dem Parameter /ML ausführen. Dadurch werden die Headerinformationen eines Transaktionsprotokolls wie im folgenden Beispiel ausgegeben: Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Base name: e01 Log file: e0100000736.log Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating FILE DUMP mode... Base name: e01 Log file: e0100000736.log lGeneration: 1846 (0x736) Checkpoint: NOT AVAILABLE creation time: 11/20/2009 01:03:23 prev gen time: 11/20/2009 00:26:26 Format LGVersion: (7.3704.16.1) Engine LGVersion: (7.3704.16.1)
423
Der Informationsspeicher von Exchange Server 2010
Transaktionsprotokolle
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Signature: Create time:11/06/2009 00:06:00 Rand:466930790 Computer: EnvSystemPath: C:\Exchange\VIP\ EnvLogFilePath: C:\Exchange\VIP\ Env Log Sec size: 512 Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers) ( off, 552, 27600, 15960, 27600, 2048, 2048, 24572) Using Reserved Log File: false Circular Logging Flag (current file): off Circular Logging Flag (past files): off Checkpoint at log creation time: : (0x733,8,0) 1 C:\Exchange\VIP\VIP.edb dbtime: 823366 (0-823366) objidLast: 4116 Signature: Create time:11/06/2010 00:06:00 Rand:466892842 Computer: MaxDbSize: 0 pages Last Attach: (0x4CF,9,86) Last Consistent: (0x 4CE,8,1F) Last Lgpos: (0x736,34,0) Number of database page references: 304 Integrity check passed for log file: e0100000736.log Operation completed successfully in 0.156 seconds.
Transaktionen, Puffer und Commit Wenn ein Client eine Nachricht an den Informationsspeicher überträgt, geht ESE in einer genau festgelegten Reihenfolge vor, um die Transaktion anzuwenden und die neue Nachricht per Commit in den Informationsspeicher zu übernehmen. Dieselbe Reihenfolge gilt auch für andere Transaktionen, z.B. für Lösch- und Verschiebevorgänge. Als Erstes erstellt ESE einen Zeitstempel, wozu die im Datenbankheader vorgehaltene interne Zeit herangezogen wird (die »DB-Zeit«, die in einem 8-ByteWert gespeichert wird). Um eine Seite ändern zu können, muss ESE eine neue DB-Zeit auf der Grundlage des jetzigen Werts im Header berechnen. Anschließend schreibt ESE die Datensätze, die sich durch die Transaktion ändern, in das aktuelle Transaktionsprotokoll. Danach werden die entsprechenden Seiten in der Datenbank geändert. Die Seitenänderungen finden in einem Cache für »modifizierte Seiten« im Arbeitsspeicher statt, weshalb ESE zunächst die entsprechenden Seiten von der Datenbank auf der Festplatte abrufen muss. Wenn ein Client einen Vorgang durchführt, durch den Datenbankseiten geändert erden, geht ESE in folgender Reihenfolge vor: 쐍 Die Datenbankseite wird aus dem ESE-Cache im Arbeitsspeicher abgerufen. Falls sie sich dort nicht befindet, ruft ESE sie von der Festplatte ab. 쐍 Es wird ein Protokolleintrag für den Abruf der Seite und die Aktualisierung des Caches erstellt.
424
쐍 ESE ändert die Datenbankseite und markiert sie als modifiziert. Die Seite wird nicht sofort auf die Festplatte geschrieben, da sie durch nachfolgende Transaktionen noch weiter verändert werden könnte. Der Versionsspeicher verfolgt modifizierte Seiten nach, damit die Änderungen bei einer unerwarteten Beendigung der Datenbanksitzung nicht verloren gehen. Der Versionsspeicher ist eine interne Komponente, die im Arbeitsspeicher eine Liste der Änderungen an der Datenbank führt. Der Informationsspeicher greift beim Rollback von Transaktionen und zum Auflösen von Konflikten zwischen mehreren Änderungsversuchen an einer Seite auf diese Liste zurück. 쐍 Die Datenbankseite wird mit dem Eintrag im Cache verknüpft, damit ESE die Seite nicht vor dem Protokolleintrag auf die Festplatte schreibt. Für Änderungen, die erfolgreich im Transaktionsprotokoll erfasst sind, führt ESE einen Commit durch, um sie in die Datenbank zu übernehmen. 쐍 Wenn der Protokollpuffer voll ist (er fasst 1 MB) oder wenn für die Transaktion ein Commiteintrag protokolliert wird, zeichnet ESE die geänderte Seite im aktuellen Transaktionsprotokoll auf, um sie zu übernehmen. Dazu ist es eventuell erforderlich, eine neue Protokollgeneration zu erstellen. Falls die Datenbank repliziert wird, setzt Exchange Server 2010 SP1 an dieser Stelle die Blockreplikation in die Tat um. Weitere Informationen darüber erhalten Sie in Kapitel 8. 쐍 Die modifizierten Seiten werden schließlich aus dem Arbeitsspeicher entfernt und in die Datenbank geschrieben. 쐍 Der Prüfpunkt wird einen Schritt vorverlegt. Um die Konsistenz der Daten zu schützen, gilt für ESE die eiserne Regel, dass Änderungen erst dann in die Datenbank geschrieben werden, wenn die Transaktionen im Transaktionsprotokoll mit Commit abgeschlossen sind. Wenn Sie sich die einzelnen Schritte ansehen, aus denen eine vollständige Transaktion besteht, können Sie erkennen, dass der letzte Schritt der Commit der Transaktion auf der Festplatte ist. Der letzte Befehl in Abbildung 7.14 ist der Commit für die als ESE-Sitzung 8 bezeichnete Transaktion. Die vorherigen Schritte in dieser Sitzung leiten die Transaktion ein und fügen einige Daten ein, um eine vorhandene Seite zu ersetzen. Der Commit ist eine synchrone Operation, d.h., in dieser Sitzung kann keine andere Transaktion durchgeführt werden, bevor die jetzige vollständig auf die Festplatte geschrieben ist. Durch die Aktivierung des Write-Back-Caches auf der Festplatte für die Transaktionsprotokolle wird die Leistung verbessert, da die Schreibvorgänge im Arbeitsspeicher des Controllers abgeschlossen werden können, sodass die Wartezeit für die nächste Transaktion verkürzt wird. Der Controller ist anschließend dafür verantwortlich, die Daten tatsächlich auf die Festplatte zu schreiben. Abbildg. 7.14
Daten in einem Transaktionsprotokoll Sitzungs-Nr. Begin Replace Delete Insert Insert Insert Insert Commit
Seite
Seitenoffset
Länge Daten
(8) 27223(8,[1477:6],8,8,8)01 00 00 00 70 03 00 00 27150(8,[992:0]) 27224(9,[1095:7],255)7F 14 2F 6F A8 1C ... 27225(5,[702:8],255)80 D7 74 C9 68 6C ... 27226(8,[696:1],255)80 94 26 BC B5 9B B5 ... 27227(8,[735:8],255)80 D7 74 C9 68 6C 17 ... (8)
Zeitstempel
425
Der Informationsspeicher von Exchange Server 2010
Transaktionsprotokolle
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Jeder Protokolleintrag steht für eine einzelne Änderung. Die Transaktion beginnt mit einem Eintrag vom Typ Begin. Daraufhin folgen die einzelnen Operationen, bis die Transaktion abgeschlossen ist. Dann wird ein Commit-Eintrag hinzugefügt und die Transaktion per Commit ins Transaktionsprotokoll übernommen. Die Anordnung der Transaktionseinträge erlaubt es ESE, die gesamte Transaktion in einer Datenbank wiederzugeben, wenn Daten wiederhergestellt werden müssen. Wenn ESE dabei in einer Transaktion keinen Eintrag für den Commit findet, wird die Transaktion als unvollständig angesehen und nicht in der Datenbank wiedergegeben. Die Zustellung einer einzigen Nachricht führt dazu, dass ESE viele verschiedene Seiten ändert, da eine ganze Reihe von Tabellen aktualisiert werden müssen. Außerdem passt Index auch jeweils die Indizes dieser Tabellen an. Wenn die Nachricht einen umfangreichen Anhang enthält, wird der Inhalt in mehrere Teile aufgespaltet, für die jeweils Protokolleinträge erstellt werden. Alle diese Transaktionen werden in Protokolldateien erfasst. Wenn Sie das Protokolldateiverzeichnis für eine Datenbank beobachten, während eine umfangreiche Nachricht an mehrere Postfächer dieser Datenbank zugestellt wird, können Sie eine Spitze in der Erstellung von Protokollen erkennen. Für eine Nachricht von 1 MB, die an zehn Postfächer geht, werden beispielsweise mindestens zehn Transaktionsprotokolle erstellt. Wenn Sie dagegen ein Element mit einem sehr großen Anhang löschen, muss Exchange nur die Nummern der Seiten erfassen, die die zu entfernenden Daten enthalten, während der tatsächliche Inhalt nicht in den Protokollen auftaucht. Wie Sie an Abbildung 7.14 ablesen können, stehen die Einträge in einem Protokoll für maschinennahe, physische Änderungen an der Datenbank, wobei die Einträge für verschiedene Transaktionen in der Protokolldatei miteinander verwoben sind. Die Wiedergabe einer Transaktion ist daher eine komplizierte Angelegenheit. Jedes Transaktionsprotokoll enthält eine sequenzielle Liste der Operationen, die der Informationsspeicher an den Seiten im Arbeitsspeicher vorgenommen hat. Das Protokoll enthält Angaben darüber, wann eine Transaktion beginnt, wann sie mit Commit abgeschlossen wird und ob der Informationsspeicher sie aus irgendeinem Grund mit einem Rollback zurücknehmen muss. Jeder Eintrag im Protokoll weist einen bestimmten Typ auf, wobei es u.a. die Typen Begin (Anfang einer Transaktion), Replace (Daten auf einer Seite werden aktualisiert), Delete (Daten werden entfernt), Insert (Daten werden hinzugefügt) und Commit gibt. Im ganzen Transaktionsprotokoll sind die Transaktionen aus mehreren Sitzungen vermischt. Der Eintragstyp Begin muss daher auch die Sitzung bezeichnen, in der die Transaktion durchgeführt wird. Stellen Sie sich eine Sitzung als einen Thread innerhalb des Informationsspeicherprozesses vor. Sie bildet den Kontext, in dem ESE Transaktionen und alle zugehörigen Datenbankänderungen handhabt. Jede Sitzung könnte zu einem bestimmten Client zurückverfolgt werden, aber die Datenbank hat keine Kenntnis von einzelnen Clients (MAPI-Clients oder andere), den sie sieht nur die Threads, die ihre Inhalte bearbeiten. Leider gibt es kein Hilfsprogramm, um eine Protokolldatei zu interpretieren. Abbildung 7.14 zeigt, wie ein Satz von Transaktionen in einem Protokoll erscheint. In diesem Beispiel ersetzt die erste Operation der Transaktion in Sitzung 8 (oder Thread 8) einen Datensatz in der Datenbank. Jede physische Änderung an einer Datenbank wird mit einem Zeitstempel versehen. Wenn ESE Transaktionen, die zu einem bestimmten Zeitpunkt stattfanden, erneut wiedergeben muss, dienen diese Zeitstempel zur Orientierung. Die Seitennummer und ein Offset auf der Seite werden ebenfalls aufgezeichnet. Anschließend wird festgehalten, wie lang die zu ersetzenden Daten sind. Daraufhin folgen die Binärdaten, die in der Seite einzufügen sind. Die nächste Operation der Transaktion löscht einen Datensatz. Bei den anschließenden Einfügungen können Sie erkennen, dass innerhalb eines Protokolls Trans-
426
aktionen aus verschiedenen Sitzungen vermischt sein können. Die Sitzungen schreiben die Daten jeweils mit dem Fortschreiten ihrer Transaktionen in die Protokolldatei. Selbst auf einem nur mäßig belasteten Server zeigt die Ausgabe einer Protokolldatei Transaktionen aus Dutzenden von Sitzungen. Wenn der Informationsspeicher Transaktionen aus den Protokollen erneut wiedergibt, um die Datenbank konsistent zu machen, muss er sich die Inhalte all der verschiedenen Transaktionsprotokolle ansehen, die seit der letzten guten Sicherung angehäuft wurden, um die erforderlichen Transaktionen und die verschiedenen Einträge dafür zu finden und in die Datenbank einzuspielen. Modifizierte Seiten im Cache werden alle 30 Sekunden auf die Festplatte geschrieben. Das geschieht nicht unbedingt in der Reihenfolge der Änderungen, da sie während ihres Aufenthalts im Cache durchaus auch mehrmals geändert sein mögen. Während dieses Vorgangs setzt ESE einen Prüfpunkt, um den jeweiligen Wiederherstellungszustand zu kennzeichnen. Wenn Protokolle aufgrund eines Ausfalls erneut wiedergegeben werden müssen, um die Datenbank auf den neuesten Stand zu bringen, kann ESE anhand dieses Prüfpunkts erkennen, welche Protokolle dazu erforderlich sind. Jedes Transanktionsprotokoll weist eine Generationsnummer auf, die mit jeder 1-MB-Datei um 1 erhöht wird. Die Generationsnummer zeigt die Position und die Reihenfolge der Transaktionen in einer Protokolldatei des gesamten Protokollverlaufs an. Anhand dieser Nummern bestimmt ESE, welche Protokolldateien für eine Wiederherstellungsoperation notwendig sind. Im Prüfpunkt wird auch die Generationsnummer der letzten mit Commit bestätigten Protokolldatei festgehalten, damit ESE die erforderlichen Dateien bestimmen kann. Nehmen wir beispielsweise an, dass die aktuelle Generation der Protokolldateien 0x36b0 ist (14.000), während im Prüfpunkt die Nummer 0x3683 (13.955) angegeben ist. Im Klartext bedeutet das Folgendes: 쐍 Alle Protokolldateien mit einer Generationsnummer kleiner als 0x3683 enthalten vollständige Transaktionen (mit Beginn- und Commiteinträgen), die bereits in die Datenbank geschrieben worden sind. 쐍 Alle Protokolldateien zwischen dem Prüfpunktwert (0x3683) und der aktuellen Generation (0x36b0) können Transaktionen enthalten, die schon in die Datenbank geschrieben wurden, aber da wir nicht sicher sein können, welche Transaktionen das sind, müssen alle Transaktionsprotokolle zwischen 0x3683 und 0x36b0 wiedereingespielt werden, wenn es einen Ausfall gab und die Datenbank wiederhergestellt werden muss. Die letzte erforderliche Generationsnummer wird als Wegepunkt bezeichnet. Die Differenz der Generationsnummerangabe im Prüfpunkt und im Wegepunkt gibt also an, wie viele Transaktionsprotokolle für die Wiederherstellung erforderlich sind. Transaktionsprotokolle enthalten 1 MB an Daten. Auf stark belasteten Systemen, auf denen ständig neue Transaktionsprotokolle erstellt werden, können auch schon neue Protokollgenerationen jenseits des Wegepunkts existieren. Sie enthalten Transaktionen, die noch per Commit in die Datenbank übernommen wurden. Es kann sich dabei um unvollständige Transaktionen handeln (für die es keinen Commiteintrag gibt) oder um solche, die gerade in die Datenbank geschrieben wurden, als der Fehler auftrat. In jedem Fall aber sind diese Protokolle zur Wiederherstellung nicht erforderlich. Wenn ein Fehler auftritt und die Datenbank aktualisiert wird, werden die Transaktionen in diesen Protokolldateien ignoriert und gehen verloren. Anhand dieser Beschreibung können Sie schon erkennen, dass Transaktionsprotokolle für die Integrität eines Exchange Server-Computers von entscheidender Bedeutung sind. Außerdem bilden sie sowohl in Exchange Server 2007 als auch in Exchange Server 2010 den Schlüssel für die Datenbankreplikation, denn es sind diese Dateien, die Exchange kopiert und erneut wiedergibt, um die Datenbankkopien synchron zu halten.
427
Der Informationsspeicher von Exchange Server 2010
Transaktionsprotokolle
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Die Prüfpunktdatei
Anhand der Prüfpunktdatei kann der Informationsspeicher erkennen, welche Transaktionsprotokolle für eine Wiederherstellung erforderlich sind. Der Informationsspeicher aktualisiert die Prüfpunktdatei alle 30 Sekunden, wenn er modifizierte Seiten aus dem Arbeitsspeicher in die Datenbank schreibt. Für einen Satz von Transaktionsprotokollen (einen so genannten Protokolldatenstrom) gibt es immer eine eigene Prüfpunktdatei. Da Exchange Server 2010 für jede Datenbank einen Satz von Transaktionsprotokollen führt, gibt es logischerweise eine Prüfpunktdatei pro Datenbank. Beim Bereitstellen einer Datenbank liest Exchange die Prüfpunktdatei, um zu bestimmen, ob es ausstehende Transaktionsprotokolle gibt, die verarbeitet werden müssen, um die Datenbank auf den neuesten Stand zu bringen. Das ist die so genannte weiche Wiederherstellung, die beim Bereitstellen einer Datenbank vorgenommen wird, damit eine inkonsistente Datenbank (also eine Datenbank mit ausstehenden Transaktionen) in jedem Fall in einen korrekten Zustand zurückgeführt wird, auch wenn sie aufgrund eines Computer- oder Softwarefehlers unerwartet geschlossen wurde. Sofern zur Aktualisierung der Datenbank nicht Zehntausende von Protokollen erforderlich sind, dauert es gewöhnlich lange, um einen Protokollsatz wiedereinzuspielen, da Exchange anhand der Prüfpunktdatei schnell herausfinden kann, wann die letzte Transaktion in die Datenbank geschrieben wurde, und nicht alle verfügbaren Protokolle durchsehen muss, um zu ermitteln, welche der darin erfassten Transaktionen schon in der Datenbank sind und welche noch nicht. Geht jedoch die Prüfpunktdatei aus irgendeinem Grund verloren, muss Exchange tatsächlich sämtliche vorhandenen Protokolle darauf untersuchen, ob sie irgendwelche Transaktionen enthalten, die noch nicht mit einem Commit in die Datenbank geschrieben wurden. Sind einige Transaktionsprotokolle wegen eines Speicherfehlers oder aus einem anderen Grund nicht verfügbar, müssen Sie ESEUTIL mit der Option /P ausführen, um die Datenbank wieder konsistent zu machen, sodass Exchange sie bereitstellen kann. In einer solchen Situation ist es jedoch sehr wahrscheinlich, dass die Benutzer einen gewissen Datenverlust erleiden, da es keine Möglichkeit gibt, um die Transaktionen in den verloren gegangenen Protokollen wiederherzustellen.
Prüfsumme des Transaktionsprotokolls Jedes Transaktionsprotokoll hat eine Prüfsumme, die Exchange kontrolliert, um sicherzustellen, dass die Daten im Protokoll konsistent und gültig sind. Microsoft verwendet Prüfsummen, um zu verhindern, dass logische Beschädigungen auftreten, während der Informationsspeicher bei einer Wiederherstellung Transaktionen in eine Datenbank einspielt. Exchange verwendet einen Gleitfensteralgorithmus namens LRCK (Log Record Checksum), um jeweils die Prüfsummen einer ausgewählten Gruppe von Einträgen in einem Protokoll zu validieren und so letzten Endes die Integrität des gesamten Protokolls sicherzustellen. Der Informationsspeicher liest und verifiziert die Prüfsummen während der Sicherung und Wiederherstellung, damit keine ungültigen Daten verwendet werden. Falls der Informationsspeicher durch einen Prüfsummenfehler auf ungültige Daten aufmerksam wird, zeichnet er den Fehler 463 im Systemprotokoll auf. Kann er den Header eines Transaktionsprotokolls nicht lesen und die Prüfsumme daher nicht kontrollieren, hält er im Anwendungsprotokoll den Fehler 412 fest. Fehler in Transaktionsprotokollen führen unweigerlich zu Datenverlusten, da die einzige Möglichkeit zur Wiederherstellung darin besteht, die letzte gute Sicherung zu verwenden. Alle Transaktionen, die nach dieser Sicherung auftraten, gehen verloren.
428
Ein-/Ausgabe im Transaktionsprotokoll Der Informationsspeicher schreibt Transaktionen immer nacheinander, hängt die neuen Daten also stets am Ende des aktuellen Protokolls an. An Ein-/Ausgaben kommen nur Schreibvorgänge vor, weshalb die Festplatte, auf der die Protokolle untergebracht sind, eine starke Schreibbelastung schultern können muss. Auf den Festplatten mit den Datenbanken kommen dagegen Lese- und Schreibvorgänge vor, wenn die Benutzer auf die Elemente in ihren Postfächern zugreifen. Auf großen Servern wird der E/A-Aktivität durch die Transaktionsprotokolle gewöhnlich dadurch Rechnung getragen, dass die Protokolle auf einer eigenen Festplatte oder einem eigenen logischen Gerät untergebracht werden. Dadurch lösen Sie gleich zwei Probleme auf einmal. Erstens sollte dank der Größe der Festplatte (heute üblicherweise 500 GB und mehr) immer freier Speicherplatz zur Verfügung stehen. Wenn Sie Protokolle mit insgesamt 500 GB ansammeln (das wären 500.000 einzelne Protokolldateien), dann ist entweder ihr Server extrem stark belastet oder Sie haben seit geraumer Zeit keine vollständige Onlinesicherung mehr durchgeführt. Bei einer erfolgreichen vollständigen Sicherung werden die übernommenen Protokolldateien vom Server entfernt. Zweitens ist eine eigene Festplatte immer in der Lage, die E/A-Anforderungen für Transaktionsprotokolle zu erfüllen. Es müssten schon ganz extreme Umstände vorliegen, sollte das nicht der Fall sein. Ich kann mir keinen Grund vorstellen, aus dem eine allein für die Protokolle reservierte Festplatte durch E/A-Anforderungen überlastet werden sollte. Sollte jemals eine solche übermäßige E/A-Last auf dem Server hervorgerufen werden, dann bildet nicht die Protokollfestplatte das Problem, sondern die E/A-Aktivität in den Datenbanken. Insidertipp: Lassen Sie den gesunden Menschenverstand walten
Natürlich kann es sein, dass Sie sich den Luxus einer für die Protokolldateien reservierten Festplatte nicht leisten können. Die Gründe, die für eine solche eigene Festplatte sprechen – ausreichend Platz für das Wachstum der Protokolldateien zur Verfügung zu stellen und ein wachsames Auge auf die E/A-Aktivität zu haben –, sollten Sie in jedem Fall beachten, wenn Sie festlegen, wo die Protokolle auf Ihrem System gespeichert werden sollten. Beispielsweise ist es eine gute Idee, die Protokolle auf demselben Laufwerk unterzubringen, auf dem sich auch andere dynamische Dateien wie die Windows-Auslagerungsdatei befinden. Wie wir bereits beim Erstellen neuer Postfachdatenbanken gesehen haben, besteht eine andere bewährte Vorgehensweise darin, die Protokolle niemals auf demselben Laufwerk zu platzieren wie die Datenbanken. Es mag zwar bequem erscheinen, die Protokolle und die Datenbanken zusammen aufzubewahren, aber dadurch setzen Sie alles auf eine Karte, denn wenn auf der Festplatte ein Problem auftritt, sind davon nicht nur die Datenbanken, sondern auch die Protokolle betroffen, sodass ein Datenverlust droht. Für Datenbanken, die nicht repliziert werden, gilt diese Vorsichtsmaßnahme immer noch, doch angesichts der mehreren Datenbankkopien in einer Datenbankverfügbarkeitsgruppe ist sie heutzutage nicht mehr so dringlich. Wenn Sie nur zwei Datenbankopien haben, ist es jedoch immer noch angebracht, Datenbanken und Protokolle auf verschiedenen Festplatten unterzubringen, da Ihnen im Ernstfall nur eine einzige Kopie zur Verfügung steht. Bei drei oder mehr Datenbankkopien können Sie jedoch Datenbanken und Protokolle zusammen auf einer Festplatte speichern, da Sie bei einem Fehler immer noch mindestens zwei Kopien zur Verfügung haben.
429
Der Informationsspeicher von Exchange Server 2010
Transaktionsprotokolle
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Umlaufprotokollierung – ja oder nein? Bei der Umlaufprotokollierung erstellt der Informationsspeicher nur eine begrenzte Anzahl von Transaktionsprotokollen, indem er Protokolle, deren Inhalte per Commit in die Datenbank geschrieben wurden, wiederverwendet. Diese Funktion wurde ursprünglich in Exchange eingeführt, um die Festplattennutzung auf weniger gut ausgestatteten Servercomputern zu beschränken, als Speicherplatz sehr teuer war. Auch auf Testservern und Edge-Transport-Servern, auf denen die Daten kurzlebig sind und gewöhnlich nicht dauerhaft aufbewahrt werden müssen, ist die Umlaufprotokollierung gang und gäbe. In Phasen geringer Anforderungen verwendet der Informationsspeicher dabei nur relativ wenige Protokolle zur Erfassung von Transaktionen, gewöhnlich zwischen vier und acht. Die Zahl hängt jedoch von der Systemlast sowie davon ab, wie schnell der Informationsspeicher für Transaktionen ein Commit durchführen und sie in die Datenbank überführen kann. Für eine Datenbank unter starker Belastung (beispielsweise wenn viele Postfächer in die Datenbank verschoben werden) sind Tausende von Transaktionsprotokollen nichts Ungewöhnliches. Diese Protokolle können auch eine gewisse Zeit bestehen bleiben, vor allem dann, wenn sie an andere Server repliziert werden. Wenn die Systemlast geringer wird und die Replikation erfolgt, reduziert der Informationsspeicher die Menge der Protokolle für die Umlaufprotokollierung jedoch wieder auf ein geringeres Maß und hält sie auf diesem Niveau, bis die Systembelastung wieder ansteigt. Früher haben Administratoren für Produktionsdatenbanken keine Umlaufprotokollierung verwendet (höchstens auf sehr kleinen Servern). Es gab einfach zu viele Dinge, die schiefgehen konnten, von Hardwarefehlern bis zu Irrtümern bei der Verwaltung, weshalb es nicht angeraten erschien, das Sicherheitsnetz, das die Transaktionsprotokolle bieten, aufzurollen. Wenn ein Problem auftrat, konnte man so eine gute Kopie der Datenbank wiederherstellen und dann die Transaktionen aus den seit der Sicherung erstellten Protokollen einspielen, um die Datenbank wieder auf den neuesten Stand zu bringen. Aufgrund der Wiederverwendung der Protokolle wäre dies bei der Umlaufprotokollierung jedoch nicht möglich gewesen. Für die Frage, ob die Umlaufprotokollierung für Produktionsserver geeignet ist, liefert Exchange Server 2010 jedoch ganz neue Argumente. In Datenbankverfügbarkeitsgruppen können wir mehrere Datenbankkopien vorhalten und dabei auch ausreichende Verzögerungszeiten einrichten, damit sich Beschädigungen nicht sofort auch auf die Kopien ausbreiten. Es kann also durchaus Umstände geben, unter denen die Umlaufprotokollierung für Postfachdatenbanken eine gute Sache ist, wobei Sie jedoch im Voraus alle möglichen drohenden Situationen bedenken müssen, bevor Sie diesen Schritt wagen. Sie müssen auch genau verstehen, wie sich die Umlaufprotokollierung auf andere Dinge auswirken kann, z.B. Ihr Sicherungsverfahren, wie im Microsoft-Blog auf http://msexchangeteam.com/archive/ 2010/08/18/455857.aspx erklärt wird. Manche Unternehmen brauchen auf alle Fälle die Möglichkeit, Transaktionsprotokolle wiedereinspielen zu können, weshalb sie sie aufbewahren müssen. Andere verwenden Datenbankverfügbarkeitsgruppen und brauchen vielleicht gar keine Sicherungen mehr. Die meisten Unternehmen sind irgendwo in der Mitte zwischen diesen beiden extremen Standpunkten angesiedelt und müssen herausfinden, was angesichts ihrer geschäftlichen Bedürfnisse und Ziele die bestmögliche Vorgehensweise ist. HINWEIS Standardmäßig wird für neue Postfachdatenbanken keine Umlaufprotokollierung eingesetzt. Wenn Sie sie aktivieren wollen, um Festplattenplatz zu sparen, müssen Sie die Eigenschaften der Datenbank ändern, nachdem Sie sie erstellt haben. Das neue Protokollierungsverhalten tritt dann nach der nächsten Bereitstellung der Datenbank in Kraft.
430
Abbildung 7.15 zeigt, wie Sie die Umlaufprotokollierung für eine Postfachdatenbank aktivieren. Der entsprechende Shellbefehl lautet: Set-MailboxDatabase –Identity 'DB1' –CircularLoggingEnabled $True Abbildg. 7.15
Aktivieren der Umlaufprotokollierung für eine Postfachdatenbank
Durch die Umlaufprotokollierung können Sie eine Erschöpfung des Festplattenplatzes nicht verhindern. Sie müssen die Festplatten nach wie vor sorgfältig beobachten, um sicherzustellen, dass auch dann noch ausreichend Speicherplatz für die Protokolle zur Verfügung steht, wenn sie für einen unerwartet langen Zeitraum aufbewahrt werden müssen. In einer Datenbankverfügbarkeitsgruppe behält Exchange die Protokolle bei, bis ihr Inhalt auf alle Datenbankkopien übertragen wurde. Ist eine der Kopien nicht verfügbar, verbleiben die Transaktionsprotokolle so lange auf den Servern mit den anderen Kopien, bis die unerreichbare Kopie wieder online geht und der Informationsspeicher die ausstehenden Protokolle erfolgreich einspielen kann, um die Kopie zu aktualisieren. Dadurch soll die Wahrscheinlichkeit von Datenverlusten selbst bei aktivierter Umlaufprotokollierung verringert werden. Aus diesem Grund sollten Sie auf den Festplatten für die Transaktionsprotokolle einen erheblichen Puffer an Speicherplatz für solche Fälle vorsehen. Dieses Thema wird ausführlicher in Kapitel 8 behandelt.
Protokollierung ohne Wiederverwendung Ist die Umlaufprotokollierung deaktiviert, erstellt der Informationsspeicher so viele Transaktionsprotokolle, wie nötig sind, um alle an einer Datenbank vorgenommenen Transaktionen zu speichern, und entfernt sie nur dann, wenn eine Sicherung erfolgt ist. Dadurch wird natürlich weit mehr Festplattenplatz verbraucht als bei der Umlaufprotokollierung, denn selbst ein Exchange Server-Computer mittlerer Größe kann täglich Gigabytes an Transaktionsprotokollen erstellen.
431
Der Informationsspeicher von Exchange Server 2010
Transaktionsprotokolle
Kapitel 7
Der Informationsspeicher von Exchange Server 2010
Bei deaktivierter Umlaufprotokollierung erstellt der Informationsspeicher ein neues Transaktionsprotokoll, während er noch Daten in das aktuelle schreibt, und macht es anschließend zum aktuellen Protokoll. Dazu rückt er zunächst den Prüfpunkt in der Prüfpunktdatei vor, um anzuzeigen, dass die Transaktionen im ältesten Protokoll mit Commit abgeschlossen und in die Datenbank übernommen worden sind. Als Nächstes erstellt er die temporäre Datei
Reservierte Protokolle In Exchange Server 2000 und Exchange Server 2003 verfügte jede Speichergruppe über die beiden besonderen Protokolldateien Res1.log und Res2.log, um dem Informationsspeicher für den Fall, dass er aus irgendeinem Grund keine neuen Transaktionsprotokolle erstellen konnte, Notfallspeicherplatz zur Verfügung zu stellen. Eine Verwendung dieser Dateien konnte ich nur dann erkennen, wenn der Speicherplatz auf der Festplatte mit den Transaktionsprotokollen erschöpft war. In den Anfangstagen von Exchange kam es häufiger vor, dass der Speicherplatz erschöpft war, da die Festplatten damals klein und teuer waren, aber heutzutage sollte sich so etwas nur selten ereignen. Die meisten Administratoren überwachen den freien Speicherplatz auf allen von Exchange verwendeten Festplatten und ergreifen Maßnahmen, um Speicherplatz freizugeben, wenn weniger als 1 GB verfügbar ist. 432
In Exchange Server 2007 und Exchange Server 2010 tragen die reservierten Protokolle (die jetzt nur jeweils 1 MB groß sind) andere Namen, nämlich
Die Tatsache, dass auf der Festplatte weniger als 1 GB freier Platz zur Verfügung steht, ist in jedem Fall ein Alarmsignal, dass ein sofortiges Eingreifen des Administrators erforderlich macht, um Platz freizugeben und dafür zu sorgen, dass die Situation nicht erneut auftreten kann. Wenn auf einer Festplatte mit Transaktionsprotokollen der Speicherplatz knapp wird, meldet Exchange das Ereignis 10014, auf Festplatten mit Postfachdatenbanken das Ereignis 10015. Außerdem wird das Problem in den Leistungsindikatoren MSExchangeIS Postfach\Blockierte Zustellung: Nicht ausreichend Datenbankspeicher bzw. MSExchangeIS Postfach\Blockierte Zustellung: Nicht ausreichend Protokollspeicher des Systemmonitors angezeigt.
Und nun zu etwas völlig anderem Alles, was wir bisher besprochen haben, hat es in der einen oder anderen Form schon in mehreren früheren Versionen von Exchange gegeben. Der Informationsspeicher stützt sich auf eine DatenbankEngine, und die physische Umsetzung stellt sich als eine Reihe von Datenbanken auf der Festplatte dar. Besonders interessant ist jedoch die Frage, was Sie mithilfe einer in Exchange Server 2010 neu eingeführten Technologie mit diesen Datenbanken tun können, und das ist genau das Thema, mit dem wir uns als Nächstes beschäftigen.
433
Der Informationsspeicher von Exchange Server 2010
Und nun zu etwas völlig anderem
Exchange auf dem Weg zur Hochverfügbarkeit
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
In diesem Kapitel: Trennen von Datenbank und Server
437
Active Manager
442
Wiedergabe des Transaktionsprotokolls: die Grundlage der Replikation von Datenbankverfügbarkeitsgruppen
449
Eindeutige Datenbanknamen
459
Änderungen bei der Nachrichtenübermittlung innerhalb einer Datenbankverfügbarkeitsgruppe
462
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
463
Aktualisieren von Servern in Datenbankverfügbarkeitsgruppen
511
Datacenter Activation Coordination
513
Crimson-Ereignisse
516
Einrichten einer Installation mit Datenbankverfügbarkeitsgruppen
517
Hilfreiche Skripts für die Verwaltung von Datenbankverfügbarkeitsgruppen
521
Der Schutz Ihrer Daten
526
435
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Für viele Unternehmen ist das E-Mail-System von geschäftsentscheidender Bedeutung. Im Laufe der Jahre hat Microsoft viel Know-how und Geld investiert, um aus Exchange Server ein Produkt zu machen, das verschiedene Arten von Ausfällen überstehen kann und hochgradig verfügbar ist. Dabei wurde der Exchange-Code verfeinert, vor allem in den Teilsystemen für den Informationsspeicher und den Transport, und auch die Nutzung der Hardware verbessert, indem die Notwendigkeit für teuren Speicher durch das Zurückgreifen auf andere, neue Technologien wie Windows-Cluster und asynchrone Datenreplikation reduziert wurde. Microsoft Exchange Server 2007 war in vieler Hinsicht ein Meilenstein für die Hochverfügbarkeit, da hier die fortlaufende Protokollreplikation (Protokollversand) eingeführt wurde. Mit der fortlaufenden lokalen Replikation können Transaktionsprotokolle kopiert und dann auf demselben Server erneut wiedergegeben werden, während die fortlaufende Clusterreplikation dasselbe Prinzip auf einen Windows-Cluster mit zwei Knoten anwendet. Die Standbyclusterreplikation (ab Exchange Server 2007 SP1) ist eine Möglichkeit für die Replikation zwischen Servern in verschiedenen Rechenzentren. Die Gestaltung der Protokollreplikation ist in Exchange Server 2007 noch nicht ganz ausgereift, und die Bereitstellung dieser Funktion kann kompliziert werden. Schon die Auswahl aus drei verschiedenen Möglichkeiten kann Verwirrung stiften. Außerdem zeichnete sich die erste Version durch eine fehlende Möglichkeit zum automatischen Failover, eine fehlende grafische Verwaltungsoberfläche zur Steuerung sämtlicher Vorgänge vom Erstellen des Clusters bis zum Failover und einige geringere Mängel aus. Abgesehen von diesen Einschränkungen funktionierte die grundlegende Technologie jedoch: Transaktionsprotokolle wurden geschlossen und vom Quell- auf den Zielserver kopiert, ihr Inhalt wurde validiert, und dann wurden die enthaltenen Transaktionen in die passiven Kopien der Datenbanken eingespielt, um sie zu aktualisieren. Verständlicherweise entschied sich Microsoft daher, die fortlaufende Protokollreplikation als Grundlage für die Hochverfügbarkeit zu nutzen, die verschiedenen Varianten der Protokollreplikation, die in Exchange Server 2007 zur Verfügung standen, in Exchange Server 2010 jedoch zu einer einzigen, leichter zu verwaltenden und vollständigen Lösung zusammenzufassen. Die fortlaufende lokale, Cluster- und Standbyreplikation gibt es nicht mehr, aber wie wir sehen werden, bilden die neuen Datenbankverfügbarkeitsgruppen einen mehr als gleichwertigen Ersatz. Microsoft wollte in Exchange Server 2010 auch ausreichend Funktionen aufnehmen, damit Kunden eine hochverfügbare Exchange-Infrastruktur aufbauen können, ohne dazu in teure Zusatzprodukte von Drittanbietern investieren zu müssen. Zweifellos bietet Drittanbietertechnologie vor allem in Kombination mit High-End-Speichersystemen ihre eigenen sehr guten Hochverfügbarkeitsfunktionen, aber der Kundenstamm für Exchange ist sehr gemischt, weshalb sich nicht alle die Kosten und den Verwaltungsaufwand für die Bereichstellung einer zusätzlichen Technologie leisten können. Dadurch, dass in das Produkt gleich ein umfassender Satz von Hochverfügbarkeitsfunktionen eingebaut ist, die sich über die normalen Verwaltungsschnittstellen steuern lassen (die Exchange-Verwaltungskonsole und -Verwaltungsshell), wird Exchange als Plattform für viele gewerbliche Kunden geringer bis mittlerer Größe noch ansprechender, denn dadurch bleibt das E-Mail-System überschaubar und es werden Kosten gespart. Überdies wollte Microsoft den Kunden die Gelegenheit geben, die Hochverfügbarkeit in kleinen Schritten herzustellen. In früheren Versionen von Exchange kostete die Bereitstellung einer Hochverfügbarkeitslösung eine erhebliche Menge an Vorbereitungen. Wenn Sie beispielsweise Exchange Server-Cluster verwenden wollten, mussten Sie zunächst geeignete Hardware anschaffen, dann einen Windows-Cluster erstellen und schließlich Exchange mit den entsprechenden Optionen installieren, um virtuelle Exchange Server-Computer anzulegen, die in den Clustern liefen und mit Clusterressourcen wie gemeinsamen Speichermöglichkeiten verknüpft waren. So etwas lässt sich nicht ohne Planung und eine Menge an Fachwissen erledigen. Das Prinzip der schrittweisen Bereitstellung, das
436
mit Exchange Server 2010 umgesetzt wurde, besagt, dass Sie zunächst »normale« ExchangePostfachserver bereitstellen, die Sie anschließend in Datenbankverfügbarkeitsgruppen aufnehmen können, wenn in Ihrer Umgebung der Bedarf nach Hochverfügbarkeit steigt. Diese Datenbankverfügbarkeitsgruppen können Sie dann nach und nach erweitern, wenn Zeit, Geld und die Hardware es erlauben, indem Sie mehr Server oder mehr Datenbankkopien darin aufnehmen, um immer besser gegen verschiedene mögliche Fehler gefeit zu sein.
Trennen von Datenbank und Server Trotz ihrer Mängel war die neue fortlaufende Replikation in Exchange Server 2007 ein großer Schritt nach vorn, um das Produkt selbst mit Hochverfügbarkeitsfunktionen auszustatten. Der letzte Mosaikstein bestand darin, die althergebrachte enge Verknüpfung zwischen Server und Postfachdatenbank zu trennen. Wenn Sie sich in Active Directory die Konfigurationsdaten für Exchange Server 2007 ansehen, können Sie erkennen, dass sich die Struktur nach »Organisation > administrative Gruppe > Server > Datenbank« gegliedert ist. Mit anderen Worten, Datenbanken sind untergeordnete Objekte von Servern, und jede Datenbank gehört zu einem bestimmten Server. In Exchange Server 2010 haben wir es jedoch mit einer völlig anderen Struktur zu tun, nämlich »Organisation > Datenbankverfügbarkeitsgruppe/Server/Datenbank«. Jetzt nehmen Datenbankverfügbarkeitsgruppen, Server und Datenbanken dieselbe Ebene innerhalb der Exchange-Organisation ein. Welche Server und Datenbanken sich in welcher Verfügbarkeitsgurppe befinden, wird durch Verknüpfungen festgelegt. Andere Verknüpfungen sind dazu, um die Beziehungen zwischen den Datenbankkopien und den Datenbanken sowie den Servern herzustellen. Mit Active Manager gibt es eine neue Komponente für die Systemverwaltung, die diese Informationen zurate zieht, um zu bestimmen, welche Datenbankkopie auf welchem Server zurzeit aktiv ist und welche passiven Kopien verfügbar sind. Zwischen den Datenbanken und den Servern gibt es keine Zuordnung mehr. Mit Exchange Server 2007 wurde auch das Prinzip der Portabilität von Datenbanken eingeführt. Das bedeutet, dass Sie eine Postfachdatenbank von einem Server nehmen und auf einem anderen Server bereitstellen können. In Exchange Server 2010 wird diese Möglichkeit Datenbankmobilität genannt. Die Mobilität unterscheidet sich von der Portabilität vor allem dadurch, dass die Datenbanken nicht von einem Server zum anderen verschoben werden. Stattdessen verschieben Sie nur den aktiven Endpunkt für Clientverbindungen und die Arbeitslast von einer Datenbankkopie zu einer anderen. Alle Kopien einer Datenbank weisen denselben global eindeutigen Bezeichner (GUID) oder dieselbe Identität auf, weshalb jede von ihnen die Rolle der aktiven Masterdatenbank spielen kann, und zwar unabhängig davon, auf welchem Server sie sich gerade befindet. Der Pfad für die Datenbank- und Protokolldateien auf den Servern muss bei allen Kopien gleich sein. Die Möglichkeit, zwischen den Datenbankenkopien auf den Servern einer Verfügbarkeitsgruppe umschalten zu können, ist ein grundlegendes Erfordernis, um Datenbankausfälle verkraften und eine hohe Verfügbarkeit für Exchange erreichen zu können, ohne auf die früher erforderlichen Angebote von Drittanbietern angewiesen zu sein. Exchange Server 2010 behandelt eine Postfachdatenbank als Failovereinheit, da zwischen den Servern in einer Datenbankverfügbarkeitsgruppe umgeschaltet werden kann, wenn Probleme auftreten. Natürlich sind Sie nicht gezwungen, in Ihrer Organisation Datenbankverfügbarkeitsgruppen einzurichten. Sie können Exchange wie früher mit Datenbanken betreiben, die einzig und allein auf einem Server vorgehalten werden. Wenn Sie eine Datenbankverfügbarkeitsgruppe einrichten, werden die Server Mitglieder dieser Gruppe und können aktive und passive Kopien der Postfachdatenbanken in der Gruppe beherbergen. Alle Dienste, die Sie von einem Postfachserver erwarten, sind nach wie vor
437
Exchange auf dem Weg zur Hochverfügbarkeit
Trennen von Datenbank und Server
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
vorhanden (z.B. der Informationsspeicherdienst usw.) und verarbeiten die zurzeit auf dem Server untergebrachten Datenbanken. Dazu gehört auch der Replikationsdienst, der die eingehenden Kopien der Transaktionsprotokolle verarbeitet, um die passiven Kopien der Datenbanken zu aktualisieren, deren aktive Kopien auf einem anderen Server in der Gruppe vorhanden sind. Insidertipp: Der Vorteil mehrerer passiver Datenbankkopien
Wie bei der Protokollreplikation von Exchange Server 2007 kann eine Datenbank immer nur über eine aktive Kopie auf einmal verfügen. allerdings können Sie in Exchange Server 2010 so viele passive Kopien erstellen, wie Server in der Datenbankverfügbarkeitsgruppe vorhanden sind. Je mehr Kopien einer Datenbank im Umlauf sind, umso wahrscheinlicher ist es, dass Sie sich schnell von einem Fehler erholen können, der einen Server oder ein an einen Server angeschlossenes Speichermedium beeinträchtigt, und umso weniger kann Ihre Infrastruktur unter einer Schwachstelle leiden, von der das Wohl und Wehe des ganzen Systems abhängt. Dank der Verringerung der Festplatten-E/A in Exchange Server 2010 und der Verfügbarkeit billigerer Festplatten für Datenbanken können Sie es sich jetzt leisten, mehrere Datenbankkopien zu unterhalten. Natürlich müssen Sie hier den gesunden Menschenverstand walten lassen und nicht mehr Kopien erstellen, als Sie wirklich benötigen. In einer Datenbankverfügbarkeitsgruppe, die zehn Server umfasst, kann es von einer Datenbank eine aktive Kopie auf einem Server geben, deren Inhalte an die bis zu neun passiven Kopien auf den anderen repliziert werden. Tatsächlich zehn Kopien zu unterhalten, ist jedoch eine ziemlich extreme Vorgehensweise. Gewöhnlich werden eher drei passive Kopien einer Datenbank verwendet, um einen guten Ausgleich zwischen der Möglichkeit für eine Wiederherstellung unter verschiedenen Umständen und der Begrenzung der erforderlichen Datenreplikation zur Aktualisierung der passiven Kopien zu schaffen. Wenn sich eine Datenbankverfügbarkeitsgruppe über mehrere Rechenzentren erstreckt oder wenn verzögerte Kopien vorhanden sein müssen, kann die Anzahl der passiven Kopien auf vier erhöht werden. Da Schöne ist, dass es beim Entwurf eines Systems viele Möglichkeiten gibt, um einem Datenverlust unter verschiedenen Umständen vorzubeugen. Erwartungsgemäß lässt sich die aktive Kopie einer Datenbank bereitstellen, und ihre Bereitstellung lässt sich auch wieder aufheben. Im bereitgestellten Zustand ruft die Datenbank Transaktionen hervor, die Exchange an die Server mit den passiven Kopien repliziert. Bei nicht bereitgestellten Datenbanken geschieht auch nicht viel. Neben dem Bereitstellungsstatus unterscheidet Exchange Server 2010 bei Datenbanken auch, ob es sich bei ihnen um die Quelle oder das Ziel der Replikation handelt. Jede Datenbankkopie kann sowohl als Quelle als auch als Ziel dienen, aber nicht gleichzeitig. Außerdem kann eine Datenbankkopie aktiv (zur Verarbeitung eingehender Verbindungen von E-Mail-Clients bereit) oder passiv (zum Umschalten in den aktiven Modus bereit) sein, aber nicht beides zugleich. Innerhalb einer Datenverfügbarkeitsgruppe kann immer nur eine Kopie einer Datenbank aktiv sein, und auf einem Server kann sich nur jeweils eine Kopie einer Datenbank befinden. All diese Bedingungen sind ziemlich einsichtig und bilden das Grundgerüst für die Replikation und den Wechsel der Datenbanken vom aktiven zum passiven Zustand und umgekehrt.
Datenbankverfügbarkeitsgruppen In Exchange Server 2000 wurden Speichergruppen als Grundlage für die Datenbankverwaltung eingeführt. Datenbanken gehörten zu Speichergruppen, die wiederum zu Servern gehörten. Alle Datenbanken in einer Speichergruppe teilten sich einen gemeinsamen Satz von Transaktionsprotokollen, und
438
die Transaktionen aller Datenbanken in einer Speichergruppe waren in diesen Protokollen miteinander vermischt. Seit Exchange Server 2003 konnten Sie bei Problemen mit einer Datenbank die Speichergruppe für die Wiederherstellung nutzen, um auf eine wiederhergestellte Kopie einer Datenbank zuzugreifen und die Postfachdaten abzurufen. Die Verwendung von Speichergruppen zur Verwaltung war zwar in manchen Fällen recht bequem, doch Microsoft kam letzten Endes zu dem Schluss, dass sie die Arbeit von Administratoren unnötig kompliziert machten. Mit Exchange Server 2007 begann man damit, Speichergruppen aus dem Produkt herauszunehmen. In diesem Produkt funktionierte die fortlaufende Protokollreplikation nur noch für Speichergruppen mit einer einzigen Datenbank. Es war zwar immer noch möglich, weitere Datenbanken in eine solche Gruppe aufzunehmen, auch Datenbanken für öffentliche Ordner, aber Microsoft machte deutlich, dass Speichergruppen mit einer einzigen Datenbank zu bevorzugen waren, vor allem wenn Sie die neuen Hochverfügbarkeitsfunktionen von Exchange nutzen wollten. Daher war es keine Überraschung, dass es in Exchange Server 2010 überhaupt keine Speichergruppen mehr gibt. Der Verzicht auf Speichergruppen hat zwar die Verwaltung vereinfacht, aber nichts zur Hochverfügbarkeit beigetragen. Durch die Protokollreplikation in Exchange Server 2007 wurde die Verfügbarkeit der Nachrichtenübermittlung zwar erhöht, aber diese Funktion war auf einen Quell- und einen Zielserver beschränkt. Der Einsatz der fortlaufenden und der Standbyclusterreplikation von Exchange Server 2007 hat die Funktionsfähigkeit des Prinzips bewiesen, Transaktionsprotokolle an Zielsysteme zu senden, auf denen der Replikationsdienst die Inhalte einspielte, um eine passive Kopie der Quelldatenbank zu aktualisieren, sodass bei einem Ausfall der ursprünglichen Datenbank auf diese Kopie umgeschaltet werden kann. Exchange Server 2010 erweitert dieses Prinzip dadurch, dass jede Datenbank über mehrere Kopien verfügen kann, die in der neuen Struktur der Datenbankverfügbarkeitsgruppe zusammengefasst sind. Im Prinzip ist eine Datenbankverfügbarkeitsgruppe eine Sammlung von Datenbanken und deren Kopien, die auf bis zu 16 Server verteilt sind. Ausgerechnet 16 als höchste Anzahl der Server in einer Gruppe zu wählen, erscheint völlig willkürlich, doch dieser Grenzwert kommt durch den Failoverclusterdienst von Windows zustande, der nur mit bis zu 16 Knoten in Clustern umgehen kann. Da der Failoverclusterdienst die Grundlage der Datenbankverfügbarkeitsgruppen bildet, gelten seine Einschränkungen auch für diese Gruppen. Auf jeden Fall sollten 16 Server für die meisten Umgebungen genügen, und sicherlich reicht diese Anzahl, um zu erkennen, wie weit Microsoft mit der Kombination der Technologien kommen kann, die eine Datenbankverfügbarkeitsgruppe ausmachen. Im Einzelnen handelt es sich dabei um folgende Technologien: 쐍 Protokollreplikation (die Technologie für die Übertragung und Wiedergabe der Protokolle sowie die Netzwerktechnologie, die die Replikation möglich macht) 쐍 Netzwerke 쐍 Windows-Failovercluster 쐍 Überwachungs- und Verwaltungswerkzeuge 쐍 Server und Speicherhardware Abgesehen von der internen Installation bei Microsoft hatten schon bei der früheren Generation der Einzelkopiecluster die wenigsten Kunden mehr als vier Server in einem Cluster, weshalb es keinen dringenden Bedarf für Riesencluster mit Hunderten von Servern gibt. Außerdem haben wir es zurzeit noch mit der ersten Version von Datenbankverfügbarkeitsgruppen zu tun. Es ist durchaus möglich, dass Microsoft es irgendwann für möglich und vorteilhaft hält, die Anzahl der möglichen Server in einer Datenbankverfügbarkeitsgruppe in einer zukünftigen Version von Exchange zu erhöhen oder
439
Exchange auf dem Weg zur Hochverfügbarkeit
Trennen von Datenbank und Server
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
neue Funktionen einer neuen Version von Windows zu nutzen. Zurzeit sind wir auf 16 Server beschränkt. Wenn Sie Datenbanken auf mehr als 16 Servern schützen müssen, steht ihnen die einfache Möglichkeit offen, einzelne Server in mehrere Datenbankverfügbarkeitsgruppen zu stellen. In Datenbankverfügbarkeitsgruppen wird das Funktionsprinzip umgesetzt, eine aktive (oder primäre) Datenbank zu verwenden, mit der die Benutzer verbunden sind, und Kopien davon auf anderen Servern bereitzuhalten, die zur aktiven Datenbank umgeschaltet werden können. Die Datenbankkopien werden durch die Replikation und Wiedergabe der Protokolle immer auf dem neuesten Stand gehalten. Wenn auf einem Server ein Problem auftritt, dass die auf ihm vorhandene aktive Datenbank unzugänglich macht, kann die Verfügbarkeitsgruppe eine andere Kopie zur aktiven machen. Der neue Remoteprozeduraufruf (Remote Procedure Call, RPC) Client Access Layer leitet die Clientverbindungen nahtlos zur neuen aktiven Kopie um (siehe Kapitel 11, »Clientzugriffsserver«). Ein solches Umschalten zwischen Datenbanken auf verschiedenen Servern wäre nicht möglich, wenn die Produktdatenbank eine feste Beziehung zwischen Datenbank und Server verlangen würde, wie es bei allen früheren Versionen von Exchange der Fall war. Durch die Einführung von Datenbankverfügbarkeitsgruppen wurde diese Bindung zwischen der Datenbank und dem Server, zu dem sie gehört, aufgehoben. Erst dadurch sind die übertragbaren Datenbanken möglich geworden, die die wichtigste Komponente der Hochverfügbarkeitsfunktionen in Exchange Server 2010 sind. Das ist wahrscheinlich die grundlegendste Änderung an der Architektur, die Microsoft in Exchange Server 2010 vorgenommen hat. Alle Server in einer Datenbankverfügbarkeitsgruppe müssen in der Lage sein, eine Postfachdatenbank auszuführen, weshalb auf ihnen unbedingt die Rolle des Postfachservers installiert sein muss. Allerdings können sie daneben auch noch andere Rollen ausfüllen. Die Server in einer Datenbankverfügbarkeitsgruppe können sich in unterschiedlichen Subnetzen und auch in mehreren Active Directory-Standorten befinden, solange die Netzwerkinfrastruktur genügend Bandbreite zur Verfügung stellt, um Transaktionsprotokolle im zu erwartenden Umfang zwischen ihnen zu übertragen. Um einen reibungslosen Betrieb sicherzustellen, empfiehlt Microsoft, die Postfachserver in einer Datenbankverfügbarkeitsgruppe an ein Netzwerk mit einer Roundtripwartezeit von höchstens 250 Millisekunden anzuschließen. Außerdem sollten Sie den netzwerkübergreifenden Datenverkehr zwischen Rechenzentren blockieren, um übermäßige Taktübertragungen im Cluster zu vermeiden und die verfügbare Bandbreite für wichtigere Vorgänge wie die Protokollreplikation zu reservieren. Wenn sich eine Datenbankverfügbarkeitsgruppe über mehrere Rechenzentren erstreckt, müssen Sie noch andere Aspekte bedenken, z.B. die Zuweisung der IP-Adressen für die Netzwerke, die korrekten TTL-Einstellungen für DNS (damit die Clients die Netzwerkänderungen bei einem Failover schnell genug aufgreifen) und die Verwendung geeigneter Namen für alle Dienste, die Exchange von beiden Rechenzentren aus den Clients anbietet. TIPP In einem Buch, das einen Gesamtüberblick über Exchange geben soll, ist es nicht möglich, diese Aspekte ausführlich zu beschreiben. Wenn Sie eine ausgedehnte Datenbankverfügbarkeitsgruppe planen, sollten Sie sich mit einem Exchange-Berater zusammensetzen, der bereits beträchtliche Erfahrungen mit Datenbankverfügbarkeitsgruppen gesammelt hat, um die jetzige Situation und Ihre geschäftlichen Anforderungen zu bestimmen und ein geeignetes Design für die Verfügbarkeitsgruppe zu entwerfen. Auf einem Computer mit Exchange Server 2010 Enterprise Edition können insgesamt bis zu 100 aktive und passive Datenbankkopien ausgeführt werden. In Exchange Server 2007 war zwar bereits eine Frühform der Protokollreplikation vorhanden, doch können Sie Computer mit dieser Produktversion nicht in eine Datenbankverfügbarkeitsgruppe aufnehmen.
440
Bestimmen des MAPI-Endpunkts
MAPI-Clients (Messaging Application Programming Interface), die Verbindung mit Exchange Server 2007 oder einer früheren Version aufnehmen, wissen, dass ihr Endpunkt ein Postfach in einer Datenbank auf einem bestimmten Servercomputer ist. Die Eigenschaft msExchHomeServerName des Active Directory-Kontos für den Benutzer zeigt auf den Server und die Eigenschaft HomeMDB auf die Datenbank. Da in Exchange Server 2010 keine feste Verknüpfung mehr zwischen Server und Datenbank besteht, ist ein neues Verfahren erforderlich, um den Endpunkt für MAPI-Clients zu bestimmen. Exchange Server 2010 verwendet den Wert von msExchHomeServerName nicht mehr, da es zu aufwändig wäre, während eines Datenbankwechsels in einer Datenbankverfügbarkeitsgruppe möglicherweise Tausende von Active Directory-Objekten zu aktualisieren. Stattdessen wird folgender Algorithmus verwendet: 쐍 Die Eigenschaft homeMDB für das Benutzerobjekt in Active Directory wird abgerufen. Den vollständigen Wert dieser Eigenschaft sehen Sie im Folgenden. Der erste CN-Eintrag (»Dublin Users«) bezeichnet die Datenbank, in der sich das Postfach des Benutzers befindet. CN=Dublin Users,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=contoso, CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com
쐍 Aus der Eigenschaft legacyExchangeDN der Datenbank wird der definierte Name des Servers extrahiert. Dabei handelt es sich allerdings nicht um den Server, auf dem die Datenbank tatsächlich ausgeführt wird, sondern um den Clientzugriffsserver, der zurzeit den RPC-Clientzugriffsdienst für die Datenbank anbietet. /o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT) /cn=Configuration/ cn=Servers/cn=ExServer2/cn=Microsoft Private MDB
쐍 Von dem im vorherigen Schritt bestimmten Server wird die Angabe angefordert, wo die aktive Kopie der Postfachdatenbank zurzeit bereitgestellt ist. Diese Information ist in der Eigenschaft msExchOwningServer des Datenbankobjekts gespeichert. 쐍 Die Verbindung zu dem vom Clientzugriffsserver angegebenen MAPI-Endpunkt wird hergestellt. Der Clientzugriffsserver kümmert sich um die Kommunikation mit dem Postfachserver. Dies ist nur ein Beispiel dafür, wie der Code von Exchange an die Einführung von Datenbankverfügbarkeitsgruppen angepasst werden musste.
Die Abhängigkeit von Windows-Clustern Um die Mitgliedschaft der Server in einer Datenbankverfügbarkeitsgruppe zu verwalten, um die Taktsignale zu überwachen und damit festzustellen, welche Server laufen, und um ein Quorum zu unterhalten, wird für Datenbankverfügbarkeitsgruppen auf die Windows-Failoverclusterfunktion zurückgegegriffen. Der große Unterschied zu der in anderen Exchange-Versionen verwendeten Clustertechnologie besteht darin, dass es keine virtuellen Exchange-Maschinen und keine Postfachclusterserver gibt und außer der IP-Adresse und dem Netzwerknamen auch keine Clusterressourcen zu Exchange zugewiesen werden. Die Windows-Failoverclusterfunktion verwendet den Netzwerknamen, um das Kennwort für das Computernamenobjekt des Clusters zu aktualisieren. Wenn der primäre Active Manager (siehe nächster Abschnitt) aufgrund eines Serverausfalls einen Wechsel vollziehen muss, zieht er zur Bestimmung der geeigneten Serverkandidaten die Liste der Server heran, die sich im Besitz des Dateifreigabenzeugen befinden, also einer Clusterressource. Abgesehen von diesen Kleinigkeiten gibt es jedoch keine 441
Exchange auf dem Weg zur Hochverfügbarkeit
Trennen von Datenbank und Server
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
in der Praxis bedeutsame Abhängigkeit vom Netzwerknamen, da Exchange auf die Servernamen zurückgreift, wenn keine Clusternamen zur Verfügung stehen. Tatsächlich müssen Sie Clusterressourcen wie Knoten, Netzwerke und Speicher nicht mit dem Failovercluster-Manager von Windows verwalten, da die gesamte Verwaltung über Exchange stattfindet. Wenn Sie versuchen, die Clustereinstellungen mit dem Failovercluster-Manager zu ändern, kann das sogar dazu führen, dass Sie dabei etwas kaputt machen, was für das korrekte Funktionieren von Exchange erforderlich ist. Exchange schirmt die Systemadministratoren von den komplizierten Mechanismen der Clustertechnologie ab. Insidertipp: Anforderungen an das Betriebssystem
Exchange greift zwar nur in einem absoluten Mindestmaß auf Clustertechnologie zurück, doch die Abhängigkeit von der Windows-Clusterfunktion bedeutet, dass Sie Postfachserver nur dann zu einer Datenbankverfügbarkeitsgruppe hinzufügen können, wenn auf ihnen Exchange Server 2010 Enterprise auf Windows Server 2008 (SP2 oder R2) Enterprise ausgeführt wird. Außerdem müssen alle Mitgliedsserver der Datenbankverfügbarkeitsgruppe zur selben Domäne gehören und dieselbe Betriebssystemversion verwenden. Sie können in einer Gruppe nicht Windows Server 2008 SP2 und Windows Server 2008 R2 mischen, und es ist auch sehr sinnvoll, auf allen Servern die gleiche Software auszuführen. Beispielsweise können Sie von einer Datenbankkopie auf einem Server mit der RTM-Version von Exchange Server 2010 zu einer auf einem Server mit Exchange Server 2010 SP1 umschalten, aber nicht umgekehrt. Trotz ihres Namens ist die Failoverclusterfunktion von Windows nicht am Failover von ExchangePostfachdatenbanken beteiligt. Um diesen Vorgang kümmert sich eine neue Systemverwaltungskomponente von Exchange namens Active Manager, die den aktuellen Zustand der Server und der Datenbanken beobachtet und die Server nach Bedarf anweist, Datenbankkopien vom aktiven in den passiven Zustand umzuschalten und umgekehrt. Der Exchange-Administrator muss sich nicht einmal mit den Einzelheiten der Windows-Clusterfunktion herumschlagen, da Exchange die wenigen erforderlichen Clusterfunktionen (Takt und Quorum) selbst einrichtet, wenn Sie den ersten Postfachserver zu einer Datenbankverfügbarkeitsgruppe hinzufügen. Einige der Angaben zu einer Datenbankverfügbarkeitsgruppe werden in Active Directory gespeichert. Diese Informationen ändern sich gewöhnlich nicht sehr häufig, z.B. der Name der Gruppe. Andere Informationen, die einem häufigeren Wechsel unterliegen, z.B. der Bereitstellungsstatus der Datenbank (aktiv oder passiv), werden in der Clusterdatenbank festgehalten.
Active Manager Active Manager wird auf jedem Server innerhalb einer Datenbankverfügbarkeitsgruppe als Teil des Microsoft Exchange-Replikationsdienstes ausgeführt (MSExchangeRepl, nicht zu verwechseln mit dem Postfachreplikationsdienst). Prinzipiell ist Active Manager der Dirigent der integrierten Hochverfügbarkeitsfunktion von Exchange, denn diese Komponente entscheidet, welche Datenbankkopien aktiv sind und welche passiv, wobei sie auch die vom Administrator festgelegte Aktivierungspriorität berücksichtigt. Betrachten Sie Active Manager als Nachfolger des Ressourcenverwaltungsmodells, das in früheren Versionen der Exchange-Clustertechnologie verwendet wurde. Active Manager kann zwei verschiedene Rollen einnehmen. Ein Server in der Datenbankverfügbarkeitsgruppe kann die Rolle des primären Active Manager (PAM) übernehmen, während der andere als Standby-Active Manager (SAM) fungiert. Unabhängig davon, ob sie sich im PAM- oder im SAMModus befinden, überwachen die Server ständig die Datenbanken sowohl auf der Ebene des Informa442
tionsspeichers als auch auf der von ESE, um auf Ausfälle aufmerksam zu werden. Es ist jedoch der PAM, der festlegt, welche Datenbankkopie aktiv sein soll und welche passiv bleiben. Der SAM überwacht dagegen die Funktionsfähigkeit des Informationsspeicherprozesses und der Datenbanken auf dem lokalen Server. Sobald er eine Fehlfunktion des Informationsspeichers oder einer Datenbank auf seinem Server feststellt, fordert der SAM vom PAM einen Failover an (vorausgesetzt natürlich, dass die von dem Fehler betroffene Datenbank repliziert wurde und eine Kopie existiert, die durch den Failover aktiv geschaltet werden kann). Auslöser dafür kann z.B. ein Speicherfehler sein, durch den eine oder mehrere Festplatten offline gehen, oder ein Problem, aufgrund dessen ESE zu dem Schluss kommt, dass eine Festplatte nicht mehr reagiert. Wenn der Server mit dem PAM online ist, löst er den Failover aus. Ist jedoch gerade dieser Server aufgrund des Fehlers offline, übernimmt ein anderer Server in der Datenbankverfügbarkeitsgruppe die PAM-Rolle und schaltet die erforderlichen Datenbankkopien online, um den Service für die Clients wieder aufzunehmen. Der Server mit der PAM-Rolle ist für die Verarbeitung von Topologieänderungen innerhalb der Datenbankverfügbarkeitsgruppe verwantwortlich und muss auch entscheiden, wie mit einem Serverausfall umzugehen ist, indem er z.B. automatisch eine passive Kopie der betroffenen Datenbank aktiv schaltet. Der PAM-Server ist auch Besitzer des Quorums für die Standardclustergruppe, die die Grundlage der Datenbankverfügbarkeitsgruppe bildet. Wenn dieser Server ausfällt, geht die PAMRolle auf den Server über, der den Besitz über die Quorumressource übernimmt. Nach welchen Kriterien der PAM die zu aktivierende Datenbankkopie auswählt, werden wir in Kürze sehen. Sobald eine neue Datenbankkopie erfolgreich bereitgestellt wurde, aktualisiert der PAM den RPC-Clientzugriffsdienst mit Angaben über den Server, auf dem sich die neu aktivierte Kopie befindet, sodass die Clientverbindungen dorthin umgeleitet werden können. Die aktive Kopie einer Datenbank wird auch als Postfachdatenbankmaster bezeichnet. Eine Kopie kann durch zwei Vorgänge vom aktiven in den passiven Zustand wechseln: durch einen Switchover, den ein Administrator auslöst, z.B. bevor er einen Server offline schaltet, um ein Service Pack oder eine andere Form von Softwareaktualisierung anwendet, und durch einen Failover, der die Folge eines Hardwareoder Softwarefehlers ist, aufgrund dessen die Datenbank nicht mehr richtig funktioniert. In jedem Fall ist Active Manager dafür verantwortlich, die neue Kopie auszuwählen und zu aktivieren, die eingehende Clientanforderungen annehmen soll. Active Manager ist auch die maßgebliche Quelle von Informationen darüber, auf welchem Server die zurzeit aktive Kopie einer Datenbank bereitgestellt ist. Die Konfigurationsinformationen werden zurück in die Clusterdatenbank geschrieben und dort von Active Manager aktualisiert, während kurzlebige Informationen über den aktuellen Datenbankzustand im Arbeitsspeicher festgehalten werden. Mit dem Cmdlet Get-DatabaseAvailabilityGroup können Sie Informationen über eine Datenbankverfügbarkeitsgruppe abrufen, z.B. die Namen der Server in der Gruppe und des derzeitigen PAM-Servers. Das folgende Listing ist eine bearbeitete Version der Ausgabe von Get-DatabaseAvailabilityGroup, die die Eigenschaften einer Datenbankverfügbarkeitsgruppe zeigt. Sie können erkennen, dass die Gruppe aus den beiden Servern ExServer1 und ExServer2 besteht und dass ExServer1 zurzeit als PAM fungiert. Der Dateifreigabenzeuge befindet sich auf dem Server adroot.contoso.com. Get-DatabaseAvailabilityGroup –Identity 'DAG-Dublin' –Status | Format-List Name Servers WitnessServer WitnessDirectory AlternateWitnessServer AlternateWitnessDirectory
: : : : : :
DAG-Dublin {EXSERVER2, EXSERVER1} adroot.contoso.com C:\DAG-Dublin\FSW
443
Exchange auf dem Weg zur Hochverfügbarkeit
Active Manager
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
NetworkCompression NetworkEncryption DatacenterActivationMode StoppedMailboxServers StartedMailboxServers DatabaseAvailabilityGroupIpv4Addresses DatabaseAvailabilityGroupIpAddresses AllowCrossSiteRpcClientAccess OperationalServers PrimaryActiveManager ServersInMaintenance ThirdPartyReplication ReplicationPort NetworkNames WitnessShareInUse AdminDisplayName ExchangeVersion DistinguishedName
: : : : : : : : : : : : : : : : : :
Identity ObjectCategory
: :
ObjectClass OriginatingServer
: :
InterSubnetOnly InterSubnetOnly Off {} {} {} {} False {EXSERVER1, EXSERVER2} EXSERVER1 {} Disabled 64327 {DAGNetwork01} Primary 0.10 (14.0.100.0) CN=DAG-Dublin,CN=Database Availability Groups, CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups, CN=contoso,CN=Microsoft Exchange,CN=Services, CN=Configuration,DC=contoso,DC=com DAG-Dublin contoso.com/Configuration/Schema/ ms-Exch-MDB-Availability{top, msExchMDBAvailabilityGroup} ADRoot.contoso.com
Wenn der PAM ausfällt, übernimmt automatisch ein anderer Server in der Datenbankverfügbarkeitsgruppe seine Funktion und den Besitz über das Clusterquorum. Wenn Sie den Server mit der PAMRolle aus irgendeinem Grund offline schalten möchten, z.B. um eine Softwareaktualisierung oder einen Patch einzuspielen, können Sie das Clusterquorum auch auf einen anderen Server verschieben und damit die PAM-Rolle dorthin übertragen. Die internen Mechanismen von Active Manager und die Art und Weise, wie diese Komponente den Datenbankwechsel vornimmt, hält Microsoft unter Verschluss. Drittanbieter für Cluster- und Hochverfügbarkeitssoftware, die mit Exchange zusammenarbeiten soll, können ihre Produkte zwar so anpassen, dass sie von Active Manager Anweisungen für einen Wechsel entgegennehmen, es ist jedoch nicht möglich, diese Produkte auf einer tieferen Schicht mit Exchange zu verzahnen.
Automatischer Datenbankwechsel Abbildung 8.1 zeigt das Beispiel einer Datenbankverfügbarkeitsgruppe mit drei Servern, auf denen jeweils zwei Datenbanken untergebracht sind. Jede dieser Datenbanken wird auf einen anderen Server repliziert, um eine einfache Absicherung gegen Serverausfälle zu bieten. Wenn Server 1 ausfällt,
444
auf dem sich die aktiveren Kopien der Datenbanken 1 und 2 befinden, leitet der Active Manager-Prozess die Benutzerverbindungen zu den Datenbankkopien auf den Servern 2 und 3 um. Benutzer, die mit Datenbank 1 verbunden sind, werden zu Server 2 umgeleitet, diejenigen mit einer Verbindung zur Datenbank 2 zu Server 3. Fällt auf Server 1 nur die Festplatte mit Datenbank 2 aus, erkennt Active Manager dieses Problem und leitet die Verbindungen zu Server 3 um. In diesem Beispiel gibt es von jeder Datenbank nur eine weitere Kopie. Wenn für Sie das Risiko eines gleichzeitigen Ausfalls mehrerer Server vernachlässigbar gering ist, kann es ausreichen, neben der ursprünglichen Datenbank nur eine einzige Kopie vorzuhalten. Erstreckt sich die Datenbankverfügbarkeitsgruppe jedoch über mehrere Rechenzentren, werden Sie wahrscheinlich sämtliche Datenbanken auf alle Server replizieren. In dieser Situation würden sich Kopien der Datenbanken 1 und 2 auf Server 3 befinden, sodass die Benutzer bei einem gleichzeitigen Ausfall der Server 1 und 2 mithilfe der Kopien auf Server 3 auf ihre Daten zugreifen können. Wie viele Kopien Sie von einer einzelnen Datenbank anlegen können, hängt von der Anzahl der Server in der Datenbankverfügbarkeitsgruppe, dem Festplattenplatz und der Bandbreite ab. Angesichts der hohen Bandbreite, die in einem Rechenzentrum zur Verfügung steht, müssen Sie sich dort eher um den ausreichenden Festplattenplatz für die replizierten Datenbanken und Transaktionsprotokolle kümmern. Das sollte aber auch kein großes Problem sein, da Sie Datenbanken auf preisgünstigen Laufwerken bereitstellen können, sofern es genügend Platz in den Racks, eine ausreichende Stromversorgung und Kühlung für diese Platten gibt. Betrachten wir eine Beispielumgebung mit 15 Servern in einer Datenbankverfügbarkeitsgruppe. Es gibt 110 aktive Datenbanken, und jede verfügt über zwei passive Kopien, sodass sich insgesamt 330 Datenbanken ergeben. Jeder Server beherbergt 22 Datenbanken (aktive und passive) und reserviert 18 TB Speicherplatz für Postfachdatenbanken. Drei Ausfertigungen einer Datenbank zu unterhalten, stellt schon eine vernünftige Vorgehensweise dar, um sich gegen eine breite Palette von Fehlern abzusichern. Bei der Planung sollten Sie auch dafür sorgen, dass ein Fehler, der in einem Rack auftritt, keine Datenbank vollständig unzugänglich macht. Sie sollten also nicht sämtliche Server, die Kopien einer bestimmten Datenbank enthalten, im selben Rack unterbringen. Abbildg. 8.1
Datenbanken und Kopien in einer Datenbankverfügbarkeitsgruppe Datenbankverfügbarkeitsgruppe London MBXSvr1
MBXSvr2
MBXSvr3
MbxDb1
MbxDb3
MbxDb5
MbxDb2
MbxDb4
MbxDb6
MbxDb3
MbxDb1
MbxDb2
MbxDb5
MbxDb6
MbxDb4
445
Exchange auf dem Weg zur Hochverfügbarkeit
Active Manager
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Der Exchange-Replikationsdienst überwacht den Zustand der Datenbanken auf den einzelnen Mitgliedsservern der Datenbankverfügbarkeitsgruppe darauf, ob die aktive Datenbank tatsächlich bereitsteht und zugänglich ist und ob ESE E/A-Fehler oder Beschädigungen auf dem Server meldet. Wird ein Fehler festgestellt, benachrichtigt der Replikationsdienst Active Manager, woraufhin diese Komponente die beste verfügbare Kopie auswählt und anstelle der ausgefallenen Datenbank in den aktiven Zustand schaltet. Insidertipp: Kein Failover beim Aufheben der Bereitstellung einer aktiven Datenbank
Bevor wir uns im Einzelnen ansehen, wie der automatische Übergang von einer Datenbank zur anderen abläuft, müssen wir festhalten, dass Exchange einen solchen Wechsel nicht durchführt, wenn der Administrator die Bereitstellung der aktiven Datenbank aufhebt. Es wird davon ausgegangen, dass der Administrator diesen Vorgang absichtlich durchgeführt hat, um z.B. Wartungsarbeiten oder noch weniger spektakuläre Tätigkeiten wie die Aktivierung der Umlaufprotokollierung für eine Datenbank vorzunehmen. Daher hat Exchange keinen Grund, einen Failover durchzuführen, denn dieser Vorgang soll automatisch in Folge einer Änderung in der Betriebsumgebung stattfinden und nicht aufgrund eines Administratoreingriffs.
Auswahl der besten Kopie Um die Datenbank auszuwählen, die eine ausgefallene Kopie ersetzen soll, führt Active Manager den so genannten BCS-Prozess durch (Best Copy Selection). Dabei werden alle möglichen Schwierigkeiten und Sperren berücksichtigt, da es schließlich nicht sinnvoll ist, die Clientverbindungen auf eine Datenbank zu übertragen, die selbst nicht richtig funktioniert. Dazu wird eine Liste aller verfügbaren Datenbankkopien aufgestellt, von der folgende Datenbanken ausgenommen sind: 쐍 Datenbanken auf Servern, die zurzeit aus irgendwelchen Gründen unerreichbar sind (Netzwerkfehler, Wartung oder andere Umstände) 쐍 Datenbanken, deren Eigenschaft DatabaseCopyAutoActivationPolicy der Administrator mit dem Cmdlet Set-MailboxDatabaseServer auf Blocked gesetzt hat, um sie so von der Aktivierung auszuschließen Hoffentlich umfasst die verbleibende Liste noch wenigstens eine Kopie. Ist tatsächlich nur eine Kopie verfügbar, führt Active Manager den ACLL-Prozess (Attempt Copy Last Logs) aus, um sie auf den neuesten Stand zu bringen. Stehen mehrere Kopien bereit, fährt Active Manager mit dem BCS-Prozess fort und sortiert die Liste nach der Kopierwarteschlangenlänge. Dabei gelangt die Kopie mit den wenigsten ausstehenden Protokollübertragungen an die Spitze der Liste. Die Sortierung wird anhand des Wertes der Eigenschaft LastLogInspected durchgeführt, die angibt, wann die letzten Transaktionsprotokolldateien für die betreffende Datenbank untersucht wurden. Nach Abschluss dieses Vorgangs steht die Datenbankkopie am Anfang der Liste, für die nach der Aktivierung der geringste Aufwand notwendig ist, um sie auf den neuesten Stand zu bringen. Administratoren können jedoch auch dafür sorgen, dass bei einem Ausfall eine Datenbankkopie bevorzugt aktiviert wird. Dazu legen Sie die Eigenschaft ActivationPreference der gewünschten Kopie mit dem Cmdlet Set-MailboxDatabaseCopy fest. In einer Datenbankverfügbarkeitsgruppe mit Kopien in zwei Rechenzentren wird die bevorzugte Aktivierungsreihenfolge gewöhnlich so eingerichtet, dass erst versucht wird, die Kopien im lokalen Rechenzentrum zu aktivieren, bevor auf die im anderen zurückgegriffen wird. In einer solchen Situation können Sie mit dem folgenden Befehl den Wert für die Aktivierungspriorität für die Datenbankkopie DB1 auf Server ExServer1 auf 2 setzen:
446
Active Manager
Eine Datenbankkopie, die eine geringere Aktivierungspriorität hat, wird niemals vor einer Kopie mit höherer Priorität aktiviert, aber damit Exchange Ihre Prioritäten kennen kann, müssen Sie sie angeben. Um die Vorlieben des Administrators zu berücksichtigen, sortiert Active Manager die Liste nach der Aktivierungspriorität. Es kann jedoch sein, dass der Zustand einzelner Kopien nicht so gut ist, wie wir es gern hätten, weshalb Active Manager ihn sich anhand der folgenden Kriterien genauer ansieht: 쐍 Datenbankstatus Der bestmögliche Status ist Healthy (fehlerfrei), denn das bedeutet, dass die Datenbankkopie problemlos verfügbar ist. Die anderen möglichen Statuswerte sind DisconnectedAndHealthy, DisconnectedAndResynchronizing und SeedingSource. Sie zeigen an, dass noch mehr Arbeit zu erledigen ist, um die Datenbankkopie online zu bringen. 쐍 Inhaltsindex Auch hier ist der Status Healthy am besten, da er anzeigt, dass der gesamte Inhalt der Datenbank indiziert wurde. Beim Status Crawling ist Exchange noch dabei, Inhalte zu indizieren. 쐍 Kopiewarteschlangenlänge Am besten ist es, wenn die Warteschlange nicht mehr als zehn Transaktionsprotokolle enthält, die noch kopiert werden müssen, um die Datenbank auf den neuesten Stand zu bringen. 쐍 Länge der Wiedergabewarteschlange Auch hier ist es am besten, wenn die Warteschlange nicht zu lang ist, sondern weniger als 50 Protokolle enthält, die auf die Wiedergabe warten. Stehen mehr Protokolle in der Warteschlagen, muss ein größerer Aufwand betrieben werden, um die Datenbank online zu schalten. Active Manager geht die nach Aktivierungspriorität sortierte Liste durch und wählt eine Datenbankkopie mit fehlerfreiem Status und weniger als zehn Transaktionsprotokollen in der Kopie- und weniger als 50 in der Wiedergabewarteschlange aus. Gibt es keine Datenbank, die diesen Kriterien genügt, schraubt Active Manager die Ansprüche für die Aktivierung herunter und sucht nach einer Datenbankkopie mit dem Zustand Crawling für den Inhaltsindex. Wenn auch das nicht zu einem Ergebnis führt, werden das Niveau der Anforderungen noch weiter abgesenkt, bis endlich eine passende Datenbankkopie gefunden ist. Dabei kann es natürlich sein, dass Active Manager die Auswahlkriterien sehr stark herabsetzen muss, und dass die letztendlich ausgewählte Kopie eine geringe Aktivierungspriorität aufweist und sich vielleicht gerade im Reseeding befindet. Dann kann es viel Aufwand bedeuten, um die Kopie online zu schalten und den Service für die Clients wieder aufzunehmen. Es ist auch möglich, dass keine Datenbankkopie selbst den reduzierten Ansprüchen für die Aktivierung genügt. Wenn beispielsweise alle Kopien offline sind, kann Active Manager keine davon aktivieren, sondern meldet einen Fehler. In diesem Fall muss der Administrator entweder das Problem der ursprünglichen Datenbankkopie beheben, um sie wieder online zu schalten, oder sich um die Schwierigkeiten kümmern, die Active Manager daran hindern, eine der anderen Kopien zu aktivieren. Weitere Informationen
Eine Beschreibung sämtlicher Kriterien für die Aktivierung finden Sie im Artikel »Grundlegendes zu Active Manager« auf http://technet.microsoft.com/de-de/library/dd776123.aspx. Die Auswahl der besten Kopie ist in SP1 noch verbessert worden. Wenn die Eigenschaft AutoDatabaseMountDial einer Datenbank auf Lostless (verlustfrei) gesetzt ist, verwendet Active Manager die Aktivierungspriorität als ersten Sortierungsschlüssel. Dadurch wird die Wichtigkeit der vom Administrator festgelegten Aktivierungspriorität in Umgebungen hervorgehoben, in der ein Datenverlust beim Failover nicht akzeptabel ist. 447
Exchange auf dem Weg zur Hochverfügbarkeit
Set-MailboxDatabaseCopy –Identity 'DB1\ExServer1' –ActivationPreference 2
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
ACLL Wenn Active Manager eine Datenbankkopie gefunden hat, die für eine Aktivierung geeignet ist, weist er den Replikationsdienst auf dem Server an, den ACLL-Prozess (Attempt Copy Last Logs, also »Versuch, die letzten Protokolle zu kopieren«) durchzuführen, um alle noch fehlenden Transaktionsprotokolle von dem Server mit der ausgefallenen Datenbank zu kopieren. Im Gegensatz zum Protokollversand von Exchange Server 2007 hat Exchange Server 2010 hier offensichtlich mit größeren Schwierigkeiten zu kämpfen, da Kopien der Transaktionsprotokolle, die gebraucht werden, um die Datenbank auf den neuesten Stand zu bringen, auf weit mehr Servern vorhanden sein können als zuvor. Mit dem ACLL-Vorgang sollen alle in der Form von Transaktionsprotokollen verfügbaren Daten zusammengebracht werden, damit der Replikationsdienst die Datenbankkopie auf den neuesten Stand bringen kann, bevor sie bereitgestellt und den Benutzern zugänglich gemacht wird. Das beste Ergebnis zeigt sich, wenn alle ausstehenden Transaktionsprotokolle von dem Server kopiert werden können, auf dem sich die ausgefallene Datenbankkopie befindet, da der Replikationsdienst dann in der Lage ist, alle Protokolle einzuspielen, sodass die Kopie vollständig aktualisiert werden und ein verlustfreier Failover durchgeführt werden kann. Allerdings gehen Datenbanken oftmals gerade wegen eines Speicherfehlers offline. In diesem Fall kann auch die Festplatte mit den Transaktionsprotokollen betroffen sein, sodass der Replikationsdienst keine Protokolle kopieren kann. In diesem Fall wird der Wert der Eigenschaft AutoDatabaseMountDial auf dem Postfachserver herangezogen, um zu bestimmen, wie viel Datenverlust aufgrund fehlender Protokolle toleriert werden kann. VORSICHT Der Standardwert für die Einstellung AutoDatabaseMountDial auf einem Postfachserver mit Exchange Server 2010 lautet BestAvailability. Das bedeutet, dass der Postfachserver auch noch eine Datenbank bereitstellt, in der bis zu zwölf Transaktionsprotokolle fehlen, was einem möglichen Datenverlust von 12 MB entspricht. Wahrscheinlich handelt es sich bei den meisten dieser Daten um Nachrichten, die Exchange aus dem Transportpapierkorb wiederherstellen kann, weshalb es akzeptabel ist, die Datenbank bereitzustellen und einen kleinen Datenverlust zu riskieren. Andere mögliche Werte sind GoodAvailability, was die Toleranz auf sechs fehlende Transaktionsprotokolle drückt, und Lossless, was bedeutet, das überhaupt kein Datenverlust akzeptiert wird. Exchange stellt die Datenbank nicht automatisch bereit, wenn darin mehr Transaktionsprotokolle fehlen, als nach der Einstellung AutoDatabaseMountDial zulässig ist. In diesem Fall hat der Administrator zwei Möglichkeiten. Entweder erzwingt er die Bereitstellung der Datenbank und nimmt den Datenverlust in Kauf, oder er sucht in einer Sicherung (falls vorhanden) oder auf einem Server mit einer anderen Kopie der Datenbank nach den fehlenden Protokollen. Nach erfolgreichem Abschluss des ACLL-Vorgangs verfügt Active Manager über eine Datenbankkopie, die auf dem neuesten Stand ist und bereitgestellt werden kann. Als Nächstes sendet Active Manager daher eine Bereitstellungsanforderung, um die ausgewählte Datenbankkopie online zu stellen und den Clients zugänglich zu machen. Es erfolgen jedoch noch einige weitere Überprüfungen, um sicherzustellen, dass durch die Bereitstellung der Datenbank nicht die Maximalzahl aktiver Datenbanken auf dem Server überschritten wird und dass die Datenbank nicht für die Aktivierung gesperrt ist. Beide Umstände verhindern eine Aktivierung. Wie Sie die entsprechenden Einstellungen vornehmen, erfahren Sie weiter hinten in diesem Kapitel. Wird der ACLL-Vorgang nicht erfolgreich abgeschlossen, wählt Active Manager eine andere Datenbankkopie aus und beginnt erneut mit diesem Prozess. Diese Schleife wird wiederholt, bis eine Datenbankkopie erfolgreich aktiviert und bereitgestellt werden kann oder Active Manager das Ende der Liste verfügbarer Kopien erreicht und einen Fehler melden muss. 448
Wiedergabe des Transaktionsprotokolls: die Grundlage der Replikation von Datenbankverfügbarkeitsgruppen Innerhalb einer Datenbankverfügbarkeitsgruppe werden die auf dem aktiven Server angelegten Transaktionsprotokolle vom Replikationsserver auf die einzelnen Server übertragen, die passive Kopien unterhalten. Dort werden die Protokolle überprüft und dann wiedergegeben, um die passiven Kopien auf den neuesten Stand zu bringen. Die Datenbankverfügbarkeitsgruppe legt die Grenze für die Replikation der Transaktionsprotokolle fest. Sie können also keine Protokolle auf einen Server in einer anderen Datenbankverfügbarkeitsgruppe replizieren und dort in einer Kopie wiedergeben. Wenn Sie eine Datenbankkopie erstellen möchten, müssen sich also sowohl die ursprüngliche Datenbank als auch der Zielserver in derselben Datenbankverfügbarkeitsgruppe befinden. Auch ein Failover kann nur innerhalb einer Datenbankverfügbarkeitsgruppe erfolgen. Bei der Protokollreplikation gibt es einige erhebliche Unterschiede zwischen Exchange Server 2007 und 2010. Als Erstes ist der Datenfluss zwischen den Servern zu nennen. Exchange Server 2010 verwendet die Streaming-API von ESE, um für eine Datenbank ein Seeding durchzuführen, und ungekapselte TCP-Sockets für die Übertragung der Protokolle zwischen Quell- und Zielserver. Dagegen wurden in Exchange Server 2007 SMB-Übertragungen (Server Message Block) vorgenommen. Außerdem verwendete Exchange Server 2007 eine SMB-Sitzung für alle Datenbanken auf einem Server, Exchange Server 2010 dagegen ein TCP-Socket pro Datenbank. Diese Änderung war zwar hauptsächlich aus dem Grund erforderlich, dass es jetzt mehrere Kopien einer Datenbank geben kann, doch fördert sie auch die Skalierbarkeit. Wenn Sie eine Datenbankverfügbarkeitsgruppe erstellen, können Sie den zu verwendenden TCP-Port auswählen und festlegen, dass IPsec und eine Komprimierung verwendet werden, um die Daten zu schützen und das Übertragungsvolumen zu verringern. Dadurch soll die Wirtschaftlichkeit der Übertragungen verbessert werden. Die Konfiguration von IPsec findet jedoch in Windows statt, nicht in Exchange. Die zweite Änderung besteht darin, dass der Server mit der aktiven Datenbankkopie jetzt die Transaktionsprotokolle zu den Servern mit den Kopien übertragt. In Exchange Server 2007 hatte nur ein Server eine Kopie, weshalb es sinnvoll war, dass dieser Server die Transaktionsprotokolle anforderte. Als dritte Änderung ist es jetzt der Informationsspeicher, der die Transaktionsprotokolle wiedergibt, und nicht mehr der Exchange-Replikationsdienst. Dadurch wird dafür gesorgt, dass die Datenbanken sofort auf Clientanforderungen reagieren können, wenn ein Wechsel erforderlich ist. Die Transaktionen wurden auch in Exchange Server 2007 wirkungsvoll eingespielt, aber da dieser Vorgang außerhalb des Informationsspeichervorgangs stattfand, konnte dabei nicht der Cache für die jüngsten Transaktionen im Arbeitsspeicher berücksichtigt werden. Der Cache ist also »kalt«: Wenn ein Client Daten anfordert, muss der Informationsspeicher sie nicht sofort aus dem Cache abrufen, sondern muss sie erst von der Festplatte lesen, was mit einem gewissen E/A-Aufwand verbunden ist. Bei einem Datenbankwechsel dauert es daher gewisse Zeit, bis der Informationsspeicher so schnell auf Clientanforderungen reagieren kann, wie es bei einem gut gefüllten Cache möglich ist. Von diesen Unterschieden abgesehen erfolgen die Replikation und Wiedergabe der Transaktionsprotokolle in Exchange Server 2010 im Grunde genommen genauso wie in der vorherigen Version. Der Exchange-Replikationsdienst setzt sich aus einer Reihe von Komponenten zusammen, die gemeinsam dafür sorgen, dass Replikation und Wiedergabe reibungslos verlaufen.
449
Exchange auf dem Weg zur Hochverfügbarkeit
Wiedergabe des Transaktionsprotokolls
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
쐍 Die Kopierkomponente (Copier) auf dem aktiven Server kopiert die geschlossenen Protokolldateien von der Datenbank zum Speicherort des Inspektors auf den einzelnen Servern, die über eine Datenbankkopie verfügen. Dieser Prozess ist asynchron und wird fortlaufend durchgeführt, wenn neue Protokolle erstellt werden. Wenn der Informationsspeicher die aktuelle Protokolldatei schließt, umbenennt und zu einer neuen wechselt, wird die bisherige aktuelle Protokolldatei für den Kopiervorgang verfügbar. 쐍 Die Inspektorkomponente (Inspector) auf dem Server mit der Kopie untersucht regelmäßig ihr Verzeichnis, um neue Protokolle aufzuspüren. Anschließend überprüft sie diese Protokolle auf Gültigkeit und verschiebt die gültigen Dateien in das Wiedergabeverzeichnis. Besteht ein Protokoll die Gültigkeitsprüfung nicht, kopiert der Inspektor es erneut, damit die fortlaufende Replikation nicht durch vorübergehende Umstände (z.B. Netzwerkfehler) gestört wird. Wenn Exchange ein Protokoll nicht erneut kopieren kann, muss für die betroffene passive Datenbankkopie ein erneutes Seeding durchgeführt werden. 쐍 Die Wiedergabekomponente (Log Replayer) spielt den Inhalt der kopierten Protokolle ein, um die Datenbankkopie auf den neuesten Stand zu bringen. Dabei tritt die gleiche Art der Verarbeitung auf, wie sie auch der Informationsspeicher für die weiche Datenbankwiederherstellung nach einem unerwarteten Serverausfall einsetzt. Der Informationsspeicher gibt die Protokolle alle 60 Sekunden oder nach dem Eingang von zehn neuen Protokollen wieder. 쐍 Die Löschkomponente (Truncate Deletor) entfernt die Protokolldateien, die die Wiedergabekomponente erfolgreich zum Aktualisieren der Datenbank verwendet hat. Bei einer vollständigen Onlinesicherung von Exchange-Datenbanken wurden früher die Protokolldateien gelöscht, aber bei der fortlaufenden Replikation sorgt diese Komponente dafür, dass die noch nicht wiedergegebenen Dateien nicht entfernt werden. 쐍 Die Komponente für das inkrementelle Seeding (Incremental Seeder) sorgt dafür, dass der Status der einzelnen Datenbanken nach einer Wiederherstellung oder einem Failover nicht voneinander abweicht. Wenn Sie sich in der Exchange-Verwaltungskonsole eine Datenbank mit Kopien anschauen (siehe Abbildung 8.2), können Sie unmittelbar erkennen, ob die Replikation reibungslos verläuft. In diesem Beispiel sehen Sie, dass sich die aktive Kopie der Datenbank auf dem Server ExServer1 befindet und eine andere Kopie auf ExServer2. Die Kopie ist als fehlerfrei gekennzeichnet, was bedeutet, dass Exchange diese Kopie falls nötig aktivieren kann. Die Kopierwarteschlange enthält die Protokolle, die nach darauf warten, vom aktiven Server auf den mit der Kopie übertragen zu werden. In diesem Beispiel ist das nur ein einziges. Dagegen stehen in der Wiedergabewarteschlange die Protokolle, die zwar übertragen, aber noch nicht in die Zieldatenbank eingespielt worden sind. Hier sind es sechs. Was Ihnen die Exchange-Verwaltungskonsole über die Replikationsaktivität anzeigt, ist eine statische Momentaufnahme, die nur für den Augenblick gilt, an dem die Konsole zuletzt Informationen über die Datenbank abgerufen hat. Um die Aktivität zum aktuellen Zeitpunkt zu sehen, müssen Sie auf Aktualisieren klicken, damit die Konsole den Befehl Get-MailboxDatabase -Status ausführt und die jüngsten Statusinformationen über die ausgewählte Datenbank abruft. Manchmal ist es jedoch bequemer, sich den Zustand der Replikation mit dem Cmdlet Get-MailboxDatabaseCopyStatus anzusehen: Get-MailboxDatabaseCopyStatus –Identity 'DB1\ExServer2' Name
CopyQueue Length -------------- ----------DB1\ExServer2 Healthy 1
450
Status
ReplayQueue Length ----------3
LastInspectedLogTime ContentIndex State ------------------- -------------3/15/2010 9:23:10 AM Healthy
Wiedergabe des Transaktionsprotokolls
Anzeigen des Kopierstatus von Datenbanken in einer Datenbankverfügbarkeitsgruppe
Exchange auf dem Weg zur Hochverfügbarkeit
Abbildg. 8.2
Insidertipp: Anzahl der Protokolle in den Warteschlangen
Die Anzahl der Protokolle in der Wiedergabe- und der Kopierwarteschlange schwankt je nach Clientaktivität. Relativ geringe Zahlen wie hier sind kein Grund zur Sorge. Allerdings sollten Sie sich Gedanken machen, wenn die Anzahl der Protokolle in den Warteschlangen mit der Zeit wächst oder wenn sie auch bei sinkender Belastung des Servers nicht geringer wird, denn das ist ein Hinweis darauf, dass die Replikation oder Wiedergabe gestört ist oder dass es irgendeine Quelle anomaler Belastung gibt. Beispielsweise wird eine Datenbank stark belastet, wenn Sie Postfächer verschieben – bei einem Postfach von 2 GB Größe werden dabei mindestens 2000 Transaktionsprotokolle erstellt. Der Postfachreplikationsdienst kann bis zu fünf Postfächer gleichzeitig verarbeiten. Wenn Sie das ausnutzen und fünf große Postfacher zu derselben Zieldatenbank mit Kopien in einer Datenbankverfügbarkeitsgruppe verschieben, dann rufen Sie eine enorme Belastung für die CPU (Verarbeitung der eingehenden Daten einschließlich Aktualisierung des Inhaltsindex) und des Speicherteilsystems hervor. Die Replikationsaktivität steigt mit dem Aufkommen an Transaktionsprotokollen, wobei sich wahrscheinlich lange Warteschlangen ergeben. Die Ausgabe zeigt, dass die Kopier- und die Wiedergabewarteschlange eine akzeptable Länge aufweisen und dass die letzte Protokolluntersuchung nicht zu lange her ist (bei geringer Benutzeraktivität kann es sein, dass sich die Replikationsaktivität auf die Protokolldateien beschränkt, die alle 15 Minuten infolge eines Generationswechsels erstellt werden). Außerdem können wir erkennen, dass der Inhaltsindex der Kopie fehlerfrei ist. Die Elemente wurden alle während der Wiedergabe der Transaktionsprotokolle in die Datenbankkopie korrekt indiziert. Es ist wichtig, dass die Inhaltsindizierung funktioniert, da Active Manager den Zustand des Index bei der Auswahl der zu aktivierenden Kopien berücksichtigt.
451
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Insidertipp: Was geschieht bei starker Belastung – und was tun Sie dagegen?
Eine starke Belastung des Zielservers durch eine Verschiebung von Postfächern hat gewöhnlich zwei Folgen. Erstens sind alle Server mit Kopien der Zieldatenbank belastet, sodass die Benutzer einen Leistungsabfall verspüren, bis der Postfachverschiebevorgang seinem Ende entgegengeht. Zweitens kann es sein, dass Exchange den Verschiebevorgang anhält, in den Status StalledDueToHA versetzt und erst dann wieder aufnimmt, wenn die Serverbelastung geringer geworden ist und die Replikationswarteschlangen geleert sind. Den Status können Sie überprüfen, indem Sie sich mit dem Cmdlet Get-MoveRequestStatistics die Verschiebewarteschlange ansehen. Der Status StalledDueToHA zeigt an, dass Exchange die Verarbeitung von Verschiebeanforderungen aussetzt, bis die Wiedergabewarteschlange abgearbeitet ist. Damit wird die Anzahl ausstehender Transaktionen verringert und die Hochverfügbarkeit erhalten. Daher ist es wichtig, das Verschieben von Postfächern für Zeiten einzuplanen, in denen die Server nur gering belastet sind und die zusätzliche Last durch das Verschieben der Daten von den Quell- zu den Zielservern verkraften können. Außerdem sollten Sie die Belastung durch die Verschiebevorgänge besser verteilen, indem Sie dafür sorgen, dass keine Datenbank zum Ziel von mehr als drei oder vier gleichzeitigen Verschiebevorgängen wird. Bevor der Informationsspeicher die Transaktionsprotokolle in der Datenbankkopie wiedergibt, stellt er sicher, dass die Prüfsumme und die Datenbanksignatur der Protokolle gültig sind. Das entspricht der Ausführung von ESEUTIL mit der Option /K. Ist die Prüfsumme ungültig, kopiert Exchange das Protokoll erneut. Wenn der Versuch, ein Protokoll zu kopieren und die Prüfsumme zu validieren, dreimal fehlschlägt, ist das ein Zeichen dafür, dass im Speicherteilsystem ein schwerwiegender Fehler vorliegt, der zu einer physischen Beschädigung führt. In einem solchen Fall muss wahrscheinlich ein erneutes Seeding der Datenbank durchgeführt werden. Viele Probleme beschränken sich auf ein einziges Postfach
Durch die ständige Hintergrundwartung zur Reparatur beschädigter Seiten in einer Datenbank und die Überprüfung der Transaktionsprotokolle während der Replikation sorgt Exchange sehr gut dafür, dass sich physische Beschädigungen aufgrund von Speicherproblemen nicht auf mehrere Datenbankkopien übertragen. Wenn eine Seite so beschädigt ist, dass sie sich durch die Hintergrundwartung nicht mehr reparieren lässt, wird dieser Fehler entdeckt, sobald der Replikationsprozess das Transaktionsprotokoll mit der betroffenen Seite überprüft. Es kann sein, dass eine logische Beschädigung aufgrund eines Softwarebugs durch die Maschen schlüpft, da ein solcher Fehler die Prüfsumme nicht beeinträchtigt. Aufgrund des neuen Schemas jedoch wirkt sich ein solches Problem mit hoher Wahrscheinlichkeit nur auf ein einzelnes Postfach aus (früher konnte eine logische Beschädigung in einer Tabelle viele Postfächer betreffen). In einem solchen Fall ist jedoch eine Wiederherstellung von einer Sicherung oder einer verzögerten Datenbankkopie möglich. Nachdem der Replikationsdienst ein Transaktionsprotokoll überprüft hat, verschiebt er es in das Protokollverzeichnis. Anschließend gibt der Informationsspeicher die Protokolle wieder, um die Datenbankkopie zu aktualisieren. Dieser Vorgang ähnelt der weichen Wiederherstellung, die auftritt, wenn Exchange eine Datenbank nach der Bereitstellung aktualisieren muss. Eine weitere Ähnlichkeit besteht mit der Ausführung von ESEUTIL /R, allerdings erfolgt der Vorgang, den wir uns hier ansehen, schneller, da Exchange versucht, die Protokolldateien im Stapel zu verarbeiten, um die Transaktionen in die Datenbank zu übernehmen. Für die Wiedergabe der Protokolle sorgt eine separate Instanz von ESE, die innerhalb des Informationsspeicherprozesses ausgeführt wird. Die Wiedergabe erfolgt in der Reihenfolge der Generationen. Wenn beispielsweise der Replikationsdienst die Protokollgeneration 1876 kopiert und der Informationsspeicher gerade die Generation 1873 wiedergibt, 452
muss Generation 1876 zunächst warten, bis die Protokolle der Generation 1874 und 1875 eingespielt sind. Ansonsten könnten Transaktionen, die sich über mehrere Protokollgenerationen erstrecken, nicht korrekt wiedergegeben werden. TIPP Vorübergehende Störungen können dazu führen, dass die Netzwerkverbindung zwischen den Servern eine gewisse Zeit lang nur eine geringere Kapazität aufweist oder ganz ausfällt. Unter solchen Umständen wachsen die Warteschlangen für die Transaktionsprotokolle, die auf die nicht erreichbaren Server repliziert werden müssen. Sobald das Netzwerk wieder störungsfrei funktioniert, wird der Rückstau in der Replikation abgearbeitet, sodass die Datenbankkopien auf den Servern auf den neuesten Stand kommen. Ein erneutes Seeding ist in solchen Fällen nicht erforderlich. Es kann sein, dass der Replikationsdienst einzelne Protokolle bei der Aktualisierung ignoriert, beispielsweise wenn sie aus irgendeinem Grund zu alt sind, um auf die Datenbankkopie angewendet zu werden, oder weil sie Beschädigungen aufweisen. Solche Protokolle werden in das Verzeichnis IgnoredLogs verschoben und können gelöscht werden. In diesem Verzeichnis können sich die beiden Unterverzeichnisse E00OutOfDate und InspectionFailed befinden. In den ersten gelangen E00.log-Dateien, die noch aus der Zeit vor einem Failover übrig sind, als die jetzige passive Kopie noch als aktive Kopie ausgeführt wurde. Bei einem Failover erstellt der Informationsspeicher eine neue E00.log-Datei, die als aktuelles Transaktionsprotokoll dient. Wenn er also bereits eine solche alte Datei im Verzeichnis der jetzigen passiven Kopie vorfindet, verschiebt er sie in das Verzeichnis E00OutOfDate, um sie aus dem Weg zu bekommen. Das Verzeichnis InspectionFailed ist für Protokolldateien da, die die Inspektorkomponente abgelehnt hat, z.B. weil der Informationsspeicher sie nicht lesen kann oder weil die Signatur im Header ungültig ist.
Komprimierung des Transaktionsprotokolls Anhand der bisherigen Beschreibungen können Sie schon erkennen, dass Exchange eine große Menge an Transaktionsprotokollen zwischen den Servern in einer Datenbankverfügbarkeitsgruppe überträgt, um alle Datenbanken synchron zu halten. Um die Auswirkungen auf das Netzwerk möglichst gering zu halten, hat Microsoft einige Änderungen an der Art und Weise vorgenommen, wie Daten in Transaktionsprotokolle geschrieben werden. Die Verarbeitung läuft jetzt in folgender Reihenfolge ab: 1. ESE komprimiert alle Nachrichtenheader und HTML- bzw. Textrümpfe, bevor diese Daten in die
Transaktionsprotokolle geschrieben werden. 2. Die 1 MB großen Transaktionsprotokolle werden bei der Replikation auf die Server in der Daten-
bankverfügbarkeitsgruppe komprimiert. 3. Die Transaktionsprotokolle werden dekomprimiert, bevor sie auf die Zielfestplatte für die Repli-
kation geschrieben werden. 4. Die Nachrichtenheader und -texte werden dekomprimiert, wenn Clients vom Informations-
speicher den Zugriff auf diese Daten anfordern. Nach Ansicht von Microsoft soll diese Form der Verarbeitung den Datenverkehr aufgrund der Übertragung von Transaktionsprotokollen um etwa 20% senken (wobei der Wert je nach den Bedingungen der Umgebung schwanken kann). Ebenso wurde die Durchführung des Generationswechsels nach einem festgelegten Zeitraum geändert. Der Generationswechsel dient dazu, dass die Replikation auch im »Leerlauf« ständig weitergeht, damit die Datenbanken stets synchron bleiben. Auf einem Computer mit Exchange Server 2007 läuft alle 90 Sekunden ein Timer ab. woraufhin der Informationsspeicher prüft, ob in diesem Zeitraum Seiten modifiziert wurden (sie es durch Benutzeranforderungen 453
Exchange auf dem Weg zur Hochverfügbarkeit
Wiedergabe des Transaktionsprotokolls
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
oder einen Serverprozess wie die Hintergrundwartung). Hat tatsächlich eine Datenbanktätigkeit stattgefunden, erstellt der Informationsspeicher ein neues Transaktionsprotokoll, selbst wenn noch nicht genügend Seiten modifiziert worden sind, um eine komplette Protokolldatei zu füllen. Bei der Verwendung eines 90-Sekunden-Timers kann ein inaktiver Server also täglich bis zu 960 Generationswechsel (pro Speichergruppe) vollziehen, die in Umgebungen mit fortlaufender Cluster- oder Standbyreplikation auf die Zielserver übertragen werden müssen. Dabei können bis zu 10% des gesamten Replikationsverkehrs aufgrund von leeren Protokollen zustande kommen. Eine Änderung dieses Verhaltens kann den Datenverkehr aufgrund leerer Protokolle natürlich nur für inaktive Server verringern und zeigt keine Auswirkungen, wenn die Server rund um die Uhr beschäftigt sind. Doch auch hier zeigt sich, dass Microsoft die Protokollreplikation aufgrund der Erfahrungen mit Exchange Server 2007 optimiert hat.
Blockreplikation Die Blockreplikation ist eine in Exchange Server 2010 SP1 neu eingeführte Funktion, die die Zeitspanne zwischen dem Auftreten einer Transaktion in einer aktiven Datenbank und ihrer Übertragung und Wiedergabe in allen Datenbankkopien verkürzen soll. Durch eine Beschleunigung der Replikation soll die Gefahr eines Datenverlustes für den Fall verringert werden, dass zwischen dem Ablauf der Transaktion und ihrer Wiedergabe in der Kopie ein Failover nötig wird. In dieser Hinsicht stellt die Transaktion eine neuralgische Schwachstelle dar, die Microsoft beseitigen muss, um echte Hochverfügbarkeit zu erreichen. Exchange Server 2010 muss sich darauf verlassen können, dass sämtliche Transaktionsprotokolle repliziert und wiedergegeben werden, um die Datenbankkopien auf dem neuesten Stand zu halten. Das aktuelle Transaktionsprotokoll ist jedoch gesperrt, und die darin enthaltenen Daten sind unzugänglich. Exchange Server 2010 setzt nach wie vor die Replikation von Transaktionsprotokollen ein, aber die Kopierkomponente enthält jetzt neuen Code, der den Status der Replikation überwacht und erkennen kann, was es sicher ist, die Daten, die aus dem Cache auf die Festplatte geschrieben werden, blockweise zu replizieren. »Sicher« bedeutet in diesem Zusammenhang, dass die dateiweise Replikation nicht gestört wird und die Datenbankkopien fehlerfrei bleiben. Postfachserver mit Exchange Server 2010 SP1 gehen dazu folgendermaßen vor: 쐍 Die Replikation erfolgt zu Anfang dateiweise. Wenn ein Server online geht, nimmt er Kontakt mit den Servern auf, auf denen sich aktive Kopien seiner eigenen Datenbanken befinden, und fordert die Replikation aller Protokollgenerationen an, die ihm noch nicht vorliegen. 쐍 Die Server mit den aktiven Datenbanken übertragen die Kopien aller ausstehenden Protokolle. 쐍 Der Server gibt die Protokolle wieder, um seine Datenbankkopien zu aktualisieren. 쐍 Wenn eine Datenbankkopie auf dem neuesten Stand ist (wenn also als Nächstes das aktuelle Transaktionsprotokoll erforderlich wäre), schaltet Exchange in den blockweisen Replikationsmodus um. 쐍 Im Blockmodus überträgt die Kopierkomponente die Daten, die in den ESE-Protokollpuffer geschrieben werden (den 1-MB-Cache, in dem die Transaktionen auflaufen, bevor sie in das Protokoll geschrieben werden), parallel auf alle Server, die eine Kopie der betreffenden Datenbank unterhalten. Dort werden die Daten in ähnliche Protokollpuffer geschrieben. 쐍 Wenn der Protokollpuffer auf dem empfangenden Server voll ist, wird sein kompletter Inhalt in ein Transaktionsprotokoll geschrieben. Dieses neue Protokoll wird auf Beschädigungen überprüft und in die Kette der Protokolle eingefügt, die in die passive Datenbank eingespielt werden müssen. 454
쐍 Die Replikation fährt im Blockmodus fort, bis sich vier Protokolle in der Wiedergabewarteschlange auf dem Server angesammelt haben. An dieser Stelle schaltet Exchange automatisch zurück in den Dateimodus, der beibehalten wird, bis die Wiedergabewarteschlange geleert ist und wiederum das aktuelle Protokoll zur Wiedergabe erforderlich ist. Dann geht Exchange wieder in den Blockmodus über. Sowohl für die Blockreplikation als auch zum Kopieren der Transaktionsprotokolle werden dieselben Datenpfade verwendet. Letztere werden nach wie vor auf die Server übertragen, damit die Datenbankkopien die vollständige Datenmenge zur Verfügung haben. Der Vorteil des Blockmodus besteht darin, dass die Transaktionen sofort weitergeleitet werden, nachdem sie im Protokollpuffer der aktiven Datenbank zur Verfügung stehen. Ein Generationswechsel ist nicht erforderlich, und die Transaktionsdaten treffen auf den Servern mit den passiven Kopien so schnell ein, wie der Server mit der aktiven Datenbank sie über das Netzwerk übermitteln kann. HINWEIS Da die Replikation der Protokolldateien weitergeht und die Protokolle sowohl auf dem sendenden als auch auf dem empfangenden Server überprüft werden (wird diese Prüfung nicht bestanden, muss das Protokoll erneut geschrieben werden), gibt es nicht mehr wie früher die Gefahr eines Fehlers aufgrund eines beschädigten Transaktionsprotokolls. Eine einzelne Transaktion kann auf eine Datenbankseite von 32 KB passen. Neue Daten erreichen die Server mit den Datenbankkopien offensichtlich schneller, wenn die Kopierkomponente nur auf eine 32-KB-Seite warten und diese kopieren muss und nicht ein komplettes Transaktionsprotokoll von 1 MB. Bei den Transaktionen für umfangreiche Nachrichten mit mehreren Megabyte ist dieser Vorteil nicht so deutlich, da hierzu mehrere Transaktionsprotokolle repliziert werden müssen. Wenn jedoch genügen kleine Transaktionen vorhanden sind, die nicht mehr als eine Seite einnehmen, kann der Blockmodus die Zeit für die Replikation insgesamt erheblich verkürzen. Aufgrund der Blockreplikation ändert sich auch der Aktivierungsvorgang, mit dem Exchange eine passive Datenbankkopie online schaltet. Bei der Verwendung der Blockreplikation verwendet Exchange bei einem Failover sämtliche verfügbaren Teilinhalte von Protokollen, um ein vollständiges Transaktionsprotokoll zusammenzustellen, mit dem die zu aktivierende Kopie auf den neuesten Stand gebracht wird. Dadurch ist sichergestellt, dass die neue aktive Kopie alle verfügbaren Daten hat, wenn sie online geht. Wenn der ausgefallene Server später wieder online geht, kann der Code für das inkrementelle Reseeding alle Abweichungen auflösen, die zwischen dem zur Aktualisierung der neuen aktiven Datenbank verwendeten Fragment und den Daten bestehen, die bei einer vollständigen Replikation übertragen worden wären. Das übliche Vorgehen bei solchen Abweichungen besteht darin, die gesamte Protokollgeneration, zu der das Fragment gehörte, erneut zu kopieren. Darin sind dann alle Informationen vorhanden. Sobald das fehlende Protokoll übertragen worden ist, kann es in den anderen Datenbankkopien wiedergegeben werden, damit alle über dieselben Informationen verfügen.
Abschneiden der Transaktionsprotokolle Auf stark belasteten Postfachservern werden sehr viele Transaktionsprotokolle erstellt. Wenn für eine Datenbank die Umlaufprotokollierung nicht aktiviert ist, sammeln sich die Transaktionsprotokolle an, bis sie vom Informationsspeicher abgeschnitten oder vom Administrator manuell gelöscht werden. Das Abschneiden der Protokolle für Datenbanken ohne Umlaufprotokollierung erfolgt gewöhnlich nach einer erfolgreichen Sicherung. Der Informationsspeicher kann dann alle Transaktionsprotokolle entfernen, die nicht mehr gebraucht werden, weil ihre Inhalte in die Sicherungskopie der Datenbank übertragen wurden. 455
Exchange auf dem Weg zur Hochverfügbarkeit
Wiedergabe des Transaktionsprotokolls
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Bei aktivierter Umlaufprotokollierung verwendet der Informationsspeicher eine geringere Menge von Protokollen für die Transaktionen, deren Commit in der Datenbank noch aussteht. Sobald für die Transaktionen in einem Protokoll ein Commit stattfindet und der Prüfpunkt eine Protokollgeneration weiter geschoben wurde, kann der Informationsspeicher die Protokolldatei löschen. Je nach Aktivität der Datenbank muss der Informationsspeicher dadurch nur mit einem Satz von fünf bis zehn Transaktionsprotokollen umgehen. Wird die Umlaufprotokollierung für Datenbanken in einer Datenbankverfügbarkeitsgruppe genutzt, sind die Verhältnisse jedoch noch ein wenig anders. Von einer Datenbank kann es innerhalb der Gruppe mehrere Kopien geben, weshalb der Informationsspeicher auf keinen Fall irgendetwas tun darf, was einen Datenverlust hervorrufen könnte. Ein Transaktionsprotokoll kann erst dann auf einem Server gelöscht werden, wenn sichergestellt ist, dass es von keiner anderen Datenbankkopie mehr gebraucht wird. Nehmen wir beispielsweise an, eine Datenbank ist offline, da der Server für Wartungsarbeiten ausgeschaltet wurde. Unter solchen Umständen bewahrt der Informationsspeicher die Transaktionsprotokolle so lange auf, bis er sicher sein kann, dass sie nie wieder gebraucht werden. Dazu arbeitet er die folgende Checkliste ab. Die Transaktionsprotokolle für Datenbanken ohne verzögerte Kopien (wozu verzögerte Kopien nützlich sind, erfahren Sie im Abschnitt »Verzögerte Datenbankkopien« weiter hinten in diesem Kapitel) werden abgeschnitten, wenn alle folgenden Fragen mit Ja beantwortet werden können: 쐍 Wurde die Protokolldatei gesichert oder ist die Umlaufprotokollierung aktiviert? 쐍 Weist die Protokollgeneration einen geringeren Wert auf als der Prüfpunkt der Datenbank? 쐍 Wurde die Protokolldatei erfolgreich auf allen anderen Datenbankkopien wiedergegeben? 쐍 Wurde die Protokolldatei auf Servern mit verzögerten Kopien überprüft? Verfügt die Datenbank über eine verzögerte Kopie, wird stattdessen die folgende Variante der Checkliste verwendet: 쐍 Weist die Protokollgeneration einen geringeren Wert auf als der Prüfpunkt der Datenbank? 쐍 Ist die Protokolldatei älter, als die für die verzögerten Kopien festgelegten Verzögerungszeiten für Wiedergabe und Abschneiden angeben? 쐍 Wurde die Protokolldatei auf der aktiven Kopie gelöscht? Wenn alle diese Überprüfungen zu einem positiven Ergebnis führen, weiß der Informationsspeicher, dass das Transaktionsprotokoll nicht mehr benötigt ist, sodass er es löscht. Anderenfalls bewahrt er es auf, bis alle Bedingungen erfüllt sind. Beachten Sie, dass Sie bei verzögerten Kopien genügend Speicherplatz zur Verfügung stellen, um alle während der festgelegten Zeit erstellten Protokolle festzuhalten. Wenn Sie die verzögerte Kopie so einrichten, dass die Protokolle für 14 Tage und länger aufbewahrt werden, müssen Sie wahrscheinlich mehrere Gigabyte an Speicher für diesen Zweck reservieren. Wie viele Transaktionsprotokolle für eine Datenbank aufbewahrt werden, hängt davon ab, wie schnell sie innerhalb der Datenbankverfügbarkeitsgruppe repliziert und in den Kopien wiedergegeben werden. Machen Sie sich keine Sorgen, wenn sich die Transaktionsprotokolle für eine Datenbankkopie zeitweilig anhäufen, denn es kann sein, dass die Datenbank auf die Aktualisierung anderer Kopien wartet, bis sie die Protokolle abschneiden kann, was möglicherweise einige Stunden dauern kann. Wenn die Anzahl der Protokolle jedoch ständig ansteigt und auch nicht wieder zurückgeht, wenn die Belastung geringer ist und weniger neue Protokolle erstellt werden, sollten Sie jedoch nach der Ursache für dieses Verhalten forschen.
456
Inkrementelle Neusynchronisierung Es wäre schön, wenn beim Kopieren der Transaktionsprotokolle von einem Server auf die anderen und bei ihrer Wiedergabe zur Aktualisierung der Datenbanken alles reibungslos verlaufen würde, doch leider gibt es immer die Möglichkeit von Störungen. Damit Exchange die Datenbankkopien auch dann noch verfügbar halten kann, wenn eines oder mehrere der letzten Transaktionsprotokolle verloren gegangen, beschädigt oder auf andere Weise unzugänglich sind, verfügt Exchange Server 2007 über eine Funktion zur Absicherung gegen verlorene Protokolle (Lost Log Resilience, LLR) und für das inkrementelle Reseeding. Die LLR-Funktion gestattet Exchange, eine Datenbank selbst dann bereitzustellen, wenn sie aufgrund fehlender Protokolle nicht vollständig aktualisiert werden konnte. Dabei werden die Schreibvorgänge in der Datenbank verzögert, bis die fehlenden Protokollgenerationen erstellt sind. In Exchange Server 2007 konnten Sie die Anzahl der Protokolle festlegen, doch in Exchange Server 2010 beträgt der Wert unveränderlich 1. Das ist einer der Gründe, aus denen in Exchange Server 2010 die Anzahl leerer Transaktionsprotokolle verringert wurde. Durch das inkrementelle Reseeding kann der Informationsspeicher Abweichungen im Transaktionsdatenstrom zwischen der aktiven und der passiven Datenbankkopie korrigieren. Diese Funktionen erwiesen sich in der Praxis als sehr nützlich, wiesen allerdings auch einige Mängel auf. Beispielsweise stützt sich das inkrementelle Reseeding auf die Fähigkeiten von LLR zur verzögerten Wiedergabe, weshalb eine passive Datenbankkopie nicht repariert werden konnte, nachdem die abweichenden Protokolle eingespielt worden waren. In diesem Fall mussten Sie für die Datenbank ein vollständiges Reseeding durchführen. Bei großen Datenbanken war das für Administratoren keine sinnvolle Möglichkeit. In Exchange Server 2010 gibt es jetzt eine geänderte und verbesserte Funktion namens inkrementelle Neusynchronisierung, die automatisch Abweichungen zwischen Datenbankkopien beseitigt. Allerdings kann eine automatische Korrektur nur unter bestimmten Umständen stattfinden, in denen Exchange mit vertretbarer Sicherheit davon ausgehen kann, dass ausreichend Daten für einen solchen Vorgang zur Verfügung stehen. Dabei handelt es sich um folgende Situationen: 쐍 Nach dem automatischen Failover einer Datenbank. Exchange prüft alle Kopien der Datenbank, um sicherzustellen, dass sie konsistent sind. 쐍 Wenn Sie eine neue Kopie einer Datenbank erstellen und einige der Dateien (Datenbank- und/ oder Protokolldateien) am Kopierspeicherort auf dem Zielserver bereits vorhanden sind. Das kann geschehen, wenn Sie eine Datenbankkopie aktivieren und wieder deaktivieren, und verhindert, dass Sie die Datenbank jedes Mal einem Reseeding unterziehen müssen. 쐍 Nach der Wiederaufnahme der Replikation, nachdem Sie den Replikationsdienst aus irgendeinem Grund beendet haben. Wenn der Informationsspeicher eine Abweichung zwischen einer aktiven Datenbank und einer ihrer Kopien erkennt, sucht er in den verfügbaren Transaktionsprotokollen nach der Stelle, an der die Abweichung stattgefunden hat. Anschließend sucht er die entsprechenden Seiten in der fehlerhaften Datenbankkopie, liest die geänderten Seiten aus der aktiven Datenbank und kopiert alle erforderlichen Protokolldateien vom aktiven Server. Die Informationen zur Aktualisierung oder Korrektur der beschädigten Seiten werden dann auf die kopierten Transaktionsprotokolle in der abweichenden Datenbankkopie angewendet, um sie wieder mit der aktiven Kopie zu synchronisieren.
457
Exchange auf dem Weg zur Hochverfügbarkeit
Wiedergabe des Transaktionsprotokolls
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Exchange Server 2010 kann auch einzelne Seiten innerhalb einer Datenbank korrigieren. In früheren Versionen von Exchange, vor allem in denen vor Exchange Server 2007, waren die Ereignisse -1018 und -1022 im Anwendungsprotokoll der große Schrecken der Administratoren, denn das bedeutet, dass der Informationsspeicher in der Datenbank eine Beschädigung auf Seitenebene festgestellt hatte. Beschädigungen treten gewöhnlich als Folge von Hardwareproblemen auf, vor allem in Speichercontrollern. Zwar konnte eine Datenbank in dem beschädigten Zustand weiterhin ausgeführt werden, doch die einzige Möglichkeit, um sie zu reparieren, bestand darin, sie von der letzten guten Sicherung wiederherzustellen. Angesichts der Größe mancher Datenbanken von weit über 100 GB waren die Administratoren von dieser Aussicht natürlich nicht sehr erfreut. Eine Seitenbeschädigung in einem Einzelkopiecluster ist ein ernstes Problem. Die Replikation dieser Beschädigung auf viele Datenbankkopien gibt dem Problem gleich eine neue Größenordnung. Daher kann Exchange Server 2010 Seitenbeschädigungen in aktiven und passiven Datenbankkopien erkennen und reparieren. Wenn der Informationsspeicher in der aktiven Datenbank eine problematische Seite erkennt, fügt er in das aktuelle Transaktionsprotokoll eine Anforderung nach einer gültigen Kopie der betroffenen Seite ein. Diese Anforderung wird an alle Datenbankkopien verbreitet, wo sie zusammen mit den restlichen Protokolldateien untersucht und verarbeitet wird. Bei der Wiedergabe der Daten in der passiven Kopie erkennt der Informationsspeicher diese Anforderung und reagiert darauf, indem er einen Replikationsdienst-Callback aufruft, um eine Kopie der Seite an den Server mit der aktiven Datenbank zu senden. Nach dem Eingang der replizierten Seite fügt der Informationsspeicher sie in die aktive Datenbank ein, um die beschädigte Stelle zu ersetzen. Möglicherweise gehen danach von den anderen Servern mit passiven Kopien noch Seiten ein, die aber ignoriert werden, nachdem die aktive Datenbank repariert worden ist. Die Reparatur einer beschädigten Seite in einer passiven Kopie erfolgt ein wenig anders. In diesem Fall hält der Server mit der passiven Kopie sofort die Wiedergabe der Protokolle an. Die Protokolle werden jedoch weiterhin kopiert, damit auf dem Server alle erforderlichen Protokolle vorhanden sind, um die Kopie bei einem Failover online zu bringen. Mithilfe des internen ESE-Seedingmechanismus fordert der Server eine Kopie der beschädigten Seite von dem Server an, auf dem sich die aktive Datenbank befindet, woraufhin der aktive Server mit den Seitendaten antwortet. Der passive Server wartet dann, bis alle erforderlichen Protokolldateien kopiert und untersucht worden sind, um die Datenbank auf einen Stand nach dem Zeitpunkt zu bringen, an dem der aktive Server die Seite zur Verfügung gestellt hat (das wird anhand der höchsten erforderlichen Generationsnummer bestimmt). Wenn alle benötigten Daten vorhanden sind, stellt der passive Server die beschädigte Seite wieder her und nimmt die Wiedergabe der Protokolle wieder auf, um den Rückstau zu beseitigen, der sich seit der Entdeckung der Beschädigung angesammelt hat.
Seeding von Datenbanken Seeding ist der Vorgang, mit dem Exchange eine neue Datenbankkopie erstellt oder eine bereits vorhandene, die sich durch die Protokollwiedergabe nicht mehr aktualisieren lässt, neu aufbaut. Für die fortlaufende Cluster- und die Standbyreplikation verwendet auch Exchange Server 2007 ein Seeding. Dabei kopiert Exchange die Quelldatenbank zum Ziel und aktualisiert diese Kopie durch Einspielen der Transaktionsprotokolle, die seit dem Beginn des Kopiervorgangs aufgelaufen sind. Einer der Unterschiede zwischen den beiden Versionen besteht darin, dass Exchange Server 2010 den Suchkatalog vom Quell- zum Zielserver kopiert, um ihn dort nicht neu erstellen zu müssen. Außerdem kann Exchange Server 2010 auch eine passive Kopie als Quelle für den Kopiervorgang verwenden. Bei der
458
fortlaufenden Cluster- und Standbyreplikation von Exchange Server 2007 kann es insgesamt nur zwei Ausfertigungen einer Datenbank geben, sodass das Seeding immer von der aktiven Datenbank ausgehen muss. Wie viel Zeit ein Seeding erfordert, hängt von der Geschwindigkeit der Netzwerkverbindung zwischen den beiden Servern und deren jeweiliger Belastung ab. Angesichts der Verschiedenartigkeit der Umgebungen lässt sich keine genaue Zahl für den zu erwartenden Durchsatz angeben, aber bei einem Netzwerk mit 100 Mbit/s können Sie schon mit einer Kopierrate von bis zu 50 GB/h rechnen. Wenn Sie also ein Reseeding für eine 1-TB-Datenbank durchführen müssen, kann dieser Vorgang 20 Stunden dauern. Möglicherweise ist eine solche Dauer für Sie nicht akzeptabel, aber Abhilfe können Sie nur dadurch schaffen, dass Sie die Kapazität des Replikationsnetzwerks erhöhen. Offensichtlich erfolgt das Reseeding einer 1-TB-Datenbank über ein 1-Gbit-Netzwerk viel schneller. Microsoft hat zwar dafür gesorgt, dass Reseedings nicht mehr so häufig nötig sind, doch hin und wieder kann ein solcher Vorgang trotzdem erforderlich sein. Wenn Sie daher sehr große Datenbanken planen, sollten Sie auch für ein schnelles Replikationsnetzwerk sorgen.
Eindeutige Datenbanknamen Da die Datenbanken jetzt nicht mehr an die Server gebunden sind, müssen die Datenbanknamen in Exchange Server 2010 eindeutig sein. Anstelle der Standardnamen (wie First Mailbox Database), die von früheren Exchange-Versionen verwendet wurden, gibt es jetzt ein Benennungsverfahren, dass den Datenbanken eindeutige Namen verleiht. Dabei kommen jedoch Namen wie Mailbox Database 1236069237 heraus, die zwar eindeutig sind, sich aber nur schwer merken lassen und für den Zugriff auf Datenbanken in der Exchange-Verwaltungsshell auch zu kompliziert sind. Allerdings können Sie die Datenbanken umbenennen, sodass ihr Name ihren Speicherort oder ihren Verwendungszweck anzeigt. Ein Problem auf einem Server mit der Datenbank Postfächer der Geschäftsleitung wird wahrscheinlich mehr Aufmerksamkeit und Besorgnis hervorrufen als ein ähnlicher Ausfall auf einem Server mit der Datenbank Ressourcenpostfächer. In diesem Beispiel signalisiert der Name der Datenbank die Wichtigkeit, damit Administratoren schneller reagieren, um weitere Probleme im Kielwasser dieses ersten Fehlers zu verhindern. Administratoren sollten zwar immer schnell auf Ausfälle reagieren, aber einige dezente Hinweise können als zusätzlicher Ansporn dienen. Für die vorhandenen Datenbanken auf Servern mit älteren Exchange-Versionen müssen Sie nicht noch nachträglich eindeutige Namen vergeben, da ohnehin nur Computer mit Exchange Server 2010 in eine Datenbankverfügbarkeitsgruppe aufgenommen werden und Exchange bei der Installation neuer Server von sich aus eindeutige Namen vergibt. Den Namen der Standarddatenbank, die das Exchange-Installationsprogramm auf einem neuen Postfachserver vergibt, können Sie nur dann festlegen, wenn Sie Setup im Befehlszeilenmodus ausführen und den Parameter -mdbname angeben. Dabei können Sie auch den mit -LogFolderPath den Pfad für die Transaktionsprotokolle und mit -DBFilePath den für die Datenbankdateien angeben: Setup.com /Roles:MB,CAS,HT /Targetdir:D:\Exchange /MdbName:DB1 /DbFilePath:F:\Exchange\DB1\DB1.EDB /LogFolderPath:L:\Exchange\DB1Logs"
Mit diesem Befehl weisen Sie Setup an, im Verzeichnis D:\Exchange drei Serverrollen zu installieren und die neue Datenbank DB1 zu erstellen, deren Datenbankdateien sich in F:\Exchange\DB1 befinden und deren Transaktionsprotokolle in L:\Exchange\DB1Logs.
459
Exchange auf dem Weg zur Hochverfügbarkeit
Eindeutige Datenbanknamen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Wenn Sie einen Fehler machen oder wenn bei der Serverinstallation eine Datenbank mit einem Standardnamen erstellt wird, können Sie die Datenbank später umbenennen. Während der Entwicklung hatte man sich bei Microsoft zeitweilig überlegt, eine Umbenennung von Datenbanken nicht zuzulassen (da jedes Mal beim Ausführen von Get-MailboxDatabaseCopyStatus Daten aus Active Directory abgerufen werden müssen, was die Leistung beeinträchtigen kann). Es schien eine gute Lösung zu sein, die Datenbanknamen zwischenzuspeichern und dafür auf die Möglichkeit zu verzichten, sie ändern zu können. Aufgrund des Drucks von Kunden, die die ersten Testversionen ausprobierten, war man bei Microsoft jedoch klug genug, von diesem Standpunkt abzuweichen und wieder die Möglichkeit anzubieten, Datenbanken umzubenennen. Um eine Datenbank umzubenennen, markieren Sie sie in der Exchange-Verwaltungskonsole, öffnen ihr Eigenschaftendialogfeld und geben auf der Registerkarte Allgemein den neuen Namen ein (siehe Abbildung 8.3). Natürlich muss der neue Name eindeutig sein. Abbildg. 8.3
Umbenennen einer Postfachdatenbank in einer Datenbankverfügbarkeitsgruppe
In der Verwaltungsshell können Sie eine Datenbank mit dem Cmdlet Set-MailboxDatabase umbenennen: Set-MailboxDatabase –Identity 'ExServer1\Mailbox Database 1236069237' –Name 'DB5'
Um auf eine Datenbank zu verweisen, verwenden der Informationsspeicher und die anderen Exchange-Komponenten niemals den Anzeigenamen (sondern den internen GUID), sodass Sie eine Datenbank so oft umbenennen können, wie es Ihnen gefällt. Allerdings passt Exchange den definierten Namen der Datenbank an, und wenn Sie diesen Namen in einem Skript oder anderem Code verwendet haben, müssen Sie auch i diesem Code den neuen Namen einfügen. Falls Sie beispielsweise wie in Kapitel 6, »Verwalten von E-Mail-aktivierten Empfängern«, für eine dynamische Verteilergruppe einen Filter anlegen, um alle Postfächer einer bestimmten Datenbank in die Gruppe aufzunehmen, dann funktioniert dieser Filter nicht mehr, nachdem Sie die Datenbank umbenannt haben, da der definierte Name abweicht.
460
Beim Unbenennen einer Datenbank behalten die zugrunde liegenden Datenbankdateien ihren ursprünglichen Namen. Wenn Sie beispielsweise Mailbox Database 12360693237 umbenennen, ändert Exchange lediglich den Anzeigenamen der Datenbank, während die Datenbankdateien unberührt bleiben. Das zeigt sich vor allem dann, wenn Sie aus irgendeinem Grund direkt auf die Dateien zugreifen. Beispielsweise sehen Sie die ursprünglichen Dateinamen, wenn Sie den Pfad für die Datenbank- und Protokolldateien vom ursprünglichen Installationsspeicherort auf eine andere Festplatte verlegen (siehe Abbildung 8.4). Da replizierte Datenbanken auf allen Servern den entsprechenden Speicherort haben müssen, zeigt die Exchange-Verwaltungskonsole einen Fehler an, um Sie darüber zu informieren, dass Sie den Assistenten nicht verwenden können, um den Speicherort replizierter Datenbanken zu verschieben. (Wie Sie replizierte Datenbanken tatsächlich verschieben können, lesen Sie im Abschnitt »Verschieben von Datenbankspeicherorten innerhalb einer Datenbankverfügbarkeitsgruppe« weiter hinten in diesem Kapitel.) Die ursprünglichen Dateinamen können Sie problemlos weiterhin verwenden. Wenn Sie jedoch lieber Dateinamen haben, die mit den Datenbanknamen übereinstimmen, dürfen Sie die Standarddatenbanken nicht verwenden, sondern müssen Ihre eigenen anlegen, denen Sie gleich beim Erstellen die richtigen Namen geben. Abbildg. 8.4
Verschieben des Speicherorts einer Datenbank und ihrer Transaktionsprotokolle
In kleinen und mittleren Umgebungen müssen Sie sich kaum Gedanken über die Benennung der Datenbanken machen, da wahrscheinlich nur wenige Datenbanken im Einsatz sind. Unter solchen Umständen ist es durchaus angebracht, allgemeine Namen wie »VIP-Postfächer«, »Postfächer New York« oder gar »Wichtige Postfächer« zu verwenden, da es kaum so viele Datenbanken geben wird, dass man nicht mehr genau erkennen kann, welchem Zweck sie jeweils dienen. In großen Umgebungen mit vielleicht mehreren hundert Datenbanken, die über verschiedene physische Standorte verteilt und in mehrere Datenbankverfügbarkeitsgruppen gegliedert sind, ist es jedoch wichtig, sich schon vor der Bereitstellung der Server ein genaues Benennungsschema für die Datenbanken zu überlegen.
461
Exchange auf dem Weg zur Hochverfügbarkeit
Eindeutige Datenbanknamen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Insidertipp: Datenbankverweise in Exchange
Exchange weist den Datenbanken GUIDs zu, die anstelle der Anzeigenamen verwendet werden, um auf die Datenbanken zu verweisen. Neben dem GUID und dem Anzeigenamen werden in Active Dicrectory jedoch noch andere wichtige Datenbankeigenschaften festgehalten, vor allem EdbFilePath (der Pfad zu den Datenbankdateien) und die Liste der Server, die Kopien der Datenbank unterhalten. Tatsächlich müssen alle Kopien einer Datenbank in einer Datenbankverfügbarkeitsgruppe den gleichen Pfad aufweisen. Wenn Sie eine Aktualisierung von Exchange Server 2003 oder Exchange Server 2007 vornehmen, gibt es in Ihrer Organisation wahrscheinlich mehrere doppelt vorhandene Datenbanknamen. In diesen beiden Versionen wird die Eindeutigkeit der Bezeichnung durch die Kombination aus Servername, Speichergruppenname und Datenbankname erreicht. Die Namensdubletten auf Servern mit älteren Versionen sind kein Problem, wenn Sie alle Postfächer auf Exchange Server 2010 übertragen. Wollen Sie dagegen Postfächer von Exchange Server 2010 auf einen Server mit einer älteren Version verschieben, kann es zu kleinen Schwierigkeiten kommen, da Exchange Server 2010 die Angabe eines eindeutigen Datenbanknamens verlangt. Um bei einem solchen Verschiebevorgang in der Exchange-Verwaltungskonsole eine eindeutige Zieldatenbank festzulegen, müssen Sie die Zieldatenbanken im Datenbankauswahlfeld nach dem Servernamen filtern. Falls Sie lieber mit dem Cmdlet New-MoveRequest in der Verwaltungsshell arbeiten, geben Sie im Parameter für die Zieldatenbank den Servernamen an: New-MoveRequest -Identity 'EPR' -TargetDatabase 'E2007Server\StorageGroupName\MbxDatabaseName'
Änderungen bei der Nachrichtenübermittlung innerhalb einer Datenbankverfügbarkeitsgruppe Um auf Servern mit mehreren Rollen eine bessere Hochverfügbarkeit zu erreichen, erfolgt die Transportverarbeitung in einer Datenbankverfügbarkeitsgruppe ein wenig anders als sonst. Normalerweise verwendet der Postzustellungsdienst den nächstgelegenen Hub-Transport-Server, um neue Nachrichten nach draußen zu übertragen (und dies kann der lokale Server sein, falls auf ihm der Hub-Transport-Dienst läuft). Innerhalb einer Datenbankverfügbarkeitsgruppe wendet sich der Postzustellungsdienst jedoch im Umlaufverfahren nacheinander an alle Hub-Transport-Server innerhalb des Active Directory-Standorts, wobei er auf die lokale Instanz nur dann zurückgreift, wenn kein Remoteserver verfügbar ist. Außerdem versucht das Transportsystem eine Nachricht über einen anderen Server als den weiterzuleiten, auf dem sich die Postfachdatenbank befindet, von der die Nachricht ausging. Diese Maßnahmen dienen dazu, eine Kopie der Nachricht im Transportpapierkorb festzuhalten, sodass sie nach einem Ausfall wiederhergestellt werden kann.
462
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen Eine neue Datenbankverfügbarkeitsgruppe können Sie nicht »nebenbei« einrichten. Außerdem müssen Sie dazu ausreichende Kenntnisse über alle damit zusammenhängenden Technologien haben: 쐍 Exchange Server 2010 쐍 Windows Server 2008 und die Failovercluster-Funktion 쐍 Netzwerke Bei der Erstellung und dem Betrieb einer Datenbankverfügbarkeitsgruppe schirmt Exchange die Administratoren vor den meisten Einzelheiten des Windows-Failoverclusters ab. Den Cluster selbst müssen Sie sich höchstens dann ansehen, wenn ein Problem auftritt und Sie – vielleicht unter der Anleitung des Microsoft-Supports – genauere Untersuchungen anstellen müssen. Trotzdem ist es eine gute Sache, sich zumindest einen Überblick über den Mechanismus zu verschaffen, mit dem Sie arbeiten. Das Konto, das Sie verwenden, muss über genügend Berechtigungen verfügen, um damit die erforderlichen Komponenten zu installieren und Änderungen an der Exchange-Organisation und dem Windows-System vorzunehmen. Die Einrichtung einer Datenbankverfügbarkeitsgruppe in einer Testumgebung ist eine anspruchsvolle Übung, die Sie mehrmals durchführen müssen, bevor Sie eine Datenbankverfügbarkeitsgruppe in der Produktion bereitstellen können. Wenn es ernst wird, müssen Sie wissen, welche Form die Gruppe aufweisen soll und für welchen Zweck Sie sie brauchen. Beispielsweise müssen Sie sich darüber im Klaren sein, welche Server Mitglied der Gruppe sein müssen, wie die Kommunikation zur Replikation der Transaktionsprotokolle ablaufen soll, welche Postfachdatenbanken auf welche Server repliziert werden müssen, wo sich der Dateifreigabenzeuge für die Gruppe befindet und wie sich die Gruppe unter verschiedenen Umständen verhalten wird, z.B. beim Ausfall eines oder mehrerer Server. Diese Einzelheiten sollten Sie schriftlich festhalten und genau überprüfen, bevor Sie den ersten Schritt tun, um eine Datenbankverfügbarkeitsgruppe in der Produktion einzurichten. Nachdem Sie alle Vorbereitungen erledigt haben, können Sie die Gruppe erstellen, indem Sie in der Exchange-Verwaltungskonsole den Assistenten für neue Datenbankverfügbarkeitsgruppen oder in der Verwaltungsshell das Cmdlet New-DatabaseAvailabilityGroup ausführen. Beide Vorgehensweisen sind korrekt, wobei der einzige größere Unterschied darin besteht, dass eine mithilfe des Assistenten erstellte Verfügbarkeitsgruppe über DHCP zugewiesene IP-Adressen für ihre Netzwerke verwendet, während Sie in der Shell die Möglichkeit haben, statische IP-Adressen anzugeben. Zumindest war das in der ursprünglichen Version von Exchange Server 2010 der Fall. Bei Microsoft hatte man sich überlegt, dass die Exchange-Verwaltungskonsole einfache Administrationsmöglichkeiten bieten sollte, um Datenbankverfügbarkeitsgruppen auch in sehr kleinen Standorten möglich zu machen, weshalb im Assistenten auf einige kompliziertere Funktionen verzichtet wurde. Schließlich konnten Sie statische IP-Adressen für die Kommunikation in Datenbankverfügbarkeitsgruppen jederzeit zuweisen, indem Sie die Eigenschaften der Gruppe nachträglich ändern. Allerdings beschwerten sich einige Administratoren und forderten auch für die Verwaltungskonsole die Bereitstellung sämtlicher Möglichkeiten, weshalb Microsoft in SP1 die Konsole geändert hat. Nun können Sie auch dort statische IP-Adressen zuweisen.
463
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Wenn Sie den Assistenten verwenden, um eine neue Datenbankverfügbarkeitsgruppe zu erstellen, müssen Sie nur deren Namen angeben. Dieser Name muss innerhalb der Gesamtstruktur eindeutig sein und darf maximal 15 Zeichen lang umfassen. Darüber hinaus können Sie auch die anderen Felder des Assistenten ausfüllen, um den Namen des Zeugenservers und das Freigabeverzeichnis auf dem Server anzugeben. Wenn Sie diese Felder leer lassen, füllt der Assistent sie automatisch aus. Dazu wählt er einen Hub-Transport-Server im lokalen Standort aus, auf dem die Postfachrolle nicht installiert ist, und erstellt dort das Standardverzeichnis und die Freigabe. Abbildung 8.5 zeigt, wie Sie mithilfe der Exchange-Verwaltungskonsole eine neue Datenbankverfügbarkeitsgruppe erstellen. Dieser Vorgang ist sehr einfach, und der einzige wahrscheinliche Fehler in diesem Stadium ist die Platzierung des Dateifreigabenzeugen auf einem Server, der in Zukunft vielleicht selbst Mitglied der Verfügbarkeitsgruppe wird. Wenn Sie hier einen Irrtum begehen, können Sie jedoch einfach die Eigenschaften der Gruppe ändern und den Dateifreigabenzeugen einem anderen Server zuordnen (siehe Abbildung 8.6). Abbildg. 8.5
Erstellen einer neuen Datenbankverfügbarkeitsgruppe mit der Exchange-Verwaltungskonsole
Wenn Sie auf einem Exchange Server 2010-Computer eine Datenbankverfügbarkeitsgruppe erstellen, müssen Sie einen UNC-Freigabepfad (Universal Naming Convention) und ein Verzeichnis für den Dateifreigabezeugen des Clusters angeben. Dieses Verzeichnis muss sich auf einem Computer mit Windows Server 2003 oder Windows Server 2008 (SP2 oder R2) befinden. Das physische Verzeichnis legt Exchange beim Einrichten der Verfügbarkeitsgruppe an. Der Server, auf dem sich der Dateifreigabenzeuge befindet, muss sich in derselben Gesamtstruktur befinden wie die Datenbankverfügbarkeitsgruppe, darf aber selbst nicht Mitglied der Gruppe sein. Für den Fall, dass der Server mit dem eigentlichen Dateifreigabenzeugen ausfällt, können Sie einen UNC-Pfad und ein Verzeichnis für eine Alternative angeben.
464
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Anzeigen der Eigenschaften einer Datenbankverfügbarkeitsgruppe
Exchange auf dem Weg zur Hochverfügbarkeit
Abbildg. 8.6
Exchange Server 2010 SP1 bietet mehr Möglichkeiten. Hier können Sie Folgendes tun: 1. Geben Sie nur den Namen der Datenbankverfügbarkeitsgruppe an. Dadurch zwingen Sie Exchange,
nach einem Hub-Transport-Server im Standort zu suchen, auf dem die Postfachrolle nicht installiert ist. Wird ein geeigneter Server gefunden, erstellt Exchange auf ihm das Standardverzeichnis und die Dateifreigabe für den Zeugen. 2. Geben Sie den Namen der Datenbankverfügbarkeitsgruppe und das Verzeichnis für den Dateifreigabenzeugen an. Auch hierbei sucht Exchange nach einem geeigneten Hub-Transport-Server und erstellt dort das Verzeichnis und die Dateifreigabe. 3. Geben Sie den Namen der Datenbankverfügbarkeitsgruppe und den Zeugenserver an. Exchange erstellt daraufhin auf dem angegebenen Server das Standardverzeichnis für den Dateifreigabenzeugen. 4. Geben Sie alle Parameter für die Datenbankverfügbarkeitsgruppe an. Exchange erstellt das Zeugenverzeichnis mit dem festgelegten Namen auf dem Zielserver. HINWEIS Ein Server kann die Dateifreigabenzeugen für mehrere Datenbankverfügbarkeitsgruppen enthalten, sofern den einzelnen Gruppen jeweils ein eigenes Verzeichnis zugewiesen ist. Microsoft empfiehlt, die Dateifreigabenzeugen auf einem Hub-Transport-Server in dem Active Directory-Standort einzurichten, in dem sich auch die Datenbankverfügbarkeitsgruppe befindet. (Für eine Datenbankverfügbarkeitsgruppe, die mehrere Active Directory-Standorte umspannt, wählen Sie einen Hub-Transport-Server in einem beliebigen dieser Standorte aus.) Ein guter Grund dafür, den Dateifreigabenserver auf einem Exchange Server-Computer unterzubringen besteht darin, dass ein Exchange-Administrator dann in der Lage ist, sämtliche Komponenten der Datenbankverfügbarkeitsgruppe zu verwalten.
465
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Da sich der Dateifreigabenzeuge nicht auf einem Exchange Server-Computer befinden muss, überprüft die Exchange-Verwaltungskonsole auch nicht, ob er verfügbar ist. Es ist daher durchaus möglich, dass ein Administrator einen Server, der als Dateifreigabenzeuge fungiert, entfernt oder überschreibt, ohne dass sich Exchange beschwert – bis die Datenbankverfügbarkeitsgruppe das nächste Mal auf den Zeugen zugreifen muss. Erst zu diesem Zeitpunkt stellt Exchange dann fest, dass der Server nicht mehr verfügbar ist. Alle Befehle, die das Vorhandensein des Dateifreigabenzeugen voraussetzen, schlagen dann fehl. Zum Glück können Sie die Eigenschaften einer Datenbankverfügbarkeitsgruppe in der Exchange-Verwaltungskonsole und mit dem Cmdlet Set-DatabaseAvailabilityGroup ändern, um den Dateifreigabenzeugen auf einen anderen Server zu verlegen. Wenn sich die Datenbankverfügbarkeitsgruppe über mehrere Rechenzentren erstreckt, sollten Sie den Dateifreigabenzeugen im Hauptrechenzentrum unterbringen, damit ein Netzwerkausfall zwischen den beiden Rechenzentrum nicht zu einem Failover führt oder die Datenbankverfügbarkeitsgruppe zum Stillstand bringt. Wenn Sie den Dateifreigabenzeugen auf einem Server unterbringen, auf dem Exchange Server 2010 nicht installiert ist, müssen Sie als Erstes die universelle Sicherheitsgruppe Exchange Trusted Subsystem zur lokalen Administratorengruppe auf dem Zielserver hinzufügen, bevor Sie die Datenbankverfügbarkeitsgruppe erstellen. Dadurch kann Exchange das Verzeichnis und die Freigabe auf diesem Server erstellen und verwalten. Andere Schritte sind nicht notwendig, um Exchange die Verwaltung des Dateifreigabenzeugen zu erlauben. In manchen Blogs ist zu lesen, dass Sie das Computerkonto des Servers mit dem Dateifreigabenzeugen in die Gruppe Exchange Trusted Subsystems aufnehmen müssen. Hören Sie nicht auf solche Ratschläge, sondern seien Sie sehr vorsichtig, wen Sie zu Mitgliedern der Gruppe Exchange Trusted Subsystem machen. Diese Gruppe erlaubt den Zugriff auf sämtliche Exchange-Objekte in Active Directory, weshalb Sie sie so eng fassen sollten wie möglich. Um einen Server auf den Beitritt zu einer Datenbankverfügbarkeitsgruppe vorzubereiten, erstellt Exchange lediglich ein Objekt in Active Directory, und das ist auch dann möglich, wenn Exchange nicht in der Lage ist, den Dateifreigabenzeugen auf dem angegebenen Server anzulegen. In einem solchen Fall sehen Sie die Fehlermeldung aus Abbildung 8.7. Um das Problem zu lösen, müssen Sie die universelle Sicherheitsgruppe Exchange Trusted Subsystem zur lokalen Administratorgruppe hinzufügen und dann die Eigenschaften der Datenbankverfügbarkeitsgruppe mit dem Cmdlet Set-DatabaseAvailabilityGroup ändern und dabei den Namen des Servers mit dem Dateifreigabenzeugen und das dafür verwendete Verzeichnis angeben. Wenn der Server mit dem Dateifreigabenzeugen kein Exchange Server-Computer ist, sehen Sie selbst dann eine ähnliche Warnung, wenn Exchange Trusted Subsystem Mitglied der lokalen Administratorgruppe ist und Exchange den Dateifreigabenzeugen erstellen konnte (siehe Abbildung 8.8). Sofern Sie den Zeugen wirklich dort einrichten wollten, können Sie diese Fehlermeldung ignorieren. Insidertipp: Firewallregeln für die Remoteverwaltung
Firewalls können die Kommunikation behindern – auch die rechtmäßige Kommunikation –, weshalb Sie für die Windows-Firefall auf dem Zielserver eine Regel erstellen müssen, die die Remoteverwaltung zulässt und damit RPC-Zugriffsfehler bei der Kommunikation in Datenbankverfügbarkeitsgruppen verhindert. Dazu eignet sich eine Regel wie die folgende: NetshAdvfirewall Firewall set rule group="Remote Administration" new enable=yes
466
Abbildg. 8.7
Fehler beim Erstellen des Dateifreigabezeugen während der Einrichtung einer Datenbankverfügbarkeitsgruppe
Abbildg. 8.8
Warnung beim Erstellen einer Datenbankverfügbarkeitsgruppe
467
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Datenbankverfügbarkeitsgruppen können Sie auch in der Exchange-Verwaltungsshell erstellen. Im folgenden Beispiel legen wir die neue Datenbankverfügbarkeitsgruppe DAG-Dublin an und weisen ihr statische IP-Adressen zu. Wie bereits erwähnt, müssen Sie zu diesem Zeitpunkt noch keine IPAdressen registrieren, und wenn Sie zum Erstellen der Gruppe die Verwaltungskonsole verwenden, legt Exchange (in der RTM-Verson) auch gar keine IP-Adressen fest, sondern least sie via DHCP (für die Netzwerke von Datenbankverfügbarkeitsgruppen setzt Microsoft nicht APIPA [Automatic Private IP Addressing] ein). Sie können auch eine IPv6-Adresse zuweisen, aber nur dann, wenn Sie gleichzeitig eine IPv4-Adresse angeben. IPv6 ist für die meisten Windows-Administratoren immer noch unbekanntes Terrain, weshalb Sie sich in Ihren Datenbankverfügbarkeitsgruppen vorerst lieber auf IPv4 beschränken sollten, bis IPv6 etwas ausgereifter ist. Die Failovercluster-Funktion von Windows registriert die IP-Adresse als eine Netzwerkressource für die Windows-Clusterressource, die der Datenbankverfügbarkeitsgruppe zugrunde liegt. Stellen Sie sich diese IP-Ressource als einen Zeiger vor, der die Datenbankverfügbarkeitsgruppe in DNS identifiziert. Wie wir noch sehen werden, reicht für eine Datenbankverfügbarkeitsgruppe, die lediglich ein einziges Subnetz umspannt, eine IP-Adresse aus. Wollen Sie Server zu einer Datenbankverfügbarkeitsgruppe hinzufügen, die sich über mehrere Subnetze erstreckt, müssen Sie der Gruppe mit SetDatabaseAvailabiliyGroup weitere IP-Adressen für die einzelnen Subnetze hinzufügen. Die meisten Unternehmen bevorzugen die Verwendung von statischen IP-Adressen für Serverressourcen, weshalb wir das in diesem Beispiel ebenso halten: New-DatabaseAvailabilityGroup -Name 'DAG-Dublin' -DatabaseAvailabilityGroupIPAddresses 192.165.1.8
Wenn Sie keine IP-Adresse zuweisen oder den Wert 0.0.0.0 verwenden, versucht Exchange, eine Adresse über DHCP zu leasen. In diesem Fall wird als IP-Adresse immer 0.0.0.0 angegeben, wenn Sie sich mit Get-DatabaseAvailabilityGroup die Eigenschaften der Datenbankverfügbarkeitsgruppe ansehen. HINWEIS Mit Get-DatabaseAvailabilityGroup können Sie nur die statischen Eigenschaften abrufen, die in Active Directory gespeichert sind. Um sämtliche Eigenschaften einer Datenbankverfügbarkeitsgruppe einzusehen, auch diejenigen, die in Exchange festgehalten werden, verwenden Sie Get-DatabaseAvailabilityGroup -Status. Wie für die fortlaufende Cluster- und Standbyreplikation von Exchange Server 2007 wird auch für Datenbankverfügbarkeitsgruppen ein Cluster mit Hauptknotensatz verwendet. Das bedeutet, dass mindestens die Hälfte der »Stimmen« verfügbar sein müssen, damit der Cluster funktioniert. Dabei haben alle Serverknoten und der Dateifreigabenzeuge je eine Stimme. Wenn Mitgliedsserver hinzugefügt oder entfernt werden, passt sich der Cluster automatisch an, um das Quorum zu erhalten. Eine neu erstellte Datenbankverfügbarkeitsgruppe ist zunächst ein leerer Cluster ohne Mitgliedsserver, weshalb der Cluster im Quorummodus der Knotenmehrheit betrieben wird, wobei die einzige Stimme dem Dateifreigabenzeugen gehört. Das ist zulässig, solange die eine einzige Stimme auch tatsächlich verfügbar ist. Wenn Sie der Gruppe Postfachserver hinzufügen, wechselt der Cluster automatisch in den Modus Knoten- und Dateifreigabenmehrheit, und die Datenbankverfügbarkeitsgruppe beginnt damit, den Zeugenserver zu verwenden, um das Quorum zu erhalten. In einer vollständigen Datenbankverfügbarkeitsgruppe, in der alle Mitgliedserver online sind, ist die Stimme des Dateifreigabenzeugen nicht nötig, um das Quorum zu erhalten. Wenn jedoch Mitgliedserver ausfallen oder offline geschaltet werden, gewinnt die Stimme des Zeugen an Wichtigkeit. Beispielsweise beträgt das Quorum in einer Datenbankverfügbarkeitsgruppe mit vier Knoten drei (mehr als die Hälfte der Anzahl von Mitgliedservern). Wenn die Hälfte der Server ausfällt, wird die Stimme des Dateifreigabenzeugen gebraucht, um das Quorum zu erhalten und den Cluster online zu belassen. 468
Auch in Active Directory wird eine neu erstellte Datenbankverfügbarkeitsgruppe zunächst als leeres Objekt angezeigt (siehe Abbildung 8.9). Wir werden uns noch ansehen, wie mit diesem Objekt Serverobjekte verknüpft werden, wenn Sie Server zu der Gruppe hinzufügen. Wenn Ihre aktiven Benutzer über zwei Rechenzentren verteilt sind, sollten Sie lieber zwei Datenbankverfügbarkeitsgruppen verwenden, anstatt eine einzige aufzubauen, die Server aus beiden Rechenzentren enthält. Eine Datenbankverfügbarkeitsgruppe kann nur einen einzigen Dateifreigabezeugen aufweisen. Wenn Sie daher eine einzige große Datenbankverfügbarkeitsgruppe verwenden, muss sich der Zeuge in einem der beiden Rechenzentren befinden, was für die Benutzer in dem anderen eine neuralgische Schwachstelle darstellt. Bei einem Netzwerkausfall, durch den der Dateifreigabenzeuge von dem anderen Rechenzentrum aus nicht mehr erreichbar ist, führt das dazu, dass das Quorum nicht mehr erhalten werden kann. Es ist daher besser, zwei Datenbankverfügbarkeitsgruppen zu erstellen und zwei Dateifreigabenzeugen in den beiden Rechenzentren zu verwenden. Abbildg. 8.9
Anzeigen des Objekts für eine Datenbankverfügbarkeitsgruppe in Active Directory
Microsoft bevorzugt die fortlaufende Replikation als Mechanismus, um die Datenbankkopien in einer Datenbankverfügbarkeitsgruppe auf dem neuesten Stand zu halten. Allerdings gibt es auch eine Replikations-API, mit deren Hilfe andere Hersteller ihre eigenen Produkte für Datenbankverfügbarkeitsgruppen mit eigenen Funktionen erstellen können. Wenn Sie ein solches Drittanbieterprodukt installiert haben, erstellen Sie die Datenbankverfügbarkeitsgruppen dafür mit dem Cmdlet NewDatabaseAvailabilityGroup und dem Parameter -ThirdPartyReplication. Datenbankverfügbarkeitsgruppen, die für solche Drittanbieterprodukte angelegt worden sind, können nicht geändert werden. Wenn Sie später die Exchange-Technologie verwenden möchten, müssen Sie alle Server aus der Gruppe herausnehmen, die Gruppe entfernen und neu erstellen. Weitere Informationen
Eine aktuelle Liste der für den Einsatz mit Exchange Server 2010 geeigneten Replikationsprodukte von Drittanbietern finden Sie auf der Website von Microsoft. 469
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Einrichten von Datenbankverfügbarkeitsgruppen Nachdem Sie eine Datenbankverfügbarkeitsgruppe erstellt haben, ist sie zunächst nur ein leerer Container, der darauf wartet, mit Postfachservern und Datenbanken gefüllt zu werden. Einer der Vorteile der Datenbankverfügbarkeitsgruppen in Exchange Server 2010 ist die Tatsache, dass Sie sie nach und nach ausbauen können, anstatt wie bei den Cluster-Postfachservern in Exchange Server 2007 alle Server auf einmal installieren zu müssen. Wenn Sie eine Datenbankverfügbarkeitsgruppe erstellt und ihre Eigenschaften korrekt festgelegt haben, fügen Sie ihr zunächst Postfachserver hinzu und erstellen dann neue Datenbankkopien, die von diesen Servern verwaltet werden. Allerdings müssen Sie damit nicht unmittelbar nach dem Erstellen der Datenbankverfügbarkeitsgruppe beginnen. In Ihrer Organisation können Sie auch eine leere Gruppe so lange belassen, wie es Ihnen gefällt. Um Server zu der Gruppe hinzuzufügen oder aus ihr zu entfernen, verwenden Sie den Assistenten zum Verwalten der Datenbankverfügbarkeitsgruppe in der Exchange-Verwaltungskonsole oder die Cmdlets Add-DatabaseAvailabilityGroupServer bzw. Remove-DatabaseAvailabilityGroupServer. Um in der Konsole mit der Verwaltung der Mitgliedschaft einer Datenbankverfügbarkeitsgruppe zu beginnen, wechseln Sie zum Abschnitt Postfach des Knotens Organisationskonfiguration und markieren auf der Registerkarte Datenbankverfügbarkeitsgruppen die gewünschte Gruppe. Klicken Sie dann mit der rechten Maustaste, um die Befehle zur Gruppenverwaltung einzublenden (siehe Abbildung 8.10). Abbildg. 8.10
Optionen zur Verwaltung von Datenbankverfügbarkeitsgruppen
VORSICHT Microsoft rät davon ab, Exchange auf einem Domänencontroller zu installieren. Daher sollten Sie erst recht keinen Postfachserver, der trotzdem auf einem Domänencontroller läuft, zu einer Datenbankverfügbarkeitsgruppe hinzufügen. Exchange verhindert so etwas nicht, und Sie können den Domänencontroller tatsächlich verwenden, wenn Sie das unbedingt tun müssen. Allerdings sollten Sie so etwas wirklich nur in einer Testumgebung machen und nicht in der Produktion. Nachdem Sie einen Postfachserver zu einer Datenbankverfügbarkeitsgruppe hinzugefügt haben, können Sie seine Mitgliedschaft in der Gruppe auch von einem anderen Exchange Server-Computer aus verwalten. Manche Administratoren lassen den Server-Manager die Windows-Funktion für Failovercluster installieren (siehe Abbildung 8.11), bevor sie versuchen, einen Server zu einer Datenbankverfügbarkeitsgruppe hinzuzufügen, da sie sicher sein wollen, dass alle Voraussetzungen erfüllt sind, bevor sie fortfahren.
470
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Installieren der Windows-Failoverclusterfunktion
Exchange auf dem Weg zur Hochverfügbarkeit
Abbildg. 8.11
Abbildung 8.12 zeigt den Assistenten in der Exchange-Verwaltungskonsole beim Hinzufügen eines neuen Servers zu einer Datenbankverfügbarkeitsgruppe. Abbildg. 8.12
Hinzufügen eines Servers zu einer Datenbankverfügbarkeitsgruppe
471
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Um die Datenbankverfügbarkeitsgruppe durch die Aufnahme des ersten Postfachservers zu initialisieren, führt Exchange die folgenden Schritte durch. Dabei hat Exchange eine Menge zu tun, vor allem, wenn erst noch die Windows-Failoverclusterfunktion installiert werden muss. Der Vorgang kann also eine ganze Weile in Anspruch nehmen. 1. Exchange vergewissert sich, dass auf dem Server die Postfachrolle installiert ist und dass er nicht
den Dateifreigabenzeugen für die Datenbankverfügbarkeitsgruppe enthält. 2. Wenn auf dem Postfachserver die Windows-Failoverclusterfunktion nicht vorhanden ist, instal-
liert Exchange sie dort. 3. Exchange erstellt einen Failovercluster mit dem Namen der Datenbankverfügbarkeitsgruppe. 4. In der Organisationseinheit Computer von Active Directory wird ein Clusternetzwerkobjekt
erstellt (siehe Abbildung 8.13). 5. Name und IP-Adresse der Datenbankverfügbarkeitsgruppe werden als Hosteintrag (A-Eintrag)
in DNS registriert. 6. Exchange füllt die Eigenschaft MSExchMDBAvialbilityGroupLink des Serverobjekts in Active
Directory aus, um den Postfachserver mit dem Objekt für die Datenbankverfügbarkeitsgruppe zu verknüpfen. 7. Die Clusterdatenbank wird mit Informationen über die Datenbanken auf dem neu hinzugefügten Server aktualisiert. Diese Datenbanken bleiben eigenständige aktive Kopien, bis Sie durch Replikation auf andere Server der Gruppe zusätzliche passive Kopien erstellen. Abbildg. 8.13
Eigenschaften der Datenbankverfügbarkeitsgruppe in der Organisationseinheit Computer
Es ist zwar am einfachsten, Server mithilfe der Exchange-Verwaltungskonsole hinzuzufügen, doch können Sie dazu auch die Verwaltungsshell verwenden: Add-DatabaseAvailabilityGroupServer –Identity 'DAG-Dublin' –MailboxServer 'ExServer2'
472
Wenn Sie der Datenbankverfügbarkeitsgruppe weitere Postfachserver hinzufügen, muss Exchange nur doch jeweils die folgenden Aufgaben durchführen: 쐍 Sicherstellen, dass auf dem Server die Postfachrolle installiert ist. 쐍 Aufnehmen des Servers in den Cluster. 쐍 Anpassen des Quorummodells. Für Datenbankverfügbarkeitsgruppen mit einer ungeraden Anzahl von Mitgliedern wird das Modell der Knotenmehrheit verwendet, für Gruppen mit gerader Mitgliederanzahl das Modell der Knoten- und Dateifreigabenmehrheit. Beim Hinzufügen und Entfernen von Servern zu und von einer Datenbankverfügbarkeitsgruppe wird das Quorummodell automatisch angepasst. Das gilt auch für den Fall, dass Server zu Wartungszwecken offline geschaltet werden oder aufgrund eines Fehlers ausfallen. Die Modelländerung findet im Hintergrund statt. Ein Eingreifen des Administrators ist nicht erforderlich. 쐍 Verknüpfen des Servers mit der Datenbankverfügbarkeitsgruppe in Active Directory. 쐍 Aktualisieren der Clusterdatenbank mit Informationen über die Datenbanken auf dem neu hinzugefügten Server. Abbildung 8.14 zeigt die Angaben zu einer Datenbankverfügbarkeitsgruppe mit zwei Mitgliedservern, wie sie im Failovercluster-Manager von Windows erscheinen. Die Netzwerke wurden automatisch mit DHCP eingerichtet, und für den Cluster wurde das Quorummodell der Knoten- und Dateifreigabemehrheit festgelegt (da er eine gerade Anzahl von Servern enthält). In diesem Fall befindet sich der Dateifreigabenzeuge auf einem Server, auf dem Exchange nicht ausgeführt wird. Bevor wir den Zeugen dort unterbringen konnten, mussten wir daher erst Exchange Trusted Subsystem zur lokalen Administratorgruppe hinzufügen. Wie Sie sehen, gibt es aber keinen offensichtlichen Hinweis darauf, dass der Zeugenserver kein Exchange Server-Computer ist. Abbildg. 8.14
Angaben zu einer Datenbankverfügbarkeitsgruppe im Failovercluster-Manager
Ich habe bereits erwähnt, dass Windows Server 2008 R2 dank seines höheren Entwicklungsstandes meine bevorzugte Plattform für Exchange Server 2010 ist. Neue Entwicklungen ergeben sich mit der Zeit als Reaktion auf Erfahrungen aus der Praxis, und die Windows-Clusterfunktion bildet dabei keine Ausnahme. Nehmen wir beispielsweise die Designänderungen, die in Windows Server 2008 R2 eingeflossen sind, um mit Situationen fertig zu werden, in denen das Quorum eines Clusters unvollständig 473
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Insidertipp: Keine Verwaltung von Datenbankverfügbarkeitsgruppen mit dem Failovercluster-Manager
Eine Datenbankverfügbarkeitsgruppe wird zwar im Failovercluster-Manager angezeigt, doch sollten Sie niemals versuchen, in dieser Konsole irgendeine der Gruppenressourcen zu verwalten. Wenn Sie es trotzdem tun und dadurch die Datenbankverfügbarkeitsgruppe beschädigen, sollten Sie nicht viel Verständnis vom Microsoft-Support erwarten. Exchange speichert wichtige Eigenschaften von Datenbankverfügbarkeitsgruppen in Active Directory, und die Einstellungen für diese Gruppen können Sie ausschließlich über die Exchange-Verwaltungskonsole und -Verwaltungsshell korrekt bearbeiten. Falls nötig, ändert der Code der Cmdlets, die für die Verwaltung von Datenbankverfügbarkeitsgruppen da sind, auch die Einstellungen des zugrunde liegenden Windows-Clusters. ist, weil die Zeugenressource ausgefallen ist, während das Zeugenverzeichnis aber erreichbar ist. In KB978790 bietet Microsoft ein Update an, das Sie auf Computer mit Windows Server 2008 anwenden können. Die dadurch vorgenommene Änderung kommt zum Tragen, wenn der Cluster feststellt, dass er den Dateifreigabenzeugen benötigt, um das Quorum zu erhalten. Wenn die Ressource ausgefallen ist, versucht der Cluster sie wieder online zu bringen. Ist der Server mit dem Dateifreigabenzeugen erreichbar, kann er antworten und melden, dass der Zeuge verfügbar und zugänglich ist, sodass das Quorum erhalten bleibt. Kann der Dateifreigabenzeuge jedoch nicht online gebracht werden, geht das Quorum des Clusters verloren, sodass ein Eingreifen des Administrators erforderlich ist. Bevor ein Server einer Datenbankverfügbarkeitsgruppe beitreten kann, muss er in der Lage sein, mit dem Clusterdienst zu kommunizieren, der auf allen bisherigen Mitgliedservern der Gruppe läuft. Sie können eine Datenbankverfügbarkeitsgruppe also nicht füllen, wenn einige der Server offline sind oder es Netzwerkprobleme gibt. Störungen der Kommunikation können u.a. unter folgenden Umstände auftreten: 쐍 Die Server sind ausgeschaltet oder aus anderem Grund nicht erreichbar. 쐍 Der Clusterdienst läuft auf einem Server nicht. 쐍 Firewallregeln auf einem Server blockieren die Kommunikation mit dem Clusterdienst. 쐍 Der DNS-Dienst ist nicht erreichbar. 쐍 Authentifizierungsprobleme (Kerberos, Active Directory oder NTLM) unterbinden die sichere Kommunikation zwischen den Servern. Produktionsserver sollten über zwei Netzwerkkarten verfügen, um den MAPI-Datenverkehr (Interaktion mit anderen Servern, z.B. mit dem Clientzugriffsserver und mit Active Directory) und den Replikationsdatenverkehr (Protokollversand und Seeding von Datenbanken) voneinander zu trennen. Das ist keine unbedingte Voraussetzung für Exchange, da Sie durchaus auch den gesamten Datenverkehr über eine einzige Netzwerkkarte leiten können, sofern diese genügend Kapazität für das Netzwerk hat (für Server mit einer einzigen Netzwerkkarte empfiehlt Microsoft Gigabit-Ethernet). Allerdings ist die Windows-Failoverclusterfunktion auf ein solides Netzwerk angewiesen, und da eine zuverlässige Replikation für den reibungslosen Betrieb von Datenbankverfügbarkeitsgruppen unerlässlich ist, sollten Sie die Server in Datenbankverfügbarkeitsgruppen am besten mit zwei Netzwerkkarten ausrüsten. Dann können Sie bei Bedarf auch weitere Replikatoinsnetzwerke hinzufügen und Techniken wie Netzwerkkarten-Teaming zurückgreifen, um die Widerstandskraft gegen Ausfälle zu erhöhen (siehe den Abschnitt »Netzwerke für Datenbankverfügbarkeitsgruppen« weiter hinten in diesem Kapitel). Um die besten Netzwerkeinstellungen für den Betrieb von Datenbankverfügbarkeitsgruppen herauszufinden, können Sie auch TechNet zurate ziehen.
474
Untersuchen von Problemen in Datenbankverfügbarkeitsgruppen Alle Wartungstätigkeiten für Datenbankverfügbarkeitsgruppen werden in Protokolldateien festgehalten, die im Verzeichnis \ExchangeSetupLogs\Dagtasks gespeichert sind. Die Namen dieser Protokolldateien setzen sich jeweils aus der Bezeichnung DagTask und dem Datum und der Uhrzeit der Ausführung zusammen, sodass Sie die relevanten Dateien schnell finden können. Betrachten Sie die folgenden beiden Beispielauszüge aus Protokolldateien zur Wartung von Datenbankverfügbarkeitsgruppe. Die erste zeigt das Erstellen einer neuen Datenbankverfügbarkeitsgruppe: new-databaseavailabiltygroup started on machine EXSERVER1. [2009-10-07T09:16:10] new-dag started [2009-10-07T09:16:10] commandline: $scriptCmd = {& $wrappedCmd@PSBoundParameters } [2009-10-07T09:16:10] Option 'Name' = ''. [2009-10-07T09:16:10] Option 'WitnessServer' = 'AD-SERVER12.CONTOSO.COM'. [2009-10-07T09:16:10] Option 'WitnessDirectory' = 'c:\FSW\DublinDag'. [2009-10-07T09:16:10] Option 'WhatIf' = ''. [2009-10-07T09:16:21] New-DatabaseAvailabilityGroup passed the initial checks. [2009-10-07T09:16:22] New-DatabaseAvailabilityGroup completed successfully. new-databaseavailabiltygroup explicitly called CloseTempLogFile().
Die zweite zeigt, dass Exchange auf einem Server, der zu einer Datenbankverfügbarkeitsgruppe hinzugefügt werden sollte, die Windows-Failoverclusterfunktion nicht gefunden und diese Komponente daher selbst installiert hat: [2009-10-07T09:57:49] Updated Progress 'Adding server 'EXSERVER1' to database availability group 'DAG-Dublin'.' 6%. [2009-10-07T09:57:49] Working [2009-10-07T09:57:49] Updated Progress 'The task is installing the Windows Failover Clustering component on the server EXSERVER1.' 8%. [2009-10-07T09:57:49] Working [2009-10-07T10:06:37] The following log entry comes from a different process, run on machine EXSERVER1'. BEGIN [2009-10-07T10:06:37] [2009-10-07T09:57:50] Updated Progress 'The task is installing the Windows Failover Clustering component on the server exserver1.' 2%. [2009-10-07T09:57:50] Working [2009-10-07T10:06:36] Updated Progress 'The task has installed the Windows Failover Clustering component.' 4%.
Auch das Systemereignis ist eine nützliche Quelle von Informationen, um die Ursache eines Problems zu ermitteln. Vor allem die schwerwiegenden Ereignisse für den Hochverfügbarkeitskanal sind häufig sehr erhellend, wenn es darum geht, herauszufinden, was in Active Manager vorgeht (siehe den Abschnitt »Crimson-Ereignisse« weiter hinten in diesem Kapitel). Noch detailliertere Protokolle clusterrelevanter Vorgänge werden im Verzeichnis Windows\Cluster\Reports aufgezeichnet. Die darin
475
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
enthaltenen Informationen sind sehr ausführlich, bieten aber entscheidende Hinweise auf die ungewöhnlicheren Probleme, die hin und wieder auftreten können. Eine Möglichkeit, um die Menge an Informationen zu verringern, die Sie durchsehen müssen, besteht darin, sie mit den Ereignisprotokolleinträgen in Verbindung zu bringen, die mit dem Problem zu tun haben.
Verwalten der Eigenschaften von Datenbankverfügbarkeitsgruppen Nachdem Sie eine Datenbankverfügbarkeitsgruppe erstellt haben, können Sie mit der Exchange-Verwaltungskonsole oder -shell ihre Eigenschaften an Ihre Bedürfnisse anpassen. Um diese Eigenschaften ändern zu können, müssen Sie Mitglied der Rollengruppe Organization Management sein. Eine Liste der Eigenschaften finden Sie in Tabelle 8.1. Tabelle 8.1
Eigenschaften von Datenbankverfügbarkeitsgruppen Eigenschaft
Verwendung
Zeugenserver (WitnessServer)
Pfad zur Freigabe des Dateifreigabenzeugen
Zeugenverzeichnis (WitnessDirectory)
Name des vom Dateifreigabenzeugen verwendeten Verzeichnisses
Alternativer Zeugenserver (AlternateWitnessServer)
Pfad zu einem alternativen Dateifreigabenzeugen
Alternatives Zeugenverzeichnis (AlternateWitnessDirectory)
Name des vom alternativen Dateifreigabenzeugen verwendeten Verzeichnisses
Netzwerkverschlüsselung (NetworkEncryption)
Deaktiviert (Disabled): Keine Verschlüsselung von Daten im Netzwerk der Datenbankverfügbarkeitsgruppe Aktiviert (Enabled): Verschlüsselung für Replikation und Seeding InterSubnetOnly: Verschlüsselung nur für Netzwerke im selben Subnetz SeedOnly: Verschlüsselung nur für Datenbank-Seeding
Netzwerkkomprimierung (NetworkCompression)
Deaktiviert (Disabled): Keine Komprimierung Aktiviert (Enabled): Komprimierung für Replikation und Seeding InterSubnetOnly: Komprimierung nur für Netzwerke im selben Subnetz SeedOnly: Komprimierung nur für Datenbank-Seeding.
Replikationsport (ReplicationPort)
TCP-Port für Replikationsvorgänge. Wenn Sie den vorgegebenen Wert (64327) ändern, müssen Sie die entsprechende Änderung auch bei allen Firewalls vornehmen, damit der Replikationsverkehr über diesen Port stattfinden kann.
IP-Adressen (DatabaseAvailabilityGroupIpAddresses)
IP-Adressen für die Subnetze, die die zugrunde liegende WindowsFailoverclusterfunktion verwendet
Um die Eigenschaften von Datenbankverfügbarkeitsgruppen in der Exchange-Verwaltungsshell zu ändern, verwenden Sie das Cmdlet Set-DatabaseAvailabilityGroup. (Nicht alle der damit zugänglichen Eigenschaften stehen auch in der Verwaltungskonsole zur Verfügung.) Beispielsweise ändern Sie mit dem folgenden Befehl eine Reihe von Gruppeneigenschaften: Set-DatabaseAvailabilityGroup –Identity 'DAG-Dublin' –WitnessServer 'ExHT1.contoso.com' –WitnessDirectory 'D:\DUBDAG' -AlternativeWitnessServer 'ExHT22.contoso.com' –AlternativeWitnessDirectory 'D:\DUBDAG' –ReplicationPort 33998 –NetworkEncryption SeedOnly –NetworkCompression Disabled –DatacenterActivationMode Disabled 476
Die beiden Eigenschaften für alternative Dateifreigabenzeugen steht nur dann zur Verfügung, wenn sich die Datenbankverfügbarkeitsgruppe über mehrere Rechenzentren erstreckt. Solche Datenbankverfügbarkeitsgruppen besprechen wir im Abschnitt »Vorsehen der Ausfallsicherheit von Rechenzentren« weiter hinten in diesem Kapitel. Standardmäßig wird der Replikationsdatenverkehr weder verschlüsselt noch komprimiert, es sei denn, die Replikation findet über die Grenzen eines Subnetzes hinweg statt. Die Eigenschaften NetworkCompression und NetworkEncryption sind daher auf InterSubNetOnly gesetzt. Diese Werte können Sie leicht ändern. Da es sich um Eigenschaften der Datenbankverfügbarkeitsgruppe handelt, gelten sie für den gesamten Datenverkehr zwischen allen Mitgliedern und können nicht für einzelne Mitgliedserver anders eingestellt werden. Tabelle 8.1 zeigt die verfügbaren Optionen für die Verschlüsselung in Datenbankverfügbarkeitsgruppen. Der folgende Befehl aktiviert die Komprimierung und Verschlüsselung des gesamten Datenverkehrs in einer Datenbankverfügbarkeitsgruppe: Set-DatabaseAvailabilityGroup –Identity 'DAG-Dublin' –NetworkCompression Enabled –NetworkEncryption Enabled
Windows-Code für die Kommunikation innerhalb von Datenbankverfügbarkeitsgruppen
Zur Verschlüsselung der internen Kommunikation von Datenbankverfügbarkeitsgruppen verwendet Exchange keinen eigenen Code, sondern greift auf Windows-Funktionen zurück, vor allem auf den Sicherheitsanbieter Kerberos. Dieses Modul enthält Routinen, mit denen Anwendungen die zwischen den Anwendungskomponenten (also z.B. den Mitgliedern einer Datenbankverfügbarkeitsgruppe) hin und her gesendeten Daten verschlüsseln, entschlüsseln, signieren und verifizieren können. Wenn zwei Gruppenmitglieder miteinander kommunizieren, fungieren sie als Endpunkte und beginnen die Verbindung mit einem Handshake und einem Schlüsselaustausch. Sobald die Verbindung eingerichtet ist, können darüber verschlüsselte Daten fließen, die beide Mitglieder entschlüsseln können. In Exchange Server 2010 ist auch eine Komprimierung der internen Kommunikation von Datenbankverfügbarkeitsgruppen auf der Grundlage des Algorithmus LZ77 möglich. Mit dem Cmdlet Get-DatabaseAvailabilityGroup können Sie die Eigenschaften einer Datenbankverfügbarkeitsgruppe einsehen: Get-DatabaseAvailabilityGroup –Identity 'DAG-Dublin' | Format-List
Unter Umständen kann es nötig sein, den Speicherort des Dateifreigabenzeugen zu ändern, z.B. wenn der bisherige Zeugenserver aus irgendeinem Grund nicht erreichbar ist oder eine Verlegung auf einen anderen Server produktiver ist. In diesem Fall können Sie die Eigenschaften des Dateifreigabenzeugen mit Set-DatabaseAvailabilityGroup ändern. Der folgende Befehl verlegt den Dateifreigabenzeugen auf den Server ExServer22 (der kein Mitglied der Datenbankverfügbarkeitsgruppe sein darf) und gibt auch das Verzeichnis auf dem Zielserver an, in dem die Ressource untergebracht werden soll: Set-DatabaseAvailabilityGroup –Identity 'DAG-Dublin' –WitnessServer 'ExServer22.contoso.com' -WitnessDirectory 'C:\FSW\DublinDAG'
Den Dateifreigabenzeugen sollten Sie nur dann verschieben, wenn die Datenbankverfügbarkeitsgruppe fehlerfrei ist und der Zeuge zum Erhalt des Quorums nicht benötigt wird.
477
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Netzwerke für Datenbankverfügbarkeitsgruppen Eine einfache Datenbankverfügbarkeitsgruppe, die wie die bisher besprochenen nur zwei oder Postfachfachserver enthält, stellt recht wenig Ansprüche an das Netzwerk. Sie muss in der Lage sein, die Transaktionsprotokolle zwischen den Postfachservern zu replizieren, weshalb das Netzwerk neben der Netzwerklast durch Tätigkeiten wie den Nachrichtentransport auch die Replikationslast verkraften können muss. Das lässt sich durchaus auch mit einer einzigen Netzwerkkarte erreichen, wobei diese eine Netzwerkkarte aber eine neuralgische Fehlerquelle darstellen kann. In Testumgebungen unter unter sonstigen Umständen, die nicht den Ansprüchen eines großen Produktionssystems genügen müssen, reicht eine einzige Netzwerkkarte jedoch meistens aus. Während der Entwicklung von Exchange Server 2010 überlegte man sich bei Microsoft zeitweilig, mehrere Netzwerkkarten zu einer zwingenden Voraussetzung für die Mitgliedserver von Datenbankverfügbarkeitsgruppen zu machen. Von dieser Position ist man aber wieder abgerückt, da dies bedeutet hätte, Servercomputern mit einer einfacheren technischen Ausstattung den Zugang zu Datenbankverfügbarkeitsgruppen zu verweigern. Stattdessen können Sie jetzt auch Server mit einer einzigen Netzwerkkarte bereitstellen, sofern diese Vorgehensweise für Ihre Ansprüche ausreicht. Abbildung 8.15 zeigt eine einfache Datenbankverfügbarkeitsgruppe aus zwei Postfachservern mit jeweils einer Netzwerkkarte. Im unteren Bereich sehen Sie nähere Angaben zu den Netzwerken, die der Gruppe zugewiesen sind. Jedes von einer Datenbankverfügbarkeitsgruppe genutzte Netzwerk muss über ein Subnetz verfügen. Beim Anlegen einer Datenbankverfügbarkeitsgruppe erstellt Exchange automatisch das erste Subnetz. Außerdem sehen Sie in der Abbildung die IP-Adressen für die Netzwerkkarten der beiden Server. In großen Datenbankverfügbarkeitsgruppen ist es besser, den Netzwerkverkehr auf zwei Netzwerke aufzuteilen: 쐍 Das MAPI-Netzerk ist für die Clientverbindungen da und wird außerdem für das Seeding von Datenbanken verwendet. Innerhalb einer Datenbankverfügbarkeitsgruppe gibt es immer ein MAPI-Netzwerk. 쐍 Das Replikationsnetzwerk wird für das Seeding von Datenbanken und für die Replikation der Transaktionsprotokolle verwendet. Es ist jedoch nicht erforderlich, dass Sie ein Replikationsnetzwerk verwenden. Auf Exchange-Postfachservern, die eine erhebliche Replikationslast zu schultern haben, können Sie allerdings auch mehrere Replikationsnetzwerke einrichten. Informationen über die Netzwerke einer Datenbankverfügbarkeitsgruppe können Sie auch mit dem Cmdlet Get-DatabaseAvailabilityGroupNetwork abrufen: Get-DatabaseAvailabilityGroupNetwork –Identity ‘DAG-Dublin’ | Format-List Name Description Subnets Interfaces MapiAccessEnabled ReplicationEnabled IgnoreNetwork Identity IsValid
478
: : : : : : : : :
DAGNetwork01 {{192.165.65.0/24,Up}} {{ExServer1,Up,192.165.65.50}, {EXSERVER2,Up,192.165.65.60}} True True False DAG-Dublin\DAGNetwork01 True
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Anzeigen des Netzwerks für eine einfache Datenbankverfügbarkeitsgruppe
Exchange auf dem Weg zur Hochverfügbarkeit
Abbildg. 8.15
Wenn Sie zwei Netzwerkkarten verwenden, wird das MAPI-Netzwerk der einen zugewiesen und das Replikationsnetzwerk der anderen. Mit weiteren Netzwerkkarten erweitern Sie die Kapazität des Replikationsnetzwerks. Sind für einen Server mehrere Replikationsnetzwerke eingerichtet, versucht Exchange den Datenverkehr jeweils über das am wenigsten belastete zu leiten, um die verfügbaren Netzwerkressourcen bestmöglich zu nutzen. Microsoft empfiehlt, für Postfachserver mit Exchange Server 2010 in der Produktion Gigabit-Ethernet einzusetzen. Wenn Sie mehrere Netzwerke verwenden, müssen alle Server in der Datenbankverfügbarkeitsgruppe auf dieselbe Weise eingerichtet sein. Mehrere Netzwerkkarten erhöhen die Widerstandskraft gegen Fehler: Wenn das Replikationsnetzwerk aus irgendeinem Grunde nicht mehr zur Verfügung steht, greift Exchange automatisch auf das MAPI-Netzwerk für beide Arten des Netzwerkverkehrs zurück, sodass es nicht zu einem Serverausfall kommt. Sobald das Replikationsnetzwerk wieder funktioniert, verwendet Exchange es auch automatisch wieder. Der Server kann jedoch nicht mehr als Mitglied der Datenbankverfügbarkeitsgruppe fungieren, wenn das MAPI-Netzwerk ausfällt. In diesem Fall schaltet Exchange die aktiven Datenbanken vom betroffenen Server auf andere Mitglieder der Datenbankverfügbarkeitsgruppe um. Beim Erstellen einer Datenbankverfügbarkeitsgruppe mit New-DatabaseAvailabilityGroup können wir eine IP-Adresse zur Bezeichnung der Windows-Clusterressource angeben, die der Gruppe zugrunde liegt (alternativ können wir auch eine DHCP-Adresse leasen). Diese IP-Adresse wird in DNS registriert und vom MAPI-Netzwerk verwendet. Solange sich alle Postfachserver in der Datenbankverfügbarkeitsgruppe im selben Subnetz befinden, reicht es aus, der Gruppe eine einzige IP-Adresse zuzuweisen. Erstreckt sich die Gruppe dagegen über mehrere IP-Subnetze, müssen Sie für jedes dieser Subnetze
479
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
eine IP-Adresse angeben. Die IP-Adresse wird nicht nur für die MAPI-Kommunikation gebraucht, sondern auch dazu, dass der Cluster zwischen den Server in der Datenbankverfügbarkeitsgruppe umschalten kann. Dies wäre nicht möglich, wenn der Cluster nicht alle IP-Subnetze kennen würde, die die Gruppenmitglieder verwenden. Insidertipp: Ein Wort zu Wartezeiten
Wenn mehrere Subnetze vorhanden sind, können wir stillschweigend von räumlich verteilten Aufstellungsorten der Server ausgehen. Die einzige Anforderung lautet, dass die Roundtripzeit zwischen den Mitgliedservern einer Datenbankverfügbarkeitsgruppe kürzer als 250 Millisekunden sein muss. Das ist jedoch keine strenge Voraussetzung, deren Nichterfüllung zu einem sofortigen Ausfall der Datenbankverfügbarkeitsgruppe führen würde. Vielmehr können Sie bei einem Überschreiten der Wartezeit von 250 Millisekunden erwarten, dass sich in Spitzenzeiten die Warteschlangen mit Transaktionsprotokollen füllen und dass Netzwerkstörungen oder Vorgänge, die sehr viel Netzwerkaktivität hervorrufen, die Warteschlangen noch länger machen. Diese Warteschlangen muss Exchange erst einmal abarbeiten, um die Datenbankkopien wieder auf den neuesten Stand zu bringen. In manchen Fällen können sich auch bei Wartezeiten unter 250 Millisekunden lange Warteschlangen bilden. Dann kann es sein, dass Sie die Netzwerkkapazität erhöhen müssen, damit die Protokolle schneller repliziert werden. Mehrere Subnetze sind auch dann erforderlich, wenn Sie eine Datenbankverfügbarkeitsgruppe anlegen, die mehrere Active Directory-Standorte umspannt. Solange die Netzwerkvoraussetzungen erfüllt sind und die Active Directory-Replikation normal funktioniert, ist das kein Problem. Nachdem Sie die Datenbankverfügbarkeitsgruppe erstellt haben, müssen Sie sich erst vergewissern, dass das zugehörige Objekt auf die Domänencontroller am Remotestandort repliziert wurde. Erst dann können Sie versuchen, dort Subnetze zu den Servern hinzuzufügen. Wenn Sie für eine Datenbankverfügbarkeitsgruppe eine IP-Adresse festlegen, muss es für alle Netzwerke ein Standardgateway geben. Außerdem müssen Sie, wenn Sie zur Steuerung des Datenverkehrs zwischen den beiden Subnetzen Microsoft ISA Server (Internet Security and Acceleration) oder ein ähnliches Produkt einsetzen, in den Veröffentlichungsregeln die strikte RPC-Konformität ausschalten, damit der Replikationsverkehr zwischen den Standorten fließen kann. Sollten Sie im Unklaren über die Qualität der Verbindung zwischen den beiden Standorten sein, führen Sie Exchange Best Practices Analzyer auf einem Server in einem Standort aus und versuchen Sie damit den Server im anderen Standort zu analysieren. Wenn ExBPA funktioniert, ist das ein gutes Zeichen für eine ausreichende Verbindung, die auch den Betrieb einer Datenbankverfügbarkeitsgruppe erlaubt. Als praktisches Beispiel nehmen wir an, dass wir unserer Datenbankverfügbarkeitsgruppe einen zweiten Server hinzufügen möchten, der sich im Subnetz 192.168.66.x befindet. Mit dem folgenden Code fügen wir den neuen Server zu der Datenbankverfügbarkeitsgruppe hinzu und geben die IPAdresse für alle Subnetze an, die jetzt in der Gruppe verwendet werden: Add-DatabaseAvailabilityGroupServer –Identity 'DAG-Dublin' –MailboxServer 'ExServer2' Set-DatabaseAvailabilityGroupServer –Identity 'DAG-Dublin' -DatabaseAvailabilityGroupIPAddresses 192.168.65.1, 192.168.66.1
Wenn Sie der Gruppe einen dritten Server hinzufügen, der sich wiederum in einem anderen Subnetz befindet, müssen Sie eine dritte IP-Adresse angeben. Eine Datenbankverfügbarkeitsgruppe kann bis zu 16 Server umfassen, und es ist durchaus möglich, dass sie sich alle in einem anderen Subnetz befinden. In einem solchen Fall müssen Sie beim Hinzufügen des letzten Servers IP-Adressen für alle 16 Subnetze angeben. 480
Jedes Netzwerk einer Datenbankverfügbarkeitsgruppe hat einen eindeutigen Namen aus bis zu 128 Zeichen, einen beschreibenden Namen aus bis zu 256 Zeichen, mit dem Sie seinen Zweck angeben können, mindestens ein Subnetz, das im Format IP-Adresse/Bitmaske festgelegt ist, und ein Flag, das anzeigt, ob das Netzwerk für die Protokollreplikation verwendet wird. Das folgende Beispiel zeigt diese Angaben beim Erstellen eines Netzwerks mit dem Cmdlet New-DatabaseAvailabilityGroupNetwork: New-DatabaseAvailabilityGroupNetwork –DatabaseAvailabilityGroup 'DAG-Dublin' –Name 'DAG-Dublin LS' –Description 'Network used for log shipping in the Dublin DAG' –Subnets 10.0.0.0/8 –ReplicationEnabled:$False
Mit Get-DatabaseAvailabilityGroupNetwork können Sie sich die Netzwerke ansehen, die in der Datenbankverfügbarkeitsgruppe bereitstehen. Wenn Sie wie im vorstehenden Beispiel Server aus mehreren Subnetzen zu der Gruppe hinzugefügt haben, werden in der Ausgabe dieses Cmdlets die für diese Subnetze festgelegten IP-Adressen angezeigt. Um einzelne Parameter eines Netzwerks zu ändern, verwenden Sie Set-DatabaseAvailabilityGroupNetwork. Im folgenden Beispiel ändern wir die Eigenschaften eines Netzwerks, um es für die Protokollreplikation zu reservieren: Set-DatabaseAvailabilityGroupNetwork –Identity 'DAG-Dublin\DAG-Dublin LS' –ReplicationEnabled:$True
Mit dem Parameter -IgnoreNetwork können Sie eine Datenbankverfügbarkeitsgruppe anweisen, ein Netzwerk (zeitweilig) zu ignorieren: Set-DatabaseAvailabilityGroupNetwork –Identity 'DAG-Dublin\DAG-Dublin LS' –IgnoreNetwork:$True
Mit Remove-DatabaseAvailabilityGroupNetwork entfernen Sie ein Netzwerk aus einer Datenbankverfügbarkeitsgruppe. Der Datenverkehr fließt anschließend über die verbleibenden Netzwerke der Gruppe. Das letzte Netzwerk der Gruppe können Sie mit diesem Cmdlet nicht entfernen. Remove-DatabaseAvailabilityGroupNetwork –Identity 'DAG-Dublin\DAG-Dublin LS'
Datenbankverfügbarkeitsgruppen und IPv6
Damit die Windows-Failoverclusterfunktion aktiviert werden kann, scheint IPv6 erforderlich sein, und Datenbankverfügbarkeitsgruppen wiederum stützen sich z.B. zum Nachverfolgen der Mitgliedschaft auf Windows-Failovercluster. Können Sie daher eine Datenbankverfügbarkeitsgruppe ausschließlich mit IPv6-Netzwerken einrichten und ganz auf IPv4 verzichten? Nein, das ist noch nicht möglich. Exchange Server 2010 erkennt zwar IPv6, verwendet aber IPv4. Das bedeutet, dass auch Datenbankverfügbarkeitsgruppen IPv4 einsetzen, weshalb dieses Protokoll auf allen Servern in einer solchen Gruppe vorhanden sein muss. In reinen IPv6-Umgebungen kann eine Datenbankverfügbarkeitsgruppe nicht funktionieren. Für eine Datenbankverfügbarkeitsgruppe werden zwar IPv6-Adressen angezeigt, aber zur Verwaltung der Gruppe können Sie IPv6 nicht einsetzen. Auch in anderen Gebieten weist Exchange Server 2010 Einschränkungen auf, die den Betrieb einer reinen IPv6-Umgebung verhindern. Beispielsweise muss der Server über eine IPv4-Adresse verfügen, damit Unified Messaging funktioniert, und sowohl die Exchange-Webdienste als auch die AutoErmittlung stützen sich auf Windows Communications Framework (WCF), das IPv6-Verbindungen nicht verwenden kann.
481
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Umlaufprotokollierung für Datenbankkopien In allen früheren Versionen von Exchange wurde empfohlen, für Produktionsdatenbanken niemals die Umlaufprotokollierung zu aktivieren. Diese Empfehlung gründete sich jedoch auf die Tatsache, dass immer nur eine einzige Kopie einer Datenbank verfügbar war und der Schutz gegen Datenverlust nur durch Sicherungen erreicht wurde. Der Einfluss von Datenbankkopien war bei dieser Empfehlung nicht berücksichtigt worden. Jetzt empfiehlt Microsoft, die Umlaufprotokollierung für Datenbanken zu aktivieren, von denen es mindestens drei Kopien gibt. Die Verfügbarkeit dieser Kopien schützt Sie vor einem Datenverlust, da Sie für eine Wiederherstellung nach einem Ausfall nicht alle Transaktionsprotokolle brauchen. Die Empfehlung von Microsoft bedeutet jedoch nicht, dass Sie immer drei Kopien sämtlicher Datenbanken in einer Verfügbarkeitsgruppe vorhalten sollten. Diese Anzahl von Kopien ist nur erforderlich, wenn der Aufbau der Gruppe einen guten Grund dafür gibt. Wenn Sie beispielsweise billige Festplatten verwenden, die fehleranfälliger sind, brauchen Sie die Absicherung durch weitere Kopien. Sie sollten den Zusatzaufwand für jede zusätzliche Kopie stets rechtfertigen können. Die Umlaufprotokollierung ist zwar eine nützliche Funktion, aber sie sollte nicht der alleinige Grund dafür sein, drei Datenbankkopien vorzuhalten. Sie müssen erst die Datenbank erstellen und die Kopien einrichten und können erst dann die Umlaufprotokollierung dafür aktivieren. Exchange meldet einen Fehler, wenn Sie versuchen, eine Datenbankkopie hinzuzufügen, während die Umlaufprotokollierung schon aktiviert ist (siehe Abbildung 8.16). Es gibt kleine Unterschiede in der Funktionsweise der Umlaufprotokollierung für Datenbanken in Verfügbarkeitsgruppen und Datenbanken außerhalb davon, was den Einsatz dieser Funktion etwas undurchsichtig macht. Innerhalb einer Datenbankverfügbarkeitsgruppe werden die Transaktionsprotokolle zwischen den Servern mit den Datenbankkopien übertragen, weshalb das Ein- und Ausschalten der Umlaufprotokollierung den Vorgang durcheinander bringen kann, vor allem, wenn es verzögerte Kopien gibt (siehe den Abschnitt »Verzögerte Datenbankkopien« weiter hinten in diesem Kapitel). Außerdem zeigt die Umlaufprotokollierung bei Datenbanken mit einer und mit mehreren Kopien ein unterschiedliches Verhalten, und der Code ist nicht dazu in der Lage, auf die in Datenbankverfügbarkeitsgruppen üblichen Situationen wie eine Erhöhung oder Verringerung der Anzahl von Kopien zu reagieren. Im Klartext heißt das, dass Sie schon in einer Frühphase der Bereitstellung entscheiden müssen, ob Sie die Umlaufprotokollierung für Datenbanken in Verfügbarkeitsgruppen aktivieren möchten, und dass Sie diese Entscheidung anschließend nicht wieder umwerfen können. Um die Umlaufprotokollierung in der Exchange-Verwaltungskonsole zu aktivieren, markieren Sie die Datenbank, klicken auf Eigenschaften und wählen die Option Umlaufprotokollierung aktivieren. Damit die neue Einstellung in Kraft tritt, müssen Sie die Bereitstellung der Datenbank aufheben und sie anschließend wieder bereitstellen. Die Shellbefehle zum Aktivieren der Umlaufprotokollierung, zum Aufheben der Bereitstellung und zum erneuten Bereitstellen lauten wie folgt: Set-MailboxDatabase –Identity 'DB1' –CircularLoggingEnabled $True Dismount-Database –Identity 'DB1' Mount-Database –Identity 'DB1'
Bei der Umlaufprotokollierung werden die Transaktionsprotokolle regelmäßig gelöscht, nachdem die Transaktionen mit Commit in die Datenbank geschrieben worden sind. Wenn Sie in einer Datenbankverfügbarkeitsgruppe neue Datenbankkopien erstellen, sollen aber alle möglicherweise erforderlichen Transaktionsprotokolle vorhanden sein, weshalb die Umlaufprotokollierung erst dann aktiviert werden kann, nachdem die Datenbankkopie vorhanden ist und läuft. Wie wir im Abschnitt
482
»Entfernen von Datenbankkopien« weiter hinten in diesem Kapitel noch sehen werden, können Sie in einer Datenbankverfügbarkeitsgruppe keine Kopien einer Datenbank entfernen, für die die Umlaufprotokollierung aktiviert ist. Denken Sie bei der Planung der Datenbankverwaltung auch an diese Bedingung. Abbildg. 8.16
Fehlermeldung aufgrund bereits aktivierter Umlaufprotokollierung
Hinzufügen neuer Datenbankkopien zu einer Datenbankverfügbarkeitsgruppe Eine neue Datenbankkopie können Sie nicht auf dem Postfachserver anlegen, auf dem sich schon die aktive Kopie der Datenbank befindet. Mit anderen Worten, es ist nicht möglich, zwei Kopien (eine aktive und eine passive) derselben Datenbank auf demselben Server unterzubringen. Genauso wenig kann ein Server zwei passive Kopien einer Datenbank enthalten. Unter Einhaltung dieser Einschränkungen können Sie mit dem Assistenten zum Hinzufügen einer neuen Datenbankkopie und mit dem Cmdlet Add-MailboxDatabaseCopy neue Kopien erstellen. Bei beiden Methoden ist es jedoch erforderlich, zuvor folgende Angaben in Erfahrung zu bringen: 쐍 Die Datenbank, die Sie kopieren möchten. Sie können nur eine Datenbank kopieren, die sich in der Datenbankverfügbarkeitsgruppe befindet. 쐍 Der Postfachserver in der Datenbankverfügbarkeitsgruppe, der die neue Kopie aufnehmen soll. 쐍 Die Aktivierungspriorität (im Assistenten Aktivierungseinstellungsnummer genannt) für die neue Kopie. Alle Kopien in einer Datenbankverfügbarkeitsgruppe weisen eine Nummer auf, wodurch die Reihenfolge festgelegt wird, in der Exchange versucht, die Kopien nach einem Ausfall zu aktivieren. Die aktive Datenbank hat die Priorität 1, die Kopie mit der Nummer 2 wird vor der Kopie
483
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
der Nummer 3 zu aktivieren versucht, usw. Wenn Sie eine neue Kopie hinzufügen, legt Exchange als Aktivierungsnummer die nächsthöhere Zahl über dem aktuellen höchsten Wert fest. Übernehmen Sie diesen Wert, sofern Sie keinen guten Grund für eine Änderung haben. Wenn Sie bei der Festlegung der Aktivierungsreihenfolge einen Fehler begehen, können Sie den Wert wieder ändern, indem Sie die Datenbankkopie in der Liste auswählen und ihre Eigenschaften bearbeiten. Exchange ordnet die anderen Kopien dann entsprechend neu an, sodass die Reihenfolge den von ihnen neu zugewiesenen Prioritätswert berücksichtigt. Um in der Exchange-Verwaltungskonsole eine neue Datenbankkopie zu erstellen, klicken Sie im Abschnitt Postfach des Knotens Organisationskonfiguration auf die Registerkarte Datenbankverwaltung und markieren in der angezeigten Liste die Datenbank, die Sie kopieren möchten. Anschließend klicken Sie im Aktionsbereich auf Postfachdatenbankkopie hinzufügen. Im Assistenten zum Hinzufügen einer Datenbankkopie wählen Sie den Postfachserver aus, der die neue Kopie aufnehmen soll (siehe Abbildung 8.17). Nach der Auswahl des Zielservers klicken Sie auf Hinzufügen, woraufhin Exchange die Datenbank kopiert. Wie lange das Seeding der neuen Kopie dauert, hängt von der Größe der Dateien (EDB-Dateien und Transaktionsprotokolle) und der Geschwindigkeit der Netzwerkverbindung zwischen den beiden Servern ab. Das Seeding großer Datenbankkopien (über 100 GB) sollten Sie für Zeichen geringer Netzwerkanforderungen einplanen, also z.B. außerhalb der normalen Arbeitszeiten. Abbildg. 8.17
Auswählen des Servers für eine Datenbankkopie
Nachdem das Seeding der neuen Datenbankkopie abgeschlossen ist, beginnt der Informationsspeicher damit, die neue Kopie mit der aktiven zu synchronisieren. Exchange kopiert die EDB- und die Transaktionsprotokolldateien von dem Server mit der aktiven Kopie, woraufhin für die Kopie der Status Fehlerfrei angezeigt wird. Zuerst wird die Kopierwarteschlange immer kürzer, und wenn Exchange die neue Kopie synchronisiert, auch die Wiedergabewarteschlange. Schließlich sind beide Warteschlangen leer und die neue Datenbankkopie ist auf dem neuesten Stand. 484
Datenbanken ohne Umlaufprotokollierung können über Tausende von Replikationsprotokollen verfügen, die der Informationsspeicher auf dem empfangenden Server kopieren, untersuchen und eventuell wiedergeben muss, um den neuen Server komplett zu synchronisieren. Wenn Sie den Status der Datenbankkopie überwachen, können Sie erkennen, wie die Kopierwarteschlange wächst, wenn die Protokolle von der aktiven zur neuen Kopie übertragen werden. Sind alle Protokolle kopiert, schrumpft diese Warteschlange wieder zusammen, aber dafür beginnt die Wiedergabewarteschlange zu wachsen. Auch diese Warteschlange schrumpft wieder auf null, wenn die Datenbank vollständig synchronisiert ist und in den fehlerfreien Zustand übergeht. Einfacher wird der Vorgang, wenn Sie die Anzahl der zu berücksichtigenden Transaktionsprotokolle verringern, indem Sie die neue Datenbankkopie möglichst bald nach einer vollständigen Sicherung der aktiven Datenbank erstellen. Dabei werden die Transaktionsprotokolle abgeschnitten, sodass weniger von ihnen für die Synchronisierung herangezogen werden müssen.
Handhaben von Seedingfehlern Beim Erstellen einer neuen Datenbankkopie können Seedingfehler auftreten, und zwar meistens dann, wenn Exchange die EDB-Datei von dem Server mit der aktiven Datenbankkopie auf den Zielserver für die neue Kopie zu übertragen versucht. Wenn ein solcher Fehler auftritt, müssen Sie als Erstes prüfen, ob die Server online sind und korrekt funktionieren. Anschließend sehen Sie nach, welche Fehlermeldungen Exchange bei dem Versuch, die Datenbankkopie zu erstellen, aufgezeichnet hat. Markieren Sie dazu die Datenbank und rufen Sie ihr Eigenschaftendialogfeld auf. Klicken Sie auf der Registerkarte Status auf Fehler anzeigen, wie Sie in Abbildung 8.18 sehen. In diesem Fall können wir erkennen, dass die Datenbankkopie auf dem Zielserver nicht erstellt werden konnte, weil die zugehörige EDB-Datei nicht gefunden wurde. Zwar können Sie versuchen, die Datenbankkopie zu aktualisieren, aber es ist unwahrscheinlich, dass Sie damit Erfolg haben, wenn die grundlegenden Datenbankdateien fehlen. Entfernen Sie daher die Datenbankkopie (die zu diesem Zeitpunkt nur als Eintrag in der Exchange-Konfiguration in Active Directory existiert) und beginnen Sie erneut damit, eine neue Datenbankkopie hinzuzufügen. Abbildg. 8.18
Überprüfen der Fehlermeldungen beim Seeding einer neuen Datenbankkopie
485
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Wenn die Datenbankdateien für die neue Kopie vorhanden sind, kann es sein, dass eine vorübergehende Störung das Seeding verhindert hat. In einem solchen Fall können Sie die Replikation wiederaufnehmen. Markieren Sie die Datenbankkopie und wählen Sie die Option Datenbankkopie wiederaufnehmen, um Exchange anzuweisen, mit der Replikation fortzufahren. Die Exchange-Verwaltungsshell zeigt eine Warnmeldung mit einer Erklärung an, warum die Replikation angehalten wurde, und verlangt eine Bestätigung zum Fortfahren (siehe Abbildung 8.19). Klicken Sie auf OK, um die Replikation wiederaufzunehmen, und überprüfen Sie, ob die neue Datenbankkopie in den fehlerfreien Zustand übergeht, nachdem die Transaktionsprotokolle von der aktiven Kopie übertragen und in der passiven wiedergegeben wurden. Abbildg. 8.19
Wiederaufnehmen eines Seedingvorgangs
Überwachen von Datenbankkopien Sie können die Datenbanken und ihre Kopien in der Exchange-Verwaltungskonsole fortlaufend auf ihren Zustand überprüfen. Schneller geht es jedoch, den aktuellen Replikationsstatus der Datenbanken mit Get-MailboxDatabaseCopyStatus abzurufen. Im Folgenden sehen Sie beispielsweise die Ausgabe nach der Abfrage des Replikationsstatus aller Postfachserver in einer Datenbankverfügbarkeitsgruppe: Get-MailboxServer | Where {$_.DatabaseAvailabilityGroup –eq "DAG1"} | Get-MailboxDatabaseCopyStatus Name --------DAG1-DB1\ExServer1 VIP Data\ExServer1 IT Dpt\ExServer1 DAG1-DB3\ExServer1 PR\ExServer1 ITOPS_DB1\ExServer1 ITOPS_DB2\ExServer1
486
Status
CopyQueue ReplayQueue LastInspected Length Length LogTime -------- --------- ---------- --------------------Mounted 0 0 Mounted 0 0 Mounted 0 0 Healthy 0 0 2/23/2010 5:11:10 AM Healthy 0 0 2/23/2010 5:09:52 AM Mounted 0 0 Mounted 0 0
ContentIndex State --------Healthy Healthy Healthy Healthy Healthy Healthy Healthy
DAG1-DB3\ExServer3 IT Dpt\ExServer3 DAG1-DB2\ExServer3 Dublin\ExServer3 Sales\ExServer3 Operations\ExServer3 DAG1-DB2\ExServer2 DAG1-DB1\ExServer2 VIP Data\ExServer2 IT Dpt\ExServer2 DAG1-DB3\ExServer2
Mounted Healthy Mounted Healthy Healthy Healthy Healthy Healthy Healthy Healthy Healthy
0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0
Healthy 2/23/2010 6:04:12 AM Healthy Healthy 2/23/2010 5:09:52 AM Healthy 2/23/2010 4:59:50 AM Healthy 2/23/2010 5:09:52 AM Healthy 2/23/2010 5:11:10 AM Healthy 2/23/2010 6:19:18 AM Healthy 2/23/2010 6:19:18 AM Healthy 2/23/2010 6:04:12 AM Healthy 2/23/2010 5:11:10 AM Healthy
Hier sind alle Datenbankkopien aufgelistet. Bei denen, die in der Spalte Status als Mounted (bereitgestellt) gekennzeichnet sind, handelt es sich um die zurzeit aktiven Kopien. Für die passiven Kopien wird der Status Healthy (fehlerfrei) angezeigt, was bedeutet, dass die Replikation normal verläuft. In der Spalte ContentIndex State (Status des Inhaltsindex) haben alle Kopien, sowohl die aktiven als auch die passiven, den Status Healthy. Es gibt also keinerlei Probleme mit den Kopien. Eine Liste der Statuscodes für Datenbankkopien, wie sie in der Exchange-Verwaltungskonsole und vom Cmdlet Get-MailboxDatabaseCopyStatus angezeigt werden, finden Sie auf http://technet.microsoft.com/de-de/ library/dd351258.aspx.
Erneutes Seeding einer Datenbankkopie Es kann vorkommen, dass für eine Datenbankkopie ein erneutes Seeding erforderlich wird, wenn nach einem Ausfall zu viele Transaktionsprotokolle fehlen, sodass Exchange die Kopie nicht mehr reparieren kann, oder wenn das Seeding beim Erstellen der Kopie fehlschlug. Nach meiner Erfahrung ist es am besten, eine neue Datenbankkopie auf dem Server zu erstellen, der sie beherbergen soll, denn beim Erstellen von Kopien auf Remoteservern habe ich schon häufig Probleme erlebt. Vielleicht ist es einfach nur Zufall, vielleicht liegt es aber auch daran, dass der Server, an dem Sie angemeldet sind, offensichtlich korrekt funktionieren muss, und dass Sie dort die Gelegenheit haben, sofort einzugreifen, wenn sich vor dem Erstellen der Kopie irgendwelche Probleme zeigen. Bei Reseeding, also einem erneuten Seeding, wählen Sie eine fehlerfreie Datenbankkopie auf einem laufenden Server aus und kopieren sie und ihre Transaktionsprotokolle auf den Zielserver. Wenn die Datenbank mehr als nur ein paar Gigabyte umfasst, kann das natürlich viel Zeit in Anspruch nehmen. Deshalb ist es am besten, zunächst zu versuchen, die Synchronisierung einer ausgefallenen Datenbankkopie (deren Status als Failed oder Fehlgeschlagen angezeigt wird) wieder aufzunehmen, indem Sie die Kopie markieren und Datenbankkopie wiederaufnehmen auswählen. Sollte das nicht funktionieren, müssen Sie ein Reseeding vornehmen. Dazu wählen Sie die Option Datenbankkopie aktualisieren. Bei der Auswahl dieser Option wird ein Assistent gestartet, der Ihnen die Optionen für das Reseeding zeigt (siehe Abbildung 8.20). Vor allem können Sie hier den Quellserver für die Datenbankdateien und Transaktionsprotokolle auswählen. Um Probleme aufgrund langer Wartezeiten im Netzwerk zu vermeiden, sollte sich dieser Quellserver möglichst nahe beim Zielserver befinden.
487
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8 Abbildg. 8.20
Exchange auf dem Weg zur Hochverfügbarkeit
Der Assistent zum Aktualisieren von Datenbankkopien
In der Exchange-Verwaltungsshell verwenden Sie folgenden Befehl, um beispielsweise die Datenbank Sales auf dem Server ExServer1 einem Reseeding mit ExServer1 als Quelle zu unterziehen: Update-MailboxDatabaseCopy -Identity 'Sales\ExServer4' -SourceServer 'ExServer1' -DeleteExistingFiles -Network $null
Wenn Sie innerhalb von 15 Minuten nach einem fehlgeschlagenen Seeding ein Reseeding versuchen, werden Sie darum gebeten, diesen Vorgang zu bestätigen. Exchange merkt sich, wann Seedingoperationen begonnen wurden (wann es also »Aktualisierungsanforderungen« gegeben hat), damit solche Vorgänge nicht zu nah aufeinander folgen. Anderenfalls könnte es vorkommen, dass eine Reseedingoperation noch nicht abgeschlossen ist, während eine andere gestartet wird, weil z.B. zwei Administratoren auf zwei verschiedenen Servern ungefähr zur gleichen Zeit jeweils ein Reseeding verlangen. Wenn Ihnen diese Bestätigungsanforderung angezeigt wird, sollten Sie zunächst überprüfen, ob auch wirklich alles seinen ordnungsgemäßen Gang geht, bevor Sie fortfahren. Exchange streicht Aktualisierungsanforderungen nach jeweils 15 Minuten aus dem Gedächtnis.
Hinzufügen von Datenbankkopien mit der Exchange-Verwaltungsshell Das folgende Beispiel zeigt, wie Sie in der Exchange-Verwaltungsshell eine neue Kopie der Datenbank DB1 mit der Aktivierungspriorität 2 auf dem Server ExServer2 anlegen. Den Prioritätswert müssen Sie nicht angeben. Wenn Sie darauf verzichten, addiert Exchange einfach 1 zu dem bisher höchsten Wert, um den für die neue Kopie zu bestimmen. Wenn Sie einen Prioritätswert angeben, müssen Sie darauf achten, dass er nicht zu einem Konflikt mit einem bereits vorhandenen Wert führt.
488
Add-MailboxDatabaseCopy –Identity 'DB1' –MailboxServer 'ExServer2' –ActivationPreference '2'
Wenn Sie beim Vergeben der Aktivierungspriorität einen Fehler machen, können Sie den Wert nachträglich mit Set-MailboxDatabaseCopy korrigieren und sich mit Get-MailboxDatabase davon überzeugen, dass die richtigen Einstellungen in Kraft sind. Beachten Sie, dass die Datanbankkopien mit dem Datenbank- und dem Servernamen bezeichnet sind. Viele der Cmdlets in der Exchange-Verwaltungsshell verlangen für den Umgang mit Datenbankkopien diese Schreibweise, die die langen definierten Namen aus den älteren Versionen ersetzt. Set-MailboxDatabaseCopy –Identity 'DB1\ExServer2' –ActivationPreference '1' Get-MailboxDatabase -Identity 'DB1' | Select ActivationPreference
HINWEIS In der Exchange-Verwaltungskonsole wird die neue Aktivierungsreihenfolge nach einer Änderung der Prioritätswerte erst dann angezeigt, wenn Sie die Konsole neu starten. Nachdem Sie die neue Datenbankkopie hinzugefügt haben, können Sie sich in der Exchange-Verwaltungskonsole im Unterknoten Postfach von Organisationskonfiguration einen Überblick darüber verschaffen, welche Postfachdatenbanken zurzeit in der Organisation bereitgestellt sind. Abbildung 8.21 zeigt, was Sie in einer Umgebung sehen können, bei denen manche der Datenbanken auf den Servern einer Datenbankverfügbarkeitsgruppe über Kopien verfügen und manche nicht. Alle Datenbanken, auch die für öffentliche Ordner, werden in der Datenbankverfügbarkeitsgruppe DAG-Dublin verwaltet. Für die Datenbanken öffentlicher Ordner wird keine Datenbankreplikation eingesetzt, da sie über ihren eigenen elementweisen Replikationsmechanismus verfügen. Die Datenbank für öffentliche Ordner erscheint nur deshalb in der Datenbankverfügbarkeitsgruppe, da der Server, auf dem sie liegt, Mitglied dieser Gruppe ist. Alle Kopien einer Datenbank müssen jeweils den gleichen Pfad zu den Datenbankdateien und Transaktionsprotokollen aufweisen, sodass Sie den Pfad auf dem Zielserver nicht festlegen können. Achten Sie aber darauf, dass dies nicht zu Überschneidungen mit anderen Daten führt, die sich vielleicht bereits an derselben Stelle auf dem Zielserver befinden. Im Abschnitt »Blockieren der Aktivierung« weiter hinten in diesem Kapitel finden Sie weitere Hinweise zum Umgang mit den Speicherorten von Datenbanken innerhalb von Datenbankverfügbarkeitsgruppen. Abbildg. 8.21
Liste der Datenbanken in der Exchange-Verwaltungskonsole
489
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Weiter vorn haben wir bereits mögliche Probleme beim Seeding einer neuen Datenbankkopie besprochen und darauf hingewiesen, dass Sie in einem solchen Fall den Seedingvorgang wiederaufnehmen können, wenn sich die Umstände gebessert haben. Gegenüber der Exchange-Verwaltungskonsole bietet die Exchange-Verwaltungsshell die zusätzliche Möglichkeit, das Seeding auszusetzen und später nachzuholen. Dadurch können Sie eine neue Datenbankkopie auch dann hinzufügen, wenn Sie schon vorher ahnen, dass sich das Seeding nicht durchführen lässt, z.B. wegen eines zu erwartenden Netzwerkausfalls. Dieses Vorgehen können Sie auch dann einsetzen, wenn Sie in einer aus mehreren Rechenzentren zusammengesetzten Umgebung lieber eine lokale passive Kopie für das Seeding heranziehen möchten als die aktive Remotekopie. In dem folgenden Beispiel fügen wir auf ExServer3 eine neue Datenbankkopie hinzu, setzen das Seeding aber zunächst aus und erzwingen es dann mit ExServer2 als Quelle. Add-MailboxDatabaseCopy –Identity 'DB1' –MailboxServer 'ExServer3' –SeedingPostponed Update-MailboxDatabaseCopy –Identity 'DB1\ExServer3' –SourceServer 'ExServer2'
Verzögerte Datenbankkopien In Datenbankverfügbarkeitsgruppen sind auch verzögerte Datenbankkopien möglich, die nicht sofort aktualisiert werden, sobald die Transaktionsprotokolle zur Wiedergabe zur Verfügung stehen. Stattdessen werden die Protokolle erst eine bestimmte Zeit lang aufbewahrt (übliche Zeiträume sind 7 und 14 Tage) und erst dann eingespielt. Die verzögerte Datenbankkopie stellt daher immer einen früheren Zustand der aktiven Datenbank und aller nicht verzögerten Kopien dar. Der Hauptgrund für die Verwendung verzögerter Datenbankkopien liegt darin, dass Sie dann immer die Möglichkeit haben, zu einem früheren Zustand zurückzukehren, in dem sich die Datenbank definitiv in einem guten Zustand befand, bevor sich eine logische Beschädigung einschlich. In Exchange kann »logische Beschädigung« zweierlei bedeuten: 1. Logische Beschädigung der Datenbank
Eine Datenbankseite weist eine korrekte Prüfsumme auf, aber die Daten auf der Seite sind falsch. So etwas kann vorkommen, wenn ESE versucht, auf eine Seite zu schreiben und von Windows auch eine Erfolgsmeldung darüber erhält, während die Daten in Wirklichkeit gar nicht auf die Festplatte geschrieben wurden oder an einer falschen Stelle der Datenbank gelandet sind. Die ESE-Version von Exchange Server 2010 enthält einen Mechanismus zum Erkennen solcher »verlorener Schreibvorgänge«, sodass solche Probleme verhindert werden können. 2. Logische Beschädigung des Informationsspeichers Es ist möglich, dass eine Anwendung Daten auf solche Weise in eine Datenbank schreibt, dass dabei Elemente erstellt werden, die beschädigt erscheinen. Nachrichten, die über Drittanbieterprodukte oder Gateways von anderen Messagingsystemen übertragen wurden, können manchmal beschädigte Elemente hervorrufen. Dabei können so viele beschädigte Elemente in die Datenbank gelangen, dass eine Wiederherstellung von einer verzögerten Kopie die einzige Möglichkeit ist, um die Datenbank wieder fehlerfrei zu bekommen. Bei der Wiederherstellung mithilfe einer verzögerten Kopie setzen Sie die Datenbank auf einen Zustand zurück, den sie hatte, bevor die logische Beschädigung auftrat, die seitdem an die nicht verzögerten Kopien repliziert wurde. Dieser Vorgang kann viele Stunden in Anspruch nehmen: Sie müssen zunächst die Datenbankkopie isolieren, dann herausfinden, welche Transaktionsprotokolle gebraucht werden, um die Kopie auf den Stand vor dem Auftreten der Beschädigung zu bringen, diese Protokolle einspielen, um die Datenbank zu aktualisieren und in einen konsistenten Zustand zu
490
bringen, und schließlich den Dienst mithilfe der Datenbank wieder aufzunehmen. Ein weiterer Punkt, den Sie beachten müssen, ist der ungeheure Betrag an Speicherplatz, den Sie brauchen, um sämtliche während der Verzögerungszeit auflaufenden Transaktionsprotokolle festzuhalten. Bei einer Verzögerungszeit von sieben Tagen muss der Server, auf dem die verzögerte Kopie untergebracht ist, in der Lage sein, das gesamte Protokollvolumen von sieben Tagen aufzunehmen. Selbst bei einer nur mäßig beanspruchten Datenbank können das viele Gigabyte an Daten sein. HINWEIS Da eine Wiederherstellung dieser Art viel manuelle Arbeit und viel Zeit erfordert, sind verzögerte Kopien keine Hochverfügbarkeitsfunktion für Datenbanken. Sie sind sicherlich nützlich, bieten aber keine Hochverfügbarkeit. Wenn Sie ein für Datenbankverfügbarkeitsgruppen geeignetes, umfassendes Sicherungsprodukt wie Microsoft System Center Data Protection Manager 2010 verwenden, bringt diese Software wahrscheinlich die Fähigkeit mit, eine Datenbank in dem Zustand wiederherzustellen, den sie zu einem bestimmten Zeitpunkt hatte. Das ist auch der Sinn und Zweck von verzögerten Kopien, woraus folgt, dass solche Kopien weniger wichtig werden, wenn Sie ein umfassendes Sicherungsprodukt bereitstellen. Natürlich können Sie verzögerte Kopien als zusätzliche Sicherheitsmaßnahme gegen Datenverluste beibehalten, allerdings kann das schon übertrieben sein, da Sie schon durch den richtigen Einsatz eines Sicherungssystems ausreichenden Schutz gegen Bedienfehler, Speicherbeschädigungen oder irgendwelche andere Probleme haben, die Sie dazu zwingen könnten, auf eine verzögerte Kopie zurückzugreifen. Verzögerte Kopien sind auch dann nicht mehr so attraktiv, wenn Sie eine Speichertechnologie verwenden, die es Ihnen erlaubt, Snapshots der Datenbanken und Transaktionsprotokolle aufzuzeichnen und für Wiederherstellungszwecke zu nutzen. Einige der ausgefeiltesten Speichertechnologien von heute verfügen sogar über grafische Benutzeroberflächen, die die zeitpunktgenaue Datenbankwiederherstellung sehr leicht und schnell machen. Wenn Sie eine Datenbank in verschiedenen früheren Zuständen wiederherstellen können, z.B. in dem vor vier Stunden oder dem vor acht Stunden, es ist nicht nötig, sich die Ausgaben und die Schwierigkeiten aufzuhalsen, um eine verzögerte Datenbankkopie vorzuhalten. Zwei der höheren Eigenschaften von Postfachdatenbanken, die die verzögerte Protokollwiedergabe und -löschung steuern, können nur in der Exchange-Verwaltungsshell eingestellt werden. Ursprünglich waren diese Eigenschaften auch in der Benutzeroberfläche verfügbar, wurden dann aber von Microsoft aus der Konsole entfernt, da sie bei Administratoren, die nicht mit der Art und Weise der Wiedergabe von Transaktionsprotokollen in Exchange vertraut sind, viel Verwirrung stiften könnten. Man hatte das Gefühl, dass diese Eigenschaften nur die Administratoren etwas angingen, die vielschichtige Datenbankverfügbarkeitsgruppen verwalten, wohingegen die Exchange-Verwaltungskonsole für die Bedürfnisse der breiten Mehrheit da sein soll. Falls erforderlich können diese beiden Eigenschaften mit Add-MailboxDatabaseCopy und Set-MailboxDatabaseCopy festgelegt werden: 쐍 ReplayLagTime Die Zeit (im Format Tage.Stunden:Minuten:Sekunden), um die Exchange die Wiedergabe der Protokolle in der Datenbankkopie verzögert. Wenn Sie diesen Wert auf null setzen, spielt Exchange die neuen Transaktionsprotokolle sofort ein, nachdem sie auf dem Server mit der Datenbankkopie eingegangen sind. Mit dieser Einstellung können Sie dafür sorgen, dass der Zustand der Kopie auf diesem Server dem Zustand der aktiven Kopie ein wenig hinterherhinkt, sodass Sie bei einem Problem auf dem aktiven Server, das zu einer Datenbankbeschädigung führt, die Replikation anhalten und damit die Weiterverbreitung der Beschädigung in die Kopien verhindern können. Datenbankverfügbarkeitsgruppen mit verzögerten Kopien werden gewöhnlich so eingerichtet, dass zwei oder drei Kopien stets auf dem neuesten Stand gehalten werden, während eine (gewöhnlich in einem für die Notfallwiederherstellung vorgesehenen Standort) mit einer Wiedergabeverzögerung versehen wird. Die maximale Verzögerung beträgt 14 Tage. 491
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
쐍 TruncationLagTime Die Zeit (im Format Tage.Stunden:Minuten:Sekunden), um die das Abschneiden der Protokolle verzögert wird. Auch diesen Wert können Sie auf null setzen, sodass Exchange die Transaktionsprotokolle sofort abschneidet, sobald ihr Inhalt in die Datenbankkopie eingespielt wurde. An den meisten Standorten werden die Protokolle jedoch mindestens 15 Minuten lang aufbewahrt, sodass sie noch verfügbar sind, um die Datenbankkopie bei einem Ausfall auf den neuesten Stand zu bringen. Die maximale Verzögerungszeit für das Abschneiden der Protokolle beträgt sieben Tage. Jede Datenbankkopie weist ihre eigenen Verzögerungseinstellungen auf. Mit dem folgenden Befehl können Sie diese Einstellungen für eine Datenbank abrufen: Get-MailboxDatabase –Identity 'DB1' | Format-List DatabaseCopies, ReplayLagTimes, TruncationLagTimes DatabaseCopies : {DB1\EXSERVER1, DB1\EXSERVER2} ReplayLagTimes : {[EXSERVER1, 00:00:00], [EXSERVER2, 00:00:00]} TruncationLagTimes : {[EXSERVER1, 00:00:00], [EXSERVER2, 00:00:00]}
Auf den beiden Servern mit Kopien dieser Datenbank sind sowohl die Wartezeit für die Wiedergabe als auch die für das Abschneiden der Protokolle auf 00:00:00:00 gesetzt (was für beide Wartezeiten der Standardwert ist). Dies bedeutet, dass die Transaktionsprotokolle sofort wiedergegeben werden und auch das Abschneiden keinerlei Verzögerung unterliegt. Diese Einstellung können wir ändern, indem wir die Eigenschaften einer der Kopien bearbeiten. Mit dem folgenden Befehl legen wir für die Postfachdatenbank DB1 auf ExServer2 eine Wiedergabeverzögerung von sieben Tagen fest: Set-MailboxDatabaseCopy –Identity 'DB1\ExServer2' -ReplayLagTime 7.0:0:0
Jetzt zeigt das Cmdlet Get-MailboxDatabase folgende Ausgabe: ReplayLagTimes : {[EXSERVER1, 00:00:00], [EXSERVER2, 7.00:00:00]} TruncationLagTimes : {[EXSERVER1, 00:00:00], [EXSERVER2, 00:00:00]}
Sobald Sie eine Verzögerungszeit für eine Datenbankkopie festgelegt haben, können Sie ein Wachsen der Wiedergabewarteschlange feststellen. Das ist ganz normal und liegt daran, dass die Transaktionsprotokolle jetzt erst einmal kopiert, aber noch nicht wiedergegeben werden. Die Warteschlange wächst weiter, bis die ersten Protokolle die eingestellte Verzögerungszeit überschreiten und in die Datenbankkopie eingespielt werden. Mit der Zeit pendelt sich die Länge der Wiedergabewarteschlange in einem Bereich ein, der die durchschnittliche Transaktionslast während der Verzögerungszeit widerspiegelt. Je nach Größe und Belastung der Datenbank können das durchaus Zehntausende von Protokollen sein. (Achten Sie also darauf, genügend Speicherplatz für die Transaktionsprotokolle mit verzögerter Wiedergabe bereitzustellen.) Die Länge der Wiedergabewarteschlange können Sie mit Get-MailboxDatabaseCopyStatus überwachen: Get-MailboxDatabaseCopyStatus –Identity 'DB1\ExServer2'
492
Name
Status
--------DB1\EXSERVER2
-------Healthy
CopyQueue Length ---------0
ReplayQueue LastInspectedLogTime ContentIndex Length State ---------- ---------------------------7911 6/1/2010 4:15:23 PM Healthy
Wenn Sie die Verzögerungszeit für eine Datenbankkopie ändern, passt sich die Länge der Wiedergabeschlange entsprechend an. Bei einer Verlängerung der Verzögerungszeit wächst auch wie Warteschlange, bei einer Verkürzung schrumpft sie, da Exchange die Transaktionsprotokolle einspielt, die die neue Verzögerungszeit überschritten haben. Damit Active Manager eine verzögerte Datenbankkopie nach dem Ausfall der aktiven Kopie nicht als einen Kandidaten ansieht, der online geschaltet werden kann, sollten Sie die Aktivierung mit SuspendMailboxDatabaseCopy blockieren. Normalerweise setzen Sie damit die Replikation für eine Kopie aus, doch in diesem Fall verwenden wir den Parameter -ActivationOnly, um Exchange anzuweisen, die Replikation fortzusetzen, die verzögerte Kopie aber niemals automatisch zu aktivieren. Mit dem folgenden Befehl blockieren Sie beispielsweise die Aktivierung der Kopie von DB1 auf ExServer2: Suspend-MailboxDatabaseCopy –Identity 'DB1\ExServer2' –ActivationOnly
Wenn Sie durch irgendein Ereignis dazu gezwungen werden, die Kopie zu einem möglichen Kandidaten für eine Aktivierung zu machen, können Sie die Blockierung mit Resume-MailboxDatabaseCopy wieder aufheben: Resume-MailboxDatabaseCopy –Identity 'DB1\ExServer2'
Insidertipp: Verzögerte Datenbanken als Maßnahme zur Notfallwiederherstellung
Verzögerte Datenbankkopien sind ein Mechanismus zur Notfallwiederherstellung und sollten nur als letzte Möglichkeit herangezogen werden, um eine funktionierende Kopie einer Datenbank wiederzugewinnen, wenn alle anderen Maßnahmen fehlgeschlagen sind. Übereifrige Verfechter dieser Funktion haben zwar schon behauptet, dass verzögerte Datenbankkopien Sicherungen überflüssig machen würden, da man schließlich immer eine Wiederherstellung zu einem bestimmten früheren Zeitpunkt vornehmen kann, aber das ist ein Irrglaube. Die wenigsten Systemadministratoren haben ausreichende Erfahrungen mit dem langfristigen Einsatz von Datenbankverfügbarkeitsgruppen und verzögerten Kopien auf Produktionsniveau. Daher hatten sie auch nie die Gelegenheit, die erforderlichen Fähigkeiten zu entwickeln, um eine Wiederherstellung von einer verzögerten Kopie durchzuführen. Außerdem bieten verzögerte Kopien nicht die Genauigkeit, um eine Datenbank in den Zustand zu einem bestimmten Zeitpunkt zurückzuversetzen. Es ist nicht möglich, Exchange beispielsweise anzuweisen, die Datenbank auf »16.23 Uhr am 27. August 2010« zurückzusetzen. Es ist nicht sinnvoll, auf das warme Gefühl der Sicherheit zu verzichten, das ein gut gestaltetes und häufig geübtes Sicherungsverfahren den Administratoren gibt, die ihre Daten in Sicherheit wissen und beruhigt davon ausgehen können, dass eine Wiederherstellung im Ernstfall möglich ist. Bis sich ein solches Gefühl auch aufgrund anderer Technologien einstellt, müssen noch einige weitere Versionen von Exchange erschienen sein. In der Zwischenzeit können sich diejenigen, die sich an den ungeschliffenen Kanten neuer Technologien ergötzen, ihre Daten mithilfe von verzögerten Kopien schützen, während wir anderen uns vorläufig an herkömmliche Sicherungen halten.
Aktivieren einer Postfachdatenbankkopie Wenn eine passive Kopie durch einen Administratoreingriff zur aktiven Kopie gemacht wird, spricht man von einem Switchover. Das geschieht gewöhnlich, wenn der Administrator die Clients zu einer Kopie auf einem anderen Server umleiten möchte, weil er den ursprünglichen aktiven Server einer Wartung unterziehen und daher offline schalten muss. Um eine Datenbankkopie auf einem anderen
493
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Server zu aktivieren, wechseln Sie zum Knoten Postfach unter Organisationskonfiguration, markieren die gewünschte Postfachdatenbank und wählen im Aktionsbereich die Option Aktive Postfachdatenbank verschieben. Die Exchange-Verwaltungskonsole zeigt daraufhin den Assistenten zum Aktivieren einer Datenbankkopie an (siehe Abbildung 8.22). Hier können Sie den Postfachserver mit der Kopie auswählen, die Sie aktivieren möchten. Abbildg. 8.22
Aktivieren einer Datenbankkopie
Der Assistent führt in alphabetischer Reihenfolge alle Server auf, die eine zurzeit verfügbare Kopie haben. Wenn Sie den einzelnen Kopien eine Prioritätsnummer zugewiesen haben, um eine bevorzugte Reihenfolge für die Aktivierung festzulegen, wird dies vom Assistenten bei der Anzeige der verfügbaren Server nicht berücksichtigt. Es wird auch keine Warnung angezeigt, wenn Sie die Kopie mit der geringsten Priorität auswählen, da Exchange davon ausgeht, dass Sie schon wissen, was Sie tun, wenn Sie die zu aktivierende Kopie ausdrücklich auswählen. Die Prioritätswerte werden nur dann zur Entscheidung herangezogen, wenn der PAM aufgrund eines Server- oder Speicherausfalls, der die aktive Datenbankkopie unerreichbar macht, einen Wechsel durchführen müssen. Um den Assistenten zu umgehen, können Sie auch einen Server auf der Liste der Datenbankkopien auswählen, mit der rechten Maustaste darauf klicken, die Option Datenbankkopie aktivieren aus dem Kontextmenü auswählen und dann auf OK klicken (siehe Abbildung 8.23). Dabei haben Sie weniger Auswahlmöglichkeiten, sind aber schneller fertig. Der weitere Ablauf ist jedoch von der gewählten Methode unabhängig. Sofern die Datenbankkopie fehlerfrei ist und alle erforderlichen Transaktionen verfügbar sind, um sie auf den neuesten Stand zu bringen, schaltet der Informationsspeicher auf dem ausgewählten Server die Datenbank online und lässt Clientverbindungen zu. Das geschieht sehr schnell, denn Exchange muss dazu nur einige interne Zeiger ändern, um deutlich zu machen, dass jetzt eine andere Datenbankkopie aktiv ist. Es werden keine Dateien verschoben, kopiert oder auf irgendeine andere Weise bearbeitet, die den Vorgang verlangsamen könnte. Sobald die ausgewählte Kopie aktiviert ist, nehmen die anderen Kopien eine kurze Neusynchronisierung vor, um sich an die neue Situation anzupassen. Daraufhin geht der normale Betrieb weiter. 494
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Schnelle Aktivierung einer Datenbankkopie in der Exchange-Verwaltungskonsole
Exchange auf dem Weg zur Hochverfügbarkeit
Abbildg. 8.23
Unmittelbar nach dem Switchover können Sie eine Anwachsen der Kopierwarteschlange für die gerade aktivierte Datenbankkopie sehen, die aber sehr schnell wieder auf die Länge 0 zusammenschrumpft. Im Rahmen des Switchovervorgangs werden auch die Transaktionsprotokolle überprüft, um sicherzsutellen, dass alle vorhanden sind. Dieser Durchgang erfolgt sehr schnell, und die große Länge der Kopierwarteschlange ist daher auch kein Problem, sofern sie nicht länger als eine Minute in diesem Zustand bleibt. Einen Failover müssen die Administratoren nicht manuell durchführen, denn darum kümmert sich Exchange automatisch, wenn ein Server oder eine Festplatte offline geht und dadurch die aktive Datenbank unzugänglich wird. Um zu entscheiden, welche Datenbankkopie aktiviert werden soll, zieht Exchange die Aktivierungspriorität heran. Die Prioritätswerte werden beim Erstellen einer Datenbankkopie zugewiesen und können später mit dem Cmdlet Set-MailboxDatabase geändert werden. Um eine vollständige Liste der Datenbankkopien und ihrer Aktivierungsprioritäten einzusehen, verwenden Sie folgenden Befehl: Get-MailboxDatabase | Select Name, ActivationPreference, Server | Sort Name | Format-Table -AutoSize Name --------Dublin Users DB1 DB2 DB3 IT Department Operations PR Sales VIP Data
ActivationPreference ---------------------------{[ExServer3, 1], [ExServer4, {[ExServer1, 1], [ExServer2, {[ExServer2, 1], [ExServer3, {[ExServer3, 1], [ExServer1, {[ExServer1, 1], [ExServer2, {[ExServer4, 1], [ExServer3, {[ExServer1, 1], [ExServer4, {[ExServer4, 1], [ExServer3, {[ExServer1, 1], [ExServer2,
2]} 2]} 2]} 2], [ExServer2, 3]} 2], [ExServer3, 3]} 2]} 2]} 2]} 2]}
Server -------ExServer3 ExServer1 ExServer2 ExServer1 ExServer1 ExServer4 ExServer1 ExServer3 ExServer1
Diese Ausgabe zeigt die bevorzugte Aktivierungsreihenfolge und nennt die Server, auf denen sich zurzeit die aktiven Datenbanken befinden. Wie Sie sehen, laufen zwei Datenbanken zurzeit nicht auf dem bevorzugten Server: DB3 ist auf ExServer1 aktiv und Sales auf EsServer3. Es scheint keinen Grund dafür zu geben, dass die Datenbanken nicht auf ihrem bevorzugten Server aktiv sind, da auf diesen
495
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Servern ja auch andere Datenbanken ausgeführt werden. Das mag ein Hinweis sein, um einmal nachzuforschen, warum das so ist, und um entweder die Prioritätswerte an die tatsächliche Situation anzupassen oder die Datenbanken wieder auf den bevorzugten Server zu schalten. Außerdem können Sie sehen, dass auf ExServer1 fünf der neun Datenbanken aktiv sind, obwohl in dieser Verfügbarkeitsgruppe noch drei andere Server vorhanden sind. Das ist eine anomale Verteilung der Last, die eine weitergehende Untersuchung und einen Ausgleich erfordert. Ein kleines Skript kann dabei helfen, herauszufinden, ob die Datenbanken auf dem bevorzugten Server bereitgestellt sind. Das folgende Skript stammt von Paul Flaherty und ist im Web zu finden. Das Ergebnis sehen Sie in Abbildung 8.24. Außerdem gibt es Skripts, die eine Datenbank wieder auf dem Server mit der Aktivierungspriorität 1 aktiv schalten. Get-MailboxDatabase | Sort Name | ForEach {$db=$_.Name; $xNow=$_.Ser ver.Name ;$dbown=$_.ActivationPreference| Where {$_.Value -eq 1}; Write-Host $db "on" $xNow "Should be on" $dbOwn.Key -NoNewLine; If ( $xNow -ne $dbOwn.Key){Write-host " WRONG" -ForegroundColor Red; }ELSE {Write-Host " OK" -Foregroundcolor Green}} Abbildg. 8.24
Vergleichen der tatsächlichen Bereitstellung von Datenbanken mit ihren Aktivierungsprioritäten
Microsoft liefert zusammen mit Exchange Server 2010 SP1 das Skript RedistributeActiveDatabases.ps1 (das Sie im standardmäßigen Skriptordner finden). Damit können Administratoren die aktiven Datenbanken nach einem Serverausfall neu verteilen. Das Skript kann in zwei Modi ausgeführt werden: 쐍 BalanceDbsByActivationPreference In diesem Modus wird versucht, wieder die Datenbankkopien mit dem höchsten Prioritätswert aktiv zu schalten, ohne dabei die Verteilung auf die Active Directory-Standorte zu berücksichtigen. Da Datenbankverfügbarkeitsgruppen meistens nur einen Standort umfassen, ist dies der am häufigsten eingesetzte Modus. 쐍 BalanceDbsBySiteAndActivationPreference Auch in diesem Modus wird versucht, wieder die Datenbankkopien mit dem höchsten Prioritätswert aktiv zu schalten, doch hierbei wird die Verteilung auf die Active Directory-Standorte berücksichtigt. Wenn die Datenbanken in der Verfügbarkeitsgruppe beispielsweise auf drei Standorte verteilt sind, versucht das Skript, auf den Servern jedes Standorts jeweils ein Drittel der insgesamt verfügbaren Datenbanken zu aktivieren. Diese Vorgehensweise ist offensichtlich viel komplizierter und sollte daher vor dem Einsatz in der Produktion sorgfältig getestet werden. Um beispielsweise die aktiven Datenbanken in der Verfügbarkeitsgruppe DAG1 nach ihrer Priorität neu zu verteilen, geben Sie den folgenden Befehl ein. Der Parameter -ShowFinalDatabaseDistribution sorgt dafür, dass das Skript anschließend die endgültige Verteilung der Datenbanken ausgibt. RedistributeActiveDatabases.ps1 –DAGName DAG1 –BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution
496
Anwenden von Aktualisierungen auf Server mit Datenbankverfügbarkeitsgruppen Zu den unveränderlichen Tatsachen des Administratorenlebens gehört es, dass regelmäßig Softwareaktualisierungen für Exchange, Windows und andere Produkte erscheinen. Zwar sind Sie nicht verpflichtet, die regelmäßigen Rollupupdates und Service Packs zu installieren, die Microsoft für Exchange Server 2010 herausgibt, doch ist es von Vorteil, stets die neueste Software auszuführen, in der alle bisher bekannt gewordenen Probleme ausgebügelt wurden. Dies gilt vor allem für die Sicherheitskorrekturen, die fortlaufend herausgebracht werden, um entdeckte Schwachstellen zu beseitigen. In diesem Kapitel haben wir schon gesehen, dass in einer Datenbankverfügbarkeitsgruppe ein Umschalten von einem SP1-Server zu einem RTM-Server möglich ist, aber nicht umgekehrt. Das allein unterstreicht schon die Notwendigkeit, alle Mitgliedserver in einer solchen Gruppe mit der neuesten Version von Exchange zu versehen. Da Exchange Server 2010 sehr viel neue Technologie enthält, ist es unvermeidlich, dass Bugs zum Vorschein kommen, weshalb es sinnvoll ist, stets auf dem neuesten Stand der von Microsoft veröffentlichten Softwarekorrekturen zu bleiben. Das heißt aber nicht, dass Sie Patches sofort nach dem Erscheinen installieren sollten. Nehmen Sie sich wie bei jeder neuen Software erst die Zeit, sie zu testen, bevor Sie sie in einer Produktionsumgebung einsetzen. Die Kunst des Softwaretests ist heutzutage schon weit fortgeschritten, und Microsoft und andere Hersteller betreiben einen großen Aufwand, um Patches auf ihre Eignung für verschiedene Konfigurationen zu testen. Unter anderem werden Regressionstests durchgeführt, um sicherzustellen, dass die Korrektur nicht zu einem anderen Problem führt. Allerdings bleibt immer die Möglichkeit, dass es in Ihrer Umgebung einen besonderen Aspekt gibt, der bei der Installation einer Rollupaktualisierung oder eines Service Packs Fehler verursachen kann. Die üblichen Vorsichtsmaßnahmen für Softwareaktualisierungen gelten auch für die Server in einer Datenbankverfügbarkeitsgruppe. Fertigen Sie eine Sicherung an, führen Sie den Installationsvorgang zuvor auf einem Testserver durch, der die Produktionsumgebung genau widerspiegelt, halten Sie sämtliche Software und alle Lizenzen griffbereit, die Sie benötigen könnten, sehen Sie genügend Zeit für die Arbeit vor und führen Sie sie zu einer Zeit durch, an der ein Ausfall nicht zu schweren Störungen der Benutzer führt. Bei Servern in einer Datenbankverfügbarkeitsgruppe müssen Sie darüber hinaus noch folgende besondere Maßnahmen ergreifen: 쐍 Blocken Sie die mögliche Aktivierung des Servers, den Sie aktualisieren wollen. Es wäre schlecht, wenn andere Server Datenbanken auf den Computer übertragen würden, an dem Sie gerade arbeiten. 쐍 Schalten Sie vor Beginn der Aktualisierung die aktiven Datenbanken auf dem betreffenden Server zu anderen Servern in der Gruppe um. 쐍 Vergewissern Sie sich, dass alle Datenbanken auf anderen Servern aktiv sind und dass die Benutzer durch den Switchover nicht beeinträchtigt wurden. 쐍 Führen Sie die Aktualisierung durch und überprüfen Sie, ob der Server anschließend noch korrekt funktioniert. Möglicherweise muss der Server neu gestartet werden, und wenn das der Fall ist, müssen Sie sich auch vergewissern, dass nach dem Neustart noch alles richtig funktioniert. 쐍 Heben Sie die Blockierung der Datenbanken wieder auf.
497
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
쐍 Schalten Sie die Datenbanken von den anderen Servern wieder auf den aktualisierten Computer um und stellen Sie dabei jeweils sicher, dass die Benutzer störungsfrei weiterarbeiten können. 쐍 Gehen Sie zum nächsten Server in der Datenbankverfügbarkeitsgruppe über und wiederholen Sie den Vorgang dort. Um die Aktivierung von Datenbanken auf einem Server zu blockieren, damit Exchange nicht versucht, sie während der Aktualisierung zu verwenden, führen Sie das Cmdlet Suspend-MailboxDatabaseCopy für jede Datenbank auf dem Server aus. Eine Liste der Datenbanken liefert Get-MailboxDatabaseCopyStatus, sodass wir das Ergebnis dieses Befehls an Suspend-MailboxDatabaseCopy weiterleiten können. Der folgende Befehl hält die Verarbeitung nicht an, sondern teilt Exchange nur mit, dass keine der Datenbankkopien auf dem Server aktiviert werden darf: Get-MailboxDatabaseCopyStatus | Suspend-MailboxDatabaseCopy –ActivationOnly –Confirm:$False
Um die Datenbanken umzuschalten, können wir entweder Exchange entscheiden lassen, wie sie am besten auf die verfügbaren Server in der Gruppe verteilt werden sollen, oder einen Zielserver angeben. Damit Exchange alle Datenbanken auf einem Server selbstständig umschaltet, verwenden Sie einen Befehl wie den folgenden: Move-ActiveMailboxDatabase –Server ExServer4
Alternativ können Sie auch einen Zielserver angeben: Move-ActiveMailboxDatabase –Server ExServer4 –ActivateOnServer ExServer2
Des Weiteren haben Sie die Möglichkeit, jede Postfachdatenbank einzeln umzuschalten und jeweils den gewünschten Server anzugeben: Move-ActiveMailboxDatabase –Identity 'Sales' –ActivateOnServer ExServer3
Nachdem Sie die Aktualisierung angewandt und geprüft haben, können Sie die Aktivierungssperre wieder aufheben: Get-MailboxDatabaseCopyStatus | Resume-MailboxDatabaseCopy
Auch dieser Befehl sorgt nicht dafür, dass irgendeine Form der Verarbeitung wiederaufgenommen wird, sondern informiert Exchange lediglich darüber, dass der Server wieder zur Verfügung steht, sodass die auf ihm vorhandenen Datenbankkopien bei Bedarf aktiviert werden können.
Umgang mit ausgefallenen Servern Es wäre schön, wenn wir uns niemals um einen ausgefallenen Server kümmern müssten, aber die Lebensumstände, die Software und die Hardware sind gegen uns. Daher müssen wir allzeit bereit sein, uns diesem Problem zu stellen, indem wir alle auf einem ausgefallenen Server bereitgestellten Datenbanken umschalten. Dazu verwenden Sie die Option Switchover-Server, die in Abbildung 8.25 zu sehen ist. In der Abbildung können Sie erkennen, dass ein Problem auf dem Computer ExServer2 vorliegt, da als Kopierstatus aller drei Datenbanken, die auf diesem Server bereitgestellt sein sollen, ServiceDown angezeigt wird. Es muss sich dabei zwar nicht um ein reines Exchange-Problem handeln, aber auf jeden Fall müssen wir etwas tun, da mehrere Datenbanken ausgefallen sind.
498
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Durchführen eines Switchovers in einer Datenbankverfügbarkeitsgruppe
Exchange auf dem Weg zur Hochverfügbarkeit
Abbildg. 8.25
Wenn Sie auf Switchover-Server klicken, zeigt Ihnen Exchange die Optionen an, die Sie in Abbildung 8.26 sehen. Sie können die Datenbank vom ausgefallenen Server auf einen Server umschalten, den Sie selbst auswählen, oder Exchange automatisch einen Zielserver für die einzelnen Datenbanken aussuchen lassen. Im letzteren Fall versucht Exchange, die bereitgestellten Datenbanken in der Gruppe möglichst gleichmäßig auf die Mitgliedserver zu verteilen. TIPP Am besten ist es, Exchange automatisch einen Zielserver auswählen zu lassen, da Sie die Datenbanken dadurch schnell online bekommen können, ohne erst lange überlegen zu müssen. Anschließend können Sie immer noch kleine Änderungen an der Verteilung vornehmen, indem Sie die eine oder andere Datenbank auf einen anderen Server umschalten. Abbildg. 8.26
Optionen für einen Switchover
Überschreiben von AutoDatabaseMountDial beim Umschalten von Datenbanken Der Einstellung AutoDatabaseMountDial für Postfachdatenbanken sind wir bereits begegnet, als wir uns den ACLL-Vorgang angesehen haben, mit dem Active Manager einen automatischen Datenbankfailover durchführt. Diese Einstellung teilt Exchange mit, was für ein Datenverlust beim Umschalten 499
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
einer Datenbank akzeptabel ist. Im Idealfall sind alle Datenbankkopien vollständig mit der aktiven Kopie synchronisiert, sodass auch die Kopie, die Sie online bringen, auf dem neuesten Stand ist. Die Standardeinstellung zum Überschreiben von AutoDatabaseMountDial bei der automatischen Bereitstellung der Datenbank auf dem Zielserver lautet daher None (also kein Überschreiben), sodass der Informationsspeicher die Einstellung von AutoDatabaseMountDial unverändert auf dem Server anwendet. Wenn die Umstände jedoch nicht ideal sind und beispielsweise ein Netzwerkausfall verhindert hat, dass die letzten Transaktionsprotokolle auf den Zielserver kopiert wurden, kann die dortige Kopie unter Umständen nicht vollständig synchronisiert sein. In einer solchen Situation können Sie den Informationsspeicher anweisen, die Einstellung AutoDatabaseMountDial für die Datenbank zu überschreiben, damit er selbst entscheiden kann, ob er die Datenbank nach der neuen Einstellung bereitstellen soll oder nicht. Diese Eigenschaft (die übrigens auch in Exchange Server 2007 für Cluster mit fortlaufender Cluster- oder Standbyreplikation verwendet wird) ändern Sie mit Set-MailboxServer. Der Wert, den Sie angeben, gilt für alle Datenbanken auf dem Server. Set-MailboxServer –Identity 'ExServer2' –AutoDatabaseMountDial 'LossLess'
Der Standardwert für AutoDatabaseMountDial auf einem Server ist BestAvailability. Das bedeutet, dass eine Datenbank automatisch bereitgestellt werden kann, wenn die Kopierwarteschlange (die Anzahl der Protokolle, die noch nicht repliziert sind) nicht mehr als zwölf Protokolle umfasst. Andere mögliche Werte sind GoodAvailability, wobei die Warteschlange nicht mehr als sechs Protokolle umfassen darf, und Lossless, was bedeutet, dass die Datenbank nur dann bereitgestellt wird, wenn alle auf dem aktiven Server generierten Protokolle auf den Server mit der passiven Kopie repliziert wurden. Lossless stellt sicher, dass bei einem Failover keine Daten verloren gehen, da alle Protokolle vorhanden sein müssen. Bei den anderen Einstellungen kann es zu Datenverlusten verschiedenen Umfangs kommen, da bis zu 12 MB an Transaktionsdaten fehlen können. Es ist schwer zu sagen, was ein solcher Verlust für die Praxis bedeutet, denn dies hängt von Transaktionen in den verlorenen Protokollen ab. Wenn Sie Glück haben, betreffen die verloren gegangenen Daten Antworten von Benutzern auf Besprechungsanfragen, doch es ist durchaus möglich, dass Sie wichtige Nachrichten verlieren. In jedem Fall aber besteht die Möglichkeit, diese Daten aus dem Transportpapierkorb zurückzugewinnen, der die Nachrichten, die während des Failovers gerade unterwegs waren, neu überträgt. In Kapitel 13, »Das Exchange-Transportsystem«, finden Sie eine ausführlichere Beschreibung, wie der Transportpapierkorb die Nachrichten schützt, die gerade zwischen zwei Servern unterwegs sind. Wenn Active Manager eine Datenbank nicht automatisch bereitstellen kann, da die Anforderungen von AutoDatabaseMountDial aus einem anderen Grund nicht erfüllt sind, kann ein Administrator trotzdem für ihre Bereitstellung sorgen. Beispielsweise kann es sein, dass der Inhaltsindex einer Datenbankkopie unvollständig ist, sodass Active Manager sie ignoriert. Mit Move-ActiveMailboxDatabase können Sie Exchange dazu zwingen, diese Kopie trotzdem zu aktivieren. Mit dem folgenden Befehl wird eine bestimmte Datenbank auf ExServer2 aktiviert: Move-ActiveMailboxDatabase –Identity 'DB1' –ActivateOnServer 'ExServer2' –MountDialOverride BestEffort
In diesem Beispiel haben wir den Wert BestEffort verwendet, um die Einstellung von AutoDatabaseMountDial zu überschreiben. Dieser Wert ist nicht dokumentiert, aber wird auch im Assistenten zum Aktivieren einer Datenbankkopie der Exchange-Verwaltungskonsole angezeigt (hier allerdings als Beste Leistung – siehe Abbildung 8.22). Er besagt, dass Exchange die Datenbankkopie unabhängig von der Länge der Kopierwarteschlange bereitstellen kann. Damit sagen Sie letzten Endes, dass es Ihnen egal ist, wie viele Transaktionsprotokolle nicht kopiert worden sind, und dass Sie nur daran interes-
500
siert sind, die Datenbank irgendwie online zu bekommen. Diese Überschreibeinstellung können Sie verwenden, wenn durch ein katastrophales Ereignis überhaupt kein Zugriff auf ein Rechenzentrum mehr besteht und Sie die Datenbanken in einem zweiten Rechenzentrum aktivieren möchten. VORSICHT Setzen Sie BestEffort nur mit äußerster Vorsicht ein, denn dabei erleiden Sie fast mit Sicherheit Datenverluste. Aus diesem Grunde können Sie AutoDatabaseMountDial mit Set-MailboxServer auch nicht direkt auf BestEffort setzen. Im folgenden Beispiel wählen wir mit Move-ActiveMailboxDatabase eine Datenbank aus und schalten Sie auf ExServer2 um. Durch den Wert $False für den Parameter -Confirm verhindern Sie, dass Exchange Sie um eine Bestätigung für den Vorgang bittet. Move-ActiveMailboxDatabase -Identity 'DB2'-ActivateOnServer 'ExServer2' –Confirm $False
Die Aktivierung schlägt fehlt, wenn sich der Suchkatalog auf dem Zielserver nicht in fehlerfreiem Zustand befindet (wenn der Katalog also aus irgendeinem Grund unvollständig ist). Das ist so beabsichtigt, damit die Clients in der neu aktivierten Datenbank weiterhin Suchvorgänge durchführen können. Ignorieren des Suchkatalogs
Mit dem Parameter SkipClientExperienceChecks können Sie Exchange dazu zwingen, den Suchkatalog zu ignorieren. Vielleicht fragen Sie sich, was der Name dieses Parameters zu bedeuten hat. Nach Ansicht von Microsoft verschlechtert das Fehlen des Inhaltsindex die Leistung des Clients, weshalb diese Bezeichnung gewählt wurde. Den Suchkatalog können Sie ohne Risiko ignorieren, und auch die Benutzer werden dadurch nicht übermäßig beeinträchtigt. Lediglich wenn sie versuchen, Onlinesuchvorgänge durchzuführen, müssen sie feststellen, dass der Katalog entweder nicht verfügbar oder unvollständig ist. Die Auswirkungen eines fehlenden Katalogs zeigen sich vor allem in Outlook Web App (OWA), Exchange-Webdienstclients und Clients für mobile Geräte und weniger in Outlook, denn wenn Sie Outlook im Exchange-Cache-Modus einrichten, werden die Suchvorgänge im Hauptpostfach auf dem Client durchgeführt statt auf dem Server. Der fehlende Katalog macht sich also nur bei Suchvorgängen in Archivpostfächern bemerkbar. Um die Datenbank zu aktivieren und den fehlenden Katalog dabei zu ignorieren, verwenden Sie folgenden Code: Move-ActiveMailboxDatabase -Identity 'DB2'-SkipClientExperienceChecks -ActivateOnServer ExServer2 -Confirm $False
Wenn die Clientverbindungen zu der neu aktivierten Datenbankkopie aufgebaut sind, können Sie Exchange anschließend dazu bringen, den Katalog zu aktualisieren. Am sinnvollsten ist es dabei, Exchange anzuweisen, ein Reseeding des Katalogs von einer anderen Ausfertigung vorzunehmen, die sich online befindet. Wenn ein solches Exemplar zur Verfügung steht, können Sie einen Befehl wie den folgenden verwenden: Update-MailboxDatabaseCopy –Identity 'DB2' –CatalogOnly
Wenn Sie die Zeit dazu haben, können Sie alternativ auch erst das Reseeding des Katalogs abwarten und die Datenbank erst dann aktivieren. Das Problem dabei ist, dass es in solchen Fällen aus betrieblichen Gründen meistens wichtiger ist, die Postfächer online zu bekommen und den Benutzern zur Verfügung zu stellen, als dafür zu sorgen, dass alles korrekt läuft, sodass Sie gar nicht die Zeit haben, erst den Katalog neu zu erstellen.
501
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Mit Move-ActiveMailboxDatabase können Sie auch sämtliche Datenbanken auf einem Server auf andere Server umschalten, auf denen sich Kopien davon befinden. Dadurch führen Sie im Grunde genommen einen kompletten Server-Switchover durch. Mit dem folgenden Befehl weisen Sie Exchange beispielsweise an, sämtliche Datenbanken von ExServer2 umzuschalten. Active Manager wählt dann die geeignetsten Kopien in der Datenbankverfügbarkeitsgruppe zur Aktivierung aus. Move-ActiveMailboxDatabase –Server 'ExServer2'
Auf einem Server mit der Enterprise Edition von Exchange Server 2010 können Sie bis zu 100 Datenbanken bereitstellen (worin die Wiederherstellungsdatenbank nicht enthalten ist), in der Standard Edition nur fünf. Das ist jeweils die Summe für aktive und passive Datenbanken zusammen. Zwar können Sie in Exchange Server 2010 auf einem Server bis zu 257 Postfachdatenbanken erstellen, aber nur 100 davon bereitstellen. Insidertipp: Vermeiden von Leistungseinbußen
Jede bereitgestellte Datenbank verbraucht Systemressourcen. Um zu verhindern, dass Active Manager auf einem Server so viele Datenbanken aktiviert, dass die Leistung darunter leidet, können Sie mit Set-MailboxServer einen Grenzwert für die Anzahl der bereitgestellten Datenbanken auf dem Computer festlegen. Beispielsweise beschränken Sie die Anzahl wie folgt auf 20 aktive Datenbanken: Set-MailboxServer –Identity 'ExServer1' –MaximumActivateDatabases 20
Wenn ein Administrator oder Active Manager versucht, über dieses Limit hinaus Datenbanken zu aktivieren, verweigert der Informationsspeicher die Bereitstellung und verzeichnet im Anwendungsprotokoll den Fehler ecTooManyMountedDatabases. Sobald die RPC-Clientzugriffsschicht den Wechsel bemerkt, leitet sie die Clients zu der neu aktivierten Datenbank um. Exchange Server 2010 führt ein »Vorwärmen« des Caches durch, damit die neue aktive Datenbank nicht im »kalten« Zustand startet, was die Reaktion auf Clientanforderungen verlangsamen könnte. Der Informationsspeicher auf dem Server mit der neuen aktiveren Datenbank hat die eingegangenen Transaktionsprotokolle eingespielt und einen Cache der kürzlich verwendeten Seiten unterhalten. »Vorwärmen« bedeutet, dass der Informationsspeicher diesen während der Wiedergabe der Transaktionsprotokolle erstellten Cache nicht verwirft und mit den von den Clients angeforderten Seiten neu erstellt, sondern beibehält. Da die Seiten in diesem Cache zu den jüngsten Transaktionen gehören, ist es wahrscheinlich, dass die Clients auch nach der Verbindung zu der neuen aktiven Datenbank darauf zugreifen wollen. Wie ein Client auf den Datenbankwechsel reagiert, hängt von seiner Version und Plattform ab. Outlook-Clients im Exchange-Cache-Modus melden, dass sie die Verbindung verloren haben, und nehmen erneut Verbindung auf, wenn die Datenbank wieder online ist. Outlook 2010 unterdrückt Nachrichten über eine verlorene Anbindung aus trivialen Gründen wie Netzwerkstörungen, weshalb Sie nur dann eine Meldung sehen, wenn die Verbindung wiederhergestellt ist. Nach der erfolgreichen Bereitstellung einer Datenbank weist der Informationsspeicher den Transportpapierkorb an, alle Nachrichten wiederherzustellen, die während des Umschaltvorgangs gerade übertragen wurden und sich noch im Papierkorb befinden. Außerdem benachrichtigt Active Manager den RPC-Clientzugriffsserver darüber, dass jetzt eine andere Kopie der Datenbank aktiv ist, sodass die Clientverbindungen dorthin umgeleitet werden können.
502
Wenn der Fehler behoben ist, der zu dem Wechsel führte, und der ursprüngliche Server wieder online geht, ist seine Datenbankkopie passiv und auf einem älteren Stand als die anderen Kopien. Der Informationsspeicher auf diesem Server ermittelt die Abweichungen und führt dann ein inkrementelles Reseeding durch, um die Datenbank wieder auf den neuesten Stand zu bringen. Als Erstes ermittelt er dabei den Punkt, an dem die Abweichungen beginnen, indem er die Transaktionsprotokolle auf dem Server mit denen auf einem Server mit einer aktuellen Kopie vergleicht. Der Informationsspeicher kann herausfinden, welche Datenbankseiten nach diesem Zeitpunkt geändert wurden, und Kopien dieser geänderten Seiten von einem anderen Server anfordern. Die Seiten werden eingespielt, bis die ausgefallene Kopie mit den anderen synchronisiert ist. Angestrebt wird dabei, all diese Vorgänge so zu erledigen, dass die Datenbank innerhalb von 30 Sekunden den Benutzern zur Verfügung steht. In manchen Fällen ist ein inkrementelles Reseeding nicht möglich, da die Datenbank zu stark von den anderen Kopien abweicht, z.B. weil sie sehr lange offline war. In diesen Fällen macht Exchange Sie darauf aufmerksam, dass ein vollständiges Reseeding erforderlich ist, um die Kopie wieder auf den neuesten Stand zu bringen.
Blockieren der Aktivierung Manchmal müssen Sie die Aktivierung einer bestimmten Datenbankkopie nach einem Ausfall verhindern, z.B. auf einem Server, auf dem Sie gerade eine Aktualisierung vornehmen oder einen Patch anwenden. Damit Active Manager die Datenbanken auf einem Server nicht automatisch aktiviert, setzen Sie die Eigenschaft DatabaseCopyAutoActivationPolicy mit Set-MailboxServer auf Blocked: Set-MailboxServer –Identity 'ExServer1' –DatabaseCopyAutoActivationPolicy 'Blocked'
Um die automatische Aktivierung wieder zu ermöglichen, gehen Sie wie folgt vor: Set-MailboxServer –Identity 'ExServer1' –DatabaseCopyAutoActivationPolicy 'Unrestricted'
In manchen Unternehmen wird ein besonderer Server bereitgestellt, dem zwar die Transaktionsprotokolle übertragen werden, sodass er sie in seine Datenbankkopien einspielen kann, der aber nicht in der Produktion verwendet wird und dafür häufig auch gar keine genügende Hardwareausstattung aufweist. Stattdessen wird dieser Server dazu verwendet, um Sicherungen durchzuführen, mit denen dann nicht die aktiven Server belastet werden müssen, um Daten aus Sicherungen wiederzugewinnen, um Discoverysuchvorgänge vorzunehmen usw. In Exchange Server 2003 und Exchange Server 2007 gab es eine ähnliche Technik: Dort konnten Sie in Clustern mit mehreren Knoten einen Koten für Sicherungen reservieren und einen anderen für Wartungsvorgänge. Wenn Sie einen solchen Server bereitstellen, müssen Sie eine Serveraktivierungsrichtlinie festlegen, um die Aktivierung zu verhindern, da dieser Server wahrscheinlich nicht in der Lage ist, die Last nach einem Datenbankwechsel zu tragen. Falls Sie doch einmal eine Datenbankkopie auf diesem Server aktivieren müssen, können Sie die Richtlinie ändern oder die Kopie mit Move-ActiveMailboxDatabase ausdrücklich bereitstellen. Außerdem können Sie festlegen, wie viele Datenbanken Exchange auf einem Server aktivieren darf. Das ist wichtig, wenn Sie sicherstellen müssen, dass CPU, Festplatte und Arbeitsspeicher des Computers nicht überlastet werden. Nehmen wir an, Sie haben in einer Datenbankverfügbarkeitsgruppe einen kleinen Server für die Datenbanken von VIP-Benutzern. Wenn sich auf dem Server fünf aktive und fünf passive Datenbanken befinden und er die Belastung durch bis zu acht aktive Datenbanken aushält, können Sie diesen Grenzwert wie folgt mit Set-MailboxServer festlegen:
503
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Set-MailboxServer –Identity 'LondonVIP' –MaximumActiveDatabases 8
Bei dieser Einstellung kann Active Manager drei der fünf passiven Datenbanken aktivieren. Diese Vorgehensweise können Sie auch verwenden, um die Anzahl der aktiven Datenbanken gleichmäßiger auf den Servern einer Verfügbarkeitsgruppe zu verteilen. Wählen Sie den Grenzwert so aus, dass die Last nach einem Ausfall gleichmäßig verteilt ist und kein Server unter einer besonderen Belastung leidet. Wenn Sie die mögliche Anzahl der Datenbanken auf einem Server beschränken, kann das dazu führen, dass Active Manager die Aktivierungsprioritäten für eine Datenbank übergeht. Da sich die Anzahl der bereitgestellten Datenbanken aufgrund eines Administratoreingriffs oder Failovers jederzeit ändern kann, vergleicht Active Manager die aktuelle Anzahl aktiver Datenbanken auf einem Server nicht mit dem Wert von MaximumActive Databases, wenn es darum geht, eine geeignete Datenbank zur Aktivierung auszuwählen. Nehmen wir an, eine Datenbank hat drei Kopien. Wenn die Kopie auf dem aktiven Server aufgrund eines Festplattenfehlers ausfällt, sucht Active Manager die erste fehlerfreie Datenbank mit der niedrigsten Prioritätsnummer und versucht sie bereitzustellen, um die Dienste für die Clients wieder aufzunehmen. Wenn auf dem Server, auf dem diese Kopie untergebracht ist, die mögliche Anzahl aktiver Datenbanken jedoch eingeschränkt ist, kann es sein, das die Bereitstellung fehlschlägt, sodass Active Manager auf die nächste fehlerfreie Kopie zurückgreifen muss. Diese Kopie wird dann trotz geringerer Aktivierungspriorität bereitgestellt (sofern dabei nicht ähnliche Einschränkungen ins Spiel kommen). Das zeigt, dass Sie die verschiedenen Aktivierungssituationen genau durchdenken müssen, bevor Sie auf Servern Grenzwerte für Datenbanken festlegen.
Verschieben von Datenbankspeicherorten innerhalb einer Datenbankverfügbarkeitsgruppe Es kann sein, dass Sie beim Erstellen einer Datenbank nicht den idealen Pfad für die Datenbank- und Protokolldateien festlegen. Das gilt vor allem für die Standarddatenbank, die bei der Installation von Exchange auf einem neuen Postfachserver angelegt wird. Solange es keine Kopien gibt, können Sie die Dateien mithilfe der Exchange-Verwaltungskonsole problemlos an einen anderen Speicherort verschieben, aber sobald Sie eine Datenbank in einer Verfügbarkeitsgruppe replizieren, werden Sie mit der Voraussetzung konfrontiert, dass alle Kopien einer Datenbank die gleichen Pfade für die Datenbank- und Protokolldateien aufweisen müssen. Daher erfordert es Planung, eine solche Datenbank an einen anderen Speicherort zu verschieben. Microsoft empfiehlt, dabei die folgenden grundlegenden Schritte durchzuführen: 1. Zeichnen Sie sich mit Get-MailboxDatabase sämtliche Eigenschaften der Datenbank auf, die Sie
verschieben möchten. 2. Schalten Sie die Umlaufprotokollierung aus. (Das setzt voraus, dass Sie dem Ratschlag von Micro-
soft gefolgt sind und für Datenbanken mit mehreren Kopien in einer Verfügbarkeitsgruppe die Umlaufprotokollierung aktiviert haben.) Dadurch stellen Sie sicher, dass alle Transaktionsprotokolle für die aktive Datenbank während der Zeit aufbewahrt werden, in der die Kopien in der Verfügbarkeitsgruppe nicht zugänglich sind. 3. Entfernen Sie die passiven Kopien der Datenbank mit Remove-MailboxDatabaseCopy von den anderen Servern in der Datenbankverfügbarkeitsgruppe. 4. Verwenden Sie Move-DatabasePath, um den Pfad der Datenbank zu ändern und die Datenbankdateien an den neuen Speicherort zu kopieren. Dabei wird die Bereitstellung der Datenbank aufgehoben und die Datenbank anschließend wieder bereitgestellt.
504
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
identische Speicherorte. 6. Verschieben Sie die Datenbankdateien auf den anderen Servern an den neuen Speicherort und
stellen Sie die Kopien wieder bereit. Diesen Vorgang sollten Sie auf dem Server durchführen, auf dem die Datenbank zurzeit bereitgestellt ist. 7. Fügen Sie die Datenbankkopien mit Add-MailboxDatabaseCopy wieder zu der Datenbankverfügbarkeitsgruppe hinzu. Legen Sie dabei die richtige Aktivierungsreihenfolge fest. 8. Überprüfen Sie die Datenbankeigenschaften und korrigieren Sie sie gegebenenfalls. Beispielsweise müssen Sie möglicherweise die Verzögerungszeit für die Wiedergabe oder das Abschneiden der Protokolle für eine Kopie ändern. 9. Schalten Sie ggf. die Umlaufprotokollierung wieder ein. 10. Überprüfen Sie mit Get-MailboxDatabaseCopyStatus und Test-ReplicationHealth, ob die Replikation innerhalb der Datenbankverfügbarkeitsgruppe normal verläuft. Sofern die Kopien nicht für einen längeren Zeitraum offline waren, in dem die aktive Datenbank sehr stark beschäftigt war, sollte ein vollständiges Reseeding der Kopien nicht erforderlich sein, da die normale Replikationsverarbeitung ein inkrementelles Reseeding durchführt, um sie auf den neuesten Stand zu bringen. Alternativ können Sie auch die folgende einfachere und bewährte Vorgehensweise verwenden: 1. Heben Sie die Bereitstellung der Datenbank auf und setzen Sie mit Suspend-MailboxDatabaseCopy
die Replikation für alle Kopien aus: Suspend-MailboxDatabaseCopy -Identity 'VIP Data\ExServer1' -SuspendComment 'Move database file locations' 2. Erstellen Sie den neuen Speicherort (für die Datenbank- und/oder Protokolldateien) auf dem
Server mit der Datenbank und den Servern mit den Kopien. 3. Kopieren Sie die Dateien an die neuen Speicherorte. 4. Verschieben Sie die Datenbankdateien mit Move-DatabasePath und der Option ConfigurationOnly,
sodass Exchange nur Active Directory mit den Daten für den neuen Speicherort aktualisiert: Move-DatabasePath –Identity 'VIP Data' –EDBFilePath 'G:\DAG\Data\DUBMBX01.EDB' –LogFolderPath 'G:\DAG\Logs\' -ConfigurationOnly 5. Überprüfen Sie, ob die Dateispeicherorte in Active Directory aktualisiert worden sind: Get-MailboxDatabase –Identity 'VIP Data' | Select Name, *Path* | Format-List 6. Stellen Sie die Datenbank bereit und nehmen Sie die Replikation wieder auf, damit die Kopien
wieder synchronisiert werden. Dazu können Sie das Cmdlet Resume-MailboxDatabaseCopy verwenden: Resume-MailboxDatabaseCopy -Identity 'VIP Data\ExServer1' 7. Überprüfen Sie, ob E-Mails in den Postfächern der Datenbank zugestellt werden. 8. Vergewissern Sie sich, dass die Replikationswarteschlangen nicht wachsen, um sicherzugehen, dass
die Replikation normal verläuft und dass alle Datenbankkopien fehlerfrei sind. Dies können Sie in der Exchange-Verwaltungskonsole oder mit dem Cmdlet Get-MailboxDatabaseCopyStatus tun. Get-MailboxDatabaseCopyStatus –Identity 'VIP Data\ExServer1'
505
Exchange auf dem Weg zur Hochverfügbarkeit
5. Erstellen Sie auf den Servern, auf denen Sie wieder Kopien der Datenbank unterbringen möchten,
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Da Datenbankverfügbarkeitsgruppen in jeder Organisation ein wenig anderes gestaltet sind, sollten Sie diese Vorgehensweise auf jeden Fall gründlich prüfen, bevor Sie sie in Ihrer Produktionsumgebung einsetzen.
Entfernen von Datenbankkopien Es ist zwar schön und gut, neue Datenbankkopien hinzuzufügen, aber manchmal ist es an der Zeit, den umgekehrten Schritt zu vollziehen und eine Kopie wieder zu entfernen. Die aktive Kopie einer Datenbank können Sie erst dann entfernen, wenn es keine passiven mehr gibt. Wenn Sie eine Datenbankkopie entfernen müssen, die zurzeit aktiv ist, müssen Sie den Switchover zu einer anderen Kopie erzwingen, abwarten, bis der Wechsel erfolgreich verlaufen ist, und dann die jetzt passive Kopie beseitigen. Um sämtliche Exemplare einer Datenbank loszuwerden, löschen Sie nacheinander alle passiven Kopien, bis nur noch die aktive übrig ist. Dann können Sie die übliche Option zum Entfernen von Datenbanken verwenden, um auch diese zu löschen. Um eine Datenbankkopie zu entfernen, vergewissern Sie sich zunächst, dass die Replikation fehlerfrei funktioniert und dass es innerhalb der Datenbankverfügbarkeitsgruppe keine Netzwerkprobleme gibt. Das ist wichtig, damit alle Server, die über Kopien verfügen, die Änderung mitbekommen. Damit keine Möglichkeit eines Datenverlustes besteht, entfernt Exchange eine Datenbankkopie nur dann, wenn die Umlaufprotokollierung ausgeschaltet ist (siehe Abbildung 8.27). Ist diese Funktion aktiviert, müssen Sie sie erst ausschalten. Anschließend müssen Sie die Bereitstellung aufheben und die Datenbank erneut bereitstellen, damit sich die Replikation an die geänderten Verhältnisse anpassen kann. Abbildg. 8.27
Bei aktivierter Umlaufprotokollierung kann eine Datenbankkopie nicht entfernt werden.
Wenn alles bereit ist, markieren Sie die passive Datenbankkopie, die Sie entfernen möchten, klicken mit der rechten Maustaste darauf und wählen Entfernen aus dem Kontextmenü (siehe Abbildung 8.28). Die daraufhin eingeblendete Bestätigungsmeldung wirkt zunächst alarmierend, da hier nicht gefragt wird, ob Sie die Datenbankkopie auf Server XY entfernen möchten, sondern die Datenbank, aber Sie können bedenkenlos auf Ja klicken, um fortzufahren. Wir haben uns schon daran gewöhnt, dass Computersoftware hin und wieder kleine Pannen zeigt. Der häufigste Fehler, der sich in dieser Situation zeigt, besteht darin, dass Exchange zwar das Objekt für die Datenbankkopie aus Active Diretory entfernt, aber nicht in der Lage ist, die zugrunde liegen-
506
den Dateien zu löschen. Das kann daran liegen, dass eine vorübergehende Störung die Kommunikation zwischen der Arbeitsstation, auf der Sie die Exchange-Verwaltungswerkzeuge ausführen, und dem Server mit der zu entfernenden Datenbank unterbricht. Abbildg. 8.28
Entfernen einer Datenbankkopie
Wenn Exchange beim Entfernen einer Datenbankkopie einen Fehler meldet, können Sie überprüfen, ob der Verweis auf die Kopie aus Active Directory gelöscht wurde, indem Sie Get-MailboxDatabase ausführen. dieses Cmdlet gibt eine Liste der Server und Datenbankkopien zurück, von denen Exchange weiß. In unserem Beispiel trat das Problem bei dem Versuch auf, die Kopie der Datenbank DB4 von ExServer4 zu entfernen. Nachdem die Fehlermeldung angezeigt wurde, wollen wir uns vergewissern, ob die Kopie von der Liste gelöscht wurde. Dazu rufen wir die Liste wie folgt ab: Get-MailboxDatabase –Identity DB3 | Select Servers, DatabaseCopies Servers : {ExServer1, ExServer2, ExServer3} DatabaseCopies : {DB4\ExServer1, DB4\ExServer2, DB4\ExServer3}
Es gibt kein Anzeichen für eine Kopie von DB4 auf ExServer4. Wir können also sicher sein, dass der Eintrag aus Active Directory entfernt wurde, und damit fortfahren, die Datenbankdateien auf dem Server zu löschen. Passen Sie aber auf, dass Sie die richtigen Dateien auf dem richtigen Server erwischen! Selbst wenn Exchange eine Datenbankkopie erfolgreich entfernt, werden Sie dazu aufgefordert, auf dem Server, auf dem die Kopie untergebracht war, selbst nachzusehen, um dort eventuell zurückgebliebene Datenbankdateien zu löschen (siehe Abbildung 8.29). Abbildg. 8.29
Eine Warnung vor möglicherweise nicht entfernten Datenbankdateien
507
Exchange auf dem Weg zur Hochverfügbarkeit
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Wenn Sie eine Datenbank komplett löschen wollen, müssen Sie alle Kopien davon entfernen. Bevor Sie die letzte Kopie tilgen, müssen Sie alle darin enthaltenen Postfächer in eine andere Datenbank übertragen. Das ist für besondere Exchange-Postfächer wie Vermittlungs- und Suchpostfächer außerordentlich wichtig. Wenn Sie versuchen, eine Datenbank zu löschen, die immer noch Postfächer enthält, wird die Fehlermeldung aus Abbildung 8.30 angezeigt. Abbildg. 8.30
Fehlermeldung aufgrund von vorhandenen Postfächern in einer zu löschenden Datenbank
Bevor Sie die Datenbank löschen können, müssen Sie mit Get-MailboxStatistics oder Get-Mailbox überprüfen, ob noch Postfächer darin vorhanden sind: Get-MailboxStatistics –Database 'Postfaecher Dublin' DisplayName -------------------SystemMailbox{51eb7f9d...
ItemCount ----------1
StorageLimitStatus ------------------------BelowLimit
Alternativ geben Sie folgenden Befehl: Get-Mailbox –Database 'Postfaecher Dublin'
Es werden alle Postfächer in der Datenbank aufgeführt, sodass wir erkennen können, dass nur noch die standardmäßige Systemdatenbank vorhanden ist. Daher können wir bedenkenlos weitermachen und dieDatenbank entfernen. Dazu markieren wir in der Exchange-Verwaltungskonsole die Datenbank und klicken im Aktionsbereich auf Entfernen (siehe Abbildung 8.31). Klicken Sie auf OK, um den Vorgang zu bestätigen. Daraufhin entfernt Exchange das Datenbankobjekt aus Active Directory. Möglicherweise müssen Sie danach noch aufräumen, indem Sie die Datenbank- und Protokolldateien löschen. In der Exchange-Verwaltungsshell verwenden Sie die folgenden Befehle, um eine Datenbankkopie zu entfernen. Um zunächst wie in dem vorhergehenden Beispiel die Kopie von DB4 vom Server ExServer2 zu entfernen, verwenden Sie folgenden Befehl: Remove-MailboxDatabaseCopy –Identity 'Postfaecher Dublin\ExServer2'
Nachdem alle Kopien bis auf die letzte gelöscht sind, können Sie mit Remove-MailboxDatabase die Datenbank aus der Organisation entfernen: Remove-MailboxDatabase –Identity 'Postfaecher Dublin' 508
Tägliche Aufgaben für die Verwaltung und den Betrieb von Datenbankverfügbarkeitsgruppen
Entfernen der letzten Kopie einer Postfachdatenbank
Exchange auf dem Weg zur Hochverfügbarkeit
Abbildg. 8.31
Entfernen von Servern aus Datenbankverfügbarkeitsgruppen Bevor Sie einen Server aus einer Datenbankverfügbarkeitsgruppe herausnehmen können, müssen Sie mit den im vorhergehenden Abschnitt beschriebenen Methoden alle Kopien von ihm entfernen. Anschließend können Sie mit Get-MailboxDatabase überprüfen, ob noch irgendwelche Datenbankkopien vorhanden sind. Mit dem folgenden Beispielbefehl sehen wir nach, ob es noch Postfachdatenbanken auf ExServer1 gibt: Get-MailboxDatabase –Server ExServer1 Name -------Sales VIP Data
Server --------ExServer1 ExServer1
Recovery ------------False False
ReplicationType --------------None Remote
Die Ausgabe zeigt, dass auf ExServer1 zurzeit nur eine Kopie einer replizierten Datenbank vorhanden ist (VIP Data). Der erste Schritt besteht also darin, diese Kopie zu entfernen. Um die nicht replizierte Datenbank Sales brauchen Sie sich nicht zu kümmern, da ihr Vorhandensein die Mitgliedschaft in der Datenbankverfügbarkeitsgruppe nicht betrifft. Nachdem Sie alle replizierten Datenbanken entfernt haben, rufen Sie in der Exchange-Verwaltungskonsole den Assistenten zum Verwalten von Datenbankverfügbarkeitsgruppen auf oder verwenden
509
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
das Cmdlet Remove-DatabaseAvailabilityGroupServer, um den Server aus der Gruppe herauszunehmen. Um beispielsweise den Server ExServer1 aus der Gruppe DAG-Dublin zu entfernen, gehen Sie wie folgt vor: Remove-DatabaseAvailabilityGroupServer –Identity 'DAG-Dublin' –MailboxServer 'ExServer1'
Insidertipp: Umkehrung des Hinzufügevorgangs
Beim Entfernen eines Servers aus einer Datenbankverfügbarkeitsgruppe wird praktisch der Vorgang zum Hinzufügen umgekehrt. Der Server wird aus dem Cluster entfernt, das Quorummodell wird an die neue Anzahl der Clustermitglieder angepasst, der Server wird aus dem Objekt für die Gruppe in Active Directory gelöscht und die Datenbanken auf dem Server werden aus der Quorumdatenbank getilgt. Zum Glück kümmert sich Exchange automatisch um all diese Schritte, sodass Sie sie nicht manuell durchführen müssen. Es kann vorkommen, dass Sie einen Server entfernen müssen, der physisch unzugänglich ist oder aus irgendeinem Grund nicht online geschaltet werden kann, z.B. aufgrund eines Hardwarefehlers. Zwar könnten Sie diesen Server in der Datenbankverfügbarkeitsgruppe lassen, doch kann das die Fähigkeit des Clusters beeinträchtigen, das Quorum zu erhalten. Da sich der Server nicht online bringen lässt, können Sie Remove-DatabaseAvailabilityGroupServer auch nicht auf die übliche Weise ausführen. Stattdessen müssen Sie dieses Cmdlet so einsetzen, dass es einfach in Active Directory alle Spuren des Servers aus den Konfigurationsdaten der Datenbankverfügbarkeitsgruppe löscht. Dazu müssen Sie den Parameter -ConfigurationOnly angeben: Remove-DatabaseAvailabilityGroupServer –Identity 'DAG-Dublin' –MailboxServer 'Exserver2' –ConfigurationOnly
Dieser Befehl entfernt den Server ExServer2 aus der Datenbankverfügbarkeitsgruppe DAG-Dublin. Wenn der Server später repariert ist, können Sie ihn wieder in die Gruppe aufnehmen.
Maßnahmen bei hängendem Speicher Der Speicher kann »hängen«, wenn eine Anwendung wie Exchange E/A-Anforderungen ausgibt, die das E/A-Teilsystem aus irgendeinem Grund nicht erfüllen kann, z.B. aufgrund eines Fehlers in der Speichersoftware oder -hardware. Exchange Server 2010 SP1 kann mit solchen Bedingungen wirkungsvoller umgehen, was die Hochverfügbarkeit erhöht. Ursprünglich wollte ich »eleganter« sagen, aber dann bin ich zu dem Schluss gekommen, dass »wirkungsvoll« diese Funktion treffender beschreibt – so wie eine Axt ein »wirkungsvolles« Werkzeug ist, um Äste von einem Baum abzuschlagen. Exchange Server 2010 SP1 sucht regelmäßig nach hängendem Speicher. Dabei gibt es zwei verschiedene Spielarten: 쐍 ESE oder der Informationsspeicher entdeckt ein hängendes Datenlaufwerk, wenn der Prozess versucht, Daten auf eine Festplatte zu schreiben oder von dort zu lesen, aber keine Antwort erhält. Nachdem dem Laufwerk genügend Zeit eingeräumt worden ist, um zu reagieren (einige Minuten), und wenn sich das Problem auch auf anderen Datenlaufwerken zeigt, kommt ESE zu dem Schluss, dass der Server ein Problem hat, das sich höchstwahrscheinlich nicht von selbst wieder löst. Um den Dienst wieder aufzunehmen, erstellt ESE daher ein Fehlerelement. Das wiederum erkennt der Windows Failure Item Manager, weshalb er den Server mit einem Fehlercode zum Stillstand bringt (Bluescreen). 510
쐍 Der Wiedergabedienst (der in einer Datenbankverfügbarkeitsgruppe ausgeführt wird) stellt fest, dass das Betriebssystem nicht auf seine Anforderungen reagiert. Das kann sehr schnell zu einem Problem werden, das die Hochverfügbarkeit gefährdet, weshalb rasch zu einer radikalen Lösung gegriffen wird: Exchange zwingt den Server dazu, mit einem Fehlercode anzuhalten und neu zu starten. Dieser Schritt ist wichtig, da der Taktdienst des Clusters noch funktionieren kann. Gewöhnlich ist ein Eingreifen des Administrators erforderlich, um herauszufinden, warum das Betriebssystem versagt hat, und um die Ursachen zu beheben. Sobald der ausgefallene Server wieder online ist, werden die Datenbankkopien durch ein inkrementelles Reseeding auf den aktuellen Stand gebracht. In beiden Fällen wird ein Neustart des Servers als das kleinere Übel angesehen, da dadurch die Dienste für die Clients schnell wieder aufgenommen werden können. Bei einem Einzelserver besteht die Hoffnung, dass der Server durch den Neustart in voll funktionsfähigem Zustand wieder online geht und dass die Datenbanken erneut für die Annahme von Verbindungen bereitgestellt werden. Ist das nicht der Fall, muss der Administrator die Ursache für den Fehler ermitteln. Meistens liegt ein Hardwareproblem vor. Bei einem Server in einer Datenbankverfügbarkeitsgruppe übertragt Exchange bei einem Neustart die Rolle der aktiven Datenbanken des ausgefallenen Servers auf andere Kopien in der Gruppe, um den Benutzern die Dienste so schnell wie möglich wieder zur Verfügung zu stellen. Der normale Failovermechanismus erkennt, dass die Datenbanken auf dem ausgefallenen Server offline sind, und bringt die Kopie mit der niedrigsten Prioritätsnummer online.
Aktualisieren von Servern in Datenbankverfügbarkeitsgruppen Wie in älteren Typen von Clustern müssen Sie auch in Datenbankverfügbarkeitsgruppen ein gewisses Maß an Vorsicht walten lassen, wenn Sie Patches und andere Aktualisierungen auf die Mitgliedserver anwenden. Die allgemeine Vorgehensweise besteht darin, den betreffenden Server aus der Gruppe herauszunehmen, ohne die Dienste für die Benutzer zu unterbrechen, die Aktualisierungen anzuwenden und den Server dann wieder in die Gruppe einzuführen. Dabei müssen wir zwei verschiedene Fälle unterscheiden, nämlich reine Postfachserver und Server mit mehreren Rollen. Server mit mehreren Rollen dienen meistens als Postfach- und Clientzugriffsserver, wobei in kleineren Umgebungen auch noch die Rolle des Hub-Transport-Servers dazukommen kann. Wenn der Computer der einzige Clientzugriffs- und Hub-Transport-Server ist, wird es schwierig, den Dienst aufrecht zu erhalten, aber wir wollen hier annehmen, dass (innerhalb oder außerhalb der Datenbankverfügbarkeitsgruppe) noch weitere Server zur Verfügung stehen, die diese Aufgaben übernehmen können. Um eine reibungsloses Aktualisierung durchzuführen, gehen Sie wie folgt vor: 1. Schalten Sie alle aktiven Datenbanken auf andere Postfachserver in der Datenbankverfügbarkeits-
gruppe um. 2. Beenden Sie den Clientzugriffs- und Hub-Transport-Dienst und vergewissern Sie sich, dass der
Datenverkehr durch andere Server abgewickelt wird. Wenn Sie eine Lastenausgleichslösung einsetzen, um den Datenverkehr zu dem Clientzugriffsserver auf dem Computer zu leiten, den Sie aktualisieren wollen, müssen Sie den Server aus dem Lastenausgleichsarray entfernen. 3. Blockieren Sie die Aktivierung der Datenbanken auf dem Server, damit Active Manager nicht bei einem Ausfall einer anderen Datenbank auf diesen Computer umschaltet.
511
Exchange auf dem Weg zur Hochverfügbarkeit
Aktualisieren von Servern in Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
4. Führen Sie die Softwareaktualisierung durch und testen Sie sie. Möglicherweise ist dazu ein Neu-
start erforderlich. 5. Heben Sie die Aktivierungssperre wieder auf und schalten Sie die Datenbanken wieder aktiv. 6. Nehmen Sie die Clientzugriffs- und Hub-Transport-Tätigkeiten wieder auf.
Anschließend können Sie dieselben Schritte auf dem nächsten Computer durchführen, bis alle Server in der Datenbankverfügbarkeitsgruppe aktualisiert sind. TIPP
Denken Sie daran, dass es am besten ist, auf allen Servern dieselbe Softwareversion
auszuführen.
Das Verfahren zur Aktivierung eines reinen Postfachservers ist einfacher, da Sie sich dabei nicht um den Clientzugriffs- und Hub-Transport-Dienst kümmern müssen: 1. Schalten Sie alle aktiven Datenbanken auf andere Postfachserver in der Datenbankverfügbarkeits-
gruppe um. 2. Blockieren Sie die Aktivierung der Datenbanken auf dem Server, damit Active Manager nicht bei
einem Ausfall einer anderen Datenbank auf diesen Computer umschaltet. 3. Führen Sie die Softwareaktualisierung durch und testen Sie sie. 4. Heben Sie die Aktivierungssperre wieder auf und schalten Sie die Datenbanken wieder aktiv.
Insidertipp: Automatisierung mithilfe von Windows PowerShell-Skripts
Um allen Beteiligten das Leben zu erleichtern, liefert Microsoft bei Exchange Server 2010 SP1 die Skripts StartDagServerMaintenance.ps1 und StopDagServerMaintenance.ps1 mit. Damit können Sie einen Server automatisch aus einer Datenbankverfügbarkeitsgruppe herauszunehmen, um ihn zu aktualisieren, und ihn anschließend wieder automatisch in die Gruppe aufnehmen. Diese Skripts können Sie im Lieferzustand verwenden, an Ihre Bedürfnisse anpassen oder als Vorlage für Ihre eigenen Versionen nutzen. Auf jeden Fall aber müssen Sie sie testen, damit Sie genau wissen, wie sie funktionieren, bevor Sie sich bei einer Wartung tatsächlich auf sie verlassen. Herunterfahren des Systems
Die Hochverfügbarkeitsfunktionen von Exchange Server 2007 sind nicht in den Code integriert, mit dem Windows Server 2003 das System herunterfährt. Microsoft hat Exchange Server 2007 erst nach Windows Server 2003 veröffentlicht, sodass keine Gelegenheit bestand, die Anforderungen für die Exchange-Protokollreplikation beim Herunterfahren von Windows zu berücksichtigen. Wenn Sie also einen Exchange Server 2007-Computer herunterfahren, der Mitglied eines Clusters mit fortlaufender Replikation ist, wird der Exchange-Informationsspeicherprozess beendet, ohne die Gelegenheit zu bekommen, die Aufgaben auf ein passives Clustermitglied zu übertragen. Im Idealfall schaltet ein Administrator die Dienste auf ein passives Mitglied um, bevor er einen Server herunterfährt, aber wenn er das vergisst, stehen die Benutzer in der Zeit, die es dauert, die passive Kopie online zu schalten, ohne Dienste da, die auf ihre Anforderungen reagieren. Bei Exchange Server 2010 verhält sich die Sache anders. Dieses Produkt wurde zwar auch erst nach Windows Server 2008 freigegeben, aber es konnte noch dafür gesorgt werden, dass Server in Datenbankverfügbarkeitsgruppen eleganter heruntergefahren werden. Wenn Sie einen Server herunterfahren, dessen Datenbanken über Kopien auf anderen Servern der Gruppe verfügen, versucht Exchange auf diese anderen Kopien umzuschalten, bevor eine Fortsetzung des Abschaltvorgangs erlaubt wird. Dadurch können die Benutzer unterbrechungsfrei weiterarbeiten.
512
Datacenter Activation Coordination Manche Datenbankverfügbarkeitsgruppen erstrecken sich über mehrere Rechenzentren in verschiedenen Standorten. In solchen Umgebungen können besondere Probleme auftreten, wenn ein katastrophaler Hardwarefehler mehrere Server in verschiedenen Rechenzentren beeinträchtigt. Wenn in einer Datenbankverfügbarkeitsgruppe mehrere Server ausfallen, bleibt die Gruppe normalerweise offline, bis die Mehrzahl der Server wieder in einem fehlerfreien Zustand ist, sodass sie online geschaltet werden können, und der Cluster sein Quorum erreicht. Dann versucht Active Manager, den Betrieb der Datenbankverfügbarkeitsgruppe wiederaufzunehmen und die Datenbanken erneut bereitzustellen. Wenn alles gut geht, kommen die Datenbanken wieder online, und alle Server können wieder miteinander kommunizieren. Ist aber die Kommunikation zwischen den Rechenzentren gestört, kann sich dadurch das so genannte Split-Brain-Syndrom entwickeln, da die Mitglieder der Datenbankverfügbarkeitsgruppe nicht in der Lage sind, die Taktsignale der anderen zu empfangen. Der Cluster zerfällt also praktisch in zwei Teile, die nicht mehr miteinander reden können und sich jeweils für den maßgeblichen Teil des Clusters bzw. der Datenbankverfügbarkeitsgruppe halten. Wenn dieser Zustand länger anhält, kann das dazu führen, dass in den beiden Rechenzentren zwei verschiedene Kopien einer Datenbank aktiv sind und beide den Benutzern zur Verfügung stehen. Sie können sich leicht ausmalen, zu was für einem Durcheinander das führen kann. Um dieses Problem zu vermeiden, können Sie eine Datenbankverfügbarkeitsgruppe so einrichten, dass sie Datacenter Activation Coordination Protocol (DACP) verwendet, um eine koordinierte Aktivierung der Rechenzentren zu erreichen. Ursprünglich war dieser so genannte DAC-Modus für Datenbankverfügbarkeitsgruppen mit mindestens drei Mitgliedservern in mehreren Rechenzentren gedacht. In Exchange Server 2010 hat Microsoft jedoch auch die Verwendung von DACP in Datenbankverfügbarkeitsgruppen mit nur zwei Servern möglich gemacht. Das ist eine ungewöhnliche Konstellation, die nur von kleinen Organisationen eingesetzt wird, um Hochverfügbarkeit mit einem Minimum an Servern zu erreichen. Wenn eine Datenbankverfügbarkeitsgruppe über genügend Server verfügt, um mithilfe von DACP konfiguriert zu werden, unterhält Active Manager im Arbeitsspeicher ein Flag (das so genannte DACP-Bit), das angibt, ob auf dem Server lokale Datenbanken bereitgestellt werden können. Wenn Active Manager auf dem Server startet, steht das Bit auf 0, was bedeutet, dass Exchange keine lokalen Datenbanken bereitstellen kann. Anschließend nimmt Active Manager mit seinem Gegenstück auf den anderen Mitgliedern der Datenbankverfügbarkeitsgruppe Kontakt auf, um den Wert des dortigen DACP-Flags zu ermitteln. Wenn irgendein anderer Server mit dem DACP-Wert 1 antwortet, bedeutet das, dass eine lokale Bereitstellung möglich ist, woraufhin auf dem lokalen Server das DACP-Bit auf 1 gesetzt wird und die Datenbanken bereitgestellt werden. Bei einer Datenbankverfügbarkeitsgruppe mit nur zwei Mitgliedern wird außerdem die Startzeit des Dateifreigabenzeugen mit dem Zeitpunkt verglichen, an dem das DACP-Bit auf 1 gesetzt wurde. War der Zeugenserver verfügbar, bevor das Bit gesetzt wurde (liegt die Startzeit also vor der Biteinstellungszeit), kann der Server seine Datenbanken bereitstellen. Um DACP für eine Datenbankverfügbarkeitsgruppe zu aktivieren, richten Sie mit Set-DatabaseAvailabilityGroup die Eigenschaft DatacenterActivationMode ein. Standardmäßig ist DACP ausgeschaltet. Dabei sollten Sie es belassen, sofern Sie keine guten Gründe für eine Änderung haben. Set-DatabaseAvailabilityGroup –id 'DistributedDAG' –DatacenterActivationMode 'Enabled'
513
Exchange auf dem Weg zur Hochverfügbarkeit
Datacenter Activation Coordination
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Vorsehen der Ausfallsicherheit von Rechenzentren Sicherheitsmaßnahmen gegen Fehler einzuplanen, die ein ganzes Rechenzentrum lahmlegen können, ist eine anspruchsvolle Aufgabe. Datenbankverfügbarkeitsgruppen und der DAC-Modus sind wichtige Mittel dazu, ermöglichen von sich aus aber keinen automatischen Übergang. Ergänzend zu diesen Bausteinen brauchen Sie solide, gut geplante Betriebsverfahren und geschultes Personal. Sehen wir uns dazu die erforderlichen Schritte an, um eine Datenbankverfügbarkeitsgruppe nach dem Ausfall des Hauptrechenzentrums auf das sekundäre umzuschalten. In dem folgenden Beispiel befindet sich das erste Rechenzentrum in London, das zweite in Dublin. Die Datenbankverfügbarkeitsgruppe Production umfasst beide. Alle aktiven Datenbanken befinden sich in London und werden auf die Server in Dublin kopiert. Die beiden regionalen Standorte bilden auch jeweils ihren eigenen Active Directory-Standort. In beiden Rechenzentren ist genügend Serverkapazität für Transport. Clientzugriff und Postfächer vorhanden. Nehmen wir an, in London tritt ein Fehler auf, durch den das ganze Rechenzentrum für Clientverbindungen unerreichbar wird. Um den Datenverkehr nach Dublin umzuleiten, müssen Sie Folgendes tun: 1. Aktualisieren Sie die DNS-Einträge für alle Exchange-Dienste (SMTP [MX], HTTP, Clientzugriffs-
arrays, AutoErmittlung usw.), um sie auf die entsprechenden Server in Dublin zu verweisen. Alle Lastenausgleichslösungen und Netzwerkgeräte müssen so umkonfiguriert werden, dass Sie die Clientverbindungen umleiten. 2. Aktualisieren Sie in beiden Rechenzentren Active Directory, um die Datenbankverfügbarkeitsgruppe im Standort London als »beendet« zu kennzeichnen. Dazu muss natürlich Zugriff auf Active Directory bestehen. Stop-DatabaseAvailabilityGroup –Identity 'Production' –ActiveDirectorySite 'London' –ConfigurationOnly 3. Beenden Sie den Clusterdienst auf allen Knoten in London. 4. Aktualisieren Sie in beiden Rechenzentren Active Directory, um die Mitgliedserver am Standort
London zu aktivieren. Der folgende Beispielcode setzt voraus, dass Sie einen alternativen Zeugenserver mit Zeugenverzeichnis in Dublin eingerichtet haben. Wenn nicht, können Sie in diesem Befehl auch die Werte dafür übergeben. Restore-DatabaseAvailabilityGroup –Identity 'Production' –ActiveDirectorySite 'Dublin' 5. Vergewissern Sie sich, dass die passiven Kopien der Datenbanken auf den Servern in Dublin
bereitgestellt und aktiviert sind. Anschließend können Sie die Clientverbindungen einrichten und den normalen Betrieb wiederaufnehmen. Nachdem Sie das Problem in London gelöst haben, können Sie die Clientverbindungen wieder von Dublin nach London umschalten. Gehen Sie dazu folgendermaßen vor: 1. Vergewissern Sie sich, dass das Rechenzentrum in London in der Lage ist, die Arbeitslast zu tragen. 2. Fügen Sie die Londoner Server wieder in die Datenbankverfügbarkeitsgruppe ein. Mit dem fol-
genden Befehl reaktivieren Sie den Clusterdienst in London: Start-DatabaseAvailabilityGroup –Identity 'Production' –ActiveDirectorySite 'London
514
Datacenter Activation Coordination
und das Zeugenverzeichnis wieder von einem Computer im Dubliner Rechenzentrum zu einem in London zu übertragen (dabei setzen wir voraus, dass bei dem vorhergehenden Wechsel eine Übertragung nach Dublin stattgefunden hat). Set-DatabaseAvailabilityGroup –Identity 'Production' –WitnessServer'LondonHT1' –WitnessDirectory 'C:\DAG\Production' 4. Räumen Sie genügend Zeit ein, damit die passiven Datenbankkopien in London durch Wieder-
gabe der Transaktionsprotokolle aus Dublin auf den neuesten Stand gebracht werden können (für manche Datenbanken mag ein Reseeding erforderlich sein). 5. Heben Sie die Bereitstellung aller Datenbanken auf, um die Clientverbindungen zu beenden, und überprüfen Sie, ob sie korrekt umgeleitet werden, wenn das Londoner Rechenzentrum wieder online geht. 6. Aktualisieren Sie die DNS-Einträge, um SMTP und andere Dienste wieder auf das Londoner Rechenzentrum zu übertragen. 7. Aktualisieren Sie die Datenbanken und stellen Sie sie bereit, um die Kopien in London zu aktivieren. Diesen Vorgang müssen Sie für jede Datenbank einzeln durchführen. Mit dem Parameter -SkipClientExperienceChecks erlauben Sie dem Informationsspeicher, auch dann auf eine Datenbank umzuschalten, wenn deren Suchkatalog nicht auf dem neuesten Stand ist. Move-ActiveMailboxDatabase –Identity 'Mailbox DB1' –ActivateOnServer 'LondonMBX2' -SkipClientExperienceChecks Mount-Database –Identity 'Mailbox DB1'
Beim Reseeding einer Datenbank scheint die Exchange-Verwaltungskonsole den aktuellen Status nicht anzuzeigen. Tatsächlich gibt es in der Konsole einen Fortschrittsbalken, den Sie aber nur dann sehen können, wenn Sie das Konsolenfenster auf eine Breite von mehr als 80 Zeichen eingestellt haben. Doch selbst wenn Sie den Fortschrittsbalken sehen können, ist er nicht sehr hilfreich, da kein Maßstab angegeben ist. Bei einer kleinen Datenbank ist es nicht weiter schlimm, wenn Sie nicht erkennen können, wie weit der Vorgang fortgeschritten ist, da der Vorgang gewöhnlich in kurzer Zeit erledigt ist. Bei großen Datenbanken (mit mehr als 3 GB) stehen Sie jedoch vor einem Problem, da Sie nur raten können, wie lange es noch dauert, bis das Reseeding abgeschlossen ist. Das glückliche Ende des Vorgangs bildet dann eine positive Überraschung. Da jedes Rechenzentrum anders aufgebaut ist, können wir hier nicht mehr geben als einen Überblick. Die hier vorgestellten Maßnahmen müssen Sie anhand der jeweiligen Gegebenheiten eines konkreten Rechenzentrums überprüfen und testen, um einen funktionieren Plan zur Ausfallsicherheit aufstellen zu können.
Verwalten standortübergreifender Verbindungen Die AutoErmittlung hilft MAPI-Clients, Verbindung mit den Clientzugriffsservern oder -arrays aufzunehmen, die als MAPI-Endpunkt für Exchange Server 2010 dienen. Anschließend nimmt der Clientzugriffsserver Verbindung mit den Postfachservern auf, auf denen sich die aktiven Kopien der Datenbanken mit den Postfächern befinden, die die Clients benötigen. Nach einem standortübergreifenden Failover kann es vorkommen, dass sich die Clients und der Clientzugriffsserver in einem Active Directory-Standort befinden und die Postfachserver mit den aktiven Datenbanken in einem anderen. Hier stellt sich die Frage, wie mit solchen standortübergreifenden Verbindungen und dem Datenfluss zwischen Clientzugriffs- und Postfachservern umzugehen ist.
515
Exchange auf dem Weg zur Hochverfügbarkeit
3. Aktualisieren Sie die Eigenschaften der Datenbankverfügbarkeitsgruppe, um den Zeugenserver
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Wenn Sie davon ausgehen können, dass die Postfachserver im Hauptrechenzentrum schon nach kurzer Zeit wieder online gehen und die Datenbanken wieder auf die bevorzugten Server umgeschaltet werden können, reicht es gewöhnlich aus, standortübergreifende Verbindungen zuzulassen. Die Situation ist jedoch anders, wenn der Ausfall der Postfachserver vermutlich längere Zeit anhält oder wenn das Hauptrechenzentrum aus irgendeinem Grund überhaupt nicht mehr erreichbar ist. In solchen Fällen müssen Sie die Clients zu einem Clientzugriffsarray oder -server im zweiten Rechenzentrum umleiten. Die schnellste und einfachste Methode – bei der die Outlook-Profile nicht mit den Namen des neuen Clientzugriffsarrays aktualisiert werden müssen –, besteht darin, die DNS-Einträge zu aktualisieren, um die IP-Adressen für das von den Clients bisher genutzte Zugriffsarray dem Array im neuen Standort zuzuweisen. Alternativ können Sie auch die Eigenschaft RpcClientAccessServer der Datenbanken, die auf den zweiten Active Diretory-Standort umgeschaltet wurden, so ändern, dass sie auf das Clientzugriffsarray dieses Standorts zeigt. Für Outlook-Benutzer ist das keine komfortable Lösung, da sie keine Verbindung mehr mit dem Clientzugriffsserver am Hauptstandort bekommen und erst auf den Administrator warten müssen, bevor sie wieder Kontakt aufnehmen können. Ursprünglich wollte Microsoft in SP1 einen neuen Mechanismus zur standortübergreifenden Verwaltung bereitstellen. Dabei sollte es auch eine Einstellung für Datenbankverfügbarkeitsgruppen geben, mit der Sie festlegen können, ob standortübergreifende Verbindungen zulässig sein sollen oder nicht. Bei den Praxistests stellte sich jedoch heraus, dass diese Funktion noch weitere Entwicklung benötigte, weshalb der Code aus dem endgültigen Release von SP1 herausgenommen wurde. Es ist jedoch wahrscheinlich, dass eine zukünftige Version eine elegante und automatische Einrichtung mitbringt, um standortübergreifende Clientverbindungen in Datenbankverfügbarkeitsgruppen zu verwalten.
Crimson-Ereignisse Wenn Sie schon längere Zeit als Windows-Administrator arbeiten, sind Sie wahrscheinlich mit dem Ereignisprotokoll vertraut. In Windows Server 2008 werden zwei Sätze von Protokollen angezeigt. Neben den aus früheren Versionen bekannten Windows-Protokollen (Anwendung, Sicherheit und System) gibt es jetzt die Kategorie Anwendungs- und Dienstprotokolle, die Ereignisse des »Crimson-Kanals«, also Ereignisse auf Anwendungsebene aufzeichnen. Abbildung 8.32 zeigt, wie Exchange Server 2010 diese Protokolle nutzt, um Betriebs- und Debugginginformationen über Ereignisse der Hochverfügbarkeitsfunktionen festzuhalten, in diesem Beispiel den Übergang einer Datenbankkopie in den fehlerfreien Zustand. Um Ereignisse beim Starten und Herunterfahren des Exchange-Replikationsdienstes und verschiedener anderer Komponenten zu erfassen, die innerhalb dieses Dienstes ausgeführt werden (z.B. Active Manager, Replikationsoperationen, der TCP-Listener und die VSS-Schreibkomponente für Sicherungen), verwendet Exchange Server 2010 den Kanal HighAvailability. Wie Sie in Abbildung 8.32 erkennen können, dient dieser Kanal auch dazu, Ereignisse festzuhalten, die mit dem Datenbankzustand, Übergängen und den zugrunde liegenden Clustern von Datenbankverfügbarkeitsgruppen zu tun haben. Informationen über Fehler, die den normalen Betrieb einer replizierten Postfachdatenbank betreffen, werden dagegen im Kanal MailboxDatabaseFailureItems erfasst.
516
Einrichten einer Installation mit Datenbankverfügbarkeitsgruppen
Anzeigen eines Debugereignisses für den Hochverfügbarkeitsbetrieb
Exchange auf dem Weg zur Hochverfügbarkeit
Abbildg. 8.32
Insidertipp: Suchen Sie zuerst an anderer Stelle
Diese Ereignisprotokolle sind mit Sicherheit nicht die erste Stelle, an der Sie nach Informationen über einen Datenbankausfall suchen sollten. Wenden Sie Ihre Aufmerksamkeit zunächst lieber offensichtlicheren Fehlerquellen wie Speicherfehlern oder einem Netzwerkausfall zu. Diese Protokolle bieten jedoch interessante und wertvolle Hintergrundinformationen, nach denen Sie möglicherweise vom Microsoft-Support gefragt werden, wenn Sie ein besonders kniffliges Problem mit einer Datenbankverfügbarkeitsgruppe lösen müssen.
Einrichten einer Installation mit Datenbankverfügbarkeitsgruppen Eine neue Technologie rückt erst dann aus der »Interessant, aber ...«-Ecke heraus und wird wirklich wertvoll, wenn sie dazu verwendet werden kann, die Probleme zu lösen, die sich im Praxisbetrieb von Produktionsumgebungen tatsächlich stellen. In diesem Abschnitt sehen wir uns an, wie sich Datenbankverfügbarkeitsgruppen einsetzen lassen, um die Hochverfügbarkeitsanforderungen eines (fiktiven) Unternehmens zu erfüllen. Wie alle Technologien weisen auch die Datenbankverfügbarkeitsgruppen von Exchange Server 2010 Einschränkungen und Grenzen auf, die die Systemdesigner berücksichtigen müssen, bevor Sie solche Gruppen bereitstellen können. Dabei sind vor allem die folgenden Einschränkungen zu beachten:
517
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
쐍 Eine Datenbankverfügbarkeitsgruppe kann nicht mehr als 16 Server umfassen. Allgemein gilt, dass eine Datenbankverfügbarkeitsgruppe umso mehr Sicherheit bietet, je mehr Server sie umfasst, da sie dann mehr Datenbankkopien auf mehr Computer verteilen kann. Eine höhere Anzahl von Servern bedeutet, dass es beim Ausfall eines Computers mehr Ausweichmöglichkeiten gibt, und eine höhere Anzahl von Mitgliedern im zugrunde liegenden Cluster verringert die Wahrscheinlichkeit, dass das Quorum nicht erhalten bleiben kann und der Cluster funktionsunfähig wird. Das sind wichtige Aspekte, die Sie bedenken müssen, wenn Sie vor der Entscheidung stehen, eine einzige Datenbankverfügbarkeitsgruppe aufzubauen oder die vorhandenen Server auf mehrere Gruppen zu verteilen. Für die Anzahl der Datenbankverfügbarkeitsgruppen in einer Exchange-Organisation gibt es keinen praxisrelevanten Grenzwert. 쐍 Normalerweise befinden sich alle Server im selben Active Directory-Standort, allerdings kann eine Datenbankverfügbarkeitsgruppe auch mehrere Rechenzentren und Active Directory-Standorte umfassen, sofern es dazwischen eine qualitativ hochwertige Netzwerkverbindung (mit einer Roundtripzeit von unter 250 Millisekunden) gibt. 쐍 Die Kapazität des Netzwerks muss ausreichen, um die Protokollreplikation mit einer Wartezeit von nicht mehr als 250 Millisekunden durchzuführen. 쐍 Die Abhängigkeit von der Windows-Failoverclusterunterstützung bedeutet, dass alle Server innerhalb der Datenbankverfügbarkeitsgruppe die Enterprise Edition derselben Betriebssystemversion (Windows Server 2008 SP2 oder R2) ausführen müssen. Außerdem müssen Betriebssystem und alle Anwendungen, auch Exchange Server 2010, auf demselben Aktualisierungsstand sein. 쐍 Datenbankverfügbarkeitsgruppen können Sie mit der Standard und der Enterprise Edition von Exchange Server 2010 bereitstellen. Bei der Standard Edition sind Sie auf fünf Datenbanken beschränkt, wohingegen die Enterprise Edition bis zu 100 Datenbanken auf einem Server zulässt. Es ist jedoch unwahrscheinlich, dass auf einem Server 100 aktive Datenbanken vorhanden sind, da das einen viel zu hohen Anspruch an das E/A-System und den Arbeitsspeicher stellen würde. 쐍 Auf einem Server können sich nicht zwei Kopien derselben Datenbank befinden. 쐍 Als maximale Größe für Datenbanken, die durch mindestens zwei Kopien gegen Datenverluste geschützt sind, gibt Microsoft 2 TB an. Viele Systemdesigner haben jedoch Bedenken dagegen, so riesige Datenbanken auszuführen, selbst wenn sie durch Replikation geschützt sind. Eine Maximalgröße von 1 TB ist daher eher erstrebenswert, zumindest bis mehr Erfahrungen mit dem Betrieb sehr großer Exchange-Datenbanken in Datenbankverfügbarkeitsgruppen gesammelt werden konnten. 쐍 Für Datenbanken, die durch mindestens zwei Kopien geschützt sind, kann die Umlaufprotokollierung verwendet werden. Dabei können die Transaktionsprotokolle und der Katalog der Inhaltsindizierung auf derselben Festplatte abgelegt werden wie die Datenbank selbst. 쐍 Die Leistungstests von Microsoft haben ergeben, dass aktive Benutzer ungefähr 0,2 E/A-Operationen pro Sekunde verursachen. Die Speicherinfrastruktur muss für die E/A-Anforderungen von Datenbankoperationen ausgelegt sein. Nachdem wir die Prinzipien und Einschränkungen von Datenbankverfügbarkeitsgruppen ausführlich besprochen haben, können wir uns jetzt ansehen, wie wir diese Technologie einsetzen, um die üblichen Bedürfnisse nach Hochverfügbarkeit und Notfallwiederherstellung zu befriedigen, die in Unternehmen vorherrschen. Nehmen wir an, unser fiktives Beispielunternehmen möchte die folgenden Anforderungen erfüllen:
518
Einrichten einer Installation mit Datenbankverfügbarkeitsgruppen
2.
3. 4.
5.
diese Übung, denn für die meisten Unternehmen reichen 25.000 Postfächer aus. Größere Unternehmen können die hier verwendeten Zahlen bis zur Grenze von 16 Servern pro Datenbankverfügbarkeitsgruppe und 100 Datenbanken pro Server entsprechend hochrechnen. Wenn Sie noch mehr Kapazität benötigen, können sie mehrere Datenbankverfügbarkeitsgruppen einrichten. Kleinere Unternehmen passen die Zahlen der Server und Datenbanken nach ihrem Bedarf nach unten an. Bereitstellung in einem Haupt- und einem Reserverechenzentrum, um gegen den Ausfall eines kompletten Rechenzentrums abgesichert zu sein. Wenn das erste Rechenzentrum ausfällt, muss der Dienst übergangslos auf das zweite umgeschaltet werden können. Absicherung gegen Speicherfehler auf einem einzelnen Server im Hauptrechenzentrum. Nach dem Umschalten auf das Reservezentrum muss dort dieselbe Absicherung bestehen. Abpuffern von Speicherausfällen auf verschiedenen Servern eines Rechenzentrums ohne Verlust sämtlicher Onlinekopien einer Datenbank. Um Archivkopien zu erstellen und den Bedingungen von Audits zu genügen, werden VSS-Sicherungen auf Platten und anschließend Sicherungen auf Band durchgeführt. Maximal 5000 Postfächer auf einem Server im Normalbetrieb und ausreichend Kapazität, um auch die Last durch umgeleitete Postfächer nach einem Serverausfall (oder der Abschaltung eines Servers zu Wartungszwecken) verarbeiten zu können.
Aus diesem Anforderungskatalog folgt als Erstes, dass unser Design zwei Rechenzentren enthalten muss, um die Exchange-Dienste auch nach einem Ausfall des Hauptrechenzentrums anbieten zu können. Dazu muss sich die Datenbankverfügbarkeitsgruppe über zwei Rechenzentren innerhalb eines einzigen Active Directory-Standorts erstrecken. In den Rechenzentren wiederum müssen sich genügend Server befinden, um die komplette Last zu verarbeiten, die durch 25.000 Postfächer hervorgerufen wird. Außerdem müssen wir in beiden Rechenzentren ausreichend Datenbankkopien erstellen, um mit den verschiedenen Formen von Speicherausfällen fertig werden zu können, die in den Anforderungen angesprochen werden. Dadurch wird auch eine qualitativ hochwertige Verbindung hoher Bandbreite zwischen den Rechenzentren erforderlich, um den Replikationsdatenverkehr abwickeln zu können. Die Datenbankkopien auf den Servern im Reservedatenzentrum müssen höhere Aktivierungsnummern bekommen, damit die Datenbanken im Hauptrechenzentrum stets zuerst verwendet werden. Es müssen genügend Clientzugriffs- und Hub-Transport-Server bereitgestellt werden, damit jedes Rechenzentrum sämtliche Verbindungs- und Transportanforderungen auch allein erfüllen kann. Als zweite Folge ergibt sich, dass wir im Hauptrechenzentrum mindestens zwei Datenbankkopien vorhalten müssen, eine aktive Datenbank und eine zweite als Absicherung gegen einen Speicherfehler auf einer Datenbankfestplatte. Um dieselbe Ausfallsicherheit auch nach einem Wechsel zum zweiten Rechenzentrum bieten zu können, sind auch dort zwei Kopien erforderlich. Insgesamt müssen wir in unserem Design also vier Exemplare jeder Datenbank vorsehen. Jedes Transaktionsprotokoll, das für die aktive Datenbank erstellt wird, muss auf drei andere Server übertragen und dort wiedergegeben werden. Bei der Aktualisierung ihrer Datenbankkopien sind also alle Server ziemlich beschäftigt. Damit auf einem Server nicht mehr als 5000 Postfächer betrieben werden, müssen wir drittens in jedem Standort mindestens fünf Server aufstellen. Fällt ein Server aus oder wird er zu Wartungszwecken offline geschaltet, müssen die übrigen die Last von 6250 Postfächern verarbeiten können (5000 eigene und ein Anteil von 1250 der Postfächer des ausgefallenen Servers). Zehn Postfachserver lassen sich bedenkenlos in einer einzigen Datenbankverfügbarkeitsgruppe unterbringen, wobei sogar noch Platz für sechs weitere Server ist, wenn sich die Belastung durch weitere Postfächer oder erhöhte Kontingente erhöhen sollte. 519
Exchange auf dem Weg zur Hochverfügbarkeit
1. Betrieb von 25.000 Postfächern mit einem Kontingent von je 2 GB. Das sind sinnvolle Zahlen für
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Auf allen Servern werden wir Windows Server 2008 R2 Enterprise Edition ausführen. Wir könnten zwar auch Windows Server 2008 SP2 verwenden, doch von dieser Version aus ist keine direkte Aktualisierung auf R2 möglich. Es wäre sinnlos, ein Betriebssystem bereitzustellen, das möglicherweise bald veraltet ist. Auf allen Servern wird Exchange Server 2010 mit den neuesten Rollupaktualisierungen ausgeführt. 25.000 Postfächer zu je 2 GB bedeuten ein Datenvolumen von 50 TB für die Postfachdatenbanken. Laut Angabe von Microsoft dürfen Postfachdatenbanken, die durch mehrere Kopien innerhalb einer Datenbankverfügbarkeitsgruppe geschützt sind, bis zu 2 TB umfassen. Also könnten wir die 50 TB auf 25 Datenbanken aufteilen und auf jedem Server fünf aktive Datenbanken unterbringen. Das würde jedoch bedeuten, dass jede Datenbank 1000 Postfächer enthält, was zwei mögliche Probleme verursacht. Erstens ergibt sich für eine solche Datenbank bei voller Beanspruchung eine wahrscheinliche E/A-Last von ca. 250 Operationen pro Sekunde (1000 0,25), was schon ziemlich viel ist. Zweitens muss bei einem Serverausfall die Arbeitslast der fünf Datenbanken auf dem betroffenen Server auf die anderen vier im selben Rechenzentrum verteilt werden. Dabei müsste einer der Server zwei zusätzliche Datenbanken und damit die Last von 2000 Postfächern aufnehmen, was die Anforderung verletzt, die die maximale Last nach einem Serverausfall auf 6250 Postfächer beschränkt. Zurzeit haben nicht viele Personen Erfahrungen mit dem Betrieb von 2-TB-Postfachdatenbanken, weshalb wir lieber keine so riesigen Datenbanken verwenden sollten. Ein Servercomputer mit Exchange Server 2010 Enterprise Edition kann weit mehr als fünf aktive Datenbanken betrieben, und eine größere Anzahl kleiner Datenbanken bietet ihnen mehr Flexibilität beim Verteilen der E/A-Last über die verfügbaren Festplatten und die Übertragung der Last nach einem Serverausfall. Außerdem können kleinere Datenbanken noch wachsen, sodass wir bei Bedarf größere Postfachkontingente oder Archivpostfächer bereitstellen können, ohne dazu Postfächer verschieben zu müssen. Aus diesem Grund setzen wir die maximale Datenbankgröße auf 500 GB (250 Postfächer), sodass jeder Server 20 aktive Datenbanken zugeteilt bekommt. Außerdem übernimmt jeder Server 20 Kopien von Datenbanken anderer Server. Fällt einer der Computer aus, wird jedem der vier verbleibenden die Arbeitslast von fünf Datenbanken (1250 Postfächer) übertragen. Um das gewünschte Limit von 6250 Postfächern durchzusetzen, legen wir für die Datenbankverfügbarkeitsgruppe den Grenzwert von 25 aktiven Datenbanken pro Server fest. Auf die 50 TB Speicherplatz für die Postfachdatenbanken müssen wir noch 40% für den Inhaltsindex, die Transaktionsprotokolle und als Reserve für zukünftiges Wachstum, für Wartungszwecke und gegen Überfüllung der Festplatten aufschlagen. Unser Design erfordert also insgesamt 70 TB 4 Kopien = 280 TB. Dabei wird jedoch davon ausgegangen, dass alle Postfächer vollständig gefüllt sind, was in einer Produktionsumgebung in der Praxis wahrscheinlich niemals der Fall sein wird, vor allem nicht bei einem großzügigen Kontingent von 2 GB. Das durchschnittliche Postfach ist etwa halb voll, sodass wir zu Anfang 140 TB an Speicher zur Verfügung stellen und ihn dann mit der Zeit erweitern können. Werden Archivpostfächer verwendet, macht das die Verhältnisse komplizierter, da sie in derselben Datenbank untergebracht werden wie die zugehörigen Hauptpostfächer und daher die Speicheranforderungen verdoppeln. In SP1 können Sie Haupt- und Archivpostfächer jedoch auf verschiedene Datenbanken aufteilen, sodass wir in unserem Design eigene Datenbanken für die Archivpostfächer vorsehen, die auf eine andere Weise verwaltet werden als die Datenbanken für die normalen Postfächer. Jede einzelne Postfachdatenbank ist maximal 500 GB groß. Wenn wir 40% für den Inhaltsindex und die Transaktionsprotokolle aufschlagen, landen wir bei 700 GB. Das heißt, dass eine Datenbank mitsamt ihren zugehörigen Dateien auf einer einzelnen 1-TB-Festplatte Platz hat, wobei sogar noch Raum für zukünftiges Wachstum bleibt. Diese Berechnung vereinfacht die Verhältnisse jedoch, denn der Speicher muss auch in der Lage sein, die E/A-Anforderungen zu erfüllen. Die Leistungsrichtlinien von Microsoft gehen von 0,2 E/A-Operationen pro Sekunde und Postfach aus. Die genaue Zahl hängt 520
natürlich sehr stark von der Arbeitsweise der Benutzer und der Anzahl der Elemente und Ordner in den Postfächern ab. Um auf der sicheren Seite zu bleiben, veranschlagen wir 0,25 E/A-Operationen pro Sekunde, sodass eine Datenbank mit 250 Postfächern mit Spitzenbelastung 62,5 E/A-Operationen pro Sekunde hervorruft (wenn alle Benutzer gleichzeitig aktiv sind). Diese Berechnungen berücksichtigen weder Archivpostfächer noch Merkmale wie eine verlängerte Aufbewahrungszeit für gelöschte Elemente oder ein Einfrieren des Postfachs aus rechtlichen Gründen. Bei dem Speicherdesign, dass letzten Endes umgesetzt wird, müssen solche Umstände jedoch beachtet werden. Außerdem wird das Speicherdesign auch von praktischen Überlegungen beeinflusst, z.B. der vorhandenen Speicherarchitektur, den zurzeit verfügbaren Speicherprodukten und anderen Anforderungen wie dem Sicherungsverfahren. Eine Organisation, die für Exchange Server 2007 ein SAN (Storage Area Network) eingesetzt hat, wird diese Einrichtung wahrscheinlich auch für Exchange Server 2010 nutzen wollen und muss daher die notwendigen Vorbereitungen treffen, um es an die Speicher- und E/A-Anforderungen von 100 aktiven Datenbanken und 100 Kopien sowie den Ansprüchen anderer Anwendungen anzupassen, die auf dem Postfachserver und anderen Computern in den Rechenzentren laufen. Es kann aber auch sein, dass eine Organisation die geringeren E/A-Anforderungen von Exchange Server 2010 ausnutzen und auf ein kostengünstigeres JBOD-Speicherdesign (»just a bunch of disks«) umsteigen möchte, vor allem wenn eine Erhöhung der Postfachkontingente von 2 GB in Aussicht steht. Die von Microsoft und einigen Hardwareherstellern angebotenen Hilfsprogramme zur Speicherberechnung und Dimensionierung sind für Systemdesigner von unschätzbarem Wert, da Sie damit die grundlegenden Werte für ein Speicherdesign ermitteln können, das bestimmte Speicher- und E/A-Anforderungen erfüllen muss. Außer in ganz elementaren Umgebungen können Sie jedoch nicht erwarten, dass Sie mit diesen Berechnungen das wirkungsvollste und kostengünstigste Speicherdesign aufstellen können. Stattdessen müssen Sie die Ergebnisse dieser Hilfsmittel als Ausgangswerte betrachten, die Sie noch optimieren und an Ihre Bedürfnisse anpassen müssen. Beispielsweise können Sie die Ausgabe dieser Programme einem Speicheranbieter zeigen, damit er sich darüber äußern kann, wie seine Produkte für die notwendige Leistung, Kapazität, Sicherheit und Ausfallsicherheit sorgen. Dabei können Sie nicht nur kostenlose Ratschläge von Speicherspezialisten bekommen, sondern vielleicht auch preisgünstige Paketangebote nutzen, die eigens für Exchange Server 2010 entworfen wurden und eine vorgefertigte Lösung für viele Design bieten. Außerdem können die Hersteller Sie auch über neue Speichermöglichkeiten und andere Technologien mit besonderen Fähigkeiten hinweisen, die von den derzeitigen Dimensionierungsprogrammen nicht berücksichtigt werden.
Hilfreiche Skripts für die Verwaltung von Datenbankverfügbarkeitsgruppen Im Installationspaket liefert die Exchange-Entwicklergruppe verschiedene Skripts mit, die für die Verwaltung von Datenbankverfügbarkeitsgruppen von Bedeutung sind. Einige davon haben wir in diesem Kapitel schon besprochen. Zu finden sind sie im Verzeichnis Bin\Scripts. Weitere Informationen
Weitere Informationen über die Befehlszeilenoptionen und die regelmäßige Ausführung der Überwachungsskripts finden Sie bei TechNet auf http://technet.microsoft.com/de-de/library/dd35 1258.aspx. 521
Exchange auf dem Weg zur Hochverfügbarkeit
Hilfreiche Skripts für die Verwaltung von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Die folgenden Skripts stehen zur Verfügung: 쐍 RedistributeActiveDatabases.ps1 Dieses Skript steht in Exchange Server 2010 SP1 zur Verfügung, um die aktiven Datenbanken in einer Verfügbarkeitsgruppe automatisch neu zu verteilen. Wenn Sie es mit dem Parameter -BalanceDbsByActivationPreference ausführen, wird versucht, bei der Verteilung auch die Aktivierungsprioritäten zu berücksichtigen. Weitere Informationen finden Sie weiter vorn in dem Abschnitt »Aktivieren einer Postfachdatenbankkopie«. 쐍 CheckDatabaseRedundancy.ps1 Dieses Skript überprüft, ob es von einer Postfachdatenbank mindestens zwei gültige und fehlerfreie Kopien gibt. Wenn dies der Fall ist, wird die Redundanz als ausreichend betrachtet. Das folgende Beispiel zeigt die Ausgabe, die Sie bei diesem Skript erwarten können. Hier sind zwei Kopien vorhanden, sodass das Skript den aktuellen Status (CurrentState) als »grün« (green) einstuft. Dieses Skript kann von einem Verwaltungsframework wie SCOM eingesetzt werden, wobei seine Daten zur regelmäßigen Überwachung der Fehlerfreiheit replizierter Datenbanken herangezogen werden. .\CheckDatabaseRedundancy.ps1 –MailboxDatabaseName 'DB1' DatabaseName LastRedundancyCount CurrentRedundancyCount LastState CurrentState LastStateTransitionUtc LastGreenTransitionUtc LastRedTransitionUtc LastGreenReportedUtc LastRedReportedUtc PreviousTotalRedDuration TotalRedDuration IsTransitioningState HasErrorsInHistory CurrentErrorMessages ErrorHistory
: : : : : : : : : : : : : : : :
DB1 0 2 Unknown Green 5/21/2010 8:12:17 PM 5/21/2010 8:12:17 PM 5/21/2010 8:12:17 PM 00:00:00 00:00:00 True False
Mit diesem Skript können Sie auch alle Postfachdatenbanken auf einem Server auf einmal überprüfen. Dazu übergeben Sie einfach den Namen des Servers als Parameter. Diese Verwendung sehen Sie im folgenden Beispiel. Der hier gezeigte Abschnitt der Ausgabe gilt für eine Datenbank mit nur einer einzigen Kopie, die daher nicht als redundant angesehen werden kann. Außerdem ist zu erkennen, dass es bei dieser Datenbank schon früher ein »rotes« Ereignis gegeben hat. Das ist etwas, das sich der Administrator genauer ansehen muss, z.B. ein Speicherfehler. .\CheckDatabaseRedundancy.ps1 'ExServer1' DatabaseName LastRedundancyCount CurrentRedundancyCount LastState CurrentState LastStateTransitionUtc
522
: : : : : :
DB4 0 1 Unknown Red 5/21/2010 8:16:56 PM
LastGreenTransitionUtc LastRedTransitionUtc LastGreenReportedUtc LastRedReportedUtc PreviousTotalRedDuration TotalRedDuration IsTransitioningState HasErrorsInHistory CurrentErrorMessages
: : : : : : : : :
5/21/2010 8:16:56 PM
5/21/2010 8:16:56 PM 00:00:00 00:00:00.0468756 True True {The number of configured copies for database 'DB4' (1) is less than the required redundancy count (2)., Name Status RealCopyQueue InspectorQueue ReplayQueue CIState --------------- ------------- -------------- ----------- ------DB4\EXSERVER1 Mounted 0 0 0 Healthy} ErrorHistory : {CheckHADatabaseRedundancy.DatabaseRedundancyEntry+ErrorRecord}
Hinter den Kulissen führt der Exchange-Replikationsdienst das Skript CheckDatabaseRedundancy stündlich auf den Mitgliedservern einer Datenbankverfügbarkeitsgruppe aus, um festzustellen, ob es Datenbanken gibt, die nicht ausreichend durch Kopien abgesichert sind. Wenn eine Datenbank länger als 20 Minuten pro Stunde über nur eine einzige Kopie verfügt, meldet der Replikationsdienst dies im Ereignis 4113 des Anwendungsprotokolls. Solange keine weitere Kopie zur Verfügung gestellt wird, macht er weiterhin alle 20 Minuten mit einem weiteren Ereignis dieser Art auf das Problem aufmerksam. Hat die Datenbank genügend Kopien, wird das Ereignis 4114 protokolliert. 쐍 StartDagServerMaintenance.ps1 Mit diesem Skript können Sie einen Server in einer Datenbankverfügbarkeitsgruppe auf Wartungsarbeiten vorbereiten. Dazu wird er kontrolliert offline geschaltet, nachdem alle seine aktiven Datenbanken auf andere Server in der Gruppe umgeschaltet wurden. Außerdem hält das Skript den Knoten im Windows-Failovercluster der Datenbankverfügbarkeitsgruppe an, sodass er nicht zum PAM werden kann, und verhindert, dass während der Wartungsarbeiten Datenbanken auf diesen Server umgeschaltet und dort aktiviert werden. 쐍 StopDagServerMaintenance.ps1 Dieses Skript führt einen Server nach dem Abschluss der Wartungsarbeiten wieder in die Datenbankverfügbarkeitsgruppe ein. Alle zuvor ausgesetzten Vorgänge werden wieder aufgenommen, und es können auch wieder Datenbanken auf ihm aktiviert werden. Es werden jedoch keine Ressourcen wieder zurück auf diesen Server übertragen. Das ist Sache des Administrators. 쐍 CollectOverMetrics.ps1 Dieses Skript analysiert die Ereignisse, die während eines bestimmten Zeitraums (standardmäßig während des letzten Tages) über die Operationen in Datenbankverfügbarkeitsgruppen aufgezeichnet wurden. Als Eingabedaten werden die im zuvor besprochenen Crimson-Kanal erfassten Ereignisse verwendet. Die Ausgabe ist ein Bericht im HTML-Format, der wichtige Failover- und Switchover-Ereignisse in der Gruppe vermerkt. 쐍 CollectReplicationMetrics.ps1 Dieses Skript sammelt in Echtzeit Daten über die Replikationsvorgänge. Dazu nimmt es während des Messzeitraums regelmäßig Kontakt mit den Servern in der Datenbankverfügbarkeitsgruppe auf und erfasst die jeweils aktuellen Replikationsstatistiken. Die Daten werden dann analysiert und in Form einer CSV-Datei ausgegeben, die Sie in Microsoft Excel öffnen und untersuchen können. Abbildung 8.33 zeigt die typische Ausgabe für einen Messzeitraum von 10 Minuten. Von besonderem Interesse ist die Rate, mit der Transaktionsprotokolle in den einzelnen Datenbanken erstellt, kopiert und wiedergegebenen werden. 523
Exchange auf dem Weg zur Hochverfügbarkeit
Hilfreiche Skripts für die Verwaltung von Datenbankverfügbarkeitsgruppen
Kapitel 8 Abbildg. 8.33
Exchange auf dem Weg zur Hochverfügbarkeit
Ausgabe des Skripts CollectReplicationMetrics
Insidertipp: Eine zweite Chance
Es ist wahr, dass die ursprünglichen Versionen von CollectOverMetrics und CollectReplicationMetrics noch einige Ecken und Kanten aufwiesen und dass manche der dokumentierten Parameter einfach nicht funktionierten. Teilweise lag das an einem Mangel an Erfahrung mit dem Betrieb von Datenbankverfügbarkeitsgruppen in unterschiedlichen Umgebungen, teilweise aber auch daran, dass die Entwickler keine klare Vorstellung davon hatten, welche Daten für Administratoren besonders hilfreich sein können, um einen Überblick über die Datenbankverfügbarkeitsgruppen zu gewinnen. Diese Skripts wurden für SP1 generalüberholt und sind jetzt stabiler und nützlicher. Wenn Sie sie in der RTM-Version ausprobiert haben und zu dem Schluss gekommen sind, dass sie nichts taugen, sollten Sie ihnen daher eine zweite Chance geben. Einzelheiten über die verfügbaren Parameter und andere wichtige Informationen über diese Skripts finden Sie auf TechNet. Skripts wie diese erfüllen nicht nur ihren eigentlichen Zweck, sondern sind auch hervorragende Lernhilfen für Administratoren, die ihre eigenen Skripts erstellen möchten, um die Überwachung und den Betrieb zu automatisieren. Es gibt keine herkömmlichen Cluster mehr
Microsoft hat aus Exchange Server 2010 die Unterstützung für herkömmliche Cluster herausgenommen und konzentriert sich jetzt streng auf die fortlaufende Protokollreplikation in Datenbankverfügbarkeitsgruppen als beste Möglichkeit zum Erreichen der Hochverfügbarkeit. Mit der »Wolfpack«-Technologie von Exchange 5.5 standen 1997 zum ersten Mal Cluster in Exchange zur Verfügung (in Exchange Server 2007 wurden sie als Einzelkopiecluster bezeichnet), und seitdem haben sie eine sehr wechselhafte Geschichte erlebt. Einerseits waren Cluster lange Zeit die einzige Möglichkeit, um Hochverfügbarkeitslösungen für Exchange einzurichten, bis ab Exchange Server 2003 Drittanbieterprodukte für die asynchrone Datenreplikation allgemein erhältlich waren.
524
Es gibt keine herkömmlichen Cluster mehr
Andererseits sind und waren Cluster immer sehr aufwändig und teuer. Zusätzliche Hardware ist erforderlich, Windows und Exchange müssen in Clustern auf besondere Weise installiert werden, nicht jegliche Software läuft reibungslos auf Clustern (falls sie es überhaupt tut), und Administratoren müssen sich erst mit dem Betrieb von Clustern vertraut machen, bevor sie sie sinnvoll verwalten können. Darüber hinaus haben Kritiker der Clustertechnologie auf folgende Nachteile hingewiesen: 쐍 Wenn der Informationsspeicherprozess in einem Cluster ausfällt, startet der Cluster ihn auf demselben Servercomputer neu, ohne dass ein Failover stattfindet. Wenn es auf diesem Rechner also ein Problem gibt, bleibt es bestehen, bis ein Administrator etwas dagegen tut. 쐍 Treten Speicherprobleme auf – sei es in dem für das Betriebssystem und andere wichtige Dateien reservierten Speicher oder in dem freigegebenen Speicher, den die Clusterknoten verwenden –, bieten auch Cluster keine Abhilfe. Befällt ein katastrophaler Fehler den freigegebenen Speicher, kann dadurch der gesamte Cluster ausfallen, da Exchange nicht in der Lage ist, die Speichergruppen von einem Knoten zum anderen umzuschalten. 쐍 Da Cluster keinen Schutz gegen Speicherfehler bieten, können sie auch die Postfachdatenbanken und die Datenbanken für öffentliche Ordner nicht absichern, die doch das Herz von Exchange bilden und die wichtigsten Daten des Messagingsystems darstellen. Um diese Daten zu schützen, müssen Sie in andere Technologien investieren (z.B. die asynchrone Datenreplikation), damit sie auch nach einem katastrophalen Speicherfehler noch verfügbar sind. 쐍 Es sind Zusatzprodukte von Drittanbietern nötig, um einen standardortübergreifenden Clusterfailover zu ermöglichen. 쐍 Einzelkopiecluster setzen freigegebenen SAN-Speicher voraus und können nicht auf preiswerten Festplatten eingerichtet werden. Die Kritiker haben den Clustern zwar zugestanden, dass sie einen gewissen Schutz gegen Serverausfälle wie einen »Bluescreen« bieten, aber gerade solche Probleme sind heutzutage relativ selten und lassen sich durch einen Serverneustart auch schnell wieder beheben. Ein weiterer Pluspunkt besteht darin, dass Administratoren Patches und Aktualisierungen auf einen passiven Knoten im Cluster anwenden und diesen dann aktivieren können, sodass der aktive Knoten auf dem neuesten Stand ist. Außerdem bieten Cluster bei manchen Sicherungsverfahren Vorteile, da die Sicherung auf einem passiven Knoten vorgenommen werden kann, ohne den aktiven zu beeinträchtigen. Das mögen zwar alles Vorteile sein, aber sie reichen nach Meinung von Microsoft nicht aus, um die weitere Verwendung herkömmlicher Exchange-Cluster zu rechtfertigen, vor allem angesichts der Investitionen, die erforderlich sind, um Exchange auch für den Einsatz in Clustern weiterzuentwickeln (wobei zur Weiterentwicklung auch Service Packs, Hotfixes und Rollupaktualisierungen zählen) und Kundendienst für diejenigen zu leisten, die diese Cluster einsetzen. Der erfolgreiche Einsatz der Protokollreplikation in Exchange Server 2007 hat Microsoft die Möglichkeit gegeben, die Hochverfügbarkeit von Exchange mithilfe einer eigenen Produktfunktion zu verbessern, die das Exchange-Entwicklungsteam weiter ausbauen kann, z.B. durch Datenbankverfügbarkeitsgruppen.
525
Exchange auf dem Weg zur Hochverfügbarkeit
Hilfreiche Skripts für die Verwaltung von Datenbankverfügbarkeitsgruppen
Kapitel 8
Exchange auf dem Weg zur Hochverfügbarkeit
Es gibt keine herkömmlichen Cluster mehr
Aus technischer Sicht ist das ein sinnvoller Ansatz, da das Exchange-Entwicklungsteam jetzt die volle Kontrolle über das Gesamtprodukt hat und sich nicht mehr auf andere Gruppen verlassen muss, die umfangreiche Komponenten beisteuern. Zwar greift Exchange weiterhin auf die Windows-Failoverclustertechnologie und auf Active Directory zurück, doch sämtliche Grundbausteine für die Hochverfügbarkeit befinden sich jetzt im Besitz einer einzigen Entwicklergruppe. Die Kunden, die in herkömmliche Cluster investiert haben, werden den Verlust dieser Technologie beklagen, aber dieser Schritt ist nur die logische Folge von Microsofts Entscheidung, vor allem in die Entwicklung eigener Technologien zu investieren.
Der Schutz Ihrer Daten Wir haben uns ausführlich angesehen, wie Informationen in Datenbanken für Postfächer und öffentliche Ordner gespeichert werden. Es liegt jedoch in der Natur der Informationstechnologie, dass Pannen und Hardwareausfälle selbst in den am besten geführten Umgebungen vorkommen. Da sich solche unglücklichen Zwischenfälle nun einmal nicht wegdiskutieren lassen, müssen wir uns dagegen durch Sicherungskopien schützen, selbst wenn wir unsere Daten an viele Stellen rund um die Welt replizieren. Schließlich gibt es nichts, was mehr zum Sicherheitsgefühl eines Administrators beiträgt, als eine vollständige Sicherungskopie.
526
Sicherung und Wiederherstellung
Kapitel 9
Sicherung und Wiederherstellung
In diesem Kapitel: Eine wichtige Grundsatzfrage
528
Das VSS-Plug-In für Windows Server-Sicherung
530
Durchführen einer Exchange Server 2010-Sicherung
533
Wiederherstellung in einer Wiederherstellungsdatenbank
538
Vollständige Serversicherungen
550
Clients
551
527
Kapitel 9
Sicherung und Wiederherstellung
Sicherungen gehören zu den elementaren Aufgaben eines Administrators, solange ich denken kann. Das ist schon ein ziemlich langer Zeitraum, aber tatsächlich gibt es Sicherungen schon sehr viel länger. Auf jedem Computersystem können defekte Festplatten, Serverausfälle, Irrtümer bei der Verwaltung, Softwarebugs, Hardwarefehler und andere Störungen zu Datenverlusten führen. Angesichts dieser Gefahr benötigen Sie Sicherungen, um das beruhigende Gefühl genießen zu können, die verlorenen Daten wiederherstellen zu können, ohne in Schweiß auszubrechen. Die Einführung von Datenbankverfügbarkeitsgruppen und anderen Neuentwicklungen in Exchange Server 2010 erweitert die Palette der Aspekte, die Sie berücksichtigen müssen, wenn Sie ein Sicherungsverfahren aufstellen. Vielleicht gelangen wir eines Tages an einen Punkt, an dem Sicherungen nicht mehr so wichtig sind, wie sie einst waren, vielleicht führen wir Sicherungen irgendwann auf eine andere Art und Weise durch. Außerdem müssen Sie sich über die Wiederherstellung Gedanken machen. Da es bei diesem Thema viel zu besprechen gibt, wollen wir gleich anfangen.
Eine wichtige Grundsatzfrage Wenn Datenbankverfügbarkeitsgruppen so funktionieren, wie Microsoft es erwartet, und eine stabile Hochverfügbarkeitsumgebung für Exchange schaffen, dann können wir theoretisch die herkömmlichen Ansichten über Sicherung und Wiederherstellung, die seit den ersten Versionen von Exchange vorherrschten, über Bord werfen. Mit Sicherungen haben sich Administratoren vor den Auswirkungen von logischen und physischen Beschädigungen der Datenbanken geschützt, da sie das System damit in den Zustand an einem bestimmten Zeitpunkt zurückversetzen oder Daten wiedergewinnen konnten, wenn einzelne Elemente in Postfächern oder ganze Postfächer versehentlich gelöscht worden waren. Doch Exchange Server 2010 schafft eine ganz neue Situation: 쐍 Datenbanken können über viele Kopien verfügen, sodass ein Fehler auf einem Server die Datenbank nicht unzugänglich macht. 쐍 Dank größerer Postfächer (durch replizierte Datenbanken vor Datenverlusten geschützt), der Aufbewahrung und der Wiederherstellung gelöschter Objekte können Benutzer in vielen Fällen versehentlich entfernte Elemente selbst wiederherstellen. 쐍 Verzögerte Datenbankkopien bieten Schutz gegen die Folgen logischer Beschädigungen. Die meisten Administratoren werden spontan antworten, dass Sicherungen funktionieren, sodass es keinen Grund gibt, etwas zu ändern. Das klingt vernünftig, aber bedenken Sie, dass Technologie einem ständigen Wandel unterliegt. Die Vorgehensweisen, die gestern angemessen und wirtschaftlich waren, müssen es heute nicht mehr zwangsläufig sein. Exchange Server 2010 ist die erste Version mit Replikation auf mehrere Kopien. Außerdem ist es dank der neuen E/A-Merkmale auch die erste Version, die einen wirkungsvollen Einsatz von SATA-Speicher möglich macht. Die Technik hat sich soweit entwickelt, dass sich auch erschwingliche Festplatten für die Speicherung von Daten eignen, und Netzwerkbandbreite ist billig genug, um eine Replikation über mehrere Standorte hinweg zu erlauben. Wir sind daher an einem Punkt angelangt, an dem wir unsere althergebrachten Verfahrensweisen überprüfen und uns fragen müssen, ob wir unsere Aufgaben nicht auf bessere Weise erfüllen können. Bei dieser Analyse müssen wir die folgenden Faktoren berücksichtigen: 쐍 Die Anforderungen des Gesetzgebers und etwaiger Zertifizierungsprogramme, die Ihr Unternehmen bei der Aufbewahrung von Daten erfüllen muss. 쐍 Die Kosten der Wiederherstellung von herkömmlichen Sicherungen im Vergleich mit dem Aufwand dafür, gelöschte Daten in einem erweiterten Papierkorb oder in Archivpostfächern aufzubewahren. In einer typischen Exchange Server 2007-Umgebung befindet sich die überwiegende
528
Mehrzahl der Daten in den aktiven Datenbanken und ein geringer Prozentsatz im Papierkorb. Da Sie jetzt sehr große Postfächer bereitstellen, gelöschte Elemente viele Wochen und sogar Monate lang im Papierkorb aufbewahren und Archivpostfächer nutzen können, die in die Clientoberfläche integriert sind, sollte es nicht mehr so häufig erforderlich sein, gelöschte oder offline aufbewahrte Daten wiederherzustellen. 쐍 Die Kosten für die Wiederherstellung einer vollständigen Datenbank von Bandsicherungen (oder VSS-Snapshots oder Klonen) statt von einer passiven Kopie der Datenbank. 쐍 Die Kosten für Bänder, Laufwerke und die interne und externe Aufbewahrung sowie die entsprechenden Kosten für die Aufbewahrung von VSS-Sicherungen. Hier müssen Sie sich u.a. fragen, wie viele Sicherungen Sie brauchen, welches Rotationsverfahren Sie einsetzen usw. 쐍 Die Möglichkeit, Daten auch nach dem Ablauf eines normalen Sicherungszyklus noch zurückgewinnen zu können. Stellen Sie sich vor, in Ihrem Unternehmen wird wegen des Verdachts der sexuellen Nötigung ermittelt, und die Beweise befinden sich in Nachrichten, die sechs Monate zuvor gesendet wurden. Welche Maßnahmen sind erforderlich, um wieder an diese Daten zu kommen? 쐍 Testen und Üben der Maßnahmen, die zur Wiederherstellung nach verschiedenen Arten von ausfällen erforderlich sind, von einem Speicherfehler, der nur eine Datenbank betrifft, bis zum Ausfall von Servern mit mehreren Datenbankkopien. Um die Geschäftsleitung davon zu überzeugen, dass eine Verfahrensänderung möglich ist, müssen Sie vor allen Dingen genau wissen, wie Sie schnell und effektiv den Betrieb wieder aufnehmen und Daten wiederherstellen können. Brauchen wir noch herkömmliche Sicherungen?
Ist es weiterhin erforderlich, die herkömmlichen täglichen und wöchentlichen Sicherungen von Exchange-Daten ausführen, wenn es eine Datenbankverfügbarkeitsgruppe gibt und von allen wichtigen Postfachdatenbanken mehrere Kopien vorgehalten werden? Viele Unternehmen nehmen täglich vollständige Sicherungen vor, damit sie bei einem Ausfall keine inkrementellen Sicherungen wiederherstellen müssen, was den Wiederherstellungsvorgang vereinfacht. Um den Anforderungen von Zertifizierungsprogrammen zu genügen, werden die Sicherungsbänder gewöhnlich nach einigen Tagen an einen externen Lagerort gebracht, wo sie längere Zeit aufbewahrt werden können. Solche Sicherungszyklen gibt es schon seit den Tagen der ersten Mainframecomputer, doch in einer Zeit, in der die Daten auf mehrere Kopien repliziert werden, stellt sich die Frage, ob dies immer noch die sinnvollste Vorgehensweise ist, um kritische Daten zu schützen und eine Wiederherstellung nach einem katastrophalen Ausfall durchführen, die Datenbanken in den Zustand an einem bestimmten Zeitpunkt zurückversetzen, gesetzliche Anforderungen zur Beweissicherung erfüllen und Benutzerdaten wiedergewinnen zu können. Aus rechtlichen oder anderen Gründen sind in einigen Umgebungen stets Sicherungen notwendig. Bei den anderen wird es interessant sein zu beobachten, wie sich das Sicherungsverfahren beim Einsatz von Datenbankverfügbarkeitsgruppen ändert. Ich vermute, dass Sicherungen nach wie vor als Sicherheitsnetz verwendet werden, bis sich die Administratoren genügend an die Funktionsweise von Datenbankverfügbarkeitsgruppen gewöhnt haben. Mit der Zeit wird das Vertrauen in diese neue Technik steigen, vor allem nach einem Ausfall, bei dem die Administratoren die Gelegenheit haben zu sehen, wie sie mithilfe von Datenbankverfügbarkeitsgruppen mit dieser Situation fertig werden können. In Zukunft werden wahrscheinlich mehr und mehr Exchange-Umgebungen ohne Sicherungen auskommen und sich ganz auf den Schutz durch Datenbankverfügbarkeitsgruppen verlassen.
529
Sicherung und Wiederherstellung
Eine wichtige Grundsatzfrage
Kapitel 9
Sicherung und Wiederherstellung
Anhand dieser Punkte können Sie eine Kosten-Nutzen-Analyse durchführen, um herauszufinden, ob Ihre Organisation dazu bereit ist, ohne Sicherungen von Exchange-Daten auszukommen (es kann sein, dass Sie für andere Anwendungen nach wie vor herkömmliche Sicherungen benötigen), und wie schnell Sie den Wechsel nach der Bereitstellung von Exchange Server 2010 vollziehen können. Natürlich müssen Sie alle diese Aspekte im Hinblick auf den Betrieb in Ihrem Unternehmen klären. Ein gutes Beispiel dafür ist der Papierkorb. Er ist in Exchange schon seit etwa zehn Jahren vorhanden und ermöglicht den Benutzern, versehentlich gelöschte Elemente ohne Hilfe eines Administrators wiederherzustellen. Gewöhnlich wird der Papierkorb so eingerichtet, dass er gelöschte Elemente 7 bis 14 Tage lang aufbewahrt, sodass die Benutzer genügend Zeit haben, um zu erkennen, dass sie irrtümlich etwas gelöscht haben, das sie noch brauchen, und es wiederherstellen können, bevor der Informationsspeicher es aus den Datenbanken entfernt. Für besondere Postfächer, z.B. diejenigen für die Geschäftsleitung, werden häufig längere Aufbewahrungszeiten von bis zu sechs Monaten eingerichtet. Die Elemente im Papierkorb werden bei der Berechnung des Kontingents nicht berücksichtigt, sodass der Papierkorb – je nachdem, wie eifrig der Benutzer beim Empfangen, Erstellen und Löschen und E-Mails ist – bis zu 10% der Größe des Postfachs annehmen kann. In manchen Organisationen werden Aufbewahrungszeiten von bis zu zwei Monaten festgelegt, sodass der Papierkorb einen zusätzlichen Speicherplatz von bis zu 25% belegen kann. Diese Mehrbelastung ist jedoch gerechtfertigt, wenn Sie bedenken, dass die Administratoren dadurch viel Zeit sparen, die sie sonst für die Wiederherstellung einzelner Elemente aufbringen müssten. Bei einem Postfach von 1 GB machen 10% 100 MB aus. Wenn Sie die Postfachgröße auf 10 GB erhöhen, kann der Papierkorb 1 GB umfassen. Ist das noch akzeptabel? Wenn Sie die Daten jeden Tag sichern, dauern Sicherung und Wiederherstellung natürlich deutlich länger. Nutzen Sie dagegen die Datenreplikation, um sich gegen Verluste zu schützen, dann ist 1 GB zusätzlich erforderlicher Speicherplatz kein großes Übel, vor allem da Sie sehr viel Arbeitszeit einsparen, wenn Sie die Sicherungsverfahren einschränken oder ganz aufgeben. Dieses Beispiel zeigt, dass Sie Ihre bisherigen Verfahrensweisen genau unter die Lupe nehmen müssen, um die neuen Technologien und Funktionen nutzen und die Anforderungen Ihrer Organisation kostengünstig erfüllen zu können.
Das VSS-Plug-In für Windows ServerSicherung Viele Jahre lang konnten Sie in Exchange das Standardprogramm NTBACKUP verwenden, um Datenbanken auf Festplatte oder auf Band zu sichern. Grundlage war die API von ESE (Extensible Storage Engine), die Daten als Stream sicherte und wiederherstellte. Im Gegensatz dazu werden heute VSS-Snapshot-Sicherungen verwendet. Bandsicherungen erfüllten zwar ihren Zweck, doch angesichts immer größerer Datenbanken dauerte es immer länger, um die Sicherungen durchzuführen, selbst mit schnelleren Bändern und ausgefeilten Bandbibliotheken. Als Exchange Server 2007 SP1 auf Windows Server 2008 ausgeführt werden konnte, nahm Microsoft die Möglichkeit heraus, StreamingSicherungen von Exchange-Datenbanken durchzuführen, und sah einzig und allein VSS-Sicherungen für Anwendungen vor. Für kleine und mittlere Unternehmen war das ein großes Problem, da gerade sie Streaming-Sicherungen einsetzten. Große Unternehmen verwendeten auch größere Datenbanken und hatten daher gewöhnlich modernere Sicherheitsverfahren mit VSS entwickelt, weshalb sie von diesem Wechsel nicht so stark betroffen waren. Microsoft reagierte darauf mit dem VSS-Plug-In WSBExchange.exe für Windows Server-Sicherung, das zusammen mit der Postfachrolle von Exchange Server 2007 SP2 und Exchange Server 2010 instal530
liert wird. Es gibt einige Unterschiede in der Funktionsweise von Windows Server-Sicherung und NTBACKUP und auch einige Einschränkungen, die Sie bei der Planung von Sicherungen bedenken müssen. Nehmen Sie sich also die Zeit, ein bisschen mit Windows Server-Sicherung herumzuspielen, indem Sie einige Sicherungen und Wiederherstellungen auf einem Testserver durchzuführen. Vor allem müssen Sie die folgenden Punkte beachten: 쐍 Die ursprüngliche Version von Windows Server-Sicherung konnte nur VSS-Sicherungen von kompletten Volumes anlegen. Wenn es neben den Exchange-Datenbanken auch noch andere Daten in dem Volume gibt, werden sie mit in die Sicherung aufgenommen. Außerdem war es nicht möglich, einzelne Datenbanken zu sichern, da alle Datenbanken in dem Volume verarbeitet wurden. Diese Probleme gehören der Vergangenheit an, wenn Sie Windows Server 2008 R2 zusammen mit Exchange Server 2010 SP1 verwenden. In dieser Kombination können Sie einzelne Verzeichnisse auswählen, die Windows Server-Sicherung kopieren soll, z.B. diejenigen, die nur die ExchangePostfachdatenbanken enthalten. 쐍 Sie haben die Wahl zwischen vollständigen VSS-Sicherungen und VSS-Kopiesicherungen. Der Unterschied liegt darin, dass die Transaktionsprotokolle nach einer vollständigen Sicherung abgeschnitten werden, nicht aber nach einer Kopiesicherung. Erfolgreich heißt in diesem Zusammenhang, dass eine Konsistenzprüfung die Gültigkeit der Datenbank bestätigt hat und dass das gesamte Volume kopiert wurde. 쐍 Um ein Postfach oder eine einzelne Datenbank zurückzugewinnen, stellen Sie sie zunächst in einem anderen Volume von der Sicherung wieder her und verwenden die Dateien dann, um eine Wiederherstellungsdatenbank aufzubauen. 쐍 Remotesicherungen sind nicht möglich. Sie müssen die Sicherung auf dem Server ausführen, auf dem sich die Datenbanken befinden. 쐍 Die Sicherungsdateien können auf einer lokalen Festplatte oder auf einer Netzwerkfreigabe angelegt werden. Eine direkte Sicherung auf Band ist nicht möglich. Wenn Sie Sicherungsbänder benötigen, die Sie auswärts lagern möchten, müssen Sie zunächst eine Sicherung auf Festplatte durchführen und die Sicherungsdateien dann auf Band übertragen. 쐍 Sie können eine Datenbank am ursprünglichen Speicherort wiederherstellen, aber auch auf einer anderen Festplatte. Bei der ersten Möglichkeit werden alle Dateien überschrieben, die sich an dieser Stelle befinden. Alle in einem Volume gesicherten Datenbanken müssen gemeinsam wiederhergestellt werden. Der Vorgang läuft automatisch ab; Sie müssen weder die Bereitstellung der Datenbank aufheben noch die Datenbankeigenschaft Diese Datenbank kann bei einer Wiederherstellung überschrieben werden aktivieren, wie es in früheren Versionen von Exchange der Fall war. Dass die Datenbanken jetzt automatisch überschrieben werden, ist schon beängstigend, denn wenn Sie einen Fehler machen, kann das zu unvorhersehbaren Problemen führen. Nehmen wir beispielsweise an, Sie wollen eine Datenbank auf einem logischen Gerät aus einer Sicherung wiederherstellen, denken aber nicht daran, dass es auf diesem logischen Gerät noch zwei weitere, fehlerfreie Datenbanken gibt. Bei einer Wiederherstellung überschreiben Sie alle drei Datenbanken! In diesem Fall tun Sie besser daran, die Datenbank an einem anderen Speicherort wiederherzustellen, sie dort zu überprüfen und die Dateien dann manuell an die richtige Stelle zu kopieren. Eine Datenbank, die Sie an einem anderen Speicherort wiederherstellen, kann Exchange auch bereitstellen und als Wiederherstellungsdatenbank verwenden. 쐍 Bereitstellungspunkte können Sie nur dann verwenden, wenn Sie Exchange Server 2010 auf Windows Server 2008 R2 ausführen. Auf Windows Server 2008 SP2 müssen Sie für die Volumes mit den Exchange-Datenbanken Laufwerksbuchstaben angeben. Nachdem wir jetzt wissen, wie Windows Server-Sicherung mit Exchange-Datenbanken umgeht, sehen wir uns VSS genauer an. 531
Sicherung und Wiederherstellung
Das VSS-Plug-In für Windows Server-Sicherung
Kapitel 9
Sicherung und Wiederherstellung
Exchange und der Volumeschattenkopie-Dienst Der Volumeschattenkopie-Dienst (Volume ShadowCopy Services, VSS) wurde in Windows Server 2003 eingeführt. Exchange Server 2003 war die erste Version des Messagingprodukts, die VSS für die Sicherung und Wiederherstellung von Datenbanken nutzte, und nach den ersten unvermeidlichen Startschwierigkeiten (aufgrund mangelnder Kenntnisse der Administratoren und einiger Softwarefehler) hat sich die dieser Dienst sowohl in Windows als auch in Exchange nach und nach weiterentwickelt und verbessert. Bei der VSS-Sicherung spielen die drei folgenden Komponenten eine wichtige Rolle: 쐍 Die Anforderungskomponente ist eine Sicherungsanwendung wie Backup Exec oder Microsoft System Center Data Protection Manager (DPM). 쐍 Der Anbieter ist eine Windows-Komponente, die den Zugang zu einer VSS-Kopie vermittelt. 쐍 Die Schreibkomponente ist ein anwendungsspezifisches Bestandteil, das Daten für die Sicherung vorbereitet. Beispielsweise die Exchange-Schreibkomponente ESE anweisen, den Inhalt des Arbeitsspeicher-Caches auf die Festplatte zu schreiben, damit eine vollständige Sicherung durchgeführt werden kann. Was im Einzelnen geschieht, wenn Sie eine VSS-Sicherung für Exchange durchführen, hängt davon ab, welche Sicherungsanwendung Sie einsetzen. Den Verlauf der Sicherung können Sie beobachten, indem Sie sich die Ereignisse im Anwendungsprotokoll anschauen. Das allgemeine Verfahren läuft wie folgt ab: 쐍 Die Sicherungsanwendung (die Anforderungskomponente) wendet sich an VSS (den Anbieter), um den Zugriff auf eine Exchange-Datenbank anzufordern. In der Benutzeroberfläche der Sicherungsanwendung kann der Administrator angeben, welche Datenbanken er in die Sicherung aufnehmen möchte, und diese Auswahl wird an den Anbieter weitergegeben. 쐍 VSS ruft die Exchange-Schreibkomponente auf und teilt ihr mit, dass eine Sicherung angefordert wurde. Dies ist die Phase PrepareBackup, die ESE dazu zwingt, Daten aus dem Arbeitsspeicher auf die Festplatte zu schreiben, das aktuelle Transaktionsprotokoll zu schließen und die Prozesse zu beenden, die Daten in den Cache (Prozess für verzögertes Schreiben) und in die Transaktionsprotokolle schreiben. 쐍 Anschließend weist VSS die Exchange-Schreibkomponente an, die Zieldatenbank »einzufrieren«, um einen festen Zustand für die Sicherung zu erreichen. Während Datenbanken eingefroren sind, akzeptieren sie keine neuen Schreibanforderungen. 쐍 ESE wartet, bis alle Daten aus dem Cache auf die Festplatte geschrieben und die Dienste angehalten sind, und teilt der Anforderungskomponente anschließend mit, dass die Zieldatenbanken eingefroren sind. 쐍 Nachdem alles eingefroren ist, erstellt VSS einen Snapshot und platziert ihn auf einer anderen Festplatte. 쐍 Nach Fertigstellung des Snapshots wird Exchange von VSS wieder »aufgetaut«, sodass die normale Verarbeitung wieder ihren Lauf nehmen kann. Die Prozesse für verzögertes Schreiben und für das Schreiben in die Protokolle werden wieder aufgenommen. Gewöhnlich bemerken die Benutzer die Unterbrechung nicht, vor allem dann, wenn sie Outlook im Exchange-Cache-Modus verwenden. 쐍 Die Sicherungsanwendung führt eine Konsistenzprüfung durch, um sich zu vergewissern, dass sie über fehlerfreie Kopien der Datenbankdateien und Transaktionsprotokolle verfügt. Anschließend entfernt sie die gesicherten Transaktionsprotokolle von der Festplatte. 쐍 Die Sicherungsanwendung meldet die erfolgreiche Durchführung und löst die Verbindung mit VSS. 532
Nach der Aufnahme des Snapshots wird gewöhnlich ein weiteres Verfahren gestartet, um diesen Snapshot von der Festplatte auf Band zu übertragen, sodass er zur Archivierung oder als Vorsichtsmaßnahme gegen Notfälle an einem externen Standort gelagert werden kann.
Durchführen einer Exchange Server 2010Sicherung Die Argumente für die Ansicht, dass man Exchange Server 2010 auch ohne Sicherungen betreiben könne, wenn man genügend Datenbankkopien in einer geschickt entworfenen Datenbankverfügbarkeitsgruppe bereitstellt, haben etwas für sich, doch haben nur wenige Administratoren genug Vertrauen in die Software und Hardware entwickelt, um sich zu dieser Meinung zu bekehren. Zum Glück lassen sich Sicherungen mit Windows Server-Sicherung ohne große Schwierigkeiten erstellen, sofern es keine passiven Datenbanken auf dem Server gibt. Dieses Thema werden wir auch noch angemessen besprechen, aber zunächst einmal gehen wir von dem einfachen Fall einer Sicherung auf einem Server aus, auf dem es nur aktive Datenbanken gibt. Dabei ist es egal, ob es sich um einen eigenständigen Server oder ein Mitglied einer Datenbankverfügbarkeitsgruppe handelt. Datenbanken für öffentliche Ordner können keine Kopien aufweisen und sind daher stets aktiv, sodass sie bei Sicherungen keine Probleme bereiten, sondern einfach mit eingeschlossen werden, wenn sie sich auf dem betreffenden Server befinden. Windows Server-Sicherung weist einen Assistenten auf, mit dem Sie in mehreren Schritten einen Sicherungsauftrag erstellen und damit eine Reihe von Optionen auswählen können. Sobald die Sicherungsanwendung mit der Verarbeitung der Datenbanken beginnt, brauchen Sie sie nicht mehr geöffnet zu halten. Wenn Sie den Assistenten schließen, läuft sie bis zum Abschluss des Vorgangs im Hintergrund. Um sich zu vergewissern, dass die Sicherung erfolgreich verlaufen ist, können Sie später im Ereignisprotokoll oder in Windows Server-Sicherung nachsehen. 1. Starten Sie Windows Server-Sicherung und wählen Sie die Option, um zum jetzigen Zeitpunkt
eine Sicherung vorzunehmen (Einmalsicherung). 2. Wählen Sie Unterschiedliche Optionen, um angeben zu können, welche Volumes Sie sichern
möchten, und dann Benutzerdefiniert, um die gewünschten Volumes festzulegen. Denken Sie daran, dass sämtliche Datenbanken in diesen Volumes in die Sicherung aufgenommen werden. Wenn sich Datenbanken und Transaktionsprotokolle in unterschiedlichen Volumes befinden, müssen Sie dafür sorgen, dass alle relevanten Informationen in die Sicherung eingeschlossen werden. 3. Klicken Sie auf Erweiterte Einstellungen und wählen Sie dann Vollständige VSS-Sicherung aus, damit die Transaktionsprotokolle nach der erfolgeichen Sicherung abgeschnitten werden. 4. Wählen Sie das Ziel für die Sicherung aus. Dabei kann es sich um einen lokalen Datenträger, aber auch um eine Netzwerkfreigabe handeln. Natürlich erfolgt der Vorgang auf einer lokalen Festplatte schneller. Windows Server-Sicherung überprüft, ob Sie die erforderlichen Berechtigungen haben, um auf das ausgewählte Ziel zu schreiben. Sorgen Sie dafür, dass am Ziel genügend freier Speicherplatz vorhanden ist. Windows Server-Sicherung schreibt auch einen Satz von XMLDateien mit Metadaten über die Sicherung und die VHD-Dateien (Virtual Hard Disk, virtuelle Festplatte) für jedes Volume an diese Stelle. 5. Überprüfen Sie die Sicherungsoptionen, die Sie gewählt haben, und fahren Sie mit dem Vorgang fort. Windows Server-Sicherung richtet die erforderlichen Dateien und Ordner am Sicherungsziel ein. 533
Sicherung und Wiederherstellung
Durchführen einer Exchange Server 2010-Sicherung
Kapitel 9
Sicherung und Wiederherstellung
Anschließend fordert Windows Server-Sicherung von Exchange eine Konsistenzprüfung der Datenbanken an, um sicherzustellen, dass sie sich als Sicherungsdaten eignen (siehe Abbildung 9.1). Dabei wird jede Datenbank einzeln überprüft. Wenn eine den Test nicht besteht, verzeichnet Windows Server-Sicherung das Problem im Anwendungsprotokoll, fährt aber mit dem Verfahren fort. Die Datenbanken und Transaktionsprotokolle werden in die Sicherung aufgenommen, können aber nicht zur Wiederherstellung verwendet werden. Abbildg. 9.1
Windows Server-Sicherung führt eine Exchange-Konsistenzprüfung durch.
Windows Server-Sicherung kopiert die Volumes zum festgelegten Ziel (siehe Abbildung 9.2). Abbildg. 9.2
Windows Server-Sicherung kopiert Exchange-Daten.
Nachdem alle Volumes verarbeitet sind, beendet Windows Server-Sicherung den Vorgang und aktualisiert den Sicherungsverlauf auf dem lokalen Server. 534
Die einzelnen Schritte des Sicherungsvorgangs können Sie nachverfolgen, indem Sie die im Anwendungsprotokoll verzeichneten Ereignisse untersuchen. Tabelle 9.1 zeigt eine beispielhafte Abfolge von Ereignissen, wie sie bei einer Sicherung auf einem Server auftreten können, der Mitglied einer Datenbankverfügbarkeitsgruppe ist und mehrere Datenbanken beherbergt. Von diesen Datenbanken kann es auch noch weitere Kopien auf anderen Servern geben. Ist die Umlaufprotokollierung aktiviert, kann Exchange die Transaktionsprotokolle möglicherweise nicht abschneiden. Das gilt vor allem dann, wenn die Sicherung zu einem Zeitpunkt geringer Benutzeraktivität erfolgt, in der keine Transaktionsprotokolle erstellt wird. Ist ein Abschneiden der Transaktionsprotokolle nicht erforderlich, wird Ereignis 9827 gemeldet. Ohne Umlaufprotokollierung schneidet Exchange die Transaktionsprotokolle nach einer erfolgreichen vollständigen Sicherung ab und zeichnet Ereignis 9780 auf. HINWEIS Bei einigen dieser Schritte werden mehrere Ereignisse mit derselben Kennung aufgezeichnet. Beispielsweise wird Ereignis 2001 für jede einzelne Datenbank protokolliert, die ESE zur Vorbereitung auf die Sicherung einfriert. Tabelle 9.1
Sicherungsereignisse Ereigniskennung
Quelle
Ereignis
9606
MSExchangeIS
Die VSS-Schreibkomponente wird zur Verarbeitung der Datenbanken vorbereitet.
2005
ESE
Der Schattenkopiedienst wird gestartet. ESE erstellt eine Instanz und erlaubt ihm den Zugriff auf die Datenbanken.
9811
MSExchangeIS
Das Datenbankmodul die auf dem Server bereitgestellten Datenbanken auf die Sicherung vor.
2001
ESE
ESE friert die einzelnen Datenbanken ein.
9610
MSExchangeIS
Das Einfrieren war erfolgreich.
2003
ESE
Der Einfriervorgang wird beendet.
9612
MSExchangeIS
Die Datenbanken wurden erfolgreich aufgetaut.
3156
MSExchangeIS
Die Datenbanken werden für die ESE-Instanz bereitgestellt, die die Sicherung durchführt.
224 oder 225
ESE
ESE gibt an, wie das Abschneiden der Protokolle verlief. Ereignis 224 wird gemeldet, wenn Protokolle abgeschnitten werden (wobei die Namen der abgeschnitten Protokolldateien vermerkt werden). Ist kein Abschneiden erforderlich, wird Ereignis 225 aufgezeichnet.
9827 oder 9780
MSExchangeIS
Beide Ereignisse zeigen an, dass die Sicherung erfolgreich verlief. Ereignis 9827 wird gemeldet, wenn keine Transaktionsprotokolle abgeschnitten wurden, anderenfalls wird Ereignis 9780 aufgezeichnet.
2006
ESE
ESE bestätigt, dass die vollständige Sicherung erfolgreich verlaufen ist.
9618
MSExchangeIS
Die VSS-Schreibkomponente von Exchange wird geschlossen.
9648
MSExchangeIS
Das Sicherungsprogramm wird geschlossen.
Nach einer erfolgreichen vollständigen Sicherung schneidet Windows Server-Sicherung die Transaktionsprotokolle für die Datenbanken ab und aktualisiert in den Datenbankeigenschaften das
535
Sicherung und Wiederherstellung
Durchführen einer Exchange Server 2010-Sicherung
Kapitel 9
Sicherung und Wiederherstellung
Datum der letzten guten Sicherung. Dieses Datum können Sie einsehen, indem Sie die Datenbank in der Exchange-Verwaltungskonsole markieren und ihre Eigenschaften aufrufen (siehe Abbidlung 9.3) oder indem Sie mit dem folgenden Befehl den Sicherungsstatus des Servers abrufen: Get-MailboxDatabase –Server 'ServerName' –Status | Select Name, LastFullBackup Abbildg. 9.3
In den Datenbankeigenschaften wird das Datum der letzten erfolgreichen Sicherung angezeigt.
Sie können auch nach allen Postfachdatenbanken in der Organisaton suchen, die noch nie gesichert wurden. Hierbei ist der Parameter -Status wichtig, da Sie Exchange damit zwingen, Informationen über Sicherungszeitpunkte auszugeben. Ohne -Status würden alle Datenbanken aufgelistet, da Exchange dann kein Sicherungsdatum sieht und daher überall NULL-Werte annimmt. Get-MailboxDatabase –Status | Where {$_.LastFullBackup –eq $Null} | Select Name
Befindet sich auf dem Server auch eine Datenbank für öffentliche Ordner, müssen Sie dafür einen eigenen Befehl geben: Get-PublicFolderDatabase –Status | Where {$_.LastFullBackup –eq $Null} | Select Name
Insidertipp: Andere Sicherungsprodukte
Anspruchsvollere Sicherungsprodukte wie Microsoft System Center DPM, Symantec Backup Exec oder HP Data Protector weichen in Einzelheiten von dem hier vorgestellten Vorgang ab, Funktionsprinzip und allgemeiner Ablauf aber sind identisch. Alle wichtigen Sicherungsprodukte sind jetzt so aktualisiert worden, dass sie auch für Exchange Server 2010 verwendet werden können und in der Lage sind, Sicherungen der aktiven und passiven Datenbanken in Datenbankverfügbarkeitsgruppen vorzunehmen. Trotzdem sollten Sie den Anbieter Ihres Sicherungsprodukts fragen, ob besondere Maßnahmen erforderlich sind, um sicherzustellen, dass Sie zuverlässige Sicherungen anlegen, aus denen Sie Ihre Daten bei Bedarf wiederherstellen können.
536
Schwierigkeiten bei der Sicherung aufgrund passiver Datenbankkopien Das Exchange-Plug-In für Windows Server-Sicherung ermöglicht Onlinesicherungen von Postfachdatenbanken, eignet sich aber nicht zum Sichern der Datenbankkopien in einer Datenbankverfügbarkeitsgruppe. Zwar kann dieses Programm auch einen Mitgliedserver einer solchen Gruppe sichern, aber nur, wenn alle Datenbankkopien auf ihm aktiv sind. Sind auch passive Datenbanken vorhanden, werden die Daten zwar kopiert, bestehen aber die Konsistenzprüfung nicht, weshalb die Sicherung nicht zur Wiederherstellung herangezogen werden kann. Der Grund dafür liegt darin, dass der Informationsspeicher die passiven Datenbanken nicht auf solche Weise bereitstellt wie die aktiven. Nur der Exchange-Replikationsdienst greift auf diese Datenbanken zu, um die von den Servern mit den aktiven Kopien übertragenen Transaktionsprotokolle einzuspielen. Es ist also eine zweite VSS-Schreibkomponente erforderlich, die es Windows Server-Sicherung erlaubt, über den Exchange-Replikationsdienst auf die passiven Datenbanken zuzugreifen. TIPP Es ist durchaus möglich, dass Windows Server-Sicherung mit der Zeit verbessert wird und auch mit den Schwierigkeiten fertig wird, die sich durch das Vorhandensein von aktiven und passiven Datenbankkopien in einer Verfügbarkeitsgruppe stellen. Daher sollten Sie vor dem Einrichten eines Sicherheitsverfahrens in Ihrer Produktionsumgebung Tests mit den neuesten Softwareversionen durchführen. Die hier beschriebenen Erfahrungen gehen auf Exchange Server 2010 SP1 und Windows Server 2008 R2 zurück. Da auf Mitgliedservern einer Datenbankverfügbarkeitsgruppe in der Produktion wahrscheinlich sowohl aktive als auch passive Kopien vorhanden sind, wird in solchen Umgebungen gewöhnlich ein anspruchsvolleres Sicherungsprodukt bereitgestellt, z.B. Microsoft System Center DPM. Wenn Sie nicht dazu bereit sind, Geld für zusätzliche Software auszugeben, können Sie auch ein Verfahren entwickeln, bei dem Sie die aktiven Datenbanken so zwischen den Servern umschalten, dass sie mit Windows Server-Sicherung kopiert werden können. Dabei schalten Sie alle Datenbanken auf einem Server aktiv, sodass er keine passiven Kopien mehr enthält, wenn Sie mit der Sicherung beginnen. Das ist zwar möglich, aber offensichtlich mit viel Handarbeit verbunden, ganz zu schweigen von der Fehleranfälligkeit und den möglichen Betriebsstörungen für die Benutzer. Besser ist es, die bittere Pille zu schlucken und in Sicherungssoftware zu investieren, die mit sämtlichen möglichen Konstellationen in einer Datenbankverfügbarkeitsgruppe fertig wird bis hin zu der Möglichkeit, Datenbanken für öffentliche Ordner, aktive und passive Postfachdatenbankkopien alle zusammen zu sichern. Fragen Sie den Hersteller Ihres derzeitigen Sicherungsprodukts, ob dessen aktuelle Version für den Einsatz in Datenbankverfügbarkeitsgruppen geeignet ist, und welche Tipps er Ihnen zu einer möglichst rationellen Vorgehensweise für die Sicherung und Wiederherstellung in solchen Gruppen geben kann. Insidertipp: Passive Datenbankkopien zur Entlastung des aktiven Servers
Es kann wünschenswert sein, Sicherungen der passiven Datenbankkopien vorzunehmen, um den aktiven Server zu entlassen. In manchen Umgebungen werden passive Kopien auf einem eigens dafür vorgesehenen Server gesammelt, der nur zu Verwaltungszwecken da ist. Sicherungen werden dann ausschließlich auf diesem Server vorgenommen. Je nach Anzahl der passiven Kopien, die auf die Server in der Datenbankverfügbarkeitsgruppe verteilt werden müssen, kann es aber auch sein, dass diese Vorgehensweise nicht möglich ist.
537
Sicherung und Wiederherstellung
Durchführen einer Exchange Server 2010-Sicherung
Kapitel 9
Sicherung und Wiederherstellung
Wie wir bei der Beschreibung von Windows Server-Sicherung schon gesehen haben, werden die Transaktionsprotokolle nach der erfolgreichen vollständigen Sicherung einer aktiven Datenbank abgeschnitten oder gelöscht. Der Replikationsdienst auf dem Server mit der aktiven Kopie setzt sich dazu mit dem Informationsspeicher in Verbindung, um ihm den aktuellen Sicherungsstatus mitzuteilen. Der Informationsspeicher erkennt, dass eine erfolgreiche Sicherung erfolgt ist, und aktualisiert seinerseits den Header der Datenbank mit dem Sicherungsstatus, der Uhrzeit und dem Datum usw. Zusammen mit anderen Datenbankaktualisierungen werden die Headerdaten an alle Server mit Kopien repliziert. Der Code in Eseback.dll berechnet dann, welche Transaktionsprotokolle nach der Sicherung nicht mehr benötigt werden, und entfernt sie von dem Server, auf dem die Sicherung stattgefunden hat. Dieser Löschvorgang wird an den Replikationsdienst auf den Servern mit den Kopien gemeldet, sodass die dortigen Replikationsdienste auf ihren Servern die gleichen Protokolle abschneiden können.
Wiederherstellung in einer Wiederherstellungsdatenbank Wenn Sie eine Datenbankverfügbarkeitsgruppe betreiben und darin ein Server oder ein Speicher ausfällt, sollten Sie in der Lage sein, zu einer Datenbankkopie umzuschalten, sodass die Benutzer weiterhin auf ihre Daten zugreifen können, während Sie das Problem beheben. Der große Vorteil von Datenbankverfügbarkeitsgruppen lässt sich in einem kurzen Satz ausdrücken: Der Betrieb geht auch bei einem Server- oder Speicherausfall weiter. Voraussetzung dafür ist natürlich, dass Sie über genügend Datenbankkopien verfügen und dass der Ausfall nicht sämtliche Kopien betrifft. Wenn jedoch ein Speicherfehler auftritt, ohne dass Sie auf eine Datenbankverfügbarkeitsgruppe zurückgreifen können, müssen Sie eine Wiederherstellung von einer Sicherung durchführen. Insidertipp: Die ungeschminkte Wahrheit über die Wiederherstellung gelöschter Elemente
Selbst wenn Sie eine Datenbankverfügbarkeitsgruppe haben, kann es immer noch sein, dass Sie auf eine Sicherung zurückgreifen müssen, um Daten wiederzugewinnen, die auf andere Weise nicht mehr zugänglich sind. Die verlängerten Aufbewahrungszeiten für gelöschte Objekte helfen zwar, die Arbeit auf die Benutzer abzuwälzen, die ein Element versehentlich aus ihrem Postfach gelöscht haben und jetzt feststellen, dass sie es doch wieder brauchen, aber laut Murphys Gesetz denken die meisten Administratoren erst dann daran, die Standardaufbewahrungszeit für gelöschte Objekte von 14 Tagen zu verlängern, nachdem sich ein Benutzer gemeldet hat, der ein wichtiges Element vor 15 Tagen gelöscht hat. Möglicherweise können Sie solche Ansinnen auf Wiederherstellung aufgrund der hohen Kosten und des damit verbundenen Arbeitsaufwands ablehnen, aber wahrscheinlich müssen Sie den Vorgang doch durchführen, vor allem, wenn der Benutzer, der Sie darum bittet, ein Mitglied der Geschäftsführung ist. Mit Windows Server-Sicherung können Sie Exchange Server 2010-Datenbanken an demselben Speicherort wiederherstellen, an dem sie gesichert wurden, aber auch an einem anderen. In beiden Fällen werden sämtliche Datenbanken und Transaktionsprotokolle eines ganzen Volumes wiederhergestellt. Die Wiederherstellung am selben Ort ist die Möglichkeit, die Sie wählen, wenn Sie eine Festplatte ersetzen müssen und Sie alle ihre Inhalte auf den Zustand an demselben Zeitpunkt zurückversetzen möchten. Wollen Sie dagegen nur die Daten in einen oder mehreren einzelnen Postfächern des Sicherungssatzes wiederherstellen, wählen Sie einen anderen Speicherort. Bei diesem Vorgang wird die Wiederherstellungsdatenbank genutzt, die Nachfolgerin der in Exchange Server 2003 und 2007 ver538
wendeten Speichergruppe für die Wiederherstellung. Dabei handelt es sich um eine Datenbank, die von einer Sicherung an einem Speicherort wiederhergestellt wurde, an dem Exchange auf sie zugreifen kann. Die Postfächer in der Wiederherstellungsdatenbank sind in getrenntem Zustand, da sie keine Verbindung zu Benutzerkonten in Active Directory haben, allerdings können Sie Verbindung mit diesen Postfächern aufnehmen, um Daten abzurufen und in reguläre Datenbanken zu verschieben, wo sie den Benutzern zur Verfügung stehen. HINWEIS Es ist nicht möglich, eine Datenbank für öffentliche Ordner in einer Wiederherstellungsdatenbank wiederherzustellen. Letzteres gibt es nur für Postfachdatenbanken.
Durchführen der Wiederherstellung Um die Wiederherstellung durchführen zu können, müssen Sie die Antworten auf die folgenden Fragen kennen: 쐍 Wo ist der Sicherungssatz gespeichert? 쐍 Welches Datum hat die Sicherung, die Sie wiederherstellen wollen? 쐍 An welchem Speicherort soll die Wiederherstellung erfolgen? 쐍 Was möchten Sie anschließend mit der wiederhergestellten Datenbank tun? Wenn Sie einen Plan haben, in dem alle diese Fragen beantwortet werden, beginnen Sie damit, dass Sie Windows Server-Sicherung starten und darin auf den Speicherort verweisen, an dem sich der Sicherungssatz befindet. Das kann ein Ort auf demselben Speicher sein, aber auch ein Remoteordner. Wählen Sie die Dateien aus, die Sie wiederherstellen möchten. Abbildung 9.4 zeigt das entsprechende Dialogfeld. In diesem Fall stehen drei einzelne Datenbanken zur Wiederherstellung zur Verfügung, wobei eine markiert ist (nämlich DB3). Abbildg. 9.4
Auswählen der wiederherzustellenden Datenbankdateien
539
Sicherung und Wiederherstellung
Wiederherstellung in einer Wiederherstellungsdatenbank
Kapitel 9
Sicherung und Wiederherstellung
Abbildung 9.5 zeigt den nächsten Schritt, in dem Sie den Speicherort für die Wiederherstellung auswählen (der Ordner muss bereits vorhanden sein, und Sie müssen für ausreichend Platz auf der Festplatte gesorgt haben) und die Parameter bestätigen, um fortfahren zu können. Wenn Sie Datenbanken an ihrem ursprünglichen Speicherort wiederherstellen, hebt Exchange automatisch die Bereitstellung der Datenbanken auf, die sich zurzeit dort befinden, führt die Wiederherstellung durch und stellt dann die wiederhergestellten Datenbanken bereit, um sie online zu bringen. Dabei werden auch alle erforderlichen Transaktionsprotokolle eingespielt. Abbildg. 9.5
Festlegen der Parameter für die Wiederherstellung
Die Wiederherstellung der Datenbanken erfolgt meistens schneller als die ursprüngliche Sicherung, da Sie gewöhnlich nur einen Teil der Daten aus dem gesamten Volume in der Sicherung wiederherstellen müssen. Abbildung 9.6 zeigt, dass mehrere Dateien wiederhergestellt wurden und dass Windows Server-Sicherung zurzeit die Datenbankdatei DB3 verarbeitet. Wie viel Zeit für eine Wiederherstellung erforderlich ist, hängt von der Geschwindigkeit des Speicherteilsystems, von der Serverbelastung durch andere Tätigkeiten und der Größe der Datenbanken ab. Allerdings können Sie davon ausgehen, dass eine Wiederherstellung von einer Festplatte selbst auf dem langsamstem Server mit über 300 MB pro Minute erfolgt. Nach der Wiederherstellung finden Sie die Datenbanken, Transaktionsprotokolle und Prüfpunktdateien am Wiederherstellungsspeicherort. Wie Sie in Abbildung 9.7 sehen, sind alle Datenbankdateien und Katalogordner für den Inhaltsindex an Ort und Stelle.
540
Wiederherstellung in einer Wiederherstellungsdatenbank
Wiederherstellen der Dateien einer Exchange-Datenbank
Abbildg. 9.7
Datenbankdateien nach der Wiederherstellung
Sicherung und Wiederherstellung
Abbildg. 9.6
541
Kapitel 9
Sicherung und Wiederherstellung
Insidertipp: Sinnvolle Verwendung der Option »Diese Datenbank kann bei einer Wiederherstellung überschrieben werden«
Es gibt noch einen kleinen Umstand, den Sie beachten sollten: Wenn Sie die Datenbankeigenschaften anzeigen, sehen Sie auch eine Option, die Exchange erlaubt, die Datenbank während einer Wiederherstellung zu überschreiben. Wenn Sie Windows Server-Sicherung verwenden, ist diese Einstellung jedoch ohne Bedeutung, da die Sicherungen und Wiederherstellungen volumeweise durchgeführt werden. Bei der Wiederherstellung hebt das Exchange-Plug-In für Windows ServerSicherung die Bereitstellung der Kopie auf, die sich am Zielort befindet, sodass sie überschrieben werden kann. Die Option Diese Datenbank kann bei einer Wiederherstellung überschrieben werden ist jedoch für andere Sicherungsprodukte von Bedeutung, bei denen eine genauere Auswahl der wiederherzustellenden Objekte möglich ist.
Überprüfen der wiederhergestellten Datenbank Die erforderlichen Dateien befinden sich jetzt auf der Festplatte, aber in Exchange können wir noch keine Verbindung mit der Datenbank aufnehmen, um Daten abzurufen. Als Erstes müssen wir überprüfen, ob sich die Datenbank in einem Zustand befindet, in dem sie als Wiederherstellungsdatenbank auf einem Server bereitgestellt werden kann. Dazu führen wir ESEUTIL aus, um die Datenbankheader zu überprüfen. In unserem Fall wollen wir uns den Header von DB3.edb genauer aussehen, weshalb der Befehl wie folgt lautet: ESEUTIL/MH DB3.edb Abbildg. 9.8
Überprüfen des Datenbankheaders mit ESEUTIL nach der Wiederherstellung
In der Ausgabe von ESEUTIL, die Sie in Abbildung 9.8 sehen, wird als Datenbankstatus Dirty Shutdown (mit modifizierten Seiten heruntergefahren) angegeben. In diesem Zustand weigert sich Exchange, eine Datenbank bereitzustellen, weshalb wir erneut ESEUTIL ausführen müssen, um alle ausstehenden Transaktionen einzuspielen, die sich in den wiederhergestellten Transaktionsprotokollen befinden, und die Datenbank damit auf einen aktuelleren Stand zu bringen. Dazu führen wir folgenden Befehl aus: ESEUTIL /R E04 /i /d
542
Dank der Option /R wird ESEUTIL im Wiederherstellungsmodus (R für »recovery«) ausgeführt. E03 ist das Transaktionsprotokollpräfix für die Datenbank, die wir wiederherstellen möchten, wie wir anhand des letzten Transaktionsprotokolls oder er letzten Prüfpunktdatei ablesen können. In Abbildung 9.7 ist als Prüfpunktdatei E04.chk aufgeführt, weshalb E04 das korrekte Präfix sein muss. Die Option /i sorgt dafür, dass ESEUTIL das Fehlen von Dateien ignoriert, und mit /d wird der Pfad für die Transaktionsprotokolle angegeben. Da wir uns bereits in dem Verzeichnis mit den wiederhergestellten Datenbank- und Protokolldateien befinden, brauchen wir diese Wert nicht anzugeben. ESEUTIL liest zunächst die Prüfpunktdatei, um herauszufinden, welche Transaktionen mit Commit in die Datenbank übernommen wurden, und gibt dann die ausstehenden Transaktionsprotokolle wieder, um ihre Daten in die Datenbank einzuspielen (siehe Abbildung 9.9). Wenn nicht gerade Tausende von Transaktionsprotokollen zu verarbeiten sind, läuft dieser Vorgang recht zügig ab. Datenbanken mit Umlaufprotokollierung, die durch die Mitgliedschaft in Verfügbarkeitsgruppen gegen Datenverluste geschützt sind, weisen gewöhnlich weit weniger Transaktionsprotokolle auf als andere. Abbildg. 9.9
ESEUTIL aktualisiert die wiederhergestellte Datenbank durch die Daten aus den Transaktionsprotokollen.
Nachdem das Programm ESEUTIL die Wiederherstellung der Datenbank abgeschlossen hat, können wir es mit der Option /MH erneut ausführen, um uns zu vergewissern, dass sich die Datenbank jetzt im Zustand Clean Shutdown (sauber heruntergefahren) befindet.
Bereitstellen einer Wiederherstellungsdatenbank Die Datenbank ist jetzt wiederhergestellt und validiert, aber in Exchange immer noch nicht zugänglich. Dazu müssen wir einen Zeiger auf die Datenbank erstellen und sie als Wiederherstellungsdatenbank kennzeichnen, was aber nur in der Exchange-Verwaltungsshell möglich ist. Als Erstes erstellen wir mit New-MailboxDatabase den Zeiger (und zwar in den Exchange-Konfigurationsdaten von Active Directory) auf die wiederhergestellte Datenbank. Der Trick besteht darin, den Parameter -Recovery zu verwenden, damit Exchange weiß, dass diese Datenbank für Wiederherstellungszwecke verwendet wird: New-MailboxDatabase –Name 'DB3 Rec overy Database' –Server ExServer1 -Recovery –EDBFilePath 'E:\Exchange\db3.edb' –LogFolderPath 'E:\Exchange'
543
Sicherung und Wiederherstellung
Wiederherstellung in einer Wiederherstellungsdatenbank
Kapitel 9 Abbildg. 9.10
Sicherung und Wiederherstellung
Bekanntmachen der wiederhergestellten Datenbank in Exchange
Wie Sie in Abbildung 9.10 erkennen können, teilte Ihnen Exchange mit, dass Sie die wiederhergestellte Datenbank nur dann bereitstellen können, wenn Sie sich im Zustand Clean Shutdown befindet. Dafür haben wir schon mit ESEUTIL gesorgt, weshalb wir hier einfach fortfahren können. In der Exchange-Verwaltungskonsole wird die Wiederherstellungsdatenbank jetzt angezeigt, sodass wir sie genauso wie jede andere Datenbank verwalten können (siehe Abbildung 9.11). Abbildg. 9.11
Anzeige der Wiederherstellungsdatenbank in der Exchange-Verwaltungskonsole
Als nächsten Schritt müssen wir die Datenbank bereitstellen, was wir sowohl in der Verwaltungskonsole als auch in der Verwaltungsshell tun können. Versuchen wir es in der Shell: Mount-Database –Identity 'DB3 Recovery Database'
544
HINWEIS Wenn Sie versuchen, eine Datenbank bereitzustellen, bei der einige Dateien fehlen, warnt Sie Exchange, bietet Ihnen aber an, eine neue Datenbank anzulegen und diese bereitzustellen. Wenn Sie das zulassen, haben Sie eine wunderschöne neue und vollständig leere Datenbank, was manchmal durchaus in Ihrem Sinne sein kann (z.B. bei einer Dial-Tone-Wiederherstellung), aber nicht, wenn Sie einen kompletten Satz von Datenbank- und Protokolldateien wiederherstellen wollten. Beim Bereitstellen der Datenbank werden eine neue Prüfpunktdatei und ein neuer Satz von Transaktionsprotokollen angelegt, um alle Änderungen zu erfassen, die an der Datenbank vorgenommen werden, während sie sich im Wiederherstellungsmodus befindet. Da die Datenbank jetzt bereitsteht, können wir mit einigen der Cmdlets für Postfachdatenbanken auf sie zugreifen. Beispielsweise können wir wie folgt die Namen der enthaltenen Postfächer und die Anzahl der darin befindlichen Elemente herausfinden: Get-MailboxStatistics –Database 'DB3 Recovery Database' | Select DisplayName, ItemCount | Format-Table –AutoSize DisplayName ItemCount ----------------------------Pelton, David (HQ) 74 Shen, Alan 41 Shah, Niraj (China HQ) 37 Online Archive - Redmond, Tony 126 Camelbeke, Geert 11 Akers, Kim 100 Online Archive - Akers, Kim 7 Smits, Guntars 31 Redmond, Conor (IT) 43 Shen, Paul (China HQ) 39 Peled, Yael (IT) 26 Solovay, Andrew 30 Galway Conference Room 17 Parker, Darren 20 Redmond, Tony 1053 Simpson, David (Sales) 39 Pais, Wilson 21 SystemMailbox{3ef66f70-347f-4b1e-97ad-73e9ff908d0e} 1
Diese Informationen sind nützlich, da wir daran ablesen können, was sich in der Datenbank befindet. Allerdings können wir keine Cmdlets wie Get-Mailbox einsetzen, um Informationen über einzelne Postfächer in der Wiederherstellungsdatenbank abzurufen. Stattdessen müssen wir Restore-Mailbox verwenden, um die Postfächer in eine Onlinedatenbank zu verschieben, in der die Benutzer Zugriff auf die wiederhergestellten Daten haben.
545
Sicherung und Wiederherstellung
Wiederherstellung in einer Wiederherstellungsdatenbank
Kapitel 9
Sicherung und Wiederherstellung
Wiederherstellen der Postfachdaten Restore-Mailbox und das in SP1 neu eingeführte New-MailboxRestoreRequest sind bemerkenswerte Cmdlets, die Sie auf verschiedene Weisen einsetzen können, um ein Postfach aus einer Wiederherstellungsdatenbank mit einem Zielpostfach in einer anderen Datenbank zusammenzuführen. Das Zielpostfach muss mit einem Benutzerkonto verbunden sein, allerdings können Sie Daten aus einem Postfach in der Wiederherstellungsdatenbank in ein Postfach mit einem anderen Namen in der Zieldatenbank verschieben. Zusammenführen heißt, dass die Nachrichten, die bereits im Zielpostfach vorhanden sind, nicht überschrieben werden. Der Vorgang ist nicht destruktiv, sondern ergänzt nur. Wie viel Zeit erforderlich ist, um ein Postfach zu untersuchen und die Elemente wiederherzustellen, hängt von der Anzahl der enthaltenen Objekte, der Serverkonfiguration und der Systemlast ab, aber Sie können damit rechnen, dass mehrere hundert Elemente pro Minute verarbeitet werden. Exchange hält Sie während des Vorgangs über den Fortschritt auf dem Laufenden, wie Sie in Abbildung 9.12 sehen. Abbildg. 9.12
Wiederherstellen der Elemente in einem Postfach
Mit Restore-Mailbox haben Sie unter anderem folgende Möglichkeiten: 쐍 Wiederherstellung der Daten aller Postfächer aus der Wiederherstellungsdatenbank in einer Onlinedatenbank. Der folgende Befehl ruft eine Liste der Postfächer in der Datenbank DB3 ab und stellt alle Postfächer wieder her, die in der Wiederherstellungsdatenbank DB3 Recovery Database zu finden sind: Get-Mailbox –Database 'DB3' | Restore-Mailbox -RecoveryDatabase 'DB3 Recovery Database'
쐍 Wiederherstellung der Daten ausgewählter Postfächer aus der Wiederherstellungsdatenbank in einer Onlinedatenbank. Der folgende Beispielbefehl stellt den kompletten Inhalt des Postfachs für den Benutzer Simpson, David (Sales) aus der Wiederherstellungsdatenbank wieder her. Mit -Confirm: $False verhindern wir, dass Exchange uns um Bestätigung bittet, um fortzufahren, da wir davon ausgehen, dass wir wissen, was wir hier tun. Restore-Mailbox –Identity 'Simpson, David (Sales)' –RecoveryDatabase 'DB3 Recovery Database' –Confirm:$False
쐍 Wiederherstellung ausgewählter Daten einzelner Postfächer aus der Wiederherstellungsdatenbank in einer Onlinedatenbank. Nehmen wir beispielsweise an, Kim Akers teilt uns mit, dass sie mehrere Elemente gelöscht hat, die sie nicht mehr aus dem Papierkorb zurückgewinnen kann, aber nur an dem Element Confidential interessiert ist, das aus dem Posteingang entfernt wurde. Dieses eine Element können Sie mit folgendem Befehl wiederherstellen: Restore-Mailbox –Identity 'Akers, Kim' –RecoveryDatabase 'DB3 Recovery Database' –IncludeFolders '\Inbox' –SubjectKeywords 'Confidential' –Confirm:$False
546
쐍 Wiederherstellung ausgewählter Daten in einem neuen Ordner eines anderen Postfachs. Das ist eine nützliche Technik, um Informationen aus einer Sicherung wiederzugewinnen, die für eine Untersuchung benötigt werden, wenn sich die Daten nicht durch eine Discoverysuche finden lassen, da sie bereits abgelaufen sind und aus der Datenbank entfernt wurden. Im folgenden Beispiel suchen wir nach Informationen über ein Projekt namens »Athena« im Postfach von Kim Akes und exportieren alle gefundenen Elemente in den Wiederherstellungsordner im Postfach der Untersuchungsbeamten. Bei diesem Beispiel sind vor allem zwei Dinge bemerkenswert. Erstens sorgt der Parameter -ContentKeywords dafür, dass Exchange im Inhalt der Elemente und in den Anhängen sucht, was den Vorgang stark verlangsamen kann, wenn viele umfangreiche Anhänge zu durchsuchen sind. Zweitens können Sie zwar für den Parameter -Identiy jeden der üblichen Bezeichner für das Quellpostfach angeben (Alias, Name usw.), doch müssen Sie für den Parameter -RecoveryMailbox den Postfachnamen verwenden. Als Ergebnis der Suche wird ein Satz von Ordnern unter dem in dem Befehl angegebenen Stammordner ausgegeben. Außerdem werden der Name des Quellpostfachs sowie Datum und Uhrzeit der Wiederherstellung vermerkt. Abbildung 9.13 zeigt, wie die wiederhergestellten Elemente im Zielpostfach erscheinen. Restore-Mailbox –Identity 'Legal Investigators' –RecoveryDatabas 'DB3 Recovery Database'–SubjectKeywords 'Athena' –ContentKeywords 'Athena' –TargetFolder 'Recovered Data' –RecoveryMailbox 'Akers, Kim' –Confirm:$False Abbildg. 9.13
Wiederhergestellte Elemente in einem Zielpostfach
In allen Fällen erstellt Exchange zwei Protokolldateien mit Einzelheiten der von Restore-Mailbox durchgeführten Operationen, eine im Text- und eine im XML-Format. Beide Protokolle werden im Verzeichnis \Logging\MigrationLogs des Exchange-Stammverzeichnisses auf dem Server gespeichert, auf dem die Wiederherstellung stattfand. Das folgende Beispiel zeigt eine leicht bearbeitete Version der Textprotokolldatei:
547
Sicherung und Wiederherstellung
Wiederherstellung in einer Wiederherstellungsdatenbank
Kapitel 9
Sicherung und Wiederherstellung
[05/28/2010 11:39:19.0431] [0] Processing object "contoso.com/Exchange Users/Simpson, David (Sales)". [05/28/2010 11:39:19.0478] [0] Searching objects "DB3" of type "MailboxDatabase" under the root "$null". [05/28/2010 11:39:19.0509] [0] Searching objects "b9f054d2-896f-4207-a9e0-db1ef3120c52" of type "MailboxStatistics" under the root "DB3 Recovery Database". [05/28/2010 11:39:20.0274] [0] [DSimpson] The operation has started. [05/28/2010 11:39:20.0274] [0] [DSimpson] Approving object. [05/28/2010 11:39:20.0431] [0] [DSimpson] Opening source mailbox. [05/28/2010 11:39:20.0446] [0] [DSimpson] Trying to open mailbox by GUID: szServerLegacyDN: /o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXSERVER1 pguidMdb: {533F6963-BB02-493A-92CD-CE1783155B75} pguidMailbox: {B9F054D2-896F-4207-A9E0-DB1EF3120C52} szServer: EXSERVER1.contoso.com [05/28/2010 11:39:20.0446] [0] [DSimpson] Open mailbox succeeded. [05/28/2010 11:39:20.0446] [0] [DSimpson] Opening destination mailbox. [05/28/2010 11:39:20.0446] [0] [DSimpson] Trying to open mailbox by GUID: szServerLegacyDN: /o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXSERVER2 pguidMdb: {3EF66F70-347F-4B1E-97AD-73E9FF908D0E} pguidMailbox: {B9F054D2-896F-4207-A9E0-DB1EF3120C52} szServer: EXSERVER2.contoso.com [05/28/2010 11:39:20.0446] [0] [DSimpson] Open mailbox succeeded. [05/28/2010 11:39:20.0446] [0] [DSimpson] Moving messages. [05/28/2010 11:39:20.0446] [0] [DSimpson] Recovering messages. [05/28/2010 11:39:20.0446] [0] [DSimpson] Merging messages. [05/28/2010 11:40:27.0259] [0] [DSimpson] 0 items couldn't be moved to the target mailbox. [05/28/2010 11:40:27.0259] [0] [DSimpson] Messages moved. Closing connections. [05/28/2010 11:40:27.0337] [0] [DSimpson] The operation has finished.
In Exchange Server 2010 SP1 können Sie auch das Cmdlet New-MailboxRestoreRequest verwenden, um Postfachdaten aus getrennten Postfächern oder aus Postfächern in Wiederherstellungsdatenbanken wiederherzustellen. Dabei wird das asynchrone Anforderungsmodell genutzt, das auch beim Verschieben, Importieren und Exportieren von Postfächern durch den Postfachreplikationsdienst zum Einsatz kommt. Dieses neue Cmdlet wurde nötig, da es in SP1 möglich sein muss, Daten aus einem Postfach wiederherzustellen, das bei einem Verschiebungsvorgang nur »weich« gelöscht wurde. Außerdem können Sie mit ihm Daten aus Archivpostfächern wiedergewinnen. Aufgrund der asynchronen Vorgehensweise des Postfachreplikationsdienstes müssen Sie nicht auf die Wiederherstellung der Daten warten. Führen Sie einfach den Befehl aus, um eine Wiederherstellungsanforderung zu erstellen, und kümmern Sie sich dann um andere Dinge, während die Anforderung bearbeitet wird. Im folgenden Beispiel erstellen wir mit New-MailboxRestoreRequest eine Wiederherstellungsanforderung, um Daten aus dem Posteingangsordner im Postfach Akers, Kim der Datenbank DB3 Recovery Database zu lesen und in den Ordner für wiederhergestellte Elemente im Postfach Legal Investigators zu schreiben:
548
New-MailboxRestoreRequest –TargetMailbox 'Legal Investigators' –SourceDatabase 'DB3 RecoveryDatabase' –SourceStoreMailbox 'Akers, Kim' –BadItemLimit 5 –TargetRootFolder 'Recovered Items' –SourceRootFolder 'Inbox' -Name 'Legal Recovery Ref 104'
Das Ergebnis ist der Wiederherstellungsauftrag 'Legal Investigators'\Legal Recovery Ref 104, der in die Warteschlange des Postfachreplikationsdienstes gestellt wird. Den Fortschritt können Sie mithilfe des Cmdlets Get-MailboxRestoreRequest überprüfen: Get-MailboxRestoreRequest –Identity 'Legal Investigators'\Legal Recovery Ref 104'
Sobald der Auftrag abgeschlossen ist, können Sie sich das Ergebnis mit Get-MailboxRestoreRequestStatistics ansehen: Get-MailboxRestoreRequestStatistics –Identity 'Legal Investigators'\Legal Recovery Ref 104' | Format-List Name Status StatusDetail SyncStage Flags RequestStyle Direction Protect Suspend SourceExchangeGuid SourceRootFolder SourceVersion SourceDatabase MailboxRestoreFlags TargetAlias TargetIsArchive TargetExchangeGuid TargetRootFolder TargetVersion TargetDatabase TargetMailboxIdentity IncludeFolders ExcludeFolders ExcludeDumpster ConflictResolutionOption AssociatedMessagesCopyOption BadItemLimit BadItemsEncountered QueuedTimestamp StartTimestamp
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
Legal Recovery Ref 104 Completed Completed SyncFinished IntraOrg, Pull IntraOrg Pull False False d8f7a889-b430-4791-ad8c-360310f74b1c Inbox Version 14.1 (Build 218.5) DB3 Recovery Database Disabled, Recovery LegalInvestigators False 73d598ff-a7ce-4542-8740-b6509424f139 Recovered Data Version 14.1 (Build 218.5) DB3 contoso.com/Exchange Users/Legal Investigators {} {} False KeepSourceItem DoNotCopy 5 0 6/3/2010 10:08:16 PM 6/3/2010 10:08:20 PM
549
Sicherung und Wiederherstellung
Wiederherstellung in einer Wiederherstellungsdatenbank
Kapitel 9
Sicherung und Wiederherstellung
LastUpdateTimestamp CompletionTimestamp TotalQueuedDuration TotalInProgressDuration MRSServerName EstimatedTransferSize EstimatedTransferItemCount BytesTransferred ItemsTransferred PercentComplete
: : : : : : : : : :
6/3/2010 10:08:26 PM 6/3/2010 10:08:26 PM 00:00:04 00:00:05 ExServer1.contoso.com 2.414 MB (2,531,099 bytes) 62 2.881 MB (3,020,719 bytes) 62 100
Insidertipp: Aufräumen nach der Wiederherstellung
Es wäre unklug, eine Wiederherstellungsdatenbank an Ort und Stelle zu belassen, während sie mit Exchange verbunden ist oder während ihre Dateien auf der Festplatte zugänglich sind, sodass ein skrupelloser Administrator, der über die entsprechenden Berechtigungen verfügt, darauf zugreifen und sich den Inhalt der Postfächer darin ansehen kann. Nachdem Sie die erforderlichen Wiederherstellungsvorgänge ausgeführt haben, sollten Sie die Wiederherstellungsdatenbank daher entfernen und ihre Dateien von der Festplatte löschen. Gehen Sie dazu folgendermaßen vor: 1. Heben Sie die Bereitstellung der Wiederherstellungsdatenbank auf. Dismount-Database –Identity 'Sales Recovery Database' –Confirm:$False 2. Entfernen Sie die Wiederherstellungsdatenbank aus Exchange (mit der Exchange-Verwaltungs-
konsole oder -Verwaltungsshell). Remove-MailboxDatabase –Identity 'Sales Recovery Database' –Confirm:$False 3. Löschen Sie die Datenbankdateien aus dem Wiederherstellungsspeicherort.
New-MailboxRestoreRequest ist kein genaues Äquivalent zu Restore-Mailbox, denn ihm fehlen einige der Betreff- und Inhaltsfiltermöglichkeiten, die es möglich machen, bestimmte Daten aus einer Wiederherstellungsdatenbank herauszufischen. Mit den beiden Cmdlets können Sie sich entscheiden, ob Sie interaktiv oder im Hintergrund arbeiten wollen. Es ist jedoch wahrscheinlich, dass Microsoft die fehlenden Funktionen schließlich zu New-MailboxRestoreRequest hinzufügt, sodass Restore-Mailbox aufgegeben werden kann.
Vollständige Serversicherungen Der neue Schwerpunkt auf der Mobilität von Datenbanken und die Aufhebung der engen Bindung zwischen Datenbanken und Postfachservern hat auch Auswirkungen auf Sicherungen: 쐍 Die Sicherungen werden volumeweise vorgenommen. Alle Datenbanken und Transaktionsprotokolle, die es in einem Volume gibt, werden in die Sicherung aufgenommen.
550
쐍 Die Sicherungen dienen dazu, Datenbanken nach einem Festplatten- oder Serverausfall wiederherzustellen. Bei einem Serverausfall können Sie die Exchange-Konfigurationsdaten aus Active Directory wiedergewinnen, indem Sie das Exchange-Setupprogramm im Wiederherstellungsmodus ausführen (siehe Kapitel 2, »Installation von Microsoft Exchange Server 2010«). Anschließend müssen Sie dann in mehreren separaten Schritten die Daten auf dem Server wiederherstellen. Nur einer dieser Schritte betrifft jedoch die Wiederherstellung von Datenbanken. 쐍 Es gibt keinen »Systemstatus«, der in den Exchange-Sicherungen aufgezeichnet wird. Um auch die Windows-Konfiguration eines Servers zu sichern, müssen Sie zusätzliche Maßnahmen ergreifen. Auch für die anderen auf dem Exchange Server-Computer installierten Anwendungen müssen Sie eigene Sicherungsverfahren durchführen. 쐍 Was Exchange angeht, müssen die Sicherungen von Exchange Server-Computern, die nicht die Postfachrolle ausführen, lediglich die Konfigurationsdaten umfassen, die nicht in Active Directory festgehalten werden. Wenn Sie beispielsweise einige der OWA.asp-Dateien anpassen, müssen Sie Kopien davon anlegen, da diese Dateien bei der Wiederherstellung eines Clientzugriffsservers nicht berücksichtigt werden. Das Gleiche gilt auch für die Transportkonfigurationsdateien auf einem Hub-Transport-Server. HINWEIS Die offensichtliche Schwierigkeit, vor die Administratoren durch die Änderungen in Exchange Server 2010 und die neue Vorgehensweise von Windows Server-Sicherung gestellt werden, ist die Tatsache, dass es keine vorgefertigte Komplettlösung gibt, um einen gesamten Server mit einer einzigen, allumfassenden Operation zu sichern. Die Wiederherstellung eines Postfachservers mit Exchange Server 2010 erfordert daher eine andere Planung als bei den vorhergehenden Versionen. Wenn Konfigurationsdateien auf Hub-Transport- und Clientzugriffsservern geändert werden, so geschieht dies gewöhnlich nur einmalig. Die Konfigurationsdateien bleiben dann bis zur nächsten Softwareaktualisierung unberührt, weshalb es nicht notwendig ist, sie regelmäßig zu sichern. Allerdings müssen Sie eine Kopie aller geänderten Exchange-Konfigurationsdateien und jeglicher anderer manuell bearbeiteter Dateien erstellen und an einem sicheren Platz aufbewahren, um im Fall einer Serverwiederherstellung leicht darauf zugreifen können. Außerdem müssen Sie alle Änderungen, die Sie an Exchange-Dateien vornehmen, sorgfältig dokumentieren, damit auch andere Administratoren die Gründe für die Änderungen kennen und beurteilen können, ob es nach der Installation einer neuen Version, eines Service Packs oder einer Rollupaktualisierung nötig ist, diese Änderung erneut anzuwenden.
Clients Nachdem die Hardware eingerichtet ist und Exchange reibungslos läuft, können wir uns jetzt darum kümmern, wie die Clients die Infrastruktur ausnutzen. Wenden wir unseren Blick daher Outlook, Outlook Web App und den anderen Clients zu, die Verbindung mit Exchange aufnehmen können.
551
Sicherung und Wiederherstellung
Clients
Clients
Kapitel 10
Clients
In diesem Kapitel: Was geschieht mit Outlook?
555
Outlook Web App
570
Postfachrichtlinien und Segmentierung in OWA
592
POP3- und IMAP4-Clients
601
Exchange ActiveSync
608
Einschränken von Clients
624
Exchange Server 2010-APIs
632
Der zentrale Verbindungspunkt
635
553
Kapitel 10
Clients
Seit in Exchange 5.0 Webzugriff und POP3-Unterstützung (Post Office Protocol 3) eingeführt wurden, verfolgt Microsoft für Exchange eine Strategie des Zugriffs auf mehrere Clients. Der erste Browserclient wurde zu einer Zeit eingeführt, als die Anzahl unterstützter Clients stark begrenzt war und sich weitgehend um den vorhandenen »Fat Client« (den ursprünglichen MAPI-Viewer von Exchange [Messaging Application Programming Interface]) und Microsoft Outlook 97 drehte. Die Browserschnittstelle konnte zwar Verbindung zu Exchange aufnehmen, war aber langsam, lief nur in Internet Explorer, ließ sich wegen der Abhängigkeit von MAPI nicht skalieren und ermangelte einiger wichtiger Funktionen, bewies jedoch, dass eine webbasierte Schnittstelle funktionieren konnte, und schuf die Grundlage für einen Client, der mit jeder neuen Version beliebter wurde. Mit der Einführung von ActiveSync auf Serverbasis in Exchange Server 2003, das es Exchange ermöglichte, die steigende Nachfrage nach mobilem Zugriff auf Postfach-, Kalender- und Kontaktdaten zu befriedigen, errichtete Microsoft das dritte Standbein seiner Clientzugriffsstrategie. Das BlackBerry von RIM hatte dies natürlich schon einige Jahre zuvor getan, aber die Forderung nach mobilem Zugriff schien (zumindest für Exchange-Administratoren) berechtigter, als Microsoft ActiveSync bereitstellte. Außerdem wurde dadurch die Unterstützung mobiler Clients erheblich preisgünstiger, weil ActiveSync Bestandteil des Basisservers ist und keine teuren Softwarelizenzen oder zusätzliche Server benötigt werden. Trotz einiger Startschwierigkeiten und obwohl der Windows Mobile-Client hinsichtlich Einsatzfähigkeit und Funktionen weiter hinter seinen Konkurrenten zurücklag, trieb die starke Verzahnung von ActiveSync und Exchange in Verbindung mit dem unschlagbaren Preisargument (keine Zusatzkosten) die Bedeutung des mobilen Zugriffs für Exchange gewaltig voran. Die Clientzugriffsstrategie von Microsoft ermöglicht die Verbindung zahlreicher Clients mit Exchange Server 2010. Exchange Server 2010 unterstützt zahlreiche unterschiedliche Clientarten: 쐍 Die »Fat Clients« von Microsoft für Windows und den Mac von Apple aus der Office-Familie bieten einen breiten Funktionsumfang und zahlreiche Merkmale. Da Microsoft die Verbindung sehr alter Outlook-Versionen mit Exchange Server 2010 nicht unterstützt, müssen Sie mindestens Outlook 2003 bereitstellen, bevor Sie Verbindung mit Exchange Server 2010 aufnehmen können. Wollen Sie keine Clientsoftware von Microsoft kaufen, können Sie mithilfe der Protokolle IMAP4 oder POP3 eine Verbindung zu allen möglichen Clients herstellen, von einem kostenlosen Microsoft-Client (beispielsweise Windows Mail) bis hin zu einem Mobilgerät ohne ActiveSync. 쐍 Entscheiden Sie sich für OWA (Outlook Web App), können Sie eine ganze Reihe von Webbrowsern nutzen, von Internet Explorer bis Firefox, Safari und Chrome. Erwartungsgemäß bieten die Internet Explorer-Versionen 7 und 8 den größten Funktionsumfang, und die entsprechende Variante der Oberfläche (OWA Premium) können Sie auch in Firefox und Safari anzeigen. OWA Premium wird in Safari jedoch nur dargestellt, wenn der Browser unter Mac OS X von Apple läuft. Andere Browser, darunter Opera, können die abgespeckte oder Light-Version OWA Basic nutzen, die immer noch viel bietet, aber nicht ganz so schick ist wie die Premium-Ausgabe. Die vollständige Aufstellung der möglichen Browser für verschiedene Exchange-Versionen finden Sie unter http:// technet.microsoft.com/de-de/library/ff728623.aspx. 쐍 In der Vergangenheit konzentrierte sich die Strategie von Microsoft für mobile Clients auf die Zusammenarbeit des servergestützten ActiveSync mit Windows Mobile-Clients, auf denen Outlook Mobile läuft. Selbst heute benötigen Sie Windows Mobile 6.5 oder höher, damit Clients das aktuellste Erscheinungsbild bieten, jedoch können Sie auch die Outlook Mobile-Anwendung auf Windows Mobile 6.1 aktualisieren, um auf die erweiterten Funktionen zugreifen zu können, die Exchange Server 2010 bietet. Ich gehe davon aus, dass Mobile-Clients von Microsoft weiterhin hervorragend ausgestattete neue Versionen von Outlook Mobile bereitstellen. Der Antrieb, die Palette der verfügbaren ActiveSync-Clients zu erweitern, hat jedoch in den letzten Jahren zugenommen, und Microsoft konnte große Erfolge bei der Lizenzvergabe für ActiveSync an Firmen 554
verzeichnen, die mobile Clients und Anwendungen erstellen – von Apple über Google bis hin zu Nokia und Palm –, weshalb es nicht schwierig ist, geeignete Geräte zu finden. Häufig stehen Administratoren sogar vor dem Problem, die Anzahl der Gerätearten, die Verbindung zu Exchange Server aufnehmen können, zu beschränken. Wenn Sie zu den Millionen von E-MailNutzern in Firmen gehören, die auf ihr BlackBerry angewiesen sind, können Sie weiterhin mit der neuesten BES-Version (BlackBerry Enterprise Server) von RIM BlackBerry-Geräte mit Exchange Server 2010 verbinden (für die neuen, mit Exchange Server 2010 eingeführten APIs ist jedoch eine BES-Aktualisierung erforderlich). Interessant an der Clientzugriffsstrategie von Microsoft ist das Ausmaß der Verbesserungen an den Web- und Mobilplattformen in den letzten Versionen. Mit neuen APIs für Browser, allgemeiner Verfügbarkeit für ein breites Spektrum mobiler Geräte, intelligenterer Netzwerkfunktionen und harter Entwicklungsarbeit ist Microsoft an einen Punkt gelangt, an dem das Unternehmen glaubhaft behaupten kann, auf »drei Bildschirmen« geliefert zu haben.
Was geschieht mit Outlook? Die ewige Frage, die sich mit jeder neuen Exchange Server-Version stellt, lautet, was Sie mit Outlook machen sollen. Früher war die Beziehung zwischen Outlook und Exchange Server heikel. Aus welchen tieferen Gründen in der internen Firmenpolitik von Microsoft auch immer haben die beiden Produktgruppen nicht besonders gut zusammengearbeitet, und obwohl Exchange einfach der am besten funktionierende und leistungsfähigste Mailserver war, mit dem Outlook Verbindung aufnehmen konnte, schien der Schwerpunkt der Outlook-Entwicklungsgruppe erheblich stärker auf InternetMailservern zu liegen. Das war in mancher Hinsicht sogar verständlich, weil weitaus mehr Menschen Outlook als Teil der Office-Suite in Umgebungen ohne Exchange einsetzen (zu Hause, an der Hochschule und bei der Verbindung mit anderen E-Mail-Systemen, beispielsweise Google Mail und Lotus Notes), gleichzeitig aber auch rätselhaft, besonders weil die IMAP-Unterstützung von Outlook weniger gut zu sein scheint als die anderer Clients, zum Beispiel Thunderbird oder Eudora. Mit Outlook 2003 wurde es besser, nachdem Microsoft sich die Arbeit gemacht hatte, den Exchange-Cache-Modus einzuführen und zahlreiche Änderungen zur Verbesserung der Netzwerkansprüche von Outlook vorzunehmen. Der Exchange-Cache-Modus hat sich als grundlegend für Exchange erwiesen, weil der Vorstoß in Exchange-Onlinehostingdienste ohne ihn wesentlich schwieriger gewesen wäre. Außerdem muss man sagen, dass die Möglichkeit dieses Modus, Benutzer vor den Auswirkungen von Netzwerkausfällen zu schützen, die Arbeit mit Outlook wesentlich erleichtert hat. Weitere Verbesserungen kamen mit Outlook 2007, das gleichzeitig mit Exchange Server 2007 herauskam. Die beiden Produktgruppen schienen einen gemeinsamen Ansatz zur Lösung der Probleme von umfangreichen Bereitstellungen auf Unternehmensniveau zu verfolgen. Leider stellt die Veröffentlichung von Exchange Server 2010 eine Abweichung dar, weil Outlook 2010 erst einige Zeit nach Exchange Server 2010 erschien, was zwangsläufig die Frage aufkommen ließ, ob man besser wartet und die neueste Generation von Server und Client gleichzeitig bereitstellt oder mit Exchange vorprescht und Outlook später aktualisiert. Wie wir sehen werden, ist es nicht einfach eine Frage der Zeitplanung, weil einige Funktionen von Exchange Server 2010 auf Clientcode in Outlook 2010 angewiesen sind oder schlicht mit Outlook 2010 besser funktionieren. Die Beantwortung dieser Frage ist für kleine Firmen einfacher als für große. Das Gesetz der Zahlen führt dazu, dass sich eine wesentlich höhere Komplexität ergibt, wenn eine neue Anwendung auf einige zehntausend Rechner verteilt werden muss, und auch Fragen wie Benutzerschulung, Vorbereitung des internen Supportpersonals auf die Einführung sowie die Kosten neuer Softwarelizenzen und 555
Clients
Was geschieht mit Outlook?
Kapitel 10
Clients
möglicher Hardwareaktualisierungen sind zu berücksichtigen. Aus diesem Grund arbeiten so viele Unternehmen weiter mit Outlook 2003 oder noch älteren Clients, denn sie sehen keinen Sinn darin, eine Aktualisierung durchzuführen, die hohe Kosten für neue Lizenzen und die Bereitstellung mit sich bringt und gleichzeitig wenig offensichtlichen Gewinn in Form von Benutzerproduktivität, geringeren laufenden Kosten oder anderer Aspekte abwirft. Außerdem macht es auch der Umstand, dass die Clientzugriffslizenzen für Exchange Server keine Outlook-Lizenz mehr enthalten, den Firmen schwerer, eine frühe Aktualisierung zu rechtfertigen. Es besteht jedoch kein Zweifel, dass Outlook 2010 einige interessante neue Funktionen enthält. Ob sie ausreichen, um eine Aktualisierung in Erwägung zu ziehen, ist für jede Firma anderes zu beantworten. Als Diskussionseinstieg bietet Tabelle 10.1 einen Überblick über die Vorteile der einzelnen Outlook-Versionen, die Sie in Verbindung mit Exchange Server 2010 einsetzen können. Insidertipp: Die neue Funktion zur automatischen Zuordnung freigegebener Postfächer
Exchange Server 2010 SP1 enthält die Möglichkeit, freigegebene Postfächer in Outlook 2010-Clients automatisch zuzuordnen. Wenn Sie einem Postfach mithilfe des Assistenten der Exchange-Verwaltungskonsole oder des Cmdlets Add-Permission die Berechtigung Vollzugriff zuweisen, aktualisiert Exchange das Attribut MsExchDelegateListLink für das freigegebene Postfach mit dem definierten Namen des Postfachs, das das freigegebene öffnen darf. Bei der Verbindung mit Exchange empfängt Outlook 2010 in dem vom AutoErmittlungsdienst bereitgestellten Verzeichnis Angaben über das freigegebene Postfach und kann es unter dem Primärpostfach des Benutzers öffnen. Diese Funktion beseitigt ein häufiges Problem der Supportmitarbeiter, die Benutzern erklären müssen, wie sie Outlook-Profile konfigurieren müssen, damit sie freigegebene Postfächer enthalten. Sie steht und fällt jedoch mit dem Inhalt des Attributs MsExchDelegateListLink, und Berechtigungen, die vor der Bereitstellung von Exchange Server 2010 SP1 vergeben wurden, werden in diesem Attribut nicht widergespiegelt. Deshalb müssen Sie die Berechtigung Vollzugriff löschen und den freigegebenen Postfächern erneut zuweisen, bevor diese automatisch in Outlook erscheinen. Tabelle 10.1
556
Vergleich unterschiedlicher Outlook-Versionen Outlook-Version
Wesentliche Vorteile für Exchange Server
Outlook 2003
Einführung des Exchange-Cache-Modus und intelligentere Netzwerkfunktionen, um eine schnellere und effizientere Synchronisation von Serverordnern und lokalen Replikaten zu ermöglichen. Exchange Server 2010 erfordert Outlook 2003 SP 2.
Outlook 2007
Einführung der AutoErmittlung, um die automatische Konfiguration von Benutzerprofilen zu ermöglichen. Verzicht auf öffentliche Ordner als Ablage für gemeinsam genutzte Daten wie Frei/Gebucht-Informationen und das Offlineadressbuch und Bevorzugung einer webbasierten Verteilung. Erste Implementierung von verwalteten E-Mail- und Aufbewahrungsrichtlinien.
Outlook 2010
Die erste 64-Bit-Version von Outlook (auch für 32-Bit-Plattformen verfügbar). Ermöglicht die Anwendung von Funktionen wie E-Mail-Infos und Nachrichtenverfolgung aus Outlook heraus. Wesentlich weiter entwickelte und funktionsreichere Version der Richtlinien für die Messagingdatensatzverwaltung (Dokumentaufbewahrung). Ermöglicht die organisationsübergreifende Kalenderfreigabe, um Kunden beim Einsatz in gemischten lokalen und gehosteten Bereitstellungen zu helfen. Bietet die Unterhaltungsansicht von E-Mail-Threads (funktioniert auch mit älteren Exchange Server-Versionen) und die Möglichkeit, Threads zu ignorieren, die Sie nicht interessieren. Außerdem kann Outlook 2010 persönliche Archive auf Exchange Server 2010-Computern verarbeiten und zusätzlich zum Primärpostfach bis zu 15 weitere öffnen.
Outlook 2010 kann bis zu 15 Postfächer gleichzeitig öffnen, die nicht alle zur selben Exchange-Organisation gehören müssen. Standardmäßig beschränkt Outlook die Postfächer auf vier, eine willkürliche Grenze, um zu verhindern, dass Outlook umfangreiche Systemressourcen beansprucht, was der Fall wäre, wenn jemand versucht, zehn oder zwanzig Postfächer zu öffnen. Sie können die Grenze jedoch auf 15 hochsetzen, indem Sie den Wert HKCU\Software\Microsoft\Exchange\MaxNumExchange in der Systemregistrierung anpassen.
Fehlende Funktionen bei der Verwendung früherer Versionen von Outlook Outlook 2007 und Outlook 2003 nehmen bereitwillig Verbindung mit Exchange Server 2010 auf, doch da sie für frühere Exchange-Versionen entworfen und entwickelt wurden, enthalten sie nicht den Code, der für die Nutzung einiger Verbesserungen in Exchange Server 2010 erforderlich ist. Nachdem Sie Outlook 2007 mit Exchange Server 2010 verbunden haben, stehen Ihnen zum Beispiel folgende Funktionen nicht zur Verfügung: 쐍 Es ist keine Benutzerschnittstelle verfügbar, die die vom Server bereitgestellten E-Mail-Infos anzeigt. 쐍 Unterhaltungsansichten fehlen. Outlook versteht die internen Bezeichner nicht, mit denen Exchange verwandte Elemente zu einem Gespräch verknüpft. Die Fähigkeit, ein Gespräch zu bereinigen und veraltete Elemente zu löschen, fehlt genauso wie die Schaltfläche Ignorieren. 쐍 Die Integration mit der Exchange-Systemsteuerung für den Zugriff auf Gruppendaten, neuere Einstellungen für Unified Messaging (beispielsweise Regeln für die Aufrufbeantwortung) usw. fehlt. Es gibt jedoch immer noch die Möglichkeit, die Systemsteuerung zu öffnen und dann auf die betreffenden Optionen zuzugreifen. 쐍 Microsoft hat die Veröffentlichung von Code angekündigt, mit dem Outlook Verbindung zu persönlichen Archiven aufnehmen kann. Während ich dies schreibe, steht er jedoch noch nicht zur Verfügung. Outlook 2007 kann die Vorschau auf Voicemails als HTML-Text in Nachrichten darstellen, den Sprachinhalt jedoch nicht abspielen, wenn Sie in die Vorschau klicken. Auch geschützte Voicemails lassen sich in Outlook 2007 nicht verarbeiten. 쐍 SMS-Nachrichten lassen sich aus Outlook 2007 nicht versenden. 쐍 Es gibt keine Benutzerschnittstelle für Aufbewahrungstags und -richtlinien. Exchange wendet jedoch die Aktionen, die die Aufbewahrungsrichtlinien verlangen, auf Benutzerpostfächer an, auch wenn diese mit Outlook 2007 geöffnet werden. Wenn Clients mit Outlook 2003 SP 2 für die Verwendung verschlüsselter RPCs eingerichtet sind, können Sie Verbindung mit Exchange Server 2010 aufnehmen. Der Verzicht auf UDP-Verbindungen (User Datagram Protocol) in Exchange Server 2010 ist für Outlook 2003 jedoch problematisch. Outlook 2003 stützt sich für Benachrichtigungen über neue E-Mails und für die Aktualisierung von Ordnern in Benutzerpostfächern auf UDP-Pakete. UDP-Benachrichtigungen waren ein geeigneter Mechanismus für diese Arbeit, als Clients über ein Unternehmensnetzwerk (oder ein virtuelles privates Netzwerk) auf Postfächer zugreifen mussten, aber da die Anbindung inzwischen bevorzugt über das Internet erfolgt, sind sie nicht mehr von großem Nutzen. Outlook 2003 bietet als Reserve für den Fall, dass UDP nicht verfügbar ist, einen Abfragemechanismus. Er wurde für die ersten Outlook-Clients bereitgestellt, die mit RPC über HTTP Verbindung mit Exchange Server 2003 aufnahmen. Es entsteht jedoch eine Verzögerung von bis zu einer Minute, bis die UDP-Benachrichtigung fehlschlägt und die Abfrage endlich melden kann, dass eine neue Nachricht eingegangen ist. Das Problem kommt wegen des asynchro557
Clients
Was geschieht mit Outlook?
Kapitel 10
Clients
nen Charakters der Operationen weniger stark zum Tragen, wenn Outlook im Exchange-CacheModus ausgeführt wird, ist aber noch vorhanden. Obwohl eine Verbindung zwischen Clients mit Outlook 2003 SP 2 und Exchange Server 2010 möglich ist, könnten die Benutzer daher bemerken, dass Benachrichtigungen nicht so schnell erfolgen wie vorher. In der Reihenfolge ihrer Attraktivität stehen folgende Lösungsmöglichkeiten zur Verfügung: 1. Aktualisieren der Clients auf Outlook 2007 oder höher, um den Umweg über UDP zu beseitigen. 2. Neukonfigurieren von Outlook 2003-Clients im Onlinemodus, sodass sie im Exchange-Cache-
Modus ausgeführt werden (wird grundsätzlich empfohlen; dabei kommen auch zahlreiche andere Vorteile zum Tragen). 3. Ändern des Abrufintervalls, sodass die Benachrichtigungen schneller eingehen. Standardmäßig beträgt es bei Outlook 2003 60 Sekunden. Sie können es auf 10 Sekunden reduzieren (kleinere Werte werden ignoriert), indem Sie die Systemregistrierung auf Clientzugriffsservern aktualisieren, wie es auf http://technet.microsoft.com/de-de/library/aa996515(EXCHG.80).aspx beschrieben wird. Ein kürzeres Abfrageintervall führt jedoch zwangsläufig zu mehr Belastung für den Server, sodass Sie dies nicht ohne guten Grund tun sollten. Bei Outlook 2003 gibt es noch mehr Probleme, die diesen Client alles andere als optimal für Exchange Server 2010 machen. Die Exchange-Entwicklungsgruppe hat die meisten davon unter http:// msexchangeteam.com/archive/2010/04/23/454711.aspx beschrieben. Eine derart lange Liste potenzieller Probleme bedeutet nicht, dass Outlook 2003 schlecht wäre. Es war ein hervorragender Client, als es von Microsoft im Jahr 2003 veröffentlicht wurde. Wegen der Menge der Veränderungen, die seither an Datenbanken, Anbindung und Umgebungen vorgenommen wurden, ist Outlook 2003 nicht mehr so nützlich wie zuvor, und es ist wahrscheinlich an der Zeit, sich bei der Bereitstellung von Exchange Server 2010 mit der Aktualisierung auf einen neueren Client zu befassen. Insidertipp: Wie bedeutsam ist das UDP-Problem?
Das UDP-Problem oder ganz allgemein die Menge der Funktionen, die nur Clients mit Outlook 2010 zur Verfügung stehen, ist nicht lebenswichtig und reicht auch nicht aus, um eine Aktualisierung Tausender von Rechnern auf Outlook 2010 zu rechtfertigen. Andererseits unterstreicht diese Liste die enge Entwicklungsbeziehung zwischen Client und Server sowie den Umstand, dass Sie einen Client bereitstellen müssen, der sämtliche Funktionen des Servers zu nutzen versteht, wenn Sie dessen Möglichkeiten vollständig ausschöpfen wollen.
Warum scheinen neue E-Mail-Benachrichtigungen in Outlook langsamer zu erfolgen? Wie bereits erörtert, begann Outlook nach der Einführung von RPC über HTTP auf UDP-Benachrichtigungen zu verzichten. Outlook 2007 und 2010 verwenden asynchrone RPC-Benachrichtigungen, weil diese durch Firewalls hindurch funktionieren, was für UDP üblicherweise nicht gilt. Benachrichtigungen informieren Outlook darüber, dass eine Änderung eingetreten ist, beispielsweise, dass im Postfach auf dem Server, mit dem es verbunden ist, eine neue Nachricht eingetroffen ist. Einzelheiten der Änderungen muss Outlook trotzdem noch abrufen, um sie dem Benutzer anzeigen zu können, aber die Verarbeitung wäre wahrscheinlich ineffizient, wenn Outlook sofort tätig würde. Der Charakter von E-Mails bringt es mit sich, dass zu Spitzenzeiten mehrere Änderungen schnell nacheinander auftreten können. Morgendliche Sitzungen sind häufig durch hektische E-Mail-Aktivitäten gekennzeichnet, wenn die Benutzer anfangen zu arbeiten und ihre Posteingänge 558
bearbeiten, bevor sie sich an die übrigen Herausforderungen des Tages machen. Reagierte Outlook sofort auf eine Benachrichtigung, bestünde das Risiko, dass mehrere weitere neue Nachrichten eintreffen, während die erste verarbeitet wird, wodurch es zu einer Ping-Pong-Kommunikation mit dem Server gezwungen wäre. Es ist effizienter, Änderungen zu »stapeln« und dann auf einmal zu verarbeiten, was der Grund dafür ist, dass Sie gelegentlich mehrere neue Nachrichten gleichzeitig in Ihrem Posteingang erscheinen sehen, während andere Clients, beispielsweise Outlook auf einem Gerät mit Windows Mobile, den Eingang einzelner Nachrichten anzeigen. Wenn Outlook eine Benachrichtigung empfängt, startet es einen 5-Sekunden-Timer. Geht keine weitere Benachrichtigung ein, bevor der Timer abläuft, holt und verarbeitet es die Änderung. Andernfalls setzt Outlook den Timer neu und wartet wiederum. Wenn der zweite Timer abläuft, fasst Outlook die beiden Benachrichtigungen zusammen und verarbeitet sie in einer einzigen Operation. Werden jedoch ständig Änderungen festgestellt und der Timer immer wieder zurückgesetzt, wartet Outlook 60 Sekunden lang, damit sich alles auf dem Server beruhigt, ruft dann alles ab, was in der Warteschlange enthalten ist, und verarbeitet es. HINWEIS Dieser Mechanismus arbeitet wesentlich effizienter, was den Transport von Bytes über die Leitung und die Nutzung von Systemressourcen betrifft. Er vermeidet einen fortgesetzten Dialog zwischen Clients und Servern zu einer Zeit, zu der der Server ohnehin beschäftigt ist (weil er mit einer Menge neuer Nachrichten zu tun hat). Außerdem funktioniert er bei Netzwerken mit hoher Latenz gut und stellt eine geeignete Methode dar, mit den vorübergehenden Unterbrechungen fertig zu werden, die bei solchen Netzwerken häufig auftreten. Der Artikel auf http://technet.microsoft.com/de-de/library/cc179175.aspx beschreibt, wie Clients mit Outlook 2007 oder 2010 für den Exchange-Cache-Modus konfiguriert werden müssen. Unter anderem erfahren Sie hier, wie Sie das 5-Sekunden-Timerintervall und das 60-Sekunden-Intervall für gestapelte Änderungen ändern. Die Reduzierung des Timerintervalls auf etwa 2 Sekunden beschleunigt die Auslieferung neuer E-Mails, verbraucht jedoch mehr Systemressourcen für zusätzliche Synchronisierungsanforderungen. Wie bereits erwähnt, kann sich dies in Zeiten hoher Nachfrage negativ auswirken, weil Sie den Server zwingen, auf zusätzliche Synchronisierungsanforderungen von Clients zu reagieren. Daher lässt sich nicht entscheiden, ob es klug ist, hier eine Änderung vorzunehmen. Die einzigen, die wahrscheinlich merken, dass Outlook beim Ankündigen neuer Nachrichten ein wenig langsamer wird, sind jedenfalls (a) diejenigen, die über mehrere Geräte verfügen und das Eingehen einer neuen Nachricht auf den einzelnen Geräten messen können, und (b) Personen, die darauf bestehen, auf neue E-Mails innerhalb einer Nanosekunde nach ihrem Eingang zugreifen zu können. Meistens kommt es normalen Menschen darauf nicht an.
Schnellere Outlook Anywhere-Verbindungen Outlook-Clients nehmen die Verbindung mit Exchange über RPCs auf, die mittels TCP oder HTTP übertragen werden. Sie müssen HTTP nur selten in einer Umgebung nutzen, in der die Clients überwiegend über ein internes Netzwerk (zum Beispiel ein VPN) kommunizieren. Heute läuft jedoch eine zunehmende Anzahl von Verbindungen über das Internet, und zwar in einem Modus, der als Outlook Anywhere bezeichnet wird. Er eignet sich für Benutzer, die zu Hause oder an öffentlichen Orten über drahtlose Netzwerke verbunden sind. Umfasst eine Bereitstellung zahlreiche Clients mit Outlook Anywhere, können Sie Exchange so einrichten, dass Outlook 2010-Clients gezwungen werden, HTTP-Verbindungen zu probieren, bevor sie TCP verwenden. Das ist die Umkehrung der bisher geltenden
559
Clients
Was geschieht mit Outlook?
Kapitel 10
Clients
Norm, und ihr Wert besteht darin, dass sie die Notwendigkeit umgeht, vor der Verwendung von HTTP einen Verbindungsversuch von Outlook über TCP fehlschlagen zu lassen, was die Zeit verringert, die der Client braucht, bis die Verbindung steht. Mit dem folgenden Befehl machen Sie HTTP-Verbindungen zum Standard: Set-OutlookProvider EXPR -OutlookProviderFlags ServerExclusiveConnect
Er wirkt sich nur auf Outlook 2010-Clients aus. Clients mit Outlook 2003 oder 2007 arbeiten weiter wie zuvor. Und so nehmen Sie die Änderung zurück: Set-OutlookProvider EXPR -OutlookProviderFlags None
Unterhaltungsansichten Ältere E-Mail-Programme nahmen niemals den Text früherer Nachrichten in Antworten auf, weil es die Nachrichten zu umfangreich gemacht hätte, was in der Zeit von Einwahlverbindungen und teuren Festplatten eine Rolle spielte. Die Aufnahme aller früheren Antworten in Nachrichten wurde erst üblich, nachdem PC-Clients wie Microsoft Mail dies als »Feature« einführten. Heute ist es für die meisten E-Mail-Clients das Standardverhalten und eine Pest geworden. Gelegentlich ist es ja sinnvoll, um den Kontext einer Unterhaltung zu verstehen, aber normalerweise sind diese Informationen unerwünscht und unnötig und belegen jeden Tag Gigabytes, die gehandhabt und gesichert werden müssen. Die meisten E-Mail-Unterhaltungen führen zu einer Folge von Nachrichten, bei denen in jeder Antwort etwas Neues steht. Die Herausforderung besteht darin, die wertvollen Informationen zu erkennen, ohne mit dem übrigen Inhalt zugeschüttet zu werden, der aus den früheren Beiträgen stammt. Exchange Server 2010 (mit OWA) und Outlook 2010 lassen sich zu einer Lösung kombinieren, die als Unterhaltungsansichten bezeichnet wird. Ältere Outlook-Versionen geben Ihnen die Möglichkeit, auf den Betreff zu klicken und damit eine einfache Form von Unterhaltungsansichten zu erstellen, indem alle Nachrichten mit demselben Betreff zu einer Gruppe zusammengefasst werden. Schon früher hatte Microsoft auch individuellen Outlook-Code entwickelt (der meistens bei Microsoft intern genutzt wurde), um bessere Unterhaltungsansichten zu implementieren, der aber in keiner veröffentlichten Version erschien. Die neue Lösung komprimiert Unterhaltungen zu einer Ansicht, in der im Lesefenster der einmalige Inhalt jeder Nachricht angezeigt wird, wenn sie in der Unterhaltung ausgewählt wird. Dazu werden neue Algorithmen eingesetzt, die redundanten Inhalt erkennen und in der Ansicht für den Benutzer unterdrücken. Für die Entscheidung, welche Nachrichten zur aktuellen Unterhaltung gehören, nutzt Exchange folgende Nachrichteneigenschaften: 쐍 InternetMessageID 쐍 In-Reply-To 쐍 Referenzen 쐍 Betreffspräfix 쐍 Betreff in Normalform
560
Was geschieht mit Outlook?
Außerdem unterhält Exchange eine neue Gruppe unterhaltungsspezifischer Eigenschaften zur Verfolgung von Elementen in einer Unterhaltung: 쐍 Unterhaltungsthema Clients
쐍 Unterhaltungsindex 쐍 Unterhaltungsindexverfolgung 쐍 Unterhaltungsidentität Antworten Sie zum Beispiel auf eine Nachricht, weiß Exchange, dass die ursprüngliche Nachricht und die Antwort verknüpft und Bestandteil einer Unterhaltung sind, und hält dies fest, was bedeutet, dass die gesamte Unterhaltung als Ganzes betrachtet werden kann, solange die Elemente in einem Ordner des Postfachs vorhanden sind. Abbildung 10.1 zeigt eine Unterhaltung, die fünf Elemente umfasst, von denen sich eines im Ordner Gelöscht befindet (und durchgestrichen ist). Abbildg. 10.1
Eine Unterhaltung in Threadform in OWA
Insidertipp: Unterhaltungsansichten auf verschiedenen Plattformen
Die Umsetzung von Unterhaltungsansichten fällt je nach Plattform ein wenig anders aus, um deren verschiedenen Speicher- und Benutzerschnittstellenfähigkeiten Rechnung zu tragen. Outlook 2010 ist zum Beispiel in der Lage, Elemente, die in PSTs gespeichert sind, in Unterhaltungen einzubeziehen, und kann deshalb gut Unterhaltungsansichten erstellen, wenn es mit Servern verbunden ist, die nicht Exchange Server ausführen, zum Beispiel mit Gmail und Hotmail. OWA kann dagegen nur Elemente einbinden, die innerhalb eines Postfachs verfügbar sind (einschließlich des Archivpostfachs), Windows Mobile nur Elemente aus dem derzeit ausgewählten Ordner. Benutzerschnittstellenunterschiede zwischen verschiedenen Plattformen sind eine unausweichliche Tatsache des Computerlebens. Dies ist ein Grund dafür, dass Sie neue Plattformen unbedingt auf Gelegenheiten überprüfen sollten, die Benutzer zu verwirren, bevor Sie sie in die Produktion einbinden. Insidertipp: Die Umsetzung von Unterhaltungsansichten fällt je nach Plattform ein wenig anders aus
Ältere Elemente, die schon lange in Postfächern liegen, oder solche, die aus Nicht-Exchange-Systemen stammen, stellen für Unterhaltungsansichten eine Herausforderung dar, weil ihre Attribute möglicherweise nicht auf dieselbe Art gefüllt werden wie bei neu erstellten Elementen. Um das Problem zu beheben, ermittelt Exchange die Elemente, die eine Unterhaltung bilden, anhand des Nachrichtenbetreffs.
561
Kapitel 10
Clients
VORSICHT Gelegentlich kann diese Technik – Unterhaltungen anhand des Nachrichtenbetreffs zu verknüpfen – Elemente verbinden, die nicht zusammengehören, weil ihr Betreff identisch ist. Aus diesem Grund sollten Sie mit der Ignorierfunktion in Outlook vorsichtig umgehen, die ein ausgewähltes Element mitsamt den aktuellen und den zukünftigen Elementen derselben Unterhaltung in den Ordner Gelöscht verschiebt. Exchange versucht, Probleme aufgrund von älteren Nachrichten zu vermeiden, die denselben Betreff haben wie neuere, und nimmt dazu nur solche Nachrichten in eine Unterhaltung auf, die einen Höchstabstand von 72 Stunden zueinander aufweisen. Vorausgesetzt wird dabei, dass die Zugehörigkeit von Elementen auf der Grundlage des Betreffs mit der Zeit abnimmt. Ändern Sie den Betreff einer Nachricht, bevor Sie eine Antwort senden, eröffnen Sie tatsächlich eine neue Unterhaltung. Von dieser Regel gibt es eine Ausnahme, nämlich wenn eine Unterhaltung mit einer Nachricht ohne Betreff beginnt, bei der jemand später den Betreff aktualisiert. Outlook 2010 enthält zusätzlichen Code, mit dem sich Unterhaltungsansichten auch bei Verbindung mit älteren Exchange Server-Computern und Servern ohne Exchange erstellen lassen. Der Code funktioniert, muss aber ohne Hilfe vom Server auskommen und ist beim Verknüpfen von Elementen zu einer Unterhaltung daher langsamer und weniger akkurat als die Kombination von Exchange Server 2010 und Outlook 2010. Außerdem muss hier der Client sämtliche Aktionen für die Unterhaltung verarbeiten. Sie können beispielsweise beschließen, eine Unterhaltung zu »ignorieren«, was bedeutet, dass Outlook alle Nachrichten dieser Unterhaltung automatisch in den Ordner Gelöscht verschiebt. Ist Outlook 2010 mit einem älteren Exchange Server-Computer verbunden, muss es neue Elemente verarbeiten, sobald sie eintreffen, um zu entscheiden, ob sie zu der gerade ignorierten Unterhaltung gehören, und anschließend diejenigen unterdrücken, die es als dazugehörig erkannt hat. Um die Effizienz der Verarbeitung von Unterhaltungen zu steigern, speichert Exchange Server 2010 Details von Aktionen, die auf Unterhaltungen angewendet werden sollen, in dem verborgenen Ordner Conversation Action Settings. Der Vorteil liegt darin, dass die Daten nicht nur Outlook, sondern auch dem Server zur Verfügung stehen. Beschließen Sie, eine Unterhaltung zu ignorieren, verarbeitet Exchange neue Elemente also, sobald sie im Postfach eintreffen, und alle Clients sehen dasselbe. Da bei der Anwendung von Unterhaltungsansichten auf Ordner, die sich auf Servern ohne Exchange Server 2010 befinden, einige Einschränkungen bestehen, erlaubt Outlook 2010, Unterhaltungsansichten für ausgewählte oder alle Ordner zu unterdrücken. Wählen Sie im Menü Ansicht das Kontrollkästchen Als Unterhaltungen anzeigen. Anschließend fragt Outlook, ob Unterhaltungen nur für den gerade ausgewählten Ordner oder für alle Ordner unterdrückt werden sollen. Wenn Sie das Postfach später auf einen Exchange Server-Computer verschoben haben, können Sie dies rückgängig machen und Unterhaltungen erneut aktivieren (siehe Abbildung 10.2). Abbildg. 10.2
Aktivieren von Unterhaltungen in Outlook 2010
Outlook stellt keine Option bereit, mit der Benutzer wieder an einer Unterhaltung teilnehmen können, die sie ignoriert haben. Machen Sie also einen Fehler und entscheiden dann, dass die ignorierte Unterhaltung doch wichtig ist, können Sie die Aktion nur zurücknehmen, indem Sie ein Element dieser Unterhaltung im Ordner Gelöschte Elemente auswählen, es öffnen und dann auf die hervorgehobene 562
Was geschieht mit Outlook?
Schaltfläche Ignorieren klicken. Outlook fordert Sie dann auf, zu bestätigen, dass Sie das Ignorieren der Unterhaltung tatsächlich beenden wollen (siehe Abbildung 10.3). Klicken Sie auf Abweisen der Unterhaltung beenden, werden sämtliche Elemente der Unterhaltung zurück in den Posteingang verschoben. Die Option, mit der sich das Ignorieren einer Unterhaltung beenden lässt
Clients
Abbildg. 10.3
Insidertipp: Steuern der Größe von Unterhaltungen in Outlook 2010
Sie können die Ansicht erweitern, um den verborgenen Inhalt zu sehen, aber meistens wollen Sie nur das sehen, was neu ist. Outlook 2010 stellt auch die nützliche Option Unterhaltung bereinigen bereit, die redundante Elemente aus einem E-Mail-Thread entfernt. Damit können Sie ein wachsendes Postfach großartig unter Kontrolle behalten. Die Benutzeroptionen in Outlook 2010 und OWA zur Verarbeitung von Unterhaltungen sehen Sie in Abbildung 10.4. OWA bietet die Möglichkeit zum Aufräumen einer Unterhaltung nicht, sodass seine Optionen darauf beschränkt sind, wie Unterhaltungen in der Benutzerschnittstelle angezeigt werden. Mit Outlook 2010 können Sie steuern, welche Nachrichten aus Unterhaltungen entfernt und wohin sie verschoben werden. Außerdem bietet es eine ausführlichere Menge von Unterhaltungsansichten als OWA. Abbildg. 10.4
Optionen von Outlook (oben) und OWA (unten) zur Steuerung von Unterhaltungsansichten
563
Kapitel 10
Clients
Natürlich ist der Begriff der Unterhaltungsansichten nicht neu, und Sie fragen sich möglicherweise, warum Microsoft zwölf Jahre Entwicklung gebraucht hat, um ein so sinnvolles Merkmal umzusetzen, aber jetzt ist es ja verfügbar.
Konfliktlösung Die Synchronisierung von Elementen auf Clients und Servern führt gelegentlich zu unterschiedlichen Versionen an der einen oder anderen Stelle. Ein Benutzer arbeitet beispielsweise offline mit Outlook und ändert ein Element in der zwischengespeicherten Version seines Postfachs. Später stellt er mit OWA eine Onlineverbindung mit Exchange her, liest dasselbe Element erneut und geht daran, es wiederum zu ändern, beispielsweise, indem er ein Ereignis-Flag löscht. Anschließend verbindet er Outlook mit Exchange und synchronisiert die Daten. Es entsteht ein Konflikt, weil jetzt unterschiedliche Versionen desselben Elements bestehen. Dies ist ein etwas konstruiertes Beispiel, aber wegen der zahlreichen Methoden, mit denen Menschen mithilfe von Outlook, OWA, Windows Mobile-Geräten oder BlackBerrys auf Postfächer zugreifen, treten solche Konflikte ständig auf, besonders bei Kalenderelementen. Alle Outlook-Clients seit 2003 haben ein Konfliktlösungsmodul, das Konflikte automatisch beheben soll. Es beseitigt unechte Konflikte (zwei Versionen, die aber identisch sind) schnell, und bietet den Benutzern eine elegantere Schnittstelle, um Konflikte, die Benutzereingriffe erfordern, zu verfolgen und zu beseitigen. In solchen Fällen nutzt das Modul einen Algorithmus, um zu bestimmen, welche Version des Elements mit höherer Wahrscheinlichkeit beibehalten werden soll, und Outlook hebt diese im ursprünglichen Ordner auf. Die übrigen Versionen werden in den Ordner Konflikte verschoben, einen Unterordner des Ordners Synchronisierungsprobleme im Benutzerpostfach. HINWEIS Sie müssen auf die Verknüpfung Ordnerliste klicken, damit Outlook den Ordner Synchronisierungsprobleme anzeigt. Insidertipp: Die Ordner »Lokale Fehler« und »Serverfehler«
Der Ordner Lokale Fehler enthält Kopien von Elementen, die Outlook nicht mit dem Server synchronisieren konnte. Normalerweise hat ein vorübergehendes Problem den Fehler verursacht (etwa eine Netzwerkunterbrechung), und eine spätere Synchronisierung war erfolgreich. Der Ordner Serverfehler enthält Elemente, die Exchange nicht mit Outlook synchronisieren konnte. Wiederum ist die Fehlerursache meistens vorübergehend. Die Elemente, die Sie in den Ordnern Lokale Fehler und Serverfehler finden, können Sie löschen – ich tue es regelmäßig, um ein wenig Platz in meinem Postfach freizumachen. Finden Sie mehr als ein paar Elemente in den beiden Ordnern, spricht dies nicht für eine ordnungsgemäße Synchronisierung, sondern kann auf ein tiefer liegendes Problem hinweisen, das Sie beheben müssen. In einem solchen Fall können Sie die E-Mail-Protokollierung einschalten, indem Sie Extras\Optionen\Weitere und dann Erweitert wählen, um Outlook zu zwingen, ausführlichere Aufzeichnungen über Synchronisierungsoperationen vorzunehmen, die als Elemente im Ordner Synchronisierungsprobleme abgelegt werden. Beachten Sie, dass Sie Outlook neu starten müssen, bevor die detaillierte Protokollierung beginnt. Einige Daten, die Outlook protokolliert, helfen möglicherweise dabei, herauszufinden, warum Probleme auftreten, aber es ist wahrscheinlicher, dass ein Spezialist von Microsoft in der Lage ist, die Daten zu analysieren, weil sie zwar nützlich, aber auch ein wenig kryptisch sind.
564
Sie können den Inhalt von Synchronisierungsprobleme von Zeit zu Zeit überprüfen, um festzustellen, welche Elemente Outlook dorthin verschoben hat. Er hat drei Unterordner: Konflikte, Lokale Fehler und Serverfehler. Im Ordner Konflikte werden alle Elemente abgelegt, von denen Outlook meint, dass sie miteinander in Konflikt stehen. Sie können diese Elemente einzeln überprüfen und entscheiden, ob Sie lieber die Version im Ordner Konflikte behalten und die Version ersetzen wollen, die Outlook im Originalordner untergebracht hat, oder ob Sie die Version im Ordner Konflikte löschen, was eine sehr wirkungsvolle Methode ist, den Konflikt zu lösen. Alternativ können Sie die Konflikte unberührt lassen, es sei denn, Outlook fordert Sie beim Zugriff auf ein Element auf, einen Konflikt zu beheben. In diesem Fall zeigt Outlook im Nachrichtenkopf ein Konfliktlösungsband mit den Optionen an, die Sie haben. Sie können entscheiden, welche Versionen erhalten bleiben, und Outlook führt die entsprechende Aktualisierung durch.
Auflisten von Clientverbindungen Einzelheiten der Clients, die gerade mit einem Postfachserver verbunden sind, können Sie mit dem folgenden Befehl einsehen: Get-MailboxServer –Identity ServerName | Get-LogonStatistics | Format-List UserName, ApplicationId, ClientVersion
Die Ausgabe enthält Informationen folgender Art: UserName ClientVersion UserName ApplicationId ClientVersion UserName ApplicationId ClientVersion UserName
: : : : : : : : :
SystemMailbox{dc877527-83e9-4c13-a50c-b4beda917ce3} 3585.0.32903.3 Redmond, Eoin P. Client=OWA 3585.0.32903.3 Redmond, Eoin P. Client=WebServices;UserAgent=[NoUserAgent] 3585.0.32903.3 Clark, Molly (IT)
Einige der hier aufgeführten Verbindungen sind interne serverseitige Verbindungen, die Exchange erstellt hat (beispielsweise Verbindungen vom Speichertreiber, um Nachrichten in ein Postfach zu befördern), aber welche zu realen Benutzern gehören, lässt sich leicht feststellen. Sie können hier einige interessante Dinge ablesen: 쐍 Outlook-Benutzer werden mit dem Anwendungsbezeichner MSExchangeRPC angezeigt, also dem Wert für Verbindungen, die von der RPC-Clientzugriffsschicht gehandhabt werden. Jeder OutlookClient im Exchange-Cache-Modus erzeugt mindestens fünf Verbindungen. Vier davon werden von den Threads verwendet, die die »tröpfchenweise« Hintergrundsynchronisierung durchführen, um die Ordnerreplikate in der OST-Datei auf dem Client zu pflegen, die fünfte von dem Thread, der für das Senden von Nachrichten zuständig ist. 쐍 OWA-Benutzer verfügen über zwei Verbindungsarten. Die Verbindungen mit dem Bezeichner OWA dienen dazu, die Anbindung an den Server aufrechtzuerhalten, um Aufgaben wie das Auflisten des Ordnerinhalts oder das Lesen einer Nachricht auszuführen. Die als WebServices (Webdienste) angezeigten Verbindungen werden erstellt, um Nachrichten zu senden.
565
Clients
Was geschieht mit Outlook?
Kapitel 10
Clients
쐍 Exchange-Hintergrundaufgaben werden mit dem Namen des Postfachassistenten bezeichnet. Im vorstehenden Beispiel dient die Verbindung dem Kalenderassistenten, der Benutzer benachrichtigt, wenn Kalendertermine anstehen. 쐍 Verbindungen, die der Speichertreiber erstellt hat, um Nachrichten vom Transportsystem an Postfächer in einer Datenbank zu übermitteln, zeigen den Namen der Datenbank als Benutzernamen an. 쐍 Bei Exchange Server 2010 SP1 wird für alle Verbindungen dieselbe Clientversion angezeigt. Dies ist falsch, weil die Clientsoftware offensichtlich in zahlreichen unterschiedlichen Versionen vorliegt. Das Problem ist Microsoft bekannt und wird möglicherweise in einer zukünftigen Version behoben.
Blockieren von Clientverbindungen zu einem Postfach Exchange ermöglicht es, eine oder alle Clientverbindungsprotokolle einschließlich MAPI für jeden Benutzer einzeln zu deaktivieren. Dazu ändern Sie auf der Registerkarte Postfachfunktion (siehe Abbildung 10.5) die Angabe der Protokolle, auf die das Postfach zugreifen darf. Wenn Sie MAPI deaktivieren, kann der Benutzer nicht mit Outlook Verbindung zu seinem Postfach aufnehmen. Diese Option wird häufig für Postfächer gewählt, die ausschließlich OWA einsetzen und Outlook nicht benötigen. Abbildg. 10.5
MAPI-Zugriff für einen Benutzer deaktivieren
Das Cmdlet Set-CASMailbox verfügt über eine Anzahl von Parametern, mit denen sich steuern lässt, wie ein einzelnes Postfach mit MAPI Verbindung zu einem Postfach auf einem Exchange ServerComputer aufnehmen kann:
566
Was geschieht mit Outlook?
쐍 –MAPIBlockOutlookVersions Damit können Sie steuern, welche Outlook-Versionen Verbindung mit Exchange aufnehmen können. Mit dieser Einstellung können Sie Benutzer zwingen, auf eine modernere Version umzusteigen, beispielsweise Outlook 2007, weil diese Clients in der Lage sind, die Ressourcen des Servers effizient zu nutzen. Versucht ein Benutzer, eine blockierte Version von Outlook einzusetzen, wird die Fehlermeldung aus Abbildung 10.6 angezeigt. OutlookClients im Exchange-Cache-Modus können weiter offline arbeiten, aber erst dann Verbindung zum Server aufnehmen, wenn ein Administrator die Blockierung aufgehoben hat. Abbildg. 10.6
Ein Benutzer stellt fest, dass er mit dieser Outlook-Version keine Verbindung zu Exchange herstellen kann.
쐍 –MAPIBlockOutlookNonCachedMode Damit können Sie festlegen, ob Sie Outlook-Clients erlauben, im Onlinemodus Verbindung zum Server aufzunehmen. Setzen Sie diesen Parameter auf $True, um den Onlinezugriff zuzulassen, und auf $False, um Clients zu zwingen, im Cache-Modus Verbindung aufzunehmen. Ein wenig verwirrend ist es, dass Benutzer, die vom Onlinezugriff ausgeschlossen sind, ebenfalls die in Abbildung 10.6 gezeigte Meldung sehen, woraufhin eine weitere Fehlermeldung ihnen mitteilt, dass Outlook nicht in der Lage ist, ihre E-Mail-Standardordner zu öffnen. Wenn Benutzer ihr Problem melden, kann das die internen Supportmitarbeiter in die Irre führen, weil nicht darauf hingewiesen wird, den Exchange-Cache-Modus zu nutzen, sondern die Outlook-Version ins Spiel kommt. Microsoft bezeichnet Outlook-Builds nach dem System Hauptrelease, Nebenrelease, Buildnummer. Die Hauptreleasenummer ist für alle Office-Anwendungen gleich. Zur Office 12-Suite gehören Outlook 2007, Office 14 schließt Outlook 2010 ein usw. (Office 13 hat es nicht gegeben). Die Nebenreleasenummer besagt, ob es sich um den ursprünglichen RTM-Build handelt, um ein Service Pack oder eine Sammelaktualisierung, und die eigentliche Buildnummer wird täglich hochgesetzt, um Code und Korrekturen widerzuspiegeln, die Entwickler eingefügt haben. Die Buildbezeichnungen einiger neuer Outlook-Versionen lauten wie folgt: 쐍 Outlook 2007: 12.4518.1014 쐍 Outlook 2007 SP1: 12.6425.1000 쐍 Outlook 2010: 14.0.4760.1000 Um die Clientversion zu ermitteln, die im Parameter –MAPIBlockOutlookVersions anzugeben ist, können Sie die Option Hilfe\Info von Outlook benutzen oder die nützliche Liste der Clientversionen durchgehen, die Microsoft auf http://technet.microsoft.com/de-de/library/aa996848.aspx führt.
567
Clients
쐍 –MAPIBlockOutlookRpcHTTP Damit können Sie festlegen, ob Outlook-Clients Verbindungen mit RPC über HTTP über Outlook Anywhere aufbauen können. Wenn Sie den Parameter auf $True setzen, blockieren Sie den Zugriff mit RPC über HTTP, mit $False erlauben Sie ihn.
Kapitel 10
Clients
Der erste der beiden folgenden Beispielbefehle beschränkt den Zugriff so, dass der Benutzer Outlook 2003 oder höher einsetzen muss, der zweite erzwingt Outlook 2007 oder höher. In beiden Fällen ist Version 6.0.0 ausdrücklich zugelassen, um serverseitige MAPI-Verbindungen zu ermöglichen (Serververbindungen verwenden immer MAPI Version 6.0). Set-CASMailbox –Identity 'Akers, Kim' –MAPIBlockOutlookVersions '-6.0.0;10.0.0- 11.5603.0' Set-CASMailbox –Identity 'Akers, Kim' –MAPIBlockOutlookVersions '-6.0.0;10.0.0-12.4406.0'
Sie müssen bis zu 120 Minuten darauf warten, dass die zwischengespeicherten Daten über das Postfach aus dem Cache verschwinden. Alternativ können Sie den Informationsspeicherdienst neu starten, aber abgesehen von Testsituationen ist dies definitiv nicht der beste Ansatz, weil er auch alle anderen Postfächer betrifft, die mit dem Server verbunden sind. Mit dem Cmdlet Get-Mailbox können Sie die Eigenschaft ProtocolSettings der einzelnen Postfächer prüfen, um festzustellen, ob für irgendein Protokoll auf einem Server Einschränkungen vorliegen. Gibt es eine Einschränkung für eine bestimmte Clientversion, wird die Versionsnummer aufgeführt. Hat ein Administrator den MAPI-Zugriff für das Postfach vollständig deaktiviert, sehen Sie MAPI ohne Versionsnummer. Betrachten Sie das folgende Beispiel: Get-Mailbox –Server ExchServer1 | Where {$_.ProtocolSettings –ne $Null} | Select Name -------Redmond, Tony Ruth, Andy Smith, John
ProtocolSettings MAPIEnabled ---------------{MAPI§§§§-6.0.0;10.0.0-11.5603.0§§§§} {MAPI§0§§§§§§§} {OWA§1, IMAP4§0§§§§§§§§, POP3§0§§§§§...
Außerdem können Sie mit dem Cmdlet Get-CASMailbox MAPI-Blöcke suchen. Einerseits ist GetCASMailbox interessanter, weil es auch die Möglichkeit bietet, den Wert der Eigenschaft MAPIEnabled zurückzugeben (False, wenn der Benutzer komplett von MAPI ausgeschlossen ist) und die Details sämtlicher Protokolleinstellungen einzusehen, die für ein Postfach gesetzt werden können. Andererseits können Sie keinen Servernamen angeben, sodass Get-CASMailbox weniger effizient ist, weil es die gesamte Organisation durchgeht, wenn Sie den Bereich nicht mit einem serverseitigen Filter auf einen Server beschränken: Get-CASMailbox –Filter {ServerName –eq'ExchServer1'} | Where {$_.ProtocolSettings –ne $Null} | Select Name, ProtocolSettings, MapiEnabled Name -------Redmond, Tony Ruth, Andy Smith, John
ProtocolSettings ---------------{MAPI§§§§-6.0.0;10.0.0-... {MAPI§0§§§§§§§} {OWA§1, IMAP4§0§§§§§§§§...
MAPIEnabled --------------True False True
Sie können mit dem Cmdlet Set-CASMailbox nicht nur MAPI-Verbindungen blockieren, sondern auch den Clientzugriff auf andere Protokolle deaktivieren: 쐍 Den Zugriff auf POP3 deaktivieren Sie mit Set-CASMailbox –Identity Bond –PopEnabled $False. 쐍 Den Zugriff auf IMAP4 deaktivieren Sie mit Set-CASMailbox –Identity Bond –ImapEnabled $False. 쐍 Den Zugriff auf Outlook Web Access deaktivieren Sie mit Set-CASMailbox –Identity Bond –OWAEnabled $False.
568
Was geschieht mit Outlook?
Blockierungen einzelner Postfächer sind sinnvoll, aber gelegentlich möchten Sie den gesamten Zugriff auf einen Postfachserver sperren, etwa wenn Sie den Server mit einem Programm aktualisieren oder einen Patch einspielen wollen, ohne dass Benutzer den Server belasten oder gar die Aktualisierung stören. Eine solche Blockierung können Sie über die Exchange-Verwaltungsshell errichten, indem Sie alle Postfächer suchen, die in aktiven Datenbanken auf dem Server untergebracht sind, und mithilfe des Cmdlets Set-CASMailbox den MAPI-Zugriff deaktivieren. Es ist jedoch angenehmer, die Sperre zentral durchzuführen. In allen Versionen von Exchange Server 2000 bis Exchange Server 2007 können Sie die Verbindung von MAPI-Clients mit einem Postfachserver dadurch blockieren, dass Sie den Registrierungsschlüssel Disable MAPI Clients entsprechend einrichten. Er soll Administratoren ermöglichen, die Verwendung einer Mindestversion von Outlook zu verlangen. Anders ausgedrückt: Er hält Benutzer von dem Versuch ab, Verbindung mit früheren Versionen aufzunehmen, die möglicherweise nicht die Sicherheitsanforderungen Ihrer Firma erfüllen, weil das ältere Programm keine aktuellen Antispam- und Antivirenfunktionen wie das Blockieren von Beacons enthält. Der Registrierungsschlüssel wird auf einem Postfachserver gesetzt, sodass er nur dann wirksam werden kann, wenn dieser für die Handhabung von Clientverbindungen zuständig ist, was für Exchange Server 2000 bis Exchange Server 2007 gilt. In Exchange Server 2010 befasst sich jedoch die RPC-Clientzugriffsschicht, die auf Clientzugriffsservern ausgeführt wird, mit MAPI-Verbindungen, sodass die alte Methode mit dem Registrierungsschlüssel nicht mehr funktioniert. Da ein Clientzugriffsserver MAPIVerbindungen für mehrere Postfachserver handhaben kann, gibt es in Exchange Server 2010 auch keinen Mechanismus, der in einem einzigen Schritt MAPI-Verbindungen zu einem bestimmten Postfachserver blockiert. Sollte dies erforderlich sein, haben Sie zwei Möglichkeiten: 1. Sie verwenden das Cmdlet Set-RPCClientAccess, mit dem Sie alle MAPI-Verbindungen blockieren
können, die von bestimmten Versionen ausgehen. Der folgende Befehl blockiert beispielsweise den Zugriff auf alle Outlook-Versionen vor Outlook 2007 (Hauptrelease 12): Set-RPCClientAccess -Server ExCAS01 -BlockedClientVersions "0.0.0-5.65535.65535; 7.0.0-11.99999.99999"
Das Problem liegt darin, dass sämtliche Verbindungen zu allen Postfachservern blockiert werden, die der Clientzugriffsserver bedient. Das kann für kleine Standorte mit nur einem Clientzugriffsund einem Postfachserver gut funktionieren. 2. An größeren Standorten mit mehreren Clientzugriffs- und Postfachservern können Sie mit dem
Cmdlet Set-CASMailbox für alle Postfächer auf dem Server eine Sperre einrichten: Get-Mailbox –Server ExServer1 | Set-CASMailbox –MAPIBlockOutlookVersions '-6.0.0;10.0.0-12.4406.0'
Die RPC-Clientzugriffsschicht prüft, ob ein Client mit MAPI Verbindung aufnehmen kann, indem sie die mit den Cmdlets Set-RPCClientAccess and Set-CASMailbox gesetzten Server- und Postfachblockierungen ermittelt, bevor sie eine Verbindung vom Clientzugriffs- zum Postfachserver gestattet. Beide Mechanismen sind als Blockierung gleich wirkungsvoll. Die Entscheidung richtet sich deshalb danach, ob Sie alle Verbindungen sperren können, die durch einen Clientzugriffsserver laufen, ohne Rücksicht darauf, für welchen Postfachserver sie bestimmt sind, oder ob Sie nur Verbindungen zu einem bestimmten Postfachserver blockieren müssen.
569
Clients
Blockieren des Clientzugriffs auf einen Postfachserver
Kapitel 10
Clients
Betreiben Sie Postfachserver in einer Datenbankverfügbarkeitsgruppe, können Sie natürlich mithilfe des Skripts StartDAGServerMaintenance.ps1 (siehe Kapitel 8, »Exchange auf dem Weg zur Hochverfügbarkeit«) alle aktiven Postfächer von einem Server herunternehmen und die weitere Aktivierung blockieren. Damit bereiten Sie einen Postfachserver auf Wartungsvorgänge vor.
Outlook Web App Nach einem wackligen Start, als die Browserschnittstelle selbst mit großer Höflichkeit nur holprig und langsam genannt werden konnte, hat Microsoft viel Entwicklungsaufwand in OWA gesteckt, um einen Browserclient zu erstellen, der in seinem Funktionsumfang weitgehend an Outlook herankommt. Die Betonung liegt jedoch auf »weitgehend«, weil Outlook aufgrund seiner Schlüsselposition in der OfficeSuite und der für seine Entwicklung seit 1996 eingesetzten Ressourcen zahlreiche Vorteile hat. Gleichzeitig treiben andere Browserclients den Stand der Technik voran und fordern Microsoft bei jeder neuen Version heraus. Gmail ist vom klassischen ordnergestützten Schnittstellendesign zu Unterhaltungen als grundlegendem Prinzip gewechselt, Zimbra und andere webbasierte E-Mail-Anwendungen haben schwungvolle, gut gestaltete Oberflächen entwickelt, deren Benutzung ein Vergnügen ist, und selbst Microsofts eigene kostenlose Browserschnittstelle Hotmail wurde in den letzten Jahren einschneidend verbessert. Selbst beim besten Willen gibt es zwei wesentliche Gründe, aus denen OWA Outlook niemals vollständig entsprechen wird: 쐍 Es ist unwahrscheinlich, dass Microsoft die Entwicklung von Outlook beenden wird, weshalb es immer wieder neue Merkmale geben wird, bei denen OWA mit Outlook Schritt halten muss. Outlook 2010 setzt einen neuen Maßstab, an dem sich OWA 2010 messen lassen muss, und es gibt einige Stellen, an denen OWA ein Merkmal fehlt. Sie können beispielsweise keine Antwort erstellen und OWA automatisch den Text der Originalnachricht einfügen lassen, wie es in Outlook möglich ist. Outlook bietet mehr Sortieroptionen als OWA (zum Beispiel Sortierung nach Datum). OWA hat nicht die Fähigkeiten zur Verwaltung von Unterhaltungen wie Outlook 2010 und kann Aktionen wie Löschungen und Verschiebungen nicht auf dieselbe Weise rückgängig machen wie Outlook. Schließlich gibt es einige Browsereinschränkungen, mit denen OWA fertig werden muss. Beispielsweise ist es unmöglich, mehrere Anhänge in einem einzigen Vorgang im Dateisystem zu sichern. Sie müssen jeden Anhang einzeln speichern. 쐍 Es ist unwahrscheinlich, dass OWA die Fähigkeit von Outlook erreicht, offline zu arbeiten, es sei denn, Microsoft implementiert etwas Ähnliches wie Google Gears (mit dessen Hilfe Gmail und andere Google-Anwendungen offline arbeiten können). Interessanterweise hat Google im Februar 2010 bekannt gegeben, dass die Entwicklung von Gears gestoppt wurde, um sich darauf zu konzentrieren, die Fähigkeiten von Gears in eine Lösung auf der Grundlage von HTML 5 einzuarbeiten. Microsoft könnte sich natürlich an die Arbeit machen, eine ähnliche auf HTML 5 basierende Fähigkeit in Internet Explorer zu integrieren, um OWA die Offlinearbeit zu ermöglichen. Eine derartige Lösung würde natürlich in der Outlook-Entwicklungsgruppe nicht begrüßt werden, weil damit einer der wesentlichen Unterschiede zwischen den beiden Clients beseitigt würde. Ein weiterer Faktor, der berücksichtigt werden muss, ist die Tatsache, dass OWA und Outlook von unterschiedlichen Entwicklungsgruppen erarbeitet werden, die unterschiedlichem Druck von Seiten des Marktes unterliegen. OWA ist ein Exchange-Client und dient ausschließlich Exchange, steht Exchange also immer näher. Outlook dagegen gilt zwar als primärer Client für Exchange, aber nur deshalb, weil es den größten Funktionsumfang bietet. Es gehört zur Office-Suite und muss sich als
570
Outlook Web App
Vergleichen Sie die beiden Clients Merkmal für Merkmal, so entspricht OWA Outlook nicht vollständig, kommt ihm aber sehr nahe. Die Frage lautet, ob die fehlenden Merkmale den Benutzern wichtig sind und ob ihr Fehlen sie in ihrer Produktivität behindert. OWA 2010 ist in hohem Maße brauchbar und deckt den Bedarf der Mehrzahl seiner Benutzer. SP1 verbessert die Reaktionsfähigkeit von OWA durch Zwischenspeicherung und intelligentere Datennutzung und beseitigt die leichte Schwerfälligkeit, die einige Benutzer bei der RTM-Version erlebt haben. Trotzdem sollten sich Administratoren über die Dinge im klaren sein, die wir im nächsten Abschnitt behandeln.
Verbesserungen an OWA in Exchange Server 2010 Service Pack 1 Auch wenn kein Zweifel besteht, dass OWA in Exchange Server 2010 eine Verbesserung gegenüber der Vorgängerversion darstellt, hat Microsoft mit SP1 die Gelegenheit ergriffen, einige raue Kanten zu glätten und einige Funktionen hinzuzufügen. Teilweise beruht dies auf Rückmeldungen von Benutzern, nachdem Exchange Server 2010 in der Produktion eingesetzt wurde, teilweise einfach darauf, dass die Entwickler Zeit hatten, Funktionen für die Aufnahme in SP1 fertig zu stellen. Abbildung 10.7 zeigt die wichtigsten Merkmale der neuen OWA-Schnittstelle in Exchange Server 2010 SP1. Einige Unterschiede springen sofort ins Auge. Abbildg. 10.7
Die neue Benutzerschnittstelle von Outlook Web App, die mit Exchange Server 2010 SP1 eingeführt wurde
571
Clients
hochwertiger Client für andere E-Mail-Server wie Hotmail (mithilfe eines hervorragenden HotmailConnectors), Gmail und weitere Server über IMAP4 präsentieren. Outlook kann es sich nicht leisten, Exchange zu ignorieren, darf sich aber auch nicht zu stark auf Exchange ausrichten.
Kapitel 10
Clients
쐍 Es wurden wieder Designs eingeführt, die der Benutzer wählen kann. Mein persönlicher Favorit ist Katzen. (siehe Abbildung 10.7). Die in Exchange Server 2010 SP1 enthaltenen Designs bieten eine angemessene Anzahl Wahlmöglichkeiten, vom kühlen Arktis-Design bis zum Farbenrausch von Fingerfarben. Bei Cupcakes bin ich mir dagegen weniger sicher. Außerdem hilft Microsoft Kunden, die OWA mit Firmenlogos, -farben und -symbolen für sich anpassen wollen. 쐍 Die von OWA verwendeten Schriften sind größer, um die Informationen deutlicher darzustellen und leichter zugänglich zu machen. Das ausgewählte Element tritt stärker hervor und weist eine Markierung für seinen Status auf. 쐍 Die Navigation wurde durch die nach Ansicht der Schnittstellendesigner wirtschaftlichere Nutzung des Bildschirmfläche verbessert, die mehr Inhalt sichtbar macht. Weitere Verbesserungen bieten die Einführung einer Breadcrumb-Navigation, die den Benutzern zeigt, wo sie sich befinden und wie sie dorthin gekommen sind, sowie neu gestaltete Symbole für wichtige Optionen wie Antworten (Tests hatten gezeigt, dass Benutzer beim Beantworten von Nachrichten Fehler machten, und führten zu dieser Änderung). Einige überflüssige Elemente (beispielsweise das Exchange-Symbol oben im Postfach) wurden entfernt, um die Schnittstelle zu entrümpeln. 쐍 Popup-Fenster zur Benachrichtigung von Benutzern, beispielsweise über eine anstehende Besprechung, sind deutlicher hervorgehoben. Ein größeres Schriftbild lenkt die Aufmerksamkeit auf wesentliche Informationen – in diesem Fall ist der Termin drei Minuten überfällig. 쐍 Außerdem sind gängige Optionen einfacher erreichbar, etwa das Ändern von Kennwörtern, ohne in die Exchange-Systemsteuerung und wieder zurück wechseln zu müssen (siehe Abbildung 10.8). HINWEIS Auch wenn die Änderungen am OWA-Bildschirm auf den ersten Blick möglicherweise rein kosmetisch wirken, sind sie für PCs mit kleinen Bildschirmen wie etwa Netbooks von großer Bedeutung. Abbildg. 10.8
Leichterer Zugriff auf gängige Benutzeroptionen
Hinter den Kulissen hat Microsoft mehr Leistung aus OWA herausgeholt, um die Verarbeitung großer Ordner zu beschleunigen. Exchange Server 2010 ist zu »unendlichen« Ansichten übergegangen: Ordner mit mehreren tausend Elementen sollen durch den Vorabruf von Elementen beim Bildlauf besser verarbeitet werden. Damit wird das Bildlaufverfahren von Outlook simuliert, das alle Nachrichten in einer fortlaufenden Liste anzeigt anstatt wie OWA 2007 seitenweise. Die Bewegung durch Ansichten erfolgt jetzt schneller, besonders bei Unterhaltungsansichten. In SP1 liegt der Schwerpunkt bei der Leistung darauf, zur Aktualisierung von Ansichten Inhalte vorab abzurufen. In allen früheren OWAVersionen laufen Vorgänge wie das Löschen von Elementen oder das Markieren als gelesen gleichzeitig ab, und OWA wartet darauf, dass der Server ihren Abschluss bestätigt, bevor es die Ansicht aktualisiert.
572
Outlook Web App
HINWEIS An dieser Stelle besteht offensichtlich die Gefahr, dass ein Serverproblem eine Clientaktion ungültig machen kann, aber in der überwiegenden Mehrzahl der Fälle kommt es nicht so weit, sodass sich diese Abkürzung lohnt, die den Benutzer eine schnellere Verarbeitung wahrnehmen lässt. Außer den Designs, die der Benutzer auswählen kann, tauchen weitere zwischenzeitlich aufgegebene Merkmale in SP1 wieder auf, beispielsweise OWA-Webparts, die Möglichkeit, unterschiedliche Ansichten des Kalenders zu drucken (die merkwürdigerweise in Exchange Server 2010 fehlte) und die Option, das Lesefenster am unteren Bildschirmrand statt seitlich zu platzieren. Web-Ready Document Viewing verarbeitet jetzt in Internet Explorer, Firefox und Chrome unter Windows sowie Safari auf Mac auch Dokumente, die mit den Active Directory-Rechteverwaltungsdiensten (Active Directory Rights Management Services, AD RMS) geschützt wurden. Zahlreiche kleinere Fehler in bestimmten Browsern – etwa in Chrome die fehlenden Drag&Drop-Möglichkeiten zwischen Ordnern – wurden behoben, obwohl einige Einschränkungen fortbestehen, beispielsweise die Notwendigkeit, das optionale S/MIME-Steuerelement (Secure Multipurpose Internet Mail Extensions) zu laden, wenn man Anhänge in eine Nachricht ziehen und ablegen will. Da dieses Steuerelement nur in Internet Explorer funktioniert, folgt daraus, dass andere Browser diesen Trick nicht beherrschen. Insgesamt verfolgten die Microsoft-Entwickler das Ziel, eine Schnittstelle zu schaffen, die sowohl gut ausgestattet als auch einfach zu bedienen ist: Wichtige Funktionen befinden sich im Vordergrund und sind leicht zugänglich. Die Änderungen in SP1 bedeuten keine Überholung der OWA-Grundstruktur, die in Exchange Server 2010 erstellt wurde, sondern stellen eine Optimierung dar, um das wahre Potenzial der Anwendung auszuschöpfen.
In Exchange Server 2010 nicht mehr enthaltene OWA-Funktionen OWA 2010 schmückt sich mit einer attraktiven neuen Oberfläche und enthält zahlreiche neue Funktionen, die wir zu gegebener Zeit vorführen. Leider hat Microsoft eine Reihe von Merkmalen herausgenommen, die in früheren Versionen enthalten waren, weil die Entwicklungszeit nicht reichte, um sie auf Exchange Server 2010 umzustellen, weil sie nicht so oder nicht so oft genutzt wurden wie erwartet oder aus sonstigen Gründen, etwa Sicherheitsbedenken. Entfallen sind beispielsweise folgende Merkmale: 쐍 Webparts In Exchange Server 2003 und Exchange Server 2007 konnten Sie ein Webpart in einem URL angeben, um direkt darauf zuzugreifen. Sie konnten beispielsweise direkt zu einer bestimmten Ansicht eines Ordners in einem Benutzerpostfach wechseln, also etwa einen Benutzerkalender in der Wochenansicht öffnen. Dieses Merkmal erscheint möglicherweise in einem Service Pack für Exchange Server 2010 erneut. Weitere Informationen
Unter http://msexchangeteam.com/archive/2006/10/26/429362.aspx finden Sie eine ausführliche Beschreibung der Webparts in Exchange Server 2007.
573
Clients
In SP1 erfolgen die Aktionen asynchron und erscheinen wesentlich schneller, weil OWA die Ansicht aktualisiert, ohne auf eine Reaktion des Servers zu warten.
Kapitel 10
Clients
쐍 Dokumentzugriff Diese Funktion wurde mit Exchange Server 2007 eingeführt und erlaubte OWA-Benutzern den Zugriff auf Dokumente an einem SharePoint-Standort und auf Dateifreigaben über einen UNC-Zeiger. Wenn ein nun entfallenes OWA-Merkmal für Ihre Umgebung wichtig ist, sollten Sie dies über Ihr Microsoft-Kontoteam an das Exchange-Entwicklungsteam melden, damit es berücksichtigt werden kann, wenn Microsoft die Funktionsliste und das Pflichtenheft für ein zukünftiges Service Pack oder eine neue Version von Exchange aufstellt. Das Entwicklungsteam hört zu, wie die Liste der in SP1 wieder aufgenommenen Merkmale zeigt.
Unterschiedliche Browser, unterschiedliches Ergebnis OWA steht in zwei Versionen zur Verfügung: Premium und Light. Der Clientzugriffsserver entscheidet anhand des Werts der Zeichenfolge für den Benutzer-Agent, die der Browser bei der Verbindung mit Exchange übermittelt hat, welche Version er dem Client bereitstellt. Offiziell sagt Microsoft, dass Sie Internet Explorer 7 oder höher bzw. Firefox 3.0 oder höher auf einem unterstützten Betriebssystem benutzen müssen, wenn Sie die Premiumversion von OWA mit Exchange Server 2010 einsetzen wollen. Frühere Versionen von Internet Explorer und Firefox können die Premiumversion nicht nutzen und werden automatisch auf die Light-Version hinuntergestuft. Entsprechend können Sie OWA Premium in Verbindung mit Safari verwenden, aber nur, wenn es sich um Version 3 oder höher auf einem System mit der Version Leopard (10.5) oder Snow Leopard (10.6) von Mac OS X handelt. Andere Safari-Versionen, beispielsweise diejenigen, die unter Windows, auf dem iPad oder dem iPhone laufen, können nur die Light-Version von OWA anzeigen. Es mag merkwürdig wirken, dass ein Browser auf der einen Plattform die Premiumversion von OWA präsentieren kann, auf einer anderen jedoch nicht, aber zwischen den einzelnen Plattformen bestehen feine und weniger feine Darstellungsunterschiede. Microsoft muss entscheiden, wo es Ressourcen einsetzt, um eine bestimmte Browserkonfiguration zu entwickeln, zu testen und zu unterstützen, besonders dann, wenn das Unternehmen auf Entwicklungsgruppen anderer Firmen angewiesen ist, um von Kunden gemeldete Fehler zu beheben und Probleme zu lösen. Microsoft muss eine ausreichende Kundennachfrage sehen, um die erforderlichen Investitionen zu rechtfertigen – für die Erstentwicklung, damit ein Browser gut mit OWA Premium funktioniert, für die Tests und für die langfristige Unterstützung, um von Kunden gemeldete Probleme zu beseitigen und mit Softwareaktualisierungen des Browseranbieters Schritt zu halten. Gibt es diese Nachfrage nicht, dann geschieht eben nichts. Jeder Browser hat seine eigenen, einzigartigen Herausforderungen. Safari auf dem iPad ist der erste Vollbildbrowser auf einem Tablet-Gerät, der sich für die Eingabe ausschließlich auf eine virtuelle Tastatur stützt (wobei Sie selbstverständlich auch eine reale Tastatur an ein iPad anschließen können). Auf den in den Kategorien Stufe 1 und Stufe 2 in Tabelle 10.2 aufgeführten Kombinationen aus Browser und Betriebssystem läuft die Premiumversion von OWA. Ich nutze normalerweise den Google-Browser Chrome und OWA (siehe Abbildung 10.9). In diesem Screenshot sehen Sie die Chrome-Version 4.0.249.78 in Verbindung mit Exchange Server 2010 SP1 mit meinem Lieblingsdesign Katzen. Obwohl Microsoft Chrome für OWA nicht so gründlich testet wie Internet Explorer und obwohl Google dank seines iterativen Entwicklungsverfahrens regelmäßige Aktualisierungen für Chrome auf den Markt bringt, funktioniert alles reibungslos.
574
Outlook Web App
Microsoft-Unterstützung für Browser-Betriebssystem-Kombinationen Grad der Unterstützung durch Microsoft
Browser und Plattform
Stufe 1: Von der Produktgruppe vollständig getestet und unterstützt
Internet Explorer 7+: Windows XP, Vista, Windows 7, Windows Server 2003,
Clients
Tabelle 10.2
Windows Server 2008 Firefox 3+: Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, Mac OS 10.5 und höher Safari 3.1+: Mac OS 10.5 und höher Stufe 2: Unterstützt, aber mit eingeschränkten Tests
Firefox 3.0 auf Linux-Plattformen
Stufe 3: Unterstützt, aber nur mit OWA Light
Internet Explorer 6
Chrome unter Windows Vista und Windows 7 Safari unter Windows Andere Browser-Betriebssystem-Kombinationen (Opera, Safari für iPad usw.)
Abbildg. 10.9
Die Premiumversion von OWA im Browser Chrome
Die Rechtschreibprüfung zeigt weitere browserabhängige Funktionsunterschiede. OWA besitzt nur eine integrierte Rechtschreibprüfung für Internet Explorer, da Firefox, Safari und andere Browser eigene Funktionen für die Rechtschreibprüfung anbieten und es schwierig ist, dafür dieselbe Art Rechtschreibprüfung zu entwickeln wie für Internet Explorer, bei dem Microsoft die volle Kontrolle über die Schnittstelle besitzt. Außerdem muss man fairerweise sagen, dass Internet Explorer keine eigene Rechtschreibprüfung hat, weshalb Microsoft sie in OWA einfügen musste, um mit Outlook
575
Kapitel 10
Clients
Insidertipp: In Chrome nicht verfügbare OWA-Funktionen
Das einzige ständige Problem, das ich inChrome festgestellt habe, besteht darin, dass ich keine Elemente von einem Ordner in einen anderen ziehen kann. Chrome weigert sich stur, diesen Vorgang durchzuführen, lässt Sie aber ein Element in einen E-Mail-Entwurf ziehen und dort ablegen, um es als Anhang anzufügen. Im Vergleich dazu verschiebt Internet Explorer Elemente recht elegant von einem Ordner in einen anderen. Gelegentlich signalisiert Chrome keine Benachrichtigungen über neue E-Mails oder anstehende Termine, aber meistens funktioniert es. Ein wenig irritiert auch, dass anders als in Internet Explorer die Verfügbarkeitsinformationen für Benutzer nicht angezeigt werden, wenn Sie die globale Adressliste in Chrome durchgehen (siehe Abbildung 10.10). All dies zeigt, was »unterstützt, aber mit eingeschränkten Tests« in der Praxis bedeutet. Abbildg. 10.10 Sehen Sie den Unterschied! Chrome und Internet Explorer zeigen Details eines Benutzers
aus der globalen Adressliste an.
576
Outlook Web App
OWA Light soll in zahlreichen unterschiedlichen Browsern – von solchen, die Microsoft nicht testet (wie Opera) bis zu früheren Versionen derjenigen, die Microsoft testet (wie Firefox) – auf allen möglichen Geräten funktionieren – von Linux-Arbeitsstationen bis hin zu Laptops. Außerdem soll es sich an ein breites Spektrum von Bildschirmen anpassen, von Netbooks mit relativ niedriger Auflösung bis hin zu hochwertigen Arbeitsstationen. Aufgrund der uinterschiedlichen Fähigkeiten der verschiedenen Browser und Browserversionen hat Microsoft die »Intelligenz« in Form von Code wie JavaScript eingeschränkt, die OWA Light auf dem Browser ausführt. Dadurch ist sichergestellt, dass OWA Light mit hoher Wahrscheinlichkeit auf jedem Browser läuft, den Sie einsetzen, wenn auch mit Einschränkungen. Möglicherweise fällt Ihnen auf, dass Spaltenbreiten nicht automatisch an die Bildschirmauflösung angepasst werden. Unabhängig davon, welche Bildschirmgröße Sie einsetzen, beträgt die Breite der Absenderspalte immer 16 Zeichen (siehe Abbildung 10.11). OWA Premium enthält Logik zur Ermittlung von Bildschirmauflösung und Fensterbreite und passt die Spalten an, um je nach Konfiguration mehr oder weniger Informationen anzuzeigen. Abbildg. 10.11 OWA Light
gleichzuziehen. Unter Berücksichtigung aller Faktoren fürchtete Microsoft, die Benutzer zu verwirren, wenn sie zwischen der Rechtschreibprüfung des Browsers und einer für OWA wählen müssten. Deshalb deaktiviert OWA diese Funktion einschließlich der Option, Nachrichten vor dem Absenden zu prüfen, automatisch, wenn es in einem anderen Browser als Internet Explorer läuft.
577
Clients
OWA Light
Kapitel 10
Clients
Insidertipp: Mehrere Sitzungen
Moderne Browser können mehrere Registerkarten anzeigen, damit die Benutzer schnell zwischen verschiedenen Websites wechseln können. Wahrscheinlich erwarten Sie, dass Sie mit derselben Funktion mehrere Exchange-Verbindungen aufbauen und mehrere Postfächer öffnen können. Leider geht das nicht, weil Browser Verbindungen innerhalb eines Prozesses gemeinsam nutzen. OWA benötigt eine relativ hohe Anzahl von Verbindungen für Postfach- und Verzeichnisinformationen. Öffneten Sie mehrere Postfächer, wäre der Browser nicht mehr in der Lage, alle notwendigen Verbindungen aufrechtzuerhalten, und eine oder beide Sitzungen schlügen fehl, insbesondere in dem Mechanismus, der OWA mit neuen Informationen versorgt, weil die verschiedenen Sitzungen ihre Verbindungen gegenseitig blockieren. Als Notlösung erstellen Sie mit Datei\Neue Sitzung (Internet Explorer 8) bzw. Datei\Neues Fenster (Internet Explorer 7) eine vollkommen neue Sitzung mit eigenen Verbindungen. Sie können nicht in einer einzigen Browserinstanz mithilfe von Registerkarten zwischen Sitzungen wechseln, aber Sie können mit (Alt) + (Tab) zwischen den beiden Fenstern und damit zwischen den Sitzungen springen.
Die OWA-Konfigurationsdatei Exchange legt zahlreiche Konfigurationseinstellungen für OWA in Active Directory ab. Auf der Clientseite ist OWA eine ASP.NET-Anwendung mit einer weitere Gruppe von Einstellungen in der Anwendungskonfigurationsdatei Web.config.xml, die sich im Ordner \ClientAccess\OWA im ExchangeStammverzeichnis befindet. Diese Einstellungen wirken sich darauf aus, wie OWA in einem Browser ausgeführt wird. Sie können die Datei mit einem beliebigen Texteditor bearbeiten, solange Sie darauf achten, dass die XML-Syntax erhalten bleibt. Jeder Clientzugriffsserver besitzt eine eigene OWA-Konfigurationsdatei, sodass Sie die gewünschten Änderungen auf jedem einzeln vornehmen müssen. Außerdem sollten Sie die Einstellungen prüfen, nachdem Sie eine Rollupaktualisierung durchgeführt oder ein Service Pack für Exchange installiert haben, weil nicht garantiert ist, dass Microsoft die Konfigurationsdatei bei einer Aktualisierung nicht überschreibt. Manche Einstellungen steuert OWA auch mit Systemregistrierungseinträgen. Für Administratoren ist der Timeout-Wert wahrscheinlich der wichtigste davon. Es gibt zwei Werte: Der eine steuert, wie lange OWA ausgeführt wird, wenn sich der Benutzer auf einem öffentlichen Rechner anmeldet (oder bei der Verbindung mit OWA das Kontrollkästchen Öffentlich aktiviert), der andere den Ablauf privater Sitzungen. Diese Registrierungseinträge sehen aus wie folgt: Öffentlich (standardmäßig 15 Minuten) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA Name: PublicTimeout Type: DWORD
Privat (standardmäßig 8 Stunden [640 Minuten]) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA Name: PrivateTimeout Type: DWORD
578
Outlook Web App
Manche Benutzer legen gern Favoritenordner an, andere lassen die Standardstruktur, wie sie ist (Posteingang, Ungelesen, Postausgang). Benutzer der zweiten Kategorie wird es nicht stören, dass OWA 2010 mit den Outlook-Versionen vor 2010 nicht vollkommen kompatibel ist, was den Ordner Favoriten betrifft. Dies bedeutet, dass Sie in Outlook 2007 einen neuen Ordner Favoriten anlegen können, dieser aber in der von OWA angezeigten Ordnerliste möglicherweise nicht auftaucht. Ebenso können Sie in OWA 2010 einen neuen Ordner Favoriten anlegen, den Sie in Outlook 2007 nicht sehen. Noch merkwürdiger erscheint es, dass die Sortierreihenfolge in den Versionen anders ist, sodass eine Gruppe von Ordnern in OWA 2010 anders aufgeführt wird als in Outlook 2007. Das liegt daran, dass alle Outlook-Versionen vor 2010 Favoritendaten lokal ablegen, während Outlook 2010 sie im Benutzerpostfach auf dem Server speichert. Aus historischen Gründen bringen unterschiedliche Clients Benutzerdaten an sehr verschiedenen Stellen unter. MAPI-Profile liegen in der Systemregistrierung, während Outlook viele seiner Einstellungen in verborgenen Elementen im Stammordner eines Benutzerpostfachs ablegt, aber auch in Dateien wie dem Spitznamen-Speicher (.nk2). Da OWA für Browser gedacht ist, die auf vielen unterschiedlichen Rechnern laufen können, speichert es seine Einstellungen normalerweise im Stammverzeichnis des Benutzerpostfachs. Der Vorteil eines gemeinsamen Speicherorts für alle Clients liegt darin, dass sie dieselben Ordner in derselben Reihenfolge anzeigen. Solange Exchange Server 2010 zusammen mit älteren Clients eingesetzt wird, werden sich manche Benutzer jedoch fragen, wo der Ordner Favoriten abgeblieben ist. Ein weiterer Unterschied zwischen OWA und Outlook ist, dass OWA bestimmte Ordner nicht anzeigt, die es nicht benötigt, während Outlook dies tut. Der Ordner Postausgang wird zum Beispiel in OWA niemals benutzt, sodass die Premiumversion ihn in der Ordnerliste nicht aufführt (die Light-Version merkwürdigerweise doch). Dies beruht darauf, dass Sie mit OWA nicht auf dieselbe Weise verzögerte E-Mails versenden können wie mit Outlook, sodass es nicht notwendig ist, den Postausgang anzuzeigen (den Ort, an dem Exchange solche Nachrichten aufbewahrt).
Weiterleiten von Besprechungsanforderungen In Exchange Server 2007 gab es eine neue Funktion, die die Organisatoren von Besprechungen darüber informierte, wenn ein Teilnehmer die Besprechungsanforderung an einen anderen Empfänger weiterleitete. In Abbildung 10.12 sehen Sie ein typisches Beispiel einer solchen von der Kalenderautomatik erstellten Benachrichtigung. In diesem Fall geschieht der Organisation nichts Böses, wenn Einzelheiten einer Besprechung zur Feier eines Geburtstags an einen anderen Benutzer weitergeleitet werden, doch bei Besprechungen, in denen es um sensible Themen wie Budgets, Umorganisation und -strukturierung des Unternehmens und Pläne zur Einführung neuer Produkte geht, kann das anders sein. Möglicherweise ist es interessant, zu erfahren, dass jemand anders über eine von Ihnen angesetzte Besprechung informiert wurde, aber es kann auch irritieren, einen ganzen Stapel Benachrichtigungen zu bekommen, insbesondere, wenn Sie häufig Sitzungen mit zahlreichen Teilnehmern organisieren. Mit dem Cmdlet Set-CalendarProcessing können Sie Exchange die Benachrichtigungen für einzelne Postfächer automatisch löschen lassen.
579
Clients
Fehlende Favoriten
Kapitel 10
Clients
Abbildg. 10.12 So erfährt ein Benutzer, dass seine Besprechung weitergeleitet wurde
Auch mit OWA können Sie diese Benachrichtigungen automatisch löschen lassen, indem Sie im Abschnitt Automatische Verarbeitung der Kalenderoptionen das Kontrollkästchen Benachrichtigungen zu weitergeleiteten Besprechungen löschen aktivieren (siehe Abbildung 10.13). Diese Option steht in Outlook nicht zur Verfügung. Abbildg. 10.13 Die Option, Benachrichtigungen über weitergeleitete Besprechungen von Exchange automatisch
löschen zu lassen
580
Outlook Web App
Im folgenden Beispiel zwingen wir Exchange, alle Weiterleitungsbenachrichtigungen in den Ordner Gelöscht des angegebenen Benutzers zu verschieben.
Dasselbe ist auch mit Exchange Server 2007 möglich, aber dort müssen Sie das Cmdlet Set-MailboxCalendarSettings benutzen, das es in Exchange Server 2010 nicht mehr gibt. Außerdem können Sie Benachrichtigungen an externe Domänen unterdrücken, nachdem Besprechungen innerhalb Ihrer Organisation weitergeleitet wurden. Der folgende Befehl blockiert alle Weiterleitungsbenachrichtigungen an alle Domänen. Soll er nur für eine bestimmte Domäne gelten, übergeben Sie deren Bezeichner. Set-RemoteDomain -MeetingForwardNotificationEnabled $False
OWA-Webparts Webparts sind die verschiedenen Komponenten, aus denen OWA seine Benutzeroberfläche zusammenstellt. Die Möglichkeit, anderen Browseranwendungen einzelne Webparts zur Verfügung stellen zu können, ist sehr nützlich, da Sie durch Anwendungen unterschiedliche OWA-Funktionen darstellen können. Exchange Server 2010 hat diese Fähigkeit nicht, wohl aber SP1. Weitere Informationen
Die in Exchange Server 2010 verfügbaren Webparts und ihr Befehlsformat sind dieselben wie in Exchange Server 2007 OWA und werden unter http://technet.microsoft.com/de-de/library/bb232199 (EXCHG.80).aspx beschrieben. Der einzige Unterschied ist, dass der in Exchange Server 2007 für den im Webpart anzuzeigenden Ordner verwendete Parameter f in Exchange Server 2010 durch fpath ersetzt wird.
Lange Signaturen Bei einer Migration von Exchange Server 2003 ist in Ihrer Systemregistrierung möglicherweise der Wert SignatureMaxLength konfiguriert, um die Maximallänge von Signaturtext, den OWA auf ausgehende Nachrichten anwenden kann, von standardmäßig 4 KB auf bis zu 16 KB zu erhöhen. Diese Möglichkeit wurde oft von Firmen genutzt, die zum eigenen Schutz eine aussagekräftige Haftungsausschlussklausel mit mehreren Absätzen anhängen wollten. Exchange Server 2007 und Exchange Server 2010 haben die Standardgröße einer OWA-Signatur auf 8 KB erhöht, aber die Möglichkeit beseitigt, sie noch weiter zu vergrößern. OWA zeigt einen Fehler an, wenn Sie versuchen, mehr Text einzugeben, als in 8 KB passt (siehe Abbildung 10.14). Der Grund dafür, dass die Signaturgröße nicht mehr erhöht werden kann, liegt darin, dass es wesentlich sinnvoller ist, ausgehenden Nachrichten eine Haftungsausschlussklausel mithilfe einer Transportregel mitzugeben. Dabei ist garantiert, dass die Klausel angehängt wird, was nicht der Fall ist, wenn Sie die Benutzer auffordern, jeweils selbst eine Klausel zu erstellen. Am besten bitten Sie die Benutzer, den Text von Haftungsausschlussklauseln aus ihren Signaturen zu löschen und sich auf persönliche Informationen zu beschränken, die nicht in der mithilfe der Transportregel angehängten Klausel stehen. Da Transportregeln inzwischen Daten wie Namen, Telefonnummern und E-Mail-Adressen aus Active Directory abrufen und in eine Haftungsausschlussklausel aufnehmen können, ist der für Signaturen verbleibende Text auf Abteilungsspezifisches oder einen persönlichen »Spruch des Tages« beschränkt. 581
Clients
Set-CalendarProcessing –id 'EPR' –RemoveForwardedMeetingNotifications $True
Kapitel 10
Clients
Abbildg. 10.14 Probleme beim Einfügen einer sehr langen Haftungsausschlussklausel
Freigeben von Kalendern Es ist häufig notwendig, Kalender für Mitarbeiter freizugeben. OWA erlaubt Ihnen, Ihren Kalender für andere Benutzer freizugeben und deren Kalender in Ihre Ansicht einzufügen. Dazu schickt ein Benutzer den Personen, für die er seinen Kalender freigeben will, eine Einladung. Wechseln Sie zum Kalender, klicken Sie auf das Symbol Freigeben und wählen Sie Diesen Kalender freigeben. OWA erstellt eine Nachricht (der obere Teil von Abbildung 10.15), um die Empfänger zu informieren, dass Sie Ihren Kalender freigeben wollen. Insidertipp: Wie viel wollen Sie freigeben?
Wichtig ist dabei, wie viel Sie freigeben wollen. Die Optionen sehen wie folgt aus: Alle Informationen bedeutet, dass alles sichtbar ist, was Sie in Ihren Kalender eingetragen haben, außer den Dingen, die Sie als privat gekennzeichnet haben. Bei Frei/Gebucht-Informationen (einschließlich Betreff und Standort) sind die belegten Zeiträume in Ihrem Kalender und grundlegende Informationen über Ihre Tätigkeit zu sehen sind. Nur Frei/Gebucht-Informationen besagt, dass nur die belegten Zeiträume angezeigt werden, jedoch keine Hinweise darauf, ob Sie auf dem Golfplatz sind oder etwas Produktiveres tun. Außerdem können Sie umgekehrt Zugriff auf den Kalender Ihres Gegenübers anfordern.
582
Die untere Hälfte von Abbildung 10.15 zeigt eine Einladung, den Kalender einer anderen Person einzusehen. Der Text, der Sie anweist, bei microsoft.com eine Anleitung abzurufen, wie Sie freigegebene Ordner anzeigen, wird von Exchange automatisch eingefügt, ist aber ziemlich überflüssig, weil der Empfänger lediglich auf das Symbol Diesen Kalender hinzufügen zu klicken braucht, woraufhin OWA alles Weitere erledigt und den freigegebenen Kalender hinzufügt. Die OWA-Funktion zur Freigabe von Kalendern dient dazu, dass Benutzer die Kalender anderer Personen einsehen können. Deshalb weist Exchange dem Benutzer, für den Sie einen Kalender freigeben, die Berechtigung Reviewer zu. Sie gewährt Lesezugriff, erlaubt es aber nicht, Ereignisse zu aktualisieren oder neue hinzuzufügen. Diese Zugriffsstufe ist normalerweise für Benutzer wie Sekretäre der Geschäftsführung erforderlich. Exchange weist Berechtigungen mithilfe des Cmdlets Add-MailboxFolderPermission zu, aber in OWA gibt es keine Schnittstelle, um einem anderen Benutzer Schreibzugriff auf den Kalender zu gewähren. Ein Administrator kann jedoch mit dem Cmdlet Add-MailboxFolderPermission einem Benutzer die Berechtigung Editor zuweisen, um ihm Schreibzugriff zu geben, oder mit dem Cmdlet Set-MailboxFolderPermission einen Reviewer zum Editor befördern. Abbildg. 10.15 Kalenderfreigabe in OWA
583
Clients
Outlook Web App
Kapitel 10
Clients
Die folgenden Beispiele zeigen die Verwendung der Cmdlets. Der erste Befehl weist dem Benutzer »Pelton, David« die Berechtigung Editor für den Kalenderordner zu, der Kim Akers gehört. Der zweite erweitert die Berechtigung für denselben Kalender für einen anderen Benutzer. Add-MailboxFolderPermission -Identity 'Akers:\Calendar' -User 'Pelton, David' -AccessRights Editor Set-MailboxFolderPermission -Identity 'Akers:\Calendar' -User 'Smith' -AccessRights Editor
Sie können Ihrer Kalenderliste beliebig viele freigegebene Kalender hinzufügen. Computerbildschirme bieten jedoch nur begrenzten Platz, und es ist für Entwickler sehr kompliziert, sämtliche Informationen aus den Kalendern auf dem Bildschirm unterzubringen. Manche Benutzer führen OWA auf Geräten aus, deren Bildschirme nur eine geringe Auflösung von maximal 1024 x 768 bieten (denken Sie an ein niedrigpreisiges Notebook oder ein Netbook), und OWA muss sowohl mit dieser Situation als auch mit den übergroßen Bildschirmen zurechtkommen, die den halben Schreibtisch belegen. Irgendeinen Nachteil gibt es immer, und in diesem Fall ist es die Beschränkung auf die Anzeige von maximal fünf Kalendern (Ihres eigenen und vier weiterer). Versuchen Sie, einen weiteren hinzuzufügen, geraten Sie in die Situation, die in Abbildung 10.16 dargestellt wird. Es gibt keine Lösungsmöglichkeit und keinen Registrierungseintrag, der OWA zwingt, mehr Kalender auf den Bildschirm zu quetschen, selbst wenn die Auflösung dies zulässt. Sie müssen also entscheiden, welche Kalender die wichtigsten sind, und andere nur nach Bedarf anzeigen. Abbildg. 10.16 Anzeige mehrerer Kalender in OWA
584
Outlook Web App
Exchange Server 2010 SP1 führt die Möglichkeit ein, Kalender für Benutzer im Internet freizugeben oder zu veröffentlichen, was Exchange erlauben soll, dieselbe Funktion anzubieten wie andere webbasierte Kalendersoftware, etwa Google Calendar und Yahoo! Calendar. Diese Funktion nutzt die Arbeit, die in die Verbundfreigabe von Kalendern zwischen Exchange-Organisationen gesteckt wurde, berücksichtigt jedoch, dass das Ziel ganz anders aussieht. Die Freigabe von Kalendern stützt sich auf ein hohes Maß an Vertrauen unter den beteiligten Organisationen, während die Freigabe von Kalendern für Benutzer im Internet natürlich auf erheblich weniger engen Bindungen beruht, weil niemand das Internet verwaltet und überhaupt nicht vorgesehen ist, irgendeine Beglaubigung zu verlangen, um Kalenderdaten einzusehen, die ein Benutzer veröffentlicht hat. Andererseits fördert das Internet die Entwicklung und Umsetzung von Standardprotokollen für die Freigabe von Daten, in diesem Fall iCal oder iCalendar. Auch wenn Exchange-Benutzer ihre Kalender jetzt für Benutzer im Internet freigeben können, lautet das entscheidende Wort »können«. Die Freigabe erfolgt nicht automatisch. Exchange Server 2010 SP1 zieht nicht plötzlich die Jalousien hoch und veröffentlicht jeden Benutzerkalender möglichst großflächig, sondern die Administratoren müssen genau wie die Benutzer bewusst und planmäßig vorgehen, um zunächst die Bedingungen zu schaffen, unter denen eine Kalenderfreigabe möglich ist, und danach Entscheidungen treffen, für wen die Daten freigegeben werden und welches Maß an Transparenz und Zugriff gewährt wird. Die Grundlage für die Freigabe von Kalendern bildet das virtuelle Verzeichnis /calendar unterhalb von /owavdir. Um offene Freigaben mit einer möglichst großen Menge von Clients zu ermöglichen, gewährt dieses Verzeichnis den HTTP-Zugriff. HTTPS-Verbindungen werden nicht abgewiesen, aber Sie benötigen nur HTTP, um einen Kalender für einen Exchange-Benutzer freizugeben. HINWEIS Das virtuelle Kalenderverzeichnis wird von einem eigenen Anwendungspool bedient, um es von OWA-Operationen zu isolieren. Der Umstand, dass HTTP-Zugriff möglich ist, sollte also keine Bedenken auslösen, denn Hacker können nicht allein deshalb, weil sie an einen Benutzerkalender kommen, in OWA eindringen. Standardmäßig erlaubt Exchange Server 2010 keine Freigabe von Kalendern, sondern der Administrator muss Exchange entsprechend einrichten. Dazu sind folgende Schritte erforderlich: 1. Für das virtuelle OWA-Verzeichnis muss die Eigenschaft ExternalURL gesetzt werden, die übli-
cherweise etwa wie folgt aussieht: https://mail.contoso.com/owa. 2. Die Eigenschaft InternetWebProxy sämtlicher Postfachserver, auf denen Postfächer mit freizuge-
benden Kalendern untergebracht sind, muss auf den Namen des Clientzugriffsservers an dem mit dem Internet verbundenen Standort gesetzt werden, über den die Verbindungen geleitet werden: Set-ExchangeServer –Identity 'ExServer1' –InternetWebProxy 'http://ExCASInternet.contoso.com' 3. Die Eigenschaft CalendarPublishingEnabled des virtuellen OWA-Verzeichnisses auf dem Client-
zugriffsserver muss auf $True gesetzt sein: Set-OWAVirtualDirectory –Identity "ExServer1\owa (default web site)" –CalendarPublishingEnabled $True
585
Clients
Freigeben von Kalendern für Benutzer im Internet
Kapitel 10
Clients
4. Es muss eine Freigaberichtlinie erstellt werden, die anonymen Zugriff auf Kalender erlaubt. Dazu
können Sie die standardmäßige Freigaberichtlinie ändern oder eine neue erstellen und auf die Postfächer anwenden, die Kalender freigegeben dürfen sollen. In diesem Fall formulieren wir die vorgegebene Freigaberichtlinie so, dass sie Benutzern erlaubt, Frei/Gebucht-Informationen einschließlich Termindetails (Text des Terminelements) freizugeben. Set-SharingPolicy –Identity 'Default Sharing Policy' –Domains "Anonymous: CalendarSharingFreeBusyDetail"
HINWEIS Teilnehmerlisten oder Anhänge für Besprechungen werden niemals freigegeben. Freigaberichtlinien werden in Kapitel 5, »Exchange-Verwaltungskonsole und Exchange-Systemsteuerung«, ausführlicher behandelt. Wenn Sie eine neue Freigaberichtlinie erstellen, müssen Sie diese mit dem Cmdlet Set-Mailbox auf Postfächer anwenden: Set-Mailbox –Identity 'Redmond, Tony' –SharingPolicy 'Internet Calendar Sharing Policy'
Nachdem der Administrator Exchange Server für die Freigabe von Kalendern im Internet eingerichtet hat, können die Benutzer ihre Kalender mithilfe der Option Diesen Kalender veröffentlichen in OWA veröffentlichen. Outlook unterstützt diese Funktion nicht direkt, weshalb ein Benutzer, der seinen Kalender über Outlook für einen Internet-Gesprächspartner freigibt, an die Seite für die Webfreigabe umgeleitet wird, um sein Vorhaben auszuführen. Um Kalender für Benutzer im Internet verfügbar zu machen, ist folgender Vorgang erforderlich. Zunächst wählt der Benutzer die Option Diesen Kalender veröffentlichen aus. Das veranlasst OWA, ein Dialogfeld anzuzeigen, um Einzelheiten darüber abzufragen, wie der Kalender veröffentlicht werden soll. Der Benutzer kann Folgendes steuern: 쐍 Wie viele Einzelheiten zu Terminen veröffentlicht werden (es gibt die Optionen Nur Verfügbarkeit, Eingeschränkte Details und Alle Details). OWA gibt eine Warnung aus, wenn der Benutzer eine Option setzt, die nach der Freigaberichtlinie für sein Postfach nicht zulässig ist. 쐍 Wie viele Kalenderdaten veröffentlicht werden. Sie können zwischen einem Tag und einem Jahr vor und nach dem aktuellen Datum wählen. 쐍 Ob der Kalender eingeschränkt oder öffentlich sichtbar ist. Eingeschränkt sichtbare Kalender haben einen auf GUID-Basis verschleierten URL, der sich extrem schwer erraten lässt, zum Beispiel http://mail.contoso.com/owa/calendar/[email protected]/1f5d738 f17aa4700a6469aa9428556b916453351635198862711/calendar.html. Außerdem verbietet Exchange hierbei die Indizierung durch Suchmaschinen. Öffentliche Kalender bekommen URLs, die ziemlich unkompliziert sind und auf dem Alias des Benutzers aufbauen. Der Benutzer kann durch Ändern der Veröffentlichungseinstellungen für seinen Kalender zwischen eingeschränkter und vollständiger Veröffentlichung wechseln und außerdem die Veröffentlichung jederzeit beenden. 쐍 Wer über die Verfügbarkeit seines Kalenders informiert wird. Der Benutzer könnte warten, ob sein öffentlicher Kalender von Interessierten entdeckt wird, aber in den meisten Fällen wird er andere benachrichtigen wollen, dass sein Kalender im Internet zur Verfügung steht. OWA stellt die Option Links zu diesem Kalender senden bereit, die eine E-Mail für diesen Zweck erstellt. Darin sind zwei URLs enthalten: Der HTML-Link soll dem Empfänger im Internet erlauben, Einzelheiten Ihres Kalenders als einfache Webseite anzuzeigen, der ICS-Link (Internet Calendar Sharing)
586
Outlook Web App
Ein Administrator kann Kalendereinstellungen für ein Postfach auch mit dem Cmdlet Get-MailboxCalendarFolder abrufen und die Kalenderfreigabe mit dem Cmdlet Set-MailboxCalendarFolder einrichten. Um Kalendereinstellungen für mein Postfach abzufragen, benutze ich zum Beispiel den folgenden Befehl: Get-MailboxCalendarFolder –Identity 'TRedmond:\Calendar' Identity PublishEnabled PublishDateRangeFrom PublishDateRangeTo DetailLevel SearchableUrlEnabled PublishedCalendarUrl PublishedICalUrl IsValid
: : : : : : :
contoso.com/Exchange Users/Redmond, Tony:\calendar True ThreeMonths ThreeMonths LimitedDetails True http://mail.contoso.com/owa/calendar /[email protected]/Calendar/calendar.html : http://mail.contoso.com/owa/calendar /[email protected]/Calendar/calendar.ics : True
Um den Bereich der veröffentlichten Daten auf ein Jahr vor und nach dem aktuellen Datum zu ändern und meinen Kalender von öffentlich in eingeschränkt sichtbar umzuwandeln, kann ich folgenden Befehl einsetzen: Set-MailboxCalendarFolder –Identity 'Tredmond:\Calendar' –PublishDateRangeFrom 'OneYear' –PublishDateRangeTo 'OneYear' –SearchableUrlEnabled $False
Überschreiten des Postfachkontingents OWA zeigt oben in der Ordnerliste das verfügbare Speicherkontingent des Postfachs an. Sobald das Kontingent die Warnschwelle überschreitet, ändert sich die Anzeige und warnt den Benutzer, dass der Speicherplatz ausgeht (siehe Abbildung 10.17). Außerdem erhält er eine Nachricht von der Systemaufsicht, dass Elemente aus dem Postfach entfernt werden müssen, bevor weitere E-Mails verarbeitet werden können. Für das persönliche Archiv (falls vorhanden) gibt es eigene Speicherkontingente, aber OWA gibt keinen Hinweis darauf, wie viel Platz dort noch zur Verfügung steht. Abbildg. 10.17 OWA signalisiert, dass ein Postfach bald voll ist.
587
Clients
dient dazu, anderen die Möglichkeit zu geben, Ihren Kalender in eine Gruppe von Kalendern aufzunehmen, die sie häufig einsehen müssen (darunter vermutlich auch ihr eigener). Welche Funktion der ICS-Link genau in Gang setzt, hängt von der verwendeten Clientsoftware ab.
Kapitel 10
Clients
All dies entspricht weitgehend dem, was Sie von Exchange erwarten, wenn ein Postfach voll ist, und Sie können es den Benutzern überlassen, ihre Postfächer aufzuräumen, um Platz zu schaffen. Es gibt jedoch weitere Konsequenzen. Wenn kein Platz mehr verfügbar ist, kann Exchange Elemente im Postfach nicht aktualisieren – auch nicht die verborgenen Elemente, die die Postfacheinstellungen enthalten. Wechseln Sie beispielsweise zu den Optionen und versuchen, eine Einstellung zu aktualisieren, gibt OWA die Fehlermeldung in Abbildung 10.18 aus, sobald Sie die Postfacheinstellungen speichern wollen. Das Problem lässt sich lösen, indem Sie Platz im Postfach freimachen. Abbildg. 10.18 OWA kann ein Element nicht speichern.
Wie in Kapitel 6, »Verwalten von E-Mail-aktivierten Empfängern«, bereits erörtert, kann der Administrator stattdessen das Kontingent des betroffenen Postfachs erweitern. Da Exchange zur Leistungssteigerung Informationen über Postfacheinstellungen zwischenspeichert, kann es bis zu zwei Stunden dauern, bis das neue Kontingent akzeptiert wird. Sobald die Änderung wirksam ist, können die Benutzer in ihren Postfächern wieder Elemente erstellen und aktualisieren.
Umgang mit Anhängen Die Einstellung maxRequestLength in der OWA-Konfigurationsdatei Web.config.xml bestimmt, welche Datenmenge ein Client maximal auf einen Clientzugriffsserver hochladen kann. Der Standardwert lautet 30000 und ist in KB angegeben. In der Praxis bedeutet es, dass Sie einen 30-MB-Anhang in OWA hochladen oder eine Nachricht von 30 MB senden können (beispielsweise eine mit mehreren Anhängen, die zusammen 30 MB ergeben). Selbstverständlich ist die Fähigkeit, eine sehr große Datei anzuhängen, etwas ganz anderes als die Fähigkeit, sie zu senden, und andere Einschränkungen hinsichtlich der Organisation, der Connectors oder eines Postfachs können die Übermittlung trotzdem stören. Wenn Sie ein Dokument an eine Nachricht anhängen, öffnet OWA das Dialogfeld Dateien anhängen, das Sie in Abbildung 10.20 auf der linken Seite sehen. Es ist einigermaßen brauchbar, lässt sich jedoch in der SP1-Version von OWA verbessern, indem Sie die neueste Version der Microsoft-Entwicklungsplattform Silverlight auf den Clientcomputern installieren. Stellt OWA fest, dass Silverlight verfügbar ist, öffnet es das normale Dateidialogfeld Öffnen, das auch sonst unter Windows verwendet wird. Dieses Dialogfeld, das Sie rechts in Abbildung 10.20 sehen, ermöglicht Ihnen, ein Verzeichnis zu durchsuchen und mehrere Dateien auf einmal auszuwählen. (Hier habe ich einige Entwurfsdateien für dieses Buch ausgewählt.) Wegen seiner steigenden Beliebtheit bei Webentwicklern ist Silverlight mit einiger Wahrscheinlichkeit auf Clientcomputern installiert. Falls nicht, sollten Sie es in die Liste der Aktualisierungen aufnehmen, die Sie für die Bereitstellung auf Clients ins Auge fassen. Insidertipp: Umgang mit den Erwartungen der Benutzer
Abbildung 10.19 zeigt, wie Sie die OWA-Konfigurationsdatei mit dem Editor ändern. Hier ändern wir die maximale Dateigröße, die der Browser hochladen kann, auf 4800 oder 4,8 MB.
588
Outlook Web App
Insidertipp: Umgang mit den Erwartungen der Benutzer
Clients
Abbildg. 10.19 Bearbeiten der OWA-Konfigurationsdatei
Der Trick besteht darin, den Wert so zu wählen, dass er mit der von den Connectors unterstützten Maximalgröße übereinstimmt, sodass die Benutzer nicht in die Situation geraten, dass OWA ihnen erlaubt, eine Nachricht zu erstellen und hochzuladen, nur damit sie von einem Connector zurückgewiesen wird. Außerdem ist es wichtig, die Benutzer über die Begrenzung zu informieren, damit sie nicht überrascht sind, wenn sich OWA weigert, eine große Datei hochzuladen. Idealerweise sollte dies dann geschehen, wenn Sie den Benutzern erklären, wie sie Exchange sinnvoll nutzen können und wie groß die zu sendenden und zu empfangenden Nachrichten sein dürfen. Abbildg. 10.20 Die Änderung am OWA-Dialogfeld für Anhänge durch Silverlight
589
Kapitel 10
Clients
Designs und Anpassungen für OWA Ein Design legt fest, welches Farbschema und welche grafischen Elemente für OWA verwendet werden. Exchange Server 2007 ermöglicht die Anpassung des OWA-Erscheinungsbilds und liefert eine Anzahl verschiedener Designs, darunter solche, die auf Microsoft Zune- und Xbox-Produkten basieren. Sie können auch ein eigenes Design mit Ihrem Firmenlogo, eigenem Farbschema usw. erstellen. Die Auswahl eines Designs erfolgt über die OWA-Optionen. In Exchange Server 2010 werden Designs noch verwendet, aber die RTM-Version ermöglicht keine Designauswahl, sodass alle Benutzer dasselbe Standarddesign verwenden. Exchange Server 2010 SP1 behebt das Problem und bietet 27 Designs an, unter denen die Benutzer wählen können. Die Administratoren haben keine Kontrolle darüber und können einem Benutzer kein Design vorschreiben. Das Erstellen eines vollständigen Designs ist eine sehr umfangreiche Anpassung der OWA-Benutzerschnittstelle. Viele Unternehmen würden gern ihre Firmenidentität in OWA aufnehmen, aber ohne sich die Arbeit für ein Design zu machen. Da der vollständige Quellcode von OWA im Exchange-Paket enthalten ist, besteht die klassische Lösung für das Problem darin, einige der für das Standarddesign verwendeten Dateien anzupassen. Aufgrund der umfangreichen Änderungen, die Microsoft in Exchange Server 2010 an der OWA-Benutzeroberfläche vorgenommen hat, können Sie jedoch Anpassungen an den von Exchange Server 2007 benutzten Dateien nicht direkt auf ihre Exchange Server 2010-Gegenstücke übertragen, sondern müssen sie erneut entwickeln, indem Sie sie in die Bild- und CSS-Dateien (Cascading Style Sheets) von Exchange Server 2010 einarbeiten. Die gute Nachricht lautet, dass Microsoft die Anpassung der OWA-Anmeldeseite ermöglicht und in der Hilfedatei für Exchange Server 2010 dokumentiert, was dazu erforderlich ist. Die meisten Anpassungen gelten den OWA-Anmeldeseiten; um das Farbschema und die Logos an die Markengestaltung des Unternehmens anzupassen. TechNet widmet diesem Thema einen Abschnitt, der die von OWA verwendeten CSS- und Grafikdateien nennt und beschreibt, wie die Komponenten ineinandergreifen, um die für die Benutzer sichtbaren Seiten aufzubauen, und wie den einzelnen Textbereichen auf den Seiten Farben zugewiesen werden. In Abbildung 10.21 sehen Sie eine hilfreiche TechNet-Illustration mit den Grafikdateien, die OWA zu einem angepassten Anmeldedialogfeld zusammensetzt. Mithilfe dieser Informationen können Sie die für die Unternehmensidentität erforderlichen Änderungen vornehmen. Abbildg. 10.21 Komponenten zur Anpassung von OWA-Designs (Quelle: TechNet)
lgntopl.gif
lgntopr.gif
lgnleft.gif
lgnright.gif
lgnexlogo.gif lgnbotl.gif
590
lgnbotr.gif
Outlook Web App
Um neuen Text in den Anmeldebildschirm einzufügen, gehen Sie wie folgt vor: 1. Legen Sie eine Datei mit den Formatierungsanweisungen für den anzuzeigenden Text an. Sie kön-
nen sie beliebig benennen, solange Sie sie im Verzeichnis \Program Files\Microsoft\Exchange Server\ V14\Client Access Server\OWA\Auth ablegen. Nennen wir die Datei für diese Erläuterung contosodisclaimer.inc. 2. Kopieren Sie die Datei \Microsoft\Exchange Server\V14\Client Access Server\OWA\Auth\Logon.aspx. Sie enthält sämtliche Anweisungen, die OWA zum Anmelden eines Benutzers verwendet. 3. Öffnen Sie die Datei Logon.aspx mit einem Texteditor und suchen Sie die Zeichenfolge »mid tblConn«. Fügen Sie direkt darunter eine Zeile ein, die OWA anweist, den Text aus der in Schritt 1 erstellten Datei contoso-disclaimer.inc einzulesen und anzuzeigen. Anschließend sieht der Code in Logon.aspx etwa wie folgt aus: 4. Speichern Sie die Datei und starten Sie eine neue OWA-Sitzung (ohne die Internetinformations-
dienste oder einen Exchange-Dienst neu zu starten). Ihr Text sollte nun ähnlich wie der in Abbildung 10.22 aussehen. Abbildg. 10.22
Einfügen von eigenen Texten in den OWA-Anmeldebildschirm
5. Nach demselben Verfahren können Sie die Datei Logoff.aspx anpassen, wenn die Benutzer bei
ihrer Abmeldung von OWA eine firmeneigene Meldung sehen sollen.
591
Clients
Eine einfache Anpassung, die Sie in wenigen Minuten durchführen können, ist das Einfügen von Text in den OWA-Anmeldebildschirm. Damit soll den Benutzern üblicherweise ein Hinweis gegeben werden, wie sie bei Problemen Hilfe suchen sollen. Abbildung 10.22 zeigt, wie solcher Text erscheint, wenn sich ein Benutzer bei OWA anmeldet.
Kapitel 10
Clients
6. Sobald Sie mit der Anpassung zufrieden sind, können Sie sie auf alle Clientzugriffsserver anwen-
den, indem Sie die veränderten Dateien kopieren. Es gibt keinen automatischen Mechanismus, um Anpassungen dieser Art auf alle Clientzugriffsserver einer Organisation zu übertragen. Insidertipp: Anpassungen werden bei Produktaktualisierungen möglicherweise überschrieben
Denken Sie daran, dass alle Anpassungen an OWA-Komponenten von einer neuen Version in einem Service Pack, einem Hotfix oder einer Rollupaktualisierung der Komponente überschrieben werden können. Deshalb sollten Sie Anpassungen an OWA sorgfältig dokumentieren – damit Sie sie nach einer Exchange-Aktualisierung leichter wiederherstellen können. Außerdem sollten Sie eine Kopie der originalen und der angepassten Version aller Dateien aufbewahren, die Sie ändern, damit Sie sie später überprüfen können. Fairerweise muss man auch sagen, dass es keine Garantie dafür gibt, dass Microsoft nicht irgendwann die Funktionsweise von OWA ändert und diese Methode der Anpassung – oder irgendeine andere – damit unbrauchbar macht. Sehen Sie deshalb in jedem Bereitstellungsplan Zeit vor, um OWA-Anpassungen zu testen und ggf. umzuschreiben.
Postfachrichtlinien und Segmentierung in OWA Exchange Server 2010 bietet die Möglichkeit, OWA-Benutzern mithilfe von Richtlinien einen unterschiedlichen Funktionsumfang zuzuweisen. Es gibt zwar eine Standardrichtlinie für OWA, aber sie gilt tatsächlich erst dann, wenn Sie das Postfach explizit auswählen und die Richtlinie darauf anwenden. Der Zugriff auf OWA-Merkmale wird ansonsten durch die Segmentierungseigenschaften gesteuert, die auf jedem Clientzugriffsserver für das virtuelle OWA-Verzeichnis definiert sind (siehe Abbildung 10.23). In Exchange Server 2007 gab es noch keine OWA-Postfachrichtlinien, und die einzige Möglichkeit, den Funktionsumfang zu unterteilen, boten die Eigenschaften der OWA-Website. Das Problem dieses Ansatzes liegt darin, dass jede Änderung für alle Postfächer gilt, die mit dem betreffenden Clientzugriffsserver verbunden sind. Der Einsatz von Richtlinien erlaubt eine gezieltere Steuerung, weil Sie für einzelne Postfächer jeweils unterschiedliche Richtlinien anwenden können. Die OWA-Postfachrichtlinien segmentieren nicht nur die von OWA bereitgestellten Merkmale, sondern steuern auch einen Teil der benutzerdefinierten Einstellungen der Exchange-Systemsteuerung. Die einfachste Methode, eine OWA-Richtlinie, einschließlich der Standardrichtlinie, auf eine Gruppe von Postfächern anzuwenden, bietet das Cmdlet Set-CASMailbox. Der folgende Befehl ruft alle Postfächer ab, die zur Organisationseinheit Exchange Users gehören, und übergibt sie an Set-CASMailbox, um die OWA-Standardpostfachrichtlinie auf sie anzuwenden: Get-Mailbox –OrganizationalUnit 'Exchange Users' | Set-CASMailbox -OwaMailboxPolicy 'Default'
Die OWA-Standardrichtlinie kopiert üblicherweise die vorgefertigten Segmentierungseigenschaften der OWA-Standardwebsite, wie sie auf einem Clientzugriffsserver installiert sind, und gewährt Zugriff auf alle OWA-Merkmale einschließlich des Premium-Clients. Um eine neue Richtlinie zu erstellen, wechseln Sie in den Abschnitt Organisationskonfiguration der Exchange-Verwaltungskonsole, wählen Clientzugriff, wechseln auf die Registerkarte Outlook Web App-Postfachrichtlinien und wählen im Aktionsfeld Neue Outlook Web App-Postfachrichtlinie. Ein Assistent gibt Ihnen dann die
592
Postfachrichtlinien und Segmentierung in OWA
Gelegenheit, die Merkmale auszuwählen, auf die die Benutzer zugreifen dürfen (siehe Abbildung 10.24). Hier erstellen wir eine Richtlinie, die den Zugriff auf die Light-Version von OWA einschränkt, die ebenfalls selektiv einige OWA-Merkmale deaktiviert. Clients
Abbildg. 10.23 Die Segmentierungseigenschaften der OWA-Standardwebsite
Abbildg. 10.24 Erstellen einer neuen OWA-Postfachrichtlinie
593
Kapitel 10
Clients
Tabelle 10.3 listet auf, welche Merkmale Sie in einer OWA-Postfachrichtlinie steuern können. Einige davon stützen sich auf andere Komponenten (Textmessaging, öffentliche Ordner und Instant Messaging), andere erfordern einen sehr guten Grund für die Deaktivierung. Normalerweise ist es zum Beispiel nicht besonders sinnvoll, Kennwort ändern zu deaktivieren, weil die Erledigung von Benutzeranforderungen zum Ändern von Kennwörtern dem internen Support zusätzliche Arbeit macht. Tabelle 10.3
594
OWA-Merkmale, die sich durch OWA-Postfachrichtlinien steuern lassen Merkmal
Bedeutung
Erreichbar über
Exchange ActiveSyncIntegration
Wenn aktiviert, können Benutzer auf Eigenschaftender Mobilgeräte zugreifen, für die sie eine Synchronisierung durchgeführt haben. Dies schließt auch die Möglichkeit ein, Geräte bei Verlust zurückzusetzen und Protokolle mit Einzelheiten von Synchronisierungsvorgängen abzurufen. Wenn deaktiviert, ist die Option aus der Exchange-Systemsteuerung entfernt.
Exchange-Systemsteuerung
Alle Adresslisten
Wenn aktiviert, kann ein Benutzer alle definierten Adresslisten im Verzeichnis sehen. Wenn deaktiviertiert, sieht er nur die globale Adressliste.
OWA
Kalender
Wenn aktiviert, können die Benutzer auf die Kalenderanwendung zugreifen. Wenn deaktiviert, ist das Symbol aus OWA entfernt.
OWA
Kontakte
Wenn aktiviert, können die Benutzer auf die Kontaktanwendung zugreifen. Wenn deaktiviert, ist das Symbol aus OWA entfernt.
OWA
Journal
Wenn aktiviert, können Benutzer den Ordner Journal in ihrer Ordnerliste sehen. Wenn deaktiviert, verbirgt OWA den Ordner.
OWA
Junk-E-Mail-Filterung
Wenn aktiviert, können die Benutzer auf die Optionen zur Verarbeitung von Junk-E-Mails zugreifen, zum Beispiel auf Listen blockierter und sicherer Absender. Wenn deaktiviert, ist die Option aus der Exchange-Systemsteuerung entfernt.
Exchange-Systemsteuerung
Erinnerungen und Benachrichtigungen
Wenn aktiviert, versorgt OWA Benutzer mit Benachrichtigungen über neue Nachrichten, Erinnerungen an Besprechungen usw. Wenn deaktiviert, werden diese Benachrichtigungen unterdrückt.
OWA
Notizen
Wenn aktiviert, können Benutzer auf die Notizanwendung zugreifen. Wenn deaktiviert, ist das Symbol aus OWA entfernt.
OWA
Premium-Client
Wenn aktiviert, können die Benutzer den Premium-Client in einem dafür vorgesehenen Browser verwenden. Wenn deaktiviert, sind sie ohne Rücksicht darauf, welchen Browser sie einsetzen, gezwungen, den Standardclient zu verwenden.
OWA
Suchordner
Wenn aktiviert, können Benutzer auf von Outlook angelegte Suchordner zugreifen. Wenn deaktiviert, werden diese Ordner unterdrückt.
OWA
E-Mail-Signatur
Wenn aktiviert, können Benutzer auf die Option zugreifen, E-Mail-Signaturen anzulegen oder zu ändern und auf ausgehende Nachrichten anzuwenden. Wenn deaktiviert, ist die Option aus der Exchange-Systemsteuerung entfernt.
Exchange-Systemsteuerung
Postfachrichtlinien und Segmentierung in OWA
OWA-Merkmale, die sich durch OWA-Postfachrichtlinien steuern lassen (Fortsetzung) Merkmal
Bedeutung
Erreichbar über
Rechtschreibprüfung
Wenn aktiviert, können Benutzer den Inhalt von Nachrichten auf korrekte Rechtschreibung prüfen. Wenn deaktiviert, ist die Option aus OWA entfernt. Selbst wenn aktiviert, können Benutzer ihr Rechtschreibwörterbuch nicht anpassen.
OWA
Aufgaben
Wenn aktiviert, können Benutzer in OWA Aufgaben erstellen und verwalten. Wenn deaktiviert, ist die Option unterdrückt.
OWA
Designauswahl
Wenn aktiviert, können Benutzer ein anderes als das Standarddesign auswählen und es auf OWA und die Exchange-Systemsteuerung anwenden. Wenn deaktiviert, ist die Option unterdrückt.
OWA/ExchangeSystemsteuerung
Unified MessagingIntegration
Ist dieses Merkmal aktiviert und das Postfach für UM aktiviert, können Benutzer über die Systemsteuerung auf ihre UMEinstellungen zugreifen und sie verwalten. Wenn deaktiviert, ist die Option entfernt.
Exchange-Systemsteuerung
Kennwort ändern
Wenn aktiviert, können Benutzer ihr Kontokennwort von OWA aus ändern. Wenn deaktiviert, fordert OWA Benutzer nicht zur Änderung auf, wenn sich das Kennwort dem Ablaufdatum nähert (Aufforderungen beginnen 14 Tage vorher). Auch die Option zur Kennwortänderung in der Exchange-Systemsteuerung ist dann nicht sichtbar.
OWA/ExchangeSystemsteuerung
Regeln
Wenn aktiviert, können Benutzer über die Exchange-Systemsteuerung Regeln erstellen und ändern. Wenn deaktiviert, ist die Option unterdrückt. Alle mit Outlook erstellten Regeln werden von Exchange Server trotzdem beachtet.
Exchange-Systemsteuerung
Öffentliche Ordner
Wenn aktiviert, können Benutzer auf öffentliche Ordner zugreifen und mit ihnen arbeiten. Wenn deaktiviert, ist das Symbol aus OWA entfernt.
OWA
S/MIME
Wenn aktiviert, können Benutzer das optionale S/MIMESteuerelement herunterladen und dazu benutzen, Nachrichten mit digitalen Signaturen zu versehen und zu verschlüsseln. Wenn deaktiviert, können sie keine als opak signierten oder verschlüsselten Meldungen erstellen oder lesen. In Klartext signierte Nachrichten können gelesen (aber nicht geschrieben) werden, und die digitalen Signaturen der Nachricht werden nicht geprüft. Außerdem ist die Option, das S/MIME-Steuerelement herunterzuladen, aus der Exchange-Systemsteuerung entfernt.
OWA/ExchangeSystemsteuerung
Gelöschte Elemente wiederherstellen
Wenn aktiviert, können Benutzer gelöschte Elemente wiederherstellen. Wenn nicht, ist dies mit OWA nicht möglich. Exchange bewahrt die Elemente aber weiter im Papierkorb auf.
OWA
Instant Messaging
Wenn aktiviert und wenn IM verfügbar ist, können Benutzer aus OWA heraus auf IM-Funktionen einschließlich der Anzeige von Anwesenheitsinformationen zugreifen. Wenn deaktiviert, stehen diese Funktionen nicht zur Verfügung.
OWA
Textnachrichten
Wenn aktiviert, können Benutzer aus OWA heraus Textnachrichten (SMS) senden. Wenn deaktiviert, wird das Merkmal entfernt.
OWA
Clients
Tabelle 10.3
595
Kapitel 10
Clients
Eine neue Richtlinie lässt sich auch mit der Exchange-Verwaltungsshell erstellen. Aus irgendeinem Grund besteht dieser Vorgang aus zwei Schritten. Zuerst erstellen Sie die Richtlinie mit dem Cmdlet New-OWAMailboxPolicy, und dann definieren Sie mit dem Cmdlet Set-OWAMailboxPolicy, welche Merkmale aktiviert bzw. deaktiviert sein sollen. Die folgende Beispielrichtlinie erlaubt Benutzern, den Premium-Client zu verwenden, deaktiviert aber einige der eher unüblichen Funktionen: New-OWAMailboxPolicy -Name 'Limited OWA features' Set-OWAMailboxPolicy -Identity 'Limited OWA features' -ActiveSyncIntegrationEnabled $True -AllAddressListsEnabled $True -CalendarEnabled $True -ContactsEnabled $True -JournalEnabled $True -JunkEmailEnabled $True -RemindersAndNotificationsEnabled $True -NotesEnabled $True -PremiumClientEnabled $True -SearchFoldersEnabled $False -SignaturesEnabled $True -SpellCheckerEnabled $True -TasksEnabled $True -ThemeSelectionEnabled $False -UMIntegrationEnabled $False -ChangePasswordEnabled $True -RulesEnabled $True -PublicFoldersEnabled $False -SMimeEnabled $True -RecoverDeletedItemsEnabled $True -InstantMessagingEnabled $False -TextMessagingEnabled $False
Mehr als nur eine Segmentierung Obwohl OWA-Postfachrichtlinien meistens zur Segmentierung von Funktionen eingesetzt werden und diesem Zweck die größte Aufmerksamkeit gilt, können Sie damit auch andere Aspekte der Arbeit in OWA steuern. Nachdem Sie eine neue Richtlinie erstellt haben, können Sie verschiedene Regeln für den Zugriff auf Dateien und das Herunterladen definieren, je nachdem, ob OWA auf privaten oder öffentlichen Computern ausgeführt wird. Klicken Sie auf die Richtlinie, mit der Sie arbeiten wollen, und wählen Sie Eigenschaften. Anschließend können Sie auf die Eigenschaften zugreifen, die die Segmentierung steuern, sowie auf zwei weitere Registerkarten für Dateizugriff auf öffentlichne Computern und Dateizugriff auf privaten Computern (siehe Abbildung 10.25). Abbildg. 10.25 Dateizugriffsoptionen der OWA-Richtlinie
596
HINWEIS In diesem Zusammenhang beziehen sich »öffentlich« und »privat« auf den Zugriffsmodus, den der Benutzer beim Start von OWA gewählt hat, und geben an, ob der Browser auf einem öffentlichen Computer, etwa einem Kioskcomputer, oder auf einem privaten, etwa seinem eigenen Laptop, ausgeführt wird. Mit den Einstellungen für den direkten Dateizugriff (siehe Abbildung 10.26) können Sie steuern, wie die Benutzer bestimmte Dateitypen über OWA öffnen. Die Standardoption erlaubt sowohl für private als auch für öffentliche Computer den Direktzugriff, was bedeutet, dass Benutzer Dateien öffnen können. Jedoch werden nicht alle Dateitypen gleich behandelt, da es einige gibt, die ein Infektionsrisiko mit sich bringen, weil sie von Hackern, die in den Computer eindringen wollen, häufig als Angriffswege verwendet werden. Dateien werden deshalb in vier Gruppen unterteilt: 쐍 Immer zulassen Diese Dateien gelten als unschädlich und lassen sich auf dem Clientcomputer gefahrlos öffnen. Darunter fallen Typen wie Word-Dokumente (Erweiterungen .doc und .docx) und Windows-Bitmaps (Erweiterung .bmp), die mit einiger Sicherheit keinen Schadcode enthalten. 쐍 Immer blockieren Diese Dateien bergen für einen Computer ein erhebliches Risiko, wenn sie von einem Benutzer geöffnet werden, weil sie ausführbaren Code enthalten. Dazu gehören Typen wie Windows-Batchdateien (Erweiterung .bat) und Windows-Befehlsdateien (Erweiterung .cmd). 쐍 Speichern erzwingen Diese Dateien können vom Benutzer nicht direkt geöffnet werden, sondern müssen auf der Platte gespeichert werden, bevor ein Zugriff auf ihren Inhalt erfolgen kann. Dazu zählen kompilierte Windows-Hilfedateien (Erweiterung .chm). 쐍 Unbekannte Dateien (Dateien, die nicht in den anderen Listen stehen) Die Richtlinie gibt an, was zu tun ist, wenn ein unbekannter Dateityp ermittelt wird. Standardmäßig wird das Speichern auf der Platte erzwungen. Abbildg. 10.26 Konfigurieren der Liste für den erlaubten Dateizugriff einer OWA-Postfachrichtlinie
597
Clients
Postfachrichtlinien und Segmentierung in OWA
Kapitel 10
Clients
Die Priorität der Aktionen verläuft von oben nach unten, d.h., ein Dateityp, der sowohl in der Liste Immer blockieren als auch in der Liste Speichern erzwingen aufgeführt ist, wird blockiert. Ziehen Sie es vor, dass Benutzer für den Dateizugriff anstelle der zugehörigen Anwendung einen Viewer starten, können Sie die Option Bei vorhandenem Konverter WebReady Document Viewing erzwingen wählen. Damit zwingen Sie OWA, beim Öffnen von Dokumenten zu ermitteln, ob ein WebReady-Konverter vorhanden ist, und die Datei in diesem Fall immer mit dem Konverter zu öffnen, anstatt die zugehörige Anwendung aufzurufen. Damit sollen potenzielle Risiken durch Makros oder anderen Code ausgeschaltet werden, der mit den gängigen, von WebReady lesbaren Dateiformaten, etwa Microsoft Word und Microsoft Excel, transportiert werden kann. Tatsächlich fängt die Antivirensoftware, die auf heutigen PCs läuft, normalerweise allen Schadcode ab, weshalb das Erzwingen der WebReady-Ansicht für OWA auf einem privaten Computer als übertrieben angesehen werden kann. Abbildung 10.27 zeigt, wie Sie auf die Liste der von WebReady lesbaren Dateiformate zugreifen. Diese Liste wurde in den vergangenen Jahren erweitert und enthält jetzt die meisten gängigen Dateiformate, die Benutzer bei der Büroarbeit öffnen müssen. Abbildg. 10.27 Die Liste der von WebReady lesbaren Dokumenttypen
Auf privaten Computern mag es risikolos sein, Benutzern das Öffnen von Dokumenten mit Anwendungen zu erlauben, auf Computern für den öffentlichen Zugriff ist es jedoch etwas anderes. In dieser Situation ist es eher üblich, den Zugriff auf Anhänge zu verhindern, um das Risiko auszuschließen, dass Benutzer sensible Dateien herunterladen und auf einem Computer hinterlassen, auf den anschließend ein Unbefugter zugreifen kann. Dazu können Sie die Option über die Exchange-Verwaltungskonsole oder mithilfe des Cmdlets Set-OWAMailboxPolicy entfernen. Die durch eine OWA-Postfachrichtlinie vorgeschriebenen Einstellungen überschreiben diejenigen, die durch die Eigenschaften des virtuellen OWA-Verzeichnisses gesetzt werden: Set-OWAMailboxPolicy –id 'Restricted Users – OWA Light' -DirectFileAccessOnPublicComputersEnabled $False -ForceWebReadyDocumentViewingFirstOnPublicComputers $True
598
Wird diese Richtlinie angewendet, sind die Benutzer nicht in der Lage, Dateien auf öffentlichen Computern zu öffnen oder sie herunterzuladen und dort zu speichern, können aber auf ihren Inhalt zugreifen, wenn ein WebReady-Viewer zur Verfügung steht. Weblinks in Nachrichten sind noch aktiv. Exchange Server 2010 enthält Viewer für Microsoft Office-Dokumente (siehe Abbildung 10.28), RTF- und PDF-Dateien. Abbildg. 10.28 Lesen eines Dokuments im WebReady-Viewer
Insidertipp: Ein Hinweis zum Dokumentzugriff
Exchange Server 2007 bot die neue Möglichkeit, über UNC-Pfade (üblicherweise auf eine Dateifreigabe) oder an SharePoint-Standorten auf Dokumente zuzugreifen. Diese Funktion fehlt in Exchange Server 2010, möglicherweise, weil sie nicht häufig genutzt wurde, aber auch wegen der potenziellen Sicherheitsbedenken beim Zugriff auf Dokumente aus unbekannten oder nicht vertrauenswürdigen Quellen.
Verarbeiten von Anhängen Wie OWA mit Anhängen umgeht, regeln die Administratoren, indem sie eine Liste von Anhangstypen erstellen und diese als blockiert, zulässig oder »zum Speichern zwingen« markieren. Blockiert bedeutet offensichtlich, dass Benutzer einen Anhang dieses Typs nicht öffnen oder auf ihren PC herunterladen dürfen, normalerweise deshalb, weil der Dateityp wahrscheinlich einen Virus oder anderen gefährlichen Inhalt enthält. Zulässig bedeutet das Gegenteil, weil eine hohe Wahrscheinlichkeit besteht, dass diese Anhänge sicher sind.
599
Clients
Postfachrichtlinien und Segmentierung in OWA
Kapitel 10
Clients
Anhänge, bei denen das Speichern erzwungen werden soll, verarbeitet OWA auf besondere Weise. Der Benutzer muss den Anhang auf seiner lokalen Festplatte speichern, bevor er den Inhalt ansehen kann. Beim Herunterladen vom Server prüft OWA, ob es sich um XML oder HTML handelt. Ist dies der Fall, führt OWA so genannten Safe-HTML-Code aus, um gefährlichen XML- oder HTML-Code zu beseitigen. Handelt es sich um einen Anhang eines anderen Typs, untersucht OWA den Inhalt darauf, ob er womöglich XML- oder HTML-Code enthält. Diese Prüfung soll sicherstellen, dass kein Anhang mit Schadcode heruntergeladen wird, der einen Virus oder ein anderes gefährliches Programm auf den PC bringt. Wird verborgener XML- oder HTML-Code gefunden, löscht OWA den Anhang und ersetzt ihn durch einen Text, der dem Benutzer mitteilt, dass der Anhang entfernt wurde. Insidertipp: OWA schützt vor dem Empfang von Code in Textdateien
OWA bietet ein hohes Maß an Schutz. Dies beruht auf der Erfahrung, dass viele PCs durch Anhänge infiziert wurden. Es bedeutet jedoch auch, dass Sie einem OWA-Benutzer in einer Textdatei keinen HTML-Code übermitteln können, weil dieser entfernt wird. Nachdem Sie die neue Richtlinie erstellt haben, wechseln Sie in die Empfängerkonfiguration, um sie anzuwenden. Dort wählen Sie ein oder mehrere Postfächer aus und klicken dann im Aktionsbereich auf Eigenschaften. Wechseln Sie auf die Registerkarte Postfachfunktion und wählen Sie erst Outlook Web App und dann Eigenschaften. Anschließend können Sie eine Postfachrichtlinie für OWA auswählen und auf das Postfach anwenden (siehe Abbildung 10.29). Abbildg. 10.29 Anwenden einer OWA-Richtlinie auf ein Postfach
Bei der nächsten Anmeldung des Benutzers an seinem Postfach erzwingt Exchange die neue Richtlinie. Funktioniert alles wie erwartet, bekommt der Benutzer die eingeschränkte Version OWA Light zu sehen. Selbstverständlich können Sie eine OWA-Postfachrichtlinie auch mit der Exchange-Verwaltungsshell auf ein Postfach anwenden:
600
POP3- und IMAP4-Clients
Insidertipp: Gemeinsamer Einsatz von OWA und OCS
Ein kleines Problem kann sich in den Richtlinienabschnitt über Instant Messaging einschleichen. OWA 2010 ermöglicht den reibungslosen gemeinsamen Einsatz von OWA und OCS (Office Communications Server). Wollen Sie aber die Verknüpfung zwischen den beiden Produkten einrichten, müssen Sie sicherstellen, dass im Attribut InstantMessagingType der Richtlinie für die Postfächer, die OCS verwenden sollen, »OCS« steht: Set-OWAMailboxPolicy –Identity 'OCS Integration Enabled' –InstantMessagingType 'OCS' –InstantMessagingEnabled $True Set-CASMailbox –Identity 'Akers, Kim' –OWAMailboxPolicy 'OCS Integration Enabled'
Weitere Informationen über den gemeinsamen Einsatz von OWA und OCS einschließlich einiger wichtiger Verbesserungen in Exchange Server 2010 SP1 finden Sie unter http://msexchangeteam.com/ archive/2010/09/27/456446.aspx.
POP3- und IMAP4-Clients Die Internet-E-Mail-Protokolle POP3 und IMAP4 werden von einer Vielzahl von Clients und Servern verwendet. Anhänger dieser Protokolle lieben die schlanke Art ihrer Verbindungen, weshalb sie die Protokolle der Wahl für die meisten kostenlosen E-Mail-Dienste für Verbraucher sind, beispielsweise Hotmail und Gmail (Hotmail nutzt POP3, Gmail beide Protokolle). POP3 ist das ältere Protokoll und enthält weniger Funktionen. IMAP4 bietet mehr Funktionen als POP3, jedoch weniger als MAPI. Trotzdem können moderne IMAP4-Clients, darunter Outlook, diese rudimentären, aber äußerst effizienten Clientverbindungen mit einer breiten Palette von Funktionen ausstaffieren, um Nachrichten von einem Server herunterzuladen. Im Unterschied zu MAPI sind POP3 und IMAP4 jedoch Protokolle, mit denen Clients Nachrichten von einem Server abrufen. Sie unterscheiden sich wie folgt: 쐍 POP3 lädt Nachrichten auf einen Client und löscht sie vom Server. 쐍 POP3 kann nur mit einer stark eingeschränkten Menge von Ordnern auf dem Server umgehen (im Wesentlichen mit dem Posteingang). 쐍 IMAP4 kann Kopien der heruntergeladenen Nachrichten auf dem Server lassen. 쐍 IMAP4 kann auf jeden Ordner zugreifen, den ein Server bereitstellt, und Nachrichten daraus in Replikate auf dem Client herunterladen. 쐍 IMAP4 lässt einen »Live-Synchronisationsmodus« zu, in dem der Client eine Verbindung zum Server offen hält. Dieses Verhalten ist dem von Outlook ähnlicher, bei dem Nachrichten nach und nach im Posteingang erscheinen, sobald sie eintreffen, anstatt in Gruppen wie bei einer POP3Verbindung. Die Mehrzahl der Clients, die über POP3 und IMAP4 Verbindung mit Exchange Server 2010 aufnehmen, lässt sich in vier Kategorien einordnen: 쐍 Benutzer in einer Bildungseinrichtung, beispielsweise einer Universität 쐍 Benutzer, die auf ein Postfach zugreifen, das als gehosteter Dienst ausgeführt wird, wenn Outlook zur Vermeidung von Kosten nicht bereitgestellt wird 601
Clients
Set-CASMailbox –Identity 'Andrews, Ben (IT)' –OWAMailboxPolicy 'Restricted Users –OWA Light'
Kapitel 10
Clients
쐍 Benutzer, die Outlook für überladen und aufgebläht halten. Häufig setzen sie schon lange einen Client wie Eudora oder Thunderbird ein und sehen keinen Grund für einen Wechsel. 쐍 Benutzer mit einem Betriebssystem, das die OWA-Premiumversion nicht unterstützt, oder die IMAP einfach vorziehen. Dazu gehören zahlreiche Linux-Anwender. Die Attraktivität der Verwendung kostenloser POP3- oder IMAP4-Clients liegt darin, die Lizenzgebühren für Outlook zu sparen. Bei großen Firmen, die mit Microsoft Lizenzvereinbarungen für die gesamte Office-Suite abschließen, spielt dies eine geringere Rolle. Deshalb werden POP3- und IMAP4Clients in großen Firmenumgebungen relativ wenig eingesetzt. Wird Outlook nicht gewünscht, steht OWA zur Verfügung, und für den internen Support ist es einfacher, wenn nur eine begrenzte Anzahl von Clients im Einsatz ist. Ein weiterer Grund liegt darin, dass POP3- und IMAP4-Clients bewusst so entworfen wurden, dass sie mit jedem Server zusammenarbeiten, der diese Protokolle unterstützt. Besondere Exchange-Funktionen werden daher nicht ausgeführt, darunter folgende: 쐍 Anzeige von E-Mail-Infos 쐍 Anordnung von Nachrichtenthreads als Unterhaltungsansichten 쐍 Anzeige von Informationen über Aufbewahrungstags 쐍 Anzeige geschützter Inhalte, beispielsweise von Elementen, die Lizenzen der Active DirectoryRechteverwaltungsdienste benötigen Im weiteren Verlauf dieses Abschnitts konzentriere ich mich darauf, IMAP4 auf dem Exchange Server-Computer einzurichten und Clients für die Verbindung damit zu konfigurieren. Die Einrichtung des POP3-Zugriffs weicht in Einzelheiten davon ab, folgt aber einem ähnlichen Preinzip, weshalb sie hier nicht behandelt wird. Ausführliche Informationen darüber finden Sie im Internet.
Einrichten des IMAP4-Servers Beim Installieren des Clientzugriffsrolle auf einem Server legt das Setupprogramm den ExchangePOP3- und den Exchange-IMAP4-Dienst an, um Clientverbindungen über diese Protokolle zu ermöglichen, startet die Dienste jedoch nicht. Deshalb ist dies der erste Schritt, um die entsprechenden Clients zu unterstützen. Außerdem sollten Sie den Startzustand für die Dienste von Manuell auf Automatisch ändern, sodass sie von Windows beim Hochfahren des Servers automatisch gestartet werden. Diesem Zweck dienen die folgenden Windows PowerShell-Befehle: Set-Service msExchangeImap4 -StartupType Automatic Start-Service -Service msExchangeImap4
Nachdem der IMAP4-Dienst gestartet ist, läuft auf dem Clientzugriffsserver ein virtueller IMAP4-Server, der eingehende Clientverbindungen auf Port 143 (TLS [Transport Layer Security] oder unverschlüsselte Verbindungen) und 993 (mit SSL [Secure Sockets Layer] geschützte Verbindungen) überwacht. Abbildung 10.30 zeigt die Eigenschaften, die für Administratoren bei der Einrichtung der IMAP4-Anbindung für Exchange Server 2010 normalerweise am interessantesten sind. Die Bindungseigenschaften definieren die Ports, die der IMAP4-Server überwacht, und die Gruppe der IP-Adressen, über die die Clients Verbindung mit dem IMAP4-Server aufnehmen können. In den Eigenschaften unter Verbindung werden verschiedene Grenzen festgelegt, mit denen der Server Clientverbindungen steuert. Auf TechNet finden Sie genauere Informationen über diese Einstellungen.
602
POP3- und IMAP4-Clients
Clients
Abbildg. 10.30 Die Eigenschaften des Exchange-IMAP4-Servers
In Exchange Server 2010 SP1 können Sie die einfache Authentifizierung, die integrierte WindowsAuthentifizierung sowie mit TLS geschützte Serveranmeldungen (Standardeinstellung) verwenden, um Verbindungen zu POP3- oder IMAP4-Clients herzustellen. Wie in Abbildung 10.31 gezeigt, können Sie die gewünschte Authentifizierungsmethode auf der Registerkarte Authentifizierung des Eigenschaftendialogfelds für den IMAP4-Server wählen. Abbildg. 10.31 Authentifizierungseigenschaften für den IMAP4-Server
603
Kapitel 10
Clients
Mit den Cmdlets Get-IMAPSettings bzw. Set-IMAPSettings können Sie Konfigurationseinstellungen für den IMAP4-Server abrufen und setzen. Die entsprechenden Cmdlets für POP3 heißen Get-POPSettings und Set-POPSettings. Um zum Beispiel die aktuelle Konfiguration des Clientzugriffsservers ExServer1 abzurufen, verwenden wir folgenden Befehl: Get-IMAPSettings –Server ExServer1Protocol Name Name MaxCommandSize ShowHiddenFoldersEnabled UnencryptedOrTLSBindings SSLBindings InternalConnectionSettings
: : : : : : :
ExternalConnectionSettings X509CertificateName Banner LoginType AuthenticatedConnectionTimeout PreAuthenticatedConnectionTimeout MaxConnections MaxConnectionFromSingleIP MaxConnectionsPerUser MessageRetrievalMimeFormat ProxyTargetPort CalendarItemRetrievalOption OwaServerUrl EnableExactRFC822Size LiveIdBasicAuthReplacement SuppressReadReceipt ProtocolLogEnabled EnforceCertificateErrors LogFileLocation LogFileRollOverSettings LogPerFileSizeQuota Server Identity
: : : : : : : : : : : : : : : : : : : : : : :
IMAP4 1 10240 False {:::143, 0.0.0.0:143} {:::993, 0.0.0.0:993} {ExServer1.contoso.com:993:SSL, ExServer1.contoso.com:143:TLS} {} ExServer1 The Microsoft Exchange IMAP4 service is ready. PlainTextAuthentication 00:30:00 00:01:00 2000 2000 16 BestBodyFormat 143 iCalendar False False False False False C:\LOGS\IMAP4 Daily unlimited EXSERVER1 EXSERVER1\1
Beachten Sie, dass die aufgeführte Eigenschaft ExternalConnectionSetting leer ist. Diese Eigenschaft wird angezeigt, wenn der Benutzer der Seite Kontoinformationen der Exchange-Systemsteuerung auf Einstellungen für POP-, IMAP- und SMTP-Zugriff klickt. Diese Informationen können die Benutzer dann in den Clients eingeben, die zur Verbindung mit Exchange diese Protokolle verwenden. Lassen Sie die Standardeinstellungen bestehen, sehen die Benutzer beim Zugriff auf die Seite leider leere Werte. Sie müssen aber den Namen des Clientzugriffsservers, mit dem sie Verbindung aufnehmen wollen, die Portnummer für das Protokoll und die Sicherheitseinstellung für den Verschlüsselungstyp kennen. Diese Werte lassen sich mit den Cmdlets Set-POPSettings und Set-IMAPSettings festlegen. Um die Informationen bereitzustellen, müssen Sie Folgendes tun: 604
POP3- und IMAP4-Clients
쐍 Angaben für den POP3-Zugriff bereitstellen:
Clients
Set-POPSettings –ExternalConnectionSettings ExServer1.contoso.com:995:SSL –Server ExServer1
쐍 Angaben für den IMAP4-Zugriff bereitstellen: Set-IMAPSettings –ExternalConnectionSettings ExServer1.contoso.com:993:SSL –Server ExServer1
쐍 Informationen über den Connector veröffentlichen. Die meisten Firmen stellen einen Empfangsconnector auf einem Hub-Transport-Server bereit, den POP3- und IMAP4-Clients zum Weiterleiten ihrer E-Mail-Nachrichten benutzen können. Um den Benutzern mitzuteilen, welchen Server sie wählen sollen, veröffentlichen Sie Informationen über den Connector, indem Sie dessen Eigenschaft AdvertiseClientSetting auf $True setzen. Im folgenden Beispiel sage ich den Benutzern, dass Sie Verbindung zum standardmäßigen Empfangsconnector auf einem Hub-Transport-Server aufnehmen sollen, aber in der Produktion werden Sie wahrscheinlich eher einen besonderen Empfangsconnector erstellen, der als Clientrelay reserviert und konfiguriert ist. Set-ReceiveConnector –Identity 'ExServer1\Default ExServer1' –AdvertiseClientSettings $True
Denken Sie daran, dass die POP3- und IMAP4-Einstellungen immer nur serverweit gelten, sodass sie auf allen Clientzugriffsservern gesetzt werden müssen, die Sie für diesen Zweck verwenden wollen. Möglicherweise ist ein Neustart der Internetinformationsdienste auf dem Clientzugriffsserver erforderlich, damit den Clients die neuen Werte zur Verfügung stehen. Ändern Sie Konfigurationseinstellungen für den IMAP4-Server, so müssen Sie den Exchange-IMAP4Dienst neu starten. Um Fehler in den Verbindungen mit einem bestimmten Client zu suchen, müssen Sie die Protokollierung aktivieren und Exchange mitteilen, wo das Protokoll angelegt werden soll. Um in Exchange Server 2007 die Protokollierung einzuschalten, müssen Sie eine Konfigurationsdatei bearbeiten, in Exchange Server 2010 können Sie dagegen das Cmdlet Set-IMAPSettings verwenden: Set-IMAPSettings –Server ExServer1 –ProtocolLogEnabled $True –LogFileLocation 'C:\Logs\'
Die Protokollierung legt auf dem Server eine Menge Daten an, von denen ein Teil recht undurchschaubar ist, wenn Sie nicht mit der Fehlersuche in IMAP-Verbindungen vertraut sind. Auch Clients können Protokolle erstellen. Falls Sie Daten bereitstellen müssen, um einem Supportmitarbeiter bei der Lösung eines Problems zu helfen, sollten Sie Server- und Clientprotokolle anlegen, um sicherzustellen, dass sämtliche Informationen darüber vorliegen, was der Client sendet und wie der Server darauf reagiert.
Einrichten des IMAP4-Clientzugriffs Aus der Benutzerperspektive erscheint es einfach, einen POP3- oder IMAP4-Client für die Verbindung mit Exchange Server 2010 einzurichten. Für mein Beispiel habe ich den kostenlosen IMAP4-Client Thunderbird gewählt, den Sie von der Adresse http://www.mozillamessaging.com/de/thunderbird/ herunterladen können. Bevor ein IMAP4-Client Nachrichten herunterladen und senden kann, müssen zwei getrennte Verbindungen konfiguriert werden.
605
Kapitel 10
Clients
1. Auf einem Clientzugriffsserver muss ein IMAP4-Server für die Entgegennahme von Clientverbin-
dungen bereitstehen, damit IMAP4-Clients auf Postfächer zugreifen und Ordner und Elemente herunterladen können. 2. Auf einem Hub-Transport-Server muss ein SMTP-Empfangsconnector (Simple Mail Transfer Protocol) für die Entgegennahme von Clientverbindungen bereitstehen, damit IMAP4-Clients ausgehende Nachrichten über SMTP weiterleiten können. Beachten Sie, dass der Clientzugriffsserver POP3- und IMAP4-Verbindungen von den Konten Anonym und Gast blockiert. Auch das Konto Administrator kann nicht für Verbindungen mit Exchange über diese Protokolle benutzt werden. Für den Zugriff auf das Administratorpostfach müssen Sie Outlook oder OWA verwenden. Um den Client für die Verbindung zu Exchange Server 2010 zu konfigurieren, sind folgende Schritte erforderlich: 1. Setzen Sie die Authentifizierungseinstellung für den IMAP4-Server auf dem Clientzugriffsserver,
mit dem Sie den Client verbinden wollen, auf Standardauthentifizierung. Das reicht zum Testen, weil es dafür sorgt, dass praktisch jeder IMAP4-Client Verbindung aufnehmen kann. Sobald die Verbindungen problemlos funktionieren, können Sie die Sicherheitsstufe erhöhen und zu Integrierte Windows-Anmeldung oder Sichere Anmeldung wechseln, je nachdem, welche Authentifizierungsmechanismen der Client unterstützt. 2. Starten Sie den IMAP4-Server neu, um die Änderung der Authentifizierungseinstellung wirksam werden zu lassen. 3. Richten Sie den Client mit dem Namen des Clientzugriffsservers und dem Benutzernamen im Format Domänenname\Kontoname ein. Abbildung 10.32 zeigt die Servereinstellungen bei der Eingabe in Thunderbird. Abbildg. 10.32
Verbinden des IMAP4-Clients Thunderbird mit Exchange Server 2010
4. Stellen Sie mit dem Client eine Verbindung her, um sich zu überzeugen, dass Nachrichten herun-
tergeladen werden können. 5. Stellen Sie sicher, dass die Berechtigungen des standardmäßigen Client-Empfangsconnectors auf
dem für ausgehende Nachrichten vorgesehenen Hub-Transport-Server anonyme Verbindungen zulassen. Dies ist wiederum die einfachste Einstellung zum Testen der Anbindung für ausgehende 606
Nachrichten. Sie soll gewährleisten, dass alle Arten von Clients in der Lage sind, zum Senden von Nachrichten Verbindung aufzunehmen. Sobald Sie wissen, dass die Nachrichten fließen, können Sie die Sicherheit erhöhen. Wie Sie in Abbildung 10.32 sehen können, unterstützt Thunderbird die STARTTLS-Sicherheit mit Benutzernamen und Kennwort als Anmeldeinformationen. Der Empfangsconnector erkennt also auf diese Weise authentifizierte Verbindungen als »ExchangeBenutzer«, weshalb er keine anonymen Verbindungen zu erlauben braucht. Sobald Nachrichten problemlos heruntergeladen und gesendet werden können, gehen Sie dazu über, den LDAP-Zugriff (Lightweight Directory Access Protocol) auf Active Directory einzurichten, damit wir Active Directory als Adressbuch verwenden können. Die Einzelheiten der Verbindung zu Active Directory unterscheiden sich von Client zu Client, ebenso die Fähigkeit des Clients, die von Active Directory abgerufenen Daten zu nutzen. Manche Clients können Active Directory nur durchsuchen, andere wie Thunderbird dagegen E-Mail-Adressen bei der Eingabe in den Nachrichtenheader mit Active Directory abgleichen. Abbildung 10.33 zeigt die Einstellungen, die ich verwendet habe, um Active Directory als Adressbuch für Thunderbird einzurichten. Abbildg. 10.33 Einrichten des Thunderbird-Adressbuchs für die Verbindung mit Active Directory
Folgende Einstellungen wurden verwendet: 1. Der Name ist auf Active Directory gesetzt. Dies ist jedoch beliebig, weil er nur als Anzeigename
dient und keine Funktion hat. 2. Der Hostname ist auf den vollqualifizierten Domänennamen (Fully Qualified Domain Name,
FQDN) eines globalen Katalogservers gesetzt, der Zugriff auf Active Directory bereitstellt. Idealerweise sollte er sich am selben Standort befinden wie der Clientzugriffsserver. 3. Der Basis-DN bietet einen Ausgangspunkt für LDAP-Suchoperationen in Active Directory. In diesem Fall geben wir den Stamm des Verzeichnisses an, um sicherzustellen, dass alle E-Mail-aktivierten Objekte in contoso.com gefunden werden. 607
Clients
POP3- und IMAP4-Clients
Kapitel 10
Clients
4. Die Portnummer ist nicht auf den LDAP-Standardport 389, sondern auf 3268 gesetzt. 5. Der Bindungs-DN ist auf meine SMTP-Adresse gesetzt.
Um die Verbindung zu testen, öffnen Sie das Clientadressbuch und versuchen, einige Postfächer zu finden, von denen Sie wissen, dass sie existieren. Sie sollten Postfächer, Kontakte und Verteilungsgruppen sehen. Insidertipp: Kleinere Probleme
Es gibt zwei kleinere Probleme: 1. Die von einem Client ausgeführten LDAP-Suchoperationen ignorieren möglicherweise
Exchange-spezifische Filter. Aktivieren Sie zum Beispiel das Kontrollkästchen In ExchangeAdresslisten verbergen für ein Objekt, können Outlook- und OWA-Benutzer es in der globalen Adressliste nicht sehen. Auf andere Clients hat die Blockierung jedoch keine Auswirkungen, sodass die verborgenen Objekte den Benutzern wahrscheinlich angezeigt werden. 2. Aus den gleichen Gründen wendet eine LDAP-Suche in Active Directory keine Filter an, die Objekte ohne E-Mail-Aktivierung ausschließen, sodass Sie wahrscheinlich Sicherheitsgruppen wie Organisations-Admins sehen können. Sie können ihnen jedoch keine E-Mails schicken, weil sie keine E-Mail-Adressen haben. Dies sind kleine Stolpersteine, aber der Umstand, dass Benutzer Lesezugriff auf Verzeichnisinformationen haben und einige Objekte sehen, die andere Clients nicht zeigen, ist nicht besonders schlimm.
Exchange ActiveSync In Exchange Server 2003 SP2 hat Microsoft erstmals servergestütztes ActiveSync in Exchange integriert. Exchange Server 2007 brachte eine wesentliche Aktualisierung von ActiveSync. Die mit Exchange Server 2010 gelieferte ActiveSync-Version enthält deutlich weniger Änderungen, wobei es sich größtenteils um die bessere Unterstützung von Clients durch Weiterentwicklung vorhandener Funktionen handelt. Möglicherweise ist ActiveSync jetzt »ausreichend wettbewerbsfähig«, und Microsoft konzentriert sich darauf, es möglichst großflächig zu lizenzieren. Die Lizenzierungsaktivitäten verlaufen sicher sprunghaft, weil nun alle größeren Smartphone-Anbieter ActiveSync nutzen wollen, so auch Apple für das iPhone und Google für Android-Geräte. Die Attraktivität von ActiveSync ist stark mit dem Erfolg von Exchange als De-facto-E-Mail-Plattform von Firmen verknüpft. Obwohl die Fähigkeiten von Windows Mobile noch nicht so weit entwickelt sind wie die anderer Mobilplattformen, ist der Erfolg von Microsoft aufgrund der zunehmenden Anzahl von Exchange-Postfächern und der damit einhergehenden größeren Verfügbarkeit ActiveSync-fähiger Geräte gewachsen. Zu den wichtigen Funktionsänderungen in Exchange Server 2010 ActiveSync, die aktualisierte Clients nutzen können, zählen folgende: 쐍 Wie in Outlook und OWA 2010 lassen sich Nachrichten zu Unterhaltungen zusammenfassen, sodass alle Elemente, die ein Thema betreffen, gemeinsam behandelt werden können. Sie können mit einer einzigen Operation das letzte Element lesen, ein Element oder die gesamte Unterhaltung löschen oder alles verschieben. Am interessantesten ist die Art, wie Exchange Metadaten auf dem Server unterhält, um die fortlaufende Verarbeitung von Unterhaltungen beim Eintreffen neuer Elemente zu handhaben. Mithilfe der Metadaten kann Exchange Dinge erledigen wie »alle weiteren Elemente dieser Unterhaltung löschen« oder »Elemente verschieben, sobald sie in diesem Ordner ankommen«. 608
Exchange ActiveSync
쐍 Wenn Sie Exchange Server 2010 Unified Messaging bereitstellen, werden Voicemail-Nachrichten jetzt direkt in Outlook Mobile abgespielt (weil sie als MP3-Dateien kodiert werden). Sie brauchen den Sprachanhang nicht mehr zu exportieren und ihn mit Windows Media Player oder einem anderen Audioplayer abzuspielen. Außerdem werden Voicemails mit einer Durchschrift der Nachricht im Text übermittelt, sodass Sie eine Vorstellung davon bekommen, worum es geht, ohne den Anhang öffnen zu müssen. 쐍 Outlook Mobile legt Angaben über vor kurzem verwendete E-Mail-Adressen in einem Spitznamenspeicher in einem verborgenen Element des Postfachstamms ab und gibt sie für Outlook und OWA frei, sodass Sie eine Vorschlagsliste mit Empfängern sehen, wenn Sie eine neue Adresse eingeben. 쐍 Sie können von Ihrem Telefon aus SMS- oder Textmeldungen senden und empfangen. Neue Nachrichten lassen sich mit Outlook oder OWA verfassen und von ActiveSync auf das Mobilgerät übertragen, das sie dann wie jede andere SMS sendet. Umgekehrt funktioniert es auch: Eingehende SMS-Nachrichten werden auf das Gerät heruntergeladen und dann von ActiveSync mit Ihrem Postfach synchronisiert, wo sie in OWA oder Outlook verarbeitet werden können. Textnachrichten werden wie jede andere Nachricht in den Ordnern Posteingang und Gesendete Objekte gespeichert und lassen sich wie jedes andere Element bearbeiten, zum Beispiel für die Nachverfolgung kennzeichnen oder an einen anderen Benutzer weiterleiten. HINWEIS Alle, die an den beschränkten Tastaturen vieler Mobilgeräte verzweifeln, werden sich über die Möglichkeit freuen, SMS-Nachrichten mit ihrer Computertastatur zu schreiben und zu senden. Die ActiveSync-Synchronisation von Textnachrichten mit Exchange ist eine einfache, aber brillante Idee. Beklagen können Sie sich allenfalls darüber, dass dieses Merkmal erst jetzt erschienen ist, wobei als Entschuldigung wahrscheinlich angeführt wird, dass Textnachrichten zwar in Europa und Asien schon seit Jahren enorm beliebt sind, die SMS-Kommunikation in den USA aber erst seit kurzem populär ist. 쐍 Ähnlich wie in Outlook wird jetzt ein Symbol dafür angezeigt , dass Sie bereits auf eine Nachricht geantwortet bzw. sie weitergeleitet haben. Auf Telefonen mit Windows Mobile 6.1 können Sie Outlook mithilfe einer CAB-Aktualisierung in die Lage versetzen, auf die neuen Funktionen zuzugreifen, die ActiveSync in Exchange Server 2010 bereitstellt. Exchange Server 2010-Benutzer, deren Postfächer für ActiveSync aktiviert sind und die mit einem geeigneten Gerät darauf zugreifen, erhalten eine Nachricht, mit der sie eingeladen werden, eine OTA-Aktualisierung (Over-the-air) für ihr Gerät von der Microsoft-Website herunterzuladen (siehe Abbildung 10.34). Sie versieht das Gerät mit Outlook Mobile und erlaubt dem Benutzer, auf Funktionen wie SMS-Synchronisierung und Unterhaltungen zuzugreifen. Telefone mit Windows Mobile 6.5 oder höher verfügen bereits über den für diese Merkmale erforderlichen Code. Dies ist eine lange überfällige Verbesserung der früheren Situation, in der Firmen im Grunde gezwungen waren, Geräte mit Windows Mobile zu aktualisieren, um die Funktionen nutzen zu können, die mit einer neuen ActiveSync-Version eingeführt wurden. Möglicherweise hat Microsoft erkannt, dass Unternehmen mobile Geräte für Geschäftszwecke nicht so schnell ersetzen wie Privatleute, die sich gern das allerneueste Gerät zulegen.
609
Clients
쐍 Sie können für Kontakte Frei/Gebucht-Informationen vom Server abrufen, um festzustellen, ob sie zu einer bestimmten Zeit verfügbar sind. Diese Funktion ist großartig, wenn Sie mit einem Mobilgerät versuchen, eine Besprechung zu organisieren.
Kapitel 10
Clients
Abbildg. 10.34 Einladung zur Benutzung von integriertem Textmessaging
Einrichten von ActiveSync-Richtlinien Solange Sie keine andere Richtlinie angeben, wendet Exchange die ActiveSync-Standardrichtlinie auf Postfächer an, die für ActiveSync aktiviert werden. Die in Exchange Server 2007 definierten Richtlinien wurden für Exchange Server 2010 um eine neue Fähigkeit erweitert, die bestimmte Anwendungen auf einem Mobilgerät zulassen oder blockieren kann. Sie ist auf der Registerkarte Andere des Eigenschaftendialogfelds der Richtlinie zu finden (siehe Abbildung 10.35). Beachten Sie, dass die Verwendung dieser Fähigkeit einen Umstieg auf die Enterprise-Clientzugriffslizenz voraussetzt. Die Eigenschaften auf den übrigen Registerkarten sind dieselben wie vorher und steuern Einstellungen wie die, ob für den Zugriff auf das Gerät ein Kennwort erforderlich ist, welche Art von Kennwort verwendet werden soll, wie groß Nachrichten und Anhänge sein dürfen, die synchronisiert werden sollen, ob Geräte, die die Richtlinien nicht einhalten, zulässig sind und welche Gerätefunktionen (Kamera, Wechselmedien, WLAN und Bluetooth) angeboten werden. Insidertipp: Postfachrichtlinien und die Client-Server-Partnerschaft bei ActiveSync
Sie können diese Einstellungen zwar alle in einer Richtlinie sammeln und auf Postfächer anwenden, müssen aber wissen, dass ActiveSync auf der Partnerschaft von Client und Server beruht. Der Server kann zwar auf einigen Einstellungen bestehen, aber der Client kann die Ansprüche des Servers ungeniert ignorieren, wenn sein Betriebssystem den Code für die vollständige Anwendung der Richtlinie nicht implementiert hat. ActiveSync unterscheidet deutlich zwischen vollständig konformen, teilweise konformen und nicht konformen Geräten. Ein vollständig konformes Gerät setzt sämtliche Einstellungen der Richtlinie um. Ein teilweise konformes Gerät wendet einige, aber nicht alle Einstellungen der Richtlinie an, wahrscheinlich, weil der dafür erforderliche Code im Betriebssystem nicht implementiert ist. Ein nicht konformes Gerät kann sich mit Exchange synchronisieren, ignoriert Richtlinieneinstellungen aber, weil es eine vom Server bereitgestellte Richtlinie nicht erkennt oder nicht akzeptiert. Sie können beispielsweise eine Richtlinie erstellen, die die Verwendung einer Kamera in mobilen Geräten unterbindet. Auf Geräten mit Windows Mobile ist sie wirksam, weil das Betriebssystem versteht, wie man die Kamera deaktiviert. Ein iPhone von Apple ignoriert sie jedoch, und die Kamera kann weiterhin benutzt werden, weil das iPhone nur eine Teilimplementierung von ActiveSync enthält, die für die grundlegenden Dinge wie E-Mail-, Kalender- und Kontaktsynchronisierung ausreicht, aber einige wichtige Verwaltungsmöglichkeiten nicht aufweist.
610
Exchange ActiveSync Abbildg. 10.35 Bearbeiten einer ActiveSync-Richtlinie, um Anwendungen für mobile Geräte zu erlauben oder
Clients
zu blockieren
Welche Richtlinie auf ein Postfach angewendet wird, lässt sich jederzeit ändern: Set-CASMailbox -Identity 'Ruth, Andy' -ActiveSyncMailboxPolicy "Executives"
In Exchange Server 2010 SP1 können Sie ActiveSync-Richtlinien im Abschnitt Telefon und Voice der Exchange-Systemsteuerung erstellen und unterhalten. Dort sehen Sie genau dieselben Parameter wie in der Exchange-Verwaltungskonsole. Abbildung 10.36 zeigt, wie Sie eine neue ActiveSync-Richtlinie in der Exchange-Systemsteuerung erstellen. Abbildg. 10.36 Erstellen einer neuen ActiveSync-Richtlinie in der Exchange-Systemsteuerung
611
Kapitel 10
Clients
Erstellen von ActiveSync-Berichten Sämtliche Transaktionsdaten über die Kommunikation zwischen ActiveSync-Clients und Exchange werden in IIS-Protokollen aufgezeichnet. Dort finden Sie Informationen wie die Protokollversion der Geräte, die mit Exchange kommunizieren, die Art der durchgeführten Synchronisierung (E-Mail, Kalender, Kontakte, alles) und bestimmte Vorgänge wie das Erstellen von Abwesenheitsnachrichten. All dies steht zwar zur Verfügung, ist jedoch in der Menge der übrigen Daten vergraben, die in den IIS-Protokollen festgehalten werden, sodass ein wenig Hilfe erforderlich ist, um die richtigen Daten zu finden und zu interpretieren. Für genau diesen Zweck wurde das Cmdlet Export-ActiveSyncLog entworfen, das auf einem Clientzugriffsserver ausgeführt wird. Es durchsucht die Internetinformationsdienste, filtert die Daten heraus, die sich auf ActiveSync-Operationen beziehen, und erstellt daraus verschiedene Berichte: 쐍 Nutzungsbericht (Users.csv) Überblick über die insgesamt gesendeten und empfangenen Elemente (Anzahl der Elemente und Bytes), gegliedert nach Elementart (E-Mail, Kalender usw.) 쐍 Serverbericht (Servers.csv) Überblick über die Server, auf denen die mit ActiveSync-Anforderungen verknüpften Postfächer liegen 쐍 Trefferbericht (Hourly.csv) Gesamtzahl der pro Stunde verarbeiteten Synchronisierungsanforderungen und Gesamtzahl der verschiedenen Geräte, die jeweils Synchronisierungsanforderungen stellen 쐍 HTTP-Statusbericht (StatusCodes.csv) Überblick über die verschiedenen HTTP-Fehlerreaktionscodes und den Prozentanteil der Zeit, in der die einzelnen Codes auftraten. Dieser Bericht soll einen Hinweis auf die Gesamtleistung des Servers geben. 쐍 Richtlinienkonformitätsbericht (PolicyCompliance.csv) Überblick über die Anzahl vollständig konformer, teilweise konformer und inkonformer Geräte 쐍 Liste der Benutzer-Agents (UserAgents.csv) Überblick über die Gesamtzahl verschiedener Benutzer, die während der Berichtsperiode Verbindung mit ActiveSync aufgenommen haben, geordnet nach Betriebssystem des mobilen Geräts (verschiedene Versionen von Windows Mobile, iPhone, Android usw.). Da die Ausgabedateien im CSV-Format vorliegen, können Sie sie nach Bedarf öffnen und interpretieren. Sie können sie mit Microsoft Excel oder Microsoft Access öffnen oder in eine Datenbank importieren, um anhand von über einen längeren Zeitraum gesammelten Daten genauere Analysen und Berichte erstellen zu können.
Berichte über synchronisierte Geräte Das Cmdlet Get-ActiveSyncDeviceStatistics liefert Informationen über den Synchronisierungszustand eines Postfachs, wie die folgende bearbeitete Ausgabe zeigt: Get-ActiveSyncDeviceStatistics –id JSmith FirstSyncTime LastPolicyUpdateTime LastSyncAttemptTime LastSuccessSync DeviceType DeviceID
612
: : : : : :
2/24/2010 7:00:01 PM 3/3/2010 7:30:22 PM 3/4/2010 6:06:18 PM 3/4/2010 6:06:18 PM PocketPC 5ECE2DBB684616DD07FB173DF09254B5
Exchange ActiveSync
: : : : : : : : : : : : : : : :
MSFT-PPC/5.2.5070
Clients
DeviceUserAgent DeviceWipeSentTime DeviceWipeRequestTime DeviceWipeAckTime LastPingHeartbeat RecoveryPassword DeviceModel DeviceImei DeviceFriendlyName DeviceOS DeviceOSLanguage DevicePhoneNumber MailboxLogReport DeviceEnableOutboundSMS DeviceMobileOperator Identity
******** HP_KB1 ****** HP_iPAQ_Glisten Windows CE 5.2.21871 English *******7701
True AT&T contoso.com/Exchange users/JSmith/ ExchangeActiveSyncDevices/ PocketPC§5ECE2DBB684616DD07FB173DF09254B5 Guid : 8fb8848c-8c65-4f43-bb1e-450e582e1622 IsRemoteWipeSupported : True Status : DeviceOk StatusNote : DeviceAccessState : Allowed DeviceAccessStateReason : Global DeviceAccessControlRule : DevicePolicyApplied : Mobile Policy (default) DevicePolicyApplicationStatus : AppliedInFull LastDeviceWipeRequestor : DeviceActiveSyncVersion : 14.0 NumberOfFoldersSynced : 7 SyncStateUpgradeTime :
Insidertipp: Die Daten sind nützlich!
Hier werden einige interessante Daten gezeigt. Sie können nämlich sehen, welche Geräte mit dem Postfach synchronisiert wurden, wann dies geschah, und sogar den Mobilfunkanbieter erkennen. Diese Daten können die Grundlage für Verwaltungsberichte bilden, beispielsweise für einen Überblick über die Anzahl der Postfächer, die mobile Geräte benutzen, für eine Analyse der verwendeten Geräte sowie für Hinweise auf die Verteilung der Benutzer auf Mobilfunkanbieter. Solche Daten lassen sich für verschiedene Zwecke nutzen, etwa zum Aushandeln eines günstigeren Firmenvertrags mit einem Mobilfunkanbieter oder um zu planen, wie ältere mobile Geräte ersetzt werden können.
613
Kapitel 10
Clients
Das Problem bei dem Cmdlet Get-ActiveSyncDeviceStatistics besteht darin, dass es auf Postfachebene arbeitet. Es gibt kein Cmdlet, das serverweit Daten der Art liefert, die für die Analyse sinnvoll sind. Sie wollen ganz bestimmt nicht Synchronisierungsdaten für Tausende von Postfächern durchgehen, um eine Vorstellung davon zu bekommen, was auf dem Server vorgeht. Es ist also Code erforderlich, um die notwendigen Daten zu erheben und in einem Format zu speichern, das die Analyse ermöglicht. Der folgende Code benutzt das Cmdlet Get-CASMailbox, um Daten aller Postfächer mit ActiveSyncPartnerschaft abzurufen, die mit einem Exchange-Postfachserver verbunden sind. Anschließend extrahiert das Cmdlet Get-ActiveSyncDeviceStatistics die Angaben für jedes einzelne Gerät (denken Sie daran, dass man Partnerschaften mit mehreren Mobilgeräten einrichten kann) und schreibt sie in eine Variable. Nachdem die Daten aller Postfächer abgerufen sind, werden die zusammengeführten Daten in einer CSV-Datei abgelegt, die für die spätere Analyse verwendet werden kann. $Devices = $Null $Mbx = Get-CASMailbox –ResultSize Unlimited | Where {$_.HasActiveSyncDevicePartnership -eq $True -and $_.ExchangeVersion.ExchangeBuild -ilike "14*"} ForEach ($m in $Mbx) { $Devices += Get-ActiveSyncDeviceStatistics -Mailbox $m.Identity } $Devices | Export-CSV ExServer1ActiveSync.csv
Der Code funktioniert, eignet sich tatsächlich aber nur für kleine Bereitstellungen mit weniger als 1000 Postfächern, bei denen Sie nicht in Schwierigkeiten geraten, wenn Sie eine große Datenmenge im Arbeitsspeicher verarbeiten. Eine andere Möglichkeit besteht darin, zwei getrennte Schleifen zu verwenden. Die erste verarbeitet die Liste der Postfächer mit ActiveSync-Partnerschaften, die zweite ruft Informationen über jedes Gerät ab, das sich mit dem Postfach synchronisiert hat. Die gewonnenen Daten werden weniger wortreich in einer einfachen Textdatei abgelegt. Der Code wurde für monatliche Verwaltungsberichte in Organisationen mit über 30000 mobilen Geräten eingesetzt: $Date = Get-Date -uformat "%Y%m%d" $Logfile = "C:\Logs\ActiveSync-all-$date.txt" $Lst = Get-CASMailbox -ResultSize Unlimited | Where {$_.HasActiveSyncDevicePartnership -eq $True} ForEach ($CASMbx in $lst) { $Devices=$Null $Devices= @Get-ActiveSyncDeviceStatistics -Mailbox $CASMbx.name) ForEach ($device in $devices) { $DeviceModel = $Device.DeviceModel $DeviceType = $Device.DeviceType $LastSyncTime = $Device.LastSuccessSync $PhoneNumber = $Device.DevicePhonenumber $UserAgent = $Device.DeviceUserAgent Add-Content -path $Logfile "$casmbx.name |$DeviceModel|$DeviceType|$UserAgent|$LastSyncTime|$PhoneNumber|" } } 614
Exchange ActiveSync
Blockieren einzelner Typen mobiler Geräte Ständig erscheinen neue mobile Geräte, und die Benutzer sind dann versucht, sie zu kaufen, und wollen sie mit ihren Postfächern verbinden. Häufig geschieht dies ohne Wissen oder Eingreifen eines Administrators. Solange alles funktioniert und die erste Verbindung des Geräts sowie die fortlaufende Synchronisierung des Postfachinhalts perfekt klappt, ist es nicht problematisch. Sobald ein Benutzer aber versucht, ein neues Gerät einzuführen, das die Sicherheitsleitlinien des Unternehmens nicht erfüllt oder dessen Betriebssystem nicht unterstützt wird, kann es Probleme geben. Die ursprüngliche ActiveSync-Implementierung auf dem Palm Pre erzwang beispielsweise keine PIN-Sperre, was für zahlreiche Firmen ein ziemlich großes Sicherheitsproblem darstellt, sodass die Benutzer angewiesen wurden, diese Geräte nicht zu verwenden, bis Palm das Problem behoben hatte. Auch das ursprüngliche iPhone von Apple verursachte bei manchen Unternehmen einiges Unwohlsein, weil seine Umsetzung der ActiveSync-Sicherheitsmerkmale weniger vollständig war als bei Windows Mobile. Wenn Sie durch eine offene Verbindungspolitik »nicht beherrschbare Geräte« zulassen, erlauben Sie im Grunde jedem Gerät, das ActiveSync nutzen kann, die Verbindung mit Exchange, und gehen das Risiko ein, dass die Richtlinien, die das gewünschte Sicherheitsverhalten erzwingen, das eine oder andere Gerät niemals erreichen (oder von ihm ignoriert werden). Um das Problem zu beheben, führt Exchange Server 2010 das Cmdlet Set-ActiveSyncOrganizationSettings ein, mit dem Sie besser steuern können, was geschieht, wenn Benutzer versuchen, neue mobile Geräte zum ersten Mal zu synchronisieren. In diesem Zusammenhang ist ein neues mobiles Gerät eines, für dessen Typ Exchange keine Zugriffsrichtlinie definiert hat. Sie können sich dafür entscheiden, die Synchronisierung komplett zu blockieren, das Gerät in Quarantäne zu schicken oder es zuzulassen. Wird ein Gerät in Quarantäne geschickt, werden seine Informationen an eine Gruppe dafür benannter Administratoren gesendet, die entscheiden können, ob es sich synchronisieren darf oder ob sein Zugriff auf Exchange weiter blockiert wird. Der folgende Code setzt die Standardzugriffsstufe beispielsweise auf Blockiert und sendet eine Notiz an die E-Mail-Adresse [email protected], sobald ein Benutzer versucht, über ein neues Gerät Verbindung aufzunehmen. Es ist günstiger, diese Adresse auf eine Verteilergruppe zeigen zu lassen, weil dadurch normalerweise eine schnellere Reaktion gewährleistet ist. Der Parameter -UserMailInsert enthält eine Textzeichenfolge, die Exchange in die Nachricht an den Benutzer einfügt, um ihn darüber zu informieren, dass über sein Gerät eine Quarantäne verhängt wurde. Set-ActiveSyncOrganizationSettings –AdminMailRecipients '[email protected]' –DefaultAccessLevel 'Quarantine' –UserMailInsert 'Device quarantined. Please call the Help Desk to unblock the device'
Mit dem Cmdlet Get-ActiveSyncOrganizationSettings können Sie die aktuelle Richtlinie für neue Geräteverbindungen sehen. Aus dieser Ausgabe entnehmen wir, dass die ActiveSync-Standardrichtlinie für die Organisation jedem Gerät erlaubt, Verbindung aufzunehmen: Get-ActiveSyncOrganizationSettings DefaultAccessLevel UserMailInsert AdminMailRecipients Name
: Allow : : {} : Mobile Mailbox Settings 615
Clients
Welchen Ansatz für Berichte Sie auch wählen, Sie müssen Daten erheben, die für Ihre Organisation sinnvoll sind, und daraus eine solide und praktikable ActiveSync-Richtlinie für Ihre Firma erstellen.
Kapitel 10
Clients
OtherWellKnownObjects AdminDisplayName ExchangeVersion Identity
: {} : : 0.10 (14.0.100.0) : Mobile Mailbox Settings
Nehmen wir an, dass ein Benutzer versucht hat, eine Synchronisierung für ein neues Gerät namens Whiz-Bang01 durchzuführen. Jetzt sollen die Administratoren die Entscheidung treffen, wie mit solchen Geräten umzugehen ist. Sie können sie zulassen, blockieren oder die Quarantäne fortsetzen. Da die Benutzer bereits versuchen, Verbindungen aufzubauen, liegt die Entscheidung tatsächlich zwischen Zulassung und Blockierung. Ist sie gefallen, wird sie mithilfe einer neuen ActiveSync-Zugriffsregel für Geräte umgesetzt. Solche Regeln geben Exchange die Möglichkeit, Geräte gezielt nach Typ oder Modell zu blockieren. Wollen wir den Zugriff erlauben, können wir eine Zugriffsregel folgender Art aufstellen: New-ActiveSyncDeviceAccessRule -QueryString 'Whiz-Bang01' -Characteristic DeviceModel -AccessLevel: Allow
Nun müssen wir die richtigen Werte ermitteln, mit denen ein neues mobiles Gerät beim Erstellen einer neuen ActiveSync-Zugriffsregel bezeichnet wird. Eine einfache Methode besteht darin, die in der Exchange-Systemsteuerung festgehaltenen Charakteristika für eine ActiveSync-Partnerschaft mit einem Postfach zu untersuchen. Wählen Sie im Telefonbereich der Exchange-Systemsteuerung Mobiltelefone und markieren Sie dann in der Liste der bekannten Geräte, die sich mit dem Postfach synchronisiert haben, das Gerät, das Sie prüfen wollen. Klicken Sie auf das Symbol Details, um Informationen wie in Abbildung 10.37 anzuzeigen. Abbildg. 10.37 Anzeige der Charakteristika eines mobilen Geräts in der Exchange-Systemsteuerung
616
Exchange ActiveSync
Zugriffsregeln lassen sich anhand des Gerätetyps, des Modells, des Benutzer-Agents oder des Betriebssystems formulieren. In diesem Beispiel sehen wir, dass das Gerät folgende Charakteristika aufweist: 쐍 Gerätename: iPAQ_900_Phone Clients
쐍 Gerätemodell: HP iPAQ Mobile Messenger 910 쐍 Gerätetyp: PocketPC 쐍 Gerätebetriebssystem: Windows CE 5.2.19202 Einige dieser Merkmale sind natürlich umfassender als andere. Erstellen Sie beispielsweise eine Zugriffsregel, die beliebige Geräte des Typs PocketPC zulässt, gilt sie für eine Vielzahl von PocketPCGeräten zahlreicher unterschiedlicher Hersteller. Eine andere Methode, die Charakteristika von Geräten festzustellen, die Verbindung mit ActiveSync aufnehmen, besteht darin, die ActiveSync-Einträge in den IIS-Protokollen auf dem Clientzugriffsserver zu durchsuchen. Sie sind recht deutlich. Der folgende zeigt zum Beispiel einen Benutzer, der über ein PocketPC-Gerät angebunden ist. 2010-03-04 17:27:39 16.234.42.1 POST /Microsoft-Server-ActiveSync/default.eas Cmd=Sync&DeviceId=5ECE2DBB684616DD07FB173DF09254B5&DeviceType=PocketPC
Und hier ein Eintrag für ein iPhone: 2010-03-04 00:03:49 16.234.42.1 POST /Microsoft-Server-ActiveSync/default.eas User=blackadder&DeviceId=Appl87945RZ53NP&DeviceType=iPhone&Cmd=Sync&Log
Android-Telefone zeigen den Gerätetyp Android. Um sie zu blockieren, eignet sich die folgende Zugriffsregel: New-ActiveSyncDeviceAccessRule -QueryString 'iPhone' -Characteristic DeviceType -AccessLevel Block
Nachdem wir die erforderlichen ActiveSync-Gerätezugriffsregeln erstellt haben, können wir sie mithilfe des Cmdlets Get-ActiveSyncDeviceAccessRule überprüfen. Die folgende Ausgabe zeigt beispielsweise, dass in der Organisation drei Zugriffsregeln vorhanden sind. Alle PocketPC-Geräte dürfen ebenso wie die Whiz-Bang01-Geräte Verbindung aufnehmen, SmartPhones werden jedoch blockiert. Get-ActiveSyncDeviceAccessRule | Format-Table Name, Characteristic, QueryString, AccessLevel -AutoSize Name ---Whiz-Bang01 (DeviceModel) PocketPC (DeviceType) SmartPhone (DeviceType)
Characteristic -------------DeviceModel DeviceType DeviceType
QueryString ----------Whiz-Bang01 PocketPC SmartPhone
AccessLevel -----------Allow Allow Block
Wird das Gerät eines Benutzers durch eine Zugriffsregel blockiert, darf es sich nicht synchronisieren. Außerdem kann es sein, dass eine neue Gerätezugriffsregel das Gerät vorläufig mit Quarantäne belegt, während Exchange auf die Entscheidung einer Person wartet, ob ihm die Synchronisierung erlaubt wird. In beiden Fällen erhält der Benutzer eine E-Mail, die ihm mitteilt, welches Problem vorliegt und was zu tun ist. Die in der Nachricht enthaltenen Informationen helfen dem Administrator,
617
Kapitel 10
Clients
die Situation zu verstehen, wenn der Benutzer Hilfe sucht. Dieser muss die Nachricht natürlich mit einem anderen Client lesen und entscheidet sich möglicherweise, den Administrator nicht nicht anzurufen, wenn er erkennt, dass er ein nicht genehmigtes Gerät verwendet. HINWEIS Die zeitweilige Quarantäne für ein Gerät kann bei Servern mit der ursprünglichen Version von Exchange Server 2010 bis zu 90 Minuten betragen; auf Servern mit SP1 ist sie auf etwa 15 Minuten reduziert. Der Text, den der Benutzer bei einer vorübergehenden Quarantäne bekommt, kann zum Beispiel wie folgt aussehen: Your phone can't synchronize with the server via Exchange ActiveSync until it's identified and its compliance with the access policies is verified. You may see synchronization errors on your phone while your phone is being recognized. If you see this sort of error, select mail as the only content to synchronize with Exchange and start synchronization from your mobile phone. Information about your mobile phone: Device type : iPhone Device ID : Appl5K2373BX7TR Device user agent : Apple-iPhone2C1/801.26000002 Exchange ActiveSync version : 14.0 Device access state : DeviceDiscovery Device access state reason : DeviceRule Sent at 5/10/2010 11:18:53 AM to [email protected].
In Exchange Server 2010 SP1 können Sie ActiveSync-Gerätezugriffsregeln über die Exchange-Systemsteuerung verwalten. Abbildung 10.38 zeigt die Regeln, an denen wir gearbeitet haben, sowie eine weitere, die den iPhone-Zugriff blockiert. Seit ihrer Einführung 2007 haben die iPhones von Apple einen immer größeren Markanteil erobert. Ich mag das iPhone und benutze täglich eines, hege also keine Vorbehalte gegen das Gerät. Apple lizenziert ActiveSync, d.h., dass Sie ein iPhone problemlos mit Exchange verbinden können. Die genauen Einzelheiten der Implementierung von ActiveSync auf einem Gerät sind jedoch vollständig dem Gerätehersteller vorbehalten, und die Apple-Implementierung für das iPhone führt nicht zu einer genauso sicheren Infrastruktur, wie sie sich mit Windows Mobile-Geräten erreichen lässt, weshalb einige Unternehmen den Zugriff über iPhones blockieren. Zum Ausgleich bietet Apple seinen Enterprise Deployment Guide an, der Unternehmen bei der Bereitstellung von iPhones hilft, und es gibt weitere Quellen, die Sie heranziehen können, um herauszufinden, wie Firmen mit iPhones umgehen können. Der MVP Jeff Guillet hat zum Beispiel einen hervorragenden Artikel über das Verfahren geschrieben, in einem Projekt eine sichere iPhone-Anbindung zu erreichen (siehe http://www.expta.com/2010/02/how-to-securely-deploy-iphones-with.html). In Blogs und Websites finden sich weitere Beispiele, die Sie durcharbeiten können, um zu ermitteln, ob die beschriebenen Vorschläge und Verfahren für Ihr Projekt von Wert sind.
618
Exchange ActiveSync
Clients
Abbildg. 10.38 Anzeigen von ActiveSync-Gerätezugriffsregeln in der Exchange-Systemsteuerung
Blockieren von Geräten nach Benutzern Um zu steuern, welche Gerätetypen mit ActiveSync verbunden werden dürfen, können Sie nicht nur Gerätezugriffsregeln aufstellen, sondern auch im Cmdlet Set-CASMailbox den Parameter –ActiveSyncAllowedDeviceIDs mit einer Liste von Gerätebezeichnern belegen, die Verbindung zu einem Postfach aufnehmen dürfen. Der Standardwert dafür lautet $Null, d.h., dass jedes beliebige Gerät mit einem Postfach synchronisiert werden kann. Der erste Schritt, um Geräte nach Benutzern zu blockieren, besteht im Ermitteln der Gerätebezeichner. Am einfachsten ist es, das Gerät dazu mit Exchange zu verbinden. Dann können Sie mithilfe des Cmdlets Get-ActiveSyncDeviceStatistics Einzelheiten über die ActiveSync-Aktivitäten von Benutzern einschließlich der Bezeichner für die jeweils verwendeten Mobilgeräte abrufen: Get-ActiveSyncDeviceStatistics –Mailbox 'Pelton, David'
In die Liste können Sie mehrere Gerätebezeichner aufnehmen, die Sie durch Semikola trennen. Der folgende Befehl erlaubt zum Beispiel nur einem einzigen Gerät die Synchronisierung mit David Peltons Postfach: Set-CASMailbox -Identity 'Pelton, David' –ActiveSyncAllowedDeviceIDs '4B9207650054671AD0AEE83A424BCD7F'
619
Kapitel 10
Clients
Den Gerätebezeichner können Sie mit folgendem Befehl löschen, um jedem beliebigen Gerät die Verbindung zum Postfach zu gestatten: Set-CASMailbox –Identity 'Pelton, David' –ActiveSyncAllowedDeviceIDs $Null
Wenn wir eine Geräteliste haben, aus der wir nur ein Gerät entfernen wollen, können wir die Liste in eine Variable exportieren, sie dort aktualisieren und dann mit Set-CASMailbox zurückschreiben: $Devices = Get-CASMailbox –Identity 'Pelton, David' $Devices.ActiveSyncAllowedDeviceIDs -= '4B9207650054671AD0AEE83A424BCD7F' Set-CASMailbox –Identity 'Pelton, David' –ActiveSyncAllowedDeviceIDs $Devices.ActiveSyncAllowedDeviceIDs
Mit derselben Technik lassen sich Geräte blockieren. In diesem Fall aktualisieren wir den Parameter –ActiveSyncBlockedDeviceIds mit Set-CASMailbox. Sie können beispielsweise für das Unternehmen die Entscheidung treffen, Android-Geräte zu blockieren, und anschließend feststellen, dass jemand mit einem solchen Gerät auf Exchange zugreift. Die weitere Synchronisierung lässt sich mit einer schnellen Ermittlung des Gerätebezeichners und dessen Eingabe in Set-CASMailbox verhindern.
Zurücksetzen von verloren gegangenen Geräten Es liegt in der Natur mobiler Geräte, dass manche auf Flughäfen, in Taxis, in Geschäften und an anderen Orten verloren gehen. Ebenso ist es kaum vermeidbar, dass ein Teil davon niemals wiedergefunden wird. Die Möglichkeit, das Gerät mit einem drahtlos übertragenen Befehl zurückzusetzen, ist deshalb erforderlich, um die auf dem Gerät abgelegten Daten zu schützen. Administratoren können zu diesem Zweck das Postfach in der Exchange-Verwaltungskonsole auswählen und dann die Option Mobiles Gerät verwalten benutzen oder das Cmdlet Clear-ActiveSyncDevice einsetzen. Benutzer können ein Gerät zurücksetzen, indem sie es mit der Option Mobiltelefone der Exchange-Systemsteuerung auswählen (siehe Abbildung 10.39). Diese Optionen stehen natürlich nur zur Verfügung, wenn der Benutzer sein Gerät zuvor mit dem Postfach synchronisiert hat, um es Exchange bekannt zu machen. Wenn ein Administrator oder ein Benutzer die Remotelöschung auslöst, sendet ActiveSync einen Rücksetzbefehl an das Gerät, das ihn dann lokal ausführt. Anschließend bestätigt der Client dem Server den Befehl und meldet Erfolg bzw. Fehlschlag. Das Ganze läuft wie folgt ab: Der Client verbindet sich mit ActiveSync. Der Client nennt seine Gerätekennung (DeviceID). Exchange erfragt Anmeldeinformationen für das Konto. Der Client authentifiziert sich mit Benutzername und Kennwort. Exchange prüft seine ActiveSync-Blockierliste darauf, ob das Gerät Verbindung aufnehmen darf (in dieser Phase geschieht noch mehr, zum Beispiel wird geprüft, ob die für das Gerät geltende Richtlinie aktualisiert werden muss). 6. Exchange prüft, ob ein Rücksetzbefehl für das Gerät in der Warteschlange steht, und löst diesen ggf. aus. 7. Das Gerät bestätigt den Rücksetzbefehl und meldet seinen Status.
1. 2. 3. 4. 5.
Beachten Sie, dass ein Remotebefehl zum Zurücksetzen an ein Gerät, das keine Rücksetzfunktion bietet, nicht ausgeführt werden kann, sodass die Daten erhalten bleiben. Die Synchronisierung weiterer Daten scheitert jedoch, sodass Sie zumindest verhindern können, dass das Gerät noch mehr sensible Daten empfängt. Dass Gerätetypen das Remotezurücksetzen in unterschiedlichem Maß beherrschen, 620
ist ein guter Grund, dieses Merkmal vor der Genehmigung der Bereitstellung zu prüfen. Wenn ein Gerät eine Rücksetzanforderung bestätigt, sendet ActiveSync eine Bestätigungsnachricht. Löst ein Benutzer den Befehl über OWA aus, empfängt er selbst die Bestätigungsnachricht; löst ein Administrator den Befehl aus, erhält sowohl er als auch der Benutzer, dem das Gerät gehört, eine Bestätigungsnachricht. Abbildg. 10.39 Optionen der Exchange-Systemsteuerung zum Zurücksetzen eines mobilen Geräts
VORSICHT Sie müssen sich unbedingt darüber klar sein, dass eine Remoterücksetzbefehl keine Daten auf Speicherkarten im Mobilgerät löscht, sondern nur Daten, die ActiveSync bekannt sind. Außerdem sollten Sie bedenken, dass sich das Gerät authentifizieren muss, bevor Exchange einen Rücksetzbefehl senden kann. Anders ausgedrückt: Es gibt keine Möglichkeit, ein gestohlenes Gerät zurückzusetzen, solange der Dieb nicht versucht, Verbindung mit Exchange aufzunehmen, um neue E-Mails herunterzuladen. Aus diesem Grund sollten Sie sichere Kennwörter und vielleicht sogar eine Verschlüsselung einsetzen, um sensible Unternehmensdaten auf mobilen Geräten zu schützen. Die Tatsache, dass sich ein Gerät authentifizieren muss, bevor ActiveSync-Kommunikation über Richtlinien möglich ist (was Rücksetzbefehle für Geräte einschließt), bringt die Frage mit sich, wie mit Personen umzugehen ist, die die Firma verlassen. Die meisten Unternehmen verfügen über ausgefeilte Verfahren, die die IT-Abteilung in solchen Fällen einsetzt. Üblicherweise besteht der erste Schritt darin, das Konto des Betroffenen zu deaktivieren oder sein Kennwort zu ändern, damit er sich nicht mehr an einem Firmensystem anmelden kann. Diese Methode eignet sich gut, um vertrauliche Informationen auf Firmensystemen zu schützen, erfasst jedoch nicht die Informationen, die der Mitarbeiter auf seinem Mobilgerät hat. Möglicherweise verlangt das Verfahren, dass er am Tag seines Ausscheidens sein Mobilgerät abgibt, aber was geschieht, wenn das Gerät sein Eigentum ist? Die offensichtliche
621
Clients
Exchange ActiveSync
Kapitel 10
Clients
Antwort lautet, dass Sie einen Rücksetzbefehl geben sollten, um wenigstens alle E-Mails zu löschen, was jedoch unmöglich ist, wenn Sie das Konto bereits deaktiviert haben, weil sich das Gerät dann nicht mehr authentifizieren kann. Daraus ergibt sich, dass Sie den Rücksetzbefehl auslösen und dafür sorgen müssen, dass er bestätigt wird, bevor das Konto des Mitarbeiters deaktiviert ist.
Fehlerbehebung in ActiveSync Was geschieht, wenn sich ein mobiles Gerät mit einem Exchange-Postfach synchronisiert, ist prinzipiell einfach, in der Ausführung aber kompliziert. Zwischen dem Zeitpunkt, an dem eine Nachricht in Outlook Mobile erstellt wird, und dem, an dem sie auf dem Server zum Senden übergeben wird, kann vieles falsch laufen. Wenn Probleme auftreten und der Benutzer um Hilfe bittet, kann der Administrator zusammen mit ihm die grundlegenden Schritte zur Problemlösung durchgehen, um sicherzustellen, dass die Verbindung funktioniert und auch keine anderen offensichtlichen Fehler vorliegen. Wenn das jedoch nichts bringt, ist es häufig eine Herausforderung, den Fehler zu ermitteln. Um die Problemlösung zu erleichtern, führt Exchange ActiveSync-Protokolle, die Einzelheiten des Zusammenspiels zwischen Mobilgerät und Exchange festhalten. Diese Protokolle beschreiben die Ereignisse, die beim Verbinden des Geräts und beim Abrufen von Informationen stattfinden. Standardmäßig ist die Protokollierung ausgeschaltet. Tritt bei einem Gerät ein Problem auf, muss der Benutzer in den Mobiltelefonoptionen auf Protokollierung starten klicken, damit Exchange Ereignisse aufzeichnet. Sobald er es geschafft hat, das Problem zu reproduzieren, kann er die Protokollierung beenden, woraufhin Exchange ihm das ActiveSync-Protokoll als Nachrichtenanhang sendet (siehe Abbildung 10.40). Abbildg. 10.40 Exchange übergibt ein ActiveSync-Postfachprotokoll für ein Mobilgerät.
ActiveSync-Protokolle werden im XML-Format erstellt (siehe Abbildung 10.41), und es dauert eine Weile, sie zu deuten. Sie sind eigentlich nicht für die Nutzung durch Administratoren gedacht, sondern als Diagnosewerkzeug für Supportmitarbeiter bei Microsoft, die Zugriff auf die kodierten Informationen in einem Protokoll haben und deshalb herausfinden können, was sich während der Verbindung zwischen einem Gerät und Exchange abgespielt hat.
622
Exchange ActiveSync
Clients
Abbildg. 10.41 Anzeige eines ActiveSync-Postfachprotokolls
Testen der mobilen Anbindung Microsoft stellt eine Reihe von Emulator-Images für Windows Mobile 6.1-, Windows Mobile 6.5- und Windows Phone 7-Geräte bereit, die Sie herunterladen können, um die Anbindung mobiler Geräte zu testen (suchen Sie nach »Windows Mobile Emulator Images«). Diese Emulatoren lassen sich in Microsoft Virtual PC laden und mit Ihrem Netzwerk verbinden, um zu prüfen, ob ActiveSync erwartungsgemäß arbeitet. Wenn Sie eine umfangreiche ActiveSync-Bereitstellung betreiben, ist es günstig, diese Emulatoren einzurichten, um sie mit neuen Rollupreleases und Service Packs für Exchange zu testen und sicherzustellen, dass die neue Serversoftware keine Probleme hervorruft.
ActiveSync für BlackBerry Nach der herkömmlichen Methode werden BlackBerry-Mobilgeräte durch die Bereitstellung von BlackBerry Enterprise Server (BES) der Firma RIM mit Exchange verbunden. Es gibt zwar keinen Zweifel, dass BES funktioniert, aber die Lizenzierung ist teuer, und es ist eine separate Serverinfrastruktur erforderlich. Außerdem greift BES standardmäßig über MAPI auf Exchange-Postfächer und Verzeichnisinformationen zu und kann einen Postfachserver erheblich belasten, wenn es zum Abrufen und Senden von Nachrichten Verbindung aufnimmt. Unter bestimmten Bedingungen kann die Belastung, die ein BlackBerry-Benutzer auslöst, dreimal so hoch sein wie die durch einen OutlookBenutzer (oder sogar höher). (Neuere BES-Versionen unterstützen die alternative Verwendung der Exchange-Webdienste, was die Leistung verbessert, aber den BES-Administrator etwas mehr Arbeit kostet.) Die Technologie ändert sich ständig, und heute gibt es Lösungen, die zur Verbindung von BlackBerry-Geräten mit Exchange das ActiveSync-Protokoll benutzen (beispielsweise www.astrasync.com). ActiveSync ist Bestandteil von Exchange, sodass keine weitere BES-Software lizenziert oder zusätzliche Hardware bereitgestellt werden muss. Das Leistungsprofil eines ActiveSync-Clients liegt unter
623
Kapitel 10
Clients
dem eines BlackBerry. Wenn Leistung ein Problem darstellt, kann ein Wechsel zu ActiveSync dies möglicherweise beheben. Ein weiterer Vorteil liegt darin, dass ein solcher Wechsel die Infrastruktur vereinfacht, weil dann sämtliche Mobilgeräte ein einziges Protokoll verwenden, das sich mit Exchange verwalten lässt. Sie können zum Beispiel über die Exchange-Verwaltungsshell oder die Exchange-Verwaltungskonsole ein Postfach für ActiveSync aktivieren oder deaktivieren, während für BES ein eigenes Verwaltungsprogramm erforderlich ist. Den potenziellen Einsparungen steht die Notwendigkeit entgegen, ActiveSync-Clientsoftware zu kaufen und bereitzustellen, die Kosten sind jedoch erheblich geringer als die Einsparungen. Insidertipp: Kosten-Nutzen-Analyse für die Aktualisierung
Niemand sollte ohne guten Grund von einer funktionierenden Lösung Abstand nehmen. Administratoren, die wissen, wie BES funktioniert, und die erforderlichen Kenntnisse haben, um die vollständige Client-Server-Kommunikation von Anfang bis Ende zu handhaben, vielleicht mit Programmen wie MobileManager von Zenprise, sind möglicherweise nicht gern bereit, eine Veränderung ins Auge zu fassen, wenn sie mit der Herausforderung einer Aktualisierung auf Exchange Server 2010 konfrontiert werden. Da eine neue BES-Version bereitgestellt werden muss, die Exchange Server 2010 unterstützt, und da die meisten Benutzer ihre Mobilgeräte regelmäßig austauschen, bietet ein Exchange-Aktualisierungsprojekt die Gelegenheit zu einer Kosten-NutzenAnalyse, die sämtliche Vor- und Nachteile eines Wechsels zu ActiveSync aufzeigt.
Einschränken von Clients Clients können gelegentlich eine umfangreiche Belastung auf einem Exchange Server-Computer verursachen. Dafür kann es viele verschiedene Gründe geben, aber meistens haben Sie es mit irgendeinem Softwarefehler zu tun, der dazu führt, dass der Client in nicht vorhersehbarer Weise kommuniziert und dadurch eine außergewöhnliche Belastung hervorruft. Die bei früheren Versionen übliche Maßnahme bestand darin, zuerst mithilfe des Dienstprogramms Exchange User Monitor (ExMon) den fehlerhaft arbeitenden Client zu ermitteln und dann dessen Verbindung zu beenden, um die Serverbelastung zu reduzieren und für andere Clients wieder normale Reaktionsgeschwindigkeiten herzustellen. Anschließend konnte ermittelt werden, wodurch der Client das Problem ausgelöst hatte, und das Problem behoben werden. ExMon zählt zu den unschätzbaren von Microsoft-Technikern entwickelten Dienstprogrammen, die als Teil der Toolbox in das offizielle Produkt aufgenommen werden sollten. Im Augenblick müssen Sie es von der Microsoft-Website herunterladen. ExMon funktioniert auf Computern mit Exchange Server 2003, Exchange Server 2007 und Exchange Server 2010 und erlaubt Administratoren, Einzelheiten über die Clients einzusehen, die gerade mit dem Server verbunden sind, darunter die IP-Adresse und die Softwareversion. Exchange Server 2010 führt das Konzept der Einschränkung von Clients ein, damit Administratoren die Ressourcen aktiver verwalten können, indem sie Richtlinien definieren, die steuern, welche Ressourcen die Benutzer jeweils in folgenden Kategorien belegen können: 쐍 ActiveSync (EAS) 쐍 RPC-Clientzugriff (RCA; wird für MAPI-Clients wie Outlook eingesetzt) 쐍 Outlook Web App (OWA) 쐍 POP3 (POP) 쐍 IMAP4 (IMAP)
624
Einschränken von Clients
쐍 Exchange-Webdienste (EWS; diese Kategorie umfasst Benutzer von Unified Messaging und solche, die Entourage oder Outlook unter Mac OS X betreiben) Bei der Installation von Exchange Server 2010 wird automatisch eine Standardrichtlinie erstellt und innerhalb der Organisation durchgesetzt. Sie wird wirksam, wenn der Prozentsatz der Prozessornutzung durch Exchange die in ihrer Eigenschaft CPUStartPercent definierte Schwelle überschreitet. Die Einstellung gilt pro Dienst und hat den Standardwert 75. Sobald einer der zur Clienteinschränkung überwachten Exchange-Dienste diese Schwelle erreicht, beginnt Exchange, die Einschränkungen anzuwenden, die in der Standardrichtlinie oder für ein einzelnes Postfach festgelegt sind, um sicherzustellen, dass der Server weiterhin allen Clients einen einigermaßen reibungslosen Dienst bieten kann. Einschränkungsrichtlinien lassen sich nur über die Exchange-Verwaltungsshell handhaben. Einzelheiten der Standardrichtlinie können Sie mit folgendem Befehl anzeigen: Get-ThrottlingPolicy | Where {$_.IsDefault –eq $True} | Format-Table
Untersuchen Sie die Attribute einer Einschränkungsrichtlinie, so stoßen Sie auf eine Vielzahl von Daten, die Sie jedoch in die bereits aufgeführten Kategorien unterteilen können. Die ersten sechs stehen für Clientprotokolle und sind mit dem in Klammern genannten Präfix gekennzeichnet. Wir können also Einstellungen für MAPI-Clients mit dem folgenden Befehl abrufen: Get-ThrottlingPolicy | Select RCA* | Format-List RCAMaxConcurrency RCAPercentTimeInAD RCAPercentTimeInCAS RCAPercentTimeInMailboxRPC
: 20 : : :
Die Ausgabe der Parameter für den RPC-Clientzugriff besagt, dass gegenwärtig nur ein Schwellenwert in Kraft ist, die die Belastung durch Benutzer in der RPC-Clientzugriffsschicht steuert. Die Anzahl der gleichzeitigen Sitzungen pro Benutzer ist auf 20 gesetzt (der Bereich geht von 0 bis 100), d.h., ein Benutzer kann bis zu 20 aktive Sitzungen mit einem Clientzugriffsserver unterhalten. Eine Verbindung wird von dem Augenblick an mitgezählt, in dem eine Anforderung zu ihrer Einrichtung ergeht, bis zu dem Moment, in dem sie durch eine Aktion des Benutzers geschlossen oder anderweitig getrennt wird (Abmeldung). Versucht ein Benutzer, mehr Verbindungen zu erstellen als erlaubt, scheitert er. Die übrigen Grenzen sind auf $Null gesetzt, was bedeutet, dass keine Einschränkungen vorliegen. Im Grunde heißt es, dass der Benutzer die betreffenden Ressourcen nutzen kann, bis sie erschöpft sind. Diese Einstellungen steuern, wie viel Zeit ein Benutzer hat, um LDAP-Anforderungen an Active Directory, Clientzugriffscode und RPC-Anforderungen an Postfächer auszuführen. Die Werte können von 0 bis 100 reichen; es handelt sich um den Prozentsatz eines einminütigen Fensters, den der Client in dem betreffenden Modus verbringen kann. Es ist möglich, 100% zu überschreiten, weil ein Client gleichzeitige Anforderungen auslösen kann, die jeweils hohe Ansprüche stellen. Die Gesamtbelastung würde Exchange zwingen, die Last für den betreffenden Client einzuschränken. Da RPC-Anforderungen an Postfächer sowie LDAP-Anforderungen über den Clientzugriffsserver laufen, also dessen Ressourcen in Anspruch nehmen, folgt daraus, dass die Einstellung für den Clientzugriffsserver (PercentTimeCAS) eine überlappende Obermenge der Postfach- und Active Directory-Einstellungen ist und ihr Wert also höher sein sollte als der für Postfächer und Active Directory.
625
Clients
쐍 Windows PowerShell
Kapitel 10
Clients
Ähnliche Gruppen von Einstellungen gibt es für die anderen Clientkategorien. Diejenigen für die Exchange-Webdienste finden Sie mit dem folgenden Befehl: Get-ThrottlingPolicy | Select EWS* | Format-List
Fehlerbehebung: Exchange schränkt BES-Aktivitäten ein
Die Einführung der Clienteinschränkung hatte eine unglückliche Nebenwirkung auf einige Anwendungen, die Exchange stark beanspruchen. Das beste Beispiel dafür ist BES, weil das davon benutzte Konto im Grunde einen hyperaktiven Benutzer nachahmt, der auf mehrere Postfächer zugreift, um mit mobilen Geräten zu kommunizieren. Das übliche Problem bestand darin, dass Exchange die BES-Aktivitäten einschränkte, weil sie den Schwellenwert für Remoteclientzugriff überschritten. Als Lösung wurde eine neue Einschränkungsrichtlinie erstellt, die den Wert des Parameters –RCAMaxConcurrency auf $Null setzt, und auf das BES-Konto angewendet. Diesen Schritt kann der Administrator nach der Installation von BES vornehmen. Zur Steuerung der Belastung durch Windows PowerShell steht eine ganze Reihe von Parametern zur Verfügung: 쐍 –PowerShellMaxConcurrency (Standardwert 18) Diese Einschränkung wird auf zwei Arten angewendet. Sie definiert die maximale Anzahl von PowerShell-Remotesitzungen, die ein Benutzer auf einem Server gleichzeitig geöffnet haben kann, außerdem die maximale Anzahl von Cmdlets, die die Exchange-Verwaltungsshell gleichzeitig ausführen kann. 쐍 –PowerShellMaxCmdlets (standardmäßig keine Einschränkung) Legt fest, wie viele Cmdlets ein Benutzer innerhalb der von –PowerShellMaxCmdletsTimePeriod definierten Zeit ausführen kann. Wird der Wert überschritten, können bis zum Ablauf des Zeitraums keine weiteren Cmdlets mehr ausgeführt werden. 쐍 –PowerShellMaxCmdletsTimePeriod (standardmäßig kein Wert) Der Messzeitraum in Sekunden, in dem Exchange feststellt, ob die maximale Anzahl der vorhergehenden Einschränkung überschritten wurde. 쐍 –ExchangeMaxCmdlets (standardmäßig keine Einschränkung) Legt fest, wie viele Cmdlets ein Benutzer innerhalb der von –PowerShellMaxCmdletsTimePeriod definierten Zeit ausführen kann. Nach dem Überschreiten des Schwellenwerts verlangsamt Exchange die Ausführung weiterer Cmdlets. 쐍 –PowerShellMaxCmdletQueueDepth (standardmäßig keine Einschränkung) Gibt an, wie viele Operationen Exchange einem Benutzer auszuführen erlaubt. Bei der Ausführung von Cmdlets werden Operationen verbraucht, ebenso bei internen Abläufen (das Cmdlet –PowerShellMaxConcurrency benötigt beispielsweise zwei Operationen). Microsoft empfiehlt für diesen Wert, wenn er denn gesetzt wird, das Dreifache von –PowerShellMaxConcurrency. Auf den Code, den die Exchange-Systemsteuerung und die Exchange-Webdienste ausführen, wendet Exchange diese Einschränkung nicht an. Zur Begrenzung des Verbrauchs allgemeiner Ressourcen dienen drei weitere Einstellungen: 쐍 –MessageRateLimit (standardmäßig keine Einschränkung) Legt fest, wie viele Nachrichten ein Benutzer dem Transportsystem pro Minute zur Verarbeitung übergeben kann. Nachrichten, die den Grenzwert überschreiten, werden im Postausgang des Benutzers abgelegt, bis der Server sie entgegennehmen kann. Davon ausgenommen sind Clients wie POP3 und IMAP4, die Nachrichten über SMTP direkt an das Transportsystem übermitteln. Versuchen diese, zu viele Nachrichten zu übergeben, wird ihre Anforderung abgelehnt, und sie sind gezwungen, es später erneut zu versuchen. 626
Einschränken von Clients
쐍 –ForwardeeLimit (standardmäßig keine Einschränkung) Legt eine Grenze für die Anzahl von Empfängern fest, die in den Regeln für den Posteingang zum Weiter- oder Umleiten eingerichtet werden können. Insidertipp: Speichern des Bezeichners für die Standardeinschränkungsrichtlinie in einer Variable
Sie werden feststellen, dass die Standardrichtlinie für Einschränkungen als Namen und Bezeichner einen Wert folgender Art bekommt: DefaultThrottlingPolicy_dade6c60-e9cc-4692-bc6a-71771158a 82f. Ich habe den Verdacht, dass sich die Microsoft-Entwickler dabei einen Scherz mit uns erlaubt haben, weil kein vernünftiger Mensch glauben kann, ein solcher Name sei verständlich. Falls Sie mit einer Richtlinie arbeiten möchten, können Sie den Wert in einer Variable speichern und diese als Verweis auf die gewünschte Richtlinie verwenden: $TP = (Get-ThrottlingPolicy).Identifier Set-ThrottlingPolicy –Identity $TP -EWSPercentTimeInCAS 80
Wenn Sie mithilfe des Cmdlets New-ThrottlingPolicy eine Richtlinie erstellen, erbt sie die Werte der Standardrichtlinie. Sie brauchen nur noch die Werte für die Einstellungen festzulegen, die Sie ändern wollen: New-ThrottlingPolicy –Name 'Restricted CAS Access' –RCAMaxConcurrency 10
Um die neue Richtlinie in Kraft zu setzen, können wir sie zum Standard machen: Set-ThrottlingPolicy –Identity 'Restricted CAS Access' –IsDefault $True
Wir können sie stattdessen auch gezielt auf einzelne Benutzer anwenden: Set-Mailbox –Identity 'David Jones' –ThrottlingPolicy 'Restricted CAS Access'
In Exchange Server 2010 SP1 wurde die Clienteinschränkung aufgrund von Rückmeldungen aus der Praxis verbessert. Wenn in der RTM-Version ein Client eingeschränkt wird, kommt es dazu, dass Anforderungen von Serverdaten scheitern, was die Benutzer verärgert, weil etwas nicht richtig oder erwartungsgemäß funktioniert. In SP1 werden Anforderungen, die der Server einschränkt, in eine Warteschlange eingestellt und verzögert, aber ihre Verarbeitung scheitert nicht. Sie werden zurückgestellt, sodass sie einige Millisekunden warten müssen, bevor der Server versucht, sie erneut zu verarbeiten. Nach Ablauf der Wartezeit ist die Notwendigkeit der Einschränkung hoffentlich vorbei, sodass die Clientanforderung normal verarbeitet werden kann.
Unified Messaging Unified Messaging ist ein Thema, das ein eigenes Buch verdient, um die zahlreichen Fragen zu behandeln, die bei der Umsetzung von Exchange-Voicemails als Ersatz für ein herkömmliches, an eine Nebenstellenanlage angeschlossenes Voicemail-System zu berücksichtigen sind. Die Teams, die im Unternehmen für Telekommunikation und Messaging zuständig sind, müssen sich gewöhnlich gut 627
Clients
쐍 –RecipientRateLimit (standardmäßig keine Einschränkung) Legt fest, wie viele Empfänger innerhalb von 24 Stunden angesprochen werden können. Beträgt dieser Wert zum Beispiel 1000, darf der Benutzer täglich Nachrichten an 1000 Empfänger senden. Überzählige Nachrichten werden abgelehnt.
Kapitel 10
Clients
absprechen und koordinieren, damit auch Fragen wie Wählpläne geklärt werden. Firmen wie Nortel und Cisco hatten in früheren Versionen ihrer Produkte die Integration von Voicemail in Exchange angeboten, Exchange Server 2007 enthält jedoch die erste Voicemail-Lösung von Microsoft, die gezielt für die Zusammenarbeit mit Exchange, Outlook und OWA erstellt wurde und sich in eine Gesamtstrategie für Unified Communications einfügen kann. Der softwaregestützte Ansatz von Microsoft unterscheidet sich von dem hardwaregestützten Ansatz der herkömmlichen Telekommunikationsanbieter und legt den Schwerpunkt auf TCP/IP-Kommunikation und offene Standards. Daraus ergeben sich geringere Kosten und eine offenere Plattform, als es für Voicemail-Systeme bisher möglich war. In Exchange hat Microsoft zahlreiche Aspekte von UM verändert, um die Kundenerfahrungen bei der Bereitstellung von UM in Exchange Server 2007 zu berücksichtigen. Dort gab es nur drei verschiedene Audio-Codecs: WMA, GSM 06.10 und GSM G.711. Sie konnten einen Codec für einzelne Benutzer wählen, aber keiner davon eignete sich besonders für Geräte ohne Windows Mobile. Exchange Server 2010 erweitert die Skala unterstützter Audio-Codecs um MP3, das jetzt als Standard für Voicemails dient. Da MP3 von so vielen unterschiedlichen Geräten und Anwendungen verwendet wird, verbessert die Nutzung von MP3 als Standard die Möglichkeit der Benutzer, geräteübergreifend mit Voicemails zu arbeiten. Die zweite wesentliche Verbesserung in Exchange Server 2010 ist die Einführung der Voicemail-Vorschau. Es ist ein interessanter Versuch, den Benutzern den Inhalt von Voicemails leichter zugänglich zu machen, wenn sie eine Nachricht nicht abspielen können. Das Übertragen von Voicemails in Text stellt eine Herausforderung an die Informatik dar und verlangt genaue Kenntnisse der Sprache und Kultur, weshalb diese Funktion einen eigenen Abschnitt wert ist.
Voicemail-Vorschau Die Voicemail-Vorschau ist die Funktion, die Sprachnachrichten in Textform umsetzt, sodass sie auf dem Bildschirm zu lesen sind, was besonders für mobile Geräte sinnvoll ist, um festzustellen, ob eine schnelle Antwort an den Absender erforderlich ist. Das einzige Problem besteht darin, dass die Transkriptionsalgorithmen gelegentlich Text erzeugen, der die Bedeutung oder die Absicht der Nachricht nicht richtig wiedergibt. Alle Systeme, die gesprochene Sprache integrieren, stehen vor der Herausforderung, die Bedeutung des Gesagten zu erfassen, da selbst Menschen, die dieselbe Sprache sprechen, in Tonfall, Betonung und Satzbau voneinander abweichen und sogar Wörter oder Wendungen aus anderen Sprachen einfließen lassen. Häufig stellen Namen eine besondere Schwierigkeit dar, insbesondere, wenn sie für die erwartete Sprache »ausländisch« klingen. Der Code versucht, das gesprochene Wort zu bereinigen, indem er Pausen und Äußerungen wie »ehm« entfernt, die beim Sprechen häufig vorkommen. Natürlich hat es keinen Sinn, eine Voicemail-Vorschau anzubieten, wenn jedes zweite Wort nicht erkannt wird. Wie gut computergenerierter Text für den Empfänger verständlich ist, unterscheidet sich jedoch von Sprache zu Sprache. Englisch ist voll von Slang, englische Begriffe und englischer Slang wandern in immer zahlreichere Sprachen ein. Die automatische Transkription von einem Stand, bei dem 50% der Wörter erkannt werden (dabei wird eine halbwegs akkurate Version der Nachricht erreicht), auf 80% oder mehr zu bringen (das ergibt eine fast vollständig genaue Nachricht), erfordert es, die Umsetzung echter Nachrichten zu testen, die Benutzer zu verstehen suchen. Wie die Benutzer die Genauigkeit der Textübertragung einschätzen, hängt davon ab, wie brauchbar der vom Computer erzeugte Text ist. Kann der Benutzer Bedeutung und Wichtigkeit des Inhalts verstehen, hält er die Transkription wahrscheinlich für ziemlich akkurat. Sobald wichtige Wörter jedoch
628
Einschränken von Clients
HINWEIS Das Wort »Vorschau« im Namen dieser Funktion spricht für sich, denn für ein Allzweck-E-Mail-System wäre es unverhältnismäßig, eine absolut genaue Wiedergabe des Nachrichteninhalts bereitzustellen. Die Voicemail-Vorschau bietet dem Benutzer eine schnelle Möglichkeit, den Kern einer Nachricht zu verstehen, ohne sich alles anhören zu müssen. Es soll keine Entschuldigung für die Technologie sein, aber es ist wahr, dass Menschen häufig Schwierigkeiten haben, den Inhalt einer Voicemail von jemandem mit einem ungewöhnlichen Akzent, nicht vertrautem Slang oder technischen Termini zu verstehen – stellen Sie sich vor, wie schwer es erst sein muss, Code zu schreiben, der genau umsetzt, was jemand sagt. Eine weitere Schwierigkeit liegt darin, dass ein Allzweckcomputer mit Windows keine Möglichkeit hat, die vom Absender einer Voicemail gesprochene Sprache zu ermitteln. Er kann etwas annehmen, was aber nicht zutreffen muss. Bevor ein Computer überhaupt eine Chance hat, das in einer Sprachnachricht Gesagte zu verstehen, ist sehr viel Analyse und Interpretation einer erheblichen Menge echter Nachrichten erforderlich, um zu erfassen, wie Menschen miteinander kommunizieren. Je mehr Nachrichten es sind und je mehr Themen sie abdecken, desto größer ist die Genauigkeit der Voicemail-Vorschau. Nachrichten der erforderlichen Menge und Variationsbreite zu beschaffen, um deren Inhalt transkribieren und sie zur Prüfung der vom Computer erzeugten Ausgabe einsetzen zu können, ist der wesentliche Hinderungsgrund für Microsoft, die Voicemail-Vorschau für mehr Sprachen bereitzustellen. Tests und Prüfungen in erschreckender Menge müssen durchgeführt werden, bevor die Voicemail-Vorschau eine Sprache einbeziehen kann. Folgende Faktoren haben Einfluss auf die Entscheidung von Microsoft, eine Sprache einzubeziehen: 쐍 Sind genügend Tests gelaufen, um eine hohe Genauigkeitsrate für die Transkription der Sprache gewährleisten zu können? 쐍 Wie brauchbar ist der in der Vorschau erzeugte Text? 쐍 Wie gut eignet sich die Sprache oder Kultur für die maschinelle Transkription? Exchange Server 2010 RTM bietet eine Voicemail-Vorschau für folgende Sprachen: 쐍 Englisch (US- und kanadisches Englisch, aber kein britisches und australisches Englisch und keine lokalen Dialekte) 쐍 Französisch 쐍 Italienisch 쐍 Portugiesisch 쐍 Polnisch Mit Exchange Server 2010 SP1 kommt Spanisch dazu (wie es in Spanien gesprochen wird, nicht wie in Lateinamerika). Falls Ihre Sprache in der Liste für die Voicemail-Vorschau steht, werden Sie wahrscheinlich feststellen, dass der von Exchange zur Deutung von Voicemail-Nachrichten eingesetzte Algorithmus Text mit einem einigermaßen hohen Maß an Genauigkeit ausgibt. Es reicht von hohen 90% bis zu wesentlich geringeren Werten, je nachdem, wie deutlich die Benutzer in der Voicemail sprechen, welches Gerät sie verwenden, ob im Hintergrund Wind oder andere Geräusche zu hören sind usw. – es gibt noch
629
Clients
ausgelassen oder verstümmelt werden, nimmt das Verständnis ab, und selbst eine Genauigkeitsrate von 85% (gemessen an der Anzahl der korrekt transkribierten Wörter) wird möglicherweise als ziemlich unbrauchbar angesehen.
Kapitel 10
Clients
zahlreiche andere Einflussfaktoren. Gelegentlich wirkt der erzeugte Text komisch, aber meistens ist er akzeptabel, selbst wenn sich ein paar Fehler einschleichen. Kein Algorithmus kann Klingonisch oder andere abseitige Sprachen verarbeiten, aber Sie erhalten gute Ergebnisse, wenn Sie darum bitten, bei Voicemails möglichst deutlich zu sprechen. Ignorieren Ihre Gesprächspartner diesen Rat, können Sie allerdings einen Wettbewerb starten, um die lustigste von Exchange erzeugte Voicemail-Vorschau zu finden. Sollten Sie überhaupt nicht mit der Voicemail-Vorschau zurechtkommen, können Sie sie als UM-aktivierter Benutzer in den über OWA erreichbaren Optionen ausschalten. Voicemail-Vorschauen werden beim Eintreffen von Nachrichten erzeugt. Dieser Zeitpunkt bietet gegenüber der späteren Erstellung mithilfe von Hintergrundverarbeitung eine Reihe von Vorteilen. Die Vorschau steht sofort zur Verfügung, wenn die Nachricht im Benutzerpostfach eingeht, und kann in zahlreichen Schnittstellen angezeigt werden, auch auf mobilen Geräten, damit die Benutzer entscheiden können, ob die Nachricht wichtig ist. Microsoft glaubt, 90% des Wertes der Vorschau liege in der sofortigen Verfügbarkeit. Da die Vorschau zum Bestandteil der eingehenden Nachricht wird, kann ihr Text in Benachrichtigungen verwendet und von Regeln verarbeitet werden. Die Suche von Voicemails und das Erstellen der Vorschau im Hintergrund zu erledigen, würde zwar funktionieren, aber eine erhebliche Zusatzbelastung für die Postfachserver darstellen. Die Rechenleistung zum Erstellen von Voicemail-Vorschauen in Echtzeit erzwingt einige Kompromisse bei der Transkription. Die Umsetzung in Textform ist eine prozessorintensive Aktivität, die für jede Sekunde gesprochenen Inhalts etwa eine Sekunde Verarbeitung im Prozessorkern benötigt. Um zu verhindern, dass eine einzelne Nachricht zu viele Prozessorressourcen an sich reißt, versucht Exchange nicht, Nachrichten von mehr als 75 Sekunden zu transkribieren. Deshalb lohnt es sich für den Absender, seine Nachrichten kurz und aussagekräftig zu halten. Anhand der Regel, dass pro Sekunde Voicemail eine Sekunde Verarbeitung im Prozessorkern erforderlich ist, können wir berechnen, dass ein Server mit vier Kernen dauerhaft pro Minute vier 60-Sekunden-Nachrichten transkribieren kann. In Spitzenzeiten der Benutzeraktivität im Tageslauf kommen wahrscheinlich mehr Voicemails an, als Exchange zur Vorschau verarbeiten kann, sodass die Transkriptionsaktivitäten eingeschränkt werden, sobald der UM-Server stark belastet ist, um Rückstände zu vermeiden und sicherzustellen, dass die Benutzer ihre Voicemails möglichst schnell erhalten. Die ITAbteilung von Microsoft betreibt beispielsweise vier UM-Server mit insgesamt 24 Kernen. Das Exchange-Team hat ermittelt, dass diese Server während einer Fünftagewoche 236.269 Voicemails verarbeitet haben. Bei einem achtstündigen Arbeitstag ergibt das etwa hundert eingehende Voicemails pro Minute oder etwa vier Nachrichten für jeden verfügbaren Prozessorkern. Bei Microsoft dauert eine durchschnittliche Voicemail 30 Sekunden, sodass nur zwei davon transkribiert werden können und zwei ohne Vorschau übermittelt werden müssen. Dabei handelt es sich natürlich um Durchschnittswerte, und zu bestimmten Zeiten werden sämtliche Voicemails mit Vorschau übermittelt, während es in Spitzenzeiten weniger als die Hälfte sind. Die Einstellungen, die die Umsetzung steuern, befinden sich in der Konfigurationsdatei MSExchangeUM.config, in der Sie Werte wie TranscriptionMaximumMessageLength (die längste Nachricht, die Exchange noch transkribiert) und TranscriptionMaximumBacklogPerCore (maximale Anzahl von Nachrichten, die Exchange für die Transkription in die Warteschlange verschiebt, Standardwert 5) finden. Sie können die Werte der Konfigurationsdatei ändern, um die Funktionsweise von UM anzupassen, sollten dabei aber Folgendes berücksichtigen:
630
Einschränken von Clients
쐍 Zwischen den UM-Servern findet keine Replikation der Konfigurationswerte statt, sodass Änderungen manuell auf alle UM-Server übertragen werden müssen. 쐍 Die nächste Exchange-Aktualisierung überschreibt wahrscheinlich die geänderten Werte. 쐍 Die Änderungen können die Leistung der UM-Server in nicht vorhersehbarer Weise beeinflussen (siehe die vorhergehende Erörterung). 쐍 Microsoft hat umfangreiche Tests vorgenommen, um die optimalen Einstellungen zu ermitteln. Eine typische Voicemail dauert zum Beispiel zwischen 25 und 30 Sekunden. Eine, die 75 Sekunden lang ist, enthält wahrscheinlich Geschwafel, ist möglicherweise zusammenhanglos und übermittelt Informationen, die nicht wesentlich für das Unternehmen sind, beispielsweise eine Frage nach dem Gesundheitszustand des Gesprächspartners. Müssen Sie Benutzer wirklich ermuntern, Computerressourcen für das Verarbeiten und Speichern verbaler Ergüsse ohne große Bedeutung zu verschwenden? Manchen Firmen macht es nichts aus, dass einige Nachrichten ohne Vorschau eingehen. Wenn ihre dazugehört, können Sie sich auf die Kapazität beschränken, die für die durchschnittliche UM-Last ausreicht. Wollen Sie jedoch gewährleisten, dass jede Voicemail mit einer Vorschau versehen wird, müssen Sie ausreichend Prozessorkapazität bereitstellen, um die zu erwartende Spitzenlast zu verarbeiten, und zusätzlich einen gewissen Prozentsatz für noch höhere Spitzen und Wachstum vorsehen. Die rechnerintensive Natur der Transkription macht UM-Server mit Exchange Server 2010 zu schlechten Kandidaten für eine Virtualisierung, weshalb Microsoft empfiehlt, für diese Server Standardcomputer zu verwenden. Nach dem Transkribieren speichert Exchange den Inhalt der Voicemail-Vorschau als XML-Eigenschaft der Nachricht. Der XML-Inhalt enthält Informationen wie die Länge der Voicemail, die Zuverlässigkeit der Transkription (für wie genau Exchange den Inhalt der Vorschau hält) und Telefonnummern. Kann Exchange den Absender erkennen, zeichnet es auch Information darüber für die Anzeige in Outlook auf. Abbildung 10.42 zeigt ein gutes Beispiel dafür, wie der Benutzer eine Voicemail-Vorschau sieht. Es ist eine echte Nachricht, die ich für einen Mitarbeiter hinterlassen habe, nachdem ich einen Anruf des Entwicklungsteams zur Erörterung einiger technischer Hintergrundaspekte der Voicemail-Transkription abgehört hatte. Ich habe versucht, einige wichtige Dinge über die Besprechung zu übermitteln, aber bei der Transkription sind einige Wörter verloren gegangen, möglicherweise wegen meines Akzents (ein irischer Akzent, der durch langen Aufenthalt in den USA abgeschwächt wurde, stellt für das auf amerikanisches Englisch ausgelegte Transkriptionsmodul eine echte Herausforderung dar). Aus »Unified Messaging people at Microsoft« wurde zum Beispiel »you know five messaging people at Microsoft«, was nicht ganz dem Gesagten entspricht. Trotzdem ist der Text gut genug, um die Aufmerksamkeit des Lesers zu erregen und ihn vielleicht dazu zu bringen, mich zurückzurufen, was ich als Anrufender erreichen wollte.
631
Clients
쐍 Microsoft unterstützt keine Änderungen. Bei Problemen müssen Sie also zu den Originalwerten zurückkehren, um zu ermitteln, ob das Problem trotzdem auftritt, bevor Sie sich an den Support von Microsoft wenden können.
Kapitel 10
Clients
Abbildg. 10.42 Die Voicemail-Vorschau in Aktion
Fax-Integration Anders als in Exchange Server 2007 gibt es in Exchange Server 2010 keine Möglichkeit, aus eingehenden Faxen neue Nachrichten zu erstellen, weil Microsoft festgestellt hat, dass nicht viele Kunden diese Funktion verwendet haben, und sich entschlossen hat, diesen Bereich Drittanbietern zu überlassen. Wenn Exchange Server 2007 UM verwendet wird, bleibt die Faxkonfiguration erhalten, und der Server kann weiterhin bei eingehenden Nachrichten auf Faxtöne reagieren. Wird ein Faxton erkannt, sucht Exchange den Wert der Eigenschaft FaxServerURI in der UM-Postfachrichtlinie, um festzustellen, ob eine Faxlösung von einem Drittanbieter zur Verfügung steht. Dieser Wert gibt den Pfad zu der betreffenden Lösung an und erlaubt der Unified- Messaging-Komponente von Exchange Server, dem Produkt den Anruf zu übergeben, woraufhin diese die Verantwortung dafür übernimmt, eine Sitzung mit dem Absender einzurichten, eine neue Faxnachricht zu erstellen und die Nachricht an das Postfach des Benutzers zu senden. Faxnachrichten im Posteingang sehen immer noch genauso aus wie in Exchange Server 2007. Der einzige Unterschied ist, dass Exchange Server 2010 nicht an ihrer Erstellung oder Verarbeitung beteiligt ist. Unter dem Strich bedeutet dies, dass Kunden, die eine Faxunterstützung in UM von Exchange Server 2010 aufnehmen wollen (etwa durch Zulassen derselben Nummer für eingehende Fax- und Sprachanrufe), eine geeignete Lösung eines anderen Anbieters erwerben müssen.
Exchange Server 2010-APIs Der Umgang von Exchange mit APIs war im besten Fall wechselhaft, im schlimmsten armselig. APIs sind in einem Release erschienen und im nächsten wieder verschwunden, und die Entwickler konnten sich nicht darauf verlassen, dass eine API mehr als einige wenige Releases überlebt, was für die Planung eines Projekts, das Exchange-Daten nutzen soll, keine gute Grundlage ist. MAPI ist die sowohl in der Server- als auch der Clientversion ständig vorhandene API, aber da die Dokumentation dürftig ist und die meisten Fachkenntnisse bei Microsoft liegen, ist sie schwer zu beherrschen. Andere APIs wie zum Beispiel Web Distributed Authoring and Versioning (WebDAV) wurden bei ihrem
632
Exchange Server 2010-APIs
Dass es nach so vielen Releases noch inkonsistente oder unvollständige APIs gibt, ist peinlich für Exchange – besonders, da E-Mail die Grundlage einer Plattform für die Zusammenarbeit bildet –, und Lotus Domino, der wichtigste Konkurrent von Exchange, ist in diesem Bereich schon immer besser gewesen. Exchange Server 2010 macht einen neuen Anfang, der sich auf drei APIs konzentriert. Die Hoffnung besteht, dass sie für die zukünftige Entwicklungsplattform des Produkts stehen. Die Zeit wird es zeigen. Tabelle 10.4 enthält die wesentlichen von älteren Exchange-Versionen verwendeten APIs und die entsprechende Exchange Server 2010-Option. Meistens liegt der Schwerpunkt deutlich auf EWS, einer Schnittstelle auf der Basis von SOAP (Simple Object Access Protocol). Beachten Sie, dass einige dieser APIs (wie WebDAV) nicht im Code von Exchange Server 2010 enthalten sind, während andere außerhalb der direkten Kontrolle von Exchange stehen (Windows Management Instrumentation [WMI]) und dort verbleiben werden. Alles, was Microsoft fallen lässt, stellt natürlich keine gute Wahl für eine Entwicklungsoption dar, in die Sie investieren sollten. Tabelle 10.4
Alte Exchange-APIs und Optionen in Exchange Server 2010 API
Zweck
Exchange Server 2010-Option
CDOEX
Postfachzugriff
EWS
WebDAV
Remotepostfachzugriff
EWS
ExOLEDB
Postfachzugriff
EWS
OWAURLs
Zugriff auf Frei/Gebucht-Daten und Namensauflösung
EWS
Speicherereignisse
Asynchrone und synchrone Ereignisse
Transportübermittlungsereignisse und EWS
WMI
Verwaltung
Windows PowerShell
Collaboration Data Objects (CDO 1.2.1)
Zugriff auf Outlook-Objekte über eine COM-Schnittstelle zu MAPI
Funktioniert weiterhin
Außerdem hat Microsoft angekündigt, dass die CDO-Version 1.2.x (Collaboration Data Objects) in den erweiterten Support geht, d.h., dass die API jetzt noch unterstützt wird, aber für zukünftige Projekte keine gute Option mehr ist. Möglicherweise fragen Sie sich, warum Microsoft die API-Landschaft schon wieder umbaut. Es liegt eine gewisse Logik in der Behauptung, das Produkt habe sich mit Exchange Server 2007 und Exchange Server 2010 dramatisch verändert und es sei an der Zeit, sich wieder auf eine Gruppe von APIs zu konzentrieren, auf die sich die Entwickler verlassen können. Microsoft möchte, dass die Entwickler.NET Framework nutzen, und manche der älteren APIs (CDOEX, ExOLEDB, MAPI) sind aus verwaltetem Code heraus schwer handhabbar. Außerdem stützen sich einige von ihnen auf redundanten Code, den Microsoft herausnehmen will, um Wartungskosten zu sparen und die Möglichkeit zu verringern, dass die Sicherheit durch alten Code gefährdet wird, der einer neuen Art von Angriff ausgesetzt wird. Darüber hinaus hat sich Microsoft in Exchange Server 2007 wesentlich von der monolithischen Produktarchitektur entfernt, indem die Geschäftslogik in eine Reihe von PowerShell-Befehle gekapselt wurde, die von mehreren Schnittstellen aufgerufen werden. Dieser Vorgang setzt sich in Exchange Server 2010 fort, um ein besser skalierbares und robusteres Produkt zu schaffen, sodass der Verzicht auf ältere Schnittstellen, die die gemeinsame Geschäftslogik nicht nutzen, sinnvoll erscheint.
633
Clients
Erscheinen mit hohen Erwartungen begrüßt, haben aber allmählich an Bedeutung verloren, und andere wie Exchange Routing Objects wurden eingeführt, stießen aber bei der Entwicklergemeinde auf Ablehnung und gingen sang- und klanglos unter.
Kapitel 10
Clients
Exchange-Webdienste Abgesehen von Windows PowerShell liegt der Schwerpunkt für die meisten Entwickler jetzt auf der API EWS (Exchange-Webdienste), die in Exchange Server 2007 eingeführt wurde. EWS ist auf dem Clientzugriffsserver untergebracht und wird als WCF-Webdienst (Windows Communication Foundation) zugänglich gemacht. Plattformen, die diese verwaltete API nicht einsetzen können, beispielsweise Apple Macintosh, iPhone/iPad und Linux, verwenden die reinen SOAP-Funktionen. Sie können EWS von der Microsoft-Website herunterladen. Die Lizenz erlaubt es Drittanbietern, EWS zusammen mit ihrem eigenen Code zu verbreiten. Sie sollten jedoch der Versuchung widerstehen, EWS im globalen Assemblycache (GAC) zu installieren. Da Microsoft es Entwicklern erlaubt, EWS in ihren Code einzubinden, besteht bei der Installation im GAC die Gefahr, dass Sie eine ähnliche Situation wie die »DLL-Hölle« schaffen, wenn eine Funktion in der EWS-Version des GAC eine Anwendung eines Drittanbieters nicht unterstützt. Mit EWS können Entwickler Code schreiben, der die Exchange-Kernfunktionen nutzt (Nachrichten senden und empfangen, Postfächer aktualisieren, Elemente löschen und Suchvorgänge durchführen), und gleichzeitig mit einem vollständigen Satz von Speicherelementen arbeiten, von Nachrichten bis hin zu Terminen und Aufgaben. EWS kann mit der globalen Adressliste arbeiten, Verteilerlisten erweitern, auf Frei/Gebucht-Daten zugreifen und den delegierten Zugriff auf Postfächer handhaben. Es kann auf Such- und öffentliche Ordner zugreifen sowie die Berechtigungen für Ordner bearbeiten. Die Exchange Server 2010-Version von EWS kann auf den Papierkorb zugreifen, mit Anhängen und persönlichen Verteilerlisten umgehen und sogar für Zwecke der rollenbasierten Steuerung Benutzer imitieren. Windows-Entwickler setzen EWS mithilfe einer clientseitigen .NET-API ein, die objektorientierten Zugriff auf die Elemente und Strukturen gewährt, mit denen sie sich befassen müssen. Da EWS in Exchange ausgereift ist, hat sich Microsoft von WebDAV verabschiedet, der API, die die letzten Versionen des Entourage-Clients für Exchange untermauert hat, sodass die neueste Entourage-Version jetzt vollständig auf EWS aufsetzt. Wenn Sie ein gutes Beispiel dafür suchen, wie Sie EWS anwenden können, bietet der einfache Exchange-Postfachclient des MVPs Glen Scales (http://gsexdev.blogspot.com/2009/06/simple-exchangeemail-client-for.html) einen hervorragenden Ausgangspunkt, weil er in Form eines Windows PowerShell-Skripts geschrieben ist. Das Skript (siehe Abbildung 10.43) zeigt, wie Sie mit der AutoErmittlung ein Postfach finden, eine Verbindung zu einem Postfach aufbauen, die Ordner im Postfach auflisten, Nachrichten erstellen und senden sowie den Inhalt von Nachrichtentext und -header anzeigen. Es ist ein großartiges Beispiel für EWS in Aktion, an dem Sie lernen können, wie Sie EWS für den Zugriff auf zahlreiche Exchange-Funktionen einsetzen. Auch wenn Microsoft EWS als API der Wahl für Entwickler herausstellt, wird es im Produkt selbst nicht verwendet. Stattdessen erstellt Microsoft viele der Exchange-Komponenten, die mit Postfächern arbeiten müssen, beispielsweise EWS, RCA, ActiveSync und UM, auf der Grundlage einer internen API namens XSO. Auf der Serverseite wird MAPI innerhalb des Produkts noch benutzt, aber neuerdings spielt XSO die zentrale Rolle. Windows PowerShell bleibt die erste Wahl für jeden servergestützten Verwaltungsvorgang, den Sie automatisieren müssen, auch dann, wenn Sie aus einer .NET-Sprache ein Windows PowerShellSkript aufrufen müssen. Der Remoteeinsatz von Windows PowerShell ermöglicht es Administratoren, Cmdlets von Arbeitsstationen aus auszuführen, auf denen kein Exchange-Code installiert ist (dazu muss natürlich die neueste Version von Windows PowerShell installiert sein), und ist konform mit der rollenbasierten Zugriffssteuerung, sodass die Administratoren nur die Objekte handhaben können, für die sie die entsprechende Berechtigung haben.
634
Der zentrale Verbindungspunkt
Clients
Abbildg. 10.43 Der in Windows PowerShell geschriebene einfache Exchange-Postfachclient
Der zentrale Verbindungspunkt Clients zu haben, ist schön und gut, aber wir müssen sie mit Exchange verbinden, um arbeiten zu können. Der Clientzugriffsserver ist der zentrale Verbindungspunkt, an dem in Exchange Server 2010 alles zusammenkommt. Es ist also logisch, dass wir uns als Nächstes mit ihm beschäftigen.
635
Clientzugriffsserver
Kapitel 11
Clientzugriffsserver
In diesem Kapitel: Die Rolle des Clientzugriffsservers
638
Die RPC-Clientzugriffsschicht
643
Zugriff des Clientzugriffsservers auf Verzeichnisinformationen
647
Der AutoErmittlungsdienst
648
Clientzugriffsarrays
660
Clientzugriffsserver und Umkreisnetzwerke
666
Protokollierung des RPC-Clientzugriffs
668
Zertifikate
670
Outlook Anywhere
672
Mehrbelastung für Clientzugriffsserver
674
Vorbereitungen für Übergang und Interoperabilität
683
Die weitere Bearbeitung
685
637
Kapitel 11
Clientzugriffsserver
Von allen Serverrollen in Exchange Server 2010 ist die des Clientzugriffsservers wahrscheinlich diejenige, über die die größte Unklarheit herrscht. Das mag daran liegen, dass es sich dabei im Grunde genommen um eine Black Box handelt, die eingehende Verbindungen von Clients verarbeitet und an Postfachserver weitervermittelt, um den Clientzugriff auf die Daten zu ermöglichen. Das ist etwas ganz anderes als ein Postfachserver, bei dem Sie sich den Strom der Nachrichten bildlich vorstellen und über die Exchange-Verwaltungskonsole und die Verwaltungsshell großen Einfluss auf die Datenbanken nehmen können, und als ein Hub-Transport-Server, bei dem Sie den Weg der Nachrichten durch die Warteschlangen beobachten und Nachverfolgungsprotokolle studieren können, um jeden einzelnen Schritt der Nachrichtenverarbeitung zu untersuchen. Ein Clientzugriffsserver hat keine Verwaltungsoberfläche mit einer grafischen Darstellung der weitervermittelten Verbindungen. Wegen dieser fehlenden Rückmeldung der Serverfunktionen lässt sich nur schwer begreifen, welche Art von Verarbeitung auf einem Clientzugriffsserver stattfindet. Dennoch ist ein Clientzugriffsserver ein Kernelement von Exchange Server und eine wichtige Serverrolle. Weitere Informationen
Von Microsoft und anderen Anbietern gibt es viele Whitepapers mit ausführlichen Anleitungen über die Platzierung und Konfiguration von Clientzugriffsservern in verschiedenen Situationen. Einen sehr guten Blogeintrag finden Sie beispielsweise auf http://msexchangeteam.com/archive/ 2009/11/20/453272.aspx. Dieser Artikel beschreibt, wie Sie in einer bestehenden Exchange-Umgebung Clientzugriffsserver mit Exchange Server 2010 einführen. Ich möchte in diesem Kapitel nicht die verschiedenen möglichen Situationen einzeln durchgehen, sondern die grundlegende Technologie von Clientzugriffsservern vorstellen und erklären, wie ein solcher Server die Rolle erfüllt, die er in einer Exchange-Organisation spielen soll.
Die Rolle des Clientzugriffsservers Microsoft hat die Rolle des Clientzugriffsservers in Exchange Server 2007 eingeführt, um dem Informationsspeicher die Verantwortung für Clientverbindungen abzunehmen. Das geschah im Rahmen der Bemühungen, den Funktionsumfang von Exchange auf eine Reihe von Serverrollen aufzuteilen, die einzeln bereitgestellt und verwaltet werden können. Der Clientzugriffsserver ist dazu da, drei verschiedene Arten von Datenverkehr zu verarbeiten: 쐍 Externe Verbindungen von Internetclients Datenverkehr, der in eine Organisaton hineingeht und von Clients mit verschiedenen Protokollen hervorgerufen wird, z.B. Outlook Anywhere, Outlook Web App (OWA), IMAP4, POP3 und ActiveSync. Darunter fallen auch Clients, die Exchange-Webdienste verwenden, z.B. die neueste Version von Microsoft Entourage und Outlook für den Mac. 쐍 Interne Kommunikaton von Intranetclients
Datenverkehr von MAPI- und anderen Clients.
쐍 Proxyverbindungen von anderen Clientzugriffsservern oder Datenverkehr, der von einem Clientzugriffsserver zu einem anderen umgeleitet wurde Das sind beispielsweise Verbindungen von einem Clientzugriffsserver in einem Active Directory-Standort zu einem Clientzugriffsserver in einem anderen Standort oder Umleitungen von einem Clientzugriffsserver, der nicht die richtige Exchange-Version für den Zugriff auf ein Benutzerpostfach ausführt (Letzteres kommt vor, wenn auf einem Clientzugriffsserver mit Exchange Server 2010 Datenverkehr eintrifft, der erst zu einem Clientzugriffsserver mit Exchange Server 2007 gehen muss, um Zugriff auf einen Postfachserver mit der alten Version zu bekommen). 638
Tabelle 11.1 führt die Dienste auf, die die Clientzugriffsrolle bereitstellt. Einige davon ermöglichen den Zugriff auf Exchange über verschiedene Clientprotokolle, während andere für wichtige Funktionen sorgen, die die Möglichkeiten des Clients erweitern. Zwei davon sind vollständige Anwendungen für Benutzer (OWA) und Administratoren (Exchange-Systemsteuerung). Tabelle 11.1
Dienste der Clientzugriffsrolle Dienst
Funktion
ActiveSync
Zugriff auf Exchange-Postfachdaten für mobile Geräte mit einer Lizenz für das Protokoll Exchange ActiveSync.
Adressbuch
Handhabt Clientanforderungen nach Verzeichnisinformationen.
AutoErmittlung
Ruft die erforderlichen Einstellungen ab, damit unterstützte Clients (Outlook 2007 und 2010, Windows Mobile 6.1 und höher) ihre E-Mail-Profile automatisch konfigurieren können, und ermittelt die Verbindungspunkte für Exchange-Dienste.
Verfügbarkeit
Fragt bei der Planung von Besprechungen die Frei/Gebucht-Informationen für Clients ab.
Exchange-Systemsteuerung
Eine Webanwendung mit einer Browserschnittstelle, die Verwaltungsmöglichkeiten für Exchange bietet.
Exchange-Webdienste
Bietet eine XML/SOAP-Schnittstelle für Exchange-Dienste (Extended Markup Language/Simple Object Access Protocol).
IMAP4
Ermöglicht den Zugriff auf Exchange-Postfächer über das Protokoll IMAP4.
MailTips
Untersucht den Headerinhalt neuer Nachrichten und zeigt ggf. Warnungen an, um den Benutzern zu helfen, Fehler zu vermeiden, z.B. über Allen antworten einen E-Mail-Ansturm mitzuverantworten.
Outlook Anywhere
Ermöglicht Outlook 2003, 2007 und 2010, über das Internet Kontakt mit Exchange aufzunehmen. Dies erfolgt über Remoteprozeduraufrufe (Remote Procedure Calls, RPC) in HTTPS.
Outlook Web App
Eine Webanwendung mit einem im Browser ausgeführten Client, die Zugriff auf die Postfach- und Kalenderfunktionen von Exchange bietet.
POP3
Ermöglicht den Zugriff auf Exchange-Postfächer über das Protokoll POP3.
RPC-Clientzugriff
Ermöglicht den MAPI-Zugriff auf Exchange-Postfächer.
In Exchange Server 2010 ist der Verantwortungsbereich des Clientzugriffsservers erweitert worden, denn in dieser Version sind alle Clientverbindungen vom Informationsspeicher auf ihn übertragen worden. Er bietet jetzt auch einen MAPI-Endpunkt, mit dem die Clients Verbindung aufnehmen, bevor sie über die RPC-Clientzugriffsschicht zu der Postfachdatenbank mit dem Zielpostfach weitergeleitet werden. Diese Änderung trägt auch entscheidend dazu bei, die bisherige Bindung zwischen Postfach und Server aufzulösen, wodurch Exchange Server 2010 die Möglichkeit hat, zwischen Postfachdatenbanken auf verschiedenen Servern umzuschalten. Dabei sorgt die AutoErmittlung dafür, dass Outlok-Clients auch nach dem Übergang auf Exchange Server 2010 ihre Postfächer finden können. Die Übertragung des MAPI-Endpunkts vom Postfach- zum Clientzugriffsserver bedeutet, dass Clientzugriffsserver in Exchange Server 2010 stärker belastet sind als in früheren Versionen und dass der Clientzugriffsserver noch wichtiger für das reibungslose Funktionieren einer Exchange-Infrastruktur geworden ist. MAPI-Verbindungen von Outlook zu öffentlichen Ordnern werden jedoch nicht vom Clientzugriffsserver verarbeitet, sondern gehen unmittelbar an den betreffenden Server.
639
Clientzugriffsserver
Die Rolle des Clientzugriffsservers
Kapitel 11
Clientzugriffsserver
Der alleinige Kontaktpunkt
Die größte Änderung, die beim Clientzugriffsserver in Exchange Server 2010 stattgefunden hat, ist seine Entwicklung zum alleinigen Kontaktpunkt für alle Verbindungen (ausgenommen für öffentliche Ordner). Dies wurde durch eine völlige Umgestaltung der Art und Weise erreicht, in der Exchange mit MAPI-Clientverbindungen umgeht. Der Clientzugriffsserver von Exchange Server 2007 hat nur die Verbindungen für IMAP4, POP3, ActiveSync, OWA und Outlook Anywhere gehandhabt, nicht aber die MAPI-Verbindungen für Outlook-Clients, die unmittelbar zum Informationsspeicherprozess auf den Postfachservern gingen.
Vorteile durch die Verlegung des MAPI-Endpunkts Die Verlegung der MAPI-Anbindung auf den Clientzugriffsserver scheint zwar nur eine simple Umordnungsmaßnahme zu sein – die Zusammenführung des Zugriffs für alle Protokolle an einer Stelle –, doch bietet sie darüber hinaus fünf spürbare Vorteile für Exchange. Erstens fließen jetzt alle Protokolle über einen gemeinsamen Codepfad. Dadurch wird es für Exchange-Entwickler viel einfacher, eine gleichartige Datenverarbeitung für alle Clients zu implementieren. Früher konnte es durchaus passieren, dass Daten von unterschiedlichen Clients auch auf verschiedene Weise verarbeitet wurden, da der dafür zuständige Code entweder für den Clientzugriffs- oder den Postfachserver geschrieben worden war. Da sich der gesamte Protokoll- und Clientzugriffscode jetzt auf dem Clientzugriffsserver befindet, konnte die große Menge an Code für die MAPI-Clientanbindung vom Postfachserver entfernt werden. Übrig geblieben ist nur der Code für Verbindungen zu öffentlichen Ordnern. Außerdem verbleibt in Exchange noch der Coder für MAPI-Verbindungen zwischen Servern, doch wird er niemals für MAPIClients wie Outlook eingesetzt. HINWEIS Der Verzicht auf viele Codeschichten, von denen einige auf die ersten ExchangeVersionen zurückgehen, erleichtert es den Entwicklern, Postfachserver so zu optimieren, dass sie höhere Belastungen verkraften und ganz allgemein stabiler laufen, da weniger Code ausgeführt werden muss und es weniger Stellen gibt, an denen Bugs lauern können. Der dritte Vorteil besteht darin, dass sich die Verarbeitung von Clientverbindungen jetzt schlanker ist und sich leichter an andere Größenverhältnisse anpassen lässt. Bei Exchange Server 2007 gibt es eine deutlich kompliziertere Menge von Clientverbindungen als in Exchange Server 2010. Ein OutlookClient, der Kontakt mit Exchange Server 2007 aufnimmt, erhält eine dauerhafte Verbindung zum Postfach- und zum globalen Katalogserver (für den DSProxy-Zugriff auf Verzeichnisinformationen). Das funktioniert ganz gut, solange sich der Clientzugriffsserver nicht um sehr viele TCP-Verbindungen kümmern muss, wie es z.B. bei der Verwendung von Outlook Anywhere vorkommt. Die erste Verbindung muss von Outlook zum Clientzugriffsserver führen, woraufhin der Clientzugriffsserver dann im Namen von Outlook Verbindung mit dem Postfachserver und dem globalen Katalog aufnimmt. Da die Verbindungen dauerhaft sind, kann das bei starker Belastung zu Engpässen führen. Bei Exchange Server 2010 gibt es jedoch keine dauerhaften Verbindungen. Diese Version erkennt eine Outlook Anywhere-Verbindung und legt die Informationen zum Sitzungsstatus im Arbeitsspeicher ab. Der Clientzugriffsserver verfügt über einen Pool von 100 freigegebenen Verbindungen mit den Postfachservern, die er für aktive Verbindungen nutzen kann. Wenn ein Benutzer zurzeit nichts tut, kann seine Verbindung inaktiv bleiben. Fordert er dagegen Daten an, verwendet der Client eine der
640
freigegebenen Verbindungen und gibt sie anschließend wieder frei. Durch die Nutzung dieses Pools ständig wiederverwendeter Verbindungen kann sich der Clientzugriffsserver besser an verschiedene Belastungen anpassen, als wenn er mit immer mehr Anforderungen von dauerhaften Verbindungen konfrontiert wird. Der vierte Vorteil ist die Einführung des Adressbuchdienstes als Ersatz für die (seit Exchange Server 2000 verwendete) Verbindung des DSProxy-Dienstes zum globalen Katalog, um Verzeichnisinformationen abzurufen. Der Adressbuchdienst auf dem Clientzugriffsserver ist ein echter Endpunkt, der den Clients gegenüber als maßgebliche Quelle für Verzeichnisdaten dient und nicht lediglich als Vermittler. Der Code ist einfacher, löst gleich zwei Probleme, nämlich das der geteilten Verbindungen, die bei Outlook Anywhere-Clients auftreten können, und das der Adressbuchaktualisierungen in Umgebungen mit mehreren Domänen. Letzteres kann auftreten, wenn ein Client versucht, eine Gruppe zu aktualisieren. Nehmen wir beispielsweise an, ein Outlook-Client wählt eine Gruppe aus der globalen Adressliste aus und versucht dann deren Mitgliedschaften zu ändern. Das geht solange gut, wie der DSProxy den Client mit einem globalen Katalog verbindet, der über eine beschreibbare Kopie der Gruppe verfügt. Gehört der globale Katalog aber zu einer anderen Domäne als die Gruppe, weshalb er nur eine schreibgeschützte Kopie davon aufweist, geht es schief. Der Adressbuchdienst kann jetzt erkennen, wenn bei Änderungen an Gruppen Probleme auftreten, und leitet die Änderung dann an einen geeigneten globalen Katalog weiter, in dem sie tatsächlich ausgeführt werden kann. Entsprechender Code kümmert sich um ein vergleichbares Problem, das bei Delegierungen und Zertifikaten auftreten kann. Das alles stellt unter Beweis, dass es vorteilhaft ist, die gesamte Geschäftslogik einheitlich zu gestalten und an einem Platz unterzubringen. Da Exchange Server 2010 alle Clientverbindungen jetzt auf dem Clientzugriffsserver verwaltet und nicht mehr zwischen diesem und dem Postfachserver aufteilt, braucht der Client fünftens weniger Zeit, um nach einem Failover zu der neuen aktiven Datenbank zu wechseln. Bei der fortlaufenden lokalen Replikation oder der Standby-Clusterreplikation von Exchange Server 2007 kann es einige Minuten dauern, bis die Verbindungen für den Übergang zu einer anderen Postfachkopie ermittelt sind und die Dienstleistung für die Clients vollständig wiederhergestellt ist. Zwar nehmen OutlookClients im Exchange-Cache-Modus die Unterbrechung nicht wahr, aber sie ist nichtsdestoweniger vorhanden, und in OWA und anderen Clients ist der Dienstausfall in voller Länge zu bemerken. Clientzugriffsserver mit Exchange Server 2010 können diese Übergänge besser bewältigen. Als Richtwert für die Failoverzeit gelten maximal 30 Sekunden.
Wann wird der Clientzugriffsserver installiert? Bei der Bereitstellung von Exchange Server 2010 sollte die Installation des Clientzugriffsservers der erste praktische Schritt sein. Ein Clientzugriffsserver mit Exchange Server 2010 kann alle verschiedenen Clientverbindungen zu sowohl Exchange Server 2007 als auch 2010 handhaben. Außerdem kann er als Proxy zur Vermittlung von Verbindungen zu einem Clientzugriffsserver mit Exchange Server 2007 dienen, damit Clients, die Verbindungen zu Postfächern auf Computern mit Exchange Server 2003 oder 2007 benötigen, ans Ziel gelangen können. Ein Clientzugriffsserver mit Exchange Server 2007 kann dies nicht tun, da ihm der Code für die neuen Funktionen fehlt, z.B. für die Bereitstellung des MAPI-Endpunkts für Clients und Clientzugriffsarrays. Für die Bereitstellung der Exchange ServerRollen wird die folgende Reihenfolge empfohlen:
641
Clientzugriffsserver
Die Rolle des Clientzugriffsservers
Kapitel 11
Clientzugriffsserver
쐍 Wenn Sie einen mit dem Internet verbundenen Active Directory-Standort haben, um auch einen Clientzugriff von außen zu ermöglichen (über OWA, Outlook Anywhere oder ActiveSync), müssen alle dortigen Server Exchange Server 2007 SP2 oder Exchange Server 2003 SP2 ausführen, damit sie mit Exchange Server 2010 umgehen können. 쐍 Beginnen Sie mit der Bereitstellung von Exchange Server 2010, indem Sie zuerst in dem mit dem Internet verbundenen Standort zuerst Clientzugriffsserver und dann die Edge- und Hub-Transport-Server installieren. Bereiten Sie die Übertragung der eingehenden Clientverbindungen von der alten auf die neue Umgebung vor, indem Sie SSL-Zertifkate (Secure Sockets Layer) einrichten, die Clientzugriffsservern mit Exchange Server 2010 ermöglichen, den AutoErmittlungsdienst für Postfachserver mit Exchange Server 2007 anzubieten. 쐍 Stellen Sie den Internet-Namensraum für die Organisation auf die Exchange Server 2010-Umgebung um, indem Sie die externen URLs ändern und so den Datenverkehr zu den Clientzugriffs-, Edge- und Hub-Transport- sowie Unified-Messaging-Servern mit Exchange Server 2010 umleiten. 쐍 Installieren Sie Postfachserver mit Exchange Server 2010 und verschieben Sie die Benutzerpostfächer von den älteren Servern dorthin. 쐍 Entfernen Sie die alten Clientzugriffs- und Hub-Transport-Server. 쐍 Entfernen Sie die alten Unified-Messaging-Server. 쐍 Entfernen Sie die alten Postfachserver. Möglicherweise müssen Sie einige davon beibehalten, um ältere Anwendungen zu unterstützen, die auf eine ältere, von Exchange Server 2010 nicht mehr genutzte API wie WebDAV (Web Distributed Authoring and Versioning) angewiesen sind. Verbindungen mit Exchange versucht Outlook zunächst über TCP herzustellen und wenn das nicht klappt mithilfe von RPC über HTTPS (Outlook Anywhere). Für die üblichen Clients in Unternehmen, die meistens im internen Netzwerk arbeiten, ist das auch die geeignetste Konstellation. Wenn Sie jedoch viele Clients haben, die an einem anderen Ort untergebracht sind oder gewöhnlich über Outlook Anywhere Kontakt aufnehmen, können Sie das Verhalten von Outlook so ändern, dass zuerst RPC über HTTPS probiert wird. Das ist jedoch nur bei Outlook 2010 möglich, was die wachsende Bedeutung von Outlook Anywhere und die damit einhergehende Möglichkeit veranschaulicht, ohne virtuelles privates Netzwerk (VPN) auf Exchange zuzugreifen. Wenn Sie standardmäßig Outlook Anywhere verwenden möchten, führen Sie das Cmdlet Set-OutlookProvider wie folgt aus: Set-OutlookProvider –id EXPR –OutlookProviderFlags:ServerExclusiveConnect
Diese Änderung wirkt sich global aus, betrifft also alle Outlook 2010-Clients, die über einen Clientzugriffsserver mit Exchange Server 2010 Verbindung aufnehmen – selbst wenn sie auf ein Exchange Server 2007-Postfach zugreifen. Um zum vorherigen Verhalten zurückzukehren, verwenden Sie folgenden Befehl: Set-OutlookProvider –id EXPR –OutlookProviderFlags:None
Das Cmdlet Set-OutlookProvider legt globale Einstellungen für das AutoErmittlungsobjekt fest. Bei einer Änderung des Anbieterflags übergibt Exchange diese Werte mithilfe der AutoErmittlung an den Client. Benutzer von Outlook 2007 und 2010 können in ihren Profilen ein Verbindungsverhalten auswählen. Ein auf diese Weise festgelegtes Verhalten wird gegenüber dem in der globalen Einstellung bevorzugt.
642
Die RPC-Clientzugriffsschicht
In Kapitel 8, »Exchange auf dem Weg zur Hochverfügbarkeit«, geht es darum, wie Exchange durch die Einführung von Datenbankverfügbarkeitsgruppen in die Lage versetzt wird, mehrere Kopien einer Datenbank zu unterhalten. Dadurch hat der Systemdesigner deutlich verbesserte Möglichkeiten, um Umgebungen zu entwerfen, die gegen die Auswirkungen von Serverausfällen geschützt sind. Es ist jedoch nicht die Replikation der Protokolldateien, die dies ermöglicht hat, denn schließlich gab es auch schon in Exchange Server 2007 einen Protokollversand. Der tatsächliche Durchbruch, dem wir Datenbankverfügbarkeitsgruppen zu verdanken haben, ist die Verlegung des Verbindungspunkts für MAPI-Clients vom Postfach- auf den Clientzugriffsserver. Früher ermittelte Outlook über die Postfachinformationen im Active Directory-Konto des Benutzers, auf welchem Server die Datenbank mit dem gewünschten Postfach untergebracht war, und nahm dann unmittelbar Verbindung mit dem Postfachserver auf. Das funktionierte zwar offensichtlich gut, schrieb aber die enge Bindung zwischen Postfachdatenbank und Server fest. Abbildung 11.1 zeigt die Clientzugriffsarchitektur von Exchange Server 2010. Der große Unterschied gegenüber Exchange Server 2007 besteht darin, dass jetzt sämtliche Verbindungen von allen Clients über den Clientzugriffsserver laufen. In gewisser Hinsicht ähnelt dies den Änderungen, die Microsoft in Exchange Server 2007 vorgenommen hat. Damals wurde die Direktzustellung von Nachrichten innerhalb einer Datenbank aufgegeben, sodass alle Nachrichten durch den Transportdienst laufen mussten. Der neue RPC-Clientzugriffsdienst, der im Prozess MSExchange RPCAccess implementiert ist, fängt alle Clientverbindungen zu Postfächern ab, auch diejenigen von MAPI-Clients, fragt Active Directory nach dem aktuellen Speicherort des Postfachs ab und leitet die Verbindung dann an den richtigen Postfachserver weiter. Dadurch ist die gewünschte Trennung zwischen Postfachdatenbank und Server möglich. Der Informationsspeicher wird von dem Code befreit, der für die Verarbeitung von MAPI-Clientverbindungen erforderlich war, was den verbleibenden Code einfacher und leichter zu warten macht. Dadurch, dass alle Clientverbindungen durch einen gemeinsamen Punkt fließen müssen, wird außerdem eine einheitlichere Anwendung von Geschäftslogik während der Datenverarbeitung durch die Clients erreicht (wenn Sie beispielsweise von einem mobilen Gerät aus eine Besprechungsanfrage öffnen und Ihr Postfach gleichzeitig in Outlook geöffnet ist, verarbeitet auch dieser Client die Anforderung zur selben Zeit). Um einen Clientzugriffsserver zu erreichen, gehen die Clients auf verschiedene Weise vor, enden aber schließlich alle am selben Ort: 쐍 MAPI-Clients (Outlook) wenden sich für den Zugriff auf Postfächer und Verzeichnisse an Clientzugriffsserver und für den Zugriff auf öffentliche Ordner an Postfachserver. Wenn Sie den Client für die Nutzung von Exchange einrichten, geben Sie bei Exchange Server 2010 jetzt den Namen eines Clientzugriffsservers oder -arrays an und nicht mehr den eines Postfachservers. 쐍 POP3- und IMAP4-Clients nehmen Verbindung mit einem einzelnen Namensraum auf (z.B. mail.contoso.com), der auf den Clientzugriffsserver (oder das entsprechende Array) zeigt. Dieser Server leitet die eingehenden Verbindungen dann an den richtigen Postfachserver weiter. 쐍 Mobile ActiveSync-Clients nehmen zur Synchronisierung von Postfach- und Kalenderdaten Verbindung mit demselben Namensraum auf. 쐍 OWA-Clients nehmen zum Abrufen von Postfachinhalten ebenfalls Verbindung mit diesem Namensraum auf. Die Inhalte werden vom Clientzugriffsserver übermittelt.
643
Clientzugriffsserver
Die RPC-Clientzugriffsschicht
Kapitel 11
Clientzugriffsserver
Dadurch entsteht das einfache Bild eines einheitlichen Verbindungspunkts für den Clientzugriff, in dem der Clientzugriffsserver die Rolle des zentralen Hubs für Exchange-Clients spielt. Abbildg. 11.1
Die Clientzugriffsarchitektur von Exchange Server 2010 Internet-Clients Internet
Umgekehrter Proxyserver Umkreisnetzwerk Firewall
Postfachund Verzeichnisverbindungen von Outlook und OWA
Intranet
Clientzugriffsserver oder -arrays
Verbindungen für öffentliche Ordner Postfachserver
Verknüpfen des Clientzugriffsservers mit Postfachdatenbanken Hinter den Kulissen hat Outlook immer auf Active Directory zugegriffen, um den Namen des Servers mit der Datenbank zu ermitteln, in der sich das gesuchte Benutzerpostfach befindet. Wenn Sie sich die Eigenschaft legacyExchangeDN für eine Datenbank ansehen, können Sie Folgendes erkennen: legacyExchangeDN: /o=ABC Corp/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/ cn=Configuration/cn=Servers/cn=ExServer1/cn=Microsoft Private MDB;
In diesem Fall weiß Outlook, dass sich die Datenbank auf dem Server ExServer1 befindet. Wie wir aber gesehen haben, sind Datenbanken in Exchange Server 2010 nicht mehr an einen bestimmten 644
Server gebunden. Daher gibt Exchange Server 2010 den Namen des Clientzugriffsservers oder -arrays an, der jetzt als MAPI-Endpunkt fungiert. In einfachen Organisationen kann dieser MAPI-Endpunkt ein Server sein, der sowohl die Clientzugriffs- als auch die Postfachrolle ausführt. Hat ein Servercomputer beide Rollen inne, ist der Endpunkt für die Datenbanken auf diesem Rechner meistens der lokale Clientzugriffsserver. In komplizierter aufgebauten Umgebungen kann der Endpunkt auf einem beliebigen Clientzugriffsserver liegen, der sich im selben Standort befindet wie der Postfachserver. Der Endpunkt kann aber auch ein Clientzugriffsarray sein, das für die Verbindungen innerhalb eines Active Directory-Standorts vorgesehen ist. Die Postfachdatenbanken von Exchange Server 2010 verfügen über die neue Eigenschaft RpcClientAccessServer, in die Exchange beim Erstellen der Datenbank automatisch einträgt, wo der MAPI-Endpunkt zu finden ist. Fungiert der Server mit der Datenbank gleichzeitig als Clientzugriffsserver, so nennt Exchange in dieser Eigenschaft diesen Server. Anderenfalls verwendet er den Namen des Clientzugriffsarrays für den Standort (falls eines vorhanden ist) oder wählt einen der im Standort installierten Clientzugriffsserver aus. Den Aufbau eines Clientzugriffsarrays besprechen wir im Abschnitt »Clientzugriffsarrays« weiter hinten in diesem Kapitel. Die aktuellen Einstellungen können Sie mit dem folgenden Befehl einsehen: Get-MailboxDatabase | Select Name, RpcClientAccessServer, Server | Sort RpcClientAccessServer Name -------IT Department PR Dublin Users DB3 DB1 VIP Data Operations DB2 Sales
RpcClientAccessServer --------------------ExServer1.contoso.com ExServer1.contoso.com ExServer1.contoso.com ExServer1.contoso.com ExServer1.contoso.com ExServer2.contoso.com ExServer2.contoso.com ExServer2.contoso.com ExServer2.contoso.com
Server -------ExServer1 ExServer4 ExServer1 ExServer2 ExServer1 ExServer4 ExServer4 ExServer2 ExServer3
An dieser Ausgabe können wir ablesen, dass es zwei aktive Clientzugriffsserver gibt (nämlich ExServer1 und ExServer2). Angesichts seines Namens ist es sehr wahrscheinlich, dass ExServer1 der erste Clientzugriffsserver dieses Standorts war, aber aus den vorliegenden Informationen lässt sich das nicht eindeutig erkennen. Außerdem können wir sehen, dass es zwischen dem RPC-Clientzugriffsserver und dem Server, auf dem die Datenbank zurzeit bereitgestellt wird, keine Verbindung gibt. Die Eigenschaft RpcClientAccessServer wird nicht aktualisiert, wenn eine Datenbank auf einen anderen Server umgeschaltet wird, ein Server ausfällt oder aus der Organisation herausgenommen wird. Wenn der bevorzugte Clientzugriffsserver aus irgendeinem Grund nicht erreichbar sein sollte, sucht Exchange nicht automatisch einen anderen aus, der in dem Standort zur Verfügung steht, die die Postfachdatenbank ist mit einem bestimmten Clientzugriffsserver verknüpft und versucht weiterhin, Kontakt mit ihm aufzunehmen, solange sie keine gegenteilige Anweisung erhält. Die Benutzer von Outlook bekommen in einem solchen Fall keine Verbindung mit Exchange, bis der Clientzugriffsserver wieder online geht. Dann erkennt Outlook, dass der Server wieder verfügbar ist, und nimmt Kontakt mit ihm auf. Die Abhängigkeit von einem einzelnen Server zu beseitigen, ist daher ein guter Grund, um ein Clientzugriffsarray zu erstellen, selbst wenn es in einem Standort nur zwei Clientzugriffsserver gibt. Clientzugriffsarrays werden wir in Kürze besprechen. 645
Clientzugriffsserver
Die RPC-Clientzugriffsschicht
Kapitel 11
Clientzugriffsserver
Wenn Sie kein Array zur Verfügung haben, können Sie die Eigenschaft RpcClientAccessServer einer Postfachdatenbank so ändern, dass sie auf einen anderen Server zeigt. Wenn bei einem Server beispielsweise ein irreparabler Hardwareschaden auftritt, müssen Sie alle eingehenden Verbindungen auf einen anderen Clientzugriffsserver übertragen. Geben Sie dazu den vollqualifizierten Domänennamen (Fully Qualified Domain Name) des gewünschten Servers an, wie das folgende Beispiel zeigt: Set-MailboxDatabase –id Sales –RpcClientAccessServer'ExServer1.contoso.com'
In der Eigenschaft RpcClientAccessServer können Sie auch ein Clientzugriffsarray angeben. Dieses Thema sehen wir uns in Kürze an. Insidertipp: Keine externe Firewall zwischen dem Clientzugriffsserver und den Postfachservern
In Exchange Server 2010 ist es nicht möglich, externe Firewalls zwischen die Clientzugriffs- und die Postfachserver zu stellen. Sie können Clientzugriffsserver nicht in einem Umkreisnetzwerk unterbringen, das durch eine Firewall von den Postfachservern abgeschirmt ist, da Exchange für den Geschmack von Sicherheitsexperten zu viele offene Ports benötigt. Auf dem Server können Sie jedoch die Windows-Firewall aktivieren, da Exchange sie automatisch so einrichtet, dass eine Kommunikation möglich ist. Eine Hardwarefirewall aber ist nicht möglich. Eine Liste der von Exchange verwendeten Ports finden Sie auf http://technet.microsoft.com/de-de/ library/bb331973.aspx.
Unterstützen von Outlook 2003-Clients Im Lieferzustand unterstützt die RPC-Clientzugriffsschicht nur verschlüsselte MAPI-Verbindungen, sodass ohne weiteres Eingreifen nur Outlook 2007 und Outlook 2010 Kontakt erhalten. Auch Outlook 2003 kann eine Verbindung mit einem Exchange Server 2010-Clientzugriffsserver oder -array aufnehmen, aber dazu müssen Sie die MAPI-Verschlüsselung auf dem Client aktivieren oder auf allen verwendeten Clientzugriffsservern (einzeln oder im Array) mit dem Cmdlet Set-RPCClientAccess deaktivieren. Soll Outlook 2003 auch der Zugriff auf öffentliche Ordner möglich sein, müssen Sie das Erfordernis der MAPI-Verschlüsselung auch auf den Postfachservern deaktivieren, auf denen sich die Datenbanken der öffentlichen Ordner befinden. Besser ist es natürlich, die Verschlüsselung auf dem Client zu aktivieren, denn das ist schließlich auch die Standardeinstellung in Outlook 2007 und 2010. Außerdem vermeiden Sie dadurch eine Schwächung der Sicherheit, auch wenn es eher unwahrscheinlich ist, das jemand Pakete auf dem Weg von Outlook 2003 zum Clientzugriffsserver abfängt. Sie können die Verschlüsselung zwar auf jedem einzelnen Client aktivieren, aber sinnvoller ist es, diese Einstellung über ein Gruppenrichtlinienobjekt anzuwenden, falls diese Möglichkeit besteht. Um die aktuelle Verschlüsselungseinstellung einzusehen, können Sie das Cmdlet Get-RPCClientAccess verwenden: Get-RPCClientAccess –Server ExchCAS1 | Format-List Server, *Enc*
Wollen Sie die Verschlüsselung tatsächlich deaktivieren, nehmen Sie dazu Set-RPCClientAccess: Set-RPCClientAccess –Server ExchCAS1 –EncryptionRequired $False
646
Zugriff des Clientzugriffsservers auf Verzeichnisinformationen
Set-MailboxServer –id ExServer1 –MAPIEncryptionRequired $False
Die erforderliche Verschlüsselung kann in einer Exchange Server 2010-Umgebung ein echtes Problem darstellen, und sei es auch nur, weil den Administratoren dieser Umstand nicht bewusst ist und sie erst dann darauf aufmerksam werden, wenn der erste Client mit Outlook 2003 eine Verbindung herzustellen versucht. Microsoft hat die Standardeinstellung für den Clientzugriffsserver in SP1 daher geändert, sodass die Verschlüsselung jetzt deaktiviert ist. Diese Lösung ermöglicht zwar reibungslose Verbindungen von Outlook 2003 aus, beschwört aber ein anderes Problem herauf. Auf älteren Clientzugriffsservern, die noch mit der RTM-Version bereitgestellt wurden, ist die Verschlüsselung aktiviert, und das bleibt auch nach einer Aktualisierung auf SP1 so, während bei neuen Servern mit SP1 die Verschlüsselung deaktiviert ist. Man kann sich sehr leicht eine Situation vorstellen, in der ältere und neuere Server zusammen in einem Clientzugriffsarray eingesetzt werden und die Outlook 2003-Clients irritiert werden, da sie eine Verbindung zu den neuen Servern bekommen, aber nicht zu den alten. Wenn die Administratoren dann versuchen, das Problem zu beheben, werden auch sie wahrscheinlich ziemlich irritiert sein. Daher ist es weiterhin empfehlenswert, die Verschlüsselung für die gesamte Kommunikation zwischen Client und Server zu erzwingen, selbst wenn das bedeutet, dass einige Outlook 2003Profile aktualisiert werden müssen.
Zugriff des Clientzugriffsservers auf Verzeichnisinformationen Als Ersatz für die in Exchange Server 2007 verwendete Komponente DSProxy stellt ein Clientzugriffsserver Outlook-Clients auch einen NSPI-Endpunkt (Name Service Provider Interface) für Anforderungen nach Verzeichnisinformationen bereit. Wenn Outlook-Clients eine solche Anforderung übermitteln, fängt der Adressbuchdienst des Clientzugriffsservers sie ab und ermittelt in Active Directory den Standort, in dem sich das Postfach des Clients befindet, und den Wert der Eigenschaft RPCClientAccessServer der Datenbank mit dem Postfach, um zu bestimmen, zu welchem Clientzugriffsserver oder -array eine Verbindung erforderlich ist. Der aktuelle Clientzugriffsserver teilt dem Outlook-Client dann mit, an welchen Clientzugriffsserver er sich wegen Verzeichnisinformationen wenden muss. Outlook nimmt daraufhin Verbindung mit diesem Server auf, der wiederum mit einem globalen Katalogserver spricht, um auf die anschließenden Anforderungen des Clients nach Verzeichnisinformationen zu antworten. Befindet sich ein Postfach auf einem Server mit einer älteren Exchange-Version, kann der Clientzugriffsserver die Verbindung dorthin umleiten. Von dort aus erfolgt die Verbindung zum globalen Katalog dann über DSProxy. Zwei Fliegen mit einer Klappe
Die Kanalisierung der Verzeichniskommunikation durch den Clientzugriffsserver löst gleich zwei Probleme von Exchange. Erstens war es in Outlook Anywhere für den Lastenausgleich von SSL-IDLösungen schwierig, die von Exchange Server 2007 benötigten geteilten Verbindungen zu handhaben (eine LDAP-Verbindung zu Active Directory und eine RPC-Verbindung zu DSProxy). Zweitens werden jetzt alle Änderungsanforderungen von Outlook für Verzeichnisinformationen, z.B. Gruppenmitgliedschaften, Delegierungs- und Zertifikatverwaltung, auch dann korrekt erledigt, wenn sich die Clients in anderen Domänen befinden als die anderen Objekte. 647
Clientzugriffsserver
Um die MAPI-Verschlüsselung auf einem Postfachserver mit einer Datenbank für öffentliche Ordner zu deaktivieren, geben Sie folgenden Befehl:
Kapitel 11
Clientzugriffsserver
Zwei Fliegen mit einer Klappe
Nehmen wir beispielsweise an, Ihre Umgebung besteht aus zwei Domänen in einer Gesamtstruktur. Wenn ein Benutzer in Domäne A die Verwaltungsrechte für einen Gruppe in Domäne B hat, kann er die Mitgliedschaften trotzdem nicht ändern, da der Domänencontroller, mit dem Outlook Verbindung aufnimmt und der sich in der Domäne des Benutzers befindet, die Änderungen nicht verarbeiten kann. Dieses Problem ist schon seit vielen Jahren in größeren Umgebungen aufgetreten. Die Lösung bestand jetzt darin, in den Clientzugriffsserver eine Logik einzubauen, die solche domänenübergreifenden Vorgänge erkennt, sodass Exchange die Änderungen auf dem richtigen Active Directory-Server vornimmt.
Der AutoErmittlungsdienst Den AutoErmittlungsdienst hat Microsoft in Exchange Server 2007 als Hilfestellung für die Benutzer eingeführt, um in Outlook bei der ersten Verbindungsaufnahme mit Exchange den Namen ihres Postfachs und des entsprechenden Servers anzugeben, was immer ein Dauerproblem war. Die Informationen über den Speicherort des Postfachs wurden daraufhin im Outlook-Profil festgehalten. Ein Profil können Sie nach wie vor auch manuell einrichten, aber es ist einfacher, die Arbeit durch den AutoErmittlungsdienst erledigen zu lassen. Das funktioniert alles einwandfrei, solange das Postfach, für das Sie den Zugriff einrichten möchten, nicht in den Exchange-Adresslisten ausgeblendet ist. In diesem Fall kann die AutoErmittlung das Postfach nicht finden, sodass Ihnen nichts anderes übrig bleibt, als das Profil manuell einzurichten. Wenn Outlook die Verbindung zum Postfach verliert, kann es den AutoErmittlungsdienst erneut abfragen. Outlook 2007 und 2010, alle Geräte mit Windows Mobile 6.1 und höhere sowie E-Mail-Clients wie Entourage und Outlook für den Mac können die AutoErmittlung verwenden. In Exchange Server 2010 ist dieser Dienst sogar noch wertvoller, da die Datenbank mit dem Postfach des Benutzers nicht mehr an einen bestimmten Server gebunden ist, sondern innerhalb einer Verfügbarkeitsgruppe auf verschiedenen Servern aktiv geschaltet werden kann. Outlook 2007 und 2010 können auch Verbindung mit Postfächern auf Computern mit Exchange Server 2000 und 2003 aufnehmen (auf denen es keinen AutoErmittlungsdienst gibt), aber in solchen Fällen müssen die Benutzer ihre Profile gewöhnlich selbst einrichten, indem sie bei der ersten Verbindungsaufnahme sämtliche Angaben zum Postfach und zum Server beibringen. Wenn Sie Exchange Server 2010 bereitstellen, kann Outlook einen Clientzugriffsserver mit der neuen Version finden und von dort die Informationen des AutoErmittlungsdienstes abrufen.
Zugriff auf einen Dienstverbindungspunkt Clients greifen auf zwei verschiedene Weisen auf den AutoErmittlungsdienst zu. Läuft der Client auf einer Arbeitsstation in einer Domäne, kann er in Active Directory nachschlagen, um die Dienstverbindungspunkte zu finden, die Exchange bei der Installation eines neuen Clientzugriffsservers registriert. Clients außerhalb der Domäne können die erforderlichen Informationen auf der Website der AutoErmittlung abfragen. Für jeden Clientzugriffsserver in der Organisation gibt es in Active Directory einen Dienstverbindungspunkt. Er besteht aus einer maßgeblichen Liste der URLs, die Clients für den Zugriff auf den
648
AutoErmittlungsdienst innerhalb der Gesamtstruktur verwenden können. Wenn Exchange in mehreren Gesamtstrukturen bereitgestellt wird, kann ein Dienstverbindungspunkt auch als Verweis von einer Gesamtstruktur auf eine andere dienen. Die vom Dienstverbindungspunkt zurückgegebenen URLs sind meistens Zeiger auf die Clientzugriffsserver, mit denen die Clients Verbindung aufnehmen müssen, um zu den Postfachservern mit den gewünschten Postfächern weitergeleitet zu werden. Die URLs können jedoch auch auf andere Exchange-Dienste zeigen, z.B. den Verfügbarkeitsdienst. Um zu bestimmen, welchen Dienstverbindungspunkt es benutzen soll, geht Outlook wie folgt vor: 쐍 Outlook ruft von Active Directory eine Liste der Dienstverbindungspunkte für die verfügbaren Clientzugriffsserver ab. 쐍 Danach vergleicht Outlook die Dienstverbindungspunkte, um den für den Active DirecotryStandort zu finden, zu dem die Arbeitsstation mit Outlook gehört. Gibt es keinen passenden Verbindungspunkt, wird eine eigene Liste aufgestellt und nach dem Alter sortiert (also dem Datum, an dem der Dienstverbindungspunkt zu Active Directory hinzugefügt wurde). 쐍 Anschließend versucht Outlook den im ersten Dienstverbindungspunkt auf der Liste angegebenen AutoErmittlungsdienst zu erreichen. Zeigt dieser Punkt auf einen Clientzugriffsserver mit Exchange Server 2007 (weil dies der älteste Verbindungspunkt ist), während sich das Postfach auf einem Computer mit Exchange Server 2010 befindet, leitet der Clientzugriffsserver die Anforderung an einen Clientzugriffsserver mit Exchange Server 2010 im Standort mit dem Postfach weiter (diese Umleitung erfolgt innerhalb des Standorts). 쐍 Ist der erste Clientzugriffsserver auf der Liste nicht erreichbar, geht der Client zum nächsten über, bis er eine Verbindung herstellen kann oder die Liste abgearbeitet ist. Nachdem der Client eine Verbindung zu einem Clientzugriffsserver hergestellt hat, versucht er die Konfigurationsinformationen für sein Postfach und die Speicherorte der verschiedenen ExchangeDienste abzurufen. Dadurch verfügt sein Profil über die aktuellsten Postfacheinstellungen, sodass Outlook weiß, wo es folgende Dinge finden kann: 쐍 Abwesenheitsinformationen 쐍 Verfügbarkeitsinformationen von den Kalendern anderer Benutzer 쐍 Speicherorte zum Herunterladen der Offlineadressbuchdateien 쐍 Unified-Messaging-Informationen (falls verwendet) Eine weitere wichtige Aktualisierung, die der Client empfängt, ist der Name des Clientzugriffsservers, den er für zukünftige Abfragen verwenden soll. Dieser Clientzugriffsserver wird dann zum MAPI-Endpunkt und ersetzt den Postfachserver, der in früheren Versionen von Exchange im Profil angegeben war. Insidertipp: Welcher Server ist der Clientzugriffsserver?
Der Clientzugriffsserver ist nicht unbedingt ein Computer, der besonders nahe bei dem Postfachserver mit der Datenbank des Benutzerpostfachs steht. Schließlich kann die Rolle der aktiven Postfachdatenbank in einer Datenbankverfügbarkeitsgruppe von einem Server zum anderen wandern. Daher wählt Exchange den Clientzugriffsserver aus, der dem Clientcomputer im Netzwerk am nächsten steht, und verwendet diesen als MAPI-Endpunkt. In den meisten Fällen befinden sich der Postfach- und der Clientzugriffsserver im selben Active Directory-Standort, aber das muss nicht unbedingt der Fall sein.
649
Clientzugriffsserver
Der AutoErmittlungsdienst
Kapitel 11
Clientzugriffsserver
Wenn Outlook versucht, über Outlook Anywhere Verbindung über das Internet aufzunehmen, wird die Sache komplizierter. In diesem Fall kann sich Outlook nicht an Active Directory wenden, um eine Liste der Dienstverbindungspunkte für die AutoErmittlung abzurufen. 쐍 Outlook kann den im Profil angegebenen FQDN für den Clientzugriffsserver (oder das Array) nicht auflösen und versucht daher über HTTPS (Port 443) Verbindung mit dem URL für den externen AutoErmittlungsdienst der Domäne aufzunehmen. Nehmen wir an, die E-Mail-Adresse des Benutzes lautet [email protected]. Outlook sucht zuerst auf https://contoso.com/autodiscover nach der Website der AutoErmittlung, und falls das fehlschlägt, auf https://autodiscover.contoso.com. Die Website sollte über DNS zu finden sein und sich von derjenigen unterscheiden, die OWA-Benutzer für Verbindungen über das Internet benutzen und die gewöhnlich https://webmail.contoso.com oder ähnlich lautet. Die Tatsache, dass im Internet die Namen von mindestens zwei verschiedenen Websites veröffentlicht werden müssen, damit externe Clients eine Verbindung herstellen können, ist ein guter Grund dafür, SSL-Zertifikate mit alternativen Subjektnamen zu verwenden, die eine Liste aller Websitenamen enthalten. 쐍 Kann der AutoErmittlungsdienst erfolgreich nachgeschlagen werden, erhält der Client als Antwort Informationen im XML-Format, aus denen er ablesen kann, wie er den RPC-Proxydienst erreichen kann. 쐍 Bei einer eingehenden Verbindung besteht der nächste Schritt darin, die Dienste eines umgekehrten Proxyservers in Anspruch zu nehmen (Microsoft Forefront Threat Management Gateway [TMG], Microsoft Internet and Security Acceleration server [ISA] oder ein Hardwareserver). Der Regelsatz dieses Servers bestimmt, wie die Verbindungen verarbeitet werden, und leitet sie zu dem Clientzugriffsserver weiter, auf dem die RPC-Proxykomponente installiert ist, die als Endpunkt für Outlook Anywhere dient. 쐍 Die RPC-Proxykomponente akzeptiert die Verbindung über eine SSL-Bridge und den TCP-Port 443 und schlägt in Active Directory nach, um die Postfachdatenbank mit dem Benutzerpostfach zu ermitteln. Anschließend kann sie den Clientzugriffsserver (oder das Array) bestimmen, der mit dieser Postfachdatenbank verbunden ist. 쐍 Der Clientzugriffsserver nimmt einen RPC-Aufruf zu dem für die Postfachdatenbank eingerichteten Clientzugriffsserver oder -array vor, damit der Client die Verbindung fertig stellen kann. Insidertipp: Wie erfasst Outlook Informationen?
Die erforderlichen Informationen für eine Sitzung sammelt Outlook durch zwei Methoden, nämlich durch den Startprozess und durch eine regelmäßige Aktualisierung. Bei jedem Start ruft Outlook vom AutoErmittlungsdienst Informationen über die zuvor aufgeführten Exchange-Dienste ab. Die gefundenen Informationen legt Outlook 60 Minuten lang im lokalen Cache ab, bevor eine Aktualisierung erfolgt. Diesen Zeitraum können Sie ändern, indem Sie auf einem Clientzugriffsserver das Cmdlet Set-OutlookProvider ausführen und eine neue Cache-Lebensdauer in Stunden eingeben. Um den Zeitraum auf drei Stunden zu erhöhen, verwenden Sie beispielsweise folgenden Befehl: Set-OutlookProvider –id 'msExchAutoDiscoverConfig' –TTL 3
Outlook aktualisiert die Daten auch, wenn es nicht möglich war, Kontakt mit einem Exchange Server-Computer aufzunehmen. In diesem Fall wird alle fünf Minuten eine Aktualisierung versucht, bis Outlook die Daten abrufen kann. Um die Webdienstdaten abzurufen, wann immer es nötig ist, wird ein Hintergrundthread verwendet, sodass die Benutzer davon nichts mitbekommen.
650
Der AutoErmittlungsdienst
Mit dem Cmdlet Get-ClientAccessServer können Sie die Einstellungen eines Clientzugriffsservers abrufen, um sich einen Überblick darüber zu verschaffen, wie diese Daten verwendet werden. Get-ClientAccessServer –id 'ExchCAS1' Name OutlookAnywhereEnabled AutoDiscoverServiceCN AutoDiscoverServiceClassName AutoDiscoverServiceInternalUri
: : : : :
AutoDiscoverServiceGuid AutoDiscoverSiteScope IsValid OriginatingServer ObjectCategoryName DistinguishedName
: : : : : :
EXCHCAS1 False EXCHCAS1 ms-Exchange-AutoDiscover-Service https://exchcas1.contoso.com/Autodiscover/ Autodiscover.xml 77378f46-2c66-4aa9-a6a6-3e7a48b19596 {Dublin} True EXCHCAS1.contoso.com msExchExchangeServer CN=EXCHCAS1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=contoso, CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=contoso,DC=com
Vor allem zwei der hier gezeigten Informationen bedürfen der besonderen Beachtung. Die erste ist der Standortbereich (SiteScope, hier: Dublin), der angibt, dass dieser Clientzugriff zur Bedienung von Anforderungen der Clients im Active Directory-Standort Dublin eingerichtet ist. Den Standortbereich können Sie mit dem Cmdlet Set-ClientAccessServer festlegen. Zweitens ist der URI (Uniform Resource Identifier) des virtuellen Verzeichnisses für den AutoErmittlungsdienst von Bedeutung. Um den bestmöglichen Clientzugriffsserver für den AutoErmittlungsdienst auszuwählen, ziehen die Clients den Active Directory-Standortbereich heran. Wenn Active Directory mehrere Server zurückgibt, die in dem Standort zur Verfügung stehen, wählt Outlook einen davon zufällig aus und versucht ihn über HTTPS zu erreichen. Sobald die Verbindung hergestellt ist, ruft Outlook den AutoErmittlungsdienst auf diesem Server mit dem Wert der Eigenschaft AutoDiscoverServiceInternalUri auf (also mit dem URI, der auf den AutoErmittlungsdienst zeigt; vergleiche die vorstehende Beispielausgabe von Get-ClientAccessServer). Tatsächlich ist dies auch der Wert, der im Dienstverbindungspunkt gespeichert ist.
Standortbereiche Damit möglichst wenig Verzögerungen durch die Übertragung im Netzwerk auftreten, versucht Exchange stets, Clientcomputer mit dem Zugriffsserver zu verbinden, der ihnen (in der Active Directory-Topologie) am nächsten steht. Wie bereits erwähnt, wird für einen Clientzugriffsserver ein Standortbereich definiert, um festzulegen, für welche Clients er die AutoErmittlung durchführt. Ein Clientcomputer, der zum Standort London gehört, sucht während des AutoErmittlungsvorgangs nach einem Clientzugriffsserver, in dessen Bereich der Standort London enthalten ist.
651
Clientzugriffsserver
Einstellungen des Clientzugriffsservers
Kapitel 11
Clientzugriffsserver
Fehlerbehebung: Mein Outlook-Client kann nicht über Outlook Anywhere auf sein Postfach zugreifen
Ein Client, der Verbindung mit einem Postfach auf einem Exchange Server 2010-Computer aufnehmen möchte, muss einen Clientzugriffsserver derselben Version zu Rate ziehen, um die erforderlichen AutoErmittlungsinformationen für den Zugriff auf die erweiterten Webdienste von Exchange Server 2010 abzurufen. Wenn ein Outlook-Client also über Outlook Anywhere Verbindung mit einem Exchange Server 2010-Postfach aufnimmt und diese Verbindung von einem mit dem Internet verbundenen Clientzugriffsserver mit Exchange Server 2007 gehandhabt wird, ist der Zugriff auf das Postfach nicht möglich, denn der Exchange Server 2007-Computer kann keine Weitervermittlung an einen Computer mit Exchange Server 2010 vornehmen. Das liegt daran, dass er nichts von den RPC-Clientzugriffsdiensten von Exchange Server 2010 weiß und dass sich seine Methode zur Berechnung der MAPI-Endpunkte für Postfächer von der in der neueren Version unterscheidet. Jeder Versuch, Verbindungen über einen Clientzugriffsserver mit Exchange Server 2007 zu leiten, muss also unweigerlich fehlschlagen, wenn sich das Zielpostfach auf einem Computer mit Exchange Server 2010 befindet. Das ist der wichtigste technische Grund, aus dem Microsoft empfiehlt, schon sehr früh während der Bereitstellung die Clientzugriffsserver mit Exchange Server 2007 durch solche mit der neuen Version zu ersetzen, und zwar sowohl in internen Active Directory-Standorten als auch in solchen, die an das Internet angeschlossen sind. Im Allgemeinen kann eine neue Version von Exchange immer auf die Informationen zugreifen, die auf einem Server mit der älteren Version gespeichert sind. Umgekehrt ist das aber aufgrund von geändertem Code gewöhnlich nicht möglich. Genau das ist hier der Fall, und angesichts der grundlegenden Änderung, den MAPI-Endpunkt auf den Clientzugriffsserver zu verlegen, stellt das auch keine große Überraschung dar. Der Standortbereich wird während der Installation des Clientzugriffsservers erstellt, und es ist der Active Directory-Standort, in dem der Server eingerichtet wird. Ist London der Standortbereich, so heißt das, dass der Clientzugriffsserver im Standort London installiert wurde und zur Bedienung der AutoErmittlungsanforderungen von Clientcomputern an diesem Standort zuständig ist. Beachten Sie, dass Exchange nicht versucht, den Standortbereich zu ändern, wenn ein Clientzugriffsserver an einen anderen Standort verlegt wird. Ein Clientzugriffsserver kann nicht von selbst erkennen, an welchem Standort er sich zurzeit befindet. Ein falsch eingestellter Standortbereich kann dazu führen, dass ein Clientzugriffsserver die Clientanforderungen über ausgedehnte Verbindungen hinweg bedient. Es ist auch möglich, dass ein Clientzugriffsserver aufgrund des falschen Standortbereichs von den Clients ignoriert wird, sodass ein anderer Clientzugriffsserver (mit dem richtigen Bereich) eine Unmenge von Clientverbindungen handhaben muss und dadurch überlastet wird. Wenn Sie einen Clientzugriffsserver verlegen oder wenn Sie Server von einer Standardkonfiguration aus aufbauen, müssen Sie nach der Installation am endgültigen Produktionsstandort den Standortbereich anpassen. Ein Clientzugriffsserver kann auch auf AutoErmittlungsanforderungen aus mehreren Standorten antworten, wobei der Höchstwert bei 800 Standorten liegt. Erstaunlicherweise ist dieser Grenzwert in der Praxis tatsächlich von einer ganzen Reihe von Unternehmen erreicht worden, die einen Active Directory-Zugriff auf viele sehr kleine Standorte bereitstellen. Wenn Sie in Ihrer Umgebung ebenfalls Gefahr laufen, diesen Grenzwert zu überschreiten, bleibt Ihnen nichts anderes übrig, als die Last auf mehrere Clientzugriffsserver mit jeweils unterschiedlich definiertem Standortbereich zu verteilen. Außerdem sollten Sie AutodiscoverServiceInternalUri auf den FQDN eines Lastenausgleichsservers setzen (siehe
652
den Abschnitt »Lastenausgleich in Clientzugriffsarraysarrays« weiter hinten in diesem Kapitel), damit die Anforderungen auf alle verfügbaren Clientzugriffsserver verteilt werden. In dem folgenden Beispiel wird der Standortbereich eines Servers auf zwei Active Directory-Standorte eingestellt. Set-ClientAccessServer –id ExServer1 –AutoDiscoverSiteScope 'London', 'Dublin'
AutoKonfiguration Die AutoKonfigurationsfunktion von Outlook setzt die AutoErmittlung zusammen mit dem Prozess GuessSmart (also etwa »geschicktes Raten«) ein, um Informationen über Postfächer zu gewinnen. Dabei wird nach zu erwartenden Kombinationen von Server- und Protokollnamen gesucht. Die Autokonfiguration kann Einstellungen für POP3-und IMAP4-Konten herausfinden (mit AutoErmittlung und GuessSmart) und für Active Directory (mit AutoErmittlung), um das erforderliche Profil für die Verbindung mit Exchange aufzubauen. Außerdem eignet sie sich sehr gut dazu, ein Outlook-Profil für die Verbindung mit kostenlosen Endverbraucher-E-Mail-Diensten wie Hotmail zu erstellen. GuessSmart beruht auf ganz einfachen Prinzipien. Nehmen wir an, Sie möchen ein neues IMAP-Konto erstellen und Ihr Provider weist Ihnen die E-Mail-Adresse [email protected] zu. Dabei besteht eine hohe Wahrscheinlichkeit dafür, dass der IMAP-Server imap.contoso.com oder mail.contoso.com heißt und der SMTP-Server smtp.contoso.com oder mail.contoso.com. Outlook sucht daher über die von diesen Protokollen verwendeten Ports (Port 25 für SMTP und 110 für IMAP) nach Servern dieses Namens, um herauszufinden, ob diese angenommene Konfiguration funktioniert. Bei den meisten Internetprovidern lässt sich die richtige Kombination schnell raten. Wie Sie in Abbildung 11.2 sehen, gibt die Autokonfiguration URLs aus, mit denen Outlook Kontakt mit Exchange-Ressourcen wie dem Verfügbarkeitsdienst und dem Webverteilungspunkt für das Offlineadressbuch aufnehmen kann. Abbildg. 11.2
Ergebnisse der AutoKonfigurationsfunktion von Outlook 2010
653
Clientzugriffsserver
Der AutoErmittlungsdienst
Kapitel 11
Clientzugriffsserver
Wenn Sie einen Clientzugriffsserver für Outlook Anywhere einrichten, füllt der AutoErmittlungsdienst das Profil mit den Angaben aus, die Outlook braucht, um mithilfe von RPC über HTTP Verbindung mit Exchange aufzunehmen. Die Zeiger auf andere Dienste wie Exchange-Webdienste und das Offlineadressbuch muss der Administrator manuell einrichten. Dazu stellt er mit den Cmdlets Set-WebServicesVirtualDirectory und Set-OABVirtualDirectory die Eigenschaft ExternalURL so ein, dass sie auf den Ort zeigt, an dem die Clients Zugriff auf die Dienste haben. Den externen URL für das Offlineadressbuch können Sie auch in der Exchange-Verwaltungskonsole angeben. Markieren Sie dort den mit dem Internet verbundenen Clientzugriffsserver und ändern Sie die Eigenschaften des virtuellen Verzeichnisses für das Offlineadressbuch wie in Abbildung 11.3. Abbildg. 11.3
Sicherstellen des Zugriffs auf das Offlineadressbuch von außerhalb einer Firewall
Alternativ werden diese Werte für Outlook auch festgelegt, wenn ein Client innerhalb der Firewall Verbindung mit Exchange aufnimmt. Führt Outlook bei nachfolgenden Verbindungsversuchen erneut den AutoErmittlungsprozess durch, können sich diese Werte ändern.
Protokollierung von AutoErmittlungsvorgängen Wenn es bei der AutoErmittlung Probleme gibt, können Sie die Outlook-Protokollierung einschalten, sodass Outlook Angaben über die durchgeführten Vorgänge in die Datei Users\xxxx\AppDta\Local\ Temp\olkdisc.log schreibt. Abbildung 11.4 zeigt, wie Sie die Protokollierung in Outlook 2010 aktivieren. Während der Aufzeichnung von Diagnoseinformationen läuft Outlook langsamer, weshalb Sie die Protokollierung sofort wieder ausschalten sollten, wenn Sie diese Daten nicht mehr erfassen müssen. Im Folgenden sehen Sie ein Beispiel der dabei aufgezeichneten Daten. Hier können Sie erkennen, dass der Client zunächst versucht hat, Kontakt mit webmail.contoso.com aufzunehmen, eine Verbindung aber erst nach der Umleitung zu ExServer1.contoso.com erhalten hat, wo die Datei Autodiscover.xml mit den erforderlichen Informationen für den Kontakt mit den Exchange-Diensten vorhanden war und Outlook zur Verfügung gestellt werden konnte.
654
Thread Tick CountDate/TimeDescription 165638897203/03/10 18:38:47Attempting URL https://webmail.contoso.com /Autodiscover/Autodiscover.xml found through SCP 165638897203/03/10 18:38:47Autodiscover to https://webmail.contoso.com /Autodiscover/Autodiscover.xml starting 165639265403/03/10 18:38:51Autodiscover to https://webmail.contoso.com /Autodiscover/Autodiscover.xml Failed (0x800C8204) 165639265403/03/10 18:38:51Autodiscover URL redirection to https://ExServer1.contoso.com/Autodiscover/Autodiscover.xml 165639267003/03/10 18:38:51Autodiscover to https://ExServer1.contoso.com /Autodiscover/Autodiscover.xml starting 165639688203/03/10 18:38:55Autodiscover XML Received ---BEGIN XML--
655
Clientzugriffsserver
Der AutoErmittlungsdienst
Kapitel 11
Clientzugriffsserver
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=
Aktivieren der Protokollierung in Outlook 2010
Wenn Sie sich die Daten ansehen, die der AutoErmittlungsdienst von Exchange Server 2007 zurückgibt, so werden Sie feststellen, dass sie weit einfacher sind als die von Exchange Server 2010. In Exchange Server 2007 wurde zum ersten Mal dieser Dienst angeboten, um Clients mit Informationen für eine Kontaktaufnahme zu versorgen, ohne dass ein Eingreifen der Benutzer notwendig wäre. Dabei wurden lediglich Outlook und ActiveSync berücksichtigt, und die Informationen lagen im einfachen XML-Format vor. Der AutoErmittlungsdienst von Exchange Server 2010 veröffentlicht jedoch weit umfassendere Informationen (immer noch in XML) für eine sehr viel breitere Palette von Diensten, die auf die von Exchange angebotenen Webdienste zugreifen müssen. Beispielsweise macht die AutoErmittlung jetzt auch Angaben über persönliche Archive, sofern sie für ein Postfach zur Verfügung stehen. Außerdem kann die AutoErmittlung die Programmversion erkennen und gibt den Clients von Exchange Server 2007-Postfächern weniger Daten zurück, um sie nicht mit den Einzelheiten zu überwältigen, die Clients für eine Verbindung mit Exchange Server 2010 benötigen.
656
Es ist eine sinnvolle Vorgehensweise, die Outlook-Protokollierung einzuschalten, um Protokolldateien für erfolgreiche Verbindungen unter verschiedenen Bedingungen (intern und über das Internet) aufzunehmen und somit Vergleichswerte zur Verfügung zu haben. Bei Problemen können Sie dann die Protokolle für die fehlgeschlagenen Verbindungen damit vergleichen, um eine Vorstellung davon zu bekommen, worin die Ursache liegen mag. Das heißt nicht, dass Sie damit zwangsläufig jedes Verbindungsproblem lösen können, doch vermittelt es Ihnen wichtige Einsichten. Ein weiteres wertvolles Hilfsmittel, mit dem Administratoren der Ursache von Problemen mit der AutoErmittlung und Autokonfiguration auf den Grund gehen können, ist die Remoteverbindungsuntersuchung (siehe Kapitel 15, »Die Exchange-Toolbox«). Unter anderem können Sie damit Outlook Anywhere und die AutoErmittlung testen. Dazu müssen Sie lediglich eine gültige E-Mail-Adresse und ein Kennwort angeben. Das Werkzeug prüft dann nach, ob es über Outlook Anywhere Verbindung aufnehmen oder mithilfe der Autokonfiguration ein Profil erstellen kann, und meldet die Ergebnisse. Außerdem können Sie bei gedrückter (Strg)-Taste mit der rechten Maustaste auf das Outlook-Symbol in der Taskleiste klicken, um die aktuellen Verbindungseinstellungen von Outlook einzusehen. Dadurch erhalten Sie Informationen wie die Namen der Server, mit denen Outlook zurzeit verbunden ist. Neben dem Clientzugriffsserver kann das auch ein Postfachserver sein, wenn Sie auf öffentliche Ordner zugreifen. Diese Angaben werden häufig vom Supportpersonal zur Hilfestellung bei Verbindungsproblemen angefordert.
Statische AutoErmittlung Es gibt Situationen, in denen Sie den AutoErmittlungsvorgang übergehen und Outlook genau anweisen müssen, wo es die Exchange-Dienste finden kann. Nehmen wir an, Sie wollen Konten aus einer alten Ressourcengesamtstruktur mit Exchange Server 2007 in eine neue Gesamtstruktur mit Exchange Server 2010 verschieben. Zur Vorbereitung dieser Migration erstellen Sie in der neuen Gesamtstruktur neue E-Mail-aktivierte Konten für Exchange Server 2010, um sie später als Ziele für Verschiebeanforderungen zu verwenden, wenn die Benutzer zur Verlegung bereit sind. Auch die Clientcomputer mit Outlook werden in der neuen Gesamtstruktur installiert. Bis zum endgültigen Wechsel verbleiben die Postfächer jedoch noch in der alten Ressourcengesamtstruktur mit Exchange Server 2007. Wenn Outlook die AutoErmittlung durchführt, sucht es jedoch in der neuen Gesamtstruktur, entdeckt die neuen E-Mail-aktivierten Konten und versucht diese zu nutzen statt der Exchange Server 2007-Konten. Daher müssen Sie Outlook mitteilen, dass noch die Exchange Server 2007-Konten verwendet werden sollen, bis die Postfächer verschoben sind. Dazu sind die folgenden drei Maßnahmen erforderlich: 1. Erstellen Sie eine XML-Datei mit einem Zeiger auf den Speicherort der AutoErmittlungsdatei, die
Outlook verwenden soll. Diese XML-Datei wird auch als statische AutoErmittlungskonfiguration bezeichnet. 2. Erstellen Sie einen Registrierungseintrag, um Outlook mitzuteilen, wo die XML-Datei zu finden ist. 3. Erstellen Sie einen Registrierungseintrag, um Outlook anzuweisen, den Zeiger aus der XMLDatei zu verwenden.
657
Clientzugriffsserver
Der AutoErmittlungsdienst
Kapitel 11
Clientzugriffsserver
Die XML-Datei ist ziemlich einfach aufgebaut. An dem folgenden Codebeispiel können Sie ablesen, welche Informationen Sie darin angeben müssen. Der fettgedruckte Text ist die Anweisung für Outlook, nämlich der URL zu der AutoErmittlungsdatei, die Outlook verwenden soll.
Platzieren Sie die XML-Datei an einem Speicherort, an dem die Clients darauf zugreifen können. Für Outlook 2007 erstellen Sie in der Registrierung unter HKCU\Software\Microsoft\Office\12.0\Outlook\Autodiscover\
Schließlich müssen wir Outlook noch anweisen, die XML-Datei zu suchen, den Inhalt zu lesen und die darin enthaltenen Anweisungen zu beachten. Dazu verwenden wir einen weiteren Registrierungseintrag. Für Outlook 2007 erstellen Sie einen neuen DWORD-Einstrag unter HKCU\Software\Microsoft\Office\12.0\Outlook\Autodiscover\PreferLocalXML, für Outlook 2010 unter HKCU\Software\Microsoft\Office\14.0\Outlook\Autodiscover\PreferLocalXML. In beiden Fällen setzen Sie den Wert auf 1, um Outlook zu zwingen, die lokale XML-Datei zu verwenden und nicht die AutoErmittlung im Netzwerk. Diese Methode zur Konfiguration der AutoErmittlung erfordert es natürlich, die Registrierungsänderung an alle Clientcomputer zu übertragen, die aktualisiert werden müssen, um die statische AutoErmittlungskonfiguration zu verwenden. Dazu können Sie die Gruppenrichtlinien von Active Directory oder einen ähnlichen Mechanismus einsetzen.
SRV-Zeiger auf die AutoErmittlung Neben der zuvor beschriebenen Verwendung fester Domänennamen können nicht an die Domäne angeschlossene Clients mit Outlook 2007 SP1 und höher AutoErmittlungseinstellungen mithilfe von SRV-Einträgen in DNS finden. Das ist vor allem dann sehr hilfreich, wenn Sie Dienste für eine große Anzahl von Domänen anbieten. Beispielsweise verwenden einige Unternehmen »kosmetische« Domä-
658
nen für verschiedene Organisationen der Geschäftsgruppen oder für andere besondere Zwecke, z.B. besondere Ereignisse oder den Erhalt einer etablierten Marke nach einer Fusion oder Firmenübernahme. Zwar könnten Sie den AutoErmittlungsdienst in solchen Fällen auch mithilfe eines Zertifikats anbieten, das sämtliche zu verwendenden Domänennamen enthält, doch wäre das sehr aufwändig und schwer zu warten, vor allem, wenn sich die Domänennamen häufig ändern. Nehmen wir beispielsweise an, contoso.com möchte sowohl contoso-finance.com und contoso-sales.com verwenden als auch den alten Namen contoso-group.com weiterführen. Wie bereits erwähnt, könnten wir die drei zusätzlichen Domänen zu einem SAN-Zertifikat hinzufügen und die DNS-Einträge für die AutoErmittlung für jede dieser Domänen auf mail.contoso.com zeigen lassen, den allgemeinen Eintrittspunkt für Outlook Anywhere und OWA. Es ist jedoch möglich, dass noch weitere Domänen hinzukommen und wir ein neues SAN-Zertifikat erwerben müssen. Daher belassen wir es bei dem vorhandenen Zertifikat für mail.contoso.com und verwenden für die anderen Domänen SRV-Einträge. Dazu erstellen wir einen SRV-Eintrag in der externen DNS-Zone jeder der gewünschten Domänen. Entfernen Sie alle A- und CNAME-Einträge für den AutoErmittlungsdienst, sodass nur der SRV-Einträg übrig bleibt, der die AutoErmittlung auf mail.contoso.com umleitet. Dieser Eintrag sieht wie folgt aus: Service: _autodiscover Protocol: _tcp Port Number: 443 Host: mail.contoso.com
Wenn ein nicht an die Domäne angeschlossener Outlook-Client versucht, die AutoErmittlung für eine Adresse in der Domäne contoso-group.com zu verwenden, geschieht Folgendes: 1. Outlook wendet sich an https://contoso-group.com/Autodiscover/Autodiscover.xml. Das schlägt fehl,
da diese Adresse ungültig ist. 2. Danach versucht Outlook es mit https://autodiscover.contoso-group.com/Autodiscover/Autodisco-
ver.xml, was aus demselben Grund nicht funktioniert. 3. Outlook versucht, mithilfe der folgenden Umleitungsprüfung einen AutoErmittlungsdienst zu
finden: GET http://autodiscover.contoso-group.com/Autodiscover/Autodiscover.xml
Auch das schlägt aus dem bekannten Grund fehl. 4. Anschließend schlägt Outlook in DNS nach, um einen SRV-Eintrag für _autodiscover._tcp.con-
toso-group.com zu finden. Dieser Versuch ist von Erfolg gekrönt, und DNS gibt mail.contoso.com zurück. 5. Outlook zeigt dem Benutzer ein Dialogfeld an, um ihn um Erlaubnis dafür zu fragen, die AutoErmittlung über https://mail.contoso.com/autodiscover/autodiscover.xml fortzustzen. Dabei wird folgende Warnung ausgegeben: Konfigurieren von [email protected] für diese Website zulassen? Das Konto wurde für die Einstellungen auf diese Website umgeleitet. Sie sollten nur Einstellungen aus Quellen zulassen, die Sie kennen und denen Sie vertrauen. 6. Wenn der Benutzer die Erlaubnis erteilt, wird die POST-Anforderung von Outlook an https://
mail.contoso.com/autodiscover/autodiscover.xml zugestellt, sodass die AutoErmittlungsinformationen abgerufen werden können.
659
Clientzugriffsserver
Der AutoErmittlungsdienst
Kapitel 11
Clientzugriffsserver
Die Nachfrage, die in Schritt 5 angezeigt wird, kann den Benutzer verunsichern, da er, wenn er mit den Vorgängen nicht vertraut ist, wahrscheinlich nicht versteht, was mit Umleitung tatsächlich gemeint ist. Um dieses Dialogfeld zu unterdrücken (und damit Anrufe in Ihrer Supportabteilung zu vermeiden), können Sie den im Artikel http://support.microsoft.com/?kbid=956528 beschriebene Korrektur durchführen. Dabei geben Sie in einem Registrierungswert eine Reihe von Domänennamen an, um Outlook die Berechtigung für die Umleitung dieser Domänen schon im Voraus zu erteilen, sodass die Benutzer nicht gefragt werden müssen.
Clientzugriffsarrays Da die Clientzugriffsserver jetzt den Endpunkt für MAPI und alle anderen Clientprotokolle bilden, ist es wichtiger als je zuvor, für eine ausfallsichere Clientanbindung an diese Server zu sorgen. Wie Sie bereits wissen, wird den Postfachdatenbanken ein Zeiger auf den Clientzugriffsserver zugewiesen. Das funktioniert so lange, bis der Clientzugriffsserver offline geht. Kommt er nicht schnell wieder online, erhalten die Clients keine Verbindung mit ihren Postfächern. Dieses Problem droht immer dann, wenn ein Dienst auf einen einzigen Server angewiesen ist. In Exchange Server 2010 gibt es eine neue Lösung dafür, denn hier können Sie ein Array aus Clientzugriffsservern einrichten, die über einen einzigen Netzwerknamen und eine einzige IP-Adresse zu ereichen sind. Diese Verbindungsinformationen sind es auch, die einer Postfachdatenbank zugewiesen werden. Die Clients sind also nicht auf die Verbindung mit einem einzigen Clientzugriffsserver angewiesen, sondern können sich an jeden der Server innerhalb des Clientzugriffsarrays wenden, indem Sie den FQDN dieses Arrays statt den eines einzelnen Servers angeben. Durch das Clientzugriffsarray wird eine weitere feste Beziehung zwischen Client und Postfach aufgehoben. Außerdem bietet es eine grundlegende Ausfallsicherheit, da die Clients auch bei einem Serverausfall weiterarbeiten können. Insidertipp: Einschränkungen für große Installationen
Clientzugriffsarrays sind für große Umgebungen sehr reizvoll, allerdings schränkt die Begrenzung auf ein Array pro Standort das Active Directory-Design ein. Stellen Sie sich beispielsweise ein Unternehmen vor, das seine gesamte Informationstechnologie auf eine Reihe großer Standorte aufgeteilt hat, die Anwendungen für die Benutzer in verschiedenen Regionen der Erde bereitstellen. Die Beschränkung auf ein Clientzugriffsarray pro Standort führt zu einem Problem, da der Datenverkehr von verschiedenen Benutzergruppen innerhalb eines Standorts nicht getrennt und unterschiedlich gehandhabt werden kann. Eine Beziehung zwischen Active Directory-Standorten und Clientzugriffsarrays macht vieles einfacher, beraubt Sie aber gerade in besonders umfangreichen und vielschichtigen Umgebungen einiger Möglichkeiten. Ein weiteres Problem, das Sie bedenken müssen, besteht darin, dass Sie mit einem Clientzugriffsarray im Grunde genommen ein alleiniges Ziel für sämtliche mit diesem Array verknüpften Postfachdatenbanken erstellen. Fällt das Array aus irgendeinem Grund aus, können die Clients keine Verbindung mehr mit ihren Datenbanken aufnehmen. TIPP Ein Clientzugriffsarray ist keine Lastenausgleichslösung, doch wenn Sie vor dem Array einen Lastenausgleichsserver platzieren, werden die Clientverbindungen gleichmäßig auf die Server im Array verteilt.
660
In einem Active Directory-Standort kann es nur ein einziges Clientzugriffsarray geben, und ein Clientzugriffsarray kann auch nicht mehr als einen Standort umfassen. Es müssen jedoch nicht alle Clientzugriffsserver eines Standorts in dem Array enthalten sein, sodass Sie auch weiterhin den Postfachdatenbanken des Standorts einzelne Server zuweisen können. Alle Clientzugriffsserver in einem Array sollten dieselbe Version von Exchange bis hin zu den Rollupaktualisierungen ausführen. Es ist zwar möglich, dass auf den einzelnen Servern im Array unterschiedliche Hotfixes installiert sind, doch kann das im Falle eines Problems die Fehlersuche erschweren, da sich die Frage stellt, ob das Vorhandensein eines Hotfixes die Ursache sein mag. Am besten ist, auf allen Servern im Array exakt dieselbe Software zu installieren.
Erstellen eines Clientzugriffsarrays Der erste Schritt besteht darin, das Clientzugriffsarray mit New-ClientAccessArray zu ertellen und mit dem FQDN und dem Active Directory-Standort zu verknüpfen, für den es zuständig ist. Für den FQDN muss es in DNS einen A-Eintrag geben. New-ClientAccessArray –Name 'CAS-Array-01' –FQDN 'CASArrayDublin.contoso.com' –Site 'Dublin'
Insidertipp: Nicht zur Nachahmung empfohlen
Sie sollten den FQDN des Arrays nicht veröffentlichen, sodass er von externen DNS-Diensten aufgelöst werden kann. Schließlich wollen Sie nicht, dass Clients mit Outlook Anywhere versuchen, über RPC Verbindung mit dem Array aufnehmen. Diese Clients können den Arraynamen nämlich in DNS auflösen (das Array ist in ihrem Profil als MAPI-Endpunkt angegeben), müssen dann aber bis zu 30 Sekunden auf eine RPC-Zeitüberschreitung warten, bis sie über HTTPS Kontakt mit dem Outlook Anywhere-URL aufnehmen können. Weisen Sie die Clientzugriffsserver im Array der Lösung zum Netzwerklastenausgleich zu, die Sie verwenden möchten. Das kann der Netzwerklastenausgleich von Windows sein oder ein Hardware-Ausgleichsserver mit der IP-Adresse, die Sie dem Array zugewiesen haben. Unter diesen Umständen benötigt Exchange Zugriff auf TCP-Port 135 (Endpunktzuordnung) und einen beschränkten dynamischen RPC-Portbereich (6005–65535). Dieser Bereich wurde ausgewählt, da in vielen Exchange Server 2007-Umgebungen die Ports 6000–6004 für Verbindungen zwischen Clientzugriffs- und Postfachservern verwendet werden. Zur Vereinfachung können Sie für MAPI-Verbindungen und den Verzeichniszugriff statische Ports zuweisen. Diesem Thema werden wir uns in Kürze widmen. Nachdem Sie das Clientzugriffsarray erstellt haben, müssen Sie die Einstellungen der Postfachdatenbanken im Standort erweitern, um eingehende Clientverbindungen zu dem Array umzuleiten. Werden neue Postfachdatenbanken erstellt, nachdem das Clientzugriffsarray schon vorhanden ist, erkennen sie automatisch dessen Vorhandensein, aber bereits bestehende Datenbanken müssen Sie manuell anpassen. Dazu geben Sie ihnen wie folgt die Informationen über das Array an: Set-MailboxDatabase –Identity 'DB1' –RpcClientAccessServer 'CAS-Array-01'
Das Cmdlet Get-ClientAccessArray gibt nicht etwa eine Liste der Clientzugriffsserver eines Arrays zurück, sondern die Liste sämtlicher Clientzugriffsserver eines Standorts. Der Befehl ist sehr unglücklich implementiert, denn schließlich müssen nicht alle Clientzugriffsserver eines Standorts Mitglied des Arrays sein.
661
Clientzugriffsserver
Clientzugriffsarrays
Kapitel 11
Clientzugriffsserver
HINWEIS Der Wert von RpcClientAccessServer kann auf ein Array, aber auch auf einen einzelnen Clientzugriffsserver zeigen. Ein Clientzugriffsarray ist für Outlook-Clients da, die über MAPI Verbindung aufnehmen. Wenn Sie auch den Windows-Netzwerklastenausgleich verwenden, um ein Array für andere Clientprotokolle wie Outlook Anywhere und ActiveSync bereitzustellen, sollten Sie dafür einen anderen FQDN angeben, damit Outlook-Clients außerhalb Ihres Netzwerks sofort auf Outlook Anywhere zurückgreifen können, wenn sie den FQDN für das Clientzugriffsarray nicht auflösen können. Hat das Clientzugriffsarray also beispielsweise den FQDN outlook.contoso.com, so können Sie für Outlook Anywhere etwa den FQDN webmail.contoso.com verwenden. Wenn Sie einen Clientzugriffsserver, der zu einem Array gehört, außer Betrieb setzen, müssen Sie ihn auch aus dem Lastenausgleichspool herausnehmen und die Einstellungen der Postfachdatenbanken anpassen, sodass sie weiterhin mit einem einzelnen Clientzugriffsserver oder einem Clientzugriffsarray am Standort verknüpft sind. Fällt ein Clientzugriffsserver in einem Array aus oder wird er neu gestartet, ohne dass dabei Verbindungen unterbrochen werden (saubere Trennung), stellen die Outlook-Clients eine Verbindung zu einem anderen Server im Array her. OWA-Clients reagieren in einer Situation heikler und zeigen den Benutzern eine Meldung an, nach der ein unerwarteter Fehler aufgetreten ist und die Anforderung nicht verarbeitet werden konnte. Die Benutzer müssen sich dann auf der Authentifizierungsseite neu bei OWA anmelden.
Verwalten standortübergreifender Verbindungen mit dem RPC-Clientzugriffsdienst Clientzugriffsarrays werden häufig für Datenbankverfügbarkeitsgruppen in Rechenzentren bereitgestellt. Um die Möglichkeiten für eine Notfallwiederherstellung zu verbessern, können Sie die Verfügbarkeitsgruppe über ein Haupt- und ein Reserverechenzentrum ausdehnen. In einer solchen Situation verfügt meistens jedes Rechenzentrum über sein eigenes Clientzugriffsarray. Tritt der Fall ein, dass Sie das zweite Rechenzentrum aktivieren müssen, schalten die Clients jedoch nicht automatisch auf die dortigen Clientzugriffsserver um. Dazu müssen Sie die DNS-Informationen ändern und den Zeiger auf das Clientzugriffsarray im ersten Rechenzentrum durch einen Zeiger auf das zweite Array ersetzen. Es kann jedoch auch sein, dass im ersten Rechenzentrum nur ein Teilausfall auftritt und Sie als Ersatz für die betroffenen Server zusätzliche Kapazität aus dem zweiten bereitstellen wollen. Das kann auch auf einige Computer im Clientzugriffsarray zutreffen, wobei Sie das Array umgestalten müssen, um ihm Clientzugriffsserver aus dem zweiten Rechenzentrum hinzuzufügen. Für die ursprüngliche Version von Exchange Server 2010 wurde im Allgemeinen empfohlen, die Eigenschaft RpcClientAccessServer für Datenbanken während eines Failovers nur dann zu ändern, wenn dies absolut notwendig ist, z.B. wenn das Clientzugriffsarray im ersten Rechenzentrum nicht mehr erreichbar ist. Bleibt das Array dort jedoch betriebsbereit, gilt Folgendes: 쐍 Die Clients nutzen zur Verbindungsaufnahme weiterhin das Clientzugriffsarray im Hauptrechenzentrum. 쐍 Die Clients müssen ihre Profile nicht ändern und daher auch nicht neu gestartet werden (was notwendig wäre, um eine Profiländerung in Kraft treten zu lassen). Das Clientzugriffsarray im ersten Rechenzentrum verbindet die Clients mit den Postfachservern im zweiten, bis sie die Dienste wieder zurück auf die Postfachserver im ersten verlegen.
662
Das funktioniert zwar, ist aber nicht so wirkungsvoll, wie es sein könnte. Mit Exchange Server 2010 SP1 wurde daher die Handhabung von standortübergreifenden Verbindungen geändert. Um zu entscheiden, welche Maßnahmen zu ergreifen sind, müssen Sie die folgenden vier Elemente überprüfen: 1. Die Einstellungen für standortübergreifende Verbindungen in der Datenbankverfügbarkeitsgrup-
pe. Sie werden in der Eigenschaft AllowCrossSiteRPCClientAccess der Gruppe festgehalten, die standardmäßig auf False eingestellt ist. Nähere Informationen zum Festlegen von Eigenschaften für Datenbankverfügbarkeitsgruppen finden Sie in Kapitel 8. 2. Der im Outlook-Profil registrierte Servername. In früheren Versionen von Exchange wurde im Profil der Name des Postfachservers mit der Datenbank angegeben, in der sich das Benutzerpostfach befindet, in Exchange Server 2010 jedoch der Name des mit der Postfachdatenbank verknüpften Clientzugriffsservers oder -arrays. 3. Der Active Directory-Standort, zu dem der im Outlook-Profil angegebene Clientzugriffsserver (bzw. das Array) gehört. Dieser Wert wird als bevorzugter Datenbankstandort bezeichnet. 4. Der Active Directory-Standort, auf dem die aktive Kopie der Datenbank mit dem Benutzerpostfach zurzeit bereitgestellt ist. Dieser Wert wird als aktiver Datenbankstandort bezeichnet. In Tabelle 11.2 können Sie ablesen, welche Maßnahmen in den vier verschiedenen möglichen Situationen ergriffen werden. In allen diesen Fällen gehen wir von dem Rechenzentrum in Dublin aus, das über das Clientzugriffsarray ExCASArray1.contoso.com verfügt. Der erste in der Tabelle aufgezeigte Fall ist die Normalsituation, in der die Postfachdatenbank im bevorzugten Standort bereitgestellt ist und die Clientverbindungen über das Array zu den Postfachservern desselben Standorts verlaufen. Nehmen wir nun an, dass ein Ausfall dazu zwingt, zu den Postfachservern am Standort London zu wechseln. Der zweite und dritte Fall beschreiben die Situation je nachdem, ob in der Datenbankverfügbarkeitsgruppe standortübergreifende Verbindungen zulässig sind oder nicht. Im vierten Fall befindet sich die bevorzugte Datenbank jetzt in London, da das Rechenzentrum in Dublin von einem katastrophalen Ausfall heimgesucht wurde und auf längere Sicht nicht mehr online gehen kann. Dies erfordert eine Aktualisierung der Outlook-Profile, sodass sie die neuen Umstände widerspiegeln. Tabelle 11.2
Handhabung von standortübergreifenden Verbindungen in Exchange Server 2010 SP1 Name des Clientzugriffsservers im Outlook-Profil
Bevorzugter Datenbankstandort
Aktiver Datenbankstandort
Ergebnis
ExCASArray1.contoso.com
Dublin
Dublin
Direkte Verbindung von Outlook zur Postfachdatenbank über den RPC-Clientzugriffsdienst.
ExCASArray1.contoso.com (Standort Dublin)
Dublin
London
Wenn standortübergreifende Verbindungen zulässig sind, erlaubt der RPC-Clientzugriffsdienst Outlook, Verbindung mit der Postfachdatenbank am Standort London aufzunehmen.
ExCASArray1.contoso.com (Standort Dublin) Aktualisiert auf: ExCASArray2.contoso.com (Standort London)
Dublin
London
Sind standortübergreifende Verbindungen nicht zulässig, leitet der RPC-Clientzugriffsdienst Outlook zu den Postfachdatenbanken am Standort London um und erzwingt eine Änderung des Outlook-Profils auf den Namen eines Clientzugriffsservers oder -arrays des Londoner Standorts.
663
Clientzugriffsserver
Clientzugriffsarrays
Kapitel 11 Tabelle 11.2
Clientzugriffsserver
Handhabung von standortübergreifenden Verbindungen in Exchange Server 2010 SP1 Name des Clientzugriffsservers im Outlook-Profil
Bevorzugter Datenbankstandort
Aktiver Datenbankstandort
Ergebnis
ExCASArray1.contoso.com (Standort Dublin) Aktualisiert auf: ExCASArray2.contoso.com (Standort London)
London
London
Der RPC-Clientzugriffsdienst leitet Outlook zu den am Standort London bereitgestellten Postfachdatenbanken um und erzwingt eine Änderung des Outlook-Profils auf den Namen eines Clientzugriffsservers oder -arrays des Londoner Standorts.
Lastenausgleich in Clientzugriffsarrays Die Kombination des Windows-Netzwerklastenausgleichs (Network Load Balancing, NLB) mit einem Clientzugriffsarray ist eine kostengünstige Lösung, um innerhalb eines Active DirectoryStandorts belastbare Verbindungsdienste für Exchange bereitzustellen. NLB ist in Windows enthalten und daher kostenlos. Der Nachteil besteht allerdings darin, dass es sich um eine unintelligente Lastenausgleichsfunktion handelt, die einen bedauerlichen Mangel an Kenntnissen über die angebotenen Dienste aufweist. Um einen Server als geeigneten Kandidaten für den Lastenausgleich einzuschätzen, prüft NLB prüft nämlich weder die Ports noch die Dienste auf ihm. Solange der Server ein Taktsignal sendet, hält NLB ihn für geeignet. Außerdem gibt es keine Kommunikation zwischen Exchange und NLB, und Exchange versucht auch nicht, die Clientverbindungen auf die einzelnen Clientzugriffsserver eines Arrays zu verteilen. Tatsächlich ist ein Clientzugriffsarray einfach nur ein Active Directory-Objekt, das es Exchange ermöglicht, den Clients mehrere Zugriffsserver über einen einzigen logischen Verbindungspunkt bereitzustellen. Angesichts dieser Einschränkungen ist NLB keine geeignete Lösung für High-End-Umgebungen, in der Sie wahrscheinlich in Hardware für den Lastenausgleich auf allen Schichten der Verbindungen investieren. Welches Lastenausgleichsprodukt Sie auch immer verwenden, so gelten doch stets die folgenden Prinzipien: 쐍 NLB (oder ein anderes Produkt) stellt für die Server im Clientzugriffsarray eine einzige virtuelle IP-Adresse und einen einzigen FQDN bereit, über die die Clients Verbindung aufnehmen. Das einfachste mögliche Clientzugriffsarray besteht aus lediglich zwei Clientzugriffsservern. 쐍 Microsoft empfiehlt, in ein Windows-Lastenausgleichsarray nicht mehr als acht Server aufzunehmen. Wenn Sie daher den Windows-Netzwerklastenausgleich verwenden, folgt daraus, dass auch ihr Clientzugriffsarray nicht mehr als acht Clientzugriffsserver enthalten sollte. Bei einer Hardwarelösung für den Lastenaugleich gibt es jedoch praktisch kein Limit für die Anzahl der Server im Array. 쐍 Eingehende Clientverbindungen werden auf die Server im Clientzugriffsarray verteilt. 쐍 Die Postfachserver des Standorts verwenden automatisch das Clientzugriffsarray als Verbindungspunkt. Ein einzelner RPC-Clientzugriffsdienst kann bis zu 100 gleichzeitige Clientverbindungen handhaben. Microsoft hat geäußert, dass ein Postfachserver mit Exchange Server 2007 bis zu 64.000 gleichzeitige Verbindungen handhaben kann (sofern er über ausreichende Ressourcen für diese Belastung verfügt), ein Postfachserver mit Exchange Server 2010 jedoch bis zu 250.000 RPC-Verbindungen.
664
Diese Zahlen sind noch nicht durch unabhängige Leistungstests bestätigt worden, sie zeigen aber, welche neuen Größenmaßstäbe Microsoft in Exchange setzt. Dies dient hauptsächlich dazu, dass die Software mit den ständig steigenden Hardwarefähigkeiten Schritt halten kann. HINWEIS Es gibt eine 1:1-Zuordnung von Verbindungen zu Outlook-Sitzungen. Wenn eine Verbindung verloren geht, muss Outlook eine neue Sitzung aufbauen. Die Verlegung des Endpunkts für Verbindungen vom Postfach- auf den Clientzugriffsserver soll jedoch nicht nur eine solche Größenveränderung möglich machen. Der wichtigere Grund bestand darin, von dem früheren Zustand wegzukommen, in dem eine Datenbank auf einem Postfachserver eine neuralgische Fehlerstelle darstellte, und eine Umgebung zu entwickeln, in der der Clientzugriffsserver eingehende Clientverbindungen je nach Verfügbarkeit der Server zu unterschiedlichen Datenbanken umschalten kann. Das Prinzip wird auch im laufenden Betrieb weiterverfolgt. Wenn Active Manager beispielsweise erkennt, dass eine Datenbank auf einem Server nicht mehr funktioniert, sodass auf eine passive Kopie umgeschaltet werden muss, wird die Information über die aktive Datenbank in der Datenbankverfügbarkeitsgruppe aktualisiert (diese Angabe ist in Active Directory gespeichert), sodass die Clients zu dem neuen Server umgeleitet werden können.
Aktualisieren eines Clientzugriffsservers in einem Array Da Clientzugriffsserver für die Anbindung der Clients so wichtig sind, besteht immer die Gefahr, Clientverbindungen zu stören, wenn Sie einen solchen Server offline schalten müssen, um beispielsweise ein Service Pack oder eine Rollupaktualisierung einzuspielen. Wenn Sie den Clientzugriffsserver plötzlich beenden, hat das mit Sicherheit negative Auswirkungen, denn dann können keine neuen Verbindungen zu Exchange mehr aufgebaut werden, während die bestehenden Verbindungen abrupt abgebrochen werden. Outlook-Clients im Exchange-Cache-Modus können offline weiterarbeiten, andere Clients aber verlieren den Kontakt zu ihren Postfächern. Wenn es nur einen einzigen Clientzugriffsserver für einen Standort oder die gesamte Exchange-Umgebung gibt, sind solche Situationen unvermeidlich, weshalb Wartungsarbeiten für einen Zeitpunkt mit geringer Clientaktivität zu planen sind. In vielen Unternehmen wird eine Farm von Clientzugriffsservern für die Verbindungen bereitgestellt, wobei sich das Clientzugriffsarray gewöhnlich hinter einem Lastenausgleichsserver befindet. In einer solchen Situation können Sie wie folgt vorgehen, um einzelne Server offline zu schalten, zu aktualisieren und wieder in die Farm einzubringen. Auch diese Arbeiten sollten Sie jedoch für Zeiten planen, an denen die Auswirkungen auf die Clients möglichst gering sind. 1. Entfernen Sie einige der Clientzugriffsserver aus dem Lastenausgleichsarray, damit keine neuen
Verbindungen zu ihnen aufgebaut werden können, während die bereits vorhanden noch bestehen bleiben. Wie viele Server Sie herausnehmen, hängt davon ab, was für eine Belastung durch Clientverbindungen für den Zeitraum zu erwarten ist, in dem die Computer offline sind. Manche Unternehmen bevorzugen es, immer die Hälfte ihrer Server auf einmal offline zu schalten, um die komplette Aktualisierung in zwei Schüben durchführen zu können. Wenn die Umgebung jedoch rund um die Uhr in Betrieb und die Verbindungslast gleich bleibend hoch ist, können Sie dagegen immer nur ein oder zwei Server auf einmal aus der Farm herausnehmen. Wichtig ist, dass in der Farm noch ausreichend Kapazität verbleibt, um auch unerwartete Belastungen abzufedern.
665
Clientzugriffsserver
Clientzugriffsarrays
Kapitel 11
Clientzugriffsserver
2. Warten Sie eine Stunde, bis sich die Anzahl der vorhandenen Clientverbindungen auf den ent-
3. 4.
5. 6.
7. 8.
fernten Clientzugriffsservern verringert hat. Im Idealfall sollte sie auf null zurückgehen, sodass keinerlei Clients betroffen wird, wenn wir die Server offline schalten, aber in der Praxis gibt es immer die eine oder andere Clientverbindung, die Sie zwangsweise beenden müssen. Diese Verbindungen müssen dann unter Zuhilfenahme der in der Farm verbliebenen Clientzugriffsserver neu aufgebaut werden. Schalten Sie die ausgewählten Server offline und führen Sie die Aktualisierung durch. Testen Sie die Server, um sicherzustellen, dass die Aktualisierung erfolgreich war und nicht zu Einstellungen geführt hat, die einen Client daran hindern könnten, Verbindung mit dem Server aufzunehmen. Für diese Prüfung können Sie eine Reihe verschiedener Methoden anwenden. Beispielsweise können Sie das Cmdlet Test-ServiceHealth ausführen oder sich mit einem URL, der auf einen aktualisierten Server zeigt, bei OWA anmelden. Führen Sie die aktualisierten Clientzugriffsserver wieder in die Farm ein und aktualisieren Sie die Lastenausgleichslösung, sodass neue Verbindungen jetzt wieder zu diesen Servern gehen können. Warten Sie darauf, dass sich die Clientzugriffsfarm stabilisiert. Die aktualisierten Server sollten jetzt deutlich machen, dass sie die vollständige Last verkraften können, auch Verbindungen von Outlook, OWA und ActiveSync. Wiederholen Sie die Schritte 1 bis 6, um weitere Server zu aktualisieren. Stellen Sie sicher, dass die vollständig aktualisierte Farm die komplette Produktionslast schultern kann. Normalerweise können Sie keinen Test mit der vollen Produktionslast durchführen. Stattdessen müssen Sie die Clientzugriffsfarm genau bearbeiten, wenn während der nächsten Spitzenphase der Clientanforderungen eine solche Last aufgebaut wird. Um sicherzustellen, dass alles wie erwartet funktioniert, eigenen sich ihre Benutzer als die besten Tester. Wenn irgendjemand ein Problem mit dem Zugriff auf sein Postfach hat, werden Sie schnell davon hören.
Die hier beschriebene Vorgehensweise ist nur eine allgemeine Methode zur Aktualisierung von Servern in einem Array, die Sie vor dem Einsatz in er Produktion sorgfältig testen müssen. Die Notwendigkeit dafür wird durch die Erfahrungen mit der Aktualisierung auf Exchange Server 2010 SP1 unterstrichen. Wenn in einem Clientzugriffsarray sowohl RTM- als auch SP1-Server vorhanden sind, kann die ActiveSync-Anbindung unzuverlässig werden. Eine Variante, die in diesem Fall gut funktioniert, besteht darin, einen Server aus dem Array herauszunehmen, ihn zu aktualisieren und die DNS-Einträge dann so anzupassen, dass sie auf den SP1-Server zeigen, sodass dieser die Verbindungsanforderungen übernimmt. Anschließend aktualisieren Sie die anderen Server im Array, bevor Sie das vollständig aktualisierte Array online schalten. Je schneller Sie die Aktualisierung erledigen, umso eher können Sie den normalen Betrieb für die Clients wieder fortsetzen.
Clientzugriffsserver und Umkreisnetzwerke Bei einer Aktualisierung von Exchange Server 2003 sind Sie vielleicht versucht, den Clientzugriffsserver für einen direkten Ersatz des Front-End-Servers zu halten, den Sie in einem Umkreisnetzwerk installieren, um eingehende Verbindungen aus dem Internet zu verarbeiten und nicht authentifizierte Verbindungen zu blockieren. Ein Umkreisnetzwerk (auch als entmilitarisierte Zone bezeichnet) wird als Schutzvorkehrung zwischen dem Internet und dem Intranet des Unternehmens aufgebaut. In diesem Netzwerk werden Server untergebracht, die in der Lage sind, den Gefahren von Angriffen aus dem Internet zu trotzen. Sie überwachen und blockieren die Angriffswege. In einer solchen Situation trennt eine Firewall die Front-End-Server vom Rest der Exchange-Organisation und bereinigt den Datenverkehr von den Front-End-Servern zu den Back-End-Postfachservern. In
666
Exchange Server 2010 gibt es die Rollen des Front- oder Back-End-Servers nicht mehr, und Microsoft unterstützt auch nicht die Bereitstellung von Clientzugriffsservern in Umkreisnetzwerken. Wenn Sie von Exchange Server 2003 auf Exchange Server 2010 aktualisieren, müssen Sie daher Ihren Bereitstellungsplan ändern. Als Erstes müssen Sie sich über den Unterschied zwischen einem Front-End- und einem Clientzugriffsserver im Klaren sein. Ein Front-End-Server verfügt über den gesamten Code eines regulären Exchange Server 2003-Computers, führt in seiner Rolle aber nur einen Bruchteil davon aus. Microsoft hatte nicht die Zeit, in Exchange Server 2003 eine besondere Serverrolle für die Bereitstellung in Umkreisnetzwerken zu entwickeln. Die Edge-Transport-Server von Exchange Server 2010 erfüllen zwar nicht denselben Zweck wie die Front-End-Server, sind aber eigens für den Einsatz im Umkreisnetzwerk da und kümmern sich gut um den SMTP-Datenverkehr, der aus dem Internet eingeht. Die anderen Clientprotokolle müssen jedoch nach wie vor verarbeitet werden, und dafür sind die Clientzugriffsserver da. Obwohl die Front-End-Server auf den ersten Blick ähnlich erscheinen, führen sie doch eine andere Aufgabe aus als Clientzugriffsserver. Beispielsweise nehmen Front-End-Server keine Darstellung für OWA vor (das haben in Exchange Server 2003 die Postfachserver erledigt) und enthalten auch nicht den Middle-Tier-Code, den Clientzugriffsserver zur Verarbeitung von HTTPS-, MAPI-, ActiveSync-, EWS-, POP3- und IMAP-Verbindungen nutzen. Da ein Clientzugriffsserver sämtliche Clientverbindungen handhabt, kommuniziert er ständig mit Active Directory, um Daten über Benutzer, Server und andere Gesichtspunkte der Exchange-Konfiguration abzurufen. Server, die sich auf Active Directory stützen, wollen wir aber nicht in einem Umkreisnetzwerk platzieren, da hierbei die Gefahr besteht, dass ein Hacker darüber Zugriff auf Active Directory erhält. Das ist ein Grund dafür, dass Edge-Transport-Server Active Directory nicht verwenden und auch nicht benötigen. Andererseits müssen wir natürlich den Clientdatenverkehr wie bei den Front-End-Servern von Exchange Server 2003 authentifizieren, um den Zugriff auf die Postfachserver zu ermöglichen. Die Lösung besteht in einer Vorabauthentifizierung durch Reverseproxyserver. Bei der Einführung von Exchange Server 2003 waren Reverseproxyserver noch nicht sehr verbreitet, während Microsoft ISA Server noch in den Kinderschuhen steckte. Seitdem hat es jedoch große Fortschritte gegeben, was den Funktionsumfang und die Möglichkeiten von Reverseproxyservern angeht. Jetzt bilden sie die offensichtliche Lösung für das Problem, in einem Umkreisnetzwerk einen Server zu platzieren, der für eine breite Palette von Anwendungen als alleinige sichere Schnittstelle fungiert. Reverseproxyserver umfassen gewöhnlich eine Reihe von Verteidigungseinrichtungen, um Sondierungen und Angriffen zu widerstehen, und sind dabei viel stärker geschützt als ein normaler E-MailServer jemals sein kann. Daher gibt es keinen Grund mehr dafür, Clientverbindungen durch Exchange-Front-End-Server authentifizieren zu lasen, da diese Aufgabe der Reverseproxyserver übernehmen kann. Die Clientzugriffsserver wiederum vertrauen darauf, dass ihnen der Reverseproxyserver nur bereinigte Clientverbindungen zukommen lässt, die keine Gefahr für Exchange bedeuten. Wenn Sie von Exchange Server 2003 aus aktualisieren, müssen Sie daher dafür sorgen, dass es im Umkreisnetzwerk zuverlässige und stabile Reverseproxyserver gibt, die die eingehenden Verbindungen handhaben können. Diese Server nehmen anstelle der Front-End-Server die Vorabauthentifizierung der Clients vor und leiten die Verbindungen über eine Firewall an die Clientzugriffsserver im Intranet weiter. Wie Sie die Komponenten im Einzelnen einrichten müssen, hängt davon ab, welche Hardware- oder Softwarelösung Sie für die Reverseproxys verwenden und welche Firewalls vorhanden sind, aber das allgemeine Prinzip ist stets das Gleiche. Die meisten Hersteller geben ihre eigenen Empfehlungen heraus, an denen Sie sich bei den verschiedenen Formen von Exchange-Bereitstellungen orientieren können.
667
Clientzugriffsserver
Clientzugriffsserver und Umkreisnetzwerke
Kapitel 11
Clientzugriffsserver
Weitere Informationen
Der Artikel auf http://technet.microsoft.com/de-de/library/bb331973.aspx führt die Ports auf, die von den verschiedenen Rollen von Exchange Server 2010 verwendet werden.
Protokollierung des RPC-Clientzugriffs Standardmäßig unterhält Exchange ein Protokoll für den RPC-Clienzugriffsdienst. Dieses Protokoll können Sie einsehen, um Informationen über eingehende Clientverbindungen zu erhalten, was bei der Fehlersuche hilfreich sein kann. Die Protokollierung unterliegt den Einstellungen in der Konfigurationsdatei des RPC-Clientzugriffsdienst (Microsoft.Exchange.RpcClientAccess.Service.exe.config), die sich im Verzeichnis mit den Binärdateien für Exchange befindet. Wie die Konfigurationsdateien der anderen Exchange-Dienste können Sie auch diese mit einem Texteditor ändern. Damit diese Änderungen in Kraft treten, müssen Sie den Dienst anschließend neu starten. Wenn Sie die Konfigurationsdatei im folgenden Beispiellisting Schritt für Schritt durchgehen, können Sie die wichtigsten Einstellungen erkennen, die sich ändern lassen. Wie bereits gesagt, ist die Protokollierung standardmäßig aktiviert. Die folgende Einstellung besagt, dass die Protokolle im Pfad \Logging\RPC Client Access\ des Verzeichnisses festgehalten werden, in dem die Exchange-Binärdateien installiert sind. Die Maximalgröße, auf die ein Protokoll wachsen kann, bevor Exchange ein neues erstellt, beträgt 10 MB. Exchange legt täglich ein neues Protokoll an, nachdem der erste Client über RPC Verbindung aufgenommen hat, und legt darin 10 MB an Daten ab. Danach wird zum nächsten Protokoll gewechselt. Die Protokollnamen sind nach dem Schema RCA_<JJJJMMTT_x>. log aufgebaut. RCA_20100720_1.log ist also das erste Protokoll, das am 20. Juli 2010 erstellt wurde. Wird ein zweites Protokoll fällig, da mehr als 10 MB an Daten vorliegen, so trägt dieses den Namen RCA_20100720_2.log usw. Exchange hebt die RPC-Clientzugriffsprotokolle wie andere Protokolle 30 Tage lang auf (720 Stunden). Es werden bis zu 1 GB an Protokollen angesammelt (1.048.576 KB). Danach wird das Protokollverzeichnis beginnend mit dem ältesten Protokoll bereinigt.
668
Welche Arten von Informationen aufgezeichnet werden, können Sie in Abbildung 11.5 sehen. Sie zeigt eine Protokoldatei in Microsoft Excel. Anders als bei den anderen Exchange-Protokollen wird hier ein leicht verändertes CSV-Format verwendet. Uner anderem können wir folgende Daten erkennen: 쐍 Das Postfach, das Verbindung mit dem Clientzugriffsserver aufgenommen hat (aufgezeichnet wird der definierte Name) 쐍 Die Clientversion (in diesem Fall ist es 14.0.4760.100, also die ursprüngliche Version von Outlook 2010) 쐍 Eine Angabe, ob der Client im Exchange-Cache-Modus oder im Onlinemodus läuft 쐍 Einzelheiten der Verbindungen, die Outlook nacheinander mit Exchange herstellt. In diesem Fall können wir mehrere Verbindungen von einem einzigen Client erkennen. Das liegt daran, dass Outlook im Exchange-Cache-Modus bis zu vier Hintergrundthreads erstellt, die jeweils eine Verbindung zum Server verwenden. Diese Threads führen eine »tröpfchenweise« Synchronisierung durch, um die Replikatordner in der OST-Datei mit den Änderungen der Masterordner auf dem Server zu aktualisieren. Wenn Outlook eine Nachricht sendet, wird ein weiterer Thread erstellt. Administratoren müssen sich nur dann um die Clientzugriffsprotokolle kümmern, wenn etwas nicht funktioniert, die Clients keine Verbindung zum Server bekommen oder die Verbindungen instabil sind. Dann kann es vorkommen, dass der Microsoft Support nach einer Kopie des Protokolls fragt, um herauszufinden, was vor sich geht.
669
Clientzugriffsserver
Protokollierung des RPC-Clientzugriffs
Kapitel 11 Abbildg. 11.5
Clientzugriffsserver
Auszug eines RPC-Clientzugriffsprotokolls
Zertifikate Wenn Sie Exchange nur im internen Netzwerk betreiben möchten und keinen Zugriff aus dem Internet erlauben wollen, reichen die selbst veröffentlichten Zertifikate völlig aus, die das Setupprogramm auf Exchange Server 2010-Computern installiert. Allerdings müssen die OWA-Clients dann diese selbst signierten Zertifikate installieren, um die nervtötenden Warnungen über die Verbindung zu einer nicht vertrauenswürdigen Website zu unterdrücken, die sonst beim Start von OWA im Browser erscheinen. Um dieses Problem zu lösen, installieren Sie das selbst signierte Zertifikat des ExchangeClientzugriffsservers, den Sie für die Verbindung mit OWA verwenden, im Speicher der vertrauenswürdigen Stammzertifizierungsstellen auf dem Client-PC (oder verteilen dieses Zertifikate mithilfe eines Gruppenrichtlinienobjekts auf mehrere PCs in der Organisation). Die PCs, auf denen das Zertifikat installiert ist – aber nur diese! – vertrauen bei allen weiteren Verbindungen dem betreffenden Clientzugriffsserver. Wollen Sie später einen anderen Clientzugriffsserver einsetzen, müssen Sie das ganze Brimborium erneut über sich ergehen lassen und das selbst signierte Zertifikat dieses Servers installieren. Multiplizieren Sie die Anzahl der Zertifikate, die Sie für alle Clientzugriffsserver brauchen, mit der Anzahl der PCs, von denen aus Sie auf OWA (oder die Exchange-Systemsteuerung) zugreifen möchten, und Sie bekommen einen Eindruck davon, wie viel Arbeit Sie sich aufhalsen, wenn Sie in einer Produktionsumgebung selbst signierte Zertifikate einsetzen wollen. Positiv zu Buche schlägt dagegen die Tatsache, dass die bei der Installation von Exchange Server 2010-Clientzugriffsservern erstellten selbst signierten Zertifikate nicht mehr nur ein Jahr lang gültig sind, wie es bei Exchange Server 2007 der Fall war, sondern fünf Jahre, sodass die Arbeit wenigstens für einen längeren Zeitraum vorhält.
670
Die meisten Organisationen wollen sich natürlich nicht auf interne Verbindungen beschränken, sondern auch sichere externe Verbindungen aus dem Internet zu internen Diensten wie OWA, der Exchange-Systemsteuerung, ActiveSync, Exchange-Webdiensten usw. zulassen. Die vom ExchangeSetupprogramm auf Clientzugriffsservern erstellten selbst signierten Zertifikate genießen außerhalb Ihres Netzwerk jedoch keinerlei Vertrauen (sofern Sie andere Unternehmen nicht dazu überreden können, sie im Speicher für vertrauenswürdige Stammzertifizierungsstellen ihrer Server zu installieren). Kurz gesagt, diese Zertifikate können Sie nicht zum Absichern von Clientverbindungen aus dem Internet einsetzen. Daher müssen Sie Zertifikate von vertrauenswürdigen Drittanbietern erwerben und zur Absicherung der SSL-Kommunikation zwischen Client und Server nutzen. Da sowohl die Clients als auch der Server diesem Drittanbieter vertrauen, akzeptieren sie die Zertifikate als gültig, sodass keine Notwendigkeit dafür besteht, die Zertifikate erst überall zu installieren. Voraussetzung ist natürlich, dass die Zertifikate von einer bekannten Zertifizierungsstelle wie VeriSign, Entrust, DigiCert oder GoDaddy stammen. Ist ein solches Zertifikat auf einem Clientzugriffsserver installiert, kann er damit öffentlich zugängliche Verbindungen über Protokolle wie HTTPS mit SSL schützen. Ein SSL-Zertifikat enthält einen öffentlichen und einen privaten Schlüssel, die zur Verschlüsselung der zwischen Client und Server ausgetauschten Daten verwendet werden. Dabei stellt der Clientzugriffsserver den Clients, die Verbindung mit ihm aufnehmen, eine Kopie seines öffentlichen Schlüssels zur Verfügung. Die Clients können dann die Kommunikation mit dem öffentlichen Schlüssel verschlüsseln, was der Clientzugrifffsserver dann wieder mit seinem privaten Schlüssel entschlüsseln kann. Alles, was zwischen Client und Server übertragen wird, ist also geschützt. Ein vom Client generierter gemeinsamer Schlüssel wird zum Schutz der Daten herangezogen, die vom Clientzugriffsserver an den Client gehen (Einzelheiten über solche Verbindungen erfahren Sie unter http://support.microsoft.com/kb/257591). Der Client verschlüsselt den gemeinsamen Schlüssel mit dem öffentlichen Schlüssel des Clientzugriffsservers und überträgt diesem die Daten. Der Clientzugriffsserver wiederum entschlüsselt den gemeinsamen Schlüssel, um in Erfahrung zu bringen, wie er die Kommunikation so verschlüsseln kann, dass selbst jemand, der die zwischen Client und Server übertragenen Datenpakete abfängt, nicht in der Lage ist, die Daten zu lesen, da ihm der gemeinsame Schlüssel fehlt. Wie viele Zertifikate?
Wie viele Zertifikate bereitgestellt werden müssen, ist eine komplizierte Entscheidung. Beachten Sie dabei unter anderem die folgenden Anregungen: 쐍 Minimieren Sie die Anzahl der verwendeten Zertifikate. Je mehr Zertifikate Sie verwenden, umso teurer ist der Erwerb und umso komplizierter wird Ihre Umgebung. 쐍 Verwenden Sie SAN-Zertifikate. Normale Zertifikate enthalten einen einzigen Namen, SANZertifikate haben jedoch mehrere alternative Subjektnamen (Subject Alternate Names, SAN), die jeweils einem Hostnamen entsprechen. Diese Zertifikate lassen sich leichter bereitstellen und verringern die Anzahl der erforderlichen Zertifikate. Beispielsweise kann ein SAN-Zertifikat alternative Namen für autodiscover.contoso.com, mail.contoso.com, hq-exserver3.contoso.com und exserver3 enthalten, sodass es für mehrere Zwecke ausreicht. Beachten Sie, dass die FQDNs von Clientzugriffsarrays nicht in Zertifikaten enthalten sein müssen, da diese Namen nicht für SSL-Verbindungen verwendet werden. 쐍 Listen Sie in Zertifikaten keine einzelnen Hostnamen auf. Wenn möglich, sollten Sie den Namen der Arrays für den Zugriff aus dem Internet und dem Intranet auf bestimmte Dienste angeben (z.B. auf ActiveSync). Diese Vorgehensweise ist flexibler und erweiterbar.
671
Clientzugriffsserver
Zertifikate
Kapitel 11
Clientzugriffsserver
In Kapitel 5, »Exchange-Verwaltungskonsole und Exchange-Systemsteuerung«, haben wir den Assistenten für neue Zertifikate kennengelernt, der in der Exchange-Verwaltungskonsole zur Verfügung steht. Dieser Assistent ist neu in Exchange Server 2010 und vereinfacht sehr stark den Vorgang, bei einer kommerziellen vertrauenswürdigen Zertifizierungstelle ein SSL-Zertifikat für die Dienste anzufordern, die Sie absichern möchten. Auch mit dem Cmdlet New-ExchangeCertificate können Sie eine Zertifikatanforderung erstellen, die Sie dann an den Zertifikatanbieter Ihrer Wahl senden. Mit dem folgenden Befehl erstellen Sie beispielsweise eine Anforderung für ein SAN-Zertifikat, das drei Hostnamen umfasst: New-ExchangeCertificate –GenerateRequest –Path 'C:\Temp\Cert.req' –SubjectName 'c=US;O=Contoso ;CN=Mail.contoso.com' –DomainName 'mail.contoso.com, autodiscover.contoso.com, legacy.contoso.com' –PrivateKeyExportable $True
Der private Schlüssel wird zusammen mit der Anforderung generiert. Er verbleibt auf dem Server und wird nicht an den Zertifikatanbieter weitergegeben. Die Option PrivateKeyExportable besagt jedoch, dass der private Schlüssel exportiert und auf einen anderen Computer verschoben werden darf. Dadurch ist es möglich, das SAN-Zertifikat auf mehreren Hosts zu verwenden, wenn es sich bei mail.contoso.com, autodiscover.contoso.com und lecacy.contoso.com um verschiedene Computer handelt. Wenn Sie das Zertifikat erhalten, importieren Sie es mit Import-ExchangeCertificate in Exchange und weisen es dann mit Enable-ExchangeCertificate den gewünschten Diensten zu. Alternativ können Sie die ausstehende Anforderung in der Exchange-Verwaltungskonsole abschließen, und zwar unabhängig davon, ob Sie sie mit dem Assistenten oder mit New-ExchangeCertificate erstellt haben. Insidertipp: Minimieren der Anzahl von Hostnamen
Verringern Sie nach Möglichkeit die Anzahl der Hostnamen, mit denen die Clients zu tun haben. Eine Möglichkeit dazu bietet Split DNS, wobei Sie einem Namen verschiedene Adressen für den Internet- und den Intranetzugang zuweisen. Dadurch können die Clients unabhängig davon, von wo aus sie auf den Dienst zugreifen, immer denselben Namen verwenden (z.B. mail.contoso.com).
Outlook Anywhere Outlook Anywhere ist eine Komponente von Exchange Server 2010, mit der Outlook-Clients vom Internet aus über HTTPS Verbindung mit Exchange aufnehmen können. Im Prinzip verpackt Outlook dabei die Remoteprozeduraufrufe (Remote Procedure Calls, RPCs), die gewöhnlich für die Kontaktaufnahme mit Exchange verwendet werden, in eine äußere HTTPS-Schicht, die eine Firewall überwinden kann. Der Clientzugriffsserver entfernt das HTTPS und leitet die RPCs an den richtigen Postfachserver weiter. Dadurch müssen die Clients für die Kommunikation mit Exchange keine VPNs aufbauen, und die Administratoren müssen keine zusätzlichen Ports in der Firewall öffnen. Standardmäßig ist Outlook Anywhere nicht aktiviert. Diese Funktion müssen Sie auf einem Clientzugriffsserver an einem mit dem Internet verbundenen Standort einschalten, der als erster Eintrittspunkt für Clientverbindungen dient. Außerdem müssen Sie Outlook Anywhere noch auf mindestens einem Clientzugriffsserver in jedem internen Standort aktivieren. Dazu gehen Sie jeweils folgendermaßen vor: 1. Wechseln Sie in der Exchange-Verwaltungskonsole zum Knoten Serverkonfiguration und darun-
ter zu Clientzugriff. 2. Markieren Sie den gewünschten Clientzugriffsserver. 672
Outlook Anywhere
Abbildung 11.6 zeigt den Assistenten zum Aktivieren von Outlook Anywhere. Dort können Sie folgende einfache Optionen auswählen: 쐍 Der externe Hostname ist der Name, den die Outlook-Clients verwenden, um Verbindung mit dem Dienst Outlook Anywhere aufzunehmen. Normalerweise wird für alle externen E-MailZugriffspunkte derselbe Name verwendet, sodass ein SSL-Zertifikat von Outlook Anywhere, ActiveSync und OWA gemeinsam genutzt werden kann. 쐍 Die Clientauthentifizierungsmethode bestimmt, wie sich Outlook-Clients bei der Aufnahme der Verbindung gegenüber Exchange authentifizieren. Voreingestellt ist die Standardauthentifizierung, bei der Benutzername und Kennwort als Klartext über eine SSL-Verbindung übertragen werden. Die meisten Unternehmen verwenden jedoch eine fortschrittliche Firewall wie Microsoft Threat Management Gateway, die NTLM-fähig ist, weshalb Sie diese Authentifizierungsmethode verwenden können. 쐍 Das Kontrollkästchen SSL-Verschiebung (Secure Channel) zulassen können Sie nur aktivieren, wenn Sie für die Ver- und Entschlüsselung von SSL einen eigenen Server verwenden. Dieser Server steht vor dem Clientzugriffsserver und beendet alle eingehenden Verbindungen, um dann zur Weiterverarbeitung neue Verbindungen zum Clientzugriffsserver zu erstellen. Diese Option verwenden Sie normalerweise, wenn Sie einen Hardware-Lastenausgleichsserver oder einen SSLBeschleuniger haben, der SSL-Verbindungen beendet oder überbrückt. Abbildg. 11.6
Aktivieren von Outlook Anywhere
Um Outlook Anywhere mit denselben Einstellungen wie in Abbildung 11.6 in der Exchange-Verwaltungsshell zu aktivieren, verwenden Sie folgenden Code: Enable-OutlookAnywhere -Server 'EXSERVER1' -ExternalHostname'mail.contoso.com' -DefaultAuthenticationMethod 'Ntlm' -SSLOffloading $False
673
Clientzugriffsserver
3. Klicken Sie im Aktionsbereich auf die Option Outlook Anywhere aktivieren.
Kapitel 11
Clientzugriffsserver
Aufgrund der Active Directory-Replikation kann es bis zu 15 Minuten dauern, bis die neuen Outlook Anywhere-Einstellungen überall in der Organisation in Kraft treten. Nachdem die Replikation erfolgt ist, können Sie mit dem Cmdlet Test-OutlookConnectivity oder der Remoteverbindunguntersuchung (siehe Kapitel 15) überprüfen, ob Outlook Anywhere wie erwartet funktioniert.
Mehrbelastung für Clientzugriffsserver Durch die Verlegung des MAPI-Endpunkts zur RPC-Clientzugriffsschicht der Clientzugriffsserver wird offensichtlich auch ein Teil der Arbeitslast von den Postfachservern verlagert. Vor allem erfolgt auf Clientzugriffsservern jetzt eine stärkere CPU-Verarbeitung. Aus diesem Grund empfiehlt Microsoft, zwischen den Prozessorkernen für Clientzugriffs- und Postfachserver an einem Standort ein Verhältnis von 3:4 zu wahren. Wenn der Standort London beispielsweise über acht Postfachserver verfügt, braucht er sechs Clientzugriffsserver, um die eingehenden Verbindungen von Outlook-Clients handhaben zu können. Das ist jedoch nur eine grobe Abschätzung. Die tatsächliche Anzahl der erforderlichen Clientzugriffsserver hängt von den folgenden Faktoren ab: 1. Die Anzahl der Postfächer auf den einzelnen Servern und die durchschnittliche Postfachgröße. 2. Die Anzahl der Outlook-Clients (MAPI-Clients) im Verhältnis zu OWA-, ActiveSync-, POP3-
und IMAP4-Clients. Jede Art von Client bringt ihre eigene Arbeitslast mit sich. 3. Die Verteilung der Last. In einem Büro gibt es gewöhnlich zwei oder drei Zeiten der Spitzenaus-
lastung am Tag. 4. Verwendung von E-Mail-Infos. Wenn Sie diese Funktion einsetzen, müssen Sie eine gewisse Leis-
tungseinbuße in Kauf nehmen, die je nach der Anzahl der Clients und der Art und Weise, wie Sie die E-Mail-Infos verwenden, in jeder Organisation unterschiedlich stark zu Buche schlägt. Die Ratschläge zur Leistungssteigerung ändern sich immer wieder mit zunehmender Erfahrung, Optimierung der Software und Verfügbarkeit neuer Hardware. Microsoft und die Hardwarehersteller aktualisieren hin und wieder ihre Vorschläge zur Konfiguration von Postfach- und Clientzugriffsservern. Wenn das der Fall ist, sollten Sie Ihre Umgebung untersuchen, um herauszufinden, ob irgendwelche Änderungen erforderlich sind. In kleineren Standorten gibt es gewöhnlich nur einen oder zwei Server mit mehreren Rollen, sodass die Regeln für das Verhältnis zwischen den einzelnen Typen nicht zutreffen. In einer solchen Situation müssen Sie lediglich dafür sorgen, dass alle Server über ausreichend Kapazität verfügen, um die Arbeitslast ihrer verschiedenen Rollen zu schultern. Weitere Informationen
Grundlegendes zum Serverrollenverhältnis und zur Leistung von Exchange Server 2010 erfahren Sie unter http://technet.microsoft.com/de-de/library/dd346701.aspx.
Lastenausgleich für Clientzugriffsserver Bei der Frage, wie die Last am besten zu handhaben ist, kommen häufig Lastenausgleichslösungen ins Spiel, die die Last auf mehrere Computer verteilen. Durch eine geschickte Lastverteilung können Sie die vorhandenen Serverressourcen besser nutzen und die Auswirkungen eines Ausfalls verringern. Im Folgenden konzentrieren wir uns auf die Hardware- oder Softwarelösungen zum Lastenausgleich, die einer Reihe von Clientzugriffsservern oder einem Clientzugriffsarray vorgeschaltet sind, um die eingehenden Clientverbindungen zu verteilen. Vor allem geht es uns um die Verteilung meh-
674
rerer Verbindungen, die über denselben Port eingehen, um auf einen bestimmten Netzwerkdienst zuzugreifen. In jedem Fall aber nimmt die Lastenausgleichslösung die Verbindung entgegen und entscheidet dann, welcher der Clientzugriffsserver sich darum kümmern soll. Tabelle 11-3 führt die verschiedenen Lastenausgleichslösungen auf, die für Exchange in Unternehmen gewöhnlich ins Auge gefasst werden. Eine Hardwarelösung mit so genannten ADN-Geräten (Application Delivery Network) ist erforderlich, wenn Zehntausende von einzelnen Clients Verbindung aufnehmen, sodass zur Verarbeitung mehr als acht ISA/TMG-Server notwendig wären. Bei einer solchen Größenordnung müssen Sie sich Sorgen über die Skalierbarkeit, die Fähigkeit zur Handhabung von TCP/IP-Verbindungen, die Speichernutzung usw. machen. Die Hersteller solcher Hardwarelösungen geben gewöhnlich hervorragende Richtlinien heraus, an denen Sie sich bei der Bereitstellung orientieren können (beispielsweise werden die Ratschläge von F5 auf http://www.f5. com/pdf/deployment-guides/f5-exchange-2010-dg.pdf veröffentlicht). Tabelle 11.3
Lastenausgleichslösungen Technologie
Kommentar
Affinität zwischen Client und Clientzugriffsserver
Größenanpassung
Kosten
Hardwarebasiertes Netzwerkanwendungssystem, z.B. F5 BigIP oder Citrix NetScaler
Verwendet andere Betriebssystem- und Verwaltungskomponenten, die Sie in Ihren Verwaltungsbereich aufnehmen müssen. Von den Administratoren werden besondere Fähigkeiten erwartet.
Verschiedene Möglichkeiten, z.B. vorhandene Cookies, vom Lastenausgleichsserver erstellte Cookies, SSL-ID, Quell-ID
Sehr gut (Hunderttausende von Verbindungen)
Teuer
Softwarebasierter Lastenausgleich auf eigenem WindowsServercomputer, z.B. Microsoft TMG oder ISA
Es sind mehr Windows-Servercomputer zu verwalten und zu lizenzieren, und die Serverinfrastruktur wird komplizierter. Außerdem können diese Server keinen Lastenausgleich für RPCClientzugriffsarrays durchführen, da sie nicht in der Lage sind, MAPI-Endpunkte zu verteilen.
Je nach Protokoll und Client entweder von der Lastenausgleichssoftware erstellte Cookies oder Quell-IP
Brauchbar (Zehntausende von Verbindungen)
Mittel
Abbildung 11.7 veranschaulicht die grundlegende Vorgehensweise bei der Verwendung eines ADNHardwaresystems für Exchange. Der Datenverkehr über HTTP (also auch von Outlook Anywhere), IMAP und POP gelangt durch die externe Firewall zu dem ADN-System, das im Umkreisnetzwerk installiert ist. Dieses System führt eine Reihe von Aufgaben durch, indem es etwa SSL-Verbindungen beendet und als Reverseproxyserver fungiert. Danach verteilt es die Verbindungen über die Umkreisfirewall hinweg im Umlaufverfahren an eine Farm aus Clientzugriffsservern, die wiederum die Verbindungen annehmen und an die Postfachserver weiterleiten. In Exchange Server 2007 waren die einzelnen Clientzugriffsserver in der Farm eindeutig bezeichnet, doch in Exchange Server 2010 können Sie auch ein Clientzugriffsarray einsetzen. Hardwarelösungen sind für einen einzigen Zweck ausgelegt und lassen sich daher von Natur aus besser an andere Größenverhältnisse anpassen. Außerdem können Sie schwere Lasten besser handhaben als Server mit einem Allzweckbetriebssystem wie Windows und Hardware von der Stange. Gewöhnlich verfügen sie über Funktonen wie eine Netzwerkoptimierung und die Möglichkeit, den Datenverkehr von Anwendungen nach Prioritäten zu ordnen. Auch sind sie oft mit anspruchsvollen Mechanismen zur Abwehr von Angriffen aus dem Netzwerk ausgestattet. Der Nachteil solcher Produkte besteht darin, dass sie teuer sind und besondere Fähigkeiten für die Bereitstellung und Wartung erfordern. Gewöhnlich bringen sie ihre eigenen Programme für Betrieb und Überwachung mit, die
675
Clientzugriffsserver
Mehrbelastung für Clientzugriffsserver
Kapitel 11
Clientzugriffsserver
sich nicht unbedingt gut in Ihre Arbeitsabläufe zur Serverüberwachung einfügen müssen. Die Erfahrungen mit Lastenausgleichshardware in Produktionsumgebungen mit Exchange Server 2007 und 2010 zeigen jedoch, dass diese Geräte bei hoher Belastung sehr viel mehr Stabilität und Leistung bieten, als mit Softwareprodukten möglich wäre. Lastenausgleichssoftware ist für mittlere und kleine Umgebungen geeignet, in denen sich das Verbindungsvolumen in der Größenordnung von Tausenden misst. Das neuste Angebot von Microsoft auf diesem Gebiet ist Forefront TMG. Im Grunde genommen ist TMG ein Ersatz für ISA Server 2006 und außerdem die offensichtliche Wahl für die Verwendung zusammen mit Exchange Server 2010, sofern Sie nicht auf die Kapazität einer Hardwarelösung angewiesen sind. Die Grenzen von softwarebasierten Reverseproxylösungen wurden in einer Reihe von umfangreichen Exchange Server 2007-Umgebungen ausgelotet, die den Datenverkehr von mehr als 40.000 gleichzeitig zugreifenden Outlook Anywhere-Clients handhaben mussten. In der Anfangsphase sind solche Bereitstellungen häufig erfolgreich, da noch nicht die gesamte Clientlast zu spüren ist. Mit zunehmendem Clientzulauf aber zeigen sich die ersten Risse. ISA Server 2006 ist grundlegend durch seine 32-Bit-Architektur und die begrenzte Anzahl von TCP-Verbindungen beschränkt, die ein einzelner Server handhaben kann. TMG dagegen ist eine 64-Bit-Software, die sich besser an ein größeres Volumen anpassen kann. Das entbindet Sie aber nicht von der Verantwortung, jedes Reverseproxy- und Lastenausgleichsprodukt unter realistischer Belastung zu testen, um zu sehen, wo seine Grenzen liegen. Abbildg. 11.7
Kombinierter Einsatz von ADN-Spitzenhardware und Clientzugriffsservern
Externe Firewall
ADN-Hardwaresystem
Umkreisfirewall
Farm aus Clientzugriffsservern
Postfachserver
Jede Exchange-Installation ist einmalig, was die Anzahl und Art der Clients, die Benutzungsmuster, die Sicherheitsanforderungen, die Netzwerkumgebung usw. angeht. Daher ist es am besten, die Vorund Nachteile von Software- und Hardwarelösungen abzuwägen, bevor Sie eine endgültige Entscheidung treffen.
676
Mehrbelastung für Clientzugriffsserver
Affinität bedeutet, dass die Sitzung eines Clients während der Gesamtdauer der Verbindung bei einem Clientzugriffsserver verbleibt. Mit anderen Worten, sobald ein Client Verbindung mit einem bestimmten Clientzugriffsserver aufnimmt, kümmert sich dieser Server um die Verbindung, bis sie beendet wird. Dazu muss der Sitzungsstatus beibehalten werden, damit das Lastenausgleichsprodukt weiß, welcher Clientzugriffsserver welche Verbindung handhabt und diese Verbindungen sozusagen »kleben bleiben«. Wenn eine Lastenausgleichs- oder Reverseproxylösung keine Affinität kennt, kann das einige Exchange-Dienste funktionsunfähig machen und andere eine geringere Leistung aufweisen, da jedes Mal eine erneute Authentifizierung notwendig ist, wenn die Sitzung zu einem anderen Clientzugriffsserver übergeht. Dies ist also ein Aspekt, dem Sie bei der Auswahl einer Lösung Beachtung schenken müssen. Folgende Dienste werden bei Nichtbeachtung der Affinität funktionsunfähig: 쐍 OWA und die Exchange-Systemsteuerung Diese Anwendungen teilen sich ein Authentifizierungscookie. Die Affinität zu einem Clientzugriffsserver muss über die gesamte Sitzung hinweg bestehen bleiben, denn nur dieser Server kann das Cookie entschlüsseln. 쐍 Exchange-Webdienste Einige Teile der Exchange-Webdienste funktonieren auch ohne Affinität, z.B Anforderungen an den Verfügbarkeitsdienst, doch andere sind auf die Affinität angewiesen. Um die besten Ergebnisse zu erzielen, sollten Sie daher davon ausgehen, dass die Exchange-Webdienste insgesamt Affinität erfordern. 쐍 RPC-Clientzugriffsdienst Outlook-Clients setzen voraus, dass alle von ihnen erstellen RPCVerbindungen an denselben Clientzugriffsserver gehen, was ohne Affinität nicht möglich ist. Bei fehlender Affinität leiden die folgenden Dienste unter verringerter Leistung: 쐍 Outlook Anywhere Ohne Affinität versucht eine Komponente, nämlich der Lastenausgleichsdienst, seine beiden Verbindungen RPC_DATA_IN und RPC_DATA_OUT (die Halbduplexverbindungen, die eine Vollduplex-RPC-Kommunikaton über HTTPS simulieren) zu koordinieren, indem er alle Clientzugriffsserver des Standorts abfragt. Je mehr Server es gibt, desto stärker ist der Datenverkehr zwischen ihnen und umso mehr Serverressourcen werden für diese Koordinierung verbraucht. Bei Exchange Server 2010 ist das Problem nicht so schlimm wie bei Exchange Server 2007. Hier sind die DSProxy-Verweise durch einen vom Adressbuchdienst bereitgestellten Endpunkt auf dem Clientzugriffsserver ersetzt. Anstelle der zwei Verbindungen für die RPC-Verweise geht deshalb nur eine einzige LDAP-Verbindung zum globalen Katalog. 쐍 ActiveSync Auf einem ActiveSync-Client gehen neue E-Mail-Benachrichtigungen als Folge einer Benachrichtigungsanforderung ein, die der Client auf dem Server platziert hat. Ohne Affinität muss der Client nach dem Wechsel zu einem anderen Clientzugriffsserver eine neue Benachrichtigungsanforderung öffnen. 쐍 Adressbuchdienst Clientzugriffsserver speichern Active Directory-Informationen zwischen, um die Reaktion auf Clientanforderungen zu verbessern. Wenn ein Client zu einem anderen Clientzugriffsserver wechselt, verliert er den Zugriff auf diese zwischengespeicherten Ergebnisse seiner früher in der Sitzung erstellten Anforderungen. 쐍 Remoteausführung von Windows PowerShell Sitzungen der Exchange-Verwaltungsshell werden zu einem bestimmten Clientzugriffsserver aufgebaut. Ohne Affinität muss die Shell nach dem Wechsel zu einem anderen Server eine neue Sitzung aufbauen.
677
Clientzugriffsserver
Die Wichtigkeit der Affinität
Kapitel 11
Clientzugriffsserver
Die folgenden Dienste werden durch das Fehlen der Affinität nicht beeinträchtigt: 쐍 Offlineadressbuch Um auf die Dateien des Offlineadressbuchs zuzugreifen, nimmt ein Client Verbindung mit einem der Clientzugriffsserver auf, der für die OAB-Verteilung zuständig ist. Eine Affinität ist daher nicht erforderlich. 쐍 AutoErmittlung Dieser Dienst stellt einmalige Anforderungen, um Verbindungsinformationen für ein Postfach zu gewinnen, und braucht daher keine Affinität. 쐍 POP3 und IMAP4 Um Nachrichten abzurufen und zu senden, stellen diese Protokolle ständig Verbindungen her und beenden sie wieder, weshalb sie nicht auf Affinität angewiesen sind. Zwar könnten Sie auch ohne OWA und die Exchange-Systemsteuerung auskommen, doch sind Sie für die Verbindung mit Postfächern unbedingt auf die Verwendung des RPC-Clientzugriffsdienstes angewiesen. Das allein reicht schon aus, um die Wichtigkeit der Affinität für Verbindungen mit Exchange Server 2010-Computern zu unterstreichen. Manche Lastenausgleichsprodukte sind intelligenter als andere und probieren nacheinander verschiedene Affinitätslösungen aus, wobei sie zunächst mit Cookies beginnen (vorhandene oder selbst erstellte Cookies) und dann, wenn das nicht funktioniert, mit der SSL-Sitzungs-ID und schließlich der Quell-IP weitermachen (die einzige Option, die beim Windows-Netzwerklastenausgleich möglich ist). Weitere Aspekte, um die Sie sich kümmern müssen, sind etwa die Frage, ob die vorgesehene Lastenausgleichslösung vorhandene Cookies oder HTTP-Header verwenden kann oder seine eigenen Cookies erstellen muss, und ob Sie den Datenverkehr je nach Protokoll aufteilen wollen (mit SSL-Sitzungs-ID). Außerdem müssen Sie sich um die Sonderfälle kümmern, die bei einzelnen Clients vorkommen können (beispielsweise erstellt das Apple iPhone in Teilen seiner ActiveSync-Kommunikation mit Exchange neue SSL-Sitzungen). Schließlich müssen Sie noch überlegen, wie Ihre Lastenausgleichslösung neue Verbindungen auf die vorhandenen Clientzugriffsserver verteilt. Dabei werden oft die beiden folgenden Verfahren verwendet: 쐍 Wenigste Verbindungen Die Lastenausgleichslösung verfolgt anhand der Affinität die Clientverbindungen zu den einzelnen Servern nach. Ein Client, der häufig Verbindung aufnimmt, aktualisiert seinen Affinitätseintrag, sodass das Lastenausgleichsprodukt die Verbindung als aktiv ansieht, sodass sie beim alten Server verbleiben soll. Bei Clients, die seltener Kontakt aufnehmen, kann der Affinitätseintrag jedoch abgelaufen sein, weshalb Sie beim nächsten Mal, wenn Sie auf Daten zugreifen wollen, eine neue Verbindung aufbauen müssen. 쐍 Umlaufprinzip Die Lastenausgleichslösung wählt zufällig einen Server aus, dem sie die Clientverbindung sendet. Dieses Verfahren ist für Exchange besser geeignet, da es sich leichter an das wechselnde Verhältnis von aktiven und inaktiven Clients anpasst und die Arbeitslast gleichmäßiger auf die verfügbaren Server verteilt. Bis eine ausgeglichene Verteilung auf sämtliche Server erreicht ist, kann es jedoch eine Zeit lang dauern. Außerdem müssen Sie sicher sein, dass das ausgewählte Lastenausgleichsprodukt ausgefallene Server von der Verteilung ausnimmt. Insidertipp: Ein wichtiger Aspekt der Planung
Welche Lastenausgleichslösung Sie auch immer verwenden, so müssen Sie doch auf jeden Fall die Affinität als wichtiges Thema während der Bereitstellungsplanung anschneiden. Testen Sie außerdem das ausgewählte Verfahren mit allen Arten von vorgesehenen Clients in einer realistischen Umgebung, die die zu erwartende Produktionslast simuliert. Nur so können Sie die optimale Konfiguration erreichen.
678
Zuweisen von statischen Ports zum Clientzugriffsserver Exchange verwendet eine Reihe von Ports, um eingehende MAPI- und HTTP- Clientverbindugnen an die Clientzugriffsserver weiterzuleiten. TCP-Verbindungen werden gewöhnlich dynamische Ports zugewiesen. Wenn ein Dienst wie Exchange startet, der sich auf Windows-RPC stützt, registriert er sich selbst beim RPC-Dienst und bekommt einen TCP-Port dynamisch zugewiesen. Die Portnummer ändert sich mit der Zeit und wird als Endpunkt bezeichnet. Wenn ein Client eine Verbindung zu einem Dienst herstellen möchte, sendet er über Port 135 eine Anfrage an den Endpunktzuordnungsdienst und erhält als Antwort die Portnummer für den angesprochenen Dienst. Durch diese dynamische Zuordnung soll die begrenzte Menge der verfügbaren TCP/IP-Ports besser ausgenutzt werden. Theoretisch gibt es zwar 65.536 solcher Ports, doch gibt es verschiedene Faktoren, die die Anzahl der verfügbaren einschränken. Wenn jeder mögliche Dienst darauf bestehen würde, dauerhaft einen bestimmten statischen Port zu nutzen, wären Konflikte zwischen Anwendungen unvermeidlich. HINWEIS Der RPC-Dienst lässt Ausnahmen von der dynamischen Zuordnung zu, um Verbindungen über Firewalls hinweg zu ermöglichen, wenn es für die Administratoren aus Sicherheitsgründen nicht möglich ist, dynamische Endpunkte zu verwenden. Für den Zugriff von MAPI-Clients auf Postfächer und Verzeichnisinformationen können Sie auf Clientzugriffs- und Postfachservern auch statische Ports festlegen. Das wird hauptsächlich getan, damit Lastenausgleichsprodukte nur einen begrenzten Satz von Ports zur Verfügung haben, der sich einfacher verwalten lässt und sicherer ist. In Tabelle 11.4 finden Sie die verschiedenen Endpunkte, die für Outlook-Clientverbindungen genutzt werden. Die statischen Endpunkte für Outlook Anywhere können Sie nicht ändern, aber Sie können statische Endpunkte als Ersatz für die dynamischen Endpunkte festlegen, die ansonsten für interne MAPI- und Adressbuchverbindungen verwendet würden. Am besten ist es, wenn Sie alle Endpunkte entweder dynamisch oder statisch machen. Mit anderen Worten, wenn Sie einen statischen MAPI-Endpunkt festlegen, sollten Sie das Adressbuch und den Referenzdienst nicht bei einem dynamischen Port belassen, sondern alle drei zusammen ändern. Tabelle 11.4
TCP-Ports für Outlook-Clientverbindungen Verbindung
Typ
Standardport
Konfiguration
Postfach (MAPI)
TCP
Dynamisch
Erstellen Sie in der Systemregistrierung den DWORD-Wert TCP/IP Port.
Postfach (MAPI)
HTTP
6001
Nicht konfigurierbar.
Adressbuch (NSPI)
TCP
Dynamisch
Erstellen Sie in der Systemregistrierung den Zeichenkettenwert RpcTcpPort.
Adressbuch (NSPI)
HTTP
6004
Nicht konfigurierbar. Outlook hartkodiert diesen Wert.
Referenzdienst (RFR)
TCP
Dynamisch
Die NSPI-Endpunkteinstellung steuert auch diesen Endpunkt, weshalb sich die Änderung der Einstellung RpcTcpPort auch hierauf auswirkt.
Referenzdienst (RFR)
HTTP
6002
Nicht konfigurierbar. Outlook hartkodiert diesen Wert.
Den Port für interne Postfachverbindungen geben Sie auf dem Clientzugriffsserver im Registrierungswert TCP/IP Port an. Um einen statischen Port zuzuweisen, erstellen Sie im Schlüssel HKLM\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem den DWORD-Wert TCP/IP Port. (Wenn der Schlüssel in der Registrierung nicht vorhanden ist, müssen Sie auch ihn erstellen.) Geben Sie die gewünschte Portnummer als Wert ein. 679
Clientzugriffsserver
Mehrbelastung für Clientzugriffsserver
Kapitel 11
Clientzugriffsserver
In Exchange Server 2010 SP1 hat Microsoft die Anzahl der verfügbaren Ports, die Sie zuweisen können, reduziert. Ursprünglich konnten Sie jeden Port zwischen 6005 und 65535 auswählen, wobei Administratoren gewöhnlich Werte ganz weit oben aus dem dynamischen Bereich nahmen, um mögliche Konflikte mit anderen Anwendungen zu vermeiden. In SP1 lautet der höchstmögliche Portwert nur noch 60554, und der dynamische Bereich ist auf die Werte zwischen 6005 und 59350 geschrumpft. Dadurch entsteht ein Wertebereich zwischen 59531 und 60554, der für statische Ports reserviert ist. Als statische Ports für Postfachverbindungen (MAPI) und das Adressbuch sollten Sie daher Werte aus diesem Bereich auswählen. Im folgenden Beispiel habe ich 60001 genommen (siehe Abbildung 11.8). Abbildg. 11.8
Zuweisung eines statischen Ports für Postfachverbindungen
Wenn Sie auf einem Clientzugriffsserver einen statischen Port für Postfachverbindungen zugewiesen haben, sollten Sie dieselbe Änderung auch auf allen anderen Clientzugriffsservern der Organisation durchführen. Falls Sie öffentliche Ordner verwenden, müssen Sie das auch auf den Postfachservern mit den Datenbanken für diese Ordner tun, da die entsprechenden Verbindungen über die Postfachund nicht über die Clientzugriffsserver verlaufen. Insidertipp: Eine Sicherheitsmaßnahme
Der Port für Verzeichnisverbindungen wird jetzt über eine Registrierungseinstellung für den Adressbuchdienst festgelegt. Das ist ein Unterschied gegenüber der ursprünglichen Version von Exchange Server 2010, bei der der Adressbuchdienst die Einstellungen der Datei Microsoft.Exchange.AdressBook.Service.exe.config gelesen hat. Diese Verlagerung in die Registrierung wurde vorgenommen, damit nicht mehr die Gefahr besteht, dass ein Service Pack oder eine Aktualisierung eine wichtige Einstellung überschreibt. Komponenten wie Konfigurationsdateien werden bei Softwareaktualisierungen oft komplett ersetzt. Um einen statischen Port für den Adressbuchdienst festzulegen, wechseln Sie im RegistrierungsEditor zum Schlüssel HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeAB\Parameters und erstellen dort einen neuen Zeichenkettenwert namens RcpTcpPort. Setzen Sie den Wert auf die Portnummer, die Sie verwenden möchten. Über diesen Port laufen sowohl die NSPI-Adressbuchverbindungen als auch die des Referenzdienstes (RFR). Die für Outlook Anywhere festgelegten Ports können Sie nicht ändern, da hierfür die Ports 6002 und 6004 in Outlook hartkodiert sind. 680
Damit Exchange die neuen statischen Ports verwendet, müssen Sie auf Postfachservern den Exchange-Informationsspeicherdienst und auf Clientzugriffsservern den Adressbuch- und den RPCClientzugriffsdienst neu starten. Anschließend sollten Sie überprüfen, ob Outlook-Clients über die vorgesehenen Ports Verbindung aufnehmen. Um nachzusehen, welche Ports Exchange verwendet, können Sie das Programm NetStat heranziehen. Führen Sie an einer Befehlszeile auf dem Client-PC NetStat mit dem Parameter -na aus. In der Ausgabe sollten Sie die aufgebauten TCP-Verbindungen zu der IP-Adresse und dem zugewiesenen Port des Clientzugriffsservers sehen (bzw. des Postfachservers, wenn es um öffentliche Ordner geht). Wenn Sie beispielsweise die Ports 61000 für Postfachverbindungen und 61001 für Adressbuchverbindungen verwenden und die IP-Adresse des Clientzugriffsservers 192.168.50.1 lautet, können Sie Verbindungen mit 192.168.50.1:61000 und 192.168.50.1:61001 erwarten. Abbildung 11.9 zeigt ein typisches Beispiel für die Ausgabe von NetStat bei der Verwendung von statischen Ports. Sie können erkennen, dass der Clientcomputer (192.168.65.60) Verbindungen zu den Ports 61001 und 61002 auf dem Server (192.65.65.50) unterhält. Es handelt sich um statische Ports, die für den MAPI-Endpunkt und den Adressbuchdienst eingerichtet wurden. Abbildg. 11.9
Überprüfen der statischen Ports mit NetStat
Webdienst-URLs und Lastenausgleich Clientzugriffsserver veröffentlichen URLs, damit die Clients Verbindung mit den verschiedenen von Exchange genutzten Webdiensten aufnehmen können. Wenn Sie den Zugriff auf diese Dienste über das Internet erlauben wollen, platzieren Sie gewöhnlich einen oder mehrere Clientzugriffsserver an einem mit dem Internet verbundenen Standort (hinter der Umkreisfirewall) und leiten die bei diesen Servern eingehenden Verbindungen über einen Proxy an andere Server in der Organisation weiter. Um mehr Verbindungen zuzulassen, als ein einzelner Server handhaben kann, bietet sich ein Array mit Windows-Netzwerklastenausgleich oder einer anderen Lastenausgleichslösung an. Dann stellt sich jedoch die Frage, wie Sie die verschiedenen URLs am besten veröffentlichen, sodass interne und externe Verbindungen reibungslos verarbeitet werden können. Grundlegend richten Sie in solchen Fällen die URLs nach den Richtlinien in Tabelle 11.5 ein und gehen nach den folgenden Prinzipien vor: 1. Setzen Sie den internen URI des AutoErmittlungsdienstes (AutoDiscoverServiceInternalURI) des
Clientzugriffsservers auf den FQDN des Lastenausgleichsservers. 2. Belassen Sie InternalNLBBypass für die Webdienste und InternalURL für OWA auf dem FQDN
des Clientzugriffsservers.
681
Clientzugriffsserver
Mehrbelastung für Clientzugriffsserver
Kapitel 11 Tabelle 11.5
Clientzugriffsserver
Einrichten der Webdienst-URLs für den Lastenausgleich Virtuelles Verzeichnis
Interner URL
Externer URL (mit dem Internet verbundener Active DirectoryStandort)
Externer URL (interner Active Directory-Standort)
/OWA
Clientzugriffsserver oder FQDN des Arrays
FQDN des Lastenausgleichsservers
$null
/ECP
FQDN des Lastenausgleichsservers
FQDN des Lastenausgleichsservers
$null
/Microsoft-Server-ActiveSync
FQDN des Lastenausgleichsservers
FQDN des Lastenausgleichsservers
$null
/OAB
FQDN des Lastenausgleichsservers
FQDN des Lastenausgleichsservers
$null
/EWS
FQDN des Lastenausgleichsservers
FQDN des Lastenausgleichsservers
$null
Wie immer sind Testläufe erforderlich, um eine reibungslose Handhabung der Clientverbindungen auch dann sicherzustellen, wenn ein Clientserver im Array ausfällt.
Änderungen zur Nutzung der SSL-Verschiebung Die SSL-Verschiebung ist eine Funktion, die häufig von Hardwaregeräten durchgeführt wird, um in stark beanspruchten Umgebungen die Arbeitsbelastung durch die SSL-Verschlüsselung und -Entschlüsselung vom Webserver wegzunehmen. Wenn Sie diese Funktion verwenden möchten, müssen Sie SSL die virtuellen Verzeichnisse der AutoErmittlung und der Exchange-Webdienste deaktivieren, da in diesen Verzeichnissen nur HTTP-Datenverkehr eintrifft und nicht HTTPS. In Exchange Server 2010 sind dazu zwei Schritte erforderlich. Erstens müssen Sie SSL in den Internetinformationsdiensten (IIS) deaktivieren und zweitens die entsprechende web.config-Datei bearbeiten und den SSL-Eintrag aus ihr entfernen. In Exchange Server 2010 SP1 ist die Aufgabe sehr viel einfacher geworden, denn hier gibt es den Parameter -RequireSSL für die Cmdlets, die zum Erstellen und Bearbeiten von virtuellen Verzeichnissen dienen. Dabei handelt es sich um folgende Cmdlets: 쐍 New-WebServicesVirtualDirectory 쐍 Set-WebServicesVirtualDirectory 쐍 New-AutodiscoverVirtualDirectory 쐍 Set-AutodiscoverVirtualDirectory Wenn Sie den Paramerter -RequireSSL auf $True setzen, lässt das Verzeichnis nur HTTPS-Datenverkehr zu, bei $False dagegen sowohl HTTPS als auch HTTP. Die Internetinformationsdienste müssen Sie nicht bearbeiten, da Sie die ganze Arbeit mithilfe der Cmdlets erledigen.
Domänencontroller Die Handhabung von Clientverbindungen erfordert eine vielschichtige Zusammenarbeit zwischen Reverseproxyserver, Clientzugriffsserver und Domänencontroller, und häufig ist der Domänencontroller die Ursache für lange Antwortzeiten. In Umgebungen, in denen die Domänencontroller die Authentifzierungsanforderungen von Zehntausenden von Clientverbindungen verarbeiten müssen,
682
sollten Sie zwei Aspekten besondere Aufmerksamkeit schenken. Erstens müssen Sie die Domänencontroller mit genügend sicheren Kanälen versehen, um mit der Nachfrage zur Authentifizierung von Clientverbindungen fertig zu werden. Die Warteschlange für Authentifizierungsanforderungen wird durch die Einstellung MaxConcurrentAPI auf dem Domänencontroller gesteuert. Es kann notwendig werden, den Standardwert, der zwei oder fünf beträgt, zu ändern, damit der Domänencontroller die Nachfrage nach Clientauthentifizierung besser bedienen kann. Einzelheiten darüber finden Sie bei TechNet. Zweitens führt Windows keinen automatischen Lastenausgleich der sicheren Kanäle auf den verfügbaren Domänencontrollern durch, sodass es vorkommen kann, dass ein Domänencontroller von Authentifizierungsanforderungen überschwemmt wird, während ein anderer nichts zu tun hat. Weitere Informationen
Der Knowledge Base-Artikel auf http://support.microsoft.com/kb/167029 erläutert, wie Sie das Hilfsprogramm Setprfdc einsetzen, um dieses Problem zu lösen. Unter http://blogs.technet.com/b/ ad/archive/2008/09/23/ntlm-and-maxconcurrentapi-concerns.aspx finden Sie einen hervorragenden Blogartikel, in dem es um die Einstellung des Parameters -MaxConcurrentAPI zur Handhabung der Authentifizierungslst geht.
Vorbereitungen für Übergang und Interoperabilität Die Bereitstellung ist am einfachsten, wenn Sie Exchange zum ersten Mal installieren. Wenn Sie den Clients mithilfe der Front-End-Server von Exchange Server 2003 oder der Clientzugriffsserver von Exchange Server 2007 einen externen Zugriff anbieten, dann müssen Sie den Übergang dieser Dienste auf Exchange Server 2010 genau planen. Ein genaues Rezept für die Bereitstellung in Umgebungen, in denen es noch Front-End-Server und ältere Clientzugriffsserver gibt, lässt sich nicht so einfach aufstellen. Es gibt einige grundlegende Richtlinien, die Sie aber an die Eigenheiten Ihrer Umgebung anpassen müssen, z.B. die Anzahl und Funktion der älteren Server (intern oder extern), die Anzahl der Standorte, die Geschwindigkeit, in der die Umstellung auf Exchange Server 2010 ablaufen soll, den Zeitpunkt, zu dem die älteren Server außer Betrieb genommen werden sollen usw. Im Allgemeinen aber müssen Sie den beiden nachstehend aufgeführten Grundprinzipien folgen. Der erste Schritt für den Übergang besteht darin, die externe Präsenz des Unternehmens auf Exchange Server 2010 zu aktualisieren. Das bedeutet, das Exchange Server 2010 den Namensraum übernimmt, den die Clients zur Verbindung mit Exchange verwenden (z.B. mail.contoso.com). Ältere Exchange Server-Computer, die eingehende Verbindungen handhaben (Clientzugriffsserver mit Exchange Server 2007 und Front-End-Server mit Exchange Server 2003) verwenden einen neuen Namensraum (z.B. legacymail.contoso.com), den die Clientzugriffsserver von Exchange Server 2010 als Verweis für Verbindungen zu älteren Postfachservern (Exchange Server 2003 oder 2007) heranziehen können. Dadurch müssen die Benutzer die URLs, die Sie für den externen Zugriff verwenden, nicht ändern, und auch ihre mobilen Geräte, E-Mail-Profile usw. nicht umkonfigurieren. Möglicherweise sind für den neuen Namensraum neue SSL-Zertifikate erforderlich. Nehmen Sie keine DNSÄnderungen vor, bevor Sie dazu bereit sind, auf die Exchange Server 2010-Infrastruktur umzuschalten und dort Benutzerverbindungen entgegenzunehmen. Diesen endgültigen Wechsel sollten Sie für ein Feiertagswochenende oder einen anderen Zeitraum einplanen, in dem die Beanspruchung gering ist und Fehler korrigiert werden können, ohne die Benutzer unnötig zu beeinträchtigen.
683
Clientzugriffsserver
Vorbereitungen für Übergang und Interoperabilität
Kapitel 11
Clientzugriffsserver
Aus mehreren Gründen – darunter die Einführung der RPC-Clientzugriffsschicht und der Verzicht auf WebDAV – können Exchange Server 2010-Clientzugriffsserver nicht reibungslos mit Exchange Server 2007-Postfachservern kommunizieren. Der ActiveSync-, POP3- und IMAP4-Zugriff funktioniert problemlos, aber der MAPI- und der OWA-Zugriff sind mit Schwierigkeiten verbunden. Daher müssen Sie mindestens einen Clientzugriffsserver mit Exchange Server 2007 behalten, bis Sie den letzten Exchange Server 2007-Postfachserver außer Betrieb setzen. Eingehende Verbindungen zu Exchange Server 2007-Postfächern werden dann von einem Exchange Server 2010-Clientzugriffsserver an den Exchange Server 2007-Clientzugriffsserver weitergeleitet. Die richtige Reihenfolge der Bereitstellung besteht also darin, zuerst die Exchange Server 2010Clientzugriffsserver in dem Standort für den externen Zugriff zu installieren, und dann zusammen mit den Exchange Server 2010-Postfachservern die Exchange Server 2010-Clientzugriffsserver, die die Exchange Server 2007-Clientzugriffsserver in internen Standorten ersetzen sollen. Tabelle 11.6 führt eine Reihe von Aufgaben auf, die Sie in Ihrem Bereitstellungsplan berücksichtigen müssen, wenn Sie den externen Zugriff von Front-End-Servern mit Exchange Server 2003 oder Clientzugriffsservern mit Exchange Server 2007 umstellen wollen. Überprüfen Sie diese Liste sorgfältig im Lichte Ihrer Umgebung und führen Sie Tests aus, um sicherzustellen, dass der Übergang reibungslos verläuft. Tabelle 11.6
Aufgaben zur Vorbereitung des Übergangs auf Clientzugriffsserver Aufgabe
Vorgehensweise
Erstellen eines E-Mail-Namensraums für die älteren Server
Exchange Server 2003/2007: Erstellen Sie die DNS-Einträge für den E-Mail-Namensraum, den die älteren Server nutzen sollen, und verweisen Sie darin auf die Front-End-Server mit Exchange Server 2003 bzw. die Clientzugriffsserver mit Exchange Server 2007 (oder beide). Exchange Server 2010 verwendet diesen Namensraum für Clients, deren Postfächer sich auf Servern mit den älteren Exchange-Versionen befinden.
Verknüpfen von Exchange Server 2010 mit den älteren Servern
Exchange Server 2003: Aktualisieren Sie das virtuelle OWA-Verzeichnis auf den Clientzugriffsservern mit Exchange Server 2010, sodass diese Server wissen, wohin sie Clientverbindungen für Exchange Server 2003 umleiten müssen. Um beispielsweise den Clientzugriffsserver ExServer1 anzuweisen, Clients für Exchange Server 2003 zu dem Server ExServer2003 umzuleiten, verwenden Sie folgenden Befehl: Set-OWAVirtualDirectory –Identity 'ExServer1\OWA' – Exchange2003URL 'https://ExServer2003.contoso.com/exchange' Exchange Server 2007: Ändern Sie die Eigenschaft ExternalURL des virtuellen OWA-Verzeichnisses auf den Exchange Server 2007-Clientzugriffsservern, sodass sie auf den Namensraum für die älteren Server zeigt: Set-OWAVirtualDirectory –Identity 'Ex2007\OWA' –ExternalUrl 'https://legacymail.contoso.com/owa'
684
Einrichten von ActiveSync auf Exchange Server 2003
Exchange Server 2003/2007: Aktivieren Sie auf den Back-End-Servern mit Exchange Server 2003 die integrierte Windows-Authentifizierung für das ActiveSync-Verzeichnis, damit die über die Exchange Server 2010Clientzugriffsserver weitergeleiteten Verbindungen korrekt verarbeitet werden. Eine detaillierte Anleitung für diese Aufgabe finden Sie unter http://support.microsoft.com/kb/937031.
Aktualisieren der SSL-Zertifikate
Exchange Server 2003/2007: Die SSL-Zertifikate für den Schutz der Clientverbindungen enthalten nicht den neuen Namensraum für die älteren Server. Wenden Sie sich an Ihren Zertifikatanbieter, um neue Zertifikate zu erhalten, und installieren Sie diese auf den Clientzugriffs- und Front-End-Servern.
Die weitere Bearbeitung
Aufgaben zur Vorbereitung des Übergangs auf Clientzugriffsserver (Fortsetzung) Aufgabe
Vorgehensweise
Einrichten der Reverseproxyserver
Exchange Server 2003/2007: Stellen Sie die Verbindung zu den Exchange Server 2010-Clientzugriffsservern her und überprüfen Sie, ob die Clientverbindungen durch den mit dem Internet verbundenen Reverseproxyserver verlaufen. Testen Sie alle Facetten der Clientanbindung. Dazu gehört auch die AutoErmittlung, wenn Sie eine neue Outlook-Installation konfigurieren, um Verbindung zu Postfächern auf Exchange Server 2010 und auf älteren Servern aufzunehmen.
Umschalten von DNS
Exchange Server 2003/2007: Ändern Sie die DNS-Einträge für den externen E-Mail-Zugriff (z.B. mail.contoso.com), sodass sie auf die Exchange Server 2010-Clientzugriffsserver zeigen. Führen Sie Tests durch und überwachen Sie den Clientdatenverkehr, um sicherzustellen, dass Verbindungen zu Postfächern auf Postfachservern sowohl mit Exchange Server 2010 und als auch mit älteren Versionen aufgebaut werden können.
Umkonfigurieren von Outlook Anywhere
Exchange Server 2003/2007: Sorgen Sie dafür, dass der Verbindungspunkt für Outlook Anywhere (RPC über HTTP) von Exchange Server 2010 bereitgestellt wird. Deaktivieren Sie RPC über HTTP auf den Front-EndServern mit Exchange Server 2003 und Outlook Anywhere auf den Exchange Server 2007-Clientzugriffsservern. Diese Funktionen werden nicht mehr gebraucht.
Wenn Sie einen Plan für den Übergang aufstellen, sollten Sie im Internet nach Dokumentation von Microsoft und anderen Anbietern suchen, die die verschiedenen technischen Gesichtspunkte der Umstellung beschreiben. Das ist vor allem dann wichtig, wenn sich Ihnen Aufgaben wie die Umschaltung des externen Zugriffs stellen. TechNet ist eine Informationsquelle, an die man sofort denkt, aber auch die Blogs von MVPs und anderen Exchange-Experten sind eine reichhaltige Fundgrube für Tipps und Techniken, mit denen Sie ein Problem lösen oder den Vorgang beschleunigen können.
Die weitere Bearbeitung In diesem Kapitel haben wir uns angesehen, wie Clientzugriffsserver eingehende Clientverbindungen über mehrere Protokolle handhaben. Abgesehen von der Übernahme der MAPI-Verbindungen unterscheidet sich die Natur dieser Aufgabe nicht sehr von der Vorgehensweise in Exchange Server 2007. In Exchange Server 2010 wird den Clientzugriffsservern jedoch eine ganze Palette neuer Obliegenheiten aufgebürdet, weshalb wir uns ansehen werden, wie der Postfachreplikationsdienst – ein neues Merkmal von Clientzugriffsservern – die Bearbeitung von Postfächern übernimmt. Außerdem beschäftigen wir uns noch mit einigen anderen Diensten, die die Aktivitäten der Benutzer unterstützen. All das ist Thema unseres nächsten Kapitels.
685
Clientzugriffsserver
Tabelle 11.6
Postfachunterstützungsdienste
Kapitel 12
Postfachunterstützungsdienste
In diesem Kapitel: Der Postfachreplikationsdienst
688
Import und Export von Postfächern
723
E-Mail-Infos und Messgrößen für Gruppen
737
Das Offlineadressbuch
746
Das hierarchische Adressbuch
765
Postfachassistenten
766
Als Nächstes: der Transport
772
687
Kapitel 12
Postfachunterstützungsdienste
Postfachunterstützungsdienste ist ein nicht streng definierter Begriff, den ich für Verwaltungstätigkeiten geprägt habe, die fortlaufende Benutzeraktivitäten unterstützen. In dieses Kapitel habe ich vier Arten solcher Dienste aufgenommen. Wir beginnen mit zwei wichtigen Funktionen, die vom Postfachreplikationsdienst erledigt werden: wie Postfächer verschoben und wie Daten in Postfächer importiert bzw. aus ihnen exportiert werden. Anschließend sehen wir uns den Dienst für E-Mail-Infos an, der die Benutzer auf Fehler aufmerksam macht, die sie möglicherweise gerade begehen wollen. Zum Abschluss geht es um das Offlineadressbuch, das von praktisch allen Geschäftsreisenden herangezogen wird, um für Informationen über die Personen und Gruppen in ihrer Organisation abzurufen.
Der Postfachreplikationsdienst Der Postfachreplikationsdienst von Microsoft Exchange Server (Mailbox Replication Service, MRS) ist für die Verarbeitung von Verschiebungs-, Import- und Exportanforderungen zuständig. Er läuft auf jedem Clientzugriffsserver und kann Daten zwischen, in oder aus Datenbanken transportieren. Im- und Export sind für den Postfachreplikationsdienst in Exchange Server 2010 SP1 neu hinzugekommen, vorher konnten nur Verschiebungen durchgeführt werden. Der Prozess des Postfachreplikationsdienstes heißt MSExchangeMailboxReplication.exe. Er wird häufig mit der Datenbankreplikation der Datenbankverfügbarkeitsgruppen (MSExchangeReplication.exe) in einen Topf geworfen, es handelt sich jedoch um zwei eigenständige Prozesse. Die Unterbringung des Postfachreplikationsdienstes auf dem Clientzugriffsserver ist ein Beispiel dafür, wie Microsoft die gesamte MAPI-Verarbeitung (Messaging Application Programming Interface) in diese Serverrolle verschoben hat, um sie mit der Verarbeitung der Internetprotokolle zu verbinden, die der Clientzugriffsserver in Exchange Server 2007 übernommen hat. Sie können sich Imund Exportvorgänge als eine andere Art der Protokollverarbeitung oder -wiedergabe vorstellen, weil der Postfachreplikationsdienst den Inhalt der Postfachdatenbanken bei der Übertragung in oder aus PST-Dateien übersetzen muss.
Die Konfigurationsdatei für den Postfachreplikationsdienst Der Postfachreplikationsdienst wird von den Einstellungen in der Konfigurationsdatei Exchange\ Bin\MSExchangeMailboxReplication Service.exe.config gesteuert, die Sie mit einem Texteditor bearbeiten können, um die Parameter für den Dienst (siehe Tabelle 12.1) zu ändern. Der Postfachreplikationsdienst muss nicht neu gestartet werden, um die Änderungen an den Eigenschaften wirksam werden zu lassen. Tabelle 12.1
688
Eigenschaften zur Steuerung des Postfachreplikationsdienstes Eigenschaft
Funktion
MaxActiveMovesPerTargetMDB
Legt fest, wie viele Postfächer der Postfachreplikationsdienst gleichzeitig in eine Datenbank verschieben kann. Der Standardwert beträgt in der RTM-Version 5, in SP1 2, der Höchstwert ist 100.
MaxActiveMovesPerSourceMDB
Legt fest, wie viele Postfächer der Postfachreplikationsdienst gleichzeitig aus einer Quelldatenbank verschieben kann. Der Standardwert beträgt 5, der Höchstwert 100.
Der Postfachreplikationsdienst
Eigenschaften zur Steuerung des Postfachreplikationsdienstes Eigenschaft
Funktion
MaxActiveMovesPerSourceServer
Legt fest, wie viele gleichzeitige Verschiebevorgänge ein Quellserver maximal akzeptiert. Der Standardwert beträgt 50, der Höchstwert 1000.
MaxActiveMovesPerTargetServer
Legt fest, wie viele gleichzeitige Verschiebevorgänge ein Zielserver maximal akzeptiert. Der Standardwert beträgt 5, der Höchstwert 1000.
MaxTotalMovesPerMRS
Legt fest, wie viele gleichzeitige Verschiebevorgänge eine einzelne Instanz des Postfachreplikationsdienstes verarbeiten kann. Der Standardwert beträgt 100, der Höchstwert 1024.
FullScanMoveJobsPollingInterval
Der Postfachreplikationsdienst verarbeitet Anforderungen, sobald sie ausgelöst werden, und durchsucht außerdem Datenbanken nach entsprechenden Anforderungen. Das Standardintervall zum Durchsuchen beträgt 00:05:00 (fünf Minuten).
Retry Delay
Legt fest, wie lange der Postfachreplikationsdienst wartet, bevor er bei vorübergehenden Fehlern versucht, einen Vorgang erneut durchzuführen. Der Standardwert beträgt 00:00:30 (30 Sekunden).
MaxRetries
Legt fest, wie oft der Postfachreplikationsdienst bei vorübergehenden Fehlern versucht, einen Vorgang erneut durchzuführen. Der Standardwert beträgt 60. Wird dieser Wert überschritten, scheitert der Verschiebevorgang.
MaxMoveHistoryLength
Legt fest, wie viele Verschiebungsverläufe der Postfachreplikationsdienst für ein Postfach aufbewahrt. Der Standardwert beträgt 2, d.h., Sie können die beiden letzten Verlaufseinträge für ein bestimmtes Postfach abrufen.
Diese Grenzen gelten serverweit und sind nicht verbindlich, sondern werden nur angestrebt. Anders ausgedrückt: Sie können manchmal überschritten werden, beispielsweise, wenn zwei Postfachreplikationsdienstserver auf dieselbe Quelldatenbank zugreifen, um Verschiebungsanforderungen zu verarbeiten, und zusammen die Höchstzahl der aktiven Verschiebungen überschreiten, die Sie für die Datenbank festgelegt haben. Dabei handelt es sich jedoch eher um Ausnahmen als um die Regel, und die normale Verarbeitung wird zu gegebener Zeit wieder aufgenommen. HINWEIS Wenn Sie die Konfigurationsdatei für den Postfachreplikationsdienst auf einem Clientzugriffsserver ändern, sollten Sie die Änderung auf alle anderen Clientzugriffsserver an diesem Standort übertragen, damit sämtliche Server gleich arbeiten. Die Fähigkeit, Postfächer zwischen Datenbanken zu verschieben, ist für Exchange von grundlegender Bedeutung. Da Sie zur Bereitstellung von Exchange Server 2010 neue Server installieren müssen, ist das Verschieben von Postfächern die wesentliche Methode, um Benutzerdaten von Computern mit Exchange Server 2003 und Exchange Server 2007 auf Exchange Server 2010 zu migrieren. Außerdem gibt es weitere Gründe, aus denen Postfächer verschoben werden: 쐍 Ausgleich der Benutzerlast über die verfügbaren Postfachdatenbanken hinweg Wenn Benutzer in die Firma eintreten oder sie verlassen, ändert sich die Anzahl der Postfächer, die einer Datenbank zugewiesen sind. Einige Postfächer sind auch größer als andere. Administratoren streben häufig an, die Arbeitsbelastung von Datenbanken durch Übertragen von Postfächern wieder gleichmäßig zu verteilen, sodass jede Datenbank etwa dieselbe Anzahl von Postfächern ungefähr gleicher Größe beherbergt. Mit der Einführung persönlicher Archive müssen beim Lastenausgleich auch deren Last- und Speicheranforderungen berücksichtigt werden. Ein ähnliches Pro689
Postfachunterstützungsdienste
Tabelle 12.1
Kapitel 12
Postfachunterstützungsdienste
blem tritt auf, wenn eine Datenbank für den reibungslosen Betrieb zu groß wird (beispielsweise wenn eine Sicherung länger dauert als erwünscht). In diesem Fall können die Administratoren Postfächer in andere Datenbanken verschieben. Das führt zwar nur zu zusätzlichem Leerraum in der Datenbank und reduziert ihre Größe nicht sofort, verhindert jedoch, dass sie weiter anschwillt. 쐍 Auslagerung in Hostingumgebungen Eine Exchange Server 2010-Organisation kann sich über lokale Server und die von Hostern erstrecken. Mithilfe von Postfachverschiebungen können Postfächer von lokalen auf gehostete Server verlagert werden und umgekehrt. 쐍 Umorganisation Benutzer können innerhalb der Firma versetzt werden und ihren physischen Standort so ändern, dass ihre aktuelle Postfachdatenbank nicht mehr geeignet ist (wenn sie beispielsweise nach dem Wechsel auf einem Server in einem entfernten Rechenzentrum liegt). In dieser Situation verschiebt der Administrator das Postfach des Benutzers üblicherweise auf einen Server, der »näher« an ihm liegt. 쐍 Organisationshierarchie Manche Firmen bringen gern sämtliche Postfächer ausgewählter Benutzergruppen in bestimmten Datenbanken unter, damit die jeweils passenden Richtlinien gesammelt auf sie angewendet werden können (hohe Verfügbarkeit, Postfachkontingente, Aufbewahrungsdauer für gelöschte Elemente usw.). Sämtliche leitenden Mitarbeiter der Firma können zum Beispiel in einer Datenbank zusammengefasst werden, von der es vier Exemplare gibt, um eine möglichst hohe Verfügbarkeit zu gewährleisten, während die Postfächer vorübergehend oder in Teilzeit beschäftigter Angestellter in einer Datenbank liegen, von der es nur zwei Exemplare gibt. 쐍 Serverwechsel Bevor ein Postfachserver einer Exchange-Organisation stillgelegt werden kann, müssen sämtliche Datenbanken entfernt werden, die er beherbergt. Dies ist erst möglich, nachdem alle ihre Postfächer in andere Datenbanken überführt wurden. 쐍 Beschädigung von Postfächern oder Datenbanken In einem Postfach können beschädigte Elemente vorkommen, die Probleme in der Datenbank verursachen (siehe die Erörterung über Postfachquarantäne in Kapitel 7, »Der Informationsspeicher von Exchange Server 2010«). Durch Verschieben des Postfachs lässt sich der Schaden beheben, wenn sie Sie den Grenzwert für ungültige Elemente setzen, der Exchange erlaubt, verdächtige Elemente zu löschen, die beim Verschieben von Postfachinhalten entdeckt werden. 쐍 Gruppierung von Postfächern Manche Administratoren fassen die Postfächer eines bestimmten Typs gern in einer bestimmten Datenbank zusammen (um beispielsweise alle Raumpostfächer in einer Datenbank zu haben, alle verknüpften Postfächer in einer anderen usw.). Nach demselben Ansatz werden Postfächer häufig abteilungsweise zusammengefasst, sodass alle Postfächer der Verkaufsabteilung in der Datenbank Verkauf zu finden sind. Microsoft ändert die Funktionsweise von Exchange nicht ohne guten Grund. Als Exchange Server 2010 am Horizont auftauchte, war deutlich zu erkennen, dass die zunehmende Größe von Postfächern sowie einige Probleme in früheren Implementierungen der Postfachverschiebung nach einer Änderung verlangten. Das Cmdlet Move-Mailbox verarbeitet Verschiebungen synchron. Anders ausgedrückt: Sobald es begonnen hat, Postfachinhalte zu übertragen, setzt es den Vorgang fort, bis der gesamte Inhalt erfolgreich verschoben ist, eine Fehlerschwelle aufgrund beschädigter Elemente im Quellpostfach überschritten wird oder Sie die Verschiebungsanforderung abbrechen. Wenn die Arbeitsstation, auf der die Verschiebung stattfindet, die Sitzung der Exchange-Verwaltungskonsole oder Exchange-Verwaltungsshell beendet, in der der Vorgang erfolgt, geht der Inhalt des neuen Postfachs verloren, und das Verfahren muss ganz von vorn beginnen, selbst wenn bereits einige Gigabyte
690
an Daten auf den Zielserver übertragen wurden. Außerdem verlangt Exchange Server 2007 von den Benutzern, während der Dauer der Verschiebung offline zu bleiben und nicht zu versuchen, auf ihr Postfach zuzugreifen. Bei kleinen Postfächern von weniger als 500 MB ist diese Beschränkung normalerweise nicht problematisch, aber die zum Verschieben von Postfächern erforderliche Zeit hat parallel zur Postfachgröße zugenommen. In einer Zeit, in der Postfächer von 10 oder gar 25 GB normal werden, ist vorauszusehen, dass synchrone Verschiebungen länger dauern und dass es nicht akzeptabel ist, Arbeitsstationen so lange zu blockieren, bis eine umfangreiche Verschiebung abgeschlossen ist, oder einem Benutzer zu sagen, dass er sechs Stunden lang nicht auf sein Postfach zugreifen kann, weil Exchange Elemente von einer Datenbank in eine andere verlagert. Auch die zunehmende Beliebtheit gehosteter Exchange-Dienste wirkt sich hier aus, weil es vorkommen kann, dass einige Postfächer auf Servern in der IT-Infrastruktur Ihrer Firma liegen, andere dagegen auf Servern »in der Wolke«. Es ist wahrscheinlich, dass die Bandbreite über das Internet stärker eingeschränkt ist als zwischen zwei Servern in einem lokalen Netzwerk, sodass Verschiebungen von einem lokalen Server auf einen bei einem Hostinganbieter sogar länger dauern können als zwischen Servern innerhalb der hauseigenen Infrastruktur. Onlineverschiebung von Postfächern mithilfe von Cmdlets
Microsoft hat in Exchange Server 2010 eine wesentliche Änderung in der Funktionsweise des Postfachverschiebevorgangs vorgenommen. In Exchange Server 2007 überführen Sie ein Postfach mithilfe des Cmdlets Move-Mailbox von einer Datenbank in eine andere. Exchange Server 2010 führt für diesen Vorgang eine Reihe von Cmdlets für »Verschiebungsanforderungen« ein. Der wesentliche Unterschied und der Grund für die neuen Cmdlets liegt darin, dass Postfachverschiebungen jetzt asynchron im Hintergrund stattfinden und der Benutzer sich für die erforderliche Zeit nicht mehr abmelden muss. Anders als beim Cmdlet Move-Mailbox können die Benutzer weiter online arbeiten, während der Postfachreplikationsdienst im Hintergrund Postfachinhalte kopiert. Die Benutzer bemerken lediglich in dem Augenblick eine Unterbrechung, in dem sie nach Abschluss der Verschiebung in das gerade kopierte Postfach wechseln. Microsoft bezeichnet dieses Verfahren als Onlineverschiebung von Postfächern. Die dazugehörigen Cmdlets sind über die Exchange-Verwaltungskonsole (im Assistenten für das Verschieben von Postfächern) und die Exchange-Verwaltungsshell zu erreichen.
Asynchrones Verschieben Postfachverschiebungen zwischen Exchange Server 2010-Computern erfolgen asynchron, d.h., Sie können zahlreiche Anforderungen starten und dann etwas anderes erledigen, anstatt ihre Arbeitsstation stundenlang damit blockieren. Der grundlegende Ablauf der Verarbeitung sieht wie folgt aus: 쐍 Es wird eine Verschiebungsanforderung erstellt, die das Quellpostfach und die Zieldatenbank angibt. 쐍 Der Postfachreplikationsdienst kopiert den Inhalt des ausgewählten Postfachs in die Zieldatenbank. 쐍 Der Postfachreplikationsdienst prüft, ob seit Beginn der Verschiebung in der Quelldatenbank Elemente aktualisiert oder erstellt wurden. Falls ja, werden diese mithilfe inkrementeller Synchronisierung hinüberkopiert.
691
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
쐍 Wird eine Verschiebung durch einen Fehler unterbrochen, beispielsweise das Überschreiten eines Schwellenwerts für ungültige Elemente, kann der Postfachreplikationsdienst die Verschiebung an diesem Punkt wieder aufnehmen. 쐍 Nachdem der gesamte Inhalt in das neue Postfach verschoben wurde, schließt der Postfachreplikationsdienst den Vorgang ab, indem er das Active Directory-Konto des Benutzers auf den Speicherort des neuen Postfachs umstellt. Dieser Ansatz bietet folgende Vorteile: 쐍 Die Benutzer können weiterarbeiten, während der Postfachreplikationsdienst ihre Postfächer auf den Zielserver verschiebt, ein Faktor, der mit zunehmender Postfachgröße immer wichtiger wird. Die Benutzer werden zwar gezwungen, ihre Clientverbindung zu trennen und erneut herzustellen, nachdem der Postfachreplikationsdienst in Active Directory den Zeiger auf ihr Postfach umgestellt hat, aber Microsoft wird dieses Problem bei Verschiebungen zwischen Exchange Server 2010 SP1-Datenbanken angehen und einen nahtlosen Übergang ermöglichen, was ursprünglich schon in Exchange Server 2010 SP1 implementiert werden sollte, nun aber für ein späteres Release vorgesehen ist. Lesen Sie dazu den Abschnitt »Beibehalten der Postfachsignatur« weiter hinten in diesem Kapitel. 쐍 Die Belastung durch Postfachverschiebungen wird automatisch auf alle verfügbaren Instanzen des Postfachreplikationsdienstes am Active Directory-Standort verteilt. Exchange schränkt sie ein, um zu verhindern, dass Quell- oder Zielserver überlastet werden. Administratoren können diese Einschränkungen ggf. anpassen. 쐍 Persönliche Archive können gemeinsam mit dem Primärpostfach verschoben werden oder in der Quelldatenbank verbleiben. Sie können sich auch entschließen, nur Ihr persönliches Archiv in eine andere Datenbank zu verlegen, was sinnvoll ist, wenn persönliche Archive in einer dafür reservierten Datenbank untergebracht werden sollen. 쐍 Der Inhalt des Papierkorbs (gelöschte Elemente, deren Aufbewahrungsfrist noch nicht abgelaufen ist) wird sowohl mit dem Primärpostfach als auch mit dem persönlichen Archiv gemeinsam verschoben. Dies gilt nur für Verschiebungen von Exchange Server 2010-Computern aus. Aufgrund der Änderung der Papierkorbstruktur in Exchange Server 2010 bleiben Papierkorbinhalte bei Verschiebungen von älteren Versionen aus nicht erhalten. 쐍 Elemente werden bei der Verschiebung in den Inhaltsindex der Zieldatenbank aufgenommen, um zu gewährleisten, dass weiterhin schnelle Suchvorgänge möglich sind. Dieser Faktor ist nicht so wichtig, wenn Sie Outlook im Exchange-Cache-Modus einsetzen, weil Suchoperationen auf dem Client dann mithilfe der Windows Desktop-Suche ausgeführt werden. Es bedeutet jedoch, dass Discoverysuchvorgänge von Administratoren Elemente auch finden, nachdem das Postfach in die Zieldatenbank verlegt wurde. 쐍 Bei Onlineverschiebungen von Servern mit Exchange Server 2003 oder Exchange Server 2007 werden nicht viele Informationen protokolliert, die dem Administrator aufzeigen, was während des Vorgangs abgelaufen ist. Um Fehlersuche und -behebung zu ermöglichen, zeichnet der Postfachreplikationsdienst umfassende Details über jede Postfachverschiebung auf und speichert diese Berichte im Postfach. Standardmäßig werden Angaben zu den beiden letzten Verschiebevorgängen für ein Postfach festgehalten. Ihre Anzahl kann ggf. erhöht werden. Wie der Postfachreplikationsdienst diese Vorteile im Einzelnen ausspielt, sehen wir uns im verbleibenden Teil dieses Abschnitts an.
692
Der Postfachreplikationsdienst
Der Postfachreplikationsdienst führt auch Postfachverschiebungen von Servern mit Exchange Server 2003 SP2 und Exchange Server 2007 SP2 auf Exchange Server 2010-Computer durch. Sie werden von Exchange Server 2010 aus gestartet. Verschiebungen von Exchange Server 2007 aus erfolgen online, von Exchange Server 2003 aus jedoch offline, d.h., dass die Benutzer ihr Postfach verlassen müssen, damit der Postfachreplikationsdienst die Daten von Exchange Server 2010 aus abrufen und in der Zieldatenbank ein neues Postfach anlegen kann. Verschiebungen aus noch älteren Exchange-Versionen wie Exchange Server 2000 sind nicht möglich. Umgekehrt ist der Postfachreplikationsdienst in der Lage, Postfächer aus Exchange Server 2010 in Exchange Server 2007 SP2 oder Exchange Server 2003 SP2 zu verschieben, was wiederum in Exchange Server 2010 gestartet wird und offline erfolgt. In diesen Situationen erstellt der Postfachreplikationsdienst eine direkte Verbindung zum Postfach auf dem älteren Server, um den Inhalt zu verschieben. Der Postfachreplikationsdienst kann jedoch keine Postfächer zwischen Servern verschieben, wenn sowohl auf dem Quell- als auch auf dem Zielserver ältere Exchange-Versionen installiert sind.
Verarbeitung durch den Postfachreplikationsdienst Der Postfachreplikationsdienst durchsucht das Systempostfach der Datenbanken auf den Servern am Standort regelmäßig auf neue Verschiebungsanforderungen, die dort warten. Außer den Warteschlangen für Anforderungen sind im Systempostfach auch Angaben über aktuelle Verschiebungsanforderungen gespeichert, die während des Vorgangs aktualisiert werden. Dazu zählen das aktuelle Stadium der Verschiebung, der Prozentsatz der Erledigung, die Anzahl übertragener Bytes, die Anzahl übertragener Elemente, Zeitstempel, Warnmeldungen usw. Wie wir weiter hinten in diesem Abschnitt sehen, werden diese Daten mithilfe des Cmdlets Get-MoveRequestStatistics erfasst. Abbildung 12.1 zeigt die einzelnen Schritte beim Verschieben eines Postfachs mit dem Postfachreplikationsdienst. Verschiebungsanforderungen werden in der Reihenfolge des Eingangs verarbeitet. Sobald eine neue Anforderung bemerkt wird, übernimmt eine der Instanzen des Postfachreplikationsdienstes am Standort die Zuständigkeit für ihre Verarbeitung, indem sie ihren Namen in die Anforderung schreibt, damit keine andere Instanz versucht, die Verschiebung noch einmal durchzuführen. Außerdem werden einige Active Directory-Daten für das Konto, dem das Postfach gehört, aktualisiert, um Informationen über die Verschiebungsanforderung aufzuzeichnen, darunter ihren aktuellen Status, die Quell- und die Zieldatenbank, den Batchnamen und einige Flags. Anschließend beginnt der zuständige Postfachreplikationsdienst, Daten aus der Quelldatenbank abzurufen, um das neue Postfach zu füllen. Die Daten werden in mehreren Phasen übertragen. Zunächst erfolgt ein erster Fülldurchgang, bei dem der gesamte Inhalt des Quellpostfachs aufgelistet und in das Zielpostfach kopiert wird. Parallel dazu verfolgt der Postfachreplikationsdienst Änderungen im Quellpostfach und führt danach eine oder mehrere inkrementelle Aktualisierungen durch, um geänderte oder hinzugefügte Inhalte in das Zielpostfach zu übertragen, damit es vollständig auf dem neuesten Stand ist. Die Elemente bewegen sich kontinuierlich von der Quell- in die Zieldatenbank, solange es nicht zur einem Stau aufgrund von Störungen durch eine Hochverfügbarkeitsfunktion kommt, was nur auf Servern geschehen kann, die zu einer Datenbankverfügbarkeitsgruppe gehören. Wenn der Informationsspeicher meldet, dass die Datenbank mit dem Zielpostfach mit dem Kopieren des Protokolls hinterherhinkt (wenn ihre Kopierwarteschlangen also länger werden), unterbricht der Postfachrep693
Postfachunterstützungsdienste
Insidertipp: Verschieben älterer Postfächer
Kapitel 12
Postfachunterstützungsdienste
likationsdienst den Verschiebevorgang für 30 Sekunden und macht anschließend weiter. Normalerweise reicht dies aus, um eine Anforderungsspitze abzuwarten und zu verhindern, dass Postfachverschiebungen die Protokollreplikation in der Verfügbarkeitsgruppe stören. Abbildg. 12.1
Die einzelnen Schritte beim Verschieben eines Postfachs in Exchange Server 2010 ICS-Zustand des Quellpostfachs aufzeichnen
Inhalt des Quellpostfachs auflisten
Augelisteten Postfachinhalt kopieren
Änderungen der Quelle auflisten
Änderungen auf Zielpostfach übertragen
Quellpostfach sperren
Änderungen der Quelle auflisten
Änderungen auf Zielpostfach übertragen
Active Directory-Daten aktualisieren
Zielpostfach entsperren
Quellpostfach löschen
VORSICHT Denken Sie daran, dass beim Kopieren eines Postfachs von einer Datenbank in eine andere Transaktionsprotokolle angelegt werden, die auf die Server mit den Datenbankkopien repliziert und dort eingespielt werden müssen. Verbleibt die Datenbank 30 Minuten lang in einem fehlerhaften Zustand, lässt der Postfachreplikationsdienst die Verschiebungsanforderung scheitern, sodass sie erneut gestartet werden muss. Der Postfachreplikationsdienst setzt ICS (Incremental Change Synchronization) ein, um inkrementelle Aktualisierungen vorzunehmen, also denselben Mechanismus, den auch Outlook im ExchangeCache-Modus für die tröpfchenweise Synchronisierung im Hintergrund nutzt. Um die Verschiebung abzuschließen, sperrt der Postfachreplikationsdienst das Quellpostfach, wenn er die letzte Runde inkrementeller Synchronisierungen durchführt, um zu gewährleisten, dass keine weiteren Änderungen erfolgen. Dieser Schritt wird als Finalisierungsphase bezeichnet und kann zwischen zehn Sekunden und fünf bis sechs Minuten dauern, je nach Anzahl der Ordner im Postfach. Je mehr es sind, desto mehr Arbeit muss der Postfachreplikationsdienst leisten, um sicher zu sein, dass während des ersten Füllvorgangs keine weiteren Elemente in den einzelnen Ordnern eingegangen sind oder geändert wurden. Wenn der Postfachinhalt auf dem Zielserver eintrifft, wird er indiziert, um zu gewährleisten, dass das neue Postfach vollständig ist, wenn der Postfachreplikationsdienst alles verschoben hat. Die Metadaten des Postfachs werden ebenfalls verschoben, beispielsweise Ansichten, damit das neue Postfach den Benutzern genauso dargestellt wird wie das alte. Die Verschiebungsanforderung scheitert nicht,
694
wenn der Indexdienst stoppt, Elemente nicht so schnell indizieren kann, wie sie eintreffen, oder anderweitig nicht verfügbar ist. In diesem Fall verarbeitet der Indexdienst das neue Postfach, sobald er wieder normal funktioniert. Auf jedem Clientzugriffsserver eines Active Directory-Standorts wird eine Instanz des Postfachreplikationsdienstes betrieben. Sie verfolgt die Arbeit der anderen, indem sie die wartenden Verschiebungsanforderungen untersucht, um sicherzustellen, dass die Grenzwerte für gleichzeitige Verschiebevorgänge in die Zieldatenbank global beachtet werden. Anders ausgedrückt: Warten bei zwei laufenden Instanzen des Postfachreplikationsdienstes 20 Anforderungen für eine einzige Datenbank, beginnt die erste mit der Verarbeitung, indem sie das Systempostfach der Datenbank prüft und die Anforderungen markiert, die sie zur Verarbeitung entgegennimmt. Der zweite Postfachreplikationsdienstprozess ist ebenfalls aktiv und verarbeitet weitere Anforderungen (die der erste nicht für sich markiert hat), bis der globale Grenzwert für gleichzeitig aktive Verschiebungen (fünf) erreicht ist. Dann werden keine Anforderungen für die Zieldatenbank mehr abgearbeitet, bis der Postfachreplikationsdienst einen Teil der aktiven Anforderungen abgeschlossen hat. Stoppt eine Instanz des Postfachreplikationsdienstes aus irgendeinem Grund, beispielsweise, weil der Server heruntergefahren wurde, und ist am Standort eine weitere Instanz verfügbar, übernimmt jene die Verarbeitung der aktiven Verschiebungen. Standardmäßig gelten für die Verarbeitung durch eine Instanz des Postfachreplikationsdienstes folgende Grenzwerte: 쐍 Fünf gleichzeitige Verschiebungen in dieselbe Zieldatenbank. Die Verringerung dieses Wertes in SP1 soll gewährleisten, dass die hohe Verfügbarkeit der Zieldatenbanken erhalten bleibt. 쐍 Fünf gleichzeitige Verschiebungen auf denselben Zielserver. 쐍 Fünf bzw. zwei gleichzeitige Verschiebungen (RTM bzw. SP1) aus derselben Quelldatenbank. 쐍 50 gleichzeitige Verschiebungen vom selben Quellserver. 쐍 100 Verschiebungen zwischen sämtlichen Datenbanken und Servern pro Instanz des Postfachreplikationsdienstes. Die unterschiedlichen Grenzwerte für gleichzeitige Verschiebungen bei Quell- und Zielserver liefern einen deutlichen Hinweis auf die relative Verarbeitungslast, die auf den jeweiligen Servern entsteht. Um den Umfang gleichzeitiger Aktivitäten zu steigern oder zu verringern, können Sie festlegen, wie der Postfachreplikationsdienst arbeitet, indem Sie seine Konfigurationsdatei bearbeiten (siehe den Abschnitt »Die Konfigurationsdatei für den Postfachreplikationsdienst« weiter vorn in diesem Kapitel).
Verhindern von Datenverlusten Um die Postfachverschiebung abzuschließen, stellt der Postfachreplikationsdienst zum Schluss noch den Active Directory-Zeiger auf das aktive Postfach um, damit der Benutzer damit verbunden wird und beginnen kann, es einzusetzen. In der ursprünglichen Version von Exchange Server 2010 räumte der Postfachreplikationsdienst anschließend auf, indem er das alte Postfach löschte. Dieser Mechanismus funktionierte immer gut, wenn der Quell- und der Zielserver in Ordnung waren und direkt nach der Verschiebung kein Serverausfall auftrat. Die Erfahrung zeigte jedoch, dass es zu Datenverlusten kommen konnte, wenn der Zielserver mit dem verschobenen Postfach aufgrund eines Speicherfehlers oder eines anderen Problems einen verlustbehafteten Ausfall hatte.
695
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
HINWEIS In diesem Zusammenhang bedeutet ein »verlustbehafteter Ausfall«, dass die Datenbank mit einigen Datenverlusten aufgrund fehlender Transaktionsprotokolle wiederhergestellt werden konnte. Häufig ist der Verlust gering, es können also nur ein oder zwei Protokolle mit unzusammenhängenden Daten nicht wiederhergestellt werden, aber es ist auch schon vorgekommen, dass Postfächer größere Informationsmengen verloren haben. Die mit Exchange Server 2010 SP1 eingeführte Lösung besteht in einem vorsichtigeren Ansatz. Anstatt das Quellpostfach direkt nach einer erfolgreich abgeschlossenen Verschiebung zu löschen, versetzt Exchange es jetzt in den Zustand SoftDeleted, d.h., das Quellpostfach – mit dem gesamten Postfachinhalt – bleibt bestehen, bis die Aufbewahrungsfrist der Datenbank für gelöschte Postfächer abgelaufen ist. Diese beträgt normalerweise zwischen sieben Tagen und einem Monat beträgt und ist in der Eigenschaft MailboxRetention der Datenbank festgelegt. Während dieser Zeit lassen sich Daten aus dem alten Quellpostfach durch eine Anforderung wiederherstellen, die mithilfe des Cmdlets New-MailboxRestoreRequest gestartet wird. Solche Anforderungen verarbeitet der Postfachreplikationsdienst, um Daten aus Postfächern wiederherzustellen, die sich in einer Wiederherstellungsdatenbank (siehe Kapitel 9, »Sicherung und Wiederherstellung«) befinden oder »weich« (vorläufig) gelöscht und in einer normalen Datenbank abgelegt wurden. Informationen über vorläufig gelöschte Postfächer in einer Datenbank finden Sie mit dem Cmdlet Get-MailboxStatistics: Get-MailboxStatistics –Database DB3 | Where {$_.DisconnectReason –eq 'SoftDeleted'} | Format-Table DisplayName, DisconnectReason, DisconnectDate DisplayName
DisconnectReason
DisconnectDate
------------------
------------------
-------------------
Peled, Yael (IT)
SoftDeleted
6/3/2010 9:26:42 PM
Die neue Vorgehensweise, alte Quellpostfächer beizubehalten, gewährleistet zwar die Wiederherstellung von Daten im Problemfall, bedeutet aber auch, dass die uralte Praxis, Postfächer zwischen Datenbanken zu verschieben, um die Größe von Datenbanken auszugleichen, überdacht werden muss. Der von den verschobenen Postfächern belegte Platz wird nicht sofort freigegeben, sondern erst, wenn die Aufbewahrungsfrist des gelöschten Postfachs abgelaufen ist. Stellt dies ein Problem dar, können Sie das sofortige Löschen eines Postfachs mithilfe des Cmdlets Remove-StoreMailbox erzwingen. Für das Postfach im vorigen Beispiel lautet der Befehl wie folgt: Remove-StoreMailbox –Identity 'Peled, Yael (IT)' –MailboxState 'SoftDeleted' –Database 'DB3'
Die Exchange-Verwaltungsshell fordert Sie auf, die Aktion zu bestätigen, und löscht anschließend den Postfachinhalt.
Verschieben von Postfächern Abbildung 12.2 zeigt den Assistenten zum Verschieben von Postfächern, der von der Exchange-Verwaltungskonsole aufgerufen wird, nachdem Sie ein oder mehrere Postfächer zum Verschieben ausgewählt haben. In diesem Fall sollen einige Postfächer in eine andere Datenbank verlegt werden. In Exchange Server 2010 SP1 können Sie persönliche Archive gemeinsam mit den Primärpostfächern
696
verschieben, aber auch auf verschiedene Datenbanken verteilen. Was geschieht, wenn Sie Postfächer mit Archiven auswählen, erörtern wir in Kürze. Der Assistent zeigt Ihnen die Optionen zum Verschieben von Archiven nur, wenn die ausgewählten Postfächer Archive enthalten. Abbildg. 12.2
Auswählen von Postfächern zum Verschieben und Angabe der Zieldatenbank
Die Optionen, die der Assistent bietet, sind einfach. Sie müssen eine Zieldatenbank auswählen und angeben, was mit ungültigen oder beschädigten Elementen im Quellpostfach geschehen soll (siehe Abbildung 12.3). Der Standardwert für Die fehlerhaften Nachrichten auslassen lautet 0, d.h., dass der Postfachreplikationsdienst keine Toleranz gegenüber ungültigen Elementen zeigt, die er beim Verschieben verarbeiten soll, die Verschiebung also scheitert. Der Wert 0 ist wahrscheinlich zu vorsichtig. Meistens ist es am günstigsten, den Postfachreplikationsdienst etwa zehn beschädigte Elemente überspringen zu lassen und weiterzumachen. Im Abschnitt »Beheben von Fehlern bei Verschiebungsanforderungen« weiter hinten in diesem Kapitel finden Sie weitere Informationen dazu. Sobald Sie den Assistenten durchgearbeitet haben, erstellt Exchange eine eigene Verschiebungsanforderung für jedes Postfach und reiht sie zur Verarbeitung in die Warteschlange ein. Erwartungsgemäß laufen alle Verschiebungen im Hintergrund ab. Daher ist es eine großartige Methode, eine Reihe von Verschiebungsanforderungen zur Verarbeitung in der Mittagspause oder über Nacht vorzusehen. VORSICHT Der Assistent prüft nicht, ob Sie für die Verschiebung eine andere Datenbank als Ziel ausgewählt haben. Besonders bei der Verarbeitung mehrerer Postfächer ist es leicht möglich, diesen Fehler zu begehen. In diesem Fall meldet die Exchange-Verwaltungskonsole einen Fehler, wenn sie die neue Verschiebungsanforderung erstellt: Postfach 'contoso.com/Exchange Users/Shen, Paul' befindet sich bereits in der Zieldatenbank 'IT Department'.
697
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12 Abbildg. 12.3
Postfachunterstützungsdienste
Festlegen des Schwellenwerts für ungültige Elemente, die bei einer Postfachverschiebung toleriert – werden können
Wie bereits erwähnt, verschieben Administratoren häufig Postfächer, um sie gleichmäßig über die verfügbaren Datenbanken zu verteilen. Die Exchange-Verwaltungskonsole erlaubt Ihnen, die Angabe der Datenbank in die Felder aufzunehmen, die für Postfachobjekte angezeigt werden. Sortieren Sie anschließend nach Datenbanken, ist es wesentlich einfacher, eine Gruppe von Postfächern zum Verschieben aus einer Datenbank in eine andere auszuwählen. Sie werden bemerken, dass die Exchange-Verwaltungskonsole nicht die Möglichkeit bietet, Verschiebungen für einen späteren Zeitpunkt festzulegen. Neue Verschiebungsanforderungen werden sofort in die Warteschlange eingereiht und von einer der am Standort laufenden Instanzen des Postfachreplikationsdienst zur Verarbeitung übernommen. (Mithilfe des Cmdlets New-MoveRequest können Sie eine Verschiebungsanforderung in der Exchange-Verwaltungsshell einer bestimmten Instanz des Postfachreplikationsdienstes zuweisen, was in der Exchange-Verwaltungskonsole nicht möglich ist.) Informationen über Verschiebungen, die zurzeit beim Postfachreplikationsdienst registriert sind, erhalten Sie, indem Sie im Knoten Empfängerkonfiguration auf Verschiebungsanforderung klicken (siehe Abbildung 12.4). Die Exchange-Verwaltungskonsole zeigt alle Verschiebungsanforderungen, die in Active Directory für den aktuellen Empfängerbereich der Exchange-Verwaltungskonsole registriert sind. (Standardmäßig ist das die Domäne. Einzelheiten darüber, wie Sie den Empfängerbereich für die Exchange-Verwaltungskonsole festlegen, finden Sie im Abschnitt »Zugriff der Konsole auf die Exchange-Daten« in Kapitel 5). Um die Daten der Verschiebungsanforderung abzurufen, benutzt die Konsole folgenden Befehl: Get-MoveRequest –ResultSize UnLimited
698
Der Postfachreplikationsdienst
Anzeigen von Verschiebungsanforderungen in der Exchange-Verwaltungskonsole
Postfachunterstützungsdienste
Abbildg. 12.4
Insidertipp: Datenzugriff für eine große Anzahl von Verschiebungsanforderungen
Die Angabe –ResultSize Unlimited bedeutet, dass die Exchange-Verwaltungskonsole alle Verschiebungsanforderungen zurückgibt, die sie findet. Möglicherweise müssen Sie eine Weile warten, bis sie die Daten von Active Directory abgerufen hat. Deshalb ist es unter Umständen günstiger, mithilfe der Exchange-Verwaltungsshell auf die Daten für eine bestimmte Gruppe von Postfächern zuzugreifen, wenn zahlreiche Anforderungen vorliegen. In der Exchange-Verwaltungskonsole werden Details einer Anforderung angezeigt, wenn Sie sie in der Liste markieren und dann ihre Eigenschaften einsehen. Dies entspricht der Ausführung des Cmdlets Get-MoveRequestStatistics für ein ausgewähltes Postfach. Für den Umgang mit Verschiebungsanforderungen stehen folgende Optionen zur Verfügung: 쐍 Verschiebungsanforderung anhalten Sie können eine Verschiebungsanforderung jederzeit aussetzen, bevor sie abgeschlossen ist. Die Exchange-Verwaltungskonsole fragt Sie nach einem Grund (aber Sie brauchen keinen anzugeben). Eine angehaltene Verschiebungsanforderung kann später wieder aufgenommen werden. Das entsprechende Cmdlet heißt Suspend-MoveRequest. 쐍 Verschiebungsanforderung entfernen Eine Verschiebungsanforderung lässt sich nur entfernen, wenn ihr Status In Warteschlange eingereiht oder Angehalten lautet. Beim Entfernen der Anforderung wird alles verworfen, was Exchange zur Vorbereitung der Verschiebung getan hat, sodass Sie eine neue Anforderung erstellen müssen, wenn das Postfach später doch verschoben werden soll. Das entsprechende Cmdlet der Exchange-Verwaltungsshell heißt Remove-MoveRequest.
699
Kapitel 12
Postfachunterstützungsdienste
쐍 Verschiebungsanforderung fortsetzen Eine angehaltene Anforderung lässt sich jederzeit wieder aufnehmen. Der Postfachreplikationsdienst beginnt an dem Punkt mit der Verarbeitung des Postfachinhalts, an dem er war, als die Anforderung angehalten wurde. Das entsprechende Cmdlet der Exchange-Verwaltungsshell heißt Resume-MoveRequest. 쐍 Verschiebungsanforderung löschen Sobald eine Verschiebungsanforderung abgeschlossen ist und ihr Status entweder Erledigt oder Mit Fehler abgeschlossen lautet, können Sie sie löschen, um Exchange die Möglichkeit zu geben, eine weitere Verschiebung für das Postfach in den Zeitplan aufzunehmen. (Das Cmdlet löscht das Flag In Transit für das Postfach.) Dieses Thema wird weiter hinten in diesem Abschnitt noch behandelt. Für diese Aktion wird ebenfalls das Cmdlet RemoveMoveRequest eingesetzt. Wenn Sie eine Verschiebungsanforderung auswählen und ihre Eigenschaften anzeigen, haben Sie Zugriff auf drei Registerkarten: 쐍 Allgemein Informationen über die Anforderung. Während die Anforderung verarbeitet wird, sehen Sie eine Anzeige über den Stand der Verschiebung in das neue Postfach sowie Angaben über die Quell- und Zieldatenbank und die Größe des Postfachs (siehe Abbildung 12.5). Beachten Sie das Kontrollkästchen Verschiebung aussetzen, wenn sie für den Abschluss bereit ist. Aktivieren Sie es, überträgt der Postfachreplikationsdienst den gesamten Inhalt des Postfachs aus der Quell- in die Zieldatenbank und hält dann an, damit der Administrator die Verschiebung freigeben und dem Postfachreplikationsdienst die abschließende inkrementelle Synchronisierung und die Aktualisierung von Active Directory erlauben kann, um den Vorgang endgültig zu beenden. Diese Option können Sie nutzen, um Verschiebungen abzuschließen, wenn die Benutzer offline sind, beispielsweise am Abend. Am folgenden Tag können Sie die Benutzer informieren, was sie zur Anpassung der Clienteinstellungen unternehmen müssen, um wieder Verbindung zu dem verschobenen Postfach zu erhalten. Abbildg. 12.5
700
Allgemeine Informationen über eine Verschiebungsanforderung
쐍 Details Hier finden Sie die Namen der Server, auf denen die Quell- und die Zieldatenbank untergebracht sind, sowie deren Exchange-Versionen, außerdem den Zeitpunkt, zu dem die Anforderung in die Warteschlange aufgenommen wurde, und denjenigen, zu dem der Postfachreplikationsdienst die Verarbeitung aufgenommen (und ggf. abgeschlossen) hat (jeweils Datum und Uhrzeit). 쐍 Protokoll Der Postfachreplikationsdienst führt ein vollständiges Protokoll der gesamten Verarbeitungsvorgänge zum Verschieben eines Postfachs in eine neue Datenbank, auf das Sie mit einem Klick auf Anzeigen zugreifen können. Wie Sie in Abbildung 12.6 sehen, wird das Protokoll dann in einem eigenen Fenster geöffnet. Es enthält zahlreiche Informationen, die sehr hilfreich sind, um den Vorgang zu verstehen und auch, um die Ursachen für gescheiterte Verschiebungen zu finden. Mit (Strg) + (C) können Sie das Protokoll in die Zwischenablage kopieren und dann in den Editor von Windows oder einen anderen Texteditor übernehmen, um seinen Inhalt in Ihrer Freizeit zu lesen oder auszudrucken. Diese Funktion wurde in Exchange Server 2010 SP1 in die Exchange-Verwaltungskonsole eingefügt. Wie Sie mit der Exchange-Verwaltungsshell auf die Protokolldaten der Postfachverschiebung zugreifen, können Sie im Abschnitt »Zugriff auf die Protokolldaten des Verschiebeberichts« weiter hinten in diesem Kapitel lesen. Abbildg. 12.6
Das Protokoll der Verschiebungsanforderung
Verschiebungsanforderungen löschen Sie können keine weitere Verschiebungsanforderung für ein Postfach erstellen, bevor Sie alle früheren gelöscht oder abgebrochen haben. Verschieben Sie zum Beispiel ein Postfach von Datenbank 1 in Datenbank 2, nur um festzustellen, dass es in Datenbank 3 gehört, können Sie die Verschiebung abbrechen, wenn sie sich im Status In Warteschlange eingereiht oder Verschieben befindet. Hat die Verschiebung dagegen den Status Wird abgeschlossen erreicht, lässt sie sich nicht mehr abbrechen, weil der Postfachreplikationsdienst den Vorgang jetzt abschließt und Active Directory auf das neue Postfach umstellt. In diesem Fall müssen Sie warten, bis die Verschiebung erledigt ist, und die Anforde-
701
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
rung dann löschen, indem Sie unter dem Knoten Verschiebungsanforderung das Postfach suchen, im Aktionsbereich auf Verschiebungsanforderung löschen klicken und dann eine neue Verschiebungsanforderung von Datenbank 2 nach Datenbank 3 erstellen. Es ist ärgerlich, Anforderungen für erfolgreiche Verschiebungen manuell löschen zu müssen, und Microsoft stellt in einer weiteren Exchange-Version hoffentlich einen automatischen Mechanismus bereit, der dies für abgeschlossene und veraltete Verschiebungsanforderungen erledigt. Außerdem sollten Sie regelmäßig prüfen, ob irgendwo veraltete Anforderungen herumgeistern, und sie löschen, weil sie zu nichts mehr gut sind, nachdem das Postfach erfolgreich in die Zieldatenbank verschoben wurde. Abbildung 12.7 zeigt die Symbole, mit denen die Exchange-Verwaltungskonsole Postfächer mit registrierten Verschiebungsanforderungen kennzeichnet, sowie die Vorgehensweise, um mehrere Anforderungen auf einmal zu löschen. TIPP Sobald eine Verschiebungsanforderung abgeschlossen ist, sollten Sie ihren Status prüfen, um sicher zu sein, dass sie erfolgreich und nicht mit dem Status Mit Fehler abgeschlossen beendet wurde. Verschiebungen mit dem genannten Status sind auf ein Problem gestoßen, das sich möglicherweise auf das Postfach auswirkt. Deshalb sollten Sie einen vollständigen Bericht über die Verschiebung abrufen und die Warnung suchen, die der Postfachreplikationsdienst ausgegeben hat. Wie Sie einen solchen Bericht erstellen, erfahren Sie in Kürze. Abbildg. 12.7
Löschen abgeschlossener Verschiebungsanforderungen
Verschieben von Postfächern mit der ExchangeVerwaltungsshell Mit der Exchange-Verwaltungsshell können Sie Verschiebungsanforderungen gezielter steuern als mit der Exchange-Verwaltungskonsole. Sie ist das bessere Instrument, wenn Sie es mit einer großen Menge von Anforderungen zu tun haben. Beide Werkzeuge verwenden eine neue Gruppe von Cmdlets, die mit dem Postfachreplikationsdienst über den TCP-Port 808 kommunizieren: 702
쐍 New-MoveRequest Dieses Cmdlet startet eine neue Verschiebungsanforderung und führt die Verarbeitung durch, um sicherzustellen, dass ein Postfach vom bestehenden Ort in eine andere Datenbank verschoben werden kann. Die Anforderung beginnt im Status QueuedToMove, durchläuft dann In Progress¸ was bedeutet, dass die Daten vom Quell- ins Zielpostfach repliziert werden, und erreicht schließlich Ready to Complete, sodass Sie sie abschließen können. 쐍 Get-MoveRequest Dieses Cmdlet zeigt aus Active Directory abgerufene Informationen über eine Verschiebungsanforderung an und teilt Ihnen mit, wie sie fortschreitet. 쐍 Remove-MoveRequest Dieses Cmdlet bricht eine Verschiebungsanforderung ab, die in der Warteschlange steht oder im Gang ist. Alle bereits in das Zielpostfach replizierten Daten werden gelöscht. Außerdem wird es benutzt, um eine abgeschlossene Verschiebungsanforderung aus der vom Postfachreplikationsdienst unterhaltenen Liste zu löschen. 쐍 Suspend-MoveRequest Dieses Cmdlet setzt die weitere Verarbeitung einer Verschiebungsanforderung aus, bis sie von einem Administrator freigegeben wird. 쐍 Resume-MoveRequest Dieses Cmdlet nimmt die Verarbeitung einer angehaltenen Verschiebungsanforderung wieder auf, auch solcher, die mit dem Flag SuspendWhenReadytoComplete gekennzeichnet sind und warten. 쐍 Get-MoveRequestStatistics dem Systempostfach ab.
Dieses Cmdlet ruft Daten über Verschiebungsanforderungen aus
Im Verzeichnis Exchange\Scripts finden Sie außerdem das Skript MoveMailbox.ps1, das als Ersatz für das ältere Cmdlet Move-Mailbox in Exchange Server 2007 gedacht ist. Es akzeptiert weitgehend dieselben Parameter wie das Cmdlet und kann deshalb in Situationen eingesetzt werden, in denen Administratoren Code zum Verschieben von Postfächern geschrieben haben. Genau wie das Cmdlet Move-Mailbox fährt das Skript mit der Verarbeitung von Postfächern fort, bis es fertig ist, also ohne Hintergrundverarbeitung. Sie sollten das Skript wie immer sorgfältig testen, bevor Sie es in der Produktion einsetzen. Weitere Informationen
Eine allgemeine Beschreibung des Skripts und der verfügbaren Parameter finden Sie in TechNet unter http://technet.microsoft.com/de-de/library/dd876878.aspx. Um eine Verschiebungsanforderung für ein Postfach zu starten, nennen wir das zu verschiebende Postfach und die Zieldatenbank. In diesem Fall geht es um eine Datenbank in derselben ExchangeOrganisation, sodass der Vorgang als »lokale« Verschiebung gilt. New-MoveRequest -Identity '[email protected]' –TargetDatabase 'DB1'
HINWEIS Geben Sie keine Zieldatenbank an, wählt der Exchange-Code für die automatische Bereitstellung eine der Postfachdatenbanken aus, die für die Bereitstellung vorgesehen sind. In Kapitel 6, »Verwalten von E-Mail-aktivierten Empfängern«, finden Sie weitere Informationen zur Bereitstellung von Datenbanken. New-MoveRequest startet die Anforderung und stellt sie in die Warteschlange. Wie wir wissen, läuft auf jedem Clientzugriffsserver ein Postfachreplikationsdienst. Die Prozesse der Postfachreplikationsdienste auf den Clientzugriffsservern stürzen sich begierig auf neue wartende Verschiebungsanforderungen für Postfächer ihres Active Directory-Standorts und beginnen mit deren Verarbeitung schon
703
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
bald, nachdem sie erstellt wurden. Verschiebungsanforderungen werden auf sämtliche Instanzen des Postfachreplikationsdienstes am Standort verteilt, und ein einzelner Postfachreplikationsdienst behandelt so viele Anforderungen, wie er nach den Grenzwerten in seiner Konfigurationsdatei kann. Insidertipp: Das Kontingent muss für die Zieldatenbank ausreichen
Das alte Cmdlet Move-Mailbox bietet insofern einen Vorteil gegenüber den neuen Cmdlets zum Verschieben von Postfächern, als dass Sie ihm den Parameter –PreserveMailboxSizeLimit übergeben können, damit Exchange die für ein Postfach bestehenden Kontingente respektiert, wenn es verschoben wird. Anders ausgedrückt: Wenn das Postfach in der Quelldatenbank über ein Kontingent von 1 GB verfügt, bekommt es auch in der Zieldatenbank das gleiche Kontingent, selbst wenn das Standardkontingent für Postfächer 100 MB beträgt. Das Cmdlet New-MoveRequest hat keinen Parameter dieser Art, sodass Sie dafür sorgen müssen, dass in der Zieldatenbank ein ausreichendes Kontingent zur Verfügung stehen; andernfalls scheitert die Verschiebungsanforderung. Dazu heben Sie normalerweise die Standardkontingente für die Datenbank an, bevor Sie mit dem Verschieben von Postfächern beginnen, und können danach alle eventuell erforderlichen Anpassungen vornehmen. Manchmal können Sie das Standardkontingent der Datenbank beibehalten, in anderen Fällen setzen Sie möglicherweise bestimmte höhere Kontingente für ausgewählte Postfächer und reduzieren das Standardkontingent der Datenbank für die übrigen Postfächer. Im Rahmen einer Migration auf Exchange Server 2010 werden Postfachverschiebungen häufig in Stapeln zusammengefasst. Mit dem Parameter –BatchName bezeichnen Sie eine Gruppe von Verschiebungsanforderungen, die für denselben Zeitpunkt geplant sind, damit Sie sie später mithilfe des Cmdlets Get-MoveRequest ansehen können: Get-Mailbox –Server 'ExServer1' | New-MoveRequest –TargetDatabase 'DB1' –BatchName 'Transferred Users'
Anschließend können wir den Fortschritt dieser Verschiebungen mit folgendem Befehl verfolgen: Get-MoveRequest –BatchName 'Transferred Users'
Insidertipp: Automatische Vervollständigung von Verschiebungsanforderungen
Sobald der Postfachreplikationsdienst den gesamten Postfachinhalt in die Zieldatenbank verschoben hat, aktualisiert er Active Directory, damit es den neuen Speicherort wiedergibt und den Clientzugriffsserver anweist, alle weiteren Clientverbindungen umzuleiten. Davon ausgenommen sind Verschiebungsanforderungen, die mit dem Parameter –SuspendWhenReadyToComplete erstellt wurden, weil dieser den Postfachreplikationsdienst beauftragt, den Postfachinhalt zu verschieben, den Postfachzeiger in Active Directory jedoch erst umzustellen, wenn dies von einem Administrator autorisiert wurde.
Beibehalten der Postfachsignatur Die Benutzer können weiter online (oder im Exchange-Cache-Modus) arbeiten, während im Hintergrund ihre Postfächer verschoben werden. Nachdem der Postfachreplikationsdienst das Postfach mithilfe inkrementeller Änderungen aktualisiert und auf die neue Datenbank umgestellt hat, wird den Benutzern auf Servern mit Exchange Server 2010 mitgeteilt, dass der Administrator eine Ände-
704
rung vorgenommen hat, die einen Neustart von Outlook erforderlich macht, sobald sie abgeschlossen ist. Der Neustart erlaubt Outlook, seine internen Zeiger anzupassen, die die Daten dem alten Postfach zuordnen und eine Verbindung zum verschobenen Postfach ermöglichen. Benutzer von OWA (Outlook Web Access) bekommen eine Fehlermeldung, wenn sie versuchen, sich während einer Postfachverschiebung anzumelden, aber nur in der Zeit, in der die Verschiebung mit der Aktualisierung der Active Directory-Zeiger abgeschlossen wird. Normalerweise reicht es, wenn der Benutzer etwa eine Minute wartet und dann noch einmal versucht, eine Verbindung herzustellen. Die Unterbrechung des Zugriffs auf ein Benutzerpostfach nach einer Verschiebung stellt eine kurzzeitige, aber erhebliche Irritation dar, die Microsoft in Exchange Server 2010 SP1 beseitigt. Bei der RTM-Version von Exchange muss Outlook gestartet werden, weil es Informationen wie MAPIBezeichner oder -Signaturen, Servernamen und benannte Eigenschaften zwischenspeichert. Exchange Server 2010 verschiebt oder ändert diese Daten nicht automatisch, weshalb der Neustart notwendig ist, damit Outlook und Exchange Dinge untereinander klären und den Client mit dem verschobenen Postfach verbinden können. Alle anderen Benutzer, die Verbindung mit dem verschobenen Postfach aufnehmen, beispielsweise alle, die einen delegierten Zugriff haben oder für die der Kalender freigegeben ist, müssen Outlook ebenfalls neu starten. Microsoft hat den Vorgang der Postfachverschiebung in Exchange Server 2010 SP1 geändert, damit der Postfachreplikationsdienst die MAPI-Signatur und benannte Eigenschaften von der Quell- in die Zieldatenbank kopieren kann. Diese Daten werden zuerst verschoben, danach der Postfachinhalt. Die Änderung reicht aus, um die Notwendigkeit eines Neustarts von Outlook zu beseitigen, weil sämtliche Daten, die der Client benötigt, während der Verschiebung erhalten bleiben. Die Auswirkung dieser Änderung bemerken Sie jedoch nur bei Postfächern, die in SP1-Datenbanken angelegt wurden, sowie nach dem Verschieben von Postfächern von einem RTM-Server in eine Datenbank der neuen Version. Bei der ersten Verschiebung eines Postfachs von der RTM-Version auf einen aktuelleren Server kann die Signatur nicht erhalten bleiben, sodass anschließend ein letzter Neustart von Outlook erforderlich ist. Nachrichteneingang während des Verschiebens
Geht während der Verschiebung eine Nachricht in einem Postfach ein und erzwingt die Weitergabe einer neuen benannten Eigenschaft, dann wird es kompliziert. Eine benannte Eigenschaft ist eine Eigenschaft im Nachrichtenheader, die der Client zwischenspeichert, wenn er den Wert in einen MAPI-Bezeichner übersetzt. Die meisten gängigen Eigenschaften im Header, etwa Betreff und Absender, befinden sich im Zwischenspeicher und werden im ersten Stadium der Verschiebung übertragen. Entdeckt Outlook im Header einer während der Verschiebung eingegangenen Nachricht jedoch eine neue Eigenschaft, die es nicht zwischengespeichert hat, so erstellt es im Zwischenspeicher in der Quelldatenbank eine neue benannte Eigenschaft. Daraus ergibt sich ein Problem, weil die benannten Eigenschaften bereits in die neue Datenbank übertragen wurden (der Bereich der möglichen benannten Eigenschaften ist außerdem zu diesem Zeitpunkt abgeschlossen), sodass die neue in der Zieldatenbank fehlt. Der Postfachreplikationsdienst löst es dadurch, dass er die Verschiebung von vorn beginnt, wenn er eine Änderung in der Zuordnung der benannten Eigenschaften für ein Postfach feststellt. Dadurch ist sichergestellt, dass benannte Eigenschaften erhalten bleiben, auch wenn es Zusatzaufwand für den Neustart der Verschiebung erfordert – der Benutzer braucht dagegen Outlook nicht mehr neu zu starten! Sie können das Cmdlet New-MoveRequest zwingen, zum alten Verhalten zurückzukehren und benannte Eigenschaften beim Verschieben eines Postfachs zu ignorieren. Dazu setzen Sie für die Verschiebungsanforderung den Parameter DoNotPreserveMappingSignature: New-MoveRequest –Identity 'Jeff Smith' –DoNotPreserveMappingSignature –TargetDatabase 'DB1'
705
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
Das klingt ja alles gut, jedoch machte sich sehr spät in der Entwicklung ein Fehler bemerkbar, der Microsoft veranlasste, den Teil des Codes für den Postfachreplikationsdienst zu entfernen, der Postfachsignaturen bewahrt. Deshalb funktioniert Exchange Server 2010 SP1 im Lieferzustand genauso wie die RTM-Version. Microsoft hat vor, das Problem zu beheben und den aktualisierten Code zur Aufrechterhaltung der Postfachsignaturen in eine Rollupaktualisierung für Exchange Server 2010 SP1 aufzunehmen, die verfügbar sein sollte, wenn Sie dieses Buch lesen.
Verschieben von Postfächern von einer ExchangeVersion zu einer anderen Die Cmdlets für Verschiebungsanforderungen lassen sich einsetzen, um Verschiebungsanforderungen zwischen Exchange Server 2010 und Exchange Server 2003 SP2 oder Exchange Server 2007 SP2 durchzuführen. Um ein Postfach zum Beispiel von einem älteren Exchange Server-Computer auf Exchange Server 2010 (in derselben Organisation) zu verlagern, benutzen Sie folgenden Befehl: New-MoveRequest –Identity 'Jeff Smith' –TargetDatabase 'B1' –BadItemLimit 10
Insidertipp: Der Grenzwert für ungültige Elemente
Beachten Sie, dass der Grenzwert für ungültige Elemente (BadItemLimit) in diesem Beispiel bewusst ziemlich hoch gewählt wurde, weil Exchange Server 2010 höhere Ansprüche an das korrekte Format von Elementen stellt als frühere Versionen und Sie in die Situation geraten könne, dass Verschiebungen scheitern, wenn Exchange im Quellpostfach auf dem älteren Server Elemente antrifft, die beschädigt zu sein scheinen. Eine Alternative besteht darin, mit einem niedrigeren Grenzwert zu beginnen (vielleicht 3) und zu akzeptieren, dass ein Administratoreingriff erforderlich ist, wenn die Verschiebung scheitert, weil die Grenze überschritten wurde. Für eine umgekehrte Verschiebung von einem Server mit Exchange Server 2010 auf einen älteren in derselben Organisation verwenden Sie folgenden Befehl: New-MoveRequest –Identity 'Jeff Smith' –TargetDatabase 'Exchange 2007 Mbx'
Sie können auch Verschiebungsanforderungen zwischen Gesamtstrukturen erstellen. Nehmen wir beispielsweise an, Sie legen für Exchange Server 2010 eine neue Gesamtstruktur an und wollen einige Postfächer aus einer älteren Gesamtstruktur herüberziehen, die unter Exchange Server 2003 SP2 oder Exchange Server 2007 läuft. In diesem Fall gibt es in der alten Gesamtstruktur keine Server mit Postfachreplikationsdienst, sodass Exchange Server 2010 die gesamte Arbeit übernehmen muss. Wir können die Verschiebungsanforderung wie folgt formulieren: New-MoveRequest –Identity 'Chris Ashton' –RemoteLegacy –RemoteCredential (Get-Credential) –RemoteGlobalCatalog 'GC1.contoso.com' –TargetDatabase 'Exchange 2010 Mbx'
Dieser Code enthält den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) eines globalen Katalogservers in der anderen Gesamtstruktur, damit Exchange Verbindung zu Active Directory aufnehmen und Informationen über den Server abrufen kann, auf dem sich das Quellpostfach befindet. Außerdem enthält der Befehl den Parameter RemoteLegacy, der dem Postfachreplikationsdienst mitteilt, dass die Verschiebung in einer entfernten Gesamtstruktur ohne Exchange Server
706
2010 beginnt. Sie müssen auch noch Anmeldeinformationen für ein Konto in der entfernten Gesamtstruktur übergeben, das Zugriffsrechte für das Postfach besitzt. Die Informationen lassen sich mithilfe des Cmdlets Get-Credentials ermitteln, das ein Dialogfeld anzeigt, um Informationen über die Domäne, das Konto und das Kennwort zu erheben. Es wird davon ausgegangen, dass in der Exchange Server 2010-Gesamtstruktur ein als Ziel geeignetes Konto (E-Mail-aktivierter Benutzer) besteht. Des weiteren muss eine Reihe von Attributen des Quellpostfachs, darunter msExchMailboxGuid und msExchArchiveGuid (falls Sie ein Postfach aus einer entfernten Exchange Server 2010-Gesamtstruktur verschieben und ein persönliches Archiv haben) mit dem Zielkonto synchronisiert werden. Dazu verwenden Sie ein Dienstprogramm wie GALSync 2007, das Exchange erlaubt, das Postfach an das richtige Ziel zu verschieben. Damit gesamtstrukturübergreifende oder von älteren Exchange-Organisationen ausgehende Verschiebungen erfolgreich verlaufen, sollte der Exchange Server 2010-Computer darüber hinaus in der Lage sein, den NetBIOS-Namen des Quellservers aufzulösen, weil Exchange versucht, die Verbindung zu dem betreffenden Server mithilfe des in seinem Attribut msExchArchiveGuid enthaltenen Namens aufzubauen, der üblicherweise ein NetBIOS-Name ist. HINWEIS Die zur Vorbereitung und Durchführung gesamtstrukturübergreifender Verschiebungen erforderliche Arbeit verdient wahrscheinlich ein eigenes Kapitel, das aber unglücklicherweise nicht in dieses Buch passt. Zu Beginn Ihrer Nachforschungen sollten Sie in TechNet nach weiteren Informationen über die Erfordernisse der Attributsynchronisierung suchen. Dazu gehört auch Code für Microsoft Identity Lifecycle Management FP1, um E-Mail-aktivierte Benutzer in einer Exchange Server 2010-Organisation vorzubereiten, in die Sie Postfächer verschieben wollen. Nehmen wir an, wir wollen ein Postfach zurück zu Exchange Server 2007 verschieben, wobei die andere Gesamtstruktur jedoch Clientzugriffsserver mit Exchange Server 2010 enthält: New-MoveRequest –Identity 'Chris Ashton' -Remote -RemoteTargetDatabase 'Exchange 2007 Mbx' -RemoteHostName 'Exch2010CAS.contoso.com' -RemoteCredential (Get-Credential)
Da in der anderen Organisation ein Clientzugriffsserver mit Exchange Server 2010 zur Verfügung steht, leitet der Postfachreplikationsdienst die Anforderung an diesen weiter, der die Anforderung dann als Stellvertreter verarbeitet. Der wesentliche Unterschied zwischen einer Verschiebungsanforderung mit dem Parameter –Remote und einer für einen älteren Remoteserver, also mit –RemoteLegacy, besteht darin, dass Erstere einen Webdienst mit dem Namen MRSProxy benutzen. Dieser Dienst ähnelt einer Verbindung mit RPC über HTTP, wie sie Outlook für die MAPI-Kommunikation benutzt, da er ebenfalls über eine Internetverknüpfung läuft. MRSProxy ist jedoch in der Lage, sowohl Speicherinhalte als auch Active Directory zu aktualisieren, kann also genau das, was zum Verschieben eines Postfachs erforderlich ist. Verschiebungen auf einen älteren Remoteserver setzen im Vergleich damit direkten MAPI- und LDAP-Zugriff auf die entfernte Gesamtstruktur voraus. Deshalb bestehen für die beiden Fälle unterschiedliche Anforderungen an die Firewall. Sämtliche Verschiebungen zwischen Exchange Server 2010 und älteren Versionen (außer Exchange Server 2007 SP2 und höher) erfolgen offline, sodass der Benutzer erst dann auf sein Postfach zugreifen kann, wenn die Verschiebung abgeschlossen ist. Die Verarbeitung dieser Verschiebungen lässt sich nicht anhalten und wieder aufnehmen, was außerdem bedeutet, dass jeder Fehler, der die Verschiebung unterbricht, Sie zwingt, von vorn anzufangen, anstatt von einem Prüfpunkt aus fortfahren zu können, wie es bei Onlineverschiebungen möglich ist.
707
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
Verschieben von Postfächern mit persönlichen Archiven Die ursprüngliche Version von Exchange Server 2010 speichert ein persönliches Archiv immer in derselben Datenbank wie das Primärpostfach. Exchange Server 2010 SP1 gewährt mehr Flexibilität, da ein persönliches Archiv in einer anderen Datenbank oder in einer Datenbank auf einem Server untergebracht werden darf, der zum Hostingdienst Microsoft Exchange Online gehört. Beim Verschieben eines Postfachs verlagern Sie üblicherweise auch das persönliche Archiv. In Exchange Server 2010 ist das ziemlich unkompliziert, aber die zusätzlichen Möglichkeiten in Exchange Server 2010 SP1 bringen einige Herausforderungen mit sich. Es ist noch recht einfach, wenn Sie nur Postfachserver mit Exchange Server 2010 SP1 in Gebrauch haben, weil Sie sich dann für einen der folgenden Vorgänge entscheiden können: 쐍 Postfach und persönliches Archiv in dieselbe Zieldatenbank verschieben 쐍 Postfach in eine andere Datenbank verschieben, persönliches Archiv an Ort und Stelle belassen 쐍 Persönliches Archiv in eine andere Datenbank verschieben, Postfach an Ort und Stelle belassen HINWEIS Es ist nicht möglich, das Postfach und das dazugehörige persönliche Archiv mit einer einzigen Operation in zwei unterschiedliche Datenbanken zu verschieben (zum Beispiel das Postfach aus der Datenbank DB1 in die Datenbank DB2 und gleichzeitig das Archiv in die Datenbank DB3). Um eine Aufteilung dieser Art durchzuführen, sind zwei Verschiebungsanforderungen notwendig. Abbildung 12.8 zeigt, was Sie sehen, wenn Sie auf einem Server mit Exchange Server 2010 SP1 den Assistenten für neue Verschiebungsanforderungen benutzen. Hier hat die Exchange-Verwaltungskonsole festgestellt, dass zwei der zum Verschieben ausgewählten Postfächer persönliche Archive enthalten, und bietet dem Administrator folgende Optionen an: 쐍 Nur das Postfach verschieben und das persönliche Archiv in der aktuellen Datenbank belassen 쐍 Nur das persönliche Archiv verschieben und das Primärpostfach in der aktuellen Datenbank belassen 쐍 Sowohl das Primärpostfach als auch das persönliche Archiv in eine andere Datenbank verschieben Haben die ausgewählten Postfächer keine persönlichen Archive, zeigt die Exchange-Verwaltungskonsole diese Optionen nicht an, und der Administrator kann nur die Zieldatenbank auswählen. Wollen Sie ein Postfach von einem Postfachserver mit SP1 auf einen mit der RTM-Version von Exchange verschieben, ist es komplizierter. In diesem Fall wird geprüft, ob das persönliche Archiv vom Postfach getrennt ist. Falls ja, dürfen Sie das Postfach erst verschieben, nachdem Sie das Archiv in die Datenbank des Primärpostfachs zurückverlegt haben. Wenn ein Server mit Exchange Server 2010 als Quelle und einer mit Exchange Server 2010 SP1 als Ziel fungiert, sind Sie nicht in der Lage, ein Postfach von seinem Archiv zu trennen und beide in verschiedene Datenbanken zu verlagern, weil die ursprüngliche Version von Exchange Server 2010 ein persönliches Archiv immer zusammen mit seinem Postfach verschiebt. Wollen Sie die beiden trennen, müssen Sie erst beide auf einen Server mit Exchange Server 2010 SP1 verlagern, bevor Sie das
708
Archiv einer anderen Datenbank zuweisen können. Die günstigste Methode zur Vermeidung solcher Probleme besteht natürlich darin, alle Postfachserver mit derselben Softwareversion auszustatten, idealerweise Exchange Server 2010 SP1 (oder höher). Abbildg. 12.8
Die von Exchange Server 2010 SP1 angebotenen Optionen zum Verschieben von Postfächern mit Archiven
Überprüfen des Verschiebestatus von Postfächern Um den Status einer Verschiebungsanforderung zu prüfen, übergeben wir dem Cmdlet Get-MoveRequest den Namen des Postfachs: Get-MoveRequest –Identity '[email protected]'
Wie bereits erwähnt, bleiben Verschiebungsanforderungen nach ihrem Abschluss erhalten. Auf einem stark beschäftigten System, das zahlreiche Postfachverschiebungen durchführt, sollten Sie die Anforderungen deshalb regelmäßig löschen. Eine Möglichkeit besteht darin, Verschiebungsanforderungen für einzelne Postfächer zu löschen, wenn sie erneut verschoben werden sollen. Dazu verwenden Sie einen Befehl folgender Art: Remove-MoveRequest –Identity '[email protected]'
Alternativ können Sie alles mit einem einfachen Onlinebefehl entfernen, der alle abgeschlossenen Anforderungen sucht und die zurückgegebenen Objekte dann löscht: Get-MoveRequest –MoveStatus Completed | Remove-MoveRequest –Confirm $False
709
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
Fehlerbehebung: Ich kann eine Postfachdatenbank nicht entfernen
Exchange lässt Sie eine Postfachdatenbank nicht entfernen, wenn noch Verschiebungsanforderungen dafür vorliegen. Damit wird verhindert, dass eine Datenbank gelöscht wird, solange die Gefahr besteht, dass eine Postfachverschiebung im Gang ist oder eine geplante Verschiebung nicht erfolgreich abgeschlossen wurde und der Aufmerksamkeit des Administrators bedarf. Außerdem wird jede Verschiebungsanforderung mit dem Active Directory-Objekt für die Datenbank verknüpft, die das betreffende Postfach enthält. Wenn eine Datenbank gelöscht werden könnte, während noch Verschiebungsanforderungen vorhanden sind (auch abgeschlossene), würde Exchange die Anforderungen als ungültig betrachten, sodass Sie sie nicht mit dem Cmdlet Remove-MoveRequest entfernen könnten, sondern die zugrunde liegenden Daten aus Active Directory löschen müssten.
Planen der Postfachverschiebung Wir haben bereits erörtert, wie Sie Verschiebungsanforderungen in Stapeln zusammenfassen, die gemeinsam verarbeitet werden können. Es ist allgemein üblich, eine Gruppe von Postfachverschiebungen für die Nachtstunden zu planen, wenn Benutzeraktivität und Netzwerkbelastung gering sind. Sie sollten darauf achten, das Netzwerk nicht mit zahlreichen gleichzeitigen Verschiebungsanforderungen für umfangreiche Postfächer zu überschwemmen, die mit anderen netzwerkintensiven Aktivitäten wie nächtlichen Sicherungen in Konflikt stehen. Außerdem sollten Sie Verschiebungen auf alle verfügbaren Server und Datenbanken verteilen, um das Risiko zu vermeiden, einen Zielserver der Belastung durch mehrere eingehende Verschiebungsanforderungen auszusetzen, die alle erhebliche Prozessor- und E/A-Ansprüche stellen, um die neuen Postfächer zu füllen und Inhaltsindizes zu aktualisieren. Außerdem sind die Grenzwerte zu berücksichtigen, die der Postfachreplikationsdienst für das Verschieben von Informationen in unterschiedliche Postfächer setzt. Wollen Sie zum Beispiel 1000 Postfächer verschieben, um einen Postfachserver vom Netz zu nehmen, verarbeitet der Postfachreplikationsdienst die Verschiebungen schneller, wenn Sie sie auf mehrere Zielserver und -datenbanken verteilen. Wählen Sie im Vergleich dazu eine einzige Postfachdatenbank als Ziel, können Sie die 1000 Anforderungen in eine Warteschlange stellen, aber der Postfachreplikationsdienst verarbeitet jeweils nur fünf, sodass der Vorgang wesentlich länger dauert, als Sie erwarten. VORSICHT Idealerweise sollte kein Server gezwungen werden, mehr als fünf eingehende Verschiebungsanforderungen gleichzeitig zu verarbeiten. Dies gilt auch beim Auslösen mehrerer Verschiebungen in derselben Quelldatenbank. Obwohl sich das Aktivitätsniveau erheblich unterscheidet, weil die Quelldatenbanken Informationen als Stream ausgeben und ihre Inhaltsindizes erst aktualisieren müssen, wenn die Postfächer endgültig übertragen sind, ist es möglich, einen Quellserver mit mehreren Anforderungen zu überlasten. Wiederum ist Mäßigung das beste Verfahren. Sie sollten Verschiebungen so planen, dass eine einzelne Datenbank oder ein einzelner Server weder als Quelle noch als Ziel zum Engpass werden kann. Welche Menge von Postfachdaten sich von einem Server zum anderen verschieben lässt, hängt weitgehend von Ihrer Umgebung ab. Es sind also einige Tests erforderlich, um die optimale Anzahl von Postfachverschiebungen für eine Nacht oder ein Wochenende zu ermitteln. Nachdem der Postfachreplikationsdienst die Verarbeitung beendet hat, können die Administratoren die Ergebnisse der Verschiebeoperationen durchgehen und die erfolgreichen als abgeschlossen markieren.
710
Neue Verschiebungsanforderungen können Sie mit dem Status Angehalten (Suspended) starten. Dazu gibt es zwei Vorgehensweisen: 쐍 Verwenden Sie den Parameter –Suspend. 쐍 Verwenden Sie den Parameter –SuspendWhenReadyToComplete Der erste Parameter weist den Postfachreplikationsdienst an, eine Verschiebungsanforderung im Wartezustand zu erstellen, sonst aber nichts zu tun, bis die Verschiebungsanforderung wieder aufgenommen wird. Dies ist eine gute Methode, mehrere Verschiebungsanforderungen für die Stapelverarbeitung zu verfassen, vielleicht für die Nachtstunden, wenn die Benutzernachfrage gering ist. Der Parameter –SuspendWhenReadyToComplete weist den Postfachreplikationsdienst an, die erste Füllphase durchzuführen und alle aktuellen Informationen vom Quell- ins Zielpostfach zu kopieren. Sobald ein Administrator bereit ist, die Verschiebung abzuschließen, kann er die Verschiebungsanforderung freigeben: New-MoveRequest –Identity 'Tony Redmond' –SuspendWhenReadyToComplete –TargetDatabase 'DB1' Get-MoveRequestStatistics –Identity 'Tony Redmond' | Format-List UserIdentity
: contoso.com/Exchange Users/Tony Redmond
DisplayName
: Tony Redmond
Status
: AutoSuspended
SyncStage
: IncrementalSync
Flags
: IntraOrg, Pull, Suspend, SuspendWhenReadyToComplete
SuspendWhenReadyToComplete
: True
QueuedTimestamp
: 11/17/2010 8:15:26 AM
StartTimestamp
: 11/17/2010 8:15:31 AM
LastUpdateTimestamp
: 11/17/2010 8:16:52 AM
InitialSeedingCompletedTimestamp : 11/17/2010 8:16:42 AM TotalMailboxSize
: 32.27 MB (33,832,672 bytes)
TotalMailboxItemCount
: 130
BytesTransferred
: 33.77 MB (35,411,383 bytes)
PercentComplete
: 95
Message
: Informational: The move request for mailbox c612d271-5618-408a-81ef-50f1b3f9a5f7 is ready to complete and has been automatically suspended because the SuspendWhenReadyToComplete parameter is set to $True.
Der Ausgabe des Cmdlets Get-MoveRequestStatistics können Sie entnehmen, dass die Verschiebung bei angenommenen 95% des Postfachs angehalten wurde (in der Originalversion von Exchange sind es 90%). Die letzten 5% umfassen die inkrementelle Synchronisierung, die das Postfach vollständig aktualisiert, nachdem die Verschiebung mit dem Cmdlet Resume-MoveRequest freigegeben wurde. Resume-MoveRequest –Identity 'John Smith'
711
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
HINWEIS Diese Vorgehensweise ist hilfreich, um eine Reihe von Verschiebungen für die Hintergrundverarbeitung durch den Postfachreplikationsdienst während der Arbeitszeit einzurichten, ohne dass die Benutzer beeinträchtigt werden. Sobald die Benutzernachfrage außerhalb der normalen Arbeitszeit sinkt, können die Verschiebungsanforderungen zum Abschließen freigegeben werden, sodass die Benutzer bei der nächsten Verbindungsaufnahme auf die Postfächer am neuen Ort zugreifen können. Nehmen wir an, Sie haben eine Reihe angehaltener Verschiebungsanforderungen, die jetzt zum Abschließen bereit sind. Um sie freizugeben, verwenden Sie einen Befehl der folgenden Art. Verschiebungsanforderungen, die mit dem Parameter – SuspendWhenReadyToComplete erstellt wurden, gehen nach der ersten Füllphase in den Status AutoSuspended über (entspricht Automatisch angehalten in der Konsole): Get-MoveRequest –MoveStatus 'AutoSuspended' | Resume-MoveRequest
Weitgehend nach demselben Ansatz können Sie wartende Verschiebungsanforderungen anhalten, die im Gang sind, wenn Sie sie aus irgendeinem Grund unterbrechen müssen, etwa um ein Hotfix einzuspielen oder eine geplante Sicherung abzuwarten: Get-MoveRequest –MoveStatus 'Queued' | Suspend-MoveRequest –SuspendComment 'Paused move to allow application of hot fix'
Zur Planung von Verschiebungen können Sie alternativ auch den Postfachreplikationsdienst die Verschiebungsanforderungen anlegen und in die Warteschlange stellen, aber nichts anderes tun lassen, bevor Sie bereit sind fortzufahren. Dies kann sinnvoll sein, wenn Sie eine Reihe von Verschiebungsanforderungen in die Warteschlange stellen wollen, um sie freizugeben, wenn die Systemauslastung niedrig ist. Dazu versehen Sie das Cmdlet New-MoveRequest mit dem Parameter –Suspend: New-MoveRequest –Identity 'Tony Redmond' –TargetDatabase 'DB1' –Suspend
Da Wiederaufnahmen üblicherweise weniger Verarbeitung erfordern als andere Verschiebungsanforderungen, werden sie insofern mit einem gewissen Vorrang behandelt, als der Postfachreplikationsdienst sie vor anderen Anforderungen in der Warteschlange erledigt. Mit dem folgenden Befehl können Sie Informationen über die Verschiebungen abrufen, die gerade ablaufen: Get-MoveRequest –MoveStatus 'InProgress'
Sie können auf dem folgenden Code aufbauen, um Informationen über die Anforderungen an das Cmdlet Get-MoveRequestStatistics zu leiten und festzustellen, welche Clientzugriffsserver die aktuellen Anforderungen verarbeiten. Get-MoveRequest -MoveStatus 'InProgress' | Get-MoveRequestStatistics | Format-List Alias, MoveServerName Alias: Epr MoveServerName: ExServer3.contoso.com
Das Cmdlet Get-MoveRequest ruft Daten über Verschiebungsanforderungen für ein Postfach aus Active Directory ab. Es greift nur auf die kleine Gruppe von Eigenschaften zu, die in einem Postfach zur Beschreibung einer Verschiebungsanforderung unterhalten werden, während der Aufruf von Get-
712
MoveRequestStatistics die Instanz des Postfachreplikationsdienstes abfragt, die für die Verschiebung zuständig ist, um umfassende Daten über den aktuellen Status der Verschiebung zu erhalten, beispielsweise den Prozentsatz der Fertigstellung, die Anzahl der zu verschiebenden Elemente usw. Verschiebungsanforderungen werden in der Zieldatenbank in die Warteschlange eingereiht, und der Postfachreplikationsdienst verarbeitet sie in der Reihenfolge des Eingangs (First In, First Out, FIFO). Mit dem Cmdlet Get-MoveRequestStatistics können Sie die Warteschlange von einer Datenbank aus wie folgt einsehen: Get-MoveRequestStatistics -MoveRequestQueue –Database 'DB1'
Abgebrochene Verschiebungsanforderungen
Die von Get-MoveRequestStatistics ausgegebenen Daten enthalten auch alle aufgegebenen oder abgebrochenen Verschiebungsanforderungen, die das Cmdlet in der angegebenen Datenbank findet. Es handelt sich dabei um Anforderungen, zu denen es aus irgendeinem Grund keine passenden Active Directory-Informationen gibt. Der Postfachreplikationsdienst ermittelt abgebrochene Verschiebungsanforderungen und löscht sie, wenn sie älter als 24 Stunden sind. Das Aufschieben der Löschung sorgt dafür, dass es nicht aufgrund von Problemen mit der Active Directory-Replikation zum Abbruch von Verschiebungsanforderungen kommt. Mithilfe des Cmdlets Get-MoveRequest können Sie die aktuellen Verschiebungen untersuchen, die eine Datenbank kennt. Get-MoveRequest –Database 'DB1'
Postfachverschiebungen aus älteren Exchange-Versionen nehmen den Inhalt des Papierkorbs (gelöschte Elemente, die auf den Ablauf ihrer Aufbewahrungsfrist warten) nicht mit den Postfächern mit. Verschieben Sie ein Postfach aus Exchange Server 2007 nach Exchange Server 2010, kommt kein Papierkorbinhalt mit, und das neue Postfach startet mit einem leeren Papierkorb. Exchange Server 2010 verfolgt einen anderen Ansatz, da es bei Verschiebungen zwischen Servern mit Exchange Server 2010 und von der neuen Version auf ältere Server den Papierkorb zusammen mit den Postfächern überträgt, um gesetzlichen Anforderungen an die Aufbewahrung nachzukommen. Ältere ExchangeVersionen wissen nichts über den von Exchange Server 2010 verwendeten erweiterten Papierkorb und können nicht darauf zugreifen. Verschieben Sie ein Postfach jedoch anschließend zurück auf einen Server mit Exchange Server 2010, wird der erweiterte Papierkorbinhalt wieder zugänglich. Wegen derselben gesetzlich vorgeschriebenen Aufbewahrung kann Exchange Server 2010 auch persönliche Archive und den Inhalt ihres Papierkorbs zusammen mit den Primärpostfächern verschieben. Natürlich besteht die Natur von Archiven darin, dass sie wahrscheinlich größer sind als die mit ihnen verknüpften Primärpostfächer. Wenn Sie Exchange-Archivpostfächer verwenden und die Benutzer durch Aufbewahrungsrichtlinien oder manuell zwingen, Elemente ins Archiv zu verschieben, müssen Sie davon ausgehen, dass Postfachverschiebungen länger dauern. Eine Verschiebungsanforderung kann mithilfe des Cmdlets Remove-MoveRequest vor ihrem Eintritt in den Status CompletionInProgress (Wird abgeschlossen) jederzeit abgebrochen werden. Dabei beendet Exchange die Übertragung von Inhalten in das Zielpostfach und löscht es dann. Die bereits übertragenen Inhalte werden sofort aus der Zieldatenbank entfernt. Das Quellpostfach wird durch das Löschen der Verschiebungsanforderung »entsperrt« und kehrt in seinen ursprünglichen Zustand zurück. Der Benutzer kann es weiter so verwenden wie zuvor. Müssen Sie das Postfach erneut verschieben, müssen Sie von vorn anfangen und können nicht an einem schon erreichten Punkt einsetzen.
713
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
Unterschiedliches Tempo beim Verschieben von Postfächern
Das Tempo von Postfachverschiebungen hängt von der Konfiguration und der Auslastung des Systems ab. Der Prozessor kann aufgrund der Art, wie Postfachdaten beim Eintreffen auf dem Zielserver indiziert werden, ein echter Engpass sein. Es besteht kein Zweifel daran, dass ein nur leicht belasteter Server mit einem schnellen Speicherteilsystem und mehreren Prozessoren Verschiebungen schneller verarbeitet als ein stark belasteter Server auf einer virtualisierten Plattform. Mehrere gleichzeitige Verschiebungen in dieselbe Postfachdatenbank schränken den Durchsatz ebenfalls ein. Aktuelle Erfahrungen deuten darauf hin, dass es am günstigsten ist, fünf bis zehn gleichzeitige Verschiebungen pro Zielserver vorzusehen und diese auf mehrere Datenbanken auf unterschiedlichen Festplatten zu verteilen. Sie können davon ausgehen, dass pro Stunde 4 bis 6 GB Postfachdaten verarbeitet werden, sodass es realistisch ist, für ein Postfach von 2 GB 15 bis 30 Minuten Verarbeitungszeit vorzusehen. Die wesentlichen Leistungssteigerungen beim Verschieben von Postfächern gehen auf die Änderungen am Exchange Server 2010-Informationsspeicher zurück, zum Beispiel auf die geringeren E/A-Ansprüche. Im Vergleich dazu verarbeitet Exchange Server 2007 Postfachverschiebungen üblicherweise mit 600 bis 800 MB pro Stunde.
Gewährleisten der Hochverfügbarkeit Postfachverschiebungen innerhalb einer Datenbankverfügbarkeitsgruppe müssen die Replikationsaktivitäten berücksichtigen, die die Grundlage für die Hochverfügbarkeitsfunktion dieser Gruppe bilden. Exchange Server 2010 SP1 enthält zwei Verbesserungen, um mögliche Datenverluste zu verringern, wenn Postfächer zwischen replizierten Datenbanken auf Mitgliedern von Hochverfügbarkeitsgruppen verschoben werden. 1. An bestimmten Punkten während der Postfachverschiebung – unter anderem am Ende des Vor-
gangs, bevor Active Directory auf den neuen Speicherort des Postfachs umgestellt wird – fragt der Postfachreplikationsdienst Active Manager ab, um zu ermitteln, ob sich die Replikation der Transaktionsprotokolle für die Postfachdatenbank und ihre passiven Kopien in einem fehlerfreien Zustand befindet. Was der Postfachreplikationsdienst dann unternimmt, hängt vom Wert der Eigenschaft DataMoveReplicationConstraint der Zielpostfachdatenbank ab (den Sie mithilfe des Cmdlets Set-MailboxDatabase festlegen können). Folgende Werte kommen zur Anwendung: 왍 None: Die Verschiebeoperation läuft weiter, als wäre die Zieldatenbank eigenständig (nicht repliziert), und Active Manager wird nicht über den Replikationsstatus befragt. 왍 SecondCopy: Wird die Datenbank repliziert, muss mindestens eine der passiven Kopien alle Änderungen synchronisiert haben, die vorgenommen wurden, um das Postfach auf den aktuellen Stand zu bringen. Dies ist die Standardaktion, wenn der Wert von DataMoveReplicationConstraint nicht gesetzt ist. 왍 SecondDatacenter: Wird die Datenbank auf einen zweiten Active Directory-Standort repliziert, muss mindestens eine der passiven Kopien am anderen Standort die Änderungen repliziert haben. 왍 AllDatacenters: Wird die Datenbank auf mehrere Active Directory-Standorte repliziert, muss mindestens eine der passiven Kopien an jedem Standort die Änderungen repliziert haben. 왍 AllCopies: Wird die Datenbank repliziert, müssen alle passiven Kopien die Änderungen repliziert haben.
714
Bestätigt Active Manager, dass die Replikation der neuen Postfachdaten fehlerfrei ist und die für die Datenbank gesetzte Einschränkung erfüllt, fährt der Postfachreplikationsdienst mit dem Verschieben des Postfachs fort. Diese Prüfung erfolgt während der für das Verschieben des Postfachs erforderlichen Zeit. Falls erforderlich, hält der Postfachreplikationsdienst für 30 Sekunden an, um einem belasteten Server die Möglichkeit zu geben, die notwendige Protokollreplikation abzuschließen, und prüft dann, ob die Verschiebung fortgesetzt werden kann. Wird der Vorgang nicht innerhalb von 15 Minuten wieder aufgenommen, lässt der Postfachreplikationsdienst die Verschiebung scheitern. Die Unterbrechung wird im Protokoll der Postfachverschiebung festgehalten, wo Sie Informationen folgender Art finden: 9/9/2010 4:15:57 PM [ExServer2] Move for mailbox '/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Redmond, Tony' is stalled because DataMoveReplicationConstraint is not satisfied for the database 'DB1' (agent MailboxDatabaseReplication). Failure Reason: Database 1ec5194c-90b9-43d8-aae101a5374438f2 does not satisfy constraint SecondCopy. There are no available healthy database copies. Will wait until 9/9/2010 4:30:57 PM. 9/9/2010 4:16:27 PM [ExServer2] Request is no longer stalled and will continue.
Die Einstellung DataMoveReplicationConstraint gilt für jeweils eine Postfachdatenbank und kann offensichtlich für die Datenbanken einer Verfügbarkeitsgruppe unterschiedliche Werte aufweisen. Außerdem nutzt der Postfachreplikationsdienst zwei Einstellungen in seiner Konfigurationsdatei, um zu ermitteln, wie er für alle Datenbanken mit Active Manager zusammenarbeitet. EnableDataGuaranteeCheck steuert, ob der Postfachreplikationsdienst über Active Manager den aktuellen Replikationsstatus für Datenbanken feststellt (Standardwert True), während DataGuaranteeCheckPeriod (Standardwert fünf Minuten, Bereich von 30 Sekunden bis zwei Stunden) bestimmt, wie oft der Postfachreplikationsdienst Daten von Active Manager abruft. EnableDataGuaranteeCheck muss den Wert True haben und die Einschränkung DataMoveReplicationConstraint für eine Postfachdatenbank muss gesetzt sein, damit der Postfachreplikationsdienst und Active Manager zusammenarbeiten, um sicherzustellen, dass Postfachverschiebungen die Hochverfügbarkeitsoperationen nicht stören. 2. In dem unwahrscheinlichen Fall, dass der Zielserver keine neue Protokollgeneration angelegt hat,
weil er auf genügend Daten wartet, um seinen Protokollpuffer zu füllen, zwingt der Postfachreplikationsdienst den Informationsspeicher, das aktuelle Transaktionsprotokoll zu schließen und ein neues zu eröffnen. Diese Aktion führt ihrerseits dazu, dass das gerade geschlossene Transaktionsprotokoll mit den letzten Daten der Postfachverschiebung auf die Server repliziert wird, die Kopien der Zieldatenbank enthalten. Der Postfachreplikationsdienst erzwingt für jede Postfachverschiebung eine neue Protokollgeneration, wenn eine Verschiebungsanforderung länger als eine Minute auf ihren Abschluss wartet. Dadurch wird sichergestellt, dass eine Verschiebung als eindeutige Transaktion behandelt wird. Es sollte äußerst selten vorkommen, dass zwangsweise eine neue Protokollgeneration erstellt wird, weil die normale Verarbeitung auf dem Postfachserver durch Benutzer und Hintergrundvorgänge den 1-MB-Protokollpuffer sehr schnell füllen sollte, nachdem die letzten Daten für das zu verschiebende Postfach eingetroffen sind. Es ist streng genommen nur eine Vorsichtsmaßnahme. Während einer Verschiebung kann es zu einem Datenbankwechsel kommen. In diesem Fall erfährt der Postfachreplikationsdienst von Active Manager, wo sich die aktive Datenbankkopie jetzt befindet, und nimmt erneut Verbindung auf, um mit der Verschiebung fortzufahren. Kommt nicht innerhalb von 30 Minuten keine aktive Kopie der Datenbank online, betrachtet der Postfachreplikationsdienst die Verschiebung als gescheitert, weil die Datenbank nicht erreichbar ist.
715
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
Der Bericht über die Postfachverschiebung Der Bericht über eine Postfachverschiebung in Exchange Server 2010 enthält die Postfachgröße vor und nach der Übertragung. Größenangaben für Postfächer in Exchange Server 2003 schließen den Papierkorb ein, was bei einer Verschiebung von Exchange Server 2003 nach Exchange Server 2010 zu Unterschieden zwischen der von der Verwaltungskonsole und der von der Verschiebungsanforderung gemeldeten Größe führen kann. Die Abweichung schwankt in Abhängigkeit von der Aufbewahrungsfrist für gelöschte Elemente, wobei 10% nicht ungewöhnlich sind. Es kann vorkommen, dass ein von Exchange Server 2003 mit 3 GB angegebenes Postfach nach der Verschiebung in Exchange Server 2010 mit nur noch 2,85 GB gemeldet wird. Exchange Server 2007 scheint Postfachgrößen konsistenter wiederzugeben, sodass bei der Verschiebung von Exchange Server 2007 nach Exchange Server 2010 geringere Unterschiede zu beobachten sind (möglicherweise aufgrund der vorläufig gelöschten Elemente, die der Postfachreplikationsdienst nicht nach Exchange Server 2010 überträgt). Mit dem Cmdlet Get-MoveRequestStatistics können Sie Informationen über aktive Verschiebungsanforderungen anzeigen, während die Daten noch von der Quell- in die Zieldatenbank fließen: Get-MoveRequestStatistics –Identity 'Smith, Jeff' | Select DisplayName, Status, TotalMailboxSize, TotalMailboxItemCount, PercentComplete, BytesTransferred, ItemsTransferred, BytesTransferredPerMinute DisplayName
: Smith, Jeff
Status
: InProgress
TotalMailboxSize
: 379.1 MB (397,473,599 bytes)
TotalMailboxItemCount
: 2837
PercentComplete
: 67
BytesTransferred
: 275.3 MB (288,689,472 bytes)
ItemsTransferred
: 2109
BytesTransferredPerMinute
: 62.06 MB (65,078,175 bytes)
Die von diesem Cmdlet angezeigte Eigenschaft TotalMailboxSize schließt den Inhalt des erweiterten Papierkorbs ein. Diese Größe ist für uns am interessantesten, weil sie bestimmt, wie viel zusätzlicher Speicherplatz in der Zieldatenbank benötigt wird. Außerdem legt sie fest, wie viele Transaktionsprotokolle während der Verschiebung auf dem Zielserver angelegt werden. Sie können davon ausgehen, dass ein Postfach von 200 MB mindestens 200 Transaktionsprotokolle von 1 MB hervorruft. Auf dem Quellserver werden dagegen nicht unmittelbar weitere Transaktionsprotokolle angelegt, weil das alte Postfach im Verlauf der Onlinewartung im Hintergrund entfernt wird und die dazugehörigen Löschoperationen dann zwischen die übrigen Transaktionen eingeflochten werden. Es ist jedoch möglich, dass die Quelldatenbank wächst, während sie Postfächer abgibt. Dies leuchtet nicht unmittelbar ein, lässt sich jedoch leicht erklären: Wenn die Quellpostfächer von Outlook im Exchange-Cache-Modus nicht genutzt wurden, enthalten sie keine Indizes oder Ansichten, wie sie Outlook sonst erstellt, weshalb der Postfachreplikationsdienst gezwungen ist, diese anzulegen, um seine inkrementelle Synchronisierung im letzten Abschnitt der Postfachverschiebung durchzuführen. Je nach verfügbarem Leerraum in der Quelldatenbank kann das Anlegen dieser Ansichten dazu führen, dass die Datenbank größer wird, und außerdem zusätzliche Zugriffe auf dem Quellserver auslösen. Falls es Sie interessiert: Die Verteilung des Speicherplatzes zwischen den Elementen in Ordnern (einschließlich denen in Gelöschte Elemente) und denen im Papierkorb erfahren Sie mithilfe des Cmdlets Get-MailboxStatistics:
716
Get-MailboxStatistics –Identity 'Smith, Jeff' | Select DisplayName, ItemCount, TotalItemSize, DeletedItemCount, TotalDeletedItemSize
Der dargestellte Prozentsatz für den Verlauf der Verschiebung ist eine Schätzung, die nicht auf der Anzahl der Elemente, sondern auf dem Umfang der verschobenen Nachrichten beruht. Die gemeldete Übertragungsgeschwindigkeit (Bytes pro Minute) basiert auf einer im Sekundenabstand genommenen Stichprobe, aus der ein Durchschnittswert über die letzten 20 Sekunden gebildet wird. Nehmen Sie diesen Wert nicht als sehr akkurate Messung der Netzwerkgeschwindigkeit, sondern als groben Anhaltspunkt dafür, wie die Dinge laufen. Nachdem eine Postfachverschiebung abgeschlossen ist, meldet Exchange die Gesamtzahl der verschobenen Elemente, die Größe des verschobenen Postfachs und die Gesamtzahl der übertragenen Bytes. Dieser Wert liegt ausnahmslos höher als die tatsächliche Postfachgröße, weil er einen gewissen mit der Kopie verknüpften Aufschlag für die Übertragung sowie einige Metadaten über das Postfach einschließt, die zusammen mit dem Postfachinhalt übermittelt werden. Fehlerbehebung: Ein Problem ist aufgetreten – was ist geschehen?
Stoßen Sie bei einer Verschiebung auf ein Problem, führen Sie als erste Maßnahme das Cmdlet Get-MoveRequestStatistics mit dem Parameter –IncludeReport aus, um einige Informationen über die Ereignisse während der Verschiebung abzurufen. Dies ist die gängigste Methode, um herauszufinden, welcher Art das Problem ist. Get-MoveRequestStatistics –IncludeReport –Identity '[email protected]'
Zugriff auf die Protokolldaten des Verschiebeberichts Anders als Exchange Server 2007 unterhält Exchange Server 2010 keine eigenen Protokolldateien für Postfachverschiebungen, sondern lässt Sie mithilfe des Cmdlets Get-MailboxStatistics auf diese Daten zugreifen. Das Cmdlet ruft Informationen über Verschiebungsanforderungen für ein bestimmtes Postfach aus Verschiebeberichten ab, die in einem verborgenen Ordner in der untergeordneten Nicht-IPM-Verzeichnisstruktur des Postfachs liegt. Während einer Verschiebung können Sie über die Exchange-Verwaltungskonsole oder die Exchange-Verwaltungsshell auf einen Verschiebebericht zugreifen, um den Fortschritt einzuschätzen, woraufhin Exchange die Daten aus dem Systempostfach der Zieldatenbank (bei Verschiebungen zwischen Servern mit Exchange Server 2010) oder der Quelldatenbank (bei Verschiebungen auf ältere Server) abruft. Sobald eine Verschiebungsanforderung erfolgreich abgeschlossen ist, verlagert der Postfachreplikationsdienst den Verschiebeverlauf vom Systempostfach in das des Benutzers. Standardmäßig werden in jedem Postfach die beiden letzten Verschiebeberichte gespeichert. Falls erforderlich, können Sie diese Anzahl ändern, indem Sie den Wert in der Konfigurationsdatei des Postfachreplikationsdienstes (MSExchangeMailboxReplicationService.exe.config) anpassen, die sich im Exchange-Verzeichnis für Binärdateien befindet. Hier können Sie festlegen, dass der Postfachreplikationsdienst zwischen 0 und 100 Berichte speichert. Denken Sie daran, dass die Konfigurationsdatei jeweils nur für den betreffenden Clientzugriffsserver gilt, sodass Sie diese Änderung auf jedem von ihnen vornehmen müssen, wenn sich alle gleich verhalten sollen. Bevor Sie schnell dafür sorgen, dass Exchange fünf oder sechs Verschiebeberichte speichert, sollten Sie sich klar machen, dass jeder Bericht Platz im Postfach belegt, der auf das Postfachkontingent angerechnet wird. Es kann sich um jeweils 200 bis 300 kB handeln, besonders, wenn während
717
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
der Verschiebung vorübergehende Fehler aufgetreten sind. Ursprünglich erlaubte Microsoft Exchange, pro Postfach zehn Verschiebeberichte abzulegen, senkte die Anzahl jedoch aus genau diesem Grund auf lediglich zwei, weil es Bedenken hinsichtlich des Speicherbedarfs gab. Für eine Postfachverschiebung können Sie zwei Arten von Berichten abrufen. Beide basieren auf den Verlaufsdaten und unterscheiden sich nur in der Menge der enthaltenen Details. 쐍 Die grundlegenden Angaben zum Verlauf erhalten Sie, wenn Sie den Parameter –IncludeMoveHistory übergeben. 쐍 Ein wesentlich ausführlicher Bericht wird mit dem Parameter –IncludeMoveReport erstellt. Die SP1-Version der Exchange-Verwaltungskonsole legt mithilfe dieses Parameters das Verschiebeprotokoll an, das sie anzeigt, wenn ein Administrator die Eigenschaften einer Verschiebungsanforderung abfragt. Die Exchange-Verwaltungskonsole holt die Daten für ein Postfach, das verschoben wird, jedoch aus dem Systempostfach der Zieldatenbank (bei Verschiebungen zwischen Servern mit Exchange Server 2010) bzw. der Quelldatenbank (bei Verschiebungen auf ältere Server) anstatt aus dem Benutzerpostfach. Ist die Verschiebung erfolgreich abgeschlossen, aktualisiert der Postfachreplikationsdienst das Benutzerpostfach mit dem neuesten Verschiebeverlauf. Um die grundlegenden Verlaufsdaten einer Verschiebungsanforderung für ein Postfach einzusehen, können Sie folgenden Code verwenden: Get-MailboxStatistics –Identity '[email protected]' –IncludeMoveHistory
Insidertipp: Ausgeben des Verschiebeberichts in eine Datei
Selbst der einfache Verlaufsbericht enthält eine ziemliche Menge von Informationen, die sich auf dem Bildschirm möglicherweise schwer analysieren lassen. Es ist daher am günstigsten, den Bericht in eine Datei auszugeben, die Sie dann mit einem Texteditor öffnen können. Der folgende Code ruft den Verlauf der letzten Verschiebungsanforderungen eines Postfachs ab und leitet die Ausgabe in eine Textdatei, die Sie dann mit dem Editor öffnen können. $BasicReport = (Get-MailboxStatistics –Identity '[email protected]' –IncludeMoveHistory).MoveHistory $BasicReport[0] | Out-file –FilePath 'c:\Temp\MRS-History.Log' | Notepad 'c:\Temp\MRS-History.Log'
In diesem Zusammenhang bezieht sich [0] auf den ersten (jüngsten) Verlaufsbericht, der im Benutzerpostfach gespeichert ist. Wollen Sie Einzelheiten des zweiten (älteren) Verlaufsberichts sehen, können Sie mit $BasicReport[1] darauf verweisen. Wurde die Konfigurationsdatei für den Postfachreplikationsdienst so geändert, dass er in einem Postfach mehr als zwei Verschiebeberichte ablegen darf, verwenden Sie [2], [3], [4] usw. Erstellen wir nun den vollständigen Verschiebebericht: $FullReport = (Get-MailboxStatistics –Identity '[email protected]' –IncludeMoveReport).MoveHistory $FullReport[0] | Out-file –FilePath 'c:\Temp\MRS-Report.Log' | Notepad 'c:\Temp\MRS-Report.Log'
Oberflächlich betrachtet, scheint Exchange weitgehend dieselbe Datei zu erstellen, aber der Parameter –IncludeMoveReport führt dazu, dass eine Menge zusätzlicher Informationen ausgegeben werden, die Sie genau erkennen lassen, welche Aktionen der Postfachreplikationsdienst durchführt, um ein Postfach zu verschieben.
718
Die folgende Auswahl zeigt einen bearbeiteten Auszug aus einem Postfachbericht. Sie können sehen, wie der Fortschritt der Verschiebung wiedergegeben wird und wie die inkrementelle Synchronisierung am Schluss der ersten Verschiebung abläuft. Weiter vorn im Bericht (hier nicht abgedruckt) finden Sie Details zur Erstellung des verschobenen Postfachs in der Zieldatenbank und weiter hinten, nach den Aktionen zum Durchführen der Verschiebung, sämtliche Active Directory-Eigenschaften für das alte und das verschobene Postfach. Die Active Directory-Daten können bei der Diagnose von Problemen wie fehlerhafter Proxyadressen für das verschobene Postfach von unschätzbarem Wert sein. Außerdem stehen die beteiligten Server sowie die Postfachgröße vor und nach der Verschiebung im Bericht. 5/19/2010 5:41:07 PM [ExServer1] Mailbox Replication Service 'ExServer1.contoso.com' (14.1.160.2 caps:07) is examining request. 5/19/2010 5:41:07 PM [ExServer1] Connected to target mailbox 'Primary (107738a8-b092-409298d7-d375819b9fa1)', database 'DB2', Mailbox server 'EXSERVER1.contoso.com' Version 14.1 (Build 160.0). 5/19/2010 5:41:07 PM [ExServer1] Connected to source mailbox 'Primary (107738a8-b092-409298d7-d375819b9fa1)', database 'DB1', Mailbox server 'EXSERVER1.contoso.com' Version 14.1 (Build 160.0). 5/19/2010 5:41:07 PM [ExServer1] Request processing started. 5/19/2010 5:41:07 PM [ExServer1] Source Mailbox information before the move: Regular Items: 7286, 1018 MB (1,067,144,724 bytes) Regular Deleted Items: 176, 26.99 MB (28,306,004 bytes) FAI Items: 12, 0 B (0 bytes) FAI Deleted Items: 0, 0 B (0 bytes) 5/19/2010 5:41:08 PM [ExServer1] Initializing folder hierarchy in mailbox 'Primary (107738a8-b092-4092-98d7-d375819b9fa1)': 126 folders total. 5/19/2010 5:41:33 PM [ExServer1] Folder hierarchy initialized for mailbox 'Primary (107738a8-b092-4092-98d7-d375819b9fa1)': 126 folders total. 5/19/2010 5:41:33 PM [ExServer1] Stage: CreatingInitialSyncCheckpoint. Percent complete: 15. 5/19/2010 5:41:37 PM [ExServer1] Stage: LoadingMessages. Percent complete: 20. 5/19/2010 5:41:41 PM [ExServer1] Stage: CopyingMessages. Percent complete: 25. 5/19/2010 5:41:41 PM [ExServer1] Copy progress: 0/7476 messages, 0 B (0 bytes)/1.02 GB (1,095,450,728 bytes). 5/19/2010 5:41:42 PM [ExServer1] Messages have been enumerated successfully. 7476 items loaded. Total size: 1.02 GB (1,095,450,728 bytes). 5/19/2010 5:47:00 PM [ExServer1] Stage: CopyingMessages. Percent complete: 42. 5/19/2010 5:47:00 PM [ExServer1] Copy progress: 1987/7476 messages, 260.7 MB (273,347,623 bytes)/1.02 GB (1,095,450,728 bytes). 5/19/2010 5:52:01 PM [ExServer1] Stage: CopyingMessages. Percent complete: 57. 5/19/2010 5:52:01 PM [ExServer1] Copy progress: 4223/7476 messages, 486.3 MB (509,954,232 bytes)/1.02 GB (1,095,450,728 bytes). 5/19/2010 5:57:06 PM [ExServer1] Stage: CopyingMessages. Percent complete: 69. 5/19/2010 5:57:06 PM [ExServer1] Copy progress: 5481/7476 messages, 668.2 MB (700,631,731
719
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
bytes)/1.02 GB (1,095,450,728 bytes). 5/19/2010 6:02:06 PM [ExServer1] Stage: CopyingMessages. Percent complete: 75. 5/19/2010 6:02:06 PM [ExServer1] Copy progress: 5985/7476 messages, 759.9 MB (796,797,286 bytes)/1.02 GB (1,095,450,728 bytes). 5/19/2010 6:09:32 PM [ExServer2] Request processing continued, stage LoadingMessages. 5/19/2010 6:09:34 PM [ExServer2] Stage: CopyingMessages. Percent complete: 77. 5/19/2010 6:09:34 PM [ExServer2] Copy progress: 6122/7476 messages, 776.2 MB (813,954,576 bytes)/1.02 GB (1,095,450,728 bytes). 5/19/2010 6:09:34 PM [ExServer2] Messages have been enumerated successfully. 7476 items loaded. Total size: 1.02 GB (1,095,450,728 bytes). 5/19/2010 6:14:35 PM [ExServer2] Stage: CopyingMessages. Percent complete: 88. 5/19/2010 6:14:35 PM [ExServer2] Copy progress: 7121/7476 messages, 952.6 MB (998,890,105 bytes)/1.02 GB (1,095,450,728 bytes). 5/19/2010 6:16:21 PM [ExServer2] Initial seeding completed, 7476 items copied, total size 1.02 GB (1,095,450,728 bytes). 5/19/2010 6:16:21 PM [ExServer2] Changes reported in source 'Primary (107738a8-b092-409298d7d375819b9fa1)': 0 changed folders, 0 deleted folders, 0 changed messages. 5/19/2010 6:16:21 PM [ExServer2] Incremental Sync 'Primary (107738a8-b092-4092-98d7d375819b9fa1)' completed: 0 changed items. 5/19/2010 6:16:21 PM [ExServer2] Stage: IncrementalSync. Percent complete: 95. 5/19/2010 6:16:21 PM [ExServer2] Final sync has started. 5/19/2010 6:16:21 PM [ExServer2] Changes reported in source 'Primary (107738a8-b092-409298d7d375819b9fa1)': 0 changed folders, 0 deleted folders, 0 changed messages. 5/19/2010 6:16:21 PM [ExServer2] Incremental Sync 'Primary (107738a8-b092-4092-98d7d375819b9fa1)' completed: 0 changed items. 5/19/2010 6:16:35 PM [ExServer2] Stage: FinalIncrementalSync. Percent complete: 95.
Verschieben und Bereitstellen von Postfächern Wenn Sie Postfächer zwischen Active Directory-Gesamtstrukturen verschieben, stellen Sie fest, dass das Cmdlet New-MoveRequest ein vollständig bereitgestelltes Active Directory-Objekt benötigt, mit dem es arbeiten kann. Früher konnten Sie ein Postfach auf einen Server in einer anderen Gesamtstruktur verschieben (zum Beispiel im Rahmen einer Migration von Exchange Server 2003 auf Exchange Server 2007, bei der Sie eine neue Gesamtstruktur für Exchange Server 2007 anlegten), wobei Exchange zuerst das Active Directory-Konto erstellte und anschließend das Postfach verschob und die erforderlichen Attribute aktualisierte, um auf diese Weise ein vollständig bereitgestelltes Benutzerkonto und ein Postfach einzurichten. Stützt sich Ihr Verfahren für die Kontobereitstellung auf diese Funktion, müssen Sie es ändern, um zu gewährleisten, dass das Active Directory-Konto vor dem Versuch eingerichtet wird, ein Postfach zu verschieben. Die Änderung ist erfolgt, weil Microsoft es für zu schwierig hielt, Vorkehrungen für alle möglichen Fälle zu treffen, die bei der Bereitstellung von Konten auftreten können. Die Entwickler hätten weiterhin versuchen können, Code zu schrei720
ben, der all diese Umstände abdeckt, man kam jedoch zu dem Schluss, dass es einfacher und effektiver sei, wenn sich Exchange um das Verschieben von Postfächern kümmert und die Active DirectoryProzeduren um alles andere. Ihre Sache ist es nun zu definieren, wie diese Active Directory-Prozeduren aussehen sollen, damit sie die Bedürfnisse Ihrer Firma erfüllen. Insidertipp: Ein nützliches Skript
Auf der Habenseite bietet Exchange Server 2010 SP1 ein Skript mit dem Namen Prepare-MoveRequest.ps1, das den Prototyp einer Struktur zum Verschieben von Postfächern nach Exchange Server 2010 enthält. Es ist als Ausgangspunkt für den Aufbau der Bereitstellungsverfahren für Ihre Umgebung ein wertvolles Gut.
Beheben von Fehlern bei Verschiebungsanforderungen Standardmäßig toleriert der Postfachreplikationsdienst bis zu 60 Fehler, die ihn zu einem neuen Versuch zwingen, Daten zu kopieren, bevor er eine versuchte Postfachverschiebung aufgibt. Es handelt sich um andere Fehler als diejenigen, für die der Grenzwert für ungültige oder beschädigte Elemente im Quellpostfach angibt, wie viele hingenommen werden, bevor der Postfachreplikationsdienst gezwungen ist, eine Verschiebung scheitern zu lassen. Fehler während der Verschiebung werden nur dann gezählt, wenn sie unmittelbar aufeinander folgen. Gibt es zwischen den Fehlern einen Fortschritt, setzt der Postfachreplikationsdienst die Fehlerzählung zurück und fährt fort. Mithilfe des Cmdlets Resume-MoveRequest können Sie eine abgebrochene Verschiebung wieder aufnehmen, wobei der Postfachreplikationsdienst am Punkt des Abbruchs wieder einsetzt. Die meisten Fehler sind vorübergehender Natur und beruhen auf Bedingungen wie zeitweiligen Netzwerkstörungen zwischen Quell- und Zielserver. Sie können im Ereignisprotokoll nach dem Ereignis 1101 für MSExchange Mailbox Replication suchen, um festzustellen, ob Fehler auftreten (im Verschiebebericht werden auch ungültige Elemente vermerkt). Die gemeldeten Informationen sind nicht sehr hilfreich, können aber auf einen wahrscheinlichen Grund hinweisen. TIPP Sie sollten sowohl auf dem Quell- als auch auf dem Zielserver das Ereignisprotokoll durchgehen. Finden Sie dort Fehler, können Sie die Diagnosestufe für die Postfachreplikation auf Hoch oder Maximum setzen, um den Umfang der Daten im Ereignisprotokoll zu erweitern und zu sehen, ob dies beim Ermitteln des Problems hilft. Jede Verschiebungsanforderung wird mit einem Grenzwert für ungültige Elemente erstellt, die der Postfachreplikationsdienst bei der Verschiebung tolerieren kann. Wie bereits erläutert, beträgt der Standardwert 0, was bedeutet, dass jedes Problem mit einem Element den Postfachreplikationsdienst zwingt, die Verschiebung zu stoppen. In jedem Postfach, dass länger als ein paar Jahre in Gebrauch ist, insbesondere, wenn es in Exchange Server 2000 oder Exchange Server 2003 benutzt oder aus einem fremden E-Mail-System übernommen wurde, können ungültige Elemente lauern. Es ist richtig, dass Sie ein gewisses Potenzial für Datenverluste in Kauf nehmen, wenn Sie dem Postfachreplikationsdienst erlauben, die beschädigten Elemente zu überspringen, aber wenn ein Element beschädigt ist, ist es wahrscheinlich nicht besonders wertvoll oder wurde längere Zeit nicht angefasst (sonst hätte sich der Benutzer beschwert). Außerdem könnte das Postfach in Quarantäne gestellt wird, wenn das beschädigte Element dazu führt, dass der Informationsspeicher exzessiv Ressourcen verbraucht.
721
Postfachunterstützungsdienste
Der Postfachreplikationsdienst
Kapitel 12
Postfachunterstützungsdienste
Wir können anschließend immer den Verschiebebericht durchgehen, um festzustellen, ob in einem Postfach beschädigte Elemente gefunden wurden. Scheitert eine Verschiebung, weil der Schwellenwert für ungültige Elemente überschritten wurde, können Sie sie neu starten, indem Sie mithilfe des Cmdlets Set-MoveRequest einen höheren Grenzwert für ungültige Elemente festlegen: Set-MoveRequest –Identity 'JSmith' –BadItemLimit 100
Der Postfachreplikationsdienst setzt die Verschiebung dann an der Stelle fort, an der sie gescheitert ist, und macht hoffentlich bis zum Abschluss weiter. Weist der Zielserver eine große Zahl von Elementen zurück, besteht eine Lösung darin, die Problemelemente im Verschiebebericht zu ermitteln, sie in einen persönlichen Speicher zu exportieren und dann aus dem Quellpostfach zu löschen. Anschließend können Sie den Rest des Postfachs normal verschieben und später versuchen, die problematischen Elemente aus dem persönlichen Speicher in das neue Postfach zu importieren. Insidertipp: Ein sinnvoller Grenzwert für ungültige Elemente
Den Schwellenwert für ungültige Elemente können Sie aus dem Bereich von -1 bis 2147483647 auswählen. In diesem Fall bedeutet -1, dass es Ihnen egal ist, wie viele beschädigte Elemente der Postfachreplikationsdienst findet. Es ist ziemlich ungünstig, diesen Wert zu wählen, weil es bedeutet, dass eine Verschiebung unabhängig von der Anzahl der offensichtlich ungültigen Elemente erfolgreich sein kann. Wenn ein Postfach zahlreiche ungültige Elemente enthält, ist es jedoch besser, darüber Bescheid zu wissen, und noch besser, den wahrscheinlichen Grund dafür herauszufinden. Angemessener ist es daher, einen sinnvollen Grenzwert zu setzen, etwa 10, und hinterher den Verschiebebericht durchzugehen, um herauszufinden, ob tatsächlich ungültige Elemente gefunden wurden. Denken Sie daran, dass Sie das Problem beim Scheitern einer Verschiebung wegen zu vieler ungültiger Elemente immer untersuchen und dann den Grenzwert erhöhen können, damit der Postfachreplikationsdienst die Verschiebung fortsetzt. Haben Postfächer zahlreiche ungültige Elemente (mehr als etwa fünf), so deutet das darauf hin, dass die Quelldatenbank in der Vergangenheit Probleme aufgewiesen hat, was weitere Untersuchungen erfordert. Wenn Sie wissen, dass eine Datenbank früher Probleme zeigte (normalerweise aufgrund von Hardwareausfällen), und keine zuverlässige Sicherungskopie für eine Wiederherstellung haben, kann es Ihnen natürlich egal sein, wie viele Beschädigungen der Postfachreplikationsdienst findet, solange er es schafft, den Großteil eines Postfachs in eine neue Datenbank zu verschieben. Anders ausgedrückt: Um ein Postfach wiederherzustellen, nehmen Sie einen gewissen Datenverlust in Kauf. Der Fall der fortbestehenden Anforderung
Es ist möglich, dass einige Verschiebungsanforderungen erfolgreich abgeschlossen werden, aber weiterhin fortbestehen. In diesem Fall wird das Postfach aus der Quell- in die Zieldatenbank übertragen, sodass der Benutzer Verbindung mit dem verschobenen Postfach aufnehmen kann, aber die Verschiebungsanforderung bleibt in der Warteschlange. Möglicherweise sehen Sie eine Fehlermeldung wie die folgende im Anwendungsprotokoll. The Mailbox Replication Service was unable to clean up the source mailbox after the move. The error was ignored. Mailbox move: contoso.com/Test/Redmond, Eoin' (Primary (6a144b2e-1b08-412abb1df2410db85c9d)) Database: EXCHSVR2\First Storage Group\Mailbox Database Error: MapiExceptionNotFound: Unable to delete mailbox. (hr=0x8004010f,ec=-2147221233)
722
Import und Export von Postfächern
Die Fehlermeldung besagt, dass Exchange aus irgendeinem Grund nicht in der Lage war, das Quellpostfach zu entfernen. Möglicherweise hat der Quellserver den Befehl zum Löschen des Postfachs nicht ausgeführt, oder es ist ein anderes Problem aufgetreten. Solche Schwierigkeiten kommen bei Verschiebungen von älteren Versionen auf Exchange Server 2010 häufiger vor als zwischen Computern mit Exchange Server 2010. Wenn Sie Verbindung mit der Kopie des Postfachs auf dem Zielserver aufnehmen können und wissen, dass die Verschiebung erfolgreich war, dann können Sie die Verschiebungsanforderung mit dem Cmdlet Remove-MoveRequest oder mit der entsprechenden Option in der Exchange-Verwaltungskonsole aus der Warteschlange entfernen. Die vom Informationsspeicher durchgeführte Hintergrundwartung räumt alles auf, indem sie das jetzt verwaiste Postfach in der Quelldatenbank löscht, nachdem die Aufbewahrungsfrist für gelöschte Postfächer abgelaufen ist. Sie müssen jedoch durch weitere Nachforschungen herausfinden, warum das Problem aufgetreten ist, damit Sie die zugrunde liegenden Schwierigkeiten vor weiteren Verschiebungen beheben können. Ein Postfach in eine Datenbank zu verschieben, von der es nur ein einziges Exemplar gibt, ist ein unkomplizierter Vorgang. Wenn Sie ein Postfach aus einer Datenbank mit mehreren Kopien (in einer Datenbankverfügbarkeitsgruppe) verschieben, wird es komplizierter, weil Exchange dafür sorgen muss, dass eine Wiederherstellung nach einem Fehler möglich ist, der während des Vorgangs in der primären (aktiven) Kopie der Datenbank auftritt. Dazu kopiert der Postfachreplikationsdienst den gesamten Inhalt aus dem Quellpostfach in das neue und überzeugt sich dann, dass mindestens eine der Datenbankkopien fehlerfrei ist (dass also die Einschränkung –DataReplicationConstraint für die Datenbank erfüllt ist), was bedeutet, dass Transaktionsprotokolldateien von weniger als 10 Minuten eingespielt werden müssen und dass die Kopie der Warteschlange weniger als drei Anforderungen umfasst. Probleme in Zieldatenbanken meldet Exchange im Ereignisprotokoll als Fehler. Sie finden dort Hinweise wie »einige Datenbankkopien sind im Rückstand«, sodass sich diese Bedingungen relativ leicht prüfen lassen. Ein fehlerfreier Server, der ordnungsgemäß an der Protokollreplikation teilnimmt, wird keine Schwierigkeiten haben, diese Bedingungen zu erfüllen, weil er Protokolle aus aktiven Datenbanken kopiert und sie fortlaufend in seine Datenbankkopien einspielt. Jede Ansammlung einzuspielender Transaktionsprotokolle oder zu kopierender Protokolle weist auf ein mögliches Replikationsproblem hin oder darauf, dass es auf dem Server zu viele Schreibaktivitäten gibt, um elegant damit fertig zu werden. Sobald der Postfachreplikationsdienst davon überzeugt ist, dass die Datenbanken in Ordnung sind, gibt er die Verschiebung zum Abschluss frei. Diese Verzögerungen aufgrund von Hochverfügbarkeitsfunktionen werden vom Postfachreplikationsdienst als vorübergehende Fehler betrachtet. Wenn dies länger als 30 Minuten dauert, wird die reguläre Fehlerlogik des Postfachreplikationsdienstes gestartet und die Verschiebung wegen zu vieler vorübergehender Fehler als gescheitert markiert. Im Abschnitt »Gewährleisten der Hochverfügbarkeit« weiter vorn in diesem Kapitel finden Sie weitere Informationen zu diesem Thema.
Import und Export von Postfächern In der Zeit direkt nach der Veröffentlichung von Exchange Server 2010 wurde in der ExchangeGemeinde eine Menge heiße Luft darüber produziert, dass es erforderlich sei, eine 64-Bit-Version von Outlook 2010 auf einem Postfachserver mit Exchange Server 2010 zu betreiben, bevor sich Daten
723
Postfachunterstützungsdienste
Der Fall der fortbestehenden Anforderung
Kapitel 12
Postfachunterstützungsdienste
mithilfe der Cmdlets Import-Mailbox und Export-Mailbox in einen persönlichen Speicher (PSTDatei) importieren oder daraus exportieren lassen. Diese Cmdlets wurden in Exchange Server 2007 für die Arbeit mit PST-Daten eingesetzt und sind darauf angewiesen, dass der clientseitige MAPIProvider von Outlook auf Postfächer zugreifen kann. In Exchange Server 2010 SP1 sind die Cmdlets Import-Mailbox und Export-Mailbox jedoch überflüssig, weil sie durch einen neuen Mechanismus für Im- und Exportanforderungen ersetzt wurden, der der Postfachverschiebung nachgebildet ist. Die neuen Cmdlets basieren nicht auf den MAPI-Bibliotheken von Outlook, sondern auf einer Bibliothek von PST-Schreibkomponenten, die von der Exchange-Entwicklungsgruppe stammt. Auf dem Exchange Server-Computer muss kein OutlookCode installiert werden, damit der Im- oder Export in bzw. aus einem persönlichen Speicher möglich ist. Von Exchange Server 2010 SP1 an werden Im- und Exportanforderungen von den neuen Cmdlets erledigt. Sie müssen also alle Skripts ersetzen, die auf den älteren Cmdlets aufbauen, wenn Sie sie auf einem Computer mit Exchange Server 2010 SP1 benutzen wollen. Für Exchange Server 2007 und Exchange 2010 können sie natürlich weiterhin verwendet werden. Anforderungen für den Postfachim- und -export können nur in der Exchange-Verwaltungsshell erstellt werden, weil Microsoft nicht die Zeit hatte, die neuen Cmdlets in die Benutzerschnittstelle der Exchange-Verwaltungskonsole aufzunehmen. Wie Anforderungen zum Verschieben von Postfächern werden auch diejenigen zum Im- und Exportieren zuerst in die Warteschlange gestellt und dann von einer Instanz des Postfachreplikationsdienstes auf einem Clientzugriffsserver des Standorts, an dem sie erstellt wurden, aufgegriffen und asynchron im Hintergrund verarbeitet. Der Postfachreplikationsdienst kann Daten in Postfächer in allen Datenbanken innerhalb seines Standorts importieren oder aus ihnen exportieren. Um Import/ Export-Operationen für Postfächer zu vereinfachen, müssen alle persönlichen Speicher, die der Postfachreplikationsdienst liest oder beschreibt, auf einer Dateifreigabe untergebracht sein, auf die die Clientzugriffsserver zugreifen können. Die Dateifreigaben werden gegen zufälliges Durchsuchen geschützt, indem nur Exchange Trusted Subsystem Zugriff erhält. Wie Abbildung 12.9 zeigt, ist für den Export Schreib-/Lesezugriff erforderlich, für den Import nur Lesezugriff. Alle Exporte erstellen PSTDateien im Unicode-Format. Exchange selbst kann beim Importieren von Daten sowohl das ältere ANSI- als auch das Unicode-Format lesen. Abbildg. 12.9
724
Erlauben des Zugriffs auf die Dateifreigabe für Exchange Trusted Subsystem
HINWEIS Daten aus öffentlichen Ordnern können mit den Import/Export-Cmdlets nicht imoder exportiert werden, sondern müssen ein Postfach durchlaufen, bevor sie verarbeitet werden können. Elemente aus einem öffentlichen Ordner lassen sich in einen persönlichen Speicher kopieren und dann von dort in ein anderes Postfach importieren. Wenn Sie nicht wollen, dass Administratoren ihre Zeit mit dem Im- und Export in bzw. aus Postfächern verbringen, können Sie jederzeit zu der bewährten einfachen Methode zurückkehren und die Benutzer bitten, Daten in und aus ihren Postfächern selbst zu verschieben, indem sie Elemente mit der Maus zwischen persönlichen Speichern und Postfachordnern (oder Ordnern mit persönlichen Archiven) austauschen. Dies ist jedoch nur wirklich erfolgreich, wenn es wenige Elemente gibt, weil die Benutzer schnell genug davon haben, Daten zwischen persönlichem Speicher und Postfach zu verschieben, und die Aufgabe niemals abschließen werden. Dass es nicht mehr notwendig ist, Outlook auf Exchange-Postfachservern zu installieren, ist ein großer Schritt nach vorn. Von noch größerer Bedeutung ist der Umstand, dass der neue Mechanismus für Postfachim- und -exportanforderungen, der mit SP1 eingeführt wurde, weitaus besser funktioniert als die früheren Cmdlets. Trotzdem erfordern Im- und Exportaufgaben immer noch umfangreiche Administratoreingriffe. Neben der Verlegung des Zugriffspunkts für Im- und Exportoperationen vom Postfach- auf den Clientzugriffsserver hat Microsoft im Oktober 2009 angekündigt, das interne Format der PST-Dateien zum ersten Mal zu dokumentieren. Anschließend wurden ein PST-Entwicklungskit und eine Dokumentation veröffentlicht, damit Dritte Dienstprogramme schreiben können, die auf dem PST-Format basieren. Dieser Schritt weckt berechtigte Hoffnungen darauf, dass es bald weitere Dienstprogramme gibt, die den Import von PST-Daten in Exchange automatisieren und rationalisieren. Weitere Informationen
Das PST-Entwicklungskit und die Dokumentation finden Sie unter http://www.microsoft.com/ presspass/press/2010/may10/05-24PSTToolsPR.mspx.
Berechtigungen für den Import und Export von Postfächern über die rollenbasierte Zugriffssteuerung Bevor Sie Daten in ein Postfach im- oder exportieren können, muss Ihr Konto die Rolle Mailbox Import Export haben. Sie wird nicht standardmäßig zugewiesen, noch nicht einmal Konten, die zur Rollengruppe Organization Management gehören. Um den Benutzern oder Gruppen, die diese Aktionen durchführen sollen, diese Rolle zuzuweisen, ist daher gezieltes Handeln des Administrators erforderlich. Dahinter steht die Überlegung, dass der Zugriff auf Postfächer die Privatsphäre berührt und auf Benutzer beschränkt werden sollte, die wirklich die Berechtigung brauchen, Daten ins Postfach einer anderen Person zu importieren oder daraus zu exportieren. Mitglieder der Rollengruppe Organization Management haben diese Rolle zwar nicht standardmäßig, können sie aber an Benutzer delegieren, sich selbst eingeschlossen. TIPP Wie in vielen anderen Fällen, in denen Sie eine Rolle delegieren müssen, damit jemand eine Aufgabe ausführen kann, ist es normalerweise besser, sie einer Gruppe zuzuweisen und anschließend die Gruppenmitgliedschaft zu bearbeiten, sodass die Benutzer die Rolle zusammen mit der Gruppenmitgliedschaft erwerben oder verlieren.
725
Postfachunterstützungsdienste
Import und Export von Postfächern
Kapitel 12
Postfachunterstützungsdienste
Mit einem Befehl wie dem folgenden können Sie einer Gruppe die Rolle zuweisen: New-ManagementRoleAssignment –Group 'Admins for Mailbox Import Export' –Role 'Mailbox Import Export'
Wenn ein Mitglied der Gruppe das nächste Mal eine Sitzung der Exchange-Verwaltungsshell startet, informiert die rollenbasierte Zugriffssteuerung Exchange, dass der betreffende Benutzer die Berechtigung hat, die Import/Export-Cmdlets zu benutzen. Die Cmdlets werden dann in den Befehlssatz geladen, der dem Benutzer während der Sitzung zur Verfügung steht. Die verwendeten Cmdlets sind in Tabelle 12.2 beschrieben. Tabelle 12.2
Cmdlets für den Import und Export von Postfächern Version
Cmdlet
Zweck
Exchange Server 2010
Import-Mailbox
Postfachdaten aus einer PST-Datei importieren
Export-Mailbox
Postfachdaten in eine PST-Datei exportieren
New-MailboxImportRequest
Eine neue Postfachimportanforderung für die Verarbeitung durch den Postfachreplikationsdienst erstellen
Set-MailboxImportRequest
Eigenschaften einer Postfachimportanforderung festlegen
Get-MailboxImportRequest
Den aktuellen Status einer Postfachimportanforderung abrufen
Remove-MailboxImportRequest
Eine Postfachimportanforderung löschen
Get-MailboxImportRequestStatistics
Ausführliche Informationen über eine Postfachimportanforderung ausgeben
Suspend-MailboxImportRequest
Einen Import aus einer PST-Datei anhalten
Resume-MailboxImportRequest
Einen angehaltenen Import wieder aufnehmen
New-MailboxExportRequest
Eine neue Postfachexportanforderung erstellen
Set-MailboxExportRequest
Die Eigenschaften einer Postfachexportanforderung festlegen
Get-MailboxExportRequest
Den aktuellen Status einer Postfachexportanforderung abrufen
Get-MailboxExportRequestStatistics
Ausführliche Informationen über eine Postfachexportanforderung ausgeben
Remove-MailboxExportRequest
Eine Postfachexportanforderung löschen
Suspend-MailboxExportRequest
Einen Export in eine PST-Datei anhalten
Resume-MailboxExportRequest
Einen angehaltenen Export wieder aufnehmen
Exchange Server 2010 SP1
726
Import und Export von Postfächern
Bevor wir Daten importieren, müssen wir überlegen, wie wir vorgehen. Wir stehen vor folgenden offensichtlichen Herausforderungen: 쐍 Möglicherweise müssen Postfachkontingente erhöht werden, damit die PST-Daten in das Primärpostfach importiert werden können. Dies kann dauerhaft erfolgen oder wieder reduziert werden, nachdem ein Teil oder alle Daten in das persönliche Archiv des Benutzers verlagert wurden. Das Heraufsetzen des Kontingents vor dem Import lässt sich relativ einfach als Skript formulieren, ist aber bezeichnend für den manuellen Charakter der Vorgänge für PST-Importe. Die Größe eines persönlichen Speichers auf der Festplatte ist nicht identisch mit der Datenmenge, die in das Postfach importiert wird. Die Struktur der PST-Datei erfordert einen Aufschlag von schätzungsweise 20% auf den zum Speichern der Elemente in einem Onlinepostfach oder -archiv erforderlichen Platz. Selbst wenn Sie diesen Aufschlag abziehen, ist es noch wichtig, auf ausreichende Kontingente in den Zielpostfächern zu achten, bevor Sie mit dem Datenimport beginnen. 쐍 Für jedes importierte Element wird eine Transaktion erstellt, die in einem Protokoll aufgezeichnet werden muss. Die E/A-Aktivitäten erreichen während des Imports eine Spitze, wenn die Zielpostfachdatenbanken Transaktionen übernehmen und sich ausdehnen, um sich an die nun durch die PST-Daten aufgeblähten Postfächer anzupassen. Noch mehr Ein-/Ausgaben gibt es, wenn Sie anschließend Informationen in persönliche Archive verschieben. 쐍 Findet dieser Import innerhalb einer Datenbankverfügbarkeitsgruppe statt, lassen sich auf Servern, die Datenbankkopien beherbergen, aufgrund von Replikations-, Wiedergabe- und Indizierungsaktivitäten ähnliche E/A-Spitzen beobachten. Dies birgt Potenzial für einen E/A-Tsunami. Die gleichen Transaktions- und E/A-Spitzen treten auf, wenn die Daten in die Archivpostfächer verlegt werden. 쐍 Postfachdaten werden aus persönlichen Speichern importiert, die auf Dateifreigaben untergebracht sind. Dateifreigaben werden benutzt, weil Sie nicht wissen, welcher Clientzugriffsserver des Standorts die Im- oder Exportanforderungen verarbeitet (es sei denn, es gibt nur einen), und deshalb den Zugriff auf die Daten an einem Ort ermöglichen müssen, der für alle Clientzugriffsserver erreichbar ist. Schützen Sie die Daten gegen zufälliges Durchsuchen, indem Sie nur Exchange Trusted Subsystem Zugriff gewähren, und richten Sie die Dateifreigabe auf der schnellsten Festplatte ein, die Sie verfügbar machen können, um sicherzustellen, dass die Operationen so rasch wie möglich ablaufen. 쐍 Es ist schwer vorauszusehen, wie rationell Exchange gleichzeitige Importvorgänge durchführen kann. Deshalb ist es häufig günstig, Importe für einen Zeitpunkt zu planen, zu dem sie die normale tägliche Benutzeraktivität nicht beeinträchtigen. 쐍 Mit welcher Geschwindigkeit Exchange Postfachim- und -exporte bewältigt, ist von Server zu Server unterschiedlich und hängt weitgehend von der aktuellen Belastung und der Fähigkeit des Systems ab (wobei natürlich der Plattendurchsatz wichtig ist). Ein Beispiel: Der Import eines persönlichen Speichers von 1,35 GB mit 7450 Elementen beschäftigt einen Server mit mäßiger Belastung 15 Minuten lang. Ein leistungsfähigerer Server oder die Verlegung der Importvorgänge auf Zeiten geringer Benutzernachfrage erhöht den Durchsatz. Die meisten Server sollten in der Lage sein, 8 GB pro Stunde zu importieren. 쐍 Der Postfachreplikationsdienst legt die maximale Größe von Elementen, die in ein Postfach importiert werden, mithilfe der Konfigurationseinstellung MaxSendSize fest. Der Standardwert liegt bei 10 MB. Wollen Sie größere Elemente importieren, müssen Sie die Einstellung hochsetzen: Set-TransportConfig –MaxSendSize 20MB 727
Postfachunterstützungsdienste
Planen des Imports von PST-Daten
Kapitel 12
Postfachunterstützungsdienste
Achten Sie darauf, dass Sie alle Kennwörter für die persönlichen Speicher entfernen, aus denen Sie Daten importieren wollen. Es gibt nämlich keine Möglichkeit, den Cmdlets Kennwörter zu übergeben. Ebenso können Sie kein Kennwort für einen persönlichen Speicher einrichten, wenn Sie ihn während des Postfachexports anlegen. Deshalb sind Maßnahmen zum Schutz der PST-Informationen auf der Dateifreigabe erforderlich, damit die Dateien nicht von unbefugten Clients geöffnet werden können. Denken Sie daran: Anders als bei OST-Dateien, die nur geöffnet werden können, wenn der Client das zugehörige Postfach kennt, kann jeder MAPI-Client eine PST-Datei öffnen. Außerdem garantiert ein Kennwort für einen persönlichen Speicher nicht dessen Sicherheit, weil es im Internet viele Werkzeuge gibt, die es in Sekundenschnelle knacken können. Zur Planung vor dem Start des Imports gehört es auch, dass Sie sich klar machen, um wie viele Daten es eigentlich geht, weil Sie damit folgende Dinge abschätzen können: 쐍 Wie groß sind die Postfachdatenbanken nach dem Import der persönlichen Speicher sind? 쐍 Welche Kontingente müssen Sie für primäre und Archivpostfächer festlegen, um den Import zu ermöglichen? Insidertipp: Nicht alle Informationen über PSTs sind verfügbar und zuverlässig
Das Zusammentragen dieser Informationen ist eine Herausforderung, weil Sie sich darauf verlassen müssen, dass die Benutzer Ihnen Details wie Anzahl und Größe der persönlichen Speicher mitteilen, die sie in Gebrauch haben. Diese Informationen lassen sich schwer abfragen, weil sich die persönlichen Speicher häufig auf Festplatten in Arbeitsstationen oder Laptops befinden, die möglicherweise noch nicht einmal an das Firmennetzwerk angeschlossen und daher für zentrale Werkzeuge nicht zugänglich sind. Laptops, die nur sporadisch mit dem Firmen-LAN verbunden sind, wenn sich reisende Mitarbeiter gerade im Büro aufhalten, können beispielsweise Mengen von PSTDaten enthalten, die für die Administratoren nicht sichtbar sind. Des weiteren ist die Frage zu bedenken, welche Daten in Onlinepostfächer oder persönliche Archive importiert werden sollen. Möglicherweise wollen Sie nicht alles importieren, was in den persönlichen Speichern der Benutzer steht, weil ein Teil davon privat ist und nicht den Datenaufbewahrungsrichtlinien der Firma unterliegt. Manche Daten sind vielleicht auch einfach zu alt, um sich Gedanken darüber zu machen. Solche Richtlinien verlangen häufig von Angestellten, dass sie Informationen nach einer bestimmten Zeit löschen, wenn sie nicht aus irgend einem Grund aufbewahrt werden müssen, beispielsweise wegen eines schwebenden Gerichtsverfahrens. Eine Bestandsaufnahme der persönlichen Speicher ist also eine gute Gelegenheit, die Benutzer daran zu erinnern, dass sie unerwünschte Informationen aus den Speichern löschen, bevor sie Daten in ein Onlinepostfach importieren. Manche Firmen regen an, alle persönlichen Speicher zu löschen, die älter als zwei oder drei Jahre sind, und setzen dies durch, indem sie Sperren einrichten, die den Outlook-Zugriff auf die Speicher verhindern, nachdem die Datenübertragung abgeschlossen ist. Im Abschnitt »Import in ein persönliches Archiv« weiter hinten in diesem Kapitel können Sie mehr darüber lesen. Microsoft hat kein Programm, das persönliche Speicher auf einem PC sucht und dann in Postfächer importiert, die denselben Namen tragen oder den Direktiven in einer Steuerdatei entsprechen. Vielleicht erkennen Drittanbieter, die bereits Softwarewerkzeuge in diesem Bereich herstellen, die Marktlücke, Firmen bei der Umstellung von persönlichen Speichern auf Onlinearchive zu helfen, und entwickeln Programme, die auf der Grundlage der neuen Import-Export-Cmdlets PST-Daten suchen, melden und migrieren. Obwohl dies eine gute Idee zu sein scheint, importieren Sie am Ende vielleicht eine Riesenmenge Müll in Ihr brandneues Onlinearchiv und müssen sich dann der Aufgabe widmen, diese Daten zu entrümpeln. Sind sie erst im Archiv, ist es unwahrscheinlich, dass die Benut728
zer viel Zeit darauf verwenden, altes und unerwünschtes Material auszusortieren, solange sie nicht dazu gezwungen sind. Möglicherweise erstellen Drittanbieter Programme, die beim Suchen von persönlichen Speichern und Extrahieren von Informationen zum Archivieren eleganter vorgehen.
Importieren von Postfachdaten mit der Exchange-Verwaltungsshell Um eine bessere Vorstellung davon zu entwickeln, was beim Erstellen einer Postfachimportanforderung abläuft, müssen wir uns ansehen, wie dieser Vorgang in der Exchange-Verwaltungsshell gehandhabt wird. Zu Beginn unseres Beispiels können wir mit dem Cmdlet New-MailboxImportRequest eine neue Postfachimportanforderung anlegen: New-MailboxImportRequest –Mailbox JSmith –FilePath '\\Exserver1\Imports \JSmith-Outlook.pst' –Name 'PSTfrom2007' –ConflictResolutionOption KeepLatestItem –BadItemLimit 5
Der Befehl erstellt eine neue Importanforderung für das Postfach JSmith und gibt an, dass sich die PST-Quelldatei auf einer Dateifreigabe auf dem Server ExServer1 befindet. Die Anforderung wird sofort in die Warteschlange aufgenommen und von der ersten Instanz des Postfachreplikationsdienstes am Standort verarbeitet, die die Aufgabe bemerkt (eine bestimmte Instanz lässt sich durch Übergabe ihres vollqualifizierten Domänennamens im Parameter –MRSServer erzwingen). Standardmäßig sucht Exchange nach doppelten Elementen, wenn es Daten in ein Postfach importiert, und legt keine Kopie eines Elements an, wenn es im Zielpostfach bereits vorhanden ist (Duplikate werden anhand der Nachrichtenkennung ermittelt). In diesem Fall legt der Parameter –ConflictResolutionOption fest, dass Exchange die jüngste Version des Elements behalten soll, wenn beim Import ein Duplikat entdeckt wird. Die übrigen Optionen heißen KeepAll (alle Versionen behalten) und KeepSourceItem (die Version aus dem importierten persönlichen Speicher behalten). Sie können auch sehen, dass für die Importanforderung ein eindeutiger Name bereitgestellt wird. Dieser Parameter ist optional; wenn Sie keinen Namen angeben, verwendet Exchange den Standardwert MailboxImport. Erstellen Sie mehrere Importanforderungen für ein Postfach, wählt Exchange Namen wie MailboxImport1, MailboxImport2, MailboxImport3 usw., um die einzelnen Vorgänge eindeutig zu bezeichnen. Der Postfachname und der Anforderungsname werden kombiniert und zum Abrufen von Informationen über die Importanforderung eingesetzt. Insidertipp: Mehrere gleichzeitige Importvorgänge
Die Zuweisung eines eindeutigen Namens zu einer Importanforderung ist wichtig, wenn Sie gleichzeitig mehrere Importvorgänge für dasselbe Postfach ausführen wollen, die jeweils Daten aus einem anderen persönlichen Speicher verarbeiten (gleichzeitige Importvorgänge für denselben Speicher sind nicht möglich). Für diesen Zweck sind die von Exchange vergebenen Standardnamen ideal, aber die Verfolgung des Fortschritts der einzelnen Aufträge und die Behebung möglicher Fehler sind einfacher, wenn Sie aussagekräftigere Namen verwenden, zum Beispiel den Namen der PST-Quelldatei. Sie brauchen nicht alles in einen persönlichen Datenspeicher zu importieren, weil Sie mit den Parametern ExcludeFolders und IncludeFolders genau steuern können, welche Ordner Exchange importiert. Um zum Beispiel nur einige benannte Ordner zu importieren, können wir deren Namen wie folgt übergeben: -IncludeFolders "Project A", "Project B", "Project C"
729
Postfachunterstützungsdienste
Import und Export von Postfächern
Kapitel 12
Postfachunterstützungsdienste
Wollen Sie alle unter einem bestimmten Stammordner liegenden Ordner einschließen, so übergeben Sie dessen Namen folgendermaßen: -IncludeFolders "Projects/*"
Und wenn Sie zu einem tief in der Ordnerhierarchie angesiedelten Ordner wechseln müssen, lautet der Parameter wie folgt: -IncludeFolders "Projects/2010/Secret Project A"
Häufig enthalten persönliche Datenspeicher so genannte verknüpfte Elemente. Dabei handelt es sich um verborgene Elemente, in denen Outlook Daten wie Regeln, Formulare und Ansichten speichert. Exchange importiert sie nur, wenn Sie den Parameter AssociatedMessagesCopyOption auf Copy setzen. Meistens können Sie darauf verzichten, verknüpfte Elemente aus einem persönlichen Datenspeicher zu kopieren, weil sich im Postfach ein entsprechendes verknüpftes Element befindet. Eine Ausnahme ist möglicherweise gegeben, wenn Sie wissen, dass diese Elemente Formulare enthalten, die eine Anwendung benötigt, die im Postfach jedoch fehlen.
Abrufen von Informationen über Importaufträge In den nächsten Beispielen sehen Sie, wie der Name, den Sie der Importanforderung gegeben haben, mit dem Postfachbezeichner kombiniert wird, um Informationen über einen bestimmten Importauftrag abzurufen: Get-MailboxImportRequest –Identity 'JSmith\PSTfrom2007'
Das Cmdlet Get-MailboxImportRequest hat einige Parameter, mit denen Sie den Status verschiedener Auftragsgruppen abrufen können: 쐍 Der Parameter –BatchName ruft Details aller Anforderungen ab, die zu einem benannten Batch gehören. 쐍 Der Parameter –Database ruft Details aller Anforderungen ab, die zu Postfächern in einer benannten Datenbank gehören. 쐍 Der Parameter –Status ruft Details aller Anforderungen mit einem bestimmten Status ab. Die gültigen Statuscodes lauten Completed, InProgress, Queued, CompletedWithWarning, Suspended und Failed. Um den Fortschritt eines Imports zu melden, können Sie mithilfe des Cmdlets Get-MailboxImportRequestStatistics ermitteln, wie viele Daten übertragen wurden. Zunächst sehen Sie, dass der Postfachreplikationsdienst die Ordnerhierarchie im Zielpostfach anlegt, um die importierten Daten aufzunehmen, und beobachten anschließend eine steigende Anzahl übertragener Daten, die der Postfachreplikationsdienst vom persönlichen Speicher in das Postfach verschiebt: Get-MailboxImportRequestStatistics –Identity 'JSmith\PSTfrom2007' | Format-List
Das Cmdlet Get-MailboxImportRequestStatistics gibt eine Menge Informationen aus. Deshalb ist es günstig, die zurückgegebenen Eigenschaften zu beschränken, um nur die wesentlichen Daten des Imports zu sehen. Ich verwende normalerweise die folgenden: Get-MailboxImportRequestStatistics –Identity 'JSmith\PSTfrom2007'| Select Name,Status, StatusDetail, BytesTransferred, ItemsTransferred, EstimatedTransferItemCount,BytesTransferredPerMinute
730
Name
: Import 1
Status
: InProgress
StatusDetail
: CopyingMessages
BytesTransferred
: 191.6 MB (200,929,681 bytes)
ItemsTransferred
: 2346
EstimatedTransferItemCount
: 4233
BytesTransferredPerMinute
: 75.82 MB (79,505,066 bytes)
Postfachunterstützungsdienste
Import und Export von Postfächern
Nach Abschluss des Vorgangs können Sie mit dem Cmdlet Get-MailboxImportRequestStatistics einen Bericht darüber abrufen, was der Postfachreplikationsdienst getan hat, um das Postfach mit Daten aus dem persönlichen Speicher zu füllen: Get-MailboxImportRequestStatistics –Identity 'JSmith\PSTfrom2007' –IncludeReport | Format-List
Der Bericht erscheint auf dem Bildschirm, ist jedoch handlicher und leichter lesbar und enthält wesentlich mehr Informationen, wenn Sie die Ausgabe in eine Textdatei leiten. Er ist in eine Zusammenfassung am Anfang und darauf folgende Informationen über die Verarbeitung jedes einzelnen Ordners aus dem persönlichen Speicher in das Zielpostfach unterteilt. Das folgende Beispiel zeigt eine typische Zusammenfassung eines Postfachimports. Vor allem sehen wir hier die folgenden wichtigen Informationen: 쐍 Den Namen der PST-Quelldatei 쐍 Den Namen des Zielpostfachs sowie der Datenbank, in der es liegt 쐍 Den aktuellen Status des Auftrags (abgeschlossen, ohne Warnung) 쐍 Die Anzahl der bei der Verarbeitung vorgefundenen ungültigen Elemente (drei, unterhalb des Grenzwerts von fünf) 쐍 Die Start- und Endzeit für den Auftrag und den Namen des Postfachreplikationsdienstes, der den Auftrag verarbeitet hat 쐍 Die Gesamtzahl der aus der PST-Datei in das Postfach übertragenen Elemente und ihre Größe 쐍 Eine Angabe, ob Ordner explizit aus- oder eingeschlossen wurden Name
: PSTfrom2007
Status
: Completed
StatusDetail
: Completed
SyncStage
: SyncFinished
Flags
: IntraOrg, Pull
RequestStyle
: IntraOrg
Direction
: Pull
Protect
: False
Suspend
: False
FilePath
: \\exserver1\psts\2007Files.pst
SourceRootFolder
:
SourceVersion
: Version 0.0 (Build 0.0)
TargetAlias
: KAkers
TargetIsArchive
: False 731
Kapitel 12
Postfachunterstützungsdienste
TargetExchangeGuid
: 1647709e-61ac-4447-868a-3c8b3bae9839
TargetRootFolder
:
TargetVersion
: Version 14.1 (Build 160.0)
TargetDatabase
: DB2
TargetMailboxIdentity
: contoso.com/Exchange Users/Smith, John
IncludeFolders
: {}
ExcludeFolders
: {}
ExcludeDumpster
: False
ConflictResolutionOption
: KeepSourceItem
AssociatedMessagesCopyOption
: DoNotCopy
BadItemLimit
: 5
BadItemsEncountered
: 3
QueuedTimestamp
: 07/05/2010 10:22:10
StartTimestamp
: 07/05/2010 10:22:27
LastUpdateTimestamp
: 07/05/2010 10:37:19
CompletionTimestamp
: 07/05/2010 10:37:19
OverallDuration
: 00:15:09
TotalQueuedDuration
: 00:00:14
TotalInProgressDuration
: 00:14:54
MRSServerName
: ExServer1.contoso.com
EstimatedTransferSize
: 793.6 MB (832,132,254 bytes)
EstimatedTransferItemCount
: 7450
BytesTransferred
: 1.059 GB (1,137,129,648 bytes)
ItemsTransferred
: 7381
PercentComplete
: 100
Unser Importauftrag ist auf einige ungültige Elemente gestoßen, die Exchange aus irgendeinem Grund nicht verarbeiten konnte. Sie können beschädigt sein, oder es fehlen Eigenschaften, die Exchange braucht. Details dazu sind im Importbericht festgehalten. Das folgende Beispiel zeigt solche Einzelheiten. Wir sehen, dass es sich um ein ziemlich altes Word-Dokument handelt, das in einem Postfach auf einem Computer mit Exchange 4.0 erstellt wurde, und zwar im August 1996! Abgesehen von seinem Alter gibt es keinen offensichtlichen Grund, warum dieses Element als ungültig erkannt wurde. Um die Frage zu klären, können wir dem Benutzer mitteilen, welche Elemente nicht verarbeitet wurden, und ihn bitten, sie manuell aus dem persönlichen Speicher in das Postfach zu ziehen, wenn er sie behalten möchte. 07/05/2010 10:36:53 [ExServer1] A corrupted item was encountered during the move operation. It wasn't copied to the destination mailbox.
732
Import und Export von Postfächern
<sender>Tony Redmond
Postfachunterstützungsdienste
Wollen Sie einen Importvorgang abbrechen, halten Sie die Importanforderung zunächst an und löschen sie dann: Suspend-Mailbo xImportRequest –Identity 'JSmith\PSTfrom2007' Remove-MailboxImportRequest –Identity 'JSmith\PSTfrom2007'
Insidertipp: Import in ein persönliches Archiv
Enthält ein Postfach ein persönliches Archiv, können Sie PST-Daten direkt dorthin importieren, ohne über das Primärpostfach zu gehen. Diese Funktion ist wichtig, weil das persönliche Archiv der natürliche Speicherort für einen großen Teil der Daten ist, die Benutzer in PST-Dateien ablegen. Um PST-Daten in ein persönliches Archiv zu importieren, müssen Sie den Parameter –IsArchive setzen, während Sie die Importanforderung mit dem Cmdlet New-MailboxImportRequest erstellen: New-MailboxImportRequest –Mailbox 'Tony Redmond' –IsArchive –FilePath '\\ExServer1\ImportData\TR.PST' –Name 'Import-Archive'
Die Importanforderung scheitert, wenn das Postfach kein persönliches Archiv besitzt.
733
Kapitel 12
Postfachunterstützungsdienste
Exportieren von Postfachdaten Es gibt zahlreiche Umstände, die einen Administrator veranlassen, Informationen aus einem Postfach zu exportieren, zum Beispiel, wenn ein Benutzer die Zuständigkeit für ein Projekt auf einen anderen überträgt und ihm alle Informationen darüber zur Verfügung stellen will. Sobald dies über einige wenige Elemente hinausgeht, wäre es zu mühsam und nervtötend, jedes einzelne per E-Mail zu senden, sodass es bequemer ist, eine ganze Gruppe von Elementen in einen persönlichen Speicher zu exportieren. Die Benutzer können Elemente natürlich durch Ziehen und Ablegen in einen persönlichen Speicher verschieben, aber bei einigen hundert Elementen kostet dies ziemlich viel Zeit. Außerdem können weitere Probleme auftreten, wenn sich die beiden Benutzer nicht am selben geografischen Ort befinden. Es ist einfach leichter, wenn ein Administrator (oder noch besser ein Mitarbeiter des internen Supports) die Arbeit von einer zentralen Stelle aus erledigen kann. Ein anderer relativ häufiger Fall besteht darin, dass eine Firma Rechtsanwälten aufgrund einer Vorladung Postfachdaten zur Verfügung stellen muss.
Exportieren von Postfachdaten mit der Exchange-Verwaltungsshell Ein ähnlicher Ansatz wie beim Importieren wird auf Servern mit Exchange Server 2010 SP1 beim Export von Postfachdaten verfolgt, abgesehen davon, dass wir eine andere Gruppe von Cmdlets verwenden. Zunächst erstellen wir mit dem Cmdlet New-MailboxExportRequest eine neue Exportanforderung. Um ein ganzes Postfach in einen persönlichen Speicher zu exportieren, können Sie beispielsweise einen Befehl folgender Art benutzen: New-MailboxExportRequest –Mailbox 'Jeff Smith' –Name 'JSmith Export' –BadItemLimit 5 –ExcludeDumpster:$True –FilePath '\\ExServer1\PST\JSmith.PST'
Dieser Befehl nimmt den gesamten Inhalt des genannten Postfachs und schreibt ihn in einen persönlichen Speicher auf der Dateifreigabe. Der Inhalt der Papierkorbordner ist von diesem Vorgang ausgeschlossen. Ist der persönliche Speicher nicht vorhanden, legt Exchange eine neue Datei an, übergeben Sie jedoch den Namen eines existierenden Speichers, schreibt es die exportierten Daten dort hinein. Die Erfahrung zeigt, dass die Daten beim Export aus Postfächern häufiger als beim Import eines persönlichen Speichers eingeschränkt werden. Exchange stellt eine Reihe von Parametern bereit, mit denen sich steuern lässt, welche Daten in einen persönlichen Speicher exportiert werden: 쐍 Der Parameter SourceRootFolder gibt einen Ordner im Postfach als Ausgangspunkt des Exports an. Wird er nicht übergeben, exportiert Exchange den gesamten Postfachinhalt. Der folgende Befehl exportiert zum Beispiel nur die Elemente, die im Ordner Project Athena und seinen Unterordnern gespeichert sind. Hier ist der Ordner Project Athena ein Unterordner von Projects: New-MailboxExportRequest –SourceRootFolder 'Projects/Project Athena'
쐍 Der Parameter TargetRootFolder gibt einen Stammordner im persönlichen Zielspeicher an, um die aus dem Postfach exportierten Ordner dort anzulegen. 쐍 Der Parameter IncludeFolders nennt einen oder mehrere Ordner, die exportiert werden sollen: New-MailboxExportRequest –IncludeFolders 'Projects', 'Planning/Budgets'
쐍 Der Parameter ExcludeFolders nennt einen oder mehrere Ordner, die vom Export ausgeschlossen werden sollen. 쐍 Der Parameter IsArchive legt fest, dass der Export nicht aus dem Primärpostfach des Benutzers, sondern aus seinem persönlichen Archiv erfolgen soll. 734
Wie bei Importanforderungen können Sie auch den Status einer Exportanforderung verfolgen und Informationen über die Arbeit abrufen, die sie erledigt. Das Cmdlet Get-MailboxExportRequest gibt den aktuellen Status einer Anforderung zurück, sodass Sie den Fortschritt von Queued über InProgress bis Completed (oder Failed, wenn der Postfachreplikationsdienst auf ein Problem trifft) verfolgen können. Mit dem folgenden Befehl rufen wir zum Beispiel den aktuellen Status der Exportanforderung ab, die wir vorhin erstellt haben: Get-MailboxExportRequest –Identity 'Jeff Smith\JSmith Export'
Das Cmdlet Get-MailboxExportRequestStatistics gibt detaillierte Informationen über eine Exportanforderung zurück. Der folgende Befehl ruft zum Beispiel etwas andere Informationen ab als in dem Beispiel für die Importanforderung: Get-MailboxExportRequestStatistics –Identity 'Jeff Smith\JSmith Export' | Select Name, Status, StatusDetail, EstimatedTransferSize, EstimatedTransferItemCount, BytesTransferred, ItemsTransferred, PercentComplete Name
: JSmith Export
Status
: InProgress
StatusDetail
: CopyingMessages
EstimatedTransferSize
: 85.24 MB (89,379,213 bytes)
EstimatedTransferItemCount
: 1091
BytesTransferred
: 34.53 MB (36,207,996 bytes)
ItemsTransferred
: 342
PercentComplete
: 41
Am Schluss des Auftrags können Sie mit dem Parameter –IncludeReport eine komplette Darstellung der Exportoperationen abrufen: Get-MailboxExportRequestStatistics –Identity 'Jeff Smith\JSmith Export' –IncludeReport | Format-List
Wie bei Importanforderungen ist die von Exchange bereitgestellte Menge der Informationen über den Export in einen persönlichen Speicher zu umfangreich für eine komfortable Darstellung auf dem Bildschirm, sodass Sie die Ausgabe dieses Befehls am besten in eine Textdatei umleiten, um sie in Ruhe durchgehen zu können. Wie bei Verschiebungsanforderungen für Postfächer kann es sein, dass Exchange auf ein beschädigtes Element in einem Postfach stößt und dieses nicht in den persönlichen Speicher schreiben kann. Der Parameter –BadItemLimit bestimmt, was dann geschieht. Geben Sie beim Erstellen der Exportanforderung keinen Wert für ihn an, bricht Exchange den Export ab, sobald es ein beschädigtes Element findet. Die Exportanforderung befindet sich danach im Status Failed. Um zu ermitteln, was geschehen ist, erstellen Sie mithilfe des Cmdlets Get-MailboxExportRequestStatistics einen vollständigen Bericht und durchsuchen ihn nach Fehlern wie: »A bad item was encountered during the move operation.« Dadurch erfahren Sie genau, welches Element zu dem Problem geführt hat. Sie können es dann aus dem Quellpostfach löschen oder dort lassen und den Export an der Fehlerstelle fortsetzen. Dazu setzen Sie zuerst eine höhere Toleranzschwelle für beschädigte Elemente und nehmen dann die Exportanforderung wieder auf: Set-MailboxExportRequest -Identity 'Jeff Smith\JSmith Export' –BadItemLimit 10 Resume-MailboxExportRequest –Identity 'Jeff Smith\JSmith Export'
735
Postfachunterstützungsdienste
Import und Export von Postfächern
Kapitel 12
Postfachunterstützungsdienste
Beschränken des Benutzerzugriffs auf PSTs Das Verschieben von Daten aus persönlichen Speichern von Benutzern in ein vergrößertes Primärpostfach oder ein persönliches Archiv erfüllt das Geschäftsziel, alle Elemente für die Indizierung verfügbar und in Exchange auffindbar zu machen, stellt jedoch nur eine Teillösung dar. Solange Sie Benutzer nicht daran hindern, weiter Elemente in persönlichen Speichern abzulegen, haben Sie am Ende eine Halb-und-Halb-Situation, in der ein Teil der Daten online und verfügbar ist, ein anderer jedoch unter der Kontrolle der Benutzer verbleibt. Selbst die strengste Firmenanweisung, die Benutzung persönlicher Speicher einzustellen, wird nur von einem Teil der Benutzer befolgt. Andere ignorieren sie einfach oder brauchen etwas Hilfe, um das Richtige zu tun. Mit folgenden Schritten können Sie der Verwendung persönlicher Speicher entgegentreten: 1. Löschen Sie persönliche Speicher oder verlegen Sie sie an einen Ort, an dem sie für Benutzer
unerreichbar sind, nachdem ihr Inhalt in Onlinepostfächer verschoben wurde. 2. Erstellen Sie eine neue Gruppenrichtlinie, die verhindert, dass Benutzer neue Inhalte in beste-
hende persönliche Speicher einfügen. Benutzer sind schnell frustriert, wenn Outlook meldet, dass sie nicht die Berechtigung haben, Elemente in einen persönlichen Speicher zu verschieben, auch nicht in einen neu angelegten. Wie Tabelle 12.3 zeigt, muss die Gruppenrichtlinie einen neuen Unterschlüssel anlegen und seinen Wert auf 1 setzen. 3. Erstellen Sie eine neue Gruppenrichtlinie, um das Menü AutoArchivierung in Outlook zu deaktivieren, und entfernen Sie jede Eingabeaufforderung aus Outlook, die Benutzer veranlasst, Elemente aus ihrem Postfach in einen persönlichen Archivspeicher zu übertragen (stattdessen sollen sie die Daten in ihrem erweiterten Primärpostfach unterbringen oder ein Archivpostfach benutzen). Dazu müssen wir die sechs neuen Unterschlüssel anlegen, die in Tabelle 12.3 aufgeführt sind, und alle Werte auf 1 setzen. 4. Erstellen Sie eine neue Gruppenrichtlinie, die verhindert, dass Benutzer neue persönliche Speicher anlegen können, indem Sie die Option Outlook-Datendateien entfernen. Setzen Sie den Wert für den Unterschlüssel in der Registrierung in diesem Fall für Outlook 2007 auf 5575. 5. Alle diese Unterschlüssel sind DWORD-Werte und gelten für eine bestimmte Outlook-Version. Um den korrekten Wert festzulegen, ersetzen Sie xx für Outlook 2003 durch 11 und für Outlook 2007 durch 12. Weitere Informationen
Weitere Informationen über die Anpassung von Outlook 2007 mithilfe administrativer Vorlagendateien finden Sie unter http://www.microsoft.com/downloads/details.aspx?FamilyID=92d8519ae143-4aee-8f7a-e4bbaeba13e7&displaylang=de. Tabelle 12.3
736
Registrierungswerte zum Steuern des Zugriffs auf persönliche Speicher (Outlook 2003 und Outlook 2007) Funktion
Untergeordneter Registrierungsschlüssel
Verhindern, dass neue Daten in PSTs eingefügt werden
HKCU/Software/Microsoft/Office/xx/Outlook/PST/PstDisableGrow
Archivoption deaktivieren
HKCU/Software/Policies/Microsoft/Office/xx/Outlook/Preferences/ArchiveDelete
Archivoption deaktivieren
HKCU/Software/Policies/Microsoft/Office/xx/Outlook/Preferences/ArchiveMount
Archivoption deaktivieren
HKCU/Software/Policies/Microsoft/Offi ce/xx/Outlook/Preferences/ArchiveOld
Archivoption deaktivieren
HKCU/Software/Policies/Microsoft/Office/xx/Outlook/Preferences/DeleteExpired
Archivoption deaktivieren
HKCU/Software/Policies/Microsoft/Offi ce/xx/Outlook/Preferences/DoAging
E-Mail-Infos und Messgrößen für Gruppen
Registrierungswerte zum Steuern des Zugriffs auf persönliche Speicher (Outlook 2003 und Outlook 2007) Funktion
Untergeordneter Registrierungsschlüssel
Archivoption deaktivieren
HKCU/Software/Policies/Microsoft/Office/xx/Outlook/Preferences/ PromptForAging
Option für OutlookDatendateien deaktivieren
HKCU/Software/Policies/Microsoft/Office/xx/Outlook/DisableCmdBarItemsList/ TCID1
Da Outlook 2010 zusammen mit Exchange Server 2010 entworfen wurde, blockiert es den Zugriff auf persönliche Speicher eleganter. Eine einzige Registrierungseinstellung regelt die Fähigkeit von Benutzern, Daten aus primären oder Archivpostfächern in einen persönlichen Speicher zu verschieben. Legen Sie in HKCU\Software\Microsoft\Office\14.0\Outlook einen neuen mehrteiligen Zeichenfolgenwert namens DisableCrossAccountCopy an. Er enthält die SMTP-Domänennamen der Nachrichten, die Benutzer nicht in einen persönlichen Speicher verschieben dürfen. Sie können die Domäne Ihrer Firma benutzen, damit Outlook verhindert, dass Nachrichten, die mit der Arbeit zu tun haben, in persönliche Speicher gelangen, während der Benutzer Nachrichten, die über einen anderen Dienst eingehen, etwa Hotmail, verschieben darf. Wollen Sie das Verschieben aller Nachrichten unterbinden, die mit irgend einem Konto erstellt wurden, geben Sie ein Sternchen ein (*). Eine geeignete Sperre für das Verschieben von Elementen, die von contoso.com stammen, sehen Sie oben in Abbildung 12.10, die dazugehörige Fehlermeldung unten. Abbildg. 12.10 Outlook 2010 verhindert, dass Benutzer E-Mails aus bestimmten Domänen in persönliche Speicher
verschieben
E-Mail-Infos und Messgrößen für Gruppen Wir kennen alle Erzählungen über einen unglaublichen, aber allzu häufigen Fehler, den wir bei E-Mails gemacht haben. Möglicherweise haben Sie eine Nachricht mit sensiblen oder sonstigen unpassenden Informationen an den falschen Benutzer gesendet, oder Sie haben auf einen Hinweis geantwortet, den Sie als Blindkopie erhielten, was den Absender in Schwierigkeiten brachte, als die anderen Empfänger 737
Postfachunterstützungsdienste
Tabelle 12.3
Kapitel 12
Postfachunterstützungsdienste
erfuhren, dass Sie eine Kopie erhalten haben. Microsoft nennt solche Vorkommnisse »unglückliche Messagingszenarios«, während Administratoren das Ergebnis von Benutzerfehlern, die die Systemleistung beeinträchtigen, E-Mail-Warteschlangen explodieren lassen oder eine große Anzahl von Hilferufen hervorrufen, gern mit härteren Ausdrücken beschreiben. Es ist unglücklich, aber Menschen machen ständig Fehler. Frühe E-Mail-Systeme arbeiteten nach dem einfachen Prinzip »senden und vergessen«. Sie verschickten Nachrichten ins Leere und hofften, dass sie ankämen. Im Lauf der Zeit wurden Funktionen wie Abwesenheitsnotizen, Übermittlungs- und Lesebestätigungen sowie Benachrichtigungen über fehlgeschlagene Übermittlungen hinzugefügt, um die Benutzer zu informieren, was mit ihren Nachrichten nach dem Absenden geschehen ist. Exchange Server 2010 führt mit den Übermittlungsberichten eine Variante dieses Themas ein. Damit können Benutzer den Weg einer Nachricht durch die Exchange-Organisation verfolgen, sogar die Aufgliederung von Verteilergruppen in einzelne Mitglieder, die die Nachricht empfangen haben, sowie die Übermittlung an Server und an externe Connectors zur Übertragung an andere E-Mail-Systeme. So wertvoll diese Funktionen auch sind, sie kommen alle erst nachträglich ins Spiel. Zuerst müssen Nachrichten gesendet werden, bevor Benutzer informiert werden können, dass sie übermittelt wurden, dass jemand nicht im Büro ist oder dass eine Nachricht nicht zugestellt wurde, weil das Postfachkontingent des Empfängers überschritten ist. Hier kommen die E-Mail-Infos ins Spiel, eine neue Funktion, die als Exchange-Webdienst implementiert wurde und dazu dient, Benutzer über gängige Probleme zu informieren, bevor die Nachricht abgeht. Dahinter steht die Vorstellung, dass die Produktivität der Benutzer steigt und die Wahrscheinlichkeit sinkt, dass sie sich beim Helpdesk über nicht ankommende E-Mails beklagen, wenn sie vorher gewarnt werden, dass Nachrichten möglicherweise nicht ankommen oder gelesen werden. Außerdem werden die Systemressourcen geschont, wenn keine Nachrichten verarbeitet werden müssen, die scheitern werden. Microsoft hofft, dass E-Mail-Infos dazu beitragen, E-Mails intelligenter einzusetzen. Das Merkmal funktioniert gut, obwohl es in OWA 2010 und Outlook 2010 nur in Verbindung mit einem Exchange Server 2010-Postfach verfügbar ist. E-Mail-Infos stützen sich auf eine Mischung von Daten aus verschiedenen Quellen: 쐍 Active Directory (zum Beispiel, wenn es darum geht, ob ein Empfänger Beschränkungen unterliegt oder welche Maximalgröße für Anhänge die Organisation erlaubt) 쐍 Informationsspeicher (Postfachkontingente, Abwesenheitsnotizen, benutzerdefinierte E-MailInfos) 쐍 Messgrößen für Gruppen (vom Clientzugriffsserver erstellte Metadaten wie die Gesamtzahl der Empfänger und die Anzahl externer Empfänger in einer Gruppe) Die Gruppenmessgrößen sind in einem Zwischenspeicher auf Clientzugriffsservern mit Exchange Server 2010 abgelegt. Sind für eine Organisation E-Mail-Infos eingerichtet, wird sonntags (der Tag lässt sich nicht ändern) der Dienst Group Metrics innerhalb des Diensthost-Prozesses auf jedem Postfachserver ausgeführt, der zum Erstellen von Gruppenmessgrößen vorgesehen ist, und zählt die Empfänger in jeder Gruppe in der Organisation einschließlich der dynamischen Verteilergruppen. An den übrigen Wochentagen erhebt der Dienst inkrementelle Daten über die Anzahl der hinzugefügten oder geänderten Empfänger in Gruppen (wenn dies geschieht, wird das Ereignis 14024 protokolliert). OAB-Server generieren Gruppenmessdaten, weil sie im Rahmen von E-Mail-Infos zusammen mit dem Offlineadressbuch verteilt werden. Sie müssen natürlich erhoben werden, bevor sie ins Adressbuch aufgenommen werden können. Exchange richtet Postfachserver, die das Offlineadressbuch erstellen, automatisch so ein, dass sie auch Gruppenmessdaten erfassen. Andere Server, die das Offlineadressbuch erstellen, können ebenfalls solche Daten erheben. Für kleine Organisationen ist dies zwar nicht von Bedeutung, weil sie wahrschein738
lich nur den Server einzusetzen brauchen, der das Offlineadressbuch für diesen Zweck anlegt, größere wollen die Last aber vielleicht verteilen, insbesondere, wenn sie weit verteilte Standorte mit begrenzter Netzwerkanbindung haben. Mit der Exchange-Verwaltungskonsole können Sie weder Gruppenmessdaten erstellen noch den Zeitplan dafür ändern, sondern Sie benötigen dazu das Cmdlet Set-MailboxServer. Das Erstellen von Gruppenmessgrößen auf einem Server aktivieren Sie zum Beispiel wie folgt: Set-MailboxServer –Identity ExServer1 –GroupMetricsGenerationEnabled $True
Der Wert dieser Eigenschaft auf einem Server, der das Offlineadressbuch anlegt, ist $False, solange Sie ihn nicht auf $True setzen. Der Umstand, dass der Server das Offlineadressbuch anlegt, beseitigt die Notwendigkeit, das Erstellen von Gruppenmessgrößen zu aktivieren. HINWEIS Läuft auf dem Server, der das Offlineadressbuch anlegt, Exchange Server 2007, müssen Sie einen anderen Postfachserver für das Erstellen der Gruppenmessgrößen einrichten, weil Computer mit Exchange Server 2007 diese Funktion nicht kennen. Wenn Sie einen Postfachserver für die Erstellung von Gruppenmessdaten einrichten, wird er in eine in Active Directory geführte Liste aufgenommen. Der Exchange-Dateiverteilungsdienst auf den Clientzugriffsservern ruft diese Liste aus Active Directory ab und kopiert die Messdaten alle acht Stunden vom nächstliegenden Server. Abbildung 12.11 zeigt den Inhalt des Ordners Group Metrics auf einem Postfachserver. Die BIN-Datei enthält sämtliche Daten über Gruppen und wird nach Datum und Uhrzeit ihrer Erstellung benannt. Die XML-Datei wird vom Exchange-Dateiverteilungsdienst verwendet und zeigt auf die BIN-Datei, die an die Clientzugriffsserver verteilt werden muss. Standardmäßig erstellt Exchange Gruppenmessdaten an einem zufälligen Zeitpunkt innerhalb von zwei Stunden mitten in der Nacht, aber Sie können einen Zeitpunkt festlegen. Um die Daten beispielsweise um 21.45 Uhr zu erstellen, verwenden Sie folgenden Befehl: Set-MailboxServer –Identity ExServer1 -GroupMetricsGenerationTime 21:45 Abbildg. 12.11 Gruppenmessdaten
739
Postfachunterstützungsdienste
E-Mail-Infos und Messgrößen für Gruppen
Kapitel 12
Postfachunterstützungsdienste
Clientinteraktion Für E-Mail-Infos aktivierte Clients fordern Daten an, wenn ein Benutzer einer Nachricht einen Empfänger oder einen Anhang hinzufügt oder mit dem Befehl Antworten oder Allen antworten auf eine Nachricht reagiert. E-Mail-Infos werden auch verarbeitet, wenn ein Nachrichtenentwurf geöffnet wird. Diese Aktionen veranlassen den Client, einen Hintergrundthread aufzurufen, der den Webdienst für E-Mail-Infos auf einem Clientzugriffsserver am lokalen Standort abfragt und ermittelt, ob es E-Mail-Infos für die Nachricht gibt. Der URL für den E-Mail-Info-Dienst wird dem Client als Bestandteil des AutoErmittlungsmanifests zurückgegeben. Der Clientzugriffsserver ist für die Erhebung von Daten aus Active Directory und dem lokalen Zwischenspeicher für Gruppenmessgrößen sowie für die Rückgabe der passenden Daten an den Client zuständig. Außerdem nimmt er Kontakt mit den Postfachservern der Empfängerpostfächer auf, um Informationen über Postfachkontingente und Abwesenheitsnotizen einzuholen. Liegen einige davon außerhalb des lokalen Standorts, gibt er die Datenanforderung an einen dortigen Clientzugriffsserver weiter. HINWEIS Um inakzeptabel lange Reaktionszeiten zu vermeiden, wird die Anforderung abgebrochen, wenn der Clientzugriffsserver nicht innerhalb von zehn Sekunden antwortet, woraufhin der Client ohne E-Mail-Info-Daten fortfährt. Außerdem müssen Sie wissen, dass Sie nicht zu warten brauchen, bis die E-Mail-Infos fertig ist, bevor Sie eine Nachricht senden können. Hat die E-MailInfo-Funktion nicht reagiert und müssen Sie die Nachricht zum Empfänger bekommen, können Sie auf Senden klicken und sie ohne weiteres abschicken. Um die Kommunikation mit dem Clientzugriffsserver zu begrenzen, unterhalten sowohl OWA- als auch Outlook-Clients ihrerseits Zwischenspeicher, die bei der Verarbeitung von Nachrichten gefüllt werden. Versuchen Sie zum Beispiel, eine Nachricht mit einem sehr großen Anhang zu senden, sieht der Client dort nach, ob der Anhang die maximale Nachrichtengröße der Organisation überschreitet. Findet er dort keine entsprechenden Daten, holt er sie aus der passenden Quelle (in diesem Fall aus den Exchange-Konfigurationsdaten in Active Directory) und legt sie für den späteren Gebrauch lokal ab. Zwischengespeicherte Daten werden nach 24 Stunden wegen Überalterung gelöscht. Davon ausgenommen sind die Hinweise über volle Postfächer und die Abwesenheitsnotizen, bei denen häufigere Änderungen wahrscheinlich sind und die daher nach zwei Stunden veralten. Die E-Mail-InfoEinstellungen für OWA stehen in der Datei Web.config.xml. Es ist möglich, aber nicht empfehlenswert, die Altersbegrenzung und die Anzahl der Elemente im Zwischenspeicher durch Bearbeiten dieser Datei zu ändern. Zwischenspeicher auf der Clientseite sind nicht dauerhaft, sondern werden geleert, sobald Sie Outlook oder OWA verlassen.
Einrichten von E-Mail-Infos Für der Administratoren liegt der unmittelbare Wert der E-Mail-Infos darin, dass sie viele Gründe für Unzustellbarkeitsberichte in Exchange beseitigen (zum Beispiel ein volles Zielpostfach, eine zu große Nachricht) und auf diese Weise die Belastung der Messaginginfrastruktur reduzieren. Auf der anderen Seite bedeutet die Verarbeitung, die die Erfüllung der Clientanforderungen für E-Mail-Infos erfordert, eine zusätzliche Last für die Clientzugriffsserver, die Microsoft mit etwa 5% beziffert. Die gesamte Verwaltung von E-Mail-Infos erfolgt über die Exchange-Verwaltungsshell. ExchangeAdministratoren können E-Mail-Infos ein- und ausschalten, aber nur für die gesamte Organisation,
740
indem sie mit dem Cmdlet Set-OrganizationConfig die Parameter für die Verarbeitung von E-MailInfos festlegen: 쐍 MailTipsAllTipsEnabled Gibt an, ob E-Mail-Infos aktiviert sind. Der Standardwert lautet $True. 쐍 MailTipsExternalRecipientTipsEnabled Gibt an, ob E-Mail-Infos für externe Empfänger aktiviert sind. Der Standardwert lautet $False. Externe Empfänger werden anhand der Liste der akzeptierten Domänen ermittelt. Jede darin enthaltene Domäne gilt als intern, alle anderen als extern. 쐍 MailTipsGroupMetricsEnabled Gibt an, ob E-Mail-Infos aktiviert sind, die von Gruppenmessgrößen abhängen. Der Standardwert lautet $True. 쐍 MailTipsLargeAudienceThreshold Legt den Schwellenwert für die Menge der Empfänger einer Nachricht fest, von dem an die Anzahl in E-Mail-Infos als groß gekennzeichnet wird. Der Standardwert beträgt 25. Für umfangreiche Organisationen, in denen große Verteilergruppen üblich sind, liegt er wahrscheinlich zu niedrig. In diesem Fall ist es sinnvoll, den Wert auf 50 zu erhöhen, damit die Benutzer nicht durch E-Mail-Infos gestört werden. 쐍 MailTipsMailboxSourcedTipsEnabled Gibt an, ob E-Mail-Infos auf der Grundlage von Postfachdaten wie Abwesenheitsnotizen aktiviert sind. Der Standardwert ist $True. Tabelle 12.4 listet die üblichen Bedingungen auf, unter denen E-Mail-Infos sinnvoll sind. Wie Sie sehen, hält eine E-Mail-Info in den meisten Fällen einen Benutzer davon ab, etwas zu tun, was zu Enttäuschungen führt (die Nachricht kommt nicht durch), oder reduziert den Exchange-Datenverkehr (Unzustellbarkeitsmeldungen für Nachrichten, die sich nicht verarbeiten lassen, fallen weg). Benutzer vor dem Versenden an sehr große Verteiler zu warnen ist sehr sinnvoll, weil es für einen Benutzer allzu leicht ist, eine Notiz an einen Verteiler zu richten, bei dem er nicht erkennt, dass Exchange die Nachricht dann an Tausende von Postfächern übermittelt. Personen, die die Nachricht erhalten, können einen E-Mail-Sturm auslösen, indem sie mit Allen antworten eine Antwort erstellen, die wieder an jeden geht und noch mehr Reaktionen verursacht. Am Ende ist normalerweise ein Hub-Transport-Server mit Datenverkehr überschwemmt, es entstehen riesige Nachrichtenwarteschlangen, und andere E-Mails werden nur langsam ausgeliefert. E-Mail-Infos beseitigen nicht die Notwendigkeit, als Benutzer seine Intelligenz einzusetzen, können aber zu gegebener Zeit einen Hinweis geben, um jemanden davon abzuhalten, etwas zu tun, was er lieber nicht tun sollte. Tabelle 12.4
Arten von E-Mail-Infos Potenzielles Problem
Aktion
Empfänger verarbeitet keine E-Mails mehr, weil er abwesend ist
Ist für ein Postfach eine Abwesenheitsnotiz eingerichtet, erfahren Sie, dass der Empfänger nicht da ist, und können ihn aus der Nachricht entfernen. E-MailInfos zeigen die ersten 250 Zeichen der Notiz an.
Nachricht an einen sehr großen Verteiler
Richten Sie eine Nachricht an eine Gruppe, die mehr Empfänger umfasst als die für die Organisation eingerichtete Anzahl für große Benutzergruppen, werden Sie von den E-Mail-Infos informiert, wie viele Personen die Nachricht bekommen (pro Gruppe und insgesamt). Doppelte Adressaten werden nicht gelöscht, sodass die Gesamtzahl möglicherweise etwas höher liegt als die tatsächliche Zahl der erstellten Nachrichten, aber der Wert ist ein guter Anhaltspunkt, um Benutzer davon abzuhalten, Nachrichten zu senden, die zu Hunderten von Übermittlungen führen. Exchange versucht nicht, einzelne E-Mail-Infos für Nachrichten zu verarbeiten, die an mehr als 200 Empfänger gehen, weil sich daraus ein nicht akzeptabler Leistungsaufwand für den Clientzugriffsserver ergäbe. Richten Sie eine Nachricht an eine Verteilergruppe, wertet Exchange aus demselben Grund keine einzelnen E-Mail-Infos für die Gruppenmitglieder aus. Als einzige Ausnahme zeigt Exchange die Anzahl der externen Empfänger an, wenn in der Gruppe solche vorhanden sind.
741
Postfachunterstützungsdienste
E-Mail-Infos und Messgrößen für Gruppen
Kapitel 12 Tabelle 12.4
Postfachunterstützungsdienste
Arten von E-Mail-Infos Potenzielles Problem
Aktion
Nachricht an einen nicht vorhandenen Adressaten
Nachrichten können lange in einem Benutzerpostfach liegen und enthalten möglicherweise Adressen, die nicht mehr gültig sind, weil der Inhaber die Firma verlassen hat. Ungültige Adressen können auch in der Exchange-Liste für die automatische Vervollständigung vorkommen. Die E-Mail-Info ermittelt dies und lässt den Benutzer den veralteten Empfänger entfernen, bevor er die E-Mail sendet, was die sonst unvermeidliche Unzustellbarkeitsmeldung verhindert.
Nachricht an einen externen Empfänger
Ist eine Nachricht an jemanden außerhalb der Organisation oder an eine Gruppe mit einem externen Empfänger gerichtet, warnen die E-Mail-Infos den Benutzer für den Fall, dass die Nachricht vertrauliche Firmeninformationen enthält.
Antwort auf Blindkopie
Antworten Sie auf eine Nachricht, in deren BCC-Liste Sie stehen, machen die E-Mail-Infos Sie darauf aufmerksam, dass die übrigen Empfänger durch die Antwort erfahren, dass Sie die ursprüngliche Nachricht bekommen haben.
Übergroße Nachricht
Versuchen Sie, eine Nachricht zu senden, die die Maximalgröße für die Organisation oder für einen der Empfänger überschreitet, informieren die E-MailInfos Sie, dass Exchange die Nachricht nicht zustellt. Sie können Sie natürlich nicht davor warnen, dass eine externe Organisation Probleme mit einer Nachricht bestimmter Größe bekommt.
Nachricht an moderierte Gruppe
Nachrichten an eine moderierte Gruppe benötigen die Genehmigung des Moderators. Die E-Mail-Infos warnen Sie daher, dass es eine Verzögerung geben kann. Die Moderatoren der Gruppe oder jemand, der explizit berechtigt ist, Nachrichten an die Gruppe zu empfangen, sieht diese E-Mail-Info nicht.
Nachricht an Empfänger, der Einschränkungen unterliegt
Administratoren können Postfächer und Gruppen so einrichten, dass nur bestimmte Benutzer ihnen Nachrichten schicken dürfen. Versuchen Sie, einem solchen Empfänger eine Nachricht zu senden, werden Sie von den E-Mail-Infos gewarnt, dass Ihre Nachricht nicht angenommen wird.
Benutzerdefinierte E-MailInfos
Administratoren und Gruppenbesitzer können benutzerdefinierte E-Mail-Infos einrichten, wobei sie unter anderem die Möglichkeit haben, den Text zu übersetzen, sodass die Benutzer ihn in ihrer Sprache sehen. Vielleicht wollen Sie eine E-Mail-Info für ein Postfach zur Personalsuche einrichten, um den Benutzern mitzuteilen, dass jede Nachricht dorthin innerhalb von 24 Stunden bearbeitet wird. Die benutzerdefinierte E-Mail-Info eines Empfängers wird nicht angezeigt, wenn der Benutzer nicht berechtigt ist, ihm etwas zu senden.
Was sehen die Benutzer? Abbildung 12.12 gibt eine gute Vorstellung davon, was ein Benutzer sieht, wenn er mit OWA eine Nachricht verfasst und E-Mail-Infos aktiviert sind. In diesem Fall wurden drei Bedingungen ermittelt. Der Benutzer darf nicht an die Gruppe Vertriebsleitung senden und erhält daher die Möglichkeit, diesen Empfänger zu streichen, die Anzahl der Empfänger im Nachrichtenkopf überschreitet den Grenzwert für große Benutzergruppen in der Organisationskonfiguration (Standardwert 25), sodass der Benutzer überlegen kann, ob er die Nachricht wirklich senden will, und für ein Postfach werden benutzerdefinierte E-Mail-Infos angezeigt. HINWEIS Der Benutzer kann all diese Warnungen ausblenden, indem er auf das rote Ausrufezeichen in der Infoleiste klickt – damit sagt er OWA, dass er wirklich weiß, was er tut.
742
E-Mail-Infos und Messgrößen für Gruppen
Postfachunterstützungsdienste
Abbildg. 12.12 E-Mail-Infos in OWA
Der andere Client, der E-Mail-Infos unterstützt, ist Outlook. Im Exchange-Cache-Modus ist Outlook auf Details der E-Mail-Infos angewiesen, die zusammen mit anderen Empfängerattributen im Offlineadressbuch stehen. Ist Outlook jedoch für Onlinearbeit eingerichtet, ruft es die Daten für E-MailInfos genauso ab wie OWA. In Abbildung 12.13 sehen Sie, dass Outlook die E-Mail-Infos ein wenig anders darstellt. Wir haben die Nachricht hier an dieselben drei Empfänger gerichtet wie im vorhergehenden Beispiel. Outlook meldet, dass wir keine Nachricht an die Gruppe Sales Executives senden können, und stellt den Namen der Gruppe außerdem in hellerer Farbe dar als die Gruppe Exchange Server 2010-Interessentenliste. Darüber hinaus sehen wir die E-Mail-Info für das einzelne Postfach Helpdesk. Abbildg. 12.13 E-Mail-Infos in Outlook 2010
743
Kapitel 12
Postfachunterstützungsdienste
Es gibt jedoch kein Anzeichen für die Warnung, dass wir die Nachricht an 50 Empfänger senden! Dies liegt daran, dass Outlook den Benutzer entscheiden lässt, welche E-Mail-Infos er sehen möchte (siehe Abbildung 12.14), ob die Leiste für E-Mail-Infos ständig verfügbar sein soll und ob sie erweitert wird, wenn mehrere Infos vorhanden sind. OWA besitzt dagegen keine Benutzerschnittstelle, um E-MailInfos einzurichten. Klicken Sie auf die Schaltfläche in der Symbolleiste, um die Infoleiste mit den E-Mail-Infos zu reduzieren, speichert OWA den Stand sitzungsübergreifend, und die E-Mail-Infos werden erst wieder angezeigt, wenn der Benutzer die Leiste wieder einblendet. Hinter den Kulissen sucht OWA weiter nach E-Mail-Infos und ändert die Farbe der Schaltfläche, um anzuzeigen, wenn entsprechende Daten zur Verfügung stehen. Die E-Mail-Info-Einstellungen für ein Postfach lassen sich weder über die Exchange-Verwaltungskonsole noch über die Exchange-Verwaltungsshell bearbeiten. Abbildg. 12.14 Die Optionen für E-Mail-Infos in Outlook 2010
Benutzerdefinierte E-Mail-Infos Jedes E-Mail-aktivierte Objekt lässt sich um eine benutzerdefinierte E-Mail-Info ergänzen. Meistens geschieht dies für nicht überwachte Postfächer, um die Benutzer zu benachrichtigen, dass ihre Nachricht möglicherweise nicht schnell beantwortet wird, für moderierte Adressen, für eingeschränkte Verteilergruppen (auch dynamische), die nur Nachrichten von Benutzern in einer genehmigten Liste annehmen, und um Benutzern eine gewisse Hilfe zu gewähren, wenn sie etwas an besondere Postfächer senden – etwa den internen Support –, um Erwartungen darüber zu setzen, wann mit einer Antwort zu rechnen ist. Benutzerdefinierte E-Mail-Infos können bis zu 250 Zeichen lang sein.
744
Benutzerdefinierte E-Mail-Infos werden genauso eingerichtet wie alle anderen Eigenschaften eines E-Mail-aktivierten Objekts. Um zum Beispiel eine E-Mail-Info für ein Postfach zu erstellen, benutzen Sie das Cmdlet Set-Mailbox: Set-Mailbox –Identity 'Help Desk' –MailTip 'Messages to the Help Desk are handled on a best-effort basis; please call 91184 if you need urgent support'
Nach demselben Ansatz gehen Sie für eine Verteilergruppe vor: Set-DistributionGroup –Identity 'Sales' –MailTop 'Only members of the Sales Executives group can send to this address'
E-Mail-Infos können HTML-Inhalt umfassen, was nützlich ist, wenn Sie Benutzer mithilfe eines URLs zu weiteren Informationen führen wollen. Beispielsweise können E-Mail-Infos in Nachrichten an den internen Support einen URL enthalten, der es Benutzern ermöglicht, ihre Hilfeanforderung zu protokollieren: Set-Mailbox –Identity 'Help Desk' –MailTip 'Please visit the Help Desk site to log a support call'
Insidertipp: Was Sie nicht tun können
Sie können eine E-Mail-Info nicht bearbeiten, sondern nur mit neuem Text überschreiben. In einer benutzerdefinierten E-Mail-Info lässt Exchange Server 2010 nur einfachen Text zu, also auch keinerlei Regel, die steuert, wann ein Client die Info anzeigt. Sie können zum Beispiel keine E-Mail-Infos erstellen, die den Nachrichtentext nach einem Muster durchsuchen, etwa einer Sozialversicherungsnummer oder auch nur einem einfachen Begriff wie dem Namen eines wichtigen Projekts. Exchange Server 2010 steht erst am Anfang der Entwicklung, den Benutzern vorausschauend Ratschläge anzubieten, damit sie ihre E-Mails effizienter nutzen können, und es würde nicht überraschen, wenn Microsoft in eine zukünftige Exchange-Version weitere regelbasierte Verarbeitungsfähigkeiten für E-Mail-Infos aufnähme. Die E-Mail-Infos werden in Active Directory als Eigenschaften des Postfachs gespeichert. Der Clientzugriffsserver liest die Daten im Stundentakt, sodass es bis zu einer Stunde dauern kann, bevor eine Änderung an einer benutzerdefinierten E-Mail-Info wirksam wird. Die einzige Möglichkeit, diesen Zeitpunkt vorzuziehen, besteht darin, die Internetinformationsdienste neu zu starten, was in einer Produktionsumgebung schwierig ist.
Benutzerdefinierte E-Mail-Infos in mehreren Sprachen Exchange Server 2010 trägt mehrsprachigen Organisationen mit der Möglichkeit Rechnung, E-MailInfos in allen Sprachen zu erstellen, die angeboten werden müssen. Dies ist ein wenig komplizierter, als eine einfache E-Mail-Info in einer Sprache zu schreiben, weil Sie zunächst die Liste der Sprachen aufstellen, dann die Zeichenfolge für jede davon übersetzen und anschließend das Array dieser Übersetzungen mithilfe des Parameters MailTipTranslations der Cmdlets Set-Mailbox, Set-DistributionGroup, Set-Contact und Set-MailPublicFolder nach Bedarf füllen müssen. Vor oder beim Hinzufügen der übersetzten Werte müssen Sie eine standardmäßige E-Mail-Info anlegen. Entspricht die für ein
745
Postfachunterstützungsdienste
E-Mail-Infos und Messgrößen für Gruppen
Kapitel 12
Postfachunterstützungsdienste
Benutzerpostfach angegebene Sprache keinem Wert in der Liste, wird der Standardwert verwendet. Im folgenden Beispiel setzen wir Werte für vier Sprachen zusätzlich zum englischen Standardwert. Sie werden durch Kommata getrennt. Set-Mailbox –Identity 'Jacky Chen' –MailTip 'Financial Services Manager' –MailTipTranslations 'NL: Manager van de financiële Diensten', 'IT: Responsabile di servizi finanziari', 'FR: Directeur de services financiers', 'ES: Encargado de los servicios financieros'
Die übersetzten Werte werden in der Eigenschaft MailTipTranslations als Array von HTML-Werten gespeichert. Um sie anzuzeigen, geben Sie Folgendes ein: Get-Mailbox –Identity 'Jacky Chen' | Select MailTip* | Format-List
Das Offlineadressbuch Das Offlineadressbuch (OAB) ist eine Momentaufnahme der globalen Adressliste (GAL), die Outlook-Clients von Exchange herunterladen können, um eine lokale Verzeichnisquelle zum Nachschlagen und Prüfen von Adressen zu haben. Alle in der globalen Adressliste enthaltenen Empfänger mit Ausnahme der ausgeblendeten sind im Offlineadressbuch zu finden (siehe Abbildung 12.15). Eine Liste der verborgenen Empfänger lässt sich mit folgendem Befehl anzeigen: Get-Recipient –Filter {HiddenFromAddressListsEnabled –eq $True} Abbildg. 12.15 Verbergen eines Postfachs in Adresslisten
746
Outlook-Clients müssen eine Kopie des Offlineadressbuchs herunterladen, bevor sie offline voll funktionsfähig sind. Das Offlineadressbuch enthält nur einen Teil der Eigenschaften, die Active Directory für Objekte verzeichnet, was den Benutzern nur selten bewusst ist, weil es sämtliche Daten enthält, die sie normalerweise für ihre E-Mails oder zum Auffinden von Empfängern brauchen. Daten, die sich auf Zeiger zwischen Active Directory-Objekten stützen, sind offline nicht verfügbar (bestes Beispiel: Manager mit ihren Berichten und ihrer Gruppenmitgliedschaft). Dasselbe gilt für angepasste Eigenschaften, die Sie in die globale Adressliste einfügen, es sei denn, dass Sie die Adressvorlagen anpassen und in das Offlineadressbuch aufnehmen. Ein Problem mit dem Offlineadressbuch besteht darin, dass neue Empfänger unsichtbar sind, bis Exchange das Offlineadressbuch das nächste Mal aktualisiert und die Clients die Aktualisierungen heruntergeladen und in ihr Adressbuch übernommen haben. Fügen Sie zum Beispiel am Montag um 11 Uhr ein neues Postfach hinzu und aktualisiert Exchange das Offlineadressbuch am Dienstag um 4 Uhr, sieht ein Benutzer das neue Postfach dann erst in der globalen Adressliste, nachdem er die Aktualisierung heruntergeladen hat, was möglicherweise erst am folgenden Donnerstag oder Freitag erfolgt. In der Praxis ist dies normalerweise nicht sehr problematisch, es sei denn, es geht um profilierte Benutzer, beispielsweise neue leitende Mitarbeiter, die für die Organisation sichtbar sein wollen, sobald ihr Postfach angelegt ist. Dafür gibt es zwei Lösungen. Zum einen können Sie E-Mails in jedem Fall mithilfe der SMTP-Adressen an diese Benutzer leiten. Zum anderen können Sie in der Adressliste Alle Benutzer nach neuen Einträgen suchen, weil Sie Outlook damit zwingen, Verbindung mit dem Server aufzunehmen, um das Verzeichnis zu durchsuchen.
Herunterladen des Offlineadressbuchs Outlook-Clients im Exchange-Cache-Modus laden das Offlineadressbuch automatisch herunter. Das erste Mal geschieht dies, nachdem die Postfachordner in die OST-Datei repliziert wurden. Danach sucht Outlook täglich nach Aktualisierungen des Offlineadressbuchs und lädt sie ggf. von Exchange herunter. Das Intervall lässt sich nicht ändern, weil es in Outlook hart vorgegeben ist. Eine automatische tägliche Aktualisierung ist in jedem Fall günstig, weil sie das Offlineadressbuch auf dem neuesten Stand hält und verhindert, dass es eine Menge ungültiger Daten enthält. TIPP Ist ein Offlineadressbuch eine Woche alt, stellt das normalerweise kein Problem dar, es sei denn, die Organisation befindet sich mitten in einer Fusion oder einer Übernahme oder hat einen anderen Grund für umwälzende Verzeichnisänderungen. Ein Offlineadressbuchmit einem Alter von einem Monat ist wegen der Menge der Änderungen, die in Firmenverzeichnissen üblicherweise stattfinden, wesentlich weniger befriedigend. Scheitert eine Aktualisierung des Offlineadressbuchs, unternimmt Outlook stündlich einen neuen Versuch, bis es klappt. Muss Outlook jedoch eine vollständige Kopie des Offlineadressbuchs herunterladen, versucht es dies nur einmal innerhalb von 13 Stunden. Clients können das Offlineadressbuch auch mit der Option Senden/ Empfangen\Adressbuch herunterladen nach Bedarf herunterladen. Die Menge der heruntergeladenen Daten lässt sich reduzieren, indem Sie Keine Details wählen, was Outlook veranlasst, eine abgespeckte Kopie des Offlineadressbuchs abzurufen (nur grundlegende Empfängerdaten und E-Mail-Adressen). Anhand dieser Daten kann das Offlineadressbuch immer noch verwendet werden, um Empfänger zu suchen und E-Mail-Adressen zu prüfen, aber die Datei ist dabei wesentlich weniger hilfreich, als wenn sie Daten wie Telefonnummern enthielte, die beim vollständigen Herunterladen mitgeliefert werden. Die Begrenzung der Daten war in einer Zeit sinnvoll,
747
Postfachunterstützungsdienste
Das Offlineadressbuch
Kapitel 12
Postfachunterstützungsdienste
als Netzwerke seltener zur Verfügung standen und langsamer waren als heute. Die Möglichkeit, ein gekapptes Adressbuch herunterzuladen, ist meistens nur von geringem Wert, es sei denn, Sie sind gezwungen, etwas Ähnliches wie eine Einwählverbindung zu benutzen. Wie bei anderen Synchronisierungsvorgängen ruft Outlook die Dateien des Offlineadressbuchs mithilfe eine Hintergrundthreads ab, damit die Benutzer während des Downloads weiterarbeiten können. Adressbuchdaten wurden bisher über einen öffentlichen Systemordner verfügbar gemacht, jetzt liegt der Schwerpunkt jedoch auf der webgestützten Verteilung durch die Clientzugriffsserver, um die Abhängigkeit von öffentlichen Ordnern zu beseitigen. Clients mit Postfächern auf einem Computer mit Exchange Server 2010 müssen Verbindung mit einem Clientzugriffsserver aufnehmen, auf dem Exchange Server 2010 läuft, um die Dateien für das Offlineadressbuch herunterzuladen, während solche mit Postfächern auf älteren Exchange-Servern einen Clientzugriffsserver mit Exchange Server 2007 oder einen Exchange Server-Computer mit öffentlichen Ordnern benötigen. Nach dem Herunterladen des Offlineadressbuchs legt Outlook auf dem PC eine Gruppe von sechs Dateien an oder aktualisiert sie (Tabelle 12.5). Sie unterscheiden sich je nach Anzahl der E-Mail-aktivierten Empfänger in der Organisation in der Größe und können eine ziemliche Menge Speicherplatz auf der Festplatte belegen. Das aktuelle Offlineadressbuch von HP erfordert zum Beispiel 383 MB für etwa 450.000 Objekte, also etwa 0,85 MB pro 1000 Objekte. Die Adressbuchdateien und -aktualisierungen werden beim Herunterladen durch Outlook komprimiert, sodass sie etwa halb so groß sind wie nach dem Entpacken auf der Festplatte. Dennoch kann es lange dauern, ein vollständiges Offlineadressbuch in einer großen Organisation herunterzuladen. Tabelle 12.5
OAB-Dateien Datei
Verwendung
UBrowse.oab
Der Kernindex für das Offlineadressbuch. Die Datensätze enthalten den Objekttyp, den Anzeigenamen und einen Zeiger auf den Rest der Objektdaten, die in der Detaildatei stehen.
UDetails.oab
Sämtliche Details (falls verfügbar) für Objekte beim vollständigen Herunterladen. Dies ist die umfangreichste Adressbuchdatei.
URdndex.oab
Ein Index zur Auflösung relativer definierter Namen für Empfängerobjekte und zur Verfolgung von Änderungen an Domänennamen.
UPdndex.oab
Ein Index für Domänennamen (beispielsweise contoso.com).
UAnrdex.oab
Ein Index zur Auflösung nicht eindeutiger, von Benutzern eingegebener Namen beim Prüfen von Adressen.
UTmplts.oab
Eine Datei mit sprachspezifischen Zeichenfolgen für Dialogfelder und andere statische Elemente, die von Adressbuchvorlagen verwendet werden.
Im Allgemeinen muss Outlook das Offlineadressbuch nach dem ersten vollständigen Herunterladen mithilfe von Aktualisierungsdateien auffrischen, die es von Exchange holt. Diese Dateien werden täglich erstellt und enthalten die Änderungen seit der letzten Aktualisierung. War Outlook mehrere Tage offline, muss es alle verpassten Tagesaktualisierungen herunterladen, um das Offlineadressbuch auf den neuesten Stand zu bringen. Eine vollständiger Download ist erforderlich, wenn Outlook 2003 SP2 (oder höher) feststellt, dass mehr als die Hälfte der Einträge in der globalen Adressliste seit dem letzten Mal aktualisiert wurden. Frühere Outlook-Versionen benötigten dies, wenn sich ein Achtel der globalen Adressliste geändert hatte.
748
Um das Risiko der Serverüberlastung auszugleichen, nutzt Microsoft für Aktualisierungsdateien des Offlineadressbuchs die LZX-Komprimierung und verteilt keine vollständigen Datensätze, sondern nur binäre Patches für aktualisierte Sätze. Daran sind zwei Dateien beteiligt. Die Datei Data.oab ist eine »Ausgangsdatei«, während die Datei Binpatch.oab täglich erstellt wird und die differenziellen Änderungen gegenüber dem Vortag enthält (im Grunde alle Änderungen der globalen Adressliste am Vortag). Um ein Offlineadressbuch auf den neuesten Stand zu bringen, lädt Outlook alle Versionen von Binpatch.oab für die Tage seit der letzten Aktualisierung herunter und führt sie mit Data.oab zusammen. Anschließend werden die neuen Indizes zur Aktualisierung des Offlineadressbuchs generiert. Komprimierung und binäre Aktualisierungen stellen einen wirkungsvollen Mechanismus für die Verteilung des Offlineadressbuchs in Organisationen beliebiger Größe dar. Gemischte Umgebungen
In einer gemischten Umgebung, in der es Computer mit Exchange Server 2003 gibt, können Sie einen vollständigen Download für alle Clients auslösen, indem Sie eine neue Verwaltungsgruppe hinzufügen. Andere Beispiele, in denen sich Verzeichnisänderungen auf einen großen Teil der Adressbuchdatensätze auswirken, sind neue E-Mail-Adressen für zahlreiche Empfänger, die Änderung des Vergabesystems für Telefonnummern, der Umzug in ein neues Bürogebäude und die Aktualisierung der Straßenadresse usw. In großen Organisationen, in denen größenveränderliche Dateien betroffen sind, ist es wichtig zu vermeiden, dass Clients das Offlineadressbuch vollständig herunterladen müssen. Stellen Sie sich vor, 10.000 Clients müssen Adressbuchdaten von 100 MB von einem einzigen Clientzugriffsserver oder einem Server mit öffentlichen Ordnern herunterladen. (Dieses Beispiel ist extrem, um das Wesentliche zu veranschaulichen, weil keine Bereitstellung mit 10.000 Clients nur einen einzigen Clientzugriffsserver einsetzt.) Der Server muss die Nachfrage nach 1000 GB an Daten befriedigen, möglicherweise innerhalb kurzer Zeit, was dazu führen kann, dass er andere sinnvolle Dinge erst erledigen kann, wenn die Nachfrage nach Adressbuchdaten abnimmt. Aus demselben Grund ist es auch günstig, neue Outlook-Versionen stufenweise einzuführen, damit nicht die Situation entsteht, dass Hunderte von Benutzern ihre brandneue Outlook-Version starten und sofort beginnen, ihre OST-Datei zu synchronisieren und das Offlineadressbuch herunterzuladen. Die Auswirkungen lassen sich auch dadurch begrenzen, dass Sie mehrere Verteilungspunkte für Adressbuchaktualisierungen bereitstellen, indem Sie Exchange so einrichten, dass die Aktualisierungen an mehrere Clientzugriffsserver übertragen werden (bei webgestützter Verteilung) bzw. der öffentliche Adressbuchordner auf mehrere Server mit öffentlichen Ordnern repliziert wird. Abbildung 12.16 zeigt, was Sie sehen können, wenn Sie das Verzeichnis untersuchen, in dem Exchange die Adressbuchdateien nach dem Erstellen ablegt. Eine Datei mit dem Namen Oab.xml (das OAB-Manifest) dient dazu, sämtliche verfügbaren Aktualisierungen zu verfolgen, einschließlich der vollständigen und der differenziellen Dateien, der von Windows- und Macintosh-Clients verwendeten Vorlagen und der Metadaten, beispielsweise der Größe komprimierter und nicht komprimierter Dateien. Am Ende der Liste finden Sie die Datei Data-24.lzx, die am 24. November 2009 generierte Ausgangsdatei. Wenn sie kopiert wird, heißt sie auf dem Client Data.oab. Die Ausgangsdatei wird täglich erstellt. Außerdem sehen wir die Gruppe der täglichen Aktualisierungen (Binpatch-23.lzx, Binpatch-22.lzx usw.). Ein Client, der seit dem 18. November keine Adressbuchaktualisierungen abgerufen hat, muss alle Dateien von Binpatch-19 bis Binpatch-24 kopieren und in die Datei Data.oab auf seinem PC aufnehmen, damit sein Offlineadressbuch auf den neuesten Stand kommt.
749
Postfachunterstützungsdienste
Das Offlineadressbuch
Kapitel 12
Postfachunterstützungsdienste
Abbildg. 12.16 OAB-Datendateien für Clientaktualisierungen
Wenn Outlook mit dem Herunterladen der Adressbuchdateien beginnt, setzt es dafür im Rahmen seiner Synchronisierungsaktivitäten ein Flag. Wenn Sie bei gedrückter (Strg)-Taste auf das OutlookSymbol in der Taskleiste klicken, um den Verbindungsstatus des Clients anzuzeigen, und dann auf die Registerkarte Lokales Postfach wechseln, sehen Sie, wie der Download des Offlineadressbuchs fortschreitet.
Generieren des Offlineadressbuchs Ein bestimmter Postfachserver, nämlich der Server zum Generieren des Offlineadressbuchs, ist im Rahmen des Auftrags OABGen, der als Teil des Systemaufsichtsprozesses ausgeführt wird, dafür zuständig, das Offlineadressbuch (die Standard-Offlineadressliste) zu erstellen. Dazu liest OABGen mithilfe von NSPI-Abfragen (Name Service Provider Interface) Daten aus Active Directory und legt eine Gruppe temporärer Dateien an, die anschließend komprimiert und in das Verzeichnis für die webgestützte Verteilung kopiert werden. Bei der Verteilung über öffentliche Ordner legt OABGen im öffentlichen Systemordner Elemente zur Aufnahme von Adressbuchaktualisierungen an. Eines wird für die vollständige Version des Offlineadressbuchs verwendet, die übrigen nehmen die täglichen Differenzdateien auf. Normalerweise ist der Server, der die Rolle der Adressbucherstellung übernimmt, der erste in der Organisation installierte Postfachserver. Um zu ermitteln, welcher Server dafür zuständig ist, gehen Sie zum Knoten Postfach unterhalb von Organisationskonfiguration und klicken auf die Registerkarte Offlineadressbuch. Danach können Sie das Standard-Offlineadressbuch auswählen und auf Eigenschaften klicken (siehe Abbildung 12.17). In diesem Fall sehen wir Folgendes:
750
쐍 Sowohl die webgestützte als auch die Verteilung über öffentliche Ordner ist aktiviert. Clients mit Outlook 2010 und Outlook 2007 holen Adressbuchaktualisierungen mithilfe webgestützter Verteilung von den angegebenen Clientzugriffsservern. Clients mit Outlook 2003 greifen über einen öffentlichen Ordner auf OAB-Dateien zu und rufen sie von dort ab. Die webgestützte Verteilung geht von der Standardwebsite für das Offlineadressbuch aus. Nachdem Sie den letzten Client mit Outlook 2003 außer Betrieb genommen haben, können Sie die Verteilung über öffentliche Ordner deaktivieren. 쐍 Der Name des Postfachservers, der täglich die OAB-Dateien generiert, ist angegeben. Auf der Registerkarte Allgemein finden Sie den Zeitplan dafür. Der Standardzeitpunkt ist täglich um 5 Uhr morgens. 쐍 Auf der Registerkarte Adresslisten sind die Adresslisten aufgeführt, die in das Offlineadressbuch aufgenommen wurden. Standardmäßig ist das Offlineadressbuch die einzige Liste. 쐍 Exchange kann OAB-Dateien für verschiedene Outlook-Versionen generieren. In einer Organisation, die ausschließlich Exchange Server 2010 einsetzt, brauchen wir tatsächlich nur die letzte Version (V4), die auf Unicode basiert und von Clients mit Outlook 2003 SP2 und höher verwendet wird, sodass wir die Erstellung der Version V3 deaktivieren können. Abbildg. 12.17 Festlegen, wie das Offlineadressbuch an Clients verteilt wird
Natürlich können Sie die Parameter zum Generieren des Offlineadressbuchs mit der Exchange-Verwaltungsshell einstellen. Wie Sie zum Beispiel die generierten Versionen auf V4 einschränken und die Verteilung über öffentliche Ordner deaktivieren, sehen Sie im folgenden Befehl: Set-OfflineAddressBook -Identity '\Default Offline Address Book' -Versions 'Version4’ -PublicFolderDistributionEnabled $False
751
Postfachunterstützungsdienste
Das Offlineadressbuch
Kapitel 12
Postfachunterstützungsdienste
Zahlreiche interessante Details des Offlineadressbuchs werden sichtbar, wenn Sie mit dem Cmdlet Get-OfflineAddressBook die Adressbucheigenschaften anzeigen: Get-OfflineAddressBook –Identity '\Default Offline Address Book' | Format-List Server
: ExServer1
AddressLists
: {\Default Global Address List}
Versions
: {Version4}
IsDefault
: True
PublicFolderDatabase
: PFDatabase1
PublicFolderDistributionEnabled
: False
GlobalWebDistributionEnabled
: False
WebDistributionEnabled
: True
LastTouchedTime
: 12/3/2009 3:05:42 AM
LastNumberOfRecords
: 455
ConfiguredAttributes : {OfficeLocation, ANR, ProxyAddresses, ANR, PhoneticGivenName, ANR, GivenName, ANR, PhoneticSurname, ANR, Surname, ANR, Account, ANR, PhoneticDisplayName, ANR, DisplayNameUnicode, ANR, ExternalMemberCount, Value, TotalMemberCount, Value, ModerationEnabled, Value, DelivContLength, Value, MailTipTranslations, Value, ObjectGuid, Value, IsOrganizational, Value...} DiffRetentionPeriod
: 30
VirtualDirectories
: {ExServer1\Offlineadressbuch (Default Web Site),
Identity
: \Default Offline Address Book
ExServer2\Offlineadressbuch (Default Web Site)}
Die Ausgabe des Befehls wurde aus Gründen der Deutlichkeit bearbeitet, aber wir sehen folgende Einzelheiten: 쐍 Den Namen des Postfachservers, der das Offlineadressbuch generiert (ExServer1) 쐍 Die in das Offlineadressbuch aufgenommenen Adresslisten, in diesem Fall lediglich die globale Adressliste 쐍 Die generierten Versionen des Offlineadressbuchs. Da in dieses Offlineadressbuch nur die Version 4 aufgenommen wird, können wir schließen, dass in der Organisation keine älteren Outlook-Clients eingesetzt werden. 쐍 Die Datenbank für öffentliche Ordner, in der die OAB-Dateien gespeichert sind, und die Angabe, ob die Verteilung über öffentliche Ordner genutzt wird (sie wird es nicht) 쐍 Datum und Uhrzeit der letzten Aktualisierung des Offlineadressbuchs 쐍 Die Anzahl der Datensätze im Offlineadressbuch (455). Sie sollte annähernd der Anzahl der Postfächer, Gruppen, Kontakte und E-Mail-aktivierten öffentlichen Ordner in der Organisation entsprechen, die nicht in Adresslisten verborgen sind. 쐍 Die in die einzelnen OAB-Datensätze aufgenommenen Attribute (konfigurierte Attribute). Einige von ihnen erlauben die Auflösung nicht eindeutiger Namen (Ambiguous Name Resolution, ANR), was bedeutet, dass Sie das Offlineadressbuch nach Teilentsprechungen von Attributen wie Nachname und Büroname durchsuchen können. Sie können beispielsweise alle Benutzer im Londoner Büro finden, indem Sie in das Suchfeld Lond eingeben (mit einem Klick auf Mehr Spalten zwingen Sie das Offlineadressbuch, mehr als die Standardnamensuche durchzuführen).
752
Da es sich um eine ANR-Suche handelt, gibt das Offlineadressbuch auch Benutzer zurück, deren Nachname mit »Lond« beginnt. Andere Attribute enthalten einfache Werte, beispielsweise die E-Mail-Info-Attribute. 쐍 Eine Angabe, wie lange Differenzdateien auf dem Server aufbewahrt werden (30 Tage) 쐍 Die virtuellen Verzeichnisse auf den Servern ExServer1 und ExServer2 für die webgestützte Verteilung der OAB-Dateien Die Liste der konfigurierten Attribute wurde in der Ausgabe gekürzt dargestellt. Eine vollständige Liste zeigen Sie mit folgendem Befehl an: $LA = Get-OfflineAddressBook –Identity '\Default Offline Address Book' $L2 =$LA.ConfiguredAttributes $L2 | Format-Table –AutoSize Name
Type
--------
-------
OfficeLocation
ANR
ProxyAddresses
ANR
PhoneticGivenName
ANR
GivenName
ANR
PhoneticSurname
ANR
Surname
ANR
Account
ANR
PhoneticDisplayName
ANR
DisplayNameUnicode
ANR
ExternalMember
Value
TotalMemberCount
Value
ModerationEnabled
Value
DelivContLength
Value
MailTipTranslations
Value
ObjectGuid
Value
IsOrganizational
Value
HabSeniorityIndex
Value
DisplayTypeEx
Value
DisplayNamePrintableA
Value
HomeMdbA
Value
Certificate
Value
UserSMimeCertificate
Value
UserCertificate
Value
Comment
Value
PagerTelephoneNumber
Value
AssistantTelephoneNumber
Value
MobileTelephoneNumber
Value
PrimaryFaxNumber
Value
753
Postfachunterstützungsdienste
Das Offlineadressbuch
Kapitel 12
Postfachunterstützungsdienste
otherHomePhone
Value
otherTelephone
Value
HomeTelephoneNumber
Value
TargetAddress
Value
PhoneticDepartmentName
Value
DepartmentNameUnicode
Value
Assistant
Value
PhoneticCompanyName
Value
CompanyName
Value
Title
Value
Country
Value
PostalCode
Value
StateOrProvince
Value
Locality
Value
StreetAddress
Value
Initials
Value
BusinessTelephoneNumber
Value
SendRichInfo
Value
ObjectType
Value
DisplayType
Value
RejectMessagesFromDLMembers
Indicator
AcceptMessagesOnlyFromDLMembers
Indicator
RejectMessagesFrom
Indicator
AcceptMessagesOnlyFrom
Indicator
UmSpokenName
Indicator
ThumbnailPhoto
Indicator
Welche Attribute in ein Offlineadressbuch aufgenommen werden, lässt sich mithilfe des Cmdlets SetOfflineAddressBook festlegen. Ein wirklich einfaches Offlineadressbuch mit nur drei Attributen generieren Sie wie folgt: Set-OfflineAddressBook –Identity 'Default Offline Address Book' –ConfiguredAttributes 'Surname, ANR','GivenName, ANR', 'Account, ANR'
Jedes Attribut wird durch seinen MAPI-Eigenschaftsnamen und seinen Typ definiert, der ANR, Value oder Indicator lauten kann. Den richtigen Typ für die einzelnen Attribute finden Sie in der vorstehenden Ausgabe. Falls Sie mit dem Ergebnis nicht zufrieden sind und zur Standardsituation zurückkehren wollen, verwenden Sie folgenden Befehl: Set-OfflineAddressBook –Identity 'Default Offline Address Book' –UseDefaultAttributes
Eine kleine Gruppe von Attributen ist mit dem Typ Indicator aufgeführt, d.h., Outlook muss jedes Mal auf Active Directory zugreifen, wenn es die Attributdaten abruft. In Kapitel 3, »Die ExchangeVerwaltungsshell«, haben Sie erfahren, wie Sie mit der Exchange-Verwaltungsshell ein kleines JPEGBild (weniger als 10 kB) in Active Directory importieren, um das Attribut ThumbnailPhoto zu füllen. 754
Dieses Attribut steht als Indikator in der Liste und wird nicht in das Offlineadressbuch heruntergeladen, sodass es offline nicht zur Verfügung steht. Sie können den Attributtyp auf Value setzen, um die Aufnahme von Miniaturfotos ins Offlineadressbuch zu erzwingen. Dies ist eine akzeptable Option, wenn Sie die Datenmenge begrenzen, die dem Offlineadressbuch dadurch hinzugefügt wird und später von den Clients heruntergeladen werden muss. TIPP Sie können den Benutzerobjekten nach und nach Miniaturbilder hinzufügen, um die Aktivität für das Herunterladen über mehrere Wochen zu verteilen, oder festlegen, dass nur Benutzerobjekte für Personen wie Vorstandsmitglieder oder andere wichtige Persönlichkeiten mit Miniaturbildern versehen werden. Am ungünstigsten ist es, Bilder für alle zu sammeln und mithilfe eines Skripts übers Wochenende in Active Directory zu laden, weil es zu explosionsartiger Aktivität kommen kann, wenn die Clients bei der nächsten Verbindung mit Exchange ein aufgeblähtes Offlineadressbuch herunterladen müssen. Da es sich bei Active Directory um eine Hochleistungsdatenbank handelt, wird es durch ein massenhaftes Hochladen von Miniaturbildern nicht beeinträchtigt, und die sich allmählich ausbreitende Auswirkung der Replikation auf die gesamte Organisation ist wahrscheinlich gering. Im Vergleich zur Anzahl der Clients brauchen nur relativ wenige globale Kataloge mit den Miniaturfotos aktualisiert zu werden. Für Outlook sieht die Situation allein aufgrund der Anzahl der Clients anders aus. Nehmen Sie Änderungen an vielen Objekten gleichzeitig vor, führt dies wahrscheinlich dazu, dass jeder Client das ganze Offlineadressbuch herunterladen muss. Stellen Sie sich vor, Sie versehen 10.000 Benutzerobjekte mit Minifotos. Möglicherweise sind es pro Objekt nur 9 kB, aber auch das sind etwa 88 MB, die Outlook herunterladen muss, um Aktualisierungen des Offlineadressbuchs abzurufen. Rechnen Sie dies für 12.000 Clients hoch, haben Sie ungefähr 1029 GB Daten, die die Clients herunterladen müssen, bis alle das aktuelle Offlineadressbuch mitsamt den Minifotos haben. Aus diesem Grund möchten Sie das Attribut ThumbnailPhoto vielleicht lieber ganz und gar aus den Adressbuchattributen herausnehmen. Dazu gehen Sie wie folgt vor: $NewSet = (Get-OfflineAddressBook "Default Offline Address Book").ConfiguredAttributes $NewSet.Remove("ThumbnailPhoto,Indicator") Set-OfflineAddressBook "Default Offline Address Book" -ConfiguredAttributes $NewSet
Aktualisieren der OAB-Dateien Sie können die OAB-Dateien jederzeit manuell mit der Option Aktualisieren in der Exchange-Verwaltungskonsole oder mithilfe des Cmdlets Update-OfflineAddressBook generieren: Update-OfflineAddressBook –Identity '\Default Offline Address Book'
Exchange protokolliert das Ereignis 9107, wenn die neuen OAB-Dateien verfügbar sind. Haben Sie den Verdacht, dass bei der Generierung des Offlineadressbuchs Probleme auftreten, können Sie die Diagnoseprotokollstufe erhöhen, um Exchange zu zwingen, weitere Ereignisse im Anwendungsereignisprotokoll festzuhalten: Set-EventLogLevel –Identity 'ExServer4\MSExchangeSA\OAL Generator' -Level 'Expert'
755
Postfachunterstützungsdienste
Das Offlineadressbuch
Kapitel 12
Postfachunterstützungsdienste
Wenn die neuen OAB-Dateien vorliegen, können Sie ausgewählte Clientzugriffsserver mithilfe des Cmdlets Update-FileDistributionService zwingen, Aktualisierungen abzurufen, ohne auf den Ablauf des festgelegten Intervalls zu warten. Für den Clientzugriffsserver ExchCAS1 sieht das wie folgt aus: Update-FileDistributionService –Identity 'ExchCAS1' –Type OAB
Verschieben des Servers für die OAB-Generierung Der erste Postfachserver in der Organisation ist möglicherweise nicht der geeignetste, um das Offlineadressbuch zu generieren. Sie können diese Aufgabe jedem anderen Poastfachserver der Organisation überragen, auf dem Exchange Server 2010 läuft. Dazu wählen Sie im Aktionsfenster die Option Verschieben, um den Assistenten zum Verschieben des Offlineadressbuchs zu starten. Wie Abbildung 12.18 zeigt, öffnet sich eine Liste, in der Sie einen anderen Postfachserver auswählen können. Anschließend kopiert Exchange den aktuellen Satz der OAB-Dateien (die in Abbildung 12.16 gezeigten) auf diesen Server, sodass Sie sie danach vom alten Server löschen können. Diese Aufgabe lässt sich auch mit dem Cmdlet Move-OfflineAddressBook erledigen: Move- OfflineAddressBook -Identity '\Default Offline Address Book' -Server 'ExServer4' Abbildg. 12.18 Verschieben des Servers für die OAB-Generierung
756
Das Offlineadressbuch
Standardmäßig ist nur der erste Clientzugriffsserver in der Organisation als Webzugriffspunkt für Clients mit Outlook 2007 und Outlook 2010 zum Herunterladen von Adressbuchdateien eingerichtet. Bei den virtuellen Verzeichnissen unter Webbasierte Verteilung in Abbildung 12.17 finden Sie nur einen einzigen Server. Sie können weitere hinzufügen, um die Last auf die gesamte Organisation zu verteilen und sicherzustellen, dass Clients einen lokalen Clientzugriffsserver erreichen können, anstatt eine weite Verbindung zu einem zentralen Server aufbauen zu müssen. Idealerweise sollten Sie mindestens an jedem Active Directory-Standort einen Clientzugriffsserver einrichten, um einen Webverteilungspunkt für OAB-Dateien zu haben. Um neue Server in die Liste aufzunehmen, klicken Sie auf Hinzufügen und wählen aus der Liste weitere Clientzugriffsserver aus. Alternativ können Sie auch die Exchange-Verwaltungsshell nutzen: Set-OfflineAddressBook -Identity '\Default Offline Address Book' -VirtualDirectories 'ExServer1\OAB (Default Web Site)', 'ExServer2\OAB (Default Web Site)'
Die Clientzugriffsserver müssen die Aktualisierungen des Offlineadressbuchs vom Server für die OAB-Generierung abrufen. Abbildung 12.19 zeigt die Eigenschaften der OAB-Standardwebsite. Sie sehen, dass das Standardabrufintervall 480 Minuten (8 Stunden) beträgt. In manchen Umgebungen ist ein längeres Intervall gerechtfertigt, weil OAB-Dateien dort einmal täglich generiert werden. Um das Intervall auf 720 Minuten (12 Stunden) zu setzen, können Sie die Exchange-Verwaltungskonsole oder folgenden Befehl benutzen: Get-OABVirtualDirectory | Set-OABVirtualDirectory –PollInterval 720 Abbildg. 12.19 Eigenschaften der OAB-Website
757
Postfachunterstützungsdienste
Webgestützte Verteilung
Kapitel 12
Postfachunterstützungsdienste
Um die Aktualisierungen zu bekommen, fragen die dafür vorgesehenen Clientzugriffsserver den Server für die Generierung des Offlineadressbuchs im definierten Intervall ab und untersuchen das OAB-Manifest. Werden neue Dateien gefunden, kopiert der Exchange-Dateiverteilungsdienst (MSExchangeFDS) sie mithilfe des intelligenten Hintergrundübertragungsdienstes (Background Intelligent Transfer Service, BITS) auf die Clientzugriffsserver. BITS aktiviert den Dateiverteilungsdienst, um die Dateien in kleinen Stücken zu übertragen, damit selbst umfangreiche Dateien wie das vollständige Offlineadressbuch Netzwerke mit geringer Bandbreite oder hoher Latenz effizient durchlaufen, selbst wenn die Übertragung einige Stunden dauert. HINWEIS Diese Fähigkeit zur effizienten Dateiübertragung ist ein bedeutender Faktor, um Clientzugriffsservern an räumlich weit entfernten Standorten Dateien zur Verfügung stellen zu können. Die neuen Dateien werden Clients erst dann zugänglich gemacht, wenn sie vollständig kopiert und überprüft sind (dann zeichnet der Dateiverteilungsdienst das Ereignis 1008 auf). Anschließend können die Clients Verbindung mit ihrem lokalen Clientzugriffsserver aufnehmen und die Aktualisierungen abrufen. Outlook ermittelt mithilfe des AutoErmittlungsdienstes den nächstgelegenen Clientzugriffsserver, der OAB-Dateien anbietet, und entnimmt dem OAB-Manifest, welche Dateien es vom Webverteilungspunkt kopieren muss. Es ist natürlich vorstellbar, dass Clients an verschiedenen Standorten einfach deshalb unterschiedliche Adressbuchversionen benutzen, weil bei der Verteilung der Dateien vorübergehende Probleme aufgetreten sind. Mit der Zeit sollten diese aber verschwinden und alle Clients dasselbe Offlineadressbuch einsetzen. Insidertipp: Verteilung über öffentliche Ordner
Seit der ältesten Exchange-Version werden Adressbuchaktualisierungen den Clients über öffentliche Ordner zur Verfügung gestellt. Die Zeit öffentlicher Ordner neigt sich jedoch dem Ende zu, und heute nehmen wahrscheinlich nur Clients mit Outlook 2003 Verbindung zu öffentlichen Ordnern auf, um OAB-Aktualisierungen abzurufen. Wird die Verteilung über öffentliche Ordner eingesetzt, aktualisiert der Server zum Generieren des Offlineadressbuchs die relevanten Ordner, nachdem er die Adressbuchdateien erstellt hat. Wie in Abbildung 12.20 gezeigt, unterhält Exchange für jede Adressbuchversion einen eigenen Ordner. Diese Ordner können Sie in andere Datenbanken für öffentliche Ordner replizieren, sodass die Clients zum Herunterladen Verbindung mit einem lokalen Replikat aufnehmen können. Abbildg. 12.20 Öffentliche Ordner für die Verteilung des öffentlichen Adressbuchs
758
Erstellen und Verwenden benutzerdefinierter Offlineadressbücher Die Grundlage für das Offlineadressbuch bilden eine oder mehrere Adresslisten. Das Standard-Offlineadressbuch enthält nur eine Liste, die standardmäßige globale Adressliste. Jedes darin enthaltene Objekt steht daher auch im Standard-Offlineadressbuch. Eine Adressliste ist nichts anderes als eine bequeme Möglichkeit für Exchange, eine Reihe E-Mail-aktivierter Active Directory-Objekte mithilfe eines Filters zu suchen. Die Filter ähneln denen, die zur Zusammenstellung der Mitglieder dynamischer Verteilungsgruppen verwendet werden. Jede Adressliste hat einen Filter, und im Offlineadressbuch verwendet Exchange die Filter aller darin enthaltenen Listen. Wenn das Standard-Offlineadressbuch erstellt wird, benutzt Exchange also den Filter »standardmäßige globale Adressliste«, um sämtliche E-Mail-aktivierten Objekte in der Organisation zu finden, die nicht als verborgen markiert sind. Das Offlineadressbuch, das Outlook-Clients bereitgestellt wird, lässt sich auf zwei Arten ändern. Zum einen können Sie auf der Grundlage verschiedener Adresslisten ein neues Offlineadressbuch anlegen, das maßgeschneidert ist und die Benutzer enthält, die Sie ausgewählt haben, und das normale Adressbuch durch das neue ersetzen, indem Sie es als Standard markieren. Zum anderen können Sie ein oder mehrere Offlineadressbücher erstellen, die Sie unterschiedlichen Benutzergruppen zuweisen. Dazu weisen Sie ein Offlineadressbuch einzelnen Postfächern oder einer Datenbank zu, sodass jedes Postfach in dieser Datenbank es benutzt. Unterhält Ihre Exchange-Organisation einen allgemeinen Satz von Benutzern, die jeder kennen muss, ist es nicht erforderlich, das standardmäßige Offlineadressbuch zu wechseln, weil es den Zweck des Offlinezugriffs auf das Verzeichnis angemessen erfüllt. Hostingfirmen, die anderen Unternehmen Exchange-Dienste zur Verfügung stellen, verwenden dagegen Adresslisten, um jedem Kunden ein maßgeschneidertes Offlineadressbuch mit den zu ihm gehörenden Benutzern bereitzustellen. Niederlassungen mit einer gemeinsamen Exchange-Infrastruktur
Große Unternehmen mit mehreren Niederlassungen und einer gemeinsamen Exchange-Infrastruktur verfolgen häufig denselben Ansatz wie Hostingfirmen, damit die Benutzer in den einzelnen Niederlassungen in ihrem Offlineadressbuch nur die Kollegen aus derselben Niederlassung sehen (und vielleicht zusätzlich Benutzer aus Unternehmensabteilungen, mit denen alle zu tun haben). Dazu werden neue Adresslisten angelegt, die die verschiedenen Benutzergemeinschaften ausfiltern, und dann daraus unterschiedliche Offlineadressbücher erstellt, die anschließend den Benutzern zugewiesen werden. Bevor wir uns zu sehr in das Anlegen eines neuen Adressbuchs vertiefen, sollten wir noch einmal unterstreichen, dass Offlineadressbücher nur für Outlook-Clients von Nutzen sind, die im ExchangeCache-Modus arbeiten. Online arbeitende Clients haben Zugriff auf die gesamte globale Adressliste, sofern sie nicht durch Änderungen an der Zugriffssteuerung und andere Einstellungen in Active Directory eingeschränkt sind. Die folgende Anleitung zeigt die Schritte, die ein Exchange-Administrator unternehmen muss, um ein neues Offlineadressbuch anzulegen, und geht nicht auf alle Änderungen ein, die an Active Directory vorgenommen werden müssen. Diese sind von Natur aus umfassend und tiefgreifend und sollten nicht von einem Active Directory-Neuling durchgeführt werden.
759
Postfachunterstützungsdienste
Das Offlineadressbuch
Kapitel 12
Postfachunterstützungsdienste
Microsoft hat ein Whitepaper zur Erstellung segmentierter Offlineadressbücher für Exchange Server 2007 herausgegeben, doch für Exchange Server 2010 hat die Entwicklungsgruppe bis jetzt noch keine ebenso ausführliche Dokumentation veröffentlicht. Überlegen wir vor diesem Hintergrund, wie wir ein neues Offlineadressbuch erstellen, das einer Benutzergruppe an einem bestimmten Ort zugewiesen werden soll und nur die dortigen E-Mail-aktivierten Objekte enthält. Unsere erste Aufgabe besteht darin, eine geeignete Adressliste zusammenzustellen. Wir können eine neue anlegen, die alle E-Mail-aktivierten Objekte für den Ort enthält, oder für jeden Objekttyp (Kontakte, Räume, Geräte, Postfächer und Gruppen) eine eigene und diese zu dem Offlineadressbuch kombinieren, das wir schließlich generieren. Exchange führt Adresslisten wie Alle Räume oder Alle Kontakte, um die entsprechenden Objekte für verschiedene Zwecke leichter auffindbar zu machen. In diesem Fall würden mehrere Adresslisten die Angelegenheit wahrscheinlich übermäßig kompliziert machen, sodass wir uns der Einfachheeit halber auf eine Liste beschränken. Zunächst öffnen wir den Knoten Postfach unter Organisationskonfiguration, klicken auf die Registerkarte Adresslisten und dann auf Neue Adressliste. Im ersten Schritt des Assistenten benennen wir die neue Adressliste und entscheiden, ob sie einer vorhandenen Liste (oder einem Container) untergeordnet werden oder auf der obersten Ebene liegen soll. Eine untergeordnete Adressliste kann etwa Kontakte in Zürich sein und unter der Liste Alle Kontakte angelegt werden, wobei die Kontakte in Zürich mithilfe eines geeigneten Filters ausgewählt werden. Der Name des neuen Objekts gibt deutlich den Zweck an, nämlich als Adressliste der Benutzer in Dublin zu dienen. Aus den weiteren Angaben in Abbildung 12.21 geht auch seine Position als Container auf der obersten Ebene (»\«) eindeutig hervor. Abbildg. 12.21 Erstellen einer neuen Adressliste
Im nächsten Schritt geht es um den Active Directory-Empfängercontainer, auf den der Filter angewendet werden soll. Es kann sein, dass alle Zielobjekte in derselben Organisationseinheit gespeichert sind, sodass Sie diese als Empfängercontainer verwenden können. Andernfalls wählen Sie den Stamm des Verzeichnisses, damit der Filter alle in Frage kommenden Objekte findet. Außerdem müssen Sie angeben, ob alle E-Mail-aktivierten Objekte ausgewählt werden sollen oder nur die eines bestimmten Typs.
760
Danach fahren wir mit der Auswahl der anzuwendenden Filterbedingungen fort. Dies ist vertrautes Gebiet für jeden, der schon einmal eine dynamische Verteilergruppe erstellt hat. Der für unsere Adressliste benutzte Filter ist ganz einfach, weil er lediglich alle Objekte mit »Dublin« im benutzerdefinierten Attribut 2 sucht. Abbildung 12.22 zeigt, wie Sie den Filter testen, um zu gewährleisten, dass er die Objekte, die wir in die Adressliste aufnehmen wollen, sauber identifiziert. Es ist möglich, eine neue Adressliste auf der Grundlage des Filters für eine dynamische Verteilergruppe anzulegen, da beide Objekte ähnliche Empfängerfilter verwenden: New-AddressList –Name 'Corporate Functions' –RecipientFilter (Get-DynamicDistributionGroup 'Corporate Functions').RecipientFilter Abbildg. 12.22 Testen des Filters für eine Adressliste
Wenn Sie eine Adressliste mit einem Empfängerfilter dieser Art erstellen, können Sie die Filterbedingungen nicht mithilfe des Assistenten bearbeiten und müssen Aktualisierungen über die Shell vornehmen. Kehren wir zu unserer Adressliste zurück, so besteht der nächste Schritt darin, den Zeitplan für ihre Aktualisierung zu definieren, also dafür, dass wir den Filter auf Active Directory anwenden. Üblicherweise lassen Sie dies sofort geschehen, sofern Sie keinen besonderen Grund haben, eine Zeit lang zu warten. Die Aktualisierung der Adressliste spielt in der Praxis keine große Rolle, weil wir sie in Verbindung mit einem Offlineadressbuch einsetzen wollen und Exchange die Daten dafür mithilfe des Filters generiert. Im letzten Schritt erlauben wir Exchange, das neue Adresslistenobjekt anzulegen und die Liste zu aktualisieren. Die Befehle der Exchange-Verwaltungsshell finden Sie im folgenden Code. Sie sehen, dass als Active Directory-Speicherort eine Organisationseinheit namens Exchange Users verwendet wird. Alle E-Mail-aktivierten Empfänger in dieser Organisationseinheit und alle untergeordneten Organisationseinheiten werden von dem Filter erfasst. New-AddressList -Name 'Dublin mail-enabled objects' -RecipientContainer 'contoso.com/Exchange Users' -IncludedRecipients 'AllRecipients' -Container '\' -ConditionalCustomAttribute2 'Dublin' -DisplayName 'Dublin mail-enabled objects' Update-AddressList -Identity '\Dublin mail-enabled objects'
761
Postfachunterstützungsdienste
Das Offlineadressbuch
Kapitel 12
Postfachunterstützungsdienste
Sobald die Adressliste angelegt und aktualisiert ist, stehen die darin enthaltenen Objekte den Onlinebenutzern zur Verfügung. OWA-Benutzer, die auf die globale Adressliste zugreifen, sehen im Adressbuch normalerweise nur die globale Standardliste und Alle Räume (links oben auf dem Bildschirm). Andere Adresslisten wie unsere neue Liste werden eingeblendet, wenn Sie auf Andere Adresslisten anzeigen klicken. Da wir jetzt eine Liste haben, können wir fortfahren und ein neues Offlineadressbuch erstellen. Starten Sie mit der Option Neues Offlineadressbuch den Assistenten. Wir müssen dem neuen Objekt einen Namen geben, den Postfachserver angeben, der die Adressbuchdateien generieren soll, und Exchange mitteilen, aus welchen Adresslisten das Offlineadressbuch erstellt werden soll (siehe Abbildung 12.23). Abbildg. 12.23 Anlegen eines neuen Offlineadressbuchs
Als Nächstes legen wir fest, wie wir das neue Offlineadressbuch verteilen. Dies kann über das Web oder über öffentliche Ordner erfolgen. Die webgestützte Verteilung setzt voraus, dass wir eine Liste von Clientzugriffsservern definieren, von denen Clients die OAB-Aktualisierungen abrufen können (siehe Abbildung 12.24). Im letzten Schritt legen wir das Adressbuch an, wobei Code wie der folgende ausgeführt wird. Sie sehen, dass die von uns erstellte Adressliste die einzige in diesem Offlineadressbuch ist. New-OfflineAddressBook -Name 'Dublin OAB' -Server 'ExServer1' -AddressLists ' \Dublin mail-enabled objects' -PublicFolderDistributionEnabled $True -VirtualDirectories 'ExServer1\OAB (Default Web Site)','ExServer2\OAB (Default Web Site)'
Die Dateien für das Offlineadressbuch werden nach dem für den vorgesehenen Server definierten Zeitplan erstellt und stehen den Benutzern erst dann zur Verfügung, nachdem der Prozess OABGen ausgeführt wurde. Mithilfe des Cmdlets Update-OfflineAddressBook können Sie wie folgt erzwingen, dass das Adressbuch generiert wird: Update-OfflineAddressBook –Identity 'Dublin OAB'
762
Das Offlineadressbuch
Postfachunterstützungsdienste
Abbildg. 12.24 Festlegen der webgestützten Verteilung für das neue Offlineadressbuch
Um sich davon zu überzeugen, dass die neuen OAB-Dateien verfügbar sind, sehen Sie in der Freigabe ExchangeOAB auf dem Server nach, auf dem der Prozess läuft. Jedes Adressbuch legt seine Dateien in einem eigenen Verzeichnis mit dem global eindeutigen Bezeichner (Global Unique Identifier, GUID) ab, mit dem Exchange das Offlineadressbuch intern versieht. Sie finden den Bezeichner, der sowohl für das Verzeichnis als auch für das dazugehörige Adressbuch gilt, mit folgendem Befehl: Get-OfflineAddressBook | Select Name, GUID
Jetzt haben wir ein neues Offlineadressbuch und können es einzelnen Postfächern oder allen in einer Datenbank vorhandenen zuweisen. Für ein einzelnes Postfach benutzen wir das Cmdlet Set-Mailbox: Set-Mailbox –id 'David Jones' –OfflineAddressBook 'Dublin OAB'
Wenn Sie Set-Mailbox durch Set-MailboxDatabase ersetzen, gilt die Zuweisung einer Postfachdatenbank: Set-MailboxDatabase –Identity 'Dublin mailboxes' –OfflineAddressBook 'Dublin OAB'
Alternativ können Sie in der Exchange-Verwaltungskonsole die Datenbank auswählen und das Offlineadressbuch auf der Registerkarte Clienteinstellungen festlegen. Ist für eine Postfachdatenbank nicht explizit ein Adressbuch ausgewählt, verwendet Exchange das aktuelle Standardadressbuch. Um ein neues Offlineadressbuch zum Standard zu machen, benutzen Sie den folgenden Befehl. Grundsätzlich kann nur ein Offlineadressbuch als Standard markiert sein. Set-OfflineAddressBook –Identity 'Dublin OAB' –IsDefault $True
763
Kapitel 12
Postfachunterstützungsdienste
Mit den hier gezeigten Schritten legen Sie ein neues Offlineadressbuch an und verteilen es an die Benutzer, hindern sie aber nicht daran, auf die globale Adressliste zuzugreifen, wenn sie online arbeiten. Um den Zugriff auf die Standardadresslisten zu unterbinden, müssen wir die schon erwähnten Änderungen an Active Directory vornehmen.
Unterstützung für E-Mail-Infos im Offlineadressbuch Die in Exchange Server 2010 eingeführten E-Mail-Infos wären eine Teillösung, wenn sie nur bei einer Onlineverbindung funktionierten. Deshalb hat Microsoft die Struktur des Offlineadressbuchs um eine Reihe neuer E-Mail-Info-Eigenschaften für Empfänger erweitert, die es Outlook erlauben, E-Mail-Infos offline zu verarbeiten. Dabei handelt es sich um folgende: 쐍 Einschränkungen für die Zustellung von Nachrichten 쐍 Benutzerdefinierte E-Mail-Infos 쐍 Maximalgröße für den Empfang Außerdem gibt es einige neue Eigenschaften für Gruppen: 쐍 Moderation aktiviert 쐍 Gesamtzahl der Mitglieder 쐍 Anzahl der externen Mitglieder Mit Ausnahme der Mitgliederzählungen werden diese Daten aus Active Directory abgerufen. Die Mitgliederzahlen stammen aus den Gruppenmessgrößen. Bedingungen, die sich offline nicht berücksichtigen lassen
Selbst bei Zugriff auf das Offlineadressbuch gibt es einige Bedingungen, die sich offline nicht berücksichtigen lassen, zum Beispiel, wenn ein Empfängerpostfach sein Kontingent kurzfristig überschreitet, wenn ein neues Postfach in Active Directory aufgenommen wird und erst beim Download der nächsten Aktualisierung ins Offlineadressbuch gelangt oder wenn ein Benutzer eine Abwesenheitsnotiz schreibt. Die E-Mail-Info über einen ungültigen internen Empfänger (zum Beispiel die Adresse eines gerade gelöschten Postfachs) steht ebenfalls offline nicht zur Verfügung.
OABInteg und das Blog von Dave Goldman Die Fehlersuche bei Problemen mit dem Offlineadressbuch kann kompliziert sein. Das meiste geschieht im Hintergrund, und Exchange oder Outlook geben nicht viele Details preis, wenn etwas falsch läuft, zum Beispiel wenn ein Benutzer das Offlineadressbuch nicht herunterladen kann. Das Microsoft-Hilfsprogramm OABInteg hilft Ihnen zu ermitteln, was beim Generieren und Verteilen von OAB-Dateien vor sich geht, und deren Inhalt zu überprüfen. Eine Kopie von OABInteg können Sie aus dem Artikel 907792 der Microsoft Knowledge Base herunterladen, und unter http:// blogs.msdn.com/dgoldman/archive/2005/08/28/oabinteg-and-how-to-use-it-to-troubleshoot-oab-generation-issues.aspx können Sie alles darüber lesen. Das Blog gehört dem Exchange-Ingenieur Dave Goldman, und ist eine hervorragende Informationsquelle, was die zahlreichen Fragen rund um diese Exchange-Funktion betrifft.
764
Das hierarchische Adressbuch Das Standardadressbuch wird dem Bedarf der meisten Firmen gerecht. Die Sortierung der Benutzer und Gruppen nach Vor- oder Nachnamen funktioniert jedoch in Unternehmen nicht so gut, deren Kultur in hohem Maß auf der Einhaltung einer hierarchischen Struktur beruht, insbesondere in ostasiatischen Ländern. In diesen Fällen ist es erwünscht, die Organisation nach Rang zu präsentieren, sodass die wichtigsten Mitglieder an erster Stelle stehen. Die Benutzer können das Adressbuch dann von oben nach unten durchsuchen und dabei der Struktur der Organisation folgen. Sie können beispielsweise vom Vorstandsvorsitzenden zu den Vizepräsidenten gehen, die wichtige Abteilungen leiten, dann zu den Direktoren, den Managern und schließlich zu einzelnen Personen. Um ein hierarchisches Adressbuch (HAB) einzurichten, ist die Kombination von Exchange 2010 SP1 und Outlook 2010 oder Outlook 2007 SP2 (oder höher) erforderlich. Mit den folgenden Schritten können Sie ein neues HAB anlegen. Die Schritte 1 und 3 sind insofern optional, als Sie für ein HAB streng genommen keine dedizierte Organisationseinheit brauchen. Sie erlaubt jedoch eine klare Trennung zwischen den Objekten, die das hierarchische Adressbuch bilden, und den übrigen Exchange-Gruppen und -Benutzern. Die Schritte 4 und 5 lassen sich zu einem Satz von Set-Group-Befehlen zusammenfassen. Sie stehen hier isoliert, um hervorzuheben, dass zwei unterschiedliche Eigenschaften gesetzt werden müssen, um Objekte in das hierarchische Adressbuch aufzunehmen. 1. Legen Sie in Active Directory eine Organisationseinheit als Container für die Gruppen und
Benutzerobjekte an, die das hierarchische Adressbuch bilden sollen. 2. Geben Sie in der Organisationskonfiguration den Alias der Gruppe an, die als Stamm des hierar-
chischen Adressbuchs fungiert. Hier legen wir eine Gruppe, die die E-Mail-Adresse des Vorstandsvorsitzenden enthält, als Stamm des hierarchischen Adressbuchs fest. Set-OrganizationConfig –HierarchicalAddressBook DG-CEO1 3. Fügen Sie der Organisationseinheit die Gruppen und Benutzer hinzu, die in das hierarchische
Adressbuch aufgenommen werden sollen. Auch dies ist ein optionaler Schritt. 4. Setzen Sie für jedes Gruppenobjekt, das im hierarchischen Adressbuch stehen soll, die Eigenschaft
IsHierarchicalGroup auf $True. Set-Group –Identity DG-CEO1 –IsHierarchicalGroup $True 5. Setzen Sie für jedes Gruppen- und Benutzerobjekt, das im hierarchischen Adressbuch erscheinen
soll, die Eigenschaft SeniorityIndex auf einen Integerwert, anhand dessen Exchange das hierarchische Adressbuch sortiert. Ein Objekt mit dem Wert 1 für SeniorityIndex steht an der Spitze. Stellt Ihr Vorstandsvorsitzender die Spitze der Organisation dar, setzen Sie diesen Wert also für sein Benutzerobjekt auf 1 (oder für das Gruppenobjekt, das den Vorstandsvorsitzenden und die Mitglieder seines Stabs enthält). Gruppen und Benutzer, die weiter unten in der Hierarchie stehen, erhalten höhere Werte für SeniorityIndex. Set-Group –Identity DG-CEO1 –SeniorityIndex 1 Set-User –Identity MyCEO –SeniorityIndex 1 Set-User –Identity DG-SeniorVP1 –SeniorityIndex 2 6. Sorgen Sie dafür, dass die Gruppen jeder Stufe die Gruppen der darunterliegenden enthalten,
damit die Mitglieder jeder Stufe angezeigt werden, wenn sich ein Benutzer durch die Hierarchie bewegt. Das hierarchische Adressbuch in Abbildung 12.25 verwendet beispielsweise organisationsinterne Titel vom Vorstandsvorsitzenden abwärts als Grundlage der Hierarchie. Um diese
765
Postfachunterstützungsdienste
Das hierarchische Adressbuch
Kapitel 12
Postfachunterstützungsdienste
Ansicht zu erstellen, ist die Gruppe VPs - Level 2 Mitglied der Gruppe CEO - Level 1, die Gruppe Directors - Level 3 Mitglied der Gruppe VPs - Level 2 und die Gruppe Senior Managers - Level 4 Mitglied der Gruppe Directors - Level 3. Diese verschachtelte Anordnung setzt sich für den Rest der Hierarchie fort. Abbildg. 12.25 Ansicht eines hierarchischen Adressbuchs
7. Für japanische hierarchische Adressbücher können Sie außerdem die Eigenschaft PhoneticDis-
playName für Gruppen und Benutzer setzen. Outlook sortiert das hierarchische Adressbuch zunächst nach SeniorityIndex und anschließend nach PhoneticDisplayName. Set-Group –Identity DG-HAB-Group1 –PhoneticDisplayName 'HAB Group 1' Set-User –Identity User-HAB1 –PhoenticDisplayName 'User 1' 8. Öffnen Sie Outlook 2010 oder Outlook 2007 und greifen Sie auf das Adressbuch zu. Klicken Sie
auf die Registerkarte Organisation, um das hierarchische Adressbuch einzublenden. In einer Organisation ist nur ein einziges hierarchisches Adressbuch möglich, und hierarchische Adressbücher lassen sich nur von Outlook-Clients anzeigen, die für den Exchange-Cache-Modus eingerichtet sind und erfolgreich ein Offlineadressbuch heruntergeladen haben, das nach der beschriebenen Änderung der Gruppeneigenschaften erstellt wurde.
Postfachassistenten Exchange stellt eine Reihe von Postfachassistenten bereit, um eine automatische Verarbeitung für verschiedene Aspekte der in den Postfächern enthaltenen Daten zu ermöglichen. Ein Assistent ist einfach ein anderer Name für einen Thread, der innerhalb des Prozesses Microsoft Exchange-Systemaufsicht auf einem Postfachserver ausgeführt wird. Exchange Server 2010 verwendet zwei Arten von Assistenten:
766
Postfachassistenten
Sie reagieren auf auftretende Ereignisse. Der Assistent für Ressourcenbuchung überwacht zum Beispiel Anforderungen zur Belegung von Räumen und lässt die Benutzer wissen, dass ein Raum nicht verfügbar ist. 2. Einschränkungsbasierte Assistenten Sie sind ständig in Betrieb, um Daten zu verarbeiten, und unterliegen der Einschränkung, um sicherzustellen, dass die durch sie hervorgerufene Last die Reaktionsfähigkeit eines Servers nicht beeinträchtigt. Der bekannteste von ihnen ist der Assistent für verwaltete Ordner.
Zu den bekannteren Assistenten zählen folgende: 쐍 Kalenderassistent Er prüft Postfächer auf eingehende Besprechungsanforderungen und verarbeitet sie entsprechend den Postfacheinstellungen. 쐍 Assistent für Ressourcenbuchung Gerätepostfächer.
Er verarbeitet Besprechungsanforderungen für Raum- und
쐍 Zeitplanassistent Er durchsucht Teilnehmerkalender nach geeigneten Besprechungsfenstern und schlägt sie den Organisatoren der Besprechung vor. 쐍 Assistent für Junk-E-Mail-Optionen Er kopiert Daten der Listen sicherer Adressen aus Benutzerpostfächern in die entsprechenden Active Directory-Konten, damit sie von den Antispam-Agents verwendet werden können. 쐍 Assistent für verwaltete Ordner Er verarbeitet die Aufbewahrungsrichtlinien für verwaltete Ordner und wendet Tags für Aufbewahrungsrichtlinien auf Elemente in Postfächern an. Diese Assistenten sind relativ gut bekannt, weil es sie schon in früheren Exchange-Versionen gab. Aus diesem Grund konzentrieren wir uns im verbleibenden Teil dieses Abschnitts auf einen neuen Assistenten. Exchange Server 2010 SP1 enthält ein neues Test-Cmdlet, mit dem Administratoren prüfen können, ob die Postfachassistenten auf einem Server ordnungsgemäß funktionieren, sodass sie die dabei festgestellten Probleme beheben können. Der folgende Befehl startet das Cmdlet, um zu prüfen, ob die Postfachassistenten auf dem Server ExServer1 ordnungsgemäß funktionieren, und gibt die Ergebnisse dann in Listenform aus. Test-AssistantHealth –Server ExServer1 –ResolveProblems | Format-List
Der Kalenderreparaturassistent Der Kalenderreparaturassistent (Calendar Repair Assistant, CRA) ist eine neue Komponente in Exchange Server 2010, die als Bestandteil des Exchange-Postfachassistentendienstes ausgeführt wird. Er dient dazu, Inkonsistenzen in Kalenderdaten aufzuspüren und zu korrigieren, die durch gleichzeitigen Zugriff mehrerer Clients auf Kalender, durch Softwarefehler oder durch andere Faktoren verursacht worden sein können. Viele Benutzer führen heute mobile Geräte mit sich, um unterwegs auf ihren Kalender zuzugreifen, und lassen möglicherweise auch Outlook auf einem anderen Computer geöffnet und aktiv. Beide Geräte verarbeiten eingehende Kalenderanforderungen und Benachrichtigungen, woraus sich die Möglichkeit ergibt, dass sie sich in die Quere kommen und Inkonsistenzen und Mängel in die Kalenderdaten einbringen. Der Kalenderassistent soll es bemerken, wenn sich Kalenderdaten in inkonsistentem Zustand befinden, und diese Abweichungen beheben, damit die Benutzer Besprechungen oder Termine nicht aufgrund fehlerhafter Kalenderdaten verpassen. Stellt der Assistent zum Beispiel fest, dass im Kalender eines Benutzers ein Besprechungselement fehlt, dem dieser zugestimmt hat, kann er es erstellen.
767
Postfachunterstützungsdienste
1. Ereignisbasierte Assistenten
Kapitel 12
Postfachunterstützungsdienste
Weicht die Uhrzeit oder der Ort einer Besprechung in der Kopie eines Teilnehmers ab, kann der Assistent dies anhand des Exemplars des Besprechungsbesitzers korrigieren. Außerdem ist er in der Lage, Varianten bei sich wiederholenden Besprechungen festzustellen, bei denen möglicherweise einigen Teilnehmern Einträge für einige Termine fehlen. Der Kalenderassistent ist ein »stiller« Assistent, d.h., die Benutzer merken nur, dass er aktiv ist, wenn er in ihrem Auftrag handelt und sie eine Benachrichtigung darüber erhalten, dass er eine Berichtigung an ihrem Kalender vorgenommen hat. Häufig bearbeitet der Kalenderassistent folgende Probleme: 쐍 Eine Besprechung ist im Kalender eines Teilnehmers mit einer falschen Uhrzeit oder einem falschen Ort eingetragen. 쐍 Der Kalender eines Teilnehmers enthält keine Kopie einer Besprechung, obwohl er die Einladung angenommen hat. 쐍 Ein Benutzer hat die Kopie einer Besprechung im Kalender, aber sein Name erscheint nicht in der Teilnehmerliste. 쐍 Der Verfolgungsstatus der Besprechungskopie eines Teilnehmers stimmt nicht mit dem Verfolgungsstatus der Kopie des Organisators überein. 쐍 Die Kopie einer sich wiederholenden Besprechung im Kalender eines Teilnehmers stimmt nicht mit den Besprechungsdaten im Kalender des Organisators überein. 쐍 Der Kalender eines Besprechungsorganisators oder eines Teilnehmers enthält mehrere Elemente für dieselbe Besprechung. Handhabung von Datenabweichungen im Kalender eines Besprechungsteilnehmers
In den meisten Fällen liefert die Kopie des Elements im Kalender des Organisators die definitive Version für Ort und Zeit einer Besprechung, und die Korrektur durch den Kalenderassistenten besteht darin, dass er die Daten im Kalender des Teilnehmers an die des Organisators anpasst. Stellt er fest, dass eine Besprechung im Kalender eines Teilnehmers fehlt, obwohl dieser die Einladung fest oder mit Vorbehalt angenommen hat, erstellt er den Termin neu, was in der Beschreibung der Besprechung festgehalten wird. Standardmäßig durchsucht der Kalenderreparaturassistent Elemente 30 Tage im voraus und wird nach einem Zeitplan ausgeführt, der zuvor auf einem Postfachserver festgelegt werden muss. Die Einstellungen für den Kalenderreparaturassistenten lassen sich nur über die Exchange-Verwaltungsshell bearbeiten, weil es in der Exchange-Verwaltungskonsole keine Benutzerschnittstelle für diesen Zweck gibt. Mit dem Cmdlet Get-MailboxServer rufen Sie die Einstellungen für den Kalenderreparaturassistenten auf einem Postfachserver ab: Get-MailboxServer –id ExServer1 | Select Name, Calendar* Name
: ExServer1
CalendarRepairSchedule
: {}
CalendarRepairMissingItemFixDisabled
: False
CalendarRepairLogEnabled
: True
CalendarRepairLogSubjectLoggingEnabled
: True
CalendarRepairLogPath
: C:\Program Files\Microsoft\Exchange Server\V14 \Logging\Calendar Repair Assistant
768
CalendarRepairIntervalEndWindow
: 30
CalendarRepairLogFileAgeLimit
: 365.00:00:00
CalendarRepairLogDirectorySizeLimit
: unlimited
Sie haben folgende Bedeutung: 쐍 CalendarRepairSchedule Stellt einen Zeitplan dafür auf, wann der Kalenderreparaturassistent die Benutzerkalender prüft und die gefundenen Probleme behebt. Wird der Assistent in der festgelegten Zeit nicht fertig, fährt er im nächsten vorgesehenen Zeitfenster fort. Gibt es keinen Zeitplan, wird der Kalenderreparaturassistent nicht ausgeführt. Der Assistentenzeitplan wurde in Exchange Server 2010 SP1 durch Arbeitszyklen ersetzt, und die Zeitplanung erfolgt jetzt dadurch, dass der Arbeitszyklus des Assistenten mit dem Cmdlet Set-MailboxServer wie im nächsten Abschnitt beschrieben festgelegt wird. 쐍 CalendarRepairLogEnabled Legt fest, ob die Protokollierung aktiv ist. Der Standardwert ist $True. 쐍 CalendarRepairMissingItemFixDisabled Der Standardwert ist $False. Setzen Sie ihn auf $True, versucht der Assistent nicht, fehlende Elemente zu ergänzen, die er in Benutzerkalendern findet. 쐍 CalendarRepairLogPath Gibt den Pfad zum Speicherort der Protokolldateien an. Standardmäßig werden Protokolle im Verzeichnis \Logging\Calendar Repair Agent abgelegt. Für jedes Postfach, das der Kalenderreparaturassistent durchsucht, wird ein Protokoll erstellt. Es zeichnet Details der Reparaturen auf, die der Assistent am Kalender vornimmt. 쐍 CalendarRepairLogFileAgeLimit Legt fest, wie lange der Assistent Protokolle aufbewahrt. Der Standardwert lautet 00.00:00:00, was keine Begrenzung angibt, sodass die Dateien unendlich lange aufgehoben werden. 쐍 CalendarRepairLogDirectorySizeLimit Legt die Maximalgröße für die Protokolldateien des Kalenderreparaturassistenten für einen Server fest. Sobald sie erreicht ist, löscht der Assistent die älteste Protokolldatei, um Platz freizumachen. Der Standardwert ist Unlimited (unbegrenzt). Üblicherweise benötigt jede Protokolldatei 1 bis 2 kB Speicherplatz, je nachdem, wie viel der Assistent im Postfach zu tun hat. Ein Postfachserver mit 1000 Postfächern generiert bei jeder Ausführung des Assistenten somit Protokolle von 1 bis 2 MB. Läuft der Kalenderreparaturassistent einmal wöchentlich, entstehen pro Jahr weniger als 100 MB an Protokollen. Zur Sicherheit können Sie pro Postfach 200 kB Speicherplatz jährlich zuweisen. 쐍 CalendarRepairLogSubjectLoggingEnabled Legt fest, ob die Themen von Besprechungen und Terminelementen in den Protokolldateien festgehalten werden, was standardmäßig der Fall ist. Das erste Problem, das Sie angehen müssen, besteht darin, dass dem Kalenderreparaturassistenten kein Zeitplan für diesen Server zugewiesen wurde (der Wert für CalendarRepairSchedule ist leer), d.h., der Kalenderreparaturassistent wird niemals aktiviert, und es findet keine Verarbeitung zum Aufspüren und Beheben von Problemen in den Kalenderelementen der Benutzerpostfächer statt. Zuerst müssen wir daher einen Zeitplan erstellen, damit der Assistent arbeiten kann. Der folgende Befehl legt den Verarbeitungsplan für den Kalenderreparaturassistenten für die Zeit zwischen 1 Uhr und 6 Uhr früh jeden Sonntag fest. Außerdem begrenzt er das Protokollverzeichnis auf 500 MB und verwirft Protokolle, die älter als 365 Tage sind. Set-MailboxServer –Identity 'ExServer1'-CalendarRepairSchedule 'Sun.01:00AM–Sun.06:00AM' -CalendarRepairLogDirectorySizeLimit 500MB –CalendarRepairLogFileAgeLimit 365.00:00:00
769
Postfachunterstützungsdienste
Postfachassistenten
Kapitel 12
Postfachunterstützungsdienste
Sie sollten auf allen Postfachservern dieselben Werte für den Kalenderreparaturassistenten setzen, um ein konsistentes Verhalten in der gesamten Organisation zu gewährleisten. Dazu erstellen Sie einfach eine Liste der Postfachserver und leiten diese an Set-MailboxServer weiter: Get-MailboxServer | Set-MailboxServer -CalendarRepairSchedule 'Sun.01:00AM–Sun.06:00AM'
Die Namen der Protokolldateien des Kalenderreparaturassistenten werden aus Datum und Uhrzeit der Ausführung und dem Alias des verarbeiteten Postfachs zusammengesetzt. CRA2010031703-1. JSmith.log ist zum Beispiel das am 17. März 2010 um 3 Uhr früh angelegte Protokoll für das Postfach mit dem Alias »JSmith«. Die Protokolldateien enthalten Informationen über den Durchsuchungsbereich für Elemente sowie Angaben über vorgenommene Korrekturen an Kalenderelementen. Details über reparierte Elemente, etwa Datum und Uhrzeit einer Besprechung, werden abgesehen von deren Themen nicht aufgezeichnet. Sie können auch im Anwendungsprotokoll nach Einträgen mit der ID 9018 suchen, um festzustellen, ob bei der Verarbeitung von Postfächern durch den Assistenten Probleme aufgetreten sind. Alle Postfächer auf einem Server werden untersucht, solange sie nicht explizit ausgeschlossen wurden. Um ein Postfach von der Kalenderreparatur auszunehmen, setzen Sie seine Eigenschaft CalendarRepairEnabled auf $False: Set-Mailbox –Identity 'Akers, Kim' –CalendarRepairEnabled $False
Arbeitszyklen In Exchange Server 2010 SP1 wurde die Zeitplanung für Postfachassistenten wesentlich geändert. Bisher hatte jeder Assistent seine eigene Methode, einen Zeitplan für seine Ausführung zu erstellen. Mit zunehmender Assistentenzahl wurde die fehlende Konsistenz problematisch, weil es für Administratoren schwierig herauszufinden war, wie jeder einzelne geplant wurde. Noch wichtiger war es, dass es durch die immer größere Anzahl von Postfächern auf einem Server jedes Mal zu einer künstlichen Belastungsspitze für den Server kam, wenn ein Assistent in ein geplantes Arbeitsfenster eintrat. Assistenten versuchen nämlich, ihre Arbeit möglichst schnell fertig zu stellen, und verarbeiten die Postfächer nacheinander, bis alles erledigt ist. Dieser Ansatz funktioniert gut, aber das für den Abschluss der Verarbeitung erforderliche Zeitfenster wächst und wächst, weil die Anzahl der Postfächer und der zu verarbeitenden Elemente steigt. SP1 nutzt ein anderes Modell, bei dem die Aktivität der Assistenten moderiert wird, sodass die Arbeit konsistent im Hintergrund weiterläuft und dabei die in einer Arbeitszyklusdefinition niedergelegten Bedingungen erfüllt werden. Sie können zum Beispiel festlegen, dass der Assistent für verwaltete Ordner jedes Postfach auf einem Server mindestens einmal alle zwei Tage verarbeiten muss. Unter Berücksichtigung der in einem Arbeitszyklus festgelegten Beschränkungen ermittelt der Assistent, wie viel Arbeit er in dieser Zeit erledigen muss, und stellt einen internen Zeitplan auf, damit er phasenweise vorgehen kann, um auf dem Server nicht die bei dem alten Modell üblichen Spitzen hervorzurufen, sondern einen problemlosen und vorhersehbaren Ressourcenbedarf. Der Assistent beobachtet fortlaufend die Systembedingungen, um die erforderlichen Anpassungen vornehmen zu können, damit er das Pensum seines Arbeitszyklus erfüllt. Unterliegt der Server aufgrund von Benutzeraktivitäten eine Zeit lang hoher Beanspruchung, kann der Assistent seine Arbeit zurückstellen und später loslegen, wenn die Serverbelastung nachlässt.
770
Postfachassistenten
Festlegen von Zeitplänen für Assistenten Assistent
Aufgabe
Methode zum Festlegen des Zeitplans
Assistent für verwaltete Ordner
Verarbeitet Postfächer, die Aufbewahrungsrichtlinien unterliegen, und unternimmt die in den Richtlinientags festgelegten Schritte, wenn die Aufbewahrungsfrist von Elementen abläuft.
Set-MailboxServer–ManagedFolderAssistantSchedule
Freigaberichtlinie
Erzwingt Änderungen an persönlichen Freigabebeziehungen, um zu gewährleisten, dass sie mit anderen Organisationsrichtlinien übereinstimmen.
Set-MailboxServer–SharingPolicySchedule
Kalenderreparatur
Durchsucht Benutzerkalender und nimmt Reparaturen vor, die zum Abgleichen der Kalender von Besprechungsorganisatoren und -teilnehmern erforderlich sind.
Set-MailboxServer–CalendarRepairSchedule
Junk-E-Mails
Sammelt Daten über Listen sicherer Adressen aus Benutzerpostfächern und gibt sie an die Active Directory-Objekte der Benutzer weiter, damit sie für Antispamprüfungen verwendet werden können.
Hart kodierter interner Zeitplan, für Administratoren nicht sichtbar
Top N Words
Wird vom Voicemail-Transkriptionsdienst benutzt, um beim Erkennen gängiger Wörter zu helfen, die in Voicemails vorkommen.
Registrierungsschlüssel
UM-Berichte
Berichtet, wie Exchange Unified Messaging einsetzt.
SP1 führt eine Standardmethode zum Aufstellen eines Zeitplans für den Arbeitszyklus eines Assistenten ein. Die meisten Assistenten nutzen für diesen Zweck bereits das Cmdlet Set-MailboxServer¸ sodass es sinnvoll ist, es zu optimieren und zum gemeinsamen Nenner für alle zu machen. Finden wir zunächst heraus, wie die aktuellen Arbeitszyklen für die sechs Assistenten aussehen: Get-MailboxServer –Identity ExServer1 | Format-List *WorkCycle* CalendarRepairWorkCycle
:
CalendarRepairWorkCycleCheckpoint
:
SharingPolicyWorkCycle
: 1.00:00:00
SharingPolicyWorkCycleCheckpoint
: 1.00:00:00
SharingSyncWorkCycle
: 03:00:00
SharingSyncWorkCycleCheckpoint
: 03:00:00
ManagedFolderWorkCycle
: 1.00:00:00
ManagedFolderWorkCycleCheckpoint
: 1.00:00:00
TopNWorkCycle
: 7.00:00:00
TopNWorkCycleCheckpoint
: 1.00:00:00
UMReportingWorkCycle
: 1.00:00:00
UMReportingWorkCycleCheckpoint
: 1.00:00:00
Den Arbeitszyklus für einen Assistenten legen Sie mithilfe des Cmdlets Set-MailboxServer fest. Ein Arbeitszyklus ist durch die Gesamtzeit definiert, die dem Assistenten für die Verarbeitung sämtlicher Postfächer in allen Datenbanken des Servers zur Verfügung steht. Der Prüfpunkt (Checkpoint) gibt an, wann der Assistent nach neuen Objekten zur Verarbeitung sucht. Ist kein Wert gesetzt, verwendet
771
Postfachunterstützungsdienste
Tabelle 12.6
Kapitel 12
Postfachunterstützungsdienste
er den Standardwert. (Im vorstehenden Fall beläuft sich der Standardarbeitszyklus für den Kalenderreparaturassistenten auf sieben Tage, der Standardprüfpunktabstand ist ein Tag.) Um den Kalenderreparaturassistenten zum Beispiel anzuweisen, alle Postfächer täglich zu verarbeiten, legen Sie wie folgt einen Arbeitszyklus von einem Tag fest: Set-MailboxServer -Identity ExServer1 -CalendarRepairWorkCycle "1.00:00:00"
Wie immer ist es sinnvoll, dieselben Einstellungen für den Arbeitszyklus auf alle Postfachserver der Organisation zu übertragen.
Als Nächstes: der Transport Nun ist alles bereit für die Kommunikation mit internen und externen Partnern. Sie kann nicht ohne einen funktionierenden Transportdienst stattfinden, weshalb wir jetzt den auf SMTP fußenden Exchange-Transport und das Ineinandergreifen der Teile betrachten, die gewährleisten, dass die E-Mails durchkommen.
772
Das Exchange-Transportsystem
Kapitel 13
Das Exchange-Transportsystem In diesem Kapitel: Überblick über die Transportarchitektur
774
Konfigurationseinstellungen für den Transport
786
Empfangsconnectors
800
Sendeconnectors
809
Verknüpfte Connectors
821
Einschränken
822
Rückstau
825
Transportwarteschlangen
826
Anpassbare Systemnachrichten
838
Protokollierung
846
Akzeptierte Domänen
851
Remotedomänen
854
Die Transportpipeline
856
Fremd- und Zustellungsconnectors
858
Schattenredundanz
859
Verknüpfen von Exchange Server 2003 mit Exchange Server 2010
862
Änderungen in Exchange Server 2010 SP1
865
Blitzsaubere E-Mails
870
773
Kapitel 13
Das Exchange-Transportsystem
Bei allen Versionen vor Exchange Server 2007 waren alle Komponenten eines vollständigen Messagingsystems in einem einzigen Produkt gebündelt. Durch die Einführung von Serverrollen können Administratoren einzelnen Computern jetzt unterschiedliche Rollen zuweisen. Dabei ist die Rolle des Hub-Transport-Servers von entscheidender Bedeutung dafür, dass Nachrichten innerhalb einer Exchange-Organisation hin und her fließen können. Ihr Zweck entspricht dem des Bridgehead-Servers von Exchanger Server 2003, aber sie bildet auch eine zentrale Stelle, um auf die Nachrichten, die durch das Messagingsystem fließen, Richtlinien anzuwenden. Da alle Nachrichten einen Hub-Transport-Server passieren – selbst die Nachrichten, die für die Zustellung zu einer Datenbank auf demselben Server wie das Absenderpostfach bestimmt sind – und alle Hub-Transport-Server gemeinsame Richtlinien aufweisen, die mithilfe von Active Directory definiert und weiterverbreitet werden, kann Exchange dafür garantieren, dass diese Richtlinien immer und auf einheitliche Weise durchgesetzt werden. In umfangreichen Umgebungen werden Hub-Transport-Server gewöhnlich auf eigenen Computern bereitgestellt, aber in kleineren Installationen ist es üblich, dass ein einziger Servercomputer sowohl die Rolle des Postfach- als auch des Hub-Transport-Servers innehat. Es kann sogar noch die Rolle des Clientzugriffsservers hinzukommen, um den kompletten Messagingdienst auf einem einzigen Rechner anzubieten. Beide Varianten sind zulässig, und auch die Verwaltung und Konfiguration sind gleich. Was das Transportsystem anbelangt, muss der Messagingadministrator vor allem auf folgende Dinge achten: 쐍 Die Standardconnectors müssen nach den Bedürfnissen der Organisation eingerichtet sein. 쐍 Das Messagingsystem muss auch Ausfälle auf annehmbare Weise handhaben können. 쐍 Jegliche rechtlich vorgeschriebenen Sicherheitsmaßnahmen müssen in Kraft sein. 쐍 Alle erforderlichen benutzerdefinierten Connectors für Verbindungen zu Clients, Anwendungen und anderen Messagingsystemen müssen vorhanden und betriebsfähig sein. 쐍 Auch außergewöhnliche Situationen müssen wirkungsvoll gehandhabt werden können. 쐍 Die zur Überwachung und Berichterstattung erforderlichen Daten müssen erfasst werden und verfügbar sein. Sehen wir uns mit diesen Aufgaben im Hinterkopf an, wie das Exchange-Transportsystem intern funktioniert.
Überblick über die Transportarchitektur Der Routingmechanismus von Exchange Server 2000 und 2003, der sich auf vordefinierte Routinggruppen und Connector stützte, wurde in Exchange Server 2007 aufgegeben. Das Routing in Exchange Server 2010 ähnelt sehr stark der Vorgehensweise in Exchange Server 2007, da auch hier direkte Verbindungen zwischen Hub-Transport-Servern die Grundlage bilden. Wenn ein HubTransport-Server eine Nachricht für ein Postfach auf einem anderen Server hat, versucht er eine direkte IP-Verbindung zu dem Hub-Transport-Server aufzunehmen, der dem Zielserver am nächsten ist. Dieser angepeilte Hub-Transport-Server kann ein Computer mit mehreren Rollen sein, auf dem sich auch die Zielpostfachdatenbank befindet. In diesem Fall ist die Nachrichtenübertragung damit abgeschlossen und die Zustellung kann erfolgen. Es ist jedoch auch möglich, dass der Hub-Transport-Server nur eine weitere Zwischenstation auf dem Weg ist, sodass ein weiterer Hop erforderlich ist, bevor die Nachricht an das Zielpostfach ausgeliefert werden kann. Die Standorttopologie von
774
Active Directory und die Standortverknüpfungskosten geben Exchange die erforderlichen Daten an die Hand, um die beste Route für Nachrichten auszuwählen. Dabei versucht Exchange jedoch immer, wenn irgend möglich eine direkte Verbindung herzustellen. Es gilt das Prinzip, dass Nachrichten auf dem Weg zu ihrem Ziel möglichst wenig Zwischenstopps einlegen sollen. Active Directory-Standorte bilden die Routinggrenzen für Exchange Server 2010. Wenn Benutzer Nachrichten senden, erstellt der Microsoft Exchange-Mailübergabedienst ein Benachrichtigungsereignis, um einen Hub-Transport-Server darüber zu informieren, dass eine E-Mail auf die Weiterleitung wartet. Diese Benachrichtigungsereignisse werden zum Lastenausgleich automatisch auf alle verfügbaren Hub-Transport-Server in einem Standort verteilt, damit jeder die gleiche Anzahl von Nachrichten zur Weiterleitung erhält. Allerdings können Sie einen Postfachserver auch dazu zwingen, diese Benachrichtigungen an eine feste Auswahl von Hub-Transport-Servern zu senden. Dazu versehen Sie die Eigenschaft SubmissionServerOverrideList mithilfe des Cmdlets Set-MailboxServer mit einer Liste der zu verwendenden Hub-Transport-Server. Diese Liste darf jedoch nur Server enthalten, die sich in demselben Active Directory-Standort befinden wie der Postfachserver. Betrachten Sie das folgende Beispiel: Set-MailboxServer –Identity ExServer1 –SubmissionServerOverrideList 'ExHT1', 'ExHT2'
Wenn sich Server, die sowohl die Postfach- als auch die Hub-Transport-Rolle ausführen, in einer Datenbankverfügbarkeitsgruppe befinden, ist eine besondere Verarbeitung erforderlich, damit die Schattenredundanzfunktion die Gelegenheit hat, Kopien der Nachrichten auf ihrem Weg durch das Transportsystem zu erfassen. Diese neue Funktion wurde in Exchange Server 2010 zum Schutz der Nachrichten eingeführt. Sie sorgt dafür, dass das Transportsystem von jeder Nachricht eine Kopie aufbewahrt, bis die Zustellung am endgültigen Ziel bestätigt wird. Weitere Informationen erhalten Sie im Abschnitt »Schattenredundanz« weiter hinten in diesem Kapitel. Sendet ein Postfachserver, der Mitglied einer Datenbankverfügbarkeitsgruppe ist und gleichzeitig als Hub-Transport-Server fungiert, eine Nachricht, so verwendet Exchange bevorzugt nicht den Transportserver auf demselben Computer, sondern einen anderen. Möchte der kombinierte Postfach- und Hub-Transport-Server eine Nachricht an eine Datenbank ausliefern, die auf demselben Servercomputer repliziert und bereitgestellt ist, dann sucht er ebenfalls nach einem weiteren Hub-TransportServer im Standort, um die Nachricht über ihn weiterzuleiten. Damit wird dafür gesorgt, dass die Nachrichten erfasst werden, wenn sie durch den zwischengeschalteten Hub-Transport-Server gehen. Die verfügbaren Routingpfade für Nachrichten bestimmt Exchange anhand der Active DirectoryTopologie und nicht mithilfe des Algorithmus für das Verbindungsstatusrouting, das in Exchange Server 2000 und 2003 verwendet wurde. Hub-Transport-Server senden auch keine Verbindungsstatusaktualisierungen, um sich gegenseitig auf dem neuesten Stand über mögliche Connectorausfälle zu halten. Die Routingtopologie aus Routinggruppen und Routinggruppenconnectors (oder den selteneren SMTP- und X.400-Connectors) wurde durch einfache Direktverbindungen zwischen den Hub-Transport-Servern ersetzt. Fällt eine solche direkte Verbindung aus irgendeinem Grund aus, ermittelt Exchange anhand der Active Directory-Standorttopologie, wie nah sich eine Nachricht an das Ziel transportieren lässt, bezieht dabei aber nur die Standorte ein, in denen es einen Hub-Transport-Server gibt. Um den besten Routingpfad zu bestimmen, zieht Exchange die mit den Verbindungen zwischen den Active Directory-Standorten verknüpften Kosten heran. Um einen effizienten Nachrichtenverkehr zwischen den Sites zu gewährleisten, müssen viele fundierte Entscheidungen gefällt werden. Beispielsweise wird die Auffächerung von Nachrichten verzögert, bis es notwendig wird, mehrere Kopien zu erstellen. Abgesehen davon, dass die Active Directory-Standorttopologie korrekt sein muss, läuft dies ohne Eingriff und ohne Konfiguration durch denAdministrator ab.
775
Das Exchange-Transportsystem
Überblick über die Transportarchitektur
Kapitel 13
Das Exchange-Transportsystem
Der Übergang zu einem deterministischen Routing auf der Grundlage direkter Verbindungen hat das Routingverhalten vereinfacht, flexibler gemacht und dazu geführt, dass es sich besser an Änderungen in der Organisation und dem zugrunde liegenden Netzwerk anpassen kann. Die Verwendung von Routinggruppen und Exchange-Standortverknüpfungskosten in Exchange Server 2003 funktioniert in den meisten Fällen sehr gut, erfordert aber viel mehr Planung, Überwachung und Wartung durch den Administrator. Exchange Server 2007 und 2010 bieten eine automatische Konfiguration, die immer dann durchgeführt wird, wenn ein neuer Hub-Transport-Server zu der Organisation hinzukommt. Die grundlegende Struktur aus Hub-Transport-Servern und deren standardmäßigen Empfangs- und Sendeconnectors kann durch maßgeschneiderte Connectors ergänzt werden, die jedoch nur für die externe Kommunikation und andere besondere Kanäle erforderlich sind. Wenn Sie beispielsweise eine Kommunikation zwischen Exchange Server 2010 und 2003 einrichten möchten, müssen Sie einen eigenen Connector für diesen Zweck verwenden. Das Gleiche gilt auch, wenn Sie ein externes Smarthost-Relay als Grundlage für die Kommunikation mit externen SMTP-Servern (auch anderen SMTP-Systemen jenseits der Firewall) einrichten möchten. Natürlich brauchen Sie auch besondere Connectors für die Kommunikation mit X.400-Systemen oder anderen Systemen, die über ihre eigenen Messagingprotokolle verfügen. HINWEIS Connectors, die Sie mit dem alten Exchange Development Kit (EDK) erstellt haben, z.B. diejenigen für die Verbindung von Exchange Server 2003 mit anderen Messagingsystemen wie Lotus Notes oder Novell GroupWise, können in Exchange Server 2010 nicht mehr verwendet werden. Wenn Sie diese Funktion weiterhin bereitstellen wollen, müssen Sie entweder einen Exchange Server 2003-Computer mit dem entsprechenden Connector in der Organisation behalten oder auf SMTP-Routing umsteigen, um Exchange mit dem anderen Messagingsystem zu verbinden. Solche besonderen Connectors müssen Sie nur einmalig erstellen, und auch eine Verwaltung ist nur in Ausnahmefällen erforderlich. Die alltäglichen Verbindungen zwischen den Exchange Server-Computern in einer Organisation funktionieren jedoch automatisch, ohne dass der Administrator ständig eingreifen muss. Weitere Informationen
Microsoft hat einige hervorragende Diagramme im PDF-Format veröffentlicht, die die Funktionsweise des Exchange-Transportsystems beschreiben. Sie können sie von TechNet unter http://msexchangeteam.com/archive/2009/12/01/453347.aspx herunterladen. Abbildung 13.1 zeigt eine stark vereinfachte Darstellung des Nachrichtenflusses zwischen den Postfach- und den Hub-Transport-Servern von Exchange Server 2010. Dieses Diagramm zeigt die folgenden Hauptpunkte: 쐍 Abgesehen von der lokalen Zustellung zu einer Datenbank auf dem eigenen Computer transportieren Postfachserver niemals irgendwelche Mails. Wenn ein Postfachserver eine Nachricht für eine Datenbank auf einem anderen Exchange Server-Computer oder einen Empfänger in einem anderen E-Mail-System hat, informiert der Microsoft Exchange-Mailübertragungsdienst auf diesem Rechner einen Hub-Transport-Server darüber, dass eine Nachricht bereitsteht. Dabei gibt er die Datenbank, das Postfach und die Nachrichtenkennung an, um anzuzeigen, wo die E-Mail wartet. Die Übertragung der Nachricht vom Postfach- zum Hub-Transport-Server ist dann Sache des Speichertreibers.
776
HINWEIS Der Postfachserver führt sowohl für die lokale als auch für die Remotezustellung dieselbe Verarbeitung durch, um sicherzustellen, dass alle vorgeschriebenen Erfordernisse für die Nachrichtenübermittlung erfüllt werden. Ausgehende E-Mails gelangen in den Postausgangsordner im Informationsspeicher, wo sie vom Speichertreiber abgeholt werden, der sie dann an den Hub-Transport-Server weiterleitet. Dort gelangen die Nachrichten in die Übertragungswarteschlange. Der Transportserver entnimmt sie der Warteschlange, kategorisiert sie und leitet sie dann weiter, indem er sie in die entsprechende Zustellwarteschlange für die weitere Übertragung stellt. Abbildg. 13.1
Nachrichtenfluss im Transportsystem von Exchange Server 2003 AntispamAgents
Nachrichten- Antirichtlinien virus
Transportereignis-/Nachrichten-API SMTPConnector
SMTPEmpfang PickupVerzeichnis
Übertragungswarteschalnge
Zustellwarteschlange
Kategorisierungsmodul
SMTPSender
SMTPConnector
RLAPI Übertragung (Postfach ->SMTP) MAPI-Server-RPC
Zustellung (Postfach ->SMTP) AD
MAPI-Server-RPC
Verzeichnis & Konfiguration Speichertreiber Postfachserver Benutzerpostfächer
쐍 Postfach- und Hub-Transport-Server innerhalb eines Active Directory-Standorts kommunzieren über serverseitige Remoteprozeduraufrufe (Remote Procedure Calls, RPCs) miteinander. Die Verwendung von Exchange-RPCs hat zur Folge, dass die Serververbindungen die Bandbreite von LANs aufweisen müssen, da es sonst zu RPC-Zeitüberschreitungen und Fehlern kommen kann. 쐍 Wenn es in einem Standort mehrere Hub-Transport-Server gibt, trifft der Mailübetragungsdienst seine Auswahl so, dass die Last möglichst gleichmäßig verteilt wird. Das erhöht die Fehlertolerenz des Transportdienstes. Wenn auf einem Postfachserver gleichzeitig die Rolle des Hub-TransportServers untergebracht ist, verwendet Exchange zur Verarbeitung der Nachrichten diesen lokalen Hub-Transport-Server. Eine Ausnahme besteht, wenn der Server Mitglied einer Datenbankverfügbarkeitsgruppe ist und ein weiterer Hub-Transport-Server zur Verfügung steht, denn dadurch, dass Nachrichten von dem Computer mit dem Postfachserver verlagert werden, wird sichergestellt, dass sie vom Papierkorb auf dem Hub-Transport-Server erfasst und daher bei einem Fehlschlag wiederhergestellt werden können. 쐍 Der Active Directory-Topologiedienst versorgt den Transportdienst mit Informationen über die aktuelle Standorttopologie, die er von den Active Directory-Domänencontrollern bzw. globalen Katalogservern bezieht.
777
Das Exchange-Transportsystem
Überblick über die Transportarchitektur
Kapitel 13
Das Exchange-Transportsystem
쐍 Ausgehende Nachrichten gelangen via SMTP an andere Hub-Transport-Server, über einen Routinggruppenconnector an Server mit einer ältereren Exchange-Version und über einen SMTPConnector an andere SMTP-E-Mail-Systeme. Über maßgeschneiderte Gateways erfolgt die Übergabe an andere Formen des Transports, z.B. Faxdienste. 쐍 Transportereignisse führen dazu, dass die Antispam-Agents aktiv werden, wenn eine Nachricht auf einen Server gelangt. Diese Agents können auf Hub- und auf Edge-Transport-Servern ausgeführt werden. 쐍 Wenn das Kategorisierungsmodul die Adressen der Nachrichten erweitert hat, wendet der Transportdienst Nachrichtenrichtlinien an. Dies geschieht mithilfe von Transportregeln, die ganz banale Aufgaben (z.B. das Anhängen eines rechtlichen Hinweises an ausgehende Nachrichten), aber auch sehr komplizierte erledigen können (z.B. die Blockierung von Nachrichten zwischen bestimmten Benutzergruppen). Der Transportdienst ruft auch alle Journalregeln auf, die Sie zur Erfassung des Nachrichtenverkehrs in diesem Stadium eingerichtet haben. 쐍 Virenscanner, die in der Lage sind, mit der Exchange-API (Virus Scanning API, VSAPI) zur Virenerkennung zusammenzuarbeiten, können ein- und ausgehende Nachrichten auf Hub- und EdgeTransport-Servern untersuchen. 쐍 Alle Hub-Transport-Server einer Organisation weisen eine gemeinsame Konfiguration auf, die Einstellungen wie die maximale Nachrichtengröße, die maximale Anzahl der Empfänger einer eingehenden Nachricht und die verfügbaren Connectors (einschließlich der auf Edge-TransportServern) festlegen. Diese Konfigurationseinstellungen sowie die Transport- und Journalregeln werden in Active Directory festgehalten. Edge-Transport-Server fungieren als isolierte Einheiten, die zwar lose mit der Organisation verbunden sind, aber nicht dieselben Konfigurationseinstellungen aufweisen. Wenn Sie Edge-Transport-Server bereitstellen, müssen Sie sie jeweils einzeln konfigurieren. Im weiteren Verlauf dieses Kapitels werden wir uns viele dieser Gesichtspunkte des Routings genauer ansehen.
Active Directory und Routing Wie bereits gesagt, versuchen Hub-Transport-Server mit Exchange Server 2007 und 2010 stets direkte Server-zu-Serverbindungen aufzubauen, um Nachrichten zu senden. Befindet sich das Zielpostfach auf einem Server im selben Active Directory-Standort, nimmt der Hub-Transport-Server eine direkte Verbindung mit diesem Server auf. Liegt das Postfach dagegen auf einem Server in einem anderen Standort, stellt der Hub-Transport-Server eine Verbindung zu einem Hub-Transport-Server im Zielstandort auf, um die Nachricht über eine mit TLS (Transport Layer Security) geschützten SMTP-Verknüpfung zu übertragen. Ist der Zielserver nicht erreichbar, versucht Exchange die Nachricht so nah wie möglich ans Ziel zu bringen und zieht dazu ein Verfahren zum Routing mit den geringstmöglichen Kosten heran. Hier spricht man auch von einer »Warteschlange am Ausfallort«. TIPP Zur Berechnung der günstigsten Route nutzt Exchange die Active Directory-Standortverknüpfungskosten. Wenn Sie gerade von Exchange Server 2003 aus umsteigen, können Sie sich einen Active Directory-Standort wie eine Routinggruppe vorstellen, eine Active DirectoryStandortverknüpfung wie einen Routinggruppenconnector und die Standortverknüpfungskosten wie die Kosten, die mit einem solchen Routinggruppenconnector verbunden sind.
778
Die Berechnungen für das Routing mit den geringstmöglichen Kosten scheinen sehr einfach zu sein, doch in umfangreichen Organisationen mit mehreren Active Directory-Standorten können sie zu einer ziemlich komplizierten Übung werden, vor allem wenn die Active Directory-Administratoren den Standortverknüpfungskosten nicht viel Aufmerksamkeit geschenkt haben. Wer kümmert sich auch schon um diese Kosten, solange die Replikation funktoniert? Exchange verwendet folgenden Algorithmus: 1. Bestimme den Active Directory-Zielstandort, in dem sich das Zielpostfach befindet. 2. Berechne die Kosten der Übertragung zu diesem Standort durch Addition aller Kosten für die IP-
Standortverknüpfungen oder Connectors zwischen dem Quell- und dem Zielstandort. Sofern einer Standortverknüpfung eigene Exchange-Kosten zugewiesen sind, verwende diese. Verwende die Route mit den geringsten Kosten. 3. Wenn es mehrere Pfade mit denselben Kosten gibt, verwende denjenigen mit den wenigsten Hops. 4. Wenn es immer noch mehrere Pfade gibt, verwende denjenigen, der in der alphanumerischen Sortierung am weitesten vorn steht. Um die Nachricht in die Warteschlange am Ausfallort zu stellen, geht Exchange den Pfad mit den geringsten Kosten rückwärts durch, um den Hub-Transport-Server zu finden, der dem Ziel am nächsten liegt. Wenn es nicht möglich ist, einen Hub-Transport-Server außerhalb des eigenen Standorts zu erreichen (was gewöhnlich auf einen Netzwerkausfall zurückzuführen ist), bleibt die Nachricht in der Warteschlange des lokalen Hub-Transport-Servers. Jede Minute wird eine erneute Übertragung versucht, bis die Nachricht zugestellt ist, oder nach zwei Tagen die Gültigkeitsdauer abläuft. Diese Einstellungen können Sie mit dem Cmdlet Set-TransportServer ändern. Mit dem folgenden Befehl legen Sie z.B. das Wiederholungsintervall auf fünf Minuten und die Gültigkeitsdauer auf drei Tage fest: Set-TransportServer –Identity ExServer1 –MessageRetryInterval 00:05:00 –MessageExpirationTimeOut 3.00:00:00
TIPP Ändern Sie diese Einstellungen nur dann, wenn Sie einen guten Grund dafür haben, und achten Sie darauf, dass auf allen Hub-Transport-Servern in der Organisation dieselben Werte gelten, sodass sich ein einheitliches Verhalten ergibt. Es ist ganz wichtig, sich darüber im Klaren zu sein, dass die Berechnung der Route mit den geringsten Kosten kein einmaliger Vorgang ist, der nur auf dem ursprünglichen Hub-Transport-Server stattfindet. Stattdessen läuft er auf jedem der Hub-Transport-Server ab, über die die Nachricht weitergeleitet wird, um die Route weiter zu optimieren. Im Abschnitt »Auswählen eines Sendeconnectors« weiter hinten in diesem Kapitel erfahren Sie, wie Sie durch die Angabe eines Connectorbereichs Einfluss auf die Route nehmen können.
Überschreiben der Standortverknüpfungskosten von Active Directory Offensichtlich hat Active Directory einen sehr großen Einfluss auf das Nachrichtenrouting von Exchange Server 2010. Um die bestmöglichen Entscheidungen zu treffen, sind fundierte Informationen erforderlich. Eine gute Möglichkeit, um diese Informationen zu erfassen, besteht darin, Microsoft Active Directory Topology Diagrammer einzustezen (als Download auf der Website von Microsoft
779
Das Exchange-Transportsystem
Überblick über die Transportarchitektur
Kapitel 13
Das Exchange-Transportsystem
erhältlich, um alle Daten über die aktuelle Active Directory-Struktur zu lesen und eine grafische Darstellung in Microsoft Visio zu erstellen. Die Diagramme, die sich daraus ergeben, bilden eine gute Grundlage für jegliche Diskussionen über optimale Routingpfade, wie sie zwischen den Active Directory- und den Exchange-Administratoren stattfinden können (wobei dies in kleinen bis mittleren Unternehmen die gleichen Personen sein können). Weitere wertvolle Informationen können Sie aus der Zuordnung von Exchange Server-Computern zu Standorten gewinnen. Mit dem folgenden Befehl können Sie eine Liste der Server und der zugehörigen Standorte abrufen: Get-ExchangeServer | Select Name, Site
Ein möglicher Streitpunkt kann darin bestehen, dass die für Active Directory festgelegten IP-Standortverknüpfungskosten die Kosten für das Messagingrouting nicht genau wiedergeben. Dafür gibt es verschiedene Gründe. Vielleicht ist Active Directory schon lange in der Produktion, wobei die ursprünglichen IP-Standortverknüpfungskosten niemals aktualisiert und an die jetzigen Netzwerkverbindungen angepasst wurden. Wieso sollte man sich auch mit der Überprüfung und Aktualisierung dieser Kosten befassen, wenn die Active Directory-Replikation funktioniert? Außerdem kann es sein, dass für Active Directory und Exchange unterschiedliche Teams verantwortlich sind, die sich niemals von Angesicht zu Angesicht treffen, um die sinnvollsten Kosten für das Routing auszuarbeiten. So ist das Leben. Exchange bietet eine Lösung für diese Probleme an, denn es ist möglich, für eine Verknüpfung neben den Active Directory-Standortverknüpfungskosten auch noch ausdrücklich Exchange-Routingkosten anzugeben. Dazu verwenden Sie das Cmdlet Set-ADSiteLink. Um beispielsweise der Standortverknüpfung zwischen Dublin und London die Exchange-Kosten von 10 zuweisen, geben Sie folgenden Befehl ein: Set-ADSiteLink –Identity 'Dublin–London' –ExchangeCost 10
Das Cmdlet Get-ADSite gibt alle zurzeit in Active Directory definierten Standorte zurück, das Cmdlet Get-ADSiteLink alle aktuellen Standortverknüpfungen. Sobald Sie Exchange-spezifische Kosten für eine Verknüpfung festgelegt haben, nutzt der Transportdienst diese neuen Werte für seine Berechnung der günstigsten Rute. Diese Exchange-Kosten haben jedoch keinerlei Auswirkungen auf die Active Directory-Replikation. Sie werden nur von Exchange selbst zur Berechnung des optimalen Routingpfades für Nachrichten herangezogen. Mit dem Cmdlet Set-ADSiteLink können Sie auch eine maximale Nachrichtengröße für die Verknüpfung festlegen. Das ist vor allem dann sinnvoll, wenn sich ein Standort am Ende einer ausgedehnten Verknüpfung befindet und nicht in der Lage ist, umfangreiche Nachrichten über diese Verbindung zu verkraften. Das kann z.B. der Fall sein, wenn Sie ein Nabe-Speiche-Netzwerk haben, in dem große Rechenzentren mit Filialen verbunden sind, oder wenn Sie Satellitenverbindungen zu Schiffen oder anderen schwer zu erreichenden Orten einsetzen. Beim Versuch, über die Verbindung eine Nachricht zu senden, deren Größe das Maximum überschreitet, erstellt Exchange einen Unzustellbarkeitsbericht. Die maximale Nachrichtengröße können Sie wie folgt festlegen: Set-ADSiteLink –Identity 'Hub to Luton branch' –MaxMessageSize 1MB
Noch eine Zwischenschicht?
Exchange-spezifische Routingkosten sollten Sie nur dann zuweisen, wenn es absolut notwendig ist. Dadurch können Sie zwar die Effizienz des Routings steigern, doch ein Abweichen von den in Active Directory festgehaltenen grundlegenden IP-Standortverknüpfungskosten fügt eine weitere Zwischenschicht ein, die die Verwaltung noch weiter verkompliziert.
780
Hub-Standorte
Als Netzwerkbandbreite teuer, unzuverlässig und in kleinen Zweigstellen und an abgelegenen Orten schwer zu bekommen war, wurden viele Messagingeinrichtungen in Form von Nabe-Speiche-Netzwerken gestaltet. Dieses Design ist heutzutage angesichts reichhaltigerer, billigerer und leichter zu erwerbender Netzwerkbandbreite, die sich fast überall installieren lässt, nicht mehr so beliebt. Viele Unternehmen nutzen billige Bandbreite, um die Bereitstellung von IT-Dienstleistungen und Anwendungen in riesigen Rechenzentren zu zentralisieren. Bei manchen dieser Projekte erfolgt ein Rückgriff auf Elemente des Nabe-Speiche-Routings, wobei das Rechenzentrum als Nabe oder »Hub« fungiert, in der die große Mehrheit der Datenverarbeitungsressourcen untergebracht ist, während die Speichen auf eine kleine Menge von Zweigstellen für Benutzer reduziert sind, die aus dem einen oder anderen Grund keine Verbindung mit dem Zentrum aufnehmen können. Andere Vorkommen dieses Designs treten auf, wenn eine Firewall zwei Teile eines Unternehmens trennt, die jeweils über einen eigenen Active Directory-Standort verfügen, und die gesamte Kommunikation durch einen Naben- oder Hub-Standort zwischen ihnen geschleust werden muss. Mit dem Cmdlet Set-ADSite können Sie einen Acitve Directory-Standort wie folgt als Hub kennzeichnen: Set-ADSite –Identity 'Central Hub Site' –HubSiteEnabled $True
Ob zurzeit irgendeiner Ihrer Standorte als Hub fungiert, können Sie mithilfe des Cmdlets GetADSite erkennen. Wenn ein Hub-Transport-Server die kostengünstigste Route für die Nachrichtenübermittlung berechnet, überprüft er auch, ob irgendwelche Standorte auf dem Weg als Hubs definiert sind. Wenn dies nicht der Fall ist, versucht der Hub-Transport-Server Verbindung mit einem HubTransport-Server im Zielstandort aufzunehmen. Gibt es jedoch einen Hub-Standort, dann nimmt er Kontakt mit einem dortigen Hub-Transport-Server auf, um die Nachricht zur Weiterleitung an den Bestimmungsort zu übergeben.
Verzögertes Auffächern Um bei der Übertragung von Nachrichten die Netzwerkbandbreite optimal zu nutzen, bedient sich Exchange der Technik des so genannten »verzögerten Auffächerns«. Nachdem eine Nachricht das Kategorisierungsmodul passiert hat, liest Exchange die vollständige Empfängerliste und kann den Routingpfad berechnen. Geht eine E-Mail an mehrere Empfänger, sind höchstwahrscheinlich mehrere verschiedene Pfade erforderlich, um sie zu den Zielservern zu übertragen. Gewöhnlich fächern E-Mail-Systeme die Nachrichten auf und erstellen so viele Kopien, wie für die Reise über die verschiedenen Routen notwendig sind. Das funktioniert zwar sehr gut, doch es bedeutet, dass alle Kopien auf dem Ursprungsserver erstellt und separat verarbeitet werden müssen. Befinden sich mehrere der Empfängerpostfächer aber in derselben Datenbank, werden mehrere Kopien derselben Nachricht über dieselben Connectors zu derselben Datenbank übertragen. Um das zu vermeiden, analysiert Exchange die Routingpfade für sämtliche Empfänger einer Nachricht, um zu bestimmen, wie weit die geringstmögliche Anzahl von Kopien über einen gemeinsamen Weg gelangen kann, bevor sie in weitere Kopien aufgefächert werden müssen. Einige Kopien müssen schon sofort angelegt werden, aber in vielen Fällen kann eine einzelne Kopie über eine Verknüpfung zu einem Hub-Transport-Server in einem anderen Standort reisen, wo dann erst mehrere Kopien für
781
Das Exchange-Transportsystem
Überblick über die Transportarchitektur
Kapitel 13
Das Exchange-Transportsystem
die lokale Zustellung erstellt werden müssen. Die wirtschaftlichste Auffächerung wird dadurch bestimmt, dass Exchange die Hub-Transport-Server ermittelt, auf denen Kopien erstellt werden müssen. Diese Server werden zu Gabelungen auf dem Routingpfad. Vorteile des verzögerten Auffächerns
Das verzögerte Auffächern mag wie eine abgehobene Optimierungstechnik für ein Standardverfahren zum Routing aussehen. Allerdings lassen sich dadurch erhebliche Einsparungen erzielen, wenn Nachrichten mit großen Anhängen über gemeinsame Pfade reisen. Stellen Sie sich eine E-Mail mit einem Anhang von 10 MB vor, die an 100 Benutzer geht, von denen sich 80 in einem anderen Standort befinden. Bei der normalen Auffächerung erstellt der Hub-Transport-Server im lokalen Standort 80 Kopien der Nachricht und sendet sie an den Hub-Transport-Server im Remotestandort, sodass insgesamt 800 MB über das Netzwerk zwischen den Standorten übertragen werden. Bei der verzögerten Auffächerung gehen über diese Verbindung jedoch nur 10 MB, was eine Einsparung von 790 MB bedeutet. Wenn Sie unbegrenzt billige Bandbreite zur Verfügung haben, mag das nicht so wichtig sein, aber wenn Sie für eine schnelle Nachrichtenübermittlung über Standortverknüpfungen mit geringer Bandbreite sorgen müssen, kann es zu einem entscheidenden Faktor werden.
Die wichtige Rolle der Hub-Transport-Server Wenn wir uns genauer mit der Exchange-Transportarchitektur beschäftigen möchten, ist es wichtig, genau zu verstehen, welche Aufgaben die Hub-Transport-Server und die Komponenten, die zusammen das Exchange-Transportsystem bilden, in der Exchange-Organisation erfüllen. Im weiteren Verlauf des Kapitels werden wir uns viele diese Vorgänge im Einzelnen ansehen, z.B. die Einrichtung von Connectors. Hub-Transport-Server sind für folgende Dinge verantwortlich: 쐍 Nachrichtenfluss Hub-Transport-Server verarbeiten alle Nachrichten, die innerhalb einer Exchange-Organisation gesendet werden, bevor sie an die Postfächer zugestellt oder außerhalb der Organisation geleitet werden. Von dieser Regel gibt es keine Ausnahmen. Exchange schleuste Nachrichten immer durch einen Hub-Transport-Server, um das Routing zu bestimmen und auszuführen. Das bedeutet natürlich, dass Sie in jedem Active Directory-Standort mit einem Postfachserver auch einen Hub-Transport-Server installieren müssen. 쐍 Nachrichtenübertragung Nachrichten können auf vier verschiedenen Wegen auf einen HubTransport-Server gelangen. Erstens ist dies als SMTP-Übertragung über Port 25 und einen Empfangsconnector möglich (bei POP3- und IMAP4-Clients über Port 587). Connectors kümmern sich um den Nachrichtenfluss von anderen Hub-Transport-Servern, über eine Internetverbindung oder über einen Routinggruppenconnector. Letzteres gilt für eingehende Nachrichten von Computern mit einer älteren Exchange-Version in einer gemischten Organisation. Die zweite Methode kommt zum Tragen, wenn Anwendungen korrekt formatierte SMTP-Nachrichten im Pickup- oder im Wiedergabeverzeichnis ablegen. Die dritte Methode erfolgt über den Speichertreiber. Wenn mit Postfachservern verbundene MAPI-Clients Nachrichten senden, fängt der Speichertreiber sie im Postausgangsorder der Benutzerpostfächer ab und konvertiert sie vom MAPI- ins TNEF-Format (Transport Neutral Encapsulation Format), bevor er sie übertragt. Bei der letzten Methode erstellt ein Transport-Agent eine Nachricht. In allen Fällen gelangt die Nachricht in die Übertragungswarteschlange zur Verarbeitung durch die Transportdienste. EdgeTransport-Server nehmen Nachrichten nur über Empfangsconnectors an.
782
쐍 Nachrichtenkategorisierung Das Kategorisierungsmodul nimmt die Adressauflösung vor, indem es die im Nachrichtenheader angegebenen Adressen der internen Empfänger mit den Informationen im globalen Katalogserver vergleicht. Es erweitert Verteilergruppen, wozu es auch gehört, die Abfragen zu erstellen, die notwendig sind, um die Mitgliedschaft von dynamischen Verteilergruppen zu bestimmen, und überprüft auch diese Adressen anhand des globalen Katalogs. Sobald das Kategoriesierungsmodul die Adressen kennt, mit denen es zu arbeiten hat, löst es den besten Routingpfad für die Nachrichten auf und führt alle notwendigen Konvertierungen des Inhalts durch (z.B. um dafür zu sorgen, dass der Benutzer die Nachrichten in seinem bevorzugten Format empfängt). Das Kategorisierungsmodul ist auch für die Aufteilung der Nachrichten verantwortlich, wenn dies für eine effiziente Zustellung erforderlich ist. Jede Nachricht, die einen Hub-Transport-Server durchläuft, muss das Kategorisierungsmodul passieren. Bevor dieses eine E-Mail in die Zustellwarteschlange stellt, prüft es, ob eine Transport- oder Journalregel darauf angewendet werden muss, und führt die erforderliche Verarbeitung durch. In der SP1Version werden beim Einstellen in die Warteschlangen die vom Benutzer angegebenen Prioritäten berücksichtigt, damit Nachrichten mit hoher Wichtigkeit vor denen mit geringerer Wichtigkeit verarbeitet werden. 쐍 Nachrichtenzustellung Wenn ein Hub-Transport-Server feststellt, dass eine Nachricht an ein Exchange-Postfach ausgeliefert werden soll, benachrichtigt er entweder den Speichertreiber (falls dieser auf demselben Computer läuft), um für die Auslieferung an ein lokales Postfach zu sorgen (also an ein Postfach in demselben Active Directory-Standort, in dem sich auch der Hub-Transport-Server befindet), oder er überträgt die Nachricht über einen Sendeconnector an einen HubTransport-Server in dem Active Directory-Standort, in dem sich auch die Zieldatenbank befindet. Dieser zweite Hub-Transport-Server kümmert sich dann um die Weiterleitung zum Zielpostfach. Kann die Nachricht aufgrund von Netzwerkausfällen oder anderen Gründen nicht an den gewünschten Hub-Transport-Server übermittelt werden, geht sie an einen anderen Hub-Transport-Server im Active Directory-Standort, der möglichst nahe am Zielort liegt, oder wird für einen erneuten Versuch in eine Warteschlange eingestellt. Nachrichten zu Nicht-Exchange-Empfängern werden über einen SMTP-Connector zugestellt, an einen Edge-Transport-Server oder an ein externes Gateway weitergeleitet, das für die Übertragung zu einem fremden E-Mail-System verantwortlich ist. Um die Einrichtung der Connectors zwischen den Hub-Transport-Servern in verschiedenen Active Directory-Sites müssen Sie sich nicht kümmern, da diese Server aufgrund der Konfigurationsinformationen in Active Directory gegenseitig über sich Bescheid wissen und die Connectors automatisch durch Exchange angelegt werden. Was Sie allerdings erstellen müssen, sind SMTP-Connectors für die ausgehende Kommunikation. Die gesamte Kommunikation zwischen den Hub-Transport-Servern verläuft über SMTP und wird automatisch mithilfe von TLS und Kerberos geschützt. Auch zur Einrichtung dieser sicheren Verbindungen müssen Sie nichts beitragen. 쐍 Schutz Hub- und Edge-Transport-Server sind die einzigen Exchange-Serverrollen, die mit Antispam-Agents versehen werden können, um den Nachrichtenstream zu filtern und zu bereinigen, bevor die Nachrichten an die Empfänger weitergeleitet werden. Um zusätzlichen Schutz zu bieten, können Hub-Transport-Server auch Antivirussoftware ausführen. Dies ist jedoch auch auf Postfachservern möglich. Die Bereitstellung von Antispam- und Antivirussoftware auf Hub- und Edge-Transport-Servern besprechen wir weiter hinten in diesem Kapitel. 쐍 Nachrichtenwiederherstellung Hub-Transport-Server verfügen über einen so genannten Transportpapierkorb, mit dem Nachrichten, die sich noch in der Übermittlung befinden, im Falle eines Serverausfalls wiederhergestellt werden können, um sie erneut an den Postfachserver zuzustellen.
783
Das Exchange-Transportsystem
Überblick über die Transportarchitektur
Kapitel 13
Das Exchange-Transportsystem
쐍 Messaging-Datensatzverwaltung Hub-Transport-Server bilden eine zentrale Kontaktstelle für Exchange, um Transport- und Journalregeln auf die Nachrichten anzuwenden, die in der Organisation hin und her geschickt werden. Unter anderem können Sie mit Transportregeln rechtliche Hinweise anhängen, Nachrichten gezielt kopieren und bestimmte Benutzergruppen an der Kommunikation mit anderen hindern. Mithilfe von Journalregeln kann Exchange den Nachrichtenverkehr vollständig kopieren und die Daten zu einem andren Ablageort verschieben, z.B. zu einem hierarchischen Speicherverwaltungssystem (Hierarchical Storage Management, HSM). Der Informationsspeicher wird häufig als das Herz von Exchange bezeichnet, und zwar zu Recht. Die Möglichkeiten für den Nachrichtenfluss, die die Hub-Transport-Server bieten, können dann als die Lungen angesehen werden, da diese Server Exchange in die Lage versetzen, seinen Aufgaben als Messagingsystem nachzukommen.
Versionsübergreifendes Routing Bei Exchange Server 2007 fand der Wechsel zum SMTP-Routing statt, und Exchange Server 2010 folgt demselben Ansatz, weshalb es bei der Kommunikation zwischen Servern dieser beiden Versionen keine Probleme geben sollte. Ein scheinbarer Beweis für diese Theorie ist das nahtlose Zusammenspiel zwischen Exchange Server 2007 und 2010, doch wie so oft steckt auch hier der Teufel im Detail. Das Detail ist in diesem Fall die Änderung an der XSO-Schicht aufgrund der massiven Veränderung des Datenbankschemas für den Informationsspeicher. XSO ist eine intern verwaltete RPCAPI, die außerhalb von Microsoft nirgendwo dokumentiert ist (die bevorzugte API für die externe Verwendung ist jetzt Exchange Web Services [EWS]). XSO wird jetzt vom Speichertreiber zur Kommunikation mit dem Transportdienst verwendet, wenn er Nachrichten für Postfächer senden oder abrufen muss. Der Speichertreiber muss Verbindung mit den Postfachdatenbanken aufnehmen, und das Schema dieser Datenbanken ist in Exchange Server 2010 grundlegend verändert worden. Daher unterscheidet sich die Version des Speichertreibers auf einem Postfachserver mit Exchange Server 2010 sehr stark von der Version, die auf Postfachservern mit Exchange Server 2007 läuft. Das wiederum bedeutet, dass ein Exchange Server 2007-Postfachserver nicht direkt mit einem Exchange Server 2010-Hub-Transport-Server kommunizieren kann und umgekehrt. Dieser Mangel an Kommunikation scheint eine echte Herausforderung für Exchange Server 2010 zu bedeuten, doch zum Glück gibt es keinerlei Probleme mit der Kommunikation zwischen Hub-Transport-Servern mit Exchange Server 2010 und 2007, da sie komplett auf SMTP beruht. Dasselbe gilt auch für das Routing zwischen Standorten, da dies ebenfalls über SMTP läuft. Doch wenn Sie mindestens einen Postfachserver mit Exchange Server 2007 in einem Standort haben, müssen Sie dort einen Hub-Transport-Server mit Exchange Server 2007 behalten – und zwar mit Exchange Server 2007 SP2, damit das Routingmodul die kleinen Änderungen zwischen den Serverversionen versteht. Die grundlegende Regel für das Routing besagt, dass Nachrichten, die von oder an Exchange Server 2007-Postfächer gesendet werden, von Hub-Transport-Servern mit Exchange Server 2007 verarbeitet werden müssen, und Nachrichten von oder an Exchange Server 2010-Postfächer von Hub-TransportServern mit Exchange Server 2010. Sendet ein Exchange Server 2007-Postfach eine Nachricht für ein Exchange Server 2010-Postfach und ist in dem Standort kein Hub-Transport-Server mit Exchange Server 2010 zur Verfügung, erkennt das Routingmodul auf dem Hub-Transport-Server mit Exchange Server 2007 SP2, dass es die Nachricht nicht abliefern kann, und sendet einen Unzustellbarkeitsbericht an den Benutzer zurück. Das gleiche gilt auch im umgekehrten Fall. Daher müssen wir in jedem Standort, in dem Servercomputer mit Exchange Server 2007 und 2010 vorkommen, die Konstellation aus Abbildung 13.2 nachstellen. Die Hub-Transport-Server der unterschiedlichen Versionen können
784
Sie sich dabei als interne Bridgeheadserver zwischen den beiden Versionen vorstellen, da die Nachrichten von einem Exchange Server 2007- an ein Exchange Server 2010-Postfach über Hub-Transport-Server beider Versionen laufen müssen. TIPP In großen Standorten mit vielen Postfachservern sollten Sie je zwei Hub-TransportServer der beiden Versionen bereitstellen, um eine neuralgische Fehlerstelle zu vermeiden. Durch Virtualisierung können Sie dafür sorgen, dass Sie für diese beiden Sätze von Hub-Transport-Servern nicht so viel zusätzliche Hardware bereitstellen müssen, bis Sie die Organisation komplett auf Exchange Server 2010 umstellen können. Das Erfordernis für dieses versionsübergreifende Routing ändert nichts an den allgemeinen Ratschlägen zur Reihenfolge der Bereitstellung von Exchange Server 2010-Rollen. Nach wie vor sollten Sie als Erstes Clientzugriffsserver bereitstellen, dann die Hub-Transport-Server und schließlich die Postfachserver. Bei der Planung müssen Sie jedoch daran denken, in einem Standort mindestens einen Hub-Transport-Server mit Exchange Server 2007 zu behalten, bis der letzte Exchange Server 2007Postfachserver aus diesem Standort entfernt worden ist. Abbildg. 13.2
Versionsübergreifendes Routing
Postfachserver mit Exchange Server 2010
RPC
RPC
Hub-Transport-Server mit Exchange Server 2010 SMTP
RPC
RPC
Postfachserver mit Exchange Server 2007
Hub-Transport-Server mit Exchange Server 2007
785
Das Exchange-Transportsystem
Überblick über die Transportarchitektur
Kapitel 13
Das Exchange-Transportsystem
Was geschieht mit X.400?
Wenn Sie eine Migration von Exchange Server 2003 aus vornehmen, fragen Sie sich vielleicht, welche Rolle das Protokoll X.400 in Exchange Server 2010 noch spielt. Schließlich war X.400 in den Tagen, in denen Exchange noch eine sehr zaghafte Beziehung zum Internet hatte, das ursprüngliche Transportprotokoll für die Verbindung von Servern. Das können Sie noch an der X.400Adresse erkennen, die jedes E-Mail-aktivierte Objekt älterer Exchange-Versionen aufweist. Seit Exchange Server 2000 löst sich Exchange jedoch von seinen X.400-Wurzeln, und mit Exchange Server 2007 war dieser Vorgang abgeschlossen. Kein Exchange Server 2010-Objekt erfordert eine X.400-Adresse, um funktionieren zu können, und sofern Sie nicht auf einem Exchange Server 2003-Computer einen X.400-Connector zur Kommunikation mit einem älteren E-Mail-System installieren, dass SMTP nicht beherrscht, wird dieses Protokoll für keine Verbindung benötigt. Sobald Sie zu einer reinen Exchange Server 2007/2010-Umgebung übergegangen sind, brauchen Sie sich in der allergrößten Mehrheit der Fälle nicht mehr um X.400 zu kümmern und können sämtliche X.400-Adressen entfernen, die noch irgendwo in den Eigenschaften E-Mail-aktivierter Objekte zurückgeblieben sind. Allerdings müssen Sie diese Adressen auch nicht löschen. Sie richten keinen größeren Schaden an als einige Bytes an Speicherplatz zu belegen. Das mag sich zwar alles sehr kompliziert anhören, doch war es die beste Lösung, dafür zu sorgen, dass Postfachserver jeweils mit einem Hub-Transport-Server derselben Version kommunizieren müssen. Die Alternative hätte darin bestanden, eigene Active Directory-Standorte für Exchange Server 2010 einzurichten, was noch viel Komplizierter geworden wäre. Dabei hätten Sie für jeden vorhandenen Active Directory-Standort mit Exchange Server 2007 einen entsprechenden Exchange Server 2010Standort erstellen und die Computer mit Exchange Server 2010 in den neuen Standorten installieren müssen. Nach all dieser Arbeit hätten sie dann irgendwann dafür sorgen müssen, dass die alten Active Directory-Standorte nach der Außerdienststellung von Exchange Server 2007 wieder entfernt werden.
Konfigurationseinstellungen für den Transport In Exchange Server 2000 und 2003 definierten die globalen Nachrichtenenstellungen Eigenschaften wie die maximale Nachrichtengröße. Exchange Server 2007 bietet keine Möglichkeit, in der ExchangeVerwaltungskonsole globale Standardeinstellungen für das Messaging festzulegen. In Exchange Server 2010 können Sie unter Organisationskonfiguration im Knoten Hub-Transport auf Globale Einstellungen klicken, um Zugriff auf einige der Parameter zu erhalten, die steuern, wie das Transportsystem arbeitet. Abbildung 13.3 zeigt die Registerkarte Allgemein des Dialogfelds Transporteinstellungen-Eigenschaften. In der Exchange-Verwaltungskonsole können jedoch nur die am häufigsten veränderten globalen Transporteinstellungen angezeigt werden. Vollständigen Zugriff erhalten Sie über die Cmdlets GetTransportConfig und Set-TransportConfig zum Abrufen bzw. Festlegen der Transportkonfigurationseinstellungen. In einer Organisation im gemischten Modus werden Einstellungen wie diejenigen für die maximale Größe eingehender und ausgehender Nachrichten und die höchstzulässige Anzahl von Empfängern pro Nachricht beibehalten, doch werden die Werte für diese Parameter in einer neuen Organisation auf jeweils 20 MB bzw. 5000 Empfänger festgelegt. Die Einstellungen, die Get-TransportConfig für eine Organisation meldet, sehen wie die folgende Beispielausgabe aus.
786
Konfigurationseinstellungen für den Transport
Globale Transporteinstellungen
Das Exchange-Transportsystem
Abbildg. 13.3
Wenn Sie das mit der Ausgabe für eine Exchange Server 2007-Organisation vergleichen, stellen Sie fest, dass in Exchange Server 2010 eine Reihe zusätzlicher Einstellungen hinzugekommen sind, die Sie anpassen können. Einige davon (z.B. MigrationEnabled und OpenDomainRoutingEnabled) sind nur für den internen Gebrauch durch Microsoft vorgesehen, wenn Exchange in der Hostingumgebung von Microsoft Business Productivity Online Services bereitgestellt wird. Andere, z.B. ShadowHeartbeatTimeoutInterval, dienen zur Steuerung der in Exchange Server 2010 neu eingeführten Funktionen (weitere Informationen über die Schattenredundanz erhalten Sie im Abschnitt »Schattenredundanz« weiter hinten in diesem Kapitel). Get-TransportConfig ClearCategories
: True
DSNConversionMode
: UseExchangeDSNs
ExternalDelayDsnEnabled
: True
ExternalDsnDefaultLanguage
:
ExternalDsnLanguageDetectionEnabled
: True
ExternalDsnMaxMessageAttachSize
: 10 MB (10,485,760 bytes)
ExternalDsnReportingAuthority
:
ExternalDsnSendHtml
: True
ExternalPostmasterAddress
: [email protected]
GenerateCopyOfDSNFor
: {}
HygieneSuite
: Standard
787
Kapitel 13
Das Exchange-Transportsystem
InternalDelayDsnEnabled
: True
InternalDsnDefaultLanguage
:
InternalDsnLanguageDetectionEnabled
: True
InternalDsnMaxMessageAttachSize
: 10 MB (10,485,760 bytes)
InternalDsnReportingAuthority
:
InternalDsnSendHtml
: True
InternalSMTPServers
: {}
JournalingReportNdrTo
: [email protected]
LegacyJournalingMigrationEnabled
: False
MaxDumpsterSizePerDatabase
: 18 MB (18,874,368 bytes)
MaxDumpsterTime
: 7.00:00:00
MaxReceiveSize
: 20 MB (20,971,520 bytes)
MaxRecipientEnvelopeLimit
: 5000
MaxSendSize
: 20 MB (20,971,520 bytes)
MigrationEnabled
: False
OpenDomainRoutingEnabled
: False
Rfc2231EncodingEnabled
: False
ShadowHeartbeatRetryCount
: 3
ShadowHeartbeatTimeoutInterval
: 00:05:00
ShadowMessageAutoDiscardInterval
: 2.00:00:00
ShadowRedundancyEnabled
: True
OrganizationRelationshipForExternalOrganizationEmail : SupervisionTags
: {Reject, Allow}
TLSReceiveDomainSecureList
: {}
TLSSendDomainSecureList
: {}
VerifySecureSubmitEnabled
: False
VoicemailJournalingEnabled
: True
HeaderPromotionModeSetting
: NoCreate
Xexch50Enabled
: True
Einen neuen Wert für die Transportkonfiguration festzulegen ist ganz einfach: Set-TransportConfig -MaxSendSize 50MB
Tabelle 13.1 führt die wichtigsten Eigenschaften auf, die Sie mit Set-TransportConfig ändern können, und gibt ihre Bedeutung an. Ausführlichere Informationen finden Sie auf TechNet und in der Exchange-Hilfe.
788
Konfigurationseinstellungen für den Transport
Mit Set-TransportConfig zu konfigurierende globale Transporteinstellungen Parameter
Bedeutung
-ClearCategories
Legt fest, ob das Transportmodul Outlook-Kategorien während der Inhaltskonvertierung entfernt. Der Standardwert lautet $True.
-DSNConversionMode
Legt fest, wie Exchange Benachrichtigungen über den Zustellungsstatus (Delivery Status Notifiations, DSNs) handhabt, die von früheren Exchange-Versionen oder anderen Messagingsystemen erstellt werden. Der Standardwert lautet UseExchangeDSN, was die Umwandlung in das DSN-Format von Exchange Server 2010 erzwingt. Alternativ können Sie PreserveDSNBody angeben, wodurch die DSNs zwar ebenfalls ins Format von Exchange Server 2010 konvertiert, alle jeglicher darin enthaltener benutzerdefinierter Text aber beibehalten wird. Außerdem können Sie DoNotConvert angeben, wobei keinerlei Umwandlung stattfindet.
-ExternalDelayDSNEnabled
Gibt an, ob Exchange einen DSN erstellen soll, wenn Nachrichten von externen Empfängern nicht sofort zugestellt werden können. Der Standardwert lautet $True.
-ExternalDSNLanguageDetectionEnabled
Legt fest, ob Exchange versuchen soll, einen DSN in der Sprache der ursprünglichen Nachrichten senden soll. Der Standardwert lautet $True.
-ExternalDSNMaxMessageAttachSize
Legt die Maximalgröße der Anhänge fest, die zusammen mit einem DSN gesendet werden. Der Standardwert beträgt 10 MB. Übersteigt der Anhang diese Größe, sendet Exchange den DSN mit den ursprünglichen Headern, aber ohne den Anhang.
-ExternalPostmasterAddress
Diese Eigenschaft gibt die E-Mail-Adresse an, die Exchange in das Von-Headerfeld eines DSN an einen externen Empfänger einfügt. Der Standardwert lautet $Null, sodass Exchange die standardmäßige Postmasteradresse des Hub- oder Edge-Transport-Servers verwendet, der den DSN erstellt (postmaster@<standardmäßige_akzeptierte_domäne>.com, wobei <standardmäßige_akzeptierte_domäne>.com die standardmäßige akzeptierte Domäne für die Organisation ist. Wenn Sie hier einen Wert eingeben, verwendet Exchange ihn.
-GenerateCopyOfDSNFor
Legt fest, ob DSN-Nachrichten in das Postmaster-Postfach kopiert werden (das Sie mit dem Cmdlet Set-TransportServer definieren). Die gewünschten DSNs werden anhand ihres Codes bestimmt (z.B. 5.1.1). Standardmäßig werden keine Nachrichten kopiert.
-HeaderPromotionModeSetting
Legt fest, ob Exchange benannte Eigenschaften für die Werte in benutzerdefinierten X-Headern eingehender Nachrichten anlegt. Der Standardwert lautet NoCreate, sodass Exchange nichts erstellt. Diese Eigenschaft können Sie auf MustCreate setzen, um das Erstellen zu erzwingen, oder auf MayCreate, sodass benannte Eigenschaften für Nachrichten von authentifizierten Servern erstellt werden.
-InternalDelayDSNEnabled
Gibt an, ob Exchange einen DSN erstellen soll, wenn Nachrichten von internen Absendern nicht sofort zugestellt werden können. Der Standardwert lautet $True.
-InternalDSNMaxMessageAttachSize
Dient einem ähnlichen Zweck wie -ExternalDSNMaxMessageAttachSize und hat ebenfalls den Standardwert von 10 MB.
-InternalSMTPServers
Eien Liste der IP-Adressen von SMTP-Servern, die die Antispam-Agents als interne Server erkennen und daher nicht für mögliche Spamquellen halten.
-JournalingReportNdrTo
Das Postfach, zu dem der Journal-Agent Journalberichte sendet, wenn das Journalpostfach unerreichbar ist.
-MaxDumpterSizePerDatabase
Legt die Größe des Transportpapierkorbs fest, der auf Servern in Datenbankverfügbarkeitsgruppen verwendet wird, um in der Übermittlung befindliche Nachrichten im Fall eines verlustbehafteten Datenbankwechsels wiederherzustellen. Dieser Parameter wird nur verwendet, wenn es Datenbankverfügbarkeitsgruppen gibt. 789
Das Exchange-Transportsystem
Tabelle 13.1
Kapitel 13 Tabelle 13.1
Das Exchange-Transportsystem
Mit Set-TransportConfig zu konfigurierende globale Transporteinstellungen (Fortsetzung) Parameter
Bedeutung
-MaxDumpsterTime
Legt fest, wie lange Nachrichten höchstens im Transportpapierkorb verbleiben. Dieser Parameter wird nur verwendet, wenn es Datenbankverfügbarkeitsgruppen gibt. Um den Transportpapierkorb zu aktivieren, muss seine Größe auf größer null eingestellt werden (ein sinnvoller Wert liegt bei etwa 100 MB) und die Aufenthaltsdauer auf einen von null verschiedenen Wert. Ein guter Standardwert ist 7.00:00:00, also sieben Tage.
-MaxReceiveSize
Die maximale Größe von Nachrichten, die in der Organisation empfangen werden können.
-MaxRecipientEnvelopeLimit
Die maximale Anzahl der Empfänger, die im Header einer eingehenden Nachricht stehen dürfen (Gruppen werden unabhängig von der Anzahl der darin enthaltenen Empfänger als ein Empfänger gezählt).
-MaxSendSize
Legt die maximale Größe der Nachrichten fest, die in der Organisation gesendet werden dürfen.
-Rfc2231EncodingEnabled
Gibt an, ob die MIME-Codierung nach RFC 2231 in der Organisation aktiviert ist. Der Standardwert lautet $True.
-ShadowHeartbeatRetryCount
Gibt die Anzahl der Taktintervalle an, die ein Server abwartet, bis er davon ausgeht, dass der primäre Server für eine Nachricht ausgefallen ist. In diesem Fall übernimmt er selbst den Besitz über die Nachrichten in der Schattenwarteschlange des ausgefallenen Servers. Der Standardwert beträgt 3.
-ShadowHeartbeatTimeoutInterval
Gibt an, wie lange ein Server wartet, bevor er eine Verbindung zu einem primären Server aufnimmt, um den Beibehaltungsstatus von Schattennachrichten abzufragen. Der Standardwert beträgt 00:05:00 (fünf Minuten).
-ShadowMessageAutoDiscardInterval
Gibt an, wie lange ein primärer Server Beibehaltungsereignisse für Schattennachrichten aufbewahrt. Fragt der Schattenserver die Ereignisse nicht innerhalb dieses Intervalls ab, verwirft der primäre Server sie. Der Standardwert beträgt 2.00:00:00 (zwei Tage).
-ShadowRedundancyEnabled
Gibt an, ob die Schattenredundanzfunktion in der Organisation aktiviert ist. Der Standardwert lautet $True.
-TLSReceiveDomainSecureList
Enthält eine Liste der Domänen, die für die gegenseitige TLS-Authentifizierung über Empfangsconnectors eingerichtet sind.
-TLSSendDomainSecureList
Enthält eine Liste der Domänen, die für die gegenseitige TLS-Authentifizierung über Sendeconnectors eingerichtet sind.
-VerifySecureSubmitEnabled
Beim Wert $True müssen MAPI-Clients Nachrichten über einen sicheren Kanal übertragen (verschlüsselte RPCs). Der Standardwert lautet $False. Standardmäßig verwenden Outlook 2007 und 2010 einen sicheren Kanal, frühere Versionen aber nicht.
-VoicemailJournalingEnabled
Legt fest, ob der Journal-Agent Voicemailnachrichten ins Journal aufnehmen kann. Der Standardwert lautet $True.
-Xexch50Enabled
Legt fest, ob die Rückwärtskompatibilität mit Exchange Server 2000 und 2003 aktiviert werden soll. Der Standardwert lautet $True.
Die Einstellungen für die Transportkonfiguration gelten organisationsweit und werden von allen Hub-Transport-Servern mit Exchange Server 2007 oder 2010 respektiert. Andere Befehle wirken sich darauf aus, wie die Nachrichten vom Transportmodul verarbeitet werden. Beispielsweise können Sie für Empfangsconnectors Parameter wie die maximale Anzahl der Empfänger einer Nachricht und die maximale Anzahl der insgesamt oder von einer bestimmten Quelle akzeptierten Verbindungen festlegen. Betrachten Sie dazu das folgende Beispiel: Set-ReceiveConnector –Identity 'Internet Connector for Organization'
790
Konfigurationseinstellungen für den Transport
Wenn der Connector nach dieser Änderung eine Nachricht erhält, die an über 250 Empfänger geht, akzeptiert er sie nur die höchstzulässige Anzahl von Empfängern (also 250) und lehnt den Rest ab. Die meisten modernen SMTP-Absender senden die Nachricht dann wiederholt mit jeweils der maximalen Empfängeranzahl, bis alle Empfänger berücksichtigt wurden. Nachdem ein Empfangsconnector eine Nachricht akzeptiert hat (also am Ende der Datenübertragung), prüft er, ob sie zu groß ist (ob ihre Größe also den Wert von -MaxMessageSize übersteigt). Wenn Sie in der Lage sind, eine sehr umfangreiche Nachricht zu senden, heißt das noch lange nicht, dass sie auch ihren endgültigen Bestimmungsort erreichen kann. Liegt das Ziel außerhalb der Exchange-Organisation, ist es sehr wahrscheinlich, dass die Nachricht in einem externen Connector oder auf einem Server unterwegs einen Grenzwert überschreitet, was zu ihrer Ablehnung führt. Selbst innerhalb einer Exchange-Organisation kann die Nachricht zurückgewiesen werden, wenn ein Benutzer, der E-Mails mit bis zu 10 MB senden darf, eine derartig große Nachricht an ein Postfach schickt, für das ein niedrigerer Grenzwert für den Empfang eingerichtet ist. In diesem Fall erhält der Absender eine Benachrichtigung wie die in Abbildung 13.4. Abbildg. 13.4
Unzustellbarkeitsbericht beim Senden einer zu großen Nachricht
Der Standardwert für die maximale Nachrichtengröße von Sende- und Empfangsconnectors beträgt 10 MB. Um diesen Wert für einen Sendeconnector zu ändern, verwenden Sie folgenden Befehl: Set-SendConnector –Identity 'Outbound to Legacy' –MaxMessageSize 20MB
Bei einem Empfangsconnector gehen Sie wie folgt vor: Set-ReceiveConnector –Identity 'Inbound from Fabrikam' –MaxMessageSize 15MB
791
Das Exchange-Transportsystem
–MaxRecipientsPerMessage 250
Kapitel 13
Das Exchange-Transportsystem
Wenn Sie die Kennungen für die verschiedenen Connectors in der Organisation nicht kennen, rufen Sie mit Get-SendConnector bzw. Get-ReceiveConnector eine Liste aller zurzeit vorhandenen Connectors ab. Dabei werden auch die Connectors von Edge-Transport-Servern aufgeführt. Es ist möglich, dass sich die Größe einer Nachricht zwischen dem ursprünglichen Eintrittspunkt auf einem Edge- oder Hub-Transport-Server und der endgültigen Zustellung ändert, z.B. aufgrund von Formatänderungen, Codierung und der Verarbeitung durch Agents. Allerdings wäre es unschön, wenn eine Nachricht nur deshalb abgelehnt würde, weil ihre Größe aufgrund der Verarbeitung unterwegs angeschwollen ist. Wenn eine Nachricht zum ersten Mal durch einen Hub-Transport-Server läuft, markiert Exchange sie daher mit dem X-Header X-MS-Exchange-Organization-OriginalSize und speichert in diesem Feld die ursprüngliche Nachrichtengröße. Die nachfolgenden Überprüfungen durch die Hub-Tansport-Server in anderen Standorten ziehen zur Entscheidung, ob die Nachricht blockiert oder weitergeleitet werden soll, die Angabe in diesem Feld heran und nicht die aktuelle Nachrichtengröße. Beachten Sie, dass einige Nachrichten diese Überprüfung umgehen, z.B. Systemnachrichten, von Agents erstellte Mails und alles, was mit den Journal- und Quarantänefunktionen zu tun hat. Der Parameter -MaxRecipientEnvelopeLimit bestimmt die maximale Anzahl der Empfänger, die sich im P1-Umschlag einer Nachricht befinden dürfen. Eine im Nachrichtenheader angegebene Gruppe wird dabei als ein einziger Empfänger gezählt.
Grenzwerte für Benutzerpostfächer Selbst wenn der Empfangsconnector eine Nachricht annehmen kann, müssen noch weitere Überprüfungen durchgeführt werden, um sicherzustellen, dass Exchange die eingehenden Nachrichten verarbeiten kann, denn für einzelne Postfächer können Grenzwerte gelten, die unterhalb derjenigen für die Organisation liegen. Nehmen wir beispielsweise an, ich hätte Folgendes getan: Set-Mailbox –Identity Redmond –MaxReceiveSize 2MB
Da für dieses Postfach jetzt eine maximale Nachrichtengröße von 2 MB gilt, lehnt Exchange sämtliche Nachrichten an dieses Postfach ab, die diese Größe übersteigen, auch wenn der Empfangsconnector und die globalen Transporteinstellungen sie erlauben würden. Beachten Sie, dass für authentifizierte Benutzer auch eine maximale Sendegröße eingerichtet werden kann, die Exchange selbst dann respektiert, wenn sie den Grenzwert des Connectors übersteigt. Dahinter steckt wahrscheinlich die Überlegung, dass Administratoren schon wissen, was sie tun, wenn sie bestimmten Postfächern erlauben, sehr große Nachrichten zu senden. Exchange behandelt diese Fälle daher als Ausnahmen und lässt diese Nachrichten passieren. Ein weiterer verwirrender Umstand ist die Bedeutung des Begriff »unbegrenzt« (unlimited) für ein Postfach. Wie bereits gesagt, können Sie für ein Postfach eine maximale Größe für die eingehenden Nachrichten sowie eine maximale Sendegröße festlegen. Standardmäßig weisen neu erstellte Postfächer dabei den Wert unlimited auf. Wenn Sie sich diese Einstellungen ansehen, erhalten Sie eine ähnliche Ausgabe wie die folgende: Get-Mailbox | Sort DisplayName | Format-Table DisplayName, Max*Size –AutoSize
792
DisplayName
MaxSendSize
MaxReceiveSize
-----------
-----------
--------------
Administrator
unlimited
unlimited
Abrus, Luka
unlimited
unlimited
Adams, Terry
unlimited
unlimited
Alexander, David
unlimited
unlimited
Americas Help Desk
unlimited
unlimited
Anderson, Nancy (Sales)
unlimited
unlimited
Unlimited, also unbegrenzt, heißt hier, dass Exchange bei der Verarbeitung von Nachrichten keine postfachspezifischen Einschränkungen anwendet, aber nicht, dass das Postfach über die organisationsweiten und connectorspezifischen Grenzwerte hinaus Nachrichten beliebiger Größe senden oder empfangen könnte. Wenn Sie für ein Postfach einen sehr hohen Grenzwert für die Empfangsgröße angeben, wird er ignoriert, wenn in der Organisation oder im Connector niedrigere Limits gelten. Gilt für ein Postfach ein niedrigerer Grenzwert als für die Organisation oder die Connectors, verarbeitet Exchange größere eingehende Nachrichten zunächst und lehnt sie erst dann ab, wenn sie zu dem Postfach gelangen. Für Erbsenzähler: Laut Dokumentation beträgt die Höchstgrenze, die Sie für die maximale Sendeund Empfangsgröße festlegen können, 2 GB, aber der größte Wert, den ich in der Exchange-Verwaltungsshell angeben konnte, war 1,9999 GB. Diesen Wert jedoch meldete Exchange wiederum als 2 GB. Leider war ich nie in der Lage, eine Nachricht mit 2 GB zu senden, um zu überprüfen, ob sie auch tatsächlich zugestellt wird.
Die Transportkonfigurationsdatei Bis jetzt haben wir nur die organisationsweiten Transporteinstellungen besprochen. Die serverspezifischen Transporteinstellungen für Hub- und Edge-Transport-Server mit Exchange Server 2007 und 2010 werden durch die XML-Konfigurationsdatei EdgeTransport.exe.config festgelegt, die sich im Verzeichnis \Bin befindet. Die Version von Exchange Server 2010 weist gegenüber ihrem Gegenstück aus Exchange Server 2007 viele weitere Einträge und Steuereinstellungen auf, z.B. den Speicherort der Warteschlangendatenbank sowie verschiedene Schwellenwerte, die die Leistung des Transportsystems regeln. Normalerweise brauchen Sie diese Transportkonfigurationsdatei nicht anzufassen, es sei denn, Sie müssen einen Parameter anpassen, auf den Sie in der Exchange-Verwaltungsshell keinen Zugriff haben. Wenn Sie beispielsweise den Speicherort der Datenbank für Transportwarteschlangen ändern möchten, finden Sie dazu keinen Parameter im Cmdlet Set-TransportConfig, sondern müssen die Transportkonfigurationsdatei in einem Texteditor öffnen und die Standardeinstellungen bearbeiten, um dem Transportdienst mitzuteilen, wo sich die Dateien befinden. Mit den folgenden Zeilen geben Sie beispielsweise einen nicht dem Standard entsprechenden Speicherort auf Laufwerk D: für die Datenbank der Transportwarteschlange und die zugehörigen Transaktionsprotokolle an:
Nachdem Sie diese Änderung an der Transportkonfigurationsdatei vorgenommen haben, müssen Sie den Transportdienst beenden und die Warteschlangendatenbank und die zugehörigen Dateien zu dem neuen Speicherort verlagern. Erst danach können Sie den Transportdienst wieder neu starten.
793
Das Exchange-Transportsystem
Konfigurationseinstellungen für den Transport
Kapitel 13
Das Exchange-Transportsystem
Eine weitere Anpassung, die häufiger vorgenommen wird, besteht darin, in die Transportkonfigurationsdatei Zeilen aufzunehmen, die festlegen, wie der Transportdienst vorgehen soll, wenn die Hubund Edge-Transport-Server unter Last arbeiten. Bei Exchange Server 2007 und 2010 gibt es das Prinzip des Rückstaus, was bedeutet, dass ein überlasteter Server keine neuen Verbindungen mehr annimmt, um seine Last zu verringern. Wenn sich die Bedingungen gebessert haben, die zu diesem Rückstau führten, nimmt der Transportdienst wieder eine normale Arbeitsweise auf. Um zu bestimmen, wann eine Rückstaubedingung vorherrscht, werden Umstände wie der freie Festplattenplatz und der verfügbare Arbeitsspeicher herangezogen. Gibt es beispielsweise auf der Festplatte mit der Datenbank für die Nachrichtenwarteschlange weniger als 4 GB freien Speicherplatz (auf der Festplatte insgesamt oder für die Datenbank), wendet Exchange einen Rückstau an. Sobald so etwas geschieht, werden die entsprechenden Ereignisse im Anwendungsprotokoll vermerkt. Beispielsweise zeichnet die Komponente MSExchangeTransport das Ereignis 15006 auf, wenn der verfügbare Festplattenplatz unter einen festgelegten Schwellenwert fällt. Die Reaktion von Exchange auf Rückstaubedingungen können Sie ändern, indem Sie die Transportkonfigurationsdatei bearbeiten. Das ist eine ziemlich schwierige Aufgabe, da Sie genau verstehen müssen, warum solche Bedingungen auftreten, bevor Sie die Maßnahmen ändern können, die in einer Situation ergriffen werden. Nachdem Sie eine Anpassung vorgenommen haben, müssen Sie warten, bis das Transportsystem neu gestartet ist und sich unter Last stabilisiert hat, bevor Sie erkennen können, ob diese Änderungen von Erfolg gekrönt waren. Es ist daher erforderlich, den Server genau zu beobachten, bis Sie sicher sein können, dass Ihre Änderungen langfristig die gewünschten Auswirkungen zeigen. VORSICHT Eine Gefahr, der Sie sich bewusst sein müssen, besteht darin, dass Sie bei der Bearbeitung einer Konfigurationsdatei in einem Texteditor sehr leicht Fehler machen können. Der Editor von Windows, WordPad und ähnliche Programme geben Ihnen keinerlei Hinweise auf Syntaxfehler. Wenn es ein Problem gibt, zeigt sich das erst, wenn der Transportdienst beim Neustart versucht, die Konfigurationsdatei zu lesen. Daher sollten Sie einen XML-fähigen Editor wie Microsoft XML Notepad verwenden, um das Risiko von Syntaxfehlern bei der Bearbeitung zu verringern. Gehen Sie bei solchen Änderungen sehr vorsichtig vor und überprüfen Sie sie auf einem Testsystem, bevor Sie sie in der Produktion anwenden.
Zwischenspeichern der Ergebnisse der Gruppenaufgliederung Nicht alle verfügbaren Einstellungen sind in der Transportkonfigurationsdatei enthalten. Beispielsweise weist Exchange etwas Arbeitsspeicher zu, um die Mitgliederliste einer Verteilergruppe zur Verarbeitung während der Nachrichtenkategorisierung zwischenzuspeichern. Die zwischengespeicherten Daten werden untersucht, um doppelte Adressen zu erkennen, die aufgrund der Gruppenerweiterung zustande kommen. Ein ähnlicher Cache wird verwendet, um die Zustelleinschränkungen zu bestimmen, die es möglicherweise für einzelne Empfänger in der Gruppe gibt (beispielsweise, ob der Absender überhaupt Nachrichten an den Empfänger schicken darf). Nur der global eindeutige Active Directory-Bezeichner (Globally Unique Identifier, GUID) für jeden Empfänger wird zwischengespeichert (16 Byte), und die Caches werden für jede Nachricht wiederverwendet, sodass der verfügbare Arbeitsspeicher sehr wirtschaftlich genutzt wird. Standardmäßig weist Exchange beiden Caches 1,6 MB zu, was für die GUIDs von bis zu 100.000 Empfängern ausreicht. Das sollte selbst für eine vollständig erweiterte Empfängerliste der kompliziertesten Verteilergruppen mit vielen verschachtelten Gruppen genügen. 794
Verarbeitung sehr großer Verteilergruppen
Wenn Ihre Exchange-Installation sehr große Verteilergruppen verarbeiten muss, können Sie die Cachegröße ändern, indem Sie die folgenden Schlüssel hinzufügen und darin einen Wert für die Anzahl der Empfänger im Cache angeben: 쐍 MaxResolveRecipientCacheSize legt fest, wie viel Arbeitsspeicher zur Zwischenspeicherung von Empfänger-GUIDs verwendet wird. Da die GUIDs eindeutig sind, lassen sich doppelte Einträge leicht aufspüren. 쐍 MaxResolverMemberofGroupCacheSize legt fest, wie viel Arbeitsspeicher zur Zwischenspeicherung der Gruppenmitgliedschaft des Absenders einer Nachricht verwendet wird. Exchange nutzt den Cache, um zu überprüfen, ob auf irgendwelche verschachtelten Gruppen, die erst nach der Erweiterung der Empfängerliste sichtbar werden, Einschränkungen anzuwenden sind. Dadurch wird es vermieden, mehrfach in Active Directory nachzuschlagen. Auch Exchange Server 2007 entfernt beim Erweitern der Gruppenmitgliedschaft doppelte Adressen und prüft nach, ob Einschränkungen anzuwenden sind, aber die Erfahrung hat gezeigt, dass die Leistung sehr schlecht war, wenn Exchange eine sehr große Verteilergruppe mit vielen darin verschachtelten Gruppen und komplizierten Zustelleinschränkungen verarbeiten musste. Um sich ein Bild davon zu machen, mit welchen Problemen ein E-Mail-System beim Umgang mit Nachrichten für eine sehr große Menge von Empfängern zu kämpfen hat, stellen Sie sich eine Gruppe vor, die dazu dient, allen Benutzern zu erlauben, Nachrichten an jeden anderen Benutzer in einem Unternehmen zu senden. In einer großen Organisation ist es sehr unwahrscheinlich, dass eine solche Gruppe aus einzelnen Empfängern zusammengesetzt wird. Wahrscheinlich wird nicht einmal eine dynamische Verteilergruppe für diesen Zweck erstellt. Selbst bei einer starken Verzahnung zwischen dem Personalsystem und Exchange wäre die Pflege der Mitgliederliste einer solchen Gruppe ein Albtraum, und auch die Benutzeroberfläche von Programmen wie der Exchange-Verwaltungskonsole ist nicht für den Umgang mit Listen gedacht, die mehr als 2000 Mitglieder umfassen. Außerdem bringt auch Windows seine eigenen Probleme bei der Handhabung sehr großer Gruppen mit sich. Windows Server 2003 und höher können Operationen wie die Aktualisierung der Mitgliedschaft großer Gruppen sehr viel besser durchführen, allerdings ist Windows immer noch nicht dafür optimiert, mit Gruppen von 50.000 oder gar 100.000 Mitgliedern umzugehen. Die gewöhnliche Vorgehensweise in solchen Fällen besteht daher darin, eine organisationsweite Verteilergruppe aus vielen kleineren Gruppen zusammenzustellen, von denen jede für eine Abteilung oder eine andere Einheit der Organisation steht. Die Kombination all dieser Gruppen zu einer »Supergruppe« lässt sich viel besser handhaben, da Sie die Verantwortung für die Pflege der Gruppenmitgliedschaft auf die Abteilungen verteilen können. Außerdem vermeiden Sie dadurch Probleme mit der Software zum Auflisten und Aktualisieren der Gruppenmitgliedschaft. Allerdings muss Exchange immer noch mit diesen Supergruppen umgehen, wenn Sie sie zur Adressierung von Nachrichten verwenden. Jede der Untergruppen muss erweitert werden, wobei jede ihre eigenen Einschränkungen aufweisen kann (beispielsweise kann es sein, dass nur bestimmte Benutzer Nachrichten an den Geschäftsführer senden dürfen), und es besteht durchaus die Wahrscheinlichkeit, dass einzelne Empfänger doppelt auftreten, wenn manche Personen mehreren Abteilungen angehören. Exchange Server 2007 kann alle Gruppen in einer Supergruppe erweitern und Nachrichten an eine sehr große Menge von Empfängern adressieren. In Ermangelung eines Caches, in dem die Empfängermitgliedschaft und die Einschränkungen bestimmt werden können, führt jedoch dazu, dass Exchange Server 2007 beim Aufbau der Empfängerliste ständig auf Active Directory zugreifen muss. Selbst die schnellsten Server brauchen 20 oder 30 Minuten, um eine sehr lange Liste zu verarbeiten, 795
Das Exchange-Transportsystem
Konfigurationseinstellungen für den Transport
Kapitel 13
Das Exchange-Transportsystem
wobei die globalen Katalogserver für die Active Directory-Suche durch die Abfragen von Exchange stark belastet werden. In Exchange Server 2010 wurden diese Caches jedoch hinzugefügt, sodass diese Version die Gruppenmitgliedschaft viel schneller auflösen kann und dabei auch erheblich weniger Active Directory-Abfragen stellen muss. HINWEIS Microsoft hat die Größe der Caches so festgelegt, dass sie für alle außer den extremsten Situationen geeignet sind. Ändern Sie die Werte daher nur, wenn Sie Beweise dafür haben, dass die Hub-Transport-Server Schwierigkeiten bei der Verarbeitung sehr großer Gruppen haben. Wenn Nachrichten an eine Supergruppe z.B. nicht innerhalb von fünf Minuten zugestellt werden, kann das ein Zeichen dafür sein, dass Exchange mehr Cachespeicher benötigt, vor allem, wenn die erweiterten Gruppen mehr als 100.000 Empfänger aufweisen.
Routingtabellen Die Routingtabelle enthält Angaben zu den Servern, Datenbanken und Connectors in einer Organisation und wird vom Transportsystem genutzt, um zu bestimmen, wie Nachrichten am besten weitergeleitet werden. Sie wird im Arbeitsspeicher zwischengespeichert und dient als Grundlage für Routingentscheidungen. Exchange berechnet seine Routingtabellen jedes Mal, wenn der Transportservice neu gestartet wird oder wenn die in Active Directory festgehaltenen Exchange-Konfigurationsdaten auf eine Weise geändert wurden, die sich auf das Routing auswirken kann. Das betrifft beispielsweise Änderungen wie das Hinzufügen neuer Connectors, die Ergänzung der Connectorangaben um die Definiertion eines neuen Adressraums und die Installation eines neuen Hub-Transport-Servers. Außerdem werden die Routingtabellen auch dann geändert, wenn die Hub- und Edge-Transport-Server das Kerberos-Token für die sichere Kommunikation mit Active Directoy erneuern, was alle sechs Stunden geschieht. Auch wenn keine Änderungen an der Routingkonfiguration stattfinden, schreibt der Transportdienst alle zwölf Stunden eine Momentaufnahme der aktuellen Routingtabelle in eine XML-Protokolldatei, die Sie im Verzeichnis C:\Programme\Microsoft\Exchange Server\TransportRoles\Logs\Routing finden. Falls nötig können Sie das Intervall ändern, indem Sie die Variable RoutingConfigReloadInterval in der Konfigurationsdatei EdgeTransport.exe.config ändern, die Sie im Verzeichnis \Bin finden. Die Routingprotokolldateien werden nach dem Muster RoutingConfig#x@mm_dd_yyyy hh_mm_ss.xml benannt. Beispielsweise heißt die am 18. Februar 2010 um 5.56.12 Uhr (UTC) erstellte Protokolldatei mit der laufenden Nummer 56 RoutingConfig#56@02_18_2010 05_56_12.xml. Standardmäßig bewahrt Exchange die Routingtabellen der letzten sieben Tage bzw. bis zu 50 MB an Dateien auf. Selbst in einer Organisation, in der sich die Routinginfrastruktur ständig ändert, reichen 50 MB aus, um die Protokolldateien von sieben Tagen festzuhalten. Wird der Speicherplatz trotzdem ausgeschöpft, greift Exchange auf den Mechanismus der Umlaufprotokollierung zurück und verwirft die ältesten Protokolle, um Platz für neue Dateien zu schaffen. Die Werte hierfür können Sie mit dem Cmdlet Get-TransportServer abrufen und mit Set-TransportServer festlegen: Get-TransportServer –Identity ExServer2 Name
: ExServer2
RoutingTableLogMaxAge
: 7.00:00:00
RoutingTableLogMaxDirectorySize : 50 MB (52,428,800 bytes) RoutingTableLogPath
: C:\Program Files\Microsoft\Exchange Server\V14\ TransportRoles\Logs\Routing
796
Eine Routingtabelle besteht aus 23 Abschnitten, die zusammen das gesamte Wissen von Exchange über die aktuelle Routingtopologie des Standorts bilden, in dem sich der betreffende Server befindet. Jede Standort kann eine andere Routingtabelle aufweisen, da Sie Connectors mit eingeschränktem Bereich erstellen können, die nur für die Hub-Transport-Server innerhalb eines Standorts zur Verfügung stehen, für externe Server aber nicht sichtbar sind. In einem solchen Fall weicht die Routingtabelle für den Standort mit dem eingeschränkten Connector von der in den anderen Standorten ab. Wenn Sie jemals Routingtabellen überprüfen müssen, um ein Routingproblem zu lösen, müssen Sie daher genau darauf achten, dass Sie mit dem Server verbunden sind, auf dem Sie das Problem vermuten, und dessen Routingtabelle als Ausgangspunkt verwenden. Eine Routingtabelle können Sie in einem Browser öffnen (wie in Abbildung 13.5), aber auch mit jedem XML-Editor und mit der Routingprotokollanzeige aus der Toolbox von Exchange. Wenn Sie sich den nackten XML-Code anschauen, können Sie die Einzelheiten der Struktur einer Routingtabelle erkennen. Sie ist in die folgenden Abschnitte für die verschiedenen Aspekte der ExchangeRoutingumgebung eingeteilt: 쐍 Routing Tables Gibt grundlegende Informationen über die Routingtabelle, z.B. Erstelldatum und -uhrzeit, sowie Angaben über Servernamen (zur Unterscheidung der Server werden die vollständigen definierten Active Directory-Namen verwendet), Postfachdatenbanken und ältere Server mit Serverrouten. 쐍 Exchange Topology Ordner die Servernamen den Topologieservern (also den Servern, die sich am Routing beteiligen können). 쐍 Topology Servers können.
Führt die Exchange Server-Computer auf, die sich am Routing beteiligen
쐍 Topology Sites Führt alle Active Directory-Standorte auf, auch diejenigen, in denen es keine Hub-Transport-Server gibt. 쐍 Topology Site Link Führt alle Active Directory-Standortverknüpfungen auf. 쐍 Active Directory Site Relay Map Führt alle Active Directory-Pfade zu sämtlichen Standorten mit Exchange Server-Computern auf. 쐍 Active Directory Topology Path auf. 쐍 Target Site
Führt die Routen zu allen Active Directory-Remotestandorten
Führt die Active Directory-Standorte mit Hub-Transport-Servern auf.
쐍 Routing Group Relay Map nen auf.
Führt die Routinggruppen für Server mit älteren Exchange-Versio-
쐍 Routing Group Topology Site Führt alle Routinggruppen und ihre Connectors auf. 쐍 Routing Group Topology Link Führt die Verknüpfungen zwischen den Routinggruppen auf. 쐍 Routing Group Topology Path
Ordnet Routinggruppen den Connectors zu.
쐍 Routing Group Connector Route 쐍 Server Routing
Führte alle Exchange Server-Computer und die Routen zu ihnen auf.
쐍 Home Mdb Routing Ordner). 쐍 Connector Routing 쐍 Connector Route
Führt die Routen zum nächsten Hop der Connectors auf.
Führt alle Datenbanken in der Organisation auf (auch die für öffentliche Führte jede Connectorroute in der Organisation auf.
Führen jeden Connector in der Organisation auf.
쐍 SMTP Send Connector Configuration auf.
Führt jeden SMTP-Sendeconnector in der Organisation
797
Das Exchange-Transportsystem
Konfigurationseinstellungen für den Transport
Kapitel 13
Das Exchange-Transportsystem
쐍 Address space Führt alle Andressräume und verfügbaren Andresstypen in der Organisation auf. 쐍 Legacy Gateway Connector Führt alle Notes- und GroupWise-Connectors in der Organisation auf, die von Exchange Server 2000 oder 2003 verwendet werden. Wie bereits erwähnt kann Exchange Server 2010 solche älteren Connectors nicht handhaben. Die Verbindungen müssen über einen Computer mit Exchange Server 2003 gehen. 쐍 Non-SMTP Gateway Connection Führt alle Connectors auf, die das Dropverzeichnis verwenden. 쐍 Address Type Routing
Ordnet Adresstypen dem SMTP-Connectorindex zu.
쐍 SMTP Connector Index Ordnet jeden Teil des SMTP-Adressraums einem Knoten zu und verknüpft ihn mit einem Connector. Beispielsweise ruft contoso.com Knoten für contoso und für com hervor. Abbildg. 13.5
Ein Routingprotokoll von Exchange Server 2010
Die reinen XML-Daten sind zwar interessant, lassen sich aber nur schwer deuten, da sehr viel an wichtigen Informationen in der XML-Formatierung steckt. Die Routingprotokollanzeige (siehe Abbildung 13.6) interpretiert den XML-Code, um die Routingtabelle anzuzeigen. Mit diesem Hilfsprogramm können Sie eines der Routingprotokolle auf einem Hub-Transport-Server auswählen und öffnen und seinen Inhalt durchsuchen, um sich anzusehen, welche Connectors zur Verfügung stehen, welche Server diese Connectors verwenden können, für welche Adressräume sie eingerichtet sind usw. Einige der Hindernisse für die Weiterleitung von E-Mails, z.B. die Grenzwerte für die maximale Nachrichtengröße, sind deutlich zu erkennen. Außerdem können Sie sich auch Einzelheiten der Active DirectoryStandortverknüpfungskosten anzeigen lassen, die zur Berechnung der günstigsten Route herangezogen werden, und erkennen, ob den Standortverknüpfungen zusätzlich Exchange-Kosten zugeordnet wurden. Als Hilfe zur Fehlerbehebung können Sie zwei Routingprotokolle miteinander vergleichen,
798
um herauszufinden, ob es Abweichungen zwischen den beiden Konfigurationen gibt. Leider gibt es keine Möglichkeit, einen Bericht der Konfiguration zur Archivierung auszugeben. Allerdings können Sie Screenshots aufnehmen und in Dokumente einfügen, falls Sie eine solche Möglichkeit brauchen. Abbildg. 13.6
Die Routingprotokollanzeige
TLS-Sicherheit In früheren Exchange-Versionen mussten Sie TLS manuell konfigurieren und ein Zertifikat dafür installieren, bevor die Server den Datenverkehr verschlüsseln konnten. In Exchange Server 2010 ist dieser Vorgang sehr viel einfacher, da TLS standardmäßig aktiviert ist und die Kommunikation zwischen den Hub-Transport-Servern automatisch mit TLS geschützt wird. Dazu dient entweder ein selbst signiertes Zertifikat, das Exchange erstellt, oder ein Zertifikat, das Sie eigens für diesen Zweck installieren. Alle eingehenden SMTP-Sitzungen können verschlüsselt werden, wobei Exchange Server 2010 jedoch versucht, sämtliche Remotesitzungen zu verschlüsseln, auch diejenigen zu anderen Messagingsystemen. Das Vorhandensein von selbst signierten Zertifikaten reicht aus, um Exchange Server 2010 zu erlauben, eine verschlüsselte Verbindung zu anderen SMTP-Server auszuhandeln, die die Funktion des »opportunistischen TLS« beherrschen. Kurz gesagt können die Server selbst herausfinden, ob und wie sie einander für den Austausch geschützten SMTP-Datenverkehrs vertrauen können. Das ist eine gute Sache, es sei denn, dass so genannte WAN-Optimierungscontroller (WOCs) verwendet werden. Solche Geräte werden gewöhnlich installiert, um die Verwendung des Netzwerks zwischen kleinen Filialen und großen Hub-Standorten zu optimieren, sodass alle Anwendungen, die Daten über diese Verbindungen senden müssen, eine ausreichend gute Netzwerkkapazität nutzen können. Dazu komprimieren WOCs den Datenverkehr über das Netzwerk, was allerdings zu Problemen führen kann, da sich mit TLS geschützter SMTP-Datenverkehr nicht komprimieren lässt. Die Lösung besteht darin, TLS zu deaktivieren. Dadurch können die WOCs den SMTP-Datenverkehr wieder komprimieren, was allerdings zur Folge hat, dass die Daten unverschlüsselt sind. Weitere Informationen
Eine vollständige Beschreibung der Probleme, die sich in solchen Situationen stellen, finden Sie unter http://technet.microsoft.com/de-de/library/ee633456.aspx.
799
Das Exchange-Transportsystem
Konfigurationseinstellungen für den Transport
Kapitel 13
Das Exchange-Transportsystem
Empfangsconnectors Seit dem Wechsel von X.400 in Exchange Server 2000 ist SMTP die Grundlage für das Transportsystem von Exchange. SMTP-Connectors waren schon länger in Exchange enthalten, um eine bidirektionale E-Mail-Kommunikation mit anderen SMTP-Messagingsystemen zu ermöglichen, weshalb der Übergang zu einer reinen SMTP-Umgebung schon immer auf dem Programm stand, seit die Internetprotokolle an Verbreitung zunahmen und X.400 und X.500 als De-facto-Standards für die Interoperabilität verdrängten. Exchange teilt die SMTP-Kommunikation in Sende- und Empfangsconnectors auf. Empfangsconnectors nehmen Nachrichten von anderen SMTP-Servern entgegen. Das können u.a. Exchange Server-Computer sein, aber auch POP3- und IMAP4-Clients, die Nachrichten über SMTP senden. Wenn Sie auf einem Server die Hub-Transport-Rolle installieren, werden dabei zwei standardmäßige Empfangsconnectors angelegt, damit der Server mit den anderen Exchange Server-Computern in der Organisation kommunizieren und Nachrichten von authentifizieren POP3- und IMAP4-Clients entgegennehmen kann. Bei der Installation eines Edge-Transport-Servers wird dagegen nur ein Empfangsconnector zur Annahme von Nachrichten aus dem Internet erstellt. Um sich die standardmäßigen Empfangsconnectors anzusehen, verwenden Sie wie folgt das Cmdlet Get-ReceiveConnector: Get-ReceiveConnector –Server ExServer1 Identity
Bindings
Enabled
---------
--------
--------
ExServer1\Default ExServer1
{:::25, 0.0.0.0:25}
True
ExServer1\Client ExServer1
{:::587, 0.0.0.0:587}
True
Zwei Empfangsconnectors dieser Art können Sie auf jedem Hub-Transport-Server mit Exchange Server 2010 finden. Jeder Empfangsconnector ist so eingerichtet, dass er einen bestimmten Port nach eingehenden Verbindungen für den Server abhört, auf dem er sich befindet. Connectors für Verbindungen zwischen Servern lauschen dabei auf Post 25, dem Standardport für Nachrichten von einem Server zu einem anderen, während Connectors für Nachrichten von POP3- und IMAP4-Clients Port 587 abhören. Standardmäßig müssen Clientverbindungen authentifiziert werden, was bedeutet, dass nur Nachrichten von Clients angenommen werden, die sich mithilfe von Windows-Anmeldeinformationen authentifizieren können oder die über Exchange-Postfächer verfügen. Das ist eine Änderung gegenüber dem Verhalten der Connectors in Exchange Server 2003, die es auch nicht authentifizierten POP3- und IMAP4-Clients erlaubten, Verbindung aufzunehmen und Nachrichten zu senden. Die standardmäßigen Empfangsconnectors nehmen Nachrichten von allen IP-Adressen entgegen, Sie können sie aber auf bestimmte Adressen einschränken. In den Eigenschaften eines Connectors ist festgelegt, welche Server Nachrichten über ihn senden können. Eine grundlegende Steuerungsmöglichkeit besteht darin, die Menge der Quellen einzuschränken, von denen der Connector Nachrichten entgegennimmt. Dazu wird nicht einzelnen Benutzern, sondern Berechtigungsgruppen der Zugriff auf den Connector erlaubt. Eine Berechtigungsgruppe ist einer der üblichen Sicherheitsprinzipale wie ein Benutzer oder eine Gruppe, dem eine vordefinierte Menge von Berechtigungen für ein Objekt (in diesem Fall für den Connector) zugewiesen ist. Exchange nutzt Berechtigungsgruppen zur einfacheren Konfiguration des Zugriffs auf einen Connector. Es ist sehr viel einfacher, die Sicherheit mithilfe von Gruppen einzurichten, die für etwas wie z.B. »jeder mit einem Exchange-Postfach« (Exchange-Benutzer) oder »jeder andere Exchange ServerComputer in dieser Organisation« (Exchange-Server) steht, als Berechtigungen zu einzelnen Objekten
800
zuzuweisen. Einzelheiten über alle Berechtigungsgruppen und die damit verbundenen Berechtigungen finden Sie online auf TechNet. Um Ihnen ein Beispiel zu geben, führt Tabelle 13.2 die Berechtigungen der Berechtigungsgruppen Anonyme Benutzer und Exchange-Benutzer auf. Tabelle 13.2
Beispielhafte Berechtigungsgruppen Berechtigungsgruppe
Sicherheitsprinzipal
Enthaltene Berechtigungen
Anonyme Benutzer
Anonyme Benutzerkonten
Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Authoritative-DomainSender Ms-Exch-Accept-Headers-Routing
Exchange-Benutzer
Authentifizierte Benutzerkonten
Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Recipient Ms-Exch-Bypass-Anti-Spam Ms-Exch-Accept-Headers-Routing
Der in Abbildung 13.7 gezeigte Standardconnector lässt Verbindungen von Objekten der folgenden Berechtigungsgruppen zu: 쐍 Anonyme Benutzer 쐍 Exchange-Benutzer 쐍 Exchange-Server 쐍 Vorversionen von Exchange Server Abbildg. 13.7
Berechtigungsgruppen für einen Empfangsconnector
Das stellt eine Abweichung von der Standardeinstellung dar, die Exchange Server 2010 für neue erstellte Empfangsconnectors festlegt. Durch die Hinzunahme von Anonyme Benutzer erlauben Sie auch Verbindungen von SMTP-Servern, die sich nicht selbst authentifizieren, z.B. von Exchange Server-Computern in einer anderen Organisation oder anderen SMTP-Servern irgendwo im Internet.
801
Das Exchange-Transportsystem
Empfangsconnectors
Kapitel 13
Das Exchange-Transportsystem
Insidertipp: Anonyme Verbindungen für Empfangsconnectors
Es ist bemerkenswert, dass Microsoft anonyme Verbindungen in der Standardkonfiguration ausschließt, vielleicht in der Annahm, dass Nachrichten, die aus dem Internet zu Hub-Transport-Servern gelangen zunächst einen Edge-Transport-Server passieren. Wenn das der Fall ist, besteht tatsächlich keine Notwendigkeit für anonyme Verbindungen, da die Verbindung zwischen einem Edge- und einem Hub-Transport-Server stets mit TLS geschützt wird. Edge-Transport-Server erlauben dagegen anonyme Verbindungen, da sie ansonsten keine eingehenden Nachrichten aus dem Internet entgegennehmen könnten. Was Sie sich merken sollten, ist also, dass Sie das Kontrollkästchen für die Berechtigungsgruppe Anonyme Benutzer in dem von Exchange erstellten Standard-Empfangsconnector aktivieren und die Möglichkeit zur Verarbeitung von anonymen Verbindungen hinzufügen müssen, wenn Sie keine Edge-Transport-Server verwenden. Beachten Sie auch, dass dieser Empfangsconnector die Berechtigungsgruppe Partner nicht einschließt, die verwendet wird, wenn gegenseitige TLS-Verbindungen zu einer Remotedomäne eingerichtet sind. Die hier gezeigten Berechtigungsgruppen reichen jedoch für die große Mehrheit aller Hub-Transport-Server mit Exchange Server 2007 und 2010 aus. Sofern Sie keinen schwerwiegenden Fehler begehen und einen Hub-Transport-Server direkt dem Internet aussetzen, können Sie im Empfangsconnector ohne große Sicherheitsbedenken auch die Berechtigungsgruppe Anonyme Benutzer zulassen und damit SMTP-Datenverkehr von anderen Clients und Servern innerhalb der Firewall handhaben. Es mag zwar auch sinnvoll erscheinen, Empfangsconnectors so einzurichten, dass sie nicht authentifizierte Verbindungen zwischen den Servern zulassen, doch betrachten einige Administratoren diese Maßnahme als ein Sicherheitsrisiko. Nach dem Prinzip der standardmäßig eingebauten Sicherheit hat man bei Microsoft entschieden, dass Administratoren die Connectors bewusst ändern müssen, wenn Sie anonyme Verbindungen auf Hub-Transport-Servern erlauben wollen. Genau so wird es in Exchange Server 2007 und 2010 gehandhabt. Bei Edge-Transport-Servern verhält sich die Sache anders, da sie eigens dafür entworfen sind, eingehende Nachrichten von externen Servern anzunehmen und zu verarbeiten, weshalb es nicht sinnvoll wäre, wenn ihre Connectors authentifizierte Verbindungen erzwingen würden. Die zulässigen Verbindungen können Sie mithilfe der Kontrollkästchen auf der Registerkarte Berechtigungsgruppen im Eigenschaftendialogfeld des Connectors ändern, die Sie in Abbildung 13.7 sehen, aber auch mithilfe der Exchange-Verwaltungsshell: Set-ReceiveConnector -Identity 'ExServer1\Default ExServer1' -PermissionGroups 'AnonymousUsers, ExchangeUsers, ExchangeServers, ExchangeLegacyServers'
Denken Sie daran, dass Empfangsconnectors nur für jeweils einen Server gültig sind, weshalb Sie die Änderungen an den Standardempfangsconnectors auf sämtlichen Hub-Transport-Servern in der Organisation vornehmen müssen. Wenn Sie keinen Empfangsconnector einrichten, der anonyme Verbindungen zulässt, erhalten Benutzer, die Nachrichten von anderen E-Mail-Systemen aus senden, einen Unzustellbarkeitsbericht mit dem Fehlercode 5.7.1. Das bedeutet, dass der sendende Server sich nicht authentifizieren konnte, weshalb die Verbindung vom Hub-Transport-Server beendet wurde. Wenn einige Hub-Transport-Server anonyme Verbindungen zulassen und andere nicht, werden Nachrichten, die der eine Connector akzeptiert, von einem anderen abgelehnt, was für ein Messagingsystem ein inakzeptables Verhalten darstellt. Abbildung 13.8 zeigt den Unzustellbarkeitsbericht, den eine Exchange Server 2010-Organisation für eine Nachricht erstellt, die nicht an einen Benutzer in einer anderen Exchange Server 2010-Organisation zugestellt werden konnte. Der entscheidende Hinweis ist in diesem Fall die Zeile 5.7.1 Der Client wurde nicht authentifiziert in den Diagnoseinformationen ganz unten in der Nachricht. 802
Empfangsconnectors
Unzustellbarkeitsbericht aufgrund nicht zulässiger anonymer Verbindungen
Das Exchange-Transportsystem
Abbildg. 13.8
Insidertipp: Empfohlene Vorgehensweisen für eingehende Nachrichten von externen SMTP-Servern
Die einfache Lösung für das Problem, eingehende Nachrichten von externen SMTP-Servern zu akzeptieren, besteht darin, den standardmäßigen Empfangsconnector so zu ändern, dass er anonyme Verbindungen annimmt. Das bedeutet aber, dass für interne und externe Nachrichten dieselbe Konfiguration gilt. Es kann aber durchaus sein, dass Sie externe Nachrichten anders behandeln möchten, um beispielsweise den Benutzern zu erlauben, intern 10 MB große Nachrichten zu verschicken, während eingehende Nachrichten nicht mehr als 5 MB umfassen dürfen. In diesem Fall ist es am besten, eigene Empfangsconnectors für die Verarbeitung des SMTP-Datenverkehrs im Intranet zu erstellen und entsprechend anzupassen. Anschließend können Sie den internen SMTPDatenverkehr der Exchange-Organisation zu den Servern mit diesen Empfangsconnectors leiten.
Erstellen eines Empfangsconnectors Bevor Sie einen neuen Empfangsconnector erstellen, müssen Sie sich darüber im Klaren sein, wozu Sie ihn brauchen und welche zusätzlichen Funktionen er über diejenigen der von Exchange standardmäßig auf allen Hub-Transport-Servern eingerichteten Empfangsconnectors hinaus für die Organisation bietet. Stellen Sie sich unter anderem die folgenden Fragen: 1. Auf welchem Hub-Transport-Server soll der neue Emfpangsconnector untergebracht werden? 2. Welchem Zweck dient der neue Connector? Soll er zwei interne Exchange-Organisationen ver-
binden, andere Formen des internen SMTP-Datenverkehrs handhaben, Exchange Server 2010 mit Exchange Server 2003 verbinden oder eine andere Funktion ausüben? 3. Welche besonderen Einstellungen, z.B. für die maximale Größe eingehender Nachrichten, sollen für diesen Connector gelten? 803
Kapitel 13
Das Exchange-Transportsystem
4. Welche Berechtigungen benötigen die Clients, die diesen Empfangsconnector verwenden?`
Wenn Sie diese Fragen geklärt haben, können den Abschnitt Serverkonfiguration der Exchange-Verwaltungskonsole öffnen. Öffnen Sie den Knoten Hub-Transport, markieren Sie den Server, der den neuen Connector bekommen soll, und wählen Sie die Option Neuer Empfangsconnector. Daraufhin startet die Konsole den gleichnamigen Assistenten. Darin müssen Sie den Namen des neuen Connectors angeben und seinen Zweck aus der Dropdownliste auswählen (siehe Abbildung 13.9). Abbildg. 13.9
Erstellen eines neuen Empfangsconnectors
Der ausgewählte Zweck bestimmt die Berechtigungsgruppen und anderen Einstellungen, die Exchange auf den neuen Connector anwendet. Zur Auswahl stehen die folgenden Möglichkeiten: 쐍 Benutzerdefiniert Hier haben Sie die größte Flexibilität bei der Verwendung des Connectors. Ein Connector dieses Typs lässt sich für viele Zwecke einsetzen, z.B. für Verbindungen zu anderen Gesamtstrukturen und zu anderen SMTP-E-Mail-Systemen innerhalb der Firewall. 쐍 Internet Dieser Typ wird verwendet, um ungehinderte Verbindungen von externen SMTP-Servern zuzulassen. Er ist für Edge-Transport-Server vorgesehen und sollte nicht für Intranetverbindungen eingesetzt werden. 쐍 Intranet Dieser Typ wird für Verbindungen zwischen dieser und anderen Exchange-Organisationen innerhalb der Firewall verwendet. 쐍 Client
Dieser Typ wird für POP3- und IMAP4-Clientverbindungen eingesetzt.
쐍 Partner Dieser Typ ist für TLS-geschützte Verbindungen mit festgelegten Partnerdomänen da (ausführlichere Informationen erhalten Sie im Abschnitt »TLS-Sicherheit« weiter vorn in diesem Kapitel).
804
Als Beispiel möchten wir hier einen neuen Empfangsconnector erstellen, der sich um eingehende Nachrichten von einem Sendmail-System mit Linux kümmert. Es ist nicht unbedingt erforderlich, einen eigenen Connector für diesen Zweck anzulegen, da es auch möglich wäre, die Eigenschaften des Standardconnectors auf dem Hub-Transport-Server wie bereits gezeigt so zu verändern, dass er anonyme Verbindungen annimmt, und diesen Server als Eintrittspunkt in die Exchange-Organisation für das Sendmail-System festzulegen. Ein besonderer Connector gibt uns jedoch eine größere Kontrolle über den Nachrichtenfluss, da wir ihn so einrichten können, dass er nur Nachrichten von Servern aus einem bestimmten IP-Adressbereich annimmt. Der geeignetste Typ für diesen Connector ist Benutzerdefiniert, da er uns die größten Freiheiten bei den Einstellungen einräumt. Nachdem wir Name und Zweck des neuen Connectors angegeben haben, besteht der nächste Schritt darin, die lokalen Netzwerkeinstellungen festzulegen (siehe Abbildung 13.10). Sie bestimmen, welche IP-Adressen und Ports der Connector auf eingehende Nachrichten absucht. Die Standardeinstellungen sorgen dafür, dass alle verfügbaren IP-Adressen beobachtet werden, die dem Server zugewiesen sind, und Port 25 genutzt wird. Das eignet sich auch für unsere Zwecke. Wir können auch den vollqualifizierten Domänennamen (FQDN) angeben, den der Connector anderen Servern bekannt gibt. Der Standardwert ist der FQDN des Hub-Transport-Servers, auf dem sich der Connector befindet, doch wir können diese Angabe z.B. in mail-exchange.contoso.com ändern, wenn wir einen anschaulicheren Namen bevorzugen. Natürlich müssen wir in DNS eine IP-Adresse definieren, um diesen Namen aufzulösen, bevor Remoteserver darüber Kontakt aufnehmen können. Abbildg. 13.10 Festlegen der lokalen Netzwerkeinstellungen für den neuen Connector
Der letzte Schritt besteht darin, Exchange die IP-Adressen der Remoteserver mitzuteilen, von denen der Connector Nachrichten akzeptieren soll. Die Standardeinstellung besagt, dass alle möglichen IPAdressen (von 0.0.0.0 bis 255.255.255.255) erlaubt sind, sodass jeder Server Verbindung aufnehmen kann. Unter den Begriff Remoteserver fallen hier auch POP3- und IMAP4-Clients, die Nachrichten über SMTP übermitteln. Wenn Sie beispielsweise einen Empfangsconnector für eine Reihe solcher Clients erstellen möchten, können Sie hier den IP-Adressbereich eingeben, den diese Clients nutzen,
805
Das Exchange-Transportsystem
Empfangsconnectors
Kapitel 13
Das Exchange-Transportsystem
um sicherzustellen, dass nur diese Clients Verbindung aufnehmen können, um ihre ausgehenden Nachrichten weiterzuleiten. Für einen solchen Empfangsconnector sollten Sie jedoch den Typ Client auswählen, damit Exchange die passenden Berechtigungen festlegt. In diesem Fall kennen wir die IP-Adresse unseres Sendmail-Servers, sodass wir die gültigen Verbindungen auf diese eine Adresse einschränken können (siehe Abbildung 13.11). Danach können wir den Assistenten fertig stellen, sodass er den neuen Empfangsconnector für uns anlegt. Dabei wird der folgende Shellcode verwendet: New-ReceiveConnector -Name 'SMTP traffic from Linux Sendmail server' -Usage 'Custom' -Bindings '0 .0.0.0:25' -RemoteIPRanges '192.165.70.71' -Server 'EXSERVER1' Abbildg. 13.11 Festlegen des IP-Adressbereichs für den neuen Empfangsconnector
Aufgrund des Designprinzips, die Benutzeroberfläche zu vereinfachen und nur die Optionen zu zeigen, die in der überwiegenden Mehrzahl der Fälle notwendig und von größtem Nutzen sind (eine gute Anwendung der 80/20-Regel), stellen die Einstellungen, die Sie beim Erstellen eines neuen Connectors auswählen können, nicht alle Optionen dar, die Sie zur Konfiguration eines Empfangsconnectors haben. Welche Einstellungen es insgesamt gibt, können Sie erkennen, wenn Sie sich die Konfiguration des Connectors mit Get-ReceiveConnector ansehen: Get-ReceiveConnector –Identity 'SMTP traffic from Linux Sendmail server'| Format-List
806
AuthMechanism
: Tls
Banner
:
BinaryMimeEnabled
: True
Bindings
: {0.0.0.0:25}
ChunkingEnabled
: True
DefaultDomain
:
DeliveryStatusNotificationEnabled
: True
EightBitMimeEnabled
: True
DomainSecureEnabled
: False
EnhancedStatusCodesEnabled
: True
LongAddressesEnabled
: False
OrarEnabled
: False
SuppressXAnonymousTls
: False
AdvertiseClientSettings
: False
Fqdn
: EXSERVER1.contoso.com
Comment
:
Enabled
: True
ConnectionTimeout
: 00:10:00
ConnectionInactivityTimeout
: 00:05:00
MessageRateLimit
: unlimited
MessageRateSource
: IPAddress
MaxInboundConnection
: 5000
MaxInboundConnectionPerSource
: 20
Das Exchange-Transportsystem
Empfangsconnectors
MaxInboundConnectionPercentagePerSource: 2 MaxHeaderSize
: 64 KB (65,536 bytes)
MaxHopCount
: 60
MaxLocalHopCount
: 12
MaxLogonFailures
: 3
MaxMessageSize
: 10 MB (10,485,760 bytes)
MaxProtocolErrors
: 5
MaxRecipientsPerMessage
: 200
PermissionGroups
: None
PipeliningEnabled
: True
ProtocolLoggingLevel
: None
RemoteIPRanges
: {192.165.70.71}
RequireEHLODomain
: False
RequireTLS
: False
EnableAuthGSSAPI
: False
ExtendedProtectionPolicy
: None
ExtendedProtectionTlsTerminatedAtProxy : False LiveCredentialEnabled
: False
TlsDomainCapabilities
: {}
Server
: EXSERVER1
SizeEnabled
: Enabled
TarpitInterval
: 00:00:05
807
Kapitel 13
Das Exchange-Transportsystem
MaxAcknowledgementDelay
: 00:00:30
AdminDisplayName
:
ExchangeVersion
: 0.1 (8.0.535.0)
Name
: SMTP traffic from Linux Sendmail server
Identity
: EXSERVER1\SMTP traffic from Linux Sendmail server
In unserem Fall sind die folgenden Änderungen sinnvoll: 1. Wir können dem Connector einige Berechtigungsgruppen hinzufügen. Wenn Sie einen benutzer-
definierten Connector erstellen, weist ihm der Assistent keine Berechtigungsgruppen zu, da er nicht wissen kann, welchem Zweck der Connector dienen soll, und es daher am besten ist, wenn sich der Administrator Gedanken über die Berechtigungsgruppen macht und sie selbst ergänzt. In diesem Fall brauchen wir die Berechtigungsgruppe Anonyme Benutzer, um den Sendmail-Systemen zu erlauben, Nachrichten über den Connector zu übertragen. Die Änderung der Berechtigungsgruppen kann in der Exchange-Verwaltungskonsole und in der Verwaltungsshell erfolgen. 2. Wir können die Authentifizierungsmethode ändern, die der Connector bekannt macht und verwendet. Ein benutzerdefinierter Connector wird so eingerichtet, dass er TLS unterstützt, was für den Remoteserver wahrscheinlich akzeptabel ist. Die Authentifizierungsmethode können Sie nur in der Verwaltungsshell ändern. 3. Wir können das Banner ändern, dass im SMTP-Befehl 220 ausgegeben wird, wenn ein Remoteserver eine Verbindung erstellt. Wenn Sie hier nichts anderes festlegen, gibt Exchange Server 2010 Microsoft ESMTP MAIL Service mit dem aktuellen Datum und der Uhrzeit aus. Manche Administratoren halten das für ein Sicherheitsrisiko, da Hacker daran erkennen können, dass sie eine Verbindung mit Exchange hergestellt haben. Ein Ersatzbanner muss mit 220 beginnen und darf nur 7-Bit-ASCII-Zeichen enthalten. Das Banner können Sie in der Verwaltungsshell ändern. 4. Wir können noch Änderungen an anderen Einstellungen wie der maximalen Nachrichtengröße, der Anzahl der Empfänger im Nachrichtenheader usw. vornehmen. Dies geht nur in der Exchange-Verwaltungsshell. Da sich die meisten dieser Einstellungen nur über die Exchange-Verwaltungsshell bearbeiten lassen, ist es am sinnvollsten, gleich alle Änderungen in der Shell vorzunehmen. Der folgende Befehl passt den neuen Connector an, um die Standardauthentifizierung und anonyme Verbindungen zuzulassen, ein neues Banner anzuzeigen, die maximale Nachrichtengröße auf 3 MB zu verringern und einen Administratorkommentar hinzuzufügen, der angibt, was wir getan haben. Ein solcher Kommentar kann bis zu 256 Zeichen umfassen. Wenn Sie einen hinzufügen, sollten Sie darin am besten Ihren Namen angeben, damit jeder weiß, wer die Änderungen vorgenommen hat. Set-ReceiveConnector -Identity 'SMTP traffic from Linux Sendmail server' –AuthMechanism 'tls, basicauth' -PermissionGroups 'AnonymousUsers' –Banner '220 Hallo World' –MaxMessageSize 3MB –Comment 'TRedmond 20 May 2010: Added anonymous users'
Der Connector ist jetzt in der Lage, E-Mails von einem Remoteserver zu Exchange zu übertragen. Es ist jedoch noch ein letzter Schritt zu erledigen, damit er auch in der Lage ist, Nachrichten an jede Zieldomäne weiterzuleiten, was wir beabsichtigen, wenn Exchange als der Verbindungspunkt für die externe E-Mail-Anbindung ans Internet fungieren soll. Dazu müssen wir den anonymen Verbindungen eine besondere Berechtigung einräumen: Get-ReceiveConnector –Identity 'SMTP traffic from Linux Sendmail server' | Add-ADPermission –User 'NT AUTHORITY\ANONYMOUS LOGON' –ExtendedRights 'ms-Exch-SMTP-Accept-Any-Recipient'
808
Damit sorgen wir auch dafür, dass bei allen Nachrichten, die über den Connector eingehen, eine Antispam-Überprüfung durchgeführt wird oder die P2-Adressen im Header aufgelöst werden (die SMTP-Adresse des Absenders bleibt dabei intakt).
Sendeconnectors Um SMTP-Nachrichten von einem Hub-Transport-Server zum anderen und von der Organisation aus nach draußen zu senden, greift Exchange auf Sendeconnectors zurück. Jeder Hub-Transport-Server verfügt automatisch über einen Sendeconnector, um Nachrichten mit anderen Hub-TransportServern austauschen zu können. Von diesem standardmäßigen Sendeconnector finden Sie jedoch keine Spur, wenn Sie sich die Angaben zu einem Hub-Transport-Server in der Exchange-Verwaltungskonsole anschauen. Mit dem Cmdlet Get-TransportServer können Sie jedoch einen Blick auf die Eigenschaften werfen, die Exchange zur Steuerung dieses Connectors verwendet. Das folgende Listing zeigt eine der Übersichtlichkeit halber gekürzte Ausgabe dieses Befehls. Es gibt eine Menge von Transportkonfigurationseinstellungen, die Sie anpassen können! Get-TransportServer –Identity ExServer1 | Format-List Name
: EXSERVER1
AntispamAgentsEnabled
: False
ConnectivityLogEnabled
: True
ConnectivityLogMaxAge
: 30.00:00:00
ConnectivityLogMaxDirectorySize
: 1000 MB (1,048,576,000 bytes)
ConnectivityLogMaxFileSize
: 10 MB (10,485,760 bytes)
ConnectivityLogPath
: C:\Program Files\Microsoft\ Exchange Server\V14\TransportRoles\ Logs\Connectivity
DelayNotificationTimeout
: 04:00:00
ExternalDNSAdapterEnabled
: True
ExternalDNSProtocolOption
: Any
ExternalDNSServers
: {}
ExternalIPAddress
:
InternalDNSAdapterEnabled
: True
InternalDNSProtocolOption
: Any
InternalDNSServers
: {}
MaxConcurrentMailboxDeliveries
: 20
MaxConcurrentMailboxSubmissions
: 20
MaxConnectionRatePerMinute
: 1200
MaxOutboundConnections
: 1000
MaxPerDomainOutboundConnections
: 20
MessageExpirationTimeout
: 2.00:00:00
MessageRetryInterval
: 00:01:00
809
Das Exchange-Transportsystem
Sendeconnectors
Kapitel 13
Das Exchange-Transportsystem
MessageTrackingLogEnabled
: True
MessageTrackingLogMaxAge
: 30.00:00:00
MessageTrackingLogMaxDirectorySize
: 1000 MB (1,048,576,000 bytes)
MessageTrackingLogMaxFileSize
: 10 MB (10,485,760 bytes)
MessageTrackingLogPath
: C:\Program Files\Microsoft\ Exchange Server\V14\TransportRoles\ Logs\MessageTracking
IrmLogEnabled
: True
IrmLogMaxAge
: 30.00:00:00
IrmLogMaxDirectorySize
: 250 MB (262,144,000 bytes)
IrmLogMaxFileSize
: 10 MB (10,485,760 bytes)
IrmLogPath
: C:\Program Files\Microsoft\ Exchange Server\V14\Logging\IRMLogs
ActiveUserStatisticsLogMaxAge
: 30.00:00:00
ActiveUserStatisticsLogMaxDirectorySize
: 250 MB (262,144,000 bytes)
ActiveUserStatisticsLogMaxFileSize
: 10 MB (10,485,760 bytes)
ActiveUserStatisticsLogPath
: C:\Program Files\Microsoft\ Exchange Server\V14\TransportRoles\ Logs\ActiveUsersStats
ServerStatisticsLogMaxAge
: 30.00:00:00
ServerStatisticsLogMaxDirectorySize
: 250 MB (262,144,000 bytes)
ServerStatisticsLogMaxFileSize
: 10 MB (10,485,760 bytes)
ServerStatisticsLogPath
: C:\Program Files\Microsoft\ Exchange Server\V14\TransportRoles\ Logs\ServerStats
MessageTrackingLogSubjectLoggingEnabled
: True
OutboundConnectionFailureRetryInterval
: 00:10:00
IntraOrgConnectorProtocolLoggingLevel
: None
PickupDirectoryMaxHeaderSize
: 64 KB (65,536 bytes)
PickupDirectoryMaxMessagesPerMinute
: 100
PickupDirectoryMaxRecipientsPerMessage
: 100
PickupDirectoryPath
: C:\Program Files\Microsoft\ Exchange Server\V14\TransportRoles\ Pickup
810
PipelineTracingEnabled
: False
ContentConversionTracingEnabled
: False
PipelineTracingPath
: C:\Program Files\Microsoft\ Exchange Server\V14\TransportRoles\ Logs\PipelineTracing
PipelineTracingSenderAddress
:
PoisonMessageDetectionEnabled
: True
PoisonThreshold
: 2
QueueMaxIdleTime
: 00:03:00
ReceiveProtocolLogMaxAge
: 30.00:00:00
ReceiveProtocolLogMaxDirectorySize
: 250 MB (262,144,000 bytes)
ReceiveProtocolLogMaxFileSize
: 10 MB (10,485,760 bytes)
ReceiveProtocolLogPath
: C:\Program Files\Microsoft\ Exchange Server\V14\TransportRoles\ Logs\ProtocolLog\SmtpReceive
RecipientValidationCacheEnabled
: False
ReplayDirectoryPath
: C:\Program Files\Microsoft\ Exchange Server\V14\TransportRoles\ Replay
RootDropDirectoryPath
:
RoutingTableLogMaxAge
: 7.00:00:00
RoutingTableLogMaxDirectorySize
: 50 MB (52,428,800 bytes)
RoutingTableLogPath
: C:\Program Files\Microsoft\ Exchange Server\V14\TransportRoles\ Logs\Routing
SendProtocolLogMaxAge
: 30.00:00:00
SendProtocolLogMaxDirectorySize
: 250 MB (262,144,000 bytes)
SendProtocolLogMaxFileSize
: 10 MB (10,485,760 bytes)
SendProtocolLogPath
: C:\Program Files\Microsoft\ Exchange Server\V14\TransportRoles\ Logs\ProtocolLog\SmtpSend
TransientFailureRetryCount
: 6
TransientFailureRetryInterval
: 00:05:00
AntispamUpdatesEnabled
: False
InternalTransportCertificateThumbprint
: AB3D032CF097773CC565EE41AE8EE5C2C4D2C231
TransportSyncEnabled
: False
TransportSyncPopEnabled
: False
811
Das Exchange-Transportsystem
Sendeconnectors
Kapitel 13
Das Exchange-Transportsystem
WindowsLiveHotmailTransportSyncEnabled
: False
WindowsLiveContactTransportSyncEnabled
: False
TransportSyncExchangeEnabled
: False
TransportSyncImapEnabled
: False
MaxNumberOfTransportSyncAttempts
: 3
MaxAcceptedTransportSyncJobsPerProcessor
: 64
MaxActiveTransportSyncJobsPerProcessor
: 8
HttpTransportSyncProxyServer
:
HttpProtocolLogEnabled
: False
HttpProtocolLogFilePath
:
HttpProtocolLogMaxAge
: 7.00:00:00
HttpProtocolLogMaxDirectorySize
: 250 MB (262,144,000 bytes)
HttpProtocolLogMaxFileSize
: 10 MB (10,485,760 bytes)
HttpProtocolLogLoggingLevel
: None
TransportSyncLogEnabled
: False
TransportSyncLogFilePath
:
TransportSyncLogLoggingLevel
: None
TransportSyncLogMaxAge
: 30.00:00:00
TransportSyncLogMaxDirectorySize
: 10 GB (10,737,418,240 bytes)
TransportSyncLogMaxFileSize
: 10 MB (10,485,760 bytes)
TransportSyncHubHealthLogEnabled
: False
TransportSyncHubHealthLogFilePath
:
TransportSyncHubHealthLogMaxAge
: 30.00:00:00
TransportSyncHubHealthLogMaxDirectorySize
: 10 GB (10,737,418,240 bytes)
TransportSyncHubHealthLogMaxFileSize
: 10 MB (10,485,760 bytes)
TransportSyncAccountsPoisonDetectionEnabled
: False
TransportSyncAccountsPoisonAccountThreshold
: 2
TransportSyncAccountsPoisonItemThreshold
: 2
TransportSyncAccountsSuccessivePoisonItemThreshold : 3
812
TransportSyncRemoteConnectionTimeout
: 00:01:40
TransportSyncMaxDownloadSizePerItem
: 25 MB (26,214,400 bytes)
TransportSyncMaxDownloadSizePerConnection
: 50 MB (52,428,800 bytes)
TransportSyncMaxDownloadItemsPerConnection
: 1000
DeltaSyncClientCertificateThumbprint
:
UseDowngradedExchangeServerAuth
: False
IntraOrgConnectorSmtpMaxMessagesPerConnection
: 20
In dieser Ausgabe sehen Sie einige interessante neue Optionen, die in Exchange Server 2010 hinzugekommen sind, z.B. die Eigenschaften zur Steuerung der Ausgabe von Server- und Benutzerstatistiken. Diese statistischen Protokolle können Sie analysieren, als Berichte ausgeben lassen oder als Eingabe für Überwachungsprogramme wie Microsoft System Center Operations Manager verwenden, um umfassende Möglichkeiten zur Analyse und Berichterstattung über verschiedene Zeiträume hinweg zu gewinnen. In der Dokumentation von Microsoft System Center Operations Manager erfahren Sie, wie Sie aus den von Exchange erfassten Transportdaten Berichte erstellen können. Zum Festlegen dieser Einstellungen dient logischerweise das Cmdlet Set-TransportServer. Um z.B. das Pickup-Verzeichnis zu ändern, in dem Sie wohlgeformte SMTP-Nachrichtendateien ablegen können, die Exchange senden soll, führen Sie folgenden Befehl aus: Set-TransportServer –Server ExServer1 –PickupDirectoryPath 'C:\Exchange\Pickup'
Wenn das Verzeichnis noch nicht vorhanden ist, wird es von Exchange erstellt. Die Transporteinstellungen gelten jeweils für einen Hub-Transport-Server. Auch hier gilt wieder die Empfehlung, auf allen Hub-Transport-Servern der Organisation dieselbe Konfiguration zu verwenden. Wie der standardmäßige Sendeconnector stützen sich auch benutzerdefinierte Sendeconnectors auf SMTP. Wenn Sie auf einem Hub-Transport-Server einen neuen Sendeconnector erstellen möchten, um Exchange mit dem Internet zu verbinden (oder um Nachrichten an andere SMTP-E-Mail-Systeme zu senden), gehen Sie so vor, als würden Sie einen SMTP-Connector auf einem Bridgeheadserver mit Exchange Servder 2000 oder 2003 anlegen. Allerdings müssen Sie dabei die folgenden Unterschiede bedenken: 쐍 Benutzerdefinierte Sendeconnectors können Sie auf Hub- und auf Edge-Transport-Servern erstellen. Die Connectors auf Hub-Transport-Servern werden in Active Directory registriert und können daher wie jedes andere organisationsweit bekannte Objekt verwaltet werden. Dagegen sind die Connectors von Edge-Transport-Server nur auf dem Computer bekannt, auf dem sie untergebracht sind, und müssen daher auch dort verwaltet werden. 쐍 Anders als Empfangsconnectors, die bei der Installation eines Hub-Transport-Servers automatisch erstellt werden und an den betreffenden Server gebunden bleiben, werden die Sendeconnectors auf Organisationsebene verwaltet. Bevor ein Hub-Transport-Server aber einen Sendeconnector zur Weiterleitung von Nachrichten verwenden kann, müssen Sie den Server als gültige Quelle in den Eigenschaften des Connectors angeben. Abbildung 13.12 zeigt zwei Server, die in der Lage sind, Nachrichten über den Sendeconnector Internet-Relay über Smarthost zu übertragen. Wenn Sie einen Hub-Transport-Server hinzufügen, der sich nicht im selben Active Directory-Standort befindet wie die bereits registrierten Server, wird Ihnen sowohl in der Verwaltungskonsole als auch der Verwaltungsshell eine Warnung angezeigt, um Sie darauf aufmerksam zu machen, dass Sie wahrscheinlich eine nicht optimale Routingsituation erschaffen haben. Da der Transportserver ein deterministisches Routing durchführt und einen Active Directory-Standort zur Weiterleitung von Nachrichten auswählt, kann er keinen Lastenausgleich über zwei Standorte hinweg durchführen, sondern leitet die Nachrichten stets über den ersten Active DirectoryStandort, den er in der Liste der Quellserver für den Connector findet. HINWEIS Wenn Sie wissen, dass der neue Quellserver über eine ausreichende Netzwerkanbindung für das Routing von Nachrichten aus anderen Active Directory-Standorten über den Conenctor verfügt, ist es möglich, ihn zu der Liste hinzuzufügen, aber nicht empfehlenswert. Beachten Sie, dass auch ein Hub-Transport-Server, der nicht als gültige Quelle aufgeführt ist, Nachrichten über den Connector senden kann, wobei er sie jedoch zunächst zu einem der Quellserver weiterleiten muss. 813
Das Exchange-Transportsystem
Sendeconnectors
Kapitel 13
Das Exchange-Transportsystem
Abbildg. 13.12 Die Quellserver für einen Sendeconnector
Erstellen eines Sendeconnectors Hub-Transport-Server mit Exchange Server 2010 enthalten standardmäßige Sendeconnectors für den Transport von Nachrichten innerhalb der Organisation. Diese Connectors brauchen Sie nicht eigens einzurichten. Benutzerdefinierte Sendeconnectors müssen Sie daher nur erstellen, um SMTPNachrichten von der Organisation aus nach draußen zu senden. Da praktisch jede Exchange-Organisation eine solche Verbindung nach draußen benötigt, ist dieser Vorgang eher die Regel als die Ausnahme. Außerdem können Sie zusätzliche Sendeconnectors anlegen, um Nachrichten an bestimmte Domänen zu handhaben. Wenn Sie einen benutzerdefinierten Sendeconnector einrichten, müssen Sie sich über die Eigenschaften dafür klar werden: 쐍 Wie bei einem Empfangsconnector bestimmt auch bei einem Sendeconnector der angestrebte Zweck, welche Berechtigungsgruppen Sie ihm zuweisen müssen. Connectors vom Typ Intern nehmen nur Verbindung mit anderen Exchange Server-Computern auf, während bei Internet anonyme Verbindungen akzeptiert werden. Benutzerdefiniert bedeutet, dass Sie die Berechtigungen manuell festlegen müssen. 쐍 Durch die Angabe des Adressraums können Sie eine gewisse Kontrolle darüber ausüben, welche Nachrichten über den Connector gehen. Wenn Sie den Adressraum »*« verwenden (Adressraumdefinitionen wie »*.*« oder »*@*« sind in Exchange nicht möglich), kann der Connector jegliche Nachrichten an sämtliche Domänen handhaben. Wollen Sie einen Connector einrichten, der nur Nachrichten an eine bestimmte Domäne weiterleitet, müssen Sie den entsprechenden Adressraum für ihn festlegen. Nehmen wir an, dass Sie Verbindungen zu einer bestimmten Domäne in systemx.fabrikam.com benötigen und sicherstellen möchten, dass die entsprechenden Nachrichten durch einen bestimmten Connector gehen. Das können Sie dadurch erreichen, dass sie einen Connector für die genaue Adresse der gewünschten Domäne erstellen (z.B. finance.systemx.fabrikam.com). Danach hat Exchange zwei mögliche Routen für Nachrichten an finance.systemx.fabrikam.com: den standardmäßigen SMTP-Connectort und den eigens für diese Domäne erstellten. 814
Exchange leitet Nachrichten immer über den Connector mit der genauesten Adressraumangabe, selbst wenn das zu höheren Routingkosten führt. Alle Nachrichten an fabrikam.com gehen daher durch den SMTP-Standardconnector, diejenigen an finance.systemx.fabrikam.com jedoch über den neu erstellten. Das ist jedoch nichts Neues, denn so funktionierte das Routing schon in Exchange Server 5.0. 쐍 Überlegen Sie, ob Sie MX-Einträge (Mail Exchange) in DNS verwenden, um E-Mails weiterzuleiten, oder ob Sie sie über Smarthosts senden. Ein Smarthost ist ein Server, der für andere Server SMTP-Datenverkehr weiterleiten kann. Gewöhnlich wird ein solcher Dienst von Ihrem Internetprovider oder von einem Server angeboten, der als zentrale Schaltstelle für das Routing in Ihrem Unternehmen fungiert. 쐍 Machen Sie sich klar, welche Hub-Transport-Server mit dem Connector verknüpft sein sollen. An dieser Stelle können Sie eine Zuordnung zu einem Edge-Abonnement erstellen, damit der Connector über einen Hub-Transport-Server bekannt gemacht und dem Edge-Transport-Server angekündigt wird. Um einen neuen Sendeconnector zu erstellen, wechseln Sie in der Exchange-Verwaltungskonsole unter Organisationskonfiguration zum Knoten Hub-Transport und wählen Neuer Sendeconnector. Als Erstes müssen Sie den Namen und den Zweck des Connectors festlegen (siehe Abbildung 13.13). Ein guter Name gibt die Verwendung des Connectors an und lässt für Administratoren, die sich die Messagingkonfiguration später ansehen, keine Fragen offen. Abbildg. 13.13 Der erste Schritt beim Erstellen eines neuen Sendeconnectors
Der Zweck des Connectors bestimmt, welche Berechtigungsgruppen Exchange auf das neue Objekt anwendet. Es stehen folgende Möglichkeiten zur Auswahl: 쐍 Benutzerdefiniert Wird für Verbindungen mit Nicht-Exchange-Systemen auf SMTP-Basis verwendet und bietet die vollständige Kontrolle über die Konfiguration.
815
Das Exchange-Transportsystem
Sendeconnectors
Kapitel 13
Das Exchange-Transportsystem
쐍 Internet Wird für Verbindungen zu SMTP-Systemen im Internet verwendet. Das bezieht auch Smarthosts mit ein, die Nachrichten im Namen der Organisation weiterleiten. 쐍 Intern Wird für Verbindungen verwendet, über die Nachrichten an andere Hub-TransportServer innerhalb der Organisation übertragen werden. Da diese Aufgabe schon die standardmäßigen Sendeconnectors erfüllen, müssen Sie einen solchen Connector nur erstellen, wenn Sie den Nachrichtenfluss auf besondere Weise steuern möchten. 쐍 Partner Wird für Verbindungen zu Partnerorganisationen über mit TLS geschützte Verknüpfungen verwendet. In diesem Beispiel möchten wir eine Verbindung zu einem Smarthost herstellen, der Nachrichten im Namen der Organisation weiterleitet. Das ist eine in vielen Unternehmen häufige Konstellation, in denen eine Reihe verschiedener Messagingsyteme verwendet werden. Die Relayserver laufen gewöhnlich unter Unix oder Linux und sind als Hochleistungsswitches für Nachrichten ausgelegt. Das Gegenstück von Exchange dazu ist ein Edge-Transport-Server. Der nächste Schritt besteht darin, die SMTP-Domänen oder Adressräume zu definieren, die der Connector handhaben kann (siehe Abbildung 13.14). Ein Smartrelay kümmert sich gewöhnlich um alles außer den Adressräumen, die für andere Connectors definiert sind. Denken Sie daran, dass Exchange zur Weiterleitung von Nachrichten immer den Connector mit dem spezifischsten Adressraum auswählt. Ein Smartrelay ist also häufig die letzte Wahl, wenn kein anderer Connector verfügbar ist, der mit der Nachricht umgehen kann. Das deuten wir dadurch an, dass wir den Adressraum als »*« definieren. Wenn Sie einen neuen Sendeconenctor in der Verwaltungskonsole erstellen, können Sie nur SMTP-Adressräume festlegen. Verwenden Sie dagegen das Cmdlet New-SendConnector, sind Sie auch in der Lage, andere Adressräume anzugeben, z.B. für X.400. In der Shell ist es auch möglich, eine Zeichenkette für eine gültige Routingadresse anzugeben, die das für die endgültige Zustellung verantwortliche Messaging erkennen kann. Insidertipp: Der Kostenwert für einen Adressraum
Jedem Adressraum ist ein Wert für die Verbindungskosten zugewiesen, wobei 1 der bestmögliche Wert ist und die Skala bis 100 reicht. Anhand dieser Kosten kann Exchange zwischen zwei Routen entscheiden. Nehmen wir an, in einer Organisation stehen zwei Smarthostrelays zur Verfügung, einer für den Standort Amerika und einer vor den Standort Europa. Die europäischen Server haben eine natürliche Neigung zu dem Smarthostrelay in ihrem eigenen Standort und ignorieren den in Amerika definierten selbst dann, wenn die Adresskosten gleich sind. Das ist logisch, weil die Regel gilt, dass ein Connector im lokalen Standort bevorzugt wird, wann immer das möglich ist, und weil die zusätzlichen Standortverknüpfungskosten für das Routing nach Amerika den Connector teurer machen als den, der im europäischen Standort verfügbar ist. Das Kontrollkästchen Sendeconnector mit Bereich bestimmt, ob der Connector für das Routing durch jeden Hub-Transport-Server in der Organisation zur Verfügung steht. Im Normalfall lassen Sie es deaktiviert. Wenn Sie es jedoch aktivieren, schränkt Exchange den Connector so ein, dass ihn nur die Hub-Transport-Server verwenden können, die sich im selben Standort befinden wie der Quellserver. Führen Sie die Exchange-Verwaltungskonsole auf einem Hub-Transport-Server aus, macht Exchange diesen automatisch zum Quellserver. Arbeiten Sie mit der Konsole dagegen auf einem anderen Server ohne die Hub-Transport-Rolle, nimmt Exchange als Quellserver den ersten Hub-Transport-Server im Standort. Wie bereits erwähnt (siehe Abbildung 13.12) können Sie die Liste der Quellserver eines Connectors in der Verwaltungskonsole und mit dem Cmdlet Set-SendConnector ändern.
816
Sendeconnectors
Das Exchange-Transportsystem
Abbildg. 13.14 Hinzufügen eines Adressraums zu einem neuen Sendeconnector
Als Nächstes müssen wir Exchange mitteilen, wo der Smarthost zu finden ist. Am einfachsten ist es, den FQDN oder die IP-Adresse dieses Servers anzugeben (siehe Abbildung 13.15). Es handelt sich hierbei um eine mehrwertige Eigenschaft, sodass wir einen Satz von FQDNs oder IP-Adressen angeben können, um Exchange eine Auswahl an verfügbaren Servern anzubieten. Alternativ können Sie Exchange anweisen, die in DNS definierten MX-Einträge zu verwenden, um die Relayserver zu finden. Abbildg. 13.15 Hinzufügen der Informationen über den Smarthost
817
Kapitel 13
Das Exchange-Transportsystem
Wenn Sie SMTP-Nachrichten an externe Ziele über einen Smarthost leiten möchten, müssen Sie in Exchange angeben, welchen Authentifizierungsmechanismus Sie für Verbindungen mit diesem Smarthost einsetzen möchten. Es kann sein, dass Sie einen SMTP-Server verwenden, der als offenes Relay für die allgemeine Benutzung im Unternehmen eingerichtet ist. In diesem Fall wird gar keine Authentifizierung durchgeführt oder die Angabe von Benutzername und Kennwort für die Standardauthentifizierung verlangt. Handelt es sich bei dem Smarthost um einen Exchange Server-Computer, können Sie die Exchange Server-Authentifizierung nutzen. Es ist auch möglich, IPSec für die verschlüsselte Kommunikation zwischen den Servern einzusetzen. Im nächsten Schritt des Assistenten zum Erstellen eines neuen Sendeconnectors geben Sie daher an, ob und in welcher Form eine Authentifizierung durchgeführt wird (siehe Abbildung 13.16). Abbildg. 13.16 Authentifizierungseinstellungen für einen Smarthost
Der letzte Schritt besteht darin, die Quellserver für den Sendeconnector anzugeben. Hier müssen Sie mindestens einen Hub-Transport-Server hinzufügen. Das entspricht der Auswahl eines Bridgeheadservers für einen Routinggruppenconnector in Exchange Server 2003. Wenn Sie den neuen Connector auf einem Hub-Transport-Server anlegen, schließt Exchange dessen Namen ein. Der Befehl zum Erstellen des neuen Sendeconnectors sieht wie folgt aus: New-SendConnector -Name 'Internet relay via smart host' -Usage 'Internet' -AddressSpaces 'SMTP:*;1' -IsScopedConnector $False -DNSRoutingEnabled $False -SmartHosts 'smtp-relay.contoso.com' -SmartHostAuthMechanism 'None' -UseExternalDNSServersEnabled $False -SourceTransportServers 'EXSERVER1'
Wie so oft können Sie auch in diesem Fall eine umfassendere Anpassung der Einstellungen für einen Sendeconnector in der Exchange-Verwaltungsshell durchführen. Als Erstes sehen wir uns mit dem Cmdlet Get-SendConnector an, wie die Einstellungen des neuen Connectors aussehen: Get-SendConnector –Identity 'Internet relay via smart host' | Format-List 818
AddressSpaces
: {SMTP:*;1}
AuthenticationCredential
:
Comment
:
ConnectedDomains
: {}
Das Exchange-Transportsystem
Sendeconnectors
ConnectionInactivityTimeOut : 00:10:00 DNSRoutingEnabled
: False
DomainSecureEnabled
: False
Enabled
: True
ErrorPolicies
: Default
ForceHELO
: False
Fqdn
:
HomeMTA
: Microsoft MTA
HomeMtaServerId
: EXSERVER1
Identity
: Internet relay via smart host
IgnoreSTARTTLS
: False
IsScopedConnector
: False
IsSmtpConnector
: True
LinkedReceiveConnector
:
MaxMessageSize
: 10 MB (10,485,760 bytes)
Name
: Internet relay via smart host
Port
: 25
ProtocolLoggingLevel
: None
RequireOorg
: False
RequireTLS
: False
SmartHostAuthMechanism
: None
SmartHosts
: {smtp-relay.contoso.com}
SmartHostsString
: smtp-relay.contoso.com
SmtpMaxMessagesPerConnection : 20 SourceIPAddress
: 0.0.0.0
SourceRoutingGroup
: Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers
: {EXSERVER1}
TlsAuthLevel
:
TlsDomain
:
UseExternalDNSServersEnabled : False
819
Kapitel 13
Das Exchange-Transportsystem
Um eine Einstellung zu ändern, verwenden wir das Cmdlet Set-SendConnector. Nehmen wir an, dass die die maximale Größe der Nachrichten, die über diesen Connector übertragen werden, auf 5 MB verringern und zwei weiteren Hub-Transport-Servern die Nutzung dieses Connectors erlauben wollen. Dazu verwenden wir folgenden Befehl: Set-SendConnector –Identity 'Internet relay via smart host' –MaxMessageSize 5MB –SourceTransportServers 'ExServer1', 'ExServer2', 'ExServer3' –Comment 'Admin: Limited size to 5MB 12/31/2010'
Auswählen eines Sendeconnectors Innerhalb einer Organisation kann es mehrere Sendeconnectors geben, und bei der Entscheidung, wie eine Nachricht weitergeleitet werden soll, muss Exchange sie alle berücksichtigen. Dabei wird folgender Algorithmus verwendet: 1. Stelle eine Liste aller verfügbaren Sendeconnectors auf. 2. Verwirf alle deaktivieren Connectors. 3. Verwirf alle Connectors, deren maximale Nachrichtengröße unterhalb der Größe der aktuellen
Nachricht liegt. 4. Wähle die Connectors aus, die (was den Bereich angeht) für den Hub-Transport-Server verfügbar
sind und deren Adressraum die Empfängerdomäne enthält (der Adressraum * schließt alle Domänen ein). 5. Wähle den Connector aus, dessen Adressraum am genauesten mit dem Ziel übereinstimmt. Gibt es beispielsweise einen Connector mit dem Adressraum * und einen zweiten mit dem Adressraum fabrikam.com, so sollten alle Nachrichten an die Domäne fabrikam.com über den zweiten Connector übertragen werden. 6. Gibt es mehr als einen verfügbaren Connector, so wähle den am besten geeigneten anhand der folgenden Gesichtspunkte aus: a
Geringste Routingkosten auf der Grundlage der gesamten Standortverknüpfungskosten. Ein Connector im lokalen Standort wird stets gegenüber einem Connector in einem Remotestandort bevorzugt.
b Der Hub-Transport-Server, auf dem der Connector untergebracht ist. Ein Connector auf dem Server, der die Routingentscheidung fällen muss, wird stets gegenüber einem Connector auf einem anderen Hub-Transport-Server desselben Standorts bevorzugt. c
Alphanumerische Reihenfolge. Es wird der Connector verwendet, der in der alphanumerischen Sortierung als Erster vorkommt.
Es ist jedoch zu hoffen, dass Ihre Messagingumgebung nicht so strukturiert ist, dass Exchange jemals auf die alphanumerische Sortierung zurückgreifen muss, um eine Auswahl aus den Connectors auf den Servern des lokalen Standorts zu treffen. Insidertipp: Der Einfluss des Bereichs
Sendeconnectors mit Bereich (deren Eigenschaft IsScopedConnector auf $True gesetzt ist) sind für die Hub-Transport-Server außerhalb ihres angestammten Standorts nicht sichtbar. Mit anderen Worten, die Hub-Transport-Server in anderen Standorten können einen solchen Connector nicht in ihre Routingtabellen aufnehmen und beziehen ihn daher auch nicht in ihre Berechnung der kostengünstigsten Route zur Zustellung an externe Empfänger ein.
820
Insidertipp: Der Einfluss des Bereichs
Die Routingberechnungen erfolgen auf jedem Hub-Transport-Server, den eine Nachricht passiert, sodass sie stets dem optimalen Pfad folgt. Gelangt eine Nachricht in einen Standort mit einem Connector, der einen Pfad mit geringeren Kosten anbietet, berechnet der Hub-Transport-Server dieses Standorts die Route neu und leitet die Nachricht um. In die Berechnung des optimalen Pfades wird jeder Connector einbezogen, der in dem Standort zur Verfügung steht, auch ein Connector mit Bereich, den die Hub-Transport-Server in dem Standort, aus dem die Nachricht ursprünglich stammte, gar nicht sehen konnten. Das kann bedeuten, dass eine Nachricht über einen Connector übertragen wird, der dafür gar nicht vorgesehen war. Nehmen wir beispielsweise an, von einem Standort ohne Connector wird eine Nachricht zu einem Empfänger im Internet gesendet. Um das Internet zu erreichen, muss sie zunächst einen Hub-Standort durchlaufen. Gehen wir des Weiteren davon aus, dass es in diesem Hub-Standort zwei Connectors gibt. Der eine weist keine Bereichseinschärnkung auf und hat den SMTP-Adressraum *. Er ist in der ganzen Organisation bekannt und wird von dem Hub-Transport-Server im Ursprungsstandort der Nachricht als Zielconnector ausgewählt. Der zweite Connector jedoch ist mit einem Bereich versehen und weist einen Adressraum auf, der viel genauer zu dem Empfänger passt. Wenn der HubTransport-Server im Hub-Standort die Empfängeradresse untersucht, kommt er zu dem Schluss, dass der Connector mit Bereich – der ja in der Routingtabelle des Hub-Standorts aufgeführt wird – die bessere Wahl ist. Daher stellt er die Nachricht in die Warteschlange für diesen Connector mit Bereich. Für Exchange ist diese Vorgehensweise völlig logisch, aber ein Administrator, der sich die Warteschlangen ansieht, kann verwirrt sein, wenn es weniger Datenverkehr über den Allzweck-Sendeconnector gibt als erwartet und dafür mehr über den Connector mit Bereich. Wenn beide Connectors dieselbe Internetverbindung nutzen, ist das eigentlich kein Problem, doch wenn die Pfade eine unterschiedliche Konfiguration aufweisen (z.B. eine andere maximale Nachrichtengröße) und Sie Nachrichten mithilfe von Connectors mit Bereich über einen bestimmten Weg schicken müssen, können Schwierigkeiten auftreten. Da Exchange den Routingpfad in jedem Standort, den eine Nachricht durchläuft, neu berechnet, besteht die einzige Möglichkeit, um solchen unerwünschten Datenverkehr über Connectors mit Bereich zu vermeiden, darin, solche Connectors in eigenen Standorten unterzubringen, in denen es keine anderen Sendeconnectors gibt. Haben Sie dagegen Sendeconnectors in Standorten, in denen sehr viel Datenverkehr an andere Ziele hin und her geht, besteht eine große Wahrscheinlichkeit dafür, dass Nachrichten, die diesen Standort passieren, umgeleitet werden.
Verknüpfte Connectors Empfangsconnectors können so mit Sendeconnectors verknüpft werden, dass alle Nachrichten, die über sie eingehen, unmittelbar über den Sendeconnector übertragen werden. Der Sinn solcher verknüpfter Connectors besteht darin, eine Route bereitzustellen, auf der Nachrichten zur Verarbeitung durch Dritte weitergeleitet werden können, bevor sie wieder zurück in die Organisation gelangen. Damit können Sie z.B. Nachrichten aus dem Internet zur Antispam- und Antivirusprüfung an ein Unternehmen senden, das sich auf solche Dienstleistungen spezialisiert hat. Dafür müssen allerdings eine Reihe von Voraussetzungen erfüllt sein:
821
Das Exchange-Transportsystem
Verknüpfte Connectors
Kapitel 13
Das Exchange-Transportsystem
쐍 Mit einem Sendeconnector kann nur ein Empfangsconnector verknüpft werden. Der Sendeconnector wird so eingerichtet, dass er Nachrichten an die SMTP-Domäne des Drittanbieters sendet, die diese E-Mails weiterverarbeitet. Dazu wird die Drittanbieterdomäne zu einem Smarthost für den Sendeconnector gemacht. 쐍 Der Empfangsconnector, den Sie verwenden möchten, muss schon vorhanden sein, bevor Sie ihn mit dem Sendeconnector verknüpfen können. Mit anderen Worten, Sie müssen erst beide Connectors erstellen, bevor Sie die Verknüpfung einrichten. 쐍 Um die Nachrichten entgegenzunehmen, die von dem Drittanbieter zurückkommen, wird ein komplementärer Empfangsconnector erstellt. Er ist nicht mit dem Sendeconnector verknüpft, da sich sonst eine Endlosschleife ergeben würde. Seine Funktion besteht darin, die bereinigten Nachrichten wieder zurück in die Organisation zu bringen, wo sie von den Hub-Transport-Servern zu den Zielpostfächern weitergeleitet werden. 쐍 Für die ausgehenden Nachrichten von Benutzern in der Orgnaisation benötigen Sie einen zweiten Sendeconnector. Er kann jedoch auch den Drittanbieter-Smarthost zur Bereinigung der ausgehenden Nachrichten nutzen. Verknüpfte Connectors können Sie nicht in der Exchange-Verwaltungskonsole erstellen. Stattdessen müssen Sie den im Folgenden gezeigten Shellbefehl verwenden. In diesem Beispiel legen wir einen Sendeconnector an, der mit dem vorhandenen Empfangsconnector Internet email auf dem HubTransport-Server ExHT-Dublin verknüpft wird. Durch die Verknüpfung dieser Connectors werden alle E-Mails, die durch diesen Empfangsconnector eingehen, an den Smarthost clean-me.mailstreams-contoso.com gesendet. New-SendConnector –Name 'Internet Mail Cleansing' –LinkedReceiveConnector 'ExHTDublin\Internet Email' –AddressSpaces $Null –SmartHosts 'clean-me.mail-streamscontoso.com' –SmartHostAuthMechanism ExternalAuthoritative –DNSRoutingEnabled $False – MaxMessageSize 20MB
Insidertipp: Keine Routineaufgabe – Planung und sorgfältige Tests sind nötig
Verknüpfte Connectors werden einmalig nach sorgfältiger Planung und ausführlichen Tests erstellt, um den E-Mail-Fluss von und zu Drittanbietern sicherzustellen. Dies ist keine Aufgabe, die Sie regelmäßig durchführen werden.
Einschränken E-Mail-Server, die als Gateways für große Unternehmen fungieren, können sehr leicht durch ein starkes Aufkommen eingehender Nachrichten überschwemmt werden. In einem solchen Fall können die Server einerseits versuchen, so gut wie möglich mit diesem Nachrichtenvolumen fertig zu werden und nach und nach die Rückstände abzuarbeiten, die sich zwangsläufig ansammeln. Andererseits aber kann die Software auch die Arbeitsbedingungen beobachten, eine solche Überlastung erkennen und Maßnahmen ergreifen, um wieder zu einer ordnungsgemäßen Verarbeitung zurückzuführen. Der Mechanismus, den Exchange Server 2010 einsetzt, um mit Spitzen beim eingehenden Nachrichtenverkehr umzugehen, heißt »Einschränkung«. Dieser Begriff wird in Exchange Server 2010 jedoch auch für die Art der Kontrolle verwendet, die ein Clientzugriffsserver mithilfe von Einschränkungsrichtlinien für Postfächer auf die Clientverbindungen ausüben kann. Bei dieser Art von Einschränkung wird die Fähigkeit des Clients eingeschränkt, 822
ohne guten Grund Systemressourcen in großem Stil zu verbrauchen. Dies ist offensichtlich etwas anderes als die Art der Einschränkung, die angewandt wird, um einen reibungslosen Nachrichtenfluss sicherzustellen. Einschränkungsparameter können Sie auf folgende Dinge anwenden: 쐍 Hub- und Edge-Transport-Server Dies erledigen Sie mit dem Cmdlet Set-TransportServer (wobei sich einige Parameter auch in der Verwaltungskonsole festlegen lassen). Normalerweise müssen Sie eine solche Einschränkung nur auf Server anwenden, die mit externem Datenverkehr zu tun haben. Es kann jedoch auch sein, dass eine Einschränkung für die Hub-Transport-Server in einem stark belasteten Hub-Standort erforderlich wird. 쐍 Empfangsconnectors Hierzu verwenden Sie das Cmdlet Set-ReceiveConnector. Auch hier gilt wieder, dass Sie Ihre Aufmerksamkeit nur den Empfangsconnectors schenken müssen, die eingehenden Datenverkehr von außerhalb der Organisation handhaben. 쐍 Sendeconnectors Hierzu verwenden Sie das Cmdlet Set-SendConnector. Die von Exchange festgelegten Standardeinstellungen reichen für die meisten Zwecke aus und müssen nur dann geändert werden, wenn eine Überwachung zeigt, dass Ihre Hub- und Edge-Transport-Server Schwierigkeiten haben, mit dem eingehenden Datenverkehr fertig zu werden. Wenn Sie beispielsweise feststellen, dass sich in Spitzenzeiten lange Warteschlangen bilden, die auch nach dem Abflauen der Spitzen nicht wieder abgebaut werden, liegt eine Situation vor, die sicherlich der Untersuchung bedarf. Dies kann einfach an einem Mangel an Verarbeitungskapazität liegen oder durch andere Bedingungen hervorgerufen werden, die Sie durch Anpassen der Einschränkungsparameter anpassen können. Tabelle 13.3 gibt einen Überblick über die verschiedenen Parameter, die Sie zur Steuerung dieser Einschränkungen zur Verfügung haben. Tabelle 13.3
Parameter für Transporteinschränkungen Cmdlet
Parameter
Auswirkung
Set-TransportServer
MaxConcurrentMailboxDeliveries
Legt die maximale Anzahl von Threads für die gleichzeitige Zustellung zu Postfächern über den Speichertreiber in der gesamten Organisation fest. Der Standardwert beträgt 20.
Set-TransportServer
MaxConcurrentMailboxSubmissions
Legt die maximale Anzahl der Zustellungsthreads für einen Server fest, der Nachrichten von Datenbanken in der gesamten Organisation über den Speichertreiber annehmen kann.
Set-TransportServer
MaxConnectionRatePerMinute
Legt die maximale Rate fest, mit der der Huboder Edge-Transport-Server neue eingehende Verbindungen für Empfangsconnectors erstellen kann. Der Standardwert beträgt 1200 Verbindungen pro Minute.
Set-TransportServer (und Verwaltungskonsole)
MaxOutboundConnections
Legt die maximale Anzahl von gleichzeitigen ausgehenden Verbindungen fest, die ein Huboder Edge-Transport-Server über Sendeconnectors öffnen kann. Der Standardwert beträgt 1000. Sie können diesen Wert auf Unlimited setzen, damit der Server so viele Verbindungen herstellen kann, wie die Ressourcen zulassen.
Set-TransportServer (und Verwaltungskonsole)
MaxPerDomainOutboundConnections
Legt die maximale Anzahl der Verbindungen zu einer einzelnen Domäne fest, die über Sendeconnectors geöffnet werden können. Der Standardwert beträgt 20. Sie können diesen Wert auf Unlimited setzen.
823
Das Exchange-Transportsystem
Einschränken
Kapitel 13 Tabelle 13.3
824
Das Exchange-Transportsystem
Parameter für Transporteinschränkungen (Fortsetzung) Cmdlet
Parameter
Auswirkung
Set-TransportServer
PickupDirectoryMaxMessagesPerMinute
Legt die maximale Anzahl der Nachrichten fest, die der Transportdienst pro Minute aus dem Pickup- und dem Wiedergabeverzeichnis zu laden versucht. Der Standardwert beträgt 100 Nachrichten pro Minute und Verzeichnis. Exchange ruft diese Verezeichnisse alle fünf Sekunden ab, sodass der Wert, den Sie hier angeben, durch 12 teilbar sein muss, damit Exchange die Anzahl der Nachrichten berechnen kann, die bei einem einzelnen Abruf verarbeitet werden.
Set-ReceiveConnector
ConnectionInactivityTimeOut
Legt fest, wie lange ein Empfangsconnector eine SMTP-Verbindung zu einem anderen Server im Leerlauf höchstens geöffnet hält. Nach Ablauf dieses Zeitraums wird die Verbindung geschlossen.
Set-ReceiveConnector
ConnectionTimeOut
Legt fest, wie lange eine SMTP-Verbindung höchstens geöffnet sein darf, selbst wenn der andere Server weiterhin Daten überträgt. Der Standardwert beträgt zehn Minuten für Hubund fünf Minuten für Edge-Transport-Server. Logischerweise muss dieser Wert höher sein als der von -ConnectionInactivityTimeOut.
Set-ReceiveConnector
MaxInboundConnection
Legt die maximale Anzahl gleichzeitiger eingehender Verbindungen fest, die über einen Empfangsconnector möglich sind. Der Standardwert beträgt 5000.
Set-ReceiveConnector
MaxInboundConnectionPercentagePerSource
Legt die maximale Anzahl eingehender Verbindungen von einer einzigen Quelle fest, die ein Empfangsconnector erlaubt. Der Wert wird als Prozentsatz der verfügbaren restlichen Verbindungen ausgedrückt und beträgt standardmäßig 2%.
Set-ReceiveConnector
MaxInboundConnectionPerSource
Legt die maximale Anzahl eingehender Verbindungen von einem einzigen Server fest, die ein Empfangsconnector erlaubt. Der Standardwert beträgt 100.
Set-ReceiveConnector
MaxProtocolErrors
Legt die maximale Anzahl von SMTP-Fehlern fest, die ein Empfangsconnector toleriert, bevor er die Verbindung zum Server trennt. Der Standardwert beträgt 5.
Set-ReceiveConnector
TarpitInterval
Legt den Verzögerungsparameter fest, den Exchange verwendet, wenn der Verdacht besteht, dass der andere Server einen Directory-Harvest-Angriff versucht. Der Standardwert beträgt fünf Sekunden. Weitere Informationen finden Sie in Kapitel 14, »Nachrichtenhygiene«.
Set-SendConnector
ConnectionInactivityTimeOut
Legt fest, wie lange ein Sendeconnector eine SMTP-Verbindung zu einem anderen Server höchstens offen hält. Der Standardwert beträgt zehn Minuten.
Rückstau Das Transportmodul von Exchange ist zur Verarbeitung auch extrem großer Mengen an Nachrichten ausgelegt, aber es können Umstände auftreten, unter einen ein Server nicht mehr die physische Kapazität hat, um ein- oder ausgehende Nachrichten zu verarbeiten. So kann es beispielsweise sein, dass ein Hub-Transport-Server von anderen Quellen so stark belastet wird, dass ein Großteil seines verfügbaren Arbeitsspeichers verbraucht wird, oder dass der Festplattenplatz einiger Laufwerke zur Neige geht. Unter solchen Umständen ermöglicht die Rückstaufunktion dem Transportdienst, weiterhin normal zu arbeiten und die in den Warteschlangen befindlichen Nachrichten zu verarbeiten, während er zeitweilig eingehende Verbindungen ablehnt, sodass keine neuen Nachrichten in die Warteschlangen gelangen. In einer solchen Situation müssen die sendenden SMTP-Server die Nachrichten in ihren eigenen Warteschlangen behalten, bis die Situation behoben ist, die für die Belastung des Exchange Server-Computers gesagt hat. Wenn die Belastung des Servers sinkt und dadurch Arbeitsspeicher frei wird oder wenn Sie durch das Löschen von Dateien wieder für mehr Festplattenplatz sorgen, beginnt Exchange wieder eingehende Verbindungen anzunehmen und neue Nachrichten zu verarbeiten. Tabelle 13.4 zeigt, wie Hub-Transport-Server auf mittlere und starke Rückstaubedingungen reagieren. Wie Sie sehen, bleibt der grundlegende Nachrichtenfluss unter mittlerer Last erhalten, da die Hub-Transport-Server noch Verbindungen zueinander aufnehmen können, um sich E-Mails gegenseitig E-Mails zuzusenden, und auch Nachrichten von Postfachservern entgegennehmen. Eingehender Datenverkehr von SMTP-Servern wird jedoch nicht mehr akzeptiert. Wenn die Belastung steigt, nehmen die Hub-Transport-Server schließlich gar keine Verbindungen mehr an, sondern warten damit, bis sich die Situation wieder gebessert hat. Tabelle 13.4
Die Auswirkungen von Rückstaubedingungen auf Hub-Transport-Server Ressourcennutzung
Verbindungen von anderen Hub-TransportServern
Verbindungen von anderen SMTP-Servern
Speichertreiberverbindungen von Postfachservern
Übertragungen über das Pickup- und das Wiedergabeverzeichnis
Interner Nachrichten fluss
Mittel
Zugelassen
Abgelehnt
Zugelassen
Abgelehnt
Funktioniert
Hoch
Abgelehnt
Abgelehnt
Abgelehnt
Abgelehnt
Kein Nachrichtenfluss
Woran können Sie erkennen, dass eine Rückstaubedingung vorherrscht? Das können Sie im Anwendungsprotokoll ablesen, z.B. anhand des Ereignisses 15002 des Ressourcen-Managers im ExchangeTransportsystem. Dieses Ereignis teilt Ihnen mit, welche Ressource das Transportsystem dazu zwingt, einen Rückstau anzuwenden. Beispielsweise können Sie hier eine Meldung wie die folgende sehen: Warteschlangendatenbank und Datenträgerspeicherplatz ("F:\Exchange\TransportRoles\data\ queue\Mail.Que") = 81% [Hoch][Normal = 70% Mittelhoch = 72% Hoch = 74%]
In diesem Fall liegt das Problem vor, dass die Festplatte mit der Warteschlangendatenbank zu 81% voll ist und damit den Grenzwert von 74% für die hohe Nutzung überschritten hat. Es sind zwar immer noch 19% auf der Festplatte übrig, doch es besteht die Möglichkeit, dass andere Anwendungen diesen Platz verbrauchen oder dass die Warteschlangendatenbank weiter wächst und ihn ausfüllt,
825
Das Exchange-Transportsystem
Rückstau
Kapitel 13
Das Exchange-Transportsystem
wenn Exchange weiterhin Nachrichten entgegennimmt. Angesichts der heute üblichen Größen von Festplatten mag das unwahrscheinlich erscheinen, doch wenn Sie für ein reibungsloses Funktionieren Ihres Messagingsystems sorgen wollen, sollten Sie lieber übervorsichtig sein. Die Lösung des Problems besteht darin, einige der Dateien von der Festplatte zu entfernen, um die Nutzung wieder auf unter 74% zu drücken. Ein weiteres Zeichen für Rückstaubedingungen kann darin bestehen, dass die Mailübertragungskomponente auf Postfachservern Ereignis 1009 meldet. Dieses Ereignis wird angezeigt, wenn Exchange nicht in der Lage ist, Nachrichten an einen Hub-Transport-Server im lokalen Active Directory-Standort zu übertragen. Das kann bedeuten, dass der Hub-Transport-Server ausgefallen oder der Transportdienst beendet ist oder dass Exchange unter einer Rückstaubedingung leidet, die das Transportsystem daran hindert, weitere Nachrichten von den Postfachservern anzunehmen. Wenn sich die Postfach- und die Hub-Transport-Rolle auf demselben Computer befinden, werden die anfallenden Nachrichten im Informationsspeicher in die Warteschlange gestellt, bis sich die Situation entspannt hat, es sei denn, im selben Standort steht noch ein weiterer Hub-Transport-Server zur Verfügung. Ein weiteres Indiz dafür, dass sich ein Hub-Transport-Server aufgrund einer Rückstaubedingung selbst drosselt, zeigt sich darin, dass die Absender Unzustellbarkeitsberichte erhalten, wenn Sie Nachrichten an den belasteten Server zu senden versuchen. In diesen Unzustellbarkeitsberichten ist der Fehlercode 4.3.1 unzureichende Systemressourcen angegeben. Die Nachrichten werden in die Warteschlange zur erneuten Zustellung eingereiht. Insidertipp: Optimierte Einstellungen aufgrund von Praxiserfahrungen
Microsoft hat einige der Rückstaueinstellungen in SP1 aufgrund von Erfahrungen in Produktionsumgebungen optimiert (so wurde beispielsweise der erforderliche verfügbare Festplattenplatz von 4 GB auf 500 MB reduziert). Sie können davon ausgehen, dass es in diesem Bereich noch zu weiteren Optimierungen kommt, wenn Microsoft und die Administratoren immer besser mit Rückstausituationen umzugehen lernen. HINWEIS Ist auf einem Computer sowohl die Postfach- als auch die Hub-Transport-Rolle installiert, verwendet der Postfachserver bevorzugt den Hub-Transport-Server auf dem eigenen Rechner und greift nur dann auf andere Hub-Transport-Server zurück, wenn der lokale Server keine Nachrichten mehr annehmen kann. In diesem Fall werden die anderen Hub-TransportServer im Umlaufverfahren verendet, bis der lokale Server wieder Nachrichten akzeptiert.
Transportwarteschlangen Die Nachrichten, die das Transportsystem gerade verarbeitet, werden in Warteschlangen im Arbeitsspeicher festgehalten. Damit sie zuverlässig auf die Festplatte übertragen werden können, werden sie in die ESE-Datenbank (Extensible Storage Engine) mail.que geschrieben. Wenn der Transportdienst beendet wird, führt er in dieser Datenbank einen Commit der Warteschlangen aus dem Arbeitsspeicher durch, damit sie korrekt gesichert erden. Wie andere ESE-Datenbanken verfügt auch mail.que über einen Satz von Transaktions- und reservierten Protokollen, um Nachrichten wiedereinzuspielen, wenn ein Problem wie ein Serverabsturz den Commit der Nachrichten aus dem Arbeitsspeicher heraus verhindern sollte. Das aktuelle Transaktionsprotokoll heißt trn.log. Sobald 5 MB an Nachrichtentransaktionen darin erfast sind, erstellt Exchange eine neue Protokollgeneration. Im Gegensatz zu
826
den 1 MB großen Transaktionsprotokollen für Postfachdatenbanken umfassen die für die Nachrichtenwarteschlange jeweils 5 MB. Um den Speicherplatz zu beschränken, den diese Warteschlange einnimmt, ist die Umlaufprotokollierung eingeschaltet. Abbildung 13.17 zeigt die Dateien, die die Datenbank der Nachrichtenwarteschlange ausmachen. Abbildg. 13.17 Die Datenbankdateien der Nachrichtenwarteschlange
Der Speicherort der Datenbankdateien für die Nachrichtenwarteschlange wird in der Konfigurationsdatei EdgeTransport.exe.config festgelegt. Sie können sie bei Bedarf an jeden geeigneten Speicherort verlagern. Tabelle 13.5 führt weitere wichtige Parameter für die Datenbank der Nachrichtenwarteschlange auf, die Sie in EdgeTransport.exe.config finden. Insidertipp: Verschieben der Warteschlangendatenbank vom Standardspeicherort
Es ist sinnvoll, die Datenbank für die Nachrichtenwarteschlange auf Hub-Transport-Servern, die ein sehr großes Nachrichtenaufkommen verarbeiten, von ihrem Standardspeicherort auf dem Laufwerk mit den Exchange-Binärdateien zu verlagern. Microsoft bietet das Skript Move-TransportDatabase.ps1 an, mit dem Sie die Warteschlangendatenbank verschieben können. Mit dem folgenden Befehl verlagern Sie die Datenbank und ihre Protokolldateien z.B. auf E:\Exchange\MailQueue. Am neuen Speicherort müssen mindestens 2 GB Platz frei sein, damit das Skript funktionieren kann. C:> .\Move-TransportDatabase -QueueDatabasePath E:\Exchange\MailQueue QueueDatabaseLoggingPath E:\Exchange\Ma ilQueue
827
Das Exchange-Transportsystem
Transportwarteschlangen
Kapitel 13 Tabelle 13.5
Das Exchange-Transportsystem
Parameter für zur Steuerung der Datenbank für die Nachrichtenwarteschlange Parameter
Bedeutung
QueueDatabasePath
Legt den Speicherort der Warteschlangendatenbank fest. Sie müssen das Verzeichnis erstellen, den Transportdienst beenden, die Datenbankdateien kopieren und den Transportservice neu starten.
QueueDatabaseLoggingPath
Legt den Speicherort der Transaktionsprotokolldateien für die Warteschlangendatenbank fest. Dies muss nicht derselbe Speicherort wie für die Datenbank selbst sein.
QueueDatabaseLoggingBufferSize
Legt fest, wie viel Arbeitsspeicher (in Byte) zum Zwischenspeichern von Datensätzen verwendet wird, bevor sie mit einem Commit ins Transaktionsprotokoll geschrieben werden. Der Standardwert beträgt 5.242.880 Byte (5 MB).
QueueDatabaseLoggingFileSize
Legt die maximale Größe des Transaktionsprotokolls fest. Der Standardwert beträgt 5.242.880 Byte (5 MB).
QueueDatabaseOnlineDefragEnabled
Legt fest, ob Exchange eine Onlinedefragmentierung zur Wartung der internen Datenbankstrukturen durchführt. Der Standardwert lautet $True.
QueueDatabaseOnlineDefragSchedule
Legt fest, zu welchem Zeitpunkt Exchange mit der Onlinewartung beginnt. Der Standardwert lautet 1:00:00 (1.00 Uhr nachts).
QueueDatabaseOnlineDefragTimeToRun
Legt fest, wie lange Exchange die Onlinewartung durchführen darf. Der Standardwert beträgt 3:00:00 (drei Stunden).
Wie gelangen Nachrichten in die Übermittlungswarteschlange? Nachrichten können auf vier verschiedene Weisen in den Exchange-Transportdienst eintreten: 쐍 Speichertreiber Nachrichten, die von Outlook Web App (OWA) und Outlook erstellt werden, gelangen zunächst in den Postausgangsordner. Der Mailübertragungsdienst überwacht diese Ordner, und sobald dort eine Nachricht auftaucht, informiert er den Speichertreiber, der die Nachricht an den Server übertragen soll. Sobald eine Nachricht von Exchange zur Verarbeitung akzeptiert und in die Übertragungswarteschlange gestellt wurde, wird sie auf dem Client vom Ordner Postausgang in Gesendete Objekte verschoben. 쐍 Empfangsconnectors Nachrichten von anderen SMTP-Servern sowie von POP3- und IMAP4Clients, die E-Mails per SMTP senden, gehen über einen Empfangsconnector ein. Das ist die einzige Methode, über die Nachrichten gewöhnlich auf einen Edge-Transport-Server gelangen. 쐍 Pickup- und Wiedergabeverzeichnis Fremde E-Mail-Systeme und Anwendungen können Nachrichten im Pickup-Verzeichnis ablegen, wo Exchange sie zur Verarbeitung abholt. Nachrichten, die aufgrund eines Fehlers wiedereingespielt werden müssen, kommen aus dem Wiedergabeverzeichnis. 쐍 Systemgenerierte Nachrichten Als Ergebnis bestimmter Aktionen erstellt Exchange eigene Nachrichten, z.B. Unzustellbarkeitsberichte und Zustellbestätigungen. Auch die Verarbeitung durch Agents wie Transportregeln kann dazu führen, dass Nachrichten erstellt werden. Beispielsweise kann eine Regel dafür sorgen, dass eine Nachricht kopiert und als Bcc an einen neuen Empfänger gesandt wird. Journalberichte sind ein weiteres Beispiel für systemgenerierte Nachrichten.
828
Ganz unabhängig davon, wie die Nachrichten in das System gelangt sind, so landen sie doch schließlich alle in der Übermittlungswarteschlange. Sie wird beim Start des Transportdienstes jeweils neu erstellt. Wenn diese Warteschlange ständig wächst und die Anzahl der wartenden Nachrichten nicht wieder sinkt, ist das kein gutes Zeichen, nicht einmal in Zeiten einer allgemein starken Serverbeanspruchung. Dies kann bedeuten, dass das Kategorisierungsmodul aus irgendeinem Grund belastet ist. Es ist wichtig, diesen Grund herauszufinden.
Verschieben von Nachrichten in Zustellungswarteschlangen Das Kategorisierungsmodul verarbeitet die Nachrichten in der Übertragungswarteschlange nach dem FIFO-Prinzip. Dabei verbleibt die Nachricht in dieser Warteschlange, bis das Kategorisierungsmodul die gesamte Verarbeitung abgeschlossen und eine Entscheidung über die beste Route getroffen hat. Auf einem Hub-Transport-Server erfolgen dabei drei Verarbeitungsschritte: Die vollständige Liste der Empfänger wird durch Überprüfen der Adressen und Erweitern der Verteilergruppen ermittelt, der optimale Routingpfad wird berechnet, und es werden alle Konvertierungen durchgeführt, die erforderlich sind, bevor die Nachricht an einen Benutzer oder eine Domäne gesendet werden kann. Im Vergleich dazu nimmt das Kategorisierungsmodul auf einem Edge-Transport-Server an, dass die komplette Liste der Empfänger schon in der Nachricht enthalten und der Inhalt für die Zustellung geeignet ist, sodass es die Nachricht unmittelbar in die Zustellwarteschlange stellt. Die meisten Nachrichten durchlaufen das Kategorisierungsmodul sehr schnell, doch die Erweiterung der Empfängerliste kann bei sehr umfangreichen dynamischen Verteilergruppen dazu führen, dass das Modul einige Minuten zur Verarbeitung einer Nachricht braucht. Nachdem das Kategorisierungsmodul alle Routinginformationen für eine Nachricht ermittelt hat, kann es Regeln und andere Richtlinien anwenden, um zu bestimmen, in welche Warteschlange es die Nachricht einreihen soll. Danach verschiebt es die Nachricht von der Übertragungswarteschlange entweder in die lokale Zustellwarteschlange (MapiDelivery) oder eine Remotezustellwarteschlange. Die lokalen Zustellwarteschlangen werden vom Speichertreiben für die Auslieferung im Posteingang der Empfänger im lokalen Standort betrieben. Exchange Server 2010 unterhält für jede Postfachdatenbank eine eigene lokale Zustellwarteschlange. Bei Exchange Server 2007 wurde je eine solche Warteschlange für jeden Server verwendet. Lokale Zustellwarteschlangen gibt es nur auf Hub-TransportServern, da Edge-Transport-Server keine direkte Zustellung zu Postfachdatenbanken durchführen. Die Remotezustellwarteschlangen werden von den SMTP-Sendeconnectors oder anderen Zustellconnectors betrieben, wobei jeder Connector eine eigene Warteschlange hat. Es gibt Warteschlangen für die internen SMTP-Connectors zwischen den Hub-Transport-Servern und andere Warteschlangen für die Connectors, die für besondere Zwecke erstellt wurden, z.B. für die Weiterleitung von Nachrichten an eine Partnerdomäne oder einen Smarthost.
Anzeigen von Warteschlangen Einer der Vorteile von Exchange ist die Geschwindigkeit, mit der Nachrichtenwarteschlangen verarbeitet werden. Zwischen dem Eintritt einer Nachricht in die Warteschlange und dem Zeitpunkt, an dem sie sie wieder verlässt, liegt nur ein Lidschlag, und das Vorhandensein von mehr als einigen wenigen Nachrichten in einer Warteschlange ist schon ein Indiz dafür, dass der Server stark belastet oder
829
Das Exchange-Transportsystem
Transportwarteschlangen
Kapitel 13
Das Exchange-Transportsystem
das Netzwerk mit dem derzeitigen Volumen des Datenverkehrs überfordert ist. Mit der Warteschlangenanzeige und dem mit dem Cmdlet Get-Queue können Sie sich die jeweils aktuellen Inhalte der Warteschlangen ansehen. Das folgende Beispiel zeigt die Ausgabe von Get-Queue auf einem HubTransport-Server. Wenn Sie dieses Cmdlet ausführen, ohne einen Servernamen zu übergeben, zeigt Exchange Informationen über die Warteschlangen auf dem aktuellen Server an, vorausgesetzt, es ist ein Hub-Transport-Server (wenn nicht, erhalten Sie eine Fehlermeldung). Get-Queue –Server ExServer1 –SortOrder: -MessageCount Identity
DeliveryType Status MessageCount NextHopDomain
--------
------------ ------- ------------ -------------
ExServer1\2495
MapiDelivery Active 2
vip data
ExServer1\2481
MapiDelivery Active 1
DB2
ExServer1\2503
MapiDelivery Ready
0
DB3
ExServer1\2516
SmtpRelay... Ready
0
hub version 14
ExServer1\2527
SmartHost... Ready
0
smtp1.contoso.com
ExServer1\Submission
Undefined
Ready
0
Submission
ExServer1\Shadow\2285
ShadowRed... Ready
1
ExServer2
In diesem Beispiel haben wir die Ausgabe nach der Anzahl der Nachrichten in der Warteschlange sortiert. Das Minuszeichen vor dem Parameter -MessageCount bedeutet, dass wir eine Anordnung nach absteigender Reihenfolge verlangen. Bei einem Pluszeichen wird in aufsteigender Reihenfolge sortiert. Um die Warteschlangen nach dem Status zu ordnen, verwenden wir folgenden Befehl: Get-Queue –Server ExServer1 –SortOrder: +Status
Es gibt auch den Parameter -Filter, um bestimmte Warteschlangen aus der gesamten Menge auszuwählen. Mit dem folgenden Befehl zeigen wir gezielt die Warteschlangen an, die mehr als 20 Nachrichten enthalten: Get-Queue –Server ExServer1 –Filter {MessageCount –gt 20} –SortOrder: -MessageCount
Insidertipp: Warteschlangenstatus
Der Status Ready zeigt an, dass die Warteschlange Nachrichten zur weiteren Verarbeitung aufnehmen kann. Wird der Status Connecting angezeigt, nimmt Exchange gerade Verbindung mit einem Remoteserver auf, um die Nachrichten aus der Warteschlange zu übergeben. Der Status Active bedeutet, dass Exchange Nachrichten aus der Warteschlange überträgt. Die Ausgabe sieht im Großen und Ganzen so aus wie in Exchange Server 2007, es gibt allerdings eine Reihe wichtiger Unterschiede. Exchange Server 2007 erstellt für Nachrichten, die im nächsten Hop ein Empfängerpostfach auf einem anderen Exchange Server-Computer erreichen sollen, PostfachZustellungswarteschlangen (Zustelltyp MapiDelivery), wohingegen in Exchange Server 2010 die Zustellwarteschlangen für die Datenbanken angelegt werden, zu denen die Postfächer gehören. Daher sind in der Ausgabe Warteschlangen für vip data, -DB2, DB3 usw., wobei es sich um Datenbanken auf den anderen Server im selben Active Directory-Standort handelt. Diese Änderung ist eine logische Folge der Einführung von Datenbankverfügbarkeitsgruppen. Es ist schließlich nicht mehr möglich, eine Nachricht in eine Warteschlange für einen bestimmten Server zu stellen und zu erwar-
830
ten, dass sie an ein bestimmtes Postfach ausgeliefert wird, da die Datenbank für dieses Postfach mittlerweile aufgrund eines Failovers auf einen anderen Server umgeschaltet sein könnte. Wie in Exchange Server 2007 sind Warteschlangen flüchtige Objekte: Der Transportdienst erstellt sie, wann immer sie gebraucht werden, und entfernt sie wieder, wenn keine Nachrichten eingestellt werden müssen. Wenn Sie sich einen Server während einer Phase starker Belastung ansehen, können Sie Warteschlangen für alle Datenbanken im lokalen Standort erkennen (vorausgesetzt, dass Nachrichten an Empfänger in allen Datenbanken geschickt wurden) sowie Warteschlangen für die Hub-Transport-Server in allen anderen Active Directory-Standorten der Organisation. Schauen Sie sich denselben Server dagegen zu einem Zeitpunkt geringer Nachfrage an, kann es sein, dass alle Warteschlangen für einzelne Datenbanken verschwunden sind und nur die Übertragungswarteschlange für das Kategorisierungsmodul übrig geblieben ist. Im Gegensatz zu den Warteschlangen für die lokale und die Remotezustellung von Nachrichten sind die Übertragungswarteschlangen dauerhaft vorhanden, wobei es jeweils eine auf jedem Hub-Transport-Server gibt. Exchange bereinigt die Warteschlangen auch, wenn die Gültigkeitsdauer von Nachrichten abläuft, was standardmäßig nach zwei Tagen der Fall ist. Dahinter steht der Gedanke, dass eine zwei Tage alte Nachricht für den Empfänger nicht mehr sehr nützlich ist, weshalb es besser ist, sie an den Absender zurückzuschicken, damit er versuchen kann, den beabsichtigten Empfänger auf andere Weise zu erreichen. Nicht-erreichbar-Warteschlange und die Warteschlange für nicht verarbeitete Nachrichten
Unter Umständen sehen Sie auch eine Nicht-erreichbar-Warteschlange oder eine Warteschlange für nicht verarbeitete Nachrichten. Es gibt immer nur höchstens eine Nicht-erreichbar-Warteschlange für Nachrichten, für die der Transportdienst aus irgendeinem Grund keine Route bestimmen kann. Wenn Sie beispielsweise einen X.400-Connector in Ihrer Organisation hatten und ihn dann entfernen, ist Exchange nicht mehr in der Lage, Nachrichten an X.400-Empfänger zu leiten. Exchange versucht, Nachrichten wieder aus der Nicht-erreichbar-Warteschlange zu entfernen, und prüft dazu regelmäßig, ob nicht doch eine Route bestimmt werden kann. Wenn ja, wird die Nachricht über diese Route abgefertigt. Läuft eine Nachricht ab, bevor eine Route berechnet werden kann, schickt Exchange einen Unzustellbarkeitsbericht an den Absender. Die Warteschlange für nicht verarbeitete Nachrichten ist ein sicherer Ort für Nachrichten, die Exchange für gefährlich hält. Gründe dafür können sein, dass die Nachricht nicht wohlgeformte SMTP-Befehle oder HTML-Code enthält, der im Transportsystem Probleme bereiten könnte. Wenn Exchange eine Nachricht nicht ganz koscher vorkommt, wird sie in die Warteschlange für nicht verarbeitete Nachrichten gestellt, damit ein Administrator sie sich ansehen kann. Hält der Administrator sie für sicher, kann er ihre Weiterleitung wiederaufnehmen und Exchange damit zwingen, die Nachricht zurück in die Übermittlungswarteschlange zu stellen, sodass sie das Kategorisierungsmodul ganz normal durchläuft. Um die Eindeutigkeit der Namen von Warteschlangen zu gewährleisten, setzt das Transportsystem sie aus dem Namen des Hub-Transport-Servers und einer laufenden Nummer zusammen. Diese Nummer wird bei einem Neustart des Transportdienstes zurückgesetzt. Unter anderem können wir in der Ausgabe folgende Warteschlangen erkennen: 쐍 Die SmtpRelay-Warteschlange (der vollständige Name dieses Typs lautet SmtpRelayWithinADSite) hält Nachrichten fest, die an einen anderen SMTP-Server im selben Active Directory-Standort weitergeleitet werden müssen. Geht die Nachricht an einen Edge-Transport-Server, wird eine Warteschlange vom Zustellungstyp SmtpRelayWithinADSiteToEdge verwendet.
831
Das Exchange-Transportsystem
Transportwarteschlangen
Kapitel 13
Das Exchange-Transportsystem
쐍 Die für smtp1.contoso.com aufgeführte SmartHost-Warteschlange (der vollständige Typ lautet SmartHostConnectorDelivery) ist eine Warteschlange für die Remotezustellung mit Nachrichten, die zur weiteren Auslieferung an einen SMTP-Smarthost geleitet werden sollen. Gewöhnlich befinden sich in dieser Warteschlange Nachrichten für externe SMTP-Domänen, die nicht innerhalb der Exchange-Organisation verarbeitet werden können. 쐍 Die ShadowRedundancy-Warteschlange wird vom Transportpapierkorb verwendet, um Nachrichten festzuhalten, bis der Transportdienst sicher ist, dass sie erfolgreich dem nächsten Hop zugestellt wurden. In der Beispielausgabe können wir erkennen, dass eine Nachricht noch auf die Bestätigung der erfolgreichen Verarbeitung durch ExServer2 wartet. Weitere Informationen darüber, wie die Schattenredundanz funktioniert, erhalten Sie weiter hinten in diesem Kapitel im Abschnitt »Schattenredundanz«.
Problemwarteschlangen Es kann vorkommen, dass sich Nachrichten in Warteschlangen sammeln und dass ihre Anzahl auch dann nicht geringer wird, wenn der Server nur noch leicht belastet ist und auch keine offensichtlichen Probleme vorliegen, die eine Übertragung der Nachrichten verhindern. Wenn das der Fall ist, sollten Sie das Problem genauer untersuchen, indem Sie sich die Nachrichten in der betroffenen Warteschlange ansehen. Mit dem folgenden Befehl können Sie sämtliche Angaben über den aktuellen Zustand einer Warteschlange abrufen: Get-Queue –id ExServer1\109 | Format-List Identity
: ExServer1\109
DeliveryType
: SmartHostConnectorDelivery
NextHopDomain
: smtp121.contoso.com
NextHopConnector
: f9018e1b-3beb-42eb-8f6b-bf10f09e1157
Status
: Retry
MessageCount
: 15
LastError
: 451 4.4.0 DNS query failed. The error was: SMTPSEND.DNS.NonExistentDomain; nonexistent domain
LastRetryTime
: 3/16/2010 9:19:18 AM
NextRetryTime
: 3/16/2010 9:20:18 AM
ObjectState
: Unchanged
Wir können sofort erkennen, dass der Grund für das Anwachsen der Warteschlange in der Meldung von DNS liegt, dass der Name des Smarthosts für den Sendeconnector nicht aufgelöst werden konnte. Die Fehlermeldung NonExistentDomain ist ein Sammelbecken für alle Probleme mit der DNSNamensauflösung. Die Domäne existiert zwar, aber der Name des Servers ist falsch oder kann zurzeit aus irgendeinem Grund nicht aufgelöst werden. Die Lösung besteht darin, den Namen des Smarthosts zu überprüfen und dafür zu sorgen, dass er von DNS aufgelöst werden kann. Ein weiteres Problem, dem Sie häufig begegnen können, besteht darin, dass ein Remoteserver nicht auf die Anforderung reagiert, Verbindung mit Exchange aufzunehmen. In diesem Fall sehen Sie folgende Fehlermeldung:
832
421 4.2.1 Unable to connect. Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.
Die Hub-Transport-Server innerhalb einer Site kommunizieren über SMTP. Wenn der Transportdienst auf einem Hub-Transport-Server nicht läuft, kann Exchange auf die MAPI-Zustellung zurückgreifen, sodass der Speichertreiber auf einem Server eine Nachricht für ein Postfach aufgreifen kann. Wenn Sie sich die Warteschlange ansehen, können Sie folgende Informationen erkennen: Identity
: ExServer1\145
DeliveryType
: SmtpRelayWithinAdSite
NextHopDomain
: hub version 14
NextHopConnector
: 61027a30-e9a9-4c2d-acb5-c1efc96d5d8b
Status
: Ready
MessageCount
: 0
LastError
: 451 4.4.0 Primary target IP address responded with: "421 4.2.1 Unable to connect." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to allalternate hosts. Queue will be resubmitted for routing for MAPI delivery
LastRetryTime
: 3/16/2010 9:28:21 AM
NextRetryTime
:
IsValid
: True
Die hier gemeldete Eigenschaft NextHopDomain nimmt entweder den Wert hub transport 14 (Übertragung innerhalb eines Standorts), den Namen eines SMTP-Servers, z.B. eines Smarthosts, oder den Namen des Active Directory-Standorts an, zu dem Exchange die Nachricht zu übertragen versucht. Ist Letzteres der Fall und gibt es im Zielstandort nur einen einzigen Hub-Transport-Server, besteht eine hohe Wahrscheinlichkeit dafür, dass das Problem an diesem Server liegt. Laufen in einem Standort jedoch mehrere Hub-Transport-Server, könnte jeder von ihnen die Ursache des Problems sein. Hub-Transport-Server lehnen Verbindungen ab, wenn ihre Ressourcen zur Neige gehen (siehe den Abschnitt »Rückstau« weiter vorn in diesem Kapitel), weshalb Sie auch diese Möglichkeit überprüfen müssen. Liegt das Problem an einem Postfachserver, müssen Sie nachsehen, ob auf ihm der Informationsspeicher ausgeführt wird. Möglicherweise ist die Datenbank mit dem Empfängerpostfach nicht bereitgestellt oder aus irgendeinem Grund nicht betriebsbereit. Mit dem Cmdlet Get-Message können Sie sich Informationen über die Nachrichten ansehen, die in Warteschlangen »festhängen«. Betrachten Sie dazu das folgende Beispiel: Get-Message Identity
FromAddress
Status
Queue
Subject
----------
-----------------
--------
---------
----------
ExServer1\109\1322
Tony.Redmond@con...
Ready
ExServer1\109
Really important
ExServer1\109\1324
Tony.Redmond@con...
Ready
ExServer1\109
Budget 2010 material
833
Das Exchange-Transportsystem
Transportwarteschlangen
Kapitel 13
Das Exchange-Transportsystem
Befinden sich in der Warteschlange viele Nachrichten, ist es bequemer, die Ausgabe in eine Textdatei zu leiten und sich die Daten dort anzusehen. Falls nötig, können Sie sich auch die Angaben zu einer einzelnen Nachrichten ansehen, indem Sie ihre Kennung angeben. Im folgenden Beispiel haben wir die zweite Nachricht aus der Liste ausgewählt. Get-Message –Identity 'ExServer1\109\1324'–IncludeRecipientInfo | Format-List Identity
: ExServer1\109\1324
Subject
: Budget 2010 Material
InternetMessageId :
: [email protected]
Status
: Ready
Size
: 3.363 KB (3,444 bytes)
MessageSourceName : FromLocal SourceIP
: 255.255.255.255
SCL
: -1
DateReceived
: 3/16/2010 10:44:44 AM
ExpirationTime
: 3/18/2010 10:44:44 AM
LastError
:
RetryCount
: 0
Queue
: ExServer1\109
Recipients
: {[email protected]}
ComponentLatency : MessageLatency
: 00:07:02.2280076
IsValid
: True
ObjectState
: Unchanged
Mit dem Cmdlet Suspend-Message können Sie unter Angabe der Kennung auch eine einzelne Nachricht anhalten. Exchange behält die Nachricht dann in der Warteschlange, verarbeitet sie aber nicht, bevor ein Administrator sie wieder freigibt. Suspend-Message –Identity 'ExServer1\109\1324'
Um die Nachricht wieder freizugeben, verwenden Sie Resume-Message: Resume-Message –Identity 'ExServer1\109\1324'
Mit Remove-Message löschen Sie eine Nachricht aus einer Warteschlange. In dem folgenden Beispiel sorgen wir dabei auch dafür, dass der Absender einen Unzustellbarkeitsbericht erhält, um zu erfahren, was geschehen ist. Wenn Sie den Parameter -WithNDR auf $False setzen, löscht Exchange die Nachricht, ohne einen Unzustellbarkeitsbericht zu senden. Remove-Message –Identity 'ExServer1\109\1324'–WithNDR $True
Sie müssen eine Nachricht nicht erst anhalten, bevor Sie sie löschen können.
834
Es kann sein, dass ein anderer Administrator eine ganze Warteschlange und die Verarbeitung aller darin enthaltenen Nachrichten angehalten hat. In diesem Fall hat die Warteschlange den Status Suspended (Angehalten). Wenn Sie so etwas sehen, sollten Sie zunächst herausfinden, warum sie angehalten wurde und ob Sie sie wiederaufnehmen können. Die Wiederaufnahme einer angehaltenen Warteschlange erfolgt in der Warteschlangenanzeige oder mit dem Cmdlet Resume-Queue: Resume-Queue –Identity 'ExServer1\821'
Wenn das zugrundeliegende Problem behoben ist, bereinigt Exchange die Warteschlangen sofort automatisch. Wenn die Warteschlange dann einige Minuten später nicht mehr gebraucht wird, wird sie entfernt.
Die Exchange-Warteschlangenanzeige Um sich den Inhalt der Transportwarteschlangen anzusehen, können Sie auch die Warteschlangenanzeige verwenden (siehe Abbildung 13.18). Es handelt sich dabei um ein MMC-Snap-In (Microsoft Management Console), das zur Toolbox der Exchange-Verwaltungskonsole gehört. Der Hauptvorteil der Warteschlangenanzeige besteht darin, dass sie eine einfach zu verwendende Schnittstelle bietet, um sich anzusehen, was in den Warteschlangen vor sich geht, und um die Eigenschaften der Nachrichten zu untersuchen, die sich gerade in einer Warteschlange befinden. Der Transportdienst kann selbst umfangreiche Nachrichten sehr schnell verarbeiten, weshalb die Warteschlangenanzeige alle fünf Sekunden aktualisiert wird, um Ihnen ein aktuelles Bild der Vorgänge auf dem Hub-TransportServer zu liefern. Abbildg. 13.18 Überwachung von Transportwarteschlangen in der Wartesclangenanzeige
835
Das Exchange-Transportsystem
Transportwarteschlangen
Kapitel 13
Das Exchange-Transportsystem
Insidertipp: Wo werden die Nachrichten verarbeitet?
Sofern im Standort ein anderer Hub-Transport-Server zur Verfügung steht, werden Nachrichten in einer Datenbankverfügbarkeitsgruppe stets an ihn übermittelt, anstatt sie lokal auf dem eigenen Server zu verarbeiten, wie es außerhalb solcher Gruppen üblich ist. Es haben schon einige Administratoren den Fehler begangen, sich die Warteschlangen auf dem lokalen Server anzusehen. Natürlich sahen sie dort keinerlei Aktivitäten, da die Nachrichten, die sie beobachten wollten, anderswo verarbeitet wurden. Alle Aktionen, die wir mit den hier vorgestellten Cmdlets für Warteschlangen durchgeführt haben, lassen sich auch in der Warteschlangenanzeige erledigen. Die meisten erfahrenen Administratoren bevorzugen es, sich Warteschlangen in der Exchange-Verwaltungsshell anzusehen, da die Shell nicht den Zusatzaufwand für die grafische Benutzeroberfläche leisten muss und daher schneller auf Abfragen reagiert. Allerdings ist es schön, wenn man die Wahl hat.
Übermitteln von Nachrichten über das Pickup-Verzeichnis Das Pickup-Verzeichnis wird gewöhnlich verwendet, um von Anwendungen generierte Nachrichten in den Transportdienst einzuschleusen. Nehmen wir beispielsweise an, ein Überwachungs-Agent erkennt einen Fehler in einer Anwendungsfehler und erstellt daraufhin die folgende Nachricht: To: [email protected] om From: [email protected] Date: 1 March 2011 01:15AM Subject: Warning - BlackBox Application failure MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The BlackBox application has experienced a failure on server BBOX188. Please check!
Application Problem Details BBOX Version 2.010 The application is not responding to prompts
Standardmäßig befindet sich das Pickup-Verzeichnis in \TransportRoles\Pickup. Sie können diesen Speicherort jedoch mit Set-TransportServer wie folgt ändern: Set-TransportServer –Identity ExServer2 –PickupDirectoryPath 'C:\Exchange\PickupDirectory'
836
Grundsätzlich geschieht in einem solchen Fall Folgendes: Eine Anwendung erstellt eine Textdatei mit der Erweiterung EML, die dem grundlegenden SMTP-Nachrichtenformat genügt, und platziert sie im Pickup-Verzeichnis. Alle fünf Sekunden (dieser Zeitraum lässt sich nicht ändern) sieht Exchange in diesem Verzeichnis nach und versucht alle Dateien mit der Endung EML zu verarbeiten, die sich dort befinden. Insidertipp: Verarbeiten einer großen Nachrichtenmenge
Dateien mit anderen Endungen als EML werden ignoriert. Exchange kann pro Minute bis zu 100 Dateien aus dem Pickup-Verzeichnis verarbeiten. Sind mehr vorhanden, verbleibt der Rest bis zur nächsten Runde in dem Verzeichnis. Wenn Sie ein größeres Aufkommen von anwendungsgenerierten Nachrichten haben, können Sie Exchange mit Set-TransportServer dazu veranlassen, mehr Dateien auf einmal zu verarbeiten: Set-TransportServer -PickupDirectoryMaxMessagesPerMinute 250
Eine solche Datei wird zunächst mit der Erweiterung TMP versehen und dann von Exchange untersucht, um festzustellen, ob sie die erforderliche Formatierung aufweist, um sich in eine Nachricht konvertieren zu lassen. Wenn alles richtig ist, wird die Nachricht in die Übertragungswarteschlange gestellt und die TMP-Datei aus dem Pickup-Verzeichnis entfernt. Nicht richtig formatierten Dateien gibt Exchange die Endung BAD und belässt sie im Verzeichnis, wo hoffentlich ein Administrator darauf aufmerksam wird und sich darum kümmert. Wenn beispielsweise im Feld From ein Postfachalias statt der vollständigen SMTP-Adresse des Postfachs verwendet wird, lehnt Exchange die Datei ab. Wenn der Transportdienst oder Server aufgrund eines Fehlers ausfallen, während Nachrichten aus dem Pickup-Verzeichnis verarbeitet werden, verbleibt die TMP-Datei im Verzeichnis, sodass Exchange sie bei der nächsten Suche nach neuen Nachrichten erneut verarbeiten kann. Dabei besteht eine gewisse Wahrscheinlichkeit dafür, dass Nachrichten doppelt ausgeliefert werden. Dies geschieht, ohne dass die Administratoren darüber Kenntnis erhalten, aber das ist höchstwahrscheinlich auch kein Problem, da die Benutzer schon in der Lage sein werden, Duplikate, die in ihren Postfächern ankommen, selbstständig zu erkennen und zu löschen. Eine Nachrichtendatei besteht aus den Headerfeldern und dem Text. Für sie gelten die folgenden Anforderungen: 쐍 Es werden nur Textdateien mit der Endung EML verarbeitet. 쐍 In den Feldern To, Cc oder Bcc muss sich mindestens eine E-Mail-Adresse befinden. Alle Adressen müssen im SMTP-Format vorliegen. 쐍 Enweder im Feld From oder im Feld Sender darf nur eine einzige E-Mail-Adresse stehen. Ist in beiden nur eine Adresse vorhanden, verwendet Exchange die aus dem Feld From als Urheber der Nachricht. Es ist möglich, in From mehrere Adressen anzugeben (die jeweils durch Kommata getrennt sind), doch in diesem Fall darf im Feld Sender nur eine einzige Adresse stehen, die Exchange dann als Urheber annimmt. Outlook zeigt eine solche Nachricht so an, als ob die in Sender angegebene Adresse die Nachricht im Namen der ersten Adresse der From-Liste geschickt hätte. In allen Fällen muss die E-Mail-Adresse für den Urheber der Nachricht gültig sein, da sie ansonsten von einem Antispam-Agent auf dem Weg zum Ziel verworfen werden könnte. 쐍 Bei reinen Textnachrichten muss sich zwischen den Headerfeldern und dem Nachrichtentext eine Leerzeile befinden. Dies ist bei Nachrichten im MIME-Format nicht erforderlich. 쐍 Die maximale Headergröße beträgt 64 KB, und es können nicht mehr als 100 Empfänger angegeben werden.
837
Das Exchange-Transportsystem
Transportwarteschlangen
Kapitel 13
Das Exchange-Transportsystem
Falls die Felder Received und Resent vorhanden sind, werden sie von Exchange entfernt, da sie für die Übermittlung über das Pickup-Verzeichnis nicht verwendbar sind. Auch die Bcc-Empfänger werden entfernt, um ihre Anonymität zu wahren. Sind nur Bcc-Empfänger angegeben, ersetzt Exchange sie im Header durch Undisclosed Recipients. Fehlt das Datumsfeld, verwendet Exchange Datum und Uhrzeit des Zeitpunkts, an dem die Datei aus dem Pickup-Verzeichnis entnommen wurde. Um die Nachrichten identifizieren zu können, die über das Pickup-Verzeichnis hereinkamen, fügt Exchange schließlich noch einen eigenen Header wie den folgenden hinzu: Received: from Pickup by ExServer1.contoso.com with Microsoft SMTP Server id 14.0.682.1; Thu, 25 Feb 2010 12:27:49 +0000
Das Wiedergabeverzeichnis Das Wiedergabeverzeichnis dient dazu, exportierte Exchange-Nachrichten erneut zu übertragen und Nachrichten von fremden Gateway-Servern zu empfangen. Wie im Pickup-Verzeichnis sieht Exchange auch alle fünf Sekunden im Wiedergabeverzeichnis nach und verarbeitet alle dort vorgefundenen Nachrichten. Diese Nachrichten werden vom fremden Gateway in Übereinstimmung mit den Anforderungen von Exchange formatiert. Das Gateway führt auch alle Konvertierungen durch, die nötig sind, um die Nachrichteninhalte aus dem ursprünglichen Format umzuwandeln. TIPP Versuchen Sie nicht, Nachrichten selbst in das Wiedergabeverzeichnis einzustellen. Wenn Sie eine Nachricht an Exchange übertragen müssen, verwenden Sie dazu das Pickup-Verzeichnis.
Anpassbare Systemnachrichten In Exchange können Sie zwei Arten von systemgenerierten Nachrichten anpassen: Benachrichtigungen über den Übermittlungsstatus (Delivery Status Notifications, DSNs) und Kontingentwarnungen. Um in solchen systemgenerierten Nachrichten eigene Texte anzuzeigen, mussten Sie in den Versionen vor Exchange Server 2007 mit Microsoft Kontakt aufnehmen und um eine maßgeschneiderte ErsatzDLL bitten, die die gewünschten Texte enthielt. Neben den Kosten für die Arbeiten an der neuen DLL handelten Sie sich damit zwei weitere Probleme ein. Erstens wurde dadurch der weitere Support zu einer unsicheren Sache. Wenn Sie die Anpassung von Microsoft vornehmen ließen, erhielten Sie wahrscheinlich auch Kundendienst dafür, was aber nicht der Fall war, aber wenn Sie jemand anderen damit beauftragten. Zweitens mussten Sie nach jeder Rollupaktualisierung und jedem Service Pack die Anpassung auf allen Hub-Transport-Servern der Organisation erneut testen und bereitstellen. In Exchange Server 2007 und 2010 können Sie jedoch den Text, der in Unzustellbarkeitsberichten und Kontingentwarnungen angezeigt wird, mit New-SystemMessage anpassen.
Benachrichtigungen über den Übermittlungsstatus Es ist unvermeidlich, dass Exchange einige der Nachrichten, die auf einem Hub-Transport-Server eingehen, nicht zustellen kann. Das kann daran liegen, dass das Zielpostfach voll ist, dass es deaktiviert oder gelöscht wurde, dass die Empfängeradressse ungültig ist usw. In diesem Fall erstellt
838
Exchange eine besondere Form von DSN, nämlich einen Unzustellbarkeitsbericht, um den Absender darüber zu informieren, dass die Nachricht nicht wie erwartet verarbeitet werden konnte. Insgesamt gibt es folgende fünf Kategorien von DSNs: 쐍 Weitergeleitet Diese Art von DSN wir erstellt, wenn ein Benutzer eine Auslieferungsbestätigung für eine Nachricht anfordert, die an einen SMTP-Remoteserver außerhalb der Exchange-Organisation geht. Eine weitere Nachverfolgung ist nicht mehr möglich. Exchange teilt dem Benutzer daher mit, dass die Nachricht bis zu dem Punkt weitergeleitet wurde, an dem sie die Organisation verlässt. Geht die Nachricht an eine andere Exchange-Organisation, kann ihre Zustellung jedoch nachverfolgt werden, sodass dabei kein DSN dieses Typs erstellt wird. 쐍 Verzögert Diese Art von DSN wird von einem Hub-Transport-Server erstellt, wenn die Aufenthaltsdauer von Nachrichten in einer Warteschlange den für Verzögerungsmeldungen eingestellten Grenzwert überschreitet. Der Standardwert beträgt vier Stunden, was Sie aber mit Set-TransportServer ändern können. Um ihn beispielsweise auf zwei Stunden zu verkürzen, verwenden Sie den folgenden Befehl. Beachten Sie, dass diese Einstellung nur für den betreffenden Server gilt und Sie sie daher auf allen Hub- und Edge-Transport-Servern vornehmen müssen, um eine einheitliche Verarbeitung in der gesamten Organisation zu gewährleisten. Set-TransportServer -Identity ExServer2 -DelayNotificationTimeout 02:00:00
쐍 Erfolg DSNs dieser Art werden erstellt, wenn ein Benutzer eine Zustellungsbestätigung für eine ausgehende Nachricht anfordert. Der DSN zeigt an, dass Exchange die Nachricht garantiert an das Zielpostfach ausgeliefert hat. 쐍 Fehlschlag Hierbei handelt es sich um die Unzustellbarkeitsberichte, die angeben, dass die Zustellung aus irgendeinem Grund fehlgeschlagen ist, z.B. aufgrund eines erschöpften Kontingents für das Zielpostfach oder einer mangelnden Autorisierung für Sendungen an den Empfänger. Der Transportdienst erstellt diese Nachrichten automatisch und fügt zur Orientierung des Benutzers die ursprüngliche E-Mail bei. Nachdem das Problem, das für die Unzustellbarkeit gesorgt hat, gelöst ist, kann der Benutzer die Funktionen des Clients nutzen, um die Nachricht erneut zu senden. 쐍 Erweiterung
Eine Gruppe wird erweitert, um die Nachricht an mehrere Empfänger zu senden.
Im Vergleich zu den vorherigen Versionen wurde die Qualität und Lesbarkeit der DSNs in Exchange Server 2007 erheblich verbessert, und diese Verbesserungen sind auch in Exchange Server 2010 in Kraft. Gewöhnlich gibt es keine Probleme mit den DSNs, die einen Fehlschlag oder eine Verzögerung melden. Der Standardtext in den Unzustellbarkeitsberichten ist gut verständlich, aber manchmal müssen Sie ihn anpassen, um den Anforderungen Ihrer Organisation zu genügen oder besondere Informationen für die Benutzer hinzuzufügen. Um diesen Vorgang zu erleichtern, teilt Exchange den Text eines Unzustellbarkeitsberichts in zwei Teile auf: eine einfach formulierte, kurze Erklärung des Problems, die dem Benutzer sagt, warum seine Nachricht nicht angekommen ist, und einen umfassenderen und stärker technisch orientierten Abschnitt mit Informationen zur Fehlerbehebung, der sich vor allem an Administratoren richtet. In einem Unzustellbarkeitsbericht ist der Text für die Benutzer als erster angeordnet, sodass er sofort ins Auge fällt und auch auf mobilen Geräten gelesen werden kann, die die Nachrichten nur teilweise herunterladen. Wie Sie in Abbildung 13.19 sehen, ist zwischen dem Benutzer- und dem Fehlerbehebungsabschnitt eine Menge Platz. Das ist absichtlich so, um den Benutzer nicht mit den Einzelheiten der Nachrichtenweiterleitung zu überfallen. Der Abschnitt zur Fehlerbehebung gibt die folgenden wichtigen Informationen:
839
Das Exchange-Transportsystem
Anpassbare Systemnachrichten
Kapitel 13
Das Exchange-Transportsystem
쐍 Der FQDN des Hub-Transport-Servers, der den Unzustellbarkeitsbericht erstellt hat. 쐍 Der Name und die E-Mail-Adresse des vorgesehenen Empfängers. 쐍 Die FQDNs der Remoteserver, die mit dieser Nachricht zu tun hatten. 쐍 Der erweiterte DSN-Statuscode. Diese Codes sind in RFC 3463 definiert und werden von SMTPServern generiert, um den Grund für den Fehlschlag einer Nachricht anzugeben. Beispiele sind die Codes 5.5.1 (unbekannte Adresse) und 5.7.1 (keine Autorisierung, um Nachrichten an die betreffende Adresse zu senden). Der FQDN des Remoteservers
Das Beispiel aus Abbildung 13.19 zeigt keine Einzelheiten über irgendwelche Remoteserver, da die Nachricht schon von dem Hub-Transport-Server abgelehnt wurde, an den der Postfachserver sie gesendet hat. Lehnt ein SMTP-Remotserver die Nachricht ab (z.B. aufgrund einer ungültigen Zieladresse), werden der FQDN dieses Servers und die von ihm empfangene Nachricht (z.B. RESOLVER.RST.NotAuthorized) aufgezeichnet, damit der Administrator weiß, was geschehen ist, als Exchange versucht hat, die Nachricht zu übermitteln. Abbildg. 13.19 Aufbau eines Unzustellbarkeitsberichts
Angesichts der Vielschichtigkeit moderner Messagingsysteme gibt es viele Gründe dafür, dass Exchange eine Nachricht nicht an einen internen oder externen Empfänger ausliefern kann. Tabelle 13.6 führt die DSNs für die häufigsten Fehler auf, denen Sie begegnen können.
840
Anpassbare Systemnachrichten
Häufige Gründe für eine fehlgeschlagene Zustellung DSN-Code
Problem
4.4.7 – Message expired (Nachricht abgelaufen)
Exchange konnte die Nachricht nicht innerhalb von zwei Tagen zustellen (Standardwert), weshalb sie abgelaufen ist und aus der Zustellwarteschlange entfernt wurde. Es kann aber auch sein, dass ein Administrator die Nachricht aus irgendeinem Grund aus der Warteschlange entfernt hat. Der Benutzer sollte sie erneut senden.
5.1.1 – Wrong email address (Falsche E-Mail-Adresse)
Der vorgesehene Empfänger ist im Verzeichnis des Empfängersystems nicht aufzufinden, sodass die Nachricht nicht zugestellt werden kann. Möglicherweise hat der Absender die Adresse falsch geschrieben oder eine veraltete Nachricht aus dem Spitznamencache von Outlook als Grundlage verwendet. In jedem Fall muss er die Adresse korrigieren und die E-Mail erneut senden.
5.1.3 – Incorrect address format (Falsches Adressformat)
Exchange vermutet, dass das Format der Adresse nicht korrekt ist, sodass die Nachricht nicht zugestellt werden kann. Der Benutzer muss die Adresse korrigieren und die E-Mail erneut senden.
5.1.4 – Duplicate address (Doppelte Adresse)
Das Empfängersystem hat eine doppelte Adresse entdeckt. Bei diesem Problem kann der Benutzer nichts tun. Bevor irgendjemand Nachrichten an diese Adresse senden kann, muss zunächst der Remoteadministrator die Dublette entfernen.
5.1.8 – Bad sender address (Fehlerhafte Absenderadresse)
Der Remotesender ist aus irgendeinem Grund nicht in der Lage, Nachrichten vom Absender zu empfangen. Hier bleibt nichts anderes zu tun, als die Diagnoseinformationen zu lesen und herauszufinden zu versuchen, was genau geschehen ist.
5.2.0 – Generic failure to deliver (Allgemeiner Zustellungsfehler)
Ursache hierfür können alle möglichen Arten von Problemen mit Postfächern sein, z.B. fehlende SMTP-Adressen, ungültige SMTP-Adressen oder ungültige Weiterleitungadressen. Der Administrator muss das Postfach des Empfängers prüfen und dafür sorgen, dass alles korrekt ist.
5.2.2 – Mailbox quota exceeded (Postfachkontingent überschritten)
Das Postfach des Empfängers ist voll und kann keine weiteren Nachrichten mehr annehmen. Damit wieder Nachrichten akzeptiert werden, muss der Empfänger die Nutzung seines Postfachs unter das Kontingent drücken, oder es muss ein höheres Kontingent festgelegt werden.
5.2.3 – Message too large (Nachricht zu groß)
Entweder dem Empfänger oder dem Absender ist es nicht erlaubt, eine Nachricht dieser Größe anzunehmen bzw. abzuschicken.
5.2.4 – Dynamic distribution group query is wrong (Fehlerhafte Abfrage für dynamische Verteilergruppe)
Exchange kann die Abfrage zur Bestimmung der Empfänger in einer dynamischen Verteilergruppe nicht auflösen. Der Administrator muss dieses Problem lösen, indem er die Abfrage für die Gruppe überprüft.
5.3.4 – Message too large to route (Nachricht zu groß zum Weiterleiten)
Einige der Komponenten unterwegs konnten die Nachricht aufgrund einer Größeneinschränkung nicht weiterleiten. Es kann sich dabei um eine Einschränkung für einen Connector, die in der Organisationskonfiguration festgelegt ist, oder um eine Einschränkung auf einem Remoteserver.
5.4.4 – Unable to route (Weiterleitung nicht möglich)
Wenn dieser Fehler auftritt, liegt das üblicherweise daran, das ein Benutzer versucht, eine Nachricht zu einer Domäne zu senden, die es gar nicht mehr gibt.
5.5.3 – Too many recipients (Zu viele Empfänger)
Im Nachrichtenheader sind zu viele Empfänger angegeben. Die einzige Lösung besteht darin, die Anzahl der Empfänger zu verringern und die Nachricht erneut zu senden. Denken Sie daran, dass Verteilergruppen unabhängig von der Anzahl der darin enthaltenen Empfänger nur als ein einziger Empfänger zählen. Verwenden Sie daher nach Möglichkeit Verteilergruppen.
5.7.1 – Lack of authorization (Keine Autorisierung)
Der Absender verfügt nicht über die erforderliche Autorisierung, um Nachrichten an den Empfänger zu schicken.
841
Das Exchange-Transportsystem
Tabelle 13.6
Kapitel 13
Das Exchange-Transportsystem
Anpassen von Unzustellbarkeitsberichten Sie können den Text ändern, der den Benutzern in einem Unzustellbarkeitsbericht angezeigt wird, und eigene Systemnachrichten für die neuen DSN-Codes erstellen, die im Zusammenhang mit Transportregeln verwendet werden. Nehmen wir beispielsweise an, dass Sie den Text verbessern möchten, den Exchange Server 2010 in DSNs für den Fehlercode 5.1.1 verwendet. Dieser Code wird ausgegeben, wenn Exchange eine Nachricht nicht zustellen kann, da der Empfänger unbekannt ist. Mit anderen Worten, Exchange kann keine E-Mail-aktivierten Gruppen, Kontakte, Postfächer oder öffentlichen Ordner mit der im Nachrichtenheader angegebenen Adresse finden. Der Standardtext für diesen Fall lautet: "Die eingegebene E-Mail-Adresse konnte nicht gefunden werden. Überprüfen Sie die E-MailAdresse des Empfängers, und veruschen Sie, die Nachricht erneut zu senden. Wenden Sie sich an den Helpdesk, falls das Problem weiterhin besteht."
Mit dem Cmdlet New-SystemMessage erstellen wir wie im folgenden gezeigt einen eigenen Text für den Fehlercode 5.1.1. Angezeigt werden soll er bei Nachrichten in deutscher Sprache von internen Absendern an externe Empfänger, weshalb wir den Parameter -Internal auf $False setzen. Wäre die Fehlermeldung rein für den internen Gebrauch da, wie es z.B. bei einer Nachricht für die Verwendung in einer Transportregel der Fall wäre, so hätten wir -Internal auf $True gesetzt. New-SystemMessage -Language de -DsnCode 5.1.1 -Text "Leider konnte unser E-Mail-System den Empfänger in unserem Verzeichnis nicht finden, weshalb die Nachricht nicht zugestellt werden konnte. Schauen Sie bitte in Ihrem Notizbuch nach, ob Sie die richtige Adresse verwendet haben, oder nehmen Sie per Telefon oder Fax Kontakt mit dem Empfänger auf." Internal $False
Das ist eine sehr viel persönlichere Formulierung. Abbildung 13.20 zeigt, wie unser angepasster Unzustellbarkeitsbericht aussieht, wenn ihn ein Benutzer erhält. Nur der Text für den Benutzer wurde geändert, während die Diagnoseinformationen für Administratoren so geblieben sind, wie sie waren. Abbildg. 13.20 Anzeige eines angepassten Unzustellbarkeitsberichts
842
Für Nachrichten an interne Empfänger können wir den Text noch weiter anpassen und einen URL angeben, auf den die Benutzer klicken können, um ausführlichere Anleitungen zu erhalten. Änderungen an einer angepassten Nachricht nehmen wir mit Set-SystemMessage vor. Betrachten Sie dazu das folgende Beispiel: Set-SystemMessage -Identity de\Internal\5.1.1 -Text "Ihre Nachricht konnte nicht zugestellt werden, da die von Ihnen angegebene Adresse nicht im Verzeichnis des Unternehmens zu finden ist. Bitte sehen Sie im internen Verzeichnis nach, um die korrekte E-Mail-Adresse zu finden."
Bezeichnet werden die abgepassten Nachrichten mit dem Sprachcode (de für Deutsch), einer Angabe, ob sie für den internen oder externen Gebrauch dient, und dem DSN-Code. Um unsere Aufgabe abzuschließen, müssen wir den Text natürlich noch für alle Sprachen anpassen, die in der Organisation verwendet werden, und uns überlegen, ob wir auch den Text ändern wollen, den externe Empfänger sehen. Insidertipp: Testen des angepassten Textes
Wenn Sie den gewünschten Text abgefasst haben, können Sie mit dem Cmdlet Get-SystemMessage überprüfen, ob die angepasste Nachricht verwendet wird und sie die erwarteten Eigenschaften aufweist: Get-SystemMessage -Identity de\Internal\5.1.1 | Format-List
Das ergibt folgende Ausgabe: Text : Ihre Nachricht konnte nicht zugestellt werden, da die von Ihnen angegebene Adresse nicht im Verzeichnis des Unternehmens zu finden ist. Bitte sehen Sie im internen Verzeichnis nach, um die korrekte E-Mail-Adresse zu finden. Internal : True Language : de DsnCode : 5.1.1 QuotaMessageType : AdminDisplayName : ExchangeVersion : 0.1 (8.0.535.0) Name : 5.1.1 DistinguishedName : CN=5.1.1,CN=Internal,CN=9,CN=DSN Customization,CN=Transport Settings,CN=contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com Identity : en\Internal\5.1.1
Angepasste Systemnachrichten werden in Active Directory in den Exchange-Konfigurationsdaten gespeichert und in der gesamten Organisation repliziert, sodass sie auf allen Hub-Transport-Servern zur Verfügung stehen. Der definierte Name einer Systemnachricht gibt den Pfad an, sodass wir uns im ADSI-Editor zu dem Objekt begeben und seine Eigenschaften anzeigen können (siehe Abbildung 13-21). Für Hub- und Edge-Transport-Server können Sie jeweils unterschiedliche Sätze von angepassten DSNs unterhalten, beispielsweise um in den internen DSNs zusätzliche Informationen anzugeben, die Sie externen Empfängern gegenüber nicht offenbaren möchten. Wie in Kapitel 14 erklärt wird, weisen Edge-Transport-Server ihre eigene Konfiguration auf, die von den in Active Directory gespeicherten und von den Hub-Transport-Servern verwendeten Organisationseinstellungen getrennt ist.
843
Das Exchange-Transportsystem
Anpassbare Systemnachrichten
Kapitel 13
Das Exchange-Transportsystem
Wenn Sie die DSNs für Nachrichten anpassen möchten, die auf Edge-Transport-Servern verarbeitet werden, müssen Sie diese Änderungen auf allen Edge-Transport-Servern vornehmen. Dazu können Sie die bereits beschriebenen Techniken einsetzen. Abbildg. 13.21 Anzeige der Active Directory-Eigenschaften eines benutzerdefinierten Unzustellbarkeitsberichts
Anpassen von Kontingentbenachrichtigungen Mit dem Cmdlet New-SystemMessage können Sie auch den Text von Nachrichten ändern, in denen die Besitzer von Postfächern und öffentlichen Ordnern darauf hingewiesen werden, dass ihre Kontingente zur Neige gehen oder schon überschritten sind. Der Postfachassistent von Exchange überprüft jede Nacht die Kontingente der Postfächer und öffentlichen Ordner und sendet dann die erforderlichen Nachrichten. Für ein Postfach werden so lange Warnnachrichten gesendet, bis der Besitzer des Postfachs auf das Genörgel reagiert und die Größe seines Postfachs wieder unter das Kontingent drückt. Bei einem öffentlichen Ordner werden die Warnnachrichten an alle dafür registrierten Besitzer gesendet (dies kann auch eine Verteilergruppe sein). Systemgenerierte Nachrichten werden bei der Bestimmung der Kontingente nicht einbezogen. Abbildung 13.22 zeigt die verschiedenen Teile einer typischen systemgenerierten Kontingentbenachrichtigung. Den Nachrichtenbetreff können Sie nicht ändern, da der Wert für dieses Feld aus den übersetzten Strings im Exchange-Code stammt. Es ist auch nicht möglich, die grafische Darstellung des Kontingents und der Nutzung zu ändern. Was Sie jedoch anpassen können, ist der Text unterhalt dieser Grafik, der beschreibt, welches Problem bei dem Postfach (bzw. dem öffentlichen Ordner) vorliegt und welche Maßnahmen der Benutzer ergreifen sollte. In vielen Unternehmen wird dieser Text geändert, um die Benutzer zu einer Website zu führen, auf der sie umfassende Anweisungen dazu erhalten, wie Sie alte und überholte Elemente entfernen und die Nutzung wieder unter die Kontingentgrenze drücken können. In Tabelle 13.7 finden Sie einen Überblick über die Nachrichtencodes für die Warnungen, die Sie anpassen können, zusammen mit den standardmäßigen Betreffzeilen und einem Hinweis auf die Umstände, die eine solche Nachricht hervorrufen.
844
Anpassbare Systemnachrichten
Das Exchange-Transportsystem
Abbildg. 13.22 Die Zusammensetzung einer vom System generierten Kontingentwarnung
Tabelle 13.7
Anpassbare Kontingentwarnungen Nachrichtencode
Standardbetreff
Ursache
ProhibitPostPublicFolder
Ihr Öffentlicher Ordner ist voll.
Ein öffentlicher Ordner überschreitet den Grenzwert für das Einstellen von Elementen. Es können keine weiteren Elemente mehr in den Ordner eingefügt werden.
ProhibitSendReceiveMailbox
Ihr Postfach ist voll.
Ein Postfach überschreitet die Grenzwerte für das Senden und das Empfangen. Es kann keine weiteren Nachrichten mehr erhalten oder abschicken.
ProhibitSendMailbox
Ihr Postfach ist voll.
Ein Postfach überschreitet den Grenzwert für das Senden. Es kann zwar noch Nachrichten empfangen, aber keine mehr abschicken.
WarningMailboxUnlimitedSize
Ihr Postfach ist fast voll.
Ein Postfach, für das keine Grenzwerte zum Senden und Empfangen festgelegt sind, überschreitet sein Warnlimit (falls eines festgelegt ist). Dies ist nur eine Warnung. Das Postfach kann weiterhin Nachrichten senden und empfangen.
WarningPublicFolderUnlimitedSize
Ihr Öffentlicher Ordner wird zu groß.
Ein öffentlicher Ordner, für den keine Grenzwerte zum Senden und Empfangen festgelegt sind, überschreitet sein Warnlimit (falls eines festgelegt ist). Benutzer können weiterhin Elemente in den Ordner aufnehmen.
WarningMailbox
Ihr Postfach wird zu groß.
Ein Postfach überschreitet seine Warnschwelle. Dies ist nur eine Warnung. Das Postfach kann weiterhin Nachrichten senden und empfangen, bis es die festgelegten Grenzwerte überschreitet.
WarningPublicFolder
Ihr Öffentlicher Ordner ist fast voll.
Ein öffentlicher Ordner, für den Grenzwerte für das Senden oder Empfangen festgelegt sind, überschreitet sein Warnlimit (falls eines festgelegt ist).
845
Kapitel 13
Das Exchange-Transportsystem
Nehmen wir an, Sie möchten die Meldung anpassen, die Benutzer empfangen, deren Postfächer sich dem Grenzwert für das Kontingent annähern. Dieses Ziel erreichen Sie mit dem folgenden Befehl: New-SystemMessage -QuotaMessageType WarningMailbox -Language de -Text "Das Kontingent, das für Ihr Postfach eingeräumt wurde, geht dem Ende entgegen. Sie sollten in diesem Postfach sofort aufräumen, um Speicherplatz wiederzugewinnen. Weitere Informationen erhalten Sie in den Tipps zum Aufräumen von Postfächern." -Internal $True
Insidertipp: Tipps für die Verwendung von angepassten Kontingentbenachrichtigungen
Angepasste Kontingentbenachrichtigungen sind immer intern, weshalb Sie den Parameter -Internal $True eigentlich nicht hinzuzufügen brauchen. Die Nachrichten sind sprachspezifisch, wobei Exchange auf den Standardtext zurückgreift, wenn Sie für eine Sprache keinen angepassten Text angeben. Wenn Sie einen Fehler begehen, können Sie den Text mit Set-SystemMesssage wieder ändern: Set-SystemMesssage -Identity de\WarningMailbox -Text 'Ich wünschte, ich könnte Ihnen sagen, wie Sie Ihr Postfach aufräumen sollen ...'
Mit Remove-SystemMessage können Sie eine angepasste Kontingentbenachrichtigung löschen: Remove-SystemMessage de\WarningMailbox
Protokollierung Auf Hub-Transport-Servern mit Exchange Server 2010 können Sie die Konnektivitäts- und die so genannte »Protokollprotokollierung« (Protocol Logging) einrichten. Anhand dieser Protokolle können Sie ablesen, was geschieht, wenn Exchange Nachrichten sendet und empfängt. Sicherlich werden sie sich diese Protokolle nicht täglich ansehen, aber sie sind sehr nützlich, wenn Sie herausfinden müssen, warum Nachrichten nicht wie erwartet transportiert werden. Auf der Registerkarte Protokolleinstellungen des Eigenschaftendialogfelds für einen Server, auf dem die Hub- oder Edge-Transport-Rolle installiert ist, sind einige Einstellungen für die Protokollierung zugänglich (siehe Abbildung 13.23). Abbildg. 13.23 Protokollierungseinstellungen für einen Server
846
Für Server ohne diese Rollen wird diese Registerkarte nicht angezeigt. Hier können Sie die Konnektivitätsprotokollierung ein- und ausschalten und festlegen, wo die Protokolle abgelegt werden. Außerdem können Sie Speicherorte für die Protokollprotokollierung angeben, die Protokollierung selbst aber nicht in der Konsole aktivieren, sondern nur in der Verwaltungsshell. Vielleicht wurde das so gehandhabt, weil Protokolle dieser Art nur ausnahmsweise erstellt werden müssen, allerdings stellt es eine kleine Uneinheitlichkeit dar, dass es hier kein Kontrollkästchen gibt, um die Protokollprotokollierung genauso einfach ein- und auszuschalten wie die Konnektivitätsprotokollierung.
Steuern der Konnektivitätsprotokollierung In der Dokumentation zu Exchange Server 2010 heißt es, dass die Konnektivitätsprotokollierung standardmäßig deaktiviert sei, doch auf den Servern, mit denen ich gearbeitet habe, war das nicht der Fall. Um sicherzugehen, können Sie die Konnektivitätsprotokollierung wie folgt aktivieren: Set-TransportServer –Identity ExServer4 –ConnectivityLogEnabled $True
Um sie wieder auszuschalten, setzen Sie den Parameter einfach auf $False. Exchange erstellt täglich ein neues Konnektivitätsprotokoll. Das erste Mal geschieht dies, wenn das Transportsystem eine ausgehende Nachricht verarbeitet. Das erste Protokoll eines Tages wird nach dem Prinzip CONNECTLOG<JJJJMMDD>-1.log benannt, wobei <JJJJMMDD> für die Angabe von Jahr, Monat und Tag steht. Das erste Protokoll vom 31. Dezember 2011 bekommt also den Namen CONNECTLOG20111231-1. log. Standardmäßig erstellt Exchange ein neues Protokoll, nachdem 10 MB an Verbindungsdaten erfasst wurden. Das zweite Protokoll vom 31. Dezember 2011 heißt dann CONNECTLOG20111231-2. log, das dritte CONNECTLOG20111231-3.log usw. Die Größe für diese Protokolle können Sie wie folgt ändern: Set-TransportServer –Identity ExServer4 –ConnectivityLogMaxFileSize 50MB
Exchange bewahrt 250 MB an Konnektivitätsprotokollen auf. Damit der Umfang der Protokolle im Verzeichnis diesen Speicherplatz nicht übersteigt, wird eine Umlaufprotokollierung durchgeführt, bei der die ältesten Protokolle gelöscht werden, um Platz für neue zu schaffen. Den Betrag für den Speicherplatz können Sie wie folgt erhöhen: Set-TransportServer –Identity ExServer4 –ConnectivityLogMaxDirectorySize 500MB
Sofern der Grenzwert für den Speicherplatz im Verzeichnis nicht überschritten wird, werden Konnektivitätsprotokolle normalerweise 30 Tage lang aufbewahrt. Da zur Behebung von Verbindungsproblemen gewöhnlich nur die letzten Protokolle herangezogen werden müssen, können Sie diessen Zeitraum auch verkürzen. Mit dem folgenden Befehl richten Sie ihn beispielsweise auf 15 Tage ein: Set-TransportServer –Identity ExServer4 –ConnectivityLogMaxAge 15.00:00:00
Der Standardspeicherort für die Protokolldateien ist tief unter dem Exchange-Stamm vergraben, weshalb es meistens bequemer ist, die Protokolle in einem Verzeichnis abzulegen, das Sie sich leichter merken können. Um den Standardspeicherort für die Konnektivitätsprotokolle zu ändern, verwenden Sie folgenden Befehl: Set-TransportServer –Identity ExServer4 –ConnectivityLogMaxAge 15.00:00:00
847
Das Exchange-Transportsystem
Protokollierung
Kapitel 13
Das Exchange-Transportsystem
Fehlerbehebung: Wie kann es kommen, dass ich zwei Konnektivitätsprotokolle mit demselben Namen habe?
Wenn der angegebene Pfad nicht existiert, erstellt Exchange das neue Verzeichnis, allerdings werden die aktuellen oder sonstige bereit bestehende Protokolle nicht in diesen neuen Ordner verschoben. Unmittelbar nach der Änderung fängt Exchange aber an, den neuen Speicherort für neu erfasste Verbindungsdaten zu verwenden. Wenn Sie dann die Protokolle aus dem ursprünglichen Verzeichnis in das neue kopieren, kann es vorkommen, dass Sie zwei Protokolle mit demselben Namen haben. Dieses Problem lässt sich aber durch Umbenennen der älteren Protokolle schnell lösen. Alle diese Befehle gelten jeweils für den angegebenen Server. Am besten ist es, auf allen Transportservern der Organisation dieselben Einstellungen anzuwenden, um ein einheitliches Verhalten zu gewährleisten. Zum Glück lässt sich das in der Exchange-Verwaltungsshell einfach erledigen: Get-TransportServer | Set-TransportServer –ConnectivityLogPath 'C:\Logs\Connectivity' – ConnectivityLogMaxAge 15.00:00:00 –ConnectivityLogMaxDirectorySize 500MB – ConnectivityLogMaxFileSize 50MB
Lesen eines Konnektivitätsprotokolls Ein Konnektivitätsprotokoll können Sie mit einem Texteditor oder allgemein mit jedem Programm öffnen, dass das CSV-Format versteht. Ich persönlich verwende für diesen Zweck gern Microsoft Excel. Abbildung 13.24 zeigt den typischen Inhalt eines solchen Protokolls. Die ersten fünf Zeilen besagen, dass die Datei von Exchange Server 2010 erstellt wurde (Version 14.0.0.0), und geben das Erstelldatum sowie den Typ des Protokolls an. Außerdem sehen Sie die Namen der Felder für die Datensätze in der Datei. Jede Transaktion mit einem anderen Server, die zum Senden einer Nachricht dient, setzt sich aus einer Reihe von Einzelschritten zusammen, die sich je nach Art der Transaktion und der Anzahl der beteiligten Server ändern. Bei manchen Transaktionen ist eine Auslieferung an eine Postfachdatenbank auf einem anderen Server im Standort erforderlich. Die Quelle der Nachricht wird entweder als SMTP angegeben, was bedeutet, dass sie von einer Remote-Zustellwarteschlange stammt, oder als MAPI für Verbindungen von der Postfach-Zustellwarteschlange zu einer Datenbank. Im Richtungsfeld können Sie ablesen, ob der Schritt am Anfang (+), in der Mitte (>) oder am Ende (-) der Transaktion stattgefunden hat. Damit können Sie dem Ablauf besser folgen. HINWEIS Eine Transaktion kann mehrere Sitzungen umfassen. Beispielsweise ist für eine Nachricht, die an mehrere Datenbanken auf anderen Servern geht, für jede Zieldatenbank eine eigene Sitzung erforderlich. Treten während solcher Transaktionen Fehler auf, erfasst Exchange die Angaben zu solchen Ereignissen im Konnektivitätsprotokoll. Abbildung 13.24 zeigt die typischen Informationen, die in einem Konnektivitätsprotokoll erfasst werden. Hier werden mehrere Verbindungen gezeigt. Sie sehen die Kommunikation zwischen den Hub-Transport-Servern (bezeichnet als hub version 14), die untereinander Nachrichten austauschen, die Zustellung zur Datenbank db2 (der wichtige Anhaltspunkt ist hier der Text starting delivery) sowie Verbindungen zum und vom Edge-Transport-Server exedge1.contoso.com, die aufgebaut werden, wenn Nachrichten in die Organisation hineingelangen bzw. sie verlassen.
848
Protokollierung
Das Exchange-Transportsystem
Abbildg. 13.24 Anzeige eines Konnektivitätsprotokolls
Protokollprotokollierung Die Protokollprotokollierung verfolgt die einzelnen Schritte der SMTP-Kommunikation zur Übertragung von Nachrichten zwischen Servern mit Exchange und anderen Systemen nach. Diese Protokollierung erfolgt detaillierter als die zur Nachverfolgung der Verbindungen, da hierbei auch Einzelheiten wie die Authentifizierung zwischen den Servern und die verwendeten SMTP-Verben verfasst werden. Die Vorgehensweise zur Verwaltung der Protokollprotokollierung und der dadurch aufgezeichneten Protokolle ähnelt sehr stark der für Konnektivitätsprotokolle. Schließlich wäre es für die Entwickler nicht sehr sinnvoll gewesen, mehrere Methoden zum Erstellen und Verwalten von Protokollen zu schaffen. Die Protokollprotokollierung ist standardmäßig deaktiviert, weshalb Sie sie connectorweise einschalten müssen, bevor Exchange entsprechende Protokolle anlegt. Exchange erstellt getrennte Protokolle für Sende- und Empfangsvorgänge. Wie bei der Konnektivitätsprotokollierung liegt die Ausgabe im CSV-Formt vor. In Abbildung 13.25 sehen Sie den Inhalt eines typischen SMTP-Empfangsprotokolls (zur Verdeutlichung wurden einige Schritte entfernt). Das Beispiel zeigt, wie zwei Hub-Transport-Server mit Exchange eine SMTP-Verbindung zueinander aufbauen, um Nachrichten auszutauschen. Nach dem normalen SMTP-Austausch der verwendbaren Verben wird die Verbindung mit TLS authentifiziert. Anschließend beginnt der sendende Server mit der Übertragung der Felder des Nachrichtenheaders, angefangen bei der Absenderangabe (MAIL FROM). Der empfangende Server prüft nach, ob der Absender akzeptabel und nicht etwa blockiert ist (bei dem Empfänger mag es sich um eine Adresse mit Einschränkungen
849
Kapitel 13
Das Exchange-Transportsystem
handeln, die nur Nachrichten von bestimmten Absendern erhalten darf). In dem Protokoll können Sie das neue ESMTP-Verb XSHADOW (Extended SMTP) sehen, das verwendet wird, um Informationen für die Schattenredundanzfunktion des Transportpapierkorbs zu senden. Der Nachrichteninhalt wird binär übertragen (BDAT), und die Kommunikation wird mit dem (hier nicht gezeigten) Verb XQDISCARD abgeschlossen. Dabei handelt es sich um ein neues ESMTP-Verb, das in Exchange Server 2010 zur Unterstützung der Schattenredundanz eingeführt wurde. Im Abschnitt »Schattenredundanz« weiter hinten in diesem Kapitel erhalten Sie weitere Informationen über die Funktionsweise der Schattenredundanz. Mit dem letzten Schritt wird die Verbindung zwischen den beiden Servern getrennt. Abbildg. 13.25 Anzeige eines SMTP-Empfangsprotokolls
Der Inhalt eines Sendeprotokolls sieht sehr ähnlich aus. Wenn Sie sich beispielsweise die Transaktionen zum Senden einer Nachricht über ein externes SMTP-Relay ansehen, können Sie erkennen, dass sich Exchange mit EHLO identifiziert, eine TLS-gesicherte Verbindung aufbaut, sofern der Relayserver das zulässt, die Nachricht sendet und die Verbindung dann wieder schließt. Beim Einrichten der Protokollprotokollierung müssen wir als Erstes entscheiden, für welche Connectors wir diese Protokollierung aktivieren wollen. Jeder Hub-Transport-Server verfügt über zwei standardmäßige Empfangsconnectors, einen zur Überwachung von Port 25 und zur Annahme von SMTP-Nachrichten von anderen Servern und einen zweiten zur Überwachung von Port 587 und zur Handhabung der von Clients gesendeten Nachrichten. Die Protokollierung für beide Connectors können wir wie folgt vornehmen: Get-ReceiveConnector –Server ExServer1 | Set-ReceiveConnector –ProtocolLoggingLevel Verbose
850
Um die Protokollprotokollierung abzuschalten, setzen wir den Protokollierungsgrad auf None. Natürlich müssen Sie die Protokollierung nicht für beide Connectors einschalten. Wenn Sie sie nur für den Connector aktivieren wollen, der sich um den SMTP-Datenverkehr von anderen Servern kümmert, verwenden Sie folgenden Befehl: Set-ReceiveConnector –Identity 'ExServer1\Default ExServer1' –ProtocolLoggingLevel Verbose
Die Aktivierung der Protokollprotokollierung erfolgt fast genauso. Es gibt zwei Arten von Sendeconnectors: Die expliziten oder normalen Sendeconnectors sind zur Handhabung des Datenverkehrs zu angegebenen SMTP-Domänen da, aber daneben erstellt Exchange auf jedem Hub-Transport-Server noch besondere Intraorganisations-Sendeconnectors, um Nachrichten innerhalb der Organisation zu senden. Für einen normalen Connector aktivieren Sie die Protokollierung wie folgt: Set-SendConnector –Identity 'Smart Relay via contoso.com' –ProtocolLoggingLevel Verbose
Da es keine Kennung gibt, die Sie übergeben könnten, um einen Intraorganisations-Connector zu bezeichnen, können Sie die Protokollprotokollierung dafür nicht mit Set-SetConnector aktivieren. Stattdessen verwenden Sie wie folgt Set-TransportServer: Set-TransportServer –Identity ExServer1 –IntraOrgConnectorProtocolLoggingLevel Verbose
Das Cmdlet Set-TransportServer dient auch dazu, den Speicherort für die Sende- und Empfangsprotokolle, die Maximalgröße der einzelnen Protokolle (standardmäßig 10 MB), die Gesamtgröße des Protokollverzeichnisses und die Altersgrenze für Protokolle festzulegen. Die einzige dieser Einstellungen, die Sie auch in der Exchange-Verwaltungskonsole vornehmen können, ist der Speicherort der Protokolle. Wie bei den Konnektivitätsprotokollen verwendet Exchange auch hier eine Umlaufprotokollilerung, um den Gesamtumfang der Protokolle unter den angegebenen Grenzwerten zu halten. Der folgende Beispielbefehl zeigt, wie Sie die verschiedenen Einstellungen ändern können: Set-TransportServer –Identity ExServer2 –ReceiveProtocolLogPath 'C:\Logs\SMTPReceive' –SendProtocolLogPath 'C:\Logs\SMTPSend' –ReceiveProtocolLogMaxFileSize 20MB –SendProtocolLogMaxFileSize 20MB –ReceiveProtocolLogMaxDirectorySize 500MB –SendProtocolLogMaxDirectorySize 500MB –ReceiveProtocolLogMaxAge 15:00.00.00 –SendProtocolLogMaxAge 15:00.00.00
Wie bei den Konnektivitätsprotokollen ist es auch hier empfehlenswert, auf allen Hub-TransportServern der Organisation dieselben Einstellungen zu verwenden. Das können Sie mit der im letzten Abschnitt beschriebenen Technik auf einfache Weise bewerkstelligen: Rufen Sie mit Get-TransportServer eine Liste aller Hub-Transport-Server ab und verwenden Sie diese Liste als Eingabe für SetTransportServer, um die Einstellungen festzulegen.
Akzeptierte Domänen Bevor das Transportsystem eingehende Nachrichten für eine E-Mail-Domäne (einen SMTPNamensraum) annimmt, muss diese Domäne erst in Exchange deklariert werden. Domänen, für die Exchange Nachrichten annimmt, heißen akzeptierte Domänen. Die Domäne, in der Exchange installiert wurde, wird während der Installation des ersten Hub-Transport-Servers in der Organisation automatisch in die Liste der akzeptierten Domänen aufgenommen. Wenn Sie noch andere Domänen
851
Das Exchange-Transportsystem
Akzeptierte Domänen
Kapitel 13
Das Exchange-Transportsystem
verwenden möchten, müssen Sie sie ebenfalls zu dieser Liste hinzufügen. Die Definition akzeptierter Domänen dient im Grunde dazu, Exchange mitzuteilen, welche SMTP-Namensräume in der Organisation verwendet werden, welche Namensräume vertrauenswürdige Partnerorganisationen nutzen und für welche Namensräume anderer Domänen Exchange Verarbeitungsaufgaben durchführt. In Exchange sind zwei Arten von akzeptierten Domänen möglich: 쐍 Autorisierende Domänen sind diejenigen, für die die Exchange-Organisation Postfächer unterhält. Anders ausgedrückt: Die Objekte aus dieser Domäne sind in Active Directory zu finden, wenn Exchange danach sucht, um eingehende Nachrichten weiterzuleiten. Wenn Sie beispielsweise in Ihrem Unternehmen nach einer Fusion die alten E-Mail-Adressen beibehalten und zu Postfächern zuordnen möchten, müssen Sie sämtliche früheren Domänen zu akzeptierten und autorisierenden Domänen machen. Damit externe E-Mail-Systeme Nachrichten zur Zustellung in den Postfächern dieser Adressen an Exchange weiterleiten können, müssen sie natürlich über DNS-MX-Einträge instruiert werden. 쐍 Relaydomänen sind diejenigen, zu denen Exchange eingehende Nachrichten weiterleitet. Beispielsweise kann es sein, dass Exchange Server-Computer als Front-End-E-Mail-Server für mehrere kleinere Niederlassungen dienen, deren Postfächer auf anderen E-Mail-Systemen ausgeführt werden. Die öffentlichen MX-Einträge für diese Domänen zeigen auf Exchange (entweder auf einen Edge-Transport-Server oder einen anderen Front-End-Server, der Nachrichten an Exchange leitet). In einer solchen Situation können Sie die Domänen der Niederlassungen als Relaydomänen deklarieren, sodass Exchange eingehende Nachrichten dafür annimmt und über einen geeigneten Sendeconnector an ihr endgültiges Ziel weiterleitet. Es kann sowohl interne als auch externe Relaydomänen geben. Die internen können auch Empfänger enthalten, die Exchange-Postfächer haben. In diesem Fall können alle eingehenden Nachrichten an diese Empfänger ganz normal zugestellt worden. Nachrichten an Empfänger ohne Exchange-Postfächer werden über einen Connector für diesen Adressraum weitergeleitet. Externe Relaydomänen haben nichts mit Exchange zu tun, weshalb alle eingehenden Nachrichten für sie einfach über den bestmöglichen Connector zur Zustellung an den Zielserver weitergeleitet werden. Stellen Sie sich z.B. vor, Sie haben eine Abteilung, die ihren eigenen SMTP-E-Mail-Server für die Domäne dev.contoso.com unterhält. In diesem Fall erstellen Sie einen Eintrag für die akzeptierte Domäne dev.contoso.com, sodass Exchange Nachrichten für diese Domäne annehmen kann, und fügen dev.contoso.com zum Adressraum für einen Connector hinzu, damit das Transportsystem die Nachrichten gleich bei ihrem Eintreffen zu diesem Connector weiterleiten kann. Akzeptierte Domänen können spezifisch sein, aber auch alle Unterdomänen einschließen. Beispielsweise können Sie akzeptierte Domänen namens contoso.com oder *.contoso.com anlegen. In letzterem Fall werden alle an Unterdomänen von contoso.com gesendeten Nachrichten von Exchange angenommen. VORSICHT Bevor Domänen in einer E-Mail-Adressrichtlinie verwendet werden können, müssen Sie sie zur Liste der akzeptierten Domänen hinzufügen. In Kapitel 6, »Verwalten von E-Mailaktivierten Empfängern«, erhalten Sie weitere Informationen darüber, wie Sie E-Mail-Adressrichtlinien erstellen und anwenden. Wenn Sie die akzeptierte Domäne entfernen, auf die sich eine Richtlinie stützt, wird die Richtlinie dadurch ungültig. In diesem Fall können Benutzer, die auf die von dieser Richtlinie erstellen E-Mail-Adressen angewiesen sind, keine Nachrichten mehr senden oder empfangen, bis ihren Postfächern mithilfe einer anderen Richtlinie gültige E-Mail-Adressen zugewiesen wurden.
852
Erstellen einer neuen akzeptierten Domäne Nehmen wir an, Ihr Unternehmen wurde von der Firma Fabrikam Corporation gekauft, sodass Sie nun allen Benutzern neue Adressen in fabrikam.com zuweisen müssen. Der erste Schritt besteht darin, eine neue akzeptierte Domäne für fabrikam.com zu erstellen. In der Exchange-Verwaltungskonsole öffnen Sie dazu den Abschnitt Hub-Transport unter dem Knoten Organisationskonfiguration und wählen im Aktionsbereich die Option Neue akzeptierte Domäne, woraufhin der gleichnamige Assistent aus Abbildung 13.26 erscheint. Hier können Sie einen Namen für die Domäne und die in Nachrichten verwendete SMTP-Domäne angeben. Außerdem können Sie auswählen, ob es sich um eine autorisierende oder um eine Relaydomäne handeln soll. Abbildg. 13.26 Erstellen einer neuen akzeptierten Domäne
Der Name der akzeptierten Domäne muss nichts mit der tatsächlichen Bezeichnung der SMTPDomäne zu tun haben. So können Sie beispielsweise Namen wie E-Mail-Routing an Filialen oder Alte Domänen vor der Fusion verwenden, um den Zweck der Domänen für das Messaging anzugeben. Der Verwaltungsshellbefehl zum Erstellen einer neuen akzeptierten Domäne lautet wie folgt: New-AcceptedDomain -Name 'Fabrikam' -DomainName 'Fabrikam.com' -DomainType 'Authoritative'
Nachdem wir eine neue akzeptierte Domäne erstellt haben, können wir die E-Mail-Adressrichtlinie mit der höchsten Priorität ändern, um die neuen Adressen in fabrikam.com zu den E-Mail-aktivierten Empfängern hinzuzufügen. Das können Sie mit dem folgenden Befehl tun: Set-EmailAddressPolicy -Identity 'FirstNameLastName' –Priority 1 -EnabledEmailAddressTemplates SMTP:%g.%[email protected],smtp:%g.%[email protected] Update-EmailAddressPolicy –Identity 'FirstNameLastName'
853
Das Exchange-Transportsystem
Akzeptierte Domänen
Kapitel 13
Das Exchange-Transportsystem
Verwalten akzeptierter Domänen In der Exchange-Verwaltungskonsole können Sie neue akzeptierte Domänen erstellen, die Eigenschaften von akzeptierten Domänen einsehen, eine Domäne zur Standarddomäne der Organisation machen und sie aus der Organisation entfernen. Die erste akzeptierte Domäne in der Organisation wird automatisch als Standarddomäne gekennzeichnet, was gewöhnlich auch nicht geändert zu werden braucht. Die Exchange-Verwaltungskonsole kennzeichnet die Standarddomäne in der Liste der akzeptierten Domänen. Diese Information erhalten Sie aber auch über das Cmdlet Get-AcceptedDomain. Wenn Sie eine akzeptierte Domäne löschen, nimmt Exchange keine E-Mails mehr an, die an die damit verbundene SMTP-Domäne adressiert sind. Wenn Sie beispielsweise wie folgt die Domäne Fabrikam mithilfe von Remove-AcceptedDomain entfernen, akzeptiert Exchange keine Nachrichten mehr an *.fabrikam.com. Remove-AcceptedDomain –Identity "Fabrikam"
VORSICHT Weder in der Exchange-Verwaltungskonsole noch in der Verwaltunsshell gibt es eine Möglichkeit, um die SMTP-Domänen einer akzeptierten Domäne zu ändern. Wenn Sie also bei der Definition der SMTP-Domänen für eine akzeptierte Domäne einen Fehler machen, müssen Sie den Eintrag für diese akzeptierte Domäne löschen und mit den korrekten Angaben neu erstellen.
Remotedomänen Einträge für Remotedomänen legen das Format von Nachrichten und die Art von automatischen Nachrichten (z.B. automatische Antworten) fest, die Exchange an eine andere SMTP-Domäne senden kann. Bei der Installation von Exchange wird eine »Sammelremotedomäne« (*) erstellt, die für die meisten Zwecke ausreichen sollte. Eine neue Remotedomäne müssen Sie nur dann erstellen, wenn Sie wissen, dass eine fremde SMTP-Domäne besondere Anforderungen stellt. Beispielsweise kann es sein, dass das E-Mail-System dieser Domäne nur einfache Textnachrichten mit Zeilenumbrüchen an bestimmten Positionen annimmt. Im Gegensatz dazu akzeptiert eine andere Exchange Server 2010Organisation alle Arten von Nachrichten, die Ihre Exchange-Organisation hervorbringen kann. Um auf die für die Organisation definierten Remotedomänen zugreifen zu können, wählen Sie den Knoten Organisationskonfiguration und darunter Hub-Transport. Die beiden Eigenschaftendialogfelder in Abbildung 13.27 zeigen die Standardeinstellungen für die standardmäßige Remotedomäne. Auf der Registerkarte Allgemein ist festgelegt, wie Exchange Abwesenheitsnachrichten verarbeitet. Vor Exchange Server 2007 wurden von Clients erstellte Abwesenheitsnachrichten durch das Transportsystem an jeden beliebigen Empfängertyp geleitet. In Exchange Server 2007 wurde jedoch die neue Möglichkeit eingeführt, die Informationen in diesen Nachrichten zu unterscheiden, sodass die Benutzer eine Nachricht für externe und eine für interne Empfänger erstellen können (ein interner Empfänger ist eine SMTP-Adresse in einer akzeptierten Domäne). Dahinter steckt die Überlegung, dass interne Empfänger einen umfassenderen Hinweis erhalten können, der auch vertrauliche und nicht für externe Empfänger bestimmte Einzelheiten enthalten mag. Wenn ich auf Reisen bin, gebe ich z.B. die Kontaktdaten von Personen an, die in meiner Abwesenheit Fragen beantworten können. Die Abwesenheitsnachricht für externe Korrespondenzpartner besagt dagegen nur, dass ich nicht im Büro bin und alle zwischenzeitlich angefallenen E-Mails erst nach meiner Rückkehr bearbeiten kann.
854
Remotedomänen
Das Exchange-Transportsystem
Abbildg. 13.27 Die Eigenschaften der standardmäßigen Remotedomäne
Die Standardeinstellung lautet Nur externe Abwesenheitsnachrichten zulassen, was bedeutet, dass das Transportsystem nur externe Abwesenheitsnachrichten von Clients mit Outlook 2007 oder höher an externe Empfänger überträgt. Outlook 2003 unterscheidet bei Abwesenheitsnachrichten nicht zwischen externen und internen Empfängern, sodass Sie eine der beiden Optionen für ältere Clients auswählen müssen, wenn Sie solche Clients verwenden möchten. Wenn Sie der Remotedomäne vertrauen, da sie zu einem verschwisterten Unternehmen oder einer anderen Organisation gehört, der sie auch interne Informationen anvertrauen möchten, können Sie die letzte Option wählen, die dem Transportsystem erlaubt, interne Abwesenheitsnachrichten von neuen Clients sowie die allgemeinen Abwesenheitsnachrichten älterer Clients zu übertragen. Die Einstellungen auf der Registerkarte Nachrichtenformat legen das Format der Nachrichten fest, die Exchange an die Remotedomäne übergibt. Nachrichten werden durch Benutzer erstellt, automatisch durch Exchange generiert oder von E-Mail-Programmen als Antwort auf eingehende Nachrichten angelegt. Die Standardeinstellungen unterdrücken die automatisch von Clients erstellten Antworten, erlauben Exchange aber, Zustellungs- und Unzustellbarkeitsberichte zu senden und den Namen des Absenders in den Nachrichtenheader einzufügen. Bei den standardmäßigen Nachrichtenformateinstellungen können die Benutzer im Client festlegen, ob sie einfache Text-, Rich-Text- oder HTMLNachrichten senden möchten. Außerdem können Sie ein Standardformat für Nachrichten an E-Mailaktivierte Kontakte festlegen, falls Sie diesen Empfängertyp verwenden. Die meisten heute gebräuchlichen Clients können mit sämtlichen Nachrichtenformaten umgehen, die Exchange sendet, weshalb es gefahrlos möglich ist, die Clients das bevorzugte Format auswählen zu lassen. Wenn nötig, können Sie Exchange dazu zwingen, einfache Textnachrichten zu senden, indem Sie unter Exchange-RichText-Format die Option Nie verwenden aktivieren und eine Position für den Zeilenumbruch festlegen, um Zeilen fester Länge hervorzurufen. Diese Option kann Werte bis zu 132 annehmen, der übliche Standard für Nachrichten beträgt jedoch 78. In diesem Fall können Sie auch das Cmdlet SetRemoteDomain verwenden, um eine Remotedomäne so einzurichten, dass Exchange nur einfache Textnachrichten sendet: Set-RemoteDomain –Identity 'Gmail' –ContentType 'MimeText' –LineWrapSize 78 –TNEFEnabled $False
855
Kapitel 13
Das Exchange-Transportsystem
Mit Set-RemoteDomain können Sie auch festlegen, ob Exchange Benachrichtigungen für die Besprechungsplanung erstellt, wenn Benutzer Besprechungsanforderungen an Benutzer in der Remotedomäne weiterleiten. Standardmäßig werden solche Benachrichtigungen erstellt, aber dies können Sie abschalten. Der folgende Befehl unterdrückt beispielsweise solche Benachrichtigungen, wenn Besprechungsanforderungen an Gmail-Empfänger weitergeleitet werden: Set-RemoteDomain –Identity 'Gmail' –MeetingForwardNotificationEnabled $False
Die Transportpipeline Mit dem Cmdlet Get-TransportPipeline können Sie einen Einblick in die Transport-Agents gewinnen, die seit dem letzten Start des Transportdienstes eingesetzt wurden. Es lässt sich jedoch nur auf Servern ausführen, auf denen die Hub- oder Edge-Transport-Rolle installiert ist. Jeder Agent wird zusammen mit den Ereignissen angezeigt, für die er registriert ist. Agents können mit Verbindungs-, Kategoriesierungs- und SMTP-Empfangsereignissen verknüpft werden. Verbindungsereignisse treten auf, wenn Zustellungs-Agents wie der Speichertreiber eine Nachricht übermitteln oder annehmen. Wird eine Nachricht untersucht, um den besten Routingpfad zu bestimmen und die genaue Empfängerliste zu bestimmen, ruft dies ein Kategorisierungsereignis hervor. Wenn Remoteserver Verbindungen herstellen, um SMTP-Nachrichten an einen Hub-Transport-Server zu senden, oder wenn ein Hub-Transport-Server einen SMTP-Befehl an einen anderen Server schickt, haben wir es mit einem SMTP-Ereignis zu tun. Die insgesamt verfügbaren Ereignisse bieten Ihnen sehr viele Möglichkeiten, um festzulegen, wie und wo ein Agent in den Nachrichtenstream eingreifen soll. Weitere Informationen
Genauere Hinweise zur Entwicklung von Transport-Agents finden Sie in TechNet. Das folgende Listing zeigt eine typische Ausgabe auf einem Transportserver. Ein Beispiel für die Bindung zwischen Ereignis und Agent können Sie beim Transportregel-Agent erkennen, der durch das Ereignis OnRoutedMessage aufgerufen wird. Get-TransportPipeline
856
Event
TransportAgents
-----
---------------
OnConnectEvent
{}
OnHeloCommand
{}
OnEhloCommand
{}
OnAuthCommand
{}
OnEndOfAuthentication
{}
OnMailCommand
{}
OnRcptCommand
{}
OnDataCommand
{}
OnEndOfHeaders
{}
OnEndOfData
{}
OnHelpCommand
{}
OnNoopCommand
{}
OnReject
{}
OnRsetCommand
{}
OnDisconnectEvent
{}
OnSubmittedMessage
{Text Messaging Routing Agent}
OnResolvedMessage
{}
OnRoutedMessage
{Transport Rule Agent}
OnCategorizedMessage
{}
Das Exchange-Transportsystem
Die Transportpipeline
Tabelle 13.8 führt die Standard-Agents auf, die Sie auf Hub- und Edge-Transport-Servern verwenden können. Softwareprodukte wie Antivirus- und Antispamprogramme können weitere Agents installieren. Da Agents Vollzugriff auf den Nachrichtenstream haben, müssen Sie sie selbstverständlich gründlich testen und validieren, bevor Sie sie in einer Produktionseingebung einführen. Tabelle 13.8
Agents auf Hub- und Edge-Transport-Servern Hub-Transport-Agents
Edge-Transport-Agents
Transportregel-Agent
Verbindungsfilter-Agent
RMS-Verschlüsselungs-Agent (Right Management Service)
Adressumschreibungs-Agent für eingehende Nachrichten
RMS-Entschlüsselungs-Agent
Edge-Regel-Agent
RMS-Vorlizenzierungs-Agent
Inhaltsfilter-Agent
Journal-Agent
Absender-ID-Agent
Entschlüsselungs-Agent für Journalberichte
Absenderfilter-Agent
Routing-Agent für Textnachrichten
Empfängerfilter-Agent Protokollanalyse-Agent Anhangsfilter-Agent Adressumschreibungs-Agent für ausgehende Nachrichten
Wozu diese Standard-Agents im Einzelnen dienen, können Sie aus ihren Namen ablesen. Die meisten Agents für Edge-Transport-Server sind dazu da, eingehende Nachrichten zu filtern und zu bereinigen. Inhalt, Anhänge, Empfänger und Absender werden überprüft, um dafür zu sorgen, dass unerwünschte Inhalte Exchange nicht erreichen. Auch die Verbindungen werden untersucht, sodass Exchange eingehende Nachrichten nur von solchen externen Servern empfängt, die nicht auf einer Sperrliste stehen. Außerdem können an dieser Stelle Adressen umgeschrieben werden. Alles in allem handelt es sich hierbei um Agents, die im Nachrichtenstream aufräumen und ihn optimieren. Die Agents auf Hub-Transport-Servern dagegen bieten gewöhnlich einen echten Zusatznutzen. Mit Transportregeln können Sie ein breites Spektrum an Aufgaben erfüllen, vom Anhängen einer Haftungsausschlussklaussel bis zum stillschweigenden Kopieren aller Nachrichten, die bestimmten Kriterien genügen. Mithilfe der RMS-Agents können Sie die Nachrichten schützen, die das Transportsystem durchlaufen. Der Journal-Agent sorgt dafür, dass alle Nachrichten, die aufbewahrt werden müssen, kopiert werden, während sich der Entschlüsselungs-Agent für Journalberichte um die verschlüsselten Nachrichten kümmert, die ins Journal aufgenommen werden müssen.
857
Kapitel 13
Das Exchange-Transportsystem
Fremd- und Zustellungsconnectors Die Nachrichtenkommunikation via Exchange Server 2010 wird zum größten Teil mithilfe von SMTP durchgeführt. Allerdings ist SMTP nicht das einzige gebräuchliche Messagingprotokoll, weshalb Exchange auch in der Lage sein muss, mit Systemen zu kommunizieren, die nicht SMTP einsetzen. Die wachsende Annahme von SMTP als De-facto-Standard für die E-Mail-Übertragung und das Aufkommen von Internetstandards wie iCal ermöglichen es, dass E-Mail-Systeme heutzutage schon gleich im Lieferzustand eine viel bessere Anbindung untereinander mitbringen und dass es nicht mehr nötig ist, viele maßgeschneiderte Gateways zu betreiben. Sollte trotzdem noch einmal das Bedürfnis nach so etwas bestehen, kann es durch einen Fremd- oder Zustellungsconnector erfüllt werden. Fremdconnectors sind der Ansatz, mit dem in Vorversionen für eine Verbindung zwischen Exchange und anderen Messagingsystemen gesorgt wurde. Erstellt werden sie mit dem Exchange Server 2003 Development Kit (EDK). Früher hatte Microsoft Fremdconnectors für E-Mail-Systeme wie Lotus Notes und Novell GroupWise bereitgetellt, während Drittanbieter Connectors für Fax, SMS usw. entwickelt haben. Auch der auf dem Protokoll X.400 beruhende Routinggruppenconnector, der zur Verbindung zwischen Exchange Server 2010 und Exchange Server 2003 dient, gilt als Fremdconnector. Wie in diesem Kapitel bereits erwähnt, können mit dem Exchange Server 2003 EDK erstellte Gateways und Connectors in Exchange Server 2007 und 2010 nicht mehr verwendet werden. Das zeigt sich vor allem bei der Migration von Lotus Notes oder Novell GroupWise, da Sie einen Server mit Exchange Server 2003 SP2 in der Organisation behalten müssen, solange Sie diese Connectors verwenden möchten. Es wäre jedoch besser, die Verbindung zwischen Exchange und Lotus Notes bzw. GroupWise (oder einem anderen fremden Messagingsystem, das SMTP verarbeiten kann) über SMTP herzustellen. Wenn Sie mit mehreren Messagingsystemen umgehen müssen, ist die grundlegende E-Mail-Funktion nur ein Teil des Gesamtbildes. Es ist ziemlich einfach, Nachrichten zwischen verschiedenen Systemen hin- und her zu schicken, aber die anspruchsvolleren Funktionen wie die Verzeichnissynchronisation und die Verarbeitung von Nachrichten mit Besprechungsanforderungen erfordern mehr Aufwand. Als neue Möglichkeit für die Anbindung an Nicht-SMTP-Systeme enthält Exchange Server 2010 jetzt Zustellungsconnectors. Beide Arten von Connectors führen eine beidseitige Formatumwandlung durch, um von Exchange erstellte Inhalte mit dem Zielsystem kompatibel zu machen. Der Unterschied zwischen Fremd- und Zustellungsconnectors
Zwischen Fremd- und Zustellungsconnectors bestehen die folgenden großen Unterschiede: 쐍 Bei Fremdconnectors werden Nachrichten ins Pickup-Verzeichnis gestellt, während Zustellungsconnectors in der Lage sind, auf die Nachrichten in den Warteschlangen von Hub-Transport-Servern zuzugreifen. Die Leistung der Zustellungsconnectors ist daher gewöhnlich besser, da der Zusatzaufwand zum Verschieben der Dateien in und aus dem Pickup-Verzeichnis entfällt. Nachrichten für Zustellungsconnectors erscheinen in den Transportwarteschlangen. 쐍 Fremdconnectors bestätigen den Empfäng und die Übertragung von Nachrichten nicht. Bei Zustellungsconnectors dagegen erfolgt eine Bestätigung, was bedeutet, dass Sie die Wartezeit für die Zustellung messen und diese Daten für die Vereinbarungen in Serviceverträgen heranziehen können.
858
Exchange Server 2010 wird mit einem Zustellungsconnector ausgeliefert, den Sie sich mithilfe des Cmdlets Get-DeliveryAgentConnector ansehen können: Get-DeliveryAgentConnector Name
AddressSpaces
DeliveryProtocol
Enabled
-----
-------------
----------------
-------
Text Messaging Deliver.
{MOBILE:*;1}
MOBILE
True
Der Text Messaging Delivery Connector ist zur Handhabung aller Nachrichten registriert, die an den Adressraum MOBILE gesendet werden, und kümmert sich daher um Textnachrichten an mobile Geräte. In der Transportpipeline ist auch ein Routing-Agent für Textnachrichten registriert, um solche Nachrichten an diesen Connector weiterzuleiten.
Schattenredundanz In Exchange Server 2007 wurde der Transportpapierkorb als eine Möglichkeit eingeführt, um Kopien von Nachrichten für den Fall aufzubewahren, dass nach dem Ausfall eines Postfachservers in einem Cluster eine Wiederherstellung erforderlich ist. So standen die Kopien zur Verfügung, um Nachrichten, die sich während des Ausfalls gerade in der Übertragung befanden, erneut einspielen zu können. Die Implementierung funktionierte, aber im Praxiseinsatz zeigten sich eine Reihe von Problemen. Exchange Server 2007 unterhält in jeder Speichergruppe einen Transportpapierkorb. Auf kleinen Servern mit nur ein oder zwei Speichergruppen ist das nicht weiter schlimm, aber auf großen Servern wird dadurch alles ziemlich kompliziert, und auch die Belastung steigt. Das gilt vor allem für Server, die sich dem Exchange Server 2007-Höchstwert von 50 Speichergruppen annähern. Unter solchen Umständen ruft ein Failover eine gewaltige E/A-Spitze hervor, da die Hub-Transport-Server im Standort auf den Cache des Transportpapierkorbs zugreifen, um alle wartenden Nachrichten erneut an den Informationsspeicher zu übertragen. Anschließend muss der Informationsspeicher die Nachrichten aussortieren und verwerfen, die bereits erfolgreich zugestellt werden, und diejenigen bestimmen, die noch ausgeliefert werden müssen. Diese Aktivität ruft gewöhnlich eine Spitze bei den E/AAnforderungen auf den Servern hervor und beeinträchtigt die allgemeine Serverleistung, bis der Cache geleert ist und der Informationsspeicher alle ausstehenden Nachrichten zugestellt hat. Exchange Server 2010 verwendet weiterhin den Transportpapierkorb, ergänzt ihn aber um die neue Funktion der Schattenredundanz. Damit soll die Widerstandskraft von Exchange gegen Ausfälle im Transportsystem gestärkt und die Hochverfügbarkeit, die schon in anderen Teilen des Produkts erreicht ist, erweitert werden. Der Transportpapierkorb bietet Redundanz für Nachrichten nach einem Failover, während die Schattenredundanz diese Möglichkeit auf Nachrichten ausdehnt, die sich gerade irgendwo in der Organisation in der Übertragung befanden. Anders als der Transportpapierkorb ist die Schattenredundanz nicht vom Vorhandensein eines Serverclusters abhängig, sondern funktioniert auch dann, wenn Sie nur einfache Postfachserver bereitstellen und keine Datenbankverfügbarkeitsgruppen nutzen. Unter dem Strich gewinnt das Transportsystem von Exchange dadurch die Möglichkeit eines »fast zustandslosen Betriebs«, was die Wiederherstellung von Nachrichten nach einem Ausfall angeht. Die Schattenredundanz ergänzt die anderen Hochverfügbarkeitsfunktionen von Exchange, z.B. die Datenbankreplikation, bei denen es darum geht, Datenbanken, Festplatten und Server als mögliche neuralgische Fehlerquellen auszuschließen. Das Hauptziel der Schattenredundanz besteht darin, dafür zu sorgen, dass jetzt auch ein Ausfall der Transportserver, durch die die SMTP-Nachrichten in 859
Das Exchange-Transportsystem
Schattenredundanz
Kapitel 13
Das Exchange-Transportsystem
die Messaginginfrastruktur hinein- und aus ihr hinausgelangen, keine fatalen Fehler nach sich zieht. Solange es in einer Organisation mehrere Routingpfade gibt, ist es dank der Schattenredundanz möglich, einen Edge- oder Hub-Transport-Server zu entfernen (oder durch einen Ausfall zu verlieren), ohne dass Nachrichten verloren gehen. Das bedeutet auch, dass Sie einen Transportserver offline schalten können, um eine Softwareaktualisierung oder andere Wartungsarbeiten durchzuführen, ohne sich Sorgen über die Nachrichten in den Warteschlangen dieses Servers machen zu müssen. Außerdem verliert dadurch die Hardwareredundanz für Hub-Transport-Server an Bedeutung, sodass Sie Server mit billigerem Speicherplatz bereitstellen können, denn wenn ein Server ausfällt, können Sie ihn so lange offline belassen, wie es nötig ist, um das Problem zu lösen, ohne dass Sie Nachrichten verlieren. Das alles gilt natürlich nur dann, wenn es mehrere Hub-Transport-Server in der Organisation gibt. Wenn Sie nur einen oder zwei haben, sind dies entscheidende Bausteine der Messaginginfrastruktur, die Sie gut schützen müssen. Die Schattenredundanz stützt sich auf die drei folgenden grundlegenden Prinzipien: 1. Wenn ein Benutzer eine Nachricht von einem Postfachserver mit Exchange Server 2010 sendet,
bewahrt der Mailübertragungsdienst eine Hashkopie der Nachricht im Ordner Gesendete Objekte auf. Die Nachricht verbleibt dort, bis der Hub-Transport-Server sie annimmt und in seine Transportdatenbank aufnimmt. Der jeweilige Hub-Transport-Server, der eine Nachricht gerade verarbeitet, wird der primäre Server genannt. Geht bei einem Ausfall irgendwo auf dem Weg eine Nachricht verloren, kann Exchange die Kopie aus der Transportdatenbank des primären Servers erneut übertragen und zum Zielort leiten. 2. Hub- und Edge-Transport-Server tauschen Informationen über den Fortschritt der Nachrichten aus, bis diese schließlich in einem Postfach der Organisation zugetellt oder über einen Connector an ein anderes Messagingsystem weitergeleitet werden. 3. Wenn der primäre Server sicher ist, dass eine Nachricht erfolgreich zugestellt wurde, erstellt er Ereignisse zum Entfernen von Nachrichten, um die anderen Server darüber zu informieren, dass sie ihre Kopien der Nachricht löschen können. Bei der SMTP-Kommunikation untereinander geben die Hub-Transport-Server Taktsignale, um anzuzeigen, dass sie verfügbar sind. Wenn ein primärer Server unerreichbar wird, was daran zu erkennen ist, dass in einem festgelegten Zeitraum keine Taktsignale mehr von ihm ausgehen, kann Exchange seine Rolle auf einen anderen HubTransport-Server übertragen (der über eine Kopie der Nachricht verfügt). Dieser Server überträgt die Nachricht dann erneut, wobei er auf die Kopie in seiner Schattenwarteschlange zurückgreift. Die Schattenredundanzfunktion wird auf Edge- und Hub-Transport-Servern ausgeführt. Dabei werden Kopien der Nachrichten (so genannte Schattenkopien) in eine besondere Warteschlange gestellt, bis die ursprüngliche Nachricht an alle nachfolgenden Hops auf dem Messagingpfad ausgeliefert wurde. Grundsätzlich löschen Server eine Nachricht erst dann aus ihrer Transportdatenbank, wenn Sie von allen empfangenden Servern eine Bestätigung erhalten, dass die Nachricht erfolgreich angekommen ist (diese Bestätigung erfolgt in Form einer Benachrichtigung zum Entfernen der Kopien). Sobald ein Server eine solche Bestätigung von allen Hops auf dem Pfad erhalten hat, kann er die Schattenkopie der Nachricht aus seiner Transportdatenbank entfernen. Kommt von einem der Hops keine solche Benachrichtigung stellt der Transportdienst die Nachricht zur erneuten Zustellung in die Warteschlange. Die Schattenredundanz wird organisationsweit konfiguriert. Dazu richten Sie die Eigenschaft ShadowRedundancy mit dem Cmdlet Set-TransportConfig wie folgt ein: Set-TransportConfig –ShadowRedundancy $True
860
Insidertipp: Benachrichtigungen zum Entfernen von Nachrichten
Die Benachrichtigungen zum Entfernen von Nachrichten haben nur eine geringe Auswirkung auf die Bandbreite, da es sich um sehr einfache SMTP-Transaktionen zwischen Servern handelt. Sie können sie sich etwa wie folgt vorstellen: »Server X: Ich habe die Nachricht mit der ID 136146 erhalten.« Server tauschen die Daten solcher Benachrichtigungen während der SMTP-Verbindung aus. Ein Server kann aber auch eine eigene Verbindung zu einem anderen Server herstellen, um Daten über die Nachrichten abzurufen, die er zuvor gesendet hat, und zu entscheiden, ob er seine Kopie verwerfen kann. Der Standardwert lautet $True. Exchange Server-Computer fügen daher den ESMTP-Befehl XSHADOW in ihre Kommunikation mit anderen SMTP-Servern ein, um herauszufinden, ob diese Server die Schattenredundanz unterstützen und um den Takt bereitzustellen, an dem die Verfügbarkeit des Servers abzulesen ist. Auch die Benachrichtigungen zum Entfernen von Nachrichten werden durch eine SMTP-Erweiterung realisiert, nämlich XQDISCARD. In Exchange wird zwischen primären und Schattenkopien einer Nachricht sowie zwischen primären und Schattenservern unterschieden. Die primäre Nachricht ist diejenige, die zwischen der Ursprungsserver und einem anderen Transportserver übertragen wird, die Schattenkopie ist diejenige, die aufbewahrt wird, bis der Transportdienst Gewissheit darüber hat, dass die primäre Nachricht überfall dort ausgeliefert wurde, wohin sie zugestellt werden sollte. Der primäre Server ist derjenige, der die Nachricht zurzeit verarbeitet, während es sich bei den Schattenservern um diejenigen handelt, die die Nachricht schon verarbeitet haben und auf die Benachrichtigung warten, dass sie ihre Schattenkopie verwerfen dürfen. HINWEIS Das offensichtliche Anzeichen dafür, dass auf eine Benachrichtigung zum Entfernen für eine Nachricht gewartet wird, besteht darin, dass die entsprechende Nachricht in der Schattenredundanz-Warteschlange auf einem Hub-Transport-Server vorhanden ist. Die Nachrichten verbleiben dort, bis Exchange sicher ist, dass sie erfolgreich übertragen wurden. Die Funktionsweise der Schattenredundanz kann mit zwei weiteren Einstellungen der Transportkonfiguration gesteuert werden: Set-TransportConfig –ShadowHeartbeatRetryCount 8 –ShadowHeartbeatTimeoutInterval 00:10:00 –ShadowMessageAutoDiscardInterval 3.00:00:00
Der erste Parameter in diesem Befehl setzt den Zähler für Wiederholungsversuche auf acht (der Standardwert beträgt drei), was bedeutet, dass Hub-Transport-Server bis zu acht Mal versuchen, Kontakt aufzunehmen, bevor sie zu dem Schluss kommen, dass ein Server unerreichbar ist. Ein solcher unerreichbarer Server kann nicht mehr als primärer Server dienen. Der nächste Parameter gibt an, wie lange ein Hub-Transport-Server wartet, bevor er versucht, einen anderen Server erneut anzusprechen, um herauszufinden, ob er erreichbar ist. Der Standardwert beträgt fünf Minuten. Durch eine Erhöhung des Wiederholungszählers und der Wartezeit wie in diesem Beispiel können Sie die Schattenredundanzfunktion an ausgedehnte Verbindungen zwischen den Hub-Transport-Servern anpassen, damit diese mit Netzwerkausfällen von bis zu 80 Minuten fertig werden können (acht Wiederholungsversuche in zehnminütigem Abstand). Mit dem letzten Parameter in dem Beispielbefehl wird der Zeitraum zum Verwerfen von Nachrichten von zwei auf drei Tage angehoben. Dieser Wert bestimmt, wie lange Server die Schattenkopien in ihrer Warteschlange höchstens aufbewahren, bevor sie automatisch gelöscht werden.
861
Das Exchange-Transportsystem
Schattenredundanz
Kapitel 13
Das Exchange-Transportsystem
Shadow Redundancy Manager: Die Lösung für Server, die keine Schattenredundanz unterstützen
Eine neue Komponente im Transportdienst, der Shadow Redundancy Manager (SRM), überwacht den Fluss der Nachrichten, ihren aktuellen Zustellungsstatus und die Abstimmung der Benachrichtigungen zum Entfernen von Schattenkopien, die von anderen Transportservern als Bestätigung der erfolgreichen Auslieferung zurückkommen. SRM kann auch Übertragungen an Server handhaben, die keine Schattenredundanzfunktion kennen und daher nicht in der Lage sind, beim Eintreffen von Nachrichten Bestätigungen an Exchange zurückzusenden. In solchen Fällen wird der erfolgreiche Aufbau der SMTP-Verbindung und die erfolgreiche Übertragung als ausreichendes Indiz dafür erachtet, dass die Nachricht den nächsten Hop erreicht hat. SRM tut so, als sei von dem anderen E-Mail-Server eine Bestätigung eingetroffen. Exchange versucht das Prinzip der Schattenredundanz auch auf eingehende Nachrichten anzuwenden, und zwar selbst dann, wenn sie von Servern kommen, die diese Funktion nicht aufweisen. In diesen Fällen nimmt Exchange die Nachricht entgegen, überträgt sie weiter und erstellt dabei eine Schattenkopie. Außerdem verzögert Exchange die Bestätigung an den Ursprungsserver, bis die Nachricht an alle Hops in der Organisation ausgeliefert ist. In einer Organisation mit einer komplizierten Routingtopologie und in Situationen, in denen manche Connectors nicht unmittelbar verfügbar sind, kann es einige Zeit dauern, bis eine Nachricht an alle Hops zugestellt ist. Um zu verhindern, dass die SMTP-Verbindung zu dem anderen Server wegen Zeitüberschreitung abgebrochen wird, was zu einer erneuten Übertragung der Nachricht führen würde, legt Exchange einen Höchstwert für die Wartezeit auf die vollständige Verarbeitung der Nachricht fest. Der Standardwert beträgt 30 Sekunden, kann aber in der Eigenschaft MaxAcknowledgementDelay des Empfangsconnectors geändert werden. Nach Ablauf dieses Zeitraums sendet Exchange eine Bestätigung an den Ursprungsserver. Das kann dazu führen, dass Nachrichten verloren gehen, wenn ein Hub-Transport-Server ausfällt und seine Transportdatenbank einbüßt, doch in der Praxis ist dies nicht sehr wahrscheinlich.
Verknüpfen von Exchange Server 2003 mit Exchange Server 2010 Bei einer Migration müssen Sie entscheiden, wie Sie Servercomputer mit Exchange Server 2010 an die vorhandene Routinginfrastruktur anschließen. Die Verbindung zwischen Exchange Server 2003 und 2010 ist in TechNet und anderen Büchern gut und ausführlich dokumentiert und unterscheidet sich auch kaum von der Situation unter Exchange Server 2007. Kurz gesagt, die verborgenen Routinggruppen, in denen Exchange Server 2010 installiert wird, werden den Servern mit Exchange Server 2003 über Routinggruppenconnectors zugänglich gemacht, die die SMTP-Messagingtopologie von Exchange Server 2010 und 2007 mit dem Ansatz der früheren Versionen auf der Grundlage eines X.400-Nachrichtenübertragungs-Agents (Message Transfer Agent, MTA) verknüpft. Die einfachste und beste Vorgehensweise besteht darin, den Connector in einer Hub-Routinggruppe von Exchange Server 2003 unterzubringen. Denken Sie daran, dass dies der Connector für den Nachrichtenaustausch zwischen Exchange Server 2010 und 2003 ist und dass daher während der Migration eine Menge Datenverkehr über ihn fließen wird. Der Connector muss daher in der Lage sein, die Last zu verkraften, und die Server in der Routinggruppe müssen über solide, zuverlässige und schnelle Netzwerkverbindungen mit dem Rest der Exchange Server 2003-Organisation verfügen. Eine nicht optimale Routinggruppe auszuwählen ist zwar keine Katastrophe – zumindest keine unmittelbare –, 862
kann aber zu Schwierigkeiten führen, wenn Sie die Nachrichtenlast über den Connector erhöhen, während mehr und mehr Benutzer zu Exchange Server 2010 übergehen. Nehmen wir beispielsweise an, dass Sie den ersten Hub-Transport-Server mit einer Routinggruppe verbinden, die nicht zum Kernnetzwerk gehört, vielleicht sogar mit einer kleinen Routinggruppe, die zu einer Netzwerkspeiche gehört. Es wird alles gut gehen, solange nur wenige Benutzer Nachrichten von Exchange Server 2010 senden, aber sobald dieser Datenverkehr zunimmt, ist es nicht mehr akzeptabel, alle Nachrichten von Exchange Server 2010 in eine Netzwerkspeiche zu zwingen und von dort aus zur Zustellung an andere Routinggruppen wieder zurückzuleiten. Auch für Exchange Server 2010 ist es wichtig, dass der HubTransport-Server am anderen Ende des Routinggruppenconnectors mit dem Datenverkehr fertig werden kann, weshalb Sie diesen Server in einem Kernstandort des Netzwerks installieren sollten. Mit dem Cmdlet New-RoutingGroupConnector können Sie wie folgt eine bidirektionale Anbindung zwischen Exchange Server 2010 und 2003 erstellen: New-RoutingGroupConnector –Name "RGC Exchange 2010 <-> Legacy" –SourceTransportServers "ExServer1", "ExServer2" –TargetTransportServers "E2003Svr1" –Cost 50 –Bidirectional $True
Dieser Befehl erstellt einen neuen Routinggruppenconnector, der zwei Hub-Transport-Server mit Exchange Server 2010 (ExServer1 und ExServer2) mit dem Exchange Server 2003-Bridgeheadserver namens E2003Svr verbindet. Durch den Wert $True für den Parameter -Bidirectional weisen Sie Exchange an, die erforderlichen Connectors auf beiden Seiten zu erstellen. Anschließend können Sie die Eigenschaften dieses Connectors mit Get-RoutingGroupConnector überprüfen. Im Folgenden finden Sie eine bearbeitete Fassung der Ausgabe: Get-RoutingGroupConnector –Identity "RGC Exchange 2010 <-> Legacy" | Format-List TargetRoutingGroup
: RG-InterOp
Cost
: 50
TargetTransportServers
: {E2003Svr1}
ExchangeLegacyDN
: /o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Connections/ cn=RGC Exchange 2010 <-> Legacy
PublicFolderReferralsEnabled : True SourceRoutingGroup
: Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers
: {ExServer1, ExServer2}
Name
: RGC Exchange 2010 <-> Legacy
Identity
: RGC Exchange 2010 <-> Legacy
Im Gegensatz zu den Standardkosten, die einem neuen Routinggruppenconnector gewöhnlich zugewiesen werden, sind die Kosten für diesen Connector zwischen Exchange Server 2003 und 2010 sinnvollerweise auf 50 hochgesetzt worden, denn schließlich wollen Sie ihn nicht als übliche Backboneverbindung einsetzen. Es ist immer am besten, Nachrichten soweit wie möglich innerhalb ihrer angestammten Umgebung zu belassen. Exchange Server 2003-Computer sollten Nachrichten nur dann an Exchange Server 2010 weiterleiten, wenn deren endgültiger Bestimmungsort auf einem Exchange Server 2010-Computer liegt. Irgendwann ist natürlich der Zeitpunkt gekommen, an dem Exchange Server 2010 den Großteil des Routings übernimmt oder wenn Sie entscheiden, Exchange Server 2010 zum Backbone-E-Mail-Router für die Organisation zu machen. In diesem Fall können Sie die Connectorkosten verringern, damit Exchange Server 2003-Computer häufiger Nachrichten über diesen Connector übertragen können. 863
Das Exchange-Transportsystem
Verknüpfen von Exchange Server 2003 mit Exchange Server 2010
Kapitel 13
Das Exchange-Transportsystem
Außerbetriebsetzen von Exchange Server 2003Routinggruppen Schließlich erreichen Sie bei einer Migration den Punkt, an dem Sie die Exchange Server 2003-Computer und die von ihnen genutzten Routinggruppenconnectors aus Ihrer Organisation entfernen. Hier wartet eine neue Herausforderung auf Sie: Sie müssen die Server so außer Betrieb setzen, dass keine Inseln der Verbindungsstatusreplikation zurückbleiben. Wenn Sie die Connectors zwischen den Exchange Server 2003-Routinggruppen entfernen und die verbliebenen Exchange Server 2003Computer zwingen, Nachrichten über Exchange Server 2010 zu senden, können die Nachrichten weiterhin fließen. Allerdings können Exchange Server 2003-Computer keine Verbindungsstatusaktualisierungen mehr untereinander austauschen, da diese Nachrichten von Exchange Server 2010 verworfen werden. Damit wird für die Exchange Server 2003-Server das Bild der Routingtopologie eingefroren, sodass sie Änderungen, die irgendwo in der Organisation stattfinden, gar nicht mehr mitbekommen. Wenn Sie die Server schnell außer Betrieb nehmen und nicht erwarten, dass sie Ihnen noch lange erhalten bleiben, ist das kein Beinbruch, aber in den meisten Fällen (vor allem in großen Organisationen) können Sie nicht schnell genug auf Exchange Server 2010 umschalten, um ein ineffizientes Routing von Nachrichten zu verhindern (oder die Nachrichten praktisch in ein schwarzes Loch zu schicken, da Exchange nicht mehr herausfinden kann, wohin sie gesendet werden sollen). Aus diesem Grund müssen Sie jedes Mal, wenn Sie einen Routinggruppenconnector entfernen, dafür sorgen, dass die verbliebenen Exchange Server 2003-Computer einen alternativen Connector zur Verfügung haben, den sie für den Empfang von Verbindungsstatusaktualisierungen nutzen können.
Handhaben der Verbindungsstatusaktualisierungen von Exchange Server 2003 In einer reinen Exchange Server 2010-Organisation brauchen Sie sich um Verbindungsstatusaktualisierungen nicht zu kümmern, allerdings müssen Sie bei einer Migration von Exchange Server 2003 aus darauf achten. Verbindungsstatusaktualisierungen wurden in Exchange Server 2000 eingeführt. Dort sandten sich die Server, die als Routinggruppenmaster in einer Organisation fungierten, Informationen über die Routingtopologie zu, damit sie über Probleme in dieser Topologie Bescheid wussten, z.B. über einen ausgefallenen oder aus anderen Gründen unerreichbaren Connector. Damit konnten sie das Nachrichtenrouting anpassen, um Blockierungen zu vermeiden. Dieses dynamische Routing war die natürliche Weiterentwicklung der statischen Gateway-Routingtabellen (GWART), die in Exchange 5.5 verwendet wurden. Bei einem festgeschriebenen Bild der Routingtopologie besteht die Gefahr, dass die Server Nachrichten an Orte schicken, an denen sie hängen bleiben, bis ein Connector repariert und wieder betriebsbereit gemacht wird. Solange Sie noch über wenigstens einen Routinggruppenconnector zwischen Exchange Server 2003 und Exchange Server 2010 verfügen, müssen Sie sich keine Gedanken über die Verbindungsstatusinformationen machen. Exchange Server 2003 sendet weiterhin Verbindungsstatusaktualisierungen zwischen seinen Routinggruppen, die von Exchange Server 2010 jedoch ignoriert werden. Die beiden Systeme funktionieren unabhängig voneinander und unterhalten jeweils ihre eigene Routingtopologie. Ein einziger Connector reicht für kleine bis mittlere Organisationen aus, doch in großen Organisationen wird die Sache komplizierter, da hier ein großes Aufkommen an Datenverkehr herrscht und die Nachrichten effizient in geografisch getrennte Netzwerksegmente geleitet werden müssen. In
864
einer solchen Situation müssen Sie wahrschienlich weitere Routinggruppenconnectors zwischen den entsprechenden Exchange Server 2003-Computern und den Hub-Transport-Servern mit Exchange Server 2010 einrichten. Möchten Sie die Weiterleitung der Verbindungsstatusinformationen unterbinden, müssen Sie auf allen Bridgeheadservern mit Exchange Server 2003 eine Registrierungsänderung durchführen. Fügen Sie dazu im Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc\Parameters den neuen DWORD-Wert SuppressStateChanges hinzu, setzen Sie den Wert auf 1 und starten Sie das Exchange-Routingmodul, den SMTP-Dienst und den Exchange MTA-Dienst neu. Daraufhin senden die Server zwar weiterhin Verbindungsstatusaktualisierungen zueinander, ignorieren aber alle Connectorausfälle, die zu einer Topologieänderung führen könnten. Dadurch wird Exchange Server 2003 gezwungen, als Grundlage für die Weiterleitung von Nachrichten stets die Route mit den geringsten Kosten heranzuziehen, anstatt alternative Routen zu berechnen. Wenn ein Connector ausfällt, leitet Exchange die Nachricht entweder über einen verfügbaren Connector um oder stellt sie in eine Warteschlange, bis der Connector wieder bereitsteht.
Änderungen in Exchange Server 2010 SP1 Das Transportmodul von Exchange ist ziemlich solide, weshalb es in Exchange Server 2010 SP1 keine grundlegenden Verbesserungen benötigte. Bei Microsoft hat man sich daher darauf konzentriert, das Transportsystem in drei Bereichen zu optimieren: 쐍 SMTP-Lastenausgleich und Failover Es wurde dafür gesorgt, dass Exchange die Verbindungen möglichst wirtschaftlich aufteilt, wenn ein SMTP-Server ausfällt. 쐍 Ressourcenüberwachung für die Übermittlungswarteschlange Es wurde dafür gesorgt, dass ein bereits belasteter Server nicht noch zusätzlich durch weitere Nachrichtenübermittlungen belastet wird. Dies ist eine Variante der Rückstaufunktion, die zuerst in Exchange Server 2007 eingeführt wurde. 쐍 Priorität der Postfachzustellung Es wurde dafür gesorgt, dass der allgemeine Nachrichtenfluss nicht durch das elektronische Äquivalent von Lastwagen auf der Überholspur gebremst wird. In diesem Zusammenhang sind die Lastwagen Nachrichten, für deren Verarbeitung das Transportsystem sehr viele Ressourcen aufwenden muss. Außerdem wurden in SP1 einige Änderungen an der Schattenredundanzfunktion vorgenommen, um die Erfassung und Beibehaltung von Nachrichten zu verbessern, die von Exchange Server-Computern mit Vorversionen oder von Clients stammen, die die von Exchange Server 2010 für die Schattenredundanz verwendeten ESMTP-Verben nicht verstehen.
Besserer SMTP-Lastenausgleich Exchange Server 2007 und 2010 versuchen einen Lastenausgleich für ausgehende SMTP-Verbindungen vorzunehmen, indem sie die Nachrichten über alle verfügbaren Server in der Domäne oder dem Standort des nächsten Hops verteilen. Nehmen wir beispielsweise die beiden Standorte A und B, in denen es jeweils drei Hub-Transport-Server gibt. Die Hub-Transport-Server in Standort A versuchen die Nachrichten, die an Standort B gehen, auf die drei dort vorhandenen Hub-Transport-Server zu verteilen. Das geht so lange gut, bis einer der Server in B ausfällt oder aus irgendeinem Grund, z.B.
865
Das Exchange-Transportsystem
Änderungen in Exchange Server 2010 SP1
Kapitel 13
Das Exchange-Transportsystem
für eine geplante Wartung, offline geschaltet wird. Die Hub-Transport-Server in Standort B glauben immer noch, dass es in Standort B drei Zielserver gibt, und versuchen die Last auf alle drei zu verteilen. Da aber einer dieser Server unerreichbar ist, stellen die Server in A eine fehlgeschlagene Zustellung fest, wenn sie Verbindung damit aufzunehmen versuchen. Die betroffenen Nachrichten werden dann an den nächsten verfügbaren Server in B umgeleitet. Dadurch aber gerät der Lastenausgleich in Standort B ins Ungleichgewicht, denn einer der dortigen Hub-Transport-Server muss seine normale Last zuzüglich der gesamten Last tragen, die sonst zu dem ausgefallenen Partnerserver geht. Die Änderungen, die an SP1 vorgenommen wurden, um den Lastenausgleich beim Auftreten vorübergehender Serverausfälle zu verbessern, sind sehr einfach. Wenn ein Hub-Transport-Server mit SP1 beim Senden von Daten an einen Zielserver einen Verbindungsfehler bemerkt, fügt er dessen FQDN und alle zugehörigen IP-Adressen zur Liste der ausgefallenen Server hinzu. Alle Hub-Transport-Server in Standort A können dann den unerreichbaren Server von ihrer Liste der für den Lastenausgleich verfügbaren Server in Standort B streichen. Fällt in unserem Beispiel also einer der HubTransport-Server in Standort B aus, nehmen die Server in Standort A den Lastenausgleich nur noch über die beiden verbliebenen Ziele in B vor. In den Algorithmus wurde Code zur Unterscheidung dreier verschiedener Arten von Ausfällen eingebaut: 쐍 Kurzfristige Störung: Exchange versucht den ausgefallenen Server viermal im Abstand von einer Minute zu erreichen. Wenn der Server wieder online kommt, stuft Exchange ihn wieder als gültiges Ziel für den Lastenausgleich ein und entfernt ihn von der Liste der ausgefallenen Server. 쐍 Vorübergehender Ausfall: Sind die Störungstests erfolglos verlaufen, geht Exchange zu sechs weiteren Verbindungsversuchen im Abstand von diesmal fünf Minuten über. Dahinter steht die Überlegung, dass das Einspielen einer Softwareaktualisierung oder andere kleinere Wartungsarbeiten an einem Server innerhalb von 30 Minuten abgeschlossen sein sollten. Kommt der Server wieder online, macht Exchange ihn wieder zu einem gültigen Ziel. 쐍 Ausfall: Sind auch die Tests auf einen vorübergehenden Ausfall erfolglos verlaufen, prüft Exchange die Verbindung in zehnminütigen Abständen, bis der Zielserver wieder online kommt oder aus der Exchange-Konfiguration entfernt wird. Die Tests von Microsoft haben gezeigt, dass der neue Code für den Lastenausgleich eine bessere Leistung zeigt als der ursprüngliche Algorithmus. Einzelheiten über die verschiedenen Wiederholungsintervalle und die Liste der ausgefallenen Server können Sie sich mithilfe von Get-ExchangeDiagnosticInfo ansehen. Im folgenden Beispiel sehen wir uns die Informationen vom Server ExServer1 an. Die Ausgabe ist gekürzt, um die wichtigsten Angaben hervorzuheben. Get-ExchangeDiagnosticInfo –Server ExServer1 –Process EdgeTransport –Component SmtpOut Result :
866
Änderungen in Exchange Server 2010 SP1
Das Exchange-Transportsystem
Überwachen der Übermittlungswarteschlange Das Kategorisierungsmodul gibt einen hervorragenden Anhaltspunkt über den Gesamtzustand eines Hub-Transport-Servers. Es leistet viel Arbeit, um die Adressen in den Nachrichten aufzulösen und die beste Route für die Weiterleitung zu bestimmen. Wenn das Kategorisierungsmodul neue Nachrichten sofort nach dem Eintreffen verarbeiten kann, befindet sich der Server in einem guten Zustand und ist nicht überlastet. Leider neigt das Transportsystem von Exchange Server 2010 dazu, sich zu überarbeiten. Wenn das Kategorisierungsmodul deutliche Schwierigkeiten hat, die ihm auferlegte Last zu schultern, nimmt das Transportsystem weiterhin neue Nachrichten an, die dann aber nur sehr langsam aus der Übermittlungswarteschlange in das Kategorisierungsmodul gelangen. Das führt zu einem inakzeptablen Anwachsen der Warteschlange für Nachrichten, die auf ihre Kategorisierung warten. In SP1 wurde daher eine Überwachung der Kategorisierungswarteschlange eingeführt, mit der ermittelt werden kann, wann das Kategorisierungsmodul Schwierigkeiten hat, die Nachfrage zu befriedigen. Eine Warteschlange von weniger als 1000 Nachrichten wird als normal und akzeptabel angesehen, doch wenn sie über diese Größe hinaus wächst, kann sie zwei weitere Schwellenwerte übersteigen, was Maßnahmen zur Verringerung der Nachfrage auf diesem Server auslöst. In diesem Sinne verhält sich die Überwachung dieser Warteschlange wie jede andere Ressourcenüberwachung, die dazu dient, die Nachfrage in Zeiten hoher Last zu drosseln. Allgemein durchläuft eine solche Ressourcenüberwachung folgende drei Schritte: 1. Nachdem der mittlere Schwellenwert überschritten ist, gerät der Server in einen Zustand instabi-
ler Ressourcenbelastung und ruft einen Teergruben-Algorithmus auf, um die weitere Nachfrage zu bremsen, bis der Ressourcenverbrauch wieder unter die normale Grenze sinkt. 2. Bleibt der Ressourcenverbrauch hoch, stabilisiert sich der Server oberhalb des mittleren Schwellenwerts, fängt aber damit an, Aufgaben abzulehnen. Bei der Übermittlungswarteschlange werden Nachrichtenübertragungen von anonymen Clients mit der Fehlermeldung »unzureichende Systemressourcen« abgelehnt. Der Server bleibt in diesem Zustand, bis der Ressourcenverbrauch unter die normale Grenze sinkt.
867
Kapitel 13
Das Exchange-Transportsystem
3. Steigt der Ressourcenverbrauch über den hohen Schwellenwert, werden die Übermittlung von
Nachrichten aus allen Quellen mit der Fehlermeldung »unzureichende Systemressourcen« abgelehnt. Der Server bleibt in diesem Zustand, bis der Ressourcenverbrauch unter die mittlere Grenze sinkt. Die Schwellenwerte sind in der Datei EdgeTransport.config.exe festgelegt:
Die Überwachung misst ständig die Länge der Warteschlange und vergleicht sie anhand von 300 in Zwei-Sekunden-Abständen erfassten Stichproben mit den Schwellenwerten, um festzustellen, ob Maßnahmen erforderlich sind. Dadurch wird sichergestellt, dass eine vorübergehende Spitze der Belastung, die das Kategorisierungsmodul selbst abbauen kann, keine Aktionen auslöst. Wenn der Server aber unter eine anhaltende Belastung gerät und wirklich Hilfe braucht, greift die Überwachung ein. Eine kleine Belastungsspitze, bei der der Server kurzzeitig träger reagiert, fällt niemandem auf, doch wenn ein Server für mehr als nur ein paar Sekunden langsamer wird, erkennen die Benutzer, dass ein Problem vorliegt.
Prioritäten bei der Postfachzustellung Nicht alle Nachrichten sind gleich, und für manche muss Exchange weit mehr Ressourcen zur Weiterleitung an den Bestimmungsort aufwenden als für andere. Eine Nachricht, die an eine sehr große Verteilergruppe mit über 1000 Empfängern geht, kommt in der Kategorisierung teurer zu stehen als eine Nachricht an einen einzigen Empfänger. Auch die Weiterleitung einer Nachricht mit einem Anhang von 10 MB erfordert mehr Aufwand als eine E-Mail, die nur zwei Sätze Text enthält. Das Problem ist, dass die aufwendigen Nachrichten manchmal den Weg für die »normalen« versperren und deren Zustellung verzögern. Dass es einige Sekunden dauern kann, eine umfangreiche Nachricht zuzustellen, wird allgemein akzeptiert, aber warum eine ganz einfache Nachricht lange braucht, um am Zielort anzukommen, ist eher unverständlich. Die in Exchange Server 2010 SP1 eingeführte Lösung besteht darin, den Nachrichten aufgrund der Anzahl der Empfänger und ihres Gesamtumfangs eine Priorität zuzuweisen, nach der die Zustellung erfolgt. Hat eine Nachricht über 500 Empfänger oder ist sie größer als 1 MB und stammt sie von einem Absender, der kürzlich eine Menge ähnlicher Nachrichten übermittelt und damit einen hohen Wert für die letzten Übertragungskosten angesammelt hat, stellt Exchange sie in eine Warteschlange geringer Priorität. Die anderen Nachrichten werden wie üblich verarbeitet, für die Warteschlange geringer Priorität aber gelten die folgenden Regeln: 쐍 Für die Weiterleitung an das Ziel des nächsten Hops wird die FIFO-Reihenfolge beibehalten. Das heißt, kleine Nachrichten, die nach umfangreichen Nachrichten gesendet werden, kommen nicht vor den großen Nachrichten am Ziel an, da dies die Benutzer irritieren könnte. 쐍 Nachrichten in der normalen Warteschlange werden etwa 20 Mal so schnell abgefertigt wie diejenigen in der Warteschlange geringer Priorität. Dieses Verhältnis wurde aufgrund einer Analyse ausgewählt, die gezeigt hat, dass »normale« Nachrichten ungefähr ein Zwanzigstel des Umfangs der Nachrichten in der Warteschlange geringer Priorität aufweisen.
868
쐍 Die Nachrichten in der Warteschlange geringer Priorität werden nicht zurückgehalten. Das Transportsystem kümmert sich um diese Warteschlange und nimmt fortgesetzt Nachrichten aus ihr heraus, auch wenn weiterhin Nachrichten höherer Priorität eintreffen. Die Warteschlange geringer Priorität soll nicht dadurch anwachsen, dass sich ständig Nachrichten höherer Prioritäten vordrängeln. 쐍 Dieses Verhalten gilt nur für MAPI-Zustellungswarteschlangen. Nachrichten, die über SMTP in das Transportsystem gelangen, durchlaufen die gleichen Warteschlangenprozesse wie in Exchange Server 2007 SP1. Tests bei Microsoft haben gezeigt, dass 1% bis 5% aller Nachrichten in die Warteschlange geringer Priorität gelangen, weshalb diese Änderung nicht sehr viele E-Mails betrifft. Allerdings wird dadurch die Auslieferung der Nachrichten reibungsloser gestaltet und die Nutzung der vorhandenen Ressourcen verbessert. Exchange Server 2010 SP1 unterhält nicht nur die neue Warteschlange geringer Priorität, sondern überwacht auch den Zustand der Postfachdatenbanken, damit diese vom Transportsystem nicht mit Unmengen eingehender Nachrichten überschwemmt werden. Eine Postfachdatenbank in gutem Zustand, die in der Lage ist, das aktuelle Nachrichtenaufkommen zu verarbeiten, wird mit dem Zustandsindikator 100 versehen. Zeigen Messungen bei der Zustellung durch den Transportdienst, dass die Postfachdatenbank stärker belastet ist und schlechter reagiert, wird dieser Wert verringert. Dahinter steckt die Überlegung, dass das Transportsytem in der Lage ist festzustellen, dass die Leistung einer Datenbank zurückgeht, und daher die versuchten Zustellungen drosseln kann, sodass die Datenbank weiterhin Nachrichten annehmen kann, ohne davon überlastet zu werden. Die Werte, die die Prioritätssteuerung der Nachrichtenzustellung steuern, sind in der Datei EdgeTransport.config.exe gespeichert. Darüber hinaus erfasst das Transportsystem Informationen über Nachrichten in der Eigenschaft EVENTDATA der DELIVER-Ereignisse, die im Nachrichenverfolgungsprotokoll aufgezeichnet werden. Überprüfen Sie diese Einträge, um zu sehen, welche Nachrichten Exchange in die Warteschlange geringer Priorität stellt. Das folgende Listing zeigt ein Beispiel für diese Daten: EventData : {[MailboxDatabaseName, db3], [DeliveryPriority, Low], [PrioritizationReason, AMS:10274739/1048576,ARC:14/500], [DatabaseHealth, 100]}
Hier können Sie sehen, dass die Nachricht an die Datenbank DB3 zugestellt, aber in der Warteschlange geringer Priorität platziert wurde, da ihre Größe (AMS) von 10.274.739 Byte (9,8 MB) deutlich über dem Maximal von 1.048.576 Byte (1 MB) liegt. Die Anzahl der Empfänger (ARC) beträgt 14 und bleibt damit unter dem Grenzwert von 500.
Verbesserte Schattenredundanz Die Schattenredundanzfunktion dient zum Schutz von Nachrichten, da hierdurch sichergestellt wird, dass sie wiederhergestellt werden können, wenn auf dem Weg bis zu ihrer endgültigen Zustellung ein Fehler auftritt. Diese Funktion stützt sich auf einige neue ESMTP-Verben, die Exchange Server 2010Computer verstehen. Alle Nachrichten zwischen Servern mit dieser Exchange-Version können daher geschützt werden. Exchange-Computer mit älteren Versionen sowie andere Messagingsysteme kennen die ESMTP-Verben jedoch nicht, weshalb ihre Nachrichten nicht denselben Grad an Schutz genießen. Es besteht daher die Gefahr, dass einige dieser Nachrichten verloren gehen, wenn ein schwerer Ausfall eintritt und Server wiederhergestellt werden müssen.
869
Das Exchange-Transportsystem
Änderungen in Exchange Server 2010 SP1
Kapitel 13
Das Exchange-Transportsystem
Um dieses Problem zu vermeiden, versucht das System, Nachrichten von älteren Servern bei ihrer Ankunft auf einem Hub-Transport-Server mit Exchange Server 2010 zunächst an einen anderen Hub-Transport-Server im selben Standort weiterzuleiten. Durch diese einfachen Schritte werden die ESMTP-Befehle aufgerufen, sodass die Nachrichten denselben Schutz genießen, als hätten sie ihren Ursprung auf einem Exchange Server 2010-Computer.
Blitzsaubere E-Mails Die E-Mail-Kommunikation ist nicht sehr hilfreich, wenn sie Viren transportiert und so mit Spam überflutet ist, dass Sie sich durch Hunderte von Angeboten für Medikamente, Gelegenheiten zum Reichwerden und Möglichkeiten zum Kennenlernen von Leuten durchkämpfen müssen, die Ihnen angeblich Geld für gar nichts bieten. In einer an Bedrohungen reichen Welt müssen Exchange-Administratoren Maßnahmen ergreifen, um unerwünschte Inhalte zu entfernen, bevor sie auf die HubTransport-Server gelangen. Unser nächstes Thema ist daher die Nachrichtenhygiene für ExchangeOrganisationen.
870
Nachrichtenhygiene
Kapitel 14
Nachrichtenhygiene
In diesem Kapitel: Edge oder nicht Edge, das ist hier die Frage
873
Edge-Transport-Server
874
Antispam-Agents von Exchange
886
Auswählen eines Antivirusprodukts
922
Clientseitige Schutzvorrichtungen
924
Die Toolbox
930
871
Kapitel 14
Nachrichtenhygiene
Mit »Nachrichtenhygiene« ist die Bereinigung des Nachrichtenstreams von Spam, Viren und anderen verdächtigen Inhalten gemeint. Nach den über Disketten übertragenen Viren kamen die E-Mail-Viren auf und wurden zur ersten großen Bedrohung der Unternehmen, die Microsoft Exchange bereitgestellt hatten. Diese Organisationen erfuhren bei Zwischenfällen wie den berühmten Viren Melissa (1999) und I Love You (2000) eine rapide Infektionsrate. Die wachsende Anzahl von E-Mail-Viren (und der Medienrummel darum) haben die Entwicklung von Antivirenprodukten beschleunigt. Diese Produkte nutzten zu Anfang MAPI, um auf Postfachdatenbanken zuzugreifen und befallene Elemente zu erkennen und zu desinfizieren, und litten darunter, dass MAPI für allgemeine Messagingzwecke entworfen wurde und nicht zur Durchsuchung großer Mengen von eingehenden Nachrichten. Um Abhilfe zu schaffen, schuf Microsoft die Virus Scanning API (VSAPI) für die Verwendung mit Exchange Server 2003. Diese API wird von allen modernen Antivirenprodukten verwendet, die mit Exchange zusammenarbeiten. Da immer mehr Unternehmen und Endverbraucher mit dem Internet verbundene E-Mail-Systeme nutzen, werden sie zu Zielen für Spam – unerwünschte Werbenachrichten –, die sich seit 2000 mit wachsender Geschwindigkeit ausgebreitet haben. Zurzeit nimmt unerwünschte E-Mail einen erheblichen Prozentsatz des gesamten im Internet zirkulierenden Nachrichtenaufkommens ein, und das meiste davon ist Spam. Da die überwiegende Mehrzahl der Exchange Server-Computer auf irgendeine Weise mit dem Internet verbunden ist und gewöhnlich durch eine Kombination von Firewalls und Umkreisnetzwerken geschützt wird, nimmt es nicht Wunder, dass das Thema Nachrichtenhygiene auf der Aufgabenliste von Exchange-Administratoren ganz oben steht. Schließlich möchte niemand die Benutzerpostfächer den über 80% der Elemente aussetzen, die von Antispam- und Antivirenprodukten aus den eingehenden Nachrichten herausgefiltert werden. Weitere Informationen
Manche Unternehmen wie MessageLabs haben gemeldet, dass über 80% aller Nachrichten Spam enthalten. Die jüngsten Informationen finden Sie unter http://www.messagelabs.com/intelligence.aspx. Um eine gute Nachrichtenhygiene zu pflegen, stehen Unternehmen grundsätzlich die beiden folgenden Möglichkeiten offen: 쐍 Sie können die Aufgabe der Bereinigung eingehender E-Mails an einen darauf spezialisierten Dienstleister wie MessageLabs, Postini oder Microsoft vergeben, von denen sie dann einen sauberen Nachrichtenstream zur Weiterverarbeitung auf ihren Hub-Transport-Servern zurückerhalten. In Exchange Server 2010 können Sie verknüpfte Connectors verwenden, um eingehende Nachrichten an einen externen Dienstleister umzuleiten. Der Vorteil beim Outsourcing der Aufgaben zur Nachrichtenhygiene besteht darin, dass Sie die Erfahrungen eines spezialisierten Anbieters in der Bekämpfung von Viren und Spam nutzen können. Diese Dienstleister haben tiefe Kenntnisse der dunklen Seiten der E-Mail-Kommunikation und können immer am schnellsten reagieren, wenn sich neue Bedrohungsformen im Internet entwickeln. Außerdem verschwenden Sie nicht wertvolle Verwaltungs-, Netzwerk- und Computerresourcen, um mit der ungeheuren Menge an unerwünschter E-Mail fertig zu werden, die auf den Schwellen unserer Unternehmen abgeladen wird. 쐍 Sie können selbst Systeme bereitstellen, die eingehende Nachrichten bei ihrem Eintreffen im Netzwerk des Unternehmens bereinigen. Die übliche Vorgehensweise besteht darin, alle offensichtlich verdächtigen Elemente so früh wie möglich zu beseitigen, indem z.B. Nachrichten, die
872
nicht an einen in Active Directory gespeicherten Empfänger adressiert sind, sofort entfernt werden. Anschließend werden verschiedene Tests angewandt, um herauszufinden, ob Elemente Spam sind, Viren oder Anhänge mit unerwünschten Inhalten enthalten. Verdächtige Elemente können gelöscht oder von problematischen Bestandteilen befreit werden, und der bereinigte Nachrichtenstream wird dann zur Zustellung durch die Hub-Transport-Server geleitet. Die EdgeTransport-Server von Exchange Server 2010 sind eigens für die E-Mail-Bereinigung gedacht, allerdings müssen Sie für diese Aufgabe nicht zwangsläufig Server dieses Typs bereitstellen, da es noch viele andere Lösungen gibt. Natürlich lässt sich Sicherheit am besten dadurch erreichen, dass man mehrere Schutzwälle aufwirft. Auch clientseitige Junk-E-Mail-Filter leisten einen wichtigen Beitrag zur Verringerung unerwünschter Inhalte in den Benutzerpostfächern. Es ist jedoch sehr schwer, Benutzer so weit zu schützen, dass sie niemals eine Spamnachrichte sehen oder dass niemals ein Virus durchkommt. Spammer und Hacker wenden enorm viel Zeit und Anstrengung an, um sich neue Techniken zur Tarnung übler Inhalte auszudenken, damit diese die Schutzvorkehrungen von Unternehmen unterlaufen. Daraus folgt, dass der letzte Schutzwall die Schulung der Benutzer sein muss. Die Benutzer müssen sich darüber im Klaren sein, welche Gefahren Spam und Viren bedeuten und welche Maßnahmen sie ergreifen müssen, wenn es verdächtige Nachrichten bis in ihre Postfächer behalten. All diese Themen besprechen wir in diesem Kapitel noch genauer.
Edge oder nicht Edge, das ist hier die Frage Microsoft schlägt vor, Edge-Transport-Server zum Schutz von Exchange-Organisationen bereitzustellen. Das ist sicherlich eine gute Möglichkeit, aber es ist wichtig, sich darüber im Klaren zu sein, dass es Alternativen gibt, die Sie überdenken sollten, bevor Sie damit anfangen, Edge-Transport-Server einzurichten. Für viele Unternehmen mit einer Windows-Infrastruktur sind Edge-Transport-Server eine attraktive Schutzvorkehrung. Die Verwendung solcher Server als Eintrittspunkt in die Organisation bietet die folgenden Hauptvorteile: 쐍 Da Edge-Transport-Server Windows Server 2008 und Exchange Server 2010 ausführen, sind die Administratoren mit der Verwaltung vertraut. 쐍 Edge-Transport-Server ermöglichen den Einsatz einer umfassenden Menge von TransportAgents, die eingehende Nachrichten auf verschiedene Weise untersuchen, um problematische Inhalte aufzuspüren. 쐍 Edge-Transport-Server sind eng mit Microsoft Forefront Protection for Exchange Server 2010 (FPE) verzahnt. Wenn Sie Enterprise-Clientzugriffslizenzen erworben haben, können Sie FPE ohne weitere Ausgaben nutzen, um den grundlegenden Antivirusfähigkeiten des InhaltsfilterAgents eine anspruchsvolle Antivirusverarbeitung hinzuzufügen. Durch automatische Updates sorgen Sie dafür, dass die Antivirendaten stets auf dem neuesten Stand sind. 쐍 Der Synchronisierungsmechanismus erlaubt es Edge-Transport-Servern, Konfigurations- und Benutzerinformationen mit der Exchange-Organisation auszutauschen. Das wiederum erleichtert den Administratoren die Arbeit. Außerdem hilft der Zugriff auf gesammelte Daten wie die Listen sicherer Absender der einzelnen Benutzerpostfächer, die Anzahl von Fehlalarmen bei der Antispamprüfung zu verringern.
873
Nachrichtenhygiene
Edge oder nicht Edge, das ist hier die Frage
Kapitel 14
Nachrichtenhygiene
Manche Unternehmen halten es jedoch für besser, im Umkreisnetzwerk einen Nicht-Windows-Server aufzustellen. Das kann daran liegen, dass sie bereits über »Bastionsserver« verfügen (also besondere Server, die als erster Eintrittspunkt für E-Mails in eine Domäne fungieren), die eingehende E-Mails verarbeiten, ohne dass sie die Nachrichtenhygiene an einen spezialisierten Anbieter vergeben haben und von ihm einen bereinigten Nachrichtenstream bekommen, sodass Sie keinen Bastionsserver benötigen, oder dass sie für alle Computer im Umkreisnetzwerk eine Nicht-Windows-Plattform bevorzugen, weil sie verschiedenartige E-Mail-Systeme versorgen müssen, die nicht alle die Fähigkeiten von Edge-Transport-Servern nutzen können. Jedes Unternehmen hat seine eigenen Gründe für die Entscheidung, welche Computer und Betriebssysteme es für die verschiedenen Aufgaben einsetzt. Auch wenn die auf Microsoft-Produkte eingeschworenen Kreise die Verwendung von Edge-Transport-Servern bevorzugen mögen, ist es einfach nicht allen Unternehmen möglich, diesem Beispiel zu folgen.
Edge-Transport-Server Ein Edge-Transport-Server ist ein seltsames Tier, das in seiner eigenen Welt eines halb vollständigen Active Directory und eines halb vollständigen Exchange lebt und mit seiner Exchange-Mutterorganisation durch eine Nabelschnur verbunden ist. Da Edge-Transport-Server für die Bereitstellung im Umkreisnetzwerk gedacht sind, ist es natürlich von entscheidender Bedeutung, die Angriffsfläche zu verringern, sodass Hacker über diese Computer keinen Zugriff auf wertvolle Daten gewinnen. Ein normaler Exchange Server-Computer bildet ein attraktives Ziel, da ein Hacker, der ein Administratorkonto knackt, Zugang zu den Postfächern und anderen Daten hat, ganz zu schweigen von dem Chaos, das er in Active Directory anrichten kann und das Exchange in die Knie zwingen würde. Daher sind Edge-Transport-Server eine Art abgespecktes, eigenständiges Exchange-System, das isoliert ausgeführt wird. Da diese Computer aufgrund ihres Verwendungszwecks so entworfen sind, dass sie eingehende Nachrichten allein verarbeiten, nutzen sie keine der anspruchsvollen Funktionen eines vollständigen Exchange-Systems wie rollenbasierte Zugriffssteuerung oder Remote-PowerShell. Die einzigen Daten, die auf diesen Servern vorgehalten werden, sind die Datenbank der Nachrichtenwarteschlange und eine Instanz von AD LDS (Active Directory Lightweight Directory Service) mit Informationen, die von der Exchange-Mutterorganisation übertragen werden. Diese Daten sind hashkodiert, sodass sie für einen Hacker, der Zugang zu AD LDS gewinnt, keinen Nutzen haben. Alles in allem ist ein Edge-Transport-Server ein eingeschränkter Computer, der eher wie ein Zusatzgerät funktioniert und nicht wie ein Allzweckserver. Abgesehen von den geringeren Anforderungen läuft die Installation eines Edge-Transport-Servers genauso ab wie die einer der anderen Rollen. Eine externe Firewall sollte den Edge-Transport-Server schützen, und eine interne Firewall sollte ihn von den Hub-Transport-Servern abschirmen, mit denen er Kontakt aufnimmt, um Nachrichten in die Exchange-Organisation zu senden. In diesen Firewalls müssen einige wenige Ports geöffnet sein, damit der Edge-Transport-Server seinen Zweck erfüllen kann. Eine Aufstellung dieser Ports finden Sie in Tabelle 14.1. Tabelle 14.1
874
Ports für die Kommunikation mit Edge-Transport-Servern Firewallrichtung
Port
Verwendung
Extern
25 (zu und von allen Adressen)
SMTP-Verbindungen zum Austausch von Nachrichten (Senden und Empfangen) mit externen E-Mail-Servern
Edge-Transport-Server
Ports für die Kommunikation mit Edge-Transport-Servern Firewallrichtung
Port
Verwendung
Extern
53
Auflösung von Domänennamen mithilfe von DNS
Intern
25
SMTP-Verbindungen zum Austausch von Nachrichten (Senden und Empfangen) mit den Hub-Transport-Servern des angeschlossenen Active Directory-Standorts
Intern
50636
Sichere LDAP-Verbindungen (Lightweight Directory Access Protocol) für die unidirektionale Übertragung von Active DirectoryInformationen von einem Hub-Transport-Server zur AD LDSInstanz auf dem Edge-Transport-Server. Diesen Port können Sie in der Konfigurationsdatei für den Edge-Transport-Server ändern.
Intern
3389
RDP-Verbindungen (Remote Desktop Protocol) für die Remoteverwaltung des Edge-Transport-Servers
Zusammen mit der Edge-Transport-Rolle installiert das Setupprogramm auch die Exchange-Verwaltungstools, allerdings in einer besonderen Version für die Edge-Umgebung. Die Exchange-Verwaltungskonsole erfasst und zeigt nur die Daten für den Server, auf dem sie läuft (siehe Abbildung 14.1), und es gibt keinen Hinweis auf irgendwelche anderen Funktionen als auf diejenigen, die zur Verarbeitung von Nachrichten nötig sind. Auch die Toolbox ist auf die Programme zur Nachrichtenverarbeitung eingedampft, u.a. den Verfolgungsprotokoll-Explorer. Die Verwaltungsshell versteht ebenfalls nur eine eingeschränkte Menge von Befehlen. Auf einem Edge-Transport-Server suchen Sie vergeblich nach Cmdlets wie Get-Mailbox oder Set-MailboxDatabase, da sie hier nicht gebraucht werden. Abbildg. 14.1
Die Exchange-Verwaltungskonsole auf einem Edge-Transport-Server
875
Nachrichtenhygiene
Tabelle 14.1
Kapitel 14
Nachrichtenhygiene
Insidertipp: Bei der Installation wird ein Empfangsconnector erstellt
Bei der Installation eines Edge-Transport-Servers wird auch ein Empfangsconnector erstellt, der SMTP-Datenverkehr von beliebigen Servern über anonyme Verbindungen annehmen kann. Dieser eine Connector reicht aus, denn damit kann sich der Edge-Transport-Server einerseits um den Datenverkehr aus dem Internet kümmern, während für die Edge-Synchronisierung andere Berechtigungen gelten, um eine sichere Kommunikation mit der angeschlossenen ExchangeOrganisation zu gewährleisten. Zusätzliche Empfangsconnectors müssen Sie nur dann erstellen, wenn Sie nicht die Edge-Synchronisierung einsetzen, sondern manuell Connectors zur Kommunikation mit dem Internet und mit der Exchange-Organisation einrichten möchten.
Edge-Synchronisierung Die Edge-Synchronisierung ist der Vorgang, der einen Edge-Transport-Server mit Active Directory verbindet. Dabei replizieren die Hub-Transpor-Server im angeschlossenen Standort die Active Directory-Informationen über die Messagingkonfiguration der Organisation auf den Edge-Transport-Server. Dieser speichert die replizierten Daten in seiner AD LDS-Datenbank und greift darauf zurück, um zu entscheiden, welche der eingehenden Nachrichten an Exchange weitergeleitet werden sollen. Diese Verbindung wird Standortmitgliedschaft genannt. Dadurch können Hub-Transport-Server Nachrichten zur weiteren Zustellung an Edge-Transport-Server übertragen, ohne eigens dafür Sendeconnectors erstellen zu müssen. An einen Active Directory-Standort können mehrere Edge-Transport-Server angeschlossen sein, umgekehrt aber kann ein Edge-Transport-Server nur eine Verbindung zu einem einzigen Standort aufweisen. Dabei kann ein Edge-Transport-Server mit Exchange Server 2010 mit einem Hub-Transport-Server mit Exchange Server 2007 verbunden sein und umgekehrt. Das einzige Problem, das bei der Verbindung von Servern mit unterschiedlichen Exchange-Versionen auftritt, besteht darin, dass die Computer bei jeder Verbindung eine vollständige Synchronisierung durchführen müssen. Exchange Server 2010-Computer unter sich übertragen einfach die Änderungen, die seit der letzten Synchronisierung stattgefunden haben, was die Belastung der Server und des Netzwerks verringert. Selbstverständlich müssen alle Server, die in den Synchronisierungsvorgang einbezogen sind, in der Lage sein, einander zu erreichen. HINWEIS Die Verbindung zu einem Edge-Transport-Server können Sie nicht mit Ping prüfen, da die dortige Firewall so eingerichtet ist, dass sie nicht auf Ping-Anforderungen reagiert. Der Versuch führt also stets zu einer Zeitüberschreitung. Prinzipiell läuft die Synchronisierung zwischen einem Edge-Transport-Server und einem Active Directory-Standort wie folgt ab: 1. Mit dem Cmdlet New-EdgeSubscription erstellen Sie auf dem Edge-Transport-Server ein Edge-
Abonnement (siehe Abbildung 14.2). Dazu müssen Sie die Exchange-Verwaltungsshell mit erhöhten Berechtigungen starten, indem Sie sie als Administrator ausführen, und mit dem folgenden Befehl die XML-Datei mit der Abonnementanforderung erstellen: New-EdgeSubscription –FileName "c:\temp\EdgeSyncRequest.xml"
876
Daraufhin bereitet sich der Edge-Transport-Server auf die Synchronisierung vor, indem er die Routingkonfigurationsobjekte entfernt, die durch neue, vom Hub-Transport-Server übertragene Objekte ersetzt werden. Dazu gehören Connectors und akzeptierte Domänen. Da der EdgeTransport-Server letzten Endes unter die Kontrolle des Hub-Transport-Servers gerät, der ihm die Konfigurationsdaten sendet, deaktiviert Exchange die Cmdlets zum Erstellen und Ändern der Routingkonfiguration, also New-SendConnector, New-ReceiveConnector, New-AcceptedDomain usw. Zwar können Sie auf dem Edge-Transport-Server nach wie vor die Get-Varianten dieser Cmdlets verwenden, um sich die Konfigurationsdaten anzusehen, aber Sie können selbst keine Routingkonfigurationsobjekte mehr erstellen. Abbildg. 14.2
Eine Edge-Abonnementanforderung
2. Kopieren Sie die XML-Datei mit der Abonnementanforderung vom Edge- auf einen Hub-Trans-
port-Server im gewünschten Active Directory-Standort. Dabei handelt es sich gewöhnlich um einen Hub- oder zentralen Standort für die Active Directory-Replikation mit einer guten, durch eine Firewall gesicherten Netzwerkanbindung an den Edge-Transport-Server. Die Abonnementanforderung enthält Anmeldeinformationen für die Synchronisierung sowie andere Informationen, die für den Vorgang erforderlich sind, z.B. Angaben über den zu verwendenden TCP-Port und den öffentlichen Schlüssel für das selbst signierte Zertifikat des EdgeTransport-servers, sowie einige Informationen über den Server, z.B. die Exchange-Version, die auf ihm läuft. Zusammen mit der Abonnementanforderung wird auf dem Edge-Transport-Server auch ein AD LDS-Konto angelegt, das als Bootstrap-Replikationskonto bezeichnet wird (Edge Server Bootstrap Replication Account, ESBRA). Die Anmeldeinformationen in der Edge-Abonnementanforderung ermöglichen die Verwendung des ESBRA für den Zugriff auf AD LDS im Rahmen der Synchronisierung. Dieses Konto wird nach 24 Stunden ungültig, weshalb Sie die Anforderung zum Erstellen einer Edge-Synchronisierung auf dem Hub-Transport-Server unbedingt innerhalb von 24 Stunden verwenden müssen, nachdem Sie sie angelegt haben. Anderenfalls läuft das ESBRA ab, woraufhin die Abonnementanforderung ungültig wird und sie eine neue erstellen müssen. 877
Nachrichtenhygiene
Edge-Transport-Server
Kapitel 14
Nachrichtenhygiene
3. Führen Sie auf dem Hub-Transport-Server das Cmdlet New-EdgeSubscription aus, um die XML-
Datei zu importieren und die Verbindung zwischen dem Active Directory-Standort und dem Edge-Transport-Server zu erstellen. Die Syntax für diesen Befehl wirkt ziemlich rätselhaft, da Sie nicht einfach einen Dateinamen übergeben können, sondern den Inhalt mithilfe des Cmdlets GetContent einfließen lassen müssen. Der Grund dafür ist, dass Sie diesen Befehl im Kontext einer Windows PowerShell-Remotesitzung ausführen und daher nicht davon ausgehen können, dass die Dateidaten lokal sind. Daher lesen Sie mit Get-Content die Daten aus der Abonnementsanforderungsdatei und stellen sie dem Cmdlet New-EdgeSubscription zur Verfügung. Beachten Sie, dass der Name des Active Directory-Standorts mit dem Hub-Transport-Server angegeben wird. Durch den Wert $True für die Parameter -CreateInboundSendConnector und -CreateInternetSendConnector wird Exchange aufgefordert, zwei Sendeconnectors für die Verbindung des Edge-Transportservers mit dem Active Directory-Standort und mit dem Internet zu erstellen. New-EdgeSubscription –FileData ([byte[]]$(Get-Content –Path "c:\temp\EdgeSyncRequest.xml" –Encoding Byte –ReadCount 0)) –Site 'contoso.com/Configuration/Sites/Dublin'–CreateInboundSendConnector $True –CreateInternetSendConnector $True
Nachdem der Hub-Transport-Server die Edge-Abonnementanforderung verarbeitet hat, beginnt er mit der Synchronisierung über sicheres LDAP und TCP-Port 50656. Dieser Port muss in der Firewall zwischen dem Umkreis- und dem internen Netzwerk geöffnet sein. Der Hub-Transport-Server, auf dem Sie New-EdgeSubscription ausgeführt haben, bezieht den öffentlichen Schlüssel des Edge-Transport-Servers aus der Abonnementanforderung und verwendet ihn zur Entschlüsselung der Anmeldeinformationen für das ESBRA. Anschließend fügt er den Active Directory-Objekten für den Edge-Transport-Server die verschlüsselten Anmeldeinformationen hinzu, damit sie bei späteren Synchronisierungsvorgängen zur Verbindung mit AD LDS herangezogen werden können. Active Directory informiert sämtliche Hub-Transport-Server im Standort darüber, dass jetzt eine Verbindung zu einem Edge-Transport-Server besteht. Die Hub-Transport-Server speichern die Edge-Anmeldeinformationen mithilfe ihrer eigenen öffentlichen Schlüssel in ihren Konfigurationsobjekten. Abbildung 14.3 zeigt die im Active Directory-Objekt eines Hub-Transport-Servers abgelegten Anmeldeinformationen nach dem Einrichten einer Synchronisierung. Abbildg. 14.3
878
Die gespeicherten Edge-Anmeldeinformationen auf einem Hub-Transport-Server
Mithilfe der ESBRA-Anmeldeinformationen nimmt der Hub-Transport-Server jetzt Verbindung mit dem Edge-Transport-Server auf. Wenn das geglückt ist, sendet er Topologie-, Konfigurations- und Empfängerdaten über die Exchange-Organisation an AD LDS. Außerdem kopiert er die ESBRAAnmeldeinformationen, sodass der Microsoft Exchange-Anmeldeinformationsdienst auf dem EdgeTransport-Server sie zur Authentifizierung zukünftiger sicherer Synchronisierungsitzungen verwenden kann. Schließlich sendet der Hub-Transport-Server noch einen Synchronisierungszeitplan an den Edge-Transport-Server. Erzwingen der Synchronisierung
Um die Synchronisierung zu erzwingen, können Sie das Cmdlet Start-EdgeSynchronization ausführen. Jeder Hub-Transport-Server im Standort ist in der Lage, die Synchronisierung durchzuführen. Beispielsweise lösen Sie mit dem folgenden Befehl die Synchronisierung vom Hub-Transport-Server ExServer3 zum Edge-Transport-Server ExEdge1 aus: Start-EdgeSynchronization –TargetServer ExEdge1 –Server ExServer1
Überprüfen der Edge-Synchronisierung Mithilfe der Exchange-Verwaltungsshell können Sie die Synchronisierung überprüfen und sicherstellen, dass die Konfigurationsdaten aus der Exchange-Organisation erfolgreich an AD LDS überspielt wurden. Mit Get-SendConnector können Sie sich beispielsweise Angaben über die beiden von NewEdgeSynchronization erstellten Sendeconnectors ansehen. Da sie auf dem Hub-Transport-Server angelegt und auf den Edge-Transport-Server repliziert wurden, sollten diese Connectors von GetSendConnector auf beiden Seiten der Verbindung angezeigt werden. Das folgende Beispiel zeigt, dass die beiden Connectors deutlich benannt wurden, um ihren Zweck anzuzeigen: Get-SendConnector Identity -------EdgeSync – Dublin to Internet EdgeSync – Inbound to Dublin
AddressSpaces ------------<smtp:*;100> <smtp:--:100>
Enabled ------True True
Dank des Adressraums * kann der ausgehende Connector Nachrichten an beliebige SMTP-Domänen handhaben. Der Adressraum -- für den eingehenden Connector dagegen ist ein besonderer Platzhalter, der den Edge-Transport-Server anweist, alle Nachrichten für autorisierende und für interne Relaydomänen direkt an die Hub-Transport-Server im angeschlossenen Standort zu leiten. Jeder Hub-Transport-Server in diesem Standort kann Nachrichten vom Edge-Transport-Server empfangen, auch diejenigen, die erst nach der Einrichtung des Edge-Abonnements hinzugefügt wurden. Die Hub-Transport-Server gelten dabei als »Smarthosts«. Zur Pflege der Liste von Smarthosts müssen Sie selbst nichts tun, im Gegenteil, Sie werden sogar daran gehindert, den Adressraum oder die Smarthosts für die Connectors zu ändern, die automatisch für ein Edge-Abonnement erstellt wurden. Wenn Sie das Routing genauer steuern möchten, können Sie den Parameter -CreateInboundSendConnector von New-Edge-Subscription auf $False setzen und anschließend einen eigenen Connector erstellen. Weitere Informationen über selbst angelegte Connectors für die verschiedenen Routingsituationen finden Sie auf TechNet.
879
Nachrichtenhygiene
Edge-Transport-Server
Kapitel 14
Nachrichtenhygiene
Wenn Sie Get-ReceiveConnector auf einem Edge-Transport-Server ausführen, erhalten Sie Anhaben über den Empfangsconnector, der eingehende Nachrichten aus dem Internet annimmt: Get-ReceiveConnector Identity -------ExEdge1\Default internal receive connector ExEdge1
Bindings -------<0.0.0.0:25>
Enabled ------True
Weitere Beweise für eine erfolgreiche Synchronisierung können Sie gewinnen, indem Sie Exchange mit Get-AcceptedDomain und Get-TransportServer nach den akzeptierten Domänen bzw. den HubTransport-Servern abfragen, da auch diese Daten auf den Edge-Transport-Server überspielt werden. Sie können sich auch die an AD LDS übertragenen Daten ansehen, um sich zu vergewissern, dass sie die Einstellungen für die Organisation aufweisen, mit der der Edge-Transport-Server verbunden ist. Öffnen Sie den ADSI-Editor auf dem Edge-Transport-Server und rufen Sie über Verbindung herstellen den Konfigurationsnamenskontext auf. Geben Sie als Name des gewünschten Computers den Edge-Transport-Server und den zu verwendenden Port an. Da AD LDS Port 50389 verwendet, müssen Sie die Verbindung mit einem Servernamen und einer Portnummer wie in Abbildung 14.4 herstellen. Abbildg. 14.4
Herstellen einer Verbindung mit dem Konfigurationsnamenskontext auf einem Edge-Transport-Server
Sobald die Verbindung besteht, können Sie die von Exchange auf den Edge-Transport-Server übertragenen Daten genauso durchsuchen wie die Konfigurationsdaten in Active Directory (siehe Abbildung 14.5). Der ADSI-Editor ist nicht das einzige Programm, mit dem Sie AD LDS abfragen können. Manche Administratoren bevorzugen LDP, da dies präziser sein soll. Um die Empfängerinformationen in AD LDS mit LDP einzusehen, stellen Sie auf eine ähnliche Weise wie im ADSI-Editor eine Verbindung zur Organisationseinheit MSExchangeGateway her. Schließlich können Sie auch noch das Cmdlet Test-EdgeSynchronization auf einem Hub-TransportServer im angeschlossenen Standort ausführen, um sich zu vergewissern, dass die Synchronisierung normal verläuft. Um einen vollständigen Test durchzuführen, geben Sie den Parameter -FullCompareMode an: Test-EdgeSynchronization –TargetServer ExEdge1 –FullCompareMode
880
SyncStatus UtcNow Name LeaseHolder
Normal 2/26/2010 12:10:44 AM ExEdge1 CN=ExServer1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=contoso, CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=contoso,DC=com LeaseType : Option FailureDetail : LeaseExpiryUtc : 2/26/2010 1:08:59 AM LastSynchronizedUtc : 2/26/2010 12:08:59 AM TransportServerStatus : Synchronized TransportConfigStatus : Synchronized AcceptedDomainStatus : Synchronized RemoteDomainStatus : Synchronized SendConnectorStatus : Synchronized MessageClassificationStatus : Synchronized RecipientStatus : Synchronized CredentialRecords : Number of credentials 6 CookieRecords : Number of cookies 2 Abbildg. 14.5
: : : :
Die an AD LDS überspielten Informationen über die Exchange-Organisation
881
Nachrichtenhygiene
Edge-Transport-Server
Kapitel 14
Nachrichtenhygiene
Nachdem Sie sich davon überzeugt haben, dass die Synchronisierung erfolgreich abläuft und die richtigen Connectors für den Umgang mit eingehenden Nachrichten vorhanden sind, können Sie DNS um einen MX-Eintrag für den Edge-Transport-Server ergänzen, damit dieser neue Nachrichten zur Verarbeitung empfangen kann. Insidertipp: Zugriff auf die AD LDS-Informationen über E-Mail-aktivierte Empfänger
AD LDS enthält auch Informationen über die E-Mail-aktivierten Empfänger in der ExchangeOrganisation, damit der Edge-Transport-Server eingehende Nachrichten anhand der Empfängeradressen überprüfen und auf die Daten der Benutzer über sichere Absender zugreifen kann, um herauszufinden, ob die Absender für die Empfänger akzeptabel sind. Diese Informationen sind in AD LDS jedoch nicht im Konfigurationsnamenskontext gespeichert. Um auf sie zuzugreifen, müssen Sie eine Verbindung mit der Organisationseinheit MSExchangeGateway im standardmäßigen Namenskontext aufnehmen. Die LDAP-Verbindung lautet LDAP://<Servername>:50389/ou= MsExchangeGateway. Alternativ können Sie mit localhost:50389 auf den lokalen Servernamen und Port 50389 verweisen. Nachdem die Verbindung hergestellt ist, öffnen Sie CN=Recipients. Dieser Container enthält einen Eintrag für jeden E-Mail-aktivierten Empfänger der Organisation (Benutzer, Kontakte, Gruppen und öffentliche Ordner). Allerdings diese Einträge verschleiert, sodass selbst einem Hacker, der in den Edge-Transport-Server und AD LDS eindringt, nichts mit diesen Informationen anfangen kann. Abbildung 14.6 zeigt den Empfänger Recipients der Organisationseinheit MSExchangeGateway im ADSI-Editor. Sie können erkennen, dass die Angaben über die Benutzer in AD LDS verschleiert sind. Abbildg. 14.6
882
Anzeigen der Empfängerinformationen in AD LDS
Edge-Transport-Server
Es ist wichtig, dass der Edge-Transport-Server regelmäßige Aktualisierungen empfängt, damit er über die Änderungen an den Benutzer- und Konfigurationsdaten der Exchange-Organisation auf dem Laufenden bleibt. Die Hub- und Edge-Transport-Server stehen in häufigem Kontakt miteinander, um Änderungen von der Exchange-Organisation zum Edge-Server zu übertragen. Wie bereits erwähnt ist diese Synchronisierung in Exchange Server 2010 verbessert worden, da nur noch die Änderungen und nicht mehr die gesamten Daten übertragen werden. In einem Active Directory-Standort, der mit einem Edge-Transport-Server verbunden ist, können mehrere Hub-Transport-Server vorhanden sind. Die Synchronisierung kann jeder dieser Hub-Transport-Server vornehmen, wobei es wichtig ist, dass sie nicht in Konkurrenz zueinander treten und mehrere gleichzeitige Synchronisierungssitzungen aufbauen. Mit dem folgenden Algorithmus bestimmt Exchange, welcher Hub-Transport-Server die Synchronisierung durchführt: 1. Die erste Synchronisierung nach dem Ausführen von New-EdgeSubscription führt der erste Hub-
2.
3.
4.
5.
Transport-Server durch, der den Edge-Transport-Server durch eine Topologiesuche in der Organisation findet. Dies ist möglich, da der neue Edge-Transport-Server und seine Connectors in der Routingtopologie erscheinen. Der Hub-Transport-Server, der die Edge-Verbindung entdeckt, erwirbt eine EdgeSync-Lease, die eine Sperre für das Edge-Abonnement errichtet und den betreffenden Server zum bevorzugten Synchronisierungsserver macht. Durch diese Sperre wird verhindert, dass andere Hub-Transport-Server im Standort ebenfalls die Lease erwerben. An der Synchronisierung teilnehmen können nur Hub-Transport-Server, die beim Erstellen des Edge-Abonnements schon im Standort vorhanden waren. Wenn Sie anschließend neue Hub-Transport-Server hinzufügen und dafür sorgen möchten, dass auch sie zum bevorzugten Server werden können, müssen Sie das EdgeAbonnement neu erstellen. Um zu erkennen, welcher Hub-Transport-Server die Lease zurzeit innehat, führen Sie Test-EdgeSubscription aus. Der betreffende Server erscheint in der Ausgabe als LeaseHolder. Bei der Auswahl des bevorzugten Servers genießen Hub-Transport-Server mit Exchange Server 2010 Vorrang vor denen mit Exchange Server 2007. Die EdgeSync-Lease gilt für eine Stunde. Allerdings können Sie immer das Cmdlet Start-EdgeSynchronization ausführen und mit dem Parameter -Server einen Hub-Transport-Server angeben, um manuell eine Synchronisierung über diesen Computer zu erzwingen. Wenn Sie hierbei keinen Server angeben, wird der bevorzugte verwendet. Während der Leasezeit führt der bevorzugte Server alle automatischen Synchronisierungsvorgänge durch, sofern er nicht aus irgendeinem Grund unerreichbar ist. In diesem Fall läuft die Lease fünf Minuten später aus, woraufhin ein anderer Hub-Transport-Server eine neue Lease erwirbt, zum bevorzugten Server wird und die Synchronisierung durchführt. Der bevorzugte Server behält diesen Status, bis die Lease abläuft. Danach kann er die Lease erneuern und weiterhin als bevorzugter Server fungieren, bis er aus irgendeinem Grunde nicht mehr zur Verfügung steht.
Die automatische Synchronisierung zwischen dem bevorzugten Hub-Transport-Server und dem Edge-Transport-Server läuft in folgenden Zeitabständen ab: 쐍 Änderungen an den Konfigurationsdaten, also an den akzeptierten Domänen, Connectors und Servern, werden alle drei Minuten übertragen. 쐍 Änderungen an den Empfängerdaten, also neue Postfächer und Gruppen sowie Aktualisierungen der Listen sicherer Absender, werden alle fünf Minuten übertragen.
883
Nachrichtenhygiene
Fortlaufende Synchronisierung
Kapitel 14
Nachrichtenhygiene
Diese Intervalle können Sie mit Set-EdgeSyncServiceConfig ändern. Als Erstes rufen Sie dazu auf einem Hub-Transport-Servers des mit dem Edge-Transport-Server verbundenen Active DirectoryStandorts mit Get-EdgeSyncServiceConfig die Standardeinstellungen ab, um herauszufinden, wie die Parameter heißen und welche Werte sie zurzeit aufweisen: Get-EdgeSyncServiceConfig SiteName ConfigurationSyncInterval RecipientSyncInterval LockDuration LockRenewalDuration OptionDuration CookieValidDuration FailoverDCInterval LogEnabled LogMaxAge LogMaxDirectorySize LogMaxFileSize LogLevel LogPath Identity
: : : : : : : : : : : : : : :
Dublin 00:03:00 00:05:00 00:05:00 00:01:00 01:00:00 21.00:00:00 00:05:00 True 30.00:00:00 262144000 10485760 None TransportRoles\Logs\EdgeSync\ contoso.com/Configuration/Sites/Dublin/EdgeSyncService
Deutlich zu erkennen sind die Synchronisierungsabstände (ConfigurationSyncInterval und RecipientSyncINterval) sowie der Leasezeitraum für den bevorzugten Server (LockRenewalDuration). Außerdem können Sie sehen, wie lange Exchange darauf wartet, dass ein Hub-Transport-Server wieder verfügbar wird, bevor die Verantwortung für die Synchronisierung einem anderen übertragen wird (LockDuration). Außerdem besagt die Beispielausgabe, dass die Synchronisierungsvorgänge im Pfad \TransportRoles\Logs\EdgeSync im Exchange-Installationsverzeichnis protokolliert werden. Der voreingestellte Protokolliergrad ist jedoch None. Wenn Sie Daten über die Synchronisierungsvorgänge aufzeichnen möchten, müssen Sie ihn wie folgt auf Low, Medium oder High anheben: Set-EdgeSyncServiceConfig –Identity 'contoso.com/Configuration/Sites/Dublin/ EdgeSyncService' –LogLevel 'High'
Wenn diese Einstellung in Kraft ist, werden Protokolleinträge wie der folgende aufgezeichnet: ExEdge1.contoso.com,50636,TargetConnection,Medium,"Updated: CN=Redmond, \Eoin,OU=Exchange Users,DC=contoso,DC=com",Succcessfully Updated Entry,,,
Dies ist der Eintrag für die Aktualisierung eines Benutzerpostfachs. Vielleicht wurde bei dem Postfach eine Eigenschaft wie eine E-Mail-Adresse ergänzt oder geändert oder der Benutzer hat seine Junk-EMail-Einstellungen geändert, sodass Exchange diese Daten jetzt auf den Edge-Transport-Server überspielen muss (z.B. für die Erfassung der Listen sicherer Absender im Rahmen der Antispamprüfung). Wie solche Listen auf den Edge-Transport-Server gelangen, erfahren Sie in Kürze. Mit Start-EdgeSynchronization können Sie dafür sorgen, dass sofort eine Synchronisierung stattfindet. Das hat den Vorteil, dass sie sich gezielt die Ergebnisse dieser Synchronisierung ansehen können.
884
Edge-Transport-Server
Nachrichtenhygiene
Wenn Sie z.B. ein neues Postfach erstellen und dann Start-EdgeSynchronization ausführen, sollten Sie wie in der folgenden Ausgabe erkennen können, dass der neue Empfänger hinzugefügt wurde: Start-EdgeSynchronization Result Type Name FailureDetails StartUTC EndUTC Added Deleted Updated Scanned TargetScanned
: : : : : : : : : : :
Success Recipients ExEdge1 2/26/2010 9:19:29 AM 2/26/2010 9:19:30 AM 1 0 0 1 0
Insidertipp: Die Edge-Server-Datenbank
Die bei der Synchronisierung vom Hub-Transport-Server erhaltenen Daten speichert der EdgeTransport-Server in einer AD LDS-Datenbank. Wie für andere Active Directory-Datenbanken wird auch für AD LDS eine ESE-Datenbank verwendet (Extensible Storage Engine), deren Transaktionsprotokolle eine Umlaufprotokollierung durchführen, um den erforderlichen Speicherplatz zu begrenzen. Da bei der Synchronisierung jetzt nur noch die Änderungen übertragen werden, werden dabei in Exchange Server 2010 viel weniger Transaktionsprotokolle erstellt. Der Standardspeicherort der Datenbank ist \TransportRoles \Data\Adam. Dies können Sie in der Datei EdgeTransport.config.exe ändern. Durch die Edge-Synchronisierung wird nicht die gesamte Konfiguration eines Edge-TransportServers vorgenommen. Die Serverlizenz müssen Sie immer noch selbst eingeben, und auch die serverspezifischen Konfigurationseinstellungen werden Ihnen nicht abgenommen, z.B. Transportregeln für eingehende Nachrichten, Zertifikate zur Absicherung der Dienste, Sperrlisten und andere Antispameinstellungen sowie Einzelheiten der Connectors, die nicht automatisch durch die EdgeSynchronisierung erstellt werden. Microsoft nennt dies »benutzerdefinierte Einstellungen«, da hierzu ein Eingriff des Administrators erforderlich ist, während andere Einstellungen auf einem Edge-Transport-Server über die Synchronisierung unterhalten werden. Da ein Edge-TransportServer letzten Endes isoliert von den anderen arbeitet und die in AD LDS gespeicherten Daten nicht an andere Server weitergibt, müssen Sie solche benutzerdefinierten Einstellungen auf jedem einzelnen Edge-Transport-Server vornehmen. Dazu führen Sie die Änderungen entweder manuell auf jedem Server durch oder kopieren die Konfiguration auf einem davon und importieren sie auf die anderen. Microsoft stellt das Script ExportEdgeConfig.ps1 bereit, mit dem Sie die Konfigurationsdaten eines Edge-Transport-Servers in eine XML-Datei exportieren können. Diese Daten können Sie dann mit dem Skript ImportEdgeConfig.ps1 wieder auf einen anderen Server importieren. Beide Skripts befinden sich im Exchange-Installationsverzeichnis unter \Scripts. Genauere Informationen über die einzelnen Schritte beim Export und Import erhalten Sie auf TechNet.
885
Kapitel 14
Nachrichtenhygiene
Insidertipp: Konfigurationseinstellungen für Edge-Transport-Server
Eine Ausnahme bilden die Transportregeln, die sich mit dieser Methode nicht ex- und importieren lassen. Dazu müssen Sie die Cmdlets Export-TransportRuleCollection bzw. Import-TransportRuleCollection verwenden. Denken Sie daran, dass Edge-Transport-Server ihren eigenen Regelsatz unterhalten, der von den gemeinsam verwendeten Regeln der Hub-Tarnsport-Server getrennt ist. Wenn Sie daher Regelsätze auf einem Edge-Transport-Server im- oder exportieren, so betrifft das nur die auf diesem Server definierten Regeln und hat nichts mit denen in der Organisation zu tun.
Antispam-Agents von Exchange Da sich die von Spammern eingesetzten Techniken und Mechanismen ständig weiterentwickeln, um Vorkehrungen zur Spamabwehr zu unterlaufen, ist es nicht möglich, einen Algorithmus aufzustellen, der jeglichen Spam in den eingehenden Nachrichten aus dem Internet erkennt. Exchange Server 2010 verwendet daher einen Satz aus mehreren Antispam-Agents, die zusammenarbeiten, um die eingehenden Nachrichten mit verschiedenen Techniken zu untersuchen, die einerseits Spam mit hoher Wahrscheinlichkeit entdecken und andererseits nicht zu viele Fehlalarme hervorrufen. Um die Verarbeitung zu optimieren, können Sie die Eingabedaten anpassen, die diese Agents verwenden. Außerdem bietet Microsoft Aktualisierungen zum Download an, um die Agents über neue Spamtechniken zu informieren, die in der Praxis beobachtet wurden. Edge-Transport-Server sind der ideale Ort für die Bereitstellung von Antispam-Agents. Diese Server sind die ersten Eintrittspunkte für eingehende Nachrichten, sodass hier die Gelegenheit besteht, Spam-Mails zu erkennen und zu blockieren, bevor sie die Postfächer der Benutzer zumüllen können. Die Antispam-Agents werden automatisch auf Edge-Transport-Servern installiert. Für Sie bleibt nur noch die Aufgabe, die Einstellungen an die Bedürfnisse Ihrer Organisation anzupassen. Wenn empfohlene Vorgehensweisen nicht empfehlenswert sind
In der Microsoft-Dokumentation wird empfohlen, die Antispam-Agents nicht auf einem HubTransport-Server auszuführen. Das ist völlig richtig, solange Sie auch Edge-Transport-Server betreiben. Allerdings ist diese Vorgehensweise nur in einer reinen Microsoft-Umgebung empfehlenswert und nicht, wenn Exchange durch andere Antispam-Server in einem Umkreisnetzwerk geschützt wird. Selbst wenn Antispam-Systeme anderer Hersteller als Microsoft die eingehenden Nachrichten bereinigen, können Sie nichts verlieren sondern eher noch etwas gewinnen, indem Sie die Antispam-Agents auf irgendeinem Hub-Transport-Server mit einem Empfangsconnector ausführen, der die Exchange-Organisation mit dem Internet verbindet (direkt oder indirekt über ein eingehendes Relay), denn dadurch besteht die Chance, noch Spam beseitigen zu können.
Installieren der Antispam-Agents auf einem Hub-Transport-Server Manche Organisationen stellen keine Edge-Transport-Server bereit, da sie andere Antispamserver einsetzen. Gewöhnlich führen diese Computer Linux oder Unix aus und sind wie Edge-TransportServer hochgradig für ihre Sonderaufgabe optimiert. Andere Organisationen wiederum sind zu
886
klein, um sich den relativen Luxus von Edge-Transport-Server in einem Umkreisnetzwerk zu erlauben. In solchen Fällen können Sie die grundlegenden Antispam-Agents von Exchange Server 2010 auch auf einem Hub-Transport-Server installieren. Führen Sie dazu das Skript AntiSpamAgents.ps1 aus, das Sie im Exchange-Installationsverzeichnis unter \Scripts finden. Nachdem Sie das Skript ausgeführt und die Agents auf dem Hub-Transport-Server installiert haben, werden Sie feststellen, dass die Transportpipeline auf dem betreffenden Server einen neuen Satz von Agents aufweist, die den Nachrichtenstream bereinigen. Wenn Sie die folgende Ausgabe mit dem vorherigen Beispiel von Get-TransportPipeline aus Kapitel 13, »Das Exchange-Transportsystem«, vergleichen, können Sie erkennen, dass in der Pipeline jetzt die Antispam-Agents vorhanden sind: Get-TransportPipeline Event ----OnConnectEvent OnHeloCommand OnEhloCommand OnAuthCommand OnEndOfAuthentication OnMailCommand OnRcptCommand OnDataCommand OnEndOfHeaders OnEndOfData OnHelpCommand OnNoopCommand OnReject OnRsetCommand OnDisconnectEvent OnSubmittedMessage OnResolvedMessage OnRoutedMessage OnCategorizedMessage
TransportAgents --------------Connection Filtering Agent, Protocol Analysis ... {} {} {} {} {Connection Filtering Agent, Sender Filter Agent} {Connection Filtering Agent, Recipient Filter A... {} {Connection Filtering Agent, Sender Id Agent, S... {Content Filter Agent, Protocol Analysis Agent} {} {} {Protocol Analysis Agent} {Protocol Analysis Agent} {Protocol Analysis Agent} {Text Messaging Routing Agent} {} {Transport Rule Agent} {}
Nach der Installation der Antispam-Skripts auf einem Hub-Transport-Server müssen Sie den Transportdienst neu starten und dem Verbindungsfilter-Agent gegenüber den Satz der Hub-TransportServer als »interne SMTP-Server« angeben, damit er weiß, dass jede Verbindung von diesen Servern vertrauenswürdig ist und daher ignoriert werden kann. Zur Angabe dieser Server geben Sie deren IPAdressen im Parameter -InternalSMTPServers von Set-TransportConfig an. Wenn Sie beispielsweise über zwei Hub-Transport-Server mit den IP-Adressen 192.50.60.1 und 192.50.60.2 verfügen, lautet der Befehl wie folgt: Set-TransportConfig –InternalSMTPServers '192.50.60.1', '192.50.60.2'
Abgesehen von der Anlagenfilterung, die nur auf einem Edge-Transport-Server ausgeführt werden kann, funktionieren alle Antispam-Agents auf einem Hub-Transport-Server genauso wie auf einem Edge-Transport-Server. Die folgende Erörterung der verschiedenen Agents gilt daher für beide Rollen.
887
Nachrichtenhygiene
Antispam-Agents von Exchange
Kapitel 14
Nachrichtenhygiene
Reihenfolge der Verarbeitung von AntispamAgents Exchange wendet eine Reihe von Tests an, um zu überprüfen, ob es sich bei einer Nachricht um Spam handelt. Die folgende Übersicht führt die einzelnen Antispam-Tests in der Reihenfolge auf, in der sie durchgeführt werden, und gibt jeweils eine kurze Erläuterung des betreffenden Schritts. Die Einstellungen, mit denen Sie diese Tests steuern können, sehen wir uns später an. 쐍 Verbindungsfilterung Wenn ein externer Server eine SMTP-Verbindung zur Übertragung einer Nachricht aufbaut, untersucht der Verbindungfilter-Agent dessen Quell-IP-Adresse und vergleicht sie mit den Einträgen in der IP-Zulassungsliste (bekannte harmlose Verbindungen), der IP-Sperrliste (bekannte unerwünschte Verbindungen) und ggf. einer Echtzeit-Sperrliste (Real-Time Block List, RBL), um zu entscheiden, ob diese Verbindung akzeptiert oder getrennt werden soll. Verbindungen von bekannten Spamquellen oder verdächtigen IP-Adressen werden gewöhnlich sofort abgebrochen, um die Spamnachrichten gar nicht erst hereinzulassen. 쐍 Absenderfilterung Wenn die Verbindung aufgebaut ist, vergleicht Exchange die SMTP-E-MailAdresse des Absenders mit einer Liste bekannter Spammer und sonstiger unliebsamer Absender (die z.B. obszöne oder auf andere Weise inakzeptable Inhalte senden). Nachrichten von solchen unerwünschten Quellen werden entfernt. 쐍 Empfängerfilterung Anschließend untersucht Exchange die in der Nachricht aufgeführten Empfänger anhand der Empfängersperrliste. Nachrichten an Adressen, für die keine E-Mails empfangen werden sollen, werden entfernt. Exchange kann auch eine Empfängerprüfung anhand von Active Directory durchführen, um zu ermitteln, ob die Nachrichten korrekt adressiert sind. Spammer senden häufig buchstäblich Millionen von Nachrichten mit zufällig generierten E-Mail-Adressen, um einige davon an gültige Empfänger zu bekommen, weshalb Unternehmen gewöhnlich alle Nachrichten ablehnen, die nicht an einen gültigen Empfänger adressiert sind. 쐍 Sender ID-Filterung Sie können besondere DNS-Einträge veröffentlichen, um andere Domänen über die Identität der von Ihrem Unternehmen verwendeten E-Mail-Server in Kenntnis zu setzen. Aber bei der Sender ID-Filterung werden diese Informationen herangezogen, um zu bestimmen, ob eine Nachricht tatsächlich aus der Domäne stammt, von der sie zu kommen vorgibt. Wenn DNS Exchange mitteilt, dass der Ursprungsserver nicht für die Domäne registriert ist, kann das ein Zeichen dafür sein, dass sich ein Spammer als das betreffende Unternehmen tarnt, um seine Nachrichten als gültige E-Mails auszugeben. Bei Phishing-Angriffen, bei denen Verbraucher dazu verleitet werden sollen, Ihre Online-Bankkontonummern und Kennwörter zu offenbaren, werden Spamnachrichten eingesetzt, die angeblich von der Bank kommen, in Wirklichkeit aber von den E-Mail-Systemen der Angreifer gesendet werden. 쐍 Inhaltsfilterung Zum Schluss vergleicht Exchange die Nachrichten mit den Daten, die die Benutzer in Form von Listen sicherer Absender beigesteuert haben, und mit den von Microsoft gesammelten Daten über die Charakteristika von Spam. Damit wird eine SCL-Bewertung (Spam Confidence Level) auf einer Skala von 0 bis 9 ermittelt. Je geringer der SCL-Wert, umso geringer ist die Wahrscheinlichkeit dafür, dass es sich um Spam handelt. Nachrichtem mit einer SCLBewertung von 6 oder höher sind dagegen verdächtig und müssen mit Vorsicht behandelt werden. Administratoren legen SCL-Schwellenwerte fest, um Exchange anzuweisen, wie mit den Nachrichten zu verfahren ist, nachdem ihr SCL-Wert bestimmt wurde. Die Nachrichten können sofort entfernt, aber auch zur Zustellung an die Empfängerpostfächer weitergeleitet werden, wo die clientseitige Junk-E-Mail-Filterung eine weitere Entscheidung über die Handhabung trifft.
888
Antispam-Agents von Exchange
TIPP Die goldene Regel der Antispam-Prüfung lautet, dass die Ergebnisse umso besser sind, je besser die Eingabe in die Spamtests ist.
Von Antispam-Agents hinzugefügte X-Header Es wäre unwirtschaftlich, wenn Exchange jedes Mal eine Antispam-Prüfung zur Bestimmung des SCL-Werts durchführen würde, wenn eine Nachricht einen Edge- oder Hub-Transport-Server mit den entsprechenden Agents durchläuft. Nachdem eine Nachricht einer Antispam-Prüfung unterzogen wurde, fügt ihr Exchange X-Header hinzu, in denen das Ergebnis des Tests festgehalten wird, sodass die nachfolgenden Server und Clients wissen, dass diese Art der Verarbeitung bereits erfolgt ist, und auch die Ergebnisse kennen. Die X-Header können Sie sich ansehen, indem Sie den Nachrichtenheader anzeigen. In Abbildung 14.7 können Sie erkennen, dass die SCL-Bewertung für die Nachricht 0 ist, was eine sehr geringe Wahrscheinlichkeit für Spam anzeigt. Eine vollständige Liste der von Exchange verwendeten X-Header finden Sie in Tabelle 14.2. Abbildg. 14.7
Anzeigen der von den Exchange-Antispam-Agents hinzugefügten X-Header
Tabelle 14.2
Tabelle 14.2: Von Exchange geschriebene X-Header X-Header
Bedeutung
X-MS-Exchange-Forest-RulesExecuted
Vermerkt alle Transportregeln, durch die die Nachricht verarbeitet wurde.
X-MS-Exchange-Organization-Antispam-Report
Zeigt das Ergebnis der Verarbeitung durch die AntispamAgents.
X-MS-Exchange-Organization-AuthAs
Gibt die vom empfangenden Connector gemeldete Authentifizierungsquelle der Nachricht an. Mögliche Werte sind Anonymous, Internal, External und Partner.
889
Nachrichtenhygiene
Exchange berechnet außerdem einen PCL-Wert (Phishing Confidence Level), der anzeigt, mit welcher Wahrscheinlichkeit diese Nachricht einem Phishing-Versuch dient.
Kapitel 14 Tabelle 14.2
Nachrichtenhygiene
Tabelle 14.2: Von Exchange geschriebene X-Header (Fortsetzung) X-Header
Bedeutung
X-MS-Exchange-Organization-AuthDomain
Enthält den vollqualifizierten Domänennamen (FQDN) einer authentifizierten Remotedomäne, falls die Nachricht über eine Domain-Secure-Authentifizierung empfangen wurde.
X-MS-Exchange-Organization-AuthMechanism
Gibt eine zweistellige Hexadezimalzahl für den Authentifizierungsmechanismus an, der bei der Übertragung der Nachricht verwendet wurde.
X-MS-Exchange-Organization-AuthSource
Gibt den FQDN des Servers an, der die Authentifizierung der Nachricht bei der Ankunft in der Organisation durchgeführt hat.
X-MS-Exchange-Organization-Journal-Report
Kennzeichnet eine Nachricht als Journaldatensatz.
X-MS-Exchange-Organization-OriginalArrivalTime
Enthält den Zeitpunkt (in UTC), an dem die Nachricht in der Exchange-Organisation ankam. Hat sie zuvor ein anderes E-Mail-System durchlaufen, enthält sie möglicherweise auch den Header X-OriginalArrivalTime, der die Ankunftszeit in jenem System angibt.
X-MS-Exchange-Organization-Original-Sender
Gibt den ursprünglichen Absender einer Nachricht in Quarantäne an.
X-MS-Exchange-Organization-Original-Size
Gibt die ursprüngliche Größe einer Nachricht in Quarantäne an.
X-MS-Exchange-Organization-Original-SCL
Gibt den ursprünglichen SCL-Wert einer Nachricht in Quarantäne an.
X-MS-Exchange-Organization-Original-PCL
Gibt den ursprünglichen PCL-Wert einer Nachricht in Quarantäne an.
X-MS-Exchange-Organization-Quarantine
Dieses Flag zeigt an, dass die Nachricht in das Quarantänepostfach umgeleitet wurde und dass eine Benachrichtigung über den Zustellungsstatus (Delivery Status Notification, DSN) gesendet wurde. Hiermit wird auch gekennzeichnet, dass eine Nachricht in Quarantäne versetzt, aber von einem Administrator zur Zustellung freigegeben wurde.
X-MS-Exchange-Organization-PRD
Enthält die angebliche verantwortliche Domäne (Purported Responsible Domain, PRD), falls der Sender ID-Agent sie ermittelt hat.
X-MS-Exchange-Organization-SCL
Enthält den SCL-Wert der Nachricht. Die möglichen Werte reichen von 0 bis 9, wobei höhere Werte eine höhere Wahrscheinlichkeit dafür angeben, dass es sich um Spam handelt. Mit dem Wert -1 werden interne Nachrichten gekennzeichnet (die aus derselben Exchange-Organisation stammen), die nicht vom Inhaltsfilter-Agent verarbeitet wurden.
X-MS-Exchange-Organization-SenderIdResult
Enthält die Ergebnisse der Überprüfung durch den Sender ID-Agent.
In der Abbildung können Sie auch sehen, dass die Nachricht einen PCL-Wert von 2 aufweist. Phishing-Nachrichten fordern die Empfänger gewöhnlich dazu auf, vertrauliche Daten wie Angaben zu ihrer Bankverbindung auf einer Website einzugeben. Dabei wird der Benutzer in falscher Sicherheit gewiegt, da die Nachricht von einer legitimen Quelle wie seiner Bank zu stammen scheint. Es ist jedoch immer wieder überraschend (und deprimierend), von Fällen zu hören, in denen Benutzer auf diesen Trick hereingefallen sind und sogar auf Nachrichten geantwortet haben, die angeblich von 890
einer Bank kamen, mit der sie gar nichts zu tun hatten. So viel zum Thema menschliche Fehlbarkeit. Auf jeden Fall berechnet Exchange für jede Nachricht neben dem SCL auch einen PCL mit Werten zwischen 1 und 8. Alle Werte bis zu 3 können als neutral betrachtet werden, was bedeutet, dass die Nachricht wahrscheinlich keinen Phishing-Angriff enthält. Ab einem Wert von 4 jedoch wird es immer wahrscheinlicher, dass die Nachricht Elemente wie Links zu verdächtigen Websites enthält, sodass Exchange sie als gefährlichen Spam einstuft. Bei der Überprüfung eingehender Nachrichten bezieht der Junk-E-Mail-Filter von Outlook auf den PCL-Wert in seine Berechnungen, wobei eine hohe Wahrscheinlichkeit dafür besteht, dass Nachrichten mit einem hohen PCL-Wert je nach Benutzereinstellung sofort gelöscht oder in den Junk-E-Mail-Ordner verschoben werden. Nachdem eine Nachricht die Antispam-Agents durchlaufen hat, schreibt Exchange den X-Header X-MS-Organization-Antispam-Report, der einen Überblick über die Ergebnisse der Verarbeitung durch die Agents enthält. In dem Beispiel aus Abbildung 14.7 enthält dieser Bericht die folgenden Werte: 쐍 DV 3.3.5705.600 wendet ht.
Dies ist die Version der Spamdefinitionsdatei, die der Antispam-Agent ver-
쐍 SID:SenderIDStatus:None Der Sender ID-Agent meldet, dass für den Server, von dem die Nachricht stammt, kein Eintrag im Sender Policy Framework (SPF) veröffentlicht wurde. 쐍 OrigIP
Die IP-Adresse des Servers, von dem die Nachricht stammt.
Insidertipp: Untersuchen verdächtiger Nachrichten
Ein Antispam-Bericht kann auch viele andere Arten von Informationen enthalten, z.B. eine Angabe darüber, ob der Absender auf einer Liste zugelassener Absender steht, sodass die Nachricht die Antispam-Überprüfung umgehen konnte. Für eine verdächtige Nachricht kann folgender Bericht erscheinen: SID:SenderIDStatus Fail;PCL:PhishingLevel SUSPICIOUS;CW:CustomList;TIME:TimeBasedFeatures
In diesem Beispiel hat die Überprüfung der Sender ID zu einem negativen Ergebnis geführt. Das kann verschiedene Gründe haben: Die angebliche sendende Domäne gibt es nicht (Spammer tarnen sich häufig als nicht existierende Domänen), der Phishing-Wert wird als verdächtig eingestuft, z.B. wegen eingebetteter Weblinks in der Nachricht, das CW-Feld gibt an, dass in der Nachricht ein gesperrtes Wort auftaucht, oder das Feld Time zeigt, dass es zwischen dem angeblichen Sendezeitpunkt der Nachricht und ihrem Empfang auf dem Server eine verdächtige Verzögerung gab. Die meisten Nachrichten werden sehr schnell über das Internet geleitet, aber die Übertragung von Millionen an Spamnachrichten an einen E-Mail-Server kann zu Verzögerungen führen. Weitere Informationen
Einzelheiten über die verschiedenen Felder, die die Antispam-Agents hinzufügen, finden Sie auf http://technet.microsoft.com/de-de/library/aa996878.aspx.
Headerfirewalls Die Ergänzung der normalen Nachrichtenheader um die X-Header ist gewöhnlich eine gute Sache, die Administratoren und Benutzer dann den Pfad der Nachrichten nachvollziehen und erkennen können, was auf dem Weg von Server zu Server geschehen ist. Allerdings möchten Sie Informationen über Ihre Messaginginfrastruktur – z.B. die Namen der E-Mail-Server – nicht an die Öffentlichkeit dringen lassen, da sie von Hackern ausgenutzt werden könnten. Es ist auch möglich, dass Spammer 891
Nachrichtenhygiene
Antispam-Agents von Exchange
Kapitel 14
Nachrichtenhygiene
versuchen, Nachrichten an ihren Schutzvorrichtungen vorbeizuschmuggeln, indem sie Header einfügen, die die angebliche Echtheit der E-Mails bescheinigen. Exchange bietet daher eine »Headerfirewall-Funktion«, um die X-Header-Informationen zu entfernen, wenn eine Nachricht durch einen Connector geht. Die in Exchange Server 2010 vorhandene Headerfirewall verwendet Active Directory-Berechtigungen, um zu bestimmen, welche Headerinformationen entfernt werden und welche unberührt bleiben sollen. Sehen wir uns als Erstes die Active Directory-Berechtigungen für einen Sendeconnector an. Wir können sie mit einem Befehl wie dem folgenden abrufen: Get-SendConnector –Identity 'To Internet via Smart Host' | Get-AdPermission | Select User, ExtendedRights, Deny | Format-Table -AutoSize User ---NT AUTHORITY\ANONYMOUS LOGON CONTOSO\Exchange Servers CONTOSO\Exchange Servers CONTOSO\Exchange Servers CONTOSO\Exchange Servers CONTOSO\Exchange Servers MS Exchange\Partner Servers MS Exchange\Hub Transport Servers MS Exchange\Hub Transport Servers MS Exchange\Hub Transport Servers MS Exchange\Hub Transport Servers MS Exchange\Hub Transport Servers MS Exchange\Edge Transport Servers MS Exchange\Edge Transport Servers MS Exchange\Edge Transport Servers MS Exchange\Edge Transport Servers MS Exchange\Edge Transport Servers MS Exchange\Externally Secured Servers MS Exchange\Externally Secured Servers MS Exchange\Legacy Exchange Servers MS Exchange\Legacy Exchange Servers
ExtendedRights -------------{ms-Exch-Send-Headers-Routing} {ms-Exch-Send-Headers-Organization} {ms-Exch-SMTP-Send-Exch50} {ms-Exch-Send-Headers-Forest} {ms-Exch-Send-Headers-Routing} {ms-Exch-SMTP-Send-XShadow} {ms-Exch-Send-Headers-Routing} {ms-Exch-SMTP-Send-XShadow} {ms-Exch-Send-Headers-Forest} {ms-Exch-Send-Headers-Organization} {ms-Exch-SMTP-Send-Exch50} {ms-Exch-Send-Headers-Routing} {ms-Exch-Send-Headers-Routing} {ms-Exch-SMTP-Send-XShadow} {ms-Exch-Send-Headers-Forest} {ms-Exch-Send-Headers-Organization} {ms-Exch-SMTP-Send-Exch50} {ms-Exch-Send-Headers-Routing} {ms-Exch-SMTP-Send-Exch50} {ms-Exch-SMTP-Send-Exch50} {ms-Exch-Send-Headers-Routing}
Deny ---False False False False False False False False False False False False False False False False False False False False False
Die hier gezeigte Ausgabe ist gekürzt worden, um das Hauptaugenmerk auf die wichtigsten Berichtigungen für unser Thema zu lenken, wobei die Berechtigungen, die uns am meisten interessieren, am Anfang der Liste stehen. Für nicht authentifizierte Verbindungen zu externen Servern verwendet Exchange das Konto NT Authority\Anonymous Logon. Die anderen hier aufgeführten Konten sind für Verbindungen mit der Organisation oder mit Edge-Transport-Servern da, die mit TLS (Transport Layer Security) geschützt sind. Um die Headerinformationen aus Nachrichten zu entfernen, die an externe Server gehen, müssen wir das erweiterte Recht ms_Exch-Send-Headers-Routing für dieses Konto verweigern. Das erreichen wir mit einem Befehl wie dem folgenden: Add-AdPermission –User 'NT Authority\Anonymous Logon' –ExtendedRights 'ms-Exch-Send-Headers-Routing' –Deny
892
Nachdem Sie die neue Verweigerungsberechtigung hinzugefügt haben, müssen Sie den Microsoft Exchange-Transportdienst auf allen Hub-Transport-Servern neu starten, die diesen Sendeconnector verwenden, damit sie die neuen Berechtigungen lesen und in Kraft setzen. Die einzige Angabe über einen Server, die im Header erhalten bleiben, ist der Name des Hub-Transport-Servers, der die Nachricht über den Sendeconnector geschickt hat. Das ist eine sehr vereinfachte Darstellung der Gründe und der Vorgehensweise zur Verwendung der Headerfirewall. Wenn noch Empfangsconnectors hinzukommen und Sie mit Nachrichten von älteren Exchange Server 2003-Organisationen zu tun haben, wird die Sache sehr viel komplizierter. (In diesem Zusammenhang gilt Exchange Server 2007 nicht als eine ältere Version, da auch darin schon eine Headerfirewall eingesetzt werden kann.) Weitere Informationen
TechNet gibt eine gute Darstellung dieses Themas auf http://technet.microsoft.com/de-de/library/ bb232136.aspx.
Verbindungsfilterung Wenn ein SMTP-Remoteserver eine SMTP-Sitzung mit Exchange aufbaut, untersucht der Verbindungsfilter-Agent die von ihm vorgewiesene IP-Adresse, um zu entscheiden, ob die von diesem Server gesendete Nachricht angenommen werden soll. Diese Art der Filterung wird auf alle Verbindungen angewandt, die von nicht authentifizierten SMTP-Servern stammen. Der Agent wird beim Auftreten des Transportereignisses OnConnect ausgelöst, ruft die IP-Adresse ab, die die SMTP-Sitzung ausgelöst hat, und vergleicht sie mit den Einträgen auf der IP-Sperrliste und der IP-Zulassungsliste (um zu entscheiden, ob die Sitzung abgebrochen oder akzeptiert werden soll). Befindet sich die IP-Adresse auf der Sperrliste, akzeptiert Exchange so lange Daten, bis alle Empfängerinformationen vorliegen (die Daten in RCPT TO), um zu ermitteln, ob sich unter den vorgesehenen Empfängern auch solche befinden, die die Verbindungsfilterung umgehen dürfen. Solche Ausnahmen können Sie definieren, um bewusst Spamnachrichten zu empfangen, die Sie dann analysieren und dazu nutzen können, ihre Schutzvorkehrungen zu verbessern. Von der Verarbeitung ausgenommene Empfänger richten Sie mit Set-IPBlockListProvidersConfig (oder in der Exchange-Verwaltungskonsole) ein: Set-IPBlockListProvidersConfig -BypassedRecipients '[email protected]', '[email protected]'
Welche Überprüfungen der Verbindungsfilter-Agent durchführt, bestimmt die Konfiguration der IPSperr- und der IP-Zulassungsliste, die Sie sich mit Get-IPAllowListConfig und Get-IPBlockListConfig ansehen können. Die folgenden Einstellungen zeigen beispielsweise, dass der VerbindungsfilterAgent externe Verbindungen untersucht, aber keine internen. Außerdem können Sie erkennen, dass den Absendern gesperrter Nachrichten ein Unzustellbarkeitsbericht geschickt wird. Diese Einstellungen können Sie mit den Cmdlets Set-IPAllowListconfig und Set-IPBlockListConfig ändern. Get-IPBlockListConfig Name : IPBlockListConfig MachineEntryRejectionResponse : External client with IP address {0} does not have permissions to submit to this server. Visit http://support.microsoft.com/kb/928123
893
Nachrichtenhygiene
Antispam-Agents von Exchange
Kapitel 14
Nachrichtenhygiene
for more information. StaticEntryRejectionResponse : External client with IP address {0} does not have permissions to submit to this server. Enabled : True ExternalMailEnabled : True InternalMailEnabled : False AdminDisplayName : ExchangeVersion : 0.1 (8.0.535.0) Identity : IPBlockListConfig
Bei den meisten Prüfvorgängen für eingehende IP-Verbindungen werden Listen von IP-Adressen bekannter Spammer herangezogen, die von Drittanbietern wie Spamhaus.org unterhalten werden. Solche Echtzeit-Sperrlisten (Real-Time Block Lists, RBLs) sind schon seit Jahren in Gebrauch. Die verschiedenen Listen weisen eine unterschiedliche Genauigkeit und Aktualität auf, sodass Sie den Anbieter mit Bedacht auswählen müssen. Dabei müssen Sie nicht nur auf die Genauigkeit der Daten achten (im Web finden Sie eine Menge Informationen über RBLs), sondern auch darauf, dass der Anbieter schnell auf Anfragen reagiert und eine gewisse Garantie der Verfügbarkeit gibt. Steht eine IP-Adresse auf einer dieser Listen, trennt Exchange wie in den zuvor beschriebenen Fällen die Verbindung. IP-Adressen als Spamquelle
Wenn Sie wissen, dass von bestimmten IP-Adressen Spam ausgeht, können Sie diese Adressen mit Add-IPBlockListEntry in eine Sperrliste aufnehmen. Exchange sieht sich erst diese Sperreinträge an und wendet sich erst dann den RBLs zu. Der folgende Beispielbefehl sorgt dafür, dass ein Bereich von IP-Adressen gesperrt wird, wobei diese Sperrung um 23.59 Uhr am 31. Dezember 2011 ausläuft. Wenn Sie kein Ablaufdatum angeben, verbleibt der Eintrag in der Liste, bis Sie ihn mit Remove-IPBlockListEntry entfernen. Mit Set-IPBlockListEntry können Sie die Einträge in der Liste bearbeiten. Add-IPBlockListEntry -IPRange 192.168.0.1-192.168.0.10 -ExpirationTime "12/31/2011 23:59"
Die Anbieter für IP-Sperr- und IP-Zulassungslisten können Sie in der Exchange-Verwaltungskonsole angeben. Klicken Sie auf den Knoten Organisationskonfiguration, wählen Sie Hub-Transport aus, doppelklicken Sie auf der Registerkarte Antispam auf den Eintrag IP-Sperrlistenanbieter, wechseln Sie in dem daraufhin eingeblendeten Eigenschaftendialogfeld auf die Registerkarte Providers und klicken Sie auf Hinzufügen. Abbildung 14.8 zeigt, wie Sie einen Eintrag für einen solchen Anbieter hinzufügen. Je mehr Anbieter Sie hinzufügen, umso langsamer werden die eingehenden Nachrichten verarbeitet, weshalb es sehr wichtig ist, einen sinnvollen Kompromiss zwischen Schutz und Leistung zu finden. Beschränken Sie sich am besten auf zwei oder höchstens drei Anbieter. Das ist auch eine Kostenfrage, da RBL-Anbieter eine Gebühr für ihre Dienste erheben, wenn Ihre Organisation sehr viele Anfragen pro Trag stellt. Eine solche Gebühr wird gewöhnlich für den regelmäßig aktualisierten Zonentransfer der Anbieterdaten zu einem lokalen DNS-Server verlangt. In der Verwaltunskonsole können Sie auch Provider für IP-Zulassungslisten angeben, die im Grunde genommen die komplementäre Dienstleistung zu den Speerlisten anbieten. In Zulassungslisten stehen IP-Adressen, die bekanntermaßen sicher sind.
894
Antispam-Agents von Exchange
Festlegen von IP-Sperrlistenanbietern
Nachrichtenhygiene
Abbildg. 14.8
Um mit der Verwaltungsshell den Eintrag festzulegen, den Sie in Abbildung 14.8 sehen, verwenden Sie folgenden Befehl: Add-IPBlockListProvider -Name 'Spamhaus' -LookupDomain 'zen.spamhous.org' -Enabled $true -BitmaskMatch $null -IPAddressesMatch @() -AnyMatch $True -Priority '1' -RejectionResponse ''
Mit dem Cmdlet Test-IPBlockListProvider können Sie überprüfen, ob ein Sperrlistenanbieter korrekt funktioniert. Wenn Sie mehrere Blocklistenanbieter verwenden, können Sie sie wie folgt alle auf einmal testen: Get-IPBlockListProvider | Test-IPBlockListProvider –IPAddress xx.xx.xx.xx
Für die einzelnen Anbieter erhalten Sie jeweils ein Ergebnis wie das folgende: RunspaceId Provider ProviderResult Matched
: : : :
3d8ded65-134f-4543-a52f-aaf3e19ea79e Spamhaus {208.73.210.27} True
Das Ergebnis True bedeutet, das der Abgleich der angegebenen IP-Adresse mit der RBL einen Treffer ergeben hat, dass es sich also um die Adresse eines mutmaßlichen Spammers handelt. Wäre dies kein Testlauf, sondern hätte der Verbindungsfilter-Agent diesen Abgleich durchgeführt, hätte das Ergebnis ausgereicht, um die weitere Verarbeitung der Nachricht zu unterbinden.
895
Kapitel 14
Nachrichtenhygiene
Absenderfilterung Der Schutz, den Verbindungsfilter bieten, besteht darin, dass IP-Adressen von bekannten Spammern blockiert werden. Bei der Absenderfilterung werden auch E-Mail-Adressen und Domänen gesperrt, die bekanntermaßen von Spammern genutzt werden. Der Absenderfilter-Agent wird beim Auftreten des Ereignisses OnMailCommand ausgelöst, also wenn die MAIL FROM-Daten der Nachricht eingegangen sind. Er vergleicht die E-Mail-Adresse des Absenders (die er aus den Feldern MAIL FROM und From: der Nachricht bezieht, wobei die beiden Angaben nicht identisch sein müssen und es gerade bei Spam-E-Mails auch nicht sind) mit den Einträgen in einer Liste verbotener Adressen, die der Administrator ausgeschlossen hat. Dabei können Sie einzelne Adressen, aber auch ganze Domänen mit sämtlichen Unterdomänen ausschließen. Abbildung 14.9 zeigt den allgemeinen Aufbau einer solchen Liste blockierter Absender. Sie können auch eine Regel definieren, um Nachrichten zu blockieren, in deren Header keine Absenderangabe steht. Abbildg. 14.9
Eigenschaften des Absenderfilter-Agents
Wenn der Agent unerwünschte Nachrichten erkannt hat, muss er entscheiden, wie er mit ihnen verfahren soll. Es besteht die Möglichkeit, die Nachricht sofort abzulehnen und eine Annahmeverweigerung zurückzusenden oder sie mit dem Vorbehalt anzunehmen, dass sie von einem gesperrten Absender stammt. Der Inhaltsfilter-Agent bezieht diese Tatsache dann in seine Berechnung des SCLWerts ein. Höchstwahrscheinlich ergibt sich dann ein hoher SCL-Wert, sodass die Nachricht im weiteren Verlauf schließlich doch blockiert wird, da sie den SCL-Schwellenwert überschreitet. Mit Get-SenderFilterConfig können Sie sich ansehen, wie der Absenderfilter eingerichtet ist. Vergleichen Sie die Ergebnisse mit den Angaben in Abbildung 14.9. Get-SenderFilterConfig Name BlockedSenders BlockedDomains
896
: SenderFilterConfig : {[email protected]} : {}
Antispam-Agents von Exchange
: : : : : : :
{cohowinery.com} Reject True Reject True True False
Nachrichtenhygiene
BlockedDomainsAndSubdomains Action BlankSenderBlockingEnabled RecipientBlockedSenderAction Enabled ExternalMailEnabled InternalMailEnabled
Um die Konfiguration zu ändern, verwenden Sie Set-SenderFilterConfig. Um beispielsweise eine neue Domäne zu der Sperrliste hinzufügen, geben Sie Folgendes ein: Set-SenderFilterConfig -BlockedDomainsAndSubdomains 'cohowinery.com', 'cohovineyard.com','litwareinc.com'
Zwei Punkte bedienen hier besondere Beachtung. Erstens gibt es einen offensichtlichen Unterscheid zwischen BlockedDomains und BlockedDomainsAndSubdomains: Die erste dieser Eigenschaften sperrt nur die jeweils angegebene Domäne, die zweite auch alle deren Unterdomänen. Wenn Sie mit (ÿ) die verfügbaren Parameter von Set-SenderFilterConfig durchlaufen, kann es schnell passieren, dass Sie diese feine, aber wichtige Unterscheidung nicht erkennen. Zweitens müssen Sie jedes Mal, wenn Sie einen Eintrag für BlockedDomains und BlockedDomainsAndSubdomains hinzufügen, sämtliche Werte angeben. Hier ist man leicht versucht, nur die Domänen oder Absender anzugeben, die der Liste neu hinzugefügt werden sollen, wobei jedoch alle zuvor angegebenen Werte verloren gehen.
Spam-Rücklauf Nachrichten zu blockieren, die nicht über eine Absenderangabe verfügen, ist eine Grundregel der Nachrichtenhygiene, die auch schon seit Jahren angewandt wird. Leider haben Spammer schon vor langer Zeit Wind von dieser Schutzmaßnahme bekommen und daher Absenderadressen in ihre Nachrichten aufgenommen. Das hat dazu geführt, das die empfangenden MTAs (Message Transfer Agents) neue Tests durchführen mussten, um zu überprüfen, ob die angegebene Absenderdomäne tatsächlich gültig ist (Rückruf-Verifizierung). Bei einer ungültigen Absenderadresse wird die Verbindung sofort abgebrochen. Um die Rückruf-Verifizierung zu unterlaufen, haben Spammer damit begonnen, legitime Adressen zu fälschen, die sie abgegrast haben und untereinander verkaufen. Das wiederum hat zum Problem des Spam-Rücklaufs geführt, wobei die Spammer zwei Umstände ausnutzen. Erstens haben sie eine legitime Absenderadresse, die ein MTA akzeptiert, und zweitens ist ihnen bekannt, dass die meisten seriösen MTAs einen Unzustellbarkeitsbericht senden, wenn eine Nachricht aufgrund eines unbekannten Empfängers nicht ausgeliefert werden kann. Spammer senden nun Zehntausende von Nachrichten, die anscheinend von echten Absendern stammen, an eine E-Mail-Domäne. Das Ziel besteht gar nicht darin, diese Nachrichten zuzustellen, sondern dafür zu sorgen, dass Unzustellbarkeitsberichte an die vermeintlichen Absender zurückgehen. Die nicht ahnenden Empfänger finden dann den Unzustellbarkeitsbericht in ihrem Postfach und öffnen ihn, weil sie wissen wollen, warum ihnen ein solcher Bericht für eine Nachricht geschickt wird, die sie nie gesendet haben – und schon lesen sie den Inhalt der unzustellbaren Nachricht. Damit hat der Spammer sein Ziel erreicht, seinen gewünschten Inhalt an tatsächlich existierende Personen auszuliefern, und dabei den Antispamschutz unterlaufen. Für eine Exchange-Organisation stellt sich dabei das Problem, dass das
897
Kapitel 14
Nachrichtenhygiene
Tarnsportsystem dass die Transportserver mit dem Erstellen und Senden der Unzustellbarkeitsberichte fertig werden müssen – und mit der Flut eingehender Unzustellbarkeitsberichte, die durch Spamangriffe auf andere Domänen hervorgerufen werden. Die Sender ID-Filterung hilft hier ein wenig, da sie eine Verifizierung der E-Mail-Server für Domänen erzwingt, aber wie wir in Kürze sehen, werden Sender IDs nicht immer verwendet. Die Lösung besteht häufig in einem Verfahren namens BATV (Bounce Address Tag Verification), bei dem ausgehende Nachrichten mit überprüfbaren Tags versehen werden, um zu bestätigen, dass sie von echten Benutzern kommen. Dadurch soll dem Spam-Rücklauf entgegengewirkt werden. Viele weit verbreitete MTAs wie SendMail, Exim und Postfix führen das BATV-Verfahren durch. Die Antispam-Agents von Exchange Server 2010 enthalten BATV nicht, doch bieten Zusatzprodukte wie Microsoft Forefront Protection for Exchange Server 2010 (FPE) optionale Rücklauffilter, die Sie aktivieren können. Bei FPE ist der Rücklauffilter in Form zweiter Agents implementiert, von denen der eine ausgehende Nachrichten kennzeichnet, während sie das Kategorisierungsmodul durchlaufen, und der andere eingehende Nachrichten untersucht, die von der SMTP-Pipeline verarbeitet werden. Schutzvorkehrungen gegen Spam-Rücklauf sind nicht unbedingt erforderlich, aber Entwicklung von Filtern dagegen ist ein gutes Beispiel für die in Exchange Server 2010 fehlenden Funktionen, die in Zusatzprodukten vorhanden sind und die Sie in Betracht ziehen sollten, wenn es um den Schutz Ihrer Server geht.
Absenderzuverlässigkeit Der Absenderzuverlässigkeitsgrad (Sender Reputation Level, SRL) ist der Wert, den der Absenderzuverlässigkeits-Agent auf der Grundlage von Tests der eingehenden Nachrichten berechnet. Dabei wird geprüft, ob die Reverse-DNS-Daten für einen Absender stimmen, ob der Server, den der Absender verwendet, ein offener Proxy zu sein scheint (also ein Proxyserver, der Verbindungsanforderungen von allen anderen Servern annimmt und SMTP-Datenverkehr so weiterleitet, als würde er auf dem lokalen Hostcomputer entspringen), ob die EHLO- oder HELO-Verbindung korrekt ist (Absender, die viele verschiedene, einmalige EHLO-Befehle verwenden, sind sehr wahrscheinlich Spammer, denn beim regulären Datenverkehr wird meistens durchgängig der gleiche EHLO-Befehl verwendet) und welche SCL-Werte der Inhaltsfilter-Agent von Exchange für vorherige Nachrichten dieses Absenders berechnet hat. Eine Nachricht mit einem hohen SCL-Wert führt dazu, dass der SRL-Wert des Absenders erhöht wird, und umgekehrt. Der resultierende SRL-Wert ist eine Zahl zwischen 0 und 9, wobei ein Wert von 0 eine Wahrscheinlichkeit von unter 1% dafür angibt, dass es sich bei dem Absender um einen Spammer handelt, während ein Wert von 9 mit hoher Wahrscheinlichkeit auf einen Spammer hinweist. Beim Wert 4 schätzt Exchange den Absender neutral ein. (Beachten Sie, dass es zwar »Zuverlässigkeitsgrad« heißt, die Zuverlässigkeit aber umso geringer ist, je höher dieser Wert steigt.) Der Absenderzuverlässigkeits-Agent speichert die erfassten Daten in der Datenbank Pasetting.edb, die sich im Verzeichnis \TransportRoles\Data\Senderreputation befindet. Mit der Zeit kann sich der Zuverlässigkeitsgrad je nachdem verbessern oder verschlechtern, welche Nachrichten von dem Absender ausgehen. Für alle Absender gilt der Anfangswert 0. Nachdem Exchange 20 Nachrichten von einem Absender empfangen hat, beginnt Exchange damit, den SRL zu berechnen. Ausgelöst wird der Agent an zwei Stellen: nach einem MAIL FROM:-Befehl (damit der Agent weiß, von wem die Nachricht anscheinend stammt) und beim Eingang des Befehls für das Datenende (dadurch kennt der Agent auch den SCL, den der Inhaltsfilter-Agent für die Nachricht berechnet hat).
898
Im Eigenschaftendialogfeld des Absenderzuverlässigkeits-Agents (siehe Abbildung 14.10) können Sie für den Agent einen SRL-Schwellenwert angeben, um die Toleranz gegenüber Spam festzulegen. Die Standardeinstellung ist 9, was bedeutet, dass der Ruf eines Absenders schon sehr schlecht sein muss, bevor Exchange ihn sperrt. Ein geringerer Grenzwert kann dazu führen, dass auch Absender blockiert werden, die nicht blockiert werden sollten. Erreicht ein Absender den Grenzwert, kennzeichnet der Absenderzuverlässigkeits-Agent ihn gegenüber dem Absenderfilter-Agent, sodass dieser die zugehörige IP-Adresse vorübergehend zur Liste der blockierten Absender hinzufügen kann, standardmäßig für einen Zeitraum von 24 Stunden. Sie können diese Sperrperiode nach Bedarf kürzer oder länger machen, wobei der Maximalwert 48 Stunden beträgt. Absender, deren IP-Adressen in der SRL-Liste von Microsoft stehen, werden automatisch zur Sperrliste hinzugefügt. Abbildg. 14.10 Eigenschaften der Absenderzuverlässigkeitsfilterung
Weitere Einzelheiten der Konfiguration für die Absenderzuverlässigkeitsfilterung können Sie mit Get-SenderReputationConfig abrufen. Wie Sie sehen können, ist der Agent für externe E-Mails standardmäßig aktiviert und für interne deaktiviert. Get-SenderReputationConfig MinMessagesPerDatabaseTransaction SrlBlockThreshold MinMessagesPerTimeSlice TimeSliceInterval OpenProxyDetectionEnabled SenderBlockingEnabled OpenProxyRescanInterval MinReverseDnsQueryPeriod
: : : : : : : :
20 7 100 48 True True 10 1
899
Nachrichtenhygiene
Antispam-Agents von Exchange
Kapitel 14
Nachrichtenhygiene
SenderBlockingPeriod MaxWorkQueueSize MaxIdleTime Socks4Ports Socks5Ports WingatePorts HttpConnectPorts HttpPostPorts TelnetPorts CiscoPorts TablePurgeInterval MaxPendingOperations ProxyServerName ProxyServerPort ProxyServerType Name MinDownloadInterval MaxDownloadInterval SrlSettingsDatabaseFileName ReputationServiceUrl Enabled ExternalMailEnabled InternalMailEnabled
: : : : : : : : : : : : : : : : : : : : : : :
24 1000 10 {1081, {1081, {23} {6588, {6588, {23} {23} 24 100
1080} 1080} 3128, 80} 3128, 80}
0 None Sender Reputation 10 100
True True False
Die Eigenschaften des Absenderzuverlässigkeits-Agents können Sie mit Set-SenderReputationConfig festlegen. Der folgende Befehl setzt beispielsweise den SRL-Schwellenwert auf 8 und die Sperrdauer auf 36 Stunden: Set-SenderReputationConfig –SrlBlockThreshold 8 –SenderBlockingPeriod 36
Da ein Absender, der den SRL-Schwellenwert übersteigt, auf die Sperrliste gesetzt wird, bestimmt die Konfiguration der Absenderfilterung, wie Exchange mit Nachrichten von solchen Absendern umgeht. Die Standardaktion besteht darin, neue Nachrichten abzulehnen, aber Sie können auch dafür sorgen, dass sie als E-Mails von einem gesperrten Absender gekennzeichnet und dann weitergeleitet werden.
Empfängerfilterung Die Empfängerfilterung ruft die Empfängeradressen aus dem Feld RCTP TO: von eingehenden Nachrichten ab und untersucht sie. Dabei vergleicht der Agent sie mit den vom Administrator definierten Einträgen in der Empfängersperrliste (siehe Abbildung 14.11) und mit Active Directory, um zu bestimmen, ob irgendwelche Maßnahmen erforderlich sind. Meistens wird Exchange so eingerichtet, dass Nachrichten abgelehnt werden, deren Empfänger nicht im Verzeichnis gefunden werden können.
900
Antispam-Agents von Exchange
Nachrichtenhygiene
Abbildg. 14.11 Eigenschaften der Empfängerfilterung
Die Konfiguration des Empfängerfilter-Agents ist sehr einfach, und die meisten Angaben in der Verwaltungsshell können Sie sehr leicht in den Eigenschaften wiederfinden, die in Abbildung 14.11 zu sehen sind. Ausnahmen sind die Eigenschaft Enabled, die bestimmt, ob der Agent aktiv ist, und InternalMailEnabled, die festlegt, ob auch Nachrichten aus authentifizierten Domänen untersucht werden. Meistens ist es am besten, die Standardwerte beizubehalten. Get-RecipientFilterConfig Name BlockedRecipients RecipientValidationEnabled BlockListEnabled Enabled ExternalMailEnabled InternalMailEnabled
: RecipientFilterConfig : {[email protected], [email protected], [email protected], [email protected]} : True : True : True : True : False
Mit Set-RecipientFilterConfig können Sie diese Einstellungen ändern: Set-RecipientFilterConfig -BlockedRecipients '[email protected]', '[email protected]', '[email protected]', '[email protected]'
Teergruben Exchange Server 2010 bietet auch eine Teergruben-Funktion, also die Fähigkeit, die Serverreaktion zu drosseln, wenn mögliche Spamkommunikationsmuster entdeckt werden. Stellen Sie sich vor, von einem Remoteserver aus wird ein Versuch zum Abgreifen von Adressen durchgeführt. Dabei werden Tausende von Adressen an Exchange ausprobiert, um zu sehen, ob Exchange einige davon akzeptiert.
901
Kapitel 14
Nachrichtenhygiene
Dabei stellt der Remoteserver die Adressen gewöhnlich nach einem Muster zusammen, sodass er mehrere mögliche Kombinationen für mögliche Benutzer überprüfen kann. Spammer wollen damit gültige Adressen herausfinden, um sie für eigene Spamaktionen zu verwenden oder an andere Spammer zu verkaufen. Die Teergruben-Funktion verzögert die Antworten von Exchange auf die Anforderungen des externen Servers und verlangsamt so die Kommunikation. Dadurch soll erreicht werden, dass der Remoteserver irgendwann aufgibt, da der Angriff zu lange dauert, und sich leichteren Zielen zuwendet. Mit dem folgenden Befehl können Sie das zurzeit gültige Teergruben-Verzögerungsintervall auf einem Server abrufen: Get-ReceiveConnector | Select Server, TarpitInterval Name ---Default internal receive connector EXEDGE1
TarpitInterval -------------00:00:05
Hier beträgt die Teergruben-Verzögerung fünf Sekunden.
Sender ID Der Sender ID-Agent ist standardmäßig aktiviert. Der zuvor besprochene Absenderfilter-Agent untersucht die MAIL FROM-Angaben der Nachrichten, um Spam zu entdecken, aber Spammer tarnen sich häufig, indem sie die Adressen manipulieren, sodass Sie eine noch eine andere Möglichkeit benötigen, um zu erkennen, ob ein Server, der Ihrem Server eine Nachricht zukommen lassen möchte, wirklich zu einer gültigen Domäne gehört. Hier kommt der Sender ID-Agent ins Spiel, der versucht, die Identität des SMTP-Servers zu bestimmen, der mit Exchange kommunizieren möchte. Die Prüfung erfolgt anhand von DNS-Einträgen, in denen die IP-Adressen der E-Mail-Server angegeben sind, die Nachrichten im Namen einer SMTP-Domäne übermitteln dürfen. Diese bei der Sender ID-Prüfung verwendeten Einträge werden als SPF-Einträge bezeichnet. Wie hat sich das System entwickelt?
Das 2003 von Meng Weng Wong gegründete Projekt Sender Policy Framework (http:// www.openspf.org) bildete den Anstoß für den Versuch, E-Mail-Fälschung durch eine Authentifizierung der E-Mail-Absender zu unterbinden. Ziemlich genau zur selben Zeit startete Microsoft das eigene Projekt CallerID. Es sah so aus, als würden die beiden Konzepte zum Nutzen aller miteinander verschmolzen. Jedoch scheiterte Microsoft damit, die eigene Variante mit dem RFC-Entwurf »MTA authentication records in DNS« (http://tools.ietf.org/html/draft-ietf-marid-core-01) von der Internet Engineering Task Force anerkennen zu lassen, empfahl daraufhin aber weiterhin die Verwendung von Sender ID anstelle von SPF. Zwischen den beiden Implementierungen gibt es praxisrelevante Unterschiede, und zurzeit ist noch kein Plan in Sicht, die Kluft zu überbrücken. Das sollte jedoch nicht vom Kernpunkt ablenken: Es ist eine gute Idee, überprüfen zu können, wer Ihnen einen Nachricht zukommen lässt, und zwar unabhängig davon, ob dies per E-Mail oder per Telefon geschieht. Zur Verarbeitung einer Nachricht führt der Sender ID-Agent folgende Schritte aus:
902
Antispam-Agents von Exchange
Address, PRA), also den vermeintlichen Absender der Nachricht. Dazu werden die folgenden Nachrichtenattribute in der Reihenfolge geprüft, wie schwer sie von einem Spammer gefälscht werden können (der From-Header lässt sich am einfachsten fälschen): a. Resent-Sender-Header b. Resent-From-Header c. Delivered-To-, X-Envelope-To- und Evelope-To-Header d. Sender-Header e. From-Header 2. Der Sender ID-Agent bestimmt dann die angebliche verantwortliche Domäne (Purported
Responsible Domain, PRD) aus der E-Mail-Adresse des Absenders. Scheint die Nachricht von [email protected] zu kommen, dann ist contoso.com die PRD. 3. Der Sender ID-Agent stellt eine DNS-Abfrage, um das »E-Mail-Richtliniendokument« für die PRD zu finden (unter Zuhilfenahme der IP-Adresse des Servers, der die Nachricht übermittelt). Dieses Dokument listet die IP-Adressen der Server auf, die Nachrichten für die PRD senden dürfen. 4. Stimmt die IP-Adresse des übermittelnden SMTP-Servers mit einer der IP-Adressen für die PRD überein, kennzeichnet Exchange die Nachricht mit den Sender ID-Informationen und leitet sie an den Inhaltsfilter-Agent weiter. 5. Gibt es keine Übereinstimmung, ergreift Exchange die Maßnahme, die für den Sender ID-Agent festgelegt ist (siehe Abbildung 14.12). Abbildg. 14.12 Konfiguration des Sender ID-Agents
Während Unternehmen wie IBM, Microsoft und Google SPF-Einträge für ihre Domänen in DNS veröffentlichen, machen andere dies nicht (z.B. General Electric). Es ist interessant, sich das Format der SPF-Einträge verschiedener Firmen anzusehen, um zu erkennen, wie sie ihre Absenderidentität
903
Nachrichtenhygiene
1. Der Sender ID-Agent bestimmt die angebliche verantwortliche Adresse (Purported Responsible
Kapitel 14
Nachrichtenhygiene
im Internet veröffentlichen und daraus zu lernen, wie Sie SPF-Einträge für Ihre eigenen Zwecke formatieren müssen. Hierzu können Sie den Domänennamen für ein Unternehmen in den Microsoft Sender ID Wizard eingeben (siehe Abbildung 14-13) und prüfen lassen, ob es für die Firma SPF-Einträge gibt oder ob sie zur Identifizierung ihrer E-Mail-Server die standardmäßigen A- und MX-Einträge verwendet. Sind SPF-Einträge vorhanden, werden sie auch angezeigt. Damit können Sie sich die die verschiedenen Techniken ansehen, die für diesen Zweck eingesetzt werden, und die in der Praxis verwendeten Einträge mit den theoretischen Richtlinien für ihre Komposition vergleichen. Der SPFEintrag für Google.com lautet beispielsweise wie folgt: v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all
Dagegen ist der SPF-Eintrag für Gmail.com nur eine einfache Umleitung zu Google.com: v=spf1 redirect=_spf.google.com Abbildg. 14.13 Der Microsoft Sender ID Wizard
904
Antispam-Agents von Exchange
Weitere Informationen
Eine Anleitung zum erstellen von SPF-Einträgen für Ihre eigenen Domänen erstellen erhalten Sie auf der Webseite »Sender ID Framework SPF Record Wizard« unter http://www.microsoft.com/ mscorp/safety/content/technologies/senderid/wizard/default.aspx. Da zurzeit noch nicht alle Unternehmen SPF-Einträge veröffentlichen, kann es durchaus sein, dass eine Sender ID-Prüfung nicht zu einem eindeutigen Ergebnis führt. Es gibt folgende mögliche Resultate: 쐍 Pass (Bestanden) Die IP-Adresse des sendenden Servers befindet sich unter den autorisierten Adressen für die PRD. 쐍 Neutral Das Ergebnis ist nicht schlüssig. Möglicherweise hat das Unternehmen keine SPF-Einträge in DNS veröffentlicht. 쐍 SoftFail (möglicher Fehlschlag) zugelassenen Adressen.
Die IP-Adresse befindet sich möglicherweise unter den nicht
쐍 Fail (Fehlschlag) Die IP-Adresse befindet sich unter den nicht zugelassenen Adressen. Die Nachricht stellt daher definitiv ein Problem dar. 쐍 TempError (vorübergehender Fehler) Während der Überprüfung trat ein vorübergehender Fehler auf. Beispielsweise kann es sein, dass es aufgrund eines Netzwerkfehlers nicht möglich war, DNS zu erreichen. 쐍 PermError (dauerhafter Fehler) Es ist ein dauerhafter Fehler aufgetreten. Beispielsweise kann es sein, dass die SPF-Einträge in einem ungültigen Format vorliegen und daher nicht korrekt gelesen werden können. Angesichts dieser Liste möglicher Ergebnisse ist es kein Wunder, dass die Standardaktion für den Sender ID-Agent darin besteht, die Nachrichten einfach mit dem Ergebnis zu kennzeichnen und dann an den Inhaltsfilter-Agent weiterzuleiten, der das Ergebnis der Sender ID-Überprüfung dann in die Berechnung des SCL-Werts für die Nachricht einbezieht. Beispielsweise führt Fail oder SoftFail zu einer Erhöhung des SCL-Werts. Die SCL-Gewichtung, die Exchange den verschiedenen Ergebnissen einer Sender ID-Prüfung zumisst, können Sie nicht beeinflussen. Abbildung 14.12 zeigt die Eigenschaften des Sender ID-Agents, in denen Sie festlegen, welche Aktion durchgeführt werden soll. Bevor Sie von der Standardeinstellung abgehen und verlangen, Nachrichten abzulehnen oder gar zu löschen, sollten Sie sich genau über die Konsequenzen im Klaren sein. Wird eine Nachricht abgelehnt, geht sie mit einem Unzustellbarkeitsbericht an den Absender zurück. Beim Löschen wird sie einfach entfernt, ohne dass der Absender etwas davon erfährt. Es besteht die Gefahr, dass Sie damit völlig korrekte E-Mails verlieren, nur weil ein vorübergehender Fehler wie ein DNS-Ausfall aufgetreten ist. Kluge Administratoren lassen die Nachrichten passieren, um sie vom Inhaltsfilter-Agent weiterverarbeiten zu lassen.
905
Nachrichtenhygiene
Mit der Zeit werden immer mehr Unternehmen SPF-Einträge für ihre Domänen veröffentlichen, doch solange einige der großen Firmen es nicht tun, bleibt die Sender ID-Prüfung Stückwerk.
Kapitel 14
Nachrichtenhygiene
Mit Get-SenderIDConfig können Sie zusätzliche Informationen über die Sender ID-Konfiguration gewinnen: Get-SenderIDConfig SpoofedDomainAction TempErrorAction BypassedRecipients BypassedSenderDomains Name Enabled ExternalMailEnabled InternalMailEnabled AdminDisplayName ExchangeVersion DistinguishedName
: : : : : : : : : : :
StampStatus StampStatus {} {} SenderIdConfig True True False 0.1 (8.0.535.0) CN=SenderIdConfig,CN=Message Hygiene,CN=Transport Settings, CN=contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=contoso,DC=com
In dieser Konfiguration sind zwei Aktionen definiert. Die Maßnahme, die auch in der Verwaltungskonsole angezeigt wird, ist die für SpoofedDomainAction, also für den Fall, dass tatsächlich eine Domäne gefälscht wurde. Sie ist hier auf StampStatus gesetzt, also auf die Markierung der Nachricht, was auch das ist, was wir erwartet haben. Die zweite Aktion ist in der Eigenschaft TempErrorAction definiert, und auch sie ist auf StampStatus eingestellt. Diese Maßnahme führt der Sender ID-Agent für Nachrichten aus, deren Überprüfung einen vorübergehenden Fehler (TempError) ergeben hat. Drei weitere Optionen sind ebenfalls erwähnenswert. Erstens können Sie bis zu 100 Empfängeradressen angeben, für die der Sender ID-Agent keine Verarbeitung vornimmt. Mit dem folgenden Beispielbefehl legen wir drei solcher Empfängerausnahmen fest, wobei die einzelnen Adressen durch Kommata getrennt werden: Set-SenderIDConfig –BypassedRecipients '[email protected],[email protected],[email protected]'
Zweitens können Sie auch bis zu 100 Absenderdomänen festlegen, die der Sender ID-Agent ignoriert: Set-SenderIDConfig –BypassedSenderDomains 'contoso.com,fabrikam.com'
VORSICHT Es ist keine gute Idee, den Sender ID-Agent anzuweisen, Nachrichten aus bestimmten Domänen zu ignorieren. Sie müssen sich schon sehr sicher sein, dass ein Spammer diese Domäne niemals für seine Zwecke missbrauchen wird. Drittens ignoriert der Sender ID-Agent standardmäßig alle Nachrichten aus autorisierenden Domänen innerhalb Ihrer Orgnisation (da anzunehmen ist, dass Sie wissen, woher diese Nachrichten kommen). Sie können die Überprüfung solcher Nachrichten jedoch einschalten: Set-SenderIDConfig –InternalMailEnabled $True
Um zu überprüfen, ob der Sender ID-Agent normal funktioniert, können Sie das Cmdlet Test-SenderID verwenden. Übergeben Sie dazu eine IP-Testadresse und die Domäne, zu der sie gehören soll.
906
Antispam-Agents von Exchange
Nachrichtenhygiene
Im folgenden Beispiel verwenden wir eine der Adressen, von der wir dank des Sender ID Wizard von Microsoft wissen, dass sie zu Google.com gehört: Test-SenderID –IPAddress 216.73.93.70 -PurportedResponsibleDomain Google.com RunspaceId Status FailReason Explanation
: 3d8ded65-134f-4543-a52f-aaf3e19ea79e : Pass : None :
Wie Sie sehen, ist der Test erfolgreich. Google.com verwendet wirklich die IP-Adresse, die im zugehörigen SPF-Eintrag angegeben ist.
Inhaltsfilterung Der Inhaltsfilter-Agent wird als Letzer in der Antispam-Kette ausgeführt. Er baut auf dem Intelligent Message Agent (IMA) auf, den Microsoft zuerst für Exchange Server 2003 SP1 bereitgestellt hat und der dann in den Inhaltsfilter-Agent von Exchange Server 2007 aufgenommen wurde. Sowohl der Inhaltsfilter-Agent als auch der Junk-E-Mail-Agent von Outlook beruhen auf der SmartScreen-Technologie, die ursprünglich von Microsoft Research entwickelt wurde, um das Problem der Spamerkennung zu lösen. Neben den Algorithmen, die der Inhaltsfilter-Agent nutzt, unterhält Microsoft eine Datenbank mit Elementen aus Milliarden von Nachrichten, die das Unternehmen im Laufe der Jahre für seinen Hotmail-Dienst verarbeitet und von Kunden empfangen hat. Anhand dieser Daten kann Microsoft die typischen Merkmale von sowohl seriösen E-Mails als auch von Spam ermitteln und die Antispamalgorithmen kontinuierlich verbessern. Microsoft bringt die SmartScreen-Datenbank regelmäßig auf den neuesten Stand und stellt den Kunden die Aktualisierungen über Microsoft Update zur Verfügung. Der Inhaltsfilter ergänzt die von Microsoft bereitgestellten Daten mit denen, die er aus den Listen sicherer und blockierter Absender der Benutzer gewonnen hat (siehe den Abschnitt »Anlagenfilterung« weiter hinten in diesem Kapitel), um die Überprüfung genauer auf die Art des E-Mail-Verkehrs zuzuschneiden, der in der Organisation eingeht, und damit die Anzahl der Fehlalarme zu verringern. Auf einem Edge-Transport-Server werden die gesammelten Daten aus den Zulassungs- und Sperrlisten in der AD LDS-Datenbank gespeichert, die die Synchronisierungsdaten von den Hub-TransportServern in der Organisation erhält. Läuft der Inhaltsfilter-Agent auf einem Hub-Transport-Server, kann er die Sperr- und Zulassungslistendaten für einen vorgesehenen Empfänger aus Active Directory abrufen. Der Agent berücksichtigt sowohl die SmartScreen-Daten von Microsoft als auch die gesammelten Listendaten der Benutzer, um zu bestimmen, ob eine Nachricht Spam enthält. Findet der Inhaltsfilter-Agent für die Nachricht einen Eintrag in der Liste sicherer Absender, fügt er die Kennzeichnung SenderOnRecipientSafeSendersList zum X-Header X-MS-Exchange-Organization-Antispam-Report hinzu, den Sie sich in den Eigenschaften der Nachrichten ansehen können. Einer der X-Header, die Exchange eingehenden Nachrichten hinzufügt, enthält den SCL-Wert, der vom Inhaltsfilter-Agent berechnet wird und bestimmt, was mit der Nachricht geschehen soll. Abbildung 14.14 zeigt, welche verschiedenen Möglichkeiten es gibt, nachdem der Inhaltsfilter-Agent den SCL-Wert berechnet hat. Die Entscheidungen werden auf dem Hub- bzw. Edge-Transport-Server getroffen, der die Nachricht verarbeitet, und auf dem Postfachserver mit der Datenbank für das Empfängerpostfach. Wenn die Nachrichten in den Posteingang gelangen, können die Clients noch eine
907
Kapitel 14
Nachrichtenhygiene
weitere benutzerdefinierte Verarbeitung durchführen, z.B. durch den Junk-E-Mail-Filter in Microsoft Outlook und Outlook Web App. Wie Sie diese Entscheidungen mithilfe der SCL-Schwellenwerte beeinflussen, erfahren Sie in Kürze. Abbildg. 14.14 Weiterverarbeitung einer Nachricht aufgrund ihres SCL-Werts
Zum Quarantänepostfach senden InhaltsfilterAgent Eingehender Nachrichtenstream
SmartScreenDaten und Zulassungsund Sperrlisten der Benutzer Hub-/EdgeTransport-Server
Ablehnen und mit Unzustellbarkeitsbericht an den Absender
Postfach »Redmond, Tony« Posteingang Organisationsund postfachspezifische SCL-Schwellenwerte
Nachrichten werden im Posteingang oder im Junk-E-Mail-Ordner platziert Junk-E-Mail
Postfachserver
Nachricht löschen
HINWEIS Von allen Antispam-Agents stellt der Inhaltsfilter-Agent die meisten Ansprüche an die Berechnungsressourcen, da er so viele Merkmale einer Nachricht überprüfen muss. Da Exchange ihn als letzten ausführt, wird die Last jedoch dadurch verringert, so dass er nur die Nachrichten verarbeiten muss, die die anderen Agents wie den Verbindungs- und den Empfängerfilter passiert haben. Zum Aufspüren von verdächtigen Nachrichten können Sie nicht nur die SmartScreen-Spamheuristiken von Microsoft nutzen, sondern auf der Registerkarte Benutzerdefinierte Wörter des Eigenschaftendialogfelds der Inhaltsfilterung auch selbst Begriffe und Wendungen eingeben, deren Vorhandensein dazu führt, dass eine Nachricht blockiert oder zugelassen wird (siehe Abbildung 14.15). Seien Sie sehr vorsichtig bei den Wörtern, die eine Blockierung veranlassen, denn möglicherweise sind Begriffe, die in einem gewissen Zusammenhang verdächtig sind, in einem anderen völlig natürlich. Internationale Unternehmen müssen besonders achtsam sein, da hier noch das Problem hinzukommet, dass in Wort in verschiedenen Sprachen eine ganz unterschiedliche Bedeutung aufweisen kann. So kann das Wort »Mist« zwar einen milden Kraftausdruck bedeuten, ist im Gartenbedarfshandel aber alltäglich und bezeichnet im Englischen etwas so Harmloses wie feinen Nebel. Sowohl der Nachrichtentext als auch der Header werden auf das Vorhandensein dieser Wörter geprüft. Die zugelassenen Wörter haben dabei Vorrang vor den gesperrten, sodass der Inhaltsfilter Nachrichten durchlässt, die verbotene Wörter enthalten, wenn sie gleichzeitig auch erlaubte umfassen. Auch Nachrichten, die von einer Person auf der Liste der sicheren Absender des Empfängers stammen, werden beim Vorhandensein ausgeschlossener Wörter trotzdem zugestellt. Schließlich hat der Empfänger bewusst entschieden, dass er Nachrichten von diesem Absender erhalten möchte, und sollte daher in der Lage sein, mit ansonsten beanstandenswerten Inhalten umzugehen. Allerdings wird die Nachricht in einem solchen Fall nicht an eventuelle andere Empfänger zugestellt. Auf der Registerkarte Ausnahmen des Eigenschaftendialogfelds können Sie außerdem Empfänger angeben, deren Nachrichten grundsätzlich nicht durch den Inhaltsfilter-Agent überprüft werden. 908
Antispam-Agents von Exchange
Nachrichtenhygiene
Abbildg. 14.15 Hinzufügen verbotener Wörter im Inhaltsfilter-Agent
Insidertipp: Inhaltsfilterung nur für Nachrichten unter 11 MB
Nachrichten mit einer Größe von mehr als 11 MB werden vom Inhaltsfilter-Agent nicht untersucht. Die standardmäßig in Empfangsconnectors definierte Maximalgröße für Nachrichten beträgt 10 MB, weshalb eine 11 MB große E-Mail von Exchange ohnehin nur dann angenommen wird, wenn die Organisation eigens für den Umgang mit so umfangreichen Nachrichten eingerichtet ist. Es ist auch nicht davon auszugehen, dass Spammer und Personen, die Viren verbreiten möchten, extrem große Anhänge verwenden, da dies die Nachrichtenübertragung stark verlangsamen würde.
SCL-Schwellenwerte Wie bereits erwähnt, gibt der Inhaltsfilter-Agent einen SCL-Wert für die Nachricht aus, der zu ihren MAPI-Eigenschaften hinzugefügt wird. Dieser Wert liegt zwischen 0 und 9, wobei 0 bedeutet, dass die Nachricht kein Spam ist, und 9, dass es sich um Spam handelt. Der besondere Wert -1 zeigt an, dass die Nachricht von einer vertrauenswürdigen internen Quelle stammt. Welche Maßnahmen der Inhaltsfilter-Agent ergreift, nachdem er den SCL-Wert ermittelt hat, können Sie festlegen, indem Sie auf der Registerkarte Aktion seines Eigenschaftendialogfelds drei verschiedene Schwellenwerte angeben (siehe Abbildung 14.16). 쐍 Löschen Die Nachricht wird gelöscht, wenn ihr SCL-Wert den dafür vorgesehenen Schwellenwert erreicht oder überschreitet. Der E-Mail-Server, von dem sie stammt, enthält keine Benachrichtigung. Liegt der SCL-Wert unter dem Schwellenwert für den Löschvorgang, wird überprüft, ob er den Schwellenwert für eine Ablehnung erreicht. 쐍 Ablehnen Erreicht oder überschreitet der SCL-Wert einer Nachricht den Ablehnungsschwellenwert, wird sie gelöscht, und Exchange sendet eine Unzustellbarkeitsbenachrichtigung an den Ursprungsserver. Der Grund für diese Maßnahme besteht darin, dass der Absender durch diese Benachrichtigung darüber informiert wird, dass seine Nachricht als Spam eingestuft wurde. 909
Kapitel 14
Nachrichtenhygiene
Wenn es sich um eine völlig korrekte E-Mail handelt, kann der Absender dann den Inhalt entsprechend anpassen und die Nachricht erneut senden (oder darum bitten, seinen Namen zur Liste der sicheren Absender hinzuzufügen). Liegt der SCL-Wert unterhalb der Ablehnungsschwelle, wird er mit dem Quarantänegrenzwert verglichen. Abbildg. 14.16 Festlegen der Aktionen des Inhaltsfilter-Agents
쐍 Isolieren: Erreicht oder überschreitet der SCL-Wert einer Nachricht den Isolierschwellenwert, wird sie in ein besonderes Quarantänepostfach gesendet. Es muss sich dabei nicht um ein Exchange-Postfach handeln. Die einzige Voraussetzung ist, dass Exchange die Nachricht an die betreffende Adresse senden kann, da sie anderenfalls gelöscht wird. Die Administratoren können sich die Nachrichten, die in diesem Postfach gelandet sind, von Zeit zu Zeit ansehen (am besten täglich), um zu prüfen, ob die SCL-Schwellenwerte angemessen sind. Beachten Sie, dass Nachrichten, die in einem Qurantänepostfach ankommen, wie Unzustellbarkeitsberichte aussehen. Um sich ihren Inhalt anzusehen, müssen Sie sie in Outlook öffnen und die Option zum erneuten Senden verwenden. Da die Nachrichten, die ins Quarantänepostfach gelangen, durchaus vertrauliche und sensible Informationen enthalten können, müssen Sie sehr vorsichtig dabei sein, den Zugriff auf dieses Postfach zu erlauben, und auch Anweisungen dafür geben, wie mit den Inhalten darin zu verfahren ist. Insidertipp: Es ist ein Drahtseilakt
Um sinnvolle SCL-Schwellenwerte zu setzen, müssen Sie einen Kompromiss zwischen einem sehr hohen Schutz vor Spam (Benutzer beschweren sich sehr schnell, wenn sie große Mengen an Spam erhalten) und der Vermeidung von Fehlalarmen finden. Außerdem ist es nicht sehr hilfreich, wenn Sie den Isolierschwellenwert so niedrig ansetzen, dass eine große Menge an Nachrichten im Quarantänepostfach landet, wo sie erst auf eine Überprüfung durch den Administrator warten müssen, bevor sie an die eigentlichen Zieladressen weitergeleitet werden können. Es sind sicherlich mehrere Versuche und Korrekturen nötig, bis sie eine sinnvolle Einstellung für die Bedürfnisse Ihrer Organisation gefunden haben. 910
Antispam-Agents von Exchange
Mit Set-Mailbox können SCL-Schwellenwerte auch für einzelne Postfächer einrichten. Eine solche Maßnahme eignet sich beispielsweise für Benutzer, die sich darüber beschweren, dass sie zu viel Spam erhalten. Um für ein einzelnes Postfach strengere SCL-Schwellenwerte festzulegen und die Standardeinstellung von 9 (Löschen), 8 (Ablehnen) und 7 (Isolieren) auf 8, 6 und 5 zu reduzieren, verwenden Sie folgenden Befehl: Set-Mailbox –Identity TRedmond –SCLDeleteEnabled $True –SCLDeleteThreshold 8 -SCLRejectEnabled $True –SCLRejectThreshold 6 –SCLQuarantineEnabled $True –SCLQuarantineThreshold 5
Alle bisher besprochenen Schwellenwerte gelten für die Verarbeitung durch den Inhaltsfilter-Agent. Nachrichten mit SCL-Werten unterhalb des Isoliergrenzwerts können den Hub- bzw. Edge-Transport-Server verlassen und werden zu den Zielpostfächern weitergeleitet. Der nächste Schritt der Antispamverarbeitung besteht darin, dass der Postfachserver entscheidet, ob die Nachricht im Posteingang zugestellt oder im Junk-E-Mail-Ordner abgelegt werden soll. Exchange verfügt über einen organisationsweit gültigen SCL-Schwellenwert, der den Postfachservern sagt, wie mit potenziellen Spamnachrichten zu verfahren ist, wenn für ein Postfach keine eigenen Schwellenwerte festgelegt sind. Der Standardgrenzwert beträgt 4, sodass alle Nachrichten mit einem SCL-Wert von 5 oder höher in den Junk-E-Mail-Ordner geleitet werden und nicht in den Posteingang. Diesen Grenzwert können Sie mit Set-OrganizationConfig ändern. Wenn Sie beispielsweise folgenden Befehl ausführen, stellen die Postfachserver alle Nachrichten mit einem SCL-Wert größer als 5 in den Junk-E-MailOrdner: Set-OrganizationConfig –SCLJunkThreshold 5
Sie können jedoch mit Set-Mailbox auch einen Schwellenwert für ein einzelnes Postfach festlegen: Set-Mailbox –Identity TRedmond –SCLJunkEnabled $True –SCLJunkThreshold 6
Insidertipp: Umgang mit den Postfächern der Geschäftsleitung
Es ist auch möglich, ein Postfach so einzurichten, dass es bei der Antispamverarbeitung ignoriert wird. Alle Nachrichten an ein Postfach, dessen Eigenschaft AniSpamBypassEnabled auf $True gesetzt ist, umgehen den Inhaltsfilter-Agent. Um zu verhindern, dass ein solches Postfach mit Spam überflutet wird, aktivieren Administratoren häufig die Eigenschaft RequireSenderAuthenticationEnabled, sodass das Postfach keine Nachrichten von Absendern empfängt, die sich in Exchange nicht authentifizieren. Das ist eine wirkungsvolle Möglichkeit, um die Postfächer der Geschäftsführung vor Spam zu schützen, allerdings können dadurch Nachrichten von Drittanbietern verloren gehen, die für die Geschäftsführer interessant sein mögen, aber nicht zugestellt werden, wenn keine Authentifizierung stattfindet. Eine Lösung für dieses Problem besteht darin, für jedes Mitglied der Geschäftsführung zwei Postfächer einzurichten. Das eine hat eine öffentliche E-Mail-Adresse und wird von einer Sekretärin überwacht, das andere ist für die interne Kommunikation da, wird moderiert und nimmt keine Nachrichten von nicht authentifizierten Absendern entgegen. Mit dem folgenden Befehl sorgen Sie dafür, das ein Postfach von der Antispamprüfung ausgeschlossen wird, aber gegen Nachrichten von nicht authentifizierten Absendern gesperrt ist: Set-Mailbox –Identity CEOMailbox –RequireSenderAuthenticationEnabled $True -AntiSpamBypassEnabled $True
911
Nachrichtenhygiene
SCL-Schwellenwerte für einzelne Postfächer
Kapitel 14
Nachrichtenhygiene
Verwalten des Inhaltsfilter-Agents mit der Exchange-Verwaltungsshell Wie alle anderen Objekte in Exchange können Sie auch die Eigenschaften des Inhaltsfilter-Agents in der Verwaltungsshell abrufen und ändern. Mit dem folgenden Befehl listen Sie die zurzeit gültigen Eigenschaften des Agents auf. Auf einem Hub-Transport-Server handelt es sich dabei um organisationsweite Einstellungen, auf einem Edge-Transport-Server um serverspezifische. Get-ContentFilterConfig Name RejectionResponse OutlookEmailPostmarkValidationEnabled BypassedRecipients QuarantineMailbox SCLRejectThreshold SCLRejectEnabled SCLDeleteThreshold SCLDeleteEnabled SCLQuarantineThreshold SCLQuarantineEnabled BypassedSenders BypassedSenderDomains Enabled ExternalMailEnabled InternalMailEnabled AdminDisplayName ExchangeVersion DistinguishedName
Identity
: : : : : : : : : : : : : : : : : : :
ContentFilterConfig Message rejected as spam by Content Filtering. True {} [email protected] 8 True 9 True 7 True {} {} True True True
0.1 (8.0.535.0) CN=ContentFilterConfig,CN=Message Hygiene, CN=Transport Settings,CN=contoso, CN=Microsoft Exchange,CN=Services, CN=Configuration,DC=contoso,DC=com : ContentFilterConfig
Standardmäßig verarbeitet der Inhaltsfilter-Agent nur Nachrichten, die von externen Absendern aus in eine Organisation gelangen. Sie können jedoch auch die Verarbeitung interner Nachrichten erzwingen, indem Sie -InternalMailEnabled mit Set-ConentFilterConfig auf $True setzen: Set-ContentFilterConfig –InternalMailEnabled $True
Eine weitere häufige Anpassung des Inhaltsfilter-Agents besteht darin, die Antwort zu ändern, die zurückgesendet wird, wenn eine Nachricht bei der Filterung entfernt wird. Der DSN-Code für diese Nachricht lautet 5.7.1, und Sie können Exchange anwesen, jeden beliebigen Text (bis zu 240 Zeichen) darin zu verwenden: Set-ContentFilterConfig –RejectionResponse 'Diese Nachricht ist offensichtlich Spam. Wieso schicken Sie uns so etwas?'
912
Antispam-Agents von Exchange
Nachrichtenhygiene
Auf die verbotenen Wörter und Wendungen, nach denen der Inhaltsfilter-Agent sucht, können Sie mit Get-ContentFilterPhrase zugreifen: Get-ContentFilterPhrase RunspaceId Influence Phrase Identity IsValid
: : : : :
3d8ded65-134f-4543-a52f-aaf3e19ea79e BadWord reich werden reich werden True
Mit Add-ContentFilterPhrase können Sie neue Begriffe hinzufügen, mit Remove-ContentFilterPhrase auch wieder entfernen. Es gibt jedoch kein Cmdlet, um einen vorhandenen Begriff zu ändern, weshalb Sie dazu zunächst den alten Eintrag entfernen und dann die neue Version hinzufügen müssen: Remove-ContentFilterPhrase –Identity 'tolle Investition' –Force Add-ContentFilterPhrase –Identity 'fantastische neue Investition' –Influence BadWord
Verwenden von SCL-Werten in Transportregeln Sie können Transportregeln aufstellen, die eine Nachricht aufgrund der ihr zugewiesenen SCL-Werte weiterverarbeiten. Beispielsweise können Sie dadurch die Betreffzeile mit einer Angabe wie SPAM>>> ergänzen, um den Empfänger darauf hinzuweisen, dass es sich möglicherweise um eine Spam-E-Mail handelt. Der Regel-Agent darf dazu natürlich erst dann ausgeführt werden, nachdem der InhaltsfilterAgent seine Bewertung der Nachrichten abgeschlossen und sie mit SCL-Werten gekennzeichnet hat. Auf einem Edge-Transport-Server wird der Regel-Agent jedoch standardmäßig vor dem InhaltsfilterAgent ausgeführt, weshalb die Transportregeln gar nicht auf die SCL-Werte zurückgreifen können. Die Lösung besteht darin, dem Inhaltsfilter-Agent in der Transportpipeline eine höhere Priorität zu geben als dem Transportregel-Agent und damit deren Reihenfolge zu vertauschen. Das erreichen Sie mit dem folgenden Befehl: Set-TransportAgent 'Content Filter Agent' -Priority 3
Anlagenfilterung Der Anlagenfilter-Agent läuft nur auf Edge-Transport-Servern, um Anhänge abzufangen, die er aufgrund ihrer Dateinamenerweiterung, ihres MIME-Typs oder Dateinamens als verdächtig einstuft. Es gibt keinen offensichtlichen Grund dafür, dass der Anlagenfilter-Agent nicht auf einem internen Hub-Transport-Server ausgeführt werden kann. Es bestünde dabei höchstens die Gefahr, dass eine übereifrige Anwendung dieses Filters viele Anhänge der Nachrichten entfernen könnte, die zwischen internen Empfängern ausgetauscht erden. Dieser Agent unterscheidet sich von den anderen, da der Zugriff auf ihn nur über die Verwaltungsshell möglich ist, und zwar mit den Cmdlets Get-AttachmentFilterEntry und Add-AttachmentFilterEntry. Überdies werden die Aktionen dieses Agents nicht im Agentprotokoll festgehalten. Die von
913
Kapitel 14
Nachrichtenhygiene
Microsoft aufgestellte Standardliste zu blockierender Anhänge ist lang, da Hacker schon viele verschiedene Versuche unternommen haben, die Unachtsamkeit der Empfänger auszunutzen. Mit dem folgenden Befehl können Sie sich einen Überblick über die Anhangstypen verschaffen, die der Agent zurzeit abfängt (die hier gezeigte Ausgabe ist gekürzt, da die Liste wirklich sehr lang ist): Get-AttachmentFilterEntry | Format-List Type, Name -AutoSize Type ---ContentType ContentType ContentType ContentType ContentType ContentType ContentType ContentType ContentType ContentType FileName FileName FileName FileName FileName FileName FileName
Name ---application/x-msdownload message/partial text/scriptlet application/prg application/msaccess text/javascript application/x-javascript application/javascript x-internet-signup application/hta *.xnk *.wsh *.wsf *.wsc *.vbs *.vbe *.vb
Dieser Auszug macht deutlich, dass Exchange keine Nachrichten passieren lässt, deren Anhänge ausführbaren Code enthalten. Der Anlagenfilter-Agent kann die Dateitypen auch dann erkennen, wenn die Erweiterung geändert wurde (z.B. von VBS in TMP). Außerdem überprüft er komprimierte Dateien (z.B. im ZIP-Format), um festzustellen, ob die darin enthaltenen Dateien blockiert werden sollten. Die Liste der zu blockierenden Dateien können Sie mit Add-AttachmentFilterEntry ergänzen, um bestimmte Dateinamen oder alle Dateien eines bestimmten Typs oder MIME-Inhaltstyps auszuschließen. Um beispielsweise die Datei ILoveYou.docx zu blockieren, verwenden Sie folgenden Befehl: Add-AttachmentFilterEntry –Name 'ILoveYou.docx' –Type FileName
Der Befehl zur Sperrung sämtlicher Dateien eines bestimmten Typs lautet wie folgt: Add-AttachmentFilterEntry –Name '*.ttx' –Type FileName
Bei der Blockierung bestimmter MIME-Typen müssen Sie ein wenig anders vorgehen. Der folgende Befehl schließt alle MEPG-Videodateien aus: Add-AttachmentFilterEntry -Name 'video/mpeg' -Type ContentType
914
Antispam-Agents von Exchange
Eine vollständige Liste der MIME-Inhaltstypen finden Sie auf http://www.iana.org/assignments/ media-types/index.html. Wollen Sie einen Eintrag von der Liste entfernen, verwenden Sie dazu Remove-AttachmentFilterEntry: Remove-AttachmentFilterEntry –Name 'video/mpeg'
Mit Get-AttachmentFilterListConfig können Sie weitere Informationen über den Anlagenfilter abrufen. Unter anderem können Sie damit erfahren, welche Aktion standardmäßig ausgeführt wird, wenn der Filter einen verdächtigen Anhang entdeckt. In der folgenden Ausgabe sehen Sie die Angabe Strip für die Aktion, was bedeutet, dass Exchange den Anhang entfernt und die Nachricht weiterleitet, ohne dem Benutzer einen Hinweis darauf zu geben, was geschehen ist. Get-AttachmentFilterListConfig Name : Transport Settings RejectResponse : Message rejected due to unacceptable attachments AdminMessage : This attachment was removed. Action : Strip ExceptionConnectors : {} AttachmentNames : {ContentType:application/x-msdownload, ContentType:message/partial, ContentType:text/scriplet, ContentType:application/prg, ContentType:application/msaccess, ContentType:text/javascript, ContentType:application/x-javascript, ContentType:application/javascript, ContentType:x-internet-signup, ContentType:application/hta, FileName:*.xnk, FileName:*.wsh, FileName:*.wsf, FileName:*.wsc, FileName:*.vbs, FileName:* .vbe...}
Sie können die Aktion in Reject ändern (die Nachricht wird gelöscht und der Absender erhält einen Unzustellbarkeitsbericht) oder in SilentDelete (die Nachricht wird gelöscht, ohne dass ein Unzustellbarkeitsbericht gesendet wird). Im ersten Fall können mit durch eine Änderung der Eigenschaft RejectResponse eine selbst formulierte Erklärung für den Absender in bis zu 240 Zeichen verfassen. Betrachten Sie dazu das folgende Beispiel: Set-AttachmentFilterListConfig –Action 'Reject' –RejectResponse 'Die Contoso Corporation nimmt Anhänge dieses Typs nicht an.'
HINWEIS In der Aktion Strip entfernte Anhänge werden sofort gelöscht. Selbst Administratoren können nicht mehr darauf zugreifen, um z.B. die Wirksamkeit der Blockierung zu überprüfen. Es gibt hier noch zwei weitere bemerkenswerte Eigenschaften. AdminMessage enthält den Text, den Exchange in eine Nachricht einfügt, wenn der Anhang entfernt und die E-Mail ohne ihn an den Empfänger weitergeleitet wird. In ExceptionConnectors sind die global eindeutigen Bezeichner (GUIDs) aller Conenctors vermerkt, die sie von der Anlagenfilterung ausnehmen möchten. Wenn ein Connector z.B. für E-Mails von einem vertrauenswürdigen Partner zuständig ist, die Informationen in einem unter anderen Umständen gesperrten Formt enthalten (z.B. Videodateien), können Sie ihn damit von der Anlagenfilterung ausnehmen.
915
Nachrichtenhygiene
Weitere Informationen
Kapitel 14
Nachrichtenhygiene
Adressumschreibung Der Adressumschreibungs-Agent kann nur auf einem Edge-Transport-Server ausgeführt werden. Er soll Nachrichten abfangen und die RCPT TO-Adressen der eingehender E-Mails bzw. die MAIL FROM-Adressen der ausgehenden umschreiben. Diese Funktion entspricht grob der Tokenersetzung, die U*X-E-Mail-Systeme wie SendMail durchführen. Manche Organisationen möchten ihre internen E-Mail-Adressen nicht nach außen dringen lassen, und geben ihren Benutzern daher Adressen, mit denen die Nachrichten bis zur Grenze der Organisation gelangen, aber nicht weiter. Der Adressumschreibungs-Agent ändert dann den Header der ausgehenden Nachrichten, sodass sie außerhalb der Organisation die öffentlich sichtbaren Adressen enthalten. Ebenso werden eingehende Nachrichten bei ihrem Weg in die Organisation vom Adressumschreibungs-Agent abgefangen, um die Adressen zu erhalten, die für die interne Zustellung erforderlich sind. Der erste Schritt besteht darin, den Adressumschreibungs-Agent zu aktivieren. Es gibt zwei Varianten dieses Agents, eine für eingehende und eine für ausgehende Nachrichten. Sie können einen oder beide davon aktivieren: Enable-TransportAgent –Identity 'Address Rewriting Inbound Agent' Enable-TransportAgent –Identity 'Address Rewriting Outbound Agent'
Anschließend müssen Sie den Exchange-Transportdienst neu starten. Danach können Sie damit beginnen, Umschreibungseinträge hinzuzufügen, um das Vorgehen des Agents zu steuern. Ein solcher Eintrag nennt eine einzelne E-Mail-Adresse oder eine ganze Domäne und gibt an, wie die betreffenden Adressen umgeschrieben werden sollen. Es gibt keine grafische Benutzeroberfläche für die Umschreibungsregeln, sodass sie alles mit den Cmdlets New-, Get-, Set- und Remove-AddressRewriteEntry erledigen müssen. Sofern nicht anders angegeben, werden die Regeln sowohl auf ein- als auch auf ausgehende Nachrichten angewendet. Nehmen wir beispielsweise an, dass Ihre Benutzer öffentlich sichtbare Adressen folgender Art haben: [email protected]
Intern jedoch trägt das Postfach die Bezeichnung [email protected]. Die erste Form lässt sich natürlich leichter merken und macht sich auch auf Visitenkarten besser. Um den Adressumschreibungs-Agent anzuweisen, wie er mit dieser Adresse verfahren soll, erstellen wir folgenden Umschreibungseintrag: New-AddressRewriteEntry –Name "John Smith External" –InternalAddress '[email protected]' [email protected]" -ExternalAddress [email protected]
Die internen Adressen, die Sie angeben, müssen in der Exchange-Organisation vorhanden sein, damit Exchange die Nachrichten weiterleiten kann. Die Adressumschreibungseinträge auf diese Weise zu erstellen und zu pflegen, ist offensichtlich eine mühselige Arbeit, wenn Sie nicht nur einige wenige Einträge dieser Art haben. Daher können Sie auch Adressumschreibungseinträge für ganze Domänen erstellen. So etwas kann z.B. nötig sein, wenn ein Unternehmen von einem anderen aufgekauft wird. Dabei kann es vorkommen, dass die Benutzer weiterhin die E-Mail-Adressen ihrer alten Firma verwenden, dass diese Adressen aber aus ausgehenden Nachrichten entfernt und durch den Domänennamen der neuen Firma ersetzt werden. Betrachten Sie dazu das folgende Beispiel: New-AddressRewriteEntry 'Transform Contoso to Fabrikam' –InternalAddress '*.contoso.com'
916
Antispam-Agents von Exchange
Dieser Umschreibungseintrag gilt nur für ausgehende Nachrichten (-Outbound ist $True), betrifft aber sämtliche Unterdomänen von contoso.com. Wenn Sie einzelne Domänen von einer Umschreibungsregel ausnehmen müssen, geben Sie deren Namen im Parameter -ExceptionList dieses Cmdlets an. TIPP Denken Sie daran, dass Sie alle Änderungen, die Sie an der Konfiguration eines Edge-Transport-Servers vornehmen, auf alle anderen Edge-Transport-Server kopieren müssen. Das ist vor allem bei Einstellungen zu Dingen wie Benutzeradressen sehr wichtig. Es kann vorkommen, dass der Adressumschreibungs-Agent die Adressen einiger Nachrichten nicht bearbeiten kann, da sie verschlüsselt, digital signiert oder durch eine Rechteverwaltung geschützt sind. Eine Änderung könnte die digitale Integrität gefährden oder die resultierende Nachricht unlesbar machen. In solchen Fällen nimmt der Agent keine Änderung vor, sondern reicht die Nachricht so weiter, wie sie bei ihm eingegangen ist.
Agentprotokolle Exchange erfasst die Ergebnisse der Agentverarbeitung in Protokolldateien, die nach dem Muster AgentLog<JJJJMMDD-#>.log benannt sind und im Verzeichnis \Programme\Microsoft\Exchange Server\V14\TransportRoles\Logs\AgentLog gespeichert erden. Die Protokolle werden täglich erstellt und 30 Tage lang aufbewahrt oder so lange, bis das Verzeichnis 250 MB an Protokolldaten enthält. Nachdem 10 MB Daten erfasst sind, wird ein neues Protokoll angelegt. Die Einträge in diese Protokolle schreiben der Verbindungsfilter-, der Inhaltsfilter-, der Edge-Regel-, der Empfängerfilter-, der Absenderfilter- und der Sender ID-Agent. Wie die anderen von Exchange Server 2010 erstellten Protokolle werden auch die Agentprotokolle im CSV-Format gespeichert. Abbildung 14.17 zeigt, wie diese Protokolle in Microsoft Excel aussehen und welche Arten von Informationen Sie darin finden. In diesem Fall kommen die Daten vom Inhaltsfilter-Agent. Hier können Sie sehen, dass einige Nachrichten als Spam eingestuft wurden (der SCL-Wert beträgt 9), andere weitergeleitet wurden, da sie mit hoher Wahrscheinlichkeit kein Spam sind (SCL-Werte 2 und 1), und wiederum andere aufgrund der Postfacheinstellungen (z.B. der Eigenschaft AntiSpamBypassEnabled) den Inhaltsfilter-Agent umgangen haben. Sie können außerdem erkennen, welche Maßnahmen der Agent eingeleitet hat: Er hat eine Nachricht gelöscht und bei einer anderen mindestens einen Empfänger entfernt. Letzteres geschieht, wenn der Agent eine Nachricht an einen Empfänger ausliefern kann, obwohl der SCL-Grenzwert überschritten ist, da sich der Urheber auf der Liste sicherer Absender des betreffenden Empfängers befindet. Die Nachricht wird daher diesem Empfänger zugestellt, nicht aber zu den anderen. Mit dem Cmdlet Get-AgentLog können Sie die Agentprotokolle einsehen, um sich eine Vorstellung davon zu machen, welche Schritte die Agents bei der Verarbeitung von Nachrichten durchführen. Um z.B. herauszufinden, welche Nachrichten gelöscht wurden, weil sie den entsprechenden SCL-Schwellenwert überschritten haben, durchsuchen Sie das Agentprotokoll wie im Folgenden Angegeben. Als Ausgabe erhalten Sie die Nachrichtenkennung, die P1-Information (Header) für den Absender und die Empfänger. Geben Sie ein Anfangs- und ein Enddatum für die Suche an, da sie sich sonst die Einträge für sämtliche Nachrichten durchforsten müssen, die in den letzten 30 Tagen gelöscht wurden. Get-AgentLog –StartDate '03/10/2011 07:00AM' –EndDate '03/10/2011 09:00AM' | Where {$_.Reason –eq 'SCLAtOrAboveDeleteThreshold'} | Select MessageId, P1FromAddress, Recipient
917
Nachrichtenhygiene
–ExternalAddress 'fabrikam.com' –Outbound $True
Kapitel 14
Nachrichtenhygiene
Abbildg. 14.17 Anzeige eines Agentprotokolls
Das Cmdlet Get-AgentLog bringt keine großartigen Filtermöglichkeiten mit. Um herauszufinden, was mit einer bestimmten Nachricht geschehen ist, müssen Sie den Datumsbereich festlegen und dadurch die Anzahl der zu durchsuchenden Einträge begrenzen. Anschließend filtern Sie die Ausgabe anhand der Nachrichtenkennung oder eines anderen eindeutigen Wertes. Wenn Sie beispielsweise nach einer Nachricht eines bestimmten Absenders forschen, die nie angekommen ist, verwenden Sie als Filter das Feld P1From Address. Get-AgentLog –StartDate '01/01/2011 03:00PM' –EndDate '01/01/2011 03:15PM' | Where {$_.P1FromAddress –eq '[email protected]'}
Die folgende Beispielausgabe zeigt den Protokolleintrag für eine Nachricht von der angegebenen Adresse, die den Inhaltsfilter-Agent erfolgreich durchlaufen hat: Timestamp SessionId IPAddress MessageId P1FromAddress P2FromAddresses Recipients Agent Event Action SmtpResponse Reason ReasonData Diagnostics
918
: : : : : :
10/7/2010 10:10:48 AM 08CC8C3823463F3F 16.228.9.186 <EF806EB1F8A19642B316B86DFA23C58B15E337E5@[email protected]> [email protected] {[email protected]} {[email protected], [email protected]} : Content Filter Agent : OnEndOfData : AcceptMessage : : SCL : 1 :
Zum Vergleich sehen Sie im Folgenden einen Protokolleintrag für das Löschen einer Nachricht mit einem SCL-Wert von 9. Den Grund für diesen hohen Wert können Sie in dem Bericht erkennen, den Sie im Feld Diagnostics finden. Hier ist CW:CustomList angegeben, was bedeutet, dass der Inhaltsfilter-Agent eines der ausgeschlossenen Wörter entdeckt hat. Timestamp SessionId IPAddress MessageId P1FromAddress P2FromAddresses Recipients Agent Event Action SmtpResponse Reason ReasonData Diagnostics
: : : : : : : : : : : : : :
10/7/2010 9:55:27 AM 08CC8C35250120E3 16.228.9.186 <[email protected]> [email protected] {[email protected]} {[email protected]} Content Filter Agent OnEndOfData DeleteMessage SclAtOrAboveDeleteThreshold 9 DV:3.3.8622.512;SV:3.3.4604.600;SID:SenderIDStatus None;CW:CustomList
Insidertipp: Aktivieren der Antispamaktualisierungen
Spammer lernen dazu und entwickeln ständig neue Techniken, um ihre Nachrichten zu tarnen, sodass sie von E-Mail-Systemen angenommen werden. Häufige und zeitnahe Aktualisierungen der SmartScreen-Daten, die der Inhaltsfilter zum Aufspüren von Spam nutzt, sind sehr wichtig für eine wirkungsvolle Spamabwehr. Microsoft stellt solche SmartScreen-Aktualisierungen über Microsoft Update zur Verfügung. Wenn Sie Enterprise-Lizenzen erworben haben und Microsoft Forefront Protection for Exchange verwenden, werden die Aktualisierungen dafür automatisch heruntergeladen und übernommen. In Exchange Server 2010 SP1 müssen Sie Aktualisierungen nicht mehr manuell herunterladen, wie es in Exchange Server 2007 und 2010 der Fall ist. Das Cmdlet Enable-AntiSpamUpdates ist in dieser Version unnötig geworden. Nur wenige Administratoren haben die Zeit oder die Geduld, um Agentprotokolle zu durchsuchen, sofern dies nicht absolut notwendig ist, z.B. um den Grund dafür herauszubekommen, dass eine Nachricht nicht weitergeleitet wurde. Die Agentprotokolle enthalten einige interessante Analysedaten, und Microsoft stellt eine Reihe von Skripts bereit (die Sie imVerzeichnis \Scripts finden), um diese Daten zu analysieren und Berichte über die Antispamvorgänge zu erstellen. Tabelle 14.3 gibt einen Überblick über diese Skripts und ihren Verwendungszweck. Die Skripts greifen auf die Daten in den Agentprotokollen zu, weshalb ihre Ausgabe auf den Zeitraum beschränkt ist, für den Protokolle vorhanden sind. Da es sich um Skripts handelt, können Sie den Code an Ihre eigenen Anforderungen anpassen. Tabelle 14.3
Tabelle 14.3: Skripts zur Berichterstellung über Antispamvorgänge Skript
Verwendung
Get-AntispamFilteringReport.ps1
Erstellt eine Top-Ten-Liste der Spamquellen aufgrund der abgelehnten Verbindungen oder der Nachrichten, die gelöscht oder in Quarantäne gestellt wurden. Gültige Parameter sind connections, commands, messagesrejected, messagesdeleted und messagesquarantined. 919
Nachrichtenhygiene
Antispam-Agents von Exchange
Kapitel 14 Tabelle 14.3
Nachrichtenhygiene
Tabelle 14.3: Skripts zur Berichterstellung über Antispamvorgänge Skript
Verwendung
Get-AntispamSCLHistogram.ps1
Analysiert die Einträge, die der Inhaltsfilter-Agent geschrieben hat, und gruppiert sie nach den SCL-Werten der Nachrichten.
Get-AntispamTopBlockedSenderDomains.ps1
Nennt die zehn Domänen, die am häufigsten von AntispamAgents blockiert wurden.
Get-AntispamTopBlockedSenderIPs.ps1
Nennt die IP-Adressen der zehn Absender, die am häufigsten blockiert wurden.
Get-AntispamTopBlockedSenders.ps1
Nennt die zehn Absender, die am häufigsten blockiert wurden.
Get-AntispamTopRBLProviders.ps1
Nennt die zehn häufigsten Gründe für die Ablehnung von Nachrichten durch Sperrlistenanbieter.
Get-AntispamTopRecipients.ps1
Nennt die zehn Empfänger, die am häufigsten von AntispamAgents blockiert wurden.
Erfassung von Zulassungs- und Sperrlisten Während die Benutzer eingehende Nachrichten bearbeiten, können sie Listen sicherer Absender und Empfänger sowie blockierter Absender aufstellen. Diese Listen werden als verborgene Elemente im Stammorder ihres Postfachs gespeichert. Wenn die Benutzer E-Mails von externen Kontakten als vertrauenswürdig einstufen, können auch diese Kontakte in die Listen eingehen. OWA und Outlook nutzen diese Daten, um die eingehenden Nachrichten zu untersuchen, die die Antispamverarbeitung auf dem Server durchlaufen haben, und endgültig zu entscheiden, welche Elemente in den Posteingang gelangen und welche gelöscht oder im Ordner Junk-E-Mail abgelegt werden. Die Zulassungsund Sperrlisten für ein Postfach können bis zu 1024 verschiedene Einträge umfassen. Exchange sammelt und formatiert die Daten dieser von den Benutzern angelegten Zulassungs- und Sperrlisten, sodass der Inhaltsfilter-Agent sie dazu nutzen kann, Spam schon beim Eintreffen auf dem Edge-Transport-Server auszusortieren. Wenn Sie Forefront Protection for Exchange Server 2010 ausführen, ist dieser Agent deaktiviert, da dieses Produkt seine eigene Inhaltsfilterung mitbringt. Allerdings greift auch Forefront auf die erfassten Daten der Zulassungs- und Sperrlisten zurück, sodass diese Informationen nicht verloren gehen. Der Wert dieser von den Benutzern bereitgestellten Listen besteht darin, dass es dadurch während der Prüfung auf Spam zu weniger Fehlalarmen kommt. Fehlalarme sind schlecht, denn dadurch wird eine Nachricht blockiert, die der Benutzer eigentlich annehmen möchte. Die Sammlung der Zulassungs- und Sperrlisten von allen Benutzern in der Organisation und ihre Verwendung bei der Antispamverarbeitung können die Anzahl von Fehlalarmen deutlich verringern und sicherzustellen, dass die Benutzer erwünschte Nachrichten erhalten, während die unerwünschten vom Server blockiert werden. Dass Exchange zur Entscheidungsfindung Daten von den Benutzern heranzieht, die auf ihren tatsächlichen Beziehungen zu ihren Korrespondenten in anderen Organisationen beruhen, ist schon eine gute Sache, aber dass die Benutzer diese Daten beibringen, ohne dass ein Administrator eingreifen oder irgendwelche zusätzlichen Tätigkeiten verrichten muss, ist sogar noch besser. Um diese Daten zu erfassen, überwacht ein Postfachassistent die Junk-E-Mail-Optionen der Benutzer auf Änderungen. Tritt eine Änderung auf, aktualisiert der Assistent das Active Diretory-Objekt für den betreffenden Benutzer mit einer Einweg-Hashversion (SHA-256) der Listendaten. Die Hashkodierung dient dazu, die Daten vor einer Analyse zu schützen, wenn sie zu AD LDS auf einem Edge-
920
Transport-Server repliziert werden. Selbst wenn es einem Hacker gelingen sollte, auf den Edge-Transport-Server zu gelangen und in AD LDS einzudringen, kann er die 4-Byte-Einträge nicht in nutzbare E-Mail-Adressen umwandeln. Insidertipp: Hashkodierung von Zulassungs- und Sperrlisten
Durch die Hashkodierung werden die Daten auch auf 4 Bytes pro Eintrag geschrumpft, was die erforderlichen Ressourcen für die Speicherung und Replikation der Daten verringert. Eine komplette Sammlung von Zulassungs- und Sperrlisten umfasst daher lediglich 4.096 Byte an Speicherplatz. Die Einträge bestehen jeweils aus SMTP-Adressen, und Exchange kann die SMTP-Adressen von eingehenden Nachrichten sehr schnell mit den hashkodierten Adresseinträgen vergleichen, um zu entscheiden, ob eine Nachricht erwünscht ist oder nicht. Befindet sich die Adresse auf der Liste der sicheren Absender, überspringt die Nachricht die Inhaltsfilterung, steht sie dagegen auf der Sperrliste, wird die E-Mail vom Server blockiert. Active Directory speichert die gesammelten Zulassungs- und Sperrlisten in drei großen binären Objekten (Binary Large Objects, BLOBs), den Attributen msExchSafeSendersHash, msExchSafeRecipientsHash und msExchBlockedSendersHash. Diese Attribute können Sie mit dem ADSI-Editor einsehen. Abbildung 14.18 zeigt, wie msExchSafeRecipientsHash aussieht, wenn Sie sich die Eigenschaften eines E-Mail-aktivierten Kontos ansehen, in dem entsprechende Daten vorhanden sind. Die nicht druckbaren Zeichen verschleiern den Inhalts des BLOBs, sodass niemand erkennen kann, wofür die hashkodierten Werte stehen. Abbildg. 14.18 Anzeige der Zulassungs- und Sperrlistenattribute eines Active Directory-Kontos
In Exchange Server 2007 sind Administratoren noch gezwungen, die Zulassungs- und Sperrlistendaten mit Update-SafeList von den Benutzerpostfächern zu gewinnen und zur Übertragung auf einen Edge-Transport-Server vorzubereiten. Diese Verantwortung nimmt ihnen in Exchange Server 2010 der Assistent für Junk-E-Mail-Optionen ab. Er sorgt dafür, dass Active Directory regelmäßig mit aktuellen Listendaten versorgt wird, sodass Sie sich nicht mehr darum kümmern müssen, wiederkehrende Aufträge für diesen Zweck auszuführen.
921
Nachrichtenhygiene
Antispam-Agents von Exchange
Kapitel 14
Nachrichtenhygiene
Bei der Zusammenstellung der Zulassungs- und Sperrlistendaten gibt es noch zwei weitere Unterschiede zwischen Exchange Server 2007 und 2010. Erstens nutzt Exchange Server 2010 dabei nur die E-Mail-Adressen einzelner Absender und nicht ganze Absenderdomänen. In Exchange Server 2007 dagegen kann ein Benutzer unbeabsichtigt eine Hintertür öffnen, indem er eine ganze Absenderdomäne in seine Zulassungsliste aufnimmt. Diese Domäne wird zur Antispamprüfung herangezogen, und wenn es einem Spammer gelingt, sich als ein Benutzer aus dieser Domäne auszugeben, umgehen seine Spamnachrichten die Überprüfungen, da sich die Domäne ja auf der Zulassungsliste befindet. Durch die Beschränkung auf Absenderadressen bei der Erfassung der Listendaten wird diese Sicherheitslücke gestopft. Der zweite Unterschied besteht darin, dass der Assistent für Junk-E-Mail-Optionen Kopieren der Listendaten von den Postfächern zu Active Directory alle Einträge für autorisierende Domänen ignoriert. Dadurch wird verhindert, dass ein Benutzer versehentlich Spamnachrichten zulässt, die scheinbar von einer der autorisierenden Domänen stammen. Der Informationsspeicherprozess, der die Nachrichten nach ihrer Zustellung im Postfach eines Benutzers untersucht, um Spam in den Junk-E-Mail-Ordner zu verschieben, übergeht dabei dann nicht die Nachrichten, die von einer autorisierenden Domäne zu stammen scheinen, wenn der Benutzer die internen Domänen zu seinen Zulassungslisten hinzugefügt hat. Das Cmdlet Update-SafeList ist in Exchange Server 2010 nach wie vor vorhanden, sodass Sie Exchange damit zwingen können, die Zulassungs- und Sperrlistendaten aus einem oder mehreren Postfächern zu erfassen, in Hashwerte umzuwandeln und die entsprechenden Active Directory-Konten zu aktualisieren. Um beispielsweise die Listendaten von einem bestimmten Postfach zu erfassen, übergeben Sie dem Cmdlet dessen Kennung: Update-SafeList –Identity JSmith
Natürlich können Sie Update-SafeList auch einen Satz von Postfächern aus einer anderen Abfrage übergeben, um die Daten von allen betroffenen Postfächern zu erfassen: Get-Mailbox –Database 'VIP Data' | Update-SafeList
TIPP Diese Aktualisierungen können Sie problemlos dem Assistenten für Junk-E-MailOptionen überlassen, es sei denn, Sie haben eine triftigen Grund für die manuelle Erfassung. In jedem Fall werden die aktualisierten Daten in Active Directory erst nach der nächsten Edge-Synchronisierung zur Antispamprüfung auf dem Edge-Transport-Server verwendet. Laufen die Antispam-Agents dagegena uf einem Hub-Transport-Server stehen die Informationen unmittelbar zur Verfügung.
Auswählen eines Antivirusprodukts Die Antispam-Agents erfüllen ihre Aufgabe, grundlegende Antispamtechniken anzuwenden, um erwünschte E-Mails aus den eingehenden Nachrichten auszusortieren, auf angemessene Weise. Ihre Fähigkeiten zum Virenabwehr sind jedoch nur rudimentär und bieten nicht denselben Schutz wie ein ausgewiesenes Antivirenprodukt. Daher sollten Sie auf den Edge- oder Hub-Transport-Servern, die die aus dem Internet eingehenden Nachrichten verarbeiten, zur Ergänzung ein gutes Antivirenprodukt bereitstellen, das für die Unterstützung von Exchange vorgesehen ist. Hier stellt sich vor allem die Entscheidung zwischen Microsoft FPE und einem Produkt eines anderen Herstellers. Man könnte glauben, dass die Entscheidung sehr schnell für FPE ausfällt, da die Entwicklungsgruppe
922
dafür schließlich Hand in Hand mit dem Exchange-Team arbeitet, was doch zu einem besser verzahnten und genaueren Schutz führen muss. Außerdem haben Sie bereits die Lizenz für FPE, wenn Sie Enterprise-Clientzugriffslizenzen für Exchange nutzen. Es ist sicherlich wahr, dass FPE eine Überlegung wert ist, und sei es auch nur aufgrund seiner Verzahnung mit Exchange, aber bevor Sie eine endgültige Entscheidung treffen, sollten Sie dennoch eine umfassende und gründliche Bewertung von Antivirusprodukten durchführen und bei der Auswahl die folgenden Aspekte bedenken: 1. VSAPI-Unterstützung: Alle modernen Antivirusprodukte, die Exchange unterstützen, verwen-
2.
3.
4.
5.
6.
den VSAPI. Wählen Sie kein Produkt aus, dass versucht, auf andere Weise auf die Datenstrukturen von Exchange zuzugreifen. Unterstützung für alle Formen der Exchange-Bereitstellung: Achten Sie darauf, dass das Antivirusproudkt alle Arten der Bereitstellung unterstützt, von einfachen Postfachservern über Datenbankverfügbarkeitsgruppen bis zu Servern mit mehreren Rollen. Zentrale Verwaltung und Bereitstellung neuer Antivirenaktualisierungen: Wenn Sie mehr als nur ein oder zwei Server haben, wird die Handhabung viel einfacher, wenn das Antivirusprodukt Ihnen ermöglicht, alle Server von einer einzigen Konsole aus zu verwalten. Zu dieser Verwaltung gehören auch die Berichterstattung über Alarme und das Herunterladen und Verteilen der Aktualisierungen für die Virensignaturen an die Server. Es ist auch gut, wenn das Produkt Berichte erstellt, um die Virenaktivitäten und Angriffe zu analysieren, sodass Sie erkennen können, welchen Bedrohungen Ihre E-Mail-Server ausgesetzt sind. Unterstützung für mehrere Antivirus-Engines: Eine einzelne Antivirus-Engine kann sehr viel Schutz gegen Viren bieten, aber auch als eine mögliche neuralgische Schwachstelle angesehen werden. Mehrere Antivirus-Engines bieten gewöhnlich einen besseren Schutz, vor allem nach dem Ausbruch eines neuen Virus, denn jede Engine weist ihre eigenen Stärken bei der Erkennung auf, und ein Virus, der eine Engine überlistet, kann von einer anderen aufgespürt werden. Es ist auch möglich, auf Edge- und Hub-Transport-Servern jeweils verschiedene Antivirus-Engines auszuführen. Auf Clientzugriffsservern brauchen Sie keine Antivirusprodukte, da auf diesen Computern keine Nachrichten verarbeitet werden. Keine wiederholte Verarbeitung: Das Antivirusprodukt sollte die Nachricht nach der Verarbeitung kennzeichnen, sodass die Leistung nicht dadurch sinkt, dass eine Nachricht von der gleichen Engine an mehreren Stellen der Organisation wiederholt geprüft wird. Zügige Veröffentlichung von Aktualisierungen: Virensignaturen müssen zeitnah aktualisiert und verfügbar gemach werden (vorzugsweise automatisch), um die Organisation auch beim Auftreten neuer Arten von Viren zu schützen. Außerdem sollten für Rollupaktualisierungen und Service Packs von Exchange kurz nach deren Bereitstellung durch Microsoft auch neue Releases des Antivirusprodukts zur Verfügung stehen.
Neben diesen Exchange-spezifischen Kriterien müssen Sie auch die Bedürfnisse des Unternehmens für den Schutz vor Viren auf allen Plattformen bedenken. Die Kosten für den Schutz einer großen Menge von Client-PCs können so hoch sein, dass sie eine wichtige Rolle bei der Produktauswahl spielen. Wenn Sie sehr viel in den Schutz von Client-PCs und Windows Server-Computern investieren müssen, kann es sein, dass Sie Kompromisse schließen und eine für Exchange nicht ganz optimale Antiviruslösung erwerben müssen. Allerdings sind alle wichtigen heutzutage für Exchange erhältlichen Antivirenprodukte umfassend eingerichtet und für den Schutz vieler Arten von Systemen geeignet.
923
Nachrichtenhygiene
Auswählen eines Antivirusprodukts
Kapitel 14
Nachrichtenhygiene
Müssen Sie auf den Edge-Transport-Servern auch Microsoft Forefront Threat Management Gateway (TMG) bereitstellen, wenn Sie dort bereits FPE einsetzen? TMG ist als erste Schutzmaßnahme gegen Bedrohungen gedacht, die aus dem Internet in Umkreisnetzwerke eindringen. Dieses Produkt beherrscht URL-Filterung, Untersuchung auf Malware, HTTP/HTTPS-Überprüfung und den Schutz gegen Eindringlinge. Außerdem kann es als Firewall auf Anwendungs- und Netzwerkebene fungieren. Prinzipiell sollen gut erkennbare Bedrohungen durch eine Schutzvorrichtung am äußeren Rand des Umkreisnetzwerks schon bei der Ankunft auf einem Edge-Transport-Server entfernt werden. Microsoft hat dafür gesorgt, dass TMG, FPE und Edge-Transport-Server einschließlich der EdgeAbonnements zu einer vollständigen Sicherheitsvorkehrung kombiniert werden können, die sich vom Abschnitt für E-Mail-Richtlinien der TMG-Konsole aus zentral verwalten lässt. Angesichts dieser hochgradigen Verzahnung ist diese Zusammenstellung eine Überlegung wert, und wenn auch nur als Grundlage für eine kombinierte Vorgehensweise, die es Angreifern schwerer macht, in das Netzwerk einzudringen. Es gibt jedoch Erfahrungsberichte, nach denen es aufwändiger ist als erwartet, alle Komponenten zur reibungslosen Zusammenarbeit zu bringen. Andere Produkte können einen ähnlichen Schutz bieten, und zur endgültigen Entscheidung können auch Aspekte wie die Kosten (Kauf, Entwicklung, Unterstützung und Lizenzierung), das Zusammenspiel mit anderen NichtMicrosoft-Plattformen und die Skalierbarkeit beitragen (Hardwareprodukte bieten eine bessere Skalierbarkeit und sind gewöhnlich die geeignetere Wahl für den Schutz umfassender Netzwerke).
Clientseitige Schutzvorrichtungen Selbst mit der bestmöglichen Anordnung von Bastion- und Edge-Transport-Servern zur Abwehr von Spam vor dem Eindringen ins Netzwerk ist es doch unvermeidlich, dass ein gewisser Prozentsatz unerwünschter E-Mails durchschlüpft und in die Benutzerpostfächer gerät. Aus diesem Grund ist die clientseitige Spamabwehr ein wichtiger Bestandteil der Gesamtstrategie gegen unerwünschte E-Mails. Jede Version von Outlook enthält eine Funktion zur Verarbeitung von Regeln, durch die die Benutzer eine gewisse Automatisierung bei der Sortierung eingehender Nachrichten erzielen können. In den Anfangstagen waren diese Regeln für Aufgaben wie die Ablage von Nachrichten in passenden Ordnern zuständig. Mit der elektronischen Version von Ramschpost hatten wir praktisch nie zu kämpfen, es sei denn, eine Nachricht von einem unserer regelmäßigen Kommunikationspartner fiel in diese Kategorie. Die übliche Vorgehensweise beim Einsatz von Regeln besteht darin, nach bestimmten Wörtern im Betreff zu suchen und anhand von deren Vorhandensein zu entscheiden, ob die Nachricht gelöscht werden soll. Als unerwünschte E-Mails jedoch immer häufiger wurden, reichten Outlook-Regeln nicht mehr aus, um die komplizierte Erkennung der vielen Varianten von Spamnachrichten zu leisten, die die Spamfilter des Unternehmens überwanden und in den Benutzerpostfächern landeten. Gebraucht wurde jetzt ein intelligenter clientseitiger Spamfilter. Eine erste Version der clientseitigen Junk-E-Mail-Verarbeitung sllte Microsoft in Outlook 2003 vor, und seitdem wurde diese Vorkehrung ständig verbessert. Die Junk-E-Mail-Verarbeitung steht auch in OWA zur Verfügung. Outlook und OWA gehorchen denselben Benutzereinstellungen gehorchen, weisen aber gewisse Funktionsunterschiede auf. Beispielsweise können Sie den Junk-E-Mail-Filter von Outlook nur im Exchange-Cache-Modus verwenden, da Outlook Nachrichten herunterladen muss, bevor es sie mit dem Filter verarbeiten kann.
924
Clientseitige Schutzvorrichtungen
Manche Spamnachrichten lassen sich einfach als solche erkennen, weshalb Regeln zu ihrer Entdeckung gut geeignet waren, als Junk-E-Mails noch ziemlich selten waren. Spam wurde in seinen Anfangstagen noch einfach und ohne jegliche Finessen verfasst. Beispielsweise erhielten Sie plumpe Aufforderungen, Medikamente zu kaufen, oder wurden eingeladen, mit jemandem zusammenzuarbeiten, von dem Sie noch nie in Ihrem Leben gehört hatten, um enorme Geldbeträge aus irgendeinem afrikanischen Land herauszubekommen, usw. Es fasziniert mich immer wieder, dass so viele Menschen Aufforderungen nachgehen, ihr Geld loszuwerden, die miserabel geschrieben, komplett in Großbuchstaben abgefasst und mit Rechtschreibfehlern übersät sind. Wie in diesem Kapitel bereits erwähnt, setzt Antispamsoftware eine Reihe von Techniken ein, um unerwünschte kommerzielle E-Mails aufzuspüren. Microsoft hat die SmartScreen-Technologie ursprünglich für den Schutz der Hotmail-Server entwickelt. SmartScreen muss einer Unmenge an Spam ausgesetzt werden, um die charakteristischen Merkmale von Spamnachrichten kennenzulernen und später selbst erkennen zu können. Der Junk-E-Mail-Filter von Outlook nutzt eine Version der SmartScreen-Spamheuristiken, die Microsoft so angepasst hat, dass sie auf einem PC läuft und bei der Untersuchung von Nachrichten auch Benutzereinstellungen berücksichtigt. Um Nachrichten von bestimmten Absendern zu blockieren, können Sie auch Regeln einsetzen, aber allgemeine Regeln werden nur sehr langsam abgearbeitet und eignen sich daher nicht dazu, eingehende E-Mails mit der Rate zu prüfen, mit der sie in aktiven Postfächern eintreffen. Der JunkE-Mail-Filter von Outlook wird als kompilierter Code ausgeführt, was schnell genug geht, damit es nicht zu merkbaren Verzögerungen bei der Zustellung neuer E-Mails kommt. Die Rohdaten, die Outlook zum Filtern von Nachrichten heranzieht, befinden sich in der Datei Outfldr.dat, die ein umfangreiches Verzeichnis von Schlüsselwörtern und Wendungen für den JunkE-Mail-Filter enthält. Da Sie diese Filterdatei nicht ergänzen können, ist es nicht möglich, Outlook nach ihren eigenen Vorlieben zu trainieren. Stattdessen gibt Microsoft im Rahmen des Updateservice für Office (www.microsoft.com/officeupdate) regelmäßige Aktualisierungen für die Filterdatei heraus. Solange Sie diese Akutalisierungen herunterladen und installieren, bleiben Sie bei der Spamerkennung immer auf dem neuesten Stand. Wenn Sie den Junk-E-Mail-Filter nutzen, untersucht Outlook neue Nachrichten bei deren Eintreffen. Standardmäßig ist ein niedriger Schutzgrad eingestellt, aber ich führe den Filter lieber mit dem Grad Hoch aus, da mir die Erfahrung gezeigt hat, dass er seine Aufgabe sehr gut erledigt. Der Unterschied zwischen Niedrig und Hoch besteht darin, dass der Filter bei der ersten Einstellung nur das ausfiltert, was offensichtlich Spam ist, während er bei der zweiten viel gründlicher vorgeht. Sie können wählen, ob Outlook die als Spam aussortierten E-Mails sofort löscht oder in den Junk-E-Mail-Ordner verschiebt. Gewöhnlich entscheide ich mich für das Löschen, aber von Zeit zu Zeit erfasse ich die Nachrichten doch, nur um zu sehen, was für Arten von Spam hereinkommen. OWA bietet praktisch dieselben Steuerungsmöglichkeiten für die Junk-E-Mail-Filterung wie Outlook, doch können Sie hier nach wie vor Listen sicherer Absender und Empfänger angeben (siehe Abbildung 14.19) und festlegen, dass Sie Nachrichten von Ihren Kontakten stets bekommen möchten. Outlook und OWA verwenden dieselben Junk-E-Mail-Einstellungen, da sie im Stammordner des Benutzerpostfachs gespeichert werden.
925
Nachrichtenhygiene
Der Junk-E-Mail-Filter von Outlook
Kapitel 14
Nachrichtenhygiene
Abbildg. 14.19 Die Junk-E-Mail-Optionen von OWA
Zwar können Sie die Filter, die Outlook zur Spamerkennung nutzt, nicht ändern, aber Sie können die Genauigkeit verbessern, mit der Outlook die eingehenden Nachrichten für Ihren Posteingang filtert, indem Sie angeben, welche Absender Ihrer Ansicht nach sicher sind (Menschen, deren Nachrichten Sie immer empfangen möchten), und welche Benutzer und Domänen Sie für Nervensägen halten (diejenigen, die Ihnen bereits Spam gesendet haben). Outlook greift dann bei der Überprüfung der Nachrichten auf diese Angaben zurück. Diese Untersuchungen laufen in der folgenden Reihenfolge ab: 쐍 Der Absender wird mit Ihren Kontakten verglichen. Alle Nachrichten von Kontakten werden als sicher eingestuft, da sie aktiv tätig geworden sind, um jemanden als Kontakt zu kennzeichnen, was Sie sicherlich nicht tun wollten, wenn Sie keine Nachrichten von dieser Person empfangen möchten. 쐍 Der Absender wird mit den Einträgen in der globalen Adressliste verglichen. Outlook nimmt an, dass Sie gewillt sind, Nachrichten von allen anderen Benutzern in derselben Organisation zu empfangen. (Es ist nicht möglich, den Filter so einzustellen, dass Nachrichten von einem anderen Benutzer in der Organisation blockiert werden. Dazu müssen Sie eine Regel erstellen.) 쐍 Der Absender wird mit den Einträgen in Ihrer Liste der sicheren Absender verglichen. Wenn Sie jemanden zu dieser Liste hinzufügen, teilen Sie Outlook damit mit, dass Sie Nachrichten von ihm stets empfangen möchten. Exchange veröffentlicht diese Information in Active Directory, sodass sie bei der Antispamverarbeitung verwendet werden kann.
926
쐍 Der Absender wird mit den Einträgen in Ihrer Liste sicherer Empfänger verglichen. Wenn Sie eine Adresse zu dieser Liste hinzufügen, teilen Sie Outlook damit mit, dass der Empfang von Nachrichten, die diese Adresse enthalten, genehmigt ist. 쐍 Der Absender wird mit den Einträgen in Ihrer Liste gesperrter Absender verglichen. Outlook blockiert sämtliche Nachrichten von jemandem, der auf dieser Liste steht. Außerdem prüft der JunkE-Mail-Filter, ob die eingehenden Nachrichten von einer blockierten Domäne stammen oder bestimmte Zeichensätze enthalten. Da jeder Absender aus Russland, den ich kenne, mir E-Mails in Englisch schickt, blockiere ich beispielsweise alle Nachrichten mit dem kyrillischen Zeichensatz. Ich habe einmal spaßeshalber eine solche Nachricht mit Yahoo! Babel Fish übersetzen lassen, wobei sie sich als ziemlich harmlos herausstellte (es handelt sich um ein Angebot für einen professionellen Buchhaltungsdienstleister). Aber selbst wenn solche Nachrichten nicht gefährlich sind, verstehe ich nun einmal kein Russisch und kann daher mit russischen E-Mails in meinem Posteingang nichts anfangen, weshalb ich alle Nachrichten mit diesem Zeichensatz blockiere. 쐍 Der Junk-E-Mail-Filter wird ausgeführt, um die Spamnachrichten zu finden, die es bis zu diesem Punkt durchgekommen sind. Ergebnis des Filters ist ein Wert (stellen Sie sich eine Zahl zwischen 1 und 100 vor, wobei 100 dafür steht, dass es sich bei einer Nachricht mit absoluter Sicherheit um Spam handelt), mit dessen Hilfe Outlook bestimmt, ob eine E-Mail Spam ist. Bei der Einstellung Niedrig geht Outlook vorsichtig vor. Der Wert muss schon sehr hoch sein, bevor Outlook eine Nachricht als Spam einstuft. Entscheiden Sie sich für Hoch, geht Outlook radikaler vor und senkt den Grenzwert ab. Wie Sie in Abbildung 14.20 sehen, enthalten die Nachrichtenheader Informationen darüber, was Outlook getan hat, um möglicherweise gefährliche Inhalte aus Nachrichten zu entfernen, die im Junk-E-Mail-Ordner landen. Die E-Mails werden in einfachen Text umgewandelt, und sämtliche Links zu Websites werden deaktiviert. Dadurch wird verhindert, dass die Benutzer versehentlich auf aktive Links klicken, wenn sie sich die Nachrichten im Junk-E-Mail-Ordner ansehen, und dadurch zu Websites gelangen, die sie wahrscheinlich niemals aufsuchen wollen. Durch das Entfernen von Links werden auch Zählpixel (auch Webbugs oder Webbeacons genannt) funktionsunfähig gemacht. Dabei handelt es sich um unsichtbare Links, die »nach Hause telefonieren«, damit die Spammer wissen, dass ihre Nachrichten von einer tatsächlich existierenden Adresse empfangen wurden. Solche bestätigten Adressen sind für Spammer von viel größerem Wert als solche, die willkürlich zusammengesetzt wurden, um sich einen Weg in ein Unternehmen zu erkämpfen. Wenn ein Benutzer versucht, einen Link zu verwenden, zeigt Outlook die Warnung aus Abbildung 14.21 an. Wenn der Benutzer will, kann er alle Warnungen in den Wind schlagen und die Nachricht in den Posteingang verschieben, aber es steht zu hoffen, dass der gesunde Menschenverstand die Oberhand behält. Der Junk-E-Mail-Filter von Outlook kann Spamnachrichten, die den Antispam-Agents von Exchange entgehen, sehr wirkungsvoll blockieren und wird mit jeder Version besser. Er funktioniert sogar dann, wenn Sie versuchen, eine Nachricht aus dem Cache für gelöschte Elemente wiederherzustellen. Wenn Outlook die Nachricht für Spam hält, wird sie nicht wiederhergestellt. Wenn Sie ein BlackBerry oder ein Windows Mobile-Gerät verwenden, haben Sie einen Eindruck davon, wie viel Spam Outlook unterdrückt, denn die Junk-E-Mails, die die serverseitigen Antispam-Agents unterlaufen, werden auf dem Handheld-Gerät ausgeliefert. Es ist zwar nervtötend, diese Nachrichten dort vorzufinden, aber es zeigt, dass Outlook die Nachrichten erst heruntergeladen hat, bevor es Spam als solchen erkennen konnte. Da diese Nachrichten im Posteingang von Outlook nicht auftauchen, können Sie erkennen, wie wirkungsvoll der Junk-E-Mail-Filter ist.
927
Nachrichtenhygiene
Clientseitige Schutzvorrichtungen
Kapitel 14
Nachrichtenhygiene
Abbildg. 14.20 Eine typische blockierte E-Mail
Abbildg. 14.21 Eine Warnung wegen deaktivierter Links
Der Junk-E-Mail-Filter von Outlook funktioniert meistens zwar sehr gut, doch manchmal müssen Sie leider feststellen, dass Outlook eine ganz normale Nachricht in den Junk-E-Mail-Ordner verschoben hat oder das offensichtlicher Spam im Posteingang gelandet ist. Beides kann Sie an der Wirksamkeit des Filters zweifeln lassen. Es sind u.a. die folgenden Gründe, die zu solchen Vorfällen führen: 쐍 Von Anwendungen erstellte Nachrichten werden als Spam angesehen: Beispiele sind z.B. Ausgabenberichte, Benachrichtigungen von Microsoft SharePoint Portal Server, Abonnementaktualisierungen, Newsgroupverteiler usw. Werden solche Nachrichten erstellt, richtet eine Anwendung häufig eine nicht authentifizierte SMTP-Verbindung zu einem Server ein, und aufgrund dieser fehlenden Authentifizierung gilt die Nachricht als Spam, denn es könnte durchaus sein, dass ein Spammer eine gültige interne E-Mail-Adresse gekapert hat und sie für seine Zwecke zu missbrauchen versucht. Außerdem kann der Inhalt solcher automatisch generierten Nachrichten wenig zusammenhängenden Text enthalten, dafür aber URLs, die auf Anwendungsdaten zeigen, und möglichweise ist im Header auch kein From:-Feld angegeben – lauter Merkmale für Spam! Die Lösung besteht darin, die Absenderadresse zu einer Zulassungsliste hinzuzufügen oder die Anwendung vom Administrator so ändern zu lassen, dass sie eine authentifizierte SMTP-Verbindung nutzt.
928
쐍 Offensichtlicher Spam, der den Filter überwindet: Das kann ganz einfach daran liegen, dass die Spammer eine neue Taktik einsetzen, um die Filter zu überlisten. Leider haben Spammer mit so etwas ständig Erfolg. In einem Unternehmen mit einer umfassenden Spamabwehr können Sie davon ausgehen, dass pro Woche ein oder zwei Spamnachrichten durchschlüpfen. Sind es mehr, so ist das ein sicheres Zeichen dafür, dass die Abwehrmaßnahmen aktualisiert werden müssen, z.B. indem Sie die neueste Version der Datendatei für den Junk-E-Mail-Filter von Outlook herunterladen und installieren. 쐍 Unlogisches Verschieben von Nachrichten von einem Ordner in einen anderen: Wenn Sie zur Verarbeitung eingehender Nachrichten immer noch Postfachregeln verwenden und Outlook zunächst die Nachrichtenheader herunterlädt (damit Daten für die Verarbeitung der Regeln zur Verfügung stehen) und anschließend den vollständigen Inhalt (den der Junk-E-Mail-Filter benötigt), kann es passieren, dass die Regeln einige Nachrichten in einen bestimmten Ordner verschieben, woraufhin sie Outlook anschließend nach der Ausführung des Junk-E-Mail-Filters in den Junk-E-Mail-Ordner weiterverschiebt. Für das Programm ist dieses Verhalten völlig logisch, für Benutzer dagegen wirkt er völlig verwirrend. Da Spammer ständig neue Techniken austüfteln, um die Filter zu unterlaufen, schlüpfen selbst bei der besten Antispamabwehr immer wieder einige Nachrichten durch die Maschen. Die Adressen, von denen Sie Spam erhalten haben (oder gleich die ganze Ursprungsdomäne) können Sie der Liste der blockierten Absender hinzufügen, um nach und nach ihre eigene Spammerliste aufzubauen. Die Zulassungs- und Sperrlisten für Absender, und Empfänger können Sie in eine Textdatei exportieren und den andern Benutzer für den Import an die Hand geben. Der Zweck der Liste der blockierten und sicheren Absender ist offensichtlich, was jedoch auf die Liste der sicheren Empfänger weniger zutrifft. Im Grunde genommen handelt es sich um eine Möglichkeit, um Nachrichten an einen bestimmen Empfänger zu kennzeichnen, von dem Sie selbst Nachrichten empfangen möchten, z.B. eine Verteilerliste oder Newsgroup, bei der Sie Mitglied sind. Zwar haben Sie keinen Einfluss auf diese Liste oder Gruppe, aber Sie gehen davon aus, dass der Verantwortliche sie nicht zum Versenden von Spam missbraucht, weshalb Nachrichten, die an die Liste adressiert sind, sicher sind. Wenn Sie diese Liste als sicher markieren könnten, würde Outlook die Nachrichten womöglich als Spam einstufen und abwehren. Durch die Aufnahme der Adresse einer solchen Liste (oder ähnlicher Adressen) als sicherer Empfänger teilen Sie Outlook mit, dass Nachrichten von dieser Adresse bei der Untersuchung mithilfe der Filter ignoriert werden können. Bei der Verarbeitung von Nachrichten zieht Exchange die Einträge in der Liste der gesperrten und der sicheren Absender zusammen mit den vom Inhaltsfilter-Agent ermittelten SCL- und PCL-Werten heran. Wie bereits gesagt, zeigt der SCL-Wert an, mit welcher Wahrscheinlichkeit Exchange die Nachricht für Spam hält, während der PCL-Wert die Wahrscheinlichkeit dafür angibt, dass es sich um einen Phishingversuch handelt. Wenn eine Nachricht bis zu Outlook durchkommt, heißt das, dass Exchange sie als für sicher genug hält, da sie ansonsten auf dem Transportserver oder beim Eintreffen im Postfachspeicher blockiert worden wäre. Der Informationsspeicher schaut sich bei der Zustellung die Liste der blockierten Absender für das betreffende Postfach an und unterdrückt Nachrichten von Absendern, die auf dieser Liste stehen. Outlook muss solche E-Mails daher gar nicht erst verarbeiten (was Outlook den Aufwand dafür erspart, die Nachrichten zur lokalen Weiterverarbeitung herunterzuladen). Anhand der Liste der sicheren Absender überprüft der Informationsspeicher bei E-Mails mit einem hohen SCL-Wert, ob der Benutzer Nachrichten vom Empfänger erhalten möchte. Findet der Informationsspeicher die Adresse des Absenders auf dieser Liste, wird die Nachricht durchgelassen, sodass Outlook sie bei der nächsten Synchronisierung des Posteingangs aufgreifen kann.
929
Nachrichtenhygiene
Clientseitige Schutzvorrichtungen
Kapitel 14
Nachrichtenhygiene
Die Einstellung für den automatischen Download von Bildern (die Sie im Sicherheitscenter von Outlook finden) steuert, ob Outlook Bilder und andere Grafiken in E-Mails ohne Rückfrage herunterlädt. Laut Standardeinstellung ist der automatische Download ausgeschaltet, und es gibt auch keinen guten Grund, um das zu ändern. Sie können festlegen, ob ein Download von Websites in bestimmten Internetzonen oder für Nachrichten von vertrauenswürdigen Sendern erfolgen soll. Wenn Sie daher viele E-Mails von grafiklastigen Websites wie eBay erhalten, können Sie sie immer zur Liste der sicheren Absender hinzufügen. Die Einstellung für den automatischen Download von Bildern gibt es in Outlook 2003, 2007 und 2010. Die neuesten Hinweise dazu, wie Sie sich dieser Aufgabe mit Gruppenrichtlinien und dem Office-Anpassungstool am besten stellen, finden Sie auf TechNet. Insidertipp: Keine Poststempel mehr
In Outlook 2007 gab es die neue Möglichkeit, Nachrichten mit rechenintensiven Poststempeln zu versehen, um den Empfängern zu versichern, dass es sich nicht um Spam handelt, selbst wenn die E-Mail einige für Spam typische Merkmale aufwies. Durch das Hinzufügen von Poststempeln sollte der Vorgang für den Geschmack von Spammern, die Millionen nach Nachrichten versenden, damit einige wenige durchkommen und eine Antwort zurückgeben, zu stark verlangsamt werden. Diese Poststempel wurden in X-Headern gespeichert, die eine Rechenaufgabe und eine haskkodierte Version der Antwort vom Client enthielten. Microsoft hat die Poststempelfunktion in Outlook 2010 wieder entfernt, vor allem da diese Vorgehensweise in der Branche ansonsten nur eine sehr geringe Unterstützung fand. Die von Outlook 2007 erstellen Poststempel werden jedoch vom Inhaltsfilter-Agent in Exchange Server 2010 weiterhin verarbeitet, und eine korrekte Antwort auf die Rechenaufgabe veranlasst den Agent dazu, den SCL-Wert für die Nachricht zu senken.
Die Toolbox Nicht alles lässt sich nahtlos in einem einzigen Programm kombinieren. Es gibt daneben noch Hilfsprogramme und andere nützliche Software, die sich nicht so recht in die Struktur der Organisations-, Server- und Empfängerverwaltung einpassen lassen. Die Lösung besteht darin, alles, was sich nicht in die vorgegebenen Kategorien einteilen lässt, in einem Werkzeugkasten zusammenzufassen. Das mag sich so anhören, als sei die Toolbox eine Abstellkammer für Programme, die niemand braucht. In Wirklichkeit jedoch handelt es sich um eine Fundgrube für Administratoren! Sehen wir uns im nächsten Kapitel an, warum das so ist.
930
Die Exchange-Toolbox
Kapitel 15
Die Exchange-Toolbox
In diesem Kapitel: Der Anzeige- oder Detailvorlagen-Editor
933
Nachrichtenverfolgung
937
Systemmonitor
959
Leistungsproblembehandlung
962
Exchange Load Generator 2010
965
Remoteverbindungsuntersuchung
966
Quellen für weitere Informationen
969
931
Kapitel 15
Die Exchange-Toolbox
Die Exchange-Toolbox bietet Administratoren einen bequemen Zugriff auf eine Reihe von Hilfsprogrammen, mit denen sie die verschiedenen Bestandteile einer Exchange-Organisation analysieren, verwalten und besser kennenlernen können. Die Exchange-Entwicklergruppe beabsichtigt, der Toolbox weitere Hilfsprogramme hinzuzufügen, sobald sie zur Verfügung stehen. Allerdings ist die Entwicklergruppe nicht Urheber sämtlicher hier gesammelten Werkzeuge. Andere, z.B. die Remoteverbindungsuntersuchung, sind von anderen Microsoft-Teams gestaltet worden. In gewissem Sinne sind es gerade die Hilfsprogramme, die nicht von der Entwicklergruppe stammen, die besonders interessant und wertvoll sind, da sie erstellt wurden, um Probleme zu lösen, die sich in der Praxis zeigten. Tabelle 15.1 führt den Inhalt der Toolbox von Exchange Server 2010 auf. Wie Sie sehen, haben die einzelnen Hilfsprogramme keine gemeinsame Oberfläche. Einige nutzen das Framework, das für Exchange Best Practice Analyzer (ExBPA) erstellt wurde, andere haben ganz eigene Oberflächen, sind Bestandteil der Exchange-Systemsteuerung oder rufen ein Windows-Dienstprogramm auf. Bei zwei der Programme handelt es sich um MMC-Snap-Ins (Microsoft Management Console). Das Fehlen einer einheitlichen Oberfläche lässt sich durch die zusammengewürfelte Natur der Toolbox erklären, durch die unterschiedliche Entwicklungsgeschichte der einzelnen Hilfsprogramme und die Tatsache, dass es sich bei der Toolbox einfach nur um eine Sammelstelle für verschiedene interessante und nützliche Administratorenwerkzeuge handelt. Tabelle 15.1
932
Inhalt der Toolbox von Exchange Server 2010 Programm
Zweck
Benutzeroberfläche
Best Practice Analyzer
Vergleicht die gegenwärtige KonfiBPA guration der Exchange-Organisation mit einem Satz von Microsoft empfohlener Vorgehensweisen und gibt einen Bericht aus, anhand dessen Administratoren die Organisation verbessern können, indem Sie offensichtliche Probleme beheben oder Einstellungen verbessern und damit die Leistung steigern. Früher hat Microsoft Aktualisierungen der empfohlenen Vorgehensweisen auf der Website exbpa.com zur Verfügung gestellt, doch wird diese Site jetzt nicht mehr verwendet. Aktualisierungen empfohlener Vorgehensweisen werden jetzt zusammen mit anderen Rollupaktualisierungen für Exchange bereitgestellt.
Detailvorlagen-Editor
Ändert die sprachspezifischen Detailvorlagen, mit denen OutlookBenutzern Verzeichnisinformationen (globales Adressbuch) angezeigt werden.
Eigene Oberfläche
Öffentliche Ordner-Verwaltungskonsole
Verwaltet die Hierarchie öffentlicher Ordner sowie die Einstellungen (aber nicht den Inhalt) einzelner öffentlicher Ordner.
MMC
Remoteverbindungsuntersuchung
Prüft, ob Verbindungspunkte für SMTP, ActiveSync usw. korrekt funktionieren.
Web
Der Anzeige- oder Detailvorlagen-Editor
Inhalt der Toolbox von Exchange Server 2010 (Fortsetzung) Programm
Zweck
Benutzeroberfläche
Benutzereditor für die rollenbasierte Zugriffssteuerung
Dient zur Verwaltung von Rollengruppen sowie von Rollenzuweisungen für Benutzer.
Exchange-Systemsteuerung
NachrichtenübermittlungsProblembehandlung
Prüft, ob das Transportsystem korrekt funktioniert.
BPA
Nachrichtenverfolgung
Prüft anhand der Übermittlungsberichte den Status der gesendeten Nachrichten und protokolliert die Ergebnisse der letzten zwei Wochen.
Exchange-Systemsteuerung
Warteschlangenanzeige
Dient zur Anzeige und Verwaltung von Nachrichten in den Transportwarteschlangen.
MMC
Routingprotokollanzeige
Zeigt den Inhalt der Tarnsportroutingprotokolle an und ermöglicht Administratoren, die Konfiguration zweier Routingprotokolle zu vergleichen.
Eigene Oberfläche
Verfolgungsprotokoll-Explorer
Durchsucht den Inhalt von Verfolgungsprotokollen, um den Übermittlungsfortschritt der Nachrichten von Server zu Server bis zu den Grenzen der Organisation nachzuspüren.
BPA
Systemmonitor
Startet eine eigene Version des üblichen Windows-Systemmonitors, mit der eine Reihe vorab geladener und für den Status eines Exchange ServerComputers wichtiger Leistungsindikatoren überwacht werden kann.
Systemmonitor
Leistungsproblembehandlung
Dient dazu, die Ursachen häufig auftretender Leistungsprobleme auf Exchange Server-Computern herauszufinden.
BPA
Einige dieser Hilfsprogramme haben wir uns schon an anderen Stellen in diesem Buch angesehen (z.B. die Warteschlangenanzeige). In diesem Kapitel konzentrieren wir uns daher auf die noch nicht vorgestellten Werkzeuge.
Der Anzeige- oder Detailvorlagen-Editor Outlook verwendet Detailvorlagen (an anderer Stelle auch Anzeigevorlagen genannt), um Verzeichnisinformationen zu formatieren und anzuzeigen, wenn sich die Benutzer die Angaben über Objekte in der globalen Adressliste ansehen. Diese Vorlagen können Sie anpassen, um einzelne Felder hinzuzufügen oder zu entfernen oder die Beschreibungen der Felder zu ändern. Eine solche Anpassung der Anzeigevorlagen kommt in großen Organisationen häufiger vor, während kleinere gewöhnlich bei der mit Exchange ausgelieferten Standardversion bleiben.
933
Die Exchange-Toolbox
Tabelle 15.1
Kapitel 15
Die Exchange-Toolbox
Abbildung 15.1 zeigt eine einfache Anpassung einer Anzeigevorlage. Der obere Screenshot zeigt die standardmäßige Eigenschaftenseite Organisation, der untere die angepasste Version. In beiden Fällen wird Outlook 2010 verwendet, aber dieselben Techniken lassen sich auch in Outlook 2003 und 2007 anwenden. In der angepassten Vorlage sind zwei neue Postfachattribute zu erkennen: 쐍 Contoso-Kostenstellencode Die meisten großen Organisationen weisen ihre Angestellten Kostenstellen oder ähnlichen Abrechnungsstrukturen zu. Benutzer müssen auf diese Informationen zugreifen können, um herauszufinden, welche Kostenstelle sie in Dokumente wie Spesenabrechnungen eintragen müssen. Für diesen Zweck können Sie eine der Standardeigenschaften von Exchange verwenden und umbenennen, allerdings ist es gewöhnlich besser, eine der 15 erweiterten Eigenschaften zu nutzen, die es in Exchange eigens für solche Anpassungen gibt. 쐍 Art des Arbeitsverhältnisses In manchen Organisationen ist es erforderlich, Informationen über die Art des Arbeitsverhältnisses von Angestellten (Vollzeit, Teilzeit, freier Mitarbeiter oder wie hier Geschäftsführer) für andere Benutzer sichtbar zu machen. Abbildg. 15.1
934
Anzeige mit der normalen (oben) und einer angepassten Vorlage
Um eine Anzeigevorlage zu ändern, öffnen Sie in der Exchange-Verwaltungskonsole die Toolbox, markieren den Detailvorlagen-Editor und klicken im Aktionsbereich auf Tool öffnen. Das Programm öffnet eine neue Instanz von MMC, liest die Informationen über verfügbare Detailvorlagen in Active Directoy und lädt sie in die Konsole, wie Sie in Abbildung 15.2 sehen können. Mit diesem Werkzeug können Sie Vorlagen in allen von Exchange angebotenen Sprachen ändern. In einer mehrsprachigen Organisation sollten Sie auf Einheitlichkeit achten und für alle genutzten Sprachversionen von Outlook die gleichen Änderungen vornehmen. Haben Sie beispielsweise die deutsche, schwedische, finnische und englische Version von Outlook bereitgestellt, sollten Sie die Detailvorlagen für alle diese Sprachen auf die gleiche Weise anpassen. Abbildg. 15.2
Die Exchange-Verwaltungskonsole und der Detailvorlagen-Editor
Am häufigsten wird die Benutzervorlage geändert. Ein Beispiel dafür haben Sie bereits in Abbildung 15.1 gesehen, und im Folgenden möchte ich erklären, wie Sie die dort gezeigten Anpassungen vornehmen. Um eine Vorlage bearbeiten zu können, müssen Sie in der Liste darauf doppelklicken. Exchange ruft dann die Daten der gewünschten Vorlage aus Active Directory. Die Vorlage, mit der wir uns hier beschäftigen, heißt de-DE\User. Es handelt sich um die deutschsprachige Version der Vorlage, und zwar in der für Deutschland üblichen Variante. Es gibt zwar leichte Unterschiede zum österreichischen und schweizerischen Deutsch, aber dennoch gibt es nur diese eine deutsche Vorlage. Das gilt in ähnlicher Form auch für Englisch (nur US-Englisch), Spanisch (nur das in Spanien gesprochene Spanisch) usw.
935
Die Exchange-Toolbox
Der Anzeige- oder Detailvorlagen-Editor
Kapitel 15
Die Exchange-Toolbox
HINWEIS In der Konsole gibt es auch die Option Wiederherstellen. Das ist Ihr Rettungsanker für den Fall, dass Sie bei der Bearbeitung einer Vorlage ein absolutes Desaster angerichtet haben, denn damit können Sie die Vorlage wieder in den Lieferzustand zurückversetzen. Dabei gehen natürlich sämtliche Änderungen verloren, die Sie vorgenommen haben, aber manchmal ist das der einzige Ausweg. Der Vorlagen-Editor von Exchange Server 2010 ist der gleiche, der auch schon mit Exchange Server 2007 geliefert wurde. Im Vergleich mit den meisten Layouteditoren ist er sehr einfach, aber er erfüllt seinen Zweck. In Abbildung 15.3 sehen Sie die Registerkarte Organisation der Benutzervorlage, auf der das hinzugefügte Kostenstellenfeld gerade ausgewählt ist. Abbildg. 15.3
Anpassen einer Vorlage
In der Werkzeugpalette auf der linken Seite können Sie verschiedene Arten von Steuerelementen für die Eigenschaften auswählen, die Sie anzeigen lassen möchten. Um ein neues Feld hinzuzufügen, ziehen Sie den gewünschten Typ auf die Seite und legen die Eigenschaften fest, z.B. das anzuzeigende Attribut. In diesem Beispiel wird das Feld Contoso-Kostenstelle in einem einfachen Textfeld angezeigt, das mit dem Postfachattribut ms-Exch-Extension-Attribut15 verknüpft ist (das an anderer Stelle Benutzerdefiniertes Attribut 15 heißt). Aus einer Dropdownliste können Sie die verfügbaren Attribute für das Postfachobjekt auswählen. Sie haben die Auswahl zwischen folgenden Arten von Steuerelementen: 쐍 Kontrollkästchen Wird für Ein/Aus- und Ja/Nein-Felder verwendet, mit denen der Status eines Objekts angezeigt wird. 쐍 Bearbeiten Zeigt einen einzigen Attributwert an. Beispielsweise haben Benutzer nur einen Vornamen, der aus dem Attribut Given-Name abgerufen wird. In unserem Fall ist ein solches Feld die beste Möglichkeit, da sowohl der Kostenstellencode als auch die Art des Arbeitsverhältnisses einwertige Attribute sind. 936
쐍 Listenfeld Zeigt Daten für ein Attribut an, die von unterschiedlichen Objekten herrühren. Beispielsweise kann ein Benutzer Mitglied mehrerer Verteilergruppen sein, weshalb es auf der Registerkarte Mitglied von ein Listenfeld gibt, das aus dem Attribut Is-Member-Of-DL gespeist wird. 쐍 Mehrwertiges Listenfeld Zeigt Daten für ein Attribut an, das mehrere Werte annehmen kann. Beispielsweise können Benutzerobjekte über mehrere E-Mail-Adressen verfügen, weshalb es auf der Registerkarte E-Mail-Adressen ein mehrwertiges Listenfeld gibt, das aus dem Attribut PRoxyAddresses gespeist wird. 쐍 Beschriftung Enthält einen Text in der jeweiligen Sprache und erscheint gewöhnlich neben einem Steuerelement mit Daten. In vielen Beschriftungsfeldern ist ein Buchstabe unterstrichen, um anzuzeigen, dass Benutzer das Feld mit der Tastenkombination aus (Alt) und dem betreffenden Buchstaben aufrufen können. Beispielsweise ist beim Feld Vorgesetzter das o unterstrichen, was bedeutet, dass Sie dieses Feld mit (Alt) + (o) erreichen können. Um das zu erreichen, geben Sie im Wert für ein Beschriftungssteuerelement ein kaufmännisches Und (&) ein, also z.B. V&orgesetzter. 쐍 Gruppenfeld Definiert eine Gruppe von Feldern, um die Outlook bei der Anzeige der Vorlage einen Rahmen zieht. Auf der Registerkarte Allgemein der Benutzervorlage sind beispielsweise die Felder Vorname, Initialen, Nachname, Anzeige und Alias umrandet. Sobald Sie die geänderte Vorlage gespeichert haben, stellt Exchange sie sofort jedem Outlook-Client zur Verfügung, der online Verbindung aufnimmt. Outlook-Clients im Exchange-Cache-Modus sehen die geänderte Vorlage erst, wenn sie das nächste Mal Kontakt aufnehmen und das Offlineadressbuch herunterladen. Insidertipp: Wichtige Aspekte
Detailvorlagen lassen sich leicht anpassen, aber bevor Sie sich in die Arbeit stürzen, sollten Sie sich fragen, ob die geplante Anpassung wirklich einen Nutzen hat. Außerdem gibt es noch einige andere Gesichtspunkte zu bedenken. So müssen Sie Ihre Änderungen nach jeder Aktualisierung von Exchange überprüfen, da nicht gesagt ist, dass Microsoft diese Anpassungen in einer neuen Version oder einem Service Pack nicht wieder überschreibt oder keine Änderungen vornimmt, die mit Ihren Modifikationen unvereinbar ist. Der Übergang von Exchange Server 2003 zu 2007 und von 2007 und 2010 brachte keine Beeinträchtigungen für geänderte Vorlagen mit sich, aber das muss nicht zwangsläufig so sein. Wenn Sie mehrere Organisationen betreiben, ist es außerdem nicht möglich, Änderungen an Vorlagen organisationsübergreifend vorzunehmen. Stattdessen müssen Sie die angepassten (und getesteten) Vorlagen mit einem Programm wie LDIFDE aus der einen Organisation exportieren und dann in die Active Directory-Instanz der anderen importieren.
Nachrichtenverfolgung Die Möglichkeiten, Nachrichten anhand von Protokollen nachzuverfolgen, die Angaben über den Weg der E-Mails zwischen den verschiedenen Komponenten von Exchange enthalten, gab es schon seit der ersten Version des Produkts. Diese Funktion kann für verschiedene Zwecke eingesetzt werden, z.B. um die Leistung der Messaginginfrastruktur vom Absender zum Empfänger zu bestimmen oder um Nachrichten nachzuspüren und damit zu beweisen, dass jemand eine bestimmte E-Mail tatsächlich gesendet oder empfangen hat. Die Nachrichtenverfolgung hat sich von einer Version zur nächsten in Einzelheiten geändert, aber Funktionsweise und Bedienung in Exchange Server 2010
937
Die Exchange-Toolbox
Nachrichtenverfolgung
Kapitel 15
Die Exchange-Toolbox
ähneln noch sehr stark der Version aus Exchange Server 2007. Neu sind die Übermittlungsberichte, auf die auch für Benutzer zugänglich sind (siehe Kapitel 5, »Exchange-Verwaltungskonsole und Exchange-Systemsteuerung«) und dazu führen können, dass Systemadministratoren weniger häufig nach dem Verbleib irgendwelcher Nachrichten gefragt werden. Die Übermittlungsberichte werden auf der Grundlage der Nachrichtenverfolgungsprotokolle erstellt, zeigen aber nur einen Teil der Informationen, die für Administratoren verfügbar sind. Exchange beginnt mit der Erfassung von Informationen über eine Nachricht, wenn ein Client sie über den Informationsspeicher auf dem Postfachserver einreicht. Weitere Daten werden gesammelt, wenn der Transportdienst die Nachricht aus der Übermittlungswarteschlange des Informationsspeichers herausnimmt, kategorisiert und zu ihrem endgültigen Bestimmungsort auf einem Server in derselben Organisation oder über einen Connector zu einem anderen E-Mail-System leitet. Die Daten in den Nachrichtenverfolgungsprotokollen geben Einblick in alle Vorgänge auf einem Server, z.B. eingehende Nachrichten, Replikation öffentlicher Ordner und systemgenerierte Nachrichten wie Unzustellbarkeitsberichte, Kontingentwarnungen, Benachrichtigungen über den Auflauf moderierter Nachrichten usw. Wie viele Informationen auf einem Hub-Transport-Server erfasst werden, hängt ganz vom Umfang des Datenverkehrs ab. HINWEIS In vielen Unternehmen werden die Daten in diesen Protokollen zur Analyse des Nachrichtenverkehrs genutzt, um den zukünftigen Bedarf abzuschätzen oder um zu beweisen, dass eine Nachricht tatsächlich von einem Benutzer zu einem anderen gegangen ist. Standardmäßig sind Hub- und Edge-Transport- sowie Postfachserver so eingerichtet, dass sie Nachrichtenverfolgungsprotokolle erstellen. Auf reinen Clientzugriffs- und Unified-Messaging-Servern werden diese Protokolle nicht geführt, da sich diese Serverrollen nicht am Nachrichtentransport beteiligen. Exchange Server 2007 und 2010 weisen dasselbe CSV-format für Protokolle auf, das dem Format für andere Arten von Transportprotokollen ähnelt (z.B. die SMTP-Protokollierung). Dank dieses gemeinsamen Formats können Sie Nachrichten auf ihrem Weg über beide Serverversionen hinweg verfolgen. Exchange Server 2003 dagegen erstellt Nachrichtenverfolgungsprotokolle im IIS-Format (Internetinformationsdienste), sodass Sie E-Mails von Exchange Server 2003 zu Exchange Server 2007 oder 2010 und umgekehrt nicht nachverfolgen können. Wenn Sie auch den Weg solcher Nachrichten protokollieren möchten, müssen Sie eine Suche auf Exchange Server 2003 und eine Suche auf Exchange Server 2007 bzw. 2010 durchführen und die Ergebnisse dann manuell kombinieren. Um die Nachverfolgung durchzuführen, werden Anforderungen an die Microsoft Exchange-Transportprotokollsuche übermittel, einen in Exchange Server 2007 neu eingeführten Dienst. Logischerweise muss dieser Dienst auf allen Servern ausgeführt werden, die eine Nachricht verarbeiten, bevor Sie in der Lage sind, ihren Weg von der Einreichung bis zur endgültigen Auslieferung oder dem Verlassen der Organisation nachzuverfolgen. Den Speicherort der Nachrichtenverfolgungsprotokolle auf einem Hub-Transport-Server können Sie auf der Registerkarte Protokolleinstellungen ablesen, die Sie im Eigenschaftendialogfeld des Servers im Knoten Serverkonfiguration der Exchange-Verwaltunskonsole finden. Standardmäßig ist die Nachrichtenverfolgung aktiviert, wobei die Protokolle im Ordner C:\Programme\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking abgelegt sind. Da die Suchvorgänge durch den Transportprotokollsuchdienst durchgeführt werden, muss der Speicherort für diese Protokolle keine Dateifreigabe mehr sein, wie es in Exchange Server 2000 und 2003 der Fall war. Für den Inhalt der Protokolle ist es lediglich erforderlich, ständig neue Daten anzuhängen, um die Angaben zu einer Nachricht zu vervollständigen, weshalb Nachrichtenverfolgungsprotokolle selbst auf einem stark beschäftigen Hub-Transport-Server keine große Last hervorrufen. Bei Exchange Server
938
2007 gab Microsoft an, dass die Protokollerstellung nicht mehr als 2% zusätzlichen Aufwand hervorrief. Dank der Steigerung der Serverleistung und der Verringerung des E/A-Bedarfs in Exchange Server 2010 ist die Belastung durch andere Systemkomponenten jetzt geringer geworden, und auch die Leistung der Serverhardware hat sich in den letzten Jahren stark gebessert. Es gibt also keinen guten Grund dafür, die Nachrichtenverfolgung auf irgendeinem Server auszuschalten. Exchange führt Nachrichtenverfolgungsprotokolle zwar auch auf Postfachservern, auf denen die Hub-Transport-Rolle nicht installiert ist, doch können Sie dort in den Servereigenschaften merkwürdigerweise nicht erkennen, wo diese Protokolle gespeichert werden. Stattdessen müssen Sie in der Exchange-Verwaltungsshell auf die Eigenschaften zurückgreifen, die die Nachrichtenverfolgung aktivieren und den Speicherort angeben. Beispielsweise können Sie mit dem folgenden Befehl herausfinden, auf welchen Postfachservern in der Organisation die Nachrichtenverfolgung aktiviert ist: Get-MailboxServer |Where {$_.MessageTrackingLogEnabled –eq $True} | Select Name, MessageTrackingEnabled
Um die Hub-Transport-Server mit aktivierter Nachrichtenverfolgung zu ermitteln, gehen Sie wie folgt vor: Get-TransportServer |Where {$_.MessageTrackingLogEnabled –eq $True} | Select Name, MessageTrackingEnabled
Falls erforderlich können Sie die Nachrichtenverfolgung auf einem Postfachserver mit folgendem Befehl einschalten: Set-MailboxServer –Identity ExServer1 –MessageTrackingLogEnabled $True
Wie wir gesehen haben, werden die Nachrichtenverfolgungsprotokolle standardmäßig auf derselben Festplatte gespeichert, auf der sich auch die Binärdateien von Exchange befinden. Das mag für kleine und nur schwach belastete Server akzeptabel sein, bei größerem Datenverkehrsaufkommen allerdings sollten Sie die Protokolle auf eine andere Festplatte verlagern. Das können Sie ganz einfach tun, indem Sie die Angabe des Speicherorts in den Servereigenschaften oder mit folgendem Befehl in der Exchange-Verwaltungsshell ändern: Set-MailboxServer –Identity ExServer4 –MessageTrackingLogPath 'D:\Logs\MessageTracking\'
Wenn das angegebene Verzeichnis nicht vorhanden ist, wird es durch diesen Befehl erstellt. Bereits vorhandene Protokolldateien werden jedoch nicht verschoben. Das müssen Sie selbst nachholen, indem Sie die Dateien an den neuen Speicherort kopieren. Wenn Sie das aktuelle Protokoll nicht kopieren, erstellt Exchange es neu, wenn auf dem Server eine neue Nachricht zur Verarbeitung erscheint. Mit dem folgenden Befehl können Sie die Einstellungen für Nachrichtenverfolgungsprotokolle auf einem Postfachserver einsehen (für einen Hub- oder Edge-Transport-Server verwenden Sie GetTransportServer): Get-MailboxServer –Identity ExServer4 | Select MessageTracking* MessageTrackingLogEnabled MessageTrackingLogMaxAge MessageTrackingLogMaxDirectorySize MessageTrackingLogMaxFileSize MessageTrackingLogPath MessageTrackingLogSubjectLoggingEnabled
: : : : : :
True 30.00:00:00 1000 MB (1,048,576,000 bytes) 10 MB (10,485,760 bytes) c:\Temp\MessageLogs True 939
Die Exchange-Toolbox
Nachrichtenverfolgung
Kapitel 15
Die Exchange-Toolbox
Zwei dieser Eigenschaften sind auch in der Exchange-Verwaltungskonsole zugänglich (die Aktivierung und der Protokollspeicherort), die anderen können nur in der Shell bearbeitet werden. Die Eigenschaften, die die Aufbewahrungszeit für Nachrichtenverfolgungsprotokolle (MaxAge), die maximale Größe aller Protokolle (MaxDirectorySize) und die eines einzelnen Protokolls (FileSize) bestimmen, ähneln im Prinzip sehr stark denen für die Transportprotokolle, die wir uns in Kapitel 13, »Das ExchangeTransportsystem«, angesehen haben, weshalb wir hier nicht weiter darauf eingehen. Insidertipp: Ein nützliches Hilfsmittel mit vernachlässigbaren Risiken
Der Parameter MessageTrackingLogSubjectLoggingEnabled bestimmt, ob Exchange Informationen über den Nachrichtenbetreff in die Protokolle aufnimmt. Das hat in der Vergangenheit zu lebhaften Diskussionen geführt, da sich manche Personen Sorgen über den Datenschutz machten. Schließlich haben Administratoren Zugriff auf die Protokolldaten und könnten durch die Lektüren der Protokolle erkennen, zu welchen Themen die Benutzer E-Mails versenden. Es stimmt zwar, dass sich ein besessener Administrator die Zeit nehmen könnte, den Nachrichtenverkehr eines einzelnen Benutzers oder zwischen zwei bestimmten Benutzern zu analysieren, aber in der Praxis ist das eher unwahrscheinlich, weshalb das Risiko als gering eingestuft werden kann. Die normalen Datenschutzbestimmungen im Unternehmen sollten in jedem Fall Administratortätigkeiten dieser Art unterbinden und angemessene Sanktionen für jemanden vorsehen, der verrückt genug ist, die Nachrichtenverfolgungsdaten auf diese Weise zu missbrauchen. Was wirklich zählt, ist die Tatsache, dass die Betreffdaten für Administratoren sehr hilfreich sein können, wenn sie gebeten werden, dem Verbleib einer Nachricht nachzuspüren. Nachrichtenverfolgung auf Postfachservern
Manche Administratoren fragen sich, warum sie die Nachrichtenverfolgung auf Postfachservern aktivieren sollten. Schließlich leitet Exchange doch alles durch die Hub-Transport-Server, um eine zentrale Stelle für die Anwendung von Funktionen wie Transportregeln bereitzustellen. Reicht es daher nicht aus, die Nachrichtenverfolgung nur auf den Hub-Transport-Servern zu aktivieren? Allerdings entspringen Nachrichten nun einmal auf Postfachservern, und wenn Sie ein Gesamtbild des Verlaufs einer Nachricht haben wollen, dann müssen Sie auch alle auftretenden Ereignisse erfassen. Dabei sind vor allem drei Dinge von Interesse, die auf Hub-Transport-Servern nicht vorkommen: 1. Das ursprüngliche Übermittlungsereignis, wenn ein Benutzer eine Nachricht sendet. Es kann
im Hinblick auf das Empfangsereignis auf dem Hub-Transport-Server untersucht werden, der die Nachricht verarbeitet. 2. Das endgültige Zustellereignis, nachdem das Transportsystem die Nachricht vollständig verarbeitet und an den Postfachserver übergeben hat, auf dem sich das Postfach des Benutzers zurzeit befindet. Anhand dieses Ereignisses können Sie ablesen, ob eine Posteingangsregel ausgelöst und die Nachricht daher in einen anderen Ordner verschoben wurde. 3. Der Lesestatus der Nachricht, der nach dem Abschluss der Verarbeitung in den Nachrichteneigenschaften angezeigt wird. Aus diesen Gründen ist es tatsächlich sinnvoll, die Nachrichtenverfolgung auch auf allen Postfachservern zu aktivieren.
940
Nachrichtenverfolgung
Auf einem Server finden Sie drei verschiedene Protokolle: 쐍 MSGTRK<JJJJMMTT-N>.LOG In diesem Protokoll werden Informationen über die Routingvorgänge für eine Nachricht gespeichert, z.B. die Erweiterung der Verteilergruppen und die Weiterleitung an andere SMTP-Server. 쐍 MSGTRKA<JJJJMMTT-N>.LOG Dieses Protokoll enthält Informationen über die Ereignisse, die bei modererierten Nachrichten in einem Vermittlungspostfach auftreten. 쐍 MSGTRKM<JJJJMMTT-N>.LOG Die Daten in diesem Protokoll beziehen sich auf die Verarbeitung auf einem Postfachserver, z.B. die Übertragung der Nachrichten vom Client über den Speichertreiber zu einem Hub-Transport-Server. JJJJMMTT ist das Datum und N die laufende Nummer des an diesem Datum erstellten Protokolls. Beispielsweise ist MSGTRK20100720-1.LOG das erste Nachrichtenverfolgungsprotokoll mit Daten über Routingvorgänge, das am 20.7.2010 erstellt wurde. Die Standardgröße für Nachrichtenverfolgungsprotokolle beträgt 10 MB. Ist ein Protokoll voll, erstellt Exchange ein neues und hängt die weiteren Transaktionsdaten am Ende des neuen Protokolls an. Die Protokolle werden 30 Tage lang aufbewahrt oder bis die eingestellte Größe des Protokollverzeichnisses überschritten ist. In letzterem Fall greift Exchange auf das Prinzip der Umlaufprotokollierung zurück und löscht die ältesten Protokolle, bis die Verzeichnisgröße wieder unter den Grenzwert fällt. Die maximale Größe für Nachrichtenprotokolle und das Protokollverzeichnis sowie die Aufbewahrungsdauer können Sie mit dem Cmdlet Set-MailboxServer (auf einem Postfachserver) bzw. Set-TransportServer (auf einem Hub-TransportServer) festlegen. Wie stark die Protokolle wachsen, hängt vom Nachrichtenverkehr auf dem Server und den für das Routing erforderlichen Vorgängen ab. Insidertipp: Überprüfen der Grenzwerte
Eine einfache Nachricht von einem Benutzer zu einem anderen ruft weniger als 1 KB an Nachrichtenverfolgungsdaten hervor, wohingegen bei Nachrichten an umfangreiche Verteilergruppen mit über 100 Empfängern, von denen einige unerreichbar sind oder Abwesenheitsmeldungen zurücksenden, 30 KB und mehr anfallen können. Hub-Transport-Server, die ein großes Aufkommen an Datenverkehr für eine Organisation verarbeiten, können jeden Tag mehr als 300 MB (also wöchentlich 2 GB) an Verfolgungsprotokollen hervorrufen. Das ist natürlich nicht auf jedem Server der Fall, aber Sie müssen die Situation auf Ihren Postfach- und Hub-Transport-Servern messen und überprüfen, damit Exchange nicht in die Lage kommt, wertvolle Daten zu löschen, um einen zu niedrig angesetzten Grenzwert nicht zu überschreiten, bevor Sie die Gelegenheit haben, die Protokolle zu analysieren. Die Daten der Nachrichtenverfolgungsprotokolle sind wie die der Transportprotokolle im CSV-Format gespeichert, sodass Sie die Protokolle mit so verschiedenen Programmen wie dem Windows-Editor und Microsoft Excel öffnen können. Abbildung 15.4 zeigt, was Sie in einem solchen Protokoll erwarten können. Die Zeilen 2 bis 4 nennen die Version, den Protokolltyp sowie das Datum und die Uhrzeit, an der das Protokoll erstellt wurde. In der fünften Zeile finden Sie die Kopfzeilen für die Spalten mit den Daten der Protokolleinträge. Tabelle 15.2 gibt einen Überblick über diese Spalten und ihre Bedeutung.
941
Die Exchange-Toolbox
Die Protokolldateien der Nachrichtenverfolgung
Kapitel 15
Die Exchange-Toolbox
Abbildg. 15.4
Anzeige der Daten in einem Nachrichtenverfolgungsprotokoll
Tabelle 15.2
Bedeutung der Spalten in Nachrichtenverfolgungsprotokollen
942
Spalte
Bedeutung
date-time
Datum und Uhrzeit des Messagingereignisses, angegeben auf Sekundenbruchteile im Format ISO 8601 oder UTC.
client-ip
Die IP-Adresse des Servers oder Clients, der die Nachricht übermittelt hat.
client-hostname
Der Name des Servers oder Clients, der die Nachricht übermittelt hat.
server-ip
Die IP-Adresse des Exchange Server-Computers, der die Nachricht verarbeitet.
server-hostname
Der Name des Exchange Server-Computers, der die Nachricht verarbeitet.
source-context
In diesem Feld werden zusätzliche Informationen über einen Vorgang erfasst, z.B. die Angabe, welchen Domänencontroller der Transportdienst zur Erweiterung einer Verteilergruppe verwendet hat.
connector-id
Der Name des mit dem Ereignis verbundenen Connectors. Dieses Feld wird nicht bei allen Ereignissen ausgefüllt.
source
Die Transportkomponente, die das Ereignis hervorgerufen hat. Möglich sind folgende Angaben: ADMIN: Wiedergabe von Nachrichten aus dem Transportpapierkorb. AGENT: Verarbeitung durch einen Transport-Agent. DSN: Erstellen einer Benachrichtung über den Übermittlungstatus. GATEWAY: Übermittlung einer Nachricht von einem fremden E-Mail-System über einen Connector. PICKUP: Annahme einer Nachricht aus dem Pickup- oder Wiedergabeverzeichnis. ROUTING: Verarbeitung einer Nachricht durch das Routingmodul. SMTP: Übertragung einer Nachricht durch einen SMTP-Connector. STOREDRIVER: MAPI-Interaktion mit dem Informationsspeicher auf Postfachservern.
event-id
Eine Liste gültiger Ereignisse finden Sie in Tabelle 15.3.
Nachrichtenverfolgung
Bedeutung der Spalten in Nachrichtenverfolgungsprotokollen (Fortsetzung) Spalte
Bedeutung
internal-message-id
Eine Zahl, die die Nachricht auf dem Server mit dem Nachrichtenverfolgungsprotokoll eindeutig kennzeichnet. Die einzelnen Server, die die Nachricht verarbeiten, verwenden für ein und dieselbe Nachricht jeweils unterschiedliche interne Nachrichtenkennnungen.
message-id
Eine einheitliche Kennung, die die Nachricht während ihrer ganzen Lebensdauer begleitet und in ihrem Header vermerkt ist.
recipient-address
Eine durch Semikolons getrennte Liste der Empfänger einer Nachricht. In diesem Feld stehen auch die Namen von Verteilergruppen, bevor sie vom Transportdienst erweitert werden.
recipient-status
Dieses Feld wird nur dann ausgefüllt, wenn die Nachricht an einen anderen SMTPServer gesendet wird. In diesem Fall wird der Erfolg oder Fehlschlag der Empfängerprüfung vermerkt.
total-bytes
Die Größe der Nachricht in Bytes einschließlich der Anhänge.
recipient-count
Die Anzahl der Empfänger einer Nachricht. Eine Verteilergruppe gilt bis zur Erweiterung der Mitgliedschaft als ein Empfänger.
related-recipientaddress
Ein Feld zur Erfassung zusätzlicher Informationen für EXPAND-, RESOLVE- und REDIRECT-Ereignisse. Bei EXPAND-Ereignissen wird hier der Name der Verteilergruppe abgelegt, die in einzelne Adressen aufgelöst wird, während bei RESOLVEEreignissen, bei denen der Transportdienst eine Nicht-SMTP-Adresse in einem Nachrichtenheader auflösen muss, in diesem Feld die aufgelöste Adresse vermerkt wird.
reference
Ein Feld zur Erfassung zusätzlicher Informationen für DSN-, SEND- und TRANSFEREreignisse. Wenn Exchange beispielsweise eine Benachrichtigung über den Übermittlungsstatus (Delivery Status Notificaton, DSN) sendet, wird die Nachrichtenkennung in diesem Feld abgelegt und der Grund für den DSN in das Feld source-context geschrieben.
message-subject
In diesem Feld werden die Betreffzeilen erfasst, falls diese Funktion auf dem Server eingerichtet ist.
sender-address
Die E-Mail-Adresse des Absenders, die im Absenderfeld des Nachrichtenheaders gespeichert ist. Falls das betreffende Feld im Header leer ist, nimmt Exchange den Wert aus dem Feld From.
return-path
Die Antwortadresse für die Nachricht, die aus dem Feld MAIL FROM im Nachrichtenumschlag entnommen wird. Bei vielen Ereignissen, bei denen es nicht sinnvoll ist, einen Antwortpfad anzugeben, wird <> in dieses Feld eingetragen«
message-info
Enthält die Entstehungszeit der Nachricht für DELIVER- und SEND-Ereignisse. Dabei handelt es sich um die Uhrzeit, zu der die Nachricht zum ersten Mal in die ExchangeOrganisation eingegangen ist. Angegeben wird sie im UTC-Format.
message-latency
Die von Exchange berechnete Wartezeit in Sekunden.
message-latency-type
Das Verfahren, mit dem die Wartezeit gemessen wird. Beispielsweise bedeutet EndtoEnd die vollständige Dauer von der Einreichung der Nachricht bis zu ihrer Zustellung.
Mit dem Cmdlet Get-MessageTrackingLog können Sie Einblick in die Nachrichtenverfolgungsprotokolle gewinnen. dabei werden die verschiedenen Protokolle zu einem zusammenhängenden Ganzen kombiniert und die Ereignisse zeitlich geordnet. Wenn Sie keine Parameter angeben, öffnet Exchange das jüngste Protokoll und führt alle Einträge auf, bis das Ende des letzten verfügbaren Protokolls erreicht ist oder der Grenzwert für den Ergebnisanzeige der Exchange-Verwaltungsshell erreicht ist. Der Standardgrenzwert beschränkt den Abruf und die Anzeige von Ergebnissen auf 5000 Einträge.
943
Die Exchange-Toolbox
Tabelle 15.2
Kapitel 15
Die Exchange-Toolbox
Deuten der Einträge in Protokollen der Nachrichtenverfolgung Aufgrund der Menge von Daten, die bei der Nachrichtenverfolgung auf einem Produktionsserver erfasst werden, ist es wichtig, bei der Anzeige der Protokolle mit Get-MessageTrackingLog sehr genaue Parameter anzugeben, um die Suche einzugrenzen und nur die wirklich bedeutungsvollen Daten zurückzugeben. Ausführliche Nachrichtenverfolgungsprotokolle zu durchkämmen ist eine nervtötende Angelegenheit. TIPP Denken Sie auch daran, bei der Verwendung des Cmdlets Get-MessageTrackingLog den Parameter -Server anzugeben, da Exchange ansonsten die Einträge von dem Server ausgibt, auf dem die Exchange-Webdienste ausgeführt werden. Da kann jedoch auch ein reiner Clientzugriffsserver sein, der überhaupt nichts mit dem Nachrichtentransport zu tun hat, sodass die Suche nichts zutage fördert. Um sinnvoll mit Nachrichtenverfolgungsprotokollen arbeiten zu können, müssen Sie wissen, was die einzelnen Einträge bedeuten. Exchange kennzeichnet jeden Eintrag mit einer Ereigniskennung, um anzuzeigen, in welcher Verarbeitungsphase sich die Nachricht gerade befindet. In Tabelle 15.3 finden Sie eine vollständige Liste aller Ereigniskennungen, die Exchange in diesen Protokollen verwendet. Tabelle 15.3
944
Ereigniskennungen in Nachrichtenverfolgungsprotokollen Ereigniskennurngrr
Bedeutung
AGENT
Ein Transport- oder Journal-Agent hat die Nachricht verarbeitet.
BADMAIL
Der Transportdienst hat eine Nachricht aus dem Pickup- oder Wiedergabeverzeichnis entnommen, die nicht verarbeitet oder an den Absender zurückgeschickt werden kann.
DELIVER
Die Nachricht wurde im Postfach zugestellt. Damit ist die Verarbeitung abgeschlossen.
DEFER
Die Zustellung der Nachricht wurde verzögert.
DSN
Der Transportdienst hat eine Benachrichtigung über den Übermittlungsstatus (DSN) erstellt.
DUPLICATEDELIVER
Der Transportdienst hat nach der Auflösung aller Adressen eine doppelte Adresse im Nachrichtenheader entdeckt. Die doppelte Adresse wurde entfernt.
EXPAND
Eine Verteilergruppe wurde erweitert, um die Mitgliedschaft zu bestimmen und mit dem Routing fortzufahren.
FAIL
Bei der Weiterleitung der Nachricht ist ein Fehler aufgetreten. Beispielsweise kann es sein, dass eine Transportregel zur Ablehnung der Nachricht geführt hat.
INITMESSAGE
Der Transportdienst löst die nächste Phase bei einer moderierten Nachricht aus.
NOTIFYMAPI
Ein Postfach-Agent hat dem Speichertreiber eine MAPI-Benachrichtigung zukommen lassen, die an einen Endbenutzer zugestellt werden soll, z.B. eine Warnung, dass das Postfachkontingent fast erschöpft ist. Solche Ereignisse werden nur auf Postfachservern erfasst.
Nachrichtenverfolgung
Ereigniskennungen in Nachrichtenverfolgungsprotokollen Ereigniskennurngrr
Bedeutung
POISONMESSAGE
Der Transportdienst ist zu dem Schluss gekommen, dass eine Nachricht ungute Inhalte aufweist (also sozusagen »vergiftet« ist) und hat sie daher in die Warteschlange für nicht verarbeitete Nachrichten gestellt. Dieses Ereignis wird auch in dem Fall aufgezeichnet, dass der Transportdienst eine Nachricht wieder aus dieser Warteschlange herausnimmt, um die Verarbeitung fortzusetzen.
PROCESS
Der Transportdienst verarbeitet eine moderierte Nachricht.
RECEIVE
Eine Nachricht wurde empfangen und mit Commit in die Datenbank des Transportdienstes geschrieben.
REDIRECT
Nach der Überprüfung des ursprünglichen Empfängers in Active Directory wurde die Nachricht an einen alternativen Empfänger umgeleitet.
RESOLVE
Die Adressen für einen oder mehrere Empfänger einer Nachricht wurden nach der Überprüfung in Active Directory zu mehreren E-Mail-Adressen aufgelöst.
SEND
Der Transportdienst hat eine Nachricht über SMTP an einen anderen Server übertragen.
SUBMIT
Ein Postfachserver hat eine Nachricht zur Verarbeitung auf einen Hub-Transport-Server übertragen.
TRANSFER
Aufgrund einer Konvertierung, einer Beschränkung der Empfängeranzahl oder irgendeiner erforderlichen Form der Verarbeitung durch einen Agent, z.B. eine Transportregel, wurden Empfänger zu einer verzweigten Nachricht verschoben.
Im Folgenden finden Sie die Protokolleinträge für eine einfache Transaktion, bei der ein Benutzer eine Nachricht an einen anderen geschickt hat. Die Datenbanken mit den beiden Postfächern befinden sich in diesem Beispiel auf demselben Server. Der Deutlichkeit halber wurde die Ausgabe gekürzt. Die Ausgabe von Get-MessageTrackingLog zeigt im Großen und Ganzen die in Tabelle 15.2 beschriebenen Felder, wird aber durch die Formatierung leichter lesbar gemacht. Beispielsweise wird beim Zeitstempel die im Protokoll genannte UTC-Zeit in die lokale Serverzeit umgerechnet. Als Erstes wollen wir uns den Eintrag auf dem Postfachserver ansehen, auf dem der Benutzer die Nachricht einreicht. Wir wissen also, dass wir nach einem SUBMIT-Eintrag suchen müssen. Um die Daten abzurufen, können wir daher einen Befehl wie den folgenden verwenden. Bei der Suche nach dem Nachrichtenbetreff reicht es, die ersten Buchstaben anzugeben, und auch die Groß- und Kleinschreibung muss nicht übereinstimmen. Wenn Sie bei der Suche ein Anfangdatum angeben, müssen Sie auch ein Enddatum nennen, da die Exchange-Verwaltungsshell sonst einen Fehler meldet. Get-MessageTrackingLog –Server ExServer1 –MessageSubject 'Fantastic news' -Sender '[email protected]' –Start '5/20/2010 11:30' –End '5/20/2010 11:59' –EventId 'SUBMIT' | Format-List Timestamp ClientIp ClientHostname ServerIp ServerHostname
: : : : :
5/20/2010 11:54:30 AM fe80::3ccc:8a87:db9b:87%12 EXSERVER1 EXSERVER1
945
Die Exchange-Toolbox
Tabelle 15.3
Kapitel 15
Die Exchange-Toolbox
SourceContext
: MDB:86137325-d162-4655-a3f6-f9ddf4ccbd4a, Mailbox:dcca82c0-10b74337-8dab-7bcc6a7ed54f, Event:88401, MessageClass:IPM.Note, CreationTime:2010-05-20T10:53:45.095Z, ClientType :OWA ConnectorId : Source : STOREDRIVER EventId : SUBMIT InternalMessageId : MessageId : <[email protected]> Recipients : {} RecipientStatus : {} TotalBytes : RecipientCount : RelatedRecipientAddress : Reference : MessageSubject : Fantastic news Sender : [email protected] ReturnPath : MessageInfo : 2010-05-20T10:53:45.095Z;LSRV=EXSERVER1.contoso.com: TOTAL=45|MSSN=2|MSSFA=42 MessageLatency : 00:00:45.1410000 MessageLatencyType : LocalServer
An diesem Eintrag können wir Folgendes ablesen: 쐍 Die Namen des Postfachservers (ClientHostname), auf dem der Benutzer die Nachricht erstellt hat (ExServer1), und des Hub-Transport-Servers (ServerHostname), mit dem der Informationsspeicher auf dem Postfachserver verbunden ist. 쐍 Einige Angaben (SourceContext) über die Postfachdatenbank und die Postfächer, von denen die Nachricht stammt (angegeben sind die global eindeutigen Bezeichner), der Nachrichtentyp (IPM.Note) und der verwendete Client (Outlook Web App). 쐍 Die Quelle der Nachricht ist STOREDRIVER, woraus wir ablesen können, dass die Nachricht vom Speichertreiber auf dem Postfachserver in den Transportdienst eingebracht wurde. Der Speichertreiber ist für die gesamte Interaktion zwischen Postfachdatenbanken und Transportdienst zuständig. Denken Sie daran, dass Exchange alle Nachrichten über Hub-Transport-Server laufen lässt, damit Transportregeln und andere Richtlinien einheitlich angewendet werden können, selbst wenn sich die Ursprungs- und die Zieldatenbank auf demselben Servercomputer befinden. 쐍 Die interne Nachrichtenkennung ist eindeutig und dient dazu, alle Transaktionen einer Nachricht nachverfolgen zu können. Wenn Sie diesen Wert in Get-MessageTrackingLog eingeben, können Sie damit alle Protokolleinträge abrufen, die den Weg dieser bestimmten Nachrichten betreffen. 쐍 Der Absender ist durch seine SMTP-Adresse eindeutig gekennzeichnet. 쐍 Am Ende des Protokolleintrags finden Sie einige Informationen über die Leistung der Nachrichteninformationen. Wie Sie diese Angaben nutzen, sehen wir uns in Kürze an.
946
Der nächste Schritt auf dem Weg der Nachricht besteht darin, dass sie vom Transportdienst angenommen und zur weiteren Verarbeitung in eine Warteschlange gestellt wird. Diese Phase ist durch einen RECEIVE-Eintrag gekennzeichnet, wenn der Transportdienst die Nachricht mit einem Commit in seine Datenbank schreibt. Der folgende Eintrag stammt von dem Hub-Transport-Server, der die Nachricht verarbeitet: Timestamp ClientIp ClientHostname ServerIp ServerHostname SourceContext ConnectorId Source EventId InternalMessageId MessageId Recipients RecipientStatus TotalBytes RecipientCount RelatedRecipientAddress Reference MessageSubject Sender ReturnPath MessageInfo MessageLatency MessageLatencyType
: : : : : : : : : : : : : : : : : : : : : : :
5/20/2010 11:54:30 AM fe80::3ccc:8a87:db9b:87 EXSERVER1.contoso.com fe80::3ccc:8a87:db9b:87%12 ExServer1 08CCC5C2F0411286 STOREDRIVER RECEIVE 174 <[email protected]> {[email protected]} {To} 4159 1
Fantastic news [email protected] [email protected] 04I: None
Hier können wir Folgendes erkennen: 쐍 Client und Server in dieser Transaktion sind wie zu erwarten gleich geblieben. Der Speichertreiber auf ExServer1 fungiert als Client zur Übermittlung der Nachricht an den Transportdienst, der ebenfalls auf ExServer1 läuft. 쐍 Die Ereigniskennung lautet RECEIVE, woraus wir ablesen können, dass der Hub-Transport-Server die Nachricht zur Verarbeitung empfangen hat. 쐍 Die Felder TotalBytes und RecipientCount sind ausgefüllt worden, nachdem der Transportdienst die Nachricht angenommen hat. Unsere Nachricht ist jetzt von einem Hub-Transport-Server angenommen worden und wird dort verarbeitet. Nachdem dieser Server die Kategorisierung abgeschlossen und die Routingentscheidungen getroffen hat, gibt er die Nachricht an den Postfachserver zurück, damit sie an die Datenbank mit dem Empfängerpostfach ausgeliefert werden kann. Auf dem Hub-Transport-Server sehen wir dazu folgenden Eintrag:
947
Die Exchange-Toolbox
Nachrichtenverfolgung
Kapitel 15
Die Exchange-Toolbox
Timestamp ClientIp ClientHostname ServerIp ServerHostname SourceContext ConnectorId Source EventId InternalMessageId MessageId Recipients RecipientStatus TotalBytes RecipientCount RelatedRecipientAddress Reference MessageSubject Sender ReturnPath MessageInfo
MessageLatency MessageLatencyType EventData
: : : : : : : : : : : : : : : : : : : : :
5/20/2010 11:55:12 AM ExServer1 EXSERVER1 08CCC5C2F041128A;2010-05-20T10:55:12.533Z;0 STOREDRIVER DELIVER 175 <[email protected]> {[email protected]} {} 5014 1
Fantastic news [email protected] [email protected] 2010-05-20T10:53:45.095Z;SRV=EXSERVER1.contoso.com: TOTAL=44|MSSN=2|MSSFA=42;SRV=EXSERVER1.contoso.com: TOTAL=42|QD=42 : 00:01:27.5630000 : EndToEnd : {[MailboxDatabaseName, db1], [DatabaseHealth, -1]}
Diese Daten unterscheiden sich von dem ursprünglichen Eintrag: 쐍 Quelle für den Eintrag ist nach wie vor STOREDRIVER, aber die Ereigniskennung lautet jetzt DELIVER, um anzuzeigen, dass der Speichertreiber die Nachricht vom Transportdienst empfangen hat, um sie in der Datenbank mit dem Postfach des Empfängers zuzustellen. 쐍 Die interne Nachrichtenkennung, die Empfänger, der Absender usw. bleiben gleich. 쐍 Der Gesamtumfang in Bytes hat sich geändert. Das zeigt an, dass das Transportsystem eine Verarbeitung vorgenommen hat, die sich auf den Nachrichteninhalt auswirkt. In diesem Fall hat eine Transportregel der Nachricht eine automatische Signatur hinzugefügt, was die geänderte Größe erklärt. 쐍 Da die Nachricht am Ende ihres Weges steht, hat Exchange die Informationsfelder aktualisiert, um darin die einzelnen Schritte des Routing und die Wartezeit anzugeben. Diese Informationen können Sie mit Produkten wie Microsoft System Center Operations Manager analysieren und als Bericht ausgeben, um sich ein Gesamtbild der Routingleistung in der Organisation zu verschaffen. 쐍 Die Informationen im Feld EventData (das auch bei den anderen Routingeinträgen ausgefüllt war) ist neu in Exchange Server 2010 SP1 und dient dazu, unterschiedliche Klassen von Nachrichten zu unterscheiden. In diesem Fall wird die Datenbank angegeben, zu der die Nachricht zugestellt wird, und angezeigt, dass sich diese Datenbank in einwandfreiem Zustand befindet.
948
Anhand dieser Einträge können wir erkennen, dass der einfachste Pfad, den eine Nachricht von einem Benutzer zu einem anderen Empfänger in derselben Exchange-Organisation nehmen kann, von drei Einträgen im Nachrichtenverfolgungsprotokoll aufgezeichnet wird: 쐍 SUBMIT Wird auf dem Postfachserver protokolliert, um die Übertragung auf den Hub-Transport-Server anzuzeigen. 쐍 RECEIVE Wird auf dem Hub-Transport-Server protokolliert, wenn er die Nachricht angenommen hat. 쐍 DELIVER Wird auf dem Hub-Transport-Server protokolliert, wenn er die Nachricht an den Postfachserver mit dem Empfängerpostfach übertragen hat. Nachrichten von einem Postfach zu einem einzigen anderen machen natürlich nur einen Bruchteil derjenigen aus, die auf Produktionsservern verschickt werden. Sehen wir uns daher als Nächstes an, wie die Protokolleinträge für andere Vorgänge aussehen. Als Erstes betrachten wir die Einträge, die auf einem Hub-Transport-Transport-Server aufgezeichnet werden, nachdem er von einem Postfachserver eine Nachricht an eine Verteilergruppe erhalten hat: EventId ------SUBMIT RECEIVE
Source -----STOREDRIVER STOREDRIVER
Sender [email protected] [email protected]
EXPAND
ROUTING
[email protected]
TRANSFER ROUTING
[email protected]
DELIVER DELIVER
STOREDRIVER [email protected] STOREDRIVER [email protected]
Recipients ---------{} {[email protected], [email protected]} {[email protected], [email protected].. {[email protected], [email protected].. {[email protected]} {[email protected], [email protected]..
Die Einträge sind anders und viel zahlreicher: 쐍 Die Nachricht wird vom Absender übermittelt (SUBMIT). 쐍 Wie zuvor nimmt der Hub-Transport-Server die Nachricht vom Postfachserver an und schreibt sie mit Commit in seine Datenbank, um sie zu verarbeiten (RECEIVE). 쐍 Da die Nachricht an eine Verteilergruppe adressiert ist, tritt als nächstes Ereignis die Erweiterung der Gruppenmitgliedschaft auf, damit die Nachricht weitergeleitet werden kann (EXPAND). Wenn wir uns den EXPAND-Eintrag mit allen Einzelheiten ansehen, können wir sämtliche Empfänger erkennen. 쐍 Anschließend tritt ein TRANSFER-Ereignis auf. Aus Tabelle 15.3 wissen Sie, dass dieses Ereignis aufgezeichnet wird, wenn der Transportdienst die Nachricht aus irgendeinem Grund verzweigen muss. Das bedeutet, dass er zusätzliche Kopien von ihr anlegt, weil für einen oder mehrere Empfänger besondere Verarbeitungsschritte erforderlich sind. Beispielweise können einige Empfänger festgelegt haben, dass sie Nachrichten nur in einem bestimmten Format erhalten möchten, das von dem ursprünglichen Format abreicht. Es ist auch möglich, dass die Nachricht von einer Transportregel verarbeitet wird, die für einige, aber nicht alle Empfänger ein Präfix in den Betreff schreibt. 쐍 Für jede Postfachdatenbank, die Empfänger dieser Nachricht enthält, wird ein DELIVER-Ereignis aufgezeichnet. 949
Die Exchange-Toolbox
Nachrichtenverfolgung
Kapitel 15
Die Exchange-Toolbox
Im EXPAND-Ereignis ist der Domänencontroller verzeichnet, den der Hub-Transport-Server zum Abrufen der Gruppenmitgliedschaft verwendet. Außerdem finden Sie darin die Anzahl der Empfänger nach der Erweiterung und eine Liste der zurückgegebenen Adressen. Timestamp ClientIp ClientHostname ServerIp ServerHostname SourceContext ConnectorId Source EventId InternalMessageId MessageId Recipients
: : : : : : : : : : : :
RecipientStatus TotalBytes RecipientCount RelatedRecipientAddress Reference MessageSubject Sender ReturnPath MessageInfo MessageLatency MessageLatencyType EventData
: : : : : : : : : : : :
5/20/2010 12:09:00 PM
ExServer1 ADRoot.contoso.com ROUTING EXPAND 186 <[email protected]> {[email protected], [email protected], [email protected]} {250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded} 4679 3 [email protected] Fabrikam contract [email protected] [email protected]
None
Bei Nachrichten an dynamische Verteilergruppen tritt im Großen und Ganzen die gleiche Art von Verarbeitung auf. Das EXPAND-Ereignis wird aufgezeichnet, wenn der Transportdienst an Active Directory die OPATH-Abfrage zur Bestimmung der Gruppenmitgliedschaft stellt. Eingehende Nachrichten, die von einem Hub-Transport-Server verarbeitet und an einen Postfachserver gehen, werden durch ein RECEIVE-Ereignis für die Annahme der E-Mails und ein DELIVEREreignis für die Zustellung auf dem Server mit der Postfachdatenbank erfasst. Der Eintrag für das RECEIVE-Ereignis enthält auch einige Informationen über den Remoteserver, der die Nachricht gesendet hat, und Angaben darüber, wie Exchange die E-Mail verarbeitet. Das können Sie an dem folgenden vollständigen Eintrag erkennen: Timestamp ClientIp ClientHostname ServerIp ServerHostname SourceContext
950
: : : : : :
5/20/2010 12:09:00 PM fe80::3ccc:8a87:db9b:87 EXSERVER1.contoso.com fe80::3ccc:8a87:db9b:87%12 ExServer1 08CCC5C2F0411297
ConnectorId : Source : STOREDRIVER EventId : RECEIVE InternalMessageId : 186 MessageId : <[email protected]> Recipients : {[email protected], [email protected]} RecipientStatus : {To, Cc} TotalBytes : 4679 RecipientCount : 2 RelatedRecipientAddress : Reference : MessageSubject : Fabrikam contract Sender : [email protected] ReturnPath : [email protected] MessageInfo : 04I: MessageLatency : MessageLatencyType : None EventData : {[MailboxDatabaseGuid, 86137325-d162-4655-a3f6-f9ddf4ccbd4a], [ItemEntryId, 00-00-00-00-3F-B3-69-A2-69-A7-FC-4B-BC-C6-8D-C2-2D-FD-EE-41-07-00-7E-E1-57F8-67-DA-37-48-A7-8C-30-7F-94-77-68-AB-00-00-00-85-AD-95-00-00-7E-E1-57-F8-67-DA-37-48-A78C-30-7F-94-77-68-AB-00-00-01-81-33-83-00-00]}
Ausgehende Nachrichten, die die Exchange-Organisation verlassen, reisen über einen SMTP- oder einen anderen Connector an ihren Bestimmungsort. Das folgende Beispiel zeigt das SEND-Ereignis für eine SMTP-Nachricht, die über den Connector Intra-Organization SMTP Send Connector zum Edge-Transport-Server exedge1.contoso.com gesendet wurde. Da die Nachricht die Exchange-Organisation jetzt verläst, sind die Informationsfelder am Ende des Eintrags ausgefüllt, um festzuhalten, wie lange die Übertragung bis zu dieser Stelle gedauert hat. Timestamp ClientIp ClientHostname ServerIp ServerHostname SourceContext
: : : : : :
ConnectorId Source EventId InternalMessageId MessageId Recipients RecipientStatus TotalBytes RecipientCount
: : : : : : : : :
5/20/2010 12:16:04 PM 192.165.65.50 ExServer1 192.165.65.71 ExEdge1.contoso.com 08CCC5C2F041129F;250 2.6.0 <[email protected]> [InternalId=20] Queued mail for delivery Intra-Organization SMTP Send Connector SMTP SEND 192 <[email protected]> {[email protected]} {250 2.1.5 Recipient OK} 4706 1
951
Die Exchange-Toolbox
Nachrichtenverfolgung
Kapitel 15
Die Exchange-Toolbox
RelatedRecipientAddress Reference MessageSubject Sender ReturnPath MessageInfo MessageLatency MessageLatencyType EventData
: : : : : : : : :
RE: Fabrikam contract [email protected] [email protected] 2010-05-20T11:16:03.955Z;LSRV=EXSERVER1.contoso.com:TOTAL=0 00:00:01 LocalServer
Messen der Nachrichtenwartezeit Neu im Transportdienst von Exchange Server 2010 ist die Möglichkeit zur Messung der Wartezeit. Dadurch können Produkte wie Microsoft System Center Operations Manager Berichte über die Serverleistung erstellen, um die Einhaltung von Serviceverträgen zu überwachen. Während die Nachrichten den Transportdienst durchlaufen, erfasst Exchange Zeitdaten und schreibt diese Informationen in die Nachrichtenverfolgungsprotokolle. In den zuvor gezeigten Protokolleinträgen finden Sie die Angaben über die Wartezeiten in den Feldern MessageLatency und MessageLatencyType. Die Daten in den einzelnen Einträgen sind für sich genommen nicht sehr aussagekräftig, sondern erst dann, wenn Sie die Messungen auf dem gesamten Weg einer Nachricht von ihrem Ursprung bis zur endgültigen Zustellung zu einem Gesamtbild zusammenfassen. Um sich eine Vorstellung davon zu machen, wie Sie diese Daten nutzen können, wählen Sie mit Get-MessageTrackingLog einige Nachrichten aus und leiten die Ausgabe in das Skript ConvertTo-MessageLatency.ps1, das Sie im Verzeichnis \Scripts finden. Am besten machen Sie das mit einigen Nachrichten, die Sie selbst gesendet haben, damit Sie Ihr Wissen über die Nachrichten und ihre Empfänger mit den Ergebnissen des Skripts in Zusammenhang bringen können. Der folgende Befehl zeigt beispielhaft, wie Sie dieses Skript mit Nachrichtenverfolgungsdaten füllen und wie die Ausgabe aussieht (sie ist bearbeitet worden, um die wichtigsten Punkte deutlicher hervorzuheben): Get-MessageTrackingLog –Sender '[email protected]' –Start '05/20/2010 12:30' –End '05/20/2010 13:30' | .\ConvertTo-MessageLatency.ps1
952
InternalMessageId MessageId MessageLatency MessageLatencyType ComponentServerFqdn ComponentCode ComponentName ComponentLatency
: : : : : : : :
206 <[email protected]> 00:00:01.9840000 LocalServer EXSERVER1.contoso.com CAT Categorizer 00:00:01
InternalMessageId MessageId MessageLatency MessageLatencyType ComponentServerFqdn
: : : : :
206 <[email protected]> 00:00:48.4370000 EndToEnd EXSERVER1.contoso.com
ComponentCode ComponentName ComponentLatency
: TOTAL : Total Server Latency : 00:00:47
InternalMessageId MessageId MessageLatency MessageLatencyType ComponentServerFqdn ComponentCode ComponentName ComponentLatency
: : : : : : : :
206 <[email protected]> 00:00:48.4370000 EndToEnd EXSERVER1.contoso.com SDD Store Driver Delivery 00:00:04
InternalMessageId MessageId MessageLatency MessageLatencyType ComponentServerFqdn ComponentCode ComponentName ComponentLatency
: : : : : : : :
206 <[email protected]> 00:00:48.4370000 EndToEnd EXSERVER1.contoso.com QD Delivery Queue 00:00:41
Der erste Eintrag gibt an, wie viel Zeit die Nachricht im Kategorisierungsmodul zugebracht hat, der nächste zeigt den Übergang in die lokale Übermittlungswarteschlange. (Hier zahlen sich meine Kenntnisse über die Nachricht aus, denn ich weiß, dass sie von einem Postfach auf dem Computer ExServer1 gesendet wurde.) Der dritte Eintrag berichtet von der Übertragung durch den Speichertreiber zur Zustellung an eine Postfachdatenbank auf demselben Server, und der letzte nennt Einzelheiten der Übermittlung an einen anderen Hub-Transport-Server im selben Standort. Die Wartezeiten sind klar und deutlich in Sekunden angegeben. Die ersten drei Einträge betreffen die Zustellung auf demselben Server, weshalb die gesamte Auslieferungszeit vom Einreichen der Nachricht bis zur Zustellung insgesamt weniger als sechs Sekunden beträgt. Zur Auslieferung auf den zweiten HubTransport-Server benötigt sie etwas länger. Das ist zwar alles schön und gut, aber es wäre ein Unding, von Administratoren zu verlangen, dass sie Zehntausende von Nachrichtenverfolgungsprotokollen durchgehen, um die Leistung der Server zu überwachen. Daher verarbeitet Exchange diese Protokolle auf Hub-Transport-Servern automatisch und formt daraus eine Reihe von Statistiken für die Analyse und Berichterstattung. Dabei werden die Daten wie folgt erfasst: 쐍 Jede Stunde werden Daten über den Nachrichtenverkehr zwischen den Servern in Protokolldateien im Verzeichnis \TransportRoles\Logs\ServerStats abgelegt. Ist der Server inaktiv, werden keine Dateien erstellt. 쐍 Alle acht Stunden werden Daten über die Wartezeit von Nachrichten von und an Postfächer in Protokolldateien im Verzeichnis \TransportRoles\Logs\ActiveUserStats aufgezeichnet. Die Protokolldateien liegen im CSV-Format vor und können mit Microsoft Excel geöffnet und angezeigt werden.
953
Die Exchange-Toolbox
Nachrichtenverfolgung
Kapitel 15
Die Exchange-Toolbox
Das Exchange Management Pack für Microsoft System Center Operations Manager importiert die Protokolldateien in das Data Warehouse von System Center, um Berichte der stündlichen und täglichen Serverstatistiken, aktiven Benutzer und Verwendung von Verteilergruppen (gemessen anhand der Erweiterung der Gruppenmitgliedschaft im Kategorisierungsmodul) zu erstellen.
Verwenden des Verfolgungsprotokoll-Explorers Das Cmdlet Get-MessageTrackingLog ist vielseitig und ermöglicht Ihnen, äußerst nützliche Informationen aus den Protokollen der Nachrichtenverfolgung zu gewinnen. Allerdings kann es ziemlich mühselig und anstrengend sein, dieses Cmdlet zu verwenden, vor allem wenn Sie nicht mit den Parametern vertraut sind und nicht genau wissen, wie Sie sie für effiziente Suchvorgänge einsetzen müssen. Dank des Verfolgungsprotokoll-Explorers können Sie diese Schwierigkeiten jedoch ad acta legen, denn er bietet eine einfach zu nutzende Oberfläche auf der Grundlage des Exchange Troubleshooting Assistant. Diese Funktion hat sich seit Exchange Server 2007 nicht geändert. Stellen Sie sich den Verfolgungsprotokoll-Explorer wie einen Informationstrichter vor. Wenn Sie am oberen Rand des Trichters mit der Suche beginnen, geben Sie einige allgemeine Informationen über die Nachricht an, über die Sie etwas wissen möchten. Die Suche engt die Menge der Nachrichtenverfolgungsdaten ein, um die gewünschte Nachricht zu finden. Danach können Sie das Ergebnis noch weiter einengen, um den Verlauf der Nachricht vom Absender zu einem Empfänger in derselben Organisation, vom Postfachserver zum Hub-Transport-Server und wieder zurück zu einem Postfachserver oder über einen Connector zu einem fremden E-Mail-System zu verfolgen. Als Erstes müssen Sie im Verfolgungsprotokoll-Explorer also Hinweise angeben, um die gewünschte Nachricht zu finden. Offensichtliche Angaben sind die Absenderadresse, der Nachrichtenbetreff, der Zeitraum, in dem die Nachricht gesendet wurde, und der Name des Servers, auf dem die Suche beginnen soll. Bei der Suche nach Nachrichtenverfolgungsprotokollen verwendet Exchange die SMTPAdresse des Absenders, weshalb Sie in das betreffende Feld die SMTP-Adresse eines externen oder internen Absenders einfügen können. Wenn Sie auf die Schaltflächen Absender auflösen und Server von Absender klicken, schlägt Exchange in der globalen Adressliste nach, um die eingegebenen Adressen aufzulösen. Das funktioniert aber nur dann gut, wenn Sie eindeutige Daten eingeben. Bei einer mehrdeutigen Adresse, für die es in der globalen Adressliste mehrere Übereinstimmungen gibt, können Fehler auftreten. Wenn Sie beispielsweise Schmidt eingeben und in der globalen Adressliste mehrere Benutzer dieses Namens stehen, gibt Exchange den ersten passenden Eintrag zurück, und das muss nicht unbedingt die Person sein, nach der Sie wirklich suchen. Seien Sie also vorsichtig und überprüfen Sie den zurückgegebenen Wert, wenn Sie Adressen mithilfe dieser Schaltflächen auflösen. Insidertipp: Beginnen Sie auf dem Server mit den Postfächern
Wenn Sie eine gültige interne Adresse für einen Absender eingeben, sollten Sie auch auf Server von Absender klicken, damit Exchange den Namen des Servers mit dem Postfach des Absenders einfügt. Dadurch sorgen Sie dafür, dass Exchange mit der Suche auf dem Server beginnt, auf dem die Nachrichten von diesem Benutzer ausgehen. Beginnen Sie stets auf dem Server, auf dem das Postfach untergebracht ist, und folgen Sie der Nachricht von dem Punkt aus, an dem sie vom Speichertreiber eingereicht wird. Arbeiten Sie sich von dort aus weiter vor. Abbildung 15.5 zeigt den Bildschirm, auf dem Sie die ersten Suchparameter eingeben. Hier haben wir den Namen des Absenders sowie ein Anfangs- und Enddatum angegeben. Der Screenshot zeigt die Liste der Ereignisse, aus denen wir auswählen können. Da wir den Weg einer Nachricht verfolgen
954
wollen, die von einer bekannten Einzelperson gesendet wurde, wählen wir SUBMIT, um bei dem Punkt zu beginnen, an dem die Nachricht eingereicht wurde. Im unteren Feld können Sie erkennen, dass der Verfolgungsprotokoll-Explorer Code für Verwaltungsshell aufstellt. Diesen Code können Sie kopieren, um ihn später wiederzuverwenden oder um sich besser mit den Shellbefehlen vertraut zu machen. Wenn Sie genügend Angaben für einen wirkungsvollen Filter gemacht haben, der nicht Hunderte von Nachrichten zurückgibt (drei oder vier Felder), klicken Sie auf Weiter, um die Suche zu starten. Abbildg. 15.5
Angeben der ersten Suchparameter mit dem Verfolgungsprotokoll-Explorer
Der Verfolgungsprotokoll-Explorer zeigt die Suchergebnisse in einem Raster an (siehe Abbildung 15.6). Darin finden Sie die Nachrichten, die der ausgewählte Benutzer im angegebenen Zeitraum gesendet hat. In diesem Raster können Sie sich nach oben und unten bewegen, um eine Nachricht auszuwählen, die Sie genauer untersuchen möchten. Nachdem Sie die Nachricht markiert haben, klicken Sie auf Weiter, um den Vorgang fortzusetzen. Abbildg. 15.6
Anzeige der ersten Suchergebnisse
955
Die Exchange-Toolbox
Nachrichtenverfolgung
Kapitel 15
Die Exchange-Toolbox
Der Verfolgungsprotokoll-Explorer zeigt Ihnen erneut das Suchdialogfeld an (siehe Abbildung 15.7). Dieses Mal sind die Suchfelder bereits mit den Daten der ausgewählten Nachricht gefüllt, vor allem mit der Nachrichten-ID. Abbildg. 15.7
Anzeige der Parameter für die weitergehende Suche nach Einträgen über die ausgewählte Nachricht
Bei den weiteren Suchvorgängen wird diese Kennung beachtet, es werden also nur Ergebnisse zu dieser Nachricht zurückgegeben. Der Verwaltungsshellcode zur Suche nach dieser Nachricht zeigt, wie die Nachrichtenkennung übergeben wird: Get-MessageTrackingLog -Server 'EXSERVER1' -MessageID '[email protected]' -Start '5/20/2010 12:27:00 PM' -End '5/20/2010 12:47:00 PM'
Um mit der Suche fortzufahren, klicken Sie auf Weiter. Der Verfolgungsprotokoll-Explorer zeigt jetzt alle Ereignisse für die ausgewählte Nachricht an, wie Sie in Abbildung 15.8 sehen. Hier können wir die Nachricht von einem Ereignis zum nächsten nachverfolgen: Erstmalige Einreichung (SUBMIT). Annahme durch den Speichertreiber (RECEIVE). Erweiterung der Gruppenmitgliedschaft (EXPAND). Ausführung einer Transportregel (AGENT). Weiterleitung der Nachricht (ROUTING). Da die Nachricht an mehrere Empfänger geht (sowohl interne als auch externe), werden auch mehrere Ereignisse aufgezeichnet. 6. Ein Fehlschlag bei der Weiterleitung der Nachricht (FAIL). Das ist kein Wunder, denn der Empfänger (mein eigenes Postfach!) nimmt nur Nachrichten von bestimmten Absendern an. 7. Weiterleitung an einen Connector zur Zustellung an externe Empfänger (SEND). 8. Zustellung in lokalen Postfachdatenbanken (DELIVER). 1. 2. 3. 4. 5.
956
Es gibt zwar keine Möglichkeit, um einen hübsch formatierten Bericht zu erstellen, aber wir können einen Screenshot der Ergebnisse aufnehmen, um skeptischen Benutzern zu beweisen, dass die Nachricht tatsächlich zugestellt wurde. Abbildg. 15.8
Die aufgezeichneten Ereignisse für eine Nachricht
In diesem Raster können wir nun ein Ereignis auswählen und die Suche fortsetzen. Was bei dieser Suche herauskommt, hängt davon ab, welche Route die Nachricht von diesem Punkt an genommen hat: 쐍 Lokale Zustellung Das Ereignis DELIVER zeigt an, dass die Nachricht ihre Reise zum Zielpostfach abgeschlossen hat, weshalb keine weiteren Nachverfolgungsdaten verfügbar sind. 쐍 Weiterleitung an einen anderen Hub-Transport-Server in der Organisation Der Verfolgungsprotokoll-Explorer fordert Protokolldaten von dem Hub-Transport-Server an, der die Nachricht angenommen hat, und setzt die Nachverfolgung von diesem Punkt an fort. 쐍 Weiterleitung an einen SMTP-Connector zur Zustellung an einen externen Empfänger Der Verfolgungsprotokoll-Explorer kann die Nachricht nicht weiter verfolgen, da sie die Exchange-Organisation verlassen hat und sich jetzt in den Händen eines anderen Messagingsystems auf dem Weg zu seinem endgültigen Bestimmungsort befindet. 쐍 Weiterleitung an einen Edge-Transport-Server Der Verfolgungsprotokoll-Explorer hat keinen Zugriff auf Nachrichtenverfolgungsdaten auf einem Edge-Transport-Server, weshalb er keine weiteren Ereignisse mehr anzeigen kann. Die Nachverfolgung von Nachrichten kann jedoch deutlich komplizierter sein als in diesem Beispiel. Es kann vorkommen, dass ein Server gerade nicht erreichbar ist, wenn Sie versuchen, dem Weg der Nachricht über ihn nachzuspüren. Vielleicht läuft auf einigen Servern zwar der Transportprotokollsuchdienst, doch können Sie nicht auf Suchanforderungen antworten. Möglicherweise haben Ihnen auch die Benutzer unzureichende Daten gegeben, um effiziente Suchvorgänge durchführen zu können – oder sogar falsche Daten, die zu langwierigen und ergebnislosen Suchen führen. Mit Zeit und Ausdauer sollten Sie jedoch in der Lage sein, mit dem Verfolgungsprotokoll-Explorer und vielleicht der einen oder anderen selbst gestalteten Suchabfrage in der Exchange-Verwaltungsshell die gewünschte Nachricht zu finden. Beispielsweise dient der folgende Shellbefehl dazu, nach allen Ereignissen zu suchen, die für eine bestimmte Nachricht aufgezeichnet wurden. Hier erfolgt die Suche über alle Hub-Transport- und Postfachserver der Organisation. Außerdem wird vorausgesetzt, dass Sie die Nachrichtenkennung in der Variable $MsgId gespeichert haben. Get-ExchangeServer | Where {$_.IsHubTransportServer –or $_.IsMailboxServer} | Get-MessageTrackingLog –MessageId $MsgId | Sort TimeStamp | Format-Table TimeStamp, EventId, Source, MessageSubject, Sender, Recipients –AutoSize
957
Die Exchange-Toolbox
Nachrichtenverfolgung
Kapitel 15
Die Exchange-Toolbox
Eine weitere häufig gestellte Aufgabe besteht darin, nach Spuren von Nachrichten zu suchen, die an eine externe Domäne gesendet wurden. Auch dazu können Sie Get-MessageTrackingLog verwenden. Der folgende Code durchsucht die Protokolle auf einem Server nach allen Nachrichten, die während eines Zeitraums von 90 Minuten an einen Empfänger in der Domäne fabrikam.com gesendet wurden. Ausgegeben werden Uhrzeit, Absender, Empfänger und Betreff. Get-MessageTrackingLog -Start "5/20/2010 8:00AM" –End "5/20/2010 9:30AM" –Server 'ExServer1' -Eventid "SEND" | Where-Object {$_.Recipients –Match ".*@fabrikam\.com"} | Sort TimeStamp | Format-Table TimeStamp, Sender, Recipients, MessageSubject -AutoSize
TIPP Der Trick bei Befehlen dieser Art besteht darin, den Zeitraum, der untersucht werden soll, so stark einzugrenzen wie nur möglich, um den Aufwand zu verringern, den Exchange zur Suche nach den Protokolleinträgen betreiben muss. Eine Suche nach übereinstimmendem Text in einem Feld, bei der Hunderte von Megabyte an Protokolldaten verarbeitet werden müssen, wird nicht gerade schnell ausgeführt.
Andere Möglichkeiten zur Analyse von Nachrichtenverfolgungsprotokollen Mit dem Verfolgungsprotokoll-Explorer können Sie sich auf ausgewählte Nachrichten konzentrieren, aber Sie erhalten damit weder einen Überblick über den Datenverkehr, den ein Exchange ServerComputer insgesamt verarbeitet, noch erhalten Sie Informationen, die Ihnen einen Eindruck von der Serverbelastung vermitteln. Messergebnisse darüber, wie hoch das durchschnittliche tägliche Nachrichtenaufkommen ist (Rohzahlen, Absender, verarbeitete Bytes usw.), welche Benutzer am häufigsten E-Mails senden oder empfangen, welche Verteilergruppen ständig genutzt werden und welche niemals Nachrichten empfangen, wie viel Prozent der Nachrichten nicht an alle vorgesehenen Empfänger zugestellt werden können usw. sind gute Indikatoren, an denen Sie ablesen können, in welchem Zustand sich ihre Messaginginfrastruktur befindet. Um einen tieferen Einblick in den Nachrichtenverkehr zu bekommen, haben Sie folgende Möglichkeiten: 쐍 Aufbau eines eigenen Analysesystems 쐍 Erwerb eines kommerziellen Produkts 쐍 Aufnahme der Nachrichtenverfolgungsanalyse in ein weiter gefasstes Verwaltungssystem In dieser Liste sind die einzelnen Möglichkeiten nach steigenden Kosten geordnet.
Ein eigenes Analysesystem Eine gern genutzte Möglichkeit besteht darin, ein eigenes Analysesystem aus verfügbaren Hilfsprogrammen aufzubauen. Dabei sind vor allem die folgenden drei Werkzeuge gut geeignet: 쐍 LogParser Auf den TechEd- und Exchange Connections-Konferenzen gab es im Laufe der Jahre schon eine Reihe von Präsentationen, in denen erklärt wurde, wie Sie Daten mit LogParser abrufen und analysieren können. Dabei handelt es sich um ein kostenloses Hilfsprogramm, das sich ganz hervorragend dazu eignet, den Inhalt von Protokolldateien der verschiedensten Anwendungen zu untersuchen, unter anderem von Exchange und IIS (wo Sie sehr nützliche Informationen über die ActiveSync-Aktivitäten gewinnen können). Im Internet finden Sie außerdem Hinweise dazu, wie andere Administratoren Nachrichtenverfolgungsdaten über ihre Exchange Server-Computer ana-
958
lysieren. Die Vorschläge unter http://msexchangeteam.com/archive/2007/11/12/447515.aspx wurden zwar für Exchange Server 2007 geschrieben, bilden aber einen hervorragenden Ausgangspunkt für Do-it-yourself-Administratoren. 쐍 Process Tracking Log Tool Sehen Sie sich auch das vom Exchange-Entwicklungsteam erstellte Process Tracking Log Tool für Exchange Server 2007 an (das Sie von http://msexchangeteam.com/ archive/2008/02/07/448082.aspx herunterladen können). Es funktioniert auch in Exchange Server 2010, weshalb Sie es auch für Ihre Zwecke verwenden und anpassen können. 쐍 ExLogAnalyzer Dieses Hilfsprogramm wurde ebenfalls von Microsoft als Ergänzung zu Exchange beigesteuert und dient dazu, Berichte und Analysediagramme aus Nachrichtenverfolgungsprotokollen zu erstellen. Außerdem können Sie damit die Daten in Konnektivitäts- und SMTP-Empfangsprotokollen analysieren. Es steht auf http://msexchangeteam.com/archive/2010/01/20/453843. aspx zum Download bereit.
Kommerzielle Produkte Die Messlatte in diesem Bereich wurde für viele Jahre von Promodag Reports aufgestellt (http:// www.promodag.com). Dieses Programm ruft Daten aus Nachrichtenverfolgungsprotokollen ab und speichert sie in SQL- oder Microsoft Access-Datenbanken, um eine umfassende Analyse der grundlegenden Merkmale und der Arbeitslast auf einem Exchange Server-Computer zu ermöglichen. Von Promodag gibt es auch eine Freeware-Version, die vor dem Kauf ausprobieren können. In letzter Zeit sind auch noch andere Produkte aufgetaucht, die es mit Promodag aufnehmen können. Sirana AppAnalyzer (http://www.sirana.com) ist ebenfalls ein sehr leistungsfähiges Produkt, das Nachrichtenverfolgungsprotokolle analysiert, um daraus Informationen über Trends zu gewinnen und z.B. festzustellen, wie stark die einzelnen Abteilungen jeweils Exchange nutzen.
Analyse der Nachrichtenverfolgung im größeren Zusammenhang Neben seinen anderen Funktionen kann Microsoft System Center for Operations Manager Daten aus Nachrichtenverfolgungsprotokollen nutzen, um Statistiken über den E-Mail-Verkehr aufzustellen. Wenn Sie dieses Produkt als Verwaltungssystem für Windows nutzen, können Sie es auch für die Berichterstattung über Exchange einsetzen.
Systemmonitor Den Systemmonitor können Sie auch von Windows aus starten, doch die Version in der Toolbox von Exchange ist bereits vorkonfiguriert und enthält die wichtigsten Indikatoren zur Überwachung der Leistung von Exchange Server-Computern. Eine Liste aller Leistungsindikatoren für Exchange können Sie mit dem folgenden Befehl abrufen: $FormatEnumerationLimit = -1 Get-Counter –ListSet 'MSExchange*' | Format-List CounterSetName, Paths > C:\Temp\MSExchangePerf.txt
Der Wert -1 für $FormatEnumerationLimit weist Windows PowerShell an, die Ausgabewerte nicht abzuschneiden. Das ist wichtig, da viele der Leistungsindikatorensätze von Exchange, vor allem die für den Informationsspeicher, über sehr viele Indikatoren verfügen. Durch die Angabe von CounterSetName verlangen Sie, dass die Namen der Leistungsindikatorensätze ausgegeben werden. Dabei
959
Die Exchange-Toolbox
Systemmonitor
Kapitel 15
Die Exchange-Toolbox
handelt es sich jeweils um Sammlungen von Leistungsindikatoren für einen bestimmten Bereich des Produkts. Mit Paths rufen Sie die Namen der einzelnen Indikatoren ab. Im Folgenden sehen Sie die Ausgabe für den Leistungsindikatorensatz Mail Submission: CounterSetName : MSExchange Mail Submission Counter : {\MSExchange Mail Submission(*)\Successful Submissions, \MSExchange Mail Submission(*)\Successful Submissions Per Second, \MSExchange Mail Submission(*)\Failed Submissions, \MSExchange Mail Submission(*)\Failed Submissions Per Second, \MSExchange Mail Submission(*)\Temporary Submission Failures, \MSExchange Mail Submission(*)\Temporary Submission Failures/sec, \MSExchange Mail Submission(*)\Hub Servers InRetry, \MSExchange Mail Submission(*)\Hub Servers, \MSExchange Mail Submission(*)\Hub Transport Servers Percent Active, \MSExchange Mail Submission(*)\Aggregate Shadow Queue Length, \MSExchange Mail Submission(*)\Shadow Queue Auto Discards Total, \MSExchange Mail Submission(*)\Shadow Re-submission Length, \MSExchange Mail Submission(*)\Shadow Message Re-submissions Total}
Alle Fachleute für die Leistungsbewertung von Exchange haben jeweils ihre eigenen Lieblingsindikatoren, die sie zur Analyse heranziehen. Der in Tabelle 15.4 gezeigte Satz bietet Ihnen einen guten Ausgangspunkt. Nach Ihrer eigenen Erfahrung und Ihren Kenntnissen Ihrer Server können Sie weitere Indikatoren hinzufügen oder einige der hier genannten außen vor lassen. Insidertipp: Deuten der Informationen
Es ist in jedem Fall wichtig, eine fundierte Vorstellung davon zu haben, welche Werte der Systemmonitor zeigen sollte, wenn der Server korrekt funktioniert, und welche Abweichungen Ihrer Aufmerksamkeit bedürfen. Eine solche Definition der akzeptablen Leistung ist von entscheidender Bedeutung, um das System zu verstehen und zu erkennen, wenn etwas nicht richtig läuft. Tabelle 15.4
960
Wichtige Leistungsindikatoren für Exchange Server 2010 Leistungsobjekt (Instanz)
Leistungsindikator
Bedeutung
Akzeptable Werte
MSExchange-Datenbanken (
E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (Angefügt)
Die Zeit, die durchschnittlich zum Lesen von Daten aus der aktiven Datenbankdatei erforderlich ist.
Dieser Wer sollte durchschnittlich unter 20 ms liegen, mit Spitzen bis zu höchstens 100 ms.
MSExchange-Datenbanken
E/A: Durchschnittliche Wartezeit für Datenbankleseoperationen (Wiederherstellung)
Die Zeit, die durchschnittlich zum Lesen von Daten aus der passiven Datenbankdatei erforderlich ist (nur in Datenbankverfügbarkeitsgruppen.
Dieser Wert kann höher sein als für die aktive Kopie, da hierbei keine Tätigkeiten für den Benutzer geleistet werden. Allerdings sollte es auch keine übermäßigen Unterschiede geben.
MSExchangeIS
RPC-Anforderungen
Gibt die Anzahl der RPCDer Wert sollte unter Anforderungen an, die 70 bleiben. zurzeit innerhalb des Informationsspeicherprozesses ausgeführt werden.
MSExchangeIS
Durchschnittl. RPC-Wartezeit
Gibt die durchschnittliche RPC-Wartezeit in Millisekunden an. Der Durchschnitt wird über sämtliche Operationen in den letzten 1024 Paketen ermittelt.
Dieser Wert sollte unter 10 ms bleiben.
Systemmonitor
Wichtige Leistungsindikatoren für Exchange Server 2010 (Fortsetzung) Leistungsobjekt (Instanz)
Leistungsindikator
Bedeutung
Akzeptable Werte
MSExchangeIS-Client (
Durchschnittliche RPC-Wartezeit
Wie oben, allerdings wird die Wartezeit für RPC-Clientanforderungen angegeben.
Wie oben. Beachten sie, dass bei der Auswahl von
Datenbank
Database Page Fault Stalls/sec
Gibt die Rate der Seitenanforderungen an, die Windows nicht erfüllen kann, da die sich keine Seiten im Cache befinden.
Dieser Wert sollte 0 betragen. Alles andere deutet darauf hin, dass die Wartezeit für Schreibvorgänge in Datenbanken zu hoch ist (die Datenbank kommt mit den Anforderungen nicht mit).
MSExchangeTransport-Warteschlangen (<_Total>)
Aggregierte Länge der Zustellungswarteschlangen (alle Warteschlangen)
Gibt die Gesamtzahl der auf die Zustellung wartenden Nachrichten in sämtlichen Warteschlangen an.
Diese Zahl schwankt auf Hub-Transport-Servern. Sollten zu Spitzenzeiten mehr als 5000 Elemente auf ihre Zustellung warten, ist eine genauere Untersuchung angebracht.
MSExchangeTransport-Warteschlangen (<_Total>)
Länge der aktiven Remotezustellungswarteschlange)
Gibt die Anzahl der Nachrichten an, die in aktiven Warteschlangen auf die Remotezustellung warten.
Auch diese Zahl schwankt. Besorgniserregend ist es, wenn der Wert über 250 steigt und in dieser Höhe bleibt. Dies ist möglicherweise ein Anzeichen dafür, das die Nachrichten den Server nicht verlassen können.
MSExchangeTransport-Warteschlangen (<_Total>)
Länge der Übermittlungswarteschlange
Gibt die Gesamtanzahl der Nachrichten in der Übermittlungswarteschlange an.
Diese Warteschlange sollte weniger als 50 Elemente enthalten. Wächst sie auf 100 Objekte an, liegt möglicherweise ein Engpass auf den globalen Katalogservern (die auf die Anforderung von Active Directory-Anforderungen während der Kategorisierung antworten) oder auf den Postfachservern vor (die die Nachrichten einreichen).
Für Leistungsexperten ist es besonders wichtig, dass die folgenden vier Grundelemente eine gute Leistung zeigen: Prozessor, Arbeitsspeicher, Festplatte und Netzwerk. Wenn Sie sich Sorgen über die Serverleistung machen, sollten Sie bei der Untersuchung nach dieser Liste vorgehen, denn dadurch können Sie gezielt Fragen stellen und nach Daten forschen, die anzeigen, ob der Server korrekt läuft. Anhand dieser Daten können Sie Symptome wie eine überfüllte Festplatte oder mangelnden Arbeitsspeicher auf die grundlegenden Probleme zurückzuführen, um eine Lösung zu finden. 961
Die Exchange-Toolbox
Tabelle 15.4
Kapitel 15
Die Exchange-Toolbox
Leistungsproblembehandlung Die Exchange-Leistungsproblembehandlung wurde als Ableger des Exchange Best Practice Analyzer (ExBPA) entwickelt. Sie liest einige Leistungsdaten eines Servers und vergleicht sie mit bekannten Problembedingungen, um den Administratoren dann Maßnahmen zur Behebung des Fehlers vorzuschlagen. Es ist durchaus möglich, dass Ihnen dieses Programm die nötigen Einblicke gibt, die Sie benötigen, um ein Leistungsproblem auf einem Server zu lösen. Allerdings sind wir angesichts der immer komplexer werdenden Technologie über den Punkt hinausgelangt, an dem ein Programm, das nur eine begrenzte Menge möglicher Probleme abdeckt, bei Leistungsmängeln besonders wertvolle Hilfestellung geben kann. Meistens fahren Sie besser damit, die entsprechenden Leistungsindikatoren auf dem betroffenem Server mit dem Systemmonitor aufzuzeichnen und die Leistungsdaten dann an Fachleute weiterzugeben, um herauszufinden, was die Ursache des Problems ist – falls es bei der Betrachtung der Daten nicht unmittelbar ins Auge springt. Insidertipp: Offlineschalten eines Servers
Wenn ein Server eine anomale Leistung zeigt, steht der Administrator vor dem Problem, ob und wann er den Computer offline schalten soll, um den Grund für die mangelnde Leistung eventuell durch einen Neustart zu beheben. Niemand möchte einen Server tagsüber offline schalten, da dies die Benutzer beeinträchtigen kann (selbst ein langsamer Server bietet Zugriff auf die Daten, die die Benutzer benötigen). In den meisten Fällen warten Administratoren, bis die Benutzernachfrage abnimmt und ein vorübergehender Verzicht auf den Server möglichst geringe Auswirkungen zeigt. Diese Wartezeit kann der Administrator sinnvoll nutzen, indem er einige Leistungstests durchführt, um die mögliche Ursache zu finden.
ExPerfWiz Wenn Sie Leistungsprobleme auf einem Server feststellen und die Hilfe einer Gruppe wie Microsoft PSS in Anspruch nehmen, um herauszufinden, worin die Ursache liegt, werden Sie wahrscheinlich gebeten, Daten für die Analyse beizubringen. Der herkömmliche Weg dazu besteht darin, im Windows-Systemmonitor eine Reihe von entscheidenden Leistungsindikatoren für Exchange und vielleicht die eine oder andere Windows-Komponente wie IIS zu messen. In der Toolbox finden Sie sogar eine vorkonfigurierte Version des Systemmonitors, die die wichtigsten Leistungsindikatoren für Exchange erfasst und einen hervorragenden Ausgangspunkt zur Erfassung von Daten für die Analyse bietet. Eine weitere Möglichkeit, um die benötigten Leistungsdaten für Exchange zu ermitteln, besteht darin, die von Microsoft veröffentlichten ExPerfWiz-Dateien (Exhange Performance Wizard) zu nutzen. Dabei handelt es sich um XML-Vorlagendateien für den Systemmonitor, mit denen Sie die Daten erfassen können, die zur Analyse der Leistung aller Exchange-Rollen erforderlich sind. Es gibt jeweils eigene Versionen für Exchange Server 2007 und 2010. Der Einsatz dieser Vorlagen im Systemmonitor ist ein Ersatz für das Hilfsprogramm PerfWiz.exe (den Leistungsassistenten), das in Exchange Server 2003 vorhanden war.
962
Die XML-Vorlagen legen einen Sammlungssatz aus einer Reihe von Leistungsindikatoren fest. Um Daten zu erfassen, gehen Sie folgendermaßen vor: 쐍 Laden Sie die neuesten ExPerfWiz-Vorlagen herunter und speichern Sie sie auf dem Server. 쐍 Öffnen Sie den Systemmonitor. 쐍 Öffnen Sie die Knoten Leistungsprotokolle und Warnungen und Sammlungssätze. 쐍 Rechtsklicken Sie auf Benutzerdefiniert und wählen Sie Neu\Sammlungssatz, um den Assistenten zu starten und einen neuen Sammlungssatz zu erstellen. Geben Sie die gewünschte Vorlage an. 쐍 Klicken Sie auf Fertig stellen, um den Sammlungssatz zu erstellen. Wie Sie in Abbildung 15.9 sehen, können Sie den Sammlungssatz ausführen, indem Sie mit der rechten Maustaste darauf klicken und Starten wählen. Anschließend beginnt der Systemmonitor, Informationen über alle Leistungsindikatoren zu erfassen, die in der Vorlage definiert sind, bis Sie den Vorgang mit einem Klick auf Anhalten stoppen. Die dabei erstellten Berichte werden im Abschnitt Benutzerdefiniert unter dem Knoten Berichte gespeichert (siehe Abbildung 15.10). Jedes Mal, wenn der Sammlungssatz ausgeführt wird, erstellt der Systemmonitor einen neuen Bericht. Der erste trägt die Nummer 000001, der zweite 000002, der dritte 000003usw. Abbildg. 15.9
Starten des ExPerfWiz-Sammlungssatzes
Klicken Sie auf einen Bericht, um seinen Inhalt anzuzeigen. Standardmäßig gibt der Systemmonitor die gesammelten Daten als Graph an. Die ExPerfWiz-Vorlagen enthalten jedoch so viele Leistungsindikatoren, dass der Graph völlig unübersichtlich und damit für die Leistungsanalyse unbrauchbar ist (siehe Abbildung 15.10). Es ist daher am besten, in den Berichtsmodus umzuschalten, um sich die angegebenen Ergebnisse anzusehen und sich auf die Indikatoren zu konzentrieren, die einen Hinweis auf die Ursache des Leitungsproblem geben.
963
Die Exchange-Toolbox
Leistungsproblembehandlung
Kapitel 15
Die Exchange-Toolbox
Abbildg. 15.10 Der Graph der ExPerfWiz-Ergebnisse
Einschränkungen von ExPerfWiz Auch der Datenerfassung mithilfe der ExPerfWiz-Vorlage sind Grenzen gesetzt. Das liegt vor allem an dem Einfluss von Anwendungen, die zwar mit Exchange verknüpft, für Exchange aber nicht unmittelbar zugänglich sind. Die beiden besten Beispiele dafür sind folgende Programme: 쐍 RIM BlackBerry Enterprise Server (BES) 쐍 Desktopindizierungsprogramme BES verknüpft BlackBerry-Geräte, Exchange und den Mobilfunkbetreiber, der die Verbindung der Geräte zum Netzwerk herstellt. Um Nachrichten von Postfächern abzurufen oder dort zuzustellen, verwendet BES MAPI zur Kommunikation mit Exchange. MAPI-Clients belasten Exchange ServerComputer stärker als andere Protokolle. Als Faustregel können Sie davon ausgehen, dass BlackBerryClients eine ungefähr viermal so hohe E/A-Last mit sich bringen wie Clients mit ActiveSync (z.B. Windows Mobile, Android, iPhones und Palm-Geräte). Wenn Sie daher BlackBerry-Geräte einsetzen, müssen Sie ausreichend Computer mit BES bereitstellen, um die Verbindungslast schultern zu können, und die BlackBerry-Benutzer so über die verfügbaren Postfachserver verteilen, dass es keinen BlackBerry-Schwerpunkt mit vielen BlackBerry-Benutzern in einer einzigen Postfachdatenbank gibt. Achten Sie sorgfältig darauf, wie viele BlackBerry-Geräte Verbindung mit Exchange aufnehmen, und sehen Sie sich auf der Website von RIM (http://na.blackberry.com/eng/services/business/server/ full/) die neuesten Informationen über Optimierung und Leistung von BES in Kombination mit Exchange Server 2010 an. Sorgen Sie dafür, dass dieses außerordentlich nützliche Kommunikationssystem nicht zu einem Problem für die Bereitstellung wird. Mit Drittanbieterprogrammen wie Zenprise Mobile Manager (http://www.zenprise.com) können Sie die BlackBerry-Nutzung beobachten und mögliche Anbindungsprobleme lösen.
964
Desktopindizierungsprogramme wie Google Desktop für Windows oder Xobni (http://www.xobni. com) sind nützliche Hilfsmittel zur Produktivitätssteigerung, die es den Benutzern ermöglichen, sämtliche Inhalte in ihren Postfächern zu indizieren. Die Desktopsuche von Windows tut das Gleiche, die anderen Programme bieten jedoch zusätzliche Funktionen an, die zu ihrer Popularität beigetragen haben. Beispielsweise waren in Xobni Unterhaltungsthreads und Social-Media-Verbindungen möglich, lange bevor Microsoft diese Funktionen in Outlook 2010 einbaute. Das Problem bei Desktopindizierungsprogrammen liegt darin, dass Sie Zugriff auf die Daten haben müssen, um sie zu indizieren, und wenn sie das online tun, können sie einen Exchange-Postsachserver manchmal sehr stark belasten. Das wirkt dann so, als stünde der Server unter der Last einer Menge hyperaktiver Benutzer, die zu viel Kaffee getankt haben. Nicht alle Desktopindizierungsanwendungen greifen online auf die Daten zu (bei der Desktopsuche von Windows wurde der Onlinezugriff ab Version 3.01 aufgegeben), sondern verwenden stattdessen die in den OST- und PST-Dateien auf dem PC gespeicherten Daten. Dieses Verhalten ist zu bevorzugen. Wenn Sie ein Desktopindizierungsprogramm für Ihre Benutzer auswählen, sollten Sie darauf achten. Es ist natürlich möglich, dass Benutzer ohne Wissen des Administrators ein neues Desktopindizierungsprogramm herunterladen und installieren. Das können Sie nur daran feststellen, dass es bei den von diesem Benutzer verbrauchten Ressourcen zu einer unerwarteten Spitze kommt.
Exchange Load Generator 2010 Exchange Load Generator 2010 (LoadGen) ist der einzige unterstützte Lastgenerator für Exchange und ersetzt die älteren Hilfsprogramme Loadsim und Exchange Server Stress and Performance (ESP). LoadGen verwendet dieselbe Oberfläche wie ExBPA, bietet aber auch eine Befehlszeilenschnittstelle, an der Sie Leistungssimulationen für Clients mit den folgenden Protokollen durchführen können: 쐍 Outlook (im Online- und im Exchange-Cache-Modus). Die Tests basieren auf Outlook 2003 und 2007, können aber auch zur Simulation von Outlook 2010 genutzt werden. 쐍 Internet (POP3 und IMAP4) 쐍 Outlook Web App 쐍 ActiveSync 쐍 SMTP LoadGen ist für die Anwendung in einer Umgebung gedacht, die die vorgesehene Produktionsumgebung nachstellt. Das Programm soll diese Umgebung einem Belastungstest unterziehen, um herauszufinden, ob sie in der Lage ist, eine bestimmte Menge von Clients zu versorgen. Da LoadGen Postfächer erstellt, um sie für den Test zu nutzen, sollten Sie das Programm nicht in einer Produktionsumgebung einsetzen. LoadGen würde sonst nicht nur Active Directory mit Testkonten vollstopfen, sondern auch noch zu einem offensichtlichen und messbaren Leistungsabfall für andere Anwendungen auf denselben Systemen führen. Die LoadGen-Tests können Sie von einem Clientcomputer mit Vista, Windows 7 oder Windows Server 2008 SP2 oder R2 aus steuern. Eine Installation der Exchange-Verwaltungstools auf diesem Rechner ist nicht erforderlich. Ein LoadGen-Test läuft einen angegebenen Zeitraum lang und folgt der von Ihnen eingerichteten Konfiguration. Diese Konfiguration ahmt die Zusammenstellung der Clients nach, die sie in der Produktionsumgebung erwarten. Hierbei geht es um die Anzahl der Postfächer, die Art der verwendeten
965
Die Exchange-Toolbox
Exchange Load Generator 2010
Kapitel 15
Die Exchange-Toolbox
Clients und andere Bedingungen wie die verwendeten Verteilerlisten. Von einem einzigen Clientcomputer aus können Sie die Simulation von bis zu 1500 Benutzern steuern. Wenn Sie eine größere Anzahl benötigen, müssen Sie die Tests von mehreren Clients aus durchführen. Großmaßstäbliche Tests (mit über 10.000 simulierten Benutzern) sind eine anspruchsvolle Aufgabe, die eine sorgfältige Koordination und Planung erfordern. Erfahrene Fachleute sagen jedoch, dass Sie sich diese Mühe nicht machen müssen, sondern aus den Ergebnissen eines Tests für etwa 1000 Benutzer die Resultate für die gewünschte Anzahl vorhersagen können. Es stimmt sicherlich, dass man sehr leicht in die Falle tappen kann, Unmengen von Zeit und Kraft auf Tests zu verschwenden und dabei andere Dinge aus den Augen zu verlieren, z.B. die Verwaltung der Betriebsumgebung. Nach der Konfiguration der Tests initialisieren Sie die Umgebung, um die Postfächer und anderen Objekte zu erstellen, die LoadGen während der Tests verwendet. Anschließend können Sie den Test starten. LoadGen führt ihn dann bis zum Ende des vorgesehenen Zeitraums aus. Insidertipp: Die Ergebnisse eines LoadGen-Tests
Erwarten Sie nicht, am Ende eines LoadGen-Tests eine ausführliche Ausgabe mit den Ergebnissen zu erhalten. LoadGen gibt zwar einen Übersichtsbericht aus, um anzuzeigen, dass der Test erfolgreich verlaufen ist, aber die Exchange Server-Computer werden nicht mit einem Qualitätsindex versehen wie in Windows 7. Stattdessen müssen Sie die Server während des Tests beobachten, um herauszufinden, ob sie die von LoadGen ausgeübte Belastung auf akzeptable Weise schultern können. Dazu können Sie die von Ihnen bevorzugten Hilfsmittel einsetzen, z.B. den Systemmonitor. Die in Tabelle 15.4 beschriebenen Leistungsindikatoren eignen sich gut für die Messung während eines LoadGen-Tests. Kein Leistungstest kann hundertprozentig die Vorgänge in einer Produktionsumgebung widerspiegeln. Simulierte Benutzer verhalten sich nicht wie Menschen, und Tests rufen naturgemäß Situationen hervor, die immer wieder reproduziert werden können, damit die Ergebnisse vergleichbar sind. Es ist schwierig, in solche Leistungstests Geschäftsanforderungen oder die Besonderheiten einer Organisation einzubringen (beispielsweise, ob die Benutzer Videodateien als E-Mail-Anhänge senden dürfen, oder ob Voicemailnachrichten gewöhnlich kurz und knapp oder lang und ausführlich gehalten werden). Durch Leistungstests gewinnen Sie einen Eindruck von der Grundlast, mit der Sie verschiedene Konfigurationen vergleichen können, um herauszufinden, welche Konstellation für Ihr Unternehmen am besten ist. Diese Tests versichern Ihnen auch, dass Ihre Bereitstellung auf einer soliden Grundlage ruht. Sie sind aber kein Allheilmittel, und keine noch so ausführlichen Tests können Ihnen ein sicheres Ergebnis garantieren. Das gilt vor allem für Systeme, die sich weiterentwickeln und an Benutzeranforderungen, Softwareaktualisierungen und neue Hardware anpassen müssen. In einer Exchange-Organisation können Sie eine anhaltend gute Leistung daher nur durch harte Arbeit und Aufmerksamkeit für die Einzelheiten erreichen.
Remoteverbindungsuntersuchung Die Remoteverbindungsuntersuchung (Remote Connectivity Analyzer, RCA) wurde als Website entwickelt, auf der Kunden die Outlook Anywhere-Anbindung testen können. RPC-über-HTTP-Verbindungen sind manchmal schwierig einzurichten, und diese Site ist dabei äußerst hilfreich, da sie eine externe Stelle bildet, die einen Server »anpingen« kann, um die Verbindung vom Client zum Postfach zu testen. Mit der Zeit hat Microsoft diese Website (https://www.testexchangeconnectivity.com) verbessert, um Tests für folgende Arten von Verbindungen zu ermöglichen: 966
Remoteverbindungsuntersuchung
쐍 Outlook Anywhere (einschließlich AutoErmittlung für Outlook) 쐍 Exchange-Webdienste (z.B. Verfügbarkeits- und Abwesenheitsbenachrichtigungsdienste) 쐍 Ein- und ausgehende SMTP-Verbindungen (siehe Abbildung 15.11) Abbildg. 15.11 Die Remoteverbindungsuntersuchung
Insidertipp: Die Remoteverbindungsuntersuchung – Pflichtprogramm für Exchange-Administratoren
Microsoft hat die Remoteverbindungsuntersuchung in die Toolbox von Exchange Server 2010 aufgenommen, um dieses Hilfsmittel stärker ins Blickfeld zu rücken, denn schließlich ist es die wertvollste Möglichkeit zum Testen von Verbindungen, die es zurzeit gibt. Es gibt nichts, das dieselben Tests durchführen kann wie die Remoteverbindungsuntersuchung, weshalb sich jeder ExchangeAdministrator damit vertraut machen sollte. Um die Remoteverbindungsuntersuchung zu nutzen, können Sie in der Toolbox darauf zugreifen oder den URL in einem Browser eingeben. Die besten Ergebnisse erzielen Sie mit Microsoft Internet Explorer, da dieser Browser auch von den Entwicklern verwendet wurde. 967
Die Exchange-Toolbox
쐍 Exchange ActiveSync (einschließlich AutoErmittlung für mobile Geräte)
Kapitel 15
Die Exchange-Toolbox
Auf der Website der Remoteverbindungsuntersuchung müssen Sie die Anmeldeinformationen für ein Konto auf einem Exchange Server-Computer angeben, der mit dem Internet verbunden ist und die Funktionen beherbergt, die Sie testen möchten. Dies sollte nach Möglichkeit ein Konto sein, das Sie ausschließlich für Testzwecke erstellt haben. Die Anmeldeinformationen für Ihr eigenes Konto sollten Sie niemals einem System anvertrauen, über das Sie keine Kontrolle haben. Microsoft macht es sehr deutlich, dass Sie die volle Verantwortung für die Nutzung der Remoteverbindungsuntersuchung tragen. Wählen Sie auf der Website der Remoteverbindungsuntersuchung als Nächstes den Test aus, den Sie durchführen möchten, und geben Sie die Informationen an, die dazu erforderlich sind. Abbildung 15.11 zeigt die notwendigen Angaben, um zu prüfen, ob ein System ausgehende SMTP-Nachrichten senden kann. In diesem Fall müssen Sie die IP-Adresse des SMTP-Servers und eine E-Mail-Adresse eingeben, an die die Testnachricht gehen soll. Die Remoteverbindungsuntersuchung nutzt diese Angaben, um die Tätigkeit eines Benutzers nachzuahmen und damit zu ermitteln, ob die Funktion wie erwartet läuft. Ist das nicht der Fall, meldet die Remoteverbindungsuntersuchung, welche Maßnahme ergriffen wurde und warum das Problem aufgetreten ist. In Abbildung 15.12 ist ein ActiveSync-Test fehlgeschlagen, da der AutoErmittlungsdienst für die zu prüfende Domäne nicht erreicht werden konnte. Schlägt ein Test der Remoteverbindungsuntersuchung fehl, sind entweder die Testparameter falsch (wenn z.B. falsche Anmeldeinformationen für das Testkonto angegeben wurden), oder es liegt tatsächlich ein Problem vor, dass die Benutzer auch in der Praxis daran hindert, Verbindung aufzunehmen. Durch diese Art der Rückmeldung erhalten Administratoren sofort einen Hinweis auf ein Problem, dass sie lösen müssen, bevor Sie eine Funktion wie ActiveSync in der Produktionsumgebung einführen. Abbildg. 15.12 Ein fehlgeschlagener ActiveSync-Test in der Remoteverbindungsuntersuchung
968
Quellen für weitere Informationen
Damit sind wir am Ende dieses Buches angelangt, aber mit Sicherheit nicht am Ende der Suche nach Informationen über Exchange Server 2010. Jedes Buch ist durch Umstände wie die Seitenzahl, die Produktionszeit und nicht zuletzt die Zeit eingeschränkt, die die Recherche und das Schreiben erfordern. Ich gebe offen zu, dass es eine Menge von Themen gibt, die ich nicht ausführlich genug behandelt oder sogar komplett außen vor gelassen habe. Es gibt noch mehr Bücher über Exchange Server 2010 und die damit zusammenhängenden Technologien, die grundlegende Voraussetzungen bilden oder häufig zusammen mit Exchange Server 2010 bereitgestellt werden. Ich möchte Sie dazu ermuntern, Ihre Lektüre u.a. über die folgenden Themen fortzusetzen: 쐍 Windows Server 2008 R2 쐍 Active Directory 쐍 SharePoint 2010 쐍 Outlook 2010 쐍 Office Communications Server 2010 In meinem Blog auf http://thoughtsofanidlemind.wordpress.com/ unterhalte ich eine Liste von Fachbüchern, die mir selbst gefallen. Sehen Sie sich diese Liste an, aber hüten Sie sich davor, die dort genannten Bücher als die einzig lesenswerten anzusehen. Es erscheinen ständig neue Bücher, die unser Wissen über die Technologie erweitern und die empfohlenen Vorgehensweisen verbessern. Ich möchte Ihnen auch ans Herz legen, regelmäßig das Blog der Exchange-Entwicklergrupe (EHLO) unter http://msexchangeteam.com/ zu besuchen. Die Artikel dieser Gruppe über ihre Produkte sind im Laufe der Jahre sehr viel besser geworden, und das Blog ist eine hervorragende und wertvolle Informationsquelle, die Sie im Auge behalten sollten. Neben den anderen Informationen dieser Gruppe, auf die ich in diesem Buch schon eingegangen bin, sollten Sie sich vor allem auch eine Kopie des Posters mit der Architektur von Exchange Server 2010 besorgen, das Sie von http://msexchangeteam.com/archive/2010/10/18/456643.aspx herunterladen können. Und jetzt warten wir auf die nächste Version von Exchange – wann immer sie auch herauskommen mag.
969
Die Exchange-Toolbox
Quellen für weitere Informationen
Stichwortverzeichnis Numerisch /m:recoverserver 81 /PrepareAD 67
A Abfragebasierte Verteilergruppen 341 Absenderfilterung 888, 896 Absenderzuverlässigkeit 898 ACID 421 ACLL-Prozess 446, 448 Active Directory /PrepareAD 67 Active Directory-Benutzer und -Computer 208 AD LDS 80 ADAccess 53 ADSI-Editor 50 Anpassbares Schema 62 Attribute für Namensbestandteile 275 Benutzerdefinierte Attribute 63 Bereich für Abfragen festlegen 150 Bereitstellung 51 Clientzugriffsserver 647 Edge-Synchronisierung 876 Edge-Transport-Server 880 Exchange-Daten 50 Exchange-Konten 99 Exchange-Sicherheitsgruppen 97 Exchange-Verwaltungskonsole 212 Exchange-Zugriff 208 Gesamtstrukturfunktionsebene 41 Geteilte Berechtigungen 197 Keine Synchronisierung mit Exchange 62 Konfigurationsdaten 56 Mit dem Internet verbundener Standort 642 OPATH-Abfragen 136 Organisationsdaten 224 OWA-Konfiguration 578 Postfach entfernen 302 Postfacheigenschaften 287 PowerShell 148 Rechteverwaltungsdienste 573 Replikation während der Schemaaktualisierung 60 Routing 778
Active Directory (Fortsetzung) Schemaerweiterung 48 Speicherort für neue Gruppen 258 Standorte 775 Standortverknüpfungskosten 778, 779, 780 Systemnachrichten 844 Verbunddienste 226 Vorbereiten 59 Zulassungs- und Sperrlisten 921 Active Directory Topology Diagrammer 779 Active Manager Attempt Copy Last Logs 446, 448 AutoDatabaseMountDial 500 Best Copy Selection 446 Einführung 442 Leistung 502 Primär 442 Standby 442 ActiveSync Anbindung testen 623, 967 Berichte 612 BlackBerry 623 Einführung 608 Exchange-Systemsteuerung 618 Fehlerbehebung 622 Geräte nach Benutzern blockieren 619 Gerätetypen blockieren 615 Konforme Geräte 610 Richtlinien 610 SMS 609 Synchronisierte Geräte 612 Textnachrichten 609 Verbindungen 643 Zugriffsregeln 616 AD LDS 80 AD RMS 573 ADAccess 53, 56 Add-AttachmentFilterEntry 913 Add-DatabaseAvailabilityGroupServer 470, 472 Add-DistributionGroupMember 282 Add-IPBlockListProvider 895 Add-MailboxDatabaseCopy 483, 489 Add-MailboxFolderPermission 583 Add-MailboxPermission 291, 364 Add-RoleGroupMember 182
971
Stichwortverzeichnis
Add-WindowsFeature 71 AdminSessionADSettings 150 Adresslisten Alle Räume 358 Benutzerdefiniertes Offlineadressbuch 760 Erstellen 760 Hierarchisches Adressbuch 765 Postfächer verbergen 746 Raumpostfächer anzeigen 359 Verborgene Empfänger anzeigen 746 Virtuelle Listenansicht 315 Adressumschreibung 916 ADSI-Editor 50, 880 Affinität 677 Aktivierungsreihenfolge 446, 489, 495 Aktualisierung Antispam-Agents 919 Arbeitsstationen 40 CAB 609 Clientzugriffsserver 665 Direkt 38 Direkte Datenbankaktualisierung 39 Edge-Transport-Server 883 Exchange Server 2003 35 Exchange Server 2007 35 Externe Anbindung 683 Hotfixes 41 Massenaktualisierung 140 Offlineadressbuch 747, 755 OTA 609 Server in Datenbankverfügbarkeitsgruppen 497, 511 Testplan 42 Überschreiben von Änderungen 592 Vorbereiten 41 Vorüberlegungen 37 Akzeptierte Domänen 851 Alle Räume 358 Anführungszeichen 128 Anhänge 588, 599 Anlagenfilterung 913 Anonyme Verbindungen 802 Antispam-Agents Absenderfilterung 896 Absenderzuverlässigkeit 898 Anlagenfilterung 913 Antispamaktualisierungen 919 Berichte 891, 919 Empfängerfilterung 900 Hub-Transport-Server 886 Inhaltsfilterung 907 Installieren 886
972
Antispam-Agents (Fortsetzung) Protokolldateien 917 Reihenfolge 888 Sender ID 902 Teergruben 901 Verbindungsfilterung 893 X-Header 889 Zulassungs- und Blockierlisten 920 AntiSpamAgents.ps1 887 Antivirusprodukte 922 APIs 632 ApplicationImpersonation 185 Arbeitszyklen 770 Archive Import 733 Kontingente 300 Verschieben 697, 708 Assistent für Junk-E-Mail-Optionen 767 Assistent für neue Freigaberichtlinien 227 Assistent für Ressourcenbuchung 767 Assistent für verwaltete Ordner 767 Assistent zum Aktivieren einer Datenbankkopie 494 Assistent zum Aktivieren von Outlook Anywhere 673 Assistent zum Aktualisieren von Datenbankkopien 488 Assistent zum Erstellen einer neuen E-MailAdressrichtlinie 309 Assistent zum Erstellen eines neuen Sendeconnectors 818 Assistent zum Erstellen eines Postfachs 278 Assistent zum Verbinden von Postfächern 305 Assistent zum Verschieben von Postfächern 696 Attempt Copy Last Logs 446, 448 Attribute Benutzerdefiniert 63 Eingeschränkter Attributsatz 134 Namensbestandteile 275 Offlineadressbuch 753 PAS 134 Aufbewahrungspflicht 43 Aufbewahrungszeit für gelöschte Objekte 402 Aufgliederungsserver 334 Ausfallsicherheit 514 Ausführungsrichtlinien 159 Authentifizierung Clients 800 E-Mail-Absender 902 IMAP4 603, 606 Smarthost 818 AutoDatabaseMountDial 448, 499
Stichwortverzeichnis
AutoErmittlung Dienst 648 Dienstverbindungspunkt 648 Domänen 658 Interner URI 681 Outlook Anywhere 650 Protokollierung 654 SRV-Zeiger 658 Statisch 657 Autokonfiguration 653 Automatische Antworten 291 Autorisierende Domänen 852 AvailableNewMailboxSpace 417
B BAD 837 BATV 898 BCS-Prozess 446 Benachrichtigungen zum Entfernen von Nachrichten 861 Benannte Eigenschaften 414 Benutzer E-Mail-Benutzer 357 Gruppen erstellen 266 Gruppenverwaltung 268 Miniaturbilder 755 Mitgliedschaft in Gruppen ermitteln 264 Zugriff auf PSTs beschränken 736 Zulassungs- und Blockierlisten 920 Berechtigungen Berechtigungsgruppen 800 Berechtigungsstruktur 43 Connectors 800 Empfangsconnectors 606 Entfernen 295 Exchange-Verwaltungskonsole 207 Geteilt 196 Import/Export 725 Kalenderfreigabe 583 Kalenderzugriff 364 Postfachberechtigungen 319 Postfächer 291 Sendeconnectors 814, 892 Senden als 319, 321 Senden im Auftrag von 319, 321 Vollzugriff 324 Bereitstellungsassistent 47 Berichte ActiveSync 612 Antispam-Bericht 891 Antispamvorgänge 919 Ausgabe in eine Datei 718
Berichte (Fortsetzung) CSV-Datei 152 HTML 153 Import/Export 731 Postfachverschiebung 716 Rollenbasierte Zugriffssteuerung 199 Verschiebebericht 717 BES 623, 626, 964 Besprechungen Anforderungen verarbeiten 367 Anforderungen weiterleiten 579 Assistent für Ressourcenbuchung 767 Buchungsrichtlinien 362 Genehmigung durch einen Raumstellvertreter 368 Gleichzeitige Belegung von Räumen 364 Räume hinzufügen 359 Zeitplanassistent 767 Best Copy Selection 446 BitLocker 413 BlackBerry 623, 626, 964 Blockreplikation 454 Bounce Address Tag Verification 898 Bridgeheadserver 785 Bulk-Mailbox-Load.ps1 296
C CAB-Aktualisierung 609 CalendarPublishingEnabled 585 CheckDatabaseRedundancy.ps1 522 Chrome 574, 576 Clean-MailboxDatabase 305 Clear-ActiveSyncDevice 620 ActiveSync 608 APIs 632 Authentifizierung 800 AutoErmittlungsdienst 648 Clientseitige Schutzvorrichtungen 924 Einschränken 624 Exchange-Cache-Modus 559 Fat Clients 554 Fax 632 Fehlerbehebung 608 Gemeinsamer Speicherort 579 IMAP4 601, 605 Konfliktlösung 564 Lange Antwortzeiten 682 MAPI-Clients 643 Mobile Clients 554 Outlook 2003 646 Outlook Anywhere 559 OWA 554 973
Stichwortverzeichnis
Clients (Fortsetzung) POP3 601 Serverzugriff blockieren 569 Synchronisierungsprobleme 564 Testen 42 Thunderbird 606 Unified Messaging 627 Unterhaltungsansichten 560 Unterstützte Typen 554 Verbindung prüfen 162 Verbindungen auflisten 565 Verbindungen blockieren 566 Verbindungspunkt 643 Verschlüsselung 646 Zugriffsarchitektur 644 Clientzugriffsarrays Datenbankeinstellungen 661 Datenbankverfügbarkeitsgruppen 662 Einführung 660 Erstellen 661 Netzwerklastenausgleich 661, 664 Rechenzentren 662 Server aktualisieren 665 Standortübergreifende Verbindungen 662 Clientzugriffslizenzen Anzahl 48 Enterprise-Lizenzen 48 Funktionen 223 Postfächer prüfen 274 Postfachfunktionen 280 Versionen 42 Clientzugriffsserver Active Directory-Zugriff 647 Affinität 677 Aktualisieren 665 Clientzugriffsarrays 660 Dienste 639 Dienstverbindungspunkt 648 Einstellungen 651 E-Mail-Infos 740 Firewalls 646 Funktion 638 IMAP4 602 Installation 641 Lastenausgleich 674 Leistung 674 MAPI-Endpunkt 640 MAPI-Verschlüsselung 646 Offlineadressbuch 757 POP3 602 Postfachdatenbanken 644 Postfachreplikationsdienst 695 RPC-Clientzugriffsschicht 643 974
Clientzugriffsserver (Fortsetzung) Standortbereiche 652 Statische Ports 679 Umkreisnetzwerke 666 URLs 681 Vorbereiten 684 Zertifikate 671 Cluster mit Hauptknotensatz 468 Cmdlets Am häufigsten verwendet 118 Anzahl der zurückgegebenen Objekte 135 Arrays 125 Ausführungsrichtlinien 159 Ausgabe weiterleiten 121, 132 Berechtigungen 109 Berechtigungen für Kalenderfreigabe 583 Clientzugriffsserver 651 Connectors 800, 809 CSV-Dateien importieren 296 Datenbanken verschieben 396 Datenbankkopien hinzufügen 483, 488 Edge-Abonnements 876 Edge-Synchronisierung 880 Eigenschaften von Datenbankverfügbarkeitsgruppen 476 Einführung 102 Einschränkungsrichtlinie erstellen 627 E-Mail-Infos 741 E-Mails senden 154 Erforderliche Cmdlets für eine Aufgabe bestimmen 237 Fehler beim Weiterleiten der Ausgabe 133 Hub-Standorte 781 Identitätsparameter 130 IMAP4 604 Kalendereinstellungen 587 Lokalisierte Werte 158 MAPI-Eigenschaften 568 MAPI-Verschlüsselung 646 Massenaktualisierungen 140 Maximale Nachrichtengröße 780 Mobile Geräte zurücksetzen 620 Offlineadressbuch aktualisieren 755 Outlook Anywhere 642 Parametertypen 123 Pipelines 143 POP3 604 Postfacheinrichtung 290 Postfächer online verschieben 691 Postfach-Import/-Export 724 Postfachreparatur 411 Postfachrichtlinien erstellen 596 Postfachwiederherstellung 546
Stichwortverzeichnis
Cmdlets (Fortsetzung) Remotedomänen 855 Rollen 174 Rollenbasierte Zugriffssteuerung 110 Routinggruppenconnectors 863 Rückgabewerte 123 Schattenredundanz 860 Selektive Ausgabe 124 Sendeconnectors 816, 818 Server zu Datenbankverfügbarkeitsgruppen hinzufügen 470 Serverseitige Filter 138 Skripts 119 Standortsverknüpfungskosten 780 Synchronisierungsberichte 612 Syntax 119 Systemnachrichten 842 Test-Cmdlets 160 Transporteinschränkungen 823 Transporteinstellungen 786 Transportpipeline 856 Umfangreiche Ausgabe 126 Variablen 125, 127 Verfügbare Cmdlets 104 Verschiebungsanforderungen 702 Verwendung einschränken 176 Warteschlangen 830 Wartungszeitpläne 400 Zertifikatanforderung 672 Zustellungsconnectors 859 CollectOverMetrics.ps1 523 CollectReplicationMetrics.ps1 523 Connect-Mailbox 306 Connectors Adressräume 879 Ältere Connectors 776 Banner 808 Berechtigungen 606 Berechtigungsgruppen 800 Einstellungen 791 Empfangsconnectors 800 Erstellen 803 Exchange Server 2003 862 Fremdconnectors 858 IMAP4 605 POP3 605 Protokollierung 850 Routinggruppenconnectors 863 Sendeconnectors 809 Sendmail 805 SMTP-Connectors 800 Verknüpfungen 821 Zustellungsconnectors 858
ConvertTo-MessageLatency.ps1 952 Crimson-Ereignisse 516 CSV-Dateien 152 CSV-Eingabedateien 296 CustomRecipientWriteScope 184
D DACP 513 DatabaseCopyAutoActivationPolicy 503 Datacenter Activation Coordination 513 DataPath 392 Dateifreigabenzeugen 465, 477 Datenbanken Ablaufdatum für Sichten 401 Aktivierung blockieren 503 Aktivierung unterdrücken 498 Aktivierungspriorität 489, 495 Aktualisieren 394 Anzahl der Postfächer 377 Aufbewahrungszeit für gelöschte Objekte 402 AutoDatabaseMountDial 499 Automatisch neu verteilen 522 Automatische Bereitstellung 284 Automatischer Datenbankwechsel 444 Bei Wiederherstellung überschreiben 542 Bereich für Rollengruppen 184 Bereitstellen 392 Bereitstellung aufheben 395 Beschädigte Elemente 404 Bevorzugte Aktivierung einer Kopie 446 Clientzugriffsarrays 661 Commit 421, 424 Dateien 387 Defragmentierung 375, 397, 415 Direkte Aktualisierung 39 Dirty Shutdown 542 Doppelte Namen 462 Edge-Transport-Server 885 Eindeutige Namen 459 Erstellen 390 ESEUTIL 542 Failover 495 Filter 389 Größe abschätzen 300, 377 GUID 376, 462 Header überprüfen 542 Indexalterungstabelle 401 Informationen anzeigen 156 Inhaltswartung 401 Inkonsistente Datenbanken 423 Inkrementelle Neusynchronisierung 457 Kapazitätsplanung 378 975
Stichwortverzeichnis
Datenbanken (Fortsetzung) Kontingente 298 Kopien 375 Kopien aktivieren 493 Kopien entfernen 506 Kopien hinzufügen 483 Kopien überwachen 486 legacyExchangeDN 644 Logische Beschädigung 490 Maximale Anzahl von Kopien 440 Maximale Größe 374 Mehrere passive Kopien 438 Mobilität 437 Namenskonventionen 221 Nur gesicherte Elemente endgültig entfernen 406 Öffentliche Ordner 402 Offlineadressbuch 393 Offlineadressbuch zuweisen 763 Onlinedefragmentierung 397, 415 Onlinewartung 397 Passive Kopien 537 Portabilität 437 Postfachdatenbankmaster 443 Postfächer zuweisen 283 Protokollpuffer 425 Prüfpunkt 425 Prüfpunktdateien 388, 428 Prüfsummen 398 Registrierungseinstellung für Maximalgröße 376 Reseeding 457, 487 Rollenbereiche 195 RpcClientAccessServer 645 Schema 386 Seeding 458 Seedingfehler 485 Seitenbeschädigungen 458 Seitengröße 380, 455 Sichten 379 Sichtenanzahl verringern 401 Speicherort der Transaktionsprotokolle 392 Speicherort verschieben 461, 504 Standard Edition 376 Standardpostfachdatenbank 394 Statistiken 419 Switchover 493, 499 Tombstone-Wartung 401 Transaktionsprotokolle 388, 421 Übermäßiges Wachstum 408 Umbenennen 460 Umlaufprotokollierung 395, 430, 456, 482 Umschalten 498, 502 Unabhängigkeit vom Server 437 Verknüpfung mit Clientzugriffsserver 644 976
Datenbanken (Fortsetzung) Verringerung der E/A-Vorgänge 378 Verschieben 396 Verschlüsselung 413 Verwaltung 387 Verzögerte Kopien 490, 493 Warteschlangen 827 Wartezeiten 407 Wartung im Hintergrund 384, 397 Wartungszeitplan 400 Wiederhergestellte Datenbanken überprüfen 542 Wiederherstellungsdatenbank 538, 543 Zusammenhängender Speicherplatz 384 Datenbankverfügbarkeitsgruppen Active Manager 442 Aktivierung blockieren 503 Aktivierung unterdrücken 498 Aktivierungspriorität 446, 489 Ausfallsicherheit 514 Ausgefallene Server 498 Auswahl der besten Kopie 446 AutoDatabaseMountDial 500 Automatischer Datenbankwechsel 444 Beispiel 518 Bevorzugte Aktivierung einer Kopie 446 Clientzugriffsarrays 662 Cluster mit Hauptknotensatz 468 Datacenter Activation Coordination Protocol 513 Dateifreigabenzeugen 465, 477 Datenbanken automatisch neu verteilen 522 Datenbanken hinzufügen 483 Datenbanken umbenennen 460 Datenbanken umschalten 498, 502 Datenbanken verschieben 396 Datenbankkopien aktivieren 493 Datenbankkopien entfernen 506 Datenbankkopien hinzufügen 488 Datenbanknamen 459 Domänencontroller 470 Eigenschaften 476 Eigenschaften anzeigen 465 Einführung 438 Einschränkungen 517 Erstellen 464 Exchange-Verwaltungskonsole 463 Exchange-Verwaltungsshell 468 Failover 443, 495 Fehlerbehebung 475 Firewalls 466 Inkrementelle Neusynchronisierung 457 IP-Adressen 468, 479
Stichwortverzeichnis
Datenbankverfügbarkeitsgruppen (Fortsetzung) IPv6 481 Konto 463 Leistungseinbußen 502 MAPI-Endpunkt 441 Maximalanzahl von Servern 439 Mehrere Active Directory-Standorte 480 Messungen 523 Nachrichtenübermittlungsoptionen 462 Namenskonventionen 221 Netzwerke 478 Postfachdatenbankmaster 443 Postfächer verschieben 714 Quorum 468 Rechenzentren 469, 513 Replikationsdienst 446 Reseeding 487 Schattenredundanz 775 Seedingfehler 485 Server aktualisieren 497, 511 Server entfernen 509 Server hinzufügen 470 Servervoraussetzungen 474 Sicherung 491, 537 Skripts 521 Speicherorte verschieben 504 Split-Brain-Syncrom 513 Standardgateway 480 Standortübergreifende Verbindungen 515 Suchkatalog ignorieren 501 Switchover 443, 493, 499 Transaktionsprotokolle wiedergeben 449 Überwachen 486 Umlaufprotokollierung 456, 482 Verschlüsselung 477 Verwaltung 463 Verzögerte Datenbankkopien 490 Voraussetzungen 442 Wartezeiten 480 Windows-Cluster 441 Datenbankwartung Abgelaufene Sichten 401 Aufgaben 384, 397 Beschädigte Elemente 404 Defragmentierung 397 Inhaltswartung 401 Nachverfolgen 403 Öffentliche Ordner 402 Onlinewartung 397 Planen 400 Prüfsummen 398 Tombstone-Wartung 401 Zeitplan 400
Datenschutz Programm zur Verbesserung der Kundenzufriedenheit 85 Übermittlungsberichte 250 Datenverluste 695 Datums- und Uhrzeitformat 289 Deferred Action Message 241 Deferred Actions 241 Defragmentierung 397, 415 Deinstallation 74, 77 Delegated Setup 83 Designs 590 Detailvorlagen-Editor 933 Dial-Tone-Wiederherstellung 545 Dienste AutoErmittlung 648 Clientzugriffsserver 639 Exchange-Mailübergabedienst 775 IMAP4 602 POP3 602 Postfachreplikationsdienst 688 Prüfen 162 Übersicht 85 Dienstverbindungspunkt 648 Dirty Shutdown 542 Disable-Mailbox 302 Discoverysuchpostfächer 316 Dismount-Database 395 DNS Clientzugriffsarrays 661 MX-Einträge 815 SRV-Zeiger 658 Domänen Absenderfilterung 896 Akzeptierte Domänen 851 Akzeptierte Domänen erstellen 853 AutoErmittlung 658 Autorisierende Domänen 852 E-Mail-Adressrichtlinien 852 Gefälschte Domänen 906 NextHopDomain 833 Relaydomänen 852 Remotedomänen 854 Verwalten 854 Weiterleitungsbenachrichtigungen blockieren 581 Domänencontroller Affinität 109 Computeruhr läuft nicht synchron 116 Datenbankverfügbarkeitsgruppen 470 Exchange-Verwaltungskonsole 214 Keine Verbindung 57 Lange Antwortzeiten 682 977
Stichwortverzeichnis
Domänencontroller (Fortsetzung) RODC 59 Sicherheitsprobleme 67 Dynamische Verteilergruppen Abfragebasierte Verteilergruppen umwandeln 341 Benutzerdefinierte Filter 345 Einführung 328, 340 Erstellen 342 Filter 343 Leistung 341 Moderation 351 OPATH-Abfragen 341 Vorschau 343
E E00OutOfDate 453 Edge-Abonnements 876 Edge-Synchronisierung Ablauf 876 Einführung 876 Erzwingen 879 Fortlaufend 883 Intervalle 884 Lease 883 Testen 880 Überprüfen 879 EdgeSync-Lease 883 EdgeTransport.exe.config 793, 827 Edge-Transport-Server Adressumschreibung 916 ADSI-Editor 880 Agents 857 Antispam-Agents 886 Edge-Abonnements 876 Edge-Synchronisierung 876 Einführung 874 Empfängeranzeige 882 Empfangsconnectors 800, 876, 880 Exchange-Versionen 876 Exchange-Verwaltungskonsole 875 Firewalls 874 Installieren 80 Konfigurationseinstellungen 886 Konfigurationsnamenskontext 880 Regelmäßige Aktualisierung 883 Schattenredundanz 860 Standortmitgliedschaft 876 Synchronisierungsdatenbank 885 Transporteinschränkungen 823 Vorteile 873 Einmalsicherung 533 978
Einschränkungsrichtlinien 625 E-Mail-Adressrichtlinien Adressformat 311 Ausschließen 307 Benutzerdefinierte Filter 313 Domänen 852 Einführung 307 Erstellen 309 Filter 313 Gültigkeitsbereich 310 Maskenvariablen 312 Priorität 308, 314 Veraltete Richtlinien 308 E-Mail-Benutzer 357 E-Mail-Infos Anzeige 742 Benutzerdefiniert 744 Einführung 738 Einrichten 740 Funktionsweise 740 Gründe 741 Moderierte Gruppen 351 Moderierte Postfächer 355 Offlineadressbuch 764 Sprache 745 E-Mails Adressrichtlinien 307 Anhalten 834 Anhänge 588, 599 Anhänge filtern 913 Aus Warteschlangen löschen 834 Automatische Antworten 291 Beschädigte Nachrichten 404 Blockierte Absender 295 Erneut übertragen 838 Freigeben 834 Für andere Benutzer senden 325 Gelöschte Nachrichten 402 Genehmigen 352 Journal 354 Junk-E-Mail-Einstellungen 295 Komprimierung von Anhängen 385 Lange Signaturen 581 Langsame Benachrichtigungen 558 Maximale Nachrichtengröße 780 Mehrere Empfänger 781 Moderation 352 Nachricht über verzögerte Aktionen 241 Nachverfolgen 937 Pickup-Verzeichnis 836 Prioritäten 868 Problemwarteschlangen 832 Rechtschreibprüfung 295
Stichwortverzeichnis
E-Mails (Fortsetzung) Routing 775 Senden als 319, 321 Senden im Auftrag von 319, 321 SMS 609 Spam 872 Systemnachrichten 828 Textnachrichten 609 Transporteinschränkungen 822 Transporteinstellungen 786 Über Verwaltungsshell senden 154 Übermittlung prüfen 166 Übermittlungsberichte 245 Umfangreiche Nachrichten 791 Unterhaltungen 560 Viren 872 Weiterleitungsadresse 320 Wiedergabeverzeichnis 838 EML 837 Empfänger Anzeige in AD LDS 882 Fotos hinzufügen 134 Maximale Anzahl 320 Moderierte Empfänger 349 Verborgene Empfänger anzeigen 746 Empfängerfilterung 888, 900 Empfängersperrlisten 900 Empfangsconnectors Anonyme Verbindungen 802 Berechtigungen 606 Edge-Transport-Server 800, 876, 880 Einstellungen 790, 806 Erstellen 803 Hub-Transport-Server 800 IMAP4 605 IP-Adressbereich 806 SMTP 800 Standardconnector 800 Transporteinschränkungen 823 Verknüpfung mit Sendeconnectors 821 Enable-Mailbox 281 Enable-TransportAgent 916 Ereignisse 1009 826 1018 458 1022 458 2080 54 Crimson 516 Nachrichtenverfolgung 944 Sicherungen 535 SMTP-Ereignisse 856 ESE 373 ESE-Scan 398, 399
ESEUTIL 418, 542 EWS 634 ExBPA.StayingInformed.Config.xml 223 Exchange Best Practices Analyzer Installationsvorbereitung 41 Leistungsproblembehandlung 962 Organisationsstatusdaten 223 Rollenbasierte Zugriffssteuerung 199 Exchange Load Generator 2010 965 Exchange Server 2000 Entfernen 41 Streaming-Datei 414 Exchange Server 2003 Abfragebasierte Verteilergruppen 341 Aktualisierung 35 Außer Betrieb setzen 864 Connectors 776, 858 E-Mail-Adressrichtlinien 308 Exchange-System-Manager 205 Front-End-Server 667 Offlineadressbuch 749 Parallele Bereitstellung 46 Postfächer verschieben 693 Routinggruppen 862 Verbindungsstatusaktualisierungen 864 Verknüpfen mit Exchange Server 2010 862 Exchange Server 2007 Aktualisierung 35 Anpassungen übernehmen 44 Bereich für Active Directory-Abfragen 150 Cmdlet-Pipeline 133 Cmdlets zur Kalenderverarbeitung 366 Datenbankschema 386 Delegierung 181 E/A-Leistung 382 Einzelkopiecluster 524 Entfernen 46 Gruppenaufgliederung 795 Parallele Bereitstellung 46 Postfächer verschieben 693 PowerShell 105 Replikation 43 Routing 784 Service Packs 45 Verwaltung von Exchange Server 2007-Objekten in Exchange Server 2010 209 Verwendung in Exchange Server 2010Umgebung 41, 45 Exchange Server 2010 Aktualisierung vorbereiten 41 Änderungen bei betrieblichen Verfahren 43 APIs 44, 632 Auswirkungen auf Programme 44 979
Stichwortverzeichnis
Exchange Server 2010 (Fortsetzung) Bereitstellungsassistent 47 Beta-Versionen 36 Coexistence Edition 47 Datenbankschema 386 Dienste 86 E/A-Leistung 382 Editionen 41, 47 Enterprise Edition 47 Gateway Edition 47 Gründe für die Aktualisierung 34 Installieren 66 Lokale und Onlineinstallation 35 Neuerungen der ExchangeVerwaltungskonsole 206 Parallele Bereitstellung 46 PowerShell-Remotezugriff 106 Reparieren 79 Replikation 375 Sicherungen 374 Standard Edition 47, 376 Transportarchitektur 774 Umfangreiche Postfächer 380 Veraltete Adressrichtlinien 308 Verwaltung von Exchange Server 2007Objekten 209 Voraussetzungen 69 Vorteile 32 Windows-Version 39 Exchange Server 2010 SP1 ActiveSync-Gerätezugriffsregeln 618 ActiveSync-Richtlinien 611 Automatische Zuordnung freigegebener Postfächer 556 Blockreplikation 454 Datenbankverfügbarkeitsgruppen 465 Exchange-Systemsteuerung 235 Hängender Speicher 510 Kalenderfreigabe im Internet 227, 585 New-MailboxRestoreRequest 548 Organisationsstatusdaten 225 OWA 571 Postfächer entfernen 303 Postfächer online verschieben 705 Rollenbasierte Zugriffssteuerung 191 Schemaerweiterungen 68 Transportsystem 865 Verbesserungen 91 Zugriff auf Exchange-Systemsteuerung 255 Exchange Trusted Subsystem 67, 100, 107, 196, 466 Exchange User Monitor 624 Exchange Windows Permissions 196 Exchange.ps1 146 980
Exchange-Cache-Modus 559 Exchange-Replikationsdienst 446 Exchange-System-Manager 205 Exchange-Systemsteuerung ActiveSync-Gerätezugriffsregeln 618 ActiveSync-Richtlinien 611 Administratoraufgaben 247 Anmeldung 236 Ansicht 239 Anzahl der zurückgegebenen Objekte 236 Ausführen ohne Exchange-Postfach 255 Benutzeraufgaben 237 Einführung 234, 236 Einstellungen 239 Gruppen erstellen 261 Gruppenbenennungsrichtlinie 258, 259 Gruppenerstellung durch Benutzer 266 Gruppenverwaltung 257 Mitgliedschaft in Gruppen ermitteln 264 Mobile Geräte zurücksetzen 621 Öffentliche Gruppen 265 Posteingangsregeln 242 Postfacheinstellungen eines anderen Benutzers bearbeiten 256 Recipient Management 247 Rollen 200 Rollen hinzufügen 194 Rollenbasierte Zugriffssteuerung 235, 237 Rollengruppen 192 Rollengruppen erstellen 195 Rollengruppen erweitern 194 Service Pack 1 235 Sicherheitsgruppen 263 Speicherort für Gruppen 258 Transportregeln 235 Übermittlungsberichte 245 Verwaltungsbereich auswählen 237 Zugriff 234 Zugriff prüfen 165 Exchange-Verwaltungskonsole Active Directory 212 Aktuelle Informationen abrufen 213 Anzahl der zurückgegebenen Objekte 215 Aufbau 206 Automatisch generierte PowerShell-Befehle 216 Befehlsprotokollierung 216, 218 Benutzerdefinierte Attribute 63 Berechtigungen 207 Berechtigungsprobleme 115 Datenbanken umbenennen 460 Datenbanken verschieben 396 Datenbankkopien erstellen 484 Datenbankkopien überwachen 486
Stichwortverzeichnis
Exchange-Verwaltungskonsole (Fortsetzung) Datenbankverfügbarkeitsgruppen 463 Diagnoseprotokollierung 270 Domänencontroller 214 Domänenverwaltung 854 Edge-Transport-Server 875 Eigenschaften von Datenbankverfügbarkeitsgruppen 476 E-Mail-Adressrichtlinien erstellen 309 Exchange Server 2007-Objekte 209 Freigaberichtlinien 227 Getrenntes Postfach 304 Kalendereinstellungen 293 Kein Serverzugriff 211 Keine Verbindung mit Domänencontroller 57 Massenbearbeitung 217 Mehrere Organisationen 225 Mobile Geräte zurücksetzen 620 Nachrichtenübermittlungseinstellungen 319 Neuerungen 206 Nicht lizenzierte Server 95 Offlineadressbuch aktualisieren 755 Organisationsstatusdaten 222 Outlook Anywhere aktivieren 672 Postfachdatenbanken bereitstellen 392 Postfachdatenbanken erstellen 390 Postfächer erstellen 277 Postfächer verschieben 696 Reaktionsgeschwindigkeit der Konsole erhöhen 389 Replikation beobachten 450 Sendeconnectors 815 Server zu Datenbankverfügbarkeitsgruppen hinzufügen 470 Serverauswahl 211 Spalten 216 Starten 210 Switchover 494 Transporteinstellungen 786 Transportregeln 235 View-Only Management 211 Zertifikate 231 Exchange-Verwaltungsshell Anzahl der zurückgegebenen Objekte 135 Ausführlicher Modus 158 Ausführungsrichtlinien 159 Ausgabe weiterleiten 132 Benutzerdefinierte Attribute 64 Clientzugriff auf Postfachserver blockieren 569 Connectors 802, 808 Datenbanken umbenennen 460 Datenbank-GUID 376
Exchange-Verwaltungsshell (Fortsetzung) Datenbankkopien hinzufügen 488 Datenbankverfügbarkeitsgruppen 468 Discoverysuchpostfächer 317 Edge-Synchronisierung 879 Eigenschaften von Datenbankverfügbarkeitsgruppen 476 Einschränkungsrichtlinien 625 E-Mail-Adressrichtlinien 313 E-Mails senden 154 Empfängerfotos hinzufügen 134 Fehler beim Weiterleiten der Ausgabe 133 Grundlagen 118 Gruppen schützen 335 Gruppenbenennungsrichtlinie ignorieren 259 Gültigkeitsbereich 149 Hilfreicher Code im Internet 151 Hintergrundwartung 399 Inhaltsfilter-Agent 912 Kalendereinstellungen 293 Keine Verbindung zum lokalen Host 110 Keine Verbindung zum Server 113 Kontakte erstellen 356 Massenaktualisierungen 141 Moderierte Gruppen 350 Offlineadressbuch 751 Posteingangsregeln 244 Postfachberechtigungen 320 Postfachdaten exportieren 734 Postfachdaten importieren 729 Postfachdatenbanken bereitstellen 392 Postfächer verschieben 702 Postfachrichtlinien erstellen 596 Probleme bei Remotesitzungen 111 Profile 146 Protokollierung 139 Quarantänepostfächer 405 Raumlisten 330 Remotesitzung 108, 110 Reseeding 488 Sendeconnectors 818 Server zu Datenbankverfügbarkeitsgruppen hinzufügen 472 Übermittlungsberichte 254 Verbindung abgelehnt 114 Verzögerte Protokollwiedergabe 491 Voraussetzungen 112 Exchange-Webdienste 634 Exhange Performance Wizard 962 ExLogAnalyzer 959 ExMon 624 ExPerfWiz 962
981
Stichwortverzeichnis
F Failover 443, 495 Failovercluster Datenbankverfügbarkeitsgruppen 441 Hauptknotensatz 468 IP-Adressen 468, 479 IPv6 481 Manager 473 Quorum 468 Voraussetzungen 442 Windows-Funktion 470 Favoriten 579 Fax 632 Fehlerbehebung ActiveSync 622 Älterer PowerShell-Code 143 Ausgefallene Server 498 AutoErmittlung 654 Berechtigungsprobleme bei der ExchangeVerwaltungskonsole 115 BlackBerry 626 Clients 608 Cmdlet-Pipeline 133 Datenbank lässt sich nicht entfernen 710 Datenbankbereitstellung 393 Datenbankkopien entfernen 508 Datenbankverfügbarkeitsgruppen 475 Exchange-Verwaltungsshell hat keine Verbindung zum lokalen Host 110 Fehlender Serverzugriff für ExchangeVerwaltungskonsole 211 Gelöschte Nachrichten 402 Hängender Speicher 510 Installationsfehler 75 Kalenderreparaturassistent 767 Keine Datenbanken für ein Postfach verfügbar 286 Keine Synchronisierung zwischen Exchange und Active Directory 62 Keine Verbindung zu einem Domänencontroller 57 Keine Verbindung zum Remotehost 114 Konnektivitätsprotokolle 848 Kontingentüberschreitung 154 Lange Wartezeiten 407 Mobile Geräte 622 Organisationsstatusdaten 225 Outlook Anywhere 652 Postfächer erstellen 278 Postfächer verschieben 717
982
Fehlerbehebung (Fortsetzung) Postfachzugriff 652 PowerShell-Skripts 129 Quarantänepostfächer 406 Remotesitzung der ExchangeVerwaltungsshell 112 Rollengruppenbereiche 184 Seedingfehler 485 Speichertreiber 409 Test-Cmdlets 160 Übermäßiges Datenbankwachstum 409 Übermittlungsberichte für verschobene Postfächer 249 Verschiebungsanforderungen 721 WS-Verwaltungsdienst 114 Filter Absenderfilterung 896 Absenderzuverlässigkeitsfilterung 899 Adresslisten 761 Anlagenfilterung 913 Antispam-Agents 888 Benutzerdefinierte Filter 345 Clientseitig 136 Datenbankbereiche 196 Datenbanken 389 Dynamische Verteilergruppen 343 E-Mail-Adressrichtlinien 313 Empfängerfilterung 901 Empfängertypen 349 Erstellen 139 Inhaltsfilterung 907 Junk-E-Mail-Filter 925 Objekte ohne gemeinsame Eigenschaft 142 Offlineadressbücher 759 OPATH 136 Rücklauffilter 898 Serverseitig 136 Verbindungsfilterung 893 Warteschlangen 830 Firewalls Clientzugriffsserver 646 Datenbankverfügbarkeitsgruppen 466 Edge-Transport-Server 874 Headerfirewalls 891 Postfachserver 646 Format-List 123 Format-Table 123, 125 Freigaberichtlinien 226, 227 Fremdconnectors 858 Front-End-Server 667
Stichwortverzeichnis
G Gerätepostfächer 283, 358 Gesamtstrukturen Mehrere Domänen 149 Ressourcen unterbringen 52 Verschiebungsanforderungen 706 Get-ActiveSyncDeviceStatistics 612 Get-ActiveSyncOrganizationSettings 615 Get-ADSiteLink 780 Get-AgentLog 917 Get-AttachmentFilterEntry 913 Get-Calendar-Processing 365 Get-CASMailbox 568 Get-ClientAccessArray 661 Get-ClientAccessServer 651 Get-Command 119 Get-ContentFilterConfig 912 Get-DatabaseAvailabilityGroup 443 Get-DeliveryAgentConnector 859 Get-DistributionGroupMember 338 Get-DynamicDistributionGroup 345 Get-EdgeSyncServiceConfig 884 Get-EmailAddressPolicy 307 Get-EventLogLevel 272 Get-ExchangeServer 92 Get-Help 119 Get-IMAPSettings 604 Get-InboxRule 244 Get-IPAllowListConfig 893 Get-IPBlockListConfig 893 Get-Mailbox 94 Get-MailboxAutoReplyConfiguration 291 Get-MailboxCalendarConfiguration 293, 366 Get-MailboxCalendarFolder 587 Get-MailboxDatabaseCopyStatus 486 Get-MailboxFolder 294 Get-MailboxImportRequest 730 Get-MailboxImportRequestStatistics 730 Get-MailboxJunkEmailConfiguration 295 Get-MailboxMessageConfiguration 294 Get-MailboxRegionalConfiguration 291 Get-MailboxSpellingConfiguration 295 Get-MailboxStatistics 301 Get-ManagementRole 238 Get-ManagementRoleAssignment 182, 188, 189, 238 Get-Message 833 Get-MessageTrackingLog 952 Get-MoveRequest 703, 709 Get-MoveRequestStatistics 703 Get-OABVirtualDirectory 757 Get-OfflineAddressBook 752
Get-OrganizationConfig 224 Get-POPSettings 604 Get-Queue 830 Get-ReceiveConnector 800, 806, 808 Get-RecipientFilterConfig 901 Get-RoleGroup 188 Get-SendConnector 818 Get-SenderFilterConfig 896 Get-SenderIDConfig 906 Get-SenderReputationConfig 899 Get-service 89 Get-StoreUsageStatistics 419 Get-SystemMessage 843 Get-ThrottlingPolicy 625 Get-TransportConfig 786 Get-TransportPipeline 856, 887 Get-TransportServer 809 Get-UserPrincipalNameSuffix 207 Globale Kataloge 58 Gruppen Abfragebasierte Verteilergruppen 341 Anzeige der Mitglieder unterbinden 339 Aufgliedern 334, 794 Benennungsrichtlinie festlegen 259 Benutzung nachverfolgen 340 Besitzer 332 Erstellen 261 Erstellen durch Benutzer zulassen 266 Exchange Trusted Subsystem 100 Exchange-Sicherheitsgruppen 96 Exchange-Systemsteuerung 257 Geschützte Gruppen 335 Gruppenbenennungsrichtlinie 258 Messdaten 738 Mitglieder anzeigen 338 Mitgliedschaft 261 Mitgliedschaft ermitteln 264 Moderierte Gruppen 339, 349 Namenskonventionen 221 Öffentliche Gruppen 265 Organisationseinheit 258 Raumlisten 330 Rollengruppen 179 Routinggruppen außer Betrieb setzen 864 Selbstwartende Gruppen 337 Sicherheitsgruppen 263 Standardspeicherort 258 Verteilergruppen 327 Verwaltung durch Benutzer zulassen 268 Zugriffssteuerungslisten 338 GuessSmart 653
983
Stichwortverzeichnis
H Headerfirewalls 892 Hierarchisches Adressbuch 765 Hub-Transport-Server Agents 857 Antispam-Agents 886 Dynamische Verteilergruppen 341 Edge-Abonnement 877 Einführung 774 Empfangsconnectors 605, 800 Funktion 782 Gruppenaufgliederung 334 Lastenausgleich 775 Rückstau 825 Schattenredundanz 860 Sendeconnectors 809 TLS 799 Transporteinschränkungen 823 Transporteinstellungen 786 Transportpapierkorb 783
I ICS 694 Identitätsparameter 130 Identity Lifecycle Management 44 IgnoreNamingPolicy 259 IIS-Manager 113 IMAIL 414 IMAP4 Authentifizierung 606 Blockierte Konten 606 Clients 601 Clientzugriff 605 Connector 605 Server einrichten 602 Verbindung prüfen 166 Verbindungen 643 Implicit...WriteScope 178 Implizite Schreibbereiche 178 Import/Export Archive 733 Berechtigungen 725 Bericht 731 Cmdlets 726 Exchange-Verwaltungsshell 729, 734 Importvorgang abbrechen 733 Informationen über Aufträge abrufen 730 Mehrere gleichzeitige Importvorgänge 729 Öffentliche Ordner 725 Planen 727 Postfachdaten 734
984
Import/Export (Fortsetzung) Postfächer 723 PST-Daten 727 Ungültige Elemente 732 Import-CSV 296 Import-Module 70 Import-RecipientDataProperty 134 Incremental Change Synchronization 694 Indexalterungstabelle 401 Informationsspeicher Hauptkomponenten 372 Logische Beschädigung 490 Postfachprobleme erkennen 404 Speichertreiber 409 Verbesserungen 381 Verringerung der E/A-Vorgänge 378 Infrastruktur für öffentliche Schlüssel 230 Inhaltsfilterung 888, 907 ININTEG 411 InspectionFailed 453 Installation /m:recoverserver 81 /PrepareAD 67 Ablauf 66 Antispam-Agents 887 Befehlszeile 74 Clientzugriffsserver 641 Delegieren 83 Domänencontroller 67 Edge-Transport-Server 80 Fehlerbehebung 75 Geteilte Active Directory-Berechtigungen 197 Microsoft Filter Pack 73 Modi 73 Notfallwiederherstellung 74 Programm zur Verbesserung der Kundenzufriedenheit 84 Setupprotokolle 76 Sprachpakete 80 Systemkomponenten 69 Wiederherstellungsmodus 81 XML-Installationsdateien 70 iPhone 618 IP-Sperrlisten 893 IPv6 481 IP-Zulassungslisten 893 IssueWarningQuota 297
J Jet 373 Journal 354 Junk-E-Mail-Einstellungen 295
Stichwortverzeichnis
Junk-E-Mail-Filter 925 Junk-E-Mail-Ordner 911
K Kalender Einstellungen 293 Freigabe im Internet 585 Freigaberichtlinien 227, 586 Freigeben 582 Kalenderanforderungen verarbeiten 293 Kalenderassistent 293, 767 Raumpostfächer 364 Weitergeleitete Besprechungsanforderungen 580 Zeitplanassistent 767 Kalenderreparaturassistent 767 Kapazitätsplanung 378 KerbAuth 112 Konfigurationsnamenskontext 880 Konnektivitätsprotokollierung 847 Kontakte E-Mail-aktiviert 356 Erstellen 356 Moderation 356 Namenskonventionen 221 Kontingente Archive 300 Benachrichtigungen 844 Cacheaktualisierungen 154 Datenbankgrößen abschätzen 300 Papierkorb 300 Postfacheigenschaften 297 Postfachverschiebungen 704 Standardspeicherkontingente einer Datenbank 298 Überschreiten 587 Umfangreiche Postfächer 383 Warnnachrichten 297
L Lastenausgleich Clientzugriffsarrays 661 Hub-Transport-Server 775 Möglichkeiten 675 Service Pack 1 865 SMTP 865 Windows-Netzwerklastenausgleich 664 legacyExchangeDN 644 Leistungsindikatoren 960 Leistungsproblembehandlung 962 Listen blockierter Absender 920 Listen sicherer Absender 920
Lizenzierung Clientzugriffslizenzen 42 Enterprise-Lizenz 48 Funktionen 223 Nicht lizenzierte Server 95 Postfachfunktionen 280 LLR 457 LoadGen 965 LogParser 958 Lokale Fehler 564 Lost Log Resilience 457 Lotus Notus 776
M Mailbox Import Export 185 Mailbox Search 185 MAPI Eigenschaften 414 Endpunkt 441, 640 Zugriff deaktivieren 566 Massenaktualisierungen 140 Measure-Command 117 Message Tracking 248 MFCMAPI 405 Microsoft Exchange-Mailübergabedienst 775 Microsoft Exchange-Transportprotokollsuche 938 Microsoft Federation Gateway 226 Microsoft Filter Pack 73 Microsoft Forefront Protection for Exchange Server 2010 898, 922 Microsoft Forefront Threat Management Gateway 924 Microsoft Sender ID Wizard 904 Microsoft System Center Data Protection Manager 2010 491 Mobile Geräte ActiveSync 608 ActiveSync-Richtlinien 610 Anbindung testen 623 Benutzer blockieren 619 BlackBerry 623, 964 Fehlerbehebung 622 iPhone 618 Quarantäne 618 Synchronisiserungsberichte 612 Typen blockieren 615 Windows Mobile 609 Zugriffsregeln 616 Zurücksetzen 620 Moderatoren 352 Mount-Database 392, 393 Move-ActiveMailboxDatabase 498, 502 985
Stichwortverzeichnis
Move-DatabasePath 396 Move-Mailbox 691 MoveMailbox.ps1 703 Move-OfflineAddressBook 756 MX-Einträge 815
N Nachrichtenverfolgung Analysemöglichkeiten 958 Dateien 941 Datenanzeige 942 Einführung 937 Einträge deuten 944 Ereignisse 944 Grenzwerte 941 Postfachserver 940 Protokollierung des Betreffs 940 Verfolgungsprotokoll-Explorer 954 Wartezeit messen 952 Name Service Provider Interface 647 Namenskonventionen 221, 275 Network Load Balancing 664 New-ActiveSyncDeviceAccessRule 616 New-AddressList 761 New-ClientAccessArray 661 New-DatabaseAvailabilityGroup 468 New-DistributionGroup 259, 330 New-DynamicDistributionGroup 345 New-EdgeSubscription 876, 878 New-EmailAddressPolicy 312, 313 New-ExchangeCertificate 672 New-FederationTrust 226 New-InboxRule 244 New-Mailbox 280 New-MailboxDatabase 392 New-MailboxFolder 294 New-MailboxImportRequest 729 New-MailboxRepairRequest 411 New-MailboxRestoreRequest 546, 696 New-MailContact 356 New-MailMessage 154 New-MailUser 358 New-ManagementRoleAssignment 186, 187 New-ManagementRoleAssignmentPolicy 238 New-ManagementScope 195 New-MoveRequest 703 New-OrganizationRelationship 226 New-OWAMailboxPolicy 596 New-PublicFolderDatabaseRepairRequest 411 New-ReceiveConnector 806 New-RoleGroup 181 New-RoutingGroupConnector 863 986
New-SendConnector 816 New-SystemMessage 842 New-TestCASConnectivity.ps1 117 New-ThrottlingPolicy 627 NextHopDomain 833 Nicht-erreichbar-Warteschlange 831 NLB 664 Notfallwiederherstellung 74, 493 Novell GroupWise 776 NSPI-Endpunkt 647 NTBACKUP 530
O OABInteg 764 Objektversionen 94 OCS 601 Öffentliche Ordner Aufbewahrungszeit 402 Hintergrundwartung 402 Import und Export 725 Löschen 402 Namenskonventionen 221 Offlineadressbuch 758 Outlook 2003 646 Reparieren 411 Replikation 403 Office Communications Server 601 Offlineadressbuch Aktualisieren 747, 755 Anderer Server zur Generierung 756 Attribute 754 Benutzerdefiniert 759 Dateien 748 Datenbanken 393 Einführung 746 E-Mail-Infos 764 Erstellen 760 Exchange Server 2003 749 Generieren 750 Gruppenmessdaten 738 Herunterladen 747 Miniaturbilder 755 OABInteg 764 Öffentliche Ordner 758 Verteilung an Clients 751 Virtuelles Verzeichnis 757 Webgestützte Verteilung 757, 763 Zuweisen 763 Onlinedefragmentierung 397, 415 OPATH-Abfragen 341 OPATH-Filter 136 Organisationsstatusdaten 222
Stichwortverzeichnis
Organization Management 172 OTA-Aktualisierung 609 Outlook Autokonfiguration 653 Buildnummern 567 Deaktivierte Links 927 Detailvorlagen 933 Dienstverbindungspunkt 649 E-Mail-Infos 743 Exchange-Cache-Modus 559 Fehlerbehebung 652 Frühere Versionen 557 Gruppenmitgliedschaften ändern 332 Junk-E-Mail-Filter 925 Konfliktlösung 564 Langsame E-Mail-Benachrichtungen 558 Lokale Fehler 564 NSPI-Endpunkt 647 Offlineadressbuch herunterladen 747 Poststempel 930 Protokollierung 657 Regelfunktion 241 Regions- und Zeitzoneneinstellungen 287 Registrierungswerte für den Zugriff auf persönliche Speicher 736 Serverfehler 564 Sichten 379 Synchronisierungsprobleme 565 Verbindungen 642, 643 Verschlüsselung 646 Versionen 556 Versionen blockieren 567 Outlook 2003 Fehlende Funktionen 557 Unterstützen 646 Outlook 2007 Fehlende Funktionen 557 Outlook 2010 Automatische Zuordnung freigegebener Postfächer 556 Gleichzeitig geöffnete Postfächer 557 Moderierte Gruppen 339 Raumlisten 330 Übermittlungsberichte 245 Unterhaltungsansichten 560 Zertifikate 230 Outlook Anywhere Aktivierung 672 Schnellere Verbindungen 559 Standardmäßig verwenden 642 Testen 967
OWA Anhänge 588, 599 Anpassungen 590 Aufgegebene Funktionen 573 Benutzeroberfläche 571 Besprechungsanforderungen 359 Browser 554, 574 Browser-Betriebssystem-Kombinationen 575 Chrome 574, 576 Code in Textdateien 600 Dateizugriff 596 Designs 572, 590 Dokumentzugriff 574 Eigener Text im Anmeldebildschirm 591 Einschränkungen 570 E-Mail-Infos 742 ExternalURL 585 Favoriten 579 Junk-E-Mail-Optionen 925 Kalender freigeben 582 Kalender veröffentlichen 586 Kalenderfreigabe im Internet 585 Konfigurationsdatei 578 Kontingentüberschreitungen 587 Lange Signaturen 581 Light 574, 577 Postfachrichtlinien 592 Premium 574 Rechtschreibprüfung 575 Regions- und Zeitzoneneinstellungen 288 Registrierungseinträge 578 Safari 574 Segmentierung 592, 596 Sitzungen 578 Sprache wechseln 288 Sprachen 286 Standardsprache 289 Timeout 578 Übermittlungsberichte 245 Unterhaltungsansichten 560 Verbesserungen in SP1 571 Verbindungen 643 Versionen 574 Webparts 573, 581 WebReady 598 Weitergeleitete Besprechungsanforderungen 580 Zugriff auf die Postfächer anderer Benutzer 326 Zugriff prüfen 164
987
Stichwortverzeichnis
P PAM 442 Papierkorb 300 PAS 134 PCL-Wert 889 Phishing 889 Pickup-Verzeichnis 813, 828, 836 PKI 230 POP3 Blockierte Konten 606 Clients 601 Connector 605 Verbindung prüfen 166 Verbindungen 643 Posteingangsregeln 241 Postfachassistenten 766 Postfachbereitstellungs-Agent 283 Postfachdatenbankmaster 443 Postfächer Absenderpostfach auswählen 325 ActiveSync-Richtlinien 610 Allgemeine Eigenschaften 294 Ältere Postfächer verschieben 693 Anzahl pro Datenbank 377 Archive 282 Archive verschieben 697, 708 Arten 274, 277 Assistenten 766 Asynchron verschieben 691 Aufbewahrungsfrist ändern 304 Automatische Antworten 291 Automatische Zuordnung freigegebener Postfächer 556 Benutzerdefinierte Eigenschaften 360 Berechtigungen 291 Berechtigungen entfernen 295 Bereitstellen 720 Clientverbindungen blockieren 566 Clientzugriffslizenzen 280 Daten exportieren 734 Datenbanken mit Clientzugriffsserver verknüpfen 644 Deaktivieren 302 Discoverysuchpostfächer 99, 316, 324 Doppelte Namen 278 Eigenschaften aktualisieren 282 Einrichten 282 Einstellungen ändern 290 E-Mail-Aktivierung 281 Entfernen 302 Enthaltene Objekte 301 Erneut verbinden 303
988
Postfächer (Fortsetzung) Erstellen 277 Gerätepostfächer 283, 358, 369 Gesamtzahl abrufen 224 Geschäftsleitung 911 Getrennte Postfächer 154, 304 Gleichzeitig in Outlook geöffnete Postfächer 557 Grenzwerte 792 Import/Export 723 Junk-E-Mail-Einstellungen 295 Kalenderanforderungen 293 Kalendereinstellungen 293 Kennwörter 280 Kontingente 297, 587 Kontingentwarnungen 297 Massenerstellung 280, 295 Maximale Empfängeranzahl 320 Moderierte Postfächer 354 Namenskonventionen 221, 275 Offlineadressbuch zuweisen 763 Online verschieben 691 Ordner 294 Postfachberechtigungen 319 Postfacheinstellungen eines anderen Benutzers bearbeiten 256 Postfächer anderer Benutzer öffnen 326 Postfächer für Anwendungen 274 Postfachreplikationsdienst 688 Prioritäten 868 Probleme 278, 404 Prüfen 274 Quarantäne 404 Raumpostfächer 282, 358 Remotestandort 283 Reparieren 411 Ressourcenpostfächer 358 Richtlinien 592 SCL-Werte 911 Sicherheit 274 Sichten 379 Sofortige Löschung 303 Spracheinstellungen 286 Threads 404 Übermittlungsberichte für verschobene Postfächer 249 Überwachung 327 Umfangreiche Postfächer 380, 383 Vermittlungspostfach 354 Verschieben 689, 696 Vollzugriffsberechtigung 322 Vorüberlegungen 274 Weiterleitungsadresse 320 Wiederherstellen 546
Stichwortverzeichnis
Postfächer (Fortsetzung) Zu Datenbanken zuweisen 283 Zu Verteilergruppen hinzufügen 282 Zustellungsoptionen 319 Postfachreplikationsdienst Fehlertoleranz 721 Grenzwerte 695 Konfiguration 688 Prüfen 165 Verarbeitungsweise 693 Postfachserver Clientzugriff blockieren 569 Firewalls 646 MAPI-Clientanbindung 640 Nachrichtenverfolgung 940 Offlineadressbuch 750 Postfachverschiebungen Ablauf 693 Ältere Postfächer 693 Archive 697, 708 Assistent 697 Asynchron 691 Berichte 716, 717 Berichtsdatei 718 Datenbanken mit mehreren Kopien 723 Datenbankverfügbarkeitsgruppen 714 Datenverluste 695 Fehlerbehebung 717 Gesamtstrukturübergreifend 706 Geschwindigkeit 714 Grenzwert für ungültige Elemente 721 Gründe 689 Im Hintergrund 704 Kontingente 704 Nachrichteneingang 705 Online 691 Planen 710 Postfächer bereitstellen 720 Schwellenwert für ungültige Elemente 698 Signaturen beibehalten 704 Status prüfen 709 Verschiebungsanforderungen 697 Zwischen Exchange-Versionen 706 Problemwarteschlangen 832 Process Tracking Log Tool 959 Product Key 96 Profile 146 Programm zur Verbesserung der Kundenzufriedenheit 84 ProhibitSendQuota 297 ProhibitSendReceiveQuota 297 Promodag Reports 959
Protokolle Einschränkungen 568 IMAP4 601 POP3 601 X.400 786 Zertifikate 229 Protokollierung ActiveSync 622 Agentprotokolle 917 AutoErmittlung 654 Betreffzeile 250 Crimson-Kanal 516 Datenbankverfügbarkeitsgruppen 475 Diagnoseprotokollierung 270 Empfangsprotokolle 850 Exchange-Verwaltungskonsole 217, 218 Exchange-Verwaltungsshell 139 Konnektivitätsprotokollierung 847 Nachrichtenbetreff 940 Nachrichtenverfolgungsprotokolle 938 Ohne Wiederverwendung 431 Outlook 654 Postfachwiederherstellung 547 Protokolliergrade 271 Protokollprotokollierung 849 Reservierte Protokolle 432 RPC-Clienzugriffsdienst 668 Sendeprotokolle 850 Umlaufprotokollierung 395, 430 Verschiebungsanforderungen 701 Prüfpunktdateien 428 Prüfsummenvalidierung 398 PST-Dateien Importieren 727 Spracheinstellungen 290 Zugriff beschränken 736 Public Key Infrastructure 230
Q Quorum 468 QuotaNotificationSchedule 297
R Raumlisten 330 Raumpostfächer Adressliste 359 Besprechungsanforderungen 359 Buchungen verarbeiten 367 Buchungsrichtlinien 362 Erstellen 282
989
Stichwortverzeichnis
Raumpostfächer (Fortsetzung) Kalender 364 Kapazität 360 Stellvertreter 368 Rechenzentren 513, 662 Rechtschreibprüfung 295, 575 Recipient Management 247 RecipientOrganizationalUnitScope 184 RedistributeActiveDatabases.ps1 496, 522 Regionalcodes 289 Relaydomänen 852 Remote Connectivity Analyzer 966 Remotedomänen 854 RemoteExchange.ps1 110 Remoteverbindungsuntersuchung 966 Remove-AcceptedDomain 854 Remove-DatabaseAvailabilityGroupServer 470 Remove-Mailbox 176, 302 Remove-MailboxPermission 295 Remove-Message 834 Remove-MoveRequest 703, 709 Remove-RoleGroupMember 182 Remove-StoreMailbox 303, 696 Reparatur 79 Replikation Beobachten 450 Blockreplikation 454 Datenbankkopien 448 Datenbankverfügbarkeitsgruppen 446 Ereignisanzeige 516 Ignorierte Protokolle 453 Inkrementelle Neusynchronisierung 457 Komponenten des Replikationsdienstes 449 Komprimierung 477 Leistungsabfall 452 Neues Modell 375 Öffentliche Ordner 403 Postfachreplikationsdienst 688 Prüfen 163 Replikationsdienst 446 Replikationsnetzwerk 478 Reseeding 487 Schemaaktualisierung 60 Seitenbeschädigungen 458 Status prüfen 486 Transaktionsprotokolle abschneiden 455 Transaktionsprotokolle wiedergeben 449 Verschlüsselung 477 Wartezeiten 480 Reread Logon Quotas Interval 300 Reseeding 457, 487 Reservierte Protokolle 432 ResourceCapacity 360 990
Ressourcenbuchungsautomatik 362 Ressourceninformationen 362 Ressourcenrichtlinie 362 Restore-Mailbox 546 Resume-Message 834 Resume-MoveRequest 703, 711 Resume-Queue 835 RODC 59 Rollen Benutzerdefiniert 176, 187 Bereiche 177 Bereiche für Rollengruppen 184 Datenbankweite Bereiche 195 Definition 174 Delegieren 180 Endbenutzerrollen 189 Erforderliche Rollen für bestimmte Aufgaben ermitteln 238 Erstellen 176 Exchange-Systemsteuerung 200 Implizite Schreibbereiche 178 Message Tracking 248 Mitgliedschaft bestimmen 188 MyDistributionGroups 266 Ohne Bereich 186 Recipient Management 247 Rollen eines Benutzers ermitteln 238 Rollengruppen 179 Rollengruppen erstellen 181, 195 Rollenzuweisungen 175, 182 Rollenzuweisungsrichtlinie erstellen 238 Rollenzuweisungsrichtlinien 175, 189 Sonderrollen 185 Untergeordnet 176 Verwaltungsrollen 189 Zu Rollengruppen hinzufügen 193 Rollenbasierte Zugriffssteuerung Benutzerdefinierte Rollen 176 Berechtigungen für Cmdlets 109 Bereiche 177 Bereiche für Rollengruppen 184 Berichte 199 Cmdlet-Verwendung einschränken 176 Endbenutzerrollen 189 Exchange Best Practices Analyzer 199 Exchange-Systemsteuerung 192, 200, 235, 237 Exchange-Verwaltungskonsole 115, 207 Geteilte Berechtigungen 196 Grundlagen 171 Gruppenerstellung durch Benutzer 266 Gruppenverwaltung durch Benutzer 268 Import/Export 725 Mitgliedschaftsinformationen 188
Stichwortverzeichnis
Rollenbasierte Zugriffssteuerung (Fortsetzung) PowerShell-Sitzung 109 Recipient Management 247 Rollen 174 Rollen erstellen 176 Rollen ohne Bereiche 186 Rollengruppen 172, 179 Rollengruppen erstellen 181 Rollenzuweisungen 175, 182 Rollenzuweisungsrichtlinien 175, 189 Service Pack 1 191 Sonderrollen 185 Übermittlungsberichte 248 Universelle Sicherheitsgruppen 179 Untergeordnete Rollen 176 Validierungsregeln 199 Verwaltungsrollen 189 View-Only Management 211 Rollupupdates 89 Routing Active Directory 778 Exchange Server 2003 862 Exchange Server 2007 784 Exchange-spezifische Routingkosten 780 Externe SMTP-Server 803 Gruppenaufgliederung 794 Hub-Transport-Server 782 Kosten 775 Netzwerkausfall 779 Pfade 775 Prioritäten 868 Routingtabellen 796 Rückstau 794, 825 Schattenredundanz 775 Sendeconnector mit Bereich 821 Standortverknüpfungskosten 778, 779 Topologie 775 Transportarchitektur 774 Transporteinschränkungen 822 Transporteinstellungen 787 Transportkonfigurationsdatei 793 Transportpipeline 856 Transportwarteschlangen 826 Verbindungskosten von Adressräumen 816 Verknüpfte Connectors 821 Verschlüsselung 799 Versionsübergreifend 784 Verzögertes Auffächern 781 Routinggruppenconnectors 863 RoutingTLS 799 RpcClientAccessServer 645 RPC-Clientzugriffsschicht 643 Rückstau 794, 825
S SACLs 55 Safari 574 SAM 442 Sammlungssätze 963 Schattenredundanz 775, 859, 869 SCL-Werte Bedeutung 909 Einführung 888 Einzelne Postfächer 911 Transportregeln 913 Search-MessageTrackingReport 254 Seitenbeschädigungen 458 Select-Object 124 Sendeconnectors Adressraum 814, 817 Auswählen 820 Authentifizierung 818 Benutzerdefiniert 813 Berechtigungen 892 Berechtigungsgruppen 814 Bereich 816, 820 Edge-Synchronisierung 879 Eigenschaften 809 Einstellungen 818 Erstellen 813, 814 Maximale Nachrichtengröße 791 Quellserver 814, 818 Smarthost 817 Transporteinschränkungen 823 Verbindungskosten 816 Verknüpfung mit Empfangsconnectors 821 Verwalten 813 Senden als 319, 321 Senden im Auftrag von 319, 321 Sender ID 888, 902 Sender Policy Framework 902 Sender Reputation Level 898 Sendmail 805 Server Active Manager-Rolle 443 Aktualisieren 497, 511 Aus Datenbankverfügbarkeitsgruppen entfernen 509 Ausfall 498 Datenbankverfügbarkeitsgruppen 439 Externe SMTP-Server 803 IMAP4 602 Konfiguration prüfen 161 OAB-Generierung 756 Offline schalten 962 Smarthosts 815
991
Stichwortverzeichnis
Server (Fortsetzung) Vollständige Sicherung 550 Voraussetzungen für Datenbankverfügbarkeitsgruppen 474 Serverfehler 564 Service Packs 89 Set_Exchange2010Prereqs.ps1 72 Set-ActiveSyncOrganizationSettings 615 Set-ADSite 781 Set-ADSiteLink 780 Set-CalendarProcessing 293, 366, 581 Set-CASMailbox 568, 569 Set-ContentFilterConfig 912 Set-DatabaseAvailabilityGroup 476 Set-DatabaseAvailabiliyGroup 468 Set-DistributionGroup 263, 330, 333, 335 Set-DynamicDistributionGroup 341 Set-EdgeSyncServiceConfig 884 Set-EmailAddressPolicy 308, 312, 314 Set-EventLogLevel 270, 403, 755 Set-ExchangeServer 96 Set-ExecutionPolicy 159 Set-IMAPSettings 604 Set-Mailbox 135, 282 Set-MailboxAutoReplyConfiguration 291, 293 Set-MailboxCalendarConfiguration 293 Set-MailboxCalendarFolder 587 Set-MailboxDatabase 285 Set-MailboxFolderPermission 583 Set-MailboxJunkEmailConfiguration 295 Set-MailboxMessageConfiguration 294 Set-MailboxRegionalConfiguration 289, 291 Set-MailboxSpellingConfiguration 295 Set-MailContact 356 Set-OfflineAddressBook 751, 757 Set-OrganizationConfig 741 Set-OutlookProvider 560, 642 Set-OWAMailboxPolicy 596, 598 Set-OWAVirtualDirectory 289 Set-POPSettings 604 Set-PublicFolder 402 Set-PublicFolderDatabase 402 Set-ReceiveConnector 605, 790, 791, 802, 808 Set-RecipientFilterConfig 901 Set-RemoteDomain 581, 855 Set-RoleAssignmentPolicy 190 Set-RoleGroup 184 Set-RPCClientAccess 569, 646 Set-SendConnector 791, 820 Set-SystemMessage 843 Set-ThrottlingPolicy 627 Set-TransportConfig 786 Set-TransportServer 779, 813 992
Setupprotokolle 76 Set-User 282 Shadow Redundancy Manager 862 Sicherheit Adressumschreibung 916 Alte Postfächer 274 Anmeldeinformationen in Skripts 155 Antivirenprodukte 922 Authentifizierung für IMAP4 603, 606 Banner 808 Berechtigungsstruktur 43 BitLocker 413 Clientauthentifizierung 800 Clientseitige Schutzvorrichtungen 924 Code in Textdateien 600 Deaktivierte Links 928 Delegierung 116 Edge-Transport-Server 80 Einschränkungen für Administratoren 244 Empfängeranzeige auf Edge-TransportServern 882 Empfangsconnectors 802 Exchange Server 2010 auf einem Domänencontroller 67 Exchange Trusted Subsystem 67, 100 Gerätetypen blockieren 615 Konten zur Computerverwaltung 255 MAPI-Verschlüsselung 646 Mobile Geräte zurücksetzen 620 Nachrichtenhygiene 872 Phishing 888 Port für Verzeichnisverbindungen 680 Postfachregeln 244 Programm zur Verbesserung der Kundenzufriedenheit 85 Protokollierung des Betreffs 940 Rollenbasierte Zugriffssteuerung 171 Selbst signierte Zertifikate 230 Sicherheitsgruppen 96, 263 Skriptausführung 159 TLS 799 Verschlüsselung 413 Verschlüsselung in Datenbankverfügbarkeitsgruppen 477 Webbeacons 927 Webbugs 927 Zählpixel 927 Zertifikate 670 Sicherheitsgruppen 263 Sicherungen Assistent 533 Bandlaufwerke 43, 374 Datenbankverfügbarkeitsgruppen 491, 537
Stichwortverzeichnis
Sicherungen (Fortsetzung) Durchführen 533 Eeignisse 535 Einmalsicherung 533 Notwendigkeit 529 NTBACKUP 530 Passive Datenbankkopien 537 Transaktionsprotokolle abschneiden 533 Vollständige Serversicherung 550 Volumeschattenkopie-Dienst 532 Vorüberlegungen 528 VSS 531 Windows Server-Sicherung 530 Ziel 533 Sichten 379 SkipClientExperienceChecks 501 Skripts Aktivierung von Datenbanken sperren 512 Anführungszeichen 128 Anmeldeinformationen 155 Antispam-Agents installieren 887 Ausführen 145 Ausführungsrichtlinien 159 Ausgabe in CSV-Datei 152 Bereitgestellte Datenbanken 496 Berichterstellung über Antispamvorgänge 919 Cmdlet-Namen 119 CSV-Eingabedateien 296 Datenbankverfügbarkeitsgruppen 521 Debugging 129 Editor 128 Exchange Server 2007-Cmdlets zur Kalenderverarbeitung 366 Identitätsparameter 130 Initialisieren 147 Massenerstellung von Postfächern 295 Postfächer erstellen 280 Postfächer verschieben 703 Skriptumgebung 144 Variablen 127 Smarthosts 815, 817 Smartrelays 816 SMS-Nachrichten 609 Spam Antispam-Agents 886 Aufkommen 872 Clientseitiger Schutz 924 IP-Adressen 894 Junk-E-Mail-Filter 925 Junk-E-Mail-Ordner 911 Rücklauf 897 Zulassungs- und Blockierlisten 920 Speichergruppen 439
Speicherung in einer einzigen Instanz 379 Sperrlisten 920 Sperrlistenanbieter 895 Split-Brain-Syndrom 513 Sprache Cmdlet-Werte 158 E-Mail-Infos 745 Gebietsschema 287 OWA 286 Postfacheinstellungen 286 PST-Dateien 290 Sprachpakete 80 Systemnachrichten 843 Voicemail 629 Wechseln 288 SRL 898 SRV-Zeiger 658 SSL 671 SSL-Verschiebung 673, 682 Standorte Bereiche 651, 652 Edge-Transport-Server 876 Einführung 775 Hub-Standorte 781 Mit dem Internet verbunden 642 Standortmitgliedschaft 876 Standortübergreifende Verbindungen 662 Standortverknüpfungskosten 778, 779 Standortübergreifende Verbindungen 515 StartDagServerMaintenance.ps1 512, 523 Start-EdgeSynchronization 879, 884 Start-Transcript 139 Statische AutoErmittlung 657 STM 414 StopDagServerMaintenance.ps1 512, 523 Suche Discoverysuchpostfächer 316 Getrennte Postfächer 154 Prüfen 164 Transportprotokollsuche 938 Übermittlungsberichte 245 Umfangreiche Ordner 151 Verfolgungsprotokoll-Explorer 955 Support diagnostics 185 Suspend-MailboxDatabaseCopy 498 Suspend-Message 834 Suspend-MoveRequest 703 Switchover 443, 493, 498 Synchronisierungsprobleme 565 Systemmonitor ExPerfWiz 963 Leistungsindikatoren 959 Sammlungssätze 963 993
Stichwortverzeichnis
Systemnachrichten Anpassen 838 Benachrichtigungen über den Übermittlungsstatus 838 Generierung 828 Kontingentbenachrichtigungen 844 Speicherung 843 Sprache 843 Testen 843 Unzustellbarkeitsberichte 839 Systemzugriffssteuerungslisten 55
T Technology Adoption Program 36 Teergruben 901 Terminkonflikte 364 Test-ECPConnectivity 165 Test-EdgeSynchronization 880 Test-ExchangeSearch 164 Test-IMAP4Connectivity 166 Test-IPBlockListProvider 895 Test-MailFlow 166 Test-MAPIConnectivity 162 Test-MRSHealth 165 Test-OWAConnectivity 164 Test-POP3Connectivity 166 Test-PowerShellConnectivity 117 Test-ReplicationHealth 163 Test-ServiceHealth 162 Test-SystemHealth 161 Textnachrichten 609 Thunderbird 606 TLS 799 Tmp.edb 388 Tombstone-Wartung 401 Toolbox Detailvorlagen-Editor 933 Exchange Load Generator 2010 965 Inhalt 932 Leistungsproblembehandlung 962 Nachrichtenverfolgung 937 Remoteverbindungsuntersuchung 966 Systemmonitor 959 Verfolgungsprotokoll-Explorer 954 Warteschlangenanzeige 835 Topologieermittlung 54 Transaktionsprotokolle Abschneiden 455, 533 ACLL 448 Bei der Replikation ignoriert 453 Dateien 387 Datenbankseiten 455 994
Transaktionsprotokolle (Fortsetzung) Ein-/Ausgabe 429 Einführung 421 Einträge 426 Generationsnummer 427 Größe 422 Inkrementelle Neusynchronisierung 457 Interpretieren 426 Komprimieren 453 Postfächer verschieben 694 Protokollierung ohne Wiederverwendung 431 Protokollsätze 421 Prüfpunkt 427 Prüfsumme 428 Reservierte Protokolle 432 Speicherort 392 Speicherort verschieben 461 Speicherplatz knapp 433 Übermäßiges Wachstum 408 Umlaufprotokollierung 430, 455 Verknüpfung mit Datenbanken 423 Verzögerte Kopien 490 Warteschlangen 451 Wiedergeben 449 Transport-Agents 856 Transportkonfigurationsdatei 793 Transportpapierkorb 859 Transportpipeline 856 Transportregeln 235, 913 Troubleshoot-DatabaseLatencylps1 407 Troubleshoot-DatabaseSpace.ps1 409
U Übermittlungsberichte Administratoren 248 Aufbewahrung 249 Benutzer 245 Datenschutz 249 Erforderliche Rollengruppen 248 Exchange-Verwaltungsshell 254 Nachrichten an andere Benutzer 250 Verschobene Postfächer 249 Weiterleiten 253 Übermittlungsstatus 838 UDP-Problem 558 Umkreisnetzwerke 666 Umlaufprotokollierung Aktivieren 395 Datenbankkopien 482 Transaktionsprotokolle 456 Vor- und Nachteile 430 Warteschlangen 827
Stichwortverzeichnis
Unified Messaging 609, 627 Unscoped role management 186 Unterhaltungsansichten 560 Unzustellbarkeitsberichte Anpassen 842 Aufbau 840 Gründe 841 Nachricht an geschützte Gruppen 336 Umfangreiche Nachrichten 791 Update-EmailAddressPolicy 313 Update-FileDistributionService 756 Update-MailboxDatabaseCopy 488 Update-OfflineAddressBook 755 Update-SafeList 922
Verteilergruppen (Fortsetzung) Exchange-Systemsteuerung 257 Namenskonventionen 221 Organisationsweit 795 Vertrauensstellungen 226 Verzögertes Auffächern 781 View-Only Management 211 Viren Antivirusprodukte 922 Bedrohung 872 Voicemail 609, 628 Vollzugriffsberechtigung 322 Volumeschattenkopie-Dienst 532 VSS-Plug-In 530
V
W
Validierungsregeln 199 Verbindungsfilterung 888, 893 Verbindungsstatusaktualisierungen 864 Verbunddienste 226 Verbundvertrauensstellung 226 Verfolgungsprotokoll-Explorer 954 Verschiebungsanforderungen Abbrechen 713 Angehalten 711 Anzeigen 698 Erstellen 697 Exchange-Verwaltungsshell 702 Fehlerbehebung 721 Fortbestehende Anforderungen 722 Gesamtstrukturübergreifend 706 Grenzwert für ungültige Elemente 706, 721 Große Anzahl 699 Löschen 701 Planen 710 Stapelverarbeitung 704 Starten 703 Status prüfen 709 Verwalten 699 Zwischen Exchange-Versionen 706 Verschlüsselung BitLocker 413 Datenbanken 413 MAPI 646 Replikationsdatenverkehr 477 Routing 799 Zertifikate 671 Versionsnummern 92 Verteilergruppen Aufgliedern 795 Dynamisch 328 Einrichten 328
WAN-Optimierungscontroller 799 Warteschlangen Anhalten 835 Anzahl der Transaktionsprotokolle 451 Anzeigen 829 Nachrichten anhalten 834 Nachrichten anzeigen 833 Nachrichten freigeben 834 Nachrichten löschen 834 Namen 831 Nicht-erreichbar-Warteschlange 831 Problemwarteschlangen 832 Speicherort 827 Status 830 Transportwarteschlangen 826 Übermittlungswarteschlange 828, 867 Überwachen 867 Umlaufprotokollierung 827 Warteschlange für nicht verarbeitete Nachrichten 831 Warteschlange geringer Priorität 869 Warteschlangenanzeige 835 Zu moderierende Nachrichten 353 Zustellungswarteschlangen 829 WCF 634 Webbeacons 927 Webbugs 927 WebDAV 634 Webdienste 634, 681 Webparts 573, 581 WebReady Document Viewing 598 Wiedergabeverzeichnis 828, 838 Wiederherstellung Aufräumen 550 Datenbanken bereitstellen 543 Datenbanken überprüfen 542 995
Stichwortverzeichnis
Wiederherstellung (Fortsetzung) Datenbanken überschreiben 542 Dial-Tone 545 Durchführen 539 ESEUTIL 542 Gelöschte Elemente 538 Notfallwiederherstellung 493 Postfächer 546 Server 81 Transportpapierkorb 783, 859 Verzögerte Kopien 490, 493 Wiederherstellungsdatenbank 538 Windows Mobile 609 Windows PowerShell Active Directory-Modul 148 Anführungszeichen 128 Ausführlicher Modus 158 Ausführungsrichtlinien 159 Ausgabe weiterleiten 132 Codeänderungen 44, 142 Dienste starten 602 Einführung 102 Einschränkungsrichtlinie 626 E-Mails senden 154 Exchange-Verwaltungskonsole 216 Fehler beim Remotezugriff 112 Filter 136 HTML-Berichte 153 Informationen über Dienste abrufen 89 Integrierte Skriptumgebung 144 Langsamer Start 117 Leistung messen 117 OPATH-Abfragen 136 Parametertypen 123 Pipelines 143 Registrierte Module 113 Remotezugriff 105, 107 Rollenbasierte Zugriffssteuerung 109 Skripts debuggen 129 Speichergrenzen 137 Tastaturbefehle 121 Variablen 127 Vervollständigung der Eingabe 122 Vorteile des Remotezugriffs 116 Windows-Features hinzufügen 71 Windows Server 2008 Editionen 39 Features hinzufügen 71 Komponenten installieren 72 R2 69 RODC 59
996
Windows Server-Sicherung 530 Windows-Zertifikatdienste 230 WinRM 116 WinRM QuickConfig 114 WOC 799 WSBExchange.exe 530 WSMan 112 WS-Verwaltungsdienst 114
X X.400 786 X.509 229 X-Header 414, 889 XML-Installationsdateien 70 Xobni 965 XSO-Schicht 784
Z Zählpixel 927 Zeitplanassistent 767 Zeitpläne für Assistenten 771 Zertifikate Anfordern 232, 672 Anzahl 671 Clientzugriffsserver 671 Drittanbieter 671 Exchange-Verwaltungskonsole 231 Externe Verbindungen 671 Infrastruktur für öffentliche Schlüssel 230 Kommerziell 230 Outlook 2010 230 Protokolle 229 Public Key Infrastructure 230 Selbst signiert 229 SSL 671 TLS 799 Typen 229 Windows-Zertifikatdienste 230 X.509 229 Zugriffsregeln 617 Zugriffssteuerungslisten 338 Zulassungslisten 920 Zustellungsconnectors 858 Zustellungsoptionen 319 Zustellungswarteschlangen 829 Zwei-Phasen-Commit 421
Recommend Documents
Thomas Joos: Microsoft Outlook 2010 – Das Handbuch Copyright © 2010 O'Reilly Verlag GmbH & Co. KG
Das in diesem Buch e...
From the Library of Lee Bogdanoff
Rand H. Morimoto, Ph.D., MCITP Michael Noel, MVP, MCITP Chris Amaris, MCSE Andrew Ab...
From the Library of Lee Bogdanoff
Rand H. Morimoto, Ph.D., MCITP Michael Noel, MVP, MCITP Chris Amaris, MCSE Andrew Ab...
Bill English und die Experten der Microsoft SharePoint-Community
Microsoft Office SharePoint Server 2007 – Das Handbuch...
PUBLISHED BY Microsoft Press A Division of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399 Copyr...
PUBLISHED BY Microsoft Press A Division of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399 Copyr...
Wojciech Micka: Microsoft SharePoint 2010 für Administratoren – Das Handbuch Copyright © 2011 O'Reilly Verlag GmbH & Co...
Microsoft Exchange 2010 PowerShell Cookbook Manage and maintain your Microsoft Exchange 2010 environment with Windows P...
Sign In
Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close
