Hi all, i have secureboot working with ipxe (FOG) using a self-signed certificate and you do however need to enroll the keys but i have added an .efi program that you can run to automate all this from the pxe boot menu to ease this process.

i’ve been testing it for the last 12 months or so to see if there is any gotchas but none yet and over 80% of our estate have secureboot with ipxe working (7K devices) - only lenovo x1 carbons have been problematic but this appears to be due to poor bios and/or secureboot implementation.

this does mean you have to manage the certificates yourself going forward too as you are essentially taking ownership and provisioning the devices and applying your own PK which means you have to trust 3rd party CAs however the plus side there is no cost involved. i also don’t have assurances how to remotely distribute a renewed certificate when it expires but expiration is 10 years and there is going to be some work needed when microsoft CA expires in 2026.

on first attempt, i hadn’t included microsoft CA so windows os failed to load with untrusted error from secureboot… i loved the irony… i dont trust microsoft either

if anyone is interested i can write up instructions however you have to remember technically this is outside of FOG remit, so support on FOG forums will be extremely limited and unfortunately with 2 jobs i have very little time to spare either.

@ITCC to setup how you want so no image goes across the wan but replication, setup like below (Be mindful you will have no resillience and if JS is busy for example and you want to image a machine at JS it will wait rather than use SS - which by the sounds of things is how you want it to work anyway)

Storage Group Definitions:
Storage Group - SS
Storage Group - JS

Storage Node Definitions:
Storage Node - SS - In Storage Group SS
Storage Node - JS - In Storage Group JS

Location Definitions:
Location SS - Storage Node - SS - Storage Group - SS
Location JS - Storage Node - JS - Storage Group - JS

Image Definitions:
ImageA - Storage Group - SS AND JS
ImageA - Storage Group - SS AND JS
make sure you tick whichever is primary (that you will upload your image to and want replication to come from)

so Location JS will only have Node JS available and vice versa.

You will be utilizing the use of Group to Group Replication which @TomElliott awesomely implemented sometime ago.

Whenever you upload an image, whatever location you choose will be the node it uploads to, just make sure you do it to whichever you set as primary otherwise you newly upload image with be overwritten.

Hope this helps

why would you want to blindly apply windows updates post image anyway? surely you should be going through some form of testing at least…?

maybe that varies in different environments and we have to air on the side of caution because if our systems go down/stop working people start dying… lol

@rmurra81 said in Do windows update on uploded image stored on fog server:

It would be very difficult to inject Windows updates into an image, but what this thread should be talking about is to spin up a VM with those image files. This would allow you to run updates, install programs, maintenance, etc. It seems stupid to me that the conversation didn’t go there. Why would you spend all your resources updating this FOG server software for it only to do windows update? Tom Elliott, that is a waste of time. Deploying an image to a PC and then running updates just to capture it. Just setup WDS and run a VM. This feature already exists and it seems like it wouldn’t be that difficult. Maybe some button to deploy to a VM within the FOG Server.

that’s how you should be building your images… build on VM, snapshot/create checkpoint before sysprep/capture… when you need to apply windows updates to your “image”, revert vm to snapshot/checkpoint - apply windows updates, snapshot again before sysprep/capture etc etc etc…

you’ll have a cleaner image building on VM and you avoid rearm restriction as theoretically your image only ever gets sysprepped once (as you revert to unsysprepped state before applying changes/update)

so that’s not a feature needed in FOG that’s a learning curve or a “suggestion” if you’d like that we need to teach FOG administrators…

“Maybe some button to deploy to a VM within the FOG Server”… that’s what the deploy task button is for unless i’ve been up far too long and i’m reading that wrong, you clearly don’t understand the architecture behind virtualisation if you think that could be implemented so easily. it would kill most environments just trying to implement that and most FOG Servers are being hosted on a VM already so then you’re talking about nested VMs and that’s just the tip of the iceburg on that head ache… can of worms springs to mind just to do something you can already easily and quickly do a thousand different ways as wayne and tom pointed out a few below

