@jyost said in Roughly half of reimaged devices do not run first run scripts in autounattend.xml after imaging.:

If the renaming/domain join occurs AFTER the final restart I will need to run a powershell script to install our AntiVirus software and also add a domain user account to the Remote Desktop Users group –

You might want to consider deploying this action with a snapin. Snapins will run after all of the other imaging actions are complete.

@AlexPDX Which version of Windows do you use exactly?

We had reports about what sounds similar to what you say not long ago.
https://forums.fogproject.org/topic/15258/windows-10-and-fog-product-key-problem-20h2
https://forums.fogproject.org/topic/15256/win-10-pro-product-key-not-installed-probably

I am still not sure if this is something the fog-client is doing wrong (we just use the slmgr.vbs calls that worked for a long time) or if it’s Windows preventing it from happening.

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