This guide explains how to fully back up an older FOG server and restore it to a freshly installed server – especially for installations using HTTPS communication between server and clients.

️ Note:

• Modern FOG versions only allow TLS 1.2.
• Older Windows FOG clients may not connect anymore → update required!

1. Create backup from the old FOG server

In the old FOG web interface:

FOG Configuration → Configuration Save → Export Database → Export
➜ Save the SQL backup

Backup the SSL certificates:

sudo bash -c '
set -euo pipefail

DEST="/root/fogcerts"
mkdir -p "$DEST/CA"

echo "[1/5] Collecting files …"
# Collect mandatory files (if present)
cp -a /opt/fog/snapins/ssl/.srvprivate.key            "$DEST/"           2>/dev/null || true
cp -a /opt/fog/snapins/ssl/CA/.fogCA.key              "$DEST/CA/"        2>/dev/null || true
cp -a /opt/fog/snapins/ssl/CA/.fogCA.pem              "$DEST/CA/"        2>/dev/null || true
cp -a /opt/fog/snapins/ssl/CA/.fogCA.srl              "$DEST/CA/"        2>/dev/null || true
cp -a /var/www/fog/management/other/ssl/srvpublic.crt "$DEST/"           2>/dev/null || true
cp -a /var/www/fog/management/other/ca.cert.pem       "$DEST/"           2>/dev/null || true
cp -a /var/www/fog/management/other/ca.cert.der       "$DEST/"           2>/dev/null || true

# Optional helpful templates/CSR (if present)
cp -a /opt/fog/snapins/ssl/ca.cnf                     "$DEST/"           2>/dev/null || true
cp -a /opt/fog/snapins/ssl/req.cnf                    "$DEST/"           2>/dev/null || true
cp -a /opt/fog/snapins/ssl/fog.csr                    "$DEST/"           2>/dev/null || true

echo "[2/5] Hardening permissions …"
chown -R root:root "$DEST"
chmod 700 "$DEST"
[ -f "$DEST/.srvprivate.key" ] && chmod 600 "$DEST/.srvprivate.key"
[ -f "$DEST/CA/.fogCA.key"   ] && chmod 600 "$DEST/CA/.fogCA.key"

echo "[3/5] Listing content …"
ls -lah "$DEST" || true
ls -lah "$DEST/CA" || true

echo "[4/5] Creating checksums …"
( cd "$DEST" &&   find . -type f \( -name "*.key" -o -name "*.crt" -o -name "*.pem" -o -name "*.der" \) -print0   | xargs -0 sha256sum > SHA256SUMS.txt )

echo "[5/5] Creating archive …"
ARCH="/root/fogcerts_$(date +%F).tar.gz"
tar -czf "$ARCH" -C /root fogcerts
chmod 600 "$ARCH"

echo
echo "Done. Archive: $ARCH"
echo "To list archive content: tar -tzf $ARCH"
echo "To verify checksums: cat /root/fogcerts/SHA256SUMS.txt"
'

Save the archive (e.g. fogcerts_YYYY-MM-DD.tar.gz) using WinSCP
→ Old server may now be shut down

2. Prepare new Debian-12 server

• Install Debian 12 without GUI but WITH SSH server
• Allow root login via SSH (/etc/ssh/sshd_config)
• Configure IP & reboot
• Connect via PuTTY as root

3. Install FOG server

apt update && apt install git -y
cd /root
cd /root
git clone https://github.com/FOGProject/fogproject.git
cd fogproject/bin
./installfog.sh

Configure FOG as usual

4. Import database from the old server

In the new FOG web interface:

• FOG Configuration → FOG Settings

• Save mysqlpass (under Storage Nodes)
• Save TFTP FTP Password (under TFTP Server)

• Storage → DefaultMember → Save Management Password

• Configuration Save → Import Database
→ Select the SQL backup & import it

Afterwards: Enter the three passwords back in their original places

5. Copy certificates to the new server

Transfer the archive to /root
(e.g. fogcerts_2025-10-25.tar.gz)

