Jan Geisbauer - About IT from Redmond and Elsewhere

killPeople.ps1

noreply@blogger.com (Jan Geisbauer) — Fri, 30 Aug 2013 10:35:00 +0000

psGalSync

noreply@blogger.com (Jan Geisbauer) — Thu, 21 Feb 2013 15:54:00 +0000

Es ist nicht das erste Mal, dass ich bei einem Kunden den Auftrag habe einen Sync Process zwischen zwei Exchange Organisationen einzurichten. Mailboxen und Mailuser auf der einen Seite sollen zu Kontakten auf der anderen Seite werden. Wenn sich die Quell-Objekte verändern oder gelöscht werden muss die Gegenseite diese Änderungen entsprechend widerspiegeln.
Es gibt eine Menge Tools da draußen, die diese Aufgabe erledigen. Aber: sobald auch nur ein Hauch an Flexibilität gefordert wird (z.B. ein Exclude-Filter auf die zu synchronisierenden Objekte -> keine Mailboxen die im ExtensionAttribute9 den Wert "VIP" stehen haben) wird die Auswahl an zumindest kostenlosen Lösungen dünn.
Andere wiederum erwarten vom "einfachen" Consultant oder Admin dass er eine nicht ganz triviale Erweiterung schreibt. Der eingebaute GalSync von FIM (Forefront Identity Manager) z.B. schreibt einem vor, wie der Remote PowerShell Connect in die fremde Org abzulaufen hat. Hier hat man keinen Einfluss auf Authentifizierungsmechanismen (Kerberos ist Pflicht) oder auf andere Optionen, wie "Ignore CRL-Checking". Das erschwert den Verbindungsaufbau durch eine Legion an Firewalls und anderen Gemeinheiten. Dabei geht das Ganze in den meisten Fällen eh nicht durchs Internet, sondern wird irgendwo auf der Strecke durch ein VPN geroutet und bringt somit schonmal ein schönes Maß an Sicherheit mit.

Also, hab ich mir gedacht - warum sich mit den Tools anderer rumschlagen, wenn man sowas auch relativ einfach selbst bauen kann und damit ein Maximum an Flexibilität gewinnt. Gesagt, getan - hier ist psGalSync:

psGalSync ist ein PowerShell script das ein Active Directory nach einem anzugebenden LDAP Filter durchforstet und die gefundenen Mail User und Mailboxen mit denen aus einer bestimmten OU im fremden Forest vergleicht und die Unterschiede entsprechend anpasst.

Das ganze geht immer nur in eine Richtung. D.h. wenn Unternehmen A seine Mailboxen zu Unternehmen B synced ist das eine Richtung. Will man auch von Unternehmen B zu Unternehmen A syncen, muss man eine zweite Instanz von psGalSync auf der Seite von Unternehmen B etablieren.

Für das Provisionieren wird lediglich remote PowerShell verwendet - also kommt man mit Port 443 bzw. 80 (falls man das wirklich will) aus. Welche Möglichkeiten es gibt Remote PowerShell Verbindungen aufzubauen steht u.a. hier.

psGalSync nimmt folgende command line Attribute:

Cmd Attribut	Kurz	Kommentar
ExportSource	ES	Es wird nur eine Export des lokalen ADs in ein Textfile gemacht. (In Abhängigkeit zum LDAP filter).
ExportTarget	ET	Es wird ein Export des Ziel ADs in ein Textfile gemacht (von der angegebenen OU)
ExportOnly	EO	Macht beide der eben beschriebenen Schritte
ProvisioningOnly	PO	Erwaret “outputsource.txt” und “outputtarget.txt” im root Folder. Provisioning wird in der remote Org durchgeführt.
FullRun	FR	Es werden alle drei bisher erwähnten Schritte durchgeführt.
ManualSync	MS	Hier werden keine Exports gefahren. Es wird lediglich ein angegebener User gesynced. (dessen SamAccountName muss angegeben werden): psGalSync ms samAccountName

Abb 1: Command Line Attribute

Exportieren von der Quelle (z.B.: psGalSync ES)

psGalSync exportiert aus dem lokalen AD mit der adsisearcher Funktion (darauf hat mich erst kürzlich Frank aufmerksam gemacht). Der LDAP Filter hierzu kann nach Belieben verändert werden. Die entsprechenden User müssen eine Email Adresse haben.
Die User werden in ein File exportiert, das "outputsource.txt" heißt. Darin befinden sich alle relevanten Informationen zum jeweiligen User - semikolon-getrennt:

objectGUID, Mail(WindowEmailAddress), Name, Givenname ,sn (Lastname), initials, displayname, title, mobile, facsimile (Fax), phone, homephone, streetaddress, l (City), postalcode, co (Country), st (StateOrRegion), Company, department

Wie man sehen kann, wird "proxyAddresses" nicht gesynced. Meiner Meinung nach sollte das Mail Attribute in den meisten Fällen genügen.

Hier ein Beispiel aus "outputsource.txt":

87-6E-3D-BF-6D-59-5C-42-A7-A4-E8-CD-A7-88-B3-C8,Testuser1@company.com; Testuser1;Test;;;User1;;;Heidelberg;;;;;;;;

Wie man sehen kann sind hier nur ein paar Attribute gefüllt, andere sind leer.

Primary Key

Die Mailbox Guid wird hier sozusagen als "Primary Key" verwendet. Diese wird auf dem Kontakt auf der Gegenseite ins "Notes" Feld geschrieben, damit dieser der entsprechenden Mailbox auf der Source zugeordnet werden kann (alle anderen Properties inkl. der Email Adresse können sich ja theoretisch ändern).

Exportieren aus dem Ziel (z.B.: psGalSync ET)

Der Export aus dem Ziel erfolgt über das Cmdlet "get-contact" Alle Attribute, aller Kontakte werden in das File "outputtarget.txt" geschrieben.

Provisionierung (z.B.: psGalSync po oder psGalSync fr)

Nachdem sowohl das Source File als auch das Target File exportiert wurden können wir mit dem Provisioning beginnen. Zuerst werden hierbei beide Files in ein Dictionary geladen um besser verglichen werden zu können. Danach foreach-en wir durch das Source Dictionary und überprüfen ob die jeweilige objectGuid auch im Target File existiert.

Wenn sie existiert werden die beiden Zeilen (aus dem Source- und aus dem Target File) verglichen. Wenn die gleich sind, ist alles gut - keine weitere Action. Wenn sie sich unterscheiden, wird ein Set-Contact im Remote Forest durchgeführt, um den Kontakt auf den aktuellen Stand zu bringen.
Wenn die Zeile aus dem Source File im Remote File nicht gefunden wird, wird ein "new-MailContact" ausgeführt und der Contact damit angelegt.
Das gleiche gilt, wenn die Zeile nur im Remote File zu finden ist und nicht mehr im Source File - dann wird eben eine Löschung des Kontakts angestoßen.

