Feedback: Snap-in system
-
Please list any problems or feature requests for the snap-in system.
If you have any suggestions, they are more than welcome.
Be short and to the point, list form is more than acceptable.
-
I’m guessing the snap-in system is perfect! No changes required! :eek:
-
I haven’t used the snapin system in a while (over a year), but if it hasn’t been improved since 0.29 then I would guess it still has issues with defining an order for deployment. There were some tricks to get it to function in some sort of hierarchy, but there was no way of explicitly calling dependencies, so it didn’t matter if snapin02 required snapin01, and if snapin01 failed it would continue on with installing snapin02.
I also recall hearing complaints about it only allowing a single executable file, so there was no straightforward method for pushing down a collection of scripts or config files.
as per your request:
[LIST]
[]Order of deployment (weighting snapins)
[]Dependency
[*]Multiple files
[/LIST] -
I’d suggest the order of snapin deployment.
-
Thanks for the feedback guys.
Multiple files is a hard one as it will require a lot of work (more than i can do before 0.33)
Dependency & weighting are very possible though.
-
Deploy a single snap-in to a group was something I always needed. I’ve a feeling someone has submitted code for this though. Connection restrictions would be good to, on a per snap-in level so large downloads from the server can be restricted, or ideally, throttled down. Add a reboot option to only reboot if no one is logged in so installing a snap-in won’t interrupt someone’s work but would ideally reboot if the computer was unused (maybe when they log out?).
-
- dependency/ordering would be tops on my list
- making click to install icon in FOG Tray menu would be very nice also even though I understand that will probably take some work.
-
I would like to see a way to remove all snapins from a whole group. we repurpose PC’s around here alot and sometimes we setup a group of PC’s that have all sorts of different snapins associated to them. The only way to remove them is to do it snapin-by-snapin. When we have 30+ snapins it can take quite a bit of time.
I would also like to be able to change the time snapins are checked for, and the time the client waits after starting to check for snapins.
-
it would be great to have a better application to make the snap-ins! the installrite seems to record reg structure which is messy and the sfx is ok but needs alot of work. I would like to see the snap-in system changed to more of a push type of method as it seems like its more of a pull type now, i think we should be able to rapidly infuse applications on to our client machines from the fog interface
-
Keep them coming guys, this is great feedback.
Sadly, snapins in FOG are very primitive and are certainly not an enterprise solution.
Right now they are there to get you out of a jam, they are not designed to deploy gigabytes of data.I would love to revamp the system, but application packaging is a massive task. I would feel much more comfortable implementing an open source system to handle this so we dont need to worry about it. TBH, i havent looked at what is out there.
Maybe application virtualization would be a better idea?
If anyone has any ideas, please feel free to post.
-
[URL=‘http://wpkg.org/’]WPKG[/URL] might be worth looking into; perhaps building a middleware plugin between WPKG and FOG, which could allow official updates to WPKG to continue without taking away much of the FOG developers time.
-
The existing snapin system isnt that bad. I don’t mind making snapins, but deploying them is clumsy. And so is trying to train people on how to properly deploy them.
Maybe if there was some sort of “Host Profile” template system.
For example, create a template that contains everything that would be normally manually defined in a group and be able to apply to a new group with 1 click. Image assoc, os assoc, snapin associations, AD settings, etc.
If we had this I could simply tell my technicians “Image training room 1 with the HR template”. Without having to tell them which snapins that contains etc. When it gets applied to the group, it would clear any previous snapin associations, service settings and anything else host specific that was changed.
-
[quote=“Blackout, post: 420, member: 1”]Keep them coming guys, this is great feedback.
Sadly, snapins in FOG are very primitive and are certainly not an enterprise solution.
Right now they are there to get you out of a jam, they are not designed to deploy gigabytes of data.I would love to revamp the system, but application packaging is a massive task. I would feel much more comfortable implementing an open source system to handle this so we dont need to worry about it. TBH, i havent looked at what is out there.
Maybe application virtualization would be a better idea?
If anyone has any ideas, please feel free to post.[/quote]
application virtualization is a good idea but costly one thing we have alot apps that could work with something like remote app but dont wanna go down that road
-
My biggest frustrations with the snapin systems are 3 fold.
#1. The inability to upload folders to the snapin system, and then run a .exe or .msi directly from the uploaded folder.
I’d love to take an office install / Adobe Pro install / etc. and just upload the entire installer folder, and then have the client run the .msi / .exe of my choice. Currently I have to use SFX Maker or some other encapsulation software to package it as an .exe and then tell the software to run the file of my choice (seems like I’m duplicating work)
#2. The wait time of the snapin ins needs to be cut down… WAY down.
Currently the fog client waits I think 5 min’s when first checking in with the server to see if there are any tasks. I’d like to see this cut down to say 1 min at most, or even give us the option of changing it during the install on the client side.
I can edit the .ini file after the service has been installed to check in more rapidly AFTER the wait time. But why have it wait 5+ min’s before checking for a job? Is this due to the network traffic it would generate?
#3. Updating the snapin to play nicer with Windows 7.
I’d like to have the snapin play nicer with Windows 7 in regards to the UI, and perhaps have a simpler way to push the software out via GPO.
-
I do not feel that application virtualization is a sutible replacement. We have a very large VMWare infastructure in place here, with ThinApp, and while it does have it uses it can not be used for a lot of things.
-
[quote=“ssx4life, post: 693, member: 268”]
#3. Updating the snapin to play nicer with Windows 7.
[/quote]Ditto on this one !
-
A slot system would be nice to prioritize the installs of the snap-ins. This idea comes from Deploy Studio for Macs. You can decide in what order you would like what application to run. The problem I run into is that I would like a specific program to run last because it needs to restart the machine. So it would be nice if I could have that go last so I don’t have to wait for a reboot, the client to checkin, and start deploying more.
-
I would absolutely love to see another application to create snapins. Because unfortunately, InstallRite seems to be a “hit-or-miss” problem. Not to mention, I’ve also used another custom build repackager called “AppDeploy” which has the same concepts as installrite, but converts it into an MSI form. (There’s other little handy features it comes with as well!). However, when running MSI’s and putting in arguements and everything needed to run the MSI snap-in; sadly it fails because the account for which it is to be installed on, does not have the permissions
-
I too would like to see a Single Snapin to a group option. In version .28, I manually added it as an option for my fellow techs, but have been unable to do so in the latest release.
-
i would like to see maybe a progress bar or be able to send detail to the gui like what stage of the script it is installing if it is a multiple software install script… I.e Installing Adobe… Then Installing Java etc. etc…
