5.10.2009 von dr-exchange.

Die Hoffung, dass jeder Exchange Administrator seine Umgebung vorschriftsmäßig sichert, bleibt in aller Regel erfüllt. Zu wichtig sind die Daten der E-Mailpostfächer für ein Unternehmen. In diesem Workshop stellen wir uns aber mal eine andere Situation vor, nämlich dass zwar die Exchange Datenbanken sauber und erfolgreich gesichert worden sind, aber - aus welchen Gründen auch immer – die Situation eintritt, dass das Active Directory mit allen Benutzerkonten „verloren“ ging. Das kann nicht sein sagen Sie? Oh doch, auch das durfte ich in meiner langjährigen Tätigkeit tatsächlich schon mehrfach erleben, - leider.

Wie auch immer, dieser Beitrag zeigt auf, wie man aus einer Postfachdatenbank eines Exchange Server 2003 die zu den Postfächern gehörenden Benutzerkonten restaurieren kann, um nicht alle Konten von Hand neu anlegen zu müssen. Sicher wären die folgenden Schritte auch ein Weg für eine Umgebung mit wenigen Benutzern/Postfächern.

• Active Directory neu aufsetzen und Konten neu anlegen
• Exchange Server neu installieren
• Postfachspeicher-Datenbank aus Sicherung einspielen
• Jedes Postfach mit einem Benutzerkonto wiederverbinden

Gehen wir nun aber mal davon aus, dass wir die Benutzerkonten nicht alle kennen und uns die viele Handarbeit schenken wollen. Exchange 2003 speichert zu den Postfächern auch Daten über die zugeordneten Benutzerkonten aus dem AD. Diese Tatsache machen wir uns in diesem Workshop zu Nutze.

Microsoft Support bietet dazu ein Tool, welches bis Exchange 2000 auch auf der CD unter Support\Tools mitgeliefert wurde: Mbconn.exe. Leider wird das Tool nicht mehr mit Exchange 2003 ausgeliefert, obwohl es auch in dieser Version prima funktioniert. Sie können das Tool direkt downloaden:

ftp://ftp.microsoft.com/PSS/Tools/Exchange%20Support%20Tools/MBConn/

Der erste Schritt für die erfolgreiche Wiederherstellung der verwaisten Postfächer ist nun die Postfachdatenbank aus der Datensicherung zurück zu holen und an einem neuen Exchange Server bereit zu stellen.

Hinweis:
Eine Exchange Server Datenbank kann jederzeit an einem anderen Exchange Server bereit gestellt werden, sofern der Name der Organisation und der administrativen Gruppe identisch sind. Sollten Sie nicht oder nicht mehr wissen, wie die genaue Bezeichnung der Exchange Organisation und der entsprechenden administrativen Gruppe war, können Sie das mit dem nachfolgenden Befehl direkt aus der Datenbank extrahieren.

D:\Exchange\MDBData> find “/ou=” priv2.edb

Nun erhalten Sie eine lange Liste der LegacyExchangeDN, aus der Sie eindeutig den Org- und Admingroup-Namen erkennen können. (z.B.)

/o=YOUR-ADMIN/ou=Erste administrative Gruppe/cn=Recipients/cn=Hans.Meier

Mit diesen Angaben können wir nun problemlos im neuen Active Directory eine neue Exchange Organisation sowie Exchange Server installieren, die den Namen entsprechen, die für die zurück zu sichernde Postfach-Datenbank entscheidend sind. Abschließend zeigt  ein Blick mit dem System Manager unter Postfachspeicher – Postfächer – alle Postfächer dieser Datenbank an, natürlich versehen mit dem „roten Kreuz“ für „abgehängtes“ Postfach. (Bild 1)

Diese Daten der abgehängten Benutzer in dem betreffenden Postfachspeicher machen wir uns nun mit Hilfe des Tools „Mbconn.exe“ zu Nutze. Dazu starten wir das Tool und verbinden uns im ersten Dialog mit dem betroffenen Exchange Server und einem erreichbaren Globalen Katalog. (Bild 2)

Im nächsten Schritt wird der betreffende Postfachspeicher ausgewählt: (Bild 3)

Das Tool listet nun alle abgehängten Postfächer dieses Stores auf (Bild 4).  

Über den Menüpunkt ACTIONS – EXPORT USERS erstellen wir im nächsten Schritt eine LDF-Datei, mit dessen Hilfe wir die benötigten Benutzerkonten per LDIFDE im Active Directory anlegen lassen. Dabei muss zwingend eine OU des Active Directories als Ziel für die zu erzeugenden Benutzerkonten angegeben werden. (Bild 5)

Durck Klick auf die Schaltfläche „Generate“ wird im angegebenen Verzeichnis eine LDF-Datei erzeugt, deren Inhalt per Editor bei Bedarf auch noch nachbearbeitet werden kann.

dn: CN=Lindermeier\, Robert,OU=Benutzer,DC=Your-Admin,DC=intern
changetype: add
UserAccountControl: 66048
msExchUserAccountControl: 0
displayName: Lindermeier, Robert
objectclass: user
samAccountName: RLINDERMEIER

Die zuvor angelegte LDF-Datei wird nun als Vorlage für den Benutzerimport verwendet. Der nachfolgende Befehl erzeugt daraufhin in der angegebenen OU die benötigten Konten.

C:\Temp> ldifde -i -f c:\temp\Users-to-recreate.ldf

Hinweis:
Sollte folgender Fehler auftreten:

Fehler in Zeile 1: Ausführung verweigert
Serverseitiger Fehler: “1325″