Stop services:

systemctl stop apache2
systemctl stop FOGImageReplicator
systemctl stop FOGScheduler

Extract archive:

cd /root
tar -xzf fogcerts_*.tar.gz

Copy certificates & set permissions:

# Private Keys & CA
cp -a /root/fogcerts/.srvprivate.key /opt/fog/snapins/ssl/
cp -a /root/fogcerts/CA/.fogCA.key /opt/fog/snapins/ssl/CA/
cp -a /root/fogcerts/CA/.fogCA.pem /opt/fog/snapins/ssl/CA/
[ -f /root/fogcerts/CA/.fogCA.srl ] && cp -a /root/fogcerts/CA/.fogCA.srl /opt/fog/snapins/ssl/CA/

# Server Public Cert & CA Public
cp -a /root/fogcerts/srvpublic.crt /var/www/fog/management/other/ssl/
cp -a /root/fogcerts/ca.cert.pem /var/www/fog/management/other/
cp -a /root/fogcerts/ca.cert.der /var/www/fog/management/other/

chown -R fogproject:www-data /opt/fog/snapins/ssl
chmod 600 /opt/fog/snapins/ssl/.srvprivate.key
chmod 600 /opt/fog/snapins/ssl/CA/.fogCA.key

chown -R www-data:www-data /var/www/fog/management/other

Start services:

systemctl start apache2
systemctl start FOGImageReplicator
systemctl start FOGScheduler

6. Rebuild boot images (with certificate)

Install required software:

apt-get update
apt-get install -y git build-essential gcc make binutils perl mtools   liblzma-dev libssl-dev zlib1g-dev pkg-config nasm libiberty-dev uuid-dev   xz-utils cpio gcc-aarch64-linux-gnu

Rebuild PXE boot loaders:

cd /root/fogproject/utils/FOGiPXE
# Select one CA certificate path:
CA=/var/www/fog/management/other/ca.cert.pem
# or:
# CA=/opt/fog/snapins/ssl/CA/.fogCA.pem

bash ./buildipxe.sh "$CA"

Copy new files:

