Citrix DaaS

Migration der Konfiguration zu Citrix Cloud

Gründe für die Verwendung der automatischen Konfiguration

IT-Administratoren, die für große oder komplexe Umgebungen zuständig sind, betrachten Migration oft als mühsamen Prozess. Häufig schreiben sie ihre eigenen Tools, um diese Aufgabe erfolgreich auszuführen, da sie in der Regel für ihre Anwendungsfälle spezifisch ist.

Citrix möchte die Migration durch Automatisierung mit dem Tool zur automatischen Konfiguration vereinfachen. Administratoren können mühelos aktuelle Konfigurationen in Citrix Cloud testen und die Vorteile von Citrix DaaS (ehemals Citrix Virtual Apps and Desktops Service) nutzen, während ihre aktuellen Umgebungen intakt bleiben. Es gibt zudem keine Auswirkungen auf Endbenutzer, da die automatische Konfiguration nahtlos im Hintergrund arbeitet. Zu diesen Vorteilen gehören neben anderen eine geringere administrative Überlastung, wenn Citrix einen Teil der Back-End- und Steuerungsebene verwaltet sowie automatische und anpassbare Updates von Citrix Cloud-Komponenten.

Citrix verwendet eine branchenübliche Konfiguration als Code, um einen Mechanismus zur Automatisierung von Migrationsprozessen bereitzustellen. Die automatische Konfiguration erkennt und exportiert eine oder mehrere On-Premises-Sites als Sammlung von Konfigurationsdateien. Die Konfiguration dieser Dateien kann dann in Citrix DaaS importiert werden.

Die automatische Konfiguration gibt Administratoren außerdem die Möglichkeit, mehrere On-Premises-Sites in einer einzigen Site zusammenzuführen und dabei Namenskonflikte zu vermeiden. Administratoren können steuern, ob Ressourcen durch die On-Premises- oder die Cloud-Konfiguration gesteuert werden.

Die automatische Konfiguration ist nicht nur ein einmaliges Migrationstool, sie kann auch die täglichen Konfigurationsaufgaben in Citrix Cloud automatisieren. Das Verschieben der Citrix DaaS-Konfiguration kann mehrere Vorteile bieten:

  • Synchronisieren der Site von der Testumgebung in die Produktion
  • Backup und Wiederherstellen Ihrer Konfiguration
  • Ressourcenlimits werden erreicht
  • Migration von Region zu Region

Das folgende 2-minütige Video bietet einen kurzen Überblick über die automatische Konfiguration.

Weitere Informationen zur automatischen Konfiguration finden Sie unter Proof of Concept: Automated Configuration Tool in der Tech Zone.

Detaillierte Informationen zum Migrieren Ihrer Bereitstellung und zur Vorbereitung der Konfiguration auf die Migration finden Sie unter Migrieren der On-Premises-Version von Citrix Virtual Apps and Desktops zu Citrix Cloud in der Tech Zone.

Herunterladen der automatischen Konfiguration

Laden Sie das Tool zur automatischen Konfiguration von Citrix Downloads herunter und installieren Sie es.

Wichtig:

Verwenden Sie immer die neueste verfügbare Version der automatischen Konfiguration, um Funktionsfehler zu vermeiden.

Upgrade der automatischen Konfiguration

Wenn Sie Cmdlets ausführen, die in der automatischen Konfiguration auf die Cloud zugreifen, erhalten Sie von dem Tool eine Benachrichtigung, wenn eine neuere Version zum Download verfügbar ist.

Upgrade der automatischen Konfiguration

Sie können mit folgendem Verfahren sicherstellen, dass Sie über die neueste Version verfügen:

  1. Doppelklicken Sie auf das Symbol Automatisches Konfigurieren. Ein PowerShell Fenster wird angezeigt.
  2. Führen Sie den folgenden Befehl aus, um die Versionsnummer zu überprüfen.

    Get-CvadAcStatus

  3. Prüfen Sie Ihre Version gegen die der in der Warnung oder unter Citrix Downloads aufgeführten Version. Die neueste Version befindet sich dort.
  4. Laden Sie die aktuelle Softwareversion des Tools von Citrix herunter und installieren Sie es. Sie müssen hierfür die alte Version nicht deinstallieren.

Hinweis:

Die Benachrichtigung wird jedes Mal angezeigt, wenn Sie ein Cmdlet ausführen, das auf die Cloud zugreift. Weitere Informationen zu Cmdlets finden Sie unter Cmdlets der automatischen Konfiguration.