• Löschen Sie bei dem Benutzerkonto die Zeile UserAccountControl: xxxxx.

Der abschließende Schritt ist nun, die verwaisten Postfächer mit den neu erzeugten Benutzerkonten zu verbinden. Dazu kann das Tool Mbconn.exe verwendet werden. Im Tool Mailbox Reconnect klicken wir im Menü ACTIONS – PREVIEW ALL um für alle Postfächer das zugeordnete Konto zu finden. (Bild 6)

Alle Konten werden nun den Postfächern zugeordnet und im Active Directory wieder verbunden. Dazu wählen wir das Kommando ACTIONS – APPLY. (Bild 7)

Eine abschließende Meldung gibt Aufschluss über den Erfolg der Aktion. Natürlich könnte man auch die Postfächer über den Exchange System Manager einzeln zuordnen, aber das Tool macht die Angelegenheit natürlich einfacher, vor Allem lassen sich damit in einem Zug eine ganze Liste an Postfächern wieder verbinden.

Anmerkung:
Das Tool kann sowohl in Exchange 2000 als auch Exchange 2003 Umgebungen verwendet werden, jedoch nicht mehr unter 2007. Diesen Vorgang beschreibe ich in einem der folgenden Beiträge.

Geschrieben in Sonstiges, Tipps & Tricks 2003, Tipps & Tricks 2000, Allgemein | Drucken | Keine Kommentare »

4.8.2009 von dr-exchange.

Nachdem nun die nächste Version des Exchange Servers (2010) vor der Tür steht, ist es sicherlich mal ganz interessant zu lesen, wie alles begann. Ich selbst war einer derjenigen, die von Beginn an mit diesem System intensiv gearbeitet haben, ja sogar die MS Mail 3.5 hatten wir noch in unserem Schulungshaus im Einsatz.

Im April 1996 erscheint Exchange Server 4.0 als Upgrade von MS Mail 3.5. Bis dahin war der Mailserver von Microsoft nichts anderes als eine erweiterte Verzeichnisstruktur auf dem Datenträger. Exchange Server 4.0 kam mit einer eigentlich revolutionären Änderung, die auch heute noch Status Quo ist; die transaktionsorientierte Jet-Datenbank (Eine Weiterentwicklung der heute noch unter MS Access genutzten Datenbank).

Als Client lieferte Microsoft damals den MS Exchange Client aus, der dann bald durch die erste Outlook-Version (97) ergänzt worden ist. Bereits 1 Jahr nach Exchange Server 4.0 erschien die 5.0 im März 1997, welche bereits im Oktober durch die Version 5.5 upgedatet worden war. In Exchange 5.0 lieferte MS den ersten webbasierenden E-Mailclient mit, das bis heute stets ausgebaute Outlook Web Access.

Zu Jahresbeginn erneutert Microsoft den Outlook Client und liefert ausserhalb des Office-Paketes eine neue Version, Outlook 98, welches innerhalb von knapp 2 Monaten auf mehr als 1 Million Clients installiert worden ist.

Der Juni im Jahre 1999 bringt uns das Office 2000 und erneut einen neuen Outlook-Client sowie im Oktober dann mit Exchange Server 2000 die Integration in das Active Directory. Bis dahin hatte das Zwischenrelease 5.5 des Exchange Servers bereits die Installationszahlen des damaligen sowie heutigen Konkurrenten Lotus Notes/Domino überholt. Exchange Server 2003, erschienen im Oktober 2003 wurde dann vom heute aktuellen Release 2007 im Dezember 2006 abgelöst.

Die Builds und Release-Daten des Exchange Server: http://support.microsoft.com/kb/158530

Geschrieben in Sonstiges, Allgemein | Drucken | Keine Kommentare »

13.7.2009 von dr-exchange.

Neue Server, neue Vorgehensweisen!

Viele Administratoren kennen die Anforderung, dass „Nicht-Exchange-SMTP-Server“ über den Exchange Server Ihre E-Mails nach Extern versenden wollen, da es diesen Systemen oft nicht erlaubt ist, direkten Zugriff ins Internet zu erhalten.

In Exchange 2003 musste man dabei „lediglich“ die betreffende IP-Adresse beim SMTP-Server (Bild 1) eintragen, damit das „Relayen“ erlaubt wurde.

Ansonsten nimmt ein Exchange Server nur E-Mails an Empfänger an, für die er auch zuständig ist. Dies hat sich auch bei Exchange 2007 nicht geändert, denn die Funktion der Empfängerrichtlinien aus Exchange 200x ist in die Funktion „Akzeptierte Domänen“ übergegangen. Damit wird dem Exchange 2007 Server mitgeteilt, welche Domänen er anzunehmen hat bzw. darf.

Seit Exchange 2007 ist die ganze Angelegenheit des externen Relaying nicht mehr ganz so trivial wie in Exchagne 2000x. Die virtuellen SMTP Server wurden vollständig durch den Exchange Transport Service ersetzt und Sende- und Empfangsconnectoren übernehmen nun die Arbeit des früheren SMTP-Dienstes.

Wie in früheren Versionen erlaubt ein Exchange 2007 Server Relaying, wenn man sich erfolgreich authentifiziert. Oft ist dies aber nicht gewollt bzw. umständlich einzurichten und zu pflegen.

Um nun ohne Anmeldung über einen 2007er zu relayen, bedient man sich am geschicktesten eines Empfangs-Connectors der auf einer zusätzlichen IP-Adresse basiert und entsprechend konfiguriert werden kann.

Über die Verwaltungshell erstellen wir unter Serverkonfiguration – Hub-Transport einen neuen SMTP-Empfangsconnector mit folgenden Angaben:

Name:                Relaying nach Extern
Verwendung:    benutzerdefiniert
Lokale IP:          Hier geben Sie auf dem Exchange Server zusätzlich definierte IP an
FQDN:               Einen DNS-Eintrag definieren, wie z.B. mailrelay.your-admin.intern
RemoteIP:        Entspricht der(n) IP-Adresse(n) des(r) Sender(s) (Relayer)

Hinweis:
Alternativ könnte auch mit einem anderen TCP-Port auf derselben IP-Adresse gearbeitet werden, wenn das Sendesystem dies unterstützt.

Nachdem der Empfangsconnector erstellt worden ist, sollten sämtliche Sicherheitsmechanismen wie TLS, Standardauthentifizierung etc. abgeschaltet (Bild 2) und als Berechtigungsgruppen lediglich „Anonyme Benutzer“ aktiviert sein. (Bild 3)

Nun nimmt der Connector zwar Mails von anonymen Sender an, aber er erlaubt noch nicht das Weiterleiten nach Extern. Dazu muss nun noch in der Exchange Verwaltungsshell folgender Befehl eingegeben werden:

Get-ReceiveConnector “Relaying nach Extern”| Add-ADPermission -User Anonymous-Anmeldung” -ExtendedRights ms-Exch-SMTP-Accept-Any-Recipient”

Geschrieben in Sonstiges, Tipps & Tricks 2007, Tipps & Tricks, Allgemein | Drucken | Keine Kommentare »

30.3.2009 von dr-exchange.

Wir alle kennen das Problem, wenn ein Exchange Server installiert wurde und nun die Testphase ansteht. Das MS Exchange-Team hat nun ein Tool dafür geschaffen, welches unter https://www.TestExchangeConnectivity.com verfügbar ist und folgende Optionen für Zugriffs- und Funktionstests bietet:

• Exchange ActiveSync mit Windows Mobile 5
• Exchange ActiveSync mit Windows Mobile 6.x
• Exchange ActiveSync mit 3rd-Party-Geräten (z.B. Nokia Mail for Exchange)
• Outlook Anywhere (RPCoverHTTP) mit Outlook 2003
• Outlook Anywhere (RPCoverHTTP) mit Outlook 2007
• Eingehende SMTP-Nachrichten

Hinweis:
- Benutzung wie immer auf eigene Gefahr
- Das Tool ist noch im Beta-Stadium

Aber äußerst hilfreich

Geschrieben in Outlook-Client, ActiveSync mit Windows Mobile, Sonstiges, Tipps & Tricks 2007, Tipps & Tricks 2003, Tipps & Tricks, Tipps & Tricks 2000, Allgemein | Drucken | Keine Kommentare »

27.3.2009 von dr-exchange.

Die Suche nach dem Verbleib von gesendeten oder empfangenen Nachrichten ist eine der Haupttätigkeiten eines Exchange Administrators. Oftmals wird an den Support die Frage herangetragen, warum eine bestimmte Nachricht nicht eingegangen ist bzw. nicht an den Empfänger weitergeleitet worden ist. Hier muss nun auf die Suche gegangen werden um den Verbleib der Nachricht zweifelsfrei zu klären, und wenn auch nur um den Grund für eine Nichtübermittlung festzustellen und abzustellen.

Dem Exchange Admin stehen hierfür diverse Hilfsmittel zur Verfügung. Zum Einen ist das der Exchange System Manager mit dem integrierten Nachrichten-Tracking-Modul, zum Anderen das ausführlichere Protokoll des SMPT-Servers. Per Default ist dieses jedoch nicht aktiviert und muss speziell angeschaltet werden. Der SMTP-Server unter Exchange Server 2003 – ganz im Gegensatz zum SMTP-Transportstack des Exchange Server 2007 – ist Teil des Windows Servers 2003 und wird im Zuge der Installation von Exchange Server 2003 unter dessen Kontrolle gestellt.

Es gibt Organisationen, die alleinstehende Windows Server 2003 mit eingerichtetem SMTP-Dienst als SMTP-Relay intern oder in der DMZ einsetzen, oftmals mit installiertem Spam- und/oder Antivirenschutz. Für diese Systeme gilt, dass auch darauf das SMTP-Logging zur Analyse des Nachrichtenverkehrs aktiviert werden kann. Allerdings befinden sich hier die Optionen unter dem IIS-Management. Selbstverständlich sei erwähnt, dass auch oftmals andere SMTP-Relays wie Postfix, sendmail, etc. im Einsatz sind. Auch darauf ist in der Regel ein ausführliches SMTP-Logging möglich.

Wie aber wird das SMPT-Logging unter 2003 aktiviert. Dazu beschränken wir uns in diesem Workshop auf den Betrieb eines SMTP-Dienstes unter Exchange Server 2003. Die Aktivierung wird über den Exchange System Manager durchgeführt. Öffnen wir unter ORGANISATION – SERVER – SERVERNAME – PROTOKOLLE – SMTP die Eigenschaften des betreffenden virtuellen SMTP-Servers.

Setzen wir nun das Häkchen neben Protokollierung aktivieren und wählen das Protokollformat „W3C-erweitert“. Dieses Format ermöglicht das Logging aller notwendigen Informationen, die wir später zur Analyse benötigen. Über die EIGENSCHAFTEN definieren wir nun explizit, welche Detailinformationen wir aufgezeichnet haben möchten, in diesem Fall wählen wir Alle.

