Client Management Suite

I have been trying to figure out a good way to deploy VSA files with Managed software delivery.

My problem is that I cannot figure out how to make a Detection Rule for SWV:ed apps. Without a detection rule the policy keeps hammering the client with the import/activate job with failures when the application is already imported and the VSA will get  cached and/or downloaded every time.

In case the virtualized application is msi installed I can make detection rule on the msi product code for that application, but that only works if the layer is active. I would like to be able to detect deactivated layers out on my clients and not import if it is.

First I replaced the VSA file in the software resource with a vbscript that checked if the layer was imported. If it wasn't, it imported it from a fileshare. But now when we are using multiple site servers/package servers thats not a good option.

Any ideas?

 

I thougt a bit about this, and the only thing I can think of would be to check and see if the .vsa file is present. I thought that with v7 .vsa's weren't mandatory for virtual apps though.

I could be wrong, but I would think you could use a registry key detection rule.  The app may be virtual, but still brands itself as a normal application when activated.  So, lets say you use managed delivery to run a command to import and activate the application.  You should still have an add/remove program name in the registry at HKLM\software\Microsoft\windows\currentversion\uninstall\productName\DisplayName.

Couldn't you look to see what that display name is and use that to determine if the app is installed (or some other reg key or file that gets laid down in program files)?  If the DisplayName is not there, managed delivery could run the command again to make sure the machine is in compliance.

Just kind of thinking out loud here

RS

he's looking for a way to detect apps that are not activated. If they are activated, it should behave almost like a regular app as far as managed SWD is concerned.

If it's deactivated, he won't have any files or registry keys to 'key' off of right? (Like I said, I'm as clueless as Columbo's brother on this one).

Yes, you are right Jim. My problem is users who have permission to activate/deactivate layers on their computers.

In case a user have deactivated a layer and I'm trying to detect the layer with the MSI product code or any other registry key, my policy wont find it and will keep trying to import the layer. This will generate errors aswell as keeping the layer in the cache. (Wich is bad if you have alot of large apps like CS4, Office 2007 etc)

Since the layers doesn't get fixed numbers in HKLM\System\Altiris\FSL or c:\fslrdr I cannot detect on those either.
I'm thinking about adding a OnPostImport event that creates a registry value in a certain key that I could check for. But that seems like a pretty ugly solution.

I think managed software delivery is the best way to distribute software, but am I totally wrong about using is with virtualized software? How are you ppl managing your SWV layers?

Im not sure that I know where to check if the vsa file is present.

The import is done from the cached vsa file and it will get extracted to the redirection area. After that the vsa has played out it's role and will get deleted when the cache is flushed. I could set that the cache never clears, but then I will end up with alot of vsa files eating space from the clients.

We use tasks to deploy and inventory to detect.  Our "policy" is managed by a filter that you drop out of when inventory shows that you have the specified layer, whether active or not.

Sorry, it's not a managed software solution, but that's how we've been doing it (although we don't currently have much in the virtual space).

-- Mitch

Ok, this is how I solved it.

I edited the MSI file for SWV and added two registry values and one vbscript.

In HKEY_LOCAL_MACHINE\SYSTEM\Altiris\FSL
OnPostImport and OnPostDelete
Both Multistring values and both with wscript.exe "C:\Program Files\Symantec\Workspace Virtualization\RegEnum.vbs" as data value

By putting the OnEvents directly in the FSL key they are "global" and will trigger everytime any layer gets imported or deleted.

I also added RegEnum.vbs into the program files\symantec\Workspace Virtualization folder in the msi file.
This is what the vbscript looks like:
 

strComputer = "."

const HKEY_LOCAL_MACHINE = &H80000002
Set StdOut = WScript.StdOut
 
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")
 
strKeyPath = "SYSTEM\Altiris\SVS\"
oReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys

'Loop through all subkeys in HKLM\SYSTEM\Altiris\SVS and delete them
IF NOT isnull(arrSubKeys) THEN
 For Each subkey In arrSubKeys
      oReg.DeleteKey HKEY_LOCAL_MACHINE, strKeyPath & subkey
 Next
END IF

set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default")
set colItems = objWMIService.ExecQuery("Select * from VirtualSoftwarePackage" )

'Loop through all SWV layers and add a subkey in HKLM\SYSTEM\Altiris\SVS with the GUID as name
For each objItem IN colItems
oReg.CreateKey HKEY_LOCAL_MACHINE,strKeyPath & objItem.Id
next

First I made a script that only added or removed the guid for the layer that was currently added or deleted, but since I don't know if there are any onEvents for patching or cloning I decided to check all layers.

Now I can make detection rules on SWV layers in CMS7 and use managed software delivery. I just check if the reg-key HKEY_LOCAL_MACHINE\SYSTEM\Altiris\SVS\guid exists.

Since I have no OnEvent for updating the registry keys when Im using patches I added the vbscript as a software resource and associate it as a update to all the VPS files. In that way the vbscript runs after every patch.