Jan Geisbauer - About IT from Redmond and Elsewhere

Exchange 2010 – Teil 7 (Mailtips)

noreply@blogger.com (Jan Geisbauer) — Thu, 04 Mar 2010 18:14:00 +0000

Mailtips bewahren z.B. Mitarbeiterinnen des Arbeitsamts Nürnberg vor peinlichen Veröffentlichungen. Mailtips informieren den User über Dinge, die er bisher erst nach dem Versenden der Email erfahren hat:

Wir versuchen hier an Testuser1 zu senden und bekommen beim Auflösen des Namens (hier in OWA) die “Out-Of-Office” Message des Empfängers angezeigt. Man kann sich also sparen, ellen-lange Emails an Leute zu schreiben, die vielleicht erst in zwei Wochen antworten. Das ist nur ein Beispiel für Mailtips. Ein weiterer, implementierter Mailtip ist, der Hinweis darauf, dass ich an externe Empfänger schreibe:

Auch hier kann es zu Verwechslungen kommen. Es soll schon vorgekommen sein, dass wichtige firmeninterne Informationen an einen Journalisten verschickt wurden, dessen Name ähnlich klang wie der Kollege, an den man eigentlich schicken wollte.

Konfiguration

Per Default ist ein Mailtip enabled, der einen warnt, wenn an mehr als 25 Empfänger geschrieben wird. Der Mailtip für das Versenden an externe muss dagegen freigeschaltet werden. Das macht man über Set-OrganizationConfig. Anzeigen lassen kann man sich die Mailtip Config so:

(hier wurde der ExternalRecipient Mailtip schon auf "$true” gesetzt)

Damit das “zieht” kann es sein, dass man einen IISReset machen muss und ggf. auch mal Outlook (2010 only!) neu starten muss. Weitere Tipps zur Fehlerbehebung von Mailtips finden sich hier.

Um festzulegen, dass bereits beim Versenden an 3 Email Adressen ein “LargeAudience Mailtip” gezeigt werden soll sagt man:

Set-OrganizationConfig –MailtipsLargeAudienceThreshold 3

Setze ich den Threshold auf 3, kommt das entsprechende Warning ab 4 Recipients:

Wie man hier gut sehen kann, werden Mailtips auch kombiniert. D.h. der andere Mailtip (die OOF von Testuser1) wird auch mit angezeigt. Eigentlich alles ganz einfach. Mehr Komplexität kommt durch “Group Metrics” hinein. “Group Metrics” wird gebraucht, um die Größe von Verteilerlisten zu bestimmen. Damit keine “Live-Abfrage” der Mitliederzahl von Verteilerlisten gemacht werden muss, werden die Größen der Verteilerlisten jede Nacht um Mitternacht auf einem entsprechend konfigurierten Mailbox server ermittelt. Dazu muss man den Mailbox Server konfigurieren:

Verantwortlich für die Generierung der Files ist der “Microsoft Exchange Service Host” Service. Wenn man den durchstartet, werden die Files generiert. Der File Distribution Service schiebt die Files dann auf den CAS, hier werden sie von Outlook 2010 “eingesehen”:

Auf dem CAS Server liegen sie dann in diesem Verzeichnis:

Eine weitere Möglichkeit von Mailtips zu profitieren, ist, wenn man bestimmten Usern verbietet an Verteilerlisten oder andere Mailboxen zu schreiben. Per Set-Mailbox kann dies bewerkstelligt werden:

Set-Mailbox testuser1 –RejectMessageFromSendersOrMembers ex10test1

ex10test1 darf also nicht mehr an testuser1 senden. Das sieht dann so aus:

Zum Schluss gibt es noch die Möglichkeit “Custom Mailtips” zu bauen. Das geht auch über Set-Mailbox und Set-DistributionGroup:

Set-Mailbox ex10test1 –Mailtip “Nicht jeder darf an ex10test1 schicken, du nicht! :-)”

Mehr Informationen zur Architektur von Mailtips gibts hier.

Exchange 2010 – Teil 6 (Transport Rules und AD RMS)

noreply@blogger.com (Jan Geisbauer) — Fri, 15 Jan 2010 16:20:00 +0000

Exchange 2010 kann per Transport Rule eMails mit RMS schützen. So kann man beispielsweise dafür sorgen, dass alle eMails, die das Keyword “[Confidential]” im Subject oder im Body enthalten, nicht weitergeleitet oder ausgedruckt werden können oder nach einer bestimmten Zeit “ablaufen”. Dieser Post beschreibt, wie man RMS auf einer Windows 2008 R2 Maschine installiert und welche Einstellungen anschließend notwendig sind, damit Exchange 2010 damit arbeiten kann. Merci an dieser Stelle an den RMS-Guru Hacke, der mir immer wieder virtuell zur Seite stand.

Es folgen nun die Screenshots durch die Installation von RMS. In Windows 2008 R2 wird dazu einfach eine neue Rolle hinzugefügt:

Nach der Installation

Nach der Installation müssen noch 3 Aufgaben erfüllt werden:

Das Self-Signed Certificate das wir während der Installation von AD-RMS erstellt haben, muss exportiert werden und auf dem Exchange 2010 Server unter Trusted Root CAs eingespielt werden.
Der Computer-Account des Exchange 2010 Servers muss auf die Datei “c:\inetpub\wwwroot\_wmcs\certification\ServerCertification.asmx” berechtigt werden.
Per PowerShell muss man RMS (intern) enablen:
set-irmconfiguration –internallicensingenabled:$true

Nun sind wir soweit und können die RMS Funktionalität per Cmdlet überprüfen:

In einer Transport-Rule kann nun als Action “rights protect messsage with RMS template” ausgewählt werden:

Klickt man nun auf RMS-Template, öffnet sich folgender Dialog:

Das “Do Not Forward” ist das einzige RMS Template, das standardmäßig dabei ist. Weitere kann man in der RMS GUI selbst erstellen.

Wir erstellen uns nun also eine Transport-Rule, die folgendermaßen aussieht:

Enthält eine Mail also in Subject oder Body das keyword “[Confidential]”, wird das RMS Template “Do Not Forward” applied.

Ausprobieren:

Und tatsächlich, es kommt eine RMS geschützte Email an:

(Die Condition ist übrigens nicht case-sensitive, [confidential] zieht also auch)

Exchange 2010 – Teil 5 (Berechtigungsmodell – RBAC)

noreply@blogger.com (Jan Geisbauer) — Thu, 10 Dec 2009 12:59:00 +0000

