Background Install: Installation bei angemeldeten Benutzer

Mit der Erweiterung opsi-background-install können Sie Software bei angemeldeten Benutzer im Hintergrund installieren. Ist bei einer Installation ein Konflikt mit laufender Software zu erwarten, so wird die Installation verschoben oder der Benutzer nach dem gewünschten Vorgehen gefragt.

Voraussetzungen

Die Erweiterung ist derzeit (05.2025) in der Pilotphase, welche dazu dient Fehler und Probleme im Design der Erweiterung zu finden. Die Nutzung wird in dieser Pilotphase nur einem kleinen Kreis von Kunden ermöglicht um die Auswirkungen von evtl. nötigen Änderungen klein zu halten.

Dieses Modul ist momentan eine kostenpflichtige Erweiterung. Das heißt, dass Sie eine Lizenz-Datei benötigen. Sie erhalten diese, nachdem Sie die Erweiterung gekauft haben. Zu Evaluierungszwecken stellen wir Ihnen kostenlos eine zeitlich befristete Lizenz zur Verfügung. Bitte kontaktieren Sie uns dazu per E-Mail.

Weitere Details hierzu finden Sie im Kapitel opsi-Erweiterungen.

Einführung

Anlass

Der Wunsch Software bei eingeloggtem Benutzer und (potentiell) laufender Software zu installieren kommt durch:

  • 24/7 Betrieb wie z.B. in Krankenhäusern

  • Keine Möglichkeit für nächtliche Installation per WakeOnLan

  • Verändertes Nutzerverhalten, insbesondere bei Laptops: Nutzer loggen sich nie aus und lassen Programme laufen (und klappen den Laptop zu).

Probleme

Der Versuch bei eingeloggtem Benutzer zu installieren, führt zu einer Reihe von Problemen:

  • Sichtbarkeit: Störung durch auf poppende Fenster.

  • Installationskonflikte: Konflikte mit laufender Software.

Probleme

Problem: Sichtbarkeit

Die Fülle von Fenstern und Meldungen welche während einer Installation ohne eingeloggtem Benutzer durchaus sinnvoll sind, entsprechen nicht den Anforderungen an eine Installation im Hintergrund.

Problem: Installationskonflikte

Das hier beschriebene Problem ist im Kern Windows spezifisch. Unter Unixoiden (Linux / MacOS) ist es in der Regel kein Problem laufende Software auszutauschen ohne das ein dabei laufender Prozess die Installation stört bzw. selbst gestört wird.
Unter Windows ist der Austausch einer Datei, welche in Verwendung ist, nicht möglich bzw. benötigt einen Reboot. Die Datei (.exe) eines Programms welches läuft ist also in Verwendung. Der Versuch diese Datei auszutauschen, führt bei laufender Software also unweigerlich zu einem Problem.

Daher ist diese Erweiterung auch nur für Windows implementiert.

Die Art der auftretenden Probleme bei Installationskonflikten können unterschiedlichster Natur sein, und sind wenn sie mal aufgetreten sind, nicht mehr automatisch zu beheben. Daher muß das Auftreten von Installationskonflikten im Vorfeld vermieden werden.

Auch wenn diese Erweiterung hilft, das Problem zu umgehen, es bleibt dabei:
Der beste Zeitpunkt um Software auf einem Windowssystem zu installieren ist wenn kein User eingeloggt ist, also üblicherweise beim Hoch- oder Herunterfahren.
Nicht ohne Grund sind das genau die Systemzustände welche Windows selber zum Einspielen von Updates verwendet.

Konzept

Sichtbarkeit

Hier sind keine Änderungen am Script und Konfiguration nötig, da alles nötige bereits im opsi-client-agent implementiert ist:

  • opsi-script läuft nur auf dem winlogon Desktop

  • opsi-event Notifier läuft nur auf dem winlogon Desktop

  • Interaktive Dialoge des opsi-script werden über den opsiclientd auf dem current Desktop angezeigt

Fehler vermeiden

