The issue ended up being a configuration problem with the dhcp server. Once that was straightened out the target system pxe booted like expected.

@george1421

thank you george, the current switch is unmanaged, it’s a simple switch. There is not much in the specification of the switch, so I bet that switch is the problem.
All PCs are the same and support WOL and on the old switch they all turn on, but I will check it, maybe one of the students has changed something in the BIOS

Hi @chaddarnold @Quazz

1º.- As @Quazz said, use the Reset Encryption Data Button for the host/group in UI.
2º.- Delete the token.dat file on the Fog Client folder directory if it exists.
3º.- If you install Fog Client on the image be sure to image the computer with that file deleted, better if you automate the client installation on the first boot.

Make your install script with this recommended commands:

msiexec /i "C:\NewClientInstaller" /quiet USETRAY="0" HTTPS="0" WEBADDRESS="YourFOGAddress" WEBROOT="/fog" ROOTLOG="1" sc.exe config FOGService start=delayed-auto sc.exe failure FOGService actions= restart/60000/restart/60000/restart/ reset= 120 net start FOGService

@Tom-Elliott

I guess I just see this as a UI quirk. I’ve found typically with radio buttons that are linked its one or the other and not removeable, and for a situation like this would just have a none option rather than be removed.

@Sebastian-Roth

Of course I go back to take a picture to share and it works 100% right away no error… Not sure what happened.

Got it to happen again. And after this I couldn’t even see the nic in the PXE menu. Starting to think this is a machine / usb adapter issue not a FOG issue. Here’s the screenshot anyway:

IMG_3907.jpg

I rebuilt my master and slave from scratch. Everything worked as expected, this topic can be resolved.

Just close it. Maybe I’ll put together a Galera tutorial one of these days for FOG.

@ConJon @jmason As we haven’t heard from other users this being a problem I suspect pretty much all current UEFI firmwares are able to find Windows bootloaders by themselves and I don’t see why we should mess with this if there is no need for 99% of users. I’ll put this to the archive unless I hear otherwise from someone.

If you still see this issue talk to your mainboard manufacturer first to provide an updated UEFI firmware.

@processor I still have not found the time to look into this. Can you check if this is still the case or if replication picked it up?

@Dan_Ansel No problem, there’s so much to think about, it can be hard to figure out what’s going wrong!

@0juke You are more than welcome to help us improve this part of FOG. I don’t think we will find the time to add your suggestions in the near future. Just too many other things on the list.

The problem here is that you have 2 DHCP Servers.

192.168.6.15 and 192.168.6.152

@magikmw Glad to see you found and fixed this. It’s good to know you really know your way around in that network stuff. It’s very hard for us to diagnose and help out with that kind of things.

@Sebastian-Roth yes i checked and now works its fine

@Sebastian-Roth So good news and bad news. The bad news is that I am running a Ubuntu server. Good news is that the failed update appears to have saved me from problems. At least my server still seems to be functional. My other problem(my problem, not FOG problem it turns out, stupid fast boot), is fixed(crossed fingers) and I’m capturing with my 1.5.5 server right now. Guess I’ll wait to try updating again until 1.5.8 comes out. 🙂

Philip

Follow up discussion here: https://forums.fogproject.org/topic/13686/windows-10-deployment-stuck

@dobler555 Any news on this topic?

@zclift15 Any news on this?

@Redbob Any news on this?

The PCAP revealed that there were some left overs from an old software that would open an application on a public network share on boot up of that system. Removing that stuff fixed the issue and fog-client domain join works perfectly fine now again.