Sophos Endpoint in VDI-Gold-Images vorbereiten
Ein normal installierter Endpoint darf nicht einfach als VDI-Template geklont werden. Dabei entstehen doppelte Geräteidentitäten, fehlerhafte Richtlinienzuweisungen und unzuverlässige Health-Daten. Sophos stellt für Windows-Gold-Images deshalb einen eigenen Installations- und Aktivierungsmodus bereit.
Unterstützt werden aktuelle Windows-Client- und Windows-Server-Versionen ab Windows 10 beziehungsweise Server 2016 mit den von Sophos geforderten Mindestversionen von Thin Installer und Core Agent. Vor dem Aufbau wird die aktuelle Supported-Systems-Seite geprüft.
Einschränkungen
Ein Gold Image wird nicht zusammen mit Server Lockdown, Update Cache oder BitLocker Device Encryption vorbereitet. Diese Funktionen widersprechen dem Image-Lifecycle oder erzeugen einen Zustand, der nicht sauber auf Klone übertragen werden kann.
Tamper Protection wird während der Vorbereitung kontrolliert deaktiviert und vor dem Abschluss wieder aktiviert. Der Master bleibt administrativ geschützt und wird nicht als normaler Benutzer-Endpoint verwendet.
Persistent oder non-persistent
Bei persistenten Desktops bleibt die Geräteidentität nach der Bereitstellung bestehen. Nicht persistente Desktops werden regelmässig neu erzeugt und benötigen den Installerparameter --nonpersistent, damit Sophos Central sie entsprechend behandeln kann.
Diese Wahl beeinflusst auch die Bereinigung in Central. Für non-persistent VDI kann eine Regel in Removal of Inactive Devices die veralteten Klone endgültig entfernen. Der Master, der mit --goldimage erstellt wurde, wird von diesen Regeln nicht erfasst.
Master vorbereiten
Das saubere Ausgangssystem wird vollständig gepatcht und erhält alle produktiven Anwendungen. Erst danach wird Sophos mit dem vorgesehenen Gold-Image-Modus installiert. Ein vereinfachtes Beispiel lautet:
SophosSetup.exe --quiet --products=endpoint --goldimage
Für non-persistent Desktops kommt die passende Option hinzu. Gruppe, Proxy, Relay und weitere Installerparameter werden wie bei einem normalen automatisierten Rollout bewusst festgelegt.
Der Standard-Timeout für die Gold-Image-Vorbereitung beträgt 120 Sekunden und kann im dokumentierten Bereich von 0 bis 900 Sekunden angepasst werden. Ein höherer Wert ist keine allgemeine Fehlerbehebung, sondern nur für eine tatsächlich langsamere Vorbereitung gedacht.
Notification Mode
Mit SophosSetup.exe --goldimage --notificationmode registriert sich der Master zunächst in Central und kommuniziert bis zum nächsten Neustart. Danach bleibt die Kommunikation deaktiviert, bis auf dem unveränderten Master GoldImageCli.exe activate oder in der lokalen Oberfläche Activate and Update ausgeführt wird. Ein bereitgestellter Klon wird dagegen mit GoldImageCli.exe clone aktiviert.
GoldImageCli verhindert clone, solange sich der Computername nicht geändert hat, und verhindert activate, sobald er geändert wurde. Für VMware-Horizon-Instant-Clones wird C:\Program Files\Sophos\AutoUpdate\GoldImageCli.exe mit dem Parameter clone als Post-Synchronization Script hinterlegt.
Der genaue Ablauf wird in der verwendeten Image-Pipeline automatisiert und protokolliert. Ein Snapshot wird erst freigegeben, wenn der Sophos-Status eindeutig den vorgesehenen Zustand zeigt.
Klone nur aus dem Master
Neue Desktops entstehen immer direkt aus dem vorbereiteten Gold Image. Ein bereits gestarteter Klon wird nicht als neues Template verwendet. Sonst werden Runtime-Zustand und Identitätsdaten erneut vervielfältigt.
Nach dem ersten Start eines Klons werden neue Geräteidentität, Gruppe, Agent Mode, Policies und Update geprüft. Eine erfolgreiche Anmeldung allein beweist nicht, dass Sophos den Klon korrekt als eigenes Gerät registriert hat.
Für nicht persistente Pools wird ein begrenzter, wiederverwendeter Satz von Computernamen verwendet. Seine Grösse entspricht ungefähr der maximal gleichzeitig laufenden Instanzzahl. Bei jedem Neustart ständig neue Namen zu erzeugen bläht Gerätebestand und Lizenzsicht unnötig auf. Das Gastbetriebssystem entscheidet zudem über das Produkt: Ein Windows-Server-OS mit Desktop-Oberfläche erscheint weiterhin als Server, verbraucht Server-Lizenz und erhält Server-Policies.
Lifecycle in Central
Nicht persistente Klone erzeugen viele kurzlebige Geräteobjekte. Unter Global Settings > Products and Services > Endpoint and Server > Removal of Inactive Devices wird eine gezielte Regel für die VDI-Gruppe erstellt. Permanently remove VDI desktops entfernt passende Klone ohne spätere Wiederherstellung.
Diese Option wird nur für eindeutig abgegrenzte non-persistent Gruppen aktiviert. Eine zu breite globale Regel könnte normale Offline-Notebooks entfernen. Update Caches und Message Relays werden von einer Wiederherstellung gelöschter Geräte nicht wiederhergestellt.
Upgrade des Gold Image
Agent- oder Betriebssystemupdates werden zuerst auf einer Kopie des Masters getestet. Danach wird ein neues freigegebenes Image erzeugt. Ein abgelaufenes Fixed-Term- oder LTS-Paket darf nicht im Master verbleiben, weil neue Klone sonst ohne aktuelle Schutzupdates starten.
Software Packages steuern Produktfunktions-Updates, nicht die laufenden Threat-Protection-Inhalte. Diese Schutzdaten werden weiterhin automatisch aktualisiert. Ohne festes Software Package kann jede neu gestartete Instanz unmittelbar ein Produktupgrade beginnen; deshalb wird der Updatekanal des Masters vor der Freigabe bewusst festgelegt.
Nach jedem Image-Release werden mindestens ein persistenten und, falls genutzt, ein non-persistenter Clone vollständig geprüft. Doppelte Geräteerkennungen, falsche Gruppen oder gehäufte Re-Registrierungen sind Stop-Kriterien.
Troubleshooting
Bei Duplicate-Device-Alerts wird zuerst geprüft, ob wirklich --goldimage verwendet und direkt aus dem Master geklont wurde. Ein normales Image lässt sich nicht zuverlässig durch nachträgliches Löschen von Central-Objekten reparieren.
Erscheinen Klone nicht oder bleiben ungeschützt, werden Netzwerkzugriff, Proxy beziehungsweise Relay und Installer-Logs geprüft. Bei falschem Lifecycle folgt die Kontrolle von --nonpersistent und der Zielgruppe der Removal-Regel.
Bei Citrix App Layering wird Sophos in einer eigenen App Layer statt in der OS Layer vorbereitet. Die Layer-Pipeline benötigt die von Sophos dokumentierten UniRSD-Ausnahmen für Endpoint Defense; fehlen sie, können Dienste nach dem Zusammenbau trotz aktivem Tamper Protection nicht starten. Da Central während Layer-Erstellung und Template-Nutzung bereits Geräte- und Benutzerevents sehen kann, werden Layer-Namen, Testkonten und Freigabezeitpunkt dokumentiert. Der genaue Citrix-Registry-Ablauf bleibt versionsgebunden an das aktuelle Sophos-KBA.
Sophos unterstützt Endpoint in vielen Virtualisierungsplattformen, sofern das Gastbetriebssystem selbst unterstützt ist. Das ersetzt nicht die Supportmatrix des Hypervisor-Herstellers. Microsoft unterstützt beispielsweise auf Azure Stack HCI Version 1 keine Drittanbieter-Antivirenlösung auf den Hosts; ein Sophos-Agent dort würde den Microsoft-Supportpfad verlassen.
Verwandte Artikel
Die allgemeinen CLI-Optionen erklärt Sophos Endpoint unter Windows automatisiert ausrollen. Gerätebereinigung und Wiederherstellung stehen in Sophos Central Endpoint-Geräte und Gruppen verwalten.