Möchte man eine Instanz in eine andere Infrastruktur migrieren (möglicherweise aufgrund einer Aktualisierung), sollten folgende Schritte beachtet werden.

  • Bevor die Instanz in der „alten Umgebung“ abgeschaltet wird, sollte der aktuelle Schlüssel für die Datenverschlüsselung kopiert werden. Diesen finden Sie ab Dynamics CRM 2011 unter Einstellungen > Datenverwaltung > Datenverschlüsselung > [X] Schlüssel anzeigen. Sie benötigen diesen nach der Migration, um die Datenverschlüsselung wieder zu aktivieren.
  • Stellen Sie zudem sicher, dass es einen CRM-User gibt, der alle der folgenden Eigenschaften besitzt.
    • Zugriffsmodus: Lesen-Schreiben (NICHT Administrator und erst recht nicht Lesezugriff)
    • Rolle: Mindestens Systemadministrator
  • Anschließend können Sie auf dem Anwendungsserver die Instanz deaktivieren und löschen. Hierbei wird die Datenbank nicht gelöscht.
  • Besagte Datenbank können Sie anschließend auf dem SQL-Server entweder im Rahmen eines Backups sichern, oder aber die Datenbank einfach aushängen.
  • In beiden Fällen können Sie die Datenbank entweder durch simples Wiedereinhängen oder durch das Wiederherstellen der Sicherung im neuen SQL-Server einhängen.
  • Auf dem neuen CRM- / Dynamics 365-Server können Sie dann die Organisation importieren. Nach der erneuten Eingabe der Namen sowie der Auswahl des Report-Servers kommen wir hier zum Benutzermapping. Dies können Sie automatisiert durchlaufen lassen, sofern die Domäne gleich bleibt. Anderenfalls müssen Sie die CRM-Benutzer manuell den AD-Benutzern zuweisen.
  • Im Falle des Fehlers „You must map your Active Directory user account to at least one enabled Microsoft Dynamics CRM user who has the System Administrator role before the organization can be imported“ sind folgende Ursachen möglich:
    • Sie führen den Import mit einem Benutzer durch, den Sie nicht gemappt haben > Sie müssen sich entweder den Import mit dem Benutzer durchführen, auf den die Anforderungen aus Schritt 2 passen, oder Ihren aktuellen Benutzer auf den besagten CRM-User mappen.
    • Sie führen den Import mit einem Benutzer durch, dessen CRM-User nur administrativen Zugriff auf das CRM hat > Führen Sie folgende Query in der Datenbank Ihrer Instanz aus:
      UPDATE SystemUserBase
      SET AccessMode = 0
      WHERE DomainName = 'DOMAIN\User'
    • Sie führen den Import mit einem Benutzer durch, dessen CRM-User deaktiviert ist > Führen Sie folgende Query in der Datenbank Ihrer Instanz aus:
      UPDATE SystemUserBase
      SET IsDisabled = 0
      WHERE DomainName = 'DOMAIN\User'

      Es kann sein, dass Sie davor einen anderen Benutzer deaktivieren müssen, um die maximale Anzahl von Benutzern nicht zu überschreiten:

      UPDATE SystemUserBase
      SET IsDisabled = 1
      WHERE DomainName = 'DOMAIN\OtherUser'
  • Danach wird der Import durchgeführt. Dies lief bei uns fehlerfrei durch. Sollten uns bei kommenden Migrationen noch gängige Fehler auffallen, werden wir diese an der Stelle ebenfalls festhalten.
  • Nach dem erfolgreichen Umzug müssen Sie bei der Verwendung von ADFS spätestens jetzt die alte Instanz löschen. Aktualisieren Sie anschließend beide Relying Party Trusts (mangels deutscher Server fehlt mir hier die Übersetzung) – die der alten Instanz und die der neuen.
  • Der A-Record muss ebenfalls auf die neue Infrastruktur zeigen.
  • Tragen Sie nach dem erfolgten Zugriff auf das neue CRM den in Schritt 1 gespeicherten Verschlüsselungskey wieder unter Einstellungen > Datenverwaltung > Datenverschlüsselung ein. Danach ist das CRM / Dynamics 365 wieder voll benutzbar.

