Group Management

FOG 1.6

Groups themselves are not new, but what a group is changed in 1.6. On 1.5 a group owned nothing: pressing a button on the group page wrote rows onto whichever hosts were members at that instant. In 1.6 a group owns its snapins, printers, client modules and power schedules, and every member gets them — including hosts you add tomorrow. See the 1.5 version of this page for the old behavior.

A group is a label you put on hosts. A host can be in as many groups as you like: a machine can be in Third Floor, Math Department and Dell PCs at once, and each of those groups can hand it something.

What a group gives its members

A group holds four kinds of thing, and hands all of them to every member:

The group holds	Where you set it	What the member gets
Snapins	Associations → Snapin Associations	Included when you deploy snapins to that host
Printers	Associations → Printer Associations	Installed by the FOG client on its next check-in
Client modules	Service Settings → Client Settings	The module is switched on
Power schedules	Service Settings → Power Management	The machine shuts down, reboots or wakes on that schedule

Grant an item and the group grants it; revoke it and the grant is gone. Neither action touches a host record, so nothing you do here can overwrite something an admin set on a machine directly.

This is the change people notice first

A host added to the group later gets everything in that table. On 1.5 it got nothing — silently — which is why so many sites ended up with a plugin, a script, or a habit of re-pressing the group’s buttons after adding a machine. None of that is needed now.

A host removed from the group loses them. On 1.5 the copied rows stayed behind forever, with nothing to say where they had come from.

What a host ends up with

A host’s real list is its own assignments plus every grant from every group it belongs to, worked out fresh each time FOG needs it. That is one rule for all four kinds of grant, not four rules that happen to agree. Two things cover almost every question about it:

1. The host’s own assignments come first. A snapin you gave a machine directly stays where you put it in that machine’s run order; a grant never reorders it.
2. Groups follow, in group order — the Group Order field on each group, lowest first, then by name for groups sharing a number. Every group starts at 0, so out of the box that is plain alphabetical order; set the field only on the groups where the order actually matters. Falling back to name rather than to creation date is what makes the result something you can predict by reading the group list.

An item assigned both directly and by a group appears once, in the host’s position. There is no double install and no duplicate row.

The default printer follows exactly the same precedence: a host that has chosen its own default keeps it, and otherwise the default comes from the first group in that order which names one.

If two groups grant conflicting defaults, group order decides

Give the group whose default should win a lower Group Order than the other. Setting the default on the host itself also works and beats every group, but that is a per-host edit you then have to remember — the order is set once and keeps applying as hosts come and go.

Where to see the result

The host’s own Printers and Snapins tabs show what that host was assigned directly. To see what it will actually get, look at the groups it is in — the Groups column on the Hosts list names them, in the order above.

Reading the group list

The Group Management list has a Grants column saying what each row hands out — “3 snapins, 1 printer, 2 power schedules” — and it is worth a look before you touch anything, because a group is now two quite different things wearing the same name.

A row with an empty Grants column is a label: it names a set of machines and gives them nothing, so adding a host to it changes nothing about that host. A row with entries in that column is machinery, and adding a host to it hands that host software, printers, or a shutdown time.

It shows counts rather than names on purpose. The question the column answers is is this row consequential, and a group with twenty snapins would bury that answer under twenty names. Open the group to see which ones.

Why the column does not sort

It is worked out with one extra query per page of the list rather than being a column of the groups table, which is what keeps a group with five hundred members from costing anything to display. Nothing to sort by means nothing to sort — and if what you want is “groups that grant nothing”, reading down the column is quicker than sorting anyway.

Snapins are a snapshot; printers are live

These two behave differently, and the difference matters the moment you edit a group while work is queued.

• Snapins are resolved when the task is created. A snapin deployment records the list it is going to run at the moment you queue it. Editing the group afterwards does not change a task that is already waiting — you have to re-task to pick the change up.
• Printers are resolved live, on every client check-in. Add a printer to a group and members install it on their next check-in; remove one and they uninstall it. There is nothing to re-task.

The reason is that a task is a promise about a specific moment — you queued that set of snapins for that machine, and a machine that reboots into a job three hours later should get the job you queued, not a different one. Printers have no task to hang a snapshot on: the FOG client reconciles them on a schedule, so a removal has to be able to reach the machine on its own.

Printer level "FOG Handles all printers"

On that level the list FOG sends is authoritative in both directions — the client removes every installed printer that is not on it, including ones FOG did not add. That has always been true of that mode, and it is worth re-reading now that a group can add to the list.

Settings that are no longer on the group page

Image, kernel, kernel arguments, primary disk, init, AD details, product key, printer management level, BIOS/EFI exit type, screen resolution, auto-logout and hostname enforcement are not set from a group any more. They were never group properties — pressing Update wrote the value onto each member host once — so they moved to where that operation belongs: the Hosts list.

Hosts → tick the hosts you want → Edit selected hosts.

That does the same job on any selection you can build, not only on a group, and you can repeat it whenever you like.

The fields are split across the same four tabs a single host’s own page uses — General, Active Directory, FOG Client and Plugins — so a field is where you already look for it rather than somewhere in one long list. Each field has its own action:

Action	What it does
No change	Leave every selected host’s value alone. This is the default for every field.
Set on all	Write the value you type to every selected host.
Clear on all	Empty the field on every selected host.

Fields that only make sense as on/off (joining the domain, hostname enforcement) offer No change, Enable on all and Disable on all instead.

Nothing happens on a tab you did not touch

Every field on every tab starts on No change, so opening a tab and leaving it alone is the same as never opening it. You can set an image on General and a printer level on FOG Client in one pass; you do not have to do one tab at a time.

Where each setting went

Every row is Hosts → Edit selected hosts, then the tab and field named.

Was on the group page	Tab	Field
Image	General	Image
Kernel, kernel arguments, primary disk, init	General	Host Kernel / Host Kernel Arguments / Host Primary Disk / Host Init
Product key	General	Product Key
BIOS / EFI exit type	General	Host BIOS Exit Type / Host EFI Exit Type
Enforce hostname changes	General	Host Enforce Hostname Changes
Printer management level	FOG Client	Host Printer Management Level
Screen resolution	FOG Client	Host Screen Resolution
Auto log out time	FOG Client	Auto Log Out Time (in minutes)
Active Directory (join, domain, OU, username, password)	Active Directory	the Active Directory fields
Location, OU (plugins)	Plugins	Host Location / Host OU
Building	—	Removed. Nothing read it and nothing wrote it — it was a leftover column, not a setting.

Printer management level, screen resolution and auto log out are on FOG Client rather than General because they are settings the FOG client acts on, which is where a single host’s own page has always kept them.

These controls are gone from the group page, not hidden

If you are looking for one of them on a group and cannot find it, that is why. There is no setting to bring them back and no compatibility mode. The table above is the complete map of where each one went.

The location and ou plugins each had a group tab doing the same thing. Those are gone too, and both settings appear in Edit selected hosts alongside the built-in fields.

Groups as labels: doing it from the Hosts list

Group membership is editable from the host side in bulk, which is usually the faster way round. Labelling forty machines is one action rather than three trips through Group Management:

1. Hosts → filter or search until you have the machines on screen. The Groups column shows each host’s groups and can be searched and filtered like any other column, so “everything in Third Floor that is not in Dell PCs” is a filter rather than a cross-referencing exercise.
2. Tick the hosts you want.
3. Edit groups → pick one or more groups → Add or Remove.

Typing a name that is not a group yet creates it when you add. Remove only works on groups that already exist.

Because a group grants rather than copies, adding those forty machines to a group is all it takes for them to receive that group’s snapins and printers — there is no second step, and no button to press afterwards.

The rest of the group page

• General — the group’s own name, description and Group Order. That is all it holds now; everything else that used to be on this card is in the table above.
• Tasks — deploy, capture, multicast, wake, and the rest, run across every current member. Tasking is unchanged: it acts on the membership at the moment you start the task, which is what you want from a task.
• Associations → Host Associations — who is in the group. Add and remove members here, or from the Hosts list as above.
• Associations → Printer Associations — the group’s printers, plus which of them is the group’s default.
• Associations → Snapin Associations — the group’s snapins, plus the Snapin Run Order card, which orders the group’s own snapins. A host runs its own snapins first, then these, in this order. Order only changes anything when Abort snapin sequence on failure is enabled for the task.
• Service Settings → Client Settings — the group’s modules. Just the grant: screen resolution and auto-logout are set from the Hosts list.
• Service Settings → Power Management — the group’s power grants. Every member runs these schedules, including hosts added later. Immediate actions on the same tab are still a one-time push, because they are a task; see below.
• Inventory, Login History, History Items — reporting across the group’s members.
• Site — which site the group belongs to, if you use site scoping.

Power Management: a schedule is a grant, an immediate action is a task

The tab holds both, and they are different kinds of thing on purpose.

Create New Scheduled writes one row about the group. Every host in the group runs it, hosts added later included, and nothing is written onto a host. Revoking it with Delete selected takes it away from every member at once. A host’s own schedules are untouched either way — what a machine actually runs is its own schedules plus every grant from every group it is in, worked out fresh each time, with the same schedule reached twice counted once.

