Ein in der Enteo/DSM-Welt immer wieder kontrovers disktuiertes Thema ist, ob im Anschluss an eine Betriebssystem-Installation über OSD ein sogenannter "AutoAdminLogon" durchgeführt werden soll oder nicht.

Unter NetInstall 5.x und OSD 3.x wurde standardmäßig ein solche automatische Anmeldung vorgenommen und über einen RunOnce-Eintrag sowohl der NetInstall-Client installiert als auch der NetInstall Agent und damit implizit der AutoInstaller gestartet.

Wird Enteo v6 bzw. DSM 7 und damit auch OSD in der entsprechenden Version eingesetzt, so findet standardmäßig keine automatische Anmeldung mehr statt. Stattdessen steht nach der Betriebssystem-Installation der zu installierende Rechner im Login-Bildschirm während im Hintergrund zunächst über ein Post OS Action Package der NetInstall-Client installiert wird und anschließend der Service-Installer die Applikationspakete installiert (aus diesem Grund ist auch die Standard-Ausführungseinstellung für Pakete auf "Egal, ob ein Benutzer angemeldet ist, oder nicht" gesetzt).

In Enteo v6 wurde das Konzept von Paket-Revisionen eingeführt, womit es möglich wurde, verschiedene Versionen eines Pakets vorzuhalten, zu verteilen und zu installieren.

Die verschiedenen Revisionen eines Pakets wurden (und werden auch noch in DSM 7) in Unterverzeichnissen des Paketverzeichnisses namens "REV\" abgelegt. Für Revisionen größer 1 wurden dabei in den jeweiligen REV-Unterverzeichnissen nur die gegenüber den Vorgänger-Revisionen geänderten Dateien gespeichert.

Dieser Ansatz führte in Enteo v6 dazu, dass ein Client sich in seinem lokalen Repository-Cache ein "vollständiges Paketverzeichnis zusammenbauen musste" (wofür die Informationen in der File-Package-Index-Datei package.fpi ausgewertet wurden), bevor das Paket installiert werden konnte.

Da aber das aus NetInstall 5.x bekannte Konzept der Ausführung direkt aus dem NetInstall-Share durchaus in vielen Umgebungen ein adäquater und stabil funktionierender Ansatz war, wurde in DSM 7 eine Möglichkeit geschaffen, für jede Paket-Revision ein vollständiges Paketverzeichnis bereitzustellen. Damit kann – wenn gewünscht – auf das Staging von Paketen im lokalen Repository-Cache verzichtet werden, da auf dem Server alle Dateien in der erwarteten Verzeichnisstruktur vorhanden sind (zur Deaktivierung des Stagings siehe unten).

Unter Windows XP bzw. Windows Server 2003 und früheren Windows-Versionen war es problemlos möglich, durch Dienste ein Meldungsfenster auf dem Desktop darstellen zu lassen. Dies wurde - gerade auch in NetIntall-Umgebungen - auch durchaus regelmäßig angewendet, beispielsweise wenn durch den Service-Installer eine Installation ausgeführt wurde, die einen Neustart erforderte. Dann konnte man durch die NetInstall-Scriptbefehle "MessageBox" oder "MessageBoxEx" eine Meldung anzeigen lassen, und den Benutzer auf den bevorstehenden Neustart aufmerksam machen oder ihn fragen, ob der Neustart jetzt direkt ausgeführt werden sollte.

Seit Windows Vista können Dienste jedoch keine Meldungsfenster mehr anzeigen - die Ursache hierfür liegt in der sogenannten "Session 0 Isolation", auf die an dieser Stelle nicht näher eingangen werden soll. Sehr interessante Hintergrundinformationen dazu findet man beispielsweise unter http://windowsteamblog.com/windows/b/developers/archive/2009/10/01/session-0-isolation.aspx. Auf jeden Fall führt diese Session 0 Isolation dazu, dass das oben beschriebene Szenario mit dem Meldungsfenster, das fragt, ob ein Reboot ausgeführt werden darf, unter Windows Vista, Windows Server 2008 und höher nicht mehr funktioniert

Um nun diesem Problem zu begegnen, hat die NWC Services eine neue Version des Tools MSGBOXT entwickelt.

Kürzlich bin ich bei einem Kunden über einen Bug in OSD v6 gestolpert, der mich einen ganzen Tag Troubleshooting gekostet hat. Um anderen diese Erfahrung zu ersparen, dachte ich mir, es wäre ganz sinnvoll dieses Verhalten hier kurz zu dokumentieren.

In Zusammenhang mit einer Migration von NetInstall 5.x mit OSD 3.x auf Enteo v6 und OSD v6, wollte ich zunächst OSD migrieren. Der Plan war, den zu installierenden Clients zunächst per OSD v6 das Betriebssystem zu verpassen und dann den NetInstall 5.x Client zu installieren, um die "normalen" Software-Pakete auszubringen. Dazu habe ich das OS Configuration Package von OSD v6 so umgebaut, dass dort nicht der OSD Start-Service eingerichtet wird (der anschließend das Post OS Action Package ausführt), sondern habe auf einen AutoAdminLogon umgestellt und wollte dann das aus OSD 3.x bekannte Script OSDSTART.VBS über einen RunOnce-Eintrag ausführen lassen. Ganz so eben, wie man es aus der OSD 3.x-Welt kennt.

Beim Übertragen der dem OS Configuration Package zugeordneten Dateien auf den Client, trat dann das Phänomen auf, dass die OSDSTART.VBS auf dem Client immer mit 0 KB Größe (also leer) ankam. Alle anderen Dateien wurden wie erwartet übertragen.

Notepad++ ist zweifelsohne ein genialer Text-Editor und Notepad-Ersatz. Trotzdem habe ich jahrelang UltraEdit verwendet: erstens, weil zu der Zeit, als ich mir UltraEdit angeschafft habe, Notepad++ noch nicht soweit war (oder ich es nicht wusste) und zweitens - und das ist der eigentliche Grund dieses Blog-Eintrags - weil ich relativ oft den Spalten- oder Block-Modus verwende. Hier bin ich bis vor kurzem davon ausgegangen, dass Notepad++ sowas garnicht beherrscht, auch weil es keinen entsprechenden Menüpunkt gibt, um in diesen Modus zu schalten (in UltraEdit gibt ein entsprechendes Menü).

In Windows 7 und Server 2008 R2 besteht die Möglichkeit, Sprachpakete - sogenannte Language Packs - in die Installationsquelldateien zu integrieren (bzw. bestand diese Möglichkeit auch bereits bei Vista und Windows Server 2008). Dies erlaubt die Nutzung einer einheitlichen Quellverzeichnis-Struktur für die Installation von Windows in sämtlichen benötigten Sprachen, was gerade für international agierende Konzerne, sehr vorteilhaft sein kann. Bei diesem Ansatz müssen Änderungen an den Quellen - wie die Integration neuer Treiber oder die Vorab-Installation von Patches und Hotfixes - nur einmalig an zentraler Stelle durchgeführt werden. Die geänderten Installations-Sourcen können dann im Netzwerk repliziert werden und stehen an allen Standorten konsistent zur Verfügung.