Configuration Data in VirtualStore
Sometimes, programs don't know that they are not allowed to store data in the protected Windows
locations. When a standard user runs the application and tries to change configuration data, the
application's configurations are not written to these protected Windows locations. They are
redirected or virtualized instead. In Figure 91, we can see that when the application tried to write
its data to c:\Program Files, it was actually redirected to
%LocalAppData%\VirtualStore\Program Files (x86)\Foxit Software\Foxit Reader.
Figure 91. Application data that has been redirected.
This is a safety mechanism that Windows uses to allow applications to think that they've written
data to the desired location (\Program Files), when in actuality, the application's data was
really written to
%appdata%\local\virtualstore\Program Files (x86)\Foxit Software\Foxit Reader. However, there is
one problem with this: both 32-bit and 64-bit client machines could possibly be our targets. Because
of this, even though we're finding the file in
%LocalAppData%\VirtualStore\Program Files (x86)\Foxit Software\Foxit Reader (as shown in Figure
92), the data file could also be found on 32-bit machines in
%LocalAppData%\VirtualStore\Program Files\Foxit Software\Foxit Reader (as shown in Figure 93).
Figure 92. The location for 64-bit machines is %LocalAppData%\VirtualStore\Program Files (x86).
Figure 93. The location for 32-bit machiens is %LocalAppData%\VirtualStore\Program Files.
If you select a file within the VirtualStore directory, Endpoint Policy Manager DesignStudio recognizes this and provides two features to ensure proper delivery to clients. First, as shown in Figure 94, Endpoint Policy Manager DesignStudio will substitute the correct variable so it will work on client machines of the same type.
Figure 94. Endpoint Policy Manager DesignStudio substituting the correct variable.
To account for the possibility that you might have both 32-bit and 64-bit machines as targets,
Endpoint Policy Manager Application Settings Manager, by default, will always try to write to both
locations on the target machine. That way, you're ensured that both 32-bit and 64-bit machines will
get your directives. Note that this behavior is controllable within Endpoint Policy Manager
DesignStudio in Tools|Options in the VirtualStore tab, as shown in Figure 95. It is recommended
that you keep this checkbox checked.
Figure 95. The VirtualStore tab.
If you want to see both actions, you can click on the element's "Advanced" button, as shown in Figure 96, and see the two actions created.
Figure 96. The element's "Advanced" button.
If you were to hover the mouse over each "File" location, you would see that the actions are set
against each possible file location automatically (\Program Files(x86) and \Program Files), one
for the first action and another for the second action, as shown in Figure 97 and Figure 98.
Figure 97. The file location for the first action.
Figure 98. The file location for the second action.
Therefore, there's really no downside in leaving the "Always create additional action when target files utilize Windows 7 "VirtualStore" directories (recommended)" turned on. It will mean that your 64-bit and 32-bit applications will read the right file and be correctly configured.
For more information on the idea of how an application uses file virtualization, see the following resources:
- Video and example app for testing: http://www.msigeek.com/328/video-file-registry-virtualization-in-windows-7
- http://msdn.microsoft.com/en-us/library/bb756960.aspx. Look for "Virtualization" about halfway down the page.
- http://www.thewindowsclub.com/file-registry-virtualization-in-windows-7.
- Group Policy: Fundamentals, Security and the Managed Desktop by Jeremy Moskowitz Page 561–562. Available at www.GPanswers.com/book.