Aus Legacy-Gründen führen wir keinen PXE-Boot direkt von SCCM aus, sondern verfügen über einen separaten WDS-Server, von dem wir einen PXE-Boot durchführen und auf den wir (unter anderem, ebenfalls aus Legacy-Gründen) das Boot-WIM von SCCM hochladen.
Zurück in SCCM ist jedoch der Ort, an dem dierealQuirk lügt. Also, jeder gegebenen Tasksequenz ist ein Boot-Image zugewiesen. Also ist meiner Tasksequenz Betadasselbe Boot-WIM zugewiesen, das auf den WDS-Server hochgeladen wurde, keine große Sache. Ich boote zu PXE, wähle Betaaus der Liste der verfügbaren Tasksequenzen aus und bin auf dem Weg.
Anschließend stellt SCCM sicher, dass alle von der Aufgabensequenz referenzierten Pakete an einem Verteilungspunkt verfügbar sind. Dazu gehören auch Boot-WIMs.
Mein Problem kommt direkt danach. Wenn die PackageID des Boot-WIMs, auf das in der Tasksequenz verwiesen wird,stimmt nicht übereindie PackageID des Boot-WIM, das gerade ausgeführt wird (oder wenn die Tasksequenz innerhalb eines vollständigen Windows-Betriebssystems ausgeführt wird), dann wird sccmBühne(Download lesen und irgendwo speichern) Das in der Aufgabensequenz referenzierte Boot-WIM fordert den Benutzer auf, „die CD zu entfernen“ und den Computer neu zu starten, und bootet dann bis zu diesem Boot-WIM.
Ich weiß, was Sie jetzt denken:„Mike, verwenden Sie einfach dasselbe Boot-WIM, auf das in der Aufgabensequenz auf Ihrem WDS-Server verwiesen wird, dann ist alles in Ordnung.“
Ich würde Ihre Zeit nicht damit verschwenden, das nicht zu tun. Das Problem ist, dass die PackageID auf dem WDS-Boot-WIM nicht die richtige PackageID anzeigt.
Correct PackageID: SMS000D8
Perceived PackageID: SMS0009E
Hier ist ein Ausschnitt des Protokolls für visuelle Lerner:
Nun erkannte ich die wahrgenommene Paket-ID: Es war das ursprüngliche SCCM-Boot-WIM, das nach dem Upgrade auf SP1 erstellt wurde. Natürlich, wenn ich zuweiseDasBooten Sie WIM in meiner Tasksequenz, alles läuft weiter und es erfolgt kein Neustart.
Es gibt jedoch einen guten Grund, warum dieser Boot-WIM nicht zugewiesen ist Beta. Jedes Mal, wenn wir versuchen, diesen Boot-WIM zu aktualisieren, schlägt dies fehl. Egal, ob es sich um Treiber, zusätzliche Funktionen oder gar nichts als ein DP-Update handelt, es schlägt fehl, wenn die OSD-Binärdateien eingefügt werden. Dies geschieht anscheinend auch vonvon Zeit zu Zeit. Das Importieren und Aktualisieren neuer Boot-WIMs scheint problemlos zu funktionieren, also haben wir versucht, einfach diesen Weg zu gehen, und da sind wir jetzt.
Betaerfordert einen Neustart mitten in der Aufgabensequenz, und wenn wir in das ursprüngliche Boot-WIM-System neu starten, sind die Netzwerk- und/oder Speichertreiber für unsere neuesten Computermodelle nicht darin enthalten und es passieren schlimme Dinge.
Also habe ich weiter gegoogelt, dennsicherlichIch bin nicht der einzige, der dieses Problem hat, und es stellt sich herausIch war nicht.
Nun, ja: Man könnte den Wert der BootMediaPackageIDTasksequenzvariable nach Bedarf innerhalb der Tasksequenz ändern (sogarVordie Tasksequenz beginnt mit vor der Ausführung ausgeführten Medien-Hooks) und sei fröhlich. Allerdings ist die Tasksequenzvariable BootMediaPackageIDwirklich _SMSTSBootMediaPackageIDundDasVariablen und ähnliche Variablen sind schreibgeschützt.
Die gute Nachricht ist, dass alle Tasksequenzvariablen auf dem Boot-WIM in einer Datei namens gespeichert sind variables.dat, soweit ich im Internet gelesen habe. Die schlechte Nachricht ist, dass diese Datei kein Klartext ist.
Es gibt ein Tool namens tsenv21e, mit dem man diese Datei über die Speicherzuordnung bearbeiten kann. Auf der Website steht jedoch, dass es für 2007 ist, und als ich versuchte, es zu verwenden, erhielt ich nur einen zufälligen Fehler, von dem Google nichts gehört hat. Ich habe heute später eine Telefonkonferenz mit diesen Leuten, aber ich setze nicht alles auf eine Karte.
Ein weiterer Forumsbeitragerwähnte, dass diese Datei mit dem Medienkennwort verschlüsselt ist, das für den Zugriff auf die Tasksequenzen verwendet wird, falls es eines gibt. Wenn nicht, ist es reines XML. Wir verwenden ein Medienkennwort, also schien das vielversprechend. Der Verfasser war auch so freundlich zu erwähnen, dass es mit AES-256-CBC verschlüsselt ist, was auch vielversprechend klang, also lud ich OpenSSL für Windows herunter und probierte die Datei aus, ohne Erfolg. Im Gespräch mit unserem Senior Security Admin scheint es, dass es bei CBC nicht ausreicht, die Datei zu entschlüsseln, wenn ich nicht den Schlüssel und IV, sondern nur das Kennwort habe. Ich bezweifle, dass MS diese Dinger rausrückt.
So, das ist mein Standpunkt. Wenn jemand weiß, wie man das umgehen kann, bin ich ganz Ohr.
Antwort1
Für diejenigen, die (8 Jahre später) immer noch darüber stolpern: Sie können Ihre variables.dat-Datei neu generieren, indem Sie mit SCCM „Task Sequence Media erstellen“ aufrufen, Optionen für ein ISO-Image mit „bootfähigem Medium“ auswählen und darauf achten, das gewünschte Boot-Image auszuwählen. Sobald das ISO-Image generiert ist, mounten Sie es und extrahieren die variables.dat-Datei daraus.