Hallo liebe Leser.

In einigen Foren, darunter auch in MS Foren, wird beschrieben dass man die absoluten Pfade der Lync Datenbankdateien einfach so im SQL Server ändern kann. Das stimmt so nicht! Zwar läuft Lync Server danach problemlos weiter, jedoch wird das nächste Update zu einem Fiasko!

Die absoluten Pfade zu den Datenbank Dateien werden bei der Installation festgelegt und stehen in der CMS Datenbank. Wurden nun die Pfade per SQL Server geändert, so stimme sie nicht mehr mit der Topologie überein. Da alle Lync Server via SQL Server auf die Daten zugreifen fällt es aber zunächst nicht auf. Der SQL Server weiß ja wo seine Daten sind.

Nach einem Lync Server 2010 CU müssen die Datenbanken in der Regel mit dem PS Commandlet „Install-CsDatabase –Update….“ aktualisiert werden. Dieses Commandlet ruft nun Skripte aus dem Pfad „C:\Program Files\Common Files\Microsoft Lync Server 2010\DBSetup“ auf um die eigentlichen Updates durchzuführen. Dabei werden die physikalischen Pfade der Datenbank Dateien mitgegeben, welche ja nicht mehr stimmen!

Im Folgenden wird das Commandlet für alle verschobenen Datenbanken Fehler auswerfen. In der entsprechenden Logdatei finden sich die vollständigen Befehle um die Skripte für jede Datenbank auszuführen. Sie enthalten auch die absoluten Pfade der Datenbankdateien.

Nun kommt der findige Admin schnell auf die Idee, diese Skripte per Hand aus der CMD aufzurufen. Dies ist grundsätzlich kein Problem, würde sie nicht einen kleinen „Bug“ enthalten. Im Aufruf sind Dateien mit absoluten Pfaden versehen, also auch die Skript Datei und der Interpreter. Daher kann man eigentlich davon ausgehen, dass man die Skripte aus jedem beliebigen Verzeichnis ausführen kann. Eigentlich…

Z.B. beim Update der RTCDyn Datenbank kommt die lapidare Fehlermeldung „File Not Found“. Auf dem SQL Server hat man zu diesem Zeitpunkt eine „leere“ RTCDyn“ Datenbank mit „RESTRICTED_ACCESS“ und ohne jegliche Rollen oder Berechtigungen. Ein Moment in dem man die Suche nach dem letzten Backup einleitet…

Da aber auch das Zurückspielen des Backups das eigentliche Problem, das Update der Datenbanken, nicht löst, geht man zielorientiert vor und sieht sich das Skript genauer an. Die Zeile, welche den Fehler produziert hat, wurde ja ausgegeben. An dieser Stelle wird eine weitere Skriptdatei ausgeführt. Dazu wird auch ein Pfad zusammengebaut, was aber nicht funktioniert, wie eine einfache Bildschirmausgabe der Variable zeigt.

Wechselt man nun vor der Skriptausführung in das Verzeichnis „C:\Program Files\Common Files\Microsoft Lync Server 2010\DBSetup“ läuft alles problemlos durch…

Also, bitte nicht einfach im SQL Server die Pfade ändern! Möchte man dies wirklich tun gibt es aktuell wohl nur den Weg, einen neuen SQL Server in der Topologie anzulegen um dann die Datenbanken mit Backup & Restore umzuziehen.

Sollte jemand einen (von MS unterstützten) Weg finden die absoluten Pfade in der Topologie anzupassen, so bitte ich um eine kurze Info!

Viel Glück!

Nach dem ich kurz davor war mein HTC 7 Mozart gegen ein iPhone einzutauschen konnte ich das Problem mit dem Entsperren zumindest ein deutlich reduzieren. Aber der Reihe nach…

Für mich weitgehen ohne Regelmäßigkeit habe ich Probleme mit dem Entsperren des Bildschirms meines Windows Phones. Oft treten die Probleme gar nicht auf, meist ist die Verzögerung nur ein par Sekunden bzw. lässt sich durch erneutes Ein- und ausschalten des Bildschirms oder ein Tippen auf die “Suche” Taste beheben. Manchmal dauert es aber mehrere Minuten bis sich das Telefon entsperren lässt! Das ist vor allem dann doof, wenn man gerade kein Head Set hat um einen Anruf entgegen zu nehmen…. Wirklich eingefroren ist das Telefon nicht, man kann z.B. sehen wie auf der Uhr die Minuten weiter zählen. Lediglich die Touch Eingabe scheint total blockiert zu sein.

Nun bin ich in einem Black Berry Forum zufällig über ein ähnliches Problem gestolpert. Hier wurde als Abhilfe das Löschen aller temporärer Browser Daten (Verlauf, Cookies, etc.) genannt. Und siehe da, es hilft auch beim Windows Phone 7! Zwar besteht immer noch eine kleine Verzögerung von wenigen Sekunden, die führe ich aber auf Hintergrundanwendungen wie Lync oder Facebook zurück. Warum und welche angesurften Seiten das Problem verursachen kann ich nicht sagen. Immerhin erklärt es warum das Problem mal mehr oder weniger krass ausfällt!

