Here is a pcap of the proper UEFI PXE boot. This was captured from the FOG-Pi server perspective.

0_1475453397643_uefi_pxe_boot.pcap

While I haven’t been able to get into the iPXE boot menu as of now, I can say that the dnsmasq part appears to be working since the iPXE kernel makes it to the target. But right now the iPXE kernel tries to initialize the devices for about 5 minutes then reboots the computer. I still need to dig into that but so far its taken me 4 hours to get this far so enough for tonight.

While I can’t speak for the FOG Project developers, I would say that managing MS Windows updates is not something that the FOG Project wants to enter. FOG’s focus is cross platform image deployment. I feel that moving into the MS Windows (only) space would be moving in a direction away from The FOG Project’s original charter. Also there are currently free MS Windows patch management solutions like Microsoft’s WSUS. There are other like free solutions like WSUS Offline Updater already in this space. In the linux space there is puppet, chef, and ansible.

I started doing a bit more reverse engineering on what these bits of the dnsmasq configuration was actually doing.

If you turn off this section of the dnsmasq config, that also disabled udp port 4011 (dhcpProxy).

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Press F8 for boot menu", 10

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
# PXEClient:Arch:00000
pxe-service=X86PC, "Boot BIOS PXE", undionly
# PXEClient:Arch:00007
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
# PXEClient:Arch:00009
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi

This causes the dhcp proxy function to fail and the device won’t boot.

If you turn off this section

dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI,ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI64,ipxe.efi,,192.168.112.24
dhcp-boot=net:BIOS,undionly.kpxe,,192.168.112.24

The dnsmasq server will not send out the file name in the initial dhcp offer request. Which I found doesn’t matter. I could send out one name for the dhcp offer and another name in the proxy section. The proxy section always won. So in my current config I have the vendor class stuff turned off since it was not impacting what actually was downloaded from the tftp server.

pxe-prompt="Boot to FOG iPXE", 1
pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", snp.efi

So this is what I have for the part that actually sends the file to the booting client. I also discovered in the new version of dnsmasq that it doesn’t automatically append .0 to the file name, what ever the name is listed above is what is requested from the tftp server.

In the pxe-service line. The first value correlates to the Architecture Type in this document: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#General

By creating unique pxe-service lines your dnsmasq server will send out the proper boot file based on the transmitted architecture type in the dhcp request. So far in testing with the 6230 undionly.kpxe is sent in bios mode and ipxe.efi is sent in uefi mode. I’m still hitting a wall in uefi mode where it initializes devices for about 5 minutes then reboots. But the right iPXE kernel is being sent to the target computer. I checked and the bios is old (A11) vs current A15. I’m going to update the firmware after a bit to see if that is what is causing iPXE to not init right. I can say it works flawlessly in bios mode.

If you search the tutorials FOG forum I have several on creating postdown scipts to install model specific drivers (for windows). The concepts are the same for what you want to do. You will just mount the target computer’s linux root volume. https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins

and from here: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/4

These are the list of FOG variables that are available to postdownload scripts.

shutdown	# Shut down at the end of imaging
hostdesc	#Host Description from Host Managment-General
hostip		# IP address of the FOS client
hostimageid	# ID of image being deployed
hostbuilding	# ??
hostusead	# Join Domain after image task from Host Management-Active Directory
hostaddomain	# Domain name from Host Management-Active Directory
hostaduser	# Domain Username from Host Management-Active Directory
hostadou	# Organizational Unit from Host Management-Active Directory
hostproductkey=	# Host Product Key from Host Management-Active Directory
imagename	# Image Name from Image Management-General
imagedesc	# Image Description from Image Management-General
imageosid	# Operating System from Image Management-General
imagepath	# Image Path from Image Management-General (/images/ assumed)
primaryuser	# Primary User from Host Management-Inventory
othertag	# Other Tag #1 User from Host Management-Inventory
othertag1	# Other Tag #2 from Host Management-Inventory
sysman		# System Manufacturer from Host Management-Inventory (from SMBIOS)
sysproduct	# System Product from Host Management-Inventory (from SMBIOS)
sysserial	# System Serial Number from Host Management-Inventory (from SMBIOS)
mbman		# Motherboard Manufacturer from Host Management-Inventory (from SMBIOS)
mbserial	# Motherboard Serial Number from Host Management-Inventory (from SMBIOS)
mbasset		# Motherboard Asset Tag from Host Management-Inventory (from SMBIOS)
mbproductname	# Motherboard Product Name from Host Management-Inventory (from SMBIOS)
caseman		# Chassis Manufacturer from Host Management-Inventory (from SMBIOS)
caseserial	# Chassis Serial from Host Management-Inventory (from SMBIOS)
caseasset	# Chassis Asset from Host Management-Inventory (from SMBIOS)
location	# Host Location (name) from Host Management-General

