Sonntag, 22. November 2009

Exchange 2010 – Teil2 (Die GUI)

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”:

image

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:

image

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:

image

image

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:

image

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

image

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).

image

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:

image

(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:

image

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:

image

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:

image

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:

image

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.

Freitag, 20. November 2009

Dreiklang aus Redmond: Wave 14

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.

Donnerstag, 12. November 2009

Exchange 2010 – Teil 1 (Setup)

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



image



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



image



5. Start der Installation



image



6. Einführung



image



(Licensing und Error Reporting überspringen wir)



7. Custom Installation



image



8. Rollenwahl



image



9. Name der ORG



image



10. Erstmal keine Public Folder



image



11. Internet Facing Services



image



12. Readiness Check



image



13. Alles gut



image



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

Dienstag, 27. Oktober 2009

OWA Direct File Access und Windows Integrated

(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:

image

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

image

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.

Donnerstag, 8. Oktober 2009

ExBPA schockt

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:

image

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 ! :-)

Mittwoch, 23. September 2009

Saubere Message Header

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.

Mittwoch, 9. September 2009

PowerShell Tips

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.

Jan Geisbauer - About IT from Redmond and Elsewhere