Jetzt kommt starker Tobak. Das Berechtigungsmodell in Exchange 2010 wurde komplett überarbeitet. Es bietet nun schier unbegrenzte Möglichkeiten festzulegen wer, was, wo darf. Diese ungeheuere Flexibilität, die uns Microsoft hier anbietet, fordert ihren Tribut in Sachen Verständlichkeit / Umfang. Dieser Artikel versucht das neue Modell so praxisnah wie möglich zu erläutern.

Das gesamte Konzept baut auf Rollen auf und heißt deshalb auch “Role Based Access Control (RBAC)”. Sowohl Berechtigungen für Enduser (z.B. darf der User neue Verteilerlisten erstellen) als auch Administrator Berechtigungen werden in RBAC definiert. Genau dieser Umstand sort für ein wenig Verwirrung. Wir schauen uns zuerst den Enduser an. Um einem User mehr Berechtigungen zu geben, geht man wie folgt vor:

1. Erstellen einer neuen “Role Assignment Policy”
2. Erstellen eines neuen “Management Role Assignments”
3. Die “Role Assignment Policy” wird mit der Mailbox assoziiert.

Das folgende Diagramm beschreibt den Prozess:
Schaubild 1

Wir sehen, eine Rolle (End User Management Role) besteht aus “Management Role Entries” –> (A bis E). Das sind im Grunde genommen nur Exchange Cmdlets mit den dazugehörigen Parametern. D.h. eine Rolle in RBAC besteht aus einem Set von Cmdlets, die ausgeführt werden dürfen. Genauer noch: Cmdlets und die speziellen Parameter. So könnte z.B. in einer Rolle definiert sein, dass das Cmdlet “Set-Group” ausgeführt werden kann, aber nicht z.B. der Parameter XYZ gesetzt werden darf.

Es gibt Rollen die speziell auf End-User zugeschnitten sind und so gibt es für jede Rolle ein Property namens “IsEndUserRole”, das dann ggf. auf TRUE steht. Auch im Namen sind die Enduser Roles gekennzeichnet – sie beginnen mit “My…” (get-ManagementRole my* geht auch):

Wie wir im Schaubild 1 sehen, kann man sich zu jeder Rolle auch die entsprechenden Role-Entries anzeigen lassen, per:

Get-ManagmentRole myDistributionGroups | Get-ManagementRoleEntry

Nun zu unserem Szenario: Exchange 2010 erweitert OWA um das “Exchange Control Panel (ECP)” über das der User viele Einstellungen an seiner Mailbox (und noch einiges mehr) machen kann. Per Default sieht das z.B. aus:

Auf der linken Seite sehen wir die Navigationspunkte. Genau an dieser Stelle erlaubt uns OWA 2010 auch neue Verteilerlisten zu erstellen und zu managen – wenn man die entsprechenden Rechte dazu hat. Genau diese wollen wir uns nun besorgen: Wir erstellen also per

New-RoleAssignmentPolicy meineAssignPol1

eine neue Assignment Policy. Danach müssen wir eine Rolle (z.B. MyDistributionGroups) mit der AssignmentPolicy assoziieren. Dazu erstellt man ein neues “Management Role Assignment":

New-ManagementRoleAssignment –name meinAssignment1 –Role “MyDistributionGroups” –Policy “meineAssignPol1”

Anschließend muss die AssignmentPolicy einer Mailbox zugewiesen werden:

Set-Mailbox ex10test1 –RoleAssignmentPolicy meineAssignPol1

Nachdem alles ordnungsgemäß ausgeführt wurde kommt man gar nicht mehr aufs ECP:

Das war nicht ganz unser Ziel. Was ist passiert? Jede Mailbox hat per Default eine RoleAssignmentPolicy zugewiesen. Diese beinhaltet die Rolle “MyBaseOptions”, die bestimmte Grundfunktionalitäten erlaubt. D.h. wenn man sich eine neue AssignmentPolicy erstellt, muss man dieser auch immer (zusätzlich) die Rolle “MyBaseOptions” zuweisen:

New-ManagementRoleAssignment –name meinAssignment1 –Role “MyBaseOptions” –Policy “meineAssignPol2”

Und schon haben wir wieder Zugriff aufs ECP – und nicht nur dass: nun können wir auch Gruppen managen:

So sollte man vorgehen. Durch das Erstellen von RoleAssignmentPolicies kann man mehreren Usern die gleichen Permissions geben. Man kann aber auch direkt Berechtigungen vergeben:

New-ManagementRoleAssignment “ex10test1-Voicemail” –User ex10test1 –Role “MyVoiceMail”

Dieses direkte RoleAssignment weist dem User ex10test1 die Rolle “MyVoiceMail” zu. Das ist in etwas so, wie wenn man File-Permissions auf einem File Server pro User vergibt und nicht per Security Gruppe. Irgendwann wird es un-managebar.

Administratoren und Spezial User

Im “Admin-Bereich” werden Management Role Groups erstellt, denen Rollen zugewiesen werden. Wir erstellen eine Role Group, die das Recht hat Transport Rules zu managen:

New-Rolegroup –Name “myFirstRoleGroup” –Role “Transport Rules” –Members ex10test1

Wir starten die EMC mit den Credentials von ex10test1:

Wir sehen nur den Organization Configuration Zweig und den Recipient Configuration Zweig – unter Organization Configuration ist nur “Hub Transport” zu sehen. Interessant ist auch, wie die Properties einer Usermailbox mit unseren eingeschränkten Rechten aussehen:

(man beachte die kleinen Schlösser)

Unserer neuen Rolegroup “MyFirstRoleGroup”, die Transport Rules managen darf, können wir weitere Mitglieder hinzufügen:

add-RolegroupMember “MyFirstRoleGroup” –Member ex10test2

und zusätzliche Rollen zuweisen:

New-ManagementRoleAssignment –Name “myfirstrolegroup-journaling” –SecurityGroup myfirstrolegroup –Role Journaling

Wie man sieht erfolgt das Zuweisen neuer Rollen wie im ersten Fall bei den Endusern über RoleAssignments.

Einige Rollen werden mitgeliefert:
http://technet.microsoft.com/en-us/library/dd638077.aspx

Ebenso wie einige Role Groups:
http://technet.microsoft.com/en-us/library/dd351266.aspx

Scopes

Scopes geben im RBAC an, für welchen Bereich (z.B. eine OU) die definierten Rechte gelten. Ein neuer Scope wird z.B. so erstellt:

New-ManagementScope “alleAusHeidelberg” –RecipientRestrictionFilter { City –Eq “Heidelberg” }