@Wayne-Workman Considering what is currently being packaged with modern linux distributions is dnsmasq 2.72 (Sep 2014) is over two years old, its about time they did drop the old syslinux syntax requirements. One of many improvements I’ve seen so far.

[edit] Just reviewing the change log for 2.76 this jumps out in regards to file names:

	    Subtle change in the semantics of "basename" in
	    --pxe-service. The historical behaviour has always been
	    that the actual filename downloaded from the TFTP server
	    is <basename>.<layer> where <layer> is an integer which
	    corresponds to the layer parameter supplied by the client.
	    It's not clear what the function of the "layer" 
	    actually is in the PXE protocol, and in practise layer 
	    is always zero, so the filename is <basename>.0
	    The new behaviour is the same as the old, except when
	    <basename> includes a file suffix, in which case
	    the layer suffix is no longer added. This allows
	    sensible suffices to be used, rather then the
	    meaningless ".0". Only in the unlikely event that you
	    have a config with a basename which already has a
	    suffix, is this an incompatible change, since the file
	    downloaded will change from name.suffix.0 to just 
	    name.suffix

So you might ask how would you even begin to debug and/or write one of these scripts?

Simple you would go in a create your own bash script in /images/postinstall directory call it something like fog.aws or what ever in there create a simple bash script like

#!/bin/bash

echo "debug my custom script here. Press Ctrl-C to exit now";
debugPause;

Link that script into the master fog.postdownload script. And then schedule a deployment. Before you hit the schedule task button, tick the debug check box. Then pxe boot the target computer. After a few screens of text where you need to clear with the enter key you will be dropped to the FOS Linux command prompt in debug mode. Key in fog to start the master fog script. The master fog script will stop at each break point waiting for you to press the enter key to move to the next debugPause statement. When you see the message you created in your fog.aws script, hit ctrl-C and exit out of the FOG installer script. At this point you will be where your post install script should run. Now you can start developing your post install actions. The fog post install script should be in /images/postinstall on the FOS Linux target computer you can edit with vi or what ever else is on FOS Linux. You can mount the disk partitions all of the contents of the disk image should be on the target computer by now.

While its probably not necessairy to post this image, this is from my initial request for a multi master storage node setup. The intent was to show the relationship between the master node and the remote fog servers.

ref: https://forums.fogproject.org/topic/6014/create-the-concept-of-a-foreignmasterstorage-deployment-node

You know the fog server or the web ui does query (somewhere) to find out the latest version of FOG vs what is installed. Is there a way to send the FOG version number during that query?

What we really need to know (from a demographics stand point) is

1. how many active FOG installs are out there running
2. What version of FOG is currently running
3. What host OS and version is the #2 running on

As long as we stick to those values only I don’t see any infringement on anyone’s privacy. There would be no way to tie the organization name to the data. What is really needed is prospective data. I know we could add that to FOG moving forward, but we really need to know what is already out there.

The other thing is to only support a distro supported OS. When the distro drops support for an OS then FOG should too. i.e. should FOG still support ububntu 12.04 or 14.04? When rhel/centos 7 EOL (hint: June 30th, 2024), does that mean FOG will support centos 7 until 2024? Is that the right thing to do? (asking)

@lebrun78 You post confuses me a bit, typically FOG is uses to deploy copies of complete systems and not just the install “media” for systems. A wim file on its own is not very useful, you need the installer program to do something with the wim file.

I created two tutorial for doing what I think you want, but I’m not sure.

1. PXE booting a MDT ISO file (which MDT uses a WInPE environment to deploy a wim image) https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog
2. PXE booting into the Windows setup program https://forums.fogproject.org/topic/7765/pxe-booting-into-ms-windows-7-setup

Most modern linux OS now support dnsmasq v 2.76 or later. If the FOG admin select N to install isc-dhcp server then the fog installer should ask if you want to install dnsmasq server with some verbiage related to if you have an unmodifiable dhcp server but still need to pxe boot, do you want to install the dnsmasq server? If installing the actual dnsmasq server is problematic the fog installer could at least drop a the fully configured conf file for dnsmasq in the proper location and tell the FOG admin that the dnsmasq binaries should be installed by hand after the fog install is done. (or something like that).