R I S I K O

Wenn - aus irgendeinem Grund - das Source File leer wäre, oder nur einige der User darin gelistet wären (z.b. wenn der Export irgendwie unterbrochen würde) und das Target File voll gefüllt wäre, würde das Script annehmen die fehlenden User existierten nicht mehr und würde die Kontakte der fehlenden User im Remote Forest löschen.

Um dieses Risiko etwas abzumildern, kennt das Script zwei "Versicherungs-Variablen":

$maxSimDeleteCount

Diese Variable gibt an, wieviel Kontakte auf einmal gelöscht werden dürfen. ABER: angenommen der Wert ist auf 100 gesetzt, bedeutet das, dass bei jedem Run des Scripts 100 Kontakte gelöscht werden dürfen. Also, immer schön die Logfiles lesen!

$expectdSourceOutputLength

Einen zweiten Weichmacher stellt diese Variable dar. Man weiß ja ungefähr wie viele Mai Objekte bei einem Export aus dem lokalen AD zu erwarten sind. Die entsprechende Zahl minus einen Schwellenwert schreibt man in diese Variable. Wenn man also z.B. 13.000 Objekte hat kann man 11.500 reinschreiben - somit wird das Script nicht laufen, wenn im Source File weniger als 11.500 User gelistet sind.

Apropos Logfile lesen: Das Skript verschickt auch Mails mit den wichtigsten Informationen zum letzten Lauf. Ganz nett, kann den Blick ins Logfile aber trotzdem nicht ersetzen.

Was heißt hier eigentlich RISIKO? Was soll der ganze Aufwand? Sind die Kontakte auf der Gegenseite gelöscht, erstell ich sie einfach wieder! Bei diesem Denkansatz gibt es ein kleines Problem:

Wenn ein Kontakt gelöscht wird und muss wieder angelegt werden, so erhält er einen neuen legacyExchangeDN. Hier müssen wir mit den bekannten Reply-Problemen wegen dem Outlook Cache rechnen.

Aus diesem Grund schreibt psGalSync beim Löschen eines Kontakts auch dessen legacyExchangeDN ins Logfile. Im Notfall kann so eine entsprechende X500 Adresse angelegt werden.

Konfiguration des Scripts

Wenn das Script über ein Batch File gescheduled werden soll, muss man die Credentials für den Remote Connect irgendwo speichern. Dazu erzeugt man sich einen Secure String:

read-host -assecurestring | convertfrom-securestring | out-file C:\securestring.txt

Am hierauf folgenden Prompt muss man das Passwort für den Account im Remote Forest eingeben. Dieses wird dann in verschlüsselter Form in der angegebenen Text Datei gespeichert und von psGalSync ausgelesen.

(Achtung: das Passwort wird gegen das Passwort des gerade angemeldeten Users verschlüsselt. Jeder der dieses kennt, kann auch das Passwort des Remote Forests "recovern").

Nun würde ich mit folgendem kleinen Script testen, ob eine Remote Verbindung überhaupt möglich ist:

$connectionURI = "https://remoteURL/PowerShell"

$username="domain\serviceAccount"

$password = cat C:\securestring.txt | convertto-securestring

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $password

$rs = new-pssession -conf Microsoft.Exchange -conn $connectionURI -auth basic -cred $cred

Import-PSSession $rs

Wenn der Remote Powershell Connect erfolgreich durchgeführt werden kann, wird auch psGalSync funktionieren.

Die connectionURI, der UserNamen und die Lokation des Secure String Files müssen im Config-Bereich von psGalSync angepasst werden.

Wenn man den Parameter $debug=$true setzt, wird nur ein Logfile erzeugt, keine Kontakte werden erzeugt oder verändert.

Alle anderen Parameter sollten selbsterklärend sein, bzw erschließen sich aus den Beispielen im Code.

Log Files und Archiv Files

Das Script erzeugt im Root Verzeichnis einen Archive und einen Logs Ordner. Wie nicht anders zu erwarten, werden die Log Files im Logs Ordner abgelegt und die Outputsource.txt und Outputtarget.txt im Archive Ordner.

Schedulen

Möchte man das Ganze über den Taskscheduler (na, wie könnte man da jetzt sagen ... mir fällt nix ein also doch:) schedulen erzeugt man am Besten ein Batch file mit z.B. folgendem Inhalt:

powershell -command "d:\scripts\psGalSync.ps1 fr"

Performance + Erfahrung + Warnung

Ich habe psGalSync seit einigen Monaten im produktiven Einsatz. Es funktioniert sehr zuverlässig und ist auch recht schnell. Sind die Objekte erstmal initial in-sync, dauert es z.B. bei 90.000 Objekten < 2 Stunden bis alles durch ist.

Natürlich muss man das alles sehr gut testen bevor man es selbst in einer Produktivumgebung einsetzt. Jeder muss sich selbst von der Funktionstüchtigkeit überzeugen und handelt dann am Ende eigenverantwortlich.

In diesem Sinne: Viel Spass damit :-)

Download

Hinter den 7 Bergen bei den 7 Zwergen: PowerShell von ganz weit weg

noreply@blogger.com (Jan Geisbauer) — Fri, 16 Nov 2012 12:30:00 +0000

Eigentlich ein alter Hut. Aber ich musste mich im Rahmen eines Projektes mit Remote-PowerShell beschäftigen und stieß dabei auf einige Probleme:

Prinzipiell braucht man Windows 7 und höher oder Windows 2008 und höher um mit Remote PowerShell arbeiten zu können. Für Exchange muss dann außerdem noch der Remote-User entsprechend berechtigt werden, damit er den Exchange Server von Remote administrieren darf:

set-user jan.geisbauer -RemotePowerShellEnabled $true

Am einfachsten nimmt man daraufhin den Weg der Piraten und entert eine Session:

Enter-PSSession -ConnectionURI http://CAS-Server/PowerShell -Credentials $C -Authentication Kerberos (-SessionOption $SO)

Das funktioniert innerhalb einer Domain (Client und Remote Computer sind in der selben Domain) sehr gut. Ist aber der Client nicht in der selben Domain wie der Server, fangen die Probleme an:

Für die Authentication kann man entweder "Kerberos" oder "Basic" wählen.

Basic

