@tom-elliott Many thanks!! I used now the internal ip address of the AD server … This was the whole problem.
A vaild domain name here did not work.

Normally this AD server is reachable with this fqdn YYYY.XXXX.com (it’s not the real domain). I can’t type public this domain here for security reasons.

I can now login with users from my AD into FOG.

@jmeyer said in How to Use FOG to PXE Boot MultiBoot 2k10 Unofficial:

chain memdisk iso raw

Just adding a bit of a caveat here.

memdisk is a BIOS boot loader only. There is currently not an equivalent function for UEFI based systems.

The iso image you boot from must be less than 2GB in size (remember 32bit address space) AND the booting computer must have at least 2 times the memory of the 2GB iso to function. So in the case of a 2GB ISO image, your computer needs to have 4GB of RAM.

@MasterOfUs Now that I have had a good sleep I figured that proposing to use SSH is just raising the hurdle once more but not solving the concern. Why? Because some kind of secret (probably SSH key) needs to be included in the FOS inits to authenticate when connecting. Even if this is done properly (random generated key pair) we can not prevent an attacker from loading the FOS init manually and extracting the secret, right?

So making it secure would mean the user needs to enter a connect passphrase manually on each deploy/capture.

@TraverseTheFOG First I suggest you check the free disk space on your FOG server. Connect via SSH and run: df -h

Copy the full output here or take a screenshot and post that here in the forums.

@rodluz Para MAC

@thedark5776 I can read your post in 2 ways. I answered previously in the most common way you ask. If I did not answer your question correctly then clarify if your original disk contains 2 partitions (like C and D) but you only want to deploy the C partition to the target computer).

@thedark5776 Licensing is out of scope in regards to FOG. But you will need to have 1 license for every target computer you deploy an image to. This is not a FOG requirement (because its open source) but your operating system you send to the target computer.

You did not mention the operating system you deploy to the target computer, but if you use MS Windows then you will need an enterprise activation license. The windows OEM license does not support imaging cloning. This is a microsoft EULA issue.

@sebastian-roth Perfect.
I’ll look at getting a test version up and running and see how it goes.
My work has made internet more clunky to get proxies working so I’ll have to test that as well.

@sebastian-roth I figured out how to simplify it using patch yesterday. I will look into the link that you posted.

As you said, probably not something to be merged into the official FOS kernel. I’m guessing that I would not be the only one using FOG that would find this helpful so (unless there is a better way) I’m going to fork the FOS repo and make my changes there. Like I said before, I will write up what I did and try to streamline it as much as possible for anyone to reproduce.

fwiw, there is a script that updates FOG’s IP.
https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP

this will re-write your DHCP config on your fog server too. Should be perfect for this use case.

@tenorio-leandro said in not all images appear:

Is it possible at the time to deploy via pc, not all images appear?

I don’t understand this question. Its not a clear question at all.

If you are a non-native english speaker, please ask the question in your native language so its clear to us what you ask.

Microsoft should consider doing this for FOG as a donation.. .

@george1421 Thank you for your help. I managed to speak with one of the techs from our central IT this morning. He informed me that they block PXE boot on our network. PXE traffic is automatically being filtered and dropped by the switches. I think it is unlikely that they would add my FOG server to the DHCP relay. Which makes sense I was only able to get tcpdump to see the discover traffic when I connected both machines to their own unmanaged switch.

Still not sure why dnsmasq did not respond to the DISCOVER packet. I will try reinstalling the service. Although following this revelation I may just reconfigure FOG to run DHCP and use it on its own isolated network. Thank you!

@sebastian-roth Thank you very much for your answer!! it works perfectly

@george1421 That makes much more sense. I happened to notice the installer mention it will use undionly.kpxe for the Bootfile and wanted to make sure I didn’t somehow configure it to only use that Bootfile. I will look over that wiki article. Thank you for your help!

@olive-tree The issue with WDS/MDT is that the image is purpose built for the target hardware. So the WIM file may not contain the entire image as MDT will add software or drivers based on the target hardware. MDT uses file level cloning where FOG uses block level cloning. Those are two different technologies.

Now you might be able to take a fully deployed MDT image and then sysprep it and recapture it with FOG. In a way that is what I do on my campus. I use MDT to create my golden image and then I sysprep that MDT created image and deploy with FOG. That takes me from about 1.5 hours to build an image with MDT to about a 20 minutes (bare metal to user ready) to deploy with FOG.

@fairoozfarhan dhcp option 66 should be the IP address of the fog server. dhcp option 67 should be the boot file name.

BUT I can tell you that if you are using a firewall dhcp server, some are broken and they will send their IP address to the client for dhcp option 66.
The other problem you run into is when you have both bios and uefi computers on the same subnet. The static dhcp fields will need to be updated to support both hardware types. In this case you can use DNSMASQ to supply pxe boot info to your network. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server
I’m not saying you have to only, if you need to we have options.

@george1421

Ok ! Thank you for the answer 😉