In Windows Platforms whether it be Windows XP, Windows Vista or Windows 7, Registry is a central repository, where OS, Application stores anything and everything inside registry. It’s is a shared component between kernel and user space. And this is the reason Registry plays one important Role in Application Streaming.
As I Mentioned in my earlier post, I will write about Registry Rules; here we go.
Inside Isolation, Any Application Virtualization Technology that has layers, Rules plays a very important Role, whether it would be Registry, File System, and Named Objects. Anything and Everything adheres to rules. You can think Rule Engine as the Brain of App Streaming, and obviously it doesn’t have a heart. But in this post I will limit the scope to Registry and Registry Rules for now.
Before I proceed, I would give introduction to internal of Registry from App Streaming Perspective.
As you are aware of 5 registry hives
HKEY_LOCAL_MACHINE hive stores information specific to Machine.
Microsoft Office when Installed on Local Machine, all the Application Settings and Application Information required to run Application such as the Application dll, Com Components goes to HKEY_LOCAL_MACHINE. But there are some legacy applications which are not aware of multi user, they still write user specific information also to HKEY_LOCAL_MACHINE, which is a exception case. But it is not recommended to write User Information and User Settings in HKEY_LOCAL_MACHINE, in Windows 7 onwards, A Non Admin User will not have Write Access to HKEY_LOCAL_MACHINE by default, so these legacy application fails to run in windows 7, if they are trying to write into HKEY_LOCAL_MACHINE.
HKEY_CURRENT_USER Hives is provided to stores information to Specific Users. i.e, all the user specific Information / Settings required for application should be stored here.
The Most Recently Used Files (MRU List) Ideally should be stored in HKEY_CURRENT_USER.
Ok, I think I should stop it here, I am getting diverted from the main topic I wanted to explain here, but I will talk one liner about other hives, and more details can always be googled or found in MSDN.
HKEY_CLASSES_ROOT is a combined view of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes.
HKEY_USER hive stores information about all the HKEY_CURRENT_USERS in particular Machine.
HKEY_CURRENT_CONFIG is nothing but view of HKEY_LOCAL_MACHINE\System, which stores the current Machine Configuration.
I will get into details now.
A Picture is worth more than 100 words, The above one shows the Architecture of Isolation System, and Where the Rules Comes into Picture.
Stick with me for the concept for now, I have three Application running APP1,APP2 and APP3, which are running inside sandbox, Now Sandbox acts as a Funnel, all the Access to Registry/File System/ Named Object has to pass through Sandbox, and Sandbox does the job of funneling requests to Rule Engine, And Rule Engine before processing the Funneled Request, It Consults the Rules. Now If there is any Rule Found for the Request, It applies the Corresponding Rule, otherwise it applies the Default Rule.
Now, that being explained about the internal architecture, Let me start about Rules
There are four kind of Rules
ISOLATE PER USER RULE
STRICT ISOLATE RULE
ISOLATE PER USER
This Rule is the Default Rule. i.e., if there is no rule present then this rule is applied for all the Registry Access.
Even during Profiling this is the default Rule,
When the Key is created, by default whether it’s ISOLATE PER USER RULE or STRICT ISOLATE RULE, the key goes to Per User Cache.
The Behavior of these two rules differs when the registry resource is accessed by the application.
In ISOLATE PER USER RULE, if the registry resource is found in Top Layer say User Root, it Returns the Resource from the Top Layer.
If registry resource is not found, it continues to search for the next layer, i.e., Install Root for the resource, and if still the resource is not found then the Rule Engine search for the data inside Physical Machine and returns the registry resource to application.
One Important Point to Note with Isolate Per User Rule is , When This Rule is applied to Any Resource, the Isolation System guarantees that a Copy of Resource is created Per User.
All the Registry Keys that starts with . & * in Path HKLM\Software\Classes\ refers to File Type Associations (FTA). whenever user double clicks on a file in Desktop, the operating system refers to these registered Application with extensions to find the appropriate Application.
There can be Multiple Application that can be registered for the same file extension.
For Example, Mozilla FireFox, Google Chrome, Microsoft Internet Explorer all registers .html as their extensions.
But user can always choose their default Application that would get launched when purticular File with extension is double Clicked.
When IsolatePerUser Rule is applied on HKLM\Software\Classes\.html, A Copy of HKLM\Software\Classes\.html is created for Every user, so different user can choose to have different Extension as their default based on the application they are using. (Firefox, Chrome, IE …)
STRICT ISOLATE RULE
When Strict Isolate Rule is applied, and Rule engine searches for the Registry Resource only in Top Most Layer, and If the Data is not found in Top Most Layer, and the It enquires for the Data in the Below layers expect Physical Layer. If data is present in Any of the layer expect physical layer, Isolation system is happy, and returns the Corrosponding Data. Suppose if Registry Resource is not present in any of Isolation Layers but present in Physical Layer, the Rule Engine is not happy this time, It just Returns saying Data is not Found.
When This Rule is applied, the Rule Engine Redirect all the Creation and Reading the Resource to Physical Machine.
This Rule Type is also called as Redirect Rule, with this Rule, whenever the Request comes for this Particular for registry resource; it always redirects the resource to New Path specified in REMAP RULE Definition.
More Information about the Rules can be found Here.
Rules are Created During Profiling, and the Rules are always stored in a file called Sandboxdata.xml, under <Profile_Path>\<Profile_Directory>\<GUID>\Sandboxdata.xml, this contains Most of Rules that will be applied to sandbox, or the Profile, But there are other places where the Rules are being taken from, I will talk about this in my next post.
On the Machine where the application are streamed, when the Application is launched, before the application starts running, a Sandbox is Created, and During Sandbox Creation, we Read all the Rules from Sandboxdata.xml and Give it to Rule Engine.
As a consequence, If the Rule is modified when the Sandbox is Running the Rule will not get into effect, and it gets effect only when the Sandbox is created next time. Please keep in mind about Sandbox Reuse Feature.
That’s it for today’s post, I will talk about how to play around with rules, and what are the rules that need to be fallowed while playing with rules in my next blog.