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

[Sebastian Roth]

@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…

[Cheetah2003]

@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.

[george1421]

@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.

[Cheetah2003]

@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.

[Cheetah2003]

@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]

@Cheetah2003 I can’t believe that is your unattend.xml file and you can actually build computers. That is incomplete in my mind for many reasons. Understand I’m not saying it won’t work, I just can’t believe that it worked until now.

Secondly that unattend.xml file and its copyprofile tag does nothing with windows 10. M$ removed the copyprofile feature when windows 10 was released. This alone has caused so much angst with image creators.

With that said, here is an example of my sanitized unattend.xml file. It hasn’t changed since Win7 days and works correctly for both win7/win10/bios/uefi. https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/7 Possibly there is something in my unattend.xml file that is needed for uefi deployments. I haven’t experimented with throwing things out until it broke since it worked, I really didn’t need to mess with it.

It would be interesting to know if you following the directions in that post including the sysprep command if you would still have similar results. I’m almost 100% sure your problem here is NOT a FOG issue, but rather a sysprep/M$ Windows problem.

[Cheetah2003]

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

Secondly that unattend.xml file and its copyprofile tag does nothing with windows 10. M$ removed the copyprofile feature when windows 10 was released. This alone has caused so much angst with image creators.

??? It works. It’s always worked, since day 1 of Windows 10’s release. I did have some issues at one point with it malfunctioning, but updates from M$ fixed it again.

It copies the profile exactly as it says it will. So I dunno man.

But you are right about one thing, this is not a FOG issue. I said that in my previous post. We’ve figured that out.

If y’all don’t wanna help anymore, that’s perfectly understandable. I’ll eventually figure it out.

[george1421]

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

If y’all don’t wanna help anymore, that’s perfectly understandable. I’ll eventually figure it out.

I don’t believe anyone said about not helping, I wanted to clarify that at this point the actual issue is in opposition to this thread subject line.

As for the copyprofile… My experience is that it doesn’t work or at least appears to not work as it did with Win7 in how the profile was managed. But that, I guess is just my experience.

I would still be interested with my unattend.xml file if OOBE/WinSetup runs correctly in uefi mode.

[Cheetah2003]

@george1421 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:

If y’all don’t wanna help anymore, that’s perfectly understandable. I’ll eventually figure it out.

I don’t believe anyone said about not helping, I wanted to clarify that at this point the actual issue is in opposition to this thread subject line.

As for the copyprofile… My experience is that it doesn’t work or at least appears to not work as it did with Win7 in how the profile was managed. But that, I guess is just my experience.

Yeah. There was a point where it stopped working briefly, I think 1709 was the ugly release that broke copyprofile, but it was fixed a few weeks later. don’t quote me on that, this was a couple years ago. foggy memory.

As to the topic. I agree, this should move elsewhere and be renamed. I’ve been editing the initial post as we’ve discovered things. It can probably just be entirely renamed and moved elsewhere. It’s not a FOG problem.

However, my initial ‘request’ still stands. I think it would be useful if FOG’s deploy could be configured to zero a portion or all of the target drive before dumping the image onto the target.

I would still be interested with my unattend.xml file if OOBE/WinSetup runs correctly in uefi mode.

I appreciate this sentiment. But my process requires CopyProfile. I’m not really interested in reinventing my entire image creation process. I want to fix it so it works like it always has, not change to completely new arrangement. You’ve no idea how loudly I screamed on technet for microsoft to fix CopyProfile back when they broke it a couple years ago. Gawd I hope they didn’t screw something up with it again.

Not convinced it’s entirely CopyProfile’s problem, the fact things work half the time on UEFI deployments, and work 100% of the time on CSM deployments suggests something…else.

Someday, I’ll migrate away from CopyProfile. But while it still works, I plan on using it. It really simplifies my entire workflow, and avoids having to author a bunch of ugly powershell scripts to replicate what CopyProfile does. I’ll cross that bridge when I absolutely have to.

[george1421]

@Cheetah2003 Don’t take this the wrong way, but at this time I don’t really care about the copy profile bit, that is not where your issue is. Actually if you look at my unattend.xml file it has the copy profile flag set to true anyway.

My point is your unattend.xml file is incomplete (IMO). Whereas I asked if my unattend.xml file would work more reliably since it IS complete and I know from experience works with both bios and uefi platforms. And just for clarity I have 2 images that are built by MDT exactly the same. One is for bios target systems and one is for uefi target systems. They are exactly the same and use the same unattend.xml file. The only difference is the VM that MDT builds the golden image on. One is bios based and one is uefi based.

[george1421]

[MOD note]: I moved this topic out of the developer/bug forum to the Windows Problem forum where its more closely aligned with issues in that forum.

[Cheetah2003]

@george1421 I understand what you’re saying.

However, I did generate this answer file with WSIM. This is what it spits out when you generate a catalog from installation media and flip that copyprofile option to True in the specialize step, then tell it to generate the file. So I’m a little (hopefully understandably) skeptical when you tell me my file is incomplete. This is what WSIM spits out.

