Troubleshooting Virtual Software Packages

So, finally you've decided to install SVS and you want to build your first packages! On the Juice you've found all the articles about packaging. You found out that you can choose between Single Program Capture and Global Capture. You also found out that a Global Capture takes a lot of work to clean up. You read a post about cmd.exe that enhanced your packaging skills. You even found, downloaded and tested the multiple packaging tool on the Juice.

Searching the Internet you found various free software packages. Download and import, and you're ready for work.
But now you are facing the challenge of your life: Creating, editing, and managing you're own packages. I'm going to give you a few tips to be more successful in packaging.

Tip 1: Always build your packages on a clean machine. First install Office Suite on the machine that you wish to use on your clients. Then go to update.microsoft.com, and patch the machine.

Tip 2: Make sure you're packaging machine is not attached to a domain. Keep it in a workgroup. The reason why? Simple. Logon domain policies. Machines connected to a domain ALWAYS get the local domain policy.

Tip 3: Disconnect your packaging machine from the Internet, and stop any virus scanners on it. When you are not attached, you don't need it. The virus scanner can be a pain in the butt when you try to make a stable package.

Tip 4: When you have finished your package, first export it. After the export you can start it for the first time. In some software on first boot, things can change, and this gives you a backup to the initial package.

Now you have a working package. Export it again, and import it on a different machine. There are two things that can happen now. First, import is successful, and the software works like it is supposed to. The second one is that the package is not working and generates a error. Now you are in trouble and you need a way to find out what is wrong.

When you start the application you can get several errors. I'm trying to help you to find a way to resolve your error. Please remember that this never can be a complete list, so if you find your own error, please let us know.

Error 1: The application does not start, and in your Event Viewer you find a DR Watson message. This is an easy one. In the DR Watson message there is always a Event ID. Copy the Event ID, and go to http://eventid.net. Give it the Event ID and the source, and get surprised.

Error 2: The application starts, and generates a message like integer not found, wrong value, different version expected.

This is the most common message. You have to find out what file this is generating. Follow the steps below to identify the problem.

• Activate the application, and go to c:\program files\application name.
• Copy the folder to your desktop.
• De-activate the application.
• Then copy the whole folder back to c:\program files\application name.
• Activate the package. Over 75% of the application will now work.
• De-activate the application, and then delete the folder that you placed before.
• Now create a folder c:\program files\application name.
• Open the folder with the files on your desktop, and look at the files in the root. Copy these files to c:\program files\application name.
• Activate the application and try again.
• Is it working, then de-activate the application, delete half of the files. Activate the application again. Is the application working?
• Keep doing this until you reduced the amount of files to one or two.
• If the application was not working with the files in the root, then do the same steps for the folders in the folder on the desktop.

How can this strange behavior occur? Some of the application, for instance splash screens will not work when they are virtualized. The file redirection of fslx.sys stops them from working correctly.

So in these cases you need one or maybe two files to stay local. But there is a way to get them inside the package, and they will be exported and imported on every machine where you wish to use this package.

• Open notepad.
• Create a file like xcopy c:\program files\application name\filename that you need to have local /E /S
• Name the file copy.bat.
• Go to c:\fslrdr\package number and create a directory META.
• Open regedit.
• Go to HKEY_LOCAL_MACHINE\SYSTEM\Altiris\FSL. Find out the layer you need to edit.
• Create a multistring value named OnPreActivate and give a value %VZ_LAYER_METADIR%\Filename.bat

Now when you activate the software layer, the file will be copied locally. When you do the same on a pre deactivate, and you replace Xcopy with del, the file will be deleted before the package is deactivated. For application with a driver or a service you can use this also. Windows will see the driver or service as a local service or driver. It works great for software like adobe acrobat or daemon tools.

Still, 25% of software issues cannot be resolved like this. In most cases it's because the files that you need to copy locally are not in the program files, but in windir or even in c:\windows\system32. You can use the same method as above, but it will be slightly difficult because there are a lot of files in c:\windows\system32.

It is most difficult when this occurs because you need to find a registry key. But there is a solution for most cases. Double click on the deactivated package, and go to register. Open it again ONLY in the read only layer system. Go to currentcontrol set, and export them as a reg file. Now when you import this regfile, you will see that the application works.

In the 0.1% that it will not work, you found the holy grail. There are two reasons that an application will not work and will never work.

First is when a application tries to write a register key in system currentcontrolset/ services or ENUM. You probably do not have enough permission as a administrator. There are some very difficult solutions to resolve this, but they are only intended for very experienced IT professionals.

The other reason why software will not work is when it sets registry permissions in HKEY_CLASSES_ROOT. In classes root you will not have enough permissions to set a GUID when necessary. This will only occur very rarely. I have packaged over 7000 apps, and only experienced this once.

I hope this article is helpful for you, and if you have any questions, remarks or whatever, please do not hesitate to contact me.

erik@svs4u.nl

Regards

Erik Westhovens

www.dvs4sbc.com