Wir erstellen nun wieder eine RoleGroup, aber diesmal unter Angabe es eben erstellten Scopes:

New-RoleGroup manageHeidelbergUsers –Members ex10test1 –Roles “Mail Recipients” –CustomRecipientWritescope “alleAusHeidelberg”

D.h. also, der user “ex10test1” ist nun Mitglied der RoleGroup “ManageHeidelbergUsers”, die Recipients modifizieren darf, die im “City” Feld “Heidelberg” stehen haben. Das wollen wir dann auch gleich mal überprüfen. Wir machen die EMC wieder unter den Credentials von ex10test1 auf:

Der User “ex7test1” hat ein leeres “City” Feld. Versuche ich hier per ex10test1 einen neuen ZIP Code einzutragen, bekomme ich die Meldung, dass dieses Objekt außerhalb meiner Befugnisse liegt. “Testuser1” hat Heidelberg als Stadt eingetragen, hier darf ich schreiben:

Impersoniert

So, was bedeutet das nun konkret? Wie arbeitet RBAC? Dazu schauen wir uns einmal an, was passiert, wenn per Exchange 2007 EMC eine neue Transport Rule angelegt wird. Ich habe für den entsprechenden Container im AD “auditing” eingeschaltet. Wie wir in folgendem Screenshot sehen, wurde die neue Transport Rule vom “Administrator” angelegt:

Nun, die gleiche Aktion von der Exchange 2010 EMC aus:

Wie man sieht, wird die Transport Rule hier vom Exchange Server Objekt angelgt. Exchange bzw. RBAC authorisiert mich also – es werden tatsächlich keine ACLs mehr im AD gesetzt.

Fazit

Ich könnte mir vorstellen, dass mit SP1 die GUI Version kommt und alles übersichtlicher macht. Die Tatsache, dass keine ACLs mehr geschrieben werden wird bei Migrationsscenarien weniger Ärger bringen. Die ungeheuere Flexibilität ist für größere Unternehmen sicherlich sehr gut – allerdings wird einiges an Planung nötig sein. Es lohnt sich auf jeden Fall sich mit RBAC zu beschäftigen und macht auch wirklich Spass.

Exchange 2010 – Teil 4 (Migration und Co-Existenz)

noreply@blogger.com (Jan Geisbauer) — Tue, 01 Dec 2009 10:42:00 +0000

Die meinsten Organisationen haben bereits ein Exchange System am Laufen. Wer sich jetzt mit Exchange 2010 beschäftigt, wird vermutlich momentan Exchange 2003 im Einsatz haben. Aber auch der ein oder andere Exchange 2007 Admin wird sich Fragen, welche Vorteile ihm 2010 bringt. Heute wollen wir uns damit beschäftigen, wie man nun von den älteren Systemen zum neusten Microsoft Exchange System kommt.

Wie immer, bedarf es dem Einspielen von Service Packs und anderen Voraussetzungen, bevor Exchange 2010 installiert werden kann. So muss der Forest Functional Level auf “2003 native” sein und alle Exchange 2007 Server brauchen SP2. Exchange 2010 kann entweder auf Windows 2008 SP2 oder auf R2 installiert werden. Die Schemaerweiterungen für Exchange 2010 sind übrigens bereits in Exchange 2007 SP2 enthalten.

Bevor man das Betriebssystem auswählt, muss man sich überlegen, ob man Exchange 2010 hochverfügbar betreiben möchte (in einer DAG –> späterer Blog Post). Will man das, muss man die Enterprise Edition von Windows installieren, da “Clustering” unterstützt werden muss.

Exchange 2000 darf sich nicht mehr in der Org befinden.

Damit Exchange 2010 mit Exchange 2003 koexistieren kann, braucht es – ebenso wie damals mit 2007 – einen Routing Group Connector, der bei der Installation angelegt wird. (Übrigens erst, wenn die Hub Transport Rolle installiert wird). Braucht man mehrere Verbindungen zwischen der 2010 Welt und der 2003 Welt, sollte man unbedingt Link-State-Routing unterdrücken.

Weiterhin sollte die erste Rolle, die man in eine legacy Org installiert, die CAS Rolle sein. Hier stellt sich die Frage, wie schnell alle Mailboxen von 2003 auf 2010 umgezogen werden können. Davon abhängig, lässt sich ein Migrationsplan schmieden. Wenn mein Unternehmen viele Mailboxen hat und ich nicht alle innerhalb einer Nacht umziehen kann, werde ich den neuen 2010 CAS zum Proxy für Imap, OWA und ActiveSync machen müssen. Denn der kann für 2003er Mailboxen Requests entgegen nehmen und weiterleiten. (Während der Exchange 2003 Server keine 2010er (oder 2007er) Mailboxen bedienen kann). In diesem Fall empfiehlt es sich also die primäre URL (z.B. owa.firma.de) auf den neuen CAS umzubiegen.

So, das war einfach. Zusammenfassend kann man sagen, dass sich Exchange 2010 in einer 2003 Org verhält wie Exchange 2007 (in einer 2003 Org). Wenn nun aber Exchange 2007 mit im Spiel ist, wird es komplizierter:

Wichtig zu wissen ist, dass ein Exchange 2007 Mailbox Server nur mit Exchange 2007 Hub Transport Servern sprechen kann. Ebenso kann ein Exchange 2010 Mailbox Server nur mit Exchange 2010 Transport Servern sprechen. Daraus folgt, dass ich in jeder AD Site, in der ein Exchange 2007 Mailbox Server steht, mindestens einen Exchange 2007 HT Server stehen lassen muss, solange bis ich den letzten 2007 Mailbox Server in der Site abschalte (und dass ich für jeden 2010 Mailboxserver einen 2010 HT brauche –> pro AD Site).

Da der Exchange 2010 CAS für den Exchange 2007 CAS genau wie für den Exchange 2003 Server nur als Proxy dient, muss auch in jeder AD Site, in der ein Exchange 2007 Mailbox Server steht, mindest ein Exchange 2007 CAS übrig bleigen.

Zusammenfassen kann man also sagen, dass man in einer Co-Existance von 2010 und 2007 solange HT und CAS Server in einer AD Site braucht, solange es dort Mailboxserver bzw. produktive Mailboxen gibt.

Hier zur Illustration ein kleines Bildchen:

Exchange 2010 – Teil3 (Mailbox Moves)

noreply@blogger.com (Jan Geisbauer) — Thu, 26 Nov 2009 15:16:00 +0000

