Autounattend.xml - seltsames Verhalten, wenn die Befehlszeile lang ist

Question

Kürzlich stieß ich auf dasselbe Problem und – wie Sie vermutet haben – stellte ich fest, dass die Grenze 259 Zeichen beträgt. Ich denke jedoch, dass – wenn Prozentvariablen in die Befehlszeile aufgenommen werden – die Variablenerweiterung die effektive Grenze verändern kann. Leider ergaben meine Tests diesbezüglich keine eindeutigen Schlussfolgerungen.

Der folgende einfache Test demonstriert die Beschränkung auf 259 Zeichen:

<SynchronousCommand wcm:action="add">
    <Order>1</Order>
    <RequiresUserInput>false</RequiresUserInput>
    <CommandLine>cmd /c ECHO This line will eventually be 259 characters long. This line will eventually be 259 characters long. This line will eventually be 259 characters long. This line will eventually be 259 characters long. This line will even > "C:\Windows\Temp\259.log"</CommandLine>
    <Description>259 characters, should produce file</Description>
</SynchronousCommand>
<SynchronousCommand wcm:action="add">
    <Order>2</Order>
    <RequiresUserInput>false</RequiresUserInput>
    <CommandLine>cmd /c ECHO This line will eventually be 260 characters long. This line will eventually be 260 characters long. This line will eventually be 260 characters long. This line will eventually be 260 characters long. This line will event > "C:\Windows\Temp\260.log"</CommandLine>
    <Description>260 characters, should NOT produce file</Description>
</SynchronousCommand>

Kurz gesagt: Die <CommandLine>Zeile mit 259 Zeichen, die versucht, eine Datei mit dem Namen zu schreiben, 259.logwird erfolgreich geschrieben, während die <CommandLine>Zeile mit 260 Zeichen, die versucht, eine Datei mit dem Namen zu schreiben, 260.lognicht erfolgreich geschrieben wird.

Als ich das erste Mal auf dieses Problem stieß, nahm ich einige Änderungen an den Befehlszeilen verschiedener Befehlsaufrufe nach der Windows-Installation vor. Konkret bestanden meine Änderungen darin, die Pfade zu den .exeDateien vollständig zu qualifizieren und in einigen Fällen Umgebungsvariablen zu verwenden, z. B. "%ComSpec%"statt cmd. Aber durch die Erhöhung der Zeichenanzahl machte ich unabsichtlich Dinge kaputt!

Das Rätselhafte war, dass <CommandLine>Zeilen mit einer Länge von weniger als 260 Zeichen immer noch nicht das bewirkten, was sie sollten. Ich wusste, dass die Befehle richtig waren, denn ohne die vollständige Qualifizierung der .exeDateien funktionierten sie. Hier ist eine Beispielzeile <CommandLine>mit 253 Zeichen, die fehlschlägt:

<SynchronousCommand wcm:action="add">
    <Order>3</Order>
    <RequiresUserInput>false</RequiresUserInput>
    <CommandLine>"%ComSpec%" /c FOR %I IN ("%InstallDrive%:\cfs-extras\installers\LibreOffice_*.msi") DO IF NOT DEFINED L "%WinDir%\System32\msiexec.exe" /i "%~fI" /l* "%TMP%\L.log" /qn ALLUSERS=1 CREATEDESKTOPLINK=1 QUICKSTART=1 ADDLOCAL=ALL UI_LANGS=en_GB ^&^& SET L=t</CommandLine>
    <Description>Silently install LibreOffice</Description>
</SynchronousCommand>

Wenn ich die Variablen jedoch manuell erweitere, überschreitet mein Befehl die Beschränkung auf 259 Zeichen! Dies könnte darauf hindeuten, dass vor der Ausführung des Befehls eine Vorerweiterung der Variablen erfolgt.

Eine weitere Beobachtung: Ich habe versucht zu laufenProcmon, Filtern nach z. B. Prozessname = cmd.exeund ich habe festgestellt, dass die cmd.exefehlgeschlagenen Befehle nie in der Procmon-Ausgabe erschienen.

Wie Sie festgestellt haben, habe ich auch festgestellt, dass C:\Windows\Panther\UnattendedGC\setupact.logBerichte angezeigt werden, dass der Befehl erfolgreich ausgeführt wurde, unabhängig davon, ob dies der Fall war.

Nachdem ich Ihren Kommentar zum Ausführen von einem USB-Stick gelesen habe, klingt es, als ob Sie etwas ganz Ähnliches tun wie ich. Was mir geholfen hat, war, eine Umgebungsvariable für den USB-Laufwerksbuchstaben festzulegen. Hoffentlich können Sie dann als Benutzer Skripte aufrufen, anstatt lange Befehlszeilenyagmoth555♦kommentiert. Dies habe ich im Abschnitt eingerichtet <settings pass="specialize">:

<component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
    xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <RunSynchronous>
        <RunSynchronousCommand wcm:action="add">
            <Order>1</Order>
            <Description>Set InstallDrive environment variable</Description>
            <Path>"%ComSpec%" /c FOR %i IN (C D E F G H I J K L N M O P Q R S T U V W X Y Z) DO IF NOT DEFINED InstallDrive IF EXIST %i:\cfs-extras "%SystemRoot%\System32\setx.exe" InstallDrive %i /M</Path>
        </RunSynchronousCommand>
    </RunSynchronous>
</component>

Dabei wird einfach jedes Laufwerk auf ein Verzeichnis überprüft, von dem bekannt ist, dass es auf dem USB-Stick vorhanden ist. Wenn es vorhanden ist, wird eine InstallDriveUmgebungsvariable auf den Laufwerksbuchstaben des Laufwerks mit diesem Verzeichnis gesetzt. Sie können dann %InstallDrive%später in <settings pass="oobeSystem">Befehlen/Skripten darauf verweisen. Am Ende dieses Abschnitts entferne ich die Umgebungsvariable mit:

<SynchronousCommand wcm:action="add">
    <Order>7</Order>
    <RequiresUserInput>false</RequiresUserInput>
    <CommandLine>"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -command [Environment]::SetEnvironmentVariable('InstallDrive',$null,'Machine')</CommandLine>
    <Description>Remove InstallDrive machine environment variable. Always run this last.</Description>
</SynchronousCommand>

...nur um alles sauber und ordentlich zu halten.

Ich weiß, dass es vier Jahre her ist, seit Sie Ihre Frage gestellt haben, aber ich hoffe, dass diese Antwort für Sie und möglicherweise andere, die möglicherweise mit demselben Problem konfrontiert waren, immer noch von Relevanz ist.

Answer 1