Bekannte Einschränkungen

Unterstützte Migrationsobjekte

Die automatische Konfiguration unterstützt das Verschieben der Konfiguration der folgenden Komponenten:

  • Tags
  • Delegierter Admin
    • Geltungsbereiche
    • Rollen
  • Hostverbindungen
    • Ein einzelner Ressourcenpool
    • Admin-Geltungsbereiche
  • Maschinenkataloge
    • Admin-Geltungsbereiche
    • Maschinen
    • Remote-PC-Zugriff, physisch, gepoolt, bereitgestellt, MCS, zugewiesen
  • StoreFront
  • Bereitstellungsgruppen
    • Zugriffsrichtlinie
    • Admin-Bereichszuweisung
    • Anwendungszugriffsrichtlinie
    • Zuweisungsrichtlinie
    • Anspruch-/Desktoprichtlinie
    • Energiezeitpläne
    • Sitzungsfortbestehen
    • Vorabstart von Sitzungen
    • Neustartzeitpläne
    • Tags
  • Anwendungsgruppen
    • Admin-Bereichszuweisung
    • Bereitstellungsgruppen
    • Benutzer und Gruppen
  • Anwendungen
    • Anwendungsordner
    • Symbole
    • Anwendungen
    • Per Broker konfigurierte FTAs
    • Tags
  • Gruppenrichtlinien
  • Benutzerzonenpräferenzen

Reihenfolge der Komponentenmigration

Die Komponenten und ihre Voraussetzungen sind hier aufgelistet. Abhängigkeiten einer Komponente müssen vor dem Import oder dem Zusammenführen vorhanden sein. Wenn eine Voraussetzung fehlt, kann der Befehl zum Importieren oder Zusammenführen fehlschlagen. Im Abschnitt Fixups der Protokolldatei werden bei Fehlschlagen des Imports oder des Zusammenführens fehlende Voraussetzungen aufgelistet.

  1. Tags
    • Keine Voraussetzungen
  2. Delegierter Admin
    • Keine Voraussetzungen
  3. Hostverbindungen
    • Sicherheitsinformationen in CvadAcSecurity.yml
  4. Maschinenkataloge
    • In Active Directory vorhandene Maschinen
    • Hostverbindungen
    • Tags
  5. StoreFront
  6. Bereitstellungsgruppen
    • In Active Directory vorhandene Maschinen
    • In Active Directory vorhandene Benutzer
    • Maschinenkataloge
    • Tags
  7. Anwendungsgruppen
    • Bereitstellungsgruppen
    • Tags
  8. Anwendungen
    • Bereitstellungsgruppen
    • Anwendungsgruppen
    • Tags
  9. Gruppenrichtlinien
    • Bereitstellungsgruppen
    • Tags
  10. Benutzerzonenpräferenzen

Allgemeine Voraussetzungen

Im Folgenden sind einige allgemeine Voraussetzungen aufgeführt, die erfüllt sein müssen, damit die automatische Konfiguration ordnungsgemäß funktioniert. Diese Voraussetzungen gelten sowohl für die Migration von On-Premises in die Cloud als auch für die Migration von Cloud zu Cloud.

Generieren der Kunden-ID, der Client-ID und des geheimen Schlüssels

Vor dem Beginn der Migration mithilfe der automatischen Konfiguration benötigen Sie Ihre Citrix Cloud-Kunden-ID und müssen eine Client-ID sowie einen geheimen Schlüssel erstellen, um Ihre Konfiguration in Citrix Cloud zu importieren. Alle Cmdlets, die auf die Cloud zugreifen, benötigen diese Werte.

Mit dem folgenden Verfahren können Sie die Kunden-ID abrufen und die Client-ID und den geheimen Schlüssel erstellen.

Zum Abrufen der Kunden-ID gehen Sie wie folgt vor:

  1. Melden Sie sich bei Ihrem Citrix Cloud-Konto an und wählen Sie den Kunden aus.

    Kunden-ID, Abbildung 1

  2. Klicken Sie auf das Hamburger-Menü und wählen Sie die Option Identitäts- und Zugriffsverwaltung.

    Kunden-ID, Abbildung 2

  3. Die Kunden-ID ist auf der Seite Identitäts- und Zugriffsverwaltung.

    Kunden-ID, Abbildung 35

