Exchange Fragen & AntwortenOWA-Timeouts, Cmdlet-Problembehandlung und mehr

KC Lemson and Nino Bilic

F: Wir haben vor kurzem von Exchange Server 2003 auf Exchange Server 2007 migriert. Jetzt erhalten wir Beschwerden, dass bei Outlook® Web Access (OWA) Timeouts für Benutzer mit eingeschränktem Zugriff auftreten, die bei der Anmeldung bei OWA 2007 die Option „Dies ist ein privater Computer“ ausgewählt haben. Wie lautet der entsprechende Befehl der Exchange-Verwaltungsshell zur Überprüfung des Timeouts für private Computer?

A: Lassen Sie uns langsam an das Problem herangehen. Zuerst muss erläutert werden, warum es eine getrennte Auswahl zwischen einem privaten Computer und einem öffentlichen Computer gibt (siehe Abbildung 1) und worin sich das Verhalten dieser Optionen unterscheidet. Diese Optionen sollen dem Benutzer die Möglichkeit geben, Exchange mitzuteilen, welche Sicherheitsstufe erforderlich ist – d. h. ob der Benutzer sich beispielsweise über einen öffentlichen Kiosk am Flughafen oder über den Computer zu Hause bei OWA anmeldet. Der Exchange-Administrator kann diese Sitzungstypen wahlweise unterschiedlich behandeln. So kann der Administrator beispielsweise einen kürzeren Timeoutwert für authentifizierte Sitzungen auf öffentlichen Computern (z. B. Timeout nach wenigen Minuten) als auf privaten Computern (Timeout nach maximal drei Tagen) festlegen. Der Administrator kann auch andere Einstellungen abhängig von der Auswahl des Benutzers unterschiedlich konfigurieren. Beispielsweise könnte der Administrator festlegen, dass der Zugriff auf SharePoint®-Dokumentbibliotheken und Windows®-Dateifreigaben nur bei der privaten Anmeldung gestattet ist. Natürlich ist es dazu erforderlich, dass der Benutzer die richtige Option angibt. Wenn sich der Administrator nicht darauf verlassen kann, dass die Benutzer die richtige Entscheidung treffen, können sie jeder Option dieselben Timeoutwerte und weitere Konfigurationsoptionen zuweisen.

Abbildung 1** Unterschiedliche Timeouteinstellungen und weitere Konfigurationsoptionen für öffentliche und private Computersitzungen **(Klicken Sie zum Vergrößern auf das Bild)

Die betreffende Option wurde von Exchange 2003 übernommen. Bei dieser Version wurde die formularbasierte Authentifizierung erstmals in OWA eingeführt. (Ein geschichtlicher Hinweis: Die erste Implementierung der formularbasierten Authentifizierung wurde zum Teil von einer brillanten Programmmanagerin entworfen. Ich werde ihre Identität nicht preisgeben, aber ich kann Ihnen sagen, dass sie es später als Verfasserin einer alle zwei Monate erscheinenden Rubrik des TechNet Magazins zu Ruhm und Ansehen gebracht hat.)

Die Einstellung wird in der Registrierung gespeichert. Da Windows PowerShell™ jedoch über eine Schnittstelle zur Aktualisierung der Registrierung verfügt, können Sie diese Einstellung mit der Exchange-Verwaltungsshell konfigurieren. Im folgenden Beispiel wird ein Timeoutwert von 1440 Minuten oder einem Tag festgelegt, wenn Benutzer bei der Anmeldung die Option des privaten Computers auswählen:

set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout 
-value 1440 -type dword

Da die Einstellung in der Registrierung gespeichert wird, können Sie den Schlüssel natürlich auf Wunsch auch selbst mit regedit aktualisieren:

#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>

In beiden Fällen müssen Sie IIS neu starten, um sicherzustellen, dass OWA die neue Einstellung übernimmt. Sie können diesen Neustart durch Auswahl von „Start“ | „Ausführen“ und anschließende Ausführung von „iisreset /noforce“ durchführen.

