@Piplup said in Need urgent help on joining a domain automatically after installation:

Thank you, but Christ, that’s a lot.

Its not bad if you build it up, start with the basics and add on.

I’d create an InstallUser for the AD with limited rights, which will be automatically joined to the Domain via a fixed entry in the “unattend.xml”. (?) Software will already come preinstalled with the image. From there on, the User manually Signs Out and Signs In via his given AD credentials.

Yes that is how we do it. Here is an example of an sanitized version of our unattend.xml. https://forums.fogproject.org/post/87392 The point of the tutorial link I provided before was to show you if you have text in your unattend.xml file you can “tweak” it at deploy time. Its really NOT that hard. The bit I didn’t show you was the complete working model: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed This is the full working postinstall script it does more than what you need at the moment. The script you are interested in is fog.updateunattend

Doesn’t an Active Directory Domain join require Administrator privileges from the Domain Controller in the first place? Wouldn’t I just create a security vulnerability…? If you have experience in this, please share your advice.

Yes and no. Yes you need an elevated account but you can restrict that account to only add computer to ou. Its been a while since I set that up but I know with advanced acls you can restrict that account to only the task at hand. Also if you use the WAIK toolkit you can encrypt the password in the unattend.xml file so it can’t be hacked easily. Lastly in your setupcomplete.cmd batch file, you will have that nuke any unattend.xml file or another other setup files that are used during OOBE/WinSetup.

@Sebastian-Roth Thank you for your feedback! I found the solution the dnsmasq file had just the ip of the server in dhcp-range without the subnet. So I adjusted the line dhcp-range=192.168.0.23,proxy to dhcp-range=192.168.0.23,proxy,255.255.254

Thanks for the feedback, sorry for my late response.

@ethanxp2 said in FOG Issues with HP EliteBook 735 G6:

This morning at 10am, for some reason, you can no longer deploy to any of these laptops.

Dell Latitudes seem to image okay, HP 735 are a no go.

and it won’t pxe boot again until you reset the BIOS.

get stuck where they try and PXE boot … Initializing PXE boot

The relevant and somewhat bits I see.

Someone random thoughts…
So is it time of day based, where if you reset the clock on the FOG server and pxe booting computers every things works?

FOG is still imaging because the Dells work. So we can probably rule out the FOG server.

What does resetting the BIOS have any impact here. FOG doesn’t touch the bios on any brand computer. It simply doesn’t have the capabilities.

Is it Initializing ipxe devices… where it gets stuck? Having clear screen shots of the errors is helpful in setting the context of the problem.

We are at the iPXE stage of booting so the issue isn’t with the FOG server or the FOS Linux cloning engine (kernel) so these can be ruled out for now

Specific questions…

Has the firmware (bios) been updated on these computers to the latest release?

What happens when you reset the firmware back to factor defaults?

What version of FOG are you running?

Are these computers running in bios (legacy) or uefi mode? Since they seem pretty new they may be uefi only.

It is already solved forgot to turn on the plugin.

@george1421

I did it !!

So I basically made a Frankenstein’s monster version of my image.

As I’ve stated in my last comment, I had an issue where the windows drive did not have the same partition number.

I created a new legacy windows 10 VM, with a smaller C Drive than I created the very first time I worked on that image. I converted that installation into UEFI.
So now my newly installed win10 and my oversized image have the exact same disk structure.

I deployed the partition containing all my data onto the new VM, and I had an issue where the UEFI boot was broken.

I used the tools in the installation media to repair the EFI partition. I used diskpart to assign a letter to the EFI partition, exited diskpart and ran this command :

bcdboot C:\Windows fr-fr /s B: /f

Windows booted.
Now I’m capturing the image and I’ll deploy it to make sure it’s working fine
Thanks for all the help and ideas!!

Regards,
Dan

@AxeMeAQuestion22 said in Kernel Update Issues:

Host: 172.16.20.19, Username: fogproject

Are you able to login to your FOG server via FTP using these hostname and IP?

@Sebastian-Roth Thank you so much! You save my life (almoste 😉 ) It was about ipxe.efi, I have change to realtek.efi in DHCP and now it work fine. Nice work thank you ^_^

@george1421 When the user gets the computer, it boots into Windows. But, it doesn’t just boot directly into Windows. It will go through a setup process before it hits the login screen with no user input required, just a network connection (preferably on our network for domain join). This process includes adding the machine to the domain, creating local user accounts, etc. Once the user logs in, a few other programs will load. But, for all intents and purposes, the machine is ready to go when the user gets to the log in screen.

So, my thinking is similar to yours in that I should be able to run FOG to capture what is there before it does any of the initial set up and use that on every machine without worrying about service tags. Admittedly, I’m not completely in the know on the Dell boot process with our image since I’ve not worked on that part of the imaging and will need to talk to the people who do. But, again, like you said, it seems like it shouldn’t capture that service tag until it goes through OOBE/Winsetup, thus getting it before booting the first time should work.

I’ll talk to the head of that team on Monday and keep you updated.

@Trev-lchs Thanks Tom, yea i did get a bit ahead, but time is a bit against me today, you know how it is, I will upgrade next week thanks for all your help.

@Carbonnier-Alexandre Look at the chat bubble at the top of the forum. I have some questions I don’t want to make public.

@TBCS ok good to know thanks.

@fox134 Have you restarted your FOG server yet?

@george1421 Ubuntu 20.04

You didn’t mention any baseline numbers of what you are seeing today with imaging on a 10GB network.

In my office we have a 10G core network with 1GbE going to the communication closets. I get between 13 and 15 GB/min (single unicast) transfer rates to modern target computers. On a well managed pure 1GbE network you should be seeing about 6GB/min (single unicast) transfer rates. I have not tested transfer rates on a pure 10GbE network, but I suspect the bottleneck will be in the disk controller on the server or the VM itself and not the network.

@george1421 Thank you! I have already requested that this configuration be done in PfSense. They haven’t implemented it yet, but managed to boot legacy. It was an option in the setup that was missing to allow legacy boot.

The option ‘Sistema Operacional Selecionado’ must be changed to Windows 7 or other.

I leave it registered here in case anyone comes across this same type of configuration.

link text

@NuTech3 said in UEFI secure boot off not working with DDWRT:

Does the Fog Server need to operate as the DHCP Server?

No fog does not need to operate as a dhcp server. BUT if you did install the dhcp server as part of the FOG install, then there would be no need for dnsmasq since the isc-dhcp server that fog uses is preconfigured to support both bios and uefi systems.

DNSMASQ has several modes of operation, but if you use my config file from the tutorial exactly DNSMASQ will operate in a proxydhcp mode. In this mode it supplements the main dhcp server with pxe boot information only. We will typically use dnsmasq running on a fog server when the main dhcp server is either incapable of sending pxe boot information (as in some soho routers) or the dhcp server is unmodifiable for some reason not related to FOG.

The interesting aspect of using dnsmasq on the fog server is that if the fog server is powered off so is dnsmasq. With dnsmasq off there is no chance of being directed to a server that is not powered on.

@awellis i see that you’ve solved the problem, can you share the solution, because it seems to me that i have the same thing.

Yep, that was it 🙂 I searched and searched yesterday, but couldn’t find anything that specifically applied 🙂

Anyways, mental note, delete recovery partition after Windows 10 is installed 🙂

Great forum, glad I was able to find a solution.

Quintin