I don't know about you but every time I have an SVS question there seems to be no one place to find all of the Answers I need. It takes a combination of Knowledge Base articles, Product Guides, and Juice articles to fit all of the pieces together. With that problem in mind here is a list of key hidden features that I have found vital to successfully implementing SVS in our company.
The Problem: Many applications have test files or .ini files that they utilize to store application settings in. It is a common practice to manually change the settings based on your needs. The easiest way to change them is to open the file using the Windows default text editor Notepad. What happens though is that none of your changes are recognized by the application. If you open up a text file in C:\Program Files\ApplicationX, make changes to it using something like Notepad, and then save those changes they will not be saved as part of your virtual layer.
The Reason: The text file that you are trying to edit is running in a virtual layer and only processes that are part of that virtual layer can make changes to those files. Editing the file using a program outside of that virtual layer such as Notepad will save its changes to the Base as Notepad is also part of the Base. You will then have two copies of this file. One copy will be in the redirection area under c:\fslrdr and the other will be in c:\Program Files\ApplicationX. Since the virtual layer will take priority over the Base the virtual copy of the file will always be used by the virtual application.
The Solution: There are a few workarounds for this issue.
- Manually change the file in the redirection area in c:\fslrdr
- Exclude the file type from the virtual package and manually copy it to the Base (see section below on using meta folder for details)
- Launch Notepad as part of the virtual layer and then edit the file. (my recommendation)
The easiest way to do this is to create a shortcut and include it as part of your layer. I just place the shortcuts in the programs folder along with the file. Use this command line for the shortcut:
"SVScmd SVSpackageGUID exe -p notepad.exe c:\PathToFile".
This way you will have the shortcuts readily available and do not have to remember a lot of extra steps to edit simple text files.
The Problem: Hidden inside of SVS is a great feature called onEvent actions. Documentation on using these can be difficult to find but at the end of this article are some good links, and no way to use them via the standard GUI. But deep inside the registry you can exploit these very useful features.
The Reason: These are triggers that you can use to kick off scripts or other commands when certain events happen. Suppose you have a script that needs to run when you Import a layer or even when you delete a layer to fully clean it up. These registry keys can be used to run any commands that you put in them. (Note: the regisrty key is REG_MULTI_SZ)
The Solution: First here is a list of all of the onEvent actions that you can use.
They are all just registry keys that you have to manually create. The place to create them is inside of your SVS packages registry keys. The key is HKLM\SYSTEM\Altiris\FSL\1 (replace with the layer's number.)
Many times I will have packages that need to have certain settings on the computer updated or just a simple file copy job done when the package is imported. By using the onPostImport event I can execute any script or command to automatically complete the load of my package. To completely clean your packages up when you delete them you could use the onPostDelete event to call a script that can do the final cleanup.
These commands are very useful to help you fine tune your SVS packages and settings. Especially for some of those pesky programs like Microsoft Office that just refuse to virtualize efficiently. You could even have some fun with these and use them to play sound files to let you know certain tasks have happened.How to Include Base Files and Scripts as Part of Your SVS Package
The Problem: There are many times when you want to include some files such as scripts as part of the SVS package that gets copied to the PC but you don't want it to be part of the virtual layer.
The Reason: An instance where I have needed to do this is to copy a .ini file into the c:\windows folder and needed it to be part of the Base instead of the virtual layer. This way other applications could use it and update it as needed.
The Solution: There is a great little folder that you can create in each of your SVS packages called the Meta folder. This is a folder whose files will remain as part of the Base and can be used as needed. The best part is that each layer can have its own Meta folder and is referenced with variables. This allows you to have files and scripts that are specific for each layer.
The folder is not created by default. You will have to manually create the folder inside your package under the redirection area. Depending on the number of your layer you will create the folder in C:\FSLRDR\1\Meta (the number is different for each layer). Once you have this folder created you can copy any files needed into this folder and they will be loaded into the SVS package automatically.
To reference this folder you will use the SVS variable %VZ_LAYER_METADIR%. This variable is used so that the layer can find its own Meta folder regardless of the layer number.
Using my example above of needing to copy a .ini file into the Base you would follow these steps.
- Place the .ini file in the C:\FSLRDR\1\Meta folder
- Using the onPostImport event call this command: xcopy %VZ_LAYER_METADIR%\file.ini "%WINDIR%\" /Y
When the SVS package is imported this command will execute and by using this variable it will look into its own meta folder and copy the file out of it and in this case into the Windows folder.Why Do Shortcuts Still Work Even When the Layer is Deactivated?
The Problem: If you create a shortcut to your virtual program and save it outside of the virtual layer the shortcut will still work even when the layer is deactivated. This usually happens when a user decides that they want a desktop shortcut along with their start menu shortcut or they just want to rename the existing one.
The Reason: Once you have a shortcut that is part of the Base it will not be removed when a layer is deactivated. Microsoft Windows includes a technology to make its shortcuts smarter. If the file the shortcut refers to is missing it will search the drive for another file with the same name. Since the SVS files are all in the redirection area windows will point the shortcut to the .exe under c:\fslrdr. Now the shortcut still works and the program is running as part of the Base instead of in the virtual layer. This is very bad since it could also cause alterations to your Read Only layer and prevent layer resets from working right. Most likely the program will not even execute and just generate errors that will result in helpdesk calls.
The Solution: The fix to this problem is relatively simple. You need to make the redirect area hidden. SVS includes a registry key to do this for you. Open regedit, go to HKLM\SYSTEM\Altiris\FSL and create a new DWORD value named HideRedirectAreas and set the data value to 1. You will then need to restart the computer before the setting takes effect. Now no one, including Windows, will be able to see the c:\fslrdr folder. When the shortcut tries to find the deleted .exe it will not be able to since the folder is now hidden.
This process also has other benefits. By hiding the redirect folder users will not realize it is there and try to delete it or change it. It will also prevent inventory scanners from being able to inventory the data in these folders (the Altiris Inventory Solution has this exclusion ability built-in).
You can still access these files manually if you need to. Simply use explorer and manually type in c:\fslrdr. This will open up the folder. This functionality is very similar to the way windows hide's hidden folders by default.