F: Wir empfehlen allen Mitarbeitern, die den Outlook-MAPI-Client verwenden, alle nicht dringend benötigen Elemente in persönlichen Ordnerdateien (PST-Dateien) zu archivieren. Die archivierten Elemente sind jedoch nicht verfügbar, wenn sich Benutzer von zu Hause aus bei Outlook Web Access anmelden. Wie können wir diese PST-Dateien über die OWA-Schnittstelle verfügbar machen?

A: Leider unterstützt OWA den Zugriff auf PST-Dateien nicht. OWA wurde als reiner Onlineclient von Grund auf neu entwickelt. Wir haben viel Arbeit investiert, um sicherzustellen, dass keine Spuren persönlicher Daten auf dem lokalen Computer verbleiben – hierzu gehören Features wie der erstmals in Exchange 2003 verfügbare sichere Abmeldemechanismus und der WebReady Document Viewing-Dienst in Exchange 2007, der gewährleistet, dass keine zwischengespeicherten Kopien von Anlagen auf der Festplatte verbleiben. Daher passt der Zugriff auf PST-Dateien über OWA nicht zu unserem Ziel, OWA als einfach bereitzustellenden reinen Onlineclient anzubieten.

Andererseits ist die Verwendung von PST-Dateien im Allgemeinen ein interessantes Szenario, auf das näher eingegangen werden sollte. Im letzten Herbst fand ein Gespräch mit einem Kunden statt, bei dem die Benutzer Postfachkontingente von ca. 200 MB hatten und beinahe jeder Benutzer über eine oder sogar mehrere PST-Dateien verfügte. Da es in dieser Organisation eine Richtlinie gab, die es ermöglichte, mit minimalem Aufwand alle Daten auf den Computern von Benutzern zu löschen und Computer zu ersetzen, mussten alle Benutzer ihre PST-Dateien auf einer Netzwerkfreigabe speichern. Diese Netzwerkfreigabe wurde wiederum von einem zentralen System gesichert.

Allerdings gibt es bekannte Probleme, wenn von Netzwerkfreigaben auf PST-Dateien zugegriffen wird. Genau wie OWA von Anfang an als reiner Onlineclient konzipiert wurde, waren PST-Dateien ursprünglich nur für die lokale Speicherung vorgesehen. Unabhängig davon, wie leistungsstark Ihr Netzwerk ist, treten Wartezeiten und andere Probleme auf, aufgrund derer sich die Remotespeicherung von Daten (und der gleichzeitige Benutzerzugriff) als schwierig erweisen kann.

Darüber hinaus hatte diese Organisation ein eher kleines Postfachkontingent (nicht jeder genießt den Luxus eines Unternehmenspostfachs mit einer Größe von ca. 2 GB), da diese Daten nicht alle in Exchange gespeichert werden sollten – ansonsten wäre die Organisation nämlich für die Sicherung aller dieser Daten verantwortlich gewesen. Da die Benutzer die Daten in PST-Dateien auf einer Netzwerkfreigabe speicherten, die gesichert wurde, war der Arbeitsaufwand für die Administratoren dennoch nicht wirklich geringer. Tatsächlich fiel aufgrund verschiedener Faktoren wahrscheinlich mehr Arbeit an. Hierzu zählten z. B.: keine Single Instance Storage-Funktion für mehrere PST-Dateien, durch Probleme mit PST-Dateien (wie vergessene Kennwörter und allgemeine Netzwerkprobleme) anfallende Helpdeskkosten, Schwierigkeiten beim Bereinigen von Nachrichten in PST-Dateien nach einem Virenangriff, Probleme bei einer aus rechtlichen Gründen erforderlichen Suche nach Nachrichten in PST-Dateien, Zusatzaufwand für die Verwaltung eines anderen Sicherungssystems usw.

