@Wayne-Workman setupcompletes are .cmd he probably had .bat

@Wayne-Workman if there’s enough demand for such a snapin I can make it (It just requires some know-how concerning the design of the legacy and new client).

@palloquin selinux should be left permissive. Disabling it is strongly advised against, since it requires a bit of work to properly enable selinux once disabled.

@palloquin how did you set SELinux to permissive mode? To repeat, permissive mode will absolutely work if completely set.

To expand why disabling SELinux is not advised: SELinux works by labeling files on your system. In permissive mode the labeling still takes place, but no policies are actually enforced. But when you disable SELinux that labeling system is shut off. To re-enable SELinux once disabled, it’s going to take some time. You would first have to set SELinux back into permissive mode (NEVER set back into enforced once disabled unless you know SELinux well). Once your kernel boots back into permissive mode, you would need to initiate a full filesystem relabeling which can take some time. Once that finishes you can finally safely enable SELinux.

@palloquin alright. I ask because the output of your sestatus command indicates some modifications of other selinux files (e.g. /sys/fs/selinux/deny_unknown and /sys/fs/selinux/mls). In general all that is needed to make SELinux permissive is to run:

• setenforce 0 to set the runtime selinux enforcement policy
• Edit /etc/selinux/config to read SELINUX=permissive instead of SELINUX=enforcing

But since selinux was already disabled, there’s no point in doing this now (your server setup will be fine and everything should work as normal). I do want to point out though to any @Moderators who maintain the wiki that tutorials should not instruct users to disable selinux, but instead set to permissive.

@rstockham23 @george1421 the 10 minute wait period is not normal.

@rstockham23 after all of the reboots are completed, can you try an additional reboot and see if the client still takes an unusually long period of time to startup?

@asbenavides

 1/31/2017 2:28 PM Middleware::Response Invalid security token

You need to hit Reset Encryption Data on this host in the fog web portal.

@asbenavides Firefox does not publish MSIs for their software. Firefox’s offline exe installer already has a silent mode: setup.exe -ms (assuming it hasn’t changed). Or see if that place offers an offline msi, and not a stub. Ultimately however, this is no longer a client issue.

@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 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.

@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.

@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).

@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)

The first place to look for client issues is your c:\fog.log file on the problematic host.

@oraniko said in office snapin problem:

and the office is not being installed on the target machine.
another thing is that when i click to see the snapin, then the snapin pack template is changed to the default option, when i try to switch it back to EXE and press on update, it change again to the default option “pease select an option”

Templates don’t “stick”. That is, when you click a specific template, it just sets the fields to some defaults, and that’s it. It doesn’t remember which template its using since you could change any one of those fields.

@oraniko if you use a Snapin Pack like you are now, then you can directly call the exe. @KnightRaven was talking about if you used just a regular snapin and hosted the office files on a network share.

@kylebeth94 the client does not follow 301 / 302 http codes (redirects). I run one of my development servers on https, and with a webroot of /. You’ll need to configure your webserver to serve out / without using redirects. You can redirect http to https traffic if you desire, but just make sure the client is set to use https then.

@jbrabhamMSD I’d need to remote into a problematic machine to identify why the new client still thinks the legacy is present. Send me a PM and we can work out some time that works for both of us sometime next week if it’s alright with you.

@Warget like @Scott-Adams mentioned, WSUS is specifically built to handle exactly this. However, if you really want to use a snapin, look into using a powershell script for the easiest approach (https://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc is a good library). As for .dmgs, as long as OSX is running the client, you can make a bash script do it (e.g. http://stackoverflow.com/a/22940943) inside of a snapin pack.

@anthony-delarosa in my opinion your best approach would be to have a script setup or something that changes the hostnames in the SQL database. For example if you wanted to slowly roll out the changes, the script could do 50 at a time, or it could wait until sunday night and then do all of them at once. Once changed in the DB, the fog client would receive the new hostname and apply the change almost instantly.