Hosting:Technik

Dieser Abschnitt betrifft alle, die die Funktion von Exchange 2000/2003/2007/2010 für ihre Kunden oder Mitarbeiter anbieten wollen, aber die betreffenden Benutzer benutzen nicht das Active Directory Konto im gleichen Forrest wie Exchange. Sie betreiben Exchange quasi als "Application Service Provider" Dies trifft auf folgende Fälle zu:

Aktuelle Meldung:
Future of /Hosting Mode
http://blogs.technet.com/b/exchange/archive/2011/10/13/future-of-hosting-mode.aspx

Anmeldung

Für die "Anmeldeseite" muss natürlich auch eine Lösung gefunden werden. Ein Exchange Postfach muss ein Active Directory Konto haben, damit Exchange damit arbeiten kann. Das muss aber nicht das Anmeldekonto sein. Es gibt durchaus andere Möglichkeiten sich an einem Postfach zu Authentifizieren.

  • NT4 Anmeldedomäne/Samba
    Ihre Anwender nutzen eine Windows NT4 Domäne zur Anmeldung aber sollen ein Postfach auf Exchange 2000 erhalten. Dieser Fall ist häufig, wenn die eigentliche Benutzerdomäne noch nicht migriert ist. Siehe auch Exchange 2000 mit NT4.
  • Mehrere Forrests
    Sie haben mehrere Forrests im unternehmen oder Konzern weil sie nicht alle Abteilungen oder Teilfirmen unter einen Hut bekommen haben oder durch Firmenzukäufe zu weiteren Forrests gekommen sind.
  • Exchange Ressourceforest
    Oftmals ist die Erweiterung eines bereits in der Firma umgesetzten Active Directory System um das Exchange Schema und die weitgehenden Rechte von Exchange Servern und Administratoren nicht mit der Benutzer und Serveradministration unter einen Hut zu bringen. Dann ist vielleicht ein eigener Ressourceforest für Exchange sinnvoll.
  • Keine Windows NT Benutzer
    Im schlimmsten Falle haben die zukünftigen Anwender überhaupt kein Windows NT-Konto in einer vertrauten Domäne, einem vertrauten Forrest oder dem Exchange Forrest. Auch dann muss eine Lösung geschaffen werden.

All diese Umfelder sind mit Ausnahme des NT4-Domänenszenarios sehr komplex und können im Rahmen einer FAQ-Seite nicht vollständig beschreiben werden. Wer Exchange 2000 in einem umfangreicheren Feld einsetzen möchte, ist gerne eingeladen im Rahmen eines Projekts mit mir Zusammen eine Lösung zu erarbeiten. (->Kontakt). Als Einstieg können folgende Informationen dienen.

Was bedeutet "Hosting Exchange" ?

Als Hosting von Exchange betrachte ich all die Einsatzfälle. Bei denen der Forest mit Exchange nicht mit der Anmeldedomäne identisch ist. Ich spreche dann von einem "Exchange Ressourcen Forrest", d.h. einem Active Directory, welches allein für den Betrieb von Exchange installiert wird. Von der Installation selbst ist dies natürlich ein ganz normales Active Directory mit Domaincontrollern und Exchange Servern. Nur bei der Nutzung durch die Anwender gibt es unterschiede: Es lassen sich zwei grundlegende Modelle unterscheiden:

  • Internes Hosting
    Ihr Kunde ist die eigene Firma bzw. Firmen aus dem Firmenverbunde, für die Sie zentral das Messaging koordinieren aber die Verwaltungshoheit über die Anwender bei den einzelnen lokalen Administratoren liegen. Beispiele hierzu könnten große Konzerne sein. Die primäre Anwendung dürfte dank ausreichend schneller "private" Leitungen und bekannter Clients (meist nicht Internet) Outlook sein.
    Die Anwender melden sich an anderen Domänen an, z.B.: einem anderen Windows 2000/2003 Forest, an einer NT4 Domäne oder wegen mir auch an einem SAMBA-Server. Damit der Anwender nun ein Exchange Postfach nutzen kann, müssen Sie in ihrem Exchange Forest ebenfalls einen Benutzer anlegen. Aber dieses Konto wird "disabled". Wenn das der Fall ist, dann können Sie bei dem deaktivieren User das eigentliche Benutzerkonto des Anwender als "Berechtigt" eintragen (Siehe auch Exchange 2000 mit NT4). Damit das funktioniert, muss natürlich ihr "Exchange Forest" den anderen Domänen "vertrauen" und die Namensauflösung muss auch sichergestellt sein. Insofern ist dies eine Anbindung, die nur bei ziemlich enger Netzkopplung funktioniert.
  • Externes Hosting
    Ihr Kunde sind meist Einzelpersonen, kleine Firmen oder als ASP auch mittlere Firmen, für die Sie als externe Firma und Dienstleister das Messaging betreiben. Die Kunden erhoffen sich Kosteneinsparungen durch weniger Server und Wartung, einen stabileren Betrieb und weniger eigene Administration. D.h. Sie betreiben die Funktion "Mail" aber nutzt keine Verbindung zu einem bereits bestehenden Verzeichnisdienst der Anwender. In der Regel gibt es außer POP3, SMTP, IMAP4, RPC over HTTP keine Durchgängigkeit von Protokollen. Ein Trust ist nicht möglich. Auch hier kann der Mitarbeiter dann "Mail" nutzen aber muss sich erneut mit einem anderen Benutzernamen und Kennwort anmelden. Ein "Single Sign On" wie beim internen Hosting mit Vertrauensstellungen ist dabei nicht möglich. In diesem Fall sind die Benutzer im "Exchange Forest" allerdings aktiviert, da sich sonst der Anwender nicht anmelden kann. Über Firewalls wird aber dann sicher gestellt, dass der Anwender die Zugangsdaten nicht nutzt, um auf die Server über andere als die erlaubten Protokolle zugreifen.
    Der Client ist hier meist ein Webbrowser, POP3/IMAP4 oder in einigen Fällen auch Terminal Dienste. Manchmal ist auch Outlook über VPN im Einsatz