Zum Abrufen der Client-ID und des geheimen Schlüssels gehen Sie wie folgt vor:

  1. Klicken Sie auf der Seite Identitäts- und Zugriffsverwaltung auf API-Zugriff.

    Kunden-ID, Abbildung 3

  2. Geben Sie einen Namen in das Feld ein. Dieser Name wird zur Unterscheidung zwischen mehreren Client-IDs und geheimen Schlüsseln verwendet. Klicken Sie auf Client erstellen, um die Client-ID und den geheimen Schlüssel zu erstellen.

    Kunden-ID, Abbildung 4

  3. Wenn Sie die Client-ID und den geheimen Schlüssel erstellt haben, wird das folgende Dialogfeld angezeigt. Kopieren Sie beide Werte an einen sicheren Speicherort und laden Sie die CSV-Datei herunter, die diese Informationen enthält. Die CSV-Datei kann zum Erstellen der Datei CustomerInfo.yml verwendet werden.

    Kunden-ID, Abbildung 5

  4. Die Client-ID und der geheime Schlüssel werden erfolgreich erstellt.

    Kunden-ID, Abbildung 6

Speichern Sie diese Werte an einem sicheren Ort und teilen Sie sie nur mit vertrauenswürdigen Personen im Unternehmen, die Zugriff auf das Tool oder auf die Cloud-Rest-APIs benötigen. Die Client-ID und der geheime Schlüssel laufen nicht ab. Werden sie kompromittiert, entfernen Sie sie sofort mit dem Papierkorb-Symbol und erstellen Sie neue.

Hinweis:

Der geheime Schlüssel kann nicht wiederhergestellt werden, wenn er verloren geht oder vergessen wird. Er muss zusammen mit der Client-ID und neu erstellt werden.

Auffüllen der Kundeninformationsdatei

Die Verwendung der Datei CustomerInfo.yml macht das Hinzufügen von Kundeninformationen als Cmdlet-Parameter überflüssig. Jede Kundeninformation kann per Cmdlet-Parameter überschrieben werden.

Erstellen Sie die Datei CustomerInfo.yml mit dem Cmdlet New-CvadAcCustomerInfoFile.

Wichtig:

Bearbeiten Sie die Datei CustomerInfo.yml nicht manuell. Dies kann zu unbeabsichtigten Formatierungsfehlern führen.

New-CvadAcCustomerInfoFile hat die folgenden erforderlichen Parameter.

  • CustomerId: Kunden-ID.
  • ClientId: Client-ID des Kunden, die in Citrix Cloud erstellt wurde.
  • Secret: Kundengeheimnis, das in Citrix Cloud erstellt wurde.

New-CvadAcCustomerInfoFile -CustomerId markhof123 -ClientId 6813EEA6-46CC-4F8A-BC71-539F2DAC5984 -Secret TwBLaaaaaaaaaaaaaaaaaw==

Sie können die Datei CustomerInfo.yml auch mithilfe des Parameters SecurityCsvFileSpec erstellen, der auf die heruntergeladene Datei security.csv verweist. Sie müssen auch die CustomerID angeben.

New-CvadAcCustomerInfoFile -SecurityCsvFileSpec C:\Users\my_user_name\downloads/security.csv -CustomerId markhof123

Aktualisieren Sie die Datei CustomerInfo.yml mithilfe des Cmdlets Set-CvadAcCustomerInfoFile. Dieses Cmdlet ändert nur die Client-ID.

Set-CvadAcCustomerInfoFile -ClientId C80487EE-7113-49F8-85DD-2CFE30CC398E

Nachfolgend sehen Sie das Beispiel einer CustomerInfo.yml-Datei.

            # Created/Updated on 2020/01/29 16:46:47
            CustomerId: ‘markhof123’
            ClientId: ‘6713FEA6-46CC-4F8A-BC71-539F2DDK5384’
            Secret: ‘TwBLaaabbbaaaaaaaaaaw==’
            Environment: Production
            AltRootUrl: ‘’
            StopOnError: False
            AlternateFolder: ‘’
            Locale: ‘en-us’
            Editor: ‘C:\Program Files\Notepad++\notepad++.exe’
            Confirm: True
            DisplayLog: True

Auffüllen der Zonenzuordnungsdatei

Die On-Premises-Zone entspricht dem Cloudressourcenstandort. Im Gegensatz zu anderen Sitekomponenten können Sie die On-Premises-Zone nicht automatisch in die Cloud importieren. Sie muss stattdessen manuell über die Datei ZoneMapping.yml zugeordnet werden. Importfehler können auftreten, wenn der Zonenname keinem bestehenden Ressourcenstandort zugewiesen ist.

