@kyle.heath here’s my 2 cents. Your script should look like:
...
sc config FOGService start= auto
shutdown -t 0 -r
as described in https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep Having any other setup in your script to start the client is not advised as it creates race conditions.
Now, if after that the domain joining still does not happen (will take a couple reboots), post the C:\fog.log file from the host.
@Sebastian-Roth @x23piracy @Polii123 change made, thanks for the feedback!
@x23piracy @Sebastian-Roth @Matthieu-Jacquart I finished i18n support. Can you confirm these are correct?
fr-FR (French)
de-DE (German)
@x23piracy / @Sebastian-Roth (both possible german translators) @Matthieu-Jacquart @Quazz I have updated the original post with a list of phrases. When you translate, please put the language above the phrases, and leave the phrases in the original ordering and format (basically just copy and paste the phrase list, replacing text), this will help me greatly.
@x23piracy could be that our auto-renew scripts are running a tad late. I’ll look into it.
TL;DR: Messages on the user desktop could be done, login screen is not possible. However, FOG 1.3.X is no longer adding features as FOG 2.0 is under way
Detailed explanation:
In the days of Windows XP what you want would certainly be valid (infact the legacy client took advantage of this). However, since Windows XP Microsoft has introduced something commonly called Session 0 isolation. Session 0 means the “root” account (or SYSTEM) is running the process (the fog client is one such Session 0 process). The main issue session 0 isolation fixes is un-authorized process elevation. Let’s pretend for a second that the fog client could infact open a UI on the user’s desktop from SYSTEM. This means that your regular old user now has access to a UI that has unrestricted access. That means if the UI can be exploited, a regular old user could do some massive damage to your system. This is why snapins are prohibited from showing any kind of UI.
The client works around this Session 0 isolation by having “user agents” run. That is, whenever a user logs in a FOGUserService is spawned in the user’s session. Then the Session 0 service communicates with the user agent as basically a relay. Need to spawn a shutdown prompt? Send a request to every user agent running to do it on our behalf. So sending a message to the user desktop is certainly possible, but at this point we aren’t adding new features.
So with that said, we could certainly display some message on a logged in user’s screen. But for the login screen? That would need some heavy integration with the Windows interactive Logon Architecture, which requires a massive amount of work, or for the Session 0 isolation to not be present.
@mtanigawa if you’re hard coding the credentials in the snapin, there is another option. You can set Snapin Arguments Hidden and put the password in the script’s arguments, that way the password will never be stored on disk, only in RAM for a very brief amount of time.
@davidedpg10 according to those logs user tracker is working properly and client updated is disabled. (User tracker only logs something when a login or logout event is detected). And client updated will only log something when an update is needed (and client updated is enabled).
As for the JIT message, that happens on every client startup to speed up things like the shutdown prompt’s response time. It does not install the old version of the client.
Could I get the full fog log from this computer? And could you double check on GPO? Generally whenever we see this issue there is a client policy somewhere.
@tom-langenfeld could you try running sudo service apache2 stop ? What happens?
@tom-langenfeld is this a fresh installation or an upgrade? What operating system is on the server? Is the server a fresh installation of the OS or was the server already responsible for something? We need more information.
@Olduser /c is the correct argument. C:\Program Files\FOG\tmp is a temporary folder, as soon as the client is done processing your batch script, it gets deleted.
@sudburr If you’re crazy you can also use the legacy client to upgrade to the new client. Basically you’d make a snapin that immediatly backgrounds another script and exits, so the snapin is “completed” but your backgrounded batch script is actually performing the upgrade process.
@afriedman Nope, the program will simulate a computer booting up requesting PXE information and capture who responds and with what.
@Olduser the network share must be configured for anonymous read access, not the snapin file, because the unauthenticated SYSTEM account executing your batch script must have rights to read your restricted share.
@Olduser the log indicates the batch script ran, and you stated:
copy 2 files from network drive
Remember that snapins run as SYSTEM. You have to configured your network shares to allow SYSTEM access to it (often called anonymous read), since SYSTEM is not technically a domain user or any other type of user you would have given read access to. Often what people do is make 1 folder in the share anonymous read and use that, OR use snapin packs to deploy the files and skip the network share altogether.
@Olduser please check out the Snapin Template drop down. Simply select Batch Script and all of the fields will be taken care of for you (minus the file of course). Normal snapins do not use [FOG_SNAPIN_PATH] as there is nothing to extract.
@Wayne-Workman %~dp0 includes the trailing \
@dureal99d you can skip the extra file altogether. I just looked at your script and you’re just using VBS to wait, which can be done in batch natively:
timeout /t 5 /nobreak
@dureal99d On a side note, your batch script is just creating a visual basic script and executing it. Why not just deploy a VBS in the snapin pack and skip the whole batch script work-a-round? The point of snapin packs is to let you bundle multiple files / scripts together.
@Tom-Elliott Logout is not “beat the clock”. User tracker’s code has not changed since sometime around 0.10.0.