Wählt man "Basic" und gibt die ConnectionURI mit http statt mit https an, bekommt man den dezenten Hinweis, dass "unencrypted traffic" nicht erlaubt sei und man dies erst konfigurieren müsse. Gibt man die URI mit https an, lauern andere Probleme: Per default will die PowerShell die Certificate Revocation List (CRL) des dabei verwendeten Zertifikats überprüfen. Das schlägt oft fehl, weil das über Domain (Forest) Grenzen hinweg nicht sauber gepublished ist oder ein Proxy einem in die Suppe spuckt. Entweder man überwindet also diese Hürden oder man schaltet den CRL Check aus:

$SO = New-PSSessionOption -SkipRevocationCheck

(Man kann sich die anderen Optionen dieses Cmdlets genauer ansehen und findet ggf. noch weitere "Skips")

Kerberos

Kerberos wirft eine Fehlermeldung "No Logon Servers Available" wenn man versucht von einem nicht-domain Client aus der Ferne auf eine PowerShell Session zuzugreifen. Um diesen nicht vertrauenswürdigen Clients den Remote-Zugriff zu erlauben, muss man sie als "Trusted Hosts" konfigurieren:

set-item WSMan:\localhost\Cient\TrustedHosts -value ComputerName

So klappt dann der Remote-Zugriff mit Kerberos Authentifizierung.

Ansonsten müssen natürlich die entsprechenden Netzwerk Ports offen sein und die Verbindung stehen. Für die Kerberos Authentication braucht man schonmal Port 88 (TCP/UDP) und vermutlich auch 389 (LDAP). Außerdem muss die DNS Name Resolution durchgehen (Port 53) und die PowerShell braucht für die eigentliche Arbeit auf dem IIS Port 443 oder 80.

In meinen Test reichte es nicht auf den beiden Systemen mit Hosts File Einträgen der jeweils anderen Domain zu arbeiten. Vermutlich braucht man die Möglichkeit SRV Records aufzulösen. Ich habe mir dann Conditional Forwarder für die jeweils andere Domain eingerichtet.

Gegen langsame PowerShell AD Abfragen

noreply@blogger.com (Jan Geisbauer) — Fri, 02 Nov 2012 12:58:00 +0000

Das AD PowerShell Module (Import-Module ActiveDirectory) ist sehr einfach zu handhaben. Will man jedoch große ADs damit durchsuchen und muss zeitkritische Aufgaben erledigen ist es zu langsam. DSQuery beispielsweise ist hier viel schneller. Wie man eine "DSQuery" einfach in sein PowerShell Script integriert, zeige ich hier:

$cmd = "dsquery"
$arg1 = "(&(objectcategory=user)(objectclass=user)(samAccountName=" + $varSamAccountName + "))"
$arg2 = "mail"
$arg3 = "200000"
$resultTemp = & $cmd * domainroot -filter $arg1 -attr $arg2 -limit $arg3
$result = $resultTemp[1].trim()

$varSamAccountName nimmt also vom PowerShell Skript einen SamAccountName entgegen, nachdem im AD gesucht werden soll. das "$arg2" wiederum gibt das Attribute an, welches zurückgegeben werden soll - in diesem Fall die WindowsEmailAddress (mail).

eine Besonderheit von dieser Methode ist, dass DsQuery, die Ergebnisse "nicht sauber" zurück gibt, sondern vor und nach den jeweiligen Strings noch ein paar Leerzeichen hinzufügt. Will man die Werte entsprechend weiterverarbeiten, muss man sie vorher mit "trim()" bearbeiten. Außerdem gibt DsQuery immer eine Liste zurück. Da sind (vorausgesetzt es wird überhaupt etwas zurück gegeben) mindestens zwei Werte drin: die Überschrift und der Wert:

mail
jan.geisbauer@somewhere.de

Da uns nur der eigentliche Wert interessiert, gehn wir in der Liste gleich an den zweiten Wert: [1].

Mein digitales Leben 2011

noreply@blogger.com (Jan Geisbauer) — Sun, 18 Dec 2011 13:14:00 +0000

Klingt großspurig, soll aber zum Ende des Jahres nur ein wenig beschreiben wie weit die Suche nach der perfekten Verzahnung zwischen dem wirklichen und dem digitalen Leben fortgeschritten ist. Das macht es nicht weniger großspurig, aber darum geht es doch schlußendlich: wir suchen nach Möglichkeiten, nach Techniken und Geräten, die sich so "seamless" in unser Leben integrieren, dass man sie dabei kaum bemerkt. Durch sie soll unser Leben einfacher werden, dank ihnen sollen wir uns weniger Sorgen machen müssen und mehr Freude erleben.

Wir wollen Telefone, mit denen wir unsere Emails lesen können und mit denen wir Musik hören können. Wir wollen von jedem Gerät auf die gleichen Daten zugreifen können ohne am Vortag daran denken zu müssen irgendeinen Sync-Prozess anzuwerfen. Wir wollen schicke, leichte Anzeigegeräte mit uns führen und trotzdem auf geballte CPU/RAM Power zugreifen können. Die Entwicklung im Hardware und Software Bereich wird immer schneller und genauso schnell wachsen unsere Wünsche nach weiteren neuen Möglichkeiten, die uns erst die nächste oder übernächste Entwicklungsstufe erlauben.

Aber ist das so schlecht wie es vielleicht manchmal klingt? Ich glaube nein. Vielmehr ist diese Haltung das Natürlichste was es gibt. Verbessert sich die Natur selbst nicht ständig? Passt sich an widrige Bedingungen an, optimiert, verändert, tauscht aus. Letztendlich ist das alles tierisch spannend, das Neue, die Entwicklung.

Wollen wir also mal sehen, wo wir gerade stehen:

Ich habe mich Anfang des Jahres für einen neuen Arbeitslaptop entschieden, einen Samsung 900X. Das ist im Prinzip ein Klon des Mac Book Air, ein Anzeigegerät. Genau das Richtige für unterwegs, und genau das Gegenteil der Backsteine, die ich zuvor durch die Gegend geschleppt habe. Wie wir oben gesehen haben, bringt jede Neuerung sofort einen weiteren Wunsch mit sich: der Samsung ist zwar schick und leicht, eine 10-köpfige VM Umgebung lässt sich damit aber nicht aufbauen. Also habe ich meine Powerworkstatiom zuhause über die Fritzbox nach draußen gepublished und wecke sie bei Bedarf aus dem Dornröschenschlaf.

Arbeitsorganisation

Mit Outlook organisiere ich meine Emails, meinen Kalender, die Kontakte und Aufgaben. All das wird automatisch per Activesync auf das iPhone und seit Neustem auch auf das iPad synchronisiert. Fällt mir nach Feierabend oder unterwegs noch eine Aufgabe ein, trage ich sie auf einem der Devices in die Taskliste ein und kann sichergehen dass sie damit a) aus meinem Kopf ist und b) am nächsten Tag wieder auftaucht und bearbeitet werden kann.

