Beim Aufbau einer enteo Umgebung ist das Reboot Management nicht selten heiß diskutiertes Thema und viele der Anforderungen des IT-Environment sind mit den enteo Standard Mitteln schlichtweg nicht umsetzbar.

Beispiele für solche Anforderungen könnten wie folgt lauten:

• Während der Re-Installation eines Systems soll der Reboot immer automatisch erfolgen.

• Ist kein Benutzer angemeldet, soll der Reboot im Falle einer Workstation augenblicklich erfolgen.

• Ist ein Benutzer angemeldet, soll der User gefragt werden ob ein Reboot durchgeführt werden darf. Diese Frage darf er x-mal verzögern.

• Auf einem Server darf ein Reboot nicht automatisiert erfolgen, der zuständige Administrator soll aber eine Benachrichtigung erhalten.

In Projekten, in denen mehrere Personen oder Abteilungen am Aufbau eines Enteo Softwareverteilungs-System beteiligt sind, steht der Verantwortliche oft vor der Herausforderung, den Kommunikationsfluss zwischen den Verantwortlichen zu steuern. Sehr schnell werden hier verschiedene Systeme aufgebaut, die dieses Problem mehr oder weniger lösen sollen. Oft werden dieses Möglichkeiten aber nicht von allen im Projekt beteiligten Personen wahrgenommen, wofür es auch allzu häufig sehr triftige Gründe gibt:

Möchte man eine Testumgebung „für den persönlichen“ Gebrauch aufsetzen, in der keine „Vorab-Tests“ von Patchen durchgeführt werden und keine Pilotuser/Computer versorgt werden, kann der folgende Trick genutzt werden, um sowohl Speicherplatz zu sparen, als auch die Distribution deutlich zu optimieren.

Immer wieder werde ich grade von Neukunden gefragt, welches Enteo Konto, welche Berechtigungen benötigt und wie dieses Berechtigungen verteilt und von den Infrastrukturdiensten angewendet werden. Also nun folgendes dazu: