Przejdz do tresci
Avanet

Przygotowanie Sophos Endpoint w VDI Gold Image

Normalnie zainstalowanego Endpointa nie wolno po prostu klonować jako VDI Template. Powstają zduplikowane tożsamości, błędne Policies i niewiarygodny Health. Sophos udostępnia specjalny tryb dla Windows Gold Images.

Obsługiwane są aktualne Windows Client i Server od Windows 10 lub Server 2016 z wymaganymi minimalnymi wersjami Thin Installer i Core Agent. Przed budową sprawdza się Supported Systems.

Ograniczenia

Gold Image nie przygotowuje się z Server Lockdown, Update Cache ani BitLocker Device Encryption. Funkcje te są sprzeczne z lifecycle obrazu lub tworzą stan, którego nie można poprawnie przenieść do klonów.

Tamper Protection jest kontrolowanie wyłączana podczas przygotowania i ponownie włączana przed końcem. Master pozostaje chroniony administracyjnie i nie służy jako zwykły Endpoint użytkownika.

Persistent czy non-persistent

W Persistent Desktops tożsamość urządzenia pozostaje po wdrożeniu. Non-persistent Desktops są regularnie tworzone ponownie i wymagają parametru Installer --nonpersistent, aby platforma Sophos Fusion (wcześniej Sophos Central) mogła właściwie je traktować.

Wybór ten wpływa również na porządkowanie w Sophos Fusion. Dla non-persistent VDI reguła Removal of Inactive Devices może trwale usuwać przestarzałe klony. Master utworzony z --goldimage nie jest objęty tymi regułami.

Przygotowanie Master

Czysty system bazowy otrzymuje wszystkie patches i aplikacje produkcyjne. Dopiero potem Sophos instaluje się w przewidzianym Gold Image Mode. Uproszczony przykład wygląda następująco:

SophosSetup.exe --quiet --goldimage --products=endpoint --devicegroup="VDI\Persistent"

Dla non-persistent dodaje się właściwą opcję. Grupa, Proxy, Relay i pozostałe parametry są świadomie określane jak w zwykłym rollout.

Standardowy Timeout przygotowania Gold Image wynosi 120 sekund i można go dostosować w udokumentowanym zakresie od 0 do 900 sekund. Wyższa wartość nie jest ogólnym rozwiązaniem błędów, lecz służy wyłącznie faktycznie wolniejszemu przygotowaniu.

Notification Mode

Po użyciu SophosSetup.exe --goldimage --notificationmode Master rejestruje się początkowo w Sophos Fusion i komunikuje do następnego restartu. Następnie komunikacja pozostaje wyłączona, dopóki na Master bez zmienionej nazwy nie zostanie uruchomione GoldImageCli.exe activate albo Activate and Update. Wdrożony Clone aktywuje się poleceniem GoldImageCli.exe clone.

GoldImageCli blokuje clone, dopóki nazwa komputera się nie zmieni, oraz blokuje activate po jej zmianie. Dla Instant Clones VMware Horizon należy skonfigurować C:\Program Files\Sophos\AutoUpdate\GoldImageCli.exe z parametrem clone jako Post-Synchronization Script.

Dokładny proces jest automatyzowany i logowany w używanej Image Pipeline. Snapshot zostaje zatwierdzony dopiero wtedy, gdy status Sophos jednoznacznie pokazuje przewidziany stan.

Klony tylko z Master

Nowe Desktop powstają zawsze bezpośrednio z przygotowanego Gold Image. Uruchomionego klonu nie używa się jako nowego Template, bo powiela Runtime State i dane tożsamości.

Po pierwszym uruchomieniu klonu sprawdza się nową tożsamość urządzenia, grupę, Agent Mode, Policies i Update. Samo pomyślne logowanie nie dowodzi, że Sophos prawidłowo zarejestrował klon jako odrębne urządzenie.

Dla non-persistent pool użyj ograniczonego, ponownie używanego zestawu nazw wielkości maksymalnej liczby instancji. Bez limitu Sophos Fusion gromadzi obiekty mimo czyszczenia VDI.

Lifecycle w Sophos Fusion

Non-persistent Clones tworzą wiele krótkotrwałych obiektów. W Global Settings > Products and Services > Endpoint and Server > Removal of Inactive Devices tworzy się Targeted Rule dla grupy VDI. Permanently remove VDI desktops usuwa klony bez odzyskiwania.

Opcja jest używana tylko dla jednoznacznych grup non-persistent. Zbyt szeroka reguła mogłaby usunąć zwykłe offline Notebooks. Update Caches i Message Relays nie wracają po Restore Deleted Devices.

Upgrade Gold Image

Update agenta lub systemu testuje się najpierw na kopii Master, potem wydaje nowy obraz. Wygasły Fixed Term lub LTS Package nie może pozostać w Master, bo klony startowałyby bez aktualnych Protection Updates.

Po każdym wydaniu obrazu w pełni testuje się co najmniej jeden Persistent Clone oraz, jeśli jest używany, jeden Non-persistent Clone. Duplicate Device Detections, błędne grupy i częste ponowne rejestracje są kryteriami Stop.

Software Packages steruje funkcjami, nie treścią Threat Protection aktualizowaną automatycznie. Bez stałego pakietu każda nowa instancja może rozpocząć upgrade. Ustaw kanał Master przed wydaniem.

Bezpieczny odbiór i rollback

Sprawdzenie trybu i wymagań

