Jan Geisbauer - About IT from Redmond and Elsewhere

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:

1. Rollen und Features installieren:

        1: Import-Module ServerManager

       2:  

       3: Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy –Restart

2. Reboot

3. NetTCPPortSharing auf Automatic Setzen

       1: Set-Service NetTcpPortSharing -StartupType Automatic
  

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.

SQL: Letzten fünf Einträge

noreply@blogger.com (Jan Geisbauer) — Fri, 15 May 2009 12:24:00 +0000

kleine Notiz gegen das Vergessen (Danke Marco):

Um die LETZTEN fünf einträge einer Table zu bekommen macht man einen TOP5 und stellt ihn auf den Kopf:

Select TOP 5 * from TABELLE
ORDER BY SPALTE DESC

Move Mailbox Manager

noreply@blogger.com (Jan Geisbauer) — Sat, 02 May 2009 12:16:00 +0000

Für einen großen Kunden mit deutlich über 70.000 Postfächern auf Exchange 2003 habe ich in den letzten Wochen ein sehr interessantes Teilprojekt gemacht. Davon möchte ich heute berichten.

Das gesamte Projekt geht darum Exchange 2003 abzulösen und Exchange 2007 einzuführen. Es gäbe sehr viel über die interessante neue Architektur, über Kosteneinsparung etc. zu erzählen, aber ich möchte mich mit dieser Erzählung auf ein “kleines” Teilprojekt konzentrieren, bei dem ich ein Tool entwickelt habe, um die ganzen Mailboxen zu moven. So viele Mailboxen zu moven bedeutet in erster Linie einen hohen logistischen Aufwand:

- verschiedene Zeitzonen rund um die Welt wollen bedacht werden
- die User sollen vor dem move automatisch informiert werden
- Resourcenpostfächer sollen als solche erkannt und als “Room” deklariert werden
- Postfächer von wichtigen Personen sollen erkannt und der Administrator gewarnt werden
- Es wurden im Vorfeld 4 neue Mailboxgrößen festgelegt, die anhand der aktuellen Mailboxgröße automatisch zugeordnet werden.

Außerdem sollte es drei Möglichkeiten geben, wie User, die gemoved werden sollen, definiert werden können:

- Import von CSV File
- Import per Distribution List (alle Mitglieder)
- Import von Exchange Datenbank(en)

Soweit die gröbsten Anforderungen. Ich entschied mich dazu mit Visual Studio eine GUI zu bauen, die Powershell Scripte für die Moves erzeugt. Die Powershell Skripte wollte ich dann per Windows Taskscheduler steuern. Gesagt getan:

(Ausschnitt)

Im oberen, linken Teil der GUI hat der Admin also die Möglichkeit über CSV, Distribution List oder von einer Exchange Datenbank Mailboxen in das Grid, ganz unten zu importieren. Während des Imports können verschiedene Filter applied werden, die oben rechts zu sehen sind. VIP Mailboxen oder Ressourcen können z.B. ignoriert werden und die Anzahl der Ergebnisse im Grid festgelegt werden.

Als nächstes gibt man in der “Finetune Move” Area an, aus welcher Region die Mailboxen kommen. Aus dem Ini File wird dann ausgelesen, zu welchen Zeiten Moves für diese Region erlaubt sind. Momentan unterstützt das Tool nur Moves von Mailboxen, die alle aus der selben Region stammen. Bald soll es auch über ein AD Property dynamisch auslesen können, woher die User stammen und die Moves dann entsprechend planen.

Prinzipiell hat man sich dazu entschieden alle Mailboxen über alle möglichen Target Datenbanken (Exchange 2007) zu verteilen. Das Tool holt sich also alle Exchange 2007 Server und alle darin enthaltenen Datenbanken schreibt sie abwechselnd in die TargetDB Spalte hinter den Usern im Grid. Die Inhalte des Grids werden dann in die entsprechenden Scripte gepackt und gescheduled. In den Optional Settings kann man dieses Verhalten aber auch umgehen, indem man sagt “Do not spread mailboxes accross databases”. In diesem Fall gibt man dann eine definierte target Datenank an.

Außerdem kann man einen LDAP Pfad angeben, in den die AD Objekte zusätzlich zum Mailboxmove verschoben werden.

Kommentare zur verwendeten Technik