Die Art und Weise wie Mailboxen verschoben werden können, hat sich mit Exchange 2010 verändert. Wen man in Exchange 2007 einen “Move-Mailbox” Befehl in einem PowerShell Fenster ausgeführt hat und dieses per Klick auf das “X” geschlossen hat, oder z.B. die RDP Session ausgetimed ist, wurde der Move abgebrochen.

In Exchange 2010 gibt es einen neuen Service, der Mailbox Moves handelt, den MRS –> Mailbox Replication Service. D.h. es gibt keinen “Move-Mailbox” Befehl mehr in 2010. Stattdessen verwendet man den Befehl “New-MoveRequest”, der den neuen Move-Request an den MRS schickt. Der Vorteil dabei ist, dass man die Move-Requests von allen Exchange 2010 Servern in der Org sehen kann und nicht auf ein “offenes” Powershell Fenster angewiesen ist.

Aber der Reihe nach. Wir moven in meiner brandneuen Exchange 2010 Testumgebung einfach einen User “Test1” von einer Datenbank auf eine andere:

Wie man sehen kann wird hier unterschieden in “Local” und “Remote” Move Request. Man ahnt es bereits, der Remote Move Request kann Mailboxen von anderen Orgs moven.

Wir interessieren uns hier für einen Local-Move, und moven deshalb den User Test1 von MDB1 nach MDB2:

Sobald der Move-Request abgesetzt wurde, taucht er unter “Move Request” auf. Der MRS arbeitet den Move Request nun ab –> Status “Moving”.

Und, da die Testmailbox beihnahe leer ist, wechselt er schnell auf “completed”:

Interessant sind auch die Properties eines Move Requests:

Hier gibt es einen Button um “Faild Messages” anzuschauen, also korrupte Items.

Der MRS kann in einer Config Datei nach Bedarf eingestellt werden. So kann man z.B. die maximale Anzahl an Moves pro Source Datenbank festlegen. Die Cofig Datei findet sich hier: “<Exchange Installation Path>\V14\Bin\MSExchangeMailboxReplication.exe.config”

Der MRS läuft auf jedem CAS Server. Bei einem Remote Move Request, kommt es darauf an, ob im Remote Forest Exchange 2010 läuft oder nicht. Momentan ist diese Wahrscheinlichkeit recht gering und so kontaktiert der lokale CAS direkt den Mailbox Server in der Remote Lokation (Exchange 2003 SP2 aufwärts). Sollte doch ein CAS 2010 in der Remote Lokation vorhanden sein, kann der Lokale CAS auch über einen weiteren Dienst namens “MRSproxy”. Der MRSproxy kann einen remote 2010 CAS kontatieren und über den den Move Request organisieren.

Der MRS sorgt nun auch dafür, dass eine Historie über alle Mailbox Moves in den Mailbox Properties gespeichert wird. Abrufen lässt sich das mit dem Get-MailboxStatistics Befehl:

Anschließend lässt man sich das Ergebnis in ein CSV pipen:

Das Ergebnis ist tatsächlich sehr detailiert und man kann so sehr schön herausfinden, auf welchen Datenbanken eine Mailbox schon “wohnte” und ob es beim Moven Fehler gab:

Exchange 2010 – Teil2 (Die GUI)

noreply@blogger.com (Jan Geisbauer) — Sun, 22 Nov 2009 18:51:00 +0000

Im zweiten Teil der Exchange 2010 Reihe beschäftigen wir uns mit der GUI. Das erste was neben dem leicht veränderten Logo auffält ist die neu eingezogene Ebene “On Premise”:

Exchange 2010 trägt damit dem allgemeinen Trend alles in Richtung Cloud zu bewegen Rechnung. Wobei On Premise erstmal genau das Gegenteil bedeutet. Damit sind die Exchange Server gemeint, die im eigenen Rechenzentrum stehen. Die Online gehosteten Resourcen würden dann entsprechend auf gleicher Ebene unter Online Services auftauchen.

Wir bewegen uns etwas tiefer auf die Organization Configuration. Hier gibt es zwei neue Punkte, die mehr oder weniger zum gleichen, neuen Feature gehören:

Mit den “Federation Trusts” läst sich ein Vertrauensverhältnis zu einem neuen, von Microsoft gehosteten Dienst aufbauen, dem Federation Gateway. Das Federation Gateway ist ein sogenannter Identity Broker. D.h. es hat nur eine einzige Aufgabe: mein Unternehmen als solches zu identifizieren. Zusammen mit den “Organization Relationships” und den “Sharing Policies”, baut man mit dem “Federation Trust” mit anderen Unternehmen eine Zusammenarbeit auf. Im Organization Relationship wird festgelegt mit welchem Unternehmen ich zusammenarbeiten möchte. So wird es einem Exchange Administrator leicht gemacht Frei/Gebuchtzeiten mit anderen Unternehmen auszutauschen und Kalender- und Kontaktdaten zu sharen.

All das ist wichtig, da Microsoft mit Exchange 2010 anstrebt zumindest zum Teil in die Wolke zu gehen. Und die Unternehmen sollen natürlich keinen Unterschied zwischen online gehosteten Mailboxen und den Mailboxen auf dem eigenen Server merken. Zum anderen sind Zusammenschlüsse von Firmen heute praktisch ander Tagesordnung und man möchte in diesem Fall so schnell wie möglich zusammenarbeiten.

Auf dem “Mailbox-Ast” schließlich findet sich die “Sharing Policy”, mit deren Hilfe genau festgelegt werden kann, welche Mailboxen welche Informationen mit den konfigurierten “Fremdfirmen” austauschen dürfen:

Auf der “General” Seite können Domeins hinzugefügt werden, mit denen man ein Organization Relationship konfiguriert hat. Dabei wird auch festgelegt, was genau ausgetauscht werden darf:

Das Datenbank Management ist vom Servertab nach oben ins Organizationtab gerutscht:

Das hat natürlich Gründe, denen wir uns in einem späteren Post widmen, zum Thema Database Availability Group (DAG). Hier sei nur erwähnt, dass es ab sofort keine Storage Groups mehr gibt und Datenbanknamen nun organisationsweit eindeutige Namen haben müssen.

Unter dem “Client Access-Ast” gibt es nun die Möglichkeit eine “Outlook Web App” Policy zu erstellen. Outlook Web Access heisst nun “Outlook Web App” in Anlehnung an die anderen Web Apps, die Microsoft mit Sharepoint 2010 bringen wird (z.B. Word für den Browser).

