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

@Jurgen-Goedbloed I had a look through the code and I am fairly sure this is caused by the old code signing cert has lost validity on the 7th of September 2020. This cert is only used to ensure the binaries are certified by the FOG project team. We updated the code signing cert in January 2020 and released FOG 1.5.8 together with fog-client 0.11.19.

Unfortunately I kind of lost sight of this “major” change that would affect auto-updating after 7th of September 2020 and never officially announced that people should update earlier for the auto-update to work.

So from the version number we see in your log file I am sure you updated from FOG 1.5.7 to 1.5.9 - skipping the fog-client update that introduced the new code signing cert. This would have worked perfectly fine while the old code signing cert was still valid but fails now.

You’ll need to update all your fog-client installations to 0.11.19 (auto-update to 0.12.0 will work from there) or 0.12.0 through some other kind of software deployment mechanism I am afraid.

For now you should manually edit /var/www/html/fog/lib/fog/system.class.php and set FOG_CLIENT_VERSION back to 0.11.16 or clients will keep downloading the SmartInstaller.exe binary over and over again and put load on your FOG server for no reason. The code is smart enough to handle a situation where you have FOG_CLIENT_VERSION set to 0.11.16 version but the fog-client on some or all of your machines is on 0.12.0 already. So don’t worry about this.

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 !

@ckasdf Are you still onto this?

@Real1987 What does this have to do with FOG imaging solution? Is this after deploying an image to the 3400? What version of FOG do you have? What OS is in the image? What type is it set to (resizable or non-resizable)? Is BIOS set to legacy mode or UEFI?

Many more questions arise, but we might start with those.