Wie meistens, funktioniert natürlich nicht alles so reibungslos, wie man sich das gedacht hat. Die Mailboxen sollten natürlich multithreaded gemoved werden. D.h. man wollte nicht warten bis eine Mailbox gemoved ist, bevor der 2te Move startet. Dafür war die Anzahl der zu movenden Mailboxen einfach zu hoch und die dafür zur Verfügung gestellte Zeit zu knapp. Die einzige Möglichkeit Mailboxen per move-mailbox cmdlet multithreaded zu moven ist, indem man move-mailbox aus einem array von Mailboxen füttert und dann den “threads” parameter angibt – also ungefähr so:

$allUsers = import-csv c:\myusers.csv
$allUsers | move-mailbox –targetDatabase tdb –threads 10

Das funktioniert auch wunderbar. Nur: der –targetDatabase Parameter kann auf diese Weise nicht dynamisch angegeben werden. Vielmehr ist er für das gesamte Array gleich. Das heißt ich hatte entweder das Problem, dass die User nicht gleichmäßig auf alle (sehr vielen) Datenbanken verteilt wurden, oder das die Verteilung nicht multithreaded ablaufen konnte. Nun, ich klagte mein Leid dem Entwicklungschef meines Vertrauens. Und der hatte die rettende Idee: Wir erzeugen für jeden neuen Mailbox Move eine neue Powershell-Instanz die von der Mutterinstanz überwacht und nach Ablauf der max. erlaubten Duration abgeschossen wird. Je nachdem, wie viel Threads in der GUI angegeben werden, werden mehr oder weniger parallele Powershells aufgerissen.

Nach ein paar Schwierigkeiten mit Unicode hat das alles super geklappt.

Die Tasks im Windows Taskscheduler (Windows 2008) erzeuge ich übrigens über das eingebaute Schtasks.exe:

Ein Exchange Powershell Script aufzurufen ist schwerer als man das im ersten Moment erwarten würde. Z.B. ist das auch per Shortcut nicht ganz so einfach, wie ich schon einmal beschrieben habe. Wie man in dem oben abgedruckten Snippet erkennen kann, rufe ich auch nicht die Exchange Powershell sondern die “08/15” Powershell auf. Aber wie kann die normale Powershell ein Exchange Script ausführen? So:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

Wenn man diese Zeile in sein PS Script integriert werden die Exchange Erweiterungen automatisch geladen.

Wie man generell von C# aus mit der Exchange Powershell arbeitet wird hier gut beschrieben:

http://msdn.microsoft.com/en-us/library/bb332449.aspx

Eine Weile hatte ich mich gefragt, wie man Filter in cmdlets die man von C# aus aufruft applien kann ( | where{$_.gedöns –eq ‘gedöns’} ). Nun, ich glaube das geht nicht, aber man kann ganz einfach per IF Schleife filtern:

An der Stelle, an der man sich also durch die results des Powershell Commands hangelt, fragt man per if das zu filternde Property ab und agiert entsprechend.

So, das sollte genügen um einen Überblick und ein paar Tipps für ähnliche Vorhaben zu geben. Wen Details interessieren kann mich gerne ansprechen.

Exchange 2010

noreply@blogger.com (Jan Geisbauer) — Thu, 16 Apr 2009 19:45:00 +0000

Nun gibt es also die erste Beta vom neuen Messaging System von Microsoft: Exchange 2010 aka Exchange 14. Ich hatte vor einiger Zeit bereits die Gelegenheit mich intensiv mit Alpha-Bits von Exchange 2010 auseinanderzusetzen. Mein Eindruck ist: Exchange 2010 ist das Windows 2003 unter den Microsoft Messagingsystem Versionen. Mit Exchange 2007 kamen, ähnlich wie mit Windows 2000, all die revolutionären Neuigkeiten wie SAN-loses Clustering, Logfile Shipping im Allgemeinen, rollenbasierte Installation, 64bit support, starke IO – Verbesserungen, Unified Messaging und vieles mehr.

Genau wie Windows 2003 die revolutionären Verbesserungen von Windows 2000 “rund” gemacht hat, geschieht das nun im Messagingbereich durch Exchange 2010. Bereits die Alpha-Bits machten einen extrem ausgereiften Eindruck. Müssen sie auch, denn schließlich arbeiten mittlerweile 5 Millionen User produktiv damit. Gut, das sind keine Enterprise Kunden – aber die Zahl ist trotzdem beeindruckend.