Edit: Just read the other thread you’re discussing this - if you mean deploy the image to a vm, you can do that like you would a physical machine, register the VM within FOG and deploy image, do your updates and maintenance etc etc and then capture, don’t think i fully understand your VM Feature request, maybe you could explain better?

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

add this code into /images/postscripts/fog.postdownload

clearScreen;
mkdir /ntfs &>/dev/null
ntfs-3g -o force,rw $part /ntfs
dots "Mounting Device";
if [ "$?" = "0" ]; then
	echo "Done";
	. ${postdownpath}fog.ad
	umount /ntfs;
else
	echo "Failed To Mount Device";
	sleep 30;
fi

apologies both - i could of jumped in sooner to point out about the /fog directory confusion and assisted with the partition code but been swamped as of late but luckily @Tom-Elliott had already sorted partition bit of magic for you guys!

@THEMCV if you do only have dell machines and want to use cab files - you can use cabextract which is built into the FOS.

something like:

cabextract -d /ntfs/Windows/DRV "/fog/Drivers/$osn/${machine}"/*.CAB &>/dev/null;

/ntfs/Windows/Drv - Change to wherever you want your drivers to be extracted to

/fog/Drivers/etc… - Change to match the directory you store the .cab file on the server. i.e. /images/Drivers/E7270-WIN7-A02-8924F.CAB

if you go down the .cab route - use the enterprise cabs as they are tested and put together specifically for image deployment.
http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment

if for whatever reason the cab isn’t sufficient and you need to add drivers, you could incorporate both .cab and folders using both sets of code. if you know what i mean?

as @george1421 pointed out scripts are a lil’ flawed but where written and posted sometime ago and for my own environment at the time and my own postscripts have come a long way since then.

the wiki post would be a very good idea as easier to keep up to date, once that’s done it may be worth changing any old posts with code in, redirecting users to the wiki so they don’t put conflicting or outdated code together. but like @george1421 said, a lot of it is personal preference and there is so many ways of achieving the same thing…

Glad you got there in the end though

then create a new file in the same location as fog.postdownload called fog.ad and you can edit the sysprep file however you would like - this changes the unattend.xml AFTER the machine is imaged and pulls the info for that host from fog, making the unattend.xml unique and set with the info for that host.

using the below you could use sed command to edit the local admin password set in your unattend.xml to match what you want it to be, just follow how below works.

#!/bin/sh

hostadpwd="password-to-join-domain";
panther="/ntfs/Windows/Panther/unattend.xml";
if [ -f "$panther" ]; then
	unattend="/ntfs/Windows/Panther/unattend.xml";
else
	if [ $osid == "9" ]; then
		unattend="/ntfs/Windows/System32/Sysprep/unattend.xml";
	else
		unattend="/ntfs/Windows/System32/sysprep/unattend.xml";
	fi
fi

if [ -f "$unattend" ]; then
	dots "Writing Computer Name";
	sed -i "/ComputerName/s/*/$hostname/g" $unattend
	echo "Done";
	dots "ComputerName Set To";
	echo $hostname
	dots "Set PC To Join The Domain";
	if [ "$addomain" != "" ]; then
		sed -i "/<JoinWorkgroup>/d" $unattend
		sed -i -e "s|<Password></Password>|<Password>${hostadpwd}</Password>|g" \
			-e "s|<Username></Username>|<Username>${addomain}\\\\${aduser}</Username>|g" \
			-e "s|<MachineObjectOU></MachineObjectOU>|<MachineObjectOU>${adou}</MachineObjectOU>|g" \
			-e "s|<JoinDomain></JoinDomain>|<JoinDomain>${addomain}</JoinDomain>|g" $unattend
		echo "Done";
	else
		echo "Skipped";
	fi

fi

unfortunately i do not have time to write up in detail step by step instructions but this is how i’ve done it:

follow this brilliant guide:
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html

including “Securing Multiple Computers” section, once you’ve generated the “LockDown.efi”

copy LockDown.efi to ipxe folder on fog server (i’ve renamed mine to EnrollKeys.efi) then add the option to PXE Menu.

then sign your init, bzimage and any other bzimage version you may use with your new cert you’ve generated above - something like this:

cd /var/www/html/fog/service/ipxe
mv bzImage bzImage-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage bzImage-unsigned
mv bzImage32 bzImage32-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage32 bzImage32-unsigned
mv bzImage41713m bzImage41713m-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage41713m bzImage41713m-unsigned

just remember to re-sign any init/bzimage when upgrading kernel/fog.

so the process is when you get a new machine put secureboot into user/setup mode then boot to pxe and run “Enroll Keys” option on pxe menu which will set secureboot keys accordingly, the beauty of this is you will also only need to do this once on a machine and then you will have secureboot on working with fog, when you come to reimage that same machine secureboot will already be setup.

the only caveat i would say is i don’t know what the behaviour is going to be when the Microsoft UEFI CA expires in 2026 - as you’re now effectively managing your own secureboot keys - you will need to update and manage the CAs in the db. this would normally be managed by microsoft updates/OEMs i assume.

in my research i found, that cortana/windows search breaks if you make any customization to the start menu - test my theory build another image but leave start menu as default. making all other custom changes + unattend.xml or whatever you used on your image that has broken cortana/windows search

you definitely don’t want to put all your drivers onto image not only would it be needlessly bloated in size, like you’ve pointed out - you’d do well to get them all installed and working

just repeating what George has said below, that is the cleanest and most reliable method below - just heads up, watch out for windows 10 driver changes (when you come to do windows 10)

don’t be put off by the postscripts method, it’s easier than it looks - just take your time reading the write ups - @george1421 has done some pretty clear and indepth ones in all honesty and we can always assist you if you get stuck

@plegrand yes i would wait, i wouldn’t recommend updating your production server.

if you don’t rely on the LDAP plugin then everything else is functioning as it should but i still wouldn’t recommend it in a production environment.

@Sebastian-Roth Done I haven’t had chance to look into it any further but it’s the initial bind function that fails.

https://www.php.net/manual/en/doc.changelog.php

just some initial testing in my usual environment setup (using 1.5.10.5, location, task state & ldap plugin + FOG running in SSL):

only issues so far i’ve come across is with the ldap plugin (confirmed php8.2-ldap installed and php module enabled on bookworm):

Got error 'PHP message: PHP Warning:  Undefined property: stdClass::$DN in /var/www/html/fog/lib/plugins/ldap/pages/ldapmanagementpage.class.php on line 114', referer: https://image-server.ad.wmas.nhs.uk/fog/management/index.php?node=ldap

changing line 114 from ‘searchDN’ => $LDAP->DN, to ‘searchDN’ => $LDAP->SearchDN, resolves this warning.

however getting http error 500 with same config that was working on bullseye (php7):

[Mon Jun 19 00:56:58.958186 2023] [proxy_fcgi:error] [pid 319012] [client 192.168.156.14:53122] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught TypeError: ldap_unbind(): Argument #1 ($ldap) must be of type LDAP\\Connection, null given in /var/www/html/fog/lib/plugins/ldap/class/ldap.class.php:124\nStack trace:\n#0 /var/www/html/fog/lib/plugins/ldap/class/ldap.class.php(124): ldap_unbind()\n#1 /var/www/html/fog/lib/plugins/ldap/class/ldap.class.php(235): LDAP->__call()\n#2 /var/www/html/fog/lib/plugins/ldap/hooks/ldappluginhook.hook.php(126): LDAP->authLDAP()\n#3 /var/www/html/fog/lib/fog/hookmanager.class.php(86): LDAPPluginHook->checkAddUser()\n#4 /var/www/html/fog/lib/fog/user.class.php(139): HookManager->processEvent()\n#5 /var/www/html/fog/lib/fog/user.class.php(226): User->passwordValidate()\n#6 /var/www/html/fog/lib/fog/fogbase.class.php(2469): User->validatePw()\n#7 /var/www/html/fog/lib/pages/processlogin.class.php(151): FOGBase::attemptLogin()\n#8 /var/www/html/fog/management/index.php(31): ProcessLogin->processMainLogin()\n#9 {main}\n  thrown in /var/www/html/fog/lib/plugins/ldap/class/ldap.class.php o...', referer: https://image-server/fog/management/index.php

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

