Getting More from SVS's onEvent Functionality
Recently I've seen people on the Altiris forum and others around the office discussing OnEvent with SVS. Since I'm the OnEvent tester, I thought I'd share how using this feature in combination with another less known one, the Meta folder. This combination can save time when deploying layers in any environment, be it a large corporation, a small business, or an educational institution. Best of all, it works with custom scripts so it can be used by any existing setup.
Jeremy previously wrote about OnEvent activation in his article How to Launch an Application or Run a Script when a Layer's State Changes. The concept is fairly simple, if you have an action you want to have happen before or after a layer's state is changed, you add the correct OnEvent handler to the registry and viola, your action happens. But what if you want to package a script with a layer? Or what if the script needs to run on a preEvent? Or what if the script needs to run from the base?
That's where the Meta folder comes into play.
The Meta folder is something we added a while ago and is briefly mentioned in this Knowledge base article on preActivate, but it can be really useful with any pre- or post-event as well. The Meta folder allows you to easily package a script with a layer that you can run with onEvent that's not virtualized (meaning it always runs from the base and not the layer) and will work with either pre- or post-events.
Using the Meta Folder
Using a Meta folder is fairly simple but requires a little work. First off this is not something created by default in SVS -- you'll need to create the folder yourself in your FSLRDR directory. (The FSLRDR is a hidden folder stored at C:\FLSRDR.) Before you can do anything, you need to find out which Magic Number is what layer.
Finding the Correct Folder
Open up RegEdit and navigate to HKLM > SYSTEM > Altiris > FSL. There you'll see a bunch of folders labeled the same as in C:\FLSRDR. You can check for the Name or ID values with Name myProgram being the Read Only and myProgram_ FSLPEERFSL being the Write Layer. For IDs, the one that matches the GUID given in SVS admin is the Read Only and the other is the Write Layer.
So for example:
Name: Office 2007 is the Read Only
Name: Office 2007_ FSLPEERFSL is the Write Layer
Creating the Folder
Once you know what the label is for your folder, navigate to that folder in the C:/FSLRDR and then create a new folder named "Meta". You can have multiple Meta folders at once, but only one per layer. So you could have one for Office, one for Photoshop and one for Firefox if you want; but not 2 Meta folders in the Photoshop layer. Whatever you place in that folder will be exported into the VSA on export and ready for easy access on delivery.
Referencing the Folder
When running a script from a Meta folder via an OnEvent action you use the environment variable %VZ_LAYER_METADIR% to reference the Meta folder. Without using this variable you'll have to try and figure out what that folder's label is. This will probably be different on every PC depending on how many layers are installed.
For example, this registry OnEvent key:
This will launch the myScript.vbs in the referenced layer, however you can't cross-reference meta folders, meaning you can't have an OnEvent shown above in one layer and called by a second. If myScript.vbs isn't in the same layer as the above registry key, nothing will happen.
Using with OnEvents
Now that we know what the label or magic number is for the layer and we have created the folder in the appropriate location, we can use OnEvents and the Meta Folder together. Let's say you're about to roll out Office 2007 to all your users and you need to have a simple way of copying fonts to the correct place so Office and SVS will play nice together. (Some fonts in the layer are not available to the application [link: kb.altiris.com/display/1/kb/article.asp? aid=20...] for more on this.) You either have your own script written up to manage this or you want to use the utility CopyFonts.exe.
There are many ways you could do this; You could push out the script you created and have it run, but then you have to deal with computers not being on, the Office layer not being active so nothing happens or any other manner of issue. Or you could just use OnEvents with the Meta folder and package the script/utility with the VSA and know it will run when you want it to -- after the VSA has been imported.
Creating the Registry Key
So first off we'd find the corresponding registry folder and FSLRDR folder as described previously. After doing so, create a new multi-string value named OnPostImport. The reason we're using onPostImport here is so this process only happens once, after the layer is initially imported. This will prevent a possible CPU spike every time someone activates a layer (at start up in most cases). If you work someplace, like a design company, where people tend to download and install new fonts, you might want to change this to onPreActivate depending on how SVS excludes were set up.
Next copy this line as the value:
w, %VZ_LAYER_METADIR%\CopyFonts.exe myLayerGUID
And replace myLayerGUID with the GUID if your Office layer (found as the ID in the same registry folder or via SVS admin).
Copying Files to the Meta Folder
Lastly, copy CopyFonts.exe into that layer's Meta Folder and you're ready to export.
Now, when you push out a new application, CopyFonts.exe will copy all the fonts over to the base and your job is done.
While you can create this folder for either the read or write layer it's best to place it in the Read Only unless you know you'll never need it again even if a layer is reset.
When creating links to OnEvents, it's best to use the full path to the program, unless you're certain about the environment variable being set up on all PCs (as would be the case with %vz_layer_metadir%, every PC that has SVS has this variable set).
Always test your OnEvent Handle before pushing it out, preferably on a different PC or Virtual Machine.
There are some things best not done this way, like reGUIDing on export. If you try to run a tool like GUIDer via OnPreExport you could get errors that will cause your Export to fail.
Unless the process is critical or low CPU usage, it's best to not use scripts with any of the activate or deactivate OnEvent handlers unless necessary. On pre- or post-Activate these scripts can really slow down the user's logon or start-up. This is especially true if you have multiple scripts running at once.
If it's something that needs to be done once -- like OnPostImport -- that changes something in the Write Layer, remember to add it for OnPostReset as well in case the layer is reset. You wouldn't need to do this in our above example with CopyFonts.exe because it's copying something to the base and so resetting the layer has no adverse affect on the changes.
To run a script that adds new values to a global exclude list when a layer is first imported. This would be useful if you push out a new program (like Office 2007) that has a lot of new extensions and you want to make sure none of them get saved to any layer.
When adding a data layer using a utility to copy all the correct file types to it then add excludes to all the other layers. FindExcludes.exe sort of works this way, but copies to the base instead of a data layer and doesn't add anything to the exclude list. Data layers are really useful but sometimes not something that's always set up at first. If you want to add them to a group of pre-existing layers, that are already deployed, this would be a good way to do it.
Using Data Capture Updater to modify an existing Datalayer if a second one is imported. See Data Capture Item Updater. Not as common as the previous usage, but some people like having a different data layer for each different file type or group (like all Office files go into one, all other files go into a second).