FOG Snapin Not Working in Group

[RobTitian16]

Server

• FOG Version: 1.3.0-RC-14
• OS: Ubuntu 14.04

Client

• Service Version: 0.11.5
• OS: Windows 10

Description

Hi all,
I seem to be having an issue with snap-ins and groups at the moment. When I image a PC, I first perform the full host registration and inventory. I assign the PC to a group, which has snap-ins assigned to it. When the PC is then imaged, I check the FOG log and can see that it says: ‘No Snapins’. I’m expecting it to run a script that changes the default Administrator account name and password.
It’s odd though as it joins the domain perfectly fine (which is a group setting - I say no when it asks if I want to join the PC to a domain using the default settings when performing the full host registration and inventory).
So the question is: how can I get the PC to run the snap-ins assigned to the group it’s a member of?

Any help with this would be greatly appreciated.

[Tom Elliott]

@RobTitian16 When you assign a host to a group, the host does not automatically get assigned the contents of what your group currently has. Groups are a way to update/manage hosts within the group on an en-mass setup. What this means: You can associate any host to any group (including multiples.) However, to make that newly joined host contain the contents of the group it’s been placed into, you need to update the particular group to enable that host’s “sync” with the group it’s in.

Groups do not contain snapin, printer, image, module, etc… associations. Those associations are placed directly on each host. The only things that get “associated” to the group definition (with or without hosts) is the “group general tab” and that’s mostly just to make it a slight bit simpler for group pre-defining. To get the snapins associated to a host, you need to go to the group -> snapin tab, and associate the snapins.

You’ll notice ALL snapins are always available to the group. This is because you can add and remove snapins from all hosts within the group. There’s not a nice method to know which snapins are associated to all hosts.

[RobTitian16]

@Tom-Elliott said in FOG Snapin Not Working in Group:

update the particular group to enable that host’s “sync” with the group it’s in.

Ahh that makes more sense now. Many thanks for your explanation and help.
So I suppose when users are imaging the computers themselves, it would be better for them to say ‘yes’ to the question: ‘Do you want to join this computer to the domain using default settings?’ and letting them choose the snapins themselves, rather than expecting the group settings to replicate to the hosts?
Or, is there a way to “sync” the group settings with the hosts automatically?

[Tom Elliott]

@RobTitian16 Yes they should say yes to the “Do you want to join this computer to the domain using default settings” and if you need to associate snapins you should say yes to it’s question and enter the ID’s you need associated.

There is a way to get groups to set their settings, but it’s not something I’m adding simply because of the complexity involved. @george1421 created a trigger for SQL that should enable what you’re expecting, though I can’t guarantee it will work for Registration.

It’s simpler to just answer the questions during registration though, which is why those questions are asked to begin with.

[Tom Elliott]

https://forums.fogproject.org/topic/6902/fog-1-3-persistent-groups

[Tom Elliott]

DELIMITER $$

CREATE TRIGGER `new_groupmember_added` 
AFTER INSERT ON `groupMembers` 
FOR EACH ROW
BEGIN

 SET @myHostID = `NEW`.`gmHostID`;
 SET @myGroupID = `NEW`.`gmGroupID`;

 SET @myTemplateID = (SELECT `hostID` FROM `groups` INNER JOIN `hosts` ON (`groupName` = `hostName`) WHERE `groupID`=@myGroupID);

 IF (@myTemplateID IS NOT NULL) AND (@myHostID <> @myTemplateID) THEN
   UPDATE `hosts` `d`, (SELECT `hostImage`, `hostBuilding`, `hostUseAD`, `hostADDomain`, `hostADOU`, 
   `hostADUser`, `hostADPass`, `hostADPassLegacy`, `hostProductKey`, `hostPrinterLevel`, `hostKernelArgs`, 
   `hostExitBios`, `hostExitEfi` FROM `hosts` WHERE `hostID`=@myTemplateID) `s`
   SET `d`.`hostImage`=`s`.`hostImage`, `d`.`hostBuilding`=`s`.`hostBuilding`, `d`.`hostUseAD`=`s`.`hostUseAD`, `d`.`hostADDomain`=`s`.`hostADDomain`,
   `d`.`hostADOU`=`s`.`hostADOU`, `d`.`hostADUser`=`s`.`hostADUser`, `d`.`hostADPass`=`s`.`hostADPass`, `d`.`hostADPassLegacy`=`s`.`hostADPassLegacy`,
   `d`.`hostProductKey`=`s`.`hostProductKey`, `d`.`hostPrinterLevel`=`s`.`hostPrinterLevel`, `d`.`hostKernelArgs`=`s`.`hostKernelArgs`,
   `d`.`hostExitBios`=`s`.`hostExitBios`, `d`.`hostExitEfi`=`s`.`hostExitEfi`
   WHERE `d`.`hostID`=@myHostID;

   INSERT INTO `locationAssoc` (`laHostID`,`laLocationID`)
   SELECT @myHostID as `laHostID`,`laLocationID`
   FROM `locationAssoc` WHERE `laHostID`=@myTemplateID;

   INSERT INTO `printerAssoc` (`paHostID`,`paPrinterID`,`paIsDefault`,`paAnon1`,`paAnon2`,`paAnon3`,`paAnon4`)
   SELECT @myHostID as `paHostID`,`paPrinterID`,`paIsDefault`,`paAnon1`,`paAnon2`,`paAnon3`,`paAnon4`
   FROM `printerAssoc` WHERE `paHostID`=@myTemplateID;

   INSERT INTO `snapinAssoc` (`saHostID`,`saSnapinID`)
   SELECT @myHostID as `saHostID`,`saSnapinID` 
   FROM `snapinAssoc` WHERE `saHostID`=@myTemplateID;

   INSERT INTO `moduleStatusByHost` (`msHostID`,`msModuleID`,`msState`)
   SELECT @myHostID as `msHostID`,`msModuleID`,`msState`
   FROM `moduleStatusByHost` WHERE `msHostID`=@myTemplateID;

 END IF;

END;
$$

DELIMITER ;

The way it works, you create a group name (preferably something you know will not ever be used as a “normal” hostname in your system. Then you create a host using the same groupname (which becomes your template.)

When you add the trigger, it will automatically handle the “updates” of the host as required and setup by your “template” host.

I copied the code from @george1421 as originally posted, and only updated to escape the fields as appropriate.

[RobTitian16]

@Tom-Elliott Ah, many thanks. Indeed, I think it’s simpler just to answer the questions if users are imaging the systems themselves.
On another note, is it possible to view the description of the snapins whilst registering a host? It would be somewhat helpful as then they can see exactly what the snapin does and whether they want it or not. If not, I suppose I’ll create a Word document detailing what each one does and they can review that if necessary.

[RobTitian16]

@Tom-Elliott Oh cool - thanks! I might test this out at some point soon

[Tom Elliott]

@RobTitian16 We don’t send descriptions as a part of the listings simply due to time. More often than not, I think, people are registering in a kind of “mass” scenario. This meaning you just received 500 systems and need to get them registered. Having the descriptions I think is a bit much, especially considering the number of questions we’re asking for anyway.

It might work better, though, to kind of describe the snapin a little bit in the “name” of the snapin anyway? (e.g. SmartBoard4.5.10Full for a snapin name rather than Smartboard).

Maybe I’m thinking too much.

[RobTitian16]

@Tom-Elliott Yeah, I thought it would come down to naming the snapins appropriately. In our case, I think most like to know what they’re signing up for. As such, I’ll just create a document for them to follow and then answer any questions that do come up from it.

Thanks for the help and assistance!