Vor der (De)installation muß auf störende laufende Prozesse geprüft werden. Dazu müssen die kritischen Prozesse bekannt sein. Diese werden ermittelt aus:

  • Dem Installationsverzeichnis des Produktes.
    Alle *.exe innerhalb des Installationsverzeichnis sind potentiell bedenkliche Prozesse. Als Dienst laufende Prozesse werden nicht als störende Prozesse gesehen.

Die Umsetzung der notwendigen Prüfungen erfolgt im Interpreter opsi-script.exe. Eine Anpassung der Scripte in vorhanden opsi-Produkten ist also nicht nötig.
Vielmehr benötigt ein opsi-Produkt zusätzliche Metadaten um für eine Backgroundinstallation bereit gemacht zu werden.
Im opsi-script ist implementiert worden:

  • Neuer Produktstatus deferred zum verschieben von Installationen:

    • Neuer Berichtsstatus (neben success, failed, suspended):
      'deferred'

    • Installationstatus: unverändert (installed)

    • Bericht: deferred

    • Actionrequest: bleibt erhalten (setup)

    • Installierte Version: unverändert

  • Erkennung und Interpretation der Metadatendatei:

    • Ist diese Produkt für die Background Installation zugelassen ?

    • Ermittlung der potentiell störenden Prozesse

    • Überprüfung ob störende Prozesse laufen

    • Gegebenenfalls interaktive Abfrage was mit diesen Prozessen geschehen soll:
      Verschieben (defer) oder der Start des Actionrequests

Background Install Aktivierung

Um die Erweiterung opsi-background-install zu aktivieren müssen Sie folgendes tun:

  • Einspielen einer Lizenz für die Erweiterung.

  • Den Config opsi-script.backgroundinstall.active auf true setzen.

Ablauf der Prüfungen im opsi-script

  1. Sind Benutzer eingeloggt ?
    Wenn nicht, so liegt keine Background Install Situation vor und von daher sind auch keine weitere Untersuchung nötig und der Actionrequest wird ausgeführt.

  2. background install enabled ?
    Ist der Config opsi-script.backgroundinstall.active nicht auf true gesetzt, so ist diese Erweiterung nicht aktiviert und der Actionrequest wird ohne weitere Prüfung fortgesetzt.

  3. Ist eine Lizenz für opsi-background-install eingespielt ?
    Wenn nein, so gibt es eine Fehlermeldung im Log und der Actionrequest wird ohne weitere Prüfung fortgesetzt.

  4. Sind alle der 3 vorangegangenen Bedingungen erfüllt, so befinden wir uns in einer Background Install Situation bei der nun versucht wird mögliche Installationskonflikte zu vermeiden.

  5. Gibt eine Meta-Daten Datei ?
    Wenn nein, dann wird die Installation verschoben (deferred). Es gibt einen entsprechende Warnung im Log. Ein opsi-Produkt kann aus diesem Grund beliebig häufig verschoben werden. D. h. MAX_DEFER greift hier nicht.
    Das heißt auch: Alle opsi-produkte welche Sie noch nicht mit einer entsprechenden Metadaten Datei versehen haben, können nicht in einer Background Install Situation installiert werden.

  6. Erstellung der Liste kritischer Prozesse.

    • Aus der Meta Datei wird der Eintrag check_processes_from_dirs ausgelesen. Die hier angegebene Verzeichnisse werden auf Programme geprüft und diese in die Liste kritischer Prozesse aufgenommen.

    • Aus der Meta Datei wird der Eintrag processes ausgelesen. Die hier angegebene Programme werden der Liste kritischer Prozesse hinzu gefügt.

    • Aus der Liste kritischer Prozesse werden werden alle nicht laufenden Prozesse entfernt.

    • Aus der Liste kritischer Prozesse werden werden alle laufenden Service Prozesse entfernt.

  7. Enthält die Liste kritischer Prozesse noch mindestens einen Eintrag ?
    Wenn nein, so wird der Actionrequest wird ohne weitere Prüfung fortgesetzt.

  8. Ist DIALOG_TIMEOUT > 0 ?
    Wenn nein, wird die DEFAULT_ACTION (üblicherweise = defer) gewählt.

  9. Der Benutzerdialog wird angezeigt.
    Gibt es innerhalb des DIALOG_TIMEOUT (üblicherweise = 60 Sekunden) keine Antwort des Benutzers, so wird die DEFAULT_ACTION (üblicherweise = defer) gewählt.

  10. recheck gewählt
    Ist recheck mehr als MAX_RECHECK (3) in Folge gewählt worden, so wird die Möglichkeit recheck nicht mehr angeboten und die DEFAULT_ACTION ist nun MAX_RECHECK_ACTION (defer).

  11. defer gewählt
    Ist defer mehr als MAX_DEFER (5) in Folge gewählt worden, so wird die Möglichkeit 'defer' nicht mehr angeboten und die DEFAULT_ACTION ist nun MAX_DEFER_ACTION (kill).

  12. kill gewählt
    Ist kill gewählt, so schießt opsi-script den / die störende(n) Prozesse ab und und der Actionrequest wird fortgesetzt.

Dialog: `Programme stoppen`
Abbildung 1. opsi-setup-detector: Dialog: Programme stoppen

Konfiguration über configs

Die Defaults und wie sie über Configs Hostparameter konfigurierbar sind.
Die Configs finden sich unter: opsi-script.backgroundinstall:

  • active (Default zunächst false)
    Dieser Defaultwert kann mit dem Config opsi-script.backgroundinstall.active überschrieben werden.

  • Default nach Timeout ist defer ('Jetzt nicht')
    (DEFAULT_ACTION=defer)
    Dieser Defaultwert kann mit dem Config opsi-script.backgroundinstall.default_action überschrieben werden.

  • Timeout ist 60 Sekunden
    (DIALOG_TIMEOUT=60)
    DIALOG_TIMEOUT = 0 bedeutet keine Interaktivität,
    es wird also direkt die DEFAULT_ACTION ausgeführt.
    Dieser Defaultwert kann mit dem Config opsi-script.backgroundinstall.dialog_timeout überschrieben werden.

  • Nach 3 mal recheck in Folge, wird MAX_RECHECK_ACTION gewählt
    (MAX_RECHECK=3)
    Dieser Defaultwert kann mit dem Config opsi-script.backgroundinstall.max_recheck überschrieben werden.

  • Der Default für MAX_RECHECK_ACTION=defer
    Dieser Defaultwert kann mit dem Config opsi-script.backgroundinstall.max_recheck_action überschrieben werden.

  • Nach 5 mal defer in Folge, wird MAX_DEFER_ACTION gewählt
    (MAXDEFER=5)
    Dieser Defaultwert kann mit dem Config opsi-script.backgroundinstall.max_defer überschrieben werden.

  • Der Default für MAX_DEFER_ACTION=kill
    Dieser Defaultwert kann mit dem Config opsi-script.backgroundinstall.max_defer_action überschrieben werden.

Für den Fall das diese Configs noch nicht vorhanden sind, (wie z.B. in der Pilotphase)
können diese mit folgenden Kommandozeilen-Befehlen angelegt werden:
 
opsi-cli jsonrpc execute config_createBool opsi-script.backgroundinstall.active "bg-active" false
opsi-cli jsonrpc execute config_createUnicode opsi-script.backgroundinstall.default_action "bg-default_action" '["defer", "recheck", "kill"]' "defer" "false" "false"
opsi-cli jsonrpc execute config_createUnicode opsi-script.backgroundinstall.dialog_timeout "bg-dialog_timeout" "60" "60"
opsi-cli jsonrpc execute config_createUnicode opsi-script.backgroundinstall.max_recheck "bg-max_recheck" "3" "3"
opsi-cli jsonrpc execute config_createUnicode opsi-script.backgroundinstall.max_recheck_action "bg-max_recheck_action" '["defer", "recheck", "kill"]' "defer" "false" "false"
opsi-cli jsonrpc execute config_createUnicode opsi-script.backgroundinstall.max_defer "bg-max_defer" "5" "5"
opsi-cli jsonrpc execute config_createUnicode opsi-script.backgroundinstall.max_defer_action "bg-max_defer_action" '["defer", "recheck", "kill"]' "kill" "false" "false"

