WAN-Konfiguration aktiv, Installation erfolgt trotzdem direkt vom Depot statt aus lokalem Cache
Verfasst: 04 Sep 2026, 14:42
Hallo zusammen,
wir beobachten auf mehreren Clients mit aktivierter WAN-Konfiguration ein Verhalten, bei dem bereits gecachte Produkte beim anschließenden Neustart nicht aus dem lokalen Produkt-Cache, sondern direkt vom Depot über `P:` installiert werden.
Aktuell können wir das auf einem Client gut nachvollziehen.
Der Client verwendet opsi 4.3, Server-Version:
`4.3.37.7`
opsi-script:
`4.12.21.0`
Die WAN-Konfiguration wurde über `opsi-wan-config-on` aktiviert.
Erwartetes Verhalten:
Unser bisheriges und normalerweise funktionierendes Vorgehen bei WAN-Clients ist:
1. Ein Produkt wird auf `setup` gesetzt.
2. Der Client lädt das Produkt über den Cache-Service in den lokalen Produkt-Cache.
3. Nach Abschluss des Cachings erfolgt ein Neustart.
4. Beim nächsten Systemstart wird das Produkt aus `C:\opsi.org\cache\depot` installiert.
Dieses Verhalten funktioniert bei unseren WAN-Clients grundsätzlich und wurde auch mit anderen Produkten bereits erfolgreich verwendet.
Aktuelles Verhalten:
Bei Google Chrome sehen wir nun einen abweichenden Ablauf.
Der Cache-Service lädt die benötigten Produkte zunächst herunter. Im Log findet sich später auch:
All products cached: googlechrome, opsi-script
Der lokale Produkt-Cache wird also grundsätzlich aufgebaut.
Beim anschließenden Systemstart wird Chrome jedoch nicht aus dem lokalen Cache ausgeführt.
Stattdessen mountet opsiclientd das Depot:
Mounting depot share smb://opsi.unsere.domäne/opsi_depot
Mounting CIFS share '\\opsi.unsere.domäne\opsi_depot' to 'p:'
Im opsi-script-Log wird anschließend ebenfalls `P:` als Depotpfad verwendet:
Depot path from readconfig: p:\
Depot path: p:\
Das Chrome-Script wird direkt von dort gestartet:
scriptname: "install.ins", special path: "p:\googlechrome\"
und auch die eigentliche MSI-Installation erfolgt vom Depot:
msiexec /i p:\googlechrome\googlechromestandaloneenterprise64.msi /qn
Auffälligkeiten in den Events:
Bei der Analyse der `opsiclientd`-Logs ist uns aufgefallen, dass beim Systemstart teilweise folgender Zustand besteht:
Preconditions for event config 'gui_startup{cache_ready}' not fulfilled:
{'config_cached': True, 'products_cached': False}
Preconditions for event config 'gui_startup{installation_pending}' fulfilled:
{'installation_pending': True}
Daraufhin wird gui_startup{installation_pending} verarbeitet.
Für `gui_startup{cache_ready}` sehen wir:
useCachedConfig: True
useCachedProducts: True
während für `gui_startup{installation_pending}`:
useCachedConfig: False
useCachedProducts: False
verwendet wird.
Der Cache-Service arbeitet währenddessen teilweise noch weiter. Später findet sich dann:
All products cached: googlechrome, opsi-script
Wir sind uns daher nicht sicher, ob hier ein Timing-/Statusproblem zwischen Cache-Service, `products_cached`, `config_cached` und dem beim Systemstart ausgewählten Event vorliegt.
Frage:
Warum wird das zuvor gecachte Produkt beim nächsten Systemstart nicht aus dem lokalen Produkt-Cache installiert, sondern das Depot erneut als `P:` eingebunden und die Installation von dort ausgeführt?
Insbesondere würden wir gerne verstehen, unter welchen Bedingungen opsi beim Systemstart entscheidet, `gui_startup{cache_ready}` und damit `useCachedProducts=True` zu verwenden.
Ist es normal, dass trotz zuvor erfolgtem Caching beim nächsten Start zunächst:
products_cached = False
vorliegt und dadurch stattdessen `gui_startup{installation_pending}` verarbeitet wird?
Falls dieses Verhalten auf eine fehlerhafte oder unvollständige WAN-Konfiguration bei uns hindeutet: Welche ConfigStates bzw. Event-Einstellungen sollten wir hierfür insbesondere prüfen?
Wir können die vollständigen `opsiclientd.log`- und `opsi-script.log`-Dateien sowie die relevanten Client-Konfigurationen zur Verfügung stellen.
Vielen Dank.
wir beobachten auf mehreren Clients mit aktivierter WAN-Konfiguration ein Verhalten, bei dem bereits gecachte Produkte beim anschließenden Neustart nicht aus dem lokalen Produkt-Cache, sondern direkt vom Depot über `P:` installiert werden.
Aktuell können wir das auf einem Client gut nachvollziehen.
Der Client verwendet opsi 4.3, Server-Version:
`4.3.37.7`
opsi-script:
`4.12.21.0`
Die WAN-Konfiguration wurde über `opsi-wan-config-on` aktiviert.
Erwartetes Verhalten:
Unser bisheriges und normalerweise funktionierendes Vorgehen bei WAN-Clients ist:
1. Ein Produkt wird auf `setup` gesetzt.
2. Der Client lädt das Produkt über den Cache-Service in den lokalen Produkt-Cache.
3. Nach Abschluss des Cachings erfolgt ein Neustart.
4. Beim nächsten Systemstart wird das Produkt aus `C:\opsi.org\cache\depot` installiert.
Dieses Verhalten funktioniert bei unseren WAN-Clients grundsätzlich und wurde auch mit anderen Produkten bereits erfolgreich verwendet.
Aktuelles Verhalten:
Bei Google Chrome sehen wir nun einen abweichenden Ablauf.
Der Cache-Service lädt die benötigten Produkte zunächst herunter. Im Log findet sich später auch:
All products cached: googlechrome, opsi-script
Der lokale Produkt-Cache wird also grundsätzlich aufgebaut.
Beim anschließenden Systemstart wird Chrome jedoch nicht aus dem lokalen Cache ausgeführt.
Stattdessen mountet opsiclientd das Depot:
Mounting depot share smb://opsi.unsere.domäne/opsi_depot
Mounting CIFS share '\\opsi.unsere.domäne\opsi_depot' to 'p:'
Im opsi-script-Log wird anschließend ebenfalls `P:` als Depotpfad verwendet:
Depot path from readconfig: p:\
Depot path: p:\
Das Chrome-Script wird direkt von dort gestartet:
scriptname: "install.ins", special path: "p:\googlechrome\"
und auch die eigentliche MSI-Installation erfolgt vom Depot:
msiexec /i p:\googlechrome\googlechromestandaloneenterprise64.msi /qn
Auffälligkeiten in den Events:
Bei der Analyse der `opsiclientd`-Logs ist uns aufgefallen, dass beim Systemstart teilweise folgender Zustand besteht:
Preconditions for event config 'gui_startup{cache_ready}' not fulfilled:
{'config_cached': True, 'products_cached': False}
Preconditions for event config 'gui_startup{installation_pending}' fulfilled:
{'installation_pending': True}
Daraufhin wird gui_startup{installation_pending} verarbeitet.
Für `gui_startup{cache_ready}` sehen wir:
useCachedConfig: True
useCachedProducts: True
während für `gui_startup{installation_pending}`:
useCachedConfig: False
useCachedProducts: False
verwendet wird.
Der Cache-Service arbeitet währenddessen teilweise noch weiter. Später findet sich dann:
All products cached: googlechrome, opsi-script
Wir sind uns daher nicht sicher, ob hier ein Timing-/Statusproblem zwischen Cache-Service, `products_cached`, `config_cached` und dem beim Systemstart ausgewählten Event vorliegt.
Frage:
Warum wird das zuvor gecachte Produkt beim nächsten Systemstart nicht aus dem lokalen Produkt-Cache installiert, sondern das Depot erneut als `P:` eingebunden und die Installation von dort ausgeführt?
Insbesondere würden wir gerne verstehen, unter welchen Bedingungen opsi beim Systemstart entscheidet, `gui_startup{cache_ready}` und damit `useCachedProducts=True` zu verwenden.
Ist es normal, dass trotz zuvor erfolgtem Caching beim nächsten Start zunächst:
products_cached = False
vorliegt und dadurch stattdessen `gui_startup{installation_pending}` verarbeitet wird?
Falls dieses Verhalten auf eine fehlerhafte oder unvollständige WAN-Konfiguration bei uns hindeutet: Welche ConfigStates bzw. Event-Einstellungen sollten wir hierfür insbesondere prüfen?
Wir können die vollständigen `opsiclientd.log`- und `opsi-script.log`-Dateien sowie die relevanten Client-Konfigurationen zur Verfügung stellen.
Vielen Dank.