Bei On-Premises-Sites mit nur einer Zone und Cloudsites mit nur einem Ressourcenstandort führt die automatische Konfiguration die richtige Zuordnung durch, sodass die ZoneMapping.yml-Datei nicht manuell verwaltet werden muss.

Bei On-Premises-Sites mit mehreren Zonen und bei Cloudsites mit mehreren Ressourcenstandorten muss die ZoneMapping.yml-Datei manuell aktualisiert werden, damit sie die korrekte Zuordnung von On-Premises-Zonen zu Cloud-Ressourcenstandorten widerspiegelt. Dies muss vor dem Import in die Cloud erledigt werden.

Die Datei ZoneMapping.yml ist in %HOMEPATH%\Documents\Citrix\AutoConfig. Die YML-Datei beinhaltet ein Wörterbuch mit dem Zonennamen als Schlüssel und dem Ressourcennamen als Wert.

Beispiel: Eine Citrix Virtual Apps and Desktops-On-Premises-Site mit der primären Zone “Zone-1” und der sekundären Zone “Zone-2” wird in eine Citrix DaaS-Bereitstellung mit den beiden neu erstellten Cloud-Ressourcenstandorten “Cloud-RL-1” und “Cloud-RL-2” migriert. In diesem Fall würde ZoneMapping.yml wie folgt konfiguriert:

            Zone-1: Cloud-RL-1

            Zone-2: Cloud-RL-2

Hinweis:

Ein Leerzeichen muss zwischen dem Doppelpunkt und dem Namen des Ressourcenstandorts stehen. Wenn ein Zonen- oder Ressourcenstandortname Leerzeichen enthält, setzen Sie den Namen in Anführungszeichen.

Hostverbindungen

Hostverbindungen und die zugehörigen Hypervisoren können mit der automatischen Konfiguration exportiert und importiert werden.

Das Hinzufügen eines Hypervisors zu einer Hostverbindung erfordert Hypervisortyp-spezifische Sicherheitsinformationen. Diese Informationen können aus Sicherheitsgründen nicht aus der On-Premises-Site exportiert werden. Sie müssen die Informationen manuell bereitstellen, damit die automatische Konfiguration Hostverbindungen und Hypervisors in die Cloudsite importieren kann.

Beim Exportieren wird die Datei CvadAcSecurity.yml in %HOMEPATH%\Documents\Citrix\AutoConfig erstellt. Sie enthält Platzhalter für jedes für den spezifischen Hypervisortyp benötigte Sicherheitselement. Sie müssen die Datei CvadAcSecurity.yml vor dem Import in die Cloudsite aktualisieren. Administratorupdates werden über mehrere Exportvorgänge beibehalten und bei Bedarf neue Sicherheitsplatzhalter hinzugefügt. Sicherheitselemente werden nie entfernt.

            HostConn1:
            ConnectionType: XenServer
            UserName: root
            PasswordKey: rootPassword
            HostCon2:
            ConnectionType: AWS
            ApiKey: 78AB6083-EF60-4D26-B2L5-BZ35X00DA5CH
            SecretKey: TwBLaaaaaaaaaaaaaaaaaw==
            Region: East

Hypervisor-spezifische Sicherheitsinformationen

Nachfolgend werden die für die einzelnen Hypervisortypen erforderlichen Sicherheitsinformationen aufgeführt.

  • XenServer, Hyper-V, VMware
    • Benutzername
    • Klartextkennwort
  • Microsoft Azure
    • Abonnement-ID
    • Anwendungs-ID
    • Anwendungsgeheimnis
  • Amazon Web Services
    • Dienstkonto-ID
    • Anwendungsgeheimnis
    • Region

Besondere Sicherheitsüberlegungen

Alle Sicherheitsinformationen werden als Klartext eingegeben. Wenn Klartext nicht empfohlen wird, können die Hostverbindungen und die zugehörigen Hypervisors manuell über die Oberfläche Verwalten > Vollständige Konfiguration erstellt werden. Die Namen von Hostverbindungen und Hypervisors müssen mit ihrem On-Premises-Gegenstück übereinstimmen, damit Maschinenkataloge, die die Hostverbindungen verwenden, erfolgreich importiert werden.

Aktivieren der Sites

Der Delivery Controller steuert in On-Premises- und Cloudsites Ressourcen wie das Brokering von Desktops und Anwendungen und den Neustart von Maschinen. Probleme treten auf, wenn Ressourcen von zwei oder mehr Sites gesteuert werden. Eine solche Situation kann bei der Migration von einer On-Premises-Site zu einer Cloudsite auftreten. On-Premises- und Cloud-Delivery Controller können die gleichen Ressourcen verwalten. Eine solche duale Verwaltung kann dazu führen, dass Ressourcen nicht mehr verfügbar sind oder nicht mehr verwaltet werden können und dass eine Diagnose schwierig wird.

