Video Screencast Help

SWV 7.5.522 Isolation Rules

Created: 14 Aug 2013 • Updated: 11 Mar 2014 | 16 comments
This issue has been solved. See solution.

Has anyone tried using granular isolation rules in the SWV 7.5.522 client? I'm not able to get them to work at all but doing the same thing on 6.1 SP8 client and it works. I've tried adding the key IsolationRules under HLM\System\CurrentControlSet\Services\FSLX\Parameters\FSL\%magicnumber% inside the layer and outside the layer and neither work. I've also tried adding exclude entries and that doesn't seem to work either. I fired up ProcMon and ran a reg query from the layer and I don't even see that value being queried.

Here's an example of one of my rules I was using for testing:

*\reg.exe    edcb0ff0-bbe8-4ea9-a013-e37840e54b20    0x0002    \REGISTRY\USER\S-1-5-18\Software\Classes\CLSID\{CAFEEFAC*    *    BASE

Then when I run reg query from the layer I'm returning all the keys.

SVSCmd.exe "Firefox 19.02" exec -p "c:\windows\system32\reg.exe query hku\s-1-5-18\software\classes\clsid"




I've tried it on 2 different workstations, both running Windows 7 Enterprise SP1 x64 with SWV 7.5.522.

Operating Systems:

Comments 16 CommentsJump to latest comment

EdT's picture

What exactly are you trying to do?

The S-1-5-18 user is the LocalSystem account - I cannot envisage any operation where you need to read or write to this account's user keys.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

jason.f's picture

I was trying to isolate Firefox from reading from the USER CLSID key so it wouldn't see Java installed in the base. I did have it wildcarded so it would read S-1-5*\Software\Classes\CLSID\{CAFEEFAC* but I made it more granular to make sure it was targeting the correct key and not a problem with the wildcard. I am aware that Firefox doesn't use that registry location to know that what Java version is installed but I was starting with this guide ( and working my way from there to make sure I was doing it right.

I have this rule in place in the Base and it does isolate correctly on WinXP with 6.1 SP8 client.

*\reg.exe    8f8d2cf4-c5ab-4efd-9e98-16a5d2a32221    0x0002    *\REGISTRY\USER\*    *    BASE

SVSCmd.exe "Firefox 19.02" exec -p "c:\windows\system32\reg.exe query hku"



The GUID is different from above since I had to recapture since I couldn't get the package to import when I caputered it from the 7.5 client.

EdT's picture

For completeness, which version(s) of Java are you trying to block?  The more recent versions of the 1.6 release have stopped installing a bunch of regkeys in HKCU at install time to make IE start up faster but they can get installed at a later point, or if the protected mode is toggled.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

jason.f's picture

I have 1.6.0_37 installed in the base and I was going to use 1.6.0_3 just for testing but I hadn't gotten that far. I wanted to make sure I could hide the base Java from Firefox and then move on to getting it to work with my layered version, whichever version that would be. We have an building automation system that doesn't work in IE9 but works fine in Firefox and a user was compalining they need Java 1.7 latest installed to make it work, even though I can clearly see in the code it's looking for Java 1.4 (it's probably something the vendor told them, they also said the server needed 1TB of ram lol)

Proc mon was showing that Firefox was looking at HKLM\Software\MozillaPlugins and also c:\program files\Java\jre6. I'm able to isolate it so Firefox doesn't see base on 6.1 SP8 client running on WinXP but not on 7.5 on Win7.

delvalled's picture

Hi Jason,

I verified this works on SWV 6.1 SP8 MP2 (build 6.4.1895) and also SWV 7.5 (build 7.5.522). Here are the steps I followed:

  1. Setup a virtual machine running Windows 7 Enterprise SP1 (x86).
  2. Install JRE 1.6.0_43 to the base.
  3. Create a new layer and capture Firefox 19.0.
  4. Deactivate the layer.
  5. Add the IsolationRules (see below)
  6. Activate the layer.
  7. Launch Firefox and browse to
  8. Virtualized Firefox is prevented from reading the base JRE.

Here is the set of isolation rules that I used to block JRE 6; please try these and let us know if they work for you.

*.exe YOUR_LAYER_GUID_GOES_HERE 0x0002 \REGISTRY\*\SOFTWARE\Classes\CLSID\{8AD9C840-044E-11D1-B3E9-00805F499D93}* * BASE
*.exe YOUR_LAYER_GUID_GOES_HERE 0x0002 \REGISTRY\*\SOFTWARE\Classes\CLSID\{DBC80044-A445-435b-BC74-9C25C1C588A9}* * BASE
*.exe YOUR_LAYER_GUID_GOES_HERE 0x0002 \REGISTRY\*\SOFTWARE\Classes\CLSID\{E19F9331-3110-11D4-991C-005004D3B3DB}* * BASE
*.exe YOUR_LAYER_GUID_GOES_HERE 0x0002 \REGISTRY\*\SOFTWARE\Classes\CLSID\{4299124F-F2C3-41b4-9C73-9236B2AD0E8F}* * BASE
*.exe YOUR_LAYER_GUID_GOES_HERE 0x0002 \REGISTRY\*\SOFTWARE\Classes\CLSID\{5852F5ED-8BF4-11D4-A245-0080C6F74284}* * BASE
Note: formatting is important. Each of the values in the isolation rules must be seperated by a <tab> not a <space>. I use 'find and replace' to quickly fix up the formatting.
jason.f's picture

Ok I tried that and it didn't work, I tried adding to the RO layer and to the base. Firefox still sees Java installed in the base. I did have to turn of extensions.blocklist.enabled=False in order for the plugin to activate but before I did that it was listed in extensions as disabled. I'm adding the IsolationRules key to "HKLM\System\CurrentControlSet\Services\FSLX\Parameters\FSL\1" which is what "SVSCmd.exe enum -v" shows as my read only redirect location. I did see in the post about virtualizing java with SWV that he was using this location "HKLM\SYSTEM\Altiris\FSL\%magicnumber%"

The only difference between our setups is I'm running Windows 7 Enterprise 64-bit.



delvalled's picture

Hi Jason,

It looks like you created the isolation rules inside the layer itself. However, these rules should be created in the base registry, not in the layer. Please delete this from the RO layer's HKLM hive, create this registry value directly in the base, then try again. Also, the Firefox layer can easily become "polluted", so please reset the layer between each test. 


jason.f's picture

Same. I deactivated the layer, removed the reg keys from the layer, added IsolationRules to the same location but in the base, reset Firefox layer and then activated. Firefox is still showing Java 1.6.0_37 and once I disabled extension blocking shows Java 1.6.0_37.

delvalled's picture

Hi Jason,

After getting this working on a 32-bit platform, I started investigating this process on a 64-bit platform. Using process monitor, it shows Firefox is reading in the values from the HKLM\Software\Wow6432Node registry key. Here is an article from the MSDN in case anyone is interested in learning more about the Wow6432Node.

I created additional rules to compensate for this new activity, but it appears we aren't correctly enforcing the rules against this area of the registry. I have filed a bug report and we will work towards resolving this issue in the next update cycle.



jason.f's picture

Any idea on when the next update cycle is going to be? We're currently evaluating application virtualization/streaming products (SWV/SWS, VMWare Thinapp, App-v) and I definitely prefer SWV from what I've seen of the others, isolation rules being one of them. We need to make a decision by the end of next month on which product we're going to use and I'd hate for SWV to get dinged because of a bug.

jason.f's picture

Ok thanks. I think I ended up trying about every combination of settings and I never got it to work, I was kind of hoping it would be a bug and not me just doing something wrong. I added another rule to try and isolate keys that aren't in WOW6432Node and it seems to experience the same issue.

*.exe    edcb0ff0-bbe8-4ea9-a013-e37840e54b20    0x0002    \REGISTRY\*\SOFTWARE\MozillaPlugins\*    *    BASE

SVSCmd.exe "Firefox 19.02" exec -p "c:\windows\system32\reg.exe query "HKLM\Software\mozillaplugins"


delvalled's picture

Hey Jason,

Good find! You are very thorough; thanks for keeping us on our toes! I also noticed this same thing yesterday during testing. At first, I thought this was a problem with granular isolation, however, the more I look into this, it appears it could be an issue with EXECFROMLAYER and the priorities we assign to processes that are created using this method. I have opened a seperate bug report to investigate this issue as well.

Coming back to the original problem, we can however, use the Firefox example to verify that granular isolation is working for a process that originates in the layer. This test should be performed on a 32-bit platform. Let's start by removing the isolation rule for the MozillaPlugins registry key.


*.exe layer_GUID_goes_here 0x0002 \REGISTRY\*\SOFTWARE\MozillaPlugins\* * BASE

Now when I launch Firefox, we can see that Firefox performs RegOpenKey against the HKLM\Software\MozillaPlugins key and enumerates everything in this path, specifically the Java keys we don't want it to find.

Firefox find the java plugin_0.png

Next, deaactivate the layer, put the rule back in, then launch Firefox again. This time we can see that Firefox cannot find the java keys when it scans the MozillaPlugins registry key. Success!

Firefox doesn't find the java plugin.png



jason.f's picture

Thanks. We won't be implementing any 32-bit Windows 7 except in rare vendor required situations. I'll have to keep an eye out on the beta site to see if they release a fix there. I guess I shoulda caught this in the beta but timing was wrong for my testing.

Thanks for all your help! I learned a lot more about isolation rules. Reading the few posts on here that talk about them often have conflicting information on whether the rule should go in the base or in the layer.


HighTower's picture

Hey Danny,

I talked to Jordan at the 7.5 Summit last week and he asked that I ping you for a status on Jason's issue.


delvalled's picture

Hey guys!

It turns out that the rules we tried above didn't isolate areas of the registry that were redirected into the WoW6432Node area. We've simplified the paths using the * wildcard to widen the search scope to include the redirected registry keys. We were able to block Firefox from finding Java installed to the base of a Windows 7 64-bit system using the following isolation rules:

*.exe YOUR_LAYER_GUID 0x0002 \REGISTRY\*\CLSID\{761497BB-D6F0-462C-B6EB-D4DAF1D92D43}* * BASE
*.exe YOUR_LAYER_GUID 0x0002 \REGISTRY\*\CLSID\{8AD9C840-044E-11D1-B3E9-00805F499D93}* * BASE
*.exe YOUR_LAYER_GUID 0x0002 \REGISTRY\*\CLSID\{DBC80044-A445-435b-BC74-9C25C1C588A9}* * BASE
*.exe YOUR_LAYER_GUID 0x0002 \REGISTRY\*\CLSID\{E19F9331-3110-11D4-991C-005004D3B3DB}* * BASE
*.exe YOUR_LAYER_GUID 0x0002 \REGISTRY\*\CLSID\{4299124F-F2C3-41b4-9C73-9236B2AD0E8F}* * BASE
*.exe YOUR_LAYER_GUID 0x0002 \REGISTRY\*\CLSID\{5852F5ED-8BF4-11D4-A245-0080C6F74284}* * BASE
*.exe YOUR_LAYER_GUID 0x0002 \REGISTRY\*\Classes\JavaPlugin* * BASE
*.exe YOUR_LAYER_GUID 0x0002 \REGISTRY\*\JavaSoft\* * BASE
*.exe YOUR_LAYER_GUID 0x0002 \REGISTRY\*\MozillaPlugins\* * BASE
Give these rules a shot and share you results!
jason.f's picture

Great thanks! I'll try testing this later this week on the Office 2010 package I'm working on. If you tested successfully I'll mark your post as the solution.