unfortunately i do not have time to write up in detail step by step instructions but this is how i’ve done it:

follow this brilliant guide:
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html

including “Securing Multiple Computers” section, once you’ve generated the “LockDown.efi”

copy LockDown.efi to ipxe folder on fog server (i’ve renamed mine to EnrollKeys.efi) then add the option to PXE Menu.

then sign your init, bzimage and any other bzimage version you may use with your new cert you’ve generated above - something like this:

cd /var/www/html/fog/service/ipxe
mv bzImage bzImage-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage bzImage-unsigned
mv bzImage32 bzImage32-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage32 bzImage32-unsigned
mv bzImage41713m bzImage41713m-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage41713m bzImage41713m-unsigned

just remember to re-sign any init/bzimage when upgrading kernel/fog.

so the process is when you get a new machine put secureboot into user/setup mode then boot to pxe and run “Enroll Keys” option on pxe menu which will set secureboot keys accordingly, the beauty of this is you will also only need to do this once on a machine and then you will have secureboot on working with fog, when you come to reimage that same machine secureboot will already be setup.

the only caveat i would say is i don’t know what the behaviour is going to be when the Microsoft UEFI CA expires in 2026 - as you’re now effectively managing your own secureboot keys - you will need to update and manage the CAs in the db. this would normally be managed by microsoft updates/OEMs i assume.

@eduardotseoane

unfortunately i do not have time to write up in detail step by step instructions but this is how i’ve done it:

follow this brilliant guide:
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html

including “Securing Multiple Computers” section, once you’ve generated the “LockDown.efi”

copy LockDown.efi to ipxe folder on fog server (i’ve renamed mine to EnrollKeys.efi) then add the option to PXE Menu.

then sign your init, bzimage and any other bzimage version you may use with your new cert you’ve generated above - something like this:

cd /var/www/html/fog/service/ipxe
mv bzImage bzImage-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage bzImage-unsigned
mv bzImage32 bzImage32-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage32 bzImage32-unsigned
mv bzImage41713m bzImage41713m-unsigned
sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage41713m bzImage41713m-unsigned

just remember to re-sign any init/bzimage when upgrading kernel/fog.

so the process is when you get a new machine put secureboot into user/setup mode then boot to pxe and run “Enroll Keys” option on pxe menu which will set secureboot keys accordingly, the beauty of this is you will also only need to do this once on a machine and then you will have secureboot on working with fog, when you come to reimage that same machine secureboot will already be setup.

the only caveat i would say is i don’t know what the behaviour is going to be when the Microsoft UEFI CA expires in 2026 - as you’re now effectively managing your own secureboot keys - you will need to update and manage the CAs in the db. this would normally be managed by microsoft updates/OEMs i assume.

@ProfDrSir you will also get this behaviour if the permissions and/or ownership on the image share are incorrect. was the error “segmentation fault. possibly due to run of disk storage?”

if so, on server/node you’re capturing the images to

try:

chown -r fogproject.root /images

or

chown -r fog.root /images

dependant on what version of fog you are on.

then re-run capture

what if you cleared the template but not the data?

@Greg-Plamondon apologies i thought this was part of main code.

save below code in /var/www/html/fog/lib/hooks/removehosteditgen.hook.php

