@PeterAxis

@Wayne-Workman provided a recommendation on upgrading to the latest version of Cent OS. That is not critiquing. Secondly, the solution to your problem was the first post on this thread, thanks to @Tom-Elliott. A bug was found in the latest release with CentOS 6, and was patched in our current RCs.

To be blunt here, providing unneeded hostility does not help. We’re a completely free open source project developed and supported by people donating their spare time because they want to help further FOGs goal. Our documentation is mostly community built; if you see an issue with it, politely report it or even request wiki write access and help fix it.

@Tim-M youll need to look under the Wow6432Node for the key mentioned before, assuming your machine is 64 bit.

If you can wait a day or so, I’m finishing up a snapin that you can deploy to legacy clients, and it’ll auto upgrade them to the new one (assuming everything works properly), or it can be deployed via GPO.

@x23piracy oh well that would explain it. Manually removing the client requires a reset encryption, and manually installing the client will not start the user agents until next reboot. The only recommended way to update the client is by letting it auto update itself.

@x23piracy can you try the snapin again? If it still messes up I need the fog.log. Though more than likely it’s not an issue. See, in order to show the shutdown prompt, the fog service needs a user agent running per each user (the FOGUserService). During updating this agent is temporarily stopped, and can take a couple minutes to start back up after the update is already finished. If the snapin was scheduled in that time period, no prompt would be shown.

@x23piracy this has been patched in 0.11.10, which will be available in the next server RC/release.

@x23piracy issue confirmed. I’ll patch it when I get some spare time later this week.

@thisisryanswift from FOG’s perspective there is little to no difference between a Windows 10 home edition versus a Windows 10 enterprise edition. You can absolutely clone it, and the client will be able to manage it. The only limitations you will hit are ones with the features (or lack thereof) of Home edition. For example, I’m fairly certain at least Pro edition is required to join a computer to a domain.

@Kleber while we do try to maintain legacy client compatibly, we only do so to help those transitioning from 1.2.0 to 1.3.X. Legacy client compatibility is not something at the top of our backlog, and is often an pain to deal with simply due to how the legacy client was designed. In the future, legacy client support may be completely phased out as well.

We’ll still try to patch these issues, but ultimately you should be switching over to the new client.

@lebrun78 snapins run as SYSTEM (this is like a limited root on unix). If a script works when run manually but not as a snapin, then your script is not SYSTEM compliant. Usually its an issue when someone tries to use network shares, which it appears you are doing. SYSTEM is an non domain user, so if your network share requires someone to be domained user to access it, that’s one potential issue. Ultimately this is a network share issue, and without see exactly how you are mounting / using it, we cannot help.

@jackiegl3350n well that looks right. It’s definitely some configuration issue somewhere. I’m assuming the client wasn’t already installed on these machines? Could you also try issuing a key regeneration? (sudo installfog.sh --recreate-keys).

@jackiegl3350n Can I see a screenshot of the configuration page of the installer just to double check everything is correct? Feel free to PM me a link to it, if you don’t want to post it here.

@jackiegl3350n what OS are you trying to install the client on?

Also you can test if the settings are right by opening http://{fog-address}{fog-webroot}/management/other/ca.cert.der, and replace {fog-address} with your fog server’s IP, and {fog-webroot} with the webroot (usually just /fog). So an example url would be: http://{xxx.xxx.xxx.xxx/fog/management/other/ca.cert.der. And if the server is setup correctly, you should download a public certificate file.

@wernercd it is worth noting, with the new client rebuilding it is no longer needed. And if for some reason you still need to, there’s automated build scripts available: https://github.com/fogproject/fog-client#building

@Wayne-Workman no reason to have it be a torrent, we can just host it on our public servers, and not have to worry about seeders.

@Omar.rodriguez, alright that’s what I suspected when I saw all of the macs. The problem is your installations share the same virtual mac addresses. You can fix this problem by telling FOG to ignore those macs. To quote @Tom-Elliott from https://forums.fogproject.org/topic/8315/response-error-multiple-hosts-returned-for-list-of-mac-addresses

The fix for this is to add that mac address to the FOG Configuration Page->FOG Settings->FOG Client - Host Register->FOG_QUICKREG_PENDING_MAC_FILTER, you can add the whole mac address or a part of the mac address. Using the “partial” address (usually the first 3 or 4 hex pairs) means it is going to filter anything that matches the partial part. This is comma separated. e.g. (00:01:0F,00:02:03:04,00:05:ab:af:ad:ac).

@Omar-rodriguez it can be found by either selecting a host or a group from the web portal:

@Faheem FOG 1.3.0 has no official API (Our 2.0 rewrite changes this, but it’s not ready for production). A quick look over that github repository seems to indicate that the api-wrapper simply crawled / interfaced the web portal, which has definitely changed in the past 3 years.

@Omar-rodriguez correct. That’s why I asked

could you try hitting Reset Encryption Data on the host in the web portal? Also is there a reason why so many network adapters (virtual or real) are present on this machine?

What you’re describing is usually just a symptom of a bad authentication handshake.

@Omar-rodriguez could you try hitting Reset Encryption Data on the host in the web portal? Also is there a reason why so many network adapters (virtual or real) are present on this machine?

@Omar-rodriguez please provide the fog.log file for the problematic host. It can be found in /opt/fog-server/fog.log.