We have a fully vetted dnsmaq server configuration and performing a text replace with the IP address should be trivial for the installer.

@Tom-Elliott Along the same lines as Tom mentioned, use post install scripts to modify how the clients are being installed.

The idea is to NOT install the FOG client in the reference image, but have it installed by the setupcomplete.cmd script. This also avoids the early triggering of the FOG client during OOBE (since the fog client is not installed until after OOBE has completed).

The idea with the fog post install script is to have the post install script (which executes on the target computer) determine where the client is by the IP address and then append the proper msi install line to the end of the setupcomplete.cmd file. There was just a thread about this… somewhere. ref: https://forums.fogproject.org/topic/8877/changing-from-legacy-to-new-client/5

<edit>
This tutorial discusses some of what you need in your post install script. https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/6

@Wayne-Workman Thank you for do an excellent QC check between each FOG RC releases and those supported distros.

I agree with you that pfsense is a pretty great solution. I’ve used it for both a firewall as well as an application platform. It is a solid FOSS solution.

As to your migration, don’t forget to turn of dnsmasq on your fog server now. Its not needed if pfsense is handing out the right file names for your network.

I think this access control plugin is surely needed for an enterprise environment.

These are just ideas.
From an enterprise level I need to assign imaging techs (people) to a single location, a group of locations, or all locations (super admin).

Within that location(s) the imaging tech may image machines or deploy snapins. There could be a time where I might want to restrict an imaging tech to only be able to deploy applications and/or image a computer. If you are going to that detail then you might plan for allowing one or the other or both.

Imaging techs assigned to Location A, may not touch or deploy any target host at Location B. Possibly read only access to Location B’s host records might be interesting.

Imaging Techs may not alter any FOG System settings. FOG Admins may be allowed to alter FOG system settings. It may be useful to restrict certain FOG admins to certain sections of the FOG settings. Like host admin, but not storage admin, or group admin.

As it stands today the LDAP Plugin supports 2 levels of users Admin, and mobile. Within those 2 groups the FOG ACLs can set more detailed controls on access, using a key and lock concept of access. A user can have many keys but those keys can only unlock one specific class of lock.

I might suggest that you no do this, but create a default page in the http root that just forwards the user to the /fog path.

Using the uuid as a unique system ID has been proven to not be a reliable method of system identification. I saw this when working with dnsmasq trying to deliver a certain iPXE boot file based on the system requesting boot info. I ended up giving up on the task since the UUID field is defined in IEEE documentation, but the implementation of that 32 character field it up to the hardware manufacture to populate. There is no guidance from IEEE on the content of this field or even a requirement for the system manufacturer to populate this field.

In my testing I found that most enterprise system builders do this this field to uniquely identify their hardware, but not all do. So what can we do to create a uniquely identifiable ID for fog to use. Initially we were using the network adapter’s hardware mac address for system identification. This process worked great until computers began shipping without built in ethernet adapters. USB dongles where then required to image these machines with FOG. The issue here is that now we have many machines that used the same USB dongle (or dock) for imaging and they all have the same mac address inside fog.

So again I ask, what can we do?

One solution comes from the way I had to program and manage unique record keys in Lotus Notes back in the early 2000s. At that time we used several fields to create a unique composite key that specifically described that record for searching.

I feel we can use the same concept with FOG to create a new key that precisely describes a system registered in FOG. It may be required to create a new database field to contain this key for this discussion lets call the key fluid (Fog Logical Unit ID) [yes there is a double meaning here too].

What I propose would be to use the following fields that FOG is already collecting when the system is registered. The fluid key might be comprised of the following fields: <mac_address>|<System Serial Number>|(alternate would be <Motherboard Serial Number> if <System Serial Number> was blank or contained non lower ascii characters)<Motherboard Asset Tag><Chassis Asset>|<System Product> Or any other smbios key that is unique to the specific hardware.

I did intentionally include the Motherboard asset tag and the chassis asset tag to allow the IT admin to have the ability to add uniqueness to the fluid if all other fields became equal.

I did collect samples of a few systems I have at home to see if we could find uniqueness in what FOG is collecting.

Dell e6410

System Manufacturer	Dell Inc.
System Product	Latitude E6410
System Version	0001
System Serial Number	5XXXxX1
System Type	Type: Laptop
BIOS Vendor	Dell Inc.
BIOS Version	A16
BIOS Date	12/05/2013
Motherboard Manufacturer	Dell Inc.
Motherboard Product Name	04373Y
Motherboard Version	A03
Motherboard Serial Number	/5XXXxX1/CN1XXXXXR03D5/
Motherboard Asset Tag	
CPU Manufacturer	Intel
CPU Version	Intel(R) Core(TM) i7 CPU M 640 @ 2.80GH
CPU Normal Speed	Current Speed: 2799 MHz
CPU Max Speed	Max Speed: 4000 MHz
Memory	3.65 GiB
Hard Disk Model	WDC WD2500BEKT-75PVMT0
Hard Disk Firmware	01.01A01
Hard Disk Serial Number	WD-WXK1AXXXXX4
Chassis Manufacturer	Dell Inc.
Chassis Version	
Chassis Serial	5XXXxX1
Chassis Asset	

Dell e6440

System Manufacturer	Dell Inc.
System Product	Latitude E6440
System Version	00
System Serial Number	7XXXxX1
System Type	Type: Laptop
BIOS Vendor	Dell Inc.
BIOS Version	A14
BIOS Date	12/01/2015
Motherboard Manufacturer	Dell Inc.
Motherboard Product Name	
Motherboard Version	
Motherboard Serial Number	/7XXXxX1/ /
Motherboard Asset Tag	Not Specified
CPU Manufacturer	Intel
CPU Version	Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz
CPU Normal Speed	Current Speed: 2600 MHz
CPU Max Speed	Max Speed: 2600 MHz
Memory	3.75 GiB
Hard Disk Model	Crucial_CT275MX300SSD1
Hard Disk Firmware	M0CR040
Hard Disk Serial Number	172XXXXX535
Chassis Manufacturer	Dell Inc.
Chassis Version	
Chassis Serial	7XXXxX1
Chassis Asset	

VMWare virtual machine

System Manufacturer	VMware, Inc.
System Product	VMware Virtual Platform
System Version	None
System Serial Number	VMware-42 2e a9 xx 9b xx 2c 15-xx af xx d9 xx xx xx a9
System Type	Type: Other
BIOS Vendor	Phoenix Technologies LTD
BIOS Version	6.00
BIOS Date	04/14/2014
Motherboard Manufacturer	Intel Corporation
Motherboard Product Name	440BX Desktop Reference Platform
Motherboard Version	None
Motherboard Serial Number	None
Motherboard Asset Tag	Not Specified
CPU Manufacturer	GenuineIntel 000000000000 000
CPU Version	Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
CPU Normal Speed	Current Speed: 2400 MHz
CPU Max Speed	Max Speed: 30000 MHz
Memory	3.85 GiB
Hard Disk Model	
Hard Disk Firmware	
Hard Disk Serial Number	
Chassis Manufacturer	No Enclosure
Chassis Version	
Chassis Serial	None
Chassis Asset	No Asset Tag

Intel NUC

System Manufacturer	.................................
System Product	.................................
System Version	.................................
System Serial Number	.................................
System Type	Type: Desktop
BIOS Vendor	Intel Corp.
BIOS Version	FYBYT10H.86A.0047.2014.1224.1147
BIOS Date	12/24/2014
Motherboard Manufacturer	Intel Corporation
Motherboard Product Name	DN2820FYK
Motherboard Version	H24582-204
Motherboard Serial Number	GEFYXXXXXXY
Motherboard Asset Tag	.................................
CPU Manufacturer	Intel
CPU Version	Intel(R) Celeron(R) CPU N2830 @ 2.16GHz
CPU Normal Speed	Current Speed: 2160 MHz
CPU Max Speed	Max Speed: 2400 MHz
Memory	3.68 GiB
Hard Disk Model	SanDisk SDSSDP128G
Hard Disk Firmware	3.2.0
Hard Disk Serial Number	1510XXXXXXX89
Chassis Manufacturer	.................................
Chassis Version	
Chassis Serial	.................................
Chassis Asset	

Lenovo X60