Mitschriebe bei Meetings und andere Notizen sammle ich in Onenote, das meines Erachtens all den anderen Notizbüchern überlegen ist. Seit letzter Woche gibt es jetzt auch eine iPad App dafür. Wenn ich irgendwo eine wichtige Konfiguration vorgenommen habe, dokumentiere ich diese ebenso per Screenshots darin, wie wenn ich eine Lösung für ein Problem gefunden habe. Onenote wird so über die Jahre zu meiner persönlichen Knowlegebase. Aus dem ein oder anderen Onenoteeintrag wird dann auch mal ein Blogartikel. Die Onenote Seiten werden im Hintergrund automatisch in die Microsoft Cloud gesynced, so dass sie auf allen Geräten verfügbar sind.

Alle weiteren Dokumente werden über die Dropbox auf allen Rechnern gleich gehalten. Auch meine (neusten) Bilder sind in der Dropbox und belegen damit auf dem iPad keinen Platz, sondern lassen sich bequem über WiFi auf das Gerät streamen. Mit 3G ist das dann natürlich weniger lustig. Will man also unterwegs (ohne highspeed Internetverbindung) Bilder zeigen, muss man diese etwas mühsam, eins ums andere offline nehmen. Dass die gesamte Bilderhistorie meines Lebens noch nicht in der Cloud ist, liegt schlichtweg am verfügbaren Speicherplatz (bzw. Am Preis dafür).

Musik

Mit iPhone und Apple TV wurde schon Vieles vereinfacht. Und doch musste immer noch gesynced werden und man hatte auf dem einen Rechner einen anderen Stand als auf dem anderen USW. Immerhin hatte man im Auto eine Bluetooth Schnittstelle, konnte man sogar dort auf die selbe Musikquelle zugreifen wie zuhause. Mit iTunes Match ist das aber nochmal ein Stück cooler geworden. Jetzt entscheidet man auf jedem Abspielgerät welche Titel man lokal speichern möchte und welche nicht. Potentiell hat man aber Zugriff auf alle CDs. Apple TV greift sogar gleich auf die Cloud zu und spielt direkt von da ab(was eigentlich für die anderen Devices auch eine Option sein könnte).

Information

Der Browser meiner Wahl ist Chrome und leider (noch) nicht auf den iOS Geräten verfügbar. Chrome ist, klar, schlank, schnell und simpel. Außerdem synced (auch) er meine wichtigsten Bookmarks, die ich nahezu täglich checke. Neben den wichtigsten IT Portalen gehört auch der Google-Reader dazu mit dem ich meine abonnierten Feeds konsumiere. Interessiert mich ein Artikel, habe aber keine Zeit ihn gleich zu lesen, merke ich ihn per Instapaper für später vor. Dabei spielt es keine Rolle mit welchem der erwähnten Geräte ich mich später beschäftige, der Artikel wird entsprechend gesynced.

Ebenso verfahre ich mit politischen oder sonstigen Nachrichten. Fast alles lese ich inzwischen online. Nur abends im Bett, ist mir ein Buch aus Papier immer noch lieber, aber wer weiß, vielleicht ist auch das nur eine Frage des richtigen Geräts.

Wir sind also schon ganz schön weit. Die digitale und sie reale Welt verzahnen sich immer mehr. Für uns bedeutet das auch Disziplin. Disziplin Abstand zu nehmen, die ganzen neuen Gerätschaften und Techniken als Werkzeuge zu sehen, nicht zu sehr an ihnen zu hängen, ihnen nicht zuviel Platz einzuräumen und stattdessen immer mal wieder zur Ruhe zu kommen und sich zu besinnen, dass das doch alles bloß ein großer Spass ist.

In diesem Sinne, frohe und ruhige Weihnachten.

CAS Proxying News

noreply@blogger.com (Jan Geisbauer) — Fri, 23 Sep 2011 13:37:00 +0000

Es gibt einen Technet Artikel, der wohl (noch) eine falsche Information enthält:

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

Darin steht:

If an Active Directory site is the target of an Outlook Web App or ECP proxy request from a Client Access server in any other Active Directory site, the InternalURL property for the /OWA and /ECP virtual directories on all Client Access servers in that Active Directory site must be set to the FQDN of the server. This is because Outlook Web App and the ECP use only Kerberos authentication, which will fail if the InternalURL property is set to a load-balanced value. Client Access server applications such as Outlook Web App and the ECP ignore the certificate settings when they perform proxy connections between Client Access servers. Therefore, individual server names on the certificate aren't needed for proxy purposes.

Das würde bedeuten, dass die InternalURL eines “Target-CAS” auf den Server FQDN gesetzt werden muss. Das wiederum hieße, dass die Target-Site nicht hochverfügbar ausgelegt werden könnte, da in diesem Fall die InteralURL auf die Loadbalancer URL gesetzt werden muss. Das ist aber falsch. Aber der Reihe nach:

Angenommen eine Firma hat nur einen Internet Break-Out für die weltweite Organisation. Man möchte z.B. nur mit einem Namespace für OWA (ActiveSync, etc.) nach aussen auftreten. Man wird also in der Hauptlokation, sagen wir mal, Frankfurt, ein CAS Array aufbauen und das durch einen (Hardware-) Loadbalancer ausfallsicher machen. Gehen wir mal davon aus, dass es nun noch eine weitere Niederlassung des Unternehmens in USA gibt. Auch dort möchte man eine ausfallsichere Infrastruktur aufbauen. Das bedeutet, dass man auch dort ein CAS Array installiert und ihm ein Hardwareloadbalancer vorschaltet. Um das ganze zum Fliegen zu bringen, muss man die InternalURL der CAS Server auf die URL des Loadbalancers setzen.

Eben dies “untersagt” aber der Technet Artikel, den ich oben zitiert habe. Wie gesagt, das würde bedeuten, dass eine “Proxy-Site” (für OWA und ECP) niemals hochverfügbar sein kann.

Warum ist das zwingend so das laut dem Technet Artikel die InternalURL auf den FQDN des Servers gesetzt werden muss? Microsoft begründet das mit einem Kerberos Problem. Kerberos braucht zwingend den FQDN des Zielservers.

Da ich in einem Projekt exakt dieses Problem habe, habe ich mal bei Microsoft nachgefragt und als Antwort erhalten, dass dies (was in dem Technet Artikel steht) nun nicht mehr zutreffen würde. Man könne auch in einer Proxy-Site, die InternalURL auf die des Loadbalancers setzen. Wenn Kerberos fehlschlägt, springt Exchange 2010 automatisch auf NTLM zurück.

Schaun wir mal wann der Artikel geändert wird …

Windows 8 – Die grüne Revolution (Teil 1)

noreply@blogger.com (Jan Geisbauer) — Fri, 16 Sep 2011 08:07:00 +0000

Laut Microsoft die größte (Microsoft-) Betriebssystem Revolution seit Windows 95. Auf alle Fälle ein Grund sich die erste öffentliche Beta mal genauer anzusehen. Los gehts:

Es kursieren anscheinend unterschiedliche ISOs im Netz und scheinbar hatte ich wie einige andere auch zuerst einmal eine, die bei der Installation immer wieder nach einem Treiber schrie. Ich bin dann den (sicheren) Weg über die MSDN Downloads gegangen – und siehe da – das Image ließ sich ohne Probleme installieren.

Das erste was auffällt – Windows wird grün:

Das hat erst einmal nur optische und weniger nachhaltige Gründe. Das zweite das einem während der Installation ins Auge sticht – man gibt seine Windows Live ID an, um sich mit der Wolke zu verbinden. Internet Browser Settings usw. müssen nun also nicht mehr über Zusatz Tools oder andere Browser abgeglichen werden:

Und dann geht die Revolution also wirklich los – in Form von Metro – der neuen Benutzeroberfläche von Windows. Kein Start-Button, kein Desktop, kein Papierkorb und kein blauer Hintergrund. Stattdessen – sattes Grün und Kacheln:

Die Logik hinter den Kacheln zu verstehen – wie man wieder zurück kommt, wie man sich weitere Informationen zu den Apps anzeigen lassen kann – dauert nur wenige Sekunden. Es ist tatsächlich intuitiv. Heise schreibt die Metro Oberfläche wäre auf einem “normalen” PC (Also mit Tastatur und Maus) kein “wirkliches Vergnügen” – das kann ich absolut nicht nachvollziehen.

Die Kacheln sind nicht nach unten sondern nach rechts erweitert angeordnet. Mit den Pfeiltasten oder per Scrollbar kommt man zur gewünschten Ansicht. Allerdings spielte mir Hyper-V (ich hatte Windows 8 in einer VM installiert) einen Streich. Ich öffnete den Internet Explorer (dessen Oberfläche sich komplett verändert und allen anderen Metro Apps angepasst hat):

Und dann saß ich da mit einer “Fullscreen-App oder –Website” wer weiß das schon noch. Und es gab kein zurück mehr. Der Rechtsklick brachte immerhin ein paar Optionen:

Google verkauft jetzt auch Orangen:

Und man kann Webseiten zu einem Internet Explorer Startmenü pinnen:

hat man das gemacht, und drückt wieder die rechte Maustaste, kann man durch einen Klick auf das Plus oben ein weiteres Tab hinzufügen:

Hier gibt man dann entweder eine neue URL an oder klickt auf die “pinned” Websites:

Aber halt – was ist das? “Use Desktop View”:

Der gute alte Desktop:

Das Problem mit dem “Exit” aus einer Metro App, das ich eben erwähnte konnte ich dann übrigens auch noch lösen. Normalerweise lässt sich per Klick auf die Windows-Taste (oder den Homebutton bei einem Tablet) der Homescreen anzeigen. In der Hyper-V VM funktionierte das nicht und ich musste einfach noch mal auf das VM Fenster klicken und das Startmenü erschien:

Drückt man hier auf Start, kommt man zurück zur Metro-Startseite. Hier gibt es noch weitere Apps zu erforschen. z.B. die Wetter-App:

Eine weitere Möglichkeit die App zu verlassen oder zu wechseln ist mir durch Zufall aufgefallen. Bewegt man den Mauszeiger an den linken Bildschirmrand tauchen die anderen offenen Apps auf und man kann mit dem Mausrad wählen zu welcher man springen möchte:

Das geht natürlich auch über die herkömmlichen Tastenkombinationen wie “Alt+Str+Tab”.

Hat man in der Wetter App z.B. mal Heidelberg eingestellt, wird eine Kurzzusammenfassung auch auf der Metro-Startseite angezeigt:

Ähnliches gilt für die “Stocks” App. Ich habe eine Aktie mit dem Kürzel “AAPL” hinzugefügt

und auch diese wird neben den anderen ausgewählten Werten auf dem Homescreen dargestellt:

Drückt man in der Stocks App wieder die Windows Taste (oder klickt nochmal auf das Hyper-V VM Fenster) kommt das Start-Menü zurück:

Über das kann man sich dann Settings zu der jeweiligen App anzeigen lassen:

Hier gibt es z.B. Informationen über den System Access:

Eine engere Verbindung zur Außenwelt spürt man in den Apps auch. Über eine “Share” Funktion, können z.B. Screenshots auf Facebook gepostet werden. Dafür ist die App “Socialite” da, die sich wiederum in andere Apps integriert:

Wer die Kacheln auf dem Homescreen verschieben will, tut das einfach über “Drag + Drop”:

Ein Rechtsklick auf eine Kachel lässt diese bearbeiten:

So, das beschließt unseren ersten Ausflug in die schöne neue Welt. In diesem Artikel habe ich hauptsächlich die neue Benutzeroberfläche Metro vorgestellt. in weiteren Artikeln werde ich mehr ins Detail gehen und mich auch um die Server Variante zu Windows 8 kümmern.

P.S. Nicht nur Windows steckt in neuen Kleidern – auch dieser Blog !

Exchange 2010 Provisioning Script (EPS)

noreply@blogger.com (Jan Geisbauer) — Tue, 13 Sep 2011 13:15:00 +0000

Immer wieder geht es in (größeren) Projekten darum, wie User (die meist von irgendeinem System im Active Directory erzeugt werden) ggf. eine Exchange Mailbox bekommen können. Es gibt für diesen sogenannten Provisioning-Process fertige Tools, mit denen ich mich allerdings noch nie beschäftigt habe. Die PowerShell bietet eigentlich alles was man braucht. Hier stelle ich mal ein einfaches Script vor, das diese Aufgabe übernimmt.

Beschreibung:

Das Exchange Provisioning Script (EPS) sucht im AD nach allen Usern die z.B. im “ExtensionAttribute1” bestimmte Werte stehen haben. Ob nun dafür das “ExtensionAttribute1” oder ein anderes Attribut herhalten muss kann man im Script über die Variable “$StatusAttribute” steuern. Es gibt derzeit drei mögliche Werte:

- msxmailbox (es wird eine Mailbox erstellt)
- deletemsxmailbox (es wird die Mailbox des Users gelöscht)
- deletemsxmailboxanduser (es wird die Mailbox des Users gelöscht einschließlich seines AD Uses Accounts)

Beim erstellen der Mailbox werden außerdem einige Parameter gesetzt. Dies kann man in Zeile 64 anpassen. Momentan wird die Sprache der Mailbox auf “de-DE” gesetzt und “IssueWarningQuota auf “450MB” sowie “ProhibitSendQuota” auf “500MB”. Außerdem wird immer, wenn das Script aktiv wurde, das AD Attribute “ExtensionAttribute1” (oder welches ihr auch immer benutzt) mit “readByMSXProvisioning” überschrieben, so dass das entsprechende User-Objekt in Zukunft nicht mehr angefasst wird.

Wenn eine Mailbox gelöscht werden soll (inkl. oder exkl. des AD User Accounts) wird zusätzlich der Parameter $maxDeleteCount abgefragt. Dieser soll verhindern, dass durch einen Fehler massenhaft Mailboxen geslöscht werden. Setzt man diesen Wert z.B. auf 10 – können immer nur max. 10 Mailboxen gleichzeitig durch das Script gelöscht werden. Findet das Script z.B. 11 User Objekte im AD mit dem Wert “deletemsxmailbox” werden gar keine Mailboxen gelöscht, da es von einem Fehler ausgeht.

Wenn eine Mailbox gelöscht wird, wird vorher außerdem die Grundkonfiguration (Get-Mailbox) per export-clixml in ein XML File geschrieben. Um die Rettung der eigentlichen Mailbox Daten muss man sich derzeit noch selbst kümmern.

Das EPS Script logged auch alles was es tut mit und schreibt Errorlogs.

Wer das Script testen möchte, nutzt dazu am besten seine Testumgebung – ich übernehme natürlich keine Garantien, dass alles so funktioniert wie es sollte.

Download Exchange Provisioning Script

Scalix zu Exchange

noreply@blogger.com (Jan Geisbauer) — Wed, 31 Aug 2011 09:58:00 +0000

Ich bin derzeit in einem Projekt damit beschäftigt über 12.000 Mailboxen von Scalix (ehemals HP Openmail) zu Exchange zu migrieren. In diesem Artikel berichte ich davon:

Wir hatten uns zuerst diverse IMAP Migrations Tools angeschaut, die wir alle nach einigen Test-Tagen über Bord geworfen haben. Keines dieser Tools arbeitete wirklich zuverlässig, was ich allerdings nicht wirkich den Tools als vielmehr Scalix zuschreibe. Aber diese Erkenntnis brachte uns auch nicht weiter. Klar war, dass es bei dieser Masse an Usern (die auch noch weltweit verteilt sind) keine Big-Bang Migration an einem Wochenende geben kann. Es wird also eine Co-Existence Phase geben. Außerdem – um ganz ehrlich zu sein – habe ich in meiner Zeit als Berater auch mittlerweile genügend “Migrations-Wochenend-Erfahrung” gesammelt, als dass da noch ein paar weitere hinzu kommen müssten.

Das Verschieben der Mailbox würde einige Schritte mit sich bringen, die man eigentlich alle zeitlich mit dem User abstimmen müsste. Da dies viel zu kompliziert erschien, kam die Idee auf den User die Migration selbst erledigen zu lassen. Natürlich wollten wir den User dabei nicht mit den Outlook-Bordmitteln (Export/Import Pst) alleine lassen und außerdem musste auch auf Server Seite einiges umgestellt werden. Also haben wir ein Tool entwickelt, dass zum einen die Datenmigration auf Clientseite durchführt und zum anderen (per Webservice) auf Server Seite z.B. die Routinginformationen umbiegt.

Der Webservice führt auf einem Server entweder Scalix-Shell Befehle (z.B. Weiterleitung in der Mailbox einrichten, Routing umstellen, OOF Text Abfrage, …) oder Exchange Powershell Befehle (Erstellen der Mailbox, OOF Text setzen, …) aus.

Co-Existence

Was das Routing angeht, wird ja in den meisten Projekten die grundlegende Struktur beibehalten. Man fügt Exchange hinzu und leitet von Scalix einfach alles weiter was der nicht kennt. Exchange selbst sagt man auch, dass es nicht “authoritative” für die Domain ist und erstellt einen SMTP Connector nach Scalix.

Scalix arbeitet mit einer eigenen Schema Erweiterung. Die relevanten Email – Adressen stehen zum Beispiel in ScalixEmailAddresses. “ProxyAddresses”, “TargetAddress” und “Mail” interessiert Scalix nicht die Bohne. User die also nach Exchange Verschoben werden sehen erstmal nur sich selbst, aber das will man ja nicht (Nobody is an Island). Deshalb haben wir ein Script gebaut, dass
durch alle relevanten AD User durchgeht und diese mit den Adressen aus “ScalixEmailAddresses” mail-enabled (nicht Mailbox-Enabled). Dabei wird die TargetAddress, die Primary SMTP und ShowInAddressbook gesetzt. Damit tauchen alles Scalix User im Exchange Addressbook auf, und mails an sie sind route-bar.

Fehlt nur noch eine “Kleinigkeit”: Ich hatte erwähnt, dass in den Scalix-Mailboxen bei der Migration (Tool) einfach eine Weiterleitung eingerichtet wird. Diese geht an eine Subdomain und wird dann so an Exchange weitergeleitet (Exchange User müssen natürlich diese Subdomain als zusätzliche SMTP bekommen). Das funktioniert für neue wie für alte Mails. Auf Exchange Seite sieht das anders aus. Neue Emails werden zwar über die TargetAddress an Scalix zurück geliefert – aber ein Reply auf eine Alte Mail (aus Zeiten in denen der User noch selbst auf Scalix war) landen im Nirvana.

Warum? Scalix arbeitet intern mit einem OPENMAIL format (ähnlich den X.400 Adressen). Die alten Mails in Outlook haben nur diese als Absender gespeichert (man kennt das aus Exchange 2003 Migrationszeiten). Deshalb muss unser Script dafür sorgen, dass die User alle auch Ihre alte OPENMAIL Adresse als zusätzliche SMTP bekommen. Dann klappen die Replys auch in alle Richtungen.

Migration

Der User wird im Vorfeld per EMail über die anstehende Migration informiert und ihm wird erklärt, dass er diese selbst durchführen kann. Sobald er freigeschaltet ist (wir wollen ja nicht alle gleichzeitig auf unsere Server loslassen ) kann er das sogenannte CMT (Client Migration Tool) starten und sich selbst per Benutzeroberfläche mit wenigen Click migrieren. Dabei passiert im Hintergrund folgendes:

