Home » Groups » Endpoint Virtualization

Building an SVS Layer Tom's Way!

Building an SVS Layer Tom's Way!
Filed under: Software Virtualization Solution Build/Rebuild
Submitted by tfronza on 2 July, 2007 - 14:18.

At the Department of Taxation we use SVS pretty much exclusively for the rollout of our applications. We recently moved to an ALL Altiris infrastructure -- everything from Helpdesk to NS and DS. This new direction has made everything very easy to manage. We converted about 150 application packages in a VERY short period of time.

We are currently going through a Windows 2000 to Windows XP conversion which is how we are rolling in the SVS upgrade.

I am one of the Packaging Admins so I, and one other Admin, were responsible for the packaging of all our off-the-shelf applications. Our developers also packaged all their internal applications as SVS layers. That tied up the loose ends and accounted for pretty much every application we use.

So on to building an SVS Layer Tom's Way!!!

  1. Have a Clean Machine (either freshly re-imaged or use one of the greatest products ever -- a Virtual Machine).
  2. Make sure the clean machine has Wise Package Studio or the SVS Admin tool on it. With NO Layers installed on it, and the Juice utilities ExcludeGen and ExcludeCopy.
  3. I prefer SVS Admin rather than Wise Package Studio for a quick build so that is the route I will take at this point.
  4. Open SVS Admin and click File > Create New Layer (CTRL+N)

    5. Click to view.

  5. Install Application > Next

    6. Click to view.

  6. Name Your Layer -- It is nice to have an enterprise-wide naming convention. We use something like this: "WinZip 8.1" a.k.a. ProductName(space)Version. The name you choose here SHOULD be the same as what you want it named in your Deployment Console (VERY HELPFUL).

    7. Click to view.

  7. Capture Mode -- This is pretty important, I have found that running a Global Capture has a lot of merit but will require MORE clean-up after the fact. But a Single Program Capture is more efficient. For the sake of the article I will do a Single Program Capture. Browse to the Program you want to install.

    8. Click to view.

  8. Click OK to begin the Capture

    9. Click to view.

  9. Notice the Spinning "V" in the Taskbar, that shouws you it is working (capturing).

    10. Click to view.

  10. The product is now installed and ready for editing. Deactivate the layer by right-clicking on the layer and clicking Deactivate Layer.

    11. Click to view.

  11. I find it helpful to RESET the layer right off the bat. So right-click the layer and come down to Reset Layer.

    12. Click to view.

  12. Make sure the layer is still selected. If it is not, just single click to highlight it and click Edit Advanced Layer Properties.

    13. Click to view.

  13. This is the nuts and bolts of the layer and could make or break your package. I found that there is a folder called Prefetch that gets noticed by SVS and needs to be deleted. Winamp did not capture it this time. It tends to be in System\Windir\System32\Prefetch. You get better at this step with the more packages you do in your environment.

    14. Click to view.

  14. Do a start > run > regedit and find the FSLDR folder. Find the associated SID in that package and delete it. It is usually in the higher of the two numbers in the HKLM\Software\fsldr\3\HU\S-1-5-21-1129....

    15. Click to view.

  15. It is helpful to show hidden files and folders at this point. Now that the SID is gone in the registry you must do it in the File System also. To do this, go to My Computer c:\fsldr\3\S-1-5-21-112987585-37704086-1691616715-1868 and delete the SID. Yours will not be exactly the same as mine but it will be similar.

    16. Click to view.

  16. I find at this point I need a couple of very useful utilities, "ExcludeGen" and "ExcludeCopy". They are readily available on www.symantec.com/community. Next, run ExcludeGen. The command looks like this:
    excludegen temp "Winamp 5.32"

    This will create a 2nd VSA in your SVSAdmin tool, called temp. Think of it as a "safe harbor" for your exceptions.

    17. Click to view.

  17. Now you have to copy your exclusions over to your SVS Layer. To do his you must run ExcludeCopy. The command looks like this:
    excludecopy temp "Winamp 5.34"

    At this point, you are copying the extracted exclusions over to your new VSA. Now look at the Advanced Layer Properties. The exclusions there should include a bunch of new entries. You may now delete the temp VSA. It is no longer needed.

    18. Click to view.

  18. The VSA is now safe to export, by right-clicking and coming down to Export Layer.

    19. Click to view.

  19. Try to keep the same name here as you used for the VSA layer. It makes everything really consistent. Click Save and you're done.

    20. Click to view.

  20. You will see this while it is extracting:

    21. Click to view.

  21. And this, when it is done:

    22. Click to view.

  22. Now we need to test the layer (this is the easy part). Open the SVS Admin tool, right-click your layer, and vlick Activate Layer. Use the application and see what you think. See if all the functions work as expected.
  23. Congratulations! You just built a Layer!
  24. Where you go from here is up to you. At Tax, we run the layer through some testing, with the "Sponsor" of the application or a "Power User" of the app. Then the application is copied out to our SVS storage location and it is replicated out to all our package servers. We also build DS package jobs associated with those VSA files. Our help desk can then push the apps to the users as they call in requesting them.
4.125
Average: 4.1 (24 votes)

This is....

FrankB's picture
Submitted by FrankB on 2 July, 2007 - 15:10.

This is the best tutorial i've seen.
Thank You, Great Job.

My Respect, FrankB

Nice write up

jjesse's picture
Submitted by jjesse on 2 July, 2007 - 19:32.

Tom,

Its nice to see you guys sharing your knowledge here. Great job on this one.

JOnathan

Many compliments for SVS

