@Greg-Plamondon honestly I would not recommend switching to the working branch. There is no guarantee for it to be stable, infact it’s the opposite. I’d expect the working branch to be unusable fairly often.

@Shiigehiro strange, the forum is showing that your email is validated. You should be fine, if it gives you any issues send me a PM and I’ll look into it more.

@JackieJack all the computers would download the 8GB and run it locally

@JackieJack A newish feature (as of 1.3.0+) called Snapin Packs would be perfect in this scenario. Basically you zip up all the files matlalb needs, set the snapin pack to run the setup exe inside, and that’s it. You can checkout the documentation about it here: https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks

@DarkStorm007 the maintenance pop-up can be re-branded via the web interface. The FOG banner image can be replaced with your organization’s, the color scheme changed, and the FOG text replaced with your organization’s name. The pop-up should also be automatically in Spanish, assuming that is what the system language is set to on the computer.

@Wayne-Workman that error is the final fail safe to ensure a malfunctioning module can’t bring down the service by accident. @kafluke can you do what @Wayne-Workman asked in regards to getting the file permissions?

@TrialAndError we need a lot more information. For example what anti virus are you using? Do you have any restrictive policies on these computers? Any custom software that blocks shutdowns, or isn’t programmed correctly to handle them?

The error log indicates that the win32 api for shutdowns is being blocked. You should check the windows error log for potential messages. We also need to know how you got the client onto this computer. Did you image with it installed? If so did you use sysprep?

If I had to guess without any of that info, I would say it’s likely an antivirus program ignoring the clients valid binary signatures. But I would need more info to help beyond that.

@Greg-Plamondon what is the fog client error?

@Cap_Jak It’s back online, thanks for letting us know.

@george1421 It would be best if we modeled how forwarding tables work; Longest Prefix Match. Its a fairly intuitive way of handling multiple CIDRs that may overlap, and is the standard.

Implementing this optimally is fairly straight forward as well, in fact I’ve done so before in other applications. All the “heavy lifting” should be done by the backend, as it will know the host’s IP from the HTTP request, and can quickly perform a longest prefix match on all registered CIDRs.

@Wayne-Workman I agree, this could be a very useful feature. Though it would be best to have the CIDR conversion and mapping done entirely on the backend, and not in FOS. @Tom-Elliott thoughts?

@jones We have updates the kernels, if you update your copies of them it should work.

@Scott-B the address is stored in the settings.json file, as long as the new address its being pointed to has the same certificates (if its the same server then all is good).

I’m not sure how well this would work, but you could try using a snapin, that changes the files, and reboots the machine. I’d suggest trying it on one machine first and see how it goes.

@Tom-Elliott

05/12/2017 18:56 Middleware :: Communication ERROR: Failed to POST data
05/12/2017 18:56 Middleware :: Communication ERROR: The remote server returned an error: (417) Expected Failed.

@88fingerslukee after double checking, the FOG Client does not force log offs; this means that any other user process can stop the log off. This indicates the problem is likely another program on the computer, that or a GPO policy is blocking it.

Could you try running:
shutdown.exe /l manually on a problematic machine and see what happens?

However, ultimately I would recommend using GPO to handle inactivity log outs. There are some known restrictions with the log out module (https://github.com/fogproject/fog-client#autologout)

@88fingerslukee, @Wayne-Workman helped me out with testing; we are unable to recreate this issue on Windows 10. Do you perhaps have a custom antivirus running, or some GPO policies?

@Brian-David well this is certainly strange. This is the best theory I can think of:

• Is one of the snapins specifically to blame? You state that this only happens when you run “All Snapins”; from the client perspective this is no different then running them individually. Are you running all of the snapins individually, and this issue is not present then?

If this is not the case let me know, and I can walk you through using the client’s debugger, it should help narrow down the issue pretty quickly.

@Wayne-Workman unfortunately we will not add this. The ssl directory where your private keys are stored, and should never be accessible via the web GUI. That presents a massive security risk as a single bug in the web GUI could provide anyone with access to your private certs; arguably the most sensitive data on the server.

As the saying goes, security and convience are usually at opposite ends of the spectrum; and this is one thing we will not compromise on.

Exporting your keys as root using ssh is the preferred, and only way, we will support.

@Joseph-Hales the new client always shipped with plain text passwords as the security model is fundamentally different.

@Sebastian-Roth @Joseph-Hales theinvalid time comes from creating the user-cache, specifically the auto log out time.

The client logs show the error:

11/28/2017 1:40 PM HostnameChanger Logon failure: unknown username or bad password, code = 1326

So the credentials are not set correctly on the server. A couple ideas:

• Is the AD password field for the new client filled in (the legacy client uses a different field)
• Are you placing the FOGCrypt version of the password in field? The new client does NOT use FOGCrypt, and the password should be entered plain-text.

If you are sure both are correct, I can provide instructions how to use the client’s debugger to find the exact issue.