@greg-plamondon That is one of the reasons I set this up, we have some wifi only devices, setting them to default boot to lan just doesn’t work. Also users get confused and or complain about the time it takes for the lan boot. So I set up a custom boot manager and got the best of all worlds.

I did recently accidentally (so sadly not sure how to recreate it) find that the windows boot manager does still have a gui mode. So you could theoretically create this functionality without the use of third party tools. I discovered it when I imaged a computer that had 2 drives. I imaged the nvme in a desktop that had a old spinning drive that still had a windows install on it and windows saw the old spinning drive’s install first and kept booting to that. At some point I had a windows boot menu that showed both windows options. So there is still a way to add custom boot entries to the windows boot manager. Probably a mix of enabling the timeout in bcd bootmgr settings and then adding a custom boot option. So you could theoretically make it so you see an option for straight windows boot and straight fog ipxe.efi file boot. Personally I like using grub, but just wanted to let people know it’s an option someone could try to figure out.

Hello

Did you find the solution, I have the same problem with 3 VM on proxmox :

1 debian fog server, 1 working windows 10 machine (That I have imaged) 1 test machine for deployment (I have the same problem after deployment)

Thanks for any help

@sebastian-roth
Nice one! thanks. I added the VPN MAC address!

@george1421 Scratch that. I was confused about how this works, my apologies.

The Windows 10 installation I used to create my image is using an MBR, aka Legacy boot.

Thanks again for the quick reply.

@klisza1993 said in Fresh FOG installation and no Client detected:

Middleware::Communication ERROR: Communication ERROR: Request Aborted: Unable to create SSL / TLS secure channel.

I have never seen this error before and I am not sure where it might come from yet. In your first post you said you didn’t enable HTTPS when running the installer but you later post says you are using HTTPS as well. So I would imagine that a request to the HTTP URL is being redirected to HTTPS (default when you enable HTTPS with the installer) and the error stems from an issue with the server certificate.

Did you manually change the webserver configuration?

During troubleshooting, what i have discoverd, tah i can get communication with Server pasting this link into browser.:
https://192.168.205.132//fog/service/register.php?hostname=rk-test&mac=D6:C8:93:84:8B:24&newService&json
From my poinf of view its NOT SECURE.

Surely not ideal but you need to consider that FOG is not a secure product. Very few people help working on the code to find and fix bugs. You are more than welcome to join the force and get this out of the way.

@lakk I have had to work (deal) with them from time to time. I can tell you I did the exact same thing with them (breaking the mirror) by (assuming) the intel raid controller acts like a traditional raid controller. I can tell you it does not, because it exposes both the raid device and the JBOD disks to the OS. The OS needs to be smart enough to know how to manage the array.

I did write a tutorial on how to use FOG with these type of raid adapters here: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid (oh my all the way back in 2016…)

I can tell you another example (possibly of what you are seeing). We have several dell precision rack mount workstations that use these raid controllers for their local disks. Somewhere in 2018-2019 they upgraded the OS from Windows 7 to Windows 10. About 6 months later we got a call that 2 of the workstations had reverted back to windows 7. This wasn’t possible because it was a clean install of windows 10 and not an upgrade from Windows 7. Its just not possible to do what they said it did. We had them reboot the workstation and take a few screen shots. They called back and said that it switched back to windows 10. Thinking they were just crazy we said the next time it happened give us a call. About a month later it did it again. To no make this any longer of an example I’ll cut to the point. We found that the raid-1 mirror was split (akin to split brain) some time before windows 10 was installed. So not knowing the mirror was broken they installed windows 10 and it went onto one disk while the other disk remained at windows 7 install. It appears that the intel raid controller picks at random which disk will be the leader and the other the follower in the mirror (for the intel controller the leader disk has read/write activity, while the follower only has write activity). That is how on one boot it would start up as win10 and the another boot win7.

@lebrun78 Can you run this exact script in the SYSTEM context (as described below through PsExec) and see where exactly it fails?

@sebastian-roth
No actually, the share is only accessible to administrators.
I use a powershell script which mount with a samba share account the share and launch the installer.
but the script seems not working when run as system.
I’m investigating

@tom-elliott
Merci

@sebastian-roth I looked in the registry and I deleted the left over fog files, I got it to work after a little tinkering.

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