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

@george1421 Thank you! This is all i wanted to know 🙂

@r-pawlowski I would be happy to help in anyway I can. Personally, I deploy a bootmanager (grub2win) and the ipxe.efi file to each machines efi partition. Then I can just change the boot managers default to boot straight to fog. It takes a bit of time to get setup, but I found it to be the most reliable as I then didn’t have to worry as much about the bios settings. Theoretically you can use bcdedit commands to change the boot order to boot to network, but that also differs on different hardware.

I digress though, the easy bit for queueing an image to deploy

Follow the setup instructions for the fog API (involves installing the module from powershell gallery and then inputting your API keys and fog server address) Then make sure the host you’re imaging is assigned the correct image, this can be changed in the API if you need that, but for this quick example, we’ll pretend it’s set correct. For an example, we’ll say the hostname of a computer in fog is ‘test-computer’, so this will find the host in fog, then queue an image to deploy on it right now $hostID = (Get-FogHost -hostname 'Test-Computer').id #create a quick json string, this can also be done in a powershell object and converted, but this is just a quick example. #tasktypeID of 1 is a deploy task, if no runtime/schedule time is specified, it defaults to instant deploy # shutdown = 0 is not scheduling with shutdown # I believe other2 = 0 means not a debug # other4 = 1 means to enable wol # isactive =1 means the task is active $jsonData = "{`"taskTypeID`": 1,`"shutdown`":`"0`",`"other2`":`"0`",`"other4`":`"1`",`"isActive`":`"1`" }"; # make the API call to create the new task for your host New-FogObject -type objecttasktype -coreTaskObject host -jsonData $jsonData -IDofObject $hostId;

Once you have this all setup in a powershell module or script internally, you can get things automated pretty smoothly. It’s meant to be modular so it can be applied to any infrastructure or workflow and built upon.

If you need more help let me know and I’ll see what I can do.

@ookami said in Expand Registration Info:

register a machine without a disk installed

Pretty sure you can create hosts from the web UI, all you need is the MAC address.

As to your other questions, I suppose you’re talking about the IPXE registration, and not the web UI. I don’t think RAM is a supported field, or DIMM slot allocation either, nor specific details about RAM.

What your looking for is extra fields in the database. Those are easy enough to add manually, but having them show up in the UI is a lot more work, and involves PHP as well as JS, and I’d be very little help in that area. My PHP skills are basic at best, and FOG’s PHP is fairly advanced. As to the JS, I’ve got zero experience with it.

@george1421 Thank you for your explanation! This makes sense and I was thinking of that same scenario with having more then one of same cloned disk in the same system. I tested most of our external applications and found no issues including ones that record or reference the UUID of the disk in some way and found no conflicts. As you said, the disk is attached to the “parent” record.

@Sebastian-Roth Thanks for the code reference, this does appear to be the function performing what I am referring to and I appreciate your honesty 🙂

Thank you again to both of you on your input! Tremendously appreciated.
I’ve found this to be a great community and hopefully I’ll be able to be give back in one way or another 😄

@boyan-biandov said in How to PXE boot to a Windows PE ISO:

Has there been any development on the ability to boot into one’s custom WinPE ISO on a UEFI system?

Not booting the ISO directly but if you pull apart the ISO you can pxe boot the wim file with FOG.

@wt_101 said in USB Booting a usb network adapter:

ncm–ecm–axge.efi

I have no idea what that boot loader does. Its a component of iPXE.

So tell me about your dhcp server. What is the manufacturer and model.

The idea is that if we can uniquely identify that usb drive, maybe we can send the proper boot file name. If you are using a windows dhcp server and setup efi policies, that is getting us in the direction. That policy looks to see if the arch value is 0 (bios) or 7 or 9 then its uefi. If we can combine the uefi test with the manufacturer id of the mac address then we could send that alternate boot file name when the target computer is uefi and the mac manufacturer matches. Its easier to do with a linux dhcp server or using dnsmasq as a proxydhcp server.

thanks @george1421 i’ll set up a test configuration according to your recommendation…