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.

@azm9s said in Configuring adding to an active directory domain.:

Do I need to create an capture creation task on the site in the host settings?

Just to be clear on this task. Once you have your golden image the way you want it. Use sysprep command line switches to power off the computer, or user the shutdown -s -t 0 to power off the computer. This will properly close the files for cloning. Then schedule the task for image capture in FOG and then pxe boot the target computer.

Prior to your step file, you need to create a batch script called setupcomplete.cmd in the proper location (google it), and in that batch file use the sc command to enable and start the fog client service (this should be explained in the fog client wiki page). The setupcomplete.cmd batch file (if it exists in the correct location) will be called by OOBE/WinSetup when its all done with its bits. At this point we want the fog client to be enabled and started so the fog client can do its stuff.

Yes on the AD stuff. You will probably want the fog client to rename the computer too, or it will go into AD with a generic system name.

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

@george1421 oh, that will be our best alternative for now, sure 😉 Anyway I was just trying to think in some possible feature FOG client could implement regarding this, maybe I’ll be willing in the future to contribute to the project 😊 though not sure right now if Suspend-Bitlocker will require some kind of authentication 🤔

@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

@JJ-Fullmer

Hello,

My problem is solved, it was related to the lack of loading of NVMe drivers at Windows startup.
I made my image on a workstation with NVMe disks instead of sata disks, which gets around the problem.

@Joe-Gill
I work in particular environment : a school.

All we install is use for a very short period (not more than 2 weeks) , So I don’t need to SysPrep for instance.
Nearly the same for our software that are pre-installed in our images as they usually are free and for those which are under trial license it depends from a software to another.

So I’m not using FOG in a “REAL” production environment.

@george1421 Perfect, thank you very much for all of your explanations!

Paolo