Nicht zu vernachlässigen sind auch die Optionen Protokollzeitplan und das Verzeichnis des Logs. Sinnvollerweise übernehmen wir die Einstellung „Täglich“ und wählen ein Verzeichnis mit ausreichend Speicherplatz, da die Protokolle je nach Nachrichtenverkehr mehrere MBytes an Größe annehmen können. Über Erweitert wählen wir nun alle gewünschten Eigenschaften, die wir aufgezeichnet haben möchten. Nachdem wir alles bestätigt haben, restarten wir am Besten den gesamten SMTP-Dienst unter Windows um die Protokollierung zu aktivieren.

Nachdem die ersten Nachrichten durch den Server gegangen sind, finden wir im angegebenen Verzeichnis das aktuelle Protokoll und können dieses mit einem beliebigen Text-Editor analysieren. Hier nun ein Beispiel, das über einen gesamten SMTP-Vorgang Auskunft gibt.

2007-05-01 07:19:13 xxx.xxx.xxx.204 mail.domain.com SMTPSVC1 YAEX02 192.168.1.201 0 EHLO - +mail.domain.com 250 0 314 23 297 SMTP - - - -
2007-05-01 07:19:13 xxx.xxx.xxx..204 mail.domain.com SMTPSVC1 YAEX02 192.168.1.201 0 MAIL - +FROM:<mailings@domain.com> 250 0 45 32 0 SMTP - - -
2007-05-01 07:19:13 xxx.xxx.xxx..204 mail.domain.com SMTPSVC1 YAEX02 192.168.1.201 0 RCPT - +TO:<info@your-admin.com> 250 0 0 29 296 SMTP - - - -
2007-05-01 07:19:13 xxx.xxx.xxx..204 mail.domain.com SMTPSVC1 YAEX02 192.168.1.201 0 BDAT - +<4bb61e2469ed4498776856d0e23bc659@daa30085app019> 250 0 87 2545 78 SMTP - - - -
2007-05-01 07:19:14 xxx.xxx.xxx..204 mail.domain.com SMTPSVC1 YAEX02 192.168.1.201 0 QUIT - mail.domain.com 240 1610 68 4 0 SMTP - - - -

Man kann in obigem Auszug deutlich erkennen, dass jeder einzelne Schritt eines SMTP-Eingangs am Server YAEX02 aufgezeichnet worden ist.

Hierbei ist besonders zu beachten, dass Microsoft im Zuge einer globalen Einheitlichkeit der SMTP-Protokolle die Uhrzeit stets in der GMT-Zeit protokolliert, erst der System Manager „übersetzt“ diese normalerweise in die lokal gültige Zeit.

Sollten nun im Rahmen einer SMTP-Vorganges Fehler auftreten, so sind diese deutlich im Protokoll zu erkennen. Auch diverse Suchen in der Log-Datei bzw. Imports in Programme wie Excel zur weiteren Verarbeitung sind möglich. Wer das Logging an zentralen Verteilpunkten in der Exchange Organisation mit hohem bis sehr hohem SMTP-Aufkommen aktivieren möchte, dem steht auch frei das Logging per ODBC-Schnittstelle direkt in eine SQL-Datenbank zur späteren Auswertung zu ermöglichen. Wählen Sie hierzu lediglich das entsprechende Protokollformat.

Geschrieben in Sonstiges, Tipps & Tricks 2003, Tipps & Tricks 2000, Allgemein | Drucken | Keine Kommentare »

23.12.2008 von dr-exchange.

Microsoft Outlook Web Access 2003 (OWA) ist eine mächtige und hilfreiche Schnittstelle für die Postfachdaten auf einem Exchange Server 2003, die ausgehend von einer korrekten Konfiguration der entsprechenden Server (z.B. Zugriff über einen speziellen, in der DMZ implementierten Front-End-Server) Zugriff von jedem Internet-PC auf diesem Globus bietet.

Eben diese Tatsache jedoch macht es unter Umständen sinnvoll bzw. gar notwendig, bestimmte Option von OWA über eine zentrale Konfiguration vorzugeben bzw. zu unterbinden. Hierzu stellt Microsoft mit dem Webverwaltungstool für Outlook Web Access (OWAADMIN) ein hilfreiches Tool bereit, welches >hier< heruntergeladen werden kann: . Ohne den OWAADMIN müssten die Einstellung direkt in der Registrierung des Exchange Servers vorgenommen werden.

Das Tool kann zwar auf einem Windows XP-Rechner ebenso installiert werden, wie auf einem Windows 2000 Server, sollte aber meines Erachtens am Besten auf einem der Exchange 2003 Back-End-Server installiert werden. Setzen Sie für OWA einen Front-End-Server ein, so installieren Sie das Tool NICHT auf dem Front-End-Server, da diese meist in die DMZ konfiguriert und daher WMI-Zugriffe auf die Back-End-Server nicht möglich sind – eine der Voraussetzungen für den korrekten Betrieb des Tools.

Zur Installation muss der Internet Information Server, ASP.Net und das .Net-Framework 1.1 korrekt und lauffähig installiert sein, wobei auf einem Back-End-Exchange Server eben diese Voraussetzungen gegeben sind. Wir laden die OWAAdmin.MSI über den angegebenen Link herunter und starten die Installation.

Der Installationsvorgang an sich ist mit wenigen Klicks erledigt. Das Setup hat nun im IIS unter der Standardwebseite ein Virtuelles Verzeichnis OWAADMIN erstellt, welches für die weitere Konfiguration gestartet werden kann.

