Difference between revisions of "SnapinPacks"

From FOG Project
Jump to: navigation, search
Line 15: Line 15:
  
 
All Snapins including SnapinPacks run as the <font color="red">SYSTEM</font> user's security context. If a snapin or SnapinPack will run by manual execution but not via the FOG Client - this is typically related to the security context. For example, say you have a Windows share on a domain controller that is granted read access to all <font color="red">Domain Users</font>. Well, an individual host's local <font color="red">SYSTEM</font> user is not a member of <font color="red">Domain Users</font>. Therefore, unless alternative credentials are supplied to access the share, any script executed that tries to read this share will not work. The answer to this is to allow anonymous read & execute access to the windows share.
 
All Snapins including SnapinPacks run as the <font color="red">SYSTEM</font> user's security context. If a snapin or SnapinPack will run by manual execution but not via the FOG Client - this is typically related to the security context. For example, say you have a Windows share on a domain controller that is granted read access to all <font color="red">Domain Users</font>. Well, an individual host's local <font color="red">SYSTEM</font> user is not a member of <font color="red">Domain Users</font>. Therefore, unless alternative credentials are supplied to access the share, any script executed that tries to read this share will not work. The answer to this is to allow anonymous read & execute access to the windows share.
 +
 +
= Creating a SnapinPack =
 +
 +
== Organizing files ==
 +
 +
== config.json ==
 +
 +
== Zip the SnapinPack ==
 +
 +
== Upload SnapinPack to FOG ==
 +
 +
== Deploying a Snapin ==

Revision as of 00:33, 12 July 2016

Under construction.


SnapinPacks Brief Overview

SnapinPacks are a new feature specific to FOG 1.3.0 and the new FOG Client (version 0.11.3+). The key ability that SnapinPacks allow is to deploy many files to hosts, and execute one of those files with any needed arguments.

For example, you may deploy driver files to a host with a single SnapinPack. With those files, you can include a script which would run and place the drivers where they need to be. Another example would be bundling a dozen different MSI files, and include a script that runs each MSI with it's individual needed arguments if any. Another example would be larger silent installations such as Adobe Creative Cloud or Microsoft Office, all have silent installations and many files and would be well suited for SnapinPacks.

Snapins Are Silent

SnapinPacks must be silent, this requirement has not changed. What is a silent snapin? A silent snapin requires zero interaction to run. If at any point an installer asks for input from a user, it will simply wait for input that will never come, and timeout eventually.

Snapins Run As SYSTEM

All Snapins including SnapinPacks run as the SYSTEM user's security context. If a snapin or SnapinPack will run by manual execution but not via the FOG Client - this is typically related to the security context. For example, say you have a Windows share on a domain controller that is granted read access to all Domain Users. Well, an individual host's local SYSTEM user is not a member of Domain Users. Therefore, unless alternative credentials are supplied to access the share, any script executed that tries to read this share will not work. The answer to this is to allow anonymous read & execute access to the windows share.

Creating a SnapinPack

Organizing files

config.json

Zip the SnapinPack

Upload SnapinPack to FOG

Deploying a Snapin