Grüße,

Andy

In den letzten Tage vermehren sich die Fälle in denen die Installation von IE9 probleme bei diversen Management Consolen verursacht. Konkret getestet lässt sich die Exchange 2010 EMC nicht mehr schließen, da angeblich noch ein Dialogbox offen sei. Ähnliches wird auch von Exchange 2007 und TMG 2010 berichtet.

Als Workaround steht aktuell wohl nur die Deinstallation von IE9 zur Verfügung.

Andy

Bei den aktuellen Exchange Updates scheint sich eine kleine Fehlerserie einzuschleichen. Im Gegensatz zum E2007 SP3 RU3 scheinen die Folgen beim E2010 SP1 RU3 deutlich weniger dramatisch zu sein:

http://blogs.technet.com/b/exchange/archive/2011/03/14/exchange-2010-sp1-rollup-3-and-blackberrys-sending-duplicate-messages.aspx

Mittlwerweile gibt es eine neue Version des RU3. Achtung: Unbedingt die Hinweise zu Forefront Security beachten!

http://blogs.technet.com/b/exchange/archive/2011/04/06/announcing-the-re-release-of-exchange-2010-service-pack-1-update-rollup-3-v2.aspx

Andy

Sofern noch nicht bekannt sollte dieser Artikel von allem Exchange 2007 Betreibern aufmerksam gelesen werden:

http://blogs.technet.com/b/exchange/archive/2011/03/29/potential-for-database-corruption-as-a-result-of-installing-exchange-2007-sp3-ru3.aspx

UPDATE:

http://blogs.technet.com/b/exchange/archive/2011/03/31/announcing-the-re-release-of-exchange-2007-service-pack-3-update-rollup-3-v2.aspx

Andy

In der letzten Zeit vermehren sich die Anfragen rund um die Archiv Funktion von Exchange 2010. Und immer wieder ist feststellbar, wie groß die Missverständnisse rund um das Thema sind.

Ich möchte mit diesem Artikel die technischen Möglichkeiten von Exchange 2010 aufzeigen und auch ein bisschen unter die Haube schauen. Er stellt keine rechtliche Bewertung der Funktionen dar! Dazu sind auch schon reichlich Diskussionen und Ausarbeitungen im Internet zu finden.

Ebenfalls erspare ich mir grundlegende Vorgehensweisen, wie z.B. das Anlegen einer Archive Mailbox, in diesem Dokument zu erklären. Für diese Schritte gibt es zahlreiche Anleitungen im Internet.

Das Dokument steht auch als PDF Download (ganz unten in diesem Post) zur Verfügung.

Begriffe und Missverständnisse

Bedingt durch das Fehlen einer ernsthaften, zentralen Archiv Funktion bei allen älteren Exchange Versionen, wurde dieses Feld bisher von Dritthersteller Produkten abgedeckt. Seit E-Mail ein fester Bestandteil der Unternehmenskommunikation ist, und damit auch geschäftsrelevante Informationen über dieses Medium ausgetauscht werden, wird zunehmend eine rechtliche Betrachtung erforderlich. Es hat sich daher angeboten die bestehenden Archiv Systeme auch zur Abdeckung rechtlicher Anforderungen heranzuziehen, da auch hier keine entsprechenden Mittel seitens Exchange verfügbar waren.

Aus dieser Situation heraus hat sich, nach meiner persönlichen Meinung, das größte Missverständnis und das schlimmste Unwort entwickelt: „Revisions- bzw. rechtsichere Archivierung”.

Nach meiner Ansicht sind die Funktionen „Archivierung” und „Rechtssicherheit bei geschäftlichen E-Mails” völlig unabhängig voneinander zu betrachten und zu bewerten. Leider hat sich, auf Grund der bisher eingesetzten Lösungen, die zwangsweise Verbindung beider Funktionen in vielen Köpfen manifestiert.

Dabei werden die Anforderungen häufig wie folgt definiert:

E-Mail Archivierung

• Aufbewahren und Auffinden von Informationen über einen langen Zeitraum
• Entlastung des primären Mail Systems
• Entlastung des Clients (Stichwort offline Cache)
• Zentralisierung bisheriger Client Lösungen (PST Archive)

Rechtssicherheit bei geschäftlichen E-Mails

• Manipulationssicheres und nachvollziehbares aufbewahren von Daten
• Filtern und Auffinden von für den Streitfall relevanten Daten

Microsoft Exchange 2010 SP1 Online Archive

Die Archive Mailbox wurde mit Exchange 2010 RTM erstmals eingeführt und mit den Service Pack 1 noch einmal funktionell erweitert. Sie ermöglicht nun die folgenden Funktionen:

• Aufbewahren und Auffinden von Informationen über einen langen Zeitraum
• Entlastung der primären Mailbox
• Entlastung des Clients
• Zentralisierung bisheriger Client Lösungen (PST Archive)

Das „Online Archive” (Archiv Mailbox)