Daher empfehlen wir Ihnen nachdrücklich, sämtliche Kosten zu berücksichtigen, die aufgrund von Konfigurationsentscheidungen anfallen können. Unter Umständen summieren sich die Kosten, sodass letzten Endes eine andere Konfiguration die bessere Wahl ist.

F: Ich habe ein Problem mit einem Befehl der Exchange-Verwaltungsshell. Er funktioniert einfach nicht. Woran liegt das?

A: Diese Frage ist schwierig zu beantworten. Ein Ratschlag als Hilfestellung wäre der folgende: Protokollieren Sie die von Ihnen verwendeten Befehle sowie die jeweiligen Ergebnisse mit dem in Windows PowerShell integrierten Cmdlet „start-transcript“. Anschließend können Sie die genauen Details in eine E-Mail-Nachricht, einen Blogbeitrag oder eine Frage in einem Forum einfügen.

Öffnen Sie eine Sitzung der Exchange-Verwaltungsshell, und geben Sie wie in Abbildung 2 dargestellt „start-transcript“ ein. Die Exchange-Verwaltungsshell protokolliert daraufhin automatisch alle zukünftigen Befehle in einer Textdatei wie der in Abbildung 3 (keine Sorge, der Speicherort der Textdatei wird Ihnen von der Anwendung mitgeteilt). Zum Beenden der Protokollierung geben Sie einfach „stop-transcript“ ein.

Abbildung 2** Protokollieren der von Ihnen verwendeten Befehle und der entsprechenden Ergebnisse mit dem Cmdlet „start-transcript“  **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 3** Windows PowerShell speichert ein Protokoll der von Ihnen verwendeten Befehle in einer TXT-Datei **(Klicken Sie zum Vergrößern auf das Bild)

Die vollständige Liste der von Ihnen verwendeten Befehle und der zurückgegebenen Ergebnisse stellt für jeden, der an der Behebung Ihres Problems arbeitet, eine enorme Hilfe dar. Bevor Sie das Protokoll jedoch an unbekannte oder nicht vertrauenswürdige Personen weitergeben, sollten Sie es unbedingt auf eventuell zurückgegebene vertrauliche Daten prüfen.

F: Ich habe festgestellt, dass bei der Installation von Exchange 2007 eine neue Organisationseinheit in der Stammdomäne erstellt wird. Sie trägt den Namen „Microsoft Exchange-Sicherheitsgruppen“ und enthält fünf neue Sicherheitsgruppen von Exchange 2007. Ist es möglich, diese Gruppen in eine andere Organisationseinheit zu verschieben? Oder in eine andere Domäne?

A: Diese Frage bezieht sich auf fünf universelle Sicherheitsgruppen (USGs), die während der Active Directory-Vorbereitungsphase in der Stammdomäne erstellt werden. Bei diesen Gruppen handelt es sich um:

• Exchange-Organisationsadministratoren
• Exchange-Empfängeradministratoren
• Exchange-Administratoren mit Leserechten
• Exchange-Server
• ExchangeLegacyInterop

Bei Exchange 2000 und Exchange 2003 waren die Möglichkeiten zum Verschieben der Standardsicherheitsgruppen (Exchange Domain Servers und Exchange Enterprise Servers) begrenzt. Anders ausgedrückt, sie konnten zwar verschoben werden, aber dabei wurden bestimmte Elemente beschädigt. (Weitere Informationen zu diesem Problem finden Sie unter support.microsoft.com/kb/260914). Daher war diese Möglichkeit tatsächlich sehr eingeschränkt.

In Exchange 2007 sieht die Situation anders aus. Es ist möglich, die fünf Standardgruppen zu verschieben. Sie können in eine andere Organisationseinheit in derselben Domäne oder in eine andere Domäne verschoben werden.

Falls diese fünf Gruppen einmal „verloren gehen“ und Sie nicht wissen, wohin Sie sie verschoben haben – d. h. in welche Organisationseinheit oder Domäne – können Sie den Wert des otherWellKnownObjects-Attributs im folgenden Container prüfen:

CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com