In beiden Fällen ist aber der Betrieb von Exchange von der sonstigen Infrastruktur (Mal abgesehen von Netzwerkverbindungen und Namensauflösung etc.) weitgehend unabhängig.

Der Vollständigkeit halber sei erwähnt, dass Sie natürlich auch innerhalb eines Forests auch eine eigene Domäne für Exchange installieren können. Allerdings ist diese Installation genau zu prüfen, da Sie dann in ihrem Forest jeden Benutzer zweimal angelegt haben. Einmal als aktives Konto für die Anmeldung am PC, die Nutzung von Freigaben etc. Und ein zweites Mal als "deaktiviertes" Konto mit den Exchange Eigenschaften, auf die das andere Konto Postfachrechte erhalten hat. Es gibt nur wenige spezifische Vorteile, die solche eine Installation hat aber im globalen Katalog sind alle Benutzer doppelt.

Technische Hintergründe

Domänen und Forests

Gehen wir von der folgenden Situation aus:

  • Forrest 1
    Dies ist der Forrest, mit einer Domäne, in der alle Exchange 2000 Server stehen und demnach auch die Benutzerobjekte z.B. in verschiedenen OU's angelegt werden.
  • Forrest 2 bis n
    Dies sind weitere Kundenforests, d.h. Domänen, in denen ebenso Benutzer angelegt sind, die aber aktiv für die Windows Anmeldung genutzt werden
  • NT4-Domain 1-xxx
    Einige Kunden haben vielleicht noch Windows NT 4.0 Domänen, aber benötigen Zugriff auf eine Exchange 2000 Mailbox

Trust:

Der Exchange Forrest vertraut nun allen Kundendomänen (NT4 wie auch W2K) einseitig, d.h. die Server in der Exchange Domäne können auf die Benutzerliste der anderen Domänen lesend zugreifen. Ein Trust in anderer Richtung ist nicht notwendig, es sei denn die Kundendomänen würden die Verteiler von Exchange, die ebenfalls Sicherheitsgruppen sind, zur Rechtevergabe nutzen wollen.

Aber erst mit Windows 2003 ist es möglich, dass sich Forests vertrauen. Bis dahin muss man wirklich zu JEDER Domäne mit Mailanwendern einen Trust einrichten.

Abwägung der Vor und Nachteile

Punkt für einen eigenen Forrest für Exchange als ASP:

  • Schema im eigenen Forrest, d.h. Schema des "Kunden" wird nicht angegriffen
  • E2K Administratoren sind "alleine, d h. kein anderer ist Organisations- bzw. Enterprise Administratoren. man ist nicht "untergeordnet" zu einer AD-Administratorabteilung
  • GC und Schema des E2K Forrest enthält nur "Standard" + Exchange 2000
    d.h. wenn Kunden eigene Produkte "AD-integriert" addieren, betrifft das nicht Exchange.
  • Backup und Restore ist getrennt vom Kunden
  • keine Probleme mit Verteilern als "Sicherheitsgruppen", da Kunden diese nicht verwenden können. (einseitiger Trust)
  • AD kann im "Provider Mode" gefahren werden, d.h. OU mit Rechte sehr zu machen, dann kann man je Kunde eigene "Adressansichten" machen etc.

