@azm9s
In general, it didn’t work.
it doesn’t add it to the domain, that’s all.
Either I did something wrong.
or I have configured something wrong in the settings.

@jfernandz No, it’s not being implemented at all currently. If you want to take a stab at it, please feel free. I don’t know what it would entail and I am fairly confident no one else within the FOG Dev team is currently trying to implement such a feature.

joining pc to domain and logging into the domain account seems to have brought the settings.

just to update I downloaded windows 11 23H2 from MS admin console and then made a new image with fog and deployed it and whilst for some reason the GPO that should auto encrypt the c drive doesn’t appear to be working, if I right click it and choose encrypt with BitLocker and chose allow windows to unlock the drive automatically (which is what the GPO should do) it encrypts just fine. So its definitely something new with Windows 11 24H2 I suspect its to do with secure boot being disabled.

Edit ignore the bit about the gpo not working I moved the pc to a diferent OU for testing and it simply wasn’t applied. I have since now forced windows update to install Win11 24H2 and the drive remains encrypted. so this for a while will be a workaround for our staff laptops that need to be encrypted.

@nathan67 @lebrun78

When I configured the snapin with my example script that installs the FogApi Module and runs the universal command with the snapin setup with “powershell x64” like this

a1465243-07f4-4295-a707-7b295fd19e15-image.png

The snapin worked as expected and the host boots to pxe. I only tested this snapin method on a VM so far but I imagine it will work beyond that.

@Eliseu
this ip 192.168.0.17 is from the virtual machine that is trying to boot into the pxe, the ip 192.168.0.16 is the fog server

@JJ-Fullmer Thank you for the suggestion! I’m still new to creating GPO’s so I’ll have to figure out how to do that one. Doesn’t seem like it should be too hard. Thank you!

@mentaluproar sadly, due to the windows updates previously mentioned, which are actually fully enforced in the 2024-08 updates, a domain admin account is pretty much required to join the domain in an automated fashion. Microsoft gives some guidance on creating policies to allow a least privileged account but I haven’t been able to get that to work with fog. Granted, as long as your aren’t granting access to the fog gui to non privileged users, saving those creds in fog is safe and secured.

I’ve found myself in this situation where many of my hosts are stuck in this 0.11.16 version and I was assuming they would eventually update themselves, but now I see they won’t.
I’m assuming there is no way to force update them, right?
I am managing a whole building with hundreds of computers, so it would be helpful to have a way of knowing which of my hosts have this old client and need manual updating, and which ones are already updated.
Is there any log or exported info where fog server could show which client version its hosts are using to sync with the server? something like how the fog client shows the fog server version that it is connecting to, but the other way around.

@HorizonG said in FOG Golden Image, Sysprep and unattend post install:

’d also try renaming the post as explained:
with the command: sed -i “/ComputerName/s/*/$hostname/g” $unattend >/dev/null 2>&1

The variable $hostname comes from FOG, the variable $unattend must come from your script to define the location of the unattend file on the target hard drive.

Something to know, If you are questioning if each script is being called, place an echo some text at the top of each script. This way you can see each script being called.

One other tip I use for debugging post install scripts is to run a deployment in debug mode. Schedule a deployment, but before you hit the schedule task button tick the debug checkbox. Now schedule the task. PXE boot the target computer you will be met with several screens of text that you need to clear with the enter key. This will drop you at the fos linux command prompt. Now key in fog to start single stepping through the deployment. At the end of the image push you should see the post install scripts executing. If you use the debugPause; command at certain locations in your script you can stop the execution and wait to press enter. If you were to hit the ctrl-c key you can exit the deploy process. What this will do is give you the exact environment where your script is running. You can try different commands or fix the post deployment scripts. If you enter the command fog again you can restart the deployment process again without rebooting.

One last tip is that when you are interacting with the deployment process you are executing on screen 1, if you need command shell access you can press alt-f2 to go screen 2 run some comands and then pop back to screen 1 with alt-f1 to continue your script.

The pather location is the location where microsoft recommends you place the unattend.xml file, because it will look for the file there first. Where you get things confused is if you have an unattend.xml file in both locations because it will aways use the pather location first.

@elchapulin remove hibernation file (shown hidden files) or use sysprep
FOG won’t run with those on the system.

@sweeperdave So a machine of the same make model (and roll out) works perfectly fine, but this one machine has an issue?

(Not in windows of course, but just trying to understand the issue.) I see @fogcloud has written, and I apologize for missing this sooner.

I suppose “details” are what we need to potentially be able to help.

If suddenly ALL of the same make model (equipment roll out) are acting up, I would have to ask:

“Did you update kernels recently?” but if that’s not the case we are pretty sure it’s limited to this one machine.

At that point, I would say take a known working system, look at the bios configuration and see if there’s anything different in this strangly acting system. (If I had to guess it’s related to VTx technology enabled or something like that on this machine vs the other machines.)

Be cognizant of BIOS/Hardware Firmware versions and what not as well as those can also play a role in the overall operation of the device. Since replacing the drive and testing the same machine produces the same problem I’m leaning more specifically to the BIOS itself here.

This is just my experience.

If everythign else is effectively 1:1 from another, then this could just really be a faulty machine that only presents itself in the imaging process.

@zguo There are two things I can think of to create the initial error message.

You have the fog client installed and the services hasn’t been disabled before image capture. The fog client is starting to do its action before windows is fully installed. You have a driver install that is forcing a spontaneous (all of a sudden) reboot of the computer before windows is installed.

I’m going to do a new install so hopefully all goes well.

Mat