Create New Immediate is a task. It shuts down, reboots or wakes the hosts that are in the group right now, and a host added a minute later is not affected. That is what a task should do, and it is why it is not a grant: a standing grant of “shut down immediately” would fire again for every machine that ever joined the group.

Two schedules that differ only in time are two grants — saving a new time does not replace the old one, so revoke the one you are replacing. Saving the same schedule twice is a no-op.

Clear schedules from member hosts is the odd one out, and it is not an undo for the grants above. It reaches into the member hosts and deletes the schedules they hold — which, on a server upgraded from 1.5 or from an early 1.6, is where every schedule this tab ever created ended up. It also removes schedules those hosts were given individually, so read it as “reset the members”, not “clear this group”.

A host’s own Power Management tab remains the answer to what is this machine actually scheduled to do, because it is the only place the host’s own rows and its groups’ grants are not the same thing.

Daily schedules were running on Sundays only, on PHP 8

Fixed in 1.6. A schedule whose weekday was * — which is every daily schedule — was sent to the FOG client as ... 7, meaning Sunday. The comparison that normalizes FOG’s -1 for Sunday treated * as negative on PHP 8, where it had not on PHP 7.4, so a working schedule stopped running when the server’s PHP was upgraded and nothing about FOG changed. If you have power schedules that quietly stopped happening, this is why. Wake schedules were never affected — those are sent by the server, which never ran that comparison.

Modules have one extra rule: only a host can turn one off

A snapin or a printer is a thing a host either has or does not. A module is a switch, so it needs a third answer, and 1.6 gives it one.

A group can turn a module on and can never turn one off — there is no “disabled” a group can express. That means two groups can never contradict each other over a module, and there is no “this group says on, that one says off, which wins” to resolve.

A host can say all three, on its own Modules tab, which is a dropdown rather than a checkbox:

The host says	Result
On	The module runs on this host.
Off	The module does not run, no matter how many groups grant it.
Not set	The host has no opinion; a group grant switches it on, and nothing else does.

Off is the host’s own answer and beats every grant. Note that this is the one place where unticking used to mean something different: on the old checkbox, unticking deleted the row, which under these rules means Not set — so a group granting the module would have switched it straight back on.

Hosts that already carry copies

An upgraded server keeps every association it had. That is deliberate — an upgrade that removed assignments would be an upgrade that changed what installs on your machines — but it has a consequence worth understanding before you go looking for it:

Nothing distinguishes a row that a 1.5 group copied onto a host years ago from one an admin chose for that host deliberately. They are the same row in the same table, and the copy never recorded where it came from. FOG cannot tell them apart, so it does not try, and neither will any script you write.

So the most likely surprise reads like this:

“I removed the host from the group and it still has the snapin.”

That is the old copy, sitting on the host as a direct assignment. Removing the host from the group removed the grant; it cannot remove an assignment that was never a grant in the first place. Look at the host’s own Snapins or Printers tab and you will see it listed there.

Nothing needs cleaning up for FOG to work correctly — a host holding both the direct copy and the grant gets the item once. Clean up only if you want the group to be the single place that decides, in which case the routine is:

1. Confirm the group grants the item (Associations → Snapin Associations).
2. On the Hosts list, filter to the group’s members.
3. Open each host’s Snapins or Printers tab and remove the direct assignment.

After that the group is the only thing granting it, and adding or removing a host does the whole job.

New groups do not have this problem

Anything you set up on 1.6 is a grant from the start. This only affects associations that existed before the upgrade.

persistentgroups is retired

The persistentgroups plugin existed to work around exactly the defect this release fixes: it copied settings from a template host onto every machine that joined a group, because a group could not hand anything to a machine by itself. A group can now, so the plugin is gone and the template-host naming convention it needed goes with it.

Upgrading handles the removal for you. The plugin’s code disappears with the upgrade like any other bundled plugin, and — importantly — the upgrade also drops the database trigger it installed. That matters because removing the plugin’s files never removed the trigger: it would otherwise have kept copying settings onto every new group member, silently, long after the plugin that created it was gone.

One thing you may need to do. The trigger copied hostADPass — the Active Directory join password — from the template host onto hosts that joined the group. If you are rotating a join account, read the warning on the Plugins page before you assume the old credential is gone.

If you had it installed, check afterward that the groups which relied on it now grant the snapins and printers you expect — the grants are the replacement, and they are more capable than what they replace, because they also apply to hosts that were already members.

See also

• Group Shared State — the detail behind resolution order and precedence.
• Host Management — the Hosts list, mass edit and bulk group membership.
• Snapin Management and Printer Management — creating the things a group grants.