psGalSync

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

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

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

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

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)

 

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)

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