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.

Wir haben dann versucht, dem Problem auf den Grund zu gehen, und haben dazu die Registry-Werte "EnableDynamicFilesEncryption" (auf "0") und "DebugKeepDynamicFiles" (auf "1") im Schlüssel "HKLM\Software\Netsupport\OSD\OSDProxy" auf dem OSD Proxy gesetzt. Ergebnis war, dass in diesem Fall die Datei erfolgreich und mit richtigem Inhalt übertragen wurde. Weitere Tests ergaben dann, dass es sich darauf zurückführen lässt, ob die dynamischen Dateien verschlüsselt auf den Client übertragen werden (ob also die "DynamicFilesEncryption" aktiviert ist oder nicht). Ist sie aktiviert, funktionierte es nicht, war sie deaktiviert klappte alles wie erwartet. Da wir dieses Sicherheitsfeature aber gerne nutzen wollten, haben wir noch weiter geforscht.

Ich habe dann mal kurz FrontRange kontaktiert und dabei erhielt ich den entscheidenden Tipp: im Mail des dortigen Kollegen war der Halbsatz "...könnte sein, dass wir bei der Entschlüsselung "großer" Dateien ein Problem haben...". Auffällig war, dass alle dynamischen Files relativ klein waren, während das VBScript die exorbitante Größe von 37 KB besaß. Ich bin dann mal hingegangen und habe Kommentare und Ähnliches rausgeschmissen, sodass das File auf 29 KB geschrumpft wurde - und siehe da, die Datei wurde korrekt auf unseren Testclient übertragen. Mit etwas weiterem Testen hat sich rausgestellt, dass tatsächlich 32 KB die magische Grenze ist. Sind dynamische Dateien größer als 32 KB und ist die verschlüsselte Übertragung dynamischer Dateien aktiviert, schlägt das Entschlüsseln auf dem Client fehl und das File landet mit einer Größe von 0 KB auf dem Endgerät.

Der Fehler wurde dann übrigens vom Entwickler bei FrontRange besätigt (Ursache ist ein hart-codierter Buffer für das Entschlüsseln von 64 KB Größe).

Achtet also darauf, dass Scripts oder andere dynamische Dateien auf jeden Fall unter 32 KB groß sind, sonst schlägt eine Installation, die diese Files benötigt, fehl.

Dieses Problem tritt auf jeden Fall in Umgebungen bis Enteo v6.2 SP2 Hotfix-Bundle 2 auf (also bis einschließlich Build 3257). Ich habe FrontRange darüber informiert, kann aber natürlich nicht sagen, ob das Problem in einem der nächsten Builds schon behoben sein wird. Daher besser darauf achten, dass dynamische Dateien die "magische" Grenze von 32 KB nicht überschreiten.