Snapins just let you run any file remotely. When you go to create / edit a snapin you will see several fields.
A snapin gets executed in this format:

{Snapin Run With} {Snapin Run With Arguments} {Snapin File} {Snapin Arguments}

The best way to understand this is with a couple of examples.

EXE

Let’s say you have an exe you want to run on a computer, and you normally run it like this:

MyFile.exe /foo /bar

Then you would upload MyFile.exe, set Snapin Arguments to /foo /bar and that’s it.

If you have an exe that is an installation (e.g. vlc), you will need to provide the silent installation parameters in the Snapin Arguments box.

MSI

Let’s say you want to deploy an MSI. To install an msi from the command prompt you would run

msiexec /quiet /i MyFile.msi

So to make that a snapin, upload your MSI, set Snapin Run With to msiexec and Snapin Run With Argument to /quiet /i

Batch script

Let’s say you want to deploy an batch script. To run a .bat / .cmd from the command prompt you would run

MyFile.bat

So to make that a snapin, upload your script, and that’s it.

Hopefully this helps, but if you have any more questions let me know.

@THEMCV , @Wayne-Workman one note about that batch script (or any script for that matter). I would avoid hard coding the path of the files as it can change based on your machine’s architecture. Instead use your scripting language’s command to get its directory.

For batch %~dp0 returns the script’s directory (including the last \). So to re-write wayne’s examples the commands would be:

msiexec.exe /i "%~dp0installer.msi" /quiet

copy "%~dp0your.xml" "C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\your.xml"

@george1421 the FOG client should never be set to run a domain user. The client’s security model relies on the assumption of running as SYSTEM/root. In addition if the client runs a domain user then it will not be able to rename, join, or leave a domain. Since when the client needs to temporary leave remove a machine from the domain, the client would loose all privileges.

Ultimately the client may or may not work as non-SYSTEM users, but its not something we recommend or will officially support.

For valuable snapins, I would probably start with basic cmd scripts, and then play around with silently installing some exes / msis. (For an exe installer the silent parameter is usually /s or /S).

I may be a tad bias when it comes to this, but I would recommend trying out our development builds on another vm / server. You’ll find imaging speeds are significantly faster, and there are some added security benefits. You should also check out the new beta client (my baby) which works with our development builds. It’s far more responsive than the 1.2.0 client, has quite a few security patches, and is more … ‘professional’ in areas, such as shutdown prompts and such.
(See https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk)

https://news.fogproject.org/fog-client-v0-11-12-released

Yup. You can thank @tom-s for the name.

https://news.fogproject.org/fog-1-5-0-officially-released-and-fog-client-0-11-15-officially-released/

@Wayne-Workman no such complications are needed. When I have free time, I simply need to find the appropriate registry values to check if the license key is armed or not (no language dependencies)

@george1421 @Sebastian-Roth this is a very good conversation to be having. FOG 2.0 was looking at system uuids to identify computers, but for the reasons you stated, that wouldn’t work very well. Thinking out-loud here, maybe these points are worth considering:

• There is no 1 single we can rely on as you showed in your original post, and some derived value based on client information may be the best route to go.
• A static key derived from values may not be the best idea. Instead it should be a weighted component comprised of several fields. For example, one could think about it like so:
  • UUID: .4
  • Primary MAC: .2
  • Motherboard asset #: .2
  • Hard drive asset #: .1
  • Ram/CPU information :.1

For each field that matches, a score gets increment by that amount; the host with the highest score, and above some threshold, gets selected/matched (essentially a fuzzy search). This provides some tolerance against machine’s hardware being upgraded, or portable network adapters being used. Obviously the fields I picked were completely arbitrary and some testing may need to go into it to pick the best identifiers.

@johnomaz ,the next version should automatically remove the legacy client:
https://github.com/FOGProject/fog-client/issues/31

@Zer0Cool for the SnapinPack. you’d have it run start.bat. start.bat Would then copy & run removeclient.*** as a separate task. This means start.bat would exit fairly quickly, and so the client could inform the server the snapin ran successfully. removing it from the FOG task list. I would, however, recommend putting a short sleep delay at the beginning of removeclient, just to give the client enough time to inform the server before it is uninstalled.

As for PCI/FIPS compliance, I have done some work for that here: (https://github.com/FOGProject/zazzles/commit/90b76038210175a532a5da522b7d61b281d23a99), but last I tested it still had issues. Right now the ticket is targeted to be done on v1.7 of the FOG server, but if you’d like to see it done sooner, you could hopefully assist me. To continue development/testing I’d either need to turn FIPS compliance on in one of my dev VMs or be able to remote into a machine with it enabled. The latter may be quicker. Feel free to PM me if you’d be interested in helping.

@Zer0Cool snapins act like children processes attached to the client. This means if the client is stopped (via an uninstall), it’ll likely also stop and delete any running snapins. I’d recommend using a SnapinPack. There could be 2 files in it: a start.bat and a removeclient.[bat/cmd/ps1]. Essentially the start.bat would copy removeclient to another folder, as otherwise it’ll get removed on client uninstall, and then run that script as a new backgrounded process.

@Joe-Gill on sleep, all programs and services are suspended. This means the client can not operate during this period, and so there’s not much it can do to actually perform a shutdown.

@Joe-Gill can you attach the C:\fog.log from one of the problematic machines?

@fernando-gietz said in Which is the best way to install/deploy the FOG client?:

in the sysprep proccess I install the client again

So to be clear, the image itself does not have a client installation? It’s installed during sysprep?

And by “uninstalling / re-installing the client” I’m referring to manually uninstall the client on an existing installation that is running.

@Fernando-Gietz a reset encryption data should only be done if a client installation losses its security token somehow. This can either be caused via the Debugger, manually deleting it, or uninstalling / re-installing the client. If it is being lost for another reason, then there is some other issue at play here.

@Fernando-Gietz resetting encryption data should not be needed, and doing it often/in-bulk posses security risks. Can you describe exactly what you do prior to resetting encryption being needed? In general this only occurs if the client is manually reinstalled, as the server should be handling the case where computers are deployed, automatically. (If it’s not, then it’s a bug).

@LaurentB unfortunately, once a client installation occurs, it “locks itself” into the server you first point it at. If you had the old server available, I’d recommend doing: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server.

Now, since you don’t have the old server(s), you will have to uninstall, and then install each client. However, if the machines are bound to an Active Directory domain, you should be able to automate this with a simple batch script, and deploy it via GPO.

@foghelp I’d recommend re-entering the AD password field on the web ui. Its possible that somehow a bad copy of the password got placed in the database.

I could see us adding a warning if a node cannot connect. However, I am in agreement with @Tom-Elliott that straight up preventing credential entering would cause more issues than it would solve.