Organization Name: Vistex, Inc.
Location: Corporate Office - Hoffman Estates, Illinois, USA
Approximate Number of systems: 1600 laptops/75 desktops
How long: Since 2017
12 Satellite Offices Worldwide each running a FOG server locally (VM)
@fry_p for assurance, FOG still works with windows 11 and it also works on hardware devices that are NOT supported by Microsoft, your image will still deploy, complete and be functional on these devices albeit out of support from a Microsoft perspective but if secure boot becomes compulsory for all your devices then yes, you have to consider the challenges in managing your own secureboot PKI for FOG but Windows 11 should not be a reason to consider an alternative.
I’m aware that the power of FOG is in the multicast deploy. But I have to say that I tested it with 25-30 capture tasks in parallel, and if you have the hardware+infrastucture, it works like a charm
I already have the registrations, image definitions, groups etc., but I won’t do it on scheduled basis, only on manual basis.
My only problem is the lot of clicks which I have to do, if I want to do it manually:) That’s why I asked this question here.
I will have a look at the Powershell API, it will probably/hopefully solve my problem
We have an “easy” solution for this. We are using a NAS (a Syno in our case) to store the images, and we enabled the recycle bin. When the image is overwritten by FOG, the old one goes in to the recycle bin of the Syno (#recycle). Depending on the filestore size(we have around 32TB), number of hosts, size of the images and the size of the recycle bin, you can have the “history” for a few days.
The images are renamed in the #recycle of the Syno(e.g. d1p4_1.img or d1p4_5.img) and if you need an older image, you just copy it back, and rename it.(e.g. d1p4.img )
We can go back in this way, for 5-6 copies, in your case it would be 5-6 days.
I hope it helps.
Where I also see value in this is if someone wanted to hard drive boot into iPXE then from iPXE into the hard drive or FOG without using PXE booting. Instead of a usb drive, everything could happen off the efi partition on the local hard drive. It would not solve the secure boot part of it, but its an option.
Also lets say someone wanted to setup a preboot menu (such as for dual booting) using refind. Your idea could be tweaked slightly to boot into refind menu manager and then pick to boot windows, linux or something else from the refind menu. There are a number of options this method opens up. Again, well done!
@george1421 I just tested it out on a PC outside of our IT vlan with success. I hard coded it already, but I have a habit of not disclosing our IP addresses even if they’re private. I get the Press ESC to show the menu option for one second, then it boots to the hard drive. Now I took the modified bootx64.efi from my usb drive and copied it to the Windows EFI partition, replacing the existing one (renamed the old to bootx64.efi.bak), made sure that the UEFI is pointing to the file, and now the PC boots the fog process without USB.
@george1421 well, I am excited to say that it is working. I literally just readded what was already added, and re-tested. Could have been gremlins or lack of sleep, whatever the case, I am about to capture my image, and do a test deploy. I will ping you back shortly and you can close this as solved I do believe.
Thank you so much for the assistance. Ping me anytime you need a tester.
These are the words I was looking for to give a direction. mdraid can be used for more than just the intel fake raid as you referenced previously.
Yes FOS linux (the engine that interacts with the target computer to capture and deploy images) can interact with a software raid.
the same rules for FOG imaging as with clonezilla. If the software raid doesn’t exist you must create it before you can image it. You could test to see if it exists in a FOG post init script, If your deployment mode is download then you could create a bash script to create the array. Post init scripts are executed just after the FOS OS inits and before any imaging begins. The tutorial you referenced before lays out all of the bits you need, just in this case you are not setting up the intel fake raid configuration.
@sebastian-roth 1.5.9. What is also strange about how FOG behaves across subnets is the USB boot method. I’ve explained in another post about how booting from USB on the same subnet and/or same switch stack on my floor will not prompt me to enter the tftp server but booting from a completely different vlan or subnet physically outside of our own network will prompt for it. See this line in the ipxescript:
@jmeyer Having a FOG server with a dual nic is a standard and supported configuration for installing FOG.
There are a few things you need to know/do before installing FOG.
Know the linux kernel names of your network interfaces. You can see this by using the following command ip a s Identify the name of your business network interface and your imaging network interface. Document these names.
Make sure your imaging network interface is configured for a static IP address. FOG does not like having the imaging network interface IP address changing once FOG is installed.
Make sure your business network interface has a default route defined so that it can get to the internet. Confirm that your fog server has internet access.
Make sure your imaging network interface does not have a default route defined.
Now use the git method to download the installer files onto your FOG server.
Install FOG. During the installation process you will be prompted for the linux name of your imaging network interface. Key that in when requested. You will also be prompted to if you want to install a dhcp server. Answer yes to this. The fog installer will only bind the dhcp server to the imaging network interface leaving your business network interface alone during the installation of FOG. There will be no conflicts on the business side since fog will only focus on the interface you said that is your imaging network.