FOG 1.6 with fog-agent 0.1.6, agent renames all PC's to the same golden image name when not using sysprep

[rdr]

Hi,

I am testing FOG server 1.6 (latest) to use in our PC labs. Installed Windows 10 and all the required apps to the one of the PC’s (MMF-LAB2-00). Then imported all hosts with a simple CSV file (MAC,HOST NAME). Then installed latest fog-agent and approved it in FOG server UI. So far so good. I created a capture task and captured the image from the host MMF-LAB2-00. Then created a deployment task for the remaining PC’s. Deployments also worked without any problem.

The problem is after a few minutes, there appeared a popup messages on the desktops that is saying FOG agent will rename the computer with the name “MMF-LAB2-00”. And all the PC’s rebooted with the name MMF-LAB2-00 insted of their names on FOG server, MMF-LAB2-01, 02, 03 etc.

So what am I doing wrong here? Is sysprep mandatory for fog client? Why the fog agent does not poll the name that is matched with its MAC address in FOG UI?

Regards,

Rahman

[Tom Elliott]

@rdr the fog agent is brand new and is attempting to modernize how the client did things. I wasn’t fully ready for people to be testing it live quite yet, though glad to have people doing so.

I suspect the identity.json is from that of the original machine and it’s using that as the marker for all the machines you’ve deployed to. Since that identity was for that machine, all machines are currently thinking they are that machine.

[rdr]

@Tom-Elliott Thanks for answer. So do you suggest to use FOG client instead of FOG agent? Or use the agent properly? If I decie to use the agent, should I delete the identity.json file before capturing the image? Then I need to approve all the agents of deployed images after deployment tasks?

[Tom Elliott]

@rdr You found a real bug. Sysprep is not needed, and it would not have helped.

Cause: the image carries the agent’s key and certificate from MMF-LAB2-00.
The agent compared the machine’s SMBIOS identity with that key only when it
had no certificate. A deployed copy has one, so every PC connected as
MMF-LAB2-00 and took its name.

fog-agent 0.1.7, released today, makes the check on every start.

To fix the PCs you already deployed:

• Go to FOG Configuration > FOG Settings > General Settings and set
  FOG_AGENT_DESIRED_VERSION to 0.1.7. Every enrolled agent updates itself,
  including each PC that thinks it is MMF-LAB2-00.
• After the update, each PC sees that it is not MMF-LAB2-00, makes a new
  key, and enrolls as itself. FOG matches it to its host by MAC.
• If FOG deployed to that host in the last 24 hours, the enrollment is
  approved automatically. If not, approve it under Hosts > Pending Agents.
  The agent then renames the PC to its name in FOG.

Please post back whether the names come right.

[rdr]

@Tom-Elliott Thanks for the quick update. I set desired version and waited about 1 hour, restarted multiple times but it did not auto updated the agents. As this is a test lab, I updated to the latest agent v. 0.1.9 on the source PC and recaptured an image. Then redeployed. It seems the problem is fixed. There was another problem with agent 0.1.6, even the computer name changed, fog agent was continuaously logging pending reboots for host name change. Version 0.1.9 also seems to fixed it. Here is health log sample from one of working PC’s:

2026-09-14T13:41:42+03:00 service started
2026-09-14T13:41:42+03:00 this state was made on another machine (a cloned or reimaged disk); generated a new key and enrolling as this machine
2026-09-14T13:41:43+03:00 enrolled as host 1, certificate valid until 2027-09-14 10:41:44
2026-09-14T13:41:43+03:00 facts: sending inventory=true software=39 directory=true printers=1 network=1
2026-09-14T13:41:44+03:00 host 1 (LAB-01-001), server capabilities: [hostname taskreboot snapin software power autologout directory printers wake update]
2026-09-14T13:41:44+03:00 hostname: unchanged (LAB-01-001)
2026-09-14T13:41:46+03:00 snapin "Windows SSD TRIM" (task 8): ran, exit 1, outcome failed (At C:\ProgramData\FOG\agent\snapins\8\trim_ssd.ps1:101 char:68
)
2026-09-14T13:41:46+03:00 power: on-demand reboot accepted
2026-09-14T13:41:46+03:00 update: deferred, a reboot is pending
2026-09-14T13:41:46+03:00 reboot: applied (1 user(s) logged in, 60s warning (power: on-demand reboot), mode reboot)
2026-09-14T13:42:48+03:00 service stopped
2026-09-14T13:43:31+03:00 service started
2026-09-14T13:43:31+03:00 host 1 (LAB-01-001), server capabilities: [hostname taskreboot snapin software power autologout directory printers wake update]
2026-09-14T13:43:31+03:00 hostname: unchanged (LAB-01-001)
2026-09-14T13:43:32+03:00 update: unchanged (already v0.1.9)
2026-09-14T13:48:32+03:00 host 1 (LAB-01-001), server capabilities: [hostname taskreboot snapin software power autologout directory printers wake update]
2026-09-14T13:48:32+03:00 hostname: unchanged (LAB-01-001)
2026-09-14T13:48:32+03:00 update: unchanged (already v0.1.9)

Thank you again for your help and quick updates.

[Tom Elliott]

@rdr 0.1.8 introduced rolling update patterns where 0.1.6/0.1.7 did not have them quite yet.

Thanks for letting me know about the reboot issue you were seeing and that the updates seemingly fixed.

You can unset your “desired version” on the hosts and configure your global settings:

FOG Configuration -> FOG Settings -> FOG Agent.

FOG_AGENT_DESIRED_VERSION is now meant to be a “Pinned” update version so you can maintain (in fleet, or per host - per host winning of course) what versions your environment is using.

FOG_AGENT_UPDATE_MODE is a selector for Pinned, Latest, No update. By default it’s disabled just in case. Since the FOG Agent is still very new, this may be a good setting to ensure reporting and testing.

Documentation on all of this is on docs.fogproject.org.

https://docs.fogproject.org/en/latest/management/web/agent-self-update
https://docs.fogproject.org/en/latest/kb/reference/fog-agent-reference
https://docs.fogproject.org/en/latest/tags/agent

[rdr]

Also other small problems:

1. FOG server WEb UI - > all hosts list does not show last check-in time, its empty for all hosts.

2. Uploading new file to existing snapin and saving it (press update button) does not update “Snapin File (exists)” input value, a CTRL + SHIFT + R updates it with correct value.

[Tom Elliott]

@rdr Both things should be fixed:

The “empty” Last checkin you saw was from the Legacy Client checkin time which itself is relatively new.

Added a specific Agent check in column.

Also should fix the issue with selector drop down updating on snapin update with a new file.

Please update and test.

Thank you!

[rdr]

@Tom-Elliott updated, both problems fixed. Thank you. One other feedback about installer script. Every time I run it, it notifies about modified pxe files and about keeping modified versions, even though I did not touched or modified any of them:

| next-server is already set to this FOG server (10.0.1.92).
 * Downloading iPXE binaries (v2.0.0-fog.8)....................OK
 * Kept your own copies of these iPXE files (not overwritten):
     secureboot/autoexec.ipxe
     secureboot/arm64-efi/autoexec.ipxe
     autoexec.ipxe
     arm64-efi/autoexec.ipxe
   Delete one to have FOG's version installed on the next run.
 * Configuring default iPXE file...............................OK

If I delete the corresponding files and rerun the installer, it does not complain about my own copies. But if I rerun it without doing anything, it complains about pxe files again. Is this harmless or it will not download new pxe files even it should, as it thinks I modified them.

BTW, is it OK that I am writing here? I can open separate topics here for each problem I encounter or I can open separate issues on Github.