Archiv für den Monat Februar 2016

DNS-Einträge für die Office365 Migration

Veröffentlicht am von
Antwort

Die Einrichtung von DNS – Einträgen für Office 365 (Exchange Online) ist immer eine interessante Sache, da sie in der DNS-Konfiguration des Hosters erfolgt. Diese scheinen (mein subjektiver Eindruck) meist Eigenentwicklungen zu sein – zumindest habe ich noch keine Oberfläche mehrfach vorgefunden.

Dabei ist die Sache nicht besonders schwierig …

  1. Als erstes erfolgt die Anmeldung am Office365 Portal über https://portal.office.com mit einem Account welcher administrative Rechte besitzt
  2. Im Dashboard im Abschnitt Domänen verwalten klickt man dann auf die Schaltfläche Domäne hinzufügen

    image

    Diese Auswahl impliziert, dass schon eine Domäne bei einem Hoster existiert! Nach dem Klick auf Domäne hinzufügen startet der Assistent welcher einen mit entsprechenden Hinweisen beim Prozess unterstützt.

  3. Im Assistant, wählt man die Option Fangen wir an! um die Domäne zu migrieren
  4. Der Name der Domäne wird nun ohne www in der Auswahlfeld eingetragen

    image

    Darunter erfolgt gleich ein Hinweis wie die Mail-Adressen der Domäne später aussehen (z.B. Benutzer@sbsland.de) werden, was aber keine wirkliche Rolle spielt da eine Änderung im Anschluss ohne Probleme erfolgen kann.
    Durch einen Klick auf weiter, erstellt der Assistent den notwendigen TXT-Eintrag welcher zur Überprüfung (ob einem die Domain auch wirklich gehört) gesetzt werden muss.

  5. Dieser Eintrag muss nun im DNS beim Hoster konfiguriert werden.

    image

    Das @ bezieht sich auf einen TXT Eintrag direkt für die z.B. sbsland.de Domain und nicht auf irgendeine Subdomain.

  6. In der DNS Verwaltung muss damit dieser Eintrag angelegt, oder geändert werden und hier die zugehörige DNS Verwaltung …

    image

    … in dieser KEIN TXT Eintrag vorhanden ist. Ein Anlegen des TXT Eintrags für die Root Domain ist in diesem Tool leider nicht möglich – so etwas geht nur für Subdomains.
    Microsoft bietet zwar die Möglichkeit an die Validierung auch über einen MX Eintrag durch zu führen (was hier möglich ist) – allerdings muss danach wiederum ein TXT Eintrag konfiguriert werden. Was dazu führt, dass wir den TXT Eintrag durch einen Support-Call beim Hoster (Provider) setzen lassen

  7. Nachdem uns der Hoster den TXT Eintrag gesetzt hat können wir diesen mit dem von Microsoft geforderten Wert setzen

    image

    und zurück im DNS Assistenten im Office Portal mit OK, ich habe den Eintrag hinzugefügt die Überprüfung starten!

  8. Was dann auch auf Anhieb funktioniert

    image

    Ein Klick auf Weiter bringt uns zur Einrichtung von Benutzern, welche wir an dieser Stelle überspringen.

  9. Nun kommen wir zur abschließenden Konfiguration der DNS-Einträge welche zur Funktion der Domain mit Office365 notwendig sind. Dabei ist zu beachten, dass wir nur die Einträge für Mail, setzen wollen – aber nicht für die gesamte Domain.

    image

    Hier nur die Option für die Mail-Einträge

    image

  10. Damit haben wir auch schon die Liste der notwendigen Einträge fertiggestellt

    image

  11. Die Einträge sehen in dieser DNS-Verwaltung dann wie folgt aus

    image

    Lila habe ich den vom Hoster gesetzten TXT Eintrag markiert, welcher erneut überschrieben werden muss.
    Der DNS Assistent in Office365 bestätigt die Eingaben dann mit einem Alles bereit! wenn diese in Ordnung sind.

Enjoy it, b!

Server hängt beim herunterfahren

Veröffentlicht am von
2

Nach der Installation einer großen Anzahl von Updates wollten einige Server nicht mehr sauber herunter fahren, bzw. neu starten.

Gut 20min musste ich mir den folgenden Bildschirm anschauen.

image

Dabei habe ich mir die Frage gestellt – was tun? Gut, eine VM kann ich über das Hyper-V Management einfach ausschalten, einen Hyper-V Host oder anderen physikalischen Server kann ich über das ILO-Board ausschalten. Die Konsequenzen sind aber nicht immer absehbar.

Die Ursache des Problems war bei allen Systemen (3x virtuell und 1x Hyper-V Host), dass sich ein Services nicht korrekt beenden wollte.

Eine Abfrage der Services …

sc \\server queryex >c:\temp\process.txt

… welche remote noch möglich war lieferte folgendes Ergebnis.

SERVICE_NAME: TrkWks
DISPLAY_NAME: Distributed Link Tracking Client
        TYPE               : 20  WIN32_SHARE_PROCESS  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 12
        FLAGS              : 

SERVICE_NAME: TrustedInstaller
DISPLAY_NAME: Windows Modules Installer
        TYPE               : 10  WIN32_OWN_PROCESS  
        STATE              : 3  STOP_PENDING 
                                (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x2
        WAIT_HINT          : 0x36ee80
        PID                : 4124
        FLAGS              : 

SERVICE_NAME: UmRdpService
DISPLAY_NAME: Remote Desktop Services UserMode Port Redirector
        TYPE               : 20  WIN32_SHARE_PROCESS  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0

Da die Ausgabe in eine Textdatei erfolgte konnte ich hier einfach eine Suche durchführen und bin dabei mehrfach auf den TrustedInstaller Service gestoßen welcher mit STOP_PENDING das Herunterfahren, bzw. den Neustart des Servers verhinderte.

Ein Beenden des Prozesses mit taskkill half sofort und das Problem war gelöst.

taskkill /S server /PID 4124

Nach dem Neustart wurden nochmals wenige ausstehende Updates installiert und der Server läuft wieder ohne Probleme.

Auf einem Hyper-V Host hatte ich das gleiche Problem, hier wollte eine VM sich nicht beenden und nach über 1h Warten habe ich mich entschlossen den Prozess der VM zu beenden.

SERVICE_NAME: vds
DISPLAY_NAME: Virtual Disk
        TYPE               : 10  WIN32_OWN_PROCESS  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 1076
        FLAGS              : 

SERVICE_NAME: vmms
DISPLAY_NAME: Hyper-V Virtual Machine Management
        TYPE               : 10  WIN32_OWN_PROCESS  
        STATE              : 3  STOP_PENDING 
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_PRESHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0xdcb
        WAIT_HINT          : 0x7d0
        PID                : 1112
        FLAGS              : 

SERVICE_NAME: W32Time
DISPLAY_NAME: Windows Time
        TYPE               : 20  WIN32_SHARE_PROCESS  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 844
        FLAGS              :

Das Beenden erfolgt wiederum über taskkill.exe und der entsprechenden Prozess-ID (1112).

Nach dem Neustart des Hyper-V Hosts hat lediglich die VM einen “unexpected shutdown” gemeldet, alle anderen VMs waren davon nicht betroffen.

Generell erscheint mir diese Vorgehensweise (auch bei Hyper-V Hosts) die deutlich sinnvollere als einfach den Server aus zu schalten. Ein Power-Reset betrifft gleich immer alle darauf laufenden Systeme was auch mal einige VMs beschädigen kann.

Enjoy it, b!