Wenn Gruppen verschoben werden, wird ihr Speicherort in diesem Attribut aktualisiert, wodurch Sie stets herausfinden können, wo sich die Gruppen befinden. Äußerst praktisch!

F: Ich habe eine globale Sicherheitsgruppe namens „Exchange Install Domain Servers“ in meiner Domäne gefunden. Welchem Zweck dient sie?

A: Sie beobachten Ihr Active Directory® wirklich genau. Tatsächlich gibt es in jeder Domäne, in der Exchange 2007-Server installiert wurden, eine Gruppe namens „Exchange Install Domain Servers“. Diese Gruppe wird in der Organisationseinheit „Microsoft Exchange-Systemobjekte“ (MESO) erstellt. Wenn Sie sich diese Gruppe näher ansehen, werden Sie feststellen, dass sie der Exchange Servers-Gruppe der Stammdomäne als Mitglied zugewiesen wird, bei der es sich um eine universelle Sicherheitsgruppe handelt.

Kurz gesagt ist „Exchange Install Domain Servers“ eine Gruppe, die zur Umgehung möglicher langer Active Directory-Replikationszyklen verwendet wird, wenn Sie das Setup von Exchange 2007 in einer Ihrer untergeordneten Domänen ausführen. Angenommen, Sie verfügen über eine Stammdomäne namens „Stamm“, eine untergeordnete Domäne namens „Kind“ und eine untergeordnete Domäne von „Kind“ namens „Enkel“. (Sie müssen zugeben, dass die Namensgebung brillant ist! Als Nächstes meinen Sie wohl, dass Sie unsere Kennwörter erraten können.)

Um mit der Einrichtung von Exchange 2007 in dieser Organisation zu beginnen, müssen Sie zuerst das Schema erweitern und die Stammdomäne vorbereiten. Dadurch werden die fünf ursprünglichen USGs erstellt, die in der vorhergehenden Antwort erörtert wurden.

Angenommen, Sie müssen dann das Setup in der Domäne „Enkel“ ausführen. Um die Dienste von Exchange 2007 in der lokalen Domäne starten zu können, fügt das Setupprogramm ein Computerkonto des Exchange 2007-Computers in die Gruppe „Exchange-Server“ aus der Stammdomäne ein. Da Sie jedoch jetzt in der Domäne „Enkel“ arbeiten, kann es eine Weile dauern, bis die Mitgliedschaft in der Gruppe „Exchange-Server“ repliziert wird.

„Exchange-Server“ ist eine universelle Gruppe, deren Mitgliedschaft überall in der Gesamtstruktur repliziert wird. Aufgrund potenzieller Replikationswartezeiten ist es möglich, dass beim Setup in der Domäne „Enkel“ bestimmte Dienste nicht gestartet werden, weil zum Zeitpunkt des Setups die Berechtigungen noch nicht repliziert wurden. Aus diesem Grund wird bei der Einrichtung des ersten Exchange 2007-Servers in einer Domäne die Gruppe „Exchange Install Domain Servers“ in der lokalen Domäne erstellt.

Das Exchange-Computerkonto wird im Rahmen des Setups dieser Gruppe als Mitglied hinzugefügt. Durch eine Mitgliedschaft in dieser Gruppe erhalten Dienste ausreichende Berechtigungen für den Start am Ende des Setups, selbst wenn die Mitgliedschaft der Gruppe „Exchange-Server“ noch nicht von der Stammdomäne repliziert wurde. Beachten Sie, dass die Replikation in der lokalen Domäne in der Regel schneller erfolgt als die Replikation zwischen Domänen.

Q In der Dokumentation zu Exchange 2007 heißt es, dass ich das Setup mit dem Befehlsschalter „/PrepareLegacyExchangePermissions“ ausführen sollte, noch bevor ich das Schema für Exchange 2007 erweitere. Aus welchem Grund? (Hätte für den Schalter nicht noch ein längerer Name gefunden werden können?)