Zu beachten ist jedoch, dass OWAADMIN nur über eine SSL-Verbindung benutzt werden kann, da nur hierüber die Authentifizierung und der Remotezugriff auf die Exchange-Server ermöglicht wird. Sollte der Back-End-Server, auf dem Sie OWAADMIN installieren, nicht bereits ein SSL-Zertifikat konfiguriert haben, erstellt das Setup des OWAADMIN automatisch ein Testzertifikat und konfiguriert dieses auch.

Starten wir nun die Konfigurationsoberfläche über https://<Servername>/owaadmin. Die Konfiguration der einzelnen Optionen erweist sich über die Oberfläche des OWAADMIN als relativ simpel, so dass wir in diesem Workshop nur auf die interessantesten Optionen eingehen werden.

Die wichtigste Option ist die Möglichkeit der Anpassung der Outlook Web Access Oberfläche, so dass nur ausgewählte Features in OWA angezeigt werden. Dazu kann über den Abschnitt „Anpassung – Featureunterstützung für den gesamten Server“ definiert werden, welche Komponenten in OWA zur Verfügung gestellt werden sollen (Bild 3).

Damit lässt sich z.B. der Zugriff auf Öffentliche Order über OWA komplett unterbinden, eine nicht zu unterschätzendes Feature in Punkto Sicherheit. Alle eingestellten Optionen stehen sofort beim nächsten Zugriff per OWA zur Verfügung.

Alles in Allem steht dem Exchange Administrator mit OWAADMIN ein mächtiges Werkzeug zur Verfügung, um das Web-Front-End seiner Exchange Organisation nach eigenen Wünschen und Bedürfnissen zu gestalten.

Geschrieben in Sonstiges, Outlook-Client, Tipps & Tricks 2003, Allgemein | Drucken | Keine Kommentare »

16.7.2008 von dr-exchange.

Um ein oder mehrere Postfächer unter Exchange Server 200x auf einen neuen Server oder in einen neuen Postfachspeicher zu verschieben, stehen dem Exchange Administrator verschiedene Möglichkeiten zur Verfügung. Entweder wird das Postfach über das Active Directory Benutzer- und Computer Snapin (ADBuC) bzw. den Exchange Server 200x System Manager (ESM) verschoben oder mit Hilfe eines Datenexports und -imports über Outlook, ExMerge oder andere 3rd-party-Tools am bestehenden Exchange gelöscht und auf dem neuen Server bzw. neuen Postfachspeicher neu angelegt.

Viele haben bestimmt schon häufiger von den Möglichkeiten des Postfachverschiebens Gebrauch gemacht, aber nur wenige sich wohl nähere Gedanken über den Vorgang an sich gemacht. Ich will hier auch nicht näher beschreiben, wie man das macht - denke mal, das weiß jeder Admin - sondern im Detail erläutern, was wirklich im Hintergrund passiert.

1. Zuerst öffnet der Assistent von dem Computer aus, auf dem er gestartet worden ist, eine MAPI-Verbindung zum Quell-Postfachserver und anschließend ebenso eine MAPI-Verbindung zum Ziel-Postfachserver. 2. Im nächsten Schritt wird im Quellpostfach ein Flag gesetzt, welches verhindert, dass während des Verschiebens der Postfachdaten weitere neue Daten eingehen. Dazu setzt das System das Attribut PR_IN_TRANSIT. Geht nun am Server eine E-Mail für dieses Postfach ein, wird diese Nachricht in der SMTP-Warteschlange „für verzögerte Übermittlung“ deponiert bis das Verschieben abgeschlossen ist.Im Übrigen ist es nicht richtig, dass man während des Verschiebens unbedingt verhindern sollte, dass der oder die Benutzerin auf das Postfach zugreift. Auch wenn der Anwender über Outlook an seinem Postfach angemeldet ist, kann das Postfach ohne Datenverlust problemlos verschoben werden. 

3. Nun wird am Ziel-Postfachserver das Postfach angelegt und ebenfalls das Attribut PR_IN_TRANSIT gesetzt, damit kein Login möglich und keine Nachrichtenzustellung möglich ist. 

4. Nach dem erfolgreichen Öffnen beider Postfächer kann nun der Inhalt des Postfaches verschoben werden. Hierbei bedient sich Exchange einer speziellen MAPI Funktion  -IMapiPro::CopyTo() -, die schneller arbeitet, als das „einfache“ Senden von Nachrichten von einem zum anderen Server. 

Der Assistent fragt vor dem Start, wie viele „korrupte“ Elemente übersprungen werden dürfen. Wird dieser Wert während des Verschiebens übersprungen, wird der gesamte Verschiebevorgang rückgängig gemacht. 

5. Konnte das Postfach erfolgreich von A nach B verschoben werden, findet abschließend ein Update des Verzeichnisobjektes für den Benutzer statt. Dabei werden die Attribute HomeMDB, HomeMTA und msExchHomeServerName auf den neuen Postfachserver bzw. Postfachspeicher umgeschrieben. Anschließend wird vom Zielpostfach das Attribut PR_IN_TRANSIT entfernt und das Quellpostfach gelöscht.

Hinweis:
Abschließend möchte ich noch ausdrücklich darauf hinweisen, dass unter Exchange Server 2003 der Message Transfer Agent nicht mehr genutzt wird, wie in den früheren Versionen des Exchange Servers.

Geschrieben in Sonstiges, Tipps & Tricks 2003, Tipps & Tricks 2000, Allgemein | Drucken | Keine Kommentare »