Aber:

  • kein "Abgleich von Verteilern, d.h. doppelte Pflege von Benutzern und Verteilern
  • keine "Synergieeffekte"
  • Deaktivierte Kundenbenutzer in der E2K Domain erzeugen Meldungen des Eventlogs.
  • man brauch ein OU-Konzept für die Kunden mit gegenseitiger "Abschottung", damit Kunden nur sehen, was sie sehen dürfen
  • Administratoren des Kunden können selbst nichts Pflegen (Keine Mailadressen etc.)
  • Man braucht eigentliche etwas wie Mediendienste oder andere Dienste als "Replikation"
  • Zusätzliche Hardware für GC, DNS, Domaindienste
  • Höhere Integration und Automatismus bedeutet den Einsatz von Replikationssoftware zwischen den Verzeichnisdiensten (z.B.: MMS)

Das sind nur einige der Punkte, die es dabei zu beachten gibt. Weitere Informationen finden Sie z.B. auch auf:

Oder nutzen die das Leistungsangebot Net at Work.

Offene Fragen

Wenn Sie nun aber Exchange aus der Hand geben und damit vielleicht mit vielen Firmen bei einem Hoster die gleiche Infrastruktur nutzen bzw. in einem eigenen Forrest auslagern, dann stellen sich fragen, die beim Betrieb in der eigenen Domäne nie gestellt werden:

  • Sichtbarkeit der Empfänger
    Speziell wenn beim externen Hosting viele Firmen in einer Organisation zusammengefasst sind, verbietet sich die Bereitstellung eines globalen Adressbuchs. Ein solches Adressbuch ist zwar für die Exchange Server erforderlich, aber die Anwender sollten dies nicht nutzen können. (-> Berechtigungen setzen)
  • Firmenspezifische Adresslisten
    Exchange erlaubt benutzerdefinierte Adresslisten zu pflegen. Allerdings sind diese Listen "global". Als Kunde eines Hosters werden Sie daher meist keine eigenen Adresslisten z.B. nach Abteilung anlegen können. Das gleiche gilt auch für abfragebasierte Verteilergruppen. QBDG Verteiler
  • Pflege der Benutzerdaten
    Ein Konto ist schnell angelegt, aber erst wenn auch die Adresse, Telefonnummer etc. gepflegt wird, wird aus dem Exchange Adressbuch eine Adressdatenbank. Es ist mühselig, wenn Sie solche Daten nicht importieren können, sondern eintippen müssen.
  • Kennwort zurücksetzen
    Wie können Sie z.B.: beim externen Hosting das Kennwort eines solchen Kontos wieder zurücksetzen ?
  • Grenzwerte
    Einige Begrenzungen von Exchange (Maximale Nachrichtengröße etc.) sind nur organisationsweit zu regeln. Entspricht dies ihren Anforderungen ?
  • Mailrouting
    Exchange erlaubt die Anbindung von verbundenen Firmen über eigene SMTP-Connnectoren mit entsprechendem Adressraum. Das funktioniert natürlich nur in ihrer eigenen Umgebung. Ein Hoster wird sicher nicht eine VPN-Verbindung zu "ihrem" Partner aufbauen, damit Mails dort hin mit anderen Prioritäten und Größen übertragen werden können. Schließlich würde diese Einstellung für alle anderen Firmen ebenfalls gelten.

Dies sind nur einige Fragen, die bei einem Hosting beantwortet werden müssen. Die meisten Anbieter stellen für viele Funktionen eine angepasste Weboberfläche bereit, mit der Sie die verschiedenen Aktionen durchführen können. Allerdings sollten Sie als Anbieter und Kunden prüfen, ob diese Oberfläche den Anforderungen gerecht wird.

Fragen rund um Hosting

Hier die wichtigsten Fragen beim Betrieb mehrerer Firmen in einer Organisation.

Eine ausführliche technische Beschreibung finden Sie auf MSXFAQ.de - HostingHowTo

ACHTUNG: Alle bisherigen Beschreibungen zum Einrichten von Hosting mit Deaktivieren von Vererbungen etc. sind veraltet und nicht mehr unterstützt.

Adressbuchsichtbarkeit mit mehreren Firmen