Die OWA (Akronym bleibt) Policy definiert, das was man in den Settings der CAS Webs schon mit 2007 einstellen konnte, z.B. welche Features dem OWA User zur Verfügung stehen sollen. Jetzt, mit der Möglichkeit mehrere Policies zu erstellen, kann ich User(gruppen) unterschiedlich behandeln.

Unter dem “Server Configuration” Tab gibt es nun die GUI Version des "Set-EventLogLevel” Cmdlets:

(Sieht irgendwie aus wie damals in Exchange 2003 ;-))

Außerdem hat man nun Wizards eingebaut, mit deren Hilfe der gesamte Zertifikatsrequest Prozess einfacher zu handhaben ist:

Unterhalb der “Recipient Configuration” auf dem “Mailbox Ast” kann man einem User nun per Rechtsklick auch eine Email schreiben. Das geht aber nur, wenn Outlook auf dem Exchange Server installiert ist:

Schaut man sich die Eigenschaften einer Resource-Mailbox an, fällt auf, dass auch hier einiges in die GUI gewandert ist, was bisher nur über die Kommandozeile erreichbar war:

Wenn eine neue Mailbox über die EMC angelegt wird, muss man nun nicht mehr zwangsläufig eine Datenbank angeben, Exchange sucht eine DB aus. Außerdem wird man nun beim Anlegen einer neuen Mailbox gefragt, ob für den User auch gleichzeitig eine Archivmailbox angelegt werden soll. Dabei handelt es sich um eine weitere Mailbox, die zusätzlich zur eigentlichen Mailbox in Outlook und OWA hinzugemappt wird und sich im Mailboxbaum ähnlich darstellt, wie ein PST File. Dem Thema Archiving widme ich später einen eigenen Post.

Wer “mitschreiben” möchte, was er als Exchange Administrator alles in der EMC anstellt, kann über “View/View Exchange Manament Shell Command Logging” alle von der EMC ausgeführten Powershell Befehle mitloggen, betrachten und anschließen in ein CSV exportieren:

Zu guter Letzt hat sich an der Art und Weise wie Mailboxen verschoben werden einiges geändert. Genau das schauen wir uns im nächsten Post an, dann geht es um lokale und remote Mailbox Moves.

Dreiklang aus Redmond: Wave 14

noreply@blogger.com (Jan Geisbauer) — Fri, 20 Nov 2009 07:42:00 +0000

Natürlich lohnt es sich immer die iX zu lesen, aber die Ausgabe von Dezember lohnt sich ganz besonders.

Sie befasst sich u.a. mit der sogenannten Wave 14, den 2010er Produkten von Microsoft. Dazu gibt es drei Artikel

- Outlook 2010
- Sharepoint 2010
- Exchange 2010

Nils Kczenski schreibt über das neue Outlook, Michael Greth hat den Sharepoint Artikel übernommen und Christian Segor und ich haben uns über Exchange 2010 ausgelassen.

Exchange 2010 – Teil 1 (Setup)

noreply@blogger.com (Jan Geisbauer) — Thu, 12 Nov 2009 19:44:00 +0000

Der Titel verät es. Hier soll eine Serie losgetreten werden. Mit der Verfügbarkeit von Exchange 2010 RTM möchte ich nun die Gelegenheit nutzen das Produkt hier im Blog näher zu beleuchten. Dazu habe ich mir eine kleine Testumgebung mit derzeit 4 Server aufgebaut, alle auf Basis von Windows 2008 R2:

- 1 x DC
- 3 x Exchange 2010

Die genauere Beschreibung findet in späteren Posts statt. Nun erstmal das Setup der ersten Exchange Maschine:

Vorbereitungen

In Windows 2008 R2 können alle Vorbereitungen für die Exchange 2010 Installation in der Powershell gemacht werden:

http://technet.microsoft.com/en-us/library/bb691354(EXCHG.140).aspx

Diese Features werden gebraucht, um CAS, HT und MB Rolle installieren zu können. Wir installieren alle drei.

4. Starten des Exchange 2010 Setups – Auswahl der Sprachen

Wir entscheiden uns nur die Sprachen zu installieren, die auf der DVD sind:

5. Start der Installation

6. Einführung

(Licensing und Error Reporting überspringen wir)

7. Custom Installation

8. Rollenwahl

9. Name der ORG

10. Erstmal keine Public Folder

11. Internet Facing Services

12. Readiness Check

13. Alles gut

Im nächsten Post schauen wir uns die EMC genauer an.

OWA Direct File Access und Windows Integrated

noreply@blogger.com (Jan Geisbauer) — Tue, 27 Oct 2009 16:04:00 +0000

(Editiert: ich verwende nun die Begriffe für die Authentifizierungsmethoden besser als im ursprünglichen Post)

Per Direct File Access kann man ja seit 2007 über OWA auch auf vom Admin freigegebene FileServer und Sharepoint Server zugreifen. Das funktioniert, wenn man auf “Documents” klickt:

Über “Open Location” kann dann ein Pfad zu einem Share oder eine URL eines Sharepoint Servers innerhalb des Unternehmens angegeben werden:

Das ganze funktioniert allerdings nicht auf Shares auf einem Remote Server (richtet man einen Share auf dem CAS ein, wird es gehen), wenn das virtuelle directory “OWA” auf Windows Integrated eingestellt ist, sondern nur, wenn es auf Basic oder Form Based Authentication (FBA) eingestellt ist. Warum?

Um dem OWA User die Services eines Fileservers oder Sharepoint Servers zur Verfügung zu stellen, muss der Exchange CAS mit den erwähnten Servern sprechen und ihnen hierfür erstmal die Credentials des Users unterbreiten. Das ist im Falle Basic und FBA Authentication kein Problem, da der Exchange Server Username/Passwort des Users hat.

Bei Windows Integrated / Kerberos sieht das anders aus. Der Exchange Server hat in diesem Fall nur ein Kerberos Ticket, das den User entsprechend berechtigt. Dieses Ticket kann er aber nicht ohne Weiteres an den Fileserver oder Sharepoint weitergeben. Dafür braucht es ein Feature names “Trusted for Delegation”. Das wird auf dem Computer Objekt des CAS Servers im AD eingestellt. Je nachdem in welchem Domain Functional Level man sich befindet, kann man das nur sehr grob oder explizit spezifizieren. Spezieller kann man das im Functional Level “Windows 2003” einstellen – wie das geht steht hier.

ExBPA schockt

noreply@blogger.com (Jan Geisbauer) — Thu, 08 Oct 2009 20:02:00 +0000

