File Injection (possibly through Snapin management)

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