@george1421 Done, hope that’s more obvious now.

I added some more checks and a more appropriate error message so people will find out more easy in future versions of the fog-client.

@Sebastian-Roth Thanks for your help! That fixed the issue.

Thanks for the insight! I copied one of my build images to a test-copy, then made two changes. I then ran sysprep /generalize /reboot /unattend and allowed the VM to sysprep and reboot to see what happens. I didn’t capture it to run it through FOG, but I imagine the results will be mirrored once I do.

I noticed that your unattend file didn’t contain a reference to SetupComplete. Therefore, I edited unattend.xml to remove the <Component> block that contained <AutoLogon> and <LogonCommands> (within which was contained the reference to SetupComplete.cmd).

I moved unattend.xml to the Panther directory at your suggestion. When I ran sysprep, I tested it without defining a file, and sure enough, it picked it up with no problem.

After allowing sysprep to do its job, I logged in as the local admin (since I didn’t have FOG to join the domain for me), and no command windows popped up to try running SetupComplete as the local user. SetupComplete didn’t appear in the Startup tab of Task Manager. FOGService was set to Automatic and was Running. In other words, the things that weren’t supposed to be happening no longer were, and the things that were supposed to happen WERE! 🙂

 

By the way, slightly on the topic, I know the wiki suggests restarting the computer with a command in SetupComplete after enabling the FOG Client, but Microsoft’s documentation suggests this is a bad idea:

Warning You cannot reboot the system and resume running SetupComplete.cmd. You should not reboot the system by adding a command such as shutdown -r. This will put the system in a bad state.

My SetupComplete file contains two lines:

sc config FOGService start= auto
net start FOGService

It seems to still restart if needed, so maybe the shutdown line can be removed?

 

Thanks to @fry_p, @george1421, and @Sebastian-Roth for your contributions in helping me figure out this strange issue!

In addition to what @Shad0wguy posted, your golden image should be developed on an isolated network, or at least one that doesn’t have internet access for just that reason. You don’t want windows updates to help you “fix” your system while you are preparing for it. If you are doing this in audit mode, for sure disable the windows update service until just before sysprepping it. I myself use MDT to build the golden image so one of the task sequences is to update the windows updates from our WSUS server and not to use direct internet updates. That way the updates are applied and completed in a known state before MDT exits. We will typically sysprep and capture with FOG right after MDT finishes.

But its great you are documenting the problem here and the potential solution. Because if you have the issue there are 100 other folks that will have it in the future. So thank you for helping them out too.

@seahunter Well we can take the fall back approach and build a FOS usb boot drive to bypass iPXE altogether. I’m pretty sure that bzImage will work if we boot from a usb flash drive.

Here are the instructions. Read all of my posts including the caveats in taking this approach: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

Also look at the forum chat bubble in the upper right corner of the page for a few additional hits.

@duanekaeb Thanks for the pictures. What I posted was the command parted -l - the parameter being a lower case l (like lion). But using the print command you still got us exactly the information I was hoping to see.

Ok, so the partition layout is fine from my point of view. So now I am wondering if C: is simply almost full and that is causing the problem. Reviewing the pictures again I saw something that I have not noticed before: Needed relocations: ... (16179 MB)

While I am not an expert on the ntfs3g-lib implementation I am really wondering if this is just “too much for it”. It tries to shrink the partition and for that to be able to do it would need to relocate/move roughly 16 GB of data. While it’s not nice that it fails to do so I can kind of understand it’s having a hard time to do so.

I really wonder why defrag didn’t help you with this. Probably a bit different on the SSD, hmmmm. Not sure what else we can do for you.

Yes, I’ll try to get to those. I am under a time crunch right now so I can not get to that right away.

I deployed the image that gave me the error after it was created, and it deployed successfully.

@Russell18 said in Cannot Install One Or More Boot Critical Drivers:

Does this help in way?

Truthfully, no.

FOG doesn’t care about drivers at all, your issue is with WinSetup/OOBE.

From a windows standpoint, how are you installing the drivers into your windows golden image? Are you deploying a universal image for all hardware or do you have hardware specific images? Are you sysprepping your image before you capture with FOG? If you have a single golden image did you install all drivers for all possible models you are deploying to? Have you done the Shift-F10 thing and look at the windows setup logs in c:\windows\panther directory to see what driver/issue its having troubles with?

As you might see there are more questions than answers. But at this time the issue during deployment is after FOG’s job is done, your issue is within WinSetup/OOBE.

Thank you for your help. Removing the client was the solution. I looked into and as before I didn’t need any of the functions it assisted with. Thank you for your help.

The drive still doesn’t resize correctly, but I will wait for the release of 1.5.7. At the time thought the two may be related. Looked through the reported bugs and didn’t see one that specifically called out that issue, but I will keep looking.

Thanks again for all of your help!!

+Craig

@bravetoad Anything after that? Interesting that it says “Response Invalid Host”. From what you wrote so far I suspect the host to be registered in the FOG web UI already, right?

Do you see anything in the apache or PHP-FPM logs. See my signature on where to find those.

It looks like a sysprep /generalize into audit mode before capture solved the problem. Thank you for your help!

@Fazyl Is this your first contact with FOG? Just wondering if you ever had an image that captured and deployed properly?

Please post the contents of the files d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions which you find in the /images/... directory on your FOG server.

@george1421 said in Windows Not Booting:

best hypervisor

What do you feel is the best Hypervisor for Imaging?

@george1421 said in Windows Not Booting:

But if all you have is a hammer, everything looks like a nail.

Very true!

I’m dumb. Thanks for pointing that out. Worked like a charm.

@Quazz After running tests, it was Sophos that was causing the issue. Thank you!

@jemerson93 said in Assistance with unattend script:

I also no longer need to have separate unattend scripts for Windows 7 and Windows 10 MBR and Windows 10 GPT.

Excellent!! There are a few new options in Win10 unattend file but you can bypass them and as you found you can make the unattend file almost universal. That’s one less bit you have to constantly manage.

@Fernando-Gietz Seems like a nice workaround. Please give @EduardoTSeoane’s suggestion a try for now. I can imagine this is something we should be able to fix within the fog-client but neither have I got a sysprep setup ready nor the time to dig into the depth of windows service dependencies and timing. Sorry!

Probably related: https://forums.fogproject.org/topic/13224/issue-joining-domain-activating-windows-after-deployment