Lenovo
System Manufacturer	LENOVO
System Product	17023LU
System Version	ThinkPad X60s
System Serial Number	LVXXXX6
System Type	Type: Notebook
BIOS Vendor	LENOVO
BIOS Version	7BETD5WW (2.16 )
BIOS Date	03/31/2008
Motherboard Manufacturer	LENOVO
Motherboard Product Name	17023LU
Motherboard Version	Not Available
Motherboard Serial Number	1ZDXXXXX0S
Motherboard Asset Tag	
CPU Manufacturer	GenuineIntel
CPU Version	Intel(R) Core(TM) Duo CPU
CPU Normal Speed	Current Speed: 1667 MHz
CPU Max Speed	Max Speed: 1667 MHz
Memory	1.46 GiB
Hard Disk Model	FUJITSU MHY2080BH
Hard Disk Firmware	0084000D
Hard Disk Serial Number	K43XXXXXX62PA
Chassis Manufacturer	LENOVO
Chassis Version	
Chassis Serial	Not Available
Chassis Asset	

Virtualbox

System Manufacturer	innotek GmbH
System Product	VirtualBox
System Version	1.2
System Serial Number	0
System UUID	ac7a7b42-e5d2-4bac-bcda-ef5ae35d4cf0
System Type	Type: Other
BIOS Vendor	innotek GmbH
BIOS Version	VirtualBox
BIOS Date	12/01/2006
Motherboard Manufacturer	Oracle Corporation
Motherboard Product Name	VirtualBox
Motherboard Version	1.2
Motherboard Serial Number	0
Motherboard Asset Tag	Not Specified
CPU Manufacturer	
CPU Version	
CPU Normal Speed	
CPU Max Speed	
Memory	724.69 MiB
Hard Disk Model	VBOX HARDDISK
Hard Disk Firmware	1.0
Hard Disk Serial Number	VBa44dd0ba-42d13f3b
Chassis Manufacturer	Oracle Corporation
Chassis Version	
Chassis Serial	Not Specified
Chassis Asset	Not Specified

I think we need to step back and do a sanity check on what you really need here.

I understand the whole centrally manged (MSP) perspective.

I think you need to document what exactly you hope to achieve from this solution. I am intimately familiar with Openvpn, FOG, and the concepts involved here.

Unless you are going to establish a full time vpn connection to each of these remote locations you would be better served if you had a full fog server at each location. By placing a full fog server at each location you can take advantage of all of fog’s capabilities (more than just pushing images to client computers). The fog client must be able to reach the master FOG server to check in, change system names, reboot on demand, and receive instructions from the FOG server. Storage nodes can’t do this today. If they could they would need a live connection back to the FOG server because they don’t have a local database installed, only a full fog server has a database.

So then I have to ask the question, do you / will you create master OS images at your HQ for these remote locations? If so you will need to have vpn setup so that the fog replicator can do it replication. This replicator runs continuously, so you may need the vpn established continuously. Its possible to have a cron job open the vpn tunnel and then start the replicator for after hours image replication. You may be better served with just moving the files to the remote location on flash drives and ignoring the bits around replication. How often will your images change really? Is it worth the effort?

So what it really comes down to (if there is a fog server at each location) you would just need remote access to the fog web gui at the remote location to issue capture and deploy commands to the remote clients.

I can’t say what the right answer is for your final solution. I’m not saying yes or no here either. The only point I’m raising here is to think about what you really want to accomplish here, how much effort its going to take, and how long will it take to pay back the effort put into the solution.

Can you do this with FOG and openvpn, probably. If you go this route you will want to run the openvpn software on all fog servers/storage nodes and then have the clients setup the portforwarding on their internet routers to forward the openvpn port number direct to your FOG hardware at their location. Since you will not be routing traffic beyond the openvpn software at each end you should not have to worry about (near and far end) IP range address conflicts with the openvpn.

@sebastian-roth I wonder if we should see if the testers can provide more examples of what I posted. We only have Dells at my work so what I found almost all dells are exactly the same in what they produce. It may be of some value to get the inventory of the MSI board that started this quest too. The more data we have to start with, the better the decision will be even before any code is crafted.

As for the ipxe that is going to be a difficult one.

These four look interesting:

manufacturer 	(string) 	Manufacturer
product 	(string) 	Product name
serial 	(string) 	Serial number
asset 	(string) 	Asset tag 

You can’t/shouldn’t use the hard drive serial number since that is the one device that may change more frequently than the other values. Hard drive crashes, is replaced and now we have a new identity.

@Junkhacker show off…

< really means George is envious of your tech >

@fry_p I’m not sure I can help you with the fog client checking in but looking at the tables it looks like we might be able to leverage the usertracking table.

MariaDB [fog]> describe hosts;
+------------------+---------------+------+-----+---------------------+----------------+
| Field            | Type          | Null | Key | Default             | Extra          |
+------------------+---------------+------+-----+---------------------+----------------+
| hostID           | int(11)       | NO   | PRI | NULL                | auto_increment |
| hostName         | varchar(16)   | NO   | UNI | NULL                |                |
| hostDesc         | longtext      | NO   |     | NULL                |                |
| hostIP           | varchar(25)   | NO   | MUL | NULL                |                |
| hostImage        | int(11)       | NO   |     | NULL                |                |
| hostBuilding     | int(11)       | NO   |     | NULL                |                |
| hostCreateDate   | timestamp     | NO   |     | CURRENT_TIMESTAMP   |                |
| hostLastDeploy   | datetime      | NO   |     | NULL                |                |
| hostCreateBy     | varchar(50)   | NO   |     | NULL                |                |
| hostUseAD        | char(1)       | NO   | MUL | NULL                |                |
| hostADDomain     | varchar(250)  | NO   |     | NULL                |                |
| hostADOU         | longtext      | NO   |     | NULL                |                |
| hostADUser       | varchar(250)  | NO   |     | NULL                |                |
| hostADPass       | varchar(250)  | NO   |     | NULL                |                |
| hostADPassLegacy | longtext      | NO   |     | NULL                |                |
| hostProductKey   | longtext      | YES  |     | NULL                |                |
| hostPrinterLevel | varchar(2)    | NO   |     | NULL                |                |
| hostKernelArgs   | varchar(250)  | NO   |     | NULL                |                |
| hostKernel       | varchar(250)  | NO   |     | NULL                |                |
| hostDevice       | varchar(250)  | NO   |     | NULL                |                |
| hostInit         | longtext      | YES  |     | NULL                |                |
| hostPending      | enum('0','1') | NO   |     | NULL                |                |
| hostPubKey       | longtext      | NO   |     | NULL                |                |
| hostSecToken     | longtext      | NO   |     | NULL                |                |
| hostSecTime      | timestamp     | NO   |     | 0000-00-00 00:00:00 |                |
| hostPingCode     | varchar(20)   | YES  |     | NULL                |                |
| hostExitBios     | longtext      | YES  |     | NULL                |                |
| hostExitEfi      | longtext      | YES  |     | NULL                |                |
| hostEnforce      | enum('0','1') | NO   |     | 1                   |                |
+------------------+---------------+------+-----+---------------------+----------------+
29 rows in set (0.00 sec)

MariaDB [fog]> describe userTracking;
+------------+--------------+------+-----+-------------------+----------------+
| Field      | Type         | Null | Key | Default           | Extra          |
+------------+--------------+------+-----+-------------------+----------------+
| utID       | int(11)      | NO   | PRI | NULL              | auto_increment |
| utHostID   | int(11)      | NO   | MUL | NULL              |                |
| utUserName | varchar(50)  | NO   | MUL | NULL              |                |
| utAction   | varchar(2)   | NO   | MUL | NULL              |                |
| utDateTime | timestamp    | NO   | MUL | CURRENT_TIMESTAMP |                |
| utDesc     | varchar(250) | NO   |     | NULL              |                |
| utDate     | date         | NO   |     | NULL              |                |
| utAnon3    | varchar(2)   | NO   |     | NULL              |                |
+------------+--------------+------+-----+-------------------+----------------+
8 rows in set (0.00 sec)

This query should combine the two tables into a report giving you the name of the computer and user where the user was reported between 01-Mar-19 and the end of the year.

select hostName, utUserName, utDate from userTracking left join hosts on utHostID=hostID where utDate between '2019-03-01' and '2019-12-31' and utAction=1 order by hostName,utDate desc;

If you want know the name of systems that haven’t checked in since 01-Mar-19 then this query

 select distinct hostName from userTracking left join hosts on utHostID=hostID where utDate < '2019-03-01' and utAction=1 order by hostName,utDate desc;

Now I don’t use the FOG client or snapins in my organization because we already had an application deployment tool in place (PDQ Deploy). Admin Arsenal also has a free version of PDQ Deploy that will work for your quest too. As for harmonizing your FOG client across the board you could use PDQ Deploy and create a batch file to remove the old fog client, flush the fog client directory and redeploy a new (current) fog client to all computers in your domain or selection list.