User (Outlook) Sprache wird detected
CMT holt sich die alten Scalix Attribute und erstellt (über Powershellscripts und Webservice) neue Mailboxen (vorher hatten wir ja nur Mailenabled User)
CMT checkt ob der User Out-Of-Office ist – wenn ja wird es auf Exchange per Powershell gesetzt
Checkt ob es Forwards auf der Scalix Mailbox gab – wenn ja – wird es auf Exchange per Powershell gesetzt
CMT ändert per Webservice und Scalix Scripten das Externe Routing – direkt auf die Exchange Server
CMT triggert auf Serverseite ein Backup der Scalix Mailbox
CMT fügt ein neues Outlook Profil auf dem Client hinzu und fängt an alle Daten zu verschieben
CMT löscht das Scalix Outlook Profil

Das ganze erfordert einen sehr hohen Planungsaufwand. Es muss einiges programmiert, gescripted und vor allem getestet werden. Aber all das kann völlig ohne Zeitdruck geschehen. Solche Migrationen sind viel berechenbarer und stressfreier – außerdem erlauben sie mehr freie Wochenenden - in diesem Sinne: Have a nice one !

EMC startet nicht

noreply@blogger.com (Jan Geisbauer) — Thu, 18 Aug 2011 08:09:00 +0000

Heute hatte ich (mal wieder) das Problem, dass sich die Exchange 2010 Console nicht sauber öffnen ließ:

Das ist nicht komplett ungewöhnlich und es gibt sehr viele Gründe dafür. Das Exchange Team hat eigens einen Blog Artikel dafür verfasst sogar und extra ein Tool für die Diagnose gebaut.

Diesmal war die Lage aber etwas anders, ich selbst war nicht ganz unschuldig an diesem Problem . Nun, es musste der primäre DNS Suffix des (einzigen) Exchange Servers in einer LAB-Umgebung umgenannt werden. Exchange mag das nicht und es hat mich viel Schweiß gekostet, die Console wieder zum Starten zu kriegen. Und das kam so:

Nachdem ich den primären DNS Suffix des Exchange Servers geändert hatte, ließ sich die EMC nicht mehr starten. Der genaue Verbindgunsfehler lautete:

Aus dem Fehler konnte ich erkennen, dass sich die EMC immer noch mit dem alten Namen verbinden will (dem alten DNS Suffix). Also musste der alte DNS Suffix irgendwo auftauchen. Meine erste Idee war, das .msc File der EMC in Notepad zu betrachten. Allerdings musste ich feststellen, dass dieses File seit der Installation nicht mehr verändert wurde und darin keine benutzerspezifischen Werte zu finden waren. (Nebenbei bemerkt registriert sich Notepad sofort für alle .msc Endungen wenn man ein .msc File damit öffnet ! – Muss man also auch wieder hinbiegen).

Als nächstes habe ich dann den Process Monitor angeworfen, um zu sehen, ob die EMC eventuell auf eine andere Config Datei zugreift und daraus, den alten (falschen) Namen des Exchange Servers liest. Auch das brachte keinen Erfolg. Um ganz sicher zu gehen, habe ich mit der Windows Suche das komplette Filesystem durchsucht (auch in den Files) und auch dort nichts gefunden.

Ok: dann gings in die Registry. Aber auch hier war nichts zu finden, was auf den alten Namen deutete. Daraus schloss ich, dass dieser Wert entweder nicht im Cleartext lokal vorliegt oder eben gar nicht lokal vorliegt. Also startete ich den Netzwerk Monitor und schnitt die Verbindungen während des Starts der EMC mit. Tatsächlich tauchte hierbei der falsche DNS Suffix zweimal auf. Einmal bei der Anfrage für ein Kerberos Ticket (ServicePrincipleName = Falscher DNS Name des Exchange Servers) und einmal bei der Rückmeldung des KDCs –> Falscher Service Principle Name. Ach ne! Das brachte mich also auch nicht weiter. Irgendwo musste der Name doch stecken!

Um das Active Directory komplett auszuschließen, habe ich beschlossen mit LDIFDE einen Dump des selbigen zu ziehen:

Ldifde –d DN –f c:\meinexport.txt

“DN” muss man hier entsprechend anpassen. Ich habe zum einen die komplette Configuration Partition durchsucht und auch den Default Naming Context. Tatsächlich bin ich hier an einigen Stellen fündig geworden. Ich habe alles angepasst und anschließend erwartungsfroh die EMC geöffnet – nur um mir wieder den selben Fehler anschauen zu müssen.

Auch ein Reboot brachte kein Glück. Dann fiel mir noch ein, dass die EMC einen Cache schreibt. Das macht sie unter:

C:\Users\userName\AppData\Roaming\Microsoft\MMC

Die darin liegenende Datei hab ich gelöscht und danach sicherheitshalber nochmal gebootet. Und wieder kein Erfolg.

Na gut, dachte ich mir – dann eben auf die harte Tour –> ich habe dann die CAS Rolle deinstalliert und zusätzlich noch den IIS runtergeworfen.
Danach wieder IIS und CAS installiert. Dann hatte ich noch zusätzlich die Probleme die im Ehlo Artikel beschrieben sind: das Kerberos Modul war als “managed” installiert und nicht als “native” (und kein Pfad zeigte zur entsprechenden DLL) und das gleiche galt für das WSMan Modul.
Beides wieder in Ordnung gebracht, reboot – nix tut.

Frustriert berichtete ich einem Freund von meinen Problemen mit der EMC. Der gab mir den Tipp einfach mal das komplette Profil des Admin-Users mit dem ich die EMC öffnete zu löschen (also c:\users\Username).

Gesagt – getan. Und siehe da – ERFOLG !

Mittlerweile konnte ich das Problem noch weiter eingrenzen –> NTUSER.DAT !

Es genügt diese zu löschen, um dem Problem Herr zu werden und die EMC wieder in strahlendem Orange zu sehen.

Exchange 2010 Design Entscheidungshilfe

noreply@blogger.com (Jan Geisbauer) — Thu, 14 Jul 2011 10:58:00 +0000

Wer vor der Aufgabe steht für Exchange 2010 ein Design zu entwickeln, muss sich viele Fragen stellen und einige Pros/Cons abwägen. Ich habe mich einmal hingesetzt und die (für mich) grundlegendsten Punkte aufgemalt:

JBODlessness

noreply@blogger.com (Jan Geisbauer) — Thu, 14 Apr 2011 09:54:00 +0000

Ich war jetzt – wie gesagt – eine Weile raus aus dem Thema Exchange. Als ich in Oktober loszog, gab es erst wenige Exchange 2010 Projekte. Das hat sich während meiner Abwesenheit stark geändert und ich war gespannt, was sich in Sachen JBOD getan hat.