Diese Mailbox ist grundsätzlich identisch mit einer normalen User Mailbox. Sie kann entweder in der gleichen oder einer anderen Postfach Datenbank abgespeichert werden. Zudem gib es noch die Möglichkeit, sie als online Service hosten zu lassen.

Dennoch gibt es einige Unterschiede zur primären User Mailbox:

• Der Zugriff erfolgt ausschließlich online, entweder via Outlook oder OWA (neben Outlook 2010 kann auch Outlook 2007 mit dem Hotfix KB2458611 verwendet werden)
• Ein Zugriff von anderen Benutzern auf das Online Archive ist nicht möglich
• Die Größenbeschränkungen können unabhängig von der primären User Mailbox eingestellt werden

Dargestellt wird das Online Archive als zusätzliche Mailbox:

Outlook

OWA

Etwas unglücklich gelöst ist die Unterhaltungsanzeige in Outlook. Archivierte Objekte „verschwinden” aus dem Conversation View der primären Mailbox:

Der Conversation View der Archive Mailbox ist vollständig:

Hier ist durchaus noch Raum für Verbesserungen.

Das Ergebnis der Suche ist ebenfalls vollständig, sucht man über alle Ordner:

Archive Mailbox und Information Store

Wie bereits erwähnt kann das Online Archive unabhängig von der primären Mailbox in einer beliebigen Datenbank platziert werden:

Es liegt also nahe alle Archive Mailboxen in separaten Datenbanken und auf „günstigerem” Speicher abzulegen, als die primären Postfächer. Da sich die Datenbanken nicht unterscheiden können sie, bei Bedarf, auch mit Hilfe einer DAG hochverfügbar gemacht. Ebenfalls denkbar ist auch einer unterschiedliche Behandlung bei Backup & Restore.

Die Größenbeschränkungen für das Online Archive werden per Mailbox eingestellt, eine Vorgabe auf Datenbank Ebene ist leider nicht möglich (aber wir haben ja die PowerShell ):

Retention Policies

Diese Richtlinien steuern Aufbewahrung und Archivierung und damit das Verschieben der Objekte aus der primären in die Archive Mailbox oder das Löschen von Objekten.

Die Retention Policies sind Bündel von Retention Policy Tags:

Die Regeln können auf verschiedene Objekte angewendet werden:

• Die gesamte Mailbox (Default Policy Tag, DPT): Eine globale Richtlinie auf die gesamte Mailbox. Alle Ordner in der Mailbox erben diese Einstellung, sofern für sie keine explizite Regel erstellt wurde.Default Folders (Retention Policy Tag, RPT): Alle bekannten Ordner eine Mailbox (Posteingang, Gesendete Elemente, etc.) können gezielt mit einer Aufbewahrungsrichtlinie angesprochen werden. Diese Regel wird erzwungen und kann vom Anwender nicht geändert werden. Der Anwender kann jedoch eine andere Archiv Regel anwenden, welche mit Personal Tags definiert werden.
• Personal Folder (Personal Tag): Legt der Benutzer selbst Ordner innerhalb der Mailbox an so kann er diese Richtlinien zur Archivierung verwenden.
• Recoverable Items Folder: Diese Richtlinie wirkt auf einen speziellen, für den Anwender nicht sichtbaren Bereich. Dazu später mehr unter Litigation Hold

Neben der Aufbewahrungszeit beinhaltet ein Tag auch die Maßnahme, welche nach Ablauf der Zeit durchgeführt werden soll:

• Delete and Allow Recovery: Die Daten wandern in den Dumpster (nicht in den Papierkorb der Mailbox) und können vom Anwender für die Dauer der Dumpster Aufbewahrungszeit wiederhergestellt werden.
• Permanently Delete: Die Daten werden dauerhaft gelöscht.
• Move To Archive: Die Daten werden in den identische Ordner der Archive Mailbox verschoben.

Ferner wird hier auch die Aufbewahrungszeit eingestellt. Dabei werden unterschiedliche Objekte unterschiedlich behandelt. Die Aufbewahrungsfrist zählt:

• Kalender Objekte: ab „End Datum”, bei wiederkehrenden Objekten ab dem „End Datum” des letzten Auftretens.
• Kalender Objekte (gelöscht): ab „Nachricht Empfangen”, wenn nicht vorhanden ab „Nachricht Erstellt”.
• Aufgaben (einmalig): ab „Nachricht Empfangen”, wenn nicht vorhanden ab „Nachricht Erstellt”.
• Aufgaben (Serie): ab „End Datum” des letzten Auftretens.
• Aufgabe (Folgen): Niemals.
• Aufgabe (gelöscht): ab „Nachricht Empfangen”, wenn nicht vorhanden ab „Nachricht Erstellt”.
• Alle anderen Objekte (nach Empfang): ab „Nachricht Empfangen”, wenn nicht vorhanden ab „Nachricht Erstellt”.
• Alle anderen Objekte (wenn vom Anwender in verwalteten Ordner verschoben: ab dem Zeitpunkt des Verschiebens.

Fehlen diese Attribute wird das Objekt nicht vom Regelwerk bearbeitet!

Bearbeitet man einen Tag, oder verwendet man die Shell, so stehen weitere Optionen zur Verfügung:

Diese Funktionen können nur in Personal Tag’s verwendet werden:

• Move To Deleted Items Folder: Das Objekt wird in den Papierkorb der Mailbox verschoben.
• Move to Managed Custom Folder: Managed Folder stammen noch von Exchange 2007. Sie sind in Exchange 2010 nur noch per Shell zu administrieren. Sie sind mit der Archiv Funktion von Exchange 2010 nicht kompatibel und sollten durch Personal Tag’s ersetzt werden.
• Mark as Past Retention Limit: Das Objekt wird als abgelaufen markiert und sofort archiviert.

Auf ein Postfach kann jeweils nur eine Retention Policy angewendet werden.

Anwenden von Richtlinien

Innerhalb der Mailbox kann der Anwender, soweit durch den Administrator vorgesehen, die Regeln für einzelne, persönliche Ordner oder die Objekte selbst setzen. Dabei wird zwischen der Ordnerrichtlinie (Aufbewahrung) und der Archiv Richtlinie unterschieden. Wird keine Ordnerrichtlinie ausgewählt so wird das Default Policy Tag ererbt:

Die Einstellungen des Default Policy Tag finden sich im Backstage Bereich:

Die Default Folder verhalten sich etwas anders. Hier wird grundsätzlich die Ordnerrichtlinie durchgesetzt. Wird auf dem Ordner kein eigener Retention Policy Tag festgelegt, so erbt er den Default Policy Tag. Der Benutzer kann zusätzlich aus den Personal Tags eine Archivierung auswählen, sofern vorhanden:

Ausgeführt werden die Regeln Serverseitig. Dazu wird der Managed Folder Assistant zu festgelegten Zeiten ausgeführt. Richtlinien und Änderungen werden erst zu diesem Zeitpunkt angewendet und auch erst ab diesem Zeitpunkt innerhalb der Mailbox sichtbar.

Laufen Mails aus der Aufbewahrungszeit werden diese gekennzeichnet. Je nach Häufigkeit der Ausführung des Managed Folder Assistant verbleiben diese Nachrichten mehr oder weniger lange in der Primären Mailbox, bevor sie in das Archiv verschoben oder gelöscht werden:

Ablaufende Objekte können auch mit der Suche gefunden werden:

Leider findet die Suche keine Mails die mit Hilfe von Personal Tags oder des Default Policy Tags archiviert werden sollen.

Ist ein Anwender längere Zeit nicht in der Lage seine Mails zu bearbeiten können Retention Policies auch für einen bestimmten Zeitraum ausgesetzt werden:

Microsoft Exchange 2010 SP1 Litigation Hold

Diese Funktion bietet die Möglichkeit Daten in einer Exchange Mailbox unveränderlich abzuspeichern. Dazu wird einfach die Funktion Litigation Hold aktiviert:

Litigation Hold

Litigation Hold entspricht einer Anforderung des nordamerikanischen Marktes. Hier ist es Praxis, die Daten erst im Streitfalle für die Ermittlung zu „sichern“, die Funktion also erst nach Eingang der Klage zu aktivieren. Nach Abschluss des Verfahrens kann die Funktion wieder deaktiviert werden. Im Sinne der deutschen Rechtsauffassung könnte dieses Verfahren jedoch nicht ausreichen, da der Anwender bereits Daten gelöscht oder verändert haben kann. Litigation Hold müsste also dauerhaft aktiviert sein.

Litigation Hold verwendet, wie das Single Item Recovery, den Dumpster 2.0. Das Einstellen von Aufbewahrungsfristen ist bei Litigation Hold nicht möglich, Objekte werden niemals gelöscht. Dies hat zur Folge, dass bei Erreichen der Speichergrenze keine Objekte mehr aus der Mailbox gelöscht oder geändert werden können. Weder durch den Benutzer noch durch den Managed Folder Assistant. Damit ist die Mailbox praktisch nicht mehr zu gebrauchen.

Kritisch betrachtet ist es aktuell eine der größten Schwachstellen dieser Funktion. Bei aktiviertem Litigation Hold kann die Aufbewahrungszeit nicht auf Basis einer zeitlichen Frist eingestellt werden. Letztlich werden alle Daten so lange gesammelt bis der Grenzwert erreicht ist. Ein Löschen veralteter ist sehr aufwändig. Es bleibt zu hoffen dass diese Funktion nachgebessert wird. Je nach Aufbewahrungsfrist hat Microsoft dafür ja etliche Jahre Zeit.

Bei aktiviertem Litigation Hold ist der Recoverable Items Folder also zu überwachen bzw. ausreichend groß zu konfigurieren.

Single Item Recovery

Das Single Item Recovery wurde dazu entwickelt um das Sichern bzw. das Wiederherstellen von einzelnen Objekten ohne den Umweg über die RSG zu ermöglichen. Dies stellt eine drastische Vereinfachung und Beschleunigung dar. Denn selbst beim Einsatz entsprechend intelligenter Backup Produkte musste im Zweifelsfalle immer eine komplette Datenbank wiederhergestellt werden um an eine einzelne Mail zu gelangen.

Single Item Recovery arbeitet grundsätzlich genauso wie Litigation Hold. Allerdings kann hier eine maximale Aufbewahrungsfrist definiert werden. Single Item Recovery erscheint auf den ersten Blick wie die Lösung für eine manipulationssichere Aufbewahrung. Nur werden die Objekte nach dem FIFO Prinzip gelöscht, sobald die Speichergrenze erreicht ist. Damit kann eine minimale Aufbewahrungsdauer leider nicht zuverlässig erzwungen werden.

Recoverable Items Folder

Der Recoverable Items Folder befindet sich in der Primären Mailbox. Die darin enthaltenen Objekte können jedoch mit Hilfe eines speziellen Retention Policy Tag in das Online Archive verschoben werden.

Der Inhalt des Recoverable Items Folder wird bei der Größenbeschränkung der User Mailbox nicht berücksichtigt. Hier gelten eigene Größenbeschränkungen (Soft- und Hard Quota).

Der Recoverable Items Folder steht nicht offline zur Verfügung. Er vergrößert damit auch nicht die offline Cache Datei (OST) des Outlook Clients.

Der Recoverable Items Folder befindet sich außerhalb der Reichweite des Benutzers und beinhaltet drei Unterordner:

• Deletions: Der System Dumpster. Hier landen alle dauerhaft gelöschten Objekte und werden für den voreingestellten Zeitraum aufbewahrt und anschließend endgültig entfernt.
• Purges: Dieser Order wird erst mit der Aktivierung von Litigation Hold oder Single Item Recovery aktiv. Hier landen alle endgültig gelöschten Objekte einer Mailbox und werden entsprechend der Funktion aufbewahrt.
• Versions: Auch dieser Ordner ist eine Funktion von Litigation Hold. Hier werden bei Änderungen von Objekten die vorherigen Versionen abgelegt.

Discovery Search und Single Item Recovery

Grundsätzlich werden sehr ähnliche Mechanismen zur rechtlichen Ermittlung und zum Single Item Recovery verwendet. Diese Beschreibung konzentriert sich auf Discovery Search.

Die Ermittlung kann auch an nicht-IT Mitarbeiter delegiert werden. Dies kann hilfreich sein wenn es um die Suche nach streng vertraulichen Informationen geht und diese nur von bestimmten Personen eingesehen werden dürfen. Diese Personen müssen Mitglied der Rolle Discovery Management sein:

Für die Suche muss durch einen Administrator eine Discovery Search Mailbox angelegt werden. Davon kann es durchaus mehr als eine geben. Da diese Mailbox unter Umständen extrem große Datenmengen beinhalten kann, welche sich häufig ändern können, aber im Grunde nur Kopien sind, empfiehlt sich die Platzierung in einer eigenen Datenbank, ggf. auf eigenem Storage.

Keine Sicherung und kein HA erforderlich (Daten sind Kopien).

• Umlaufprotokollierung aktivieren, um Plattenüberlauf zu vermeiden.
• Eigener Storage (produktive Mailboxen werden nicht zusätzlich beeinflussen).
• Verhindert unnötiges Wachstum der produktiven Datenbanken.
• Nach Ende der Ermittlungen kann die Datenbank gelöscht werden, vermeidet Offline Defragmentierung.

Grundsätzlich haben alle Mitglieder der Rolle Discovery Management Vollen Zugriff auf diese Mailbox. Dies kann bei mehreren, unabhängigen Ermittlungen unter Umständen nicht gewünscht sein und sollte entsprechend angepasst werden:

Die Suche wird mit Hilfe des ECP erstellt und ausgeführt:

Die Suche kann nach Stichworten (Wildcards und boolesche Verknüpfungen sind erlaubt), Sendern oder Empfängern….

… sowie nach Datumsbereichen Filtern. Zudem können die zu durchsuchenden Postfächer angegeben werden:

Weitere Paramater der Suche sind:

• Suchname: Unter diesem Namen ist die Suche später aufzufinden.
• Ergebnisse Schätzen: Die Suche wird durchgeführt, es werden jedoch keine Objekte in die Discovery Search Mailbox kopiert. Aus dem Bericht geht die wahrscheinliche Größe Objekte hervor. Dies kann bei umfangreichen Ermittlungen vor bösen Überraschungen schützen.
• Ergebnisse der Suche in das Zielpostfach kopieren: Ist diese Option aktiv werden alle gefundenen Objekte in die Discovery Search Mailbox.
• Entfernen von Duplikaten: Objekte können durchaus mehrfach vorkommen. Z.B. Mails an Verteilerlisten. Diese Option filtert die Duplikate heraus. Allerdings fehlen dann auch die Ordnerstruktur und damit auch eine gewisse Übersicht.
• Vollständige Protokollierung: legt ein ausführliches Protokoll (CSV Datei) in der Discovery Search Mailbox ab, aus dem alle gefundenen Objekte hervorgehen.

Wurde die Suche erfolgreich abgeschlossen sind die Ergebnisse in der Discovery Search Mailbox zu finden. Für jede Suche wird ein Ordner erstellt. Dort liegt eine Zusammenfassung mit dem ausführlichen Bericht als Anhang:

Sowie die Objekte als Kopie (sofern aktiviert):

Das Ergebnis kann auch mit Hilfe der Shell in eine PST Datei exportiert werden.

Für den Zweck des Single Item Recovery kann das Objekt auch als Mail Anhang direkt an den Benutzer gesendet werden:

Eine Wiederherstellung direkt in die Mailbox des Benutzers ist mit der Shell auch möglich.

Unterschiede zu anderen Systemen

Einer der bedeutendsten Unterschiede zu „klassischen” Archivsysteme ist der Verbleib der Daten im Exchange System. Dadurch verringert sich die Komplexität des Systems sowohl für den Anwender als auch für den Administrator.

• Eine Verwaltung
• Ein Backup
• Eine Überwachung
• Ein Client
• Suchen und finden an einer Stelle (Volltextindizierung in Exchange weiter möglich da Mails vollständig im System verbleiben)
• Einheitliches, bekanntes UI
• Mail Objekte bleiben als Ganzes erhalten

Auf den ersten Blick nachteilig erscheint der erhöhte Platzbedarf in der Primären Mailbox. Dem kann aber durch ein Konsequentes Archivieren von Mailbox und „Recoverable Items Folder” recht gut begegnet werden. Damit verschwinden die Daten vollständig aus der „heißen” Mailbox und damit auch aus dem offline Cache des Clients.

Bei der Betrachtung von Postfachgrößen kommt es nicht nur auf die Datenmenge an. Vielmehr ist die Anzahl der Objekte ist von entscheidender Bedeutung, und hier vor allem bei den „Default Foldern” wie Posteingang oder gesendete Objekte. Zwar wurde die „kritische” Anzahl von Objekten mit Exchange 2010 auf 100.000 / Ordner erhöht. Wir konnten jedoch schon bei deutlich geringeren Werten (20.000-40.000) massive Probleme beobachten. Bleiben also die Rümpfe der Mails als Pointer in der Mailbox stehen, so wie es klassischerweise von Archivsysteme gemacht wird, kann dies über die Jahre durchaus zu mehreren Tausend Objekten in diesen Ordnern führen. Damit ist die Mailbox zwar augenscheinlich klein, aber durchaus nicht unkritisch.

Auf den Zweiten Blick kann sich die gesamte Datenmenge sogar deutlich reduzieren. In Exchange 2010 wird jedes Objekt nur einmal abgespeichert. Von den Versionen bei Änderungen abgesehen. Klassische Archivsysteme sind darauf angewiesen die Daten bereits vor der Zustellung in die Mailbox zu speichern, damit sie nicht manipuliert werden können. Dies erfolgt in der Regel durch ein Journaling im SMTP Transport. Alle Daten müssen vom Archivsystem entsprechend aufbereitet und Indiziert werden, damit eine spätere Auswertung und ein Wiederfindet überhaupt möglich ist. Wird zu einem späteren Zeitpunkt die Mail aus dem Benutzerpostfach archiviert liegen viele der Daten zunächst doppelt vor, sofern keine Deduplizierung stattfindet. In diesem Fall wäre mit einer deutlich höheren Gesamtmenge an Daten zu rechnen.

Zum Schluss sollte nicht unerwähnt bleiben dass alle hier beschriebenen Funktionen die Microsoft Exchange Server 2010 Enterprise CAL für die entsprechend aktivierten Benutzer voraussetzt.

Download

Der vollständige Artikel als PDF:  Exchange 2010 Archiving and Litigation Hold – Demystified - V1.2p

Hinweise

Dieses Dokument wird veröffentlich „wie es ist”. Es besteht keine Garantie für Vollständigkeit und Richtigkeit. Es wird keine Haftung übernommen für mittelbare und unmittelbare Schäden die aus der Nutzung der bereitgestellten Informationen entstehen. Die Nutzung dieser Informationen liegt in der Eigenverantwortung des Lesers.

Der Inhalt dieses Dokuments ist geistiges Eigentum des Autors. Eine Weitergabe oder Verbreitung ist ausdrücklich erlaubt, sofern das Dokument unverändert bleibt und eine Quellenangabe auf den Autor verweist. Änderungen, speziell das Entfernen von Informationen zum Urheber, sind untersagt.

Die Rechte für im Dokumente genannte Markennamen liegen bei den jeweiligen Herstellern.

Seit dem 07.02.2011 steht das Lync 2010 Planning Tool für die RTM Verison zur Verfügung:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=bcd64040-40c4-4714-9e68-c649785cc43a

Grüße,

Andy

Leider sind Öffentliche Ordner auch mit Exchange 2010 noch nicht ausgestorben. Im Zuge der Migration von Exchange 2007 nach Exchange 2010 stößt man daher nach wie vor auf sie. Und auf die kleinen Probleme rund um sie.

Im diesem Fall muss die Public Folder Datenbank vom Exchange 2007 Server entfernt werden. Dabei spielt es zunächst keine Rolle ob die Daten zuvor auf einen Exchange Server 2010 repliziert wurden oder ob es tatsächlich die letzte Datenbank ist.

In dieser Installation soll mit Exchange 2010 ganz auf öffentliche Ordner verzichtet werden. Alle Benutzer Ordner wurden daher bereits gelöscht.

Im Ersten Schritt müssen nun die verbleibenden System Ordern, soweit möglich gelöscht werden. Ansonsten verweigert Exchange das Löschen der Datenbank mit dem Hnweis auf noch vorhandene Replikate.

Verschaffen wir uns erstmal einen Überlick über die System Ordner (Exchange 2007 Management Shell):

Get-PublicFolder "\NON_IPM_SUBTREE" -recurse

Nun werden alle Ordner entfernt, welche sich löschen lassen:

Get-PublicFolder "\NON_IPM_SUBTREE" -recurse|remove-publicfolder

Auf Grund der rekursiven Vorgehensweise können nicht alle Ordner in einem Durchgang gelöscht werden. Der Befhel sollte daher noch ein oder 2 mal wiederholt werden bis alle entfernbaren Ordner gelöscht sind:

Nun noch die Datenbank löschen:

Get-PublicFolderDatabase|remove-publicfolderdatabase

Obwohl diese Datenbank auf einem Exchange Server 2007 läuft wurde sie bei der Migration offensichtlich auf irgendeine Art und Weise aktualisiert. Also wechseln zur Exchange 2010 Management Shell. Da die Datenbank in der Exchange 2010 Organisation eigentlich gar nicht auftaucht muss bei der Suche der Server Name des alten Exchange 2007 Server angegeben werden:

Get-PublicFolderDatabase -server gt-exch01

Nun klappt auch das Löschen:

Get-PublicFolderDatabase -server gt-exch01|remove-publicfolderdatabase

Achtung! Diese Methode ist sehr endgültig und sollte nur nach vorheriger Datensicherung angewendet werden!

Andy

Im Rahmen einer Migration kann ein Exchange 2007 Edge Transport Server mit einem Exchange 2010 Hub Transport Server betrieben werden. Der im Folgenden beschriebene Fehler wird mit hoher Wahrscheinlichkeit auch mit einem Exchange 2010 Edge Transport auftreten, da die Ursache in der Hub Transport Rolle liegt.

Zum Fehler: Nach dem ändern der Edge Synchronisation auf den Exchange 2010 Hub Transport Server konnten keine Nachrichten mehr gesendet werden. Der Empfang funktioniert jedoch einwandfrei. Auf dem Exchange 2010 Hub Transport Server füllt sich die Warteschlange des Send Connectors in Richtung Edge Server (SMTP Relay in Active Directory Site to Edge Transport Server) mit der Fehlermeldung „451 4.4.0 DNS query failed“:

Die Anwender erhielten  zudem Benachrichtigungen „Delivery is delayed to these recipients or groups” für die entsprechenden Mails.

Beschreibung der Installation:

·         Exchange 2010 UR2 Standard English, Single Server (MB, HUB, CAS)

o   Auf Windows Server 2008 SP2 Standard English (aktueller Patch Stand)

·         Exchange 2007 SP2 UR 2 Standard English Edge Transport Server

o   Auf Windows Server 2003 R2 SP2 Standard English (aktueller Patch Stand)

Eine Analyse der Transport Logs ergab dass bisher kein Versuch gestartet wurde diese Mails per SMTP zu versenden. Damit konnte der Exchange 2007 Edge Transport als Fehlerquelle nahezu ausgeschlossen werden. Ein Blick in die Connectivity Logs des Hub Transport Servers bestätigte die Fehlermeldung der Warteschlangen:

2010-03-12T13:02:25.714Z,08CC8FFAF64ED566,SMTP,edgesync - duesseldorf to internet,+,SmtpRelayWithinAdSiteToEdge 347ebd04-3856-4d7b-8570-3a5c734c1e46

2010-03-12T13:02:25.714Z,08CC8FFAF64ED566,SMTP,edgesync - duesseldorf to internet,>,Non-existent domain reported by 172.16.2.251

2010-03-12T13:02:25.714Z,08CC8FFAF64ED566,SMTP,edgesync - duesseldorf to internet,-,Messages: 0 Bytes: 0 (The DNS query for ‘SmtpRelayWithinAdSiteToEdge’:'edgesync - duesseldorf to internet’:'347ebd04-3856-4d7b-8570-3a5c734c1e46′ failed with error: InfoDomainNonexistent)

Zugleich fand sich auf hier die Ursache des Problems. Der DNS Server 172.16.2.251 war der Sekundäre DNS Server der IP Konfiguration. Er sollte also gar nicht für die DNS Auflösung herangezogen werden, sofern der Primäre DNS Server antwortet. In diesem Fall konnte der Sekundäre DNS Server die internen Namen auch nicht auflösen. Es war ein nicht bereinigter Eintrag. Allerdings war auch dies ein DNS Server, der grundsätzlich auf die Anfragen geantwortet hat.

Da der Primäre DNS Server aber korrekt auflöst konnte das Problem durch nslookup nicht nachgestellt werden. Der Primäre DNS Server kann alle Server, inklusive Edge Transport, mit FQDN und Shortname auflösen.

Nach dem Entfernen des falschen Eintrags leerte sich dich Warteschlange augenblicklich. Der Fehler konnte durch das erneute Eintragen des falschen DNS Server reproduziert werden. Augenscheinlich verwendet der Transport Service in diesem speziellen Fall die DNS Server nicht in der richtigen Reihenfolge.

Andy

Grundsätzlich sind Snapshots eine feine Sache. Kann man doch schnell und unkompliziert Daten Sichern oder Wiederherstellen oder in Virtuellen Welten mal schnell etwas testen. Seit heute hängt über dieser Annahme ein gewaltiges Fragezeichen. Zumindest Domain Controller können das Anwenden von Snapshots sehr übel nehmen.

In Umgebungen mit mehr als einem DC finden bekanntlich Replikationen statt. Wendet man nun einen alten Snapshot an ist dies für den betroffenen Domain Controller wie eine Wiederherstellung der AD Datenbank einer älteren Version. Grundsätzlich nimmt man nun an hier wird es zu keinen größeren Problem kommen. Durch die „Update Sequence Numbers” (USN) sollten die veralteten Einträge des „wiederhergestellten” DC einfach durch die aktuelleren überschrieben werden.

Leider falsch. Dies kann funktionieren, muss es aber nicht! Der Domain Controller kann diese Prozedur auch als „nicht unterstützte Wiederherstellung” erkennen, was einen NetLogon Dienst im Status „angehalten” und diesen Eintrag im Eventlog nach sich ziehen kann:

ActiveDirectory_DomainService / NTDS General:  Event 2103

The Active Directory database has been restored using an unsupported restoration procedure. Active Directory will be unable to log on users while this condition persists. As a result, the Net Logon service has paused. User Action See previous event logs for details. For more information, see Help and Support Center at http://…

Was auch als “USN Rollback” bezeichnet wird. Zudem finden sich zahlreiche Einträge zum Thema „Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)” in den Logs.