Neulich habe ich bei einem Kunden mit Exchange 2007 SP2 ein Schema update durchgeführt. Danach – wie es sich gehört – den ExBPA Readiness Check laufen lassen. Das Ergebnis: Keine großen Auffälligkeiten, alles gut … bis auf:

Beta 2 Servers? Ok, ich gebe zu ich habe für ein paar Sekunden durchaus emotional darüber nachgedacht, ob ich je Beta Bits von SP2 besessen habe und diese eventuell im falschen Moment am falschen Ort waren.

Allerdings hatte mir der ExBPA schon so manche Falschmeldung beschert – was mich stutzig machte. Also, ging ich mal etwas professioneller an die Sache – die aktuelle Exchange Schemaversion musste her. Diese findet man im Configuration Container:

CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration

Für das Exchange 2007 SP2 Schema sollte sich hier die Zahl 14622 finden, wie u.a. dieser Kollege hier beschreibt.

In Referenzforests mal nachgeguckt, stellte ich fest, dass der ExBPA die entsprechende Meldung schon immer bringt (SP1, RTM).

@Microsoft: bitte korrigieren – meine Haare werden schon von alleine weniger ! :-)

Saubere Message Header

noreply@blogger.com (Jan Geisbauer) — Wed, 23 Sep 2009 10:34:00 +0000

Ein Kunde kam gestern zum mir und hatte die Anforderung, dass interne IP Adressen und Hostnamen nicht im Messageheader bei Internetmails auftreten sollten. Eine kurze Recherche führte mich zu Amit Tank:

Das ganze funktioniert mit einer Methode namens “Header Firewall”. Dabei werden z.B. “Anonymous Logon” bestimmte Rechte entzogen – in unserem Fall “ms-Exch-Send-Headers-Routing”. Prinzipiell sollte es genügen, wenn man diesen Befehl auf den Internet Connector andwendet:

Remove-ADPermission –id “Name des Inet-Connectors” -AccessRight ExtendedRight -ExtendedRights “ms-Exch-Send-Headers-Routing” -user “NT AUTHORITY\Anonymous Logon”

Die Message-ID, die ja auch den Namen des Mailboxservers enthält bleibt natürlich trotzdem enthalten.

PowerShell Tips

noreply@blogger.com (Jan Geisbauer) — Wed, 09 Sep 2009 14:06:00 +0000

In den letzten Monaten hatte ich viel mit der Powershell – speziell mit der Exchange Management Shell – zu tun. In diesem Post möchte ich ein paar der dabei gewonnen Erfahrungen wiedergeben:

Was ich immer wieder falsch mache, wenn ich eine Weile nicht mit der PS gearbeitet habe ist, dass ich die Formatierungsangabe NICHT an das Ende eines Commands setze:

get-mailbox |fl identity | ?{$_.alias –like ‘test*’}

Das funktioniert nicht wie erwartet. Stattdessen wird einfach “nichts” ausgegeben, auch kein Fehler. Richtig macht man das so:

get-mailbox | ?{$_.alias –like ‘test*’} |fl identity

(ja, statt “where” kann man auch “?” schreiben).

Eine Übersicht über weitere Operatoren (“like”) findet sich hier:
http://www.microsoft.com/technet/scriptcenter/topics/msh/cmdlets/where-object.mspx

Wer kein Full-Time Entwickler ist und sich nicht täglich mit Objekten rumschlägt, kann sich mal anschauen, welche Möglichkeiten es gibt von der PS aus mit Objekten zu arbeiten:

$forest = [system.directoryservices.activedirectory.forest]::getcurrentforest()

Danach einfach mal $forest. eingeben und dann mit TAB durch die Properties und Methoden springen. Hier ist sicher einiges dabei, das man immer mal wieder brauchen kann.

Als Entwicklungsumgebung habe ich mir den PowerGUI Editor besorgt. Wer IntelliSense von VisualStudio kennt und sich in Powershell anschließend per Notepad(++) einen abgemüht hat, wird vom PowerGUI Editor begeistert sein. Die PowerGUI als solche ist ganz nett anzusehen. Damit kann man sich ein Script visuell zusammenklicken. Für mich bietet das aber keinen wirklichen Mehrwert. Aber der mitgelieferte Editor ist nicht mehr aus meinem Tools-Folder wegzudenken.

Funktionen werden in der Powershell anders aufgebaut als z.B. in C#. Das muss man wissen, denn es werden nicht zwangsläufig Fehler geworfen wenn man die Funktionen wie gewohnt aufbaut, aber deren Verhalten verändert sich :-)

function addiereAundB
{ param ([string]$A, [string]$B)
$Ergebnis=$A+$B
return $Ergebnis
}

CLI-XML

Export-cliXML und ImportcliXML sind sehr hilfreiche Werkzeuge:

Mit

get-mailbox testuser1 | export-clixml –path c:\testuser1.xml

exportiert man beispielsweise alle Settings einer Usermailbox in eine XML Datei. Die einzelnen Properties darin kann man anschließend wieder weiterverwenden:

$importXML = import-clixml c:\testuser1.xml

Anschließend kann man per $importXML.Alias z.B. den Alias aus dem exportierten XML auslesen.

Managed Folder Policy Gedanken

noreply@blogger.com (Jan Geisbauer) — Thu, 27 Aug 2009 12:16:00 +0000

Ein Kunde wollte eine Managed Folder Policy erstellen, die aus den “Deleted Items” alle Mails rauslöscht, die schon länger als 30 Tage in “Deleted Items” sind. Er war überrascht, als ich ihm nach kurzer Recherche sagen musste, dass das so nicht möglich ist:

Theoretisch könnte man annehmen, dass folgende “Managed Content Settings” genau dass tun:

Aber man irrt. Zumindest teilweise. Die Frage ist, was genau bedeutet die Einstellung “When item is moved to the folder” unter “Retention period starts”? Von “Natur aus” steht in der Mail ja nicht drin, wann eine Mail in welchen Folder verschoben wird.

Ich nehme an, dass für diese Information eine seperate Tabelle in der Exchange Datenbank gefüllt wird. D.h. erst nachdem man alle Managed Folder Policy settings durchgespielt hat (näheres weiter unten) werden zukünftig beim Verschieben von mails in “Deleted Items” Einträge in besagter Tabelle gemacht. D.h. aber auch, dass alle bisherigen Mails in “Deleted Items” – vor dem Konfigurieren der Managed Folder Policy Settings – NICHT von der Policy betroffen sind.

Möchte man auch die Bestandsdaten “angreifen”, muss man “When delivered … “ einstellen.

Allerdings zählt dann eben das Datum, an dem die Mail in der Inbox landete und dieses Vorgehen bringt unter Umständen nicht den gewünschten Effekt, da mails, die z.B. schon 40 Tage in der Inbox lagen und dann gelöscht werden, sofort auch aus den Deleted Items verschwinden.

Die vier Schritte zum Erfolg:

1. Managed Content Settings auf einem “Manged Folder (z.B. Deleted Items)” erstellen. Hier wird die Condition und die Action festgelegt (z.B. Delete nach 30 Tagen)

2. Neue Managed Folder Mailbox Policy (Die Verbindung zu den Manged Content Settings stellt der “Managed Folder” dar, mit dem die Policy assoziiert wird.

3. Die User Mailbox mit der neuen Mailbox Policy assoziieren (Mailbox Settings / Messaging Records Management)

4. Server Configuration / Server Eigenschaften / Messaging Records Management den Schedule einstellen, wie oft das Konfigurierte applied werden soll.
--> Alternativ: Start-MailboxFolderAssistant CmdLet (damit wird der Prozess manuell angestartet)

Wichtige Links zum Thema:

http://technet.microsoft.com/en-us/library/bb123548.aspx

http://exchangepedia.com/blog/2007/05/applying-managed-folder-policy-to-more.html

Des Königs neue Kleider

noreply@blogger.com (Jan Geisbauer) — Wed, 26 Aug 2009 10:02:00 +0000

Bei einem Kunden sollte in den letzten Tagen die Hardware eines Exchange 2007 CCRs getauscht werden. D.h. die Hardware beider Nodes sollte ersetzt werden. Das verlief alles recht reibungslos und ohne die geringste Unterbrechung für die User. Hier meine Vorgehensweise:

Node1 = active
Node2 = passive

1. Wir fangen mit Node2 an. Connect auf Node2 per ILO. Disablen aller produktiven Netzwerkkarten.

2. Den Node2 aus dem Clusterverbund nehmen: Im Cluster manager (Windows 2003) Rechtsklick auf den Node2 –> “Evict Node”. Der Node2 verschwindet aus dem Clusterverbund

3. Im Users und Computers Snap In Rechtsclick auf den Node2 (Computerobjekt) und “Reset”

4. Konfigurieren des neuen Node2 mit dem selben Netbios Namen, selbe IPs etc

5. Reboot des Node2 und rein in die Domain

6. Neuen Node2 dem Cluster hinzufügen: Rechtscklick auf Node1 und “New / Node”.

7. So, nun gibt es wieder einen Cluster mit zwei nodes. Fehlt nur noch Exchange. Also, Setup von Exchange 2007 starten und “Passive Clustered Mailbox Role” auswählen:

8. Nach der erfolgreichen Installation müssen die Storagegroups auf den neuen Node2 geseeded werden: Rechtsclick auf die Storagegroup und “Update Storage Group Copy”. Je nach Größe der DBs dauert das eine Weile.

9. Installation des Backup Agents und des Antivir.

10. Versuch eines ersten Failovers auf den neuen Node2

11. Adrenalinschub weil 10. nicht funktioniert und mit der Fehlermeldung “Cluster Node not found” abbricht.

12. Alle Resourcen im Cluster Manager gecheckt und festgestellt, dass die Resource für den Antivir als “Possible Owner” nur den Node1 gelistet hat.

13. Node2 als Possible Owner für den Antivir hinzugefühgt, neuer Versuch zum Switchen gestartet –> Erfolg.

Alles in Allem recht schmerzfrei :-)

Disconnected Mailboxes

noreply@blogger.com (Jan Geisbauer) — Fri, 21 Aug 2009 12:20:00 +0000

Oh mann. Immer wieder läuft man in die gleichen Fehler rein. Ein für alle mal: eine leere (Test-) Mailbox taucht nach dem Löschen NICHT in “Disconnected Mailboxes” auf (!).

Übrigens: falls mal “gefüllte” Mailboxen nach dem Löschen nicht in “Disconnected Mailboxen” auftauchen:

clean-mailboxdatabase –id DB-Name

Zweideutig

noreply@blogger.com (Jan Geisbauer) — Tue, 18 Aug 2009 11:49:00 +0000

Die Ambiguous Name Resolution (ANR) sorgt dafür, dass in Outlook per Ctrl+K in der TO, CC und BCC Zeile Namen aufgelöst werden. Tippe ich in der TO Zeile z.B. “geis”:

und drücke dann Ctrl+K wird mein Name gegen das AD aufgelöst:

Standardmäßig wird dabei gegen folgende Attribute gematched:

mailNickname
displayName
physicalDeliveryOfficeName
sn

Findet der String “geis” also in einem dieser Attribute seine Entsprechung (und ist diese Eindeutig), wird der Name aufgelöst.

Über das Schema Snap-In kann man weitere Attribute hinzufügen, die bei dieser Aktion gematched werden sollen. Dazu muss man zuerst die Schema Managment DLL registrieren:

regsvr32 schmmgmt.dll

Danach kann man das Schemamanagement in einer MMC hinzufügen:

Wie wir sehen könne, ist der ANR Haken für das Attribut “givenName” bereits gesetzt. Möchte man nun z.B. gegen “Department” auflösen, sucht man sich das Attribut und setzt den Haken entsprechend.

Speed up Outlook

noreply@blogger.com (Jan Geisbauer) — Thu, 30 Jul 2009 07:44:00 +0000

Wer eine große Mailbox hat und im Cached Mode arbeitet kann versuchen sein OST File zu defragmentieren um mehr Performance zu gewinnen. Zum Defragmentieren gibts was von “Mark Russinovich” –> Contig

Expand

noreply@blogger.com (Jan Geisbauer) — Fri, 24 Jul 2009 07:05:00 +0000

Gerade lese ich auf http://www.slipstick.com/ wie man per Powershell ALLE Smtp Adressen anzeigen kann:

Get-Mailbox | select -expand EmailAddresses | %{$_.SmtpAddress}

Etwas einfacher geht es auch so:

get-mailbox |select -expand emailaddresses |fl smtpaddress

OWA Sprache

noreply@blogger.com (Jan Geisbauer) — Fri, 03 Jul 2009 07:45:00 +0000

Ergänzend zum Artikel “Schrödingers Katze” möchte ich noch erwähnen, dass, falls das msExUserCulture AD-Attribute nicht gesetzt ist, die Spracheinstellung im Internet Explorer die entscheidende Rolle für die Default-Sprache spielen. Stehen die auf “deutsch”, wird per Default beim ersten Logon an OWA “deutsch” ausgewählt. Ist das msExUserCulture Attribut aber gesetzt, kommen die Browser-Settings nicht zum tragen:

