@jdakel did u try CCTK by Dell ?
it allows you to modify bios from your chair

@dpullin said in FOG service invalid host:

The issue seems to be when the name in FOG UI doesn’t match the hostname of the machine (because I changed it in the UI after the fact) - this has started to crop up on other machines due to user error (techs giving machines the wrong names before sending them out the door) - then we try to fix it by changing the name in the UI, then it gives the “invalid host” error as described above.

I can’t seem to replicate the issue as described using the following steps - please verify if you do things a different way:

Check fog.log to see communication works fine Make sure AD credentials are set and correct for the test host in the FOG web UI Change Host Name in FOG web UI Wait for machine to reboot Check hostname (Windows GUI as well as CMD -> hostname) and fog.log (see below). ------------------------------------------------------------------------------ --------------------------------HostnameChanger------------------------------- ------------------------------------------------------------------------------ 4/16/2022 7:06:09 AM Client-Info Client Version: 0.12.0 4/16/2022 7:06:09 AM Client-Info Client OS: Windows 4/16/2022 7:06:09 AM Client-Info Server Version: 1.5.9.139 4/16/2022 7:06:09 AM Middleware::Response Success 4/16/2022 7:06:09 AM HostnameChanger Checking Hostname 4/16/2022 7:06:09 AM HostnameChanger Renaming host to Newhostname 4/16/2022 7:06:09 AM HostnameChanger Renaming host inside existing domain binding 4/16/2022 7:06:09 AM HostnameChanger Success, code = 0 4/16/2022 7:06:09 AM Power Creating shutdown command in 60 seconds 4/16/2022 7:06:09 AM Bus Emmiting message on channel: Power ------------------------------------------------------------------------------

Works fine in my test setup. Do you use plugins or other special things in your FOG setup? Other than that I con only imagine is has to do with the wireless MAC you seem to be using. Is this the primary MAC?

That work now, thank you !

hello

we have dell 3540 using UEFI boot ( legacy boot disabled everywhere)

secure boot has to be disabled dhcp is made via pfsense with ipxe.efi master has been made with UEFI ( fog service has to be stopped before sysprep , otherwise bootloop after deploy / don’t know why) STP disabled on every switch

Works fine here (single or multicast)

@george1421 yep! That’s how I have it set up. Works beautifully now

re: bitlocker - yeah, that makes sense regarding mismatched TPM signatures. Luckily I don’t have to worry about that at the moment 🙂

@mmaridev Do you use @JJ-Fullmer’s powershell FogAPI module by any chance? I remember digging through an issue with him that sounds kind of similar and we got to the point where it turned out to be caused by a powershell script he used. Can’t remember all the details anymore.

@dashwell Please use the latest FOS init as posted in your other topic to see if this is still happening.

If it does I would like to see the contents of d1.partitions and d1.minimum.partitions from that image.

@george1421 Our current solution was to isolate the two(technically 3, since the fog server is running in an Ubuntu Virtualbox) to a completely separate domain.

I brought in a spare personal router, hooked the two physical machines up and set the DHCP settings on that. The DHCP problems are no more, for now at least, and whenever necessary, or available, I can always re-bring these two back online after the image capture is done.

Thank’s a lot for for quick response. We’ll test and comme back to you.
Have a good days
Francis

@ayy_nelson @cwu_doug Thanks a lot for your feedback on this. I didn’t know 2008 DFL is an issue. Will keep that in mind.

@george1421

That worked. Thanks!

@viktor said in Echec de boot PXE:

Server IP address is 192.168.70.9
NBP filename is undionly.kpxe
Downloading NBP file …

NBP thread download successfully

OMG, this is why I don’t answer questions late at night. I totally missed what was in front of me. NBP implies uefi firmware, but you are sending undionly,kpxe which is for a bios firmware computer. The uefi firmware will reject that file.

Update dhcp option 67 to ipxe.efi and the vm should boot.

@george1421 OK great, I will deploy it with a batch and see how I get one. Thanks again

@george1421 Hello
I’m not really familiar with wireshark so i send you the pcap, thank you

@M-Gene We have evidence AD joining is working on Windows 10 21H2: https://forums.fogproject.org/topic/15978/windows-10-failing-to-join-domain

@Stuffandsht From what I see in your post you have done a fair amount of testing already. I too find it strange that running your script as SYSTEM works when running it manually but seems to not do the right thing when running it as a snapin.

For debugging I suggest you copy the djoin line and add echo in front of the first one to actually see the full command. As well add output redirection for stdout and stderr to the actual call:

... echo djoin ... >C:\temp\djoin_cmd.log djoin ... >C:\temp\djoin.log 2>C:\temp\djoin_err.log ...

@misterjroc First let me start out by shaming you. Masking a private IP address range doesn’t help us help you. There is no way if I was a hacker to know how to reach a 192.168.x.x subnet from the internet. If you were debugging using a public IP address (as in an internet address then I would suggest masking the address).

Since you mentioned the tftp address is your router/isp router I can make a few guesses.

SoHo routers are broken in that they almost aways give our their IP address as the dhcp next-server address even if they let you define a next-server value (the exceptions I’ve seen are ddwrt/openwrt and pfsense those work correctly). You have 2 dhcp servers on your subnet. One is your isp router and the second one is your 2019 server.

Two routers would explain this condition you explained. You are getting into the iPXE boot loader so your main dhcp server (Windows 2019) IS working because the iPXE boot loader is running, Inside of iPXE it once again issues a dhcp request to find the IP address of what it thinks is the FOG server. In this case your ISP router is returning the query faster than 2019 server. So your router is winning and iPXE tries to connect to your router instead of your fog server.

OK so prove me right or wrong, here is what I want you to do. On a third computer (witness computer) install wireshark. Its probably best of this witness computer is on the same wired network. Use the following capture filter inside wireshark port 67 or port 68. Start wireshark capture, then pxe boot the target computer. You will see a complete DORA cycle (DISCOVER, OFFER, REQUEST, ACK) This will be the pxe rom on the target computer getting the info to load iPXE, then when iPXE starts you will see the DORA sequence again. PXE boot to the error above. Now stop wireshark. If you have one or more OFFER packets those packets come from DHCP servers that heard the DISCOVER packet. If you only have one OFFER packet then we need to dig deeper. I’m thinking you will see two or more OFFER packets. The sending IP address will be listed in the OFFER packet.