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 Sophos Central mogło właściwie je traktować.
Wybór ten wpływa również na porządkowanie w Central. 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 --products=endpoint --goldimage
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 Central 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 Central gromadzi obiekty mimo czyszczenia VDI.
Lifecycle w Central
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.
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 Central.
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 Central Endpoint.