Wenn man sich fragt, was das für “Beta-Mailboxen” sind, findet man ganz schnell den roten Faden, der die Entwickler und Program-Manager durch den bisherigen Entwicklungsprozess von Exchange 2010 geführt hat. Es handelt sich um gehostete Mailboxen oder auch “Online-Mailboxen”. Im Gegensatz zu den “On-Premise” Installationen, die auf den hauseigenen Servern laufen, sitzen die Online Mailboxen auf Servern von Microsoft. Ich hatte schon Anfang des Jahres darüber nachgedacht was es bedeuten würde, wenn plötzlich Firmenmailboxen von Microsoft gehosted werden. Nun, wie damals bereits berichtet, liegt der Erfolg der gehosteten Services in der Flexibilität.

Was heißt das? Ein Unternehmen hat natürlich unterschiedlich wichtige Mailboxen. Sicherlich kann man trotz (eventuellem) Misstrauen gegenüber dem Softwarehersteller nicht generell sagen, dass Unternehmen ein Problem damit hätten ihre Mailboxen auszulagern. Man möchte vielleicht nicht die Mailboxen von Entscheidungsträgern oder von der Forschungsabteilung auslagern, aber die Mailboxen der sogenannten “Blue-Colored-Workers”, der einfacheren Arbeitern also, könnten möglicherweise kostengünstiger gehosted werden. Genau bei diesen Mischszenarien setzt Exchnge 2010 an. Mit den “Federated Gateway Services” bietet Microsoft die Möglichkeit eine Art “Trust” zwischen den von Microsoft gehosteten Mailboxen und den “in-house” Mailboxen zu erstellen. Dies ist notwendig damit die User und Administratoren keinen Unterschied spüren zwischen von Microsoft gehosteten und “on-premise” Mailboxen. Auch die GUI (EMC) deutet diese Mischszenarien bereits an.

Die Leute hinter Exchange

Exchange ist eines der wichtigsten Produkte von Microsoft. 6000 Entwickler entwickeln für Exchange. 3000 davon entwickeln an Exchange 2010. 1500 davon entwickeln SP2 für Exchange 2007 und weitere 1500 entwickeln bereits jetzt das SP1 für Exchange 2010 (!).

Einige Neuigkeiten im Überblick

IO Reduktion

Exchange 2007 hat eine IO Reduktion von 70% gegenüber Exchange 2003 bewerkstelligt. Mit Exchange 2010 gibt es eine weitere Reduktion von 50% gegenüber 2007. Hauptsächlich tragen dazu die nun größeren Portionen bei, die auf einmal von der Platte gelesen werden.

MAPI gegen CAS

Da man einen Failover von einem aktiven auf einen passiven Node möglichst unbemerkt für den Client gestalten möchte, hat man die MAPI Connection des Clients vom Mailbox Server weg auf den CAS Server gelegt. (Um hier einen single point of failure zu umgehen, werden die CAS ge-load-balanced).

Archiving

Microsoft steigt ins Archiving ein. Kurz gesagt: es ist eine Version Eins. D.h. wer keinen riesengroßen Anforderungskatalog ans Archiving hat, wird möglicherweise zufrieden sein. Mit ausgereifen 3rd Party Produkten ist die Microsoft Implementierung allerdings nicht zu vergleichen. Natürlich wird sich das mit einem Service Pack oder mit E15 ändern. Generell sieht Microsoft aber auch größere Mailboxen beim User (10 GB). Durch Performance-Verbesserungen auf Client (ab Outlook 2007 SP2) und Server wird dies möglich sein.

RMS Rules

Auf dem Hub Transport gibt es nun (lang erwartet) Transport Rules mit denen RMS Templates applied werden können.

DAG – Database Availability Groups

CCR, SCC, SCR, LCR. Kann man nun alles vergessen. Die Features von CCR und SCR sind sozusagen in die Technologie von DAG gewandert. SCC und LCR gibt es gar nicht mehr. Die DAGs sind CCRs mit bis zu 16 Knoten. Dabei kann immer nur ein Knoten aktiv sein. Die Flexibilität ist dabei nahezu grenzenlos. So kann auf Server A die Datenbank A aktiv sein während sie auf Server B und Server C passiv ist. Hingegen kann die Datenbank B auf Server B aktiv und auf Server A und Server C passiv sein. Und so weiter. Es gibt somit keinen wirklichen active node mehr sondern nur noch einen Server mit einer oder mehreren active databases. Das ganze geht natürlich über AD Sites hinweg. Die Failover Zeit wurde dabei massiv verbessert. Dadurch, dass nun mehr als 2 nodes an einem Cluster teilhaben können, kann man schon von einem “Application RAID” sprechen. Tatsächlich spricht Microsoft davon, dass man ab 3 DAG nodes keine hardware Redundanz mehr braucht (RAID).

In den kommenden Wochen werde ich über weitere Neuigkeiten berichten.

Es ist soweit

noreply@blogger.com (Jan Geisbauer) — Wed, 15 Apr 2009 07:06:00 +0000

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=1898ed2c-2f88-48ac-824e-d3d20fad77d7

Exchange DB Size ohne WMI ermitteln

noreply@blogger.com (Jan Geisbauer) — Sat, 28 Mar 2009 17:08:00 +0000

Aber dafür mit Kraftmuschel:

Zuerst holt man sich eine Exchange Datenbank in eine Variable:

$myDB = Get-MailboxDatabase “mailbox database”

Dann holt man sich die Child-Items des Properties “EDBfilePath” der DB ebenfalls in eine Variable:

$myDBsize = get-childitem $myDB.EDBfilePath

und schon hat man:

$myDBsize.length

Microsoft Recite

noreply@blogger.com (Jan Geisbauer) — Sun, 22 Mar 2009 12:38:00 +0000

Aus sicherer Quelle weiß ich, dass der Sänger von De-Phazz (der Herr mit dem Bart) die Angewohnheit hat, Liedideen von unterwegs per Handy, auf den Anrufbeantwortet zuhause zu singen. Vermutlich ist de Verwaltung der Anrufbeantworter-Aufnahmen nicht so einfach. Microsoft Recite könnte ihm – und wie ich glaube auch mir – das Leben leichter machen. (nicht dass ich zuhause auf den Anrufbeantworter singe, aber Ideen hat man oft im Auto – oder?!).

Recite erlaubt es Sparchnachrichten aufzunehmen und diese auch per Sprache zu durchsuchen. Natürlich alles noch Beta und US ONLY.

Wer trotzdem mehr darüber wissen möchte klickt hier: http://blogs.msdn.com/recite/archive/2009/02/15/announcement-microsoft-recite-technology-preview.aspx

Direkt oder per Agent

noreply@blogger.com (Jan Geisbauer) — Tue, 17 Mar 2009 21:06:00 +0000

Vor einiger Zeit wurde ich gefragt, warum Exchange 2007 eigentlich nicht mehr dieses praktische Pop-Up bringt, das einen schon vor dem Versenden eines Meeting-Requests darüber informiert, dass der gewünschte Raum bereits belegt ist:

Stattdessen lässt einen Exchange 2007 die Ressource munter buchen und man wiegt sich sekundenlang in der Sicherheit endlich Zuflucht aus dem grauen Großraumbüroalltag gefunden zu haben. Aber dann: bereits nach kurzer Zeit belehrt einen eine beinahe anonyme Mail in der Inbox eines Besseren.

Nun, kurz gesagt, das ist kein Exchange 2007 “Feature”. Es gibt einfach zwei Möglichkeiten eine Ressource zu managen:

1. Direct Booking
2. Auto Accept Agent

Das war schon mit Exchange 2003 so. Direct Booking (Pop-up VOR dem Versenden) verlangt eine Konfiguration im Profil der Ressource Mailbox:

Tools/Options/Calendar Options/Resource Scheduling:

Während der Auto Accept Agent es nicht nötig macht, dass sich der Admin ein Profil für die Ressource anlegt um selbige zu konfigurieren. Der Auto Accept Agent bringt auch so nette features wie “delete attachments”.

Leider ist es auch mit Exchange 2007 noch so dann man nicht beides haben kann.

Ein Gegenüberstellung der beiden Möglichkeiten findet sich hier: http://msexchangeteam.com/archive/2007/05/14/438944.aspx