Best posts made by Joe Schmitt

Is auto updating not functioning?

That setting will configure the client to enforce the hostname / AD setting regardless of if a user is logged in. So if enabled, the client will restart the computer to update the hostname even when a user is logged in. If disabled, the client will wait until no one is using the computer before restarting to apply the hostname / AD.

Note that I am not sure if v0.9.X implements this feature, so altering that checkbox may have no effect until v0.10 is released

I found the issue, a fix has been pushed. A variable was misnamed. Soon as you apply the patch the clients will work again.

Greenfog on v0.10.6 does not work. When v0.11 is released, a new module will replace it to provide more functionality. (v0.11 is currently undergoing release candidate testing)

@Shenanigan88 To run an EXE with a snapin simply upload the EXE. EXE’s a native windows executables, so there is no need for a Run With or Run With Args. Granted, if your EXE needs some parameters (such as a silent switch), you’ll need to add them to the Args field.

I believe I have patched the issue. When you are available for teamviewer, PM me and I’ll test it.

v0.11.0 is released and fixes this issue. Can you test when you have a chance?

@Rlane could you send me the fog.log of a computer right after it does the user reboot? If you could also tell me at what time the user reboot happened so I can look at the fog.log at the time, it would help greatly.

@Wayne-Workman

@Matthieu-Jacquart is dead on, one way to think of it is:

{Snapin Run With} {Snapin Run With Argument} {SNAPIN} {Snapin Arguments}

So if you were to execute an msi via cmd, you would do:

msiexec /i MSI_NAME /quiet

This would break down into:
Snapin Run With: msiexec
Snapin Run With Argument: /i
Snapin File: The MSI
Snapin Arguments : /quiet

Is the service currently stopped on this machine?

We do not have this feature implemented yet, though perhaps we will for the next client release.The reason is that it has been such a low priority in out backlog that it simply hasn’t been focused on yet.

@midas1989 Your logs indicate this is for the legacy client. Mind posting this in a new thread?

Alright, its another race condition. I’ll push a patch tonight. Basically the power api was informing all other threads that it had initiated a shutdown/reboot before it actually did. Thus the main thread killed the whole process before the power api could actually restart.

@jkepple2003 just going to throw in my 2 cents here. Either use an LTS version of Ubuntu, or avoid it and use something like CentOS. Ubuntu has quick release cycles for their normal versions and doesn’t maintain support for their releases long enough to be considered a viable option for a server. In general Ubuntu is usually the source of a lot of trouble with FOG.

@Claude-Girard @Matthieu-Jacquart @Wayne-Workman @Trevelyan @Brian-David
I need the fog.log file from disappeared hosts (preferably relatively soon after they vanished). Logs from the new client will be most helpful.

@Wayne-Workman is the service still running after the dialog closes? I’m assuming its the same race condition issue.

@gretsch your issue the the legacy client’s PrinterManager should be fixed if you update your server.

I cannot replicate this issue. I’ve replicated your snapin configuration and it works fine. According to the log you posted, the issue is with a configuration on your computer, not the client (the return Code 1). Try running the command on the machine manually (using a local copy of your license.dat file).

This issue has been addressed in v0.11.2. Please test when you get a chance.

If you are using the client to join AD after imaging, do not join your image to the domain. More than likely that is causing your issue.