@nfiglar Typically you would add the command to add the computer to azure ad in the setupcomplete.cmd batch file or in a first run command in the unattend.xml script. At the very least you could create a snapin to deploy a package that joins the target computer to azure AD. dsregcmd /join

@sebastian-roth Sorry for my late response, i use windows 10 build 20H2.
I have tried installing the key with slmgr.vbs manually, that’s not working so i think its a bug in windows…

i have tried finding a old windows 10 build (2004) to try if it works there, but no luck so far…

@sebastian-roth Thank you for your suggestions. My team and I were able to start from scratch with a new Win10 Pro image and we captured/deployed this new revision without issues. There must have been some sort of driver or configuration issue on the actual host image that was causing this.

Thank you for helping me double check that everything in my Fog settings were properly configured.

Merci je testerais cela un de ces jours.

@Navdeeppal While we use PXE boot a lot in FOG I don’t see what your question has to do with the FOG Project?!

@tom-elliott Thank you very much for your assistance and time!

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