RC8: When deploying two or more single snapins to host, only last one works

[yllwfsh]

When deploying two single snapins to a host only the last snapin gets executed. The first one disappears from the Active Snapin Tasks and remains indefinitely in the Active Tasks list.

However when you make a ‘Send all snapins’ task on a host every snapin appears as it’s own task in ‘Active snapin tasks’

I think it makes sense that every snapin I send creates a seperate task that needs to be executed. This is especially true if you have multiple admins that may be responsible for different snapins. Why would one of the snapins be cancelled like that? Doesn’t make sense to me.

It used to work like that before we upgraded to the RC’s

[Tom Elliott]

So I found the issue where the snapins wouldn’t be cancelled properly.

I’ve also altered how additional single snapins will work. It will basically leach of the original single snapin job created and turn the Active Task into a “multiple snapins” tasking (or all snapins if you will.) All snapins cannot be stacked, so the originating all snapin task will be cancelled and the new tasking will take it’s place.

This is all available in RC-9.

[Tom Elliott]

Snapin tasks work similarly to Multicast tasks.

There’s a central “Controller” and the individual snapin tasks that gets created for each tasking requiring snapins (Deploy, All Snapins, Single Snapin). When a new task is created it removes the old and a new tasking layout is setup.

What version of FOG are you using? There was a bit of a problem with what you’re describing in one of the RC releases, but this has since been corrected.

If you need to do different snapins, why not just run an “all snapins” tasking? The idea of snapins is to install software on a system. So if you have a system that needs new software that is varying from the original deployed tasking, add the snapins you need and run All snapins again. Anything that’s already installed should return quite immediately, while all the new snapins should install with little fuss.

[yllwfsh]

@Tom-Elliott We are running the latest RC8. I understand what you mean in terms of tasking, i’m just saying that it used to work like that from versions 0.32 till 1.20 (before we updated to the RC’s). I often sent two or more single snapins, they each had their own task in ‘Active snapins’ and they got executed one after another in the order that I had sent them. Now, only the last one gets executed, the other keeps hanging in the active tasks and stays ‘Queued’

[yllwfsh]

@Tom-Elliott Sending an ‘All snapins’ task every time is not a solution for us, because some installers don’t react well if they’re already installed on the host

[Tom Elliott]

So I found the issue where the snapins wouldn’t be cancelled properly.

I’ve also altered how additional single snapins will work. It will basically leach of the original single snapin job created and turn the Active Task into a “multiple snapins” tasking (or all snapins if you will.) All snapins cannot be stacked, so the originating all snapin task will be cancelled and the new tasking will take it’s place.

This is all available in RC-9.

[yllwfsh]

@Tom-Elliott Thx! I will try it out when RC9 comes!

[Wayne Workman]

@Tom-Elliott I am not following… what if the FOG Client is too fast and grabs the next snapin before it’s remade? What happened to the old behavior where multiple single snapins could be deployed and run successfully?

[Tom Elliott]

@Wayne-Workman Nothing happened to it. It just wasn’t ever supposed to work that way. This is because how it works.

In either case, now it should work that way. If the client grabs and closes the snapin task too fast, it just creates a new job and tasking as to be expected.