Die Metadaten Datei: opsi-meta-data.toml

Damit ein opsi-produkt per background_install korrekt funktioniert, muss es einige zusätzliche Metadaten enthalten. Diese werden in der Datei opsi-meta-data.toml abgelegt und zwar im Verzeichnis CLIENT_DATA. Diese Datei im TOML-Format muss für die Background Installation folgende Informationen enthalten:

  • Für jede betroffene Setup / Installer Datei eine Tabelle installers. Diese enthält die folgenden Informationen:

    • Informationen über die zu prüfender Prozesse:
      Die Listen der zu prüfenden Verzeichnisse: check_processes_from_dirs und die Liste zusätzlicher Prozesse processes. Sind beide Listen leer, so wird auf keine laufenden Prozesse geprüft.

    • Weiterhin kann hier der Eintrag install_in_background=false enthalten sein. Existiert dieser Eintrag, so bedeutet dies, das dieses Produkt nicht in einer Background Install Situation eingespielt werden darf. Gründe hierfür könnten benötigte Reboots oder andere nicht behandelbare Seiteneffekte sein.
      Existiert dieser Eintrag nicht so gilt der Default: install_in_background=true.

  • In der Tabelle installers.requirement:

    • Die Angabe des benötigten Betriebssystems (os).
      Erlaubt sind hier windows, linux, macos.
      Die Erweiterung opsi-background-install ist nur für Windows implementiert.
      Wird kein passender OS Eintrag gefunden, so geht das Produkt auf failed.

    • Die Angabe der Architektur des benötigten Betriebssystems (os_arch).
      Erlaubt sind hier x86, x64, arm64, arch_unknown. Auf einem x64 Windows Betriebssystem ist auch die Anforderung x86 erfüllt. Auf einem x86 Windows Betriebssystem ist die Anforderung x64 nicht erfüllt. Die Anforderung arch_unknown ist immer erfüllt.

Eine gültige opsi-meta-data.toml enthält für andere Zwecke noch weitere Daten:

  • Eine Tabelle specification mit der Angabe der Version der Datenspezifikation.

  • Eine Tabelle product mit der Angabe des Namens der Produkticondatei.

  • In der Tabelle installers:

    • die Angabe des Pfads (path) zur Installerdatei. Die Pfadangabe darf opsi-script Konstanten enthalten.

    • die Angabe des Installationsverzeichnisses (install_dir) zur Installerdatei. Die Pfadangabe darf opsi-script Konstanten enthalten.

  • In der Tabelle installers.requirement:

    • die Angabe des benötigten Platz in MB (required_space_MB).

Beispiele

Metadaten-Datei (Beispiel Background Installation - Beispiel 1)

Eine Windows Setupdatei - minimal Konfiguration

[specification]
version = '0.1'

[product]
product_icon_file_path = 'dummy.png'

