File Injection (possibly through Snapin management)

[THEMCV]

@Wayne-Workman So we have our Anyconnect client that FOG installs with no issue. The problem I’m having is getting the file into the location from the server.

The file I need is on \\server\subfolder\FOG_VPN_Files and it’s an .XML file that needs to go into C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile

I tried having a script mount \\server as a Z: drive, but the copying process proved unreliable and didn’t ever seem to work well. I don’t really want to be mapping drives if I don’t need to.

The snapinpack could work. Where does the FOG client drop the files to?

@Lee-Rowlett I’ll check into that snapcheck.php. These are fresh installs with no programs besides Office installed, so it could definitely work fine. The config files just need to be put in place and the vpnagent service needs to be restarted too.

The one idea I had was to just keep the config file on the image and have a script copy it over, but I’d like to be able to deploy and keep an updated version on the server for these sort of things if possible.

[Wayne Workman]

@THEMCV I would have the snapinpack both install the software and then place the file too. This way the two are together, and one is always coming before the other.

Where fog dumps the files - it was quite confusing to me until I understood it. The wiki article SnapinPacks “SnapinPacks are Compressed” section explains it very throughly.

So if you name the snapinpack in the FOG web interface ciscoanyconnect, and the zip file does not contain yet another folder in it but just contains these three files:

• Installer
• .xml file
• .bat file <-- more about this in a minute.

You’d upload the snapinpack to the web interface as a snapin pack (this is illustrated in the wiki). When it’s deployed, these files are moved from the FOG server to the host, and then extracted to this path:

• C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\your.bat
• C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\your.xml
• C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\installer.msi or whatever it is

Now, from this point, after the copy finishes, the FOG Client initiates the .bat file (but it could initiate any executable, like a powershell script or a exe or .sh or whatever).

The .bat file must make all the correct calls to do everything necessary. For example, running a msi correctly in this situation might be:

msiexec.exe /i "C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\installer.msi" /quiet

After this, and according to the info you gave below, the copy line would come last in the script, and may look something like this:

copy "C:\Program Files (x86)\FOG\tmp\ciscoanyconnect\your.xml" "C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\your.xml"

Note the quotes around the paths, thats because they has spaces in them.

Now, when you’re zipping this stuff up, and then uploading it to the web interface, you will need to specify that the SnapinPack is going to run a bat file, and then you need to put that bat file’s name in with the settings.

Watch the “very through” video if you have time, all this stuff is explained there:
https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks#Very_thorough_example

[THEMCV]

@Wayne-Workman You are the absolute best. This looks perfect and totally doable for multiple packages.

Thanks so much! I’ll give this a whirl and let you know.

[Joe Schmitt]

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

@Joe-Schmitt Your recommendations are consistent with other deployment tools too. That way the package writer doesn’t need to know the absolute path of the source files during deployment.

[Quazz]

@Joe-Schmitt Even more universal, you can replace with %SystemDrive% so that if the drive letter of the windows partition is not C for some reason, it can still do it’s thing.

So

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

Becomes

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

[Tom Elliott]

If anyconnect is already installed, a postdownload script could be VERY simple to add, just parse searching for the folder, if it exists, place the config file and be done.

Of course this would be the route I personally would go only because I would absolutely know the program is present and existing on the systems that receive the file.

The snapin/snapinpack route would work, but what happens if there’s a problem with installing within windows? (Just my thoughts).

I genuinely like the collaboration on this thread though. It gives very useful information and shows how one can accomplish any number of things with potentially different approaches.

[THEMCV]

Thank you all so much for your help. It works! And it works well! I have a lot of apps to do this with, but it’ll be worth it in the end.

Fully modular images by department with a tiny base image here I come.

[Wayne Workman]

I’m going to update the wiki to give more examples - sometime next week on a week night. I’ll also try to re-write and simplify what’s already there. I probably didn’t choose the best example names (abc def ghi). I’ll use alpha bravo charlie delta instead.

[THEMCV]

@Wayne-Workman It’s not too bad how it is. Regardless of the name you really just need to read it a few times and then it clicks.

[Wayne Workman]

@THEMCV So, you were able to get snapinpacks to deploy and configure cisco anyconnect for you huh? Fast, isn’t it?

Not to discredit what Tom and Lee said, but there are not integrated logs for postdownloadscripts. With snapins and snapinpacks there are. And also you can see the queued item in the web interface and see if it’s running and if it disappears or not when it ought to be done.

[THEMCV]

@Wayne-Workman Yes I did. FOG gets better every day I swear. I got stuck on the CiscoVPN client (legacy), but that was my fault. Parsing problem for .msi

Yeah, that’s what’s really useful for me.

All of the users hate the word imaging here, so I’m trying to change that by doing a per department automated install for them so they can have all their apps back how they want them and their downtime is minimal.

Slowly but surely.

[Tom Elliott]

@Wayne-Workman I don’t understand the “there are not integrated logs for postdownloadscripts”.

If you need them logged, you can write them. The whole basis of postdownload scripts is you can do what you need to. The only issue (which you can fix by modifying your exports file) is there isn’t a central place to store logs, though I don’t know that this would be needed. If you’re inserting files, you can create a log directly on the system using the postdownloadscripts.

[Lee Rowlett]

@Tom-Elliott this is exactly what i do which is why i caused confusion when posting code regarding injecting drivers with “/fog” directory throwing ppl off lol. postdownloadscripts are only limited to your imagination, i honestly believe it’s very under-utilized. i even use it to update the snapin state to give a detailed progress of where it is at (using snapintaskstate plugin too) as i have one snapin script for all our builds, each snapin definition just has an argument set so the script knows what software to install, settings to set etc… essentially i only have to manage one image and one snapin otherwise if i had a snapin per software i’d be managing 100’s potentially 1000’s! although i guess this is where snapin packs comes in to play! i’d already got this setup before snapin packs where introduced. Can see the appeal to snapin packs and how useful they can be but rely on having the fog client and if you don’t use fog to manage existing systems can be the only downfall i guess.

[Wayne Workman]

@Tom-Elliott Not everyone is of the mentality to write their own. Snapins have viewable status via the web interface already and have logs on each host already. It’s not wrong to point out this difference, and it’s not wrong to choose snapins because of this difference.

[Tom Elliott]

@Wayne-Workman My point isn’t about people’s “mentalities” just rather the direct facts.

People who are working to create a postdownloadscript that would like logging to be included in some form should be thinking of these things. They’re ultimately in full control of the process, which would also include logging/reporting if that’s what they so need.

While you’re correct that snapins and snapinpacks have the “logging” built in, that’s not to say a postdownload script cannot. The idea of postdownload scripts is to give the person creating it FULL control. What you do with it is completely up to YOU. How you approach logging is up to you. What that script will do is up to, you guessed it, YOU.

Just because it’s not something others may be thinking about does not mean it’s a failure in the “system” itself.