@sourcaffeine said in FOG Client Not Working:

I am not exactly sure what was different but it seems to be working now without issue on the workstations with a new image with a new copy of the fog client installed.

The re-install does something very important. It pins to the current FOG server certificate and downloads the right FOG Project CA cert as well.

@sourcaffeine

Moved topic to Windows problems. Please advise if you’ve found a solution to this or are still having the problem.

@george1421 I prefer /etc/sysconfig/network-scripts/ifcfg-xxx now after I learned more. Before that yes I clung to the cli graphical tool for dear life.

@Tom-Elliott 46MB

@sourcaffeine I’ve updated the FOG Client article to include a section on polling, here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Polling_Behavior

For why the legacy client is still being used - it’s so people can transition more easily. If there was no ability to transition easily, people would have more work to move to the coming 1.3.0 release. For example, imagine an organization with 10,000 computers, all have the legacy client installed, and they are using a 1.2.0 server. Do you think they will just move to 1.3.0 if 1.3.0 could not control the legacy client? No. Because the FOG Client might be a vital piece of their management. You don’t just image 10,000 systems at once, you image some at a time and move to the new client as you can. And if 1.3.0 can’t control the legacy client, then those people would have a huge gap in very needed management capabilities. How would people do something as simple as schedule an imaging task, if the existing legacy client cannot be ordered to reboot? Should we force people to use outside software like active directory, group policy, or something else? No. We provide a pathway in fog, anything less would be unacceptable.

Never could figure this issue out. Went ahead and installed 14.04 and upgraded to trunk, and it all went smoothly.