Durch die Siteaktivierung können Sie vorgeben, wo die aktive Site gesteuert wird.

Die Siteaktivierung wird über den Bereitstellungsgruppen-Wartungsmodus verwaltet. Bereitstellungsgruppen werden in den Wartungsmodus versetzt, wenn die Site inaktiv ist. Der Wartungsmodus wird Bereitstellungsgruppen in aktiven Sites beendet.

Die Siteaktivierung hat weder Einfluss auf die VDA-Registrierung und Maschinenkataloge noch erfolgt durch sie eine Verwaltung dieser Objekte.

  • Set-CvadAdSiteActiveStateCloud
  • Set-CvadAdSiteActiveStateOnPrem

Alle Cmdlets unterstützen IncludeByName und ExcludeByName Filter. Über diesen Parameter können Sie vorgeben, bei welchen Bereitstellungsgruppen der Wartungsmodus geändert werden kann. Bereitstellungsgruppen können bei Bedarf selektiv geändert werden.

Importieren und Übertragen der Steuerung in die Cloud

Im Folgenden finden Sie eine allgemeine Beschreibung des Verfahrens zum Importieren und Übertragen der Steuerung von der On-Premises-Site in die Cloudsite.

  1. Exportieren und importieren Sie die On-Premises-Site in die Cloud. Stellen Sie sicher, dass der Parameter –SiteActive in keinem der Cmdlets zum Importieren verwendet wird. Die On-Premises-Site ist aktiv und die Cloudsite inaktiv. Standardmäßig befinden sich Cloudsite-Bereitstellungsgruppen im Wartungsmodus.
  2. Überprüfen Sie den Inhalt und die Konfiguration der Cloud.
  3. Legen Sie die On-Premises-Site außerhalb der Geschäftszeiten auf inaktiv fest. Der Parameter –SiteActive darf nicht vorhanden sein. Alle Bereitstellungsgruppen der On-Premises-Site sind im Wartungsmodus.
    • Set-CvadAcSiteActiveStateOnPrem
  4. Legen Sie die Cloudsite auf aktiv fest. Der Parameter –SiteActive muss vorhanden sein. Keine Cloudsite-Bereitstellungsgruppe ist im Wartungsmodus.
    • Set-CvadAcSiteActiveStateCloud –SiteActive
  5. Vergewissern Sie sich, dass die Cloudsite aktiv und die On-Premises-Site inaktiv ist.

Rückübertragen der Steuerung in die On-Premises-Site

Zum Rückübertragen der Steuerung von der Cloudsite in die On-Premises-Site gehen Sie folgendermaßen vor:

  1. Legen Sie die Cloudsite außerhalb der Geschäftszeiten auf inaktiv fest. Alle Cloudsite-Bereitstellungsgruppe sind im Wartungsmodus.
    • Set-CvadAcSiteActiveStateCloud
  2. Legen Sie die On-Premises-Site auf aktiv fest. Keine Bereitstellungsgruppe der On-Premises-Site ist im Wartungsmodus.
    • Set-CvadAcSiteActiveStateOnPrem -SiteActive

Zusätzliche Informationen zur Siteaktivierung

  • Sind keine Maschinen energieverwaltet und gibt es keine Neustartzeitpläne (was normalerweise bedeutet, dass keine Hostverbindungen bestehen), können alle Cloud-Bereitstellungsgruppen als aktiv importiert werden. Fügen Sie -SiteActive zu Merge-CvadAcToSite/Import-CvadAcToSite hinzu oder führen Sie nach dem Importieren Set-CvadAcSiteActiveStateCloud -SiteActive aus.
  • Gibt es energieverwaltete Maschinen oder Neustartpläne, ist ein anderer Prozess erforderlich. Legen Sie in diesem Fall beispielsweise beim Umstieg von einer On-Premises-Bereitstellung zur Cloud die On-Premises-Site mit Set-CvadAcSiteActiveStateOnPrem auf inaktiv fest. Legen Sie dann die Cloudsite mit Set-CvadAcSiteActiveStateCloud -SiteActive auf aktiv fest.
  • Die Cmdlets Set-CvadAcSiteActiveStateCloud und Set-CvadAcSiteActiveStateOnPrem werden auch verwendet, um den Prozess umzukehren. Führen Sie beispielsweise Set-CvadAcSiteActiveStateCloud ohne den Parameter -SiteActive aus und dann Set-CvadAcSiteActiveStateOnPrem mit dem Parameter -SiteActive.