Was war passiert?

Die Umgebung betroffene Umgebung war eine „grüne Wiese” Installation für eine größere Migration bei einem Kunden. Zwar war sie noch nicht produktiv, dennoch steckte schon eine Menge Arbeit in der Einrichtung, inklusive Exchange 2010, PKI, etc.  Zum Zeitpunkt des Vorfalls bestand die Gesamtstruktur aus 1 Root- sowie 5 Child Domains auf Basis Windows Server 2008 R2. Alle DC’s wurden als virtuelle Server in einem Hyper-V 2 Cluster bereitgestellt. Für die Root Domain sowie eine Child Domain existierte bereits ein 2., physikalischer DC auf den alle FSMO Rollen übertragen wurden.

Durch einen „Unfall” ging die LUN verloren, auf der alle Hyper-V Gastsysteme abgespeichert waren. Die LUN konnte aus einem SAN Snapshot wiederhergestellt werden. Dieser Snapshot war jedoch rund 15-30 Minuten alt. Zunächst konnten alle Systeme wieder problemlos gestartet werden. Jedoch waren die Eventlogs voll mit Replikationsproblemen (Event IDs 1388, 1988, 2042). Im Falle des virtuellen DC der Root Domain erschien auch der Event 2103. Zudem war der Dienst „NetLogon” im Zustand „paused”.

Leider finden sich auf Anhieb nicht wirklich viele Informationen in der Microsoft Knowledge Base oder einschlägigen Foren. Der allgemeine Tenor zum Event 2103 lautete: AD auf dem DC entfernen und neu installieren. Sicher eine Lösung, aber nicht unbedingt eine befriedigende.

Und an dieser Stelle gilt unser Gruß und Dank Jan Kappen, der unter Einsatz von Blut Schweiß und reichlich Kaffee dieses Problem bereits mit dem Microsoft Support gelöst und freundlicherweise dokumentiert hat!

Hier die Schritte in der Kurzfassung:

Beseitigung Event 2103:

• HKLM\System\CurrentControlSet\Services\NTDS\Parameters
  • “Dsa Not Writable” von 4 auf 0 setzen
  • REG_DWORD “Ignore USN Rollback” anlegen und auf 0 setzen
• Server neu starten (NetLogon sollte nun laufen)
• Replikation wieder aktivieren:
  • repadmin /options “Servername” -DISABLE_OUTBOUND_REPL
  • repadmin /options “Servername” -DISABLE_INBOUND_REPL

Nun waren nur noch ein par “Lingering Objects” übrig welche die Replikation blockierten. Diese Objekte können ebenfalls mit dem „repadmin” entfernet werden. Dazu gibt es aber diverse Anleitungen so dass ich es nicht näher beschreibe.

Da unser Snapshot nur 15-30 Minuten alt war mussten wir kein DC Computer Konto zurücksetzen. Dies hat Jan aber auch gut beschrieben.

Viel Erfolg!

Andy

Quelle: Hyper-V, ADS-Controller und angewendete Snapshots [Update]