I was thinking the publickeytokens are not quite correct and it might be confusing setup some of the time. Why it never breaks on legacy deployments, your guess is as good as mine. Unfortunately, I can’t get WSIM to build a catalog for the current installation media. I’m on technet trying to resolve that problem. It’s a fun one… WSIM complains I need a specific version of ADK, but when I click ‘help->about’ on WSIM, it is the exact version it says I need. Fun times. Have a screenshot of that joy:

The generated file and it’s tokens has been an issue in the past, where previously generated unattended.xml would not work with newer versions, due to mismatches on those tokens. That hasn’t been an issue for about 3 or 4 update cycles, and previously, it would not even sysprep at all if the tokens were bad. I was hoping re-generating my unattended.xml with WSIM, using 1903 image as a reference would solve this issue. But I can’t get that going right now (See screenshot.)

Thank you for moving the thread to a more appropriate place. I edited the topic to reflect the issue more clearly, as well.

[Cheetah2003]

@george1421 So I just got a patch for WSIM off Technet. I’ll regenerate my answer files and report back results.

[Cheetah2003]

@george1421 Initially I thought there’s no difference. Then I spotted one tiny little change:
processorArchitecture=“amd64” This is how it was in the old file.
processorArchitecture=“wow64” This is how it is in the new file.

I will try regenerating images using this new file and see if it makes any difference.

[george1421]

@Cheetah2003 said in FOG 1.5.6: Windows unattended.xml is intermittently failing to work:

processorArchitecture=“amd64” This is how it was in the old file.
processorArchitecture=“wow64” This is how it is in the new file.

I’m in the middle of meeting this afternoon but those are not equivalent.
amd64 refers to 64 bit and wow64… maybe the 32 bit environment inside amd64.

I’ve also used this site in the past to generate the answer files: https://www.windowsafg.com/

Either way when using fog remove the parts of the unattend.xml file that deal with disk partitioning, that’s fog’s realm. Just remove those bits from the answer file.

[Cheetah2003]

Just chiming in. That subtle tiny change to the unattended.xml made no difference. I’m starting to suspect the target machines, at this point.

Today, I will try completely different target machines, and see if I still get the problem.

[Cheetah2003]

Same issue. Very consistently 50% of the computers fail, with the message in that screenshot.

Deployed to 8 identical machines, half of them boot to setup normally, the other half fail with the error. Curious I tried clicking ‘ok’ on some of the machines that failed, but they just reboot and fail again. Only redeploying will give a chance for it to work.

Got some different machines, by a different manufacturer, got 4 of those, deployed the image. 2 boot normally, 2 fail at the error.

Anyone got any ideas what to try next? I’m stumped. I posted on M$ technet about this as well.

[Cheetah2003]

New information, and alas it’s not good.

On a hunch, given the circumstances, I decided to switch the images from partition captures to just a raw disk capture (dd.) Oh god it’s slow.

But 5 out of 5 deployments worked, no hiccups. I’m afraid I believe FOG is damaging the UEFI partitions some of the time?

What should I try next in my diagnosis? I can work with DD/raw disk images, just an extra step later in our process and it’s kind of slow. But it’s working?

Could this be related to that strange error message I always get when capturing UEFI/GPT disks? I do get this message several times during a capture. It’s never caused a problem in the past, but maybe it has something to do with this?

The protective MBR's 0xEE partition is oversized!  Auto-repairing.

I’m presently preparing a new image that’s as small as I can get it, to do more deployments in mass, to get a better sample of success vs. failure rate (five isn’t a great sample size.)

[george1421]

@Cheetah2003 Ok what happens if you create your master image on a 70GB disk (smaller than anything currently in a productive environment) and make the last partition your drive. Then capture and deploy as single disk non-resizable. Maybe the FOG resize code is make things unstable for UEFI (not sure why your case is unique at the moment).

Before fog support single disk resizable I had code in my setup complete.cmd file that would instruct windows to expand the last partition to the size of the disk. I have to look to see if I can find that code again, but it basically automated diskpart to expand the partition.

[Cheetah2003]

@george1421 said in FOG 1.5.6: Windows unattended.xml is intermittently failing to work:

@Cheetah2003 Ok what happens if you create your master image on a 70GB disk (smaller than anything currently in a productive environment) and make the last partition your drive. Then capture and deploy as single disk non-resizable. Maybe the FOG resize code is make things unstable for UEFI (not sure why your case is unique at the moment).

Before fog support single disk resizable I had code in my setup complete.cmd file that would instruct windows to expand the last partition to the size of the disk. I have to look to see if I can find that code again, but it basically automated diskpart to expand the partition.

Yeah, I considered using SetupComplete.cmd to automated that resize myself. I was studying all the fancy powershell commands to manipulate partitions. Automating the resize with powershell script should be mostly trivial.

I’ll do you one better, I’ve squeezed down my image to 50GB. When it’s ready, I will try both some raw disk captures/deploys and no-resize partition capture/deploy as well and report back. Should have more information on Monday.