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:

Ü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

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

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

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

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

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

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