Virtualizing Apps, Let's Talk About Capture
Filed under:
Software Virtualization Solution
Packaging
Submitted by Jordan on 3 September, 2008 - 09:35
I work a lot with capture and SVS so I'm extremely curious as to what Juice users think would make capturing/packaging on SVS a more worry-free, easier process. If you have a minute, please post a comment and let me know what frustrates you with SVS capture, what features you'd like to see as part of a capture utility, and/or what you think would be a good approach to making it something less intimidating for new users.
Also, sharing one of your first capture experiences, what your impressions of SVS were going into the capture, if we communicated through documentation the proper methods clearly or not, and any problems you had with the capture for whatever reason, would be helpful.
(25 votes)
Well...
I've also captured a lot of packages with a lot of diverse other applications also, I have a lot of experience with MSI packaging, this is why I favor SVS.
One of the things I would like to see is a way to create a template for the capturing process.
e.g. Excludes/Autostart/Autoclose.
Maybe a process equal to SVSCleaner.
Registry Excludes would also be a nice thing to see.
Global excludes are already a feature, but I would like to see this in a sort of template.
Think about this, I took over the SVS packaging process of someone else at a customer, but due to inexperience they forgot to set a lot of settings in the layers, they weren't even cleaned before distribution.
This caused some issues on several computers, this is why I was called in, and saw these issues arise.
Same thing for the homeusers.
Confidence keeps holding them back, so making these parts easier would be great.
______________________________________________
Frank Bastiaens
Senior Technical Consultant
Vanderlet B.V.
I agree with you on the
I agree with you on the SIDs and the exclude stuff Frank, I see that Excludes tend to be the biggest problem causer (not having them).
Registry Excludes are something that requires a new driver so you'll probably see that eventually but it's not something that can be done just on the user level.
I do have a templating tool for global excludes, it lets you export them as an XML file then import them in to a different machine. I wrote it because there was no good way to transfer global excludes with a layer. You can find it here.
Indeed Jordan
About your tool, am I correct to understand this is only Global Excludes?
It would be nice to optimize an environment with these settings, but the Dot Net 3.5 holds a lot of companies back, this is not a major requirement to rollout to the desktops, and hasn't been done, could you also make a dot net 2.0 version?
______________________________________________
Frank Bastiaens
Senior Technical Consultant
Vanderlet B.V.
Of course. I tend to use
Of course. I tend to use .net 3.5 for the WFP (improved GUI stuff) but any command line tools don't need it.
So what other items should be included? The only other global settings are Program ignore and global onEvents.
Some things I would like to see...
I have been using wise package studio for several years to capture msi's we are now using wise to create svs packages. Some things I would like to see listing of the total number of (files) and (registry) keys like in wise. The ability to export a registry key from the wise svs editor (like in package editor). An Events script setting for On Post Import how else are you supposed to remove a previous version before putting down a new version? Currently wrapping the whole removal and laying down new vsa in a wrapper wisescript...but that does not help when its streamed through SVS Pro. A way to view services or environment variables other than the registry (similar to wise). That's all i can think of now but I am sure I will be back with more.
Some of those features are
Some of those features are in SVSadmin.
You can't edit onEvents this way but you can view environment variables by double clicking on an inactive layer. By bringing up the layer properties window you can see how many files and reg keys are in the layer as well.
What students say
In addition to doing a lot of packaging with WPS and the SVSAdmin, I also teach the Wise classes. In the basic class I usually let the students work with SVS on the last day, after they've spent 4 days learning the ins and outs of WPS and the Windows Installer technology. What they usually say after their first capture is something along the lines of "Wow, that was easy!". In comparison to capturing MSIs, it is easy.
But after they've had a chance to capture a few apps in SVS I tend to hear the following concerns come up regularly.
First, reboots: WPS, when packaging MSIs, stresses rebooting during every capture. With SVS this is no easy task, and the process must be explained (often several times).
Second, updates: Updating a package is fairly easy with the SVSAdmin, but isn't exposed very well. New packagers often forget where in the menu the update option is hiding, and I get regular emails from less exploratory students.
Third, WPS vs. SVSAdmin: There are still several functions not shared by the SVSAdmin and WPS. For an experienced packager this is no big deal. But for a new packager it can be quite the quandary. A true matching of functionality between these two packagers would make the whole process much easier. I'm not suggesting we remove one tool for the other (though I expect this will happen eventually). It would just be nice if we could choose either knowing that it could perform the whole task.
As for my part, I'd like to be able to delete the file portion of the logged on (packager's) user profile from within the SVSAdmin like we can the registry portion. Like most packagers, I'm rather used to doing this from the FLSRDR directory before my final export, but it'd be more convenient to do it right from withing the advanced editor.
That's some really good
That's some really good experence info, thanks. And, like Frank mentioned, we need a good way to deal with cleaning up user info out of a layer.
Agree
Added to Josh's comment I'd like to see:
Able to add files to the Meta layer through the 1.Virtual Package Editor
2.Set Permissions in the Editor that are applied to the Redirection Layer
3. Export of Registry
4. More support for Fonts
5. Inbuilt support for ini files (like WPS)
6. Automatically remove of Darwin info (as an option) for captured MSI installations
7. A few more things that I cannot think of at the moment, because it's been a few weeks since I did any SVS packages... ;-)
Cheers
Phil
Very valuable thread
Thank you Jordan for starting such a valuable thread.
What I miss the most compared to msi capturing with WPS is the neutralization of user or computer names after the capture (like [LogonUser] or [ComputerName] with WPS in MSI).
And the hard thing about it, IMHO there's no search function to find those names in the package (like we can search the tables in Windows Installer Editor).
Not to forget: SVS is just great!
Not quite sure what the
Not quite sure what the search function would be used for, is there an article or something on the Widows Installer feature you mentioned so I can get an idea?
Advanced Capture
What would be handy is an 'advanced capture', so you can immediately see which files and registry settings have been captured, and mark them for exclusion. Then you wouldn't have to go and edit them out afterwards.
And maybe also a pop-up box that shows the things being captured at the moment they are captured?
Also handy would be an option for 'continue capture' in case you have 2 installations to do, 1 after the other. Then you don't have to go back to SVS, choose 'Update layer' and find the layer you just installed.
All basically just time-saving options...
I've actually been working
I've actually been working on a packaging wizard that will do the first thing (letting you know what file types the program in the layer can modify and asks the user what they want to exclude or add to a data layer).
You can do the continue capture now by first capturing a command prompt and launching things from there but I agree there should be an easier/obvious way to do this in SVSadmin.
Advanced Capture
These features is already available, in the WPS - SetupCapture... Get the WPS (Professional) and you can have a play...
As for using SVS Admin tool, for capturing more than one installation capture a "Command Box", and install the apps from the command box one after the other.
Cheers
Phil
I'm waiting for it !!
Jordan,
I'm waiting for such tool.
Please release it soon.
All the very best! Keep up your good work.
Greetings,
Swami.
Capture
I'd like to add my vote for capture excludes, and I would also like to see a simple way of moving resources from a writeable to a read only layer as this will go a long way to sort out the "reboot" changes caused after some application installations.
As a long term WPS user, the arrival of SVS offers a 'quick and dirty' way of packaging applications and allowing user acceptance testing while configuration issues are worked out. Once this is complete, it would be excellent if the exported SVS application could be directly imported into WPS, not as an SVS project, but as a WSI project.
This would enable editing of the project and generation of an MSI which can then be deployed directly or via SVS.
Capture
I have been thinking along the lines of you EdT for some time now, but the other way round, MSI -> XML -> SVS project.
It is easier to carry out the analysis of an MSI package (table queries) to assess if an application can be virtualised, before attempting to go for SVS.
cheers
Phil
Search for user credentials
Sorry, what I wanted to say is, that after capturing an app with WPS (wsi/msi format), I search for user credentials and machine name in all the tables to replace them with variables. However, imo neither SVSAdmin nor Virtual Package Editor provides such a search function to find those credentials (i.e. user or computer names in reg keys).
rpfenninger
Instead of using the tools you mentioned, just go to the registry directly : [HKLM\Software\fslrdr\
In there you can search with the registry editor.
______________________________________________
Frank Bastiaens
Senior Technical Consultant
Vanderlet B.V.
Strange behaviour
Jordan,
One good feature that is not in SVS is the ability to search paths.
When i start a capture, and as the captured program i like to use cmd.exe, i alway's have to type the full path.
So instead of just simpley typing cmd.exe, i have to give c:\windows\system32\cmd.exe
The SVS start capture simpley does not read the standard paths that enables this.
Regards
Erik
www.DinamiQs.nl
I agree, I'll bring this
I agree, I'll bring this up.
in the mean time try using %comspec% which is shorthand for C:\windows\System32\cmd.exe
Firewall Exceptions
It'd be nice if firewall exceptions were auto-corrected or at the very least provide a utility to more easily translate/create these exceptions.
Would be nice to capture
Would be nice to capture hardware device drivers...e.g., Sentinel and NetHASP. Anything in the future about this?
Drivers are hard because
Drivers are hard because many load before the SVS driver loads which prevents any driver virtualized that needs to load sooner then we do from ever getting loaded into the system. That's a tongue twister.
There are some other issues with drivers but that's the main one.
Hardware drivers
Sebtinel and NetHasp drivers can be done with a altered SVS version. i gave a demonstration of that in Malta.
Sentinel is real hard, but Nethasp can be done with the regular version of SVS.
I have very much succes with drivers, but they need to load in Osi layer 4. Then it will work.
Use netstart to start the driver from a onpostactivate event.
Regards
Erik
www.DinamiQs.com
DELETE & IMPORT VSA 1 single command line
Hi, When integrated the Altiris NS, there is a missing command, to simplify update existing VSP. Just add a command like "DELETE & IMPORT" or "UPDATE" etc... This is a missing (we could think the 15 existing "program name" should be enough, but it is not ;-)
- Currently to update an existing layer on clients, you must DELETE before, because import a Layer will give failed error 1060... :-(
Except I miss something on Juice?
~~~PaKo
you can use the Force
you can use the Force switch (-F) to have Import overwrite an existing layer. Layer names are what's unique with SVS it's a GUID for a layer.
In SVS "Updating" a layer means placing it back into capture mode which isn't what you want to do, that being said layer patching, as mentioned in this article, is something I think you'll like.