Karsten on IT

noreply@blogger.com (Jan Geisbauer) — Mon, 29 Jun 2009 19:10:00 +0000

genau wie Marco, möchte auch ich darauf hinweisen, dass unser Kollege Karsten jetzt über MS Themen bloggt. Lohnt sich natürlich vorbei zu schauen:

http://blog.karstenkleinschmidt.de/

Outlook ist immernoch Kaputt

noreply@blogger.com (Jan Geisbauer) — Mon, 29 Jun 2009 17:16:00 +0000

Christian weist mich gerade auf eine Kampange hin, die dazu aufruft Microsoft klar zu machen, dass Word als HTML Renderer (für Outlook) suboptimal ist. Würde Outlook HTML Mails per Browser rendern, könnte z.B. auf HTML Tables verzichtet und CSS eingebunden werden. Gute Sache:

http://www.fixoutlook.org/

Branch Office auf Basis von Microsoft Hyper V

noreply@blogger.com (Jan Geisbauer) — Thu, 25 Jun 2009 07:31:00 +0000

Zu diesem Thema haben Professor Segor und ich mal wieder einen Artikel in der aktuellen (JULI) iX geschrieben:

http://www.heise.de/ix/inhalt.shtml

Schrödingers Katze

noreply@blogger.com (Jan Geisbauer) — Tue, 23 Jun 2009 18:39:00 +0000

Exchange System Messages sind keine DSNs (Delivery System Notifications). Eine System Message ist z.B. eine Mail, die von Exchange versendet wird, wenn die Mailbox voll ist (http://technet.microsoft.com/en-us/library/bb232173.aspx).

Der erste Connect eines Mapi Clients mit der Mailbox setzt auf dem Store in dem Property “PR_LOCALE_ID” den Language Code (z.B. 1033 für English-US). D.h., wenn sich z.B. ein deutscher Outlook client verbindet, wird in PR_LOCALE_ID der deutsche language code (1031) geschrieben.

Des Weiteren gibt es ein AD Proptery “msExchUserCulture” auf dem User Objekt, das ebenfalls Language Codes enthält. Dieses Property wird per “Set-Mailbox –Languages …” gesetzt und ist das per default auf “leer”. Auch wenn ein User zum erstenmal OWA verwendet und die Fragen nach den Regional settings beantwortet, wird dieses Property entsprechend gesetzt.

Wenn msExchUserCulture leer ist, werden System Messages in der Sprache versendet, die in PR_LOCALE_ID steht. Wenn msExchUserCulture gesetzt ist wird diese Sprache verwendet um System Messages zu versenden – egal was in PR_LOCALE_ID steht.

Das Attribut PR_LOCALE_ID kann man sich per Mapieditor anschauen. (Achtung: Damit das funktioniert, muss Outlook im Online Mode sein!). Der Mapieditor arbeitet ja so, dass man sich dafür ein MAPI Profil für die Mailbox anlegen muss, mit der man sich verbinden möchte. PR_LOCALE_ID wird bei jedem MAPI Connect neu geschrieben. Das Einrichten des Profils für den Mapieditor überschreibt also möglicherweise das Setting mit den lokalen Spracheinstellungen vom Outlook auf der Admin-Workstation. Der Beobachter beeinflusst also das Meßergebnis – ganz wie bei Schrödingers Katze :-)

Um das zu umgehen, kann man den Mapieditor vom entsprechenden User-Client aus laufen lassen.

Mehr Infos hier:

http://msexchangeteam.com/archive/2009/01/28/450532.aspx

Registry: Outlook Cached Mode ein/aus

noreply@blogger.com (Jan Geisbauer) — Tue, 23 Jun 2009 09:41:00 +0000

Damit ich nicht immer Carsten fragen muss:

HKCU\Software\Policies\Microsoft\Office\VersionsNummer\Cached Mode\Enable

Exchange 2010: Rpc auf CAS

noreply@blogger.com (Jan Geisbauer) — Thu, 04 Jun 2009 17:52:00 +0000

In Exchange 2010 verbindet sich ein MAPI Client nicht mehr wie in Exchange 2007 mit der Mailbox Rolle, sondern mit der CAS Rolle. Dies ist konsequent und sorgt –eventuell- auch für eine echte Ausfallsicherheit im Cluster-Fall:

Da bisher der Name des Mailboxservers im Outlookprofil stand, hat ein Outlook im Online-Mode bei einem Failover eines CCRs zumindest mal kurz gezuckt. In Zukunft (mit 2010) ist Outlook mit dem CAS verbunden. Somit bekommt der Client von einem Failover nichts mehr mit. Selbst das Verschieben der Mailbox ist jetzt möglich, (fast) ohne dass der User etwas davon mitbekommt (am Ende des Moves wird er dazu aufgefordert Outlook neu zu starten).

Exchange 2010 bringt den Vorteil mit sich, dass nun auch auf einem Cluster System (DAG = Database Availability Group) weitere Rollen mit installiert werden können. Dies war mit 2007 nicht möglich – ein CCR durfte nur die Mailboxrolle beinhalten.

So könnte man sich vorstellen, dass für mittlere Unternehmen ein System bestehend aus 3 Servern, die jeweils die CAS, MB und HT Rolle inne haben, ausreichend wäre.

Leider ist in einem solchen System die CAS Rolle nicht geclustered. D.h. man braucht doch wieder 2 seperate CAS Server, die dann über Windows NLB geclustered werden, oder – was eventuell auch gehen müsste: man verwendet einen externen (HW-basierten) Network Load Balancer, der gegen zusätzliche IPs für die CASe geht. Hierfür muss dann für die virtuelle IP Adresse ein DNS Record angelegt werden. Aber woher wissen die Outlook Clients, dass sie sich ab sofort gegen den neuen A-Record verbinden sollen?

Nun, es gibt ein neues Property für die Datenbanken (get- bzw. set-mailboxdatabase):

RpcClientAccessServer

Hier kann der (virtuelle) Name angegeben werden, der auf den CAS (bzw. auf die virtuelle IP des HW NLB) zeigt. Dieser Name wird dann entsprechend im Profil des Users upgedated. So wird also pro Datenbank (es gibt mit Exchange 2010 keine Storagegroups mehr) festgelegt, mit welchem CAS sich für den RPC Connect verbunden werden soll.