@AUTH-IT-Center with the dev-branch the created folder after the image capture has the correct permissions.

83223c8f-3d3a-46ab-af0b-c3634e6768ce-image.png

will wait for the update on stable branch to deploy to the production server.

Thank you!

@Tom-Elliott

You’re right, I created a storage group without making the storage node.

Here’s what I did:

Storage Management => New Storage Group => Storage_Group Snapin => New Snapin => Powershel script => Member of Storage_Group

The second part was to use the

$ALL_Snapins = Get-FogObject -type object -CoreObject snapin $ALL_Snapins.data $All_Snapins_Target = ($ALL_Snapin.snapins | where {$_.storagegroupname -like "Storage_Group"}).name

foreach ($ALL_Snapin in $ALL_Snapins)
{
Start-FogSnapin -hostID $FOG_HostID -snapinname ($ALL_Snapin.snapins | where {$_.storagegroupname -like “Storage_Group”}).name
}

@Tom-Elliott

Thanks Tom, that fixed it right up. I guess I overlooked that file when copying everything from the original /images.

Yeah, that fdrive number… 🙂 It is the serial number of the drive.

The NVME drives initialize differently each time during boot. I guess that is a thing, so nvme0 would sometimes be nvme1. It was a mess. Then I learned drive size could be used to differentiate between drives under Host Primary Disk. Now that both of my NVME drives are the same size, I have to use the drive serial number.

@HorizonG

Hello Sorry for the late reply, but I’ve deleted the host concerned and the problem is gone.

Using the latest experimental fos kernel I am able to deploy via task without issues. https://github.com/FOGProject/fos/releases/tag/EXP_20240720

Thank you all for your help in getting this to work.

This can be marked as Solved

Finally finished a brand new image this morning where we started from a fresh Windows install. The image captured without an issue. I suspect the age of our previous image was to blame for the issues with the capture. I think recent Windows updates by Microsoft to the recovery partition may have modified the size or something else in those recovery partitions.

New image pulled using the 6.6.34 Kernel, and then deployed successfully as well. If anyone is having issues related to the errors I posted above, I would try the CHKDSK + defrag/trim, and if that doesn’t work I recommend rebuilding your image from a clean Windows install with the absolute latest Windows enterprise installer.

Thank you Tom and crew for all the excellent technical assistance!

I haven’t gotten around to it yet, sorry about that. unfortunately I’m only working part-time.
But without this one pc, fog is just great 🙂

Ok, as I hate people that don’t come back. I try my best not to be that guy.

FOG problem = Nope… As usual.

Problem with dropouts, scrambled data. Proxmox 8 is very angry with my onboard nic. It uploads without issue (and very fast I may say) But deployment it just crapped out. Every time it re-connected, Fog just tried to do it’s job over and over. The blast of data just shut the nic down.

Finally found this looking in the Proxmox log. Found ethernet adapter hang detected, then reset.

Also a great excuse to finally order that dual 10Gb card. She’s happy now running full speed. Hopefully faster when the 10Gb switch shows up 🙂

Thanks to all that looked over this, and even more for the reply. !

@El-Fogito So with that can you reboot the machine (outside of the task) and perform a chkdisk /f on it, then disable the hibernation:
powercfg.exe /h off

Then attempt again? I apologize in advance

@PierreM59 If the computer cannot operate on HTTPS sites, and is using current software, I don’t know there’s anything we can provide to help you.

“Some work and some don’t” seems contradictory. While sites will use different versions of certificates, the fact that you cannot even reach the site tells me you are behind some kind of “gate access” preventing you from even reaching the “some don’t” category.

If you take that same machine, and run it on a network other than where you are currently, does it have the exact same problems? If it does, then is this “gateway” that’s preventing access likely installed locally on the machine? If it doesn’t have the same problems, then it’s the network from where you’re currently operating.

@Tom-Elliott

Thank you, while looking at the log, I noticed an oddity and after reinstalling the FOG client, it is now fixed. I appreciate the assistance in helping me track down this problem. The tasks are working correctly when coming from the FOG server itself now. I appreciate it!

It does look like things are working. I added a host to a group and then did a simple Basic task in the group and it pushed it out to the host. Now I just need to figure out a way to get hosts assigned to groups based on IP.

We have like 600 systems to image so trying to automate as much as I can.

Mat

@Tom-Elliott version .41 has solved the issue. Thank you so much!

@Cire3 Honestly we don’t know.

The information didn’t make sense to any specific “thing” being wrong or what even truly was wrong.

@IT-MAN
Where are you capturing your image and are you using sysprep to generalize the image without any drivers?

The only way for driver injection to work on the windows side automatically is to use sysprep via an unattend.xml. Well I guess technically setupcomplete.cmd may run after setup without it according to https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-a-custom-script-to-windows-setup?view=windows-11 but utilize sysprep and an unattend.xml is far more robust.

It is possible to inject just the driver files into the disk in a post download script but without sysprep to kick it off, you can run into issues.

This requires capturing your image with sysprep and an unattend.xml. One thing you can do with unattend.xml is remove the drivers from the image so that conflicting drivers don’t exist, then you can add the pnputil portion in the specialize phase of sysprep.

This post is what I used and I added some of what I’ve done on top of it that may be of help.

https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection
Also this one
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script

At a high level, driver injection being dynamic per model has some assumptions

You captured an image that doesn’t have model specific drivers (this is easiest when capturing from a VM and using sysprep) You have drivers organized within your /images nfs share You have a postdownload script that detects the model, finds the drivers, mounts the windows disk, and then injects them into a known path You have a method to kick off a script that installs the drivers into windows For example, I have a synchronouscommand in my specialize phase of my unattend that runs pnputil against the injected path, so drivers are loaded as early as possible in the process

@alessandro19884 Is that working-1.6? I would update your fog server, that error should be fixed in the latest version.

@JJ-Fullmer Thank you, In the end I opted to add a second disk, structurewise couldn’t add the nfs,
Regards.

@steveballantyne Did you also update the Kernel and Init? What version fo FOG are you on?

Thank you 2 for the assist. I figured it out. I had to add vendor arch 00009

solved

I disabled Windows 11 fast startup and the image could be captured.

Thank you for your answers