Grundlegendes zur Migration von mit Maschinenerstellungsdiensten bereitgestellten Katalogen

Hinweis:

Dieses Feature ist nur ab Version 3.0 verfügbar. Zur Überprüfung der Version verwenden Sie Get-CvadAcStatus in der automatischen Konfiguration.

MCS-Kataloge erstellen zwei verschiedene Arten von Katalogen:

  • Wenn Änderungen an einer Maschine verloren gehen/rückgängig gemacht werden (üblicherweise Server-OS, wo Anwendungen veröffentlicht werden). Dies ist ein gepoolte VDI-/Multisitzung-Anwendungsfall.
  • Wenn Änderungen an einer Maschine während des Neustarts beibehalten werden (üblicherweise Client-Betriebssystem mit einem dedizierten Benutzer). Dies ist ein Anwendungsfall für statische VDI.

Der Katalogtyp kann im Katalogknoten in Citrix Studio und anhand des Werts “Benutzerdaten:” des Katalogs überprüft werden.

Hinweis:

MCS kann nicht mithilfe der automatischen Konfiguration aus der Cloud gesichert werden.

Gepoolte VDI-/Multisitzungskataloge

Kataloge mit “Benutzerdaten: Verwerfen” sind gepoolte VDI-Kataloge und können nur das Hauptimage und die Konfiguration migrieren. Virtuelle Maschinen in diesen Katalogen werden von der Migration ausgeschlossen. Das liegt daran, dass der Lebenszyklus der virtuellen Maschine von der Site verwaltet wird, von der Sie importieren, was bedeutet, dass sich der Status bei jedem Einschalten der Maschinen ändern kann. Dies macht den Import unmöglich, da die Synchronisierung der Importdaten für die virtuellen Maschinen schnell verloren geht.

Wenn Sie diese Kataloge mithilfe des Tools migrieren, erstellt das Tool Katalogmetadaten und initiiert die Erstellung des Hauptimages, es werden jedoch keine Maschinen importiert.

Da dieser Prozess je nach der Größe des Hauptimages einige Zeit dauern kann, startet der Importbefehl innerhalb des Tools die Katalogerstellung mit MCS nur, wartet jedoch nicht, bis sie abgeschlossen ist. Überwachen Sie nach Abschluss des Imports den Fortschritt der Katalogerstellung mithilfe der Schnittstelle für die vollständige Konfiguration in der Cloud-Bereitstellung.

Sobald das Hauptimage erstellt wurde, können Sie Maschinen bereitstellen. Es müssen Kapazitätsüberlegungen berücksichtigt werden, da Kapazität aus der On-Premises-Nutzung verbraucht wird.

Alle anderen Objekte (Bereitstellungsgruppen/Anwendungen/Richtlinien usw.), die diesen Katalog verwenden, können importiert werden und müssen nicht auf die Erstellung des Hauptimages warten. Wenn die Erstellung des Katalogs abgeschlossen ist, können Maschinen zum importierten Katalog hinzugefügt werden, und dann können Benutzer ihre Ressourcen starten.

Hinweis:

Verwenden Sie dieselben im Tool verfügbaren Befehle zur Migration von Katalogen und allen anderen Objekten.

Statische VDI-Kataloge

Hinweis:

Da dieser Vorgang Low-Level-Details importiert, die in der Datenbank gespeichert sind, muss dieser Prozess von einer Maschine mit Datenbankzugriff ausgeführt werden.

Statische VDI-Kataloge migrieren das Hauptimage, die Konfigurationen und alle virtuellen Maschinen. Im Gegensatz zum Anwendungsfall für gepoolte VDI müssen keine Images erstellt werden.

Die VDAs müssen auf den Connector verweisen, damit sie sich bei der Cloud registrieren können.

Aktivieren Sie die Cloudsite mithilfe der Informationen im Abschnitt Aktivieren der Sites, damit der Neustartzeitplan, die Energieverwaltung und andere Elemente von der Cloud gesteuert werden.

Wenn Sie nach Abschluss der Migration diesen Katalog von Ihrer On-Premises-Site löschen möchten, müssen Sie die Option zum Belassen des VM- und AD-Kontos auswählen. Andernfalls werden sie gelöscht und die Cloudsite würde auf die gelöschte VM verweisen.