7. • Cannot cache streamed data in a pooled XD environment
• Main reason why first launch is slow
• Workaround?
• Pre-populate the RadeCache in the base image.
Citrix Confidential - Do Not Distribute
The RadeCache issue
8. • Requires the Offline plug-in 6.5 and Profiler 6.5
VHD Streaming
Citrix Confidential - Do Not Distribute
9. • Designed to only be enabled with pooled desktop
• VHD gets mounted in C:Program FilesCitrixRadeCache
VHD Streaming
Citrix Confidential - Do Not Distribute
10. • Automatic detection in XenDesktop pooled environment
• Check if the c:personality.ini contains a DiskMode=Shared entry
• Check that XenApp is not installed
• If both of the above are true, UseVHD=1 is automatically set in the registry.
VHD Streaming
Citrix Confidential - Do Not Distribute
11. • Enabled via a registry key:
HKLMCitrixSoftwareRadeUseVHD
VHD Streaming
Citrix Confidential - Do Not Distribute
13. • Pre-launch of the sandbox
• Requires Offline plug-in 6.5
• Disabled by default
• HKLMSoftwareCitrixRadeDisableFastLaunch to value 0 (DWORD).
RadeFastLaunch
Citrix Confidential - Do Not Distribute
14. • Transparent for users
• Can be deployed via policies:
HKCUSoftwareMicrosoftWindowsCurrentVersionRun
“C:Program FilesCitrixStreaming
ClientRadeFastLaunch.exe”
“shareOfficepackageOfficepackage.profile”
RadeFastLaunch
Citrix Confidential - Do Not Distribute
16. • Requires Streaming Profiler 6.5 and Offline plug-in 6.5
• To comply with FIPS (Federal Information Processing
Standards)
• SHA2 signed profiles not compatible with earlier version of
Offline plug-in!
SHA2 signing
Citrix Confidential - Do Not Distribute
17. • You can still enable offline plug-in 6.0 compatibility = SHA1
signing.
This considerably increases the build time for the profile.
SHA2 signing
Citrix Confidential - Do Not Distribute
20. Installation/Execution Image
Streaming Profiler and Client
Physical Machine
Installation/Execution Image
Profiler Machine
• Nothing gets written to the “table” at
profile time when the application is
installed
Client Machine/ XenApp Server
• The installation program is “painted” on
this “pane of glass”
• File redirection
Per User Image
Physical Machine
Read/Write
Read Only
Read Only
Read/Write
• Execution image common to all users – enables centralized app
management
The application believes it was
installed on the physical
machine
Install program, registry, named objects
etc. stored as a profile
21. Sandbox 3
Sandbox 2
Sandbox 1
Sandboxes and multiple execution
Installation/Execution Image #1
Physical Machine
Per User Image #2
Read/Write
Read Only
Per User Image #1 Per User Image #3
Application Application Application
• Three sandboxes
• Three users
• One install image
• Centralized application management
• 1st time launch ‘penalty’ applies only to the first user; DACL regulates
user access
28. • HKLMSoftwareCitrixRade
• SandboxStatusMonitorPeriod DWORD – timeout value in minutes to keep
radelauncher.exe active in the user session (Sandbox reuse feature).
Some registry keys…
Citrix Confidential - Do Not Distribute
29. • HKLMSoftwareCitrixRade
• RadeRunSwitches REG_SZ – automatically passes parameters to raderun.exe
for all streamed applications launched on the client machine.
Some registry keys…
Citrix Confidential - Do Not Distribute
Options:
-c pre-flush the cache [Administrators only]
-C pre-flush the cache, including user data [Administrators only]
-d post-flush the cache [Administrators only]
-D post-flush the cache, including user data [Administrators only]
-e pre-extract all files
-o deploy the app for offline use
-x run isolated command prompt
30. • HKLMSoftwareCitrixRade
• AppHubWhiteList REG_SZ – registry key to specify trusted application hubs.
This is used when the packaged application uses a Windows service
Some registry keys…
Citrix Confidential - Do Not Distribute
31. • This helps to understand the flow of execution and to spot
any unexpected process termination.
Using Process Explorer
Citrix Confidential - Do Not Distribute
32. • Helps to understand what the application is trying to achieve
• Can be confusing because of the layers of glass.
Using Process Monitor
Citrix Confidential - Do Not Distribute
34. • Enables you to list mounted VHD on a client machine
• http://blogs.citrix.com/2011/06/21/app-streaming-where-is-
the-vhd/
Using Diskpart
Citrix Confidential - Do Not Distribute
35. • Application specific logs if applicable
• DebugView: some applications use the default debug output
to log failures.
Other tools
Citrix Confidential - Do Not Distribute
36. • CDFControl: usually reserved to experienced users and
Citrix technical support.
Other tools
Citrix Confidential - Do Not Distribute
38. • Citrix blogs
• Joseph Nord’s: http://blogs.citrix.com/author/josephno/
• Case study on streaming Adobe Acrobat 9:
http://blogs.citrix.com/2011/07/22/streaming-adobe-acrobat-9/
• SysInternals tools : http://technet.microsoft.com/en-
ie/sysinternals
Helpful resources
Citrix Confidential - Do Not Distribute
39. Before you leave…
• Session surveys are available online at www.citrixsummit.com
starting Thursday, 27 October
• Provide your feedback and pick up a complimentary gift at the registration desk
• Download presentations starting Monday, 7 November, from your
My Organiser tool located in your My Account
Editor's Notes
In pooled XenDesktop environments, once a user logs off, the entire user written data gets wiped off. This causes problems for streamed applications as during first launch several binaries (and data) get copied to RadeCache folder. This is also one of the reasons why first launch of streamed application is slow. So when user logs on next time and launches the same application again, the launch will again be slow. This is causing serious deployment issues of application streaming on pooled XenDesktops.
The challenge is that anything written to disk at runtime is backed by per-machine backing store on the Provisioning Server or by per-machine write back store on the hypervisor. Either way, while things written to assist a first run will assist second runs during that logon session, at logoff all the cache space disappears. On the next logon, the machine state is again clean and the first launch activity has to start from scratch.
This problem exists even if the administrator pre-populates the RadeCache into the base image. It may work for a period of time, but eventually the application administrator will update the Application Hub and this will cause a first launch scenario on the execution machine. Large quantities of disk writes will occur as RadeCache content is upgraded from one GUID_VERSION to the newer version of that same content.
Multiply this times thousands of virtual desktops and the network and disk impacts are large. The solution is to minimize the number of disk writes. The RadeCache GUID_V space should be MOUNTED from a single store to support all virtual machines and that mount is a READ operation which will keep the per-machine temporary write store to a minimum size.
- New feature of Offline plug-in 6.5
Need to edit 6.0 packages with Profiler 6.5 and choose the option to create a VHD (demo?)
Designed to only be used in pooled desktop to avoid filling radecache with file copy operations.
Compare with PVS / flexibility / background for the features.
TODO: quick video showing the registry setting, the launch of a streamed application and the vhd mapping under c:\program files\citrix\radecache
Recording as plan B: VHD_Streaming.mp4
One of the most expensive operation with Citrix application streaming is the setup of the sandbox at start-up of the application.
New feature in offline plug-in 6.5 which pre-creates the sandbox for the end-user, reducing launch time when the user eventually launches his streamed application
Disabled by default
Two registry keys to set
You can setup as many auto-launch packages as you want via the Run registry key (need to verify?).
Dies after two hours if the sandbox is not used.
Invisible to users
TODO: quick video showing the registry settings, how to launch radefastlaunch and show Process Explorer with the sandbox.
RadeFastLaunch.exe is present in the sandbox and will close as soon as the first application is launched inside this sandbox.
Show the different processes inside the user session.
Recording as plan B: radefastlaunch.mp4
New feature of Offline plug-in 6.5
Federal Information Processing Standards (US mainly)
Offline plug-in 6.0 and earlier only supports SHA1!
Vision in your mind … a standard company office with a normal desk in it.
On top of the desk is a clear pane of glass.
Profiling machine (on the left in the diagram)
During profiling, the installer runs – above the desk, looking down and the desk represents the physical machine or the true file system or registry.
The installer sees only the desk (the glass is clear).
Installer “writes” to the desk (files and registry), but instead of writing on the true physical machine, it’s actions are redirected to “paint” onto the pane of glass.
The installer sees from above and sees a masked view, so it “believes” that it wrote to the desk.
The glass intercepts all file system and registry activity.
Execution system (another desk).
The physical desks on the profiling and execution machines are similar and are assumed to be “sufficiently similar” that the differences in their content will not interfere with application execution.
There are ways to correct discrepancies when the contents are different and understanding the panes of glass is the key to diagnosing the error where items go wrong. See RadeRunSwitches.
The “execution image” is the pane of glass from the profiling machine.
The application runs – looking down at its desk from above – the pane of glass representing the execution image has stuff painted on it (file system and registry) – so the application sees a modified vision of the physical machine.
Technically the pane of glass isn’t there. Items accessed are runtime populated (STREAMED). From the view of the application, everything that was present during profiling is also present during execution. For example, if the app does a directory (DIR) to inquire if its files are present, the isolation system will step in and LIE to tell it everything is installed when really nothing is installed.
When the application accesses a file from the execution image that is not present, the application execution is suspended, the item is populated onto the execution image and then the application is resumed.
On the execution system, there are 2 panes of glass.
The additional pane holds the user specific content. This is a second pane of glass that is laid down on top of the first pane.
At runtime, the execution image is read-only. The per-user image is read-write.
All of the above applies to “isolation”.
The isolation environment in App Streaming also supports
“redirect” Access to C:\Foo becomes C:\bar
“ignore” Bypasses both panes of glass and sees straight through to the true disk/reg
“strictly isolate” The true disk/registry “vanishes” for the given space (disk/reg).
Execution cache size
The default cache limit is 1 GB or 5% of client machine disk space, which ever is larger. This is be adjusted by the administrator using ClientCache.exe utility or by directly editing registry items. The keys of interest are below HKLM/Software/Citrix/Rade.
The cache algorithm is a high water mark. Until the cache limit is hit, NO files will be erased from the cache. Eventually, a cache fill operation will cause the cache limit to be surpassed. This triggers the start of cache deletion. Note: In no case does the attempt to cache fill get delayed. The cache will grow above the cache limit – though it for a short period of time.
In the background, the cache manager will trim files from the cache until it reaches 95% of the cache limit, this is the low water mark on the cache. At this point, cache deletion background activity goes to sleep until the next time the cache hits the high water mark. The administrator can also override the aggressiveness of the cache deletion by adding a registry key, CacheLowWaterPct, and setting this to the numeric percent where the deletion should stop. This is generally not necessary, but it is added here for reference.
Isolation system shares the execution image across multiple instances of the same execution image.
Example: 3 users running on a Presentation Server, each running the same application.
3 Sandboxes are created.
Each user sees the same physical machine and the same image of the profiled application.
Each user sees their own PRIVATE version of the top layer of glass.
The top layer is writable, the other layers are read-only.
Access to the application execution image is dynamically DACL adjusted so that only users who are actually RUNNING the application can see the execution image for the application.
The key: An item cache-filled for user 1 will benefit user 2 and this reduces impact of first time launches needing to fill items into the cache.
Execution image is stored in this location (example is disk, also applies to registry).
GUID is the “key” to cache management. It uniquely identifies each execution “Target”.
Execution caches are versioned (GUID_version) to allow Targets/profiles to be updated “live”.
Users do not have to terminate their applications to allow the central storage to be updated.
They get the “most current” execution image each time they launch.
RADE = Rapid Application Deployment. This was Application Streaming’s original codename.
Notice that this looks very similar to the isolation of files
0 - Raderun.exe is the initiator. All the parameters (package location, application to launch) are passed to raderun.exe.
1 - Raderun.exe talks to RadeSvc.exe to check if a sandbox already exists for this package.
2 - If the sandbox does not exists, raderun.exe spawns a radelauncher.exe process.
3 - RadeLauncher.exe then talks to RadeSvc.exe to get the Application Isolation Environment details.
4 - Radelauncher.exe applies the AIE details to itself
5 - Finally, RadeLauncher.exe creates the isolated streamed process inside the sandbox.
In the case of sandbox reuse, in step 2 we just reuse the existing radelauncher.exe process.
Review!!!
Overview of the architecture:
Kernel:
Ctxsbx.sys: kernel filesystem filter driver which provides the filesystem redirection (to c:\Program Files\citrix\radecache)
Ctxpidmn.sys : kernel driver that monitors all processes created and terminated on the system and notify ctxsbx.sys if a process is streamed.
User:
Ctxsbxhook.dll: user mode DLL injected in all processes which provides the registry redirection and the named objects
Radesvc.exe: privileged service that provides the isolation environment settings and fulfill the cache requests from ctxsbx.sys.
Radelauncher.exe: seats in the isolated application box on the schema. It is the one that spawns the isolated applications processes and runs inside the sandbox.
When the app is streamed, the AIE launcher (pkgr.exe / RADEsvc.exe) launches the AIE that was profiled with the app. The file system driver (ctxsbx.sys) redirects the file location from \program files\app to program files\citrix\radecache\GUID\Device\c\app and ctxsbxhook.dll redirects registry and named objects to the AIE location.
RadeSvc.exe is responsible for caching files on request coming from ctxsbx.sys.
The Debug console is usually helpful when facing issues that happen very early during sandbox creation i.e. radelauncher.exe is not launched.
This registry key determines if radelauncher.exe will stay opened and for how long. While troubleshooting issues, you may need to run the streamed applications multiple times in a row and disable the Sandbox reuse feature.
The parameters you can pass in this registry keys are the exact same as the ones you can pass to raderun.exe from a command prompt.
It can be useful to pre-extract or pre-deploy all files from your packages on client machines.
Examples
- “-e” can be used to check if pre-caching can reduce the very first launch time of the streamed application.
“-x” used to see the sandbox from inside, like the streamed application.
Demo with –x flag (video recorded as plan B)
Can be mandatory for certain applications!
raderun.exe is launching radelauncher.exe. Radelauncher.exe is launching the streamed app.
Dll injection : ctxsbxhook.dll, radeaphook.dll – how to check the version loaded.
Sandbox reuse (radelauncher.exe is maintaining the sandbox alive)
If you see radelauncher.exe running, there’s a very good chance that the offline plug-in did its job just fine!
Demo with debug console enable ( to prevent raderun.exe from exiting) to show the different processes. (link with previous diagrams)
Video recording called Process Explorer as plan B
- Look at a trace and show the different layers of glass (filesystem and registry)
Without VHD, we go through the normal layers of glass: user root > install root > local machine (last step not on screenshot)
With VHD, we can see the same plus an extra step where a reparse (=redirection) happens and redirects to the mapped VHD. In this case HarddiskVolume4.
- Demonstrate what Joe Nord explained in the following blog entry: http://blogs.citrix.com/2011/06/21/app-streaming-where-is-the-vhd/
CDFMonitor: This provides information on the internal mechanics of Citrix Application Streaming.
Review!!!
TODO: Put a simple extract of the CDF trace and explain meanings of each lines.
2 first lines: entering a function to open the package we’re streaming.
Following lines: Opening the .profile file which is an XML file.
End lines: this is the start of the .profile file parsing with the first parameter being checked. We can see that we check for the prelaunch analysis which is a setting you configure in the profiler.