18.6.2008 von dr-exchange.

Ein Exchange Server bietet die Möglichkeit einzelne Postfächer in Ihrer Größe einzuschränken. „Wozu?“, wird mancher sagen, „Ich habe genug Platz auf meinem Datenbank-Laufwerk!“. Teilen Sie diese Meinung auch? Ich nicht! Wieso ich diese Meinung nicht teile, möchte ich hier erläutern.

Vorab sei erinnert, dass es grundsätzlich mehrere Möglichkeiten gibt, ein Postfach in seiner Größe zu beschränken.

Entweder man beschränkt ein bestimmtes Postfach direkt in den Eigenschaften des Benutzers (Bild), oder man definiert zentrale Vorgaben über die Eigenschaften des Postfachspeichers. Letztlich gibt es diverse Gründe, warum man die Größe eines Postfaches beschränken soll. Nachfolgend eine Liste der möglichen Gründe:

Schutz vor Überlaufen des Servers (E-Mail-Bomben)
Eine „beliebte“ Denial of Service Attacke auf einen E-Mail-Server ist das „Beschießen“ eines oder mehrerer bekannter Postfächer mit großen E-Mails. Ohne eine Postfachgrößenbeschränkung kann dies nun z.B. über das Wochenende dazu führen, dass eine gesamte Exchange Organisation zusammenbricht. Selbstverständlich gehen wir davon aus, dass es eine eingehende Größenbeschränkung für einzelne E-Mails bereits gibt, aber diese bewegt sich doch in aller Regel zwischen 10 und 16 MByte, wie die Erfahrung zeigt.

Nun ist es bei vielen Organisationen so, dass zwar die Laufwerke für die Datenbanken ausreichend Platz bieten, um das Wachstum der Datenbank des Privaten Informationsspeichers möglicherweise abzufangen, bis die E-Mailbombe entdeckt wird, aber oftmals die Laufwerke für die Transaktionsprotokolle vorher bereits voll laufen. Sobald dies der Fall ist, wird der Exchange Server die Speichergruppe bzw. den Informationsspeicher offline schalten.

Dies kann nur vermieden werden, wenn es eine Beschränkung gibt, die den Empfang von Nachrichten ab einer bestimmten Postfachgröße unterbindet. Wie groß diese sein soll, hängt ganz von Ihrer IT-Umgebung ab, insbesondere davon, ob Sie bereits eine E-Mail-Archivierungslösung eingeführt haben und betreiben.

Einhaltung des nächtlichen Backupfensters bei Vollsicherungen
Je größer die einzelnen Postfächer werden, desto mehr wachsen die dahinter liegenden Exchange Datenbanken. Nun mag die tägliche, inkrementelle Sicherung bzw. tägliche Zuwachssicherung an sich noch kein Problem verursachen, aber die mind. einmal wöchentlich laufende Vollsicherung kann sehr viel länger dauern. Dies bedeutet, dass morgens evtl. Ihre Mitarbeiter bereits wieder arbeiten, aber die Exchange Vollsicherung das System zu diesem Zeitpunkt noch unnötig ausbremst.

Niedrige Recovery-Zeiten bei Datenbankausfall
Je größer eine Informationsspeicher-Datenbank ist, desto länger wird es dauern, bis diese im Fall der Fälle zurückgespielt ist. Kleine Datenbanken bieten kurze Recovery-Zeiten, und dieser unschätzbare Vorteil sollte möglichst nicht verspielt werden. Ihr IT-Leiter wird es Ihnen danken, wenn das nächste Datenbank-Recovery nötig ist.

Performance des Postfaches stabil halten
Ein von vielen missachteter Umstand ist, dass auch Outlook als Client unter übergroßen Postfächern leiden muss. Das Problem stellt zwar nicht die allgemeine Postfachgröße an sich dar, sondern es gibt nachgewiesene Performance-Einbußen, wenn in einzelnen Postfachordnern zu viele Elemente oder Unterordner abgelegt sind. Arbeiten Sie mittlerweile mit Outlook 2003 im Cached Mode, stellt auch die Größe der dahinter liegenden OST-Datei lokal auf Ihrem System ein Performance-Bottleneck dar, insbesondere wenn diese auch noch fragmentiert auf der Festplatte liegt.

Missbrauch des Postfaches zur Archivierung
Wir Administratoren haben im Laufe der Zeit schon eine Menge Dinge erlebt, eines davon ist, dass es User gibt, die tatsächlich Ihr Postfach auch als Archiv für Dokumente aller Art verwenden. Die Begründung ist meist, dass damit beispielsweise auch der Zugriff über das Internet (OWA/IMAP) möglich wird und die Dokumente aller Orte verfügbar sind. Das Problem allerdings ist oft die Größe der Dokumente, die nun ein Postfach anschwellen lassen. Verhindern lässt sich so etwas natürlich nicht, aber man kann diesen „Missbrauch“ des Exchange Postfaches damit deutlich einschränken.

Fazit
Die Erfahrung zeigt, dass man wunderbar mit einer Grenze von 200 MByte leben kann, wenn man gewisse Regeln wie tägliche Pflege des Postfaches einhält. Ich persönlich hatte seit über 10 Jahren noch nie ein Postfach, das über 150 MByte angewachsen ist.

Wir sind uns jedoch auch bewusst, dass es überall dort, wo es derzeit (noch) keine Postfachgrößenbeschränkungen gibt, unheimlich schwer für den Exchange Administrator ist, diese nachträglich umzusetzen. Unsere Hoffnung ist, dass Ihnen die Liste der Argumente in diesem Workshop als Unterstützung dient, um die IT- oder die Geschäftsleitung davon zu überzeugen Größenbeschränkungen einzuführen.

Geschrieben in Tipps & Tricks 2007, Sonstiges, Tipps & Tricks 2003, Tipps & Tricks 2000, Tipps & Tricks, Tipps & Tricks 5.5, Allgemein | Drucken | Keine Kommentare »

6.5.2008 von dr-exchange.

Alle Exchange Administratoren kennen die Situation. Eine Mitarbeiterin bzw. ein Mitarbeiter verlässt das Unternehmen und keiner denkt oftmals an die in der Regel nach wie vor eingehenden E-Mails für den oder die Ehemalige. Wie aber soll nun mit diesen verfahren werden? Einfach das Postfach zu Löschen ist die meiner Meinung nach die denkbar schlechteste Lösung, da dies zu Unzustellbarkeitsnachrichten bei betroffenen Kunden bzw. Lieferanten führen würde, und diese NDR´s (Non Delivery Reports) werfen kein gutes Bild auf unser Unternehmen.

Wohin sollen die eingehenden E-Mails vom Exchange Server nun ausgeliefert werden? Was ist mit confidential bzw. privaten E-Mails, die möglicherweise noch eingehen und datenschutzrechtlich kritisch sind? Es gibt diverse Möglichkeiten, einige davon möchte ich in diesem Artikel aufzeigen.

A. „Altes“ Postfach und vorherige E-Mailadresse dem Nachfolger zuweisen
Die schnellste und einfachste Möglichkeit ist, wenn ein Benutzer das Unternehmen verlässt das Windows-Konto und damit auch das Postfach zu löschen. Wenn Sie mindestens über Exchange 2000 Server verfügen, können Sie ein gelöschtes Postfach jederzeit wieder mit einem anderen oder neuen Windows-Konto verbinden. Beachten Sie hierbei die so genannte Retention-Time für gelöschte Postfächer, die auf Ihren Postfachspeichern eingestellt ist. Sollte diese auf 0 Tage stehen, dann funktioniert das nur unmittelbar nach Löschung des Postfaches und Replikation im Active Directory. Ansonsten ist das Postfach in der Regel über Nacht vom Mailbox Cleanup Agent auch vom Server entfernt worden.

Wird also beispielsweise für den Nachfolger ein neues Konto erstellt, so kann das vorher gelöschte Postfach direkt mit dem Konto des neuen Benutzers verbunden werden. Dabei ist darauf zu achten, dass möglichst zuvor alle beim ursprünglichen Postfach hinterlegten E-Mailadressen notiert und hinterher von Hand auf das neue Postfach als weitere SMTP-Adressen übertragen werden. Nur auf diese Weise ist der Empfang von Extern weiterhin auch an die E-Mail-Adressen des alten Postfaches möglich. Bei der Wiederzuweisung eines Postfaches werden vom Empfängeraktualisierungsdienst neue E-Mailadressen gemäß den gültigen Empfängerrichtlinien erstellt.

Bedenken Sie jedoch hierbei, dass dem neuen Benutzer nun alle vom Vorgänger im Postfach hinterlassenen Daten zugänglich sind.

B. Postfach archivieren und löschen, sowie die ursprüngliche E-Mailadressen dem Nachfolger zuweisen
Diese Vorgehensweise ermöglicht es, dass auch weiterhin Kommunikation hin zur „alten“ E-Mailadresse möglich bleibt. Die Daten des Postfaches des ehemaligen Mitarbeiters sollten zuerst revisionssicher archiviert werden. Dazu kann eine entsprechende Archiv-Software genutzt, oder aber auch die Exportfunktion von Outlook bzw. ExMerge. Der komplette Inhalt des Postfaches ist somit bis zu einem gewissen Stand gesichert, nur für den Fall, dass auf die Daten in Zukunft nochmals zugegriffen werden muss.

Überprüfen Sie nun, welche E-Mailadressen auf das Postfach eingetragen sind, um diese später auf das Zielpostfach – derjenige, der künftige Kommunikation für den ehemaligen Mitarbeiter empfangen soll – übertragen zu können. Einigen Kunden nutzen hierfür einen E-Mail-aktivierten Öffentlichen Ordner namens „Post fuer Ehemalige“ oder ähnlich.

Nun löschen Sie das zuvor archivierte Postfach und ggf. den zugehörigen Windows-Account und übertragen die Mailadressen des/der Ehemalige(n) auf das Zielpostfach oder den Zielordner im Bereich Öffentliche Ordner.

Geht nun eine E-Mail für den ehemaligen Mitarbeiter ein, dies könnten ja auch Antworten auf frühere E-Mails sein, dann haben Sie die Möglichkeit diese zu beantworten und zu bearbeiten.

C. Postfach über Abwesenheitsassistent übergangsweise offen halten
Diese Methode ist hervorragend dazu geeignet, die Kommunikationspartner darüber zu informieren, dass die Mitarbeiterin oder der Mitarbeiter nicht mehr für unser Unternehmen tätig ist. Schalten Sie hierfür bei dem betreffenden Postfach den Abwesenheitsassistenten ein und teilen über die Abwesenheitsnachricht mit, dass der Ansprechpartner sich geändert hat und der Absender bitte seine Kontaktdaten ändern möge. Hier ein Beispiel:

Sehr geehrte Damen und Herren,

YOUR-ADMIN
„administration just in time”