this is just to get you going, change data and template number to the right id that is relevent for what you want to remove and remove/comment out what you don’t want removing. read up about hooks on wiki. if you get stuck i’ll happily assist when i can to meet what you originally asked for etc but it’s worth you having a go yourself to understand how hooks function.

hope this helps

<?php
class removehosteditgen extends Hook {
    public $name = 'removehosteditgen';
    public $description = 'Remove unused fields in host edit general';
    public $author = 'Rowlett';
    public $active = true;
    public function __construct()
    {
        parent::__construct();
        self::$HookManager
            ->register(
                'HOST_EDIT_GEN',
                array(
                    $this,
                    'hostData'
                )
            )
			->register(
                'SUB_MENULINK_DATA',
                array(
                    $this,
                    'RemoveSideNotes'
                )
            )
            ->register(
                'SUB_MENULINK_DATA',
                array(
                    $this,
                    'RemoveDelete'
                )
            );
    }
	public function HostData($arguments) {
		if ($_REQUEST['node'] == 'host' && (($_REQUEST['sub'] == 'deploy') || ($_REQUEST['sub'] == 'edit') || ($_REQUEST['sub'] == 'membership'))) {
			unset($arguments['data'][5],$arguments['template'][5]);
			unset($arguments['data'][8],$arguments['template'][8]);
			unset($arguments['data'][9],$arguments['template'][9]);
			unset($arguments['data'][10],$arguments['template'][10]);
			unset($arguments['data'][11],$arguments['template'][11]);
		}
    }
	public function RemoveSideNotes($arguments) {
		if ($_REQUEST['node'] == 'host' && (($_REQUEST['sub'] == 'deploy') || ($_REQUEST['sub'] == 'edit') || ($_REQUEST['sub'] == 'membership'))) {
			unset($arguments['notes']['Host']);
			unset($arguments['notes']['MAC']);
			unset($arguments['notes']['Image']);
			unset($arguments['notes']['O/S']);
			unset($arguments['notes']['Last Deployed']);
			unset($arguments['notes']['Primary Group']);
		}
    }
	public function RemoveDelete($arguments) {
		if ($_REQUEST['node'] == 'host' && (($_REQUEST['sub'] == 'deploy') || ($_REQUEST['sub'] == 'edit') || ($_REQUEST['sub'] == 'membership'))) {
			if (!in_array(self::$FOGUser->get('type'),array(0))) {
				unset($arguments['submenu']['?node=host&sub=membership&id='.$_REQUEST['id']]);
				unset($arguments['submenu']['?node=host&sub=delete&id='.$_REQUEST['id']]);
				unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-printers']); 
				unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-service']);
				unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-powermanagement']);
				unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-virus-history']);
				unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-login-history']);
				unset($arguments['submenu']['?node=host&sub=edit&id='.$_REQUEST['id'].'#host-login-history']);
				
				
			}
		}
    }
}

Hi all, i have secureboot working with ipxe (FOG) using a self-signed certificate and you do however need to enroll the keys but i have added an .efi program that you can run to automate all this from the pxe boot menu to ease this process.

i’ve been testing it for the last 12 months or so to see if there is any gotchas but none yet and over 80% of our estate have secureboot with ipxe working (7K devices) - only lenovo x1 carbons have been problematic but this appears to be due to poor bios and/or secureboot implementation.

this does mean you have to manage the certificates yourself going forward too as you are essentially taking ownership and provisioning the devices and applying your own PK which means you have to trust 3rd party CAs however the plus side there is no cost involved. i also don’t have assurances how to remotely distribute a renewed certificate when it expires but expiration is 10 years and there is going to be some work needed when microsoft CA expires in 2026.

on first attempt, i hadn’t included microsoft CA so windows os failed to load with untrusted error from secureboot… i loved the irony… i dont trust microsoft either

if anyone is interested i can write up instructions however you have to remember technically this is outside of FOG remit, so support on FOG forums will be extremely limited and unfortunately with 2 jobs i have very little time to spare either.