riva11's picture
Submitted by riva11 on 3 July, 2007 - 09:08.

Many compliments for SVS Tom's Way!
Regards
PM

Thanks for the Support

Submitted by tfronza on 3 July, 2007 - 11:09.

Thanks guys for all the support just trying to give back a bit....Hopefully this can provide a bit of a standard for others to follow and use!

Good Luck
Tom Fronza
State of Ohio
Dept. of Taxation

SID Deletion

Submitted by Brad Horrocks on 3 July, 2007 - 15:14.

What purpose does deleting the SID have?

Deleting User-Specific Areas in a VSP for Distribution

Scott Jones's picture
Submitted by Scott Jones on 3 July, 2007 - 15:48.

Those areas are the user-specific parts of the layer. They get created after the capture, on the initial layer activation. They get created using the SID of the user currently logged in on the package-building machine. Although it's not critical to delete them, it's a good idea in the interest of cleanliness; otherwise you have a little unnecessary clutter in your package.

I wish that SVS Admin didn't automatically activate a layer after completing a capture. If it didn't, you wouldn't have that cleanup step. In Wise SetupCapture, it either doesn't do the activation or it does but deletes the user-specific areas (not completely sure which it is). Either way, you don't have this step with SetupCapture.

WPS - Ignores this

Submitted by tfronza on 21 July, 2007 - 05:43.

Scott, I think WPS by default ignores this and in doing so it never sees that area of the registry. I have been through several WPS classes any if I remeber correctly my first trainer Jimmy Wu said WPS by default uses your built in execptions and that is one of those areas.

Thanks
Thomas Fronza
State of Ohio
Dept. of Taxation

Exclustion List

Submitted by Richard Jeffrey on 29 December, 2007 - 13:23.

I'm sure that WPS uses an in-built / hardcoded exclusion list and not the WPS one (WSP\RePackage.INI). I believe this is the same approach as the Wise Web Capture tool, which uses its own exclusion list too. I'm sure you don't get to see the exclusion list as they are hard coded in the tools. I think this sucks and leaves you having to do more manual editing, even if you use the WPS tool. They should both have an external / editable exclusion list like RePackage.INI

RE: SID Deletion

Submitted by AngelD on 3 July, 2007 - 15:50.

The SID in the writeable sublayer is populated during creation of the layer and is associated with the user who created the layer. If you're going to deploy the VSA (layer) enterprise wide then that info will be of no use for the other domain users. This is a first step of cleaning up the layer before exporting to a VSA.

Great step-by-step Guide

Submitted by philparkin on 3 July, 2007 - 16:54.

Nice work - thanks.

Just one question - why do the RESET (point 11)? Surely no need, as the layer has just been created?

Cheers
Phil

Why resetting layer

Submitted by AngelD on 3 July, 2007 - 17:25.

As the layer gets activated when the capture has ended the writeable sublayer will (could) get populated with files and registry entries if example the virtual application performs any autostart actions. So by deactivating and resetting the layer before exporting it you make sure the layer does not contain any unnecessary resources that will be populated from the read-only sublayer when the virtual application is first used instead.

Got it

Submitted by philparkin on 3 July, 2007 - 23:55.

OK - I see. That's also what Scott is referring to in his message above. Thanks guys.

Exactly could not have said it better myself

Submitted by tfronza on 4 July, 2007 - 06:08.

Thanks Angel I could not have said it myself. I think SVS has a great many enterprise uses and most of the steps I do to roll out a package are built to be rolled out to the enterprise and if you look further on juice one of my co-workers Jason Cordell has written up how we are using SVS

http://juice.altiris.com/node/1706

Thanks
Tom Fronza
State of Ohio
Dept. of Taxation

What about Vista?

Submitted by vocalc on 5 July, 2007 - 03:44.

Thanks for this very helpful guide.

I'm intending to capture applications using SVS to run on Vista based clients. Does anyone know if it's best to capture these apps on an XP system or a Vista based one? Does it even matter?

If anyone can shed some light on the pros and cons of, I'd appreciate it.

I find that.....

Submitted by tfronza on 5 July, 2007 - 09:08.

I find that when packaging for the WHOLE enterprise it is better to package on the OS you will be distributing to if your clients are XP then build on XP if you clients are Vista then build on Vista but..... Layers use universal standards and you layer might work between OS's usually depends on the Application, I recommend testing. Try it once and see if it works, as SVS uses COMMONALITIES like COMMONDESKTOP and COMMONSTARTMENU your app might actually work across platforms.

GOOD LUCK
Tom Fronza
State of Ohio
Dept. of Taxation

VSAs on different OS

Submitted by AngelD on 5 July, 2007 - 12:37.

The golden rule is to always capture on a clean machine and the lowest operating system for those you're gonna deploy to in the environment. There is no guarantee that the same virtual application (VSA) will work on higher operating system then you captured on but it's more likely that they will rathen then if you had done the reverse.
And as always; test, test and test.

Shared Components

Submitted by R-Vijay on 12 September, 2007 - 08:21.

Its always better to check for shared components and system files (winnt\system32 or windows\system32) while dealing with these cases.

Though, capturing on the lowest OS is a base rule, This may need some file isolation to be done for its optimal functionality.

Nice job

Submitted by crindhag on 11 September, 2007 - 13:43.

Very concise and detailed steps.

Thanks!

Thanks

Submitted by tfronza on 11 September, 2007 - 18:10.

Thanks crindhag.....

Hopefully you can use this in your deployments too This process has worked well for us!!

Tom Fronza
State of Ohio
Dept. of Taxation