FOG 1.5.6: Windows unattended.xml is intermittently failing to work
-
@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.
-
@george1421 So I just got a patch for WSIM off Technet. I’ll regenerate my answer files and report back results.
-
@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.
-
@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.
-
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.
-
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.
-
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.)
-
@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.
-
@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.
-
@Cheetah2003 I didn’t look for my script from a few years ago, but the basic concept is here: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/diskpart-scripts-and-examples Where you run the diskpart with the /s parameter and give it a text file with the extend commands.
And this one that shows you the extend commands: https://www.cloudsigma.com/windows-partition-auto-expand-script/
No fancy powershell commands needed as well as having to deal with PS execution security.
I think with these two tests we’ll have a better idea if fog resize is messing with the disk partition structure.
-
I’m back! New results!
I prepared my same image again, just to be sure it’s ship-shape. I captured the image with ‘Multiple Partition Image - Single Disk (Not Resizable)’ setting on the image.
4 out of 4 deploys worked flawlessly. Think we can call this case closed. Resizing NTFS partitions is dubious with the linux based tools and is causing intermittent issues with UEFI systems.
Why this doesn’t affect legacy deployments, you got me. Ask Microsoft? I’m going to just put a powershell script to have windows do my resize operations after setup completes.
Thanks to all who helped me track this issue down to it’s cause. Back to work, for me!
For developers looking to remedy this issue, I’d look into this error message (which I’m not getting anymore with that no-resize setting!!):
The protective MBR's 0xEE partition is oversized! Auto-repairing.I’d bet money this has something to do with it breaking on UEFI systems.
-
@Cheetah2003
I’m having this exact issue as well on 1909. Did you ever find a fix? -
@tech49 In this topic there is more than one issue being discussed. So “exact same issue” is not clear. As this was on FOG 1.5.6 I suppose things might be different anyway. Please open a new topic and post all your details: FOG version, Linux OS/version, error message (picture)…
