Erstellen neuer Citrix MCS-Maschinen mit PowerShell

Noch bevor Sie die Schritte zum Erstellen der Maschinen ausführen, müssen die CVAD PowerShell-Cmdlets geladen werden. Vor der Version 1912 (LTSR) wurden diese als (Legacy-)Snap-Ins bereitgestellt, wohingegen sie ab dieser Version als Module verfügbar sind (lesen Sie den ersten Teil dieser Serie für weitere Informationen: Eine Einführung in PowerShell in Citrix Virtual Apps and Desktops).

Der folgende Code funktioniert in allen Versionen, um die in diesem Beitrag verwendeten Cmdlets zu laden:

Der Code kann auf einem Citrix Delivery Controller oder auf einem beliebigen Rechner ausgeführt werden, auf dem Citrix Studio oder die CVAD PowerShell-Cmdlets installiert sind, wobei letzteres aus Gründen des Ressourcenverbrauchs bevorzugt wird.

Wenn letzteres verwendet wird, muss den Citrix-Cmdlets der Parameter-AdminAddress angegeben werden, um die Aufrufe an einen bestimmten Delivery Controller zu leiten. Sofern die zweite Option verwendet wird, muss den Citrix-Cmdlets der Parameter -AdminAddress mitgegeben werden, um die Aufrufe an einen bestimmten Delivery Controller zu richten.

Abbildung 2 zeigt die daraus folgende Ausgabe.

Abb. 2: Überprüfung eines bestimmten Identitätspools mit Get-AcctIdentityPool

Wir können sehen, dass dieser den vorhandenen MCS-Maschinenkatalogen entspricht (Abbildung 3):

Abb. 3: Die Liste der Kataloge zeigt die vorhandenen MCS-Kataloge.

Um die Active Directory-Konten für die neuen Maschinen zu erstellen, führen wir Folgendes aus, wobei wir zwei Maschinenkonten unter Verwendung der Namenskonvention und der OU erstellen, die im angegebenen Identitätspool definiert sind – beachten Sie, dass wir den Namen oder die Namensbasis nicht selbst angeben müssen:

Wir haben das Ergebnis in eine Variable übertragen, da wir es im nächsten Schritt verwenden wollen, aber wir können das Ergebnis überprüfen, indem wir uns den Inhalt dieser Variable anzeigen lassen (Abbildung 4):

Abb. 4: Inhalt der Variable $newAccounts

Wenn Sie im AD nachschauen, sollten Sie sehen, dass diese Maschinenkonten in der richtigen OU erstellt wurden.

Wir müssen nun die virtuellen Maschinen erstellen, die diesen AD-Konten entsprechen, und dazu benötigen wir den Namen des Bereitstellungsschemas, der bei der Erstellung des MCS-Maschinenkatalogs erstellt wurde und wie bei den Identitätspools denselben Namen wie der Katalog aufweist, zu dem er gehört.

Abb. 5: Abrufen des Namens des Provisioningschemas über PowerShell

Beim Erstellen der VMs erstellen wir eine Aufgabe, die entweder synchron ausgeführt werden kann, sodass das Cmdlet erst dann ausgegeben wird, wenn die Aufgabe vollständig abgeschlossen ist, oder asynchron ausgeführt wird, sodass das Cmdlet sofort ausgegeben wird.

Im letzteren Fall müssen Sie prüfen, ob die Aufgabe abgeschlossen ist, bevor Sie fortfahren. Dies kann sinnvoll sein, wenn die Aufgabe so lange dauern könnte, dass andere Aktionen ausgeführt werden müssen oder eine Fortschrittsanzeige angezeigt werden muss.
Im gegebenen Fall führen wir sie asynchron aus, um zu zeigen, wie wir prüfen, ob die Aufgabe abgeschlossen ist.

Die Aufgaben-GUID ist in der Variablen gespeichert, die wir abfragen können, wie in Abbildung 6 zu sehen ist:

Abb. 6: Eigenschaften der Variable $taskDetails

Beachten Sie die Eigenschaften Active, Status, TaskState und TaskStateInformation die wir verwenden können, um zu testen, ob die Aufgabe abgeschlossen ist oder nicht. Achten Sie außerdem darauf, dass Sie bei der Überprüfung der Eigenschaften in einer Schleife eine Art Verzögerung einbauen, wie z.B. via Start-Sleep, um den CPU-Verbrauch dieser Polling-Schleife zu reduzieren.

Nachdem wir nun die VMs erstellt haben, was Sie in Ihrer Hypervisor-Konsole überprüfen können, können wir sie als Maschinen zu einem Maschinenkatalog hinzufügen. Das Beispiel unten hat einen Platzhalter für die Fehlerbehandlung, falls ein Fehler auftreten sollte – Vernachlässigen Sie auf keinen Fall die Fehlerkontrolle!

Abbildung 7 zeigt, dass die Ausführung erfolgreich war:

Abb. 7: Das Suchergebnis zeigt alle VMs, die Teil des Maschinenkatalogs „MCS Server 2019“ sind

Damit die neu erstellten Maschinen für Endanwender verfügbar sind, müssen sie zu einer Bereitstellungsgruppe gehören, was folgendermaßen erreicht wird:

Wie erwartet, zeigt Abbildung 8, dass die Maschinen erfolgreich zur Bereitstellungsgruppe hinzugefügt wurden.

Abb. 8: Das Suchergebnis zeigt alle VMs, die Teil der „MCS Server 2019“-Bereitstellungsgruppe sind

Angenommen, dies alles ist gelungen, bleibt nur noch, die neuen Maschinen in Betrieb zu nehmen, damit sie booten, sich bei einem Bereitstellungscontroller registrieren und von dort aus für die Bereitstellung veröffentlichter Anwendungen und/oder Desktops verfügbar werden.

Beachten Sie im Code-Beispiel unten, dass der in der Variablen „$taskDetails“ enthaltene Computerkontoname geändert wird, indem das „$“-Zeichen am Ende des Namens entfernt wird, um ihn in einen AD-Computernamen umzuwandeln.

Dies wird mit einem regulären Ausdruck (regex) erreicht, wobei $ ein Sonderzeichen ist, das das Ende der Zeichenfolge bedeutet, sodass wir es mit dem Backslash-Zeichen escapen müssen.

Wenn alles korrekt funktioniert hat, sollte Citrix Studio nun die neu erstellten Rechner anzeigen (Abbildung 9) und nach einer kurzen Verzögerung, damit sie booten können, sollten sie registriert sein und somit verwendet werden können, um Anwendungen und/oder Desktops bereitzustellen, die die Bereitstellungsgruppe verwenden.

Abb. 9: Überblick über die neu erstellte VM im Citrix Studio

Die Konfiguration neuer VM mit MCS über PowerShell bietet die klassischen Vorteile gescripteter Lösungen: Genauigkeit, Standardisierbarkeit und Reproduzierbarkeit. Auch die daraus resultierende Zeitersparnis ist nicht zu vernachlässigen.

In Kombination mit ScriptRunner eröffnen sich jedoch noch mehr Möglichkeiten: Die Erstellung neuer VMs kann beispielsweise vollständig automatisiert und sogar an Helpdesk und Endanwender delegiert werden. Dabei bleiben alle Vorgänge sicher, fehlerfrei und nachvollziehbar.

Wir sprechen gerne unverbindlich mit Ihnen darüber wie sie diese oder auch andere Use Cases in ihrem Unternehmen mit ScriptRunner realisieren können. Buchen Sie dazu einfach einen Termin mit unseren Produktexperten.