Es ist ja so, dass Microsoft, den IO Bedarf von Exchange 2003 auf Exchange 2010 um mehr als 90% reduziert hat. Das ist enorm und und zeigt eine eindeutige Richtung auf. In Microsofts Rückspiegel liegt Exchange auf einem SAN, der Blick nach vorne zeigt uns Direct Attached Storage (DAS) an Exchange, ~~dumme~~ Plattenkäfige also, die man per Fiberchannel direkt an die Server hängt. Wer an dieser Stelle nach Ausfallsicherheit schreit, hat sich noch nicht mit den Hochverfügbarkeitstechniken von Exchange 2010 beschäftigt. Diese Sorgen –auf Softwareebene- für einen stetigen Abgleich der Datenbanken – und das auf insgesamt bis zu 16 Kopien.

Mehr noch: Die Zukunft ist nicht nur “SANless” für Exchange, sie ist auch “RAIDless”. Microsoft “erlaubt” ab drei konfigurierten Kopien einer Datenbank (also mindestens 3 Exchange Server mit der Mailboxrolle in einer Database Availability Group – DAG), auf RAID gänzlich zu verzichten. Wie das? Nun, mit dem stetigen Abgleich, der Continouos Replication, verlagert man die RAID Technologie ein paar Ebenen nach oben in den Applikationslayer. Wenn ich also auf der Applikationsebene für Ausfallsicherheit sorge, kann ich mir diese auf Hardwareebene (Festplatten-RAID) sparen.

Diese beiden Neuerungen (Weniger IO, weniger geforderte Verlässlichkeit der Platten) ermöglicht es nun auf sehr günstigen, von Natur aus erst mal nicht redundanten Storage zu setzen (z.B. SATA Platten mit 7.200 rpm, ohne RAID).

Das klingt nach großen, günstigen Mailboxen – hat aber einen kleinen Haken: Wenn im RAID-Verbund eine Festplatte kaputt geht, sagt der Exchange-Admin (der dies hoffentlich monitored) irgendjemand er soll – “dort wo es rot blinkt” – eine neue Platte einschieben. Was ich mit diesem flapsigen Satz sagen will, ist zweierlei:

1. Das kann theoretisch jeder
2. Es gibt hier keine wirkliche Action für den Exchange Admin

Im JBOD Fall sieht das anders aus. Hier muss eine neue Platte in den Käfig, die muss formatiert werden und anschließend muss ein Re-Seeding stattfinden. D.h. über Netzwerk (und hier haben wir eventuell einen weiteren Nachteil) muss die komplette Datenbank zurück kopiert werden.

Am Ende ist es natürlich eine Frage der Prioritäten. Brauche ich sehr viele, sehr große Mailboxen und diese möglichst günstig, ist JBOD definitiv eine Überlegung wert. Mir persönlich sind momentan ca. 7 Exchange 2010 Projekte bekannt, alle basieren auf RAID und nicht auf JBOD.

Die oben aufgeführten Punkte mögen bei der Entscheidung für oder gegen JBOD eine Rolle gespielt haben (spielen). Es kommt jedoch noch ein weiterer Punkt dazu: Das Bauchgefühl. “Auf RAID ist verlass”. Hier wird es vermutlich eine Weile brauchen, bis Exchange “bei den anderen” gezeigt hat, dass es die Rolle von RAID-Systemen mit übernehmen kann.

Die Ersten haben immer das größere Risiko. Aber sie haben auch die Möglichkeit eine 5 GB Exchange Mailbox “zu bauen”, die unter 5€ / User / Monat kostet, ausfallsicher ist (und tatsächlich ALLE Kosten beinhaltet).

Back for good

noreply@blogger.com (Jan Geisbauer) — Tue, 05 Apr 2011 13:52:00 +0000

Hola Allerseits !

am 14. September 2010 habe ich also meinen letzten Post geschrieben. Kurz danach bin ich dann für ein halbes Jahr aufgebrochen die (halbe) Welt zu erkunden. Es gab wenig Rechner-Kontakt in der Zeit und so wurden auch keine Posts geschrieben. Ich hatte eine wirklich gute Zeit und freue mich jetzt wieder auf die Arbeit.

D.h. ab sofort wird es auch wieder Content geben an dieser Stelle.

Viele Grüße

Jan

Lync

noreply@blogger.com (Jan Geisbauer) — Tue, 14 Sep 2010 09:13:00 +0000

Nachdem der Office Communication Server nun in die dritte Runde geht, auch an dieser Stelle mal eine kurze Erwähnung. Für eine sehr gute Einführung zum Thema kann ich einen iX Artikel meiner Kollegen empfehlen, den man hier kostenlos beziehen kann.

Wer sich in den nächsten Wochen für die ersten praktischen Erfahrungen rund um den Lync Server interessiert, ist bei Karsten gut aufgehoben.

Viel Spass in der Welt der digitalen Sprache.

Mailboxen aus Produktivumgebung in Testumgebung kopieren

noreply@blogger.com (Jan Geisbauer) — Fri, 07 May 2010 08:56:00 +0000

Ein Post! Tja, es gibt solche Zeiten und solche. Jedenfalls wird jetzt wieder gebloggt :-)

Bei einem Kunden musste ich neulich alle Usermailboxen in die Testumgebung übernehmen und habe mir dafür zwei kleine PowerShell Scripts geschrieben, die ich Euch nicht vorenthalten möchte. Das erste exportiert die Properties der Mailboxen aus der Produktivumgbebung in XML Files (export-cliXML) und das zweite liest sie dann wieder ein und erstellt anhand einiger Properties neue Mailboxen. Here you go:

Export aus Produktivumgebung:

get-mailbox -Resultsize unlimited  %{$_  export-cliXML -Path ("C:\productiveUser\" + $_.alias + ".xml")}

Import in Testumgebung:

$db="server\sg\db"
$ou="domain.com/users"
$path="C:\productiveUser\"

$allXMLs = dir $path

$sPassword = convertto-securestring Password01 -asplaintext -force #alle User kriegen das gleiche PW

foreach($XML in $allXMLs)
{
$pathx = $path + $XML
$newMB=Import-CliXml $pathx

New-Mailbox -Name $newMB.SamAccountName -SamAccountName $newMB.SamAccountName -Password $sPassword -Database $db -UserPrincipalName $newMB.UserPrincipalName -organizationalunit $ou -Alias $newMB.alias -Displayname $newMB.Displayname -Lastname $newMB.lastname -firstname $newMB.firstname
}

Wenn man nur bestimmte User in die Testumgebung kopieren möchte, kann man entweder beim Import einen Filter einbauen, oder –noch einfacher- die XMLs löschen/verschieben, die man nicht braucht.

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