Using Snap Ins to run scripts post imaging...?

[danieln]

FOG OS: 1.5.10
Server OS: Debian 10 Buster

I wrote a Powershell script that will run a QC check on the computer’s hardware post imaging.

In an ideal world, it would be incredible if I could add just add it as a Snap In and have every image in the default storage group automatically get this snap in after it images. Is this possible? Do you have to task Snap Ins on every instance or can you assign them to a storage group?

If not, I will probably look into tasking it within Windows and baking it into the image, but was just curious!

Thanks in advance,

[JJ Fullmer]

@danieln I don’t know of a way to default assign a snapin to every new host that is built-in to fog.
However, if a snapin is assigned to a host the deployment of said snapins is automatic when you deploy an image.

Here’s a few ways you could make it close to or completely automatic on all new/existing hosts.

• You can assign a snapin when you register a host via pxe, so you just standardize there
• You can make an everyone/all group and assign the snapin in that group periodically.
• You can assign hosts to a snapin from the snapin screen I believe (maybe that’s only in 1.6) point though is you can assign to all from there.
• You can use the FogApi powershell module to write something that adds the snapin to all hosts that don’t have it, and make that a scheduled task somewhere to have that run every day or hour or what have you

If you wanted to bake it into the image you would just have it as part of your setupcomplete.cmd or unattend.xml firstlogoncommands.

[danieln]

@JJ-Fullmer Thanks for the reply! This is helpful.

I feel like maybe the best way to go about it is to assign the Snap In to each host. Just to confirm, this will deploy the Snap In after each time that host is image, regardless of which image it receives?

I’m also thinking of separating my inventory into FOG Groups by computer model and then assigning the Image Associated with it and Snap Ins at the group level.

[MatMurdock]

@JJ-Fullmer I don’t think it does this, but it would be cool that if a snapin is assigned to an image that that snapin would be assigned to run on any system that used that image.

Mat

[lukebarone]

@danieln Why would the QC be done after imaging instead of before? Just curious.

Do you have any other system for running remote commands? If you can maintain a list of system names (maybe using the FogAPI), you could run remote commands to your systems from one console on demand - would that work?

[JJ Fullmer]

@MatMurdock This could be implemented via a plugin where you build a db trigger and an imagesnapinassociation that assigns snapins assigned to an image to any host with that image. It could be done. I don’t think it would be added to the default config.

Granted, you could create a postdownload script that assigns and deploys snapins via the api based on what image was used.

[JJ Fullmer]

@danieln said in Using Snap Ins to run scripts post imaging...?:

@JJ-Fullmer Thanks for the reply! This is helpful.

I feel like maybe the best way to go about it is to assign the Snap In to each host. Just to confirm, this will deploy the Snap In after each time that host is image, regardless of which image it receives?

Yes that is correct, unless you specify otherwise (I think that’s really only available in the api though) the standard operation is to queue all assigned snapins to deploy after an image task

I’m also thinking of separating my inventory into FOG Groups by computer model and then assigning the Image Associated with it and Snap Ins at the group level.

Is this QC check also installing and or checking drivers? You could also use postdownload scripts to install drivers and have just 1 image that is universal and the drivers are injected and installed during sysprep specialize phase. Takes some setting up but works very well, see https://docs.fogproject.org/en/latest/kb/how-tos/post-download-scripts/?h=post

Also, if you wanted to create groups based on the model in the FOG Inventory you could build that out pretty quickly with my FogApi powershell module ( see my signature)

Something like this would get you a list of all unique model names you have in fog, this example uses is for 1.6 but should also work in 1.5.10.x
It also doesn’t include the initial api connection bits.

#get all your fog hosts with full details
$allhosts = Get-FogHosts | % { (Get-foghost -hostID $_.id -ea 0)}
#get the sysproduct field from the inventory of each host, and get the unique entries only
$uniqueModelNames = ($allhosts).inventory.sysproduct | sort-object -Unique
#list the model names in the shell
$uniqueModelNames

There may be some additional filtering to do here depending on your inventory (like HP sometimes has slight differentiations of a model) but if that list is what you want your groups to be

$uniqueModelNames | Foreach-object {
  $jsonObj = @{
    name = $_;
    description = "Computers that are of the model $($_)"
  }
  #I have a pending issue for creating a simple New-FogGroup function
  new-fogobject -type object -coreObject group -jsonData ($jsonObj | convertto-json)
}

Then you’d set the membership of the matching hosts

#loop through the model names you created groups of by name
$uniqueModelNames | Foreach-object {
  #get the group name and the matching group object
  $groupname = $_;
  $group = get-FogGroupByName -name $groupName;
  #find any host that is the given model and loop through them
  $allhosts | Where-object { $_.inventory.sysproduct -eq $groupName;} | Foreach-Object { 
    #set the group association/membership required fields
    $jsonGroupData = @{
      groupID = $group.id
      hostID = $_.id
    }
    #create the group membership association
    New-FogObject -type object -coreObject groupassociation -jsonData ($jsonGroupData | convertto-json) -ea 0; 
  }
}

Then you can go in the Fog web gui and assign hosts to each image. This can also be done in the api, but I just don’t have time to work out an example for that.

Also note that groups are not persistent config containers. Group membership sticks around, but it’s meant to be used as a bulk setter. If you set an image in a host it will set it on all the hosts in the group. But if you go change the image on 1 host in the group, it doesn’t auto change back, nor does it auto set when you add it to a group. There is a plugin that changes this behavior called persistent groups, but using it as a bulk setting and as a simple container/organizer of hosts is usually sufficient as you get into things more and more.