[[installers]]
path = '%scriptpath%\files1\grepWin-1.6.15-x64.msi'
install_dir = '%ProgramFiles64Dir%\grepWin\'
check_processes_from_dirs = ['%ProgramFiles64Dir%\grepWin\']
processes = []

[installers.requirement]
os_arch = 'x64'
os = 'windows'
required_space_MB = 4
Metadaten-Datei (Beispiel Background Installation - Beispiel 2)

Zwei Windows Setupdateien - 32 / 64

[specification]
version='0.1'

[product]
product_icon_file_path = 'dummy.png'

[[installers]]
name = '7Zip-win32'
path = 'files1/7Zip-32-setup.exe'       # necessary
install_dir = '%ProgramFiles32Dir%\7-Zip'
check_processes_from_dirs = ['%ProgramFiles32Dir%\7-Zip']
processes = ['7z.exe','%ProgramFiles32Dir%/7-Zip/7zFM.exe']

[[installers.requirement]]
os = 'windows'
os_arch = 'x86'

[[installers]]
name = '7Zip-win64'
path = 'files2/7Zip-64-setup.exe'       # necessary
install_dir = '%ProgramFiles64Dir%\7-Zip'
check_processes_from_dirs = ['%ProgramFiles64Dir%\7-Zip']
processes = ['7z.exe','%ProgramFiles64Dir%\7-Zip\7zFM.exe']

[[installers.requirement]]
os = 'windows'
os_arch = 'x64'

Erstellen von Produkten mit Background Metadaten

Der opsi-setup-detector ab Version 4.3.6.x unterstützt die Erstellung der für die Backgroundinstallation nötigen Metadaten. Bis zur offiziellen Freigabe dieser neuen Erweiterung, sind die entsprechenden Funktionalitäten des opsi-setup-detectors per Default ausgeschaltet und müssen zunächst über die Konfiguration aktiviert werden. Dies geschieht über die Aktivierung des Konfigs:

EnableBackgroundMetaData :
Aktiviert die Backgroundinstall Unterstützung: Zeigt den Background Info Datei Button auf dem Start Tab. Macht den Produkt Konfiguration 3 Tab sichtbar und verwendbar. Schreibt eine opsi-meta-data.toml Datei bei der Produkterzeugung.

Nach dem Setzen des Häkchens und beenden des Konfigurationsdialogs, müssen Sie den opsi-setup-detector neu starten oder die Sprache ändern um die Oberfläche neu zu laden.

Nach erfolgreicher Aktivierung der Backgroundinstall Unterstützung werden Sie nach der Produkt Konfiguration 2 zur Produkt Konfiguration 3 weitergeleitet, welche die zu speichernden Metadaten anzeigt.

Produkt-Background Info
Abbildung 2. opsi-setup-detector: Produkt-Background Info

  • Um Metadaten für eine Setup- / Installerdatei zu erzeugen, muß das Häckchen bei Installer 1 Aktiv gesetzt sein.

  • Das Feld InstallDir verweist auf das Verzeichnis in dem sich diese Software installieren wird. Wenn es noch nicht korrekt gefüllt ist, kann das hier eingegeben werden oder über den Auswahlbutton neben dem Eingabefeld ausgewählt werden.
    Über den Button Pfeil nach unten kann das InstallDir in die Liste der zu prüfenden Verzeichnisse kopiert werden.

  • Das Feld Liste der zu prüfenden Verzeichnisse ist eine Liste welche pro Zeile ein Verzeichnis enthält, das eine Quelle kritischer Prozesse sein kann. Üblicherweise steht hier nur das Installdir.

  • Das Feld Liste der zu prüfenden Prozesse ist eine Liste welche pro Zeile einen Prozeßnamen enthält (mit oder ohne Pfad), der ein kritischer Prozesse sein kann. Üblicherweise steht hier nichts.

  • Sind beide Listen leer, so wird auf keine laufenden Prozesse geprüft und die Software direkt installiert.

  • Gibt es ein Häckchen bei install_in_background, so bedeutet dies, das dieses Produkt in einer Background Install Situation eingespielt werden darf. Wird da Häkchen entfernt, so darf das Produkt nicht in einer Background Install Situation eingespielt werden. Gründe hierfür könnten benötigte Reboots oder andere nicht behandelbare Seiteneffekte sein.

  • Das Betriebssystems (OS) sollte immer auf windows stehen. Für andere Betriebsysteme wird die Erweiterung opsi-background-install nicht aktiv.

  • Die Angabe OS Architektur gibt die Architektur des benötigten Betriebssystems an.
    Erlaubt sind hier x86, x64, arm64, arch_unknown. Auf einem x64 Windows Betriebssystem ist auch die Anforderung x86 erfüllt. Auf einem x86 Windows Betriebssystem ist die Anforderung x64 nicht erfüllt. Die Anforderung arch_unknown ist immer erfüllt.

Ist alles korrekt ausgefüllt, so verlassen Sie über den Button Nächster Schritt die Maske. Beim Erstellen des opsi-Produktes über den Button opsi Paket erstellen wird die Metadaten Datei automatisch mit erzeugt.

Altprodukte mit Background Metadaten versorgen

Der opsi-setup-detector ab Version 4.3.6.x bietet die Möglichkeit einfach vorhandene Produkte mit den benötigten Metadaten zu versorgen. Dazu muß im Konfigurationsfenster ein Häkchen bei EnableBackgroundMetaData (siehe oben) gesetzt werden. Dann wird auf der Startseite, ganz unten der Button Erzeuge Background Info Datei sichtbar. Dieser dient dazu, bestehende opsi-Produkte nachträglich mit der Metadatendatei zu versorgen.

Startseite mit Button Produkt-Background Info
Abbildung 3. opsi-setup-detector: Startseite mit Button Produkt-Background Info

Wird der Button Erzeuge Background Info Datei gedrückt, so wird zunächst versucht Daten über das bestehende Produkt zu ermitteln. Dafür wird nach einer opsi-setup-detector Prokektdatei (*.osd) gefragt. Sie können den Dialog abbrechen wenn eine solche Datei nicht vorhanden ist. In diesem Fall wird nach einer bestehenden control Datei (control, control.toml) gefragt. Sie können den Dialog abbrechen wenn eine solche Datei nicht verwenden wollen oder sie nicht vorhanden ist.

Danach wird die Maske Produkt Konfiguration 3 angezeigt.

Produkt-Background Info
Abbildung 4. opsi-setup-detector: Produkt Konfiguration 3

Die Maske wird genauso ausgefüllt, wie das im Vorangehenden Kapitel beschrieben ist.

Ist alles korrekt ausgefüllt, so wählen Sie über den Button Datei Speichern das CLIENT_DATA Verzeichnis des opsi-Produktes und speichern dort die Datei opsi-meta-data.toml.
In diesem Fall wird auch die Packagenummer des Produktes um eins erhöht und ein Eintrag in die changelog.md gemacht.
Danach muß das Produkt neu gebaut werden (opsi-make-pakackage) und installiert werden.
Nun stehen die Metadaten des Produktes opsi zur Verfügung.

Best Practice: Tips zum Umgang / Konfiguration mit Background_install

Konfigurations Tips für die Clients

Eventkonfiguration für die Clients
Wenn für einen Client Background_install angeschaltet ist, so gilt das Grundsätzlich für alle Events wenn dabei Benutzer eingeloggt sind.
Hier werden zwei Möglichkeiten vorgestellt mit welchen Events bei beim Backgound_install gearbeitet werden kann:

Verwendung des vorhandenen Events opsiclientd.event_gui_startup
Hierzu müssen die folgenden Änderungen an der Standarkonfiguration des Events vorgenommen werden:

  • Loginblocker ausschalten:
    opsiclientd.event_gui_startup.block_login=false

  • Abarbeitung der Aktionen erst 30 Minuten nach Start des Events:
    opsiclientd.event_gui_startup.activation_delay = 1200

Vorteil: Produkte werden nach jedem Start installiert.
Nachteil: Nicht geeignet für Roaming Profiles da hier das Loginevent durch das event_gui_startup blockiert wird.

Die Alternative:
Erstellung des neuen Timer gesteuerten Events opsiclientd.event_background_install
Dieses Event startet gesteuert durch einen Timer. In der hier vorgeschlagenen Konfiguration 30 Minuten (1200 Sekunden) nach dem Start des Rechners.

Dieses neue Event wird über folgende Eintragungen in der opsiclientd.conf erzeugt.

[event_background_install]
super = default
type = custom

[event_timer_backgroundinstall]
super = background_install
type = timer
active = false
interval = 604800
start_interval = 1200

[event_timer_backgroundinstall{user_logged_in}]
shutdown_user_cancelable = 5
shutdown_user_selectable_time = true
shutdown_warning_time = 3600

Zur Erstellung dieser Einträge müssen Sie folgende Kommandozeilenbefehle auf dem Server ausführen:

opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_background_install.super "bg_install_super" "default" "default"
opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_background_install.type "bg_install_type" "custom" "custom"
opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_timer_backgroundinstall{user_logged_in}.shutdown_user_cancelable "bg_install_shutdown_user_cancelable" "5" "5"
opsi-cli jsonrpc execute config_createBool opsiclientd.event_timer_backgroundinstall{user_logged_in}.shutdown_user_selectable_time "bg_install_shutdown_user_cancelable" true
opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_timer_backgroundinstall{user_logged_in}.shutdown_warning_time "bg_install_shutdown_warning_time" "3600" "3600"
opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_timer_backgroundinstall.super "bg_install_timer_super" "background_install" "background_install"
opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_timer_backgroundinstall.type "bg_install_timer_type" "timer" "timer"
opsi-cli jsonrpc execute config_createBool opsiclientd.event_timer_backgroundinstall.active "bg_install_active" false
opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_timer_backgroundinstall.interval "bg_install_timer_interval" "604800" "604800"
opsi-cli jsonrpc execute config_createUnicode opsiclientd.event_timer_backgroundinstall.start_interval "bg_install_timer_start_interval" "1200" "1200"

Zur Aktivierung des neuen Events muss in den Hostparametern der betroffenen Clients gesetzt werden: opsiclientd.event_timer_backgroundinstall.active=true

Vorteil: Geignet für Roaming Profiles.
Nachteil: Neues Event muß konfiguriert werden.

Shutdown Notifier sinnvoll konfigurieren
Gerade bei Events welche bei eingeloggtem Benutzer aktiv sind, ist es von großer Wichtigkeit die shutdown notifier gut zu konfigurieren.
Für das Event welches für die Backgroundinstallation verwendet wird, empfehlen wir:

  • shutdown_user_cancelable = 5

  • shutdown_user_selectable_time = true

  • shutdown_warning_time = 3600

Events für die Installation ohne User
Da beim Background_install Produkte ohne Metadaten oder mit entsprechender Konfiguration nicht ausgeführt werden, ist es auf jeden Fall sinnvoll auch Events zu haben welche auch ohne eingeloggten Benutzer ausgeführt werden:
Die kann zum Beispiel in die Installation bei shutdown sein:
opsiclientd.event_on_shutdown.active=true

Konfiguration von opsi Standard Produkten

Die von uib bereitgestellten Standardprodukte und Abo / Abo+ Produkte werden mit Beginn der Pilotphase sukzessive auf die Nutzung mit der Backgroundinstallation angepasst.

Zugelassene aber zu konfigurierende Standardprodukte

Die folgenden Produkte sind für die Backgroundinstallation zugelassen, sollten aber in den Properties angepasst werden:

  • opsi-client-agent
    Property: allow_reboot=false setzen

  • mshotfix
    Property: noreboot=on setzen

Zugelassene Standardprodukte

Die folgenden Produkte sind für die Backgroundinstallation zugelassen:

  • Alle opsi Standardprodukte (mit wenigen Ausnahmen siehe unten)

  • Alle Produkte aus dem "Update Abo Standardprodukte" welche seit dem 1.7.2025 aktualisiert wurden.

  • Aus dem "Update Abo MS-Hotfixes" das Produkt mshotfix.

  • Alle Produkte aus dem "Abo+" Angebot welche seit dem 1.8.2025 aktualisiert wurden.

(Noch) nicht zugelassene Standardprodukte

Die folgenden Produkte sind mit Stand 15.7.2025 noch nicht für die Backgroundinstallation zugelassen:

  • jedit

  • microsoft-windows-policies

  • opsi-cli

  • opsi-client-kiosk

  • opsi-winpe

  • opsipackagebuilder_wlm

  • windows1*-enablement

  • windows1*-upgrade

Tips zur Entscheidung wie ein Produkt zugelassen / konfiguriert werden sollte

Reboots vermeiden
Wesentlich ist, dass im Rahmen der Backgroundinstallation Reboots möglichst vermieden werden sollten. D.h. konkret:

  • Produkte welche immer und unabweisbar ein oder mehr Reboots benötigen, sollten nicht für die Backgroundinstallation zugelassen werden. Das bedeutet konkret: Hier sollte in der Metadaten Datei install_in_background=false gesetzt werden.

  • Produkte welche nicht unbedingt einen sofortigen Reboot brauchen, sollten dies per Property (z.B. allow_reboot) steuerbar machen, so das die Reboots für Clients welche Backgrounsinstall machen sollen, dies ausgeschaltet werden kann.