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

@littleman1234 Well that’s one way to create a golden image. There are a few things I probably would do differently to make things go smoother and repeatable every time the golden image needs to be recreated (as each new windows 10 release is released).

How about building your image using a VM? That way you get a hardware agnostic mother image. How about using MDT to automate the Golden Image creation. Use the light touch method of image deployment or if you are old enough the Ron Popeil “set it and forget it” method. In this approach you automate the windows 10 image build, install windows updates, install any global applications, make any windows settings (understand that windows 10 will reset anything to do with user profiles in sysprep) and prepare the system for sysprepping. Just a few dos and don’ts
3.1 DO NOT let the computer connect to the internet, also set windows update to only talk to wsus server and not get updates from other windows 10 computers (i.e. turn off delivery optimization).
3.2 DO NOT connect the computer to AD (ever before sysprepping)
3.3 DO NOT install programs that are unique guid based before image capture. This would be programs like enterprise antivirus or serialized applications. Use the setupcomplete.cmd batch file to do any post image deployment customizations. This is the only way to undo some of the things microsoft reset when sysprep is run. Run sysprep with a customer answer file and power off the computer. Capture with FOG Deploy with FOG If you want hardware specific drivers pushed out you can do that with a fog post install script. And then have the setupcomplete.cmd file run the pnputil command to load them into windows during OOBE/WinSetup.

Using the above process I can build a new windows 10 image from dvd in about 50 minutes. Actual hands on time is about 7 minutes from powering on the computer to manually running the sysprep image and powering off the vm at the end. The 50 minutes includes installing 8 common company wide applications as well as windows updates in an automated manner.

Now with that said it did take me about 3 days when I first started working with MDT to get what I wanted as in a solid golden image. So its not just turn MDT on and it spits out an image. There is real work involved with setting it up the first time.

BUT I have to say what ever method works for you is OK. The double sysprep is not necessary in my opinion. Also I’ve never had a good image if I let the computer connect to AD. Doing so tattoos the golden image with AD settings, so I would avoid it until you have the golden image deployed to the target computer.

@migsterzs Can you please post your fog-client log here so we see the actually calls and might be able to help.

@markg said in SSH login while imaging:

I’ve no problem with them all having the same password so that was really easy

Just understand that the password you set will not be persistent in that once FOS Linux reboots it will go back to its default password since FOS Linux itself is not persistent or has any persistent storage. You can surely do what you need with a post init script. We also use post init scripts to setup specific hardware/software combinations like software raid solutions and such before imaging can begin.

@Fogger2021 Sure this is an issue caused by FOG? Please take a picture of the error on screen and post that here in case the answer to my question is a yes.

@kayotte said in Lenovo Thinkpad E14 Gen 2 Issues:

I noticed that now deploying old images on old laptops is also having this same problem not joining the domain. Is it possible that the fog update I ran could’ve changed something?

It’s probably best you open a new topic for this as it doesn’t seem to be related to the issue you had before. Please grab the fog-client log file (C:\fog.log) and post that (upload to a file share). I am pretty sure we’ll find why it doesn’t join in there. As well you might also add more information on details like sysprep or what else you do to prepare your image.

@blu3h4t I see a lot of references here, but I’m not sure what your problem is.

I can tell you from the start that FOG doesn’t support secure booting (generally). To image with FOG you need to have secure boot disabled.

So if you are having a secure boot processing issue inside windows that isn’t a FOG thing.

@jclumbo33 said in Can't get UEFI to PXE boot:

You are correct, the VLAN that it works on uses a /16 subnet. That’s interesting, so we could potentially be screwed without redoing our network then?

I am not saying your network is at fault. I might be partly causing what you see but in fact it would be a firmware issue. Before you even think about redoing your network I suggest you setup a test VLAN where you can try out if non-default subnet masks are actually causing this problem.

Here’s an idea of maybe a workaround? Our fog server is running in Hyper-V. If I add a NIC to the VM and put it on each VLAN we need, then point the DHCP options to the new IP address on the same VLAN, would that potentially act as a work around? And is that even possible to configure fog with multiple NICs like that? Just a thought.

Not a good idea. FOG needs a specific network interface and IP to be able to properly work.

@gooses ok a couple of things here.

WDS uses proxydhcp requests. The is only relevent if your wds server is sending this boot information to your fog environment. This would be managed by your dhcp-helper service on your subnet router. If you are pxe booting into FOG OK then you can ignore this bit, I’m only posting it because I have seen conflicts with wds/sccm/fog in the same environment. This is because proxydhcp overrides dhcp option 66 and 67.

Now to pxe boot bios based computers you would setup dhcp option 67 to be undionly.kpxe. For uefi systems you would setup dhcp option 67 to be ipxe.efi or snponly.efi. You can not boot a bios based computer with a uefi boot loader, the same is true for booting a uefi based computer with a bios boot loader (which i’m guessing is the root of your issue).

The FOG Project also has a wiki page that describes how to configure a windows 2012 or later dhcp server to support dynamic pxe booting of both uefi and bios based computers. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

The other option is to install dnsmasq on your fog server and let the fog server send out pxe boot info (only) on your imaging network. In this role your main dhcp server still issues IP addresses, just the pxe boot info comes from the fog server: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server One possible use case for dnsmasq is if you have a dhcp server that can’t be modified or one that doesn’t support dhcp dynamic pxe booting.

@sebastian-roth Hi there
we’ve done some testing and found that non resizeable seems to move between different size disks and puts the partition size back to 200gb

i think this should do the trick