Difference between revisions of "SnapinPacks"

From FOG Project
Jump to: navigation, search
(Snapins Are Silent)
(Snapins Run As SYSTEM)
Line 14: Line 14:
 
= Snapins Run As SYSTEM =
 
= Snapins Run As SYSTEM =
  
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> or <font color="red">root</font> user's security context. If a snapin or SnapinPack runs successfully by manual execution but not via the FOG Client - this is typically related to the security context. For example, say you have a shared directory 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. There are a few solutions to this. Granting the share read access for anonymous users is the most simple. Specifying credentials within scripts, or as arguments to the executable within the <font color="red">config.json</font> are other options.
  
 
= Creating a SnapinPack =
 
= Creating a SnapinPack =

Revision as of 03:32, 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; both of these 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 the snapin 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 or root user's security context. If a snapin or SnapinPack runs successfully by manual execution but not via the FOG Client - this is typically related to the security context. For example, say you have a shared directory 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. There are a few solutions to this. Granting the share read access for anonymous users is the most simple. Specifying credentials within scripts, or as arguments to the executable within the config.json are other options.

Creating a SnapinPack

Organizing files

config.json

Zip the SnapinPack

Upload SnapinPack to FOG

Deploying a Snapin