Best posts made by Lee Rowlett

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

@Raj-G under <settings pass=“specialize”>

<component name=“Microsoft-Windows-UnattendedJoin” processorArchitecture=“amd64” publicKeyToken=“31bf3856ad364e35” language=“neutral” versionScope=“nonSxS” xmlns:wcm=“http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>
<Identification>
<JoinWorkgroup>Workgroup</JoinWorkgroup>
<Credentials>
<Password></Password>
<Username></Username>
</Credentials>
<JoinDomain></JoinDomain>
<MachineObjectOU></MachineObjectOU>
</Identification>
</component>

the above is for 64-bit… if you’re ever unsure use WAIK to generate your unattend file for you if you don’t feel comfortable doing it manually

@george1421 I’m pretty sure from when we use to have HP’s that the first partition was a system recovery partition which when browsing contained snapshot of OS files so would confirm your theory!.. Slightly off topic but line 27 in fog.postdownload got a typo, ntf should be ntfs

@Robx64 This is already possible with hooks, for example in the hooks folder (webroot/lib/hooks) edit AddHostModel.hook.php and change it from public $active = false; to public $active = true;

albeit that will be the model but you can do the same for brand if needs be. this will add model in list all hosts view and is also searchable and can be sorted etc…and if you used the new search filter in model/brand field for just for example Samsung, it will display just the samsung devices again can even sort the filtered results.

Hope this helps

@Alex-Grier we have multiple sites across the UK utilizing the Multiple TFTP servers, Location Plugin (where you can also specify that the node is TFTP if you do not want to use multiple tftp servers) and imaging is as quick on remote sites as it is local (since Junkhackers speed increases - 1GB LAN 14.68gb/min averaging out at 8.58gb/min!!) and images sync pretty quick thanks to Tom’s awesome addition to the replication allowing multiple streams and you can also control the bandwidth by adding bandwidth limits.

@Arrowhead-IT certainly a nice clean approach… glad you got it figured out! and thanks for sharing with the community… i’m sure it’ll become useful as people start to move over to win10.

we have it working here with Windows DHCP 2012 - as Junkhacker said really is simple process just create the vendor class then setup the DHCP policy and specify bootfile (option 67 and don’t need to specify option 66 in the policy as it will pick this up from already defined option in the scope)

quickest fix rather than re-installing everything is: on the server rename /var/www/fog/lib/plugins/LDAP to something else like: LDAP1

this will essentially stop the LDAP Plugin “loading”

now you have access back - login to the GUI, deactivate/remove the LDAP plugin (under installed plugins) then rename /var/www/fog/lib/plugins/LDAP1 back to LDAP

if you want to try again and re-check your setting you can now enable LDAP plugin again and if it fails follow the process above again to regain access…logs will be your friend here to figure out what’s wrong

@Bob-Henderson DevicePath Registry wont work with Windows 10 - im sure its mentioned in links george has already posted

as Wayne said it’s not built-in oob but it’s easier to implement, you can even use postscripts which is very powerful - only restriction is your creativity

https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins

postscripts once setup, its literally the case of dropping drivers onto server, you could even setup permissions and map drive onto windows machine so you can “inject” there without even needing to go on the server (or give engineers permission to whole server)… pretty much what ur asking for but rather than through web interface, its network share