Mostly Anything

IT Blog über VMWare, SQL, Storage, Security und mehr.

Mostly Anything header image 1

Migration Exchange 2007 zu Office 365: Outlook findet nur internen Server bei automatischer Profilerstellung

7. Oktober 2012 · Keine Kommentare

Bei einem Kunden haben wir den internen Exchange 2007 Server in die Cloud, im speziellen zu Office 365 migriert. Das Migrationsszenario Cut-Over Migration war das passende und die Migration selbst war kein Problem. Microsoft oder die Community bieten mehrere Tools um fast alles zu testen:

Microsoft Office 365 Deployment Readiness Tool
Exchange Environment Reports
Microsoft Online Speed Test
Microsoft Remote Connectivity Analyzer

Für die Cut-Over Migration selbst musste dann einfach der Migration Assistant gestartet werden, der dann via Active Sync die ganzen Daten in die Cloud migriert und danach alle 24h synchronisiert. Am Cut-Over Tag wurden dann die DNS Server umgestellt (bereits beim Start wurde die TTL auf 600 gesetzt um spätere Änderungen schneller zu propagieren) und die Mails kommen dann via Cloud zum Benutzer.

Ein Problem blieb: Outlook. Beim Erstellen des neuen Profils erkennt Outlook immer automatisch den alten Exchange Server. Hier ist wichtig, dass der autodiscover Eintrag in der Domain nun neu auf Microsoft zeigt:

autodiscover.kunde.ch CNAME autodiscover.outlook.com

Das war auch gesetzt … aber da die interne Domain? Intern arbeitete der Kunde mit kunde.zz und nicht mit kunde.ch. Also im internen DNS Server noch

autodiscover.kunde.zz CNAME autodiscover.outlook.com

gesetzt. Läuft immer noch nicht. Es gibt einen weiteren Ort wo der alte Exchange Server noch drin ist. In der internen DNS Domain gibt es einen SRV (Service Locator Entry) im DNS.

kunde.zz/_tcp/_autodiscover

diesen auch auf autodiscover.outlook.com. umstellen.

Wars das? Für neue User ja, für bestehende User nein. Da gibts noch was (Ich frag mich ob da jetzt jemand bei Microsoft lacht und sich denkt „… die finden eh nie alle Referenzen auf den Server …“).

Die User Objekte im AD haben zwei Attribute:

– homeMDB
– homeMTA

Diese sind noch auf den alten Exchange Server gesetzt für bestehende Accounts und die findet Outlook auch und setzt dann automatisch den internen Exchange Server. Also diese zwei Attribute löschen (die sieht man in den normalen AD Tools nicht, also via ADSIedit oder einen LDAP Manager oder Powershell setzten) und dann klappts auch mit einem neuen Profil und autodiscover auf Office 365!

Nun ist es aber relativ mühsam, bei mehreren Usern diese Attribute zu löschen. Daher habe ich ein Powershell Script geschrieben, dass diese Attribute auf der Domain löscht. Das Script benötigt Powershell und die PowerShell Commands for Active Directory von Quest (gratis).

Wird das Script ohne Parameter ausgeführt, dann verbindet es sich mit dem default Active Directory und dem User, mit dem das Script ausgeführt wird. Es holt sich alle User vom AD und löscht die Attribute homeMDB und homeMTA. Weitere infos zum Script gibts mit get-help in PowerShell

get-help clear-ADAttribute.ps1

Zip Clear-ADAttribute

→ Keine KommentareTags: Exchange

Alle VMware 5.x Poster

14. September 2012 · Keine Kommentare

Hier ist ein Link mit allen aktuellen VMware 5.x Postern:

VMware Poster

→ Keine KommentareTags: VMWare

Powershell Fenster Titel setzen

14. September 2012 · Keine Kommentare

Hab hier gerade mehrere Powershell Fenster offen mit jeweils anderen Verbindungen zu Netapp Filern. Windows 7 gruppiert dies ja schoen in der Taskbar aber ich muss immer wieder suchen, welches Powershell Fenster ich eigentlich will.

Mit

$Host.UI.RawUI.WindowTitle = "Server01"

kann ich den Titel setzten und seh so sofort welches Window was ist.

→ Keine KommentareTags: Powershell

Gratis Microsoft Press Bücher

28. Juni 2012 · Keine Kommentare

Microsoft gibt einige der Microsoft Press Bücher gratis ab. Mehr Info dazu unter

Free Microsoft Press Books

→ Keine KommentareTags: IT · Windows

Windows Time Service beendet sich trotz Autostart – Service Trigger Events

20. Februar 2012 · Keine Kommentare

Bei einem Kunden haben wir einen Windows Server als Time Server für die DMZ im Einsatz. Der war bisher Windows 2003 und wurde nun auf 2008R2 aktualisiert. Der Service wurde entsprechend konfiguriert und auf Automatic Startup gesetzt. Trotzdem wurde der Service immer Sonntags 01.00 wieder gestoppt. Ohne Error aber mit Info Eintrag im Eventlog, dass der Service erfolgreich gestoppt wurde.

Windows 7 und 2008R2 haben sogenannte Service Trigger Events. Die Erklärung bei Microsoft fängt mit folgendem Satz an:

"A service can register to be started or stopped when a trigger event occurs..."

D.h. das ein Service so konfiguriert werden kann, dass z.b. wenn das Netzwerk Interface nicht mehr verbunden ist, ein Service gestoppt wird. Macht im Client sicherlich Sinn, im Serverumfeld .. naja, kann sein.

Anschauen kann man die Triggerevents mit dem SC Tool (sc.exe). Dann schauen wir uns mal die Trigger Events zum Timeservice an:

C:\>sc qtriggerinfo w32time
[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: w32time

        START SERVICE
          DOMAIN JOINED STATUS         : 1ce20aba-9851-4421-9430-1ddeb766e809 [DOMAIN JOINED]
        STOP SERVICE
          DOMAIN JOINED STATUS         : ddaf516e-58c2-4866-9574-c3b615d42ea1 [NOT DOMAIN JOINED]

Aha. Der w32time Service (Windows Time Service) hat einen Service Trigger Event auf den „Domain Joined Status“. Wenn der Computer in einer Domain ist ([DOMAIN JOINED]) dann wird der Service gestartet, falls nicht ([NOT DOMAIN JOINED]) wird der Service gestoppt.

Der Server in der DMZ ist natürlich nicht in einer Domain. Das ist also das Problem.

Man könnte nun einen entsprechenden Trigger setzen, der dem gewünschten Verhalten mehr enspricht, z.b. wenn der Computer eine IP bekommt. In userem Falle lösche ich aber einfach die Trigger Events

sc triggerinfo w32time delete

Nun hat der Service keine Events mehr

C:\>sc qtriggerinfo w32time
[SC] QueryServiceConfig2 SUCCESS

The service w32time has not registered for any start or stop triggers.

Von nun an wird der Service nicht mehr gestoppt und läuft wie er eigentlich sollte.

→ Keine KommentareTags: Uncategorized · Windows