Timeout Mode domyślnie sprawdza nazwę komputera po 120 sekundach; --goldimagetimeout=<sekundy> przyjmuje od 0 do 900. Notification Mode jest przeznaczony dla VMware Horizon Instant Clone i zapobiega rejestracji maszyn pośrednich. Aktualne wymagania CLI Sophos dla tego trybu to Thin Installer 1.20.627 lub nowszy, Core Agent 2024.2.0.527 lub nowszy albo Server Core Agent 2024.2.0.534 lub nowszy. Timeout Mode wymaga Thin Installer 1.14 oraz Core Agent lub Server Core Agent 2022.1.0.78 albo nowszego.

Przed instalacją utworzyć przetestowany snapshot do wycofania, sprawdzić łączność z Sophos Fusion i dokładną grupę VDI oraz wyłączyć Tamper Protection. Nie używać urządzenia z Server Lockdown, Update Cache, BitLocker ani komponentami Sophos Encryption. Pełny przykład dla nieutrwalonej puli Horizon:

.\SophosSetup.exe --quiet --goldimage --notificationmode --nonpersistent --products=endpoint --devicegroup="VDI\NonPersistent"

Uszczelnienie obrazu

Poczekać na zakończenie instalacji, potwierdzić obecność Master we właściwej grupie bez lokalnych błędów Health i ponownie włączyć Tamper Protection. W Notification Mode Master komunikuje się do pierwszego restartu, a następnie celowo pozostaje offline. C:\Program Files\Sophos\AutoUpdate\GoldImageCli.exe activate uruchamiać wyłącznie na niezmienionym Master, a C:\Program Files\Sophos\AutoUpdate\GoldImageCli.exe clone wyłącznie na gotowym klonie ze zmienioną nazwą. Horizon może uruchamiać program z parametrem clone jako skrypt post-synchronization. Wyłączyć zweryfikowany Master, uszczelnić snapshot w stanie wyłączonym i zachować poprzedni zatwierdzony obraz do pomyślnego odbioru klonów.

Walidacja tożsamości i lifecycle

Uruchomić co najmniej dwa klony bezpośrednio z Master. Dla każdego sprawdzić unikalną nazwę i osobny obiekt Sophos Fusion, właściwą licencję Endpoint lub Server, grupę i Policies, aktualną wartość Last active, prawidłowy Health i zakończone aktualizacje. Sophos czyści odziedziczoną konfigurację dopiero po wykryciu zmiany nazwy. Nie zastępować tego usuwaniem plików, kluczy rejestru, usług Sophos ani obiektu Sophos Fusion. Sophos wycofał również wcześniejsze ręczne i skryptowe metody zapobiegania zduplikowanym tożsamościom. Od Core Agent 2022.1 i Central Installer 1.14 należy zamiast nich stosować opisany tutaj proces z przełącznikami instalatora. Jeśli platforma nie może wykonać nadania nazwy i akcji klonowania w tej kolejności, zatrzymać wdrożenie i dostosować proces platformy lub obrazu; nie wracać do starego skryptu czyszczącego.

Dla puli non-persistent trzeba połączyć --nonpersistent z Permanently remove VDI desktops. Trwałego usunięcia VDI nie można cofnąć, a klienci MSP i Marketplace muszą ustawić co najmniej 31 dni. Sophos Fusion zezwala na maksymalnie dwie reguły Targeted, które nie mogą zawierać wykluczeń; okres nieaktywności reguły Global musi być dłuższy niż okres każdej reguły Targeted. Do tworzenia lub zmieniania tych reguł wymagana jest rola Admin lub Super Admin. Sophos Fusion sprawdza urządzenia co 24 godziny o północy regionu danych. Najpierw przetestować Targeted Rule ograniczoną do grupy VDI; Master --goldimage nie podlega regułom usuwania.

Wycofanie po błędzie

Przy zduplikowanych tożsamościach, błędzie rejestracji lub złych Policies zatrzymać rollout puli, odrzucić wadliwe klony i wrócić do ostatniego zatwierdzonego, wyłączonego template. Usunięcie obiektu Sophos Fusion nie naprawia lokalnej tożsamości. Master aktualizować tylko w kontrolowanym cyklu i publikować nowy snapshot dopiero po pomyślnym teście klonów.

Troubleshooting

Przy Duplicate Device Alerts sprawdza się --goldimage i klonowanie bezpośrednio z Master. Zwykłego obrazu nie naprawia się niezawodnie przez późniejsze usuwanie obiektów Sophos Fusion.

Przy brakujących lub niechronionych klonach sprawdza się sieć, Proxy/Relay i Installer Logs. Przy złym lifecycle: --nonpersistent i Target Group reguły Removal.

W Citrix App Layering przygotuj Sophos we własnej App Layer, nie OS Layer. Pipeline wymaga udokumentowanych wyjątków UniRSD; bez nich usługi mogą zawieść mimo Tamper Protection. Dokumentuj warstwy, konta i czas, a procedurę Registry wiąż z aktualnym KBA.

Sophos wspiera wiele platform przy wspieranym guest OS, ale nie zastępuje matrycy hypervisora. Microsoft nie wspiera antywirusa firm trzecich na hostach Azure Stack HCI v1; Sophos wyłącza tam ścieżkę wsparcia Microsoft.

Powiązane artykuły

Opcje CLI opisuje Automatyczne wdrażanie Sophos Endpoint w Windows. Czyszczenie urządzeń: Zarządzanie urządzeniami i grupami Sophos Fusion Endpoint.

Częste pytania

Czy zwykły Endpoint można sklonować jako VDI Template?

Nie. Master musi być przygotowany w Gold Image Mode, inaczej grożą zduplikowane tożsamości i problemy zarządzania.

Czy non-persistent VDI są automatycznie usuwane z Sophos Fusion?

Tylko z odpowiednią Removal of Inactive Devices Rule i opcją trwałego usuwania VDI, ograniczoną do jednoznacznej grupy.