Univention Bugzilla – Bug 21291
Automatisieren des sysprep Ablauf
Last modified: 2023-03-25 06:52:32 CET
Der Ablauf ist wie folgt vorgesehen: - Admin installiert - Admin klont optional die VM - ucs-sysprep.exe aufgerufen liegt auf einem Share - Versiegelung durchführen und UVMM anweisen, dass aus dieser Instanz eine Vorlage generiert wird (Instanz wird verschoben) - Erkennung läuft per MAC Adresse
Die Images sollten dabei vollkommen unabhängig von der Umgebung sein. Somit sollte es möglich sein, dass wir ein Image in allen DVS Umgebungen starten können.
(In reply to comment #1) > Die Images sollten dabei vollkommen unabhängig von der Umgebung sein. Somit > sollte es möglich sein, dass wir ein Image in allen DVS Umgebungen starten > können. Eine Idee ist es, einfach ein Platten- oder Floppyimage mit den notwendigen Informationen/Tools zu integrieren. Die sysprep Tools können diese dann verwenden.
Es soll unterschiedliche Möglichkeiten geben eine Zuordnung durchzuführen: - Versiegelung Im Idealfall würde eine vollautomatisierte Versiegelung durchgeführt. Im UMC DVS Template wird ausgewählt welche Instanz als Vorlage verwendet werden soll. Optional kann eine Kopie dieser Instanz erzeugt werden, da das Template später nicht mehr als neue Vorlage für ein Template verwendet werden kann. Als nächstes wird eine Festplatte vorbereitet und in die Instanz konfiguriert. Auf dieser Festplatte liegt eine vorgefertigte sysprep-inf-Datei, sowie andere Tools, wie beispielsweise ucs-dvs-auto-sysprep.exe. Dieses Tool ermöglicht die One-Click-Versiegelung. Optional könnte eine Autorun-Information auf dem System ausgeführt werden, so dass die Versiegelung automatisch durchgeführt wird. Von extern direkt auf das Dateisystem schreiben und beispielsweise die automatische Versiegelung über autoexec.bat oder andere Tools halte ich für zu fehleranfällig. Unter Windows 7 wird die autoexec.bat scheinbar auch nicht mehr automatisch in jedem Fall ausgeführt. Die Vorlage wird also einmal gestartet und der Administrator bekommt einen Hinweistext zur Versiegelung und einen VNC-Link auf die Instanz. Natürlich kann der Administrator auch auf unsere Tools zur Versiegelung verzichten und diese eigenständig durchführen. Optional kann der Startvorgang auch übersprungen werden, falls das Image bereits versiegelt ist. Nach der Versiegelung wird das Template registriert. Während des Sysprep-Vorgang wird für die beiden ersten Varianten dann eine Festplatte oder ein Floppy Image eingebunden, auf dem die notwendigen Informationen liegen: P:\SYSPREP\local-settings.bat P:\SYSPREP\HOOK1\ P:\SYSPREP\HOOK2\ P:\SYSPREP\HOOK3\ Die Datein in den Hook Verzeichnissen werden jeweils vor jedem Reboot ausgeführt. HOOK1 vor dem ersten Reboot, HOOK2 vor dem zweiten usw. - Zuordnung ohne Templates Als Alternative kann auch komplett auf Templates verzichtet werden. In diesem Fall installiert der Administrator die Desktop-Instanzen eigenständig und kann dann im Managementsystem (UDM oder UMC) die Zuordnung (Desktop Instanz <-> Benutzer) durchführen.
Der Ablauf soll leicht anders werden. Es wird kein Image eingebunden, da wir wollen, dass die Admins mit Windows Boardmitteln auch die sysprep.inf usw. anpassen können. Deshalb wird es in der Domäne ein Share geben, auf dem die Daten für die Versiegelung liegen. Diese Daten werden dann in die Instanz kopiert. Es wird dann aber keine Netzwerkverbindung mehr während der sysprep-Phase aufgebaut. Wenn also ein neuer Hook da ist, dann muss die Versiegelung einmal erneut ausgeführt werden.
Es wird jetzt pro Sysprep Rechner ein Join User angelegt. Allerdings scheint das nicht zu funktionieren, wenn der Sysprep Rechner ein Memberserver ist: Memberserver: root@xen12:~# net rpc rights -UAdministrator%univention grant dvs-autojoin-xen12 SeMachineAccountPrivilege Failed to grant privileges for dvs-autojoin-xen12 (NT_STATUS_ACCESS_DENIED) DC Master: root@dvsmaster:~# net rpc rights -UAdministrator%univention grant dvs-autojoin-xen12 SeMachineAccountPrivilege Successfully granted rights.
(In reply to comment #5) > Es wird jetzt pro Sysprep Rechner ein Join User angelegt. Allerdings scheint > das nicht zu funktionieren, wenn der Sysprep Rechner ein Memberserver ist: > > Memberserver: > root@xen12:~# net rpc rights -UAdministrator%univention grant > dvs-autojoin-xen12 SeMachineAccountPrivilege > Failed to grant privileges for dvs-autojoin-xen12 (NT_STATUS_ACCESS_DENIED) > > DC Master: > root@dvsmaster:~# net rpc rights -UAdministrator%univention grant > dvs-autojoin-xen12 SeMachineAccountPrivilege > Successfully granted rights. Der Benutzer war lokal noch nicht bekannt, nscd Probleme.
(In reply to comment #6) > (In reply to comment #5) > > Es wird jetzt pro Sysprep Rechner ein Join User angelegt. Allerdings scheint > > das nicht zu funktionieren, wenn der Sysprep Rechner ein Memberserver ist: > > > > Memberserver: > > root@xen12:~# net rpc rights -UAdministrator%univention grant > > dvs-autojoin-xen12 SeMachineAccountPrivilege > > Failed to grant privileges for dvs-autojoin-xen12 (NT_STATUS_ACCESS_DENIED) > > > > DC Master: > > root@dvsmaster:~# net rpc rights -UAdministrator%univention grant > > dvs-autojoin-xen12 SeMachineAccountPrivilege > > Successfully granted rights. > > Der Benutzer war lokal noch nicht bekannt, nscd Probleme. Der "net rpc rights"-Befehl muss auf dem DC Master ausgeführt werden. Das einfachste wird sein die Rechte ins LDAP zu verlagern: Bug #2619
Die meisten Punkte sind jetzt soweit umgesetzt. Ich denke es wäre noch gut, wenn der Admin einen Hinweis bekommt, wenn in der sysprep.inf bzw. sysprep.xml die Seriennummer und / oder der Company Name fehlt. Für die QA, bitte auch mit einem anderen Passwort als univention testen.
Ich habe UCS-DVS-Sysprep-interactive.bat gerade angepasst, weil der Architektur-Check auch x86-Systeme als 64-bit Systeme erkannte: * check %processor_architecture% in UCS-DVS-Sysprep-interactive.bat (Bug #21291)
Alles soweit in den Bug #21290 und Bug #21289 umgesetzt. Alle Dateien und Scripte liegen auf dem DVS Share des Sessionbroker. DVS bringt nun für WinXP und Win7 (32 und 64 Bit) die sysprep Startscripte UCS-DVS-Sysprep-*.bat mit. Diese werden vom Benutzer gestartet und kopieren alle nötigen Dateien und Skripte auf lokal auf den Rechner. Dann wird geprüft, ob die sysprep Konfigurationen angepasst wurden (es gibt Felder, die wir mit "must be changed" belegen, beispielsweise ProductKey oder Password, diese müssen vom Benutzer angepasst werden.) Danach wird (bei den interactive Skripten) das Tool für die Anpassung/Erstellung der Sysprep Konfigs aufgerufen. Zuletzt wird dann sysprep gestartet. Nachdem das System wieder gestartet wurde, wird die Windows Setup durchlaufen und dann unser "Konfigurationsscript" (post-sysprep.bat für Winxp, post-sysprep. vbs für Win7) ausgeführt. Dieses setzt den Namen, Joint den Rechner in die Domäne und aktiviert RemoteDesktop 1. sysprep 2. post-sysprep setname SYSPREP\HOOK1\ reboot 3. post-sysprep join SYSPREP\HOOK2\ reboot 4. post-sysprep remotedesktop SYSPREP\HOOK3\ shutdown Nach dem erneutemn Start des Rechners, sollte er den im DNS hinterlegten Namen haben, in die Domäne aufgenommen sein und RemoteDesktop + RemoteDesktop Gruppe + Firewall Exception sollten konfiguriert sein. Es muss dann ein Verbindung mit einem Domänenbenutzer (!= Admin) mit RDP auf den Rechner möglich sein. Extra Tools: Für WinXP braucht man noch das sysprep auf der deploy.cab (wird im Join Skript geladen).
Werden die Hooks 1-3 verwendet, so scheint der Abschluss (posthook3) nicht erreicht zu werden. Ich habe in jedem Hook je eine Datei anlegen lassen (hook1, hook2, hook3) - im Anschluss an das Sysprep habe ich eine laufende Administratorsitzung. Die Dateien hook1 und hook2 wurden angelegt, hook3 nicht. Ebenso findet sich noch der vollständige sysprep-post Ordner auf der Platte.
(In reply to comment #11) > Werden die Hooks 1-3 verwendet, so scheint der Abschluss (posthook3) nicht > erreicht zu werden. Genaugenommen springt das Skript scheinbar genau _nach posthook2 raus - :remoteuser wird bereits nicht mehr erreicht (Firewallexception ist nicht eingetragen).
Die Dateien in den HOOK Verzeichnissen werden nun mit "CALL" aufgerufen, damit wird das eigentlich Script nicht beendet (wie bisher der Fall).
Für Windowx XP funktioniert nun alles - Windows 7 meldet einen fehler beim Sysprep bei Vernwendung von Hooks. Siehe Screenshot
Created attachment 3246 [details] fail in win7 sysprep while using hooks
Man kann den Fehler wegklicken - der Sysprepvorgang wird dann aber beendet und befindet sich inmitten der Session.
Fehler beim Löschen der Hook Verzeichnisse werden nun übergangen, außerdem wurde der "Lösch" Funktion noch der Parameter force ( == True) übergeben " The optional force parameter returns a Boolean value - True allows folders with read-only attributes to be deleted, while False (default) does not. " Paket ist gebaut und in der Testumgebung installiert. Bitte damit noch testen.
(In reply to comment #17) > Fehler beim Löschen der Hook Verzeichnisse werden nun übergangen, außerdem > wurde der "Lösch" Funktion noch der Parameter force ( == True) übergeben > > " The optional force parameter returns a Boolean value - True allows folders > with read-only attributes to be deleted, while False (default) does not. " > > Paket ist gebaut und in der Testumgebung installiert. Bitte damit noch testen. Ok, der Fehler wird an dieser Stelle nun übersprungen und der Sysprepvorgang wird erfolgreich zuende geführt. Bzgl. des Problems mit dem nicht ernfernbaren Ordner habe ich Bug #22425 erstellt.