Migrationen über den VMM (vorallem zwischen Clustern) können oft zu merkwürdigen Fehlern führen, die sich nicht immer logisch erklären lassen. Aus diesem Grund habe ich hier mal die mir widerfahrenen Probleme aufgelistet, gemeinsam mit Lösungsansätzen.

  • Es konnte keine verfügbare Verbindung mit dem ausgewählten VM-Netzwerk gefunden werden.
  • Es wurde keine Verbindung zu „[VM-Netzwerkname]“ mit ausreichenden Ressourcen gefunden.

Das ist ein seltsamer Bug. Wenn wir jedoch im VMM aus dem Menüband die PowerShell-Konsole öffnen, und darüber die Migration durchführen, so funktioniert es ohne Probleme – Vorausgesetzt natürlich, dass das Netzwerk tatsächlich an dem Zielhost anliegt. Hierzu gehen wir folgendermaßen vor:

$VMHost = Get-VMHost -ComputerName "[Ziel-Host]"
$VM = Get-VM -Name "[Zu migrierdende VM]"
$VMPath = $VMhost.Vmpaths[[Index des korrekten Speicherorts]]
Move-VM -VM $VM -VMHost $VMHost -Path $VMPath

Move-VM : Die VM „XXXXX“ kann aufgrund von Inkompatibilitätsproblemen nicht zu Host „XXXXXXX“ migriert
werden. The virtual machine ‚XXXXX‘ is using processor-specific features not supported on physical computer ‚XXXX‘.
To allow for migration of this virtual machine to physical computers with different processors, modify the virtual
machine settings to limit the processor features used by the virtual machine. (Virtual machine ID
xxxxxxxx-xxxxxx-xxxxxxx-xxxxxxxx) (Fehler-ID: 23008, Detaillierter Fehler: )

Beheben Sie das Inkompatibilitätsproblem, und wiederholen Sie den Migrationsvorgang.

Hier ist die VM auf einem Host erstellt worden, dessen Prozessorgeneration neuer ist, als der Zielhost der Migration. Behoben werden kann das Ganze, in dem man die VM herunterfährt, den Haken unter „Hardware“ -> „Prozessor“ -> „Migration zu einem virtuellen Maschinenhost mit abweichender Prozessorversion zulassen“ setzt und dann die Migration erneut durchführt. Nach der Migration sollte die Maschine erneut heruntergefahren werden, um diesen Haken wieder zu entfernen.


Move-VM : Der Hostvorgang auf dem Server „XXXXXXXXX“ kann von VMM aufgrund des folgenden Fehlers nicht
abgeschlossen werden: Virtual machine migration operation for ‚XXXXXXXX‘ failed at migration source ‚XXXXXXX‘. (Virtual
machine ID xxxxxxxx-xxxxxx-xxxxxx-xxxxxxxxx)
Virtual machine migration for ‚XXXXXXX‘ failed because configuration data root cannot be changed for a clustered
virtual machine. (Virtual machine ID xxxxx-xxxxxxxxx-xxxxxxxx-xxxxxx) (Fehler-ID: 12700, Detaillierter Fehler:
Unknown error (0x8005))

Beheben Sie das Problem auf dem Host, und wiederholen Sie dann den Vorgang.

Dieser Fehler kann behoben werden, indem man im Anschluss an den Fehler auf „Reparieren“ -> „Ignorieren“ klickt, und anschließend die Migration erneut triggert. Notfalls über PowerShell. 

Letzte Woche wurde bei einem Kunden von uns lokal ein neuer Exchange-Server parallel zu einer 2007er Installation hochgezogen, um anschließend die Postfächer zu migrieren.

Beim Check, welcher vor der Installation durchgeführt wird, bemängelte das Setup noch vorhandene Exchange 2000/2003-Einträge im AD. Diese(n) Server gibt es allerdings schon seit geraumer Zeit nicht mehr. Somit mussten wir die Einträge manuell entfernen – Zeit für den ADSI-Editor.

Wir verbinden uns also per ADSI Edit auf die betroffene Domain. Als „bekannten Namenskontext“ wählen wir Konfiguration aus. Dann bitte folgenden Pfad befolgen:

  • Konfiguration [Domain.local]
    • CN=Configuration,DC=Domain,DC=local
      • CN=Services
        • CN=Microsoft Exchange
          • CN=[Organisationsname]
            • CN=Administrative Groups
              • CN=Erste administrative Gruppe
                • CN=Servers

Unter diesem Container finden wir nun alle verwaisten Servereinträge. Aus diesem Grund kann man alle Container innerhalb des CN=Servers entfernen. Auf keinen Fall aber irgendetwas anderes. Durch das Löschen dieser Server sollte die Meldung weggehen.