FOG 1.5.6: Windows unattended.xml is intermittently failing to work



  • @george1421 @Sebastian-Roth First, want to thank both of you for helping me with these issues. You’ve both been great. Despite this moving away from FOG issues to more of a Windows issue.

    Anyway, as per @george1421 's recommendation, here’s setuperr.log. As expected from Microsoft, it’s rather cryptic and doesn’t really tell me what’s gone wrong.

    setuperr.log:

    2019-07-02 09:49:33, Error                        [setup.exe] [Action Queue] : Unattend action failed with exit code 4
    2019-07-02 09:49:33, Error                        [setup.exe] Execution of unattend GCs failed; hr = 0x0; pResults->hrResult = 0x8030000b
    


  • @george1421 Thanks for the info.

    However… Sysprep verifies the answer file at sysprep invocation. This is typically when a ‘problem’ will show up. This is partly why this problem is so frustrating.

    Additionally, this is the SAME exact answer file I use for six different Windows images. It works flawlessly on all 4 legacy images (for BIOS/Legacy/CSM targets.) It’s only the 2 UEFI images (Pro and Home) that have issues, and even then, only sometimes. Sometimes it works great. Sometimes it pukes during that first boot. It makes no sense.

    Lastly, my answer file is simplicity itself, the only thing in it is the directive to copy admin profile to the newly created user during setup. That’s it, there’s nothing else in there.

    Here it is, if you don’t believe me!

    <?xml version="1.0" encoding="utf-8"?>
    <unattend xmlns="urn:schemas-microsoft-com:unattend">
        <settings pass="specialize">
            <component name="Microsoft-Windows-Shell-Setup" 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">
                <CopyProfile>true</CopyProfile>
            </component>
        </settings>
        <cpi:offlineImage cpi:source="wim:c:/users/administrator/desktop/install.wim#Windows 10 Home" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
    </unattend>
    

    I will however study the log files for an affected machine, because you’re right, there may be a clue there.

    @Sebastian-Roth Here’s the requested picture:

    Just an FYI, in order to fetch that picture, we deployed the UEFI image to 8 identical computers. 4 failed, 3 succeeded, 1 was still working it when i got picture.


  • Moderator

    @Cheetah2003 said in FOG 1.5.6: Deploy is leaving remnants of previous data:

    And it doesn’t do it every time, only like… 70% of the time, and only on UEFI deployments.

    First let me say that 1903 is a very different beast than 1809. While it has the Windows 10 name, its as different as Win7 was to XP.

    With that said, when the system errors out. It should tell you a bit more than sysprep is damaged. There are log files in c:\windows\panther (where you unattend.xml file should be) that might give you a better clue to what it doesn’t like. You might be able to inspect these or at least copy them to a flash drive to look at them off-line with the Shift-F10 method to call up a command window and notepad.



  • @Sebastian-Roth said in FOG 1.5.6: Deploy is leaving remnants of previous data:

    @Cheetah2003 said in FOG 1.5.6: Deploy is leaving remnants of previous data:

    It’s complaining my unattended setup answer file is invalid during the first boot of the deployed image

    Please give us the exact error message. Best if you can take a picture and post here. The more precise the info the better we can help…

    Sure I can do this. I’ll get a pic with my cell phone on one of the machines we deployed to. Should have it sometime tomorrow.


  • Senior Developer

    @Cheetah2003 said in FOG 1.5.6: Deploy is leaving remnants of previous data:

    It’s complaining my unattended setup answer file is invalid during the first boot of the deployed image

    Please give us the exact error message. Best if you can take a picture and post here. The more precise the info the better we can help…



  • @Sebastian-Roth said in FOG 1.5.6: Deploy is leaving remnants of previous data:

    What exactly goes wrong? Error message?!

    I told you before. It’s complaining my unattended setup answer file is invalid during the first boot of the deployed image (the part where Windows figures out what it’s running on.) And it doesn’t do it every time, only like… 70% of the time, and only on UEFI deployments. Legacy deployments are unaffected. Same answer file, same setup for the Windows image, except the UEFI/legacy partition layout differences, and DOS vs. GPT style partition tables.

    I’m also attacking this from the Windows angle too, trying to make a new answer file to put into my images, but of course, Microsoft’s tools are malfunctioning on me as well.


  • Senior Developer

    @Cheetah2003 said in FOG 1.5.6: Deploy is leaving remnants of previous data:

    I was honestly just going to pull at the threads of this thing to find the deployment scripts and slide in a dd drive nuking command myself.

    Nice you found this already. I was gonna suggest you try this out to see if it works for you.

    I have to admit that I am not much of a Windows guy really. Probably good to ask @george1421 and others here in the forums about issues with sysprep and stuff like that. But you will need to provide a bit more details as well I am afraid.

    it’s only when the image is deployed and booted (UEFI only) that something goes weird.

    What exactly goes wrong? Error message?!



  • It’s possible I’m incorrect in my assumption that there is data remnants causing issues.

    Basically the error I get, during Windows first-boot is it’s complaining my unattended setup answer file is incorrect. But it’s not doing it for every deployment. Seems random. I think my image is just messed up.

    However. It would still be nice to be able to nuke a portion of the drive with all zeros if needed for some reason. Maybe an optional place to insert a ‘dd’ command line during the deployment. I don’t think it’s entirely necessary, but could be handy.

    I was honestly just going to pull at the threads of this thing to find the deployment scripts and slide in a dd drive nuking command myself. But it may be unnecessary. The randomness of my issue made me believe it’s data remnants. But hand-nuking drives yield no better result.

    I’ll mark this as solved since it appears to be me, not FOG.
    EDIT: Can’t seem to change the solved/unsolved status of this topic. So, just tag it solved for now, since I’m pretty sure it’s my mistake, not FOG.

    2nd EDIT: I did want to mention, I am only encountering this issue on UEFI deployments. Normal legacy (BIOS) deployments are unaffected. Which is partly why I was suspecting FOG of messing something up, or leaving junk behind that Windows was finding and choking on. On UEFI, I will mention, I have not successfully created a PXE boot environment that works on UEFI machines, so I do have to flip target machines back to legacy BIOS mode to do the deployment, then flip it back to UEFI/Secure Boot afterwards to boot up the machine. This is when the issue comes up. Since the error I’m getting is complaining about my unattended answer file being messed up, this seems relevant. I’m using the same answer file for all my images (there’s 6 of them.) and only the UEFI deployments are choking on it. So… not sure what’s going on there. Going to regenerate my answer file with the Windows ADK today to see if that will fix things. Maybe something changed in 1903 UEFI that the legacy deployments are unaffected by.

    One more edit haha: On the unattended setup answer file, in the past, if this file was malformed in anyway, sysprep would bitch right out of the gate and refuse to run. I am not encountering that, it’s only when the image is deployed and booted (UEFI only) that something goes weird.


  • Senior Developer

    @Cheetah2003 Well that’s interesting to hear. I am not aware of anyone else having reported this lately and I really hope we can figure this out.

    The FOS scripts run the following command to clear the old data from the drive: sgdisk -Z /dev/...

    Up until now I assumed that would be save enough. Can you be more specific on the details where you get the impression that disks are not cleaned (enough)? When you say “deployments are failing with strange errors” what does that mean? Please give us more information.


Log in to reply
 

211
Online

7.2k
Users

14.4k
Topics

135.6k
Posts