@Wayne-Workman for batch you just use %~dp0 to get the full directory path of the script.

This is very concerning. There are safegaurds in place to prevent faulty modules from crashing the service. I’ll take a look at this as soon as I get a chance.

Your network share needs to have anonymous read access enabled. Also, if you have that network share you can just set the driver field of the printer to the network share location of the inf. If you have 0.11.3 of the client you could also use SnapinPacks to deploy the driver.

@ABane in the case of Windows you have a couple options.

• Using the Windows tool called sysprep and an unnattend.xml file which specifies first-time boot configurations, you can set user account information
• You can use the FOG client to control user accounts using snapins. Snapins simply run any script / executable as root/SYSTEM so there is very few limits of what you can do using a snapin.

As for your debian question, FOG would capture a debian installation that you configured. So you would set the password before capturing the FOG image.

I remoted into @joshuaparker 's system and found the issue. Its a bug with the v0.9.12’s ability to match network printers to WMI objects (basically, the client couldn’t link the printer name to the actual printer on the computer). The next version of the client will fix this.

@Joe-Gill not to my knowledge. Otherwise I would have done so in the PrinterManagerHelper. I’ll keep digging around though. I suppose I could extract the hardware ID and link that to the generalized driver windows generates on installation and then parse that for more details.

I built a FOG driver pack generator from scratch awhile ago that when run on a computer extracted all used drivers to an existing pack. I could canabalize that to get the printer driver. Unfortantly window’s driver system is anything but pretty.

@dholtz-docbox I’m not sure if the smart installer switches are in the wiki yet (pinging @Wayne-Workman). The list is here:

https://news.fogproject.org/fog-client-v0-11-0-released-2/ See the SmartInstaller Switches section.

@Matthieu-Jacquart Upgrade your server again. It’ll disable v0.9.12 auto updating. It would seem Window’s SYSTEM account’s inconsistency has the potential to remove all FOG clients on your network when upgrading to v0.10.X.

I remoted in and helped. The issue was with the printer configuration. The Model field wasn’t quite right.

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

@MadsMagnus, the client hasn’t been updated yet. I verified and the latest revision (7931) sends all of the correct data to the client. 7907 should as well. More than likely there’s and Authentication section in your fog.log file which will state it failed to authenticate (probably an invalid security token). Try “Resetting Encryption Data” for the computer having this issue?

Please upload the fog.log from one of your problem hosts here. (Usually c:\fog.log).

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

The nightly builds of v0.11 have been confirmed to fix this issue and also set default printers properly.

@x23piracy while you can do that, it is risky and unadvised. You’re basically creating a race condition and just hoping it works out. I recommend following the written wiki article for how to configure the client and sysprep. We recommend setupcomplete.cmd as that is the proper and safest way to do so.

@Ric41 teamviewer usually will take TeamViewer.exe /S as a valid parameter (note that it is capital S). However teamviewer likes to start itself after being installed, so you would probably have to get the PID of the spawned process and kill it after the installer finishes.

This is a client issue. After reviewing the logs there appears to be threading conflicts. I will look into this when I get a chance.

@dolf If you are sysprepping is the client disabled on startup and then re-enabled in setup complete?

@Wayne-Workman no reason to have it be a torrent, we can just host it on our public servers, and not have to worry about seeders.

Going to take a shot in the dark here. Is your client set to log in the program files dir (not just c:\fog.log)?