@ITCC this would definitely be a feature request. Power Management takes the approach of “If the user is away, they get logged off, and the machine is shut off”. You may be better off to use either GPO or snapins to achieve this. For example, schedule a CRON snapin that just checks if any users are logged on, otherwise it shutsdown.

@justeverything thats good. That means certificate pinning worked. Simply go to the host in the web portal and hit “Reset Encryption Data” and it should work fine now.

It would seem your issue was with recent builds of mono.

@justeverything active (exited) is fine, that’s just how the client wraps itself around the various linux service controllers. Whats; more important now is the log file.

@justeverything alright, can you test the older mono build then? So `

• sudo apt-get remove --purge mono-complete
• sudo rm /etc/apt/sources.list.d/mono-xamarin.list
• sudo apt-get update
• sudo apt-get install mono-complete

And then re-test installation. (Also re-run the version command and report which one is now installed)

@justeverything you can run this command: sudo setenforce 0 to temporarily set SELinux to permissive. After done testing with it, run sudo setenforce 1 to set to back to enforcing.

@justeverything so this is definitely a dependency issue here. Either there’s a bug in the recent builds of mono with Ubuntu 16, or some service is blocking the certificate pinning on this machine.

Could you try: removing the service, setting SELinux to permissive, and re-installing?

If that doesn’t work, goahead and re-enable SELinux, and try an older mono build (perhaps using the stock mono build provided in ubuntu repositories).

@justeverything it should be fine the way you did it. What’s the mono version installed? Run mono --version.

@justeverything it seems you have a foguser on the machine? The client must be installed and run as root, and root only.

The issue according to the logs is that the installer was unable to pin the needed certificates (these are used for the security model). It would also be helpful to know what version of mono you are running.

@adukes40 PDQ actually posted here about it: https://forums.fogproject.org/topic/9577/webcast-imaging-with-fog-managing-with-pdq

@justeverything If you install the FOG client on your linux image, you can use snapins to run a bash script that joins a machine to your domain (snapins automatically get deployed when a host is imaged).

@Joe-Gill https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#MSI_Switches , and you can use whatever you prefer to deploy the MSI (GPO, PDQ, remote powershell, …)

@jbrabhamMSD to be clear here, you just upgraded from 1.2.0 to 1.3.4? And it was the legacy client installed on the problematic computer and not an old version of the new client?

@Smennywheek to debug the client, look at / provide the C:\fog.log file on the host with issues.

@george1421 the FOG client should never be set to run a domain user. The client’s security model relies on the assumption of running as SYSTEM/root. In addition if the client runs a domain user then it will not be able to rename, join, or leave a domain. Since when the client needs to temporary leave remove a machine from the domain, the client would loose all privileges.

Ultimately the client may or may not work as non-SYSTEM users, but its not something we recommend or will officially support.

@maxiecool2 as for the search function, I’m assuming you’re on mobile, since there’s a search box when you visit the forums on desktop. You can use our search function on mobile here: https://cse.google.com/cse/publicurl?cx=013831856522586480408:mlbymhymgxs&q= , it will search both the forums and wiki.

@ablohowiak for both your cases, it would work best (and probably quickest) if you had/made a simple CRON script that runs the appropriate SQL commands. Not every user would want/need these features, and in general we take the approach of not making assumptions of what data users need to keep.

@Wayne-Workman you can make it a hyperlink: e.g. this thread

@lebrun78 We had no idea this wasn’t a windows network share (if you already mentioned that, I overlooked it, sorry). Most people use them, so we assume that by default. I may be wrong here, but that would point to more of a script issue. I think @JJ-Fullmer is working on a post in this thread about mounting a share in powershell using SYSTEM. It could also be how you get your Certificate from the cert store (cert:\CurrentUser\TrustedPublisher). SYSTEM is sometimes not considered a user, and is instead considered the LocalMachine in the cert store. Basically I would recommend adding some debugging statements to your script and see where its failing (e.g. if its getting the cert correctly, or if its just the mounting code thats going wrong).

@lebrun78 that indicates it’s a network share permission issue or a script issue, as we have been saying. While that may work, you have to alter every machine and is a work-a-round for the underlying issue. If its a network share permission, fixing the network share permissions to allow for SYSTEM access (even if just to a single public folder) is the route we recommend. If its an issue with how you mount/decrypt your share, then it just needs to be made SYSTEM compatible. The client was built with SYSTEM permissions in mind, and therefore I cannot vouch for the security, or functionality, of the client running as a different user.

@x23piracy when you update, the keys the client uses to authenticate are also regenerated. So even if there was a time difference of even a minute or a few seconds could cause this issue. But as you stated, it fixes itself after the client catches up in time.