Im Hosting werden Sie nicht je Firma einen eigenen Forest installieren. Daher müssen Sie sich Gedanken machen, wie Sie mehrere verschiedene Firmen auf einem Server in einer Organisation betreuen.

Exchange 2000/2003 unterstützt diese Konfiguration, da Sie sehr viele Adressbücher anlegen können und über entsprechende Berechtigungen auch sicherstellen können, dass jeder nur "seine" Gruppe sehen kann. Über einen Eintrag beim Benutzer (ADSIEdit !) kann auch ein anderes Adressbuch als die Standard-GAL vorgegeben werden. Eine genaue Beschreibung für die Umsetzung finden Sie in den Microsoft unterlagen (Siehe Links am Ende)

  • 319213 How To use Address Lists to Organize Recipients in Exchange 2003
    ACHTUNG: NICHT MEHR SUPPORTET
  • 822940 - How to Manage Address Lists When You Host Virtual Organizations
    ACHTUNG: NICHT MEHR SUPPORTET
  • Microsoft Seite für Hoster
    http://www.microsoft.com/serviceproviders/solutions/hostedmessaging.mspx
  • Beschreibung von Amit Zinman mit Bildern
    http://www.msexchange.org/tutorials/Shared-Hosting-Exchange-2003-Part2.html

Account und Kennwortsynchronisierung

Wenn sie internes Hosting betreiben, d.h. ein AD-Konto nutzen, dann gibt es nicht zu synchronisieren. Wenn Sie für Exchange einen eigenen Ressourcenforest nutzen und die Kontendomänen als "vertraut" eingerichtet haben, dann sollten Sie mit "disabled accounts" in ihrer Exchange Ressourcen Domäne arbeiten, denen die eigentlichen Konten als "Associated External Account" zugewiesen sind.  Das Konto kann nicht im gleichen Forest sein !

Nur wenn auch das nicht funktioniert und sie wirklich den Weg wählen, dass jeder Anwender zwei aktive Anmeldekonten nutzt (Eines für die normale Arbeit mit Windows und Dateiservern und das Zweite in Exchange), dann sollten Sie überlegen, wie sie mit Metadirectory oder anderen Tools einen Abgleich herstellen können. Solche eine Situation ist aber nicht hier zu beschreiben.

öffentliche Ordner

Alle Exchange Server in ihrem Hosting Forest sind in einer Organisation und teilen Sich die gemeinsamen Ordner. Entwickeln Sie ein Konzept, damit die Anwender "ihre" eigenen öffentlichen Ordner nutzen können. Dies betrifft die Sichtbarkeit durch Berechtigungen aber auch die Größe (Limit) und Replikate.

Service Level Agreement (SLA) und Verfügbarkeit

Sie müssen eine gewisse Verfügbarkeit garantieren, damit ihr Angebot überhaupt erst genommen und akzeptiert wird. Nur Versprechen ist einfach, Halten das andere. Und Beweisen, dass Sie ihre Verfügbarkeit erreichen wieder ein wichtiger Punkt. Schließlich kann ein Kunde auch über das Mittel einer Strafe oder Kürzung bei Nichterreichen Druck ausüben. Daher müssen Sie ihre System überwachen und die Ergebnisse auch nachweisen können.

Natürlich müssen Sie sich dann auch Gedanken über uSV, RAID, Cluster und andere Dinge machen, die ihre Verfügbarkeit beeinflussen

Verteilte Administration

Natürlich werden Sie als  Hoster ihrem "Kunden" keinen direkten Zugriff auf eine MMC zur Verwaltung von Postfächern, Verteilern und öffentlichen Ordnern zur Verfügung stellen. Aber irgendwie müssen ihre Kunden ja die eigenen Empfänger verwalten.

Es ist ja selbstverständlich, dass Sie als Betreiber auch eine Datensicherung und Überwachung des Systems vornehmen. Aber Sichern alleine ist es nicht. Wie wird geregelt, wenn jemand eine Rücksicherung einer gelöschten Mal ( Stichwort Recovery Storage Group) anfordert ? Das zu automatisieren ist nicht mehr sehr einfach.

Sie müssen sich hierzu möglichst webbasierte "Self Service"-Optionen für ihren Kunden schaffen, da sich der Kunden ansonsten natürlich bei ihnen telefonisch meldet und Sie die Arbeit haben und letztlich damit ihre Kalkulation nicht mehr aufgeht. Jede dieser Leistungen aber nach Aufwand in Rechnung stellen, bringt Sie natürlich schnell ins Hintertreffen gegenüber Wettbewerbern, die diese Aufgabe schon gelöst haben

Weitere Links