Cloudpaging technology provisions applications to desktops using a virtual container. Each application that is Cloudpaged is backed by a writable sandbox that maintains all the settings and changes made by that application to the file system and registry. This sandbox is intended to contain all the settings for the virtual application that has changed under the user profile and can be configured at packaging time. The sandbox can then be roamed using redirection or common profile management tools.
How It Works
The act of sandboxing means to separate changes made to the file system or registry from the real system. Each application container has two parts; a cache of execution pages and a writable sandbox that maintains all the settings and changes made by that application to the file system and registry. Writes by the Cloudpaged application, and by any child processes of the application, are captured into its own sandbox. The child processes can be installed executables on the target machine, but if they are launched by the Cloudpaged application then they will be captured into the virtual application’s sandboxes. The scope of what is sandboxed can be defined when packaging the application and will include the following I/O operations:
- New files created by the virtualized application
- Updates on existing files that belong in the appset
Cloudpaging performs partial‐sandboxing for files contained within the package, which means that only content modified or added to existing folders or sub‐folders are sandboxed. For example, if a package contains only the installation root folder and “Program Files”, then if the virtual application creates a new file under the “Windows” folder, then this new file will be directly written to the system. Cloudpaging Studio will sandbox all default registry hives (i.e. HKCR, HKCU, HKLM, HKU), but any other hive must be part of the appset to be sandboxed.
Exclusions can also be specified to allow specific folders to not write to the sandbox, which is useful for separating applications settings and user settings from user documents, such as Word files. Common user folders, such as desktop, documents, music, pictures, and videos, are excluded from sandboxing by default. Excluding these paths allow the data within the paths to be written directly to the filesystem and will not remain in the sandbox. Furthermore, these exclusions ensure compatibility with Folder Redirection, Profile Disks, and other User Environment Management tools when dealing with user data and is outside the scope of Cloudpaging.
How To Package
During packaging the advanced configuration allows the sandboxing rules to be configured for each application container.
All sandbox content for a virtual application is deleted when the application is removed. To preserve the application settings (e.g. changes to a toolbar and other UI customizations) after removing an application or to allow roaming, use the following options:
- Preserve application settings when application is removed - Ensures that the virtual application sandbox data stays within on the system in a secure location when the application is removed. When the same application is Cloudpaged again the settings will persist.
- Allow Windows to roam application settings - Instructs the Player to write to the virtual application sandbox for %APPDATA% (e.g. \AppData\Roaming\) to the common APPDATA location under a Cloudpaging folder. The APPDATA folder can then be roamed using standard roaming or redirection tools.
To enable roaming of the application settings:
1. In Studio, click on Settings > Sandboxing
4. Checkbox both settings under Application Settings
3. Click OK to save the changes.
To control what is saved in the sandbox:
The packaging process can specify how much to be captured into the sandbox by including additional folders into the package.
- If all possible Windows root folders (https://msdn.microsoft.com/en-us/library/windows/desktop/dd378457(v=vs.85).aspx) are present in the AIB (even if some of them are empty), all changes by the virtualized application will be captured into the sandbox.
- If only some of the possible Windows root folders are present in the AIB, writes that happen under root folders not present in the AIB are written through to the system and not captured into the sandbox.
To add a registry path exclusion for sandboxing:
1. In Studio, click Settings > Sandboxing > Sandbox Registry Key Exclusions.
2. Add the following registry key path: HKEY_CURRENT_USER\Software
To add a folder exclusion for sandboxing:
1. In Studio, click on Settings > Sandboxing > Sandbox Folder Exclusions.
2. Add the following Folder Template: ?roamingappdata? (to the already existing exclusions)
To support roaming using folder redirection:
With Folder Redirection to a network share (via Mapped drive or a UNC path), only Layer‐1 (recommended) and/or Layer‐2 files are allowed. If any Layer‐3 or Layer‐4 files are located in these folders, then the appset will fail to activate. For example, if the %appdata% folder is being redirected to \\fileshare\user1\appdata\, then the appset template folder ?roamingappdata? must only contain Layer‐1 files and folders. Redirection to another local disk supports virtual files (Layer‐3 or Layer‐4).
For information on how to configure roaming techniques to work with Cloudpaging Player, please see How To Roam article. Advanced UEM support information can be found in the Cloudpaging Player Deployment Guide for Server Admins.
ARTICLE APPLIES TO VERSION 8.6 AND ABOVE