Zuvor archivieren Sie die Daten des alten Postfaches wie in Abschnitt B. beschrieben. Bitte beachten Sie aber, dass manche Unternehmen den Abwesenheitsassistenten für den E-Mailverkehr nach extern unterbinden. Hier können Sie diese Methode natürlich nicht anwenden. Nun kann der Exchange Administrator jederzeit über die Nachrichten-nachverfolgung feststellen, ob in den letzten Wochen noch E-Mails an dieses Postfach eingegangen sind und zu einem bestimmten Zeitpunkt das Postfach dann letztendlich komplett löschen.

Grundsätzlich muss jeder für sich und sein Unternehmen selbst entscheiden, daher bleibt die Entscheidung für eine bestimmte Methode offen, allerdings hat sich die Methode mit dem Abwesenheitsassistenten bei unseren Kunden bestens bewährt.

Geschrieben in Outlook-Client, Sonstiges, Tipps & Tricks 2007, Tipps & Tricks 2003, Tipps & Tricks 5.5, Tipps & Tricks 2000, Allgemein | Drucken | Keine Kommentare »

26.3.2008 von dr-exchange.

Microsoft liefert seinen Exchange Server in einer Standard und einer Enterprise Edition aus, was sich vor allem preislich bemerkbar macht. Einer der markanten Unterschiede, neben dem, dass lediglich eine Postfachspeicher-Datenbank angelegt werden kann, ist der, dass der Postfachspeicher keine beliebige Größe – begrenzt bei theoretischen 8 TByte – annehmen kann, sondern dass die Standard Edition eine maximale Datenbankgröße von 16 GB erlaubt. Diese Grenze gibt es bereits seit Erscheinen der ersten Exchange Server Version 4.0 vor ziemlich genau 12 Jahren und ist hart codiert. Wird die Grenze erreicht, protokolliert der Exchange Server das Ereignis mit der ID 1112 und beendet danach mit dem Event 445 den Informationsspeicher.

Da das E-Mailaufkommen mittlerweile sprunghaft gestiegen ist, trägt seit über einem Jahr auch der Hersteller Microsoft dieser Tatsache Rechnung und erlaubt mit dem Update auf Exchange Server 2003 Service Pack 2 eine maximale Datenbankgröße von 75 GB.

Man ist versucht zu glauben, dass lediglich das Update auf den aktuellen Service Pack #2 die Grenze verschiebt, allerdings erlaubt auch ein Exchange 2003 Server Standard Edition nur maximal 18 GByte. Tatsächlich jedoch muss also der Administrator über die lokale Registrierung in das bestehende System eingreifen um die Grenze auf 75 GB anzuheben. Nachfolgend die Schritte, die am Exchange Server vorgenommen werden müssen um in den „Genuss“ der 75 GB Grenze zu kommen.   Die notwendigen Einstellung sind unterhalb eines Registrierungsschlüssels vorzunehmen, der auf jedem System anders lautet, da es sich um die GUID (Global User ID) des Postfachspeichers Ihres Exchange Servers handelt. Diesen Wert finden Sie im Attribut objectGUID des Postfachspeicherobjektes im Active Directory. Nachfolgend ein Beispiel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS
\YADC01\Private-d9d5700f-cbcc-4600-9916-5af39cd73db2 

A. Datenbanklimit definieren

Der folgende Registrierungsschlüssel definiert das DB Limit (Dezimalwert): 

Datentyp       REG_DWORD
Name:            Database Size Limit in GB
Wert:              1 – 75
Default:         18 

Erstellen Sie hierzu einen neuen Wert vom Typ DWORD mit dem oben angegebenen Namen. Weisen Sie die für Ihren Server passende Datenbankgröße zu und restarten Sie anschließend den Informationsspeicher. 

B. Warngrenze definieren

Exchange 2003 protokolliert ab Service Pack 2 eine Warnung, wenn nur noch ein bestimmter Anteil in der Datenbank bezogen auf das Limit frei ist. Konfigurieren Sie diesen Wert nach Ihren Anforderungen. 

Datentyp       REG_DWORD
Name:            Database Size Buffer in Percentage
Wert:              1 – 100                                
Default:         10

C. Wann wird geprüft?

Mit nachfolgendem Wert können Sie definieren, wann die Überprüfung der Datenbankgröße vom System vorgenommen wird.

Datentyp       REG_DWORD
Name:            Database Size Check Start Time in Hours from Midnight
Wert:              1 – 24                        
Default:         5 

Hinweise:

• Sollte in Zukunft eine Serverwiederherstellung Setup-Option /disasterrecovery notwendig werden, so ist der entsprechende Key vor dem ersten Start der Datenbank erneut zu setzen.
• Exchange ermittelt die Datenbankgröße im Rahmen des normalen Maintenance-Zyklus, alle 24 Stunden um 05:00 Uhr. Die Uhrzeit kann bei Bedarf ebenso konfiguriert werden.
• Bei der Berechnung der Datenbankgröße wird der “freie” Speicherplatz in der Exchange Datenbank nicht mehr mit einbezogen, somit wird auch ein Offline-Defrag, wie vielfach für frühere Versionen empfohlen, die Datenbankgröße nicht mehr reduzieren
• Das Database Size Limit kann im Übrigen auch in der Enterprise Edition konfiguriert werden, um beispielsweise ein unkontrolliertes Anwachsen der Datenbanken zu verhindern, beispielsweise auch um den Verbrauch des „kostspieligen“ SAN-Platzes zu  einzudämmen.

Geschrieben in Sonstiges, Tipps & Tricks 2003, Tipps & Tricks, Allgemein | Drucken | Keine Kommentare »