Deploy Single Snapin Shows All Snapins, Not Those Assigned to Host
-
This is semi intentional, considering FOG allows you to deploy any snapin via Groups, why not from the host? The “Associated” snapins are important on imaging tasks, but why shouldn’t you be able to deploy a specific snapin (whatever snapin you want) via a host?
-
In my opinion, this is a BAD idea.
We have different snapins for different OSs and we have to manage many types of images at any given time. We have a list a of snapins a mile long - many of which cannot / should not run on some images. Someday, Access Control will be implemented inside FOG, but until then, we manage FOG use on an honor system. Some people have the task to decide what snapins go on what machines, while others have the job of deploying snapins.
FOG’s ability to image and then apply snapins is a good feature, but in my life, we’re normally deploying snapins more frequently on an as-needed basis to repair an existing snapin install or to send software to a PC that didn’t need it until sometime long after imaging. We’re also always making new snapins for maintenance and to meet the users’ needs and these are always deployed one at a time. In point of fact, we create images that have the majority of the snapins already installed (like MS Office) to save on the deployment time.
In my opinion, allowing single snapin delivery of any snapin will lead to a lot more extra work in the form of re-imaging to undo mistakes being made.
I strongly suggest that you consider returning this feature to how it’s been. The inconvenience of having to select a snapin for a PC prior to deploying that snapin actually saves time we’ll have to spend due to mistakes and acts as a safeguard against time-consuming mistakes.
Jim
-
@Jim-Graczyk all snapins deployment only sends a hosts associated snapins.
-
Yes, I understand what you’re saying but I use Deploy a single snapin much more frequently than deploy all snapins.
Actually, the only reason I have to deploy all snapins would be with an image. It’s very rarely used alone. Maybe for some debugging and it’s good to have it in the lab.
I believe this Single Snapin change will be liked by a few but hated by a larger number in the long run - and it’s likely to take some time for mistakes in the field to lead folks to dislike the change.
I’ve been doing deployments and helpdesks back to NT 3.51 in some very large companies, but it’s still just one man’s opinion.
You’re welcome to consider this issue closed.
Jim
-
@Jim-Graczyk I’m not saying anything against it just trying to understand the issue. What I find would be a better alternative would he to designate, within the selector, what snapins are and arent associated
-
@Tom-Elliott meaning I’ll make this a feature where it lists all snapins, but will group the selector with the associated snapins at the top of the selector.
-
@Tom-Elliott
That would be much better than having no indication which snapins are assigned. Some indication in the snapin name (like an asterisk or such at the end of the Snapin name) would be something I could live with.Jim
-
@Jim-Graczyk Working branch now has the hosts with ‘associated’ and ‘unassociated’ options. These two options, themselves, are disabled meaning they don’t allow you to select them. The items below these selections are their designated elements.
Associated snapins show up on the top of the list of course.
-
@Tom-Elliott I pulled the latest working from Github and installed this morning but my Single Snapin Snapin choices look the same as before.
Any idea why I’m not seeing the change?
thanks,
Jim
-
@Jim-Graczyk Is this from dev or working?
-
@Tom-Elliott I believe it’s working since I never changed that, but you tell me:
Not sure since it says I’m not running the latest.
Jim
-
@Jim-Graczyk Apparently my changes got changed out somewhere, I’ll take a look. I know I added them last night.
-
Please update working again, sorry I didn’t see that the changes didn’t make it in accidentally. I just re-added it and pushed up those changes.
-
It should look like: