@dmoore Finer points so you can be in legal rights:

https://aidanfinn.com/?p=14534

While the article is old, I believe it is still a relevant.

https://www.reddit.com/r/msp/comments/eboxe1/windows_10_imaging_rights_per_msft/ (more recent documentation)

This is from 2017 but its still relevent today. I should update just so it doesn’t confuse people thinking well its 3 years old it can’t still work.

https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

Driver injection happens in 2 parts. The first part is a feature of FOG called a post install script. These are bash (linux scripts) that gets called just after FOG deploys the image to the target computer and just before FOG reboots the computer at the end of imaging.

Using these scripts we check the model number of the computer then copy over the right drivers to a common location on the target computer. That is where the FOG world stops.

In the windows world we add a command to the windows standard batch file that gets run at the end of OOBE and before the first login pane appears. This file is called setupcomplete.cmd. In this file we are going to add a command that calls the windows pnputil.exe program and point it to the directory where FOG dropped the drivers.

pnputil.exe /add-driver "C:\Drivers\*.inf" /subdirs /install

That pnputil program will search all sub-directories in c:\drivers looking for inf files to install. That program will also replace any windows generic drivers with hardware specific drivers.

I use a modified version of the script in the tutorial to support 15 models of Dells with one base image. Those post install scripts can also be used to update the unattend.xml file with (FOG) run time settings. I don’t use the fog client on my campus, but I use a post install script to supply the system name and target OU to the unattend.xml file and then let the target computer name itself and connect to AD in the proper OU.

@snjlscmi If you are willing it may add value for your IT partner to participate in this thread since the solution may require some technical questions and answers.

Network pxe booting requires the cooperation of several technologies. As Sebastian mentioned having a picture of the error will help set the context of where its broken. If you get no iPXE menu then that means the iPXE boot loader is not being sent to the target computer. In this case undionly.kpxe (for a bios computer) or ipxe.efi (for a uefi computer) is not being sent to the target computer. This information is typically sent via the dhcp process.

Hi,

thanks for your suggestions, i made another try i gave the first login more time, after 10 minutes the first login attempt worked, i maybe was to impatient usually a login doesnt take such long, every login attempt after that first one is working normally.

Hmpf, i will try recreate the image from scratch to see if this impact occours again.

Best Regards X23

@altitudehack said in Smart Installer caching credentials causing AD lockouts - maybe?:

It’s especially weird because I wouldn’t have been able to actually run the installer as a non-admin …
Sorry for pointing the finger at FOG but it’s the only non-commercial software installed on this particular laptop that I installed under my non-admin account.

Those two sentences don’t make sense to me. One is saying fog-client was installed using the non-admin account and the other says no.

The fog-client installs a service that should run as local system account and not using AD-accounts at all. Though the fog-client is trying to join the domain on every cycle it runs. If your non-admin account is used as AD-credentials (FOG web UI -> host settings -> Active Directory) and the password was changed at some point I can imagine this to happen as described. But the AD-account would have to have rights to join a computer to the domain - don’t think a non-admin account can do this.

MOD Note: Cross forum post here: https://forums.fogproject.org/topic/14843/doubts-about-fog-project-client-windows

I had tried that originally when I started working with all of this. Either I wasn’t doing something correctly, or it’s not built that way, because I never could get it to enable the build-in administrator account. I still have the files if you want to take a look at them.

@Maxime22 is your fog server at 192.168.1.200?

If so, do you have a cheap / unmanaged / dumb network switch you can install between the building network switch and the PXE booting computer for a test? If this dumb switch solves the problem then we have a place to look.

@george1421 said in Not able to use Legacy on BIOS 😞:

ipxe.efi

George, you are the best. You constantly help me out on these forms. If I could take you out for a working lunch I would.

I switched it over to ipxe.efi and it worked.

@george1421 Very nice, I will have to read into this. I will just need to comment out the AD domain joining and keep the host name change part only.

I realize this post is a bit old, but I wanted to thank everyone for their suggestions and give our experience to back up what has been said in this topic already. We experienced an image that should have been about 120gb, but was showing in FOG as the full 500GB hard drive. After referencing this thread, it fixed the issue. The steps we took are below in order:

Verified that the PC didn’t have a second drive or second large partition it was capturing
Verified that bitlocker encryption was OFF using the command prompt command “manage-bde -off C:”
Ran Disk Cleanup (to get rid of old unused files)
Ran Tools > Check to scan for hard drive errors (may require reboot to fix)
Ran Tools > Tools > Optimize and defagment
Capture Image again

Once we did those steps, the newly captured image only takes up the actual amount used on the hard drive.

i solved my problem using undionly.kpxe file from a debian 10.4

@sysadmin How did you create this directory /opt/fog_stable Did you clone it from the git repository? Your error is not a very common one or one I’ve personally seen before.

Just to be clear (I can read your request 2 different ways), fog doesn’t care about the source image or how its setup. FOG only moves disk blocks from the source computer to storage on the FOG server and then from storage on the FOG server to the target computer. How you prepair the reference image before cloning and what happens to the target computer after FOG is done is up to the IT technician.

But in general terms, for MS Windows you will want to setup the computer in audit mode to perfect how you want the target computers to appear, then sysprep the reference image and power it off (using a sysprep command line option). Then you pxe boot the reference image with FOG and capture the image. On the target computer side, you register the target computer with FOG. Then you assign an image to the target computer and create a deploy task. When the target computer is pxe booting FOG will image the computer then reboot it. On the first reboot the target computer will startup OOBE/Winsetup to complete the installation on the target computer, at this point of the first boot of the target computer FOG is no longer involved with the imaging process (said knowing that if the target computer is configured appropriately the FOG client will carry out an required post install commands).

There is a wiki page that describes capturing your first image that you might want to look over: https://wiki.fogproject.org/wiki/index.php?title=Booting_into_FOG_and_Capturing_your_first_Image

@rubencarmo Are both systems (target you pull the image from and destination PC) set to UEFI?

That was it! I knew once you mentioned the configuration for both uefi and bios, that was where the trouble was. I have enabled dnsmasq per the instructions you linked and it booted into the fog menu without issue.

Thank you very much!

First of all its not the best place to put the recovery partition at the beginning of the disk. The MS recommends the efi partition be on disk 1 partition 1. It has been that way for years. Also I would question the logic of needing a recovery partition at all. With FOG its much faster to rebuilt the system then to try to recover it. I understand (as someone recently pointed out) that if the computer is at a remote location to the FOG server then the only option is to try to recover it. On my campus I don’t use/create the recovery partition at all. I do use MDT to build the golden image, with MDT I can chose how to create the disk layout for both bios and uefi systems. If I had a choice I would place the recovery partition before the 😄 drive partition, that would make the biggest resizable partition last on the disk where it can be easily resized.

@bradgillap Thanks for reporting! I have not heard about fog-client being detected by any anti virus program yet. Have done a quick search in the forums and found nothing either. So I don’t have an easy solution for you on this.

Good you have been able to deploy again and put it on the exclusion list!

Soooo … 🙂

After Resetting the Encryption it works.

So in this case uninstalling the FOG Client, then Reinstalling it, manually started the FOG Service in Window and reset the Encryption Data solved the problems for this client.

I have a second machine that seems to have the same problem at first glance, but have to check that to make sure it really is the same.

And the Thread you found from me at the beginning of my FOG journey … i still add the certificate manually during sysprep via the setupcomplete. On this client I havent imaged in quite some time and its only me using it. Really strange. 😕

I’ll check the other client and report back.

Thanks !