Best posts made by Joe Schmitt

@AngryScientist that log indicates your client is not authenticated with the server. To fix this, go to the host in the web portal and hit Reset Encryption Data.

@martinm v0.10.0 of the client (osx and linux support) currently has a release candidate being tested by the development team of FOG.

@JJ-Fullmer it wouldn’t solve your issue. SYSTEM can’t interact with desktop sessions on newer windows versions. Its a security concern and is strictly prohibited. No amount of wrappers will circumvent that.

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

Some info for people experiencing high loads:

v0.10.0 of the client (currently undergoing release candidate testing) drastically cuts the amount of traffic used. In the “heaviest” cycle, the client will only make 3 requests. 1 to authenticate, 1 to get module settings, and 1 to get server settings (cycle time, client version,…). It also prevents run-away authentication, where the client had the potential to constantly spam the server’s authentication method.

Hopefully when v0.10.0 is released it should resolve any load issues. However, more than likely v0.10.0 may contain several bugs as the entire code base has changed to support any OS, and a completely new middleware API has been made to support the decrease in traffic. Since so much has changed, its almost guaranteed that I will have overlooked some minor things.

Just throwing in my support for this feature too. @Tom-Elliott.

@Wayne-Workman %~dp0 includes the trailing \

If you can wait until Tom gets around to pushing 0.10.4, it should auto repair all of hosts when you upgrade. (Keyword being should. It depends how damaged the 0.10.3 install is)

We designed the auto update system to be completely independent of server authentication in 0.10.X for scenarios just like this. Even though the client won’t take commands from your server, it will still process FOG Project update requests.

Nope. If it was server agnostic then what we have created is a rootkit capable of being hijacked by anyone.

What would be better is if you setup your certificate heirachy. In an ideal world (I.e. fog 2.0) storage nodes would receive a key from the server that allows clients to connect directly to it. For 1.3.0 you would need to manually set it up so all storage nodes have the same root CA keg and then call the SSL regen command. You could also setup intermediate CA keys for the storage nodes if you wanted to do it properly and remove some of the security issues of the desribed method above.

@RobTitian16 why do you have: <Domain>.\</Domain> ? Also look at this thread: https://forums.fogproject.org/topic/9394/trying-to-sysprep-windows-10-to-upload-to-fog-please-help . The user had a very similar issue (boot loop due to a bad unattend file), there’s several Windows 10 unattend files posted from various users in our forums.

@chamzod @Vanlue-IT-Guy If you update, v0.10.5 should fix this issue. Windows XP support was added to ensure maximum compatibility on all Windows installations.

@davidedpg10

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.

@oraniko you need to keep in mind the client runs as Windows service, which gets run as SYSTEM (that is, a non-interactive user). This means you’ll need to take non-supported approach to get this working. Change
net use r: \ph.ph.biu.ac.il\Programs MYPASSWORD /user:DOMAIN\MYUSERNAME
to
net use r: \ph.ph.biu.ac.il\Programs MYPASSWORD /user:DOMAIN\MYUSERNAME /persistent:yes

Now, you need to keep in mind SYSTEM now owns this network mapping, and so only SYSTEM can remove it. In addition, Microsoft doesn’t really support this, so its likely the drive will show as disconnected for all users, but it should still be accessible if they try to open it.

Perhaps a better approach would be to make a GPO logon script to auto mount these network shares.

@RipAU v0.10.5 is released. As long as your “broken” clients still have our FOG Project certificate installed, they should repair themselves. If they do not, you can simply run the v0.10.5 msi via a script and it will manually upgrade the broken installation that is running (you’ll still want to either restart or manually start the service when done). No need to first uninstall v0.10.3 now.

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

@Troye-Johnson this issue is patched in v0.11.12.

Also, right click “My Computer” and go to properties. Check the computer name field. What does it say? If it says (Will change to xxxx after restart), please upload the entire fog.log file

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

@tomtom what os is the client on? When did reg edit snapin a stop working?

@fry_p said in Snapin script interrupted by Hostname Changer before completion (I think):

it says it completed in 30 seconds and returned code 0

That means your batch script is exiting before it’s sub process has finished (the setup.exe). This is not a client issue but rather and issue with your snapin issue. Even if you did what @michael_f suggested you would have the exact same issue. The drive installation would claim it exited before it actually did and start the service before the installation had actually completed.

The client is performing exactly as it should. It runs the script and waits for that script’s process ID to terminate before doing anything else. This is evident by the return code being 0. If the snapin did not exit properly (or even run at all) the return code would be -1. My “guess” is that the setup.exe is actually just a poorly constructed wrapper. It does a little prep-work (that takes 30 seconds), and then spawns a child process to do the actual work. The problem is that wrapper doesn’t wait for the child process to finish, it just exits as soon as the child is spawned. This is something you’d need to investigate. Perhaps try running the batch script and monitoring the processes that exist. The other option (and probably more likely) is that the network path cannot be reached (your \homead) and that takes 30 seconds or so to “attempt”. It fails, runs the rest of the script (which of course can’t run a setup.exe it can’t find), and then exits the script.