# Standard loader (without 10s delay)
cp -av /root/fogproject/packages/tftp/* /tftpboot/

# Optional 10s-delay loaders:
# cp -av /root/fogproject/packages/tftp/10secdelay/* /tftpboot/

Restart TFTP service:

systemctl restart tftpd-hpa

FINISHED
If all steps were successful, clients will securely reconnect using HTTPS again.

It’s worth noting if you want you should be able to skip the grub stage entirely, if you load the shim directly and name your ipxe binary what you’re grub binary currently is you should be able to net boot any shim pretty easily, from there the shim can automatically call mok manager as long as it’s in the same directory as your shim.

Sorry for responding so late. I’m out on training this week.

I solve the problem with this AutoUnatted.xml

<?xml version=“1.0” encoding=“utf-8”?>
<unattend xmlns=“urn:schemas-microsoft-com:unattend”>
<!-- Bypass OOBE -->
<settings pass=“oobeSystem”>
<component name=“Microsoft-Windows-Shell-Setup” 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”>
<OOBE>
<HideEULAPage>true</HideEULAPage>
<HideLocalAccountScreen>true</HideLocalAccountScreen>
<HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
<HideOnlineAccountScreens>true</HideOnlineAccountScreens>
<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
<ProtectYourPC>3</ProtectYourPC>
<SkipUserOOBE>true</SkipUserOOBE>
<SkipMachineOOBE>true</SkipMachineOOBE>
<UnattendEnableRetailDemo>false</UnattendEnableRetailDemo>
<NetworkLocation>Other</NetworkLocation>
</OOBE>
</component>
<component name=“Microsoft-Windows-International-Core” 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”>
<SystemLocale>pt-PT</SystemLocale>
<UILanguage>pt-PT</UILanguage>
<UserLocale>pt-PT</UserLocale>
<InputLocale>0816:00000816</InputLocale>
</component>
</settings>

</unattend>

The AutoUnatted.xml will call the the script C:\Windows\Setup\Scripts\SetupComplete.cmd

I make the sysprep with AutoUnatted.xml

Greetings,

I was going to implement the script for my organizations fog server to boot macbook proz. When scrolling down through the code, I noticed that there is two sections, with different menu entrys but using dd to write out to a usb stick. How is this to be interpreted? Do I need all of it for just the first section or the second?

Thanks

#Add-WindowsFeature -Name DHCP –IncludeManagementTools
Import-Module DhcpServer
cls
"
This script will add new vendor classes, policies and options
66/67 for Legacy & UEFI PXE booting. Please double check what
you enter in the prompts or you will need to rerun the script.
This script will also update/replace entries that already
exist so you can use it to change the IP of the FOG server.
"
$Server	= Read-Host -Prompt 'Enter the FULL name of the DHCP server (FQDN)'
$Scope	= Read-Host -Prompt 'Enter the network scope IP address (DHCP server has the scope IP listed)'
$WDSvr	= Read-Host -Prompt 'Enter the IP of the FOG server'

$VendorClassUEFIx64 = @{
	Name = "PXEClient UEFI (x64)"
	Description = "PXEClient UEFI (x64)"
	Type = "Vendor"
	Data = "PXEClient:Arch:00007"
	}

$VendorClassUEFIx64_2 = @{
	Name = "PXEClient UEFI (x64)_2"
	Description = "PXEClient UEFI (x64)_2"
	Type = "Vendor"
	Data = "PXEClient:Arch:00008"
	}

$VendorClassUEFIx64_3 = @{
	Name = "PXEClient UEFI (x64)_3"
	Description = "PXEClient UEFI (x64)_3"
	Type = "Vendor"
	Data = "PXEClient:Arch:00009"
	}	

$VendorClassUEFIx86 = @{
	Name = "PXEClient UEFI (x86)"
	Description = "PXEClient UEFI (x86)"
	Type = "Vendor"
	Data = "PXEClient:Arch:00002"
	}

$VendorClassUEFIx86_2 = @{
	Name = "PXEClient UEFI (x86)_2"
	Description = "PXEClient UEFI (x86)_2"
	Type = "Vendor"
	Data = "PXEClient:Arch:00006"
	}

$VendorClassBIOS = @{
	Name = "PXEClient BIOS (x86 & x64)"
	Description = "PXEClient BIOS (x86 & x64)"
	Type = "Vendor"
	Data = "PXEClient:Arch:00000"
	}

Add-DhcpServerv4Class @VendorClassUEFIx64 -ComputerName $Server
Add-DhcpServerv4Class @VendorClassUEFIx64_2 -ComputerName $Server
Add-DhcpServerv4Class @VendorClassUEFIx64_3 -ComputerName $Server
Add-DhcpServerv4Class @VendorClassUEFIx86 -ComputerName $Server
Add-DhcpServerv4Class @VendorClassUEFIx86_2 -ComputerName $Server
Add-DhcpServerv4Class @VendorClassBIOS -ComputerName $Server

Add-DhcpServerv4Policy -Name "PXEClient UEFI (x64)" -ScopeId $Scope -Condition OR -VendorClass EQ,"PXEClient UEFI (x64)*"
Add-DhcpServerv4Policy -Name "PXEClient UEFI (x86)" -ScopeId $Scope -Condition OR -VendorClass EQ,"PXEClient UEFI (x86)*"
Add-DhcpServerv4Policy -Name "PXEClient BIOS" -ScopeId $Scope -Condition OR -VendorClass EQ,"PXEClient BIOS (x86 & x64)*"

Set-DhcpServerv4OptionValue -OptionId 66 -Value $WDSvr -ComputerName $Server -ScopeId $Scope
Set-DhcpServerv4OptionValue -OptionId 67 -Value "undionly.kpxe" -ComputerName $Server -ScopeId $Scope
Set-DhcpServerv4OptionValue -OptionId 66 -Value $WDSvr -ComputerName $Server -ScopeId $Scope -PolicyName "PXEClient BIOS"
Set-DhcpServerv4OptionValue -OptionId 67 -Value "undionly.kpxe" -ComputerName $Server -ScopeId $Scope -PolicyName "PXEClient BIOS"
Set-DhcpServerv4OptionValue -OptionId 66 -Value $WDSvr -ComputerName $Server -ScopeId $Scope -PolicyName "PXEClient UEFI (x64)"
Set-DhcpServerv4OptionValue -OptionId 67 -Value "ipxe.efi" -ComputerName $Server -ScopeId $Scope -PolicyName "PXEClient UEFI (x64)"
Set-DhcpServerv4OptionValue -OptionId 66 -Value $WDSvr -ComputerName $Server -ScopeId $Scope -PolicyName "PXEClient UEFI (x86)"
Set-DhcpServerv4OptionValue -OptionId 67 -Value "i386-efi/ipxe.efi" -ComputerName $Server -ScopeId $Scope -PolicyName "PXEClient UEFI (x86)"

I’m sure some of these parameters are not relevant as I don’t really know what I’m doing,

It looks like you are doing very well.

I can add a little context as in the kernel parameter loads the linux kernel. The initrd commands load these image files onto a virtual hard drive created by iPXE so the kernel can locate them. The .img files would actually be mapped as hard drives to the kernel. The kernel would know how to connect to them and use them.

As for the imgargs these are flags for the kernel as it boots. The different flags tell the startup scripts in the kernel how to react dynamically to the external environment. The alternative would be to build the flags into the kernel, but then you would need to recompile the kernel every time you wanted to make a change. Hint: kernel args are the way to go.

I don’t see much room for improvements with this design. You are currently using http to transfer the boot files. Once the kernel starts up then iPXE is out of the picture. I’m going to suspect most of the slowness is because most of the files are the pmodules directory. iPXE should load bzImage, initrd.img, fu.img and m.img very quickly. Where most of your time is probably once bzImage starts to boot. Then you are at the mercy of what Parted Magic does.

I did some more looking, and found yes, the GUI will re-write the dhcp config file. However I did some more reading and I guess services.inc determines what is written by the GUI.

Sorry, not a CLI guy, and I love the quick and easy edits, viewing issues that the GUI provides. Like Fog ! However my servers are headless…lol

Anyway, looking that route now, and will update if I find how Negate wants services edited so when it reboots, DHCP will remain.

Determined 🙂

Any thank you everyone here . This place has always been great for information !

I have prepared USB bootable image based in WinPE. I use it to boot from USB. I have this image in iso file and I use it to place it on USB with rufus software.

I wonder if I can use this tutorial of yours in exactly same way only to use my custom iso image instead of your mentioned WinPE.

I know this may be trivial question and I may just try it, but I am really only beginner in WinPE and fog project.

Thank you for your kind answer.
-r-

Yes, I changed it, exactly as you just mentioned, and it still didn’t work, it worked fine when I added those two lines of code I mentioned earlier.

Anyway, thank you very much for your help and attention.

For the first time, I had “zstd /stdin unsupported format” during deploy after moving an image between FOG servers and crossing two Windows computers.

I end checking CRC with the commands directly inside image directory :

• On Linux with :

cksum *

Result :

4102865288 6 d1.fixed_size_partitions
1553301511 1048576 d1.mbr
21074109 873 d1.minimum.partitions
3930731312 20 d1.original.fstypes
4294967295 0 d1.original.swapuuids
3323012245 11304005 d1p1.img
4080882029 767 d1p2.img
4038447468 7834146234 d1p3.img
1735290603 153344 d1p4.img
1356735187 873 d1.partitions
2087979657 873 d1.shrunken.partitions

• On Windows Powershell with :

Get-ChildItem * | Select-Object -Property Name,@{name="Hash";expression={(Get-FileHash $_.FullName).hash}}

Result :

d1.fixed_size_partitions 8F2326E98FF66634578EC07879B45A6ADA0B681444819A581F5F3BFCA5FA6029
d1.mbr                   5113DDB273F26E0D6F88367B5330BEF6E2A7FD399984EDB3519268DDE7B4FFCE
d1.minimum.partitions    8A04A480F69C6A6084DDF9EB43F37E913C14C5EF57AF58CBB7406CD2CB832CAC
d1.original.fstypes      A061EFCFAA6B32FBD533450D14E71E2C1EC422AC67A8F8296B773A46407F5914
d1.original.swapuuids    E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
d1.partitions            3F23AA64C5AFDCE83CCB59AACF2F03EDAD3EA6429B22010339C43B29DE406D2C
d1.shrunken.partitions   59D5B234D923B3B73EA0CB808853397B8D19644C9E135BFDD8C538633ECE4106
d1p1.img                 6B3A9D5B0C26BE448A24339F7DE1067A4C0F3615D9BE42B86BEB355BA6F9BCE6
d1p2.img                 511CBE019A39980DF90F7D9A547BAE4521551EEF53625705538713AB14311DD0
d1p3.img                 5F2223BB3D63C9400C77C10A5ADF5AE2DCA48D8C768AC2097F20E3731E843FC9
d1p4.img                 A8D21F3E22C596EA01B8F7BAC981C9FB265938D0A1A3F2C3599ADF170A75CE9E

This way I can check between my 2 computer under Windows before checking between my two FOG servers.

To configure PXE (Network) Booting with pfSense please do the following.

1. Edit your DHCP Server configuration for the subnet where you require pxe booting.
2. At the top of the DHCP Server conifugration page for the network interface (LAN in this example). Make sure that you have the DHCP server enabled and Ignore Bootp queries disabled.
   
3. Scroll down the page until you see the Network Booting section and press the Display Advanced button.
   
4. Tick the checkbox for Enable network booting and then enter the IP address of the FOG server (netboot server) in the Next Server field.
5. Complete the form as below
   
6. Make sure you don’t have any value populated for the TFTP server field
   
7. As well as under the Additional Bootp/DHCP options section. Make sure you are not populating dhcp options 60, 66, or 67.
   
8. Save the configuration and then restart the dhcp server.
   9, Be aware that you might need to enable some additional firewall rules if you have the LAN inteface locked down. Net/PXE booting requires access to the TFTP server on udp port 69 on the FOG server.

Note: If you are running pfSense as a VM, you may need to configure promiscuous mode on the network interface for your hypervisor. You would only need this option if your external target computer’s can’t pick up an IP address from pfSense. This promiscuous mode is a requirement of dhcp and not network booting.

https://github.com/mediocreatmybest/FOG-O-Matic/blob/main/FOG-Snapins/ChocolatePy.py

FOS Linux (the OS that runs on the target computer) loads the image from the target computer onto the storage node (FOG or NAS) using NFS. The files are uploaded using NFS to /images/dev directory which is read write access. Now the user ID and password comes into play. The management user ID and password is used because the FOS Linux OS connects to the storage node using FTP to move the raw data files from /images/dev/<mac_address> to /images<image_name> directory. So you need to make sure the management user ID and password has rights on the NAS to login via FTP and can execute the mv command to move the files.

On the ReadyNAS web interface

• Add a share and select NFS protocol.
  

• Click on the
  
  of the share to add allowed computer.

• Enter the IP of the FOG server and clic Add
  

• On the FOG server, create a new image directory and mount your NAS share
  

• Test write from FOG server
  

You should see the new directory on the ReadyNAS web interface

To mount it add FOG server boot, edit the /etc/fstab file and add this line

192.168.0.55:/data/images /images2  nfs      defaults    0       0

• Reboot and check auto mount working (create a file or a directory as previous test from manual mount)

• Change owner of the /images2 directory with command

chown fogproject:root /images2

• Edit or add your storage on FOG GUI to use it.
  

• If you added a new storage node in the same storage group, you should see your images, dev and postdownloadscripts directories on NAS share after replication.
  

. I’m not sure on how to check the apache error logs.

You need console access (e.g. SSH) to your FOG server. See my signature on where to find the logs files.