A: Es freut uns zu hören, dass Sie die Dokumentation lesen, bevor Sie das Setup ausführen. Wie gefällt sie Ihnen?

Durch den Schalter „/PrepareLegacyExchangePermissions“ (oder kurz „/pl“) erhalten die Empfängeraktualisierungsdienste (Recipient Update Services, RUS) von Exchange 2000 und Exchange 2003 die Berechtigung, in die Eigenschaftensätze „Exchange-Informationen“ und „Persönliche Informationen“ zu schreiben. Während des Schemaerweiterungsprozesses von Exchange 2007 werden mehrere Attribute (z. B. Proxyadressen) aus dem Active Directory-Eigenschaftensatz „Öffentliche Informationen“ in den Eigenschaftensatz „Exchange-Informationen“ verschoben. Die Empfängeraktualisierungsdienste von Exchange 2000 und Exchange 2003 sind standardmäßig nicht berechtigt, in den Eigenschaftensatz „Exchange-Informationen“ zu schreiben. In der Realität bedeutet dies Folgendes: Wenn Sie Ihre Schemaerweiterung für Exchange 2007 zuerst ausführen, zerstören Sie die Empfängeraktualisierungsdienste von Exchange 2000 und Exchange 2003, da sie dann keine neuen Empfänger mehr mit einem Stempel versehen können! (Weitere Informationen zu diesen Eigenschaftensätzen finden Sie in unserem Blog unter msexchangeteam.com.)

Daher ist es äußerst wichtig, dass Sie den Schalter „/pl“ ausführen, bevor das Schema für Exchange 2007 erweitert wird. Sie sollten zudem sicherstellen, dass diese Änderung in allen Domänen repliziert wird, die über Exchange 2000- oder Exchange 2003-Empfänger verfügen (damit Empfängeraktualisierungsdienste für diese Domänen vorhanden sind.) Wenn der Gesamtstruktur zu einem späteren Zeitpunkt neue Domänen hinzugefügt werden und Sie Empfängeraktualisierungsdienste von Exchange 2000 oder Exchange 2003 in diese Domänen einfügen müssen, sollten Sie den Schalter /pl in diesen Domänen ebenfalls ausführen.

Bei der ersten Ausführung des Schalters „/pl“ wird der Vorgang zudem stark vereinfacht, wenn Sie den Schalter mit einem Konto ausführen, das über Unternehmensadministratorrechte verfügt. Dann wird beim Setup von der Stammdomäne aus erkannt, für welche Domänen „/pl“ ausgeführt werden muss, und der Schalter „/pl“ wird für alle diese Domänen ausgeführt. Wenn Sie kein Unternehmensadministratorkonto verwenden, müssen Sie den Schalter „/pl“ unter Verwendung eines Domänenadministratorkontos für jede Domäne einzeln ausführen. Erfreulicherweise werden in der Dokumentation zu Exchange 2007 alle erforderlichen Berechtigungen beschrieben.

Sie haben uns auch gefragt, ob wir keinen längeren Namen für diesen Schalter finden konnten. Versuchen Sie einmal, /PrepareLegacyExchangePermissions dreimal schnell hintereinander zu sagen:

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

Wir beabsichtigten zunächst, den Schalter „/PrepareLegacyExchangePermissionsOH­DiesIstEinWirklichLangerName“ zu nennen, haben uns aber dann für den kürzeren und praktischeren Namen „/PrepareLegacyExchangePermissions“ entschieden.

Okay, das war nur ein Witz. Sie können jedoch gern die kürzere Form „/pl“ verwenden. Und das ist kein Witz – Ehrenwort!

KC Lemson ist User Experience Manager für Exchange Server. In ihrer Freizeit wartet sie auf E-Mails mit Empfehlungen dazu, wie sie das Geld für die Ausbildung ihrer Kinder anlegen soll.

Nino Bilicist Technical Lead für Exchange Server. Er beschäftigt sich damit zu testen, wie oft er es sich an einem normalen Arbeitstag erlauben kann, „Halo“ zu spielen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.