@Fog_Newb The per-node ports change has landed: https://github.com/FOGProject/fogproject/pull/2062

Each storage node now has an SSH Port field and an FTP Port field in Storage Node Management. If you leave a field blank, the node uses FOG_SSH_PORT or FOG_FTP_PORT. If that setting is not set either, it uses 22 or 21. Every SSH and FTP connection to that node uses its port. That includes the capture move, replication, snapins, the file deleter, the log viewer and the dashboard check.

It is on dev-branch now, and it reaches stable with the next stable update, along with the exports and key changes. On your single server, the global setting you already have is enough.

@Tom-Elliott All good! Thank you and keep up the awesome work!

@Fog_Newb Thanks for the detailed report. Your diagnosis was right on all three points.

1b, runs a day late: the chart read TIMESTAMP columns as DATETIME. In the 26 hours after the move to UTC, that made a UTC time look like New York time. Your fix is in, and it covers the imaging, storage, inventory and fleet charts. This one also corrects itself once the 26 hours pass.

1a, 1.5 history missing: the upgrade added the image name column but did not fill it on old rows. A new schema step fills it from the task’s image. A run whose task or image was deleted cannot be recovered.

2, the tooltip: the asterisk on new captures is expected for the first 26 hours, and then it goes away. The tooltip wording was wrong. It now says the value “can be in America/New_York time or in UTC”.

PR: https://github.com/FOGProject/fogproject/pull/2056. It reaches the Patches channel when it merges to dev-branch. Run the schema update after you update, so the history backfill runs.

@fgaudin Thanks, that output finds the cause. It is a bug in the 1.5.10.2482 installer.

The old IP address comes from /opt/fog/snapins/ssl/.srvpublic.crt, not from req.cnf. That file is the source of the published srvpublic.crt. When the file exists, the installer keeps it, even with -K. So -K made a new key, but it published the old certificate again. That certificate has the old IP address and the old CA. It also does not match the new key. FOG 1.6.0 fixes this: it removes a certificate that does not match the key.

The /etc/sudoers.d/fog-secureboot.tmp error has a second cause: sudo is not installed on your server, so /etc/sudoers.d does not exist.

Do these steps on the server:

Install sudo: apt install sudo Remove the old certificate: rm /opt/fog/snapins/ssl/.srvpublic.crt Run the installer without flags: ./installfog.sh -y Run the check again. It must say OK:
openssl verify -CAfile /var/www/html/fog/management/other/ca.cert.pem /var/www/html/fog/management/other/ssl/srvpublic.crt

You deleted .fogCA.key and .fogCA.pem, so the server has a new CA again. On each client, delete “FOG Server CA” in certlm.msc again, then restart the FOGService.

If step 4 does not say OK, post its output and the Creating client communication certificate lines from foginstall.log.

@astrugatch Short answer: no, the existing FOG Client does not pull the agent by itself. You push the agent with the tool you already use to deploy software.

What happens when you upgrade the server

Your legacy FOG Client installs keep working against 1.6. The server still serves the legacy client endpoints, so you can run both while you migrate. Nothing on the server needs to change first. Hosts, groups, snapins, printers, power schedules and module settings all carry over. The legacy Client Updater module is gone in 1.6. So the old client cannot update itself into the agent. The FOG server does not host the agent installer. It comes from the GitHub releases page: https://github.com/FOGProject/fog-agent/releases/latest

How to move a machine to the agent

Install the agent MSI on the machine. The MSI finds the legacy “FOG Service” and removes it for you. Do not run the two side by side.

For a silent push (GPO, PDQ, SCCM/Intune, or a script):

msiexec /i fog-agent-<version>-x64.msi /qn SERVER=https://your-fog-server/fog CAFINGERPRINT=<fingerprint> TOKEN=<token> /l*v C:\fog-agent-install.log SERVER is your web UI address with /fog on the end. Old scripts that use WEBADDRESS and WEBROOT still work. CAFINGERPRINT is the SHA-256 on the Root row of FOG Configuration → Certificates. Leave it out if your web UI uses a public or corporate certificate that the machines already trust. TOKEN is optional. Create one under Hosts → Agent Enrollment Tokens. With a token, the host enrolls with no click. Without one, each host waits under Hosts → Pending Agents until you approve it.

The FOG Client page in the 1.6 main menu shows the same command with your server address already filled in.

Images

You can put the agent in your image. Capture the machine as it is, no sysprep needed. A deployed clone detects that it is a different machine and enrolls as itself. If FOG deployed to that host in the last 24 hours, the server approves it automatically.

Docs

Install and migrate: https://docs.fogproject.org/en/latest/installation/client/install-fog-agent (see “Moving from the legacy client”) What changes for an admin (printers, AD join, user tracking): https://docs.fogproject.org/en/latest/management/web/fog-agent Reference: https://docs.fogproject.org/en/latest/kb/reference/fog-agent-reference Troubleshooting: https://docs.fogproject.org/en/latest/kb/troubleshooting/fog-agent-troubleshooting

If an install fails, post C:\ProgramData\FOG\fog-agent.log and the msiexec log here.