Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Summit301 hdx media stream for flash configuration and troubleshooting
1. HDX MediaStream Flash Redirection
Configuration and Troubleshooting
Download this slide
http://ouo.io/wsGH8
2. • What is HDX MediaStream Flash Redirection?
• Technical Deep Dive
• Configuring HDX MediaStream Flash Redirection
• Troubleshooting HDX MediaStream Flash Redirection
• Additional Information / QA
Agenda
Citrix Confidential - Do Not Distribute
3. What is HDX?
Repeaters Gateways ControllersReceivers
Citrix Confidential - Do Not Distribute
Adaptive
Orchestration
4. HDX™ MediaStream Flash Redirection (HDX Flash)
• How it works
• Known limitations
• Why it’s important
Citrix Confidential - Do Not Distribute
5. What does HDX Flash Redirection do?
• Dynamically redirects
ActiveX Flash
• Switches between server
and client rendered
• Centrally configured
Citrix Confidential - Do Not Distribute
6. Data
Center
Client-side Rendered - Flash Redirection
Citrix Confidential - Do Not Distribute
ICA ServerReceiver
PseudoServerInProc.dll
Redirects ActiveX Calls
PseudoContainer.exe
Hosts ActiveX Container
HTML
CTXFlash
Virtual Channel
Flash Content
ICA Session
7. Data
Center
Server-side Rendered Flash (HDX Broadcast)
Citrix Confidential - Do Not Distribute
ControllerReceiver
HTML
Flash Content
ICA Session
Thinwire
8. • Windows/Internet Explorer
• Adobe ActiveX Flash Player
• ICA Session Latency (<30-
50ms),
• Requires up to 500kbps
available session bandwidth
• Online Plugin 11.2+
Citrix Confidential - Do Not Distribute
Known Limitations
9. • Uncompressed audio & video playback (High-Def)
• Utilizes client GPU/CPU for decoding
• Offloads server resource overhead
• Reduction in network bandwidth requirements
• Increased server scalability
Why use HDX MediaStream Flash Redirection?
Citrix Confidential - Do Not Distribute
10. • What is HDX MediaStream Flash Redirection?
• Technical Deep Dive
• Configuring HDX MediaStream Flash Redirection
• Troubleshooting HDX MediaStream Flash Redirection
• Additional Information / QA
Agenda
Citrix Confidential - Do Not Distribute
11. Citrix Confidential - Do Not Distribute
HDX MediaStream for Flash – Key Components
• ActiveX Redirection
• Content Fetching
• Adaptive Orchestration
Main Components
12. ActiveX – A Brief History
• Based on COM
• ActiveX Controls
• Originally called OLE
Control (.OCX)
Citrix Confidential - Do Not Distribute
13. ActiveX Redirection
ActiveX Control ActiveX Container
• Server side of HDX Flash
• ‘Pseudo’ Server
• Hooks into Internet Explorer
• Redirects ActiveX Flash Player
• Decides whether or not to
redirect
• Client side of HDX Flash
• ‘Pseudo’ Container
• Supplies an environment in
which an ActiveX control can run
• Manipulates, manages, and
provides services to local
ActiveX Flash Player
Citrix Confidential - Do Not Distribute
15. Effects of Network Latency on ActiveX Redirection
Citrix Confidential - Do Not Distribute
Redirected
ActiveX Calls
ICA
Session
Latency
ActiveX ControlActiveX Container
16. Flash Redirection: Content Fetching
Client Side Server Side
• Client fetches Flash content
• PseudoServer sends the
original URL to
PseudoContainer
• Client needs to be on the
same domain as the server
for secure content
• Server fetches Flash content
• PseudoServer substitutes URL
of content with file:// address
• Allows server to proxy
authentication requests on client
behalf
• Limited access endpoints
Citrix Confidential - Do Not Distribute
17. Text BoxText Box
Content Fetching: Client-Side vs. Server-Side
Client-Side Content Fetching
Client fetches Flash content
directly from the web server.
Fetch
Flash
Content
Directly
PseudoContainer.exe PseudoContainer.exe
ICA Session ICA Session
Fetch Flash
Content From
ICA Server
Fetch Flash
Content
For Client
Server-Side Content Fetching
Client uses ICA Server as a Proxy
PseudoServerInProc.dll
ICA Server
Pseudo Container
ICA
Client
Flash
Player
ICA
Client
Flash
Player
ICA Server
PseudoServerInProc.dll
CTXFlsh CTXFlsh
Pseudo Container
Flash Content
(.swf, .flv)
18. ICA SessionICA Session
Adaptive Orchestration: Dynamic Blacklist
Flash Content
(.swf, .flv)
Client Fetches and
Renders Flash
Content
Internet Explorer page is refreshed,
Server-Side Rendering Occurs
Dynamic Blacklist
Failed URL
Added to
Blacklist
PseudoServerInProc.dll
ICA Server
ICA Client
ICA
Client
Flash
Player
CTXFlash
19. Adaptive Orchestration: Network Latency
• Measures network latency and available bandwidth
• Network Latency Detection
Measures ‘ICA Ping’ round trip time
Measures ‘Latency - Session Average’ ICA Session Counter
Uses lowest value of the two in the decision of where to render
• If latency exceeds the maximum threshold, HDX falls
back to Server-Rendered Flash
20. • What is HDX MediaStream Flash Redirection?
• Technical Deep Dive
• Configuring HDX MediaStream Flash Redirection
• Troubleshooting HDX MediaStream Flash Redirection
• Additional Information / QA
Agenda
Citrix Confidential - Do Not Distribute
22. • Server-Side Settings
• Use the HDX-Flash-Server.ADM template in Group Policy Editor
• Registry:
• SOFTWARECitrixHdxMediaStreamForFlashServerPseudoServer: UseFlashRemoting ; ValueOn =
“Always”, ValueOff = “Never”
Citrix Confidential - Do Not Distribute
Server Configuration
24. • Client-Side Settings
• Use the HDX-Flash-Client.ADM template in Group Policy Editor
• Desktop Viewer:
• Registry:
• SoftwareCitrixHdxMediaStreamForFlashClientPseudoContainer: UseFlashRemoting ; ValueOn =
“Always”, ValueOff = “Never”, Prompt = “Ask”
• Desktop Viewer preferences stored in: HKCUSoftwareCitrixICA
ClientHdxMediaStreamForFlashDesktopViewerDesktop Group Name: UseFlashRemoting ; ValueOn
= “Always”, ValueOff = “Never”, Prompt = “Ask”
Citrix Confidential - Do Not Distribute
Client Configuration
25. Configuring Server Side Content Fetching
• Enable on the client via GPO
• Add URLs on the server whitelist via GPO
• Wildcards are permitted, use * to enable SSCF for all sites
26. • Disable using the following registry setting
•HKLMSOFTWARECitrixHdxMediaStreamForFlashServerPseudo
Server: "DynamicFallbackEnabled"=dword:00000000
•HKLMSOFTWARECitrixHdxMediaStreamForFlashClientPseudo
Container]: "DynamicFallbackEnabled"=dword:00000000
Configuring the Dynamic Blacklist
27. • Simulate by killing PseudoContainer.exe on the client
• Verify URL is added to the dynamic black list
HKEY_CURRENT_USERSoftware
•For IE7 and IE8 in non-protected:
…CitrixHdxMediaStreamForFlashServerPseudoServerDynamicBlacklist
•For IE8 in protected mode:
…MicrosoftInternet ExplorerInternetRegistryREGISTRYUSERSID
CitrixHdxMediaStreamForFlashServerPseudoServerDynamicBlacklist
Simulating the Dynamic Blacklist
29. • Use the HDX Flash Client GPO template
• Enable cookie replication
Citrix Confidential - Do Not Distribute
Configuring Cookie Replication
30. Limitations of Cookie Replication
• HttpOnly attribute not supported
• Synchronization occurs server-to-client only
• Improper handling when client modifies or deletes the
cookie
• Persistent client-side cookies
31. • What is HDX MediaStream Flash Redirection?
• Technical Deep Dive
• Configuring HDX MediaStream Flash Redirection
• Troubleshooting HDX MediaStream Flash Redirection
• Additional Information / QA
Agenda
Citrix Confidential - Do Not Distribute
32. • HDX Experience Monitor
• EventLogs
• Tracing
• HTML Debugging
Citrix Confidential - Do Not Distribute
Troubleshooting HDX Flash Redirection
36. HDX Experience Monitor – Flash Network
Performance
Citrix Confidential - Do Not Distribute
37. Windows EventLog – Server Settings
Citrix Confidential - Do Not Distribute
• Enable Server-Side Logging
• [HKEY_LOCAL_MACHINESOFTWAREPoliciesCitrixHdxmediaStreamForFlash
ServerPseudoServer]
• "EventLogging"=dword:00000001
• Disable event throttling so all events are logged
• [HKEY_LOCAL_MACHINESOFTWARECitrixHdxMediaStreamForFlashServer]
• "EventTimeThrottle"=hex(b):00,00,00,00,00,00,00,00
39. Windows EventLog – Windows 7 Setting
Citrix Confidential - Do Not Distribute
• wevtutil ep |more
• wevtutil im "c:program
filescitrixicaserviceresourceenhdxflash
eventmessagesman.man"
41. Tracing: Server-Side CDF Traces
Citrix Confidential - Do Not Distribute
• MF_DLL_FlashCore
• MF_DLL_FlashTransport
• MF_Service_CtxFlashSvc
42. Tracing: Client-Side File Traces
Citrix Confidential - Do Not Distribute
HKEY_LOCAL_MACHINESOFTWARECitrixHdxMediaStream
ForFlashClientTracing
"File"=dword:00000001
"Level"=dword:00000009
"Flags"=dword:ffffffff
Setting the log level to 9 traces everything and will greatly impact performance.
46. HTML Debugging: IE Developer Tools (F12)
Citrix Confidential - Do Not Distribute
47. Need Assistance from Citrix Technical Support?
Citrix Confidential - Do Not Distribute
• Capture any Pop-Up Messages
• EventLogs (Server and Client)
• Run the HDX Experience Monitor tool within the ICA session
• Collect tracing (CDF and File)
48. • What is HDX MediaStream Flash Redirection?
• Technical Deep Dive
• Configuring HDX MediaStream Flash Redirection
• Troubleshooting HDX MediaStream Flash Redirection
• Additional Information / QA
Agenda
Citrix Confidential - Do Not Distribute
49. HDX MediaStream Flash Redirection “Version 2”
• Support for WAN-connected users
• Protocol abstraction for high latency tolerance for
Flash videos (target 300ms RTL)
• Linux device support (client-side
rendering) requires updated reciever
• URL whitelist option and
improvements in intelligent fallback to
server-side rendering
50. Resources
Citrix Confidential - Do Not Distribute
• CTX124190 - How to Deploy and Configure HDX MediaStream for
Flash
• CTX126702 - HDX MediaStream for Flash – Client-Side Content
Fetching Limitations
• CTX125060 - Best Practices for Optimizing HDX Technologies for
XenDesktop 4
• CTX125324 - HDX MediaStream for Flash Redirection – Network
Latency Performance Issues
• CTX123058 - HDX Experience Monitor for XenDesktop
• CTX126491 - HDX Experience Monitor for XenApp
51. Before you leave…
• Session surveys are available online at www.citrixsummit.com
starting Thursday, May 26
• Provide your feedback and pick up a complimentary gift at the registration desk
• Download presentations starting Friday, June 3, from your My
Organizer Tool located in your My Synergy Microsite event account
Let’s first go over today’s agenda.
The focus of our session is HDX Mediastream Flash Redirection, so first we’ll talk about what Flash Redirection is, how it works, and when and why it should be implemented.
Next, we’ll go into a technical deep dive on HDX Flash Redirection to give everyone a better understand of how this technology actually works
After that we’ll cover the configuration options to get HDX Flash up and running
And last we’ll talk about troubleshooting Flash Redirection. Here we’ll discuss the tools we use, as well as troubleshooting methodology.
In closing we’ll cover some of the new features coming up in the next version of HDX Flash, and provide links to some additional articles and resources to help you in the field
What is ‘HDX’? Most of us know it’s an acronym for High Definition Experience, but what does that mean?
HDX is a family of technologies that bridge the gap between a Citrix virtual desktop or application, and the endpoint device. It provides the platform on which to implement custom policies, to not only optimize the end user experience, but take as much processing out of the cloud as possible. There are always going to be limitations however, which is why we use Adaptive orchestration to decide what the endpoint device is capable of taking that load, which is affected most by network performance.
The focus of today’s discussion will be HDX MediaStream. which is the vehicle for delivering video and audio content to the endpoint device. Media stream is able to redirect ActiveX Adobe Flash and Windows Media player content in their native, compressed format, directly from the content provider, to the endpoint device.
So let’s talk more about HDX mediastream flash redirection, what it does, how it works, and when you should use it.
First things first going forward I’m going to refer to HDX Mediastream Flash redirection as simply, HDX Flash.
So first we’re going to look at how it works
And go over some known limitations,
Which should explain when it should or should not be used.
So as I mentioned earlier HDX Flash redirection redirects ActiveX flash player content from the ICA server to the ICA client.
This redirection process can be dynamically switched between server and client rendered content, depending on factors like platform, components, network conditions, and so forth. Because were redirecting ActiveX Flash, we can only redirect it on On Windows platforms with Internet Explorer ActiveX flash player newer versions of the online plug-in, and version of XenApp or XenDesktop
HDX media stream flash redirection is centrally configurable, along with the rest of the HDX family of technologies. If you’ve worked with XenApp 6 and/or XenDesktop 5, you should be familiar with the new Citrix policy engine, which provides a much more robust and reliable method of deploying these settings to both endpoint and server.
Let’s look at a conceptual overview of HDX Flash redirection
Here we have in ICA session between a Windows client with the Citrix reciever and all other requisite software and settings,
In the datacenter or cloud, we host the ICA server, either in the form of a XenApp published desktop or Internet Explorer browser, or a XenDesktop running IE.
With Flash Redirection, HTML content is downloaded and displayed within the Citrix virtual display adapter, which . However, when Internet Explorer encounters an ActiveX flash player object, our code intercepts the ActiveX Control’s interfaces to the ActiveX Container. It then redirects the Flash Player ActiveX calls to the client. The client then loads a Flash Player ActiveX container in a ‘reverse seamless’ window, and lines it up with a keyframe on it’s parent window or tab, within the ICA session. This gives the client display adapter direct access to the rendered content, instead of rendering on the server.
Let’s see this same workflow in a server-rendered scenario
With Server-side rendered Flash, all web content is loaded in the ICA session’s internet browser, including flash content.
Without the ability to use content redirection, the server is forced to render content within the user session, compress the output, and send screen updates to the endpoint device using HDX Broadcast, which is an entirely different topic in itself. To give you an idea of how HDX Broadcast works, we refer to it at Citrix as queuing and tossing, In other words, the server tosses the screen update to the client, and doesn’t care whether or not the client had time to receive, process, and display the compressed image to the end user. The server will just keep sending packets to the client, who might discard some in favor of keeping up with the stream.
So, when should you use redirection? Let’s talk about the limitations of ActiveX Flash Redirection.
As I mentioned earlier the client and server both require a Windows OS due to the software requirements for ActiveX. This is the most obvious limitation (at this point anyways) since ActiveX requires the Internet Explorer framework, along with the Adobe Flash ActiveX Plugin for Internet Explorer.
Because we’re dealing with ActiveX redirection, we inherit it’s sensitivity to latency (which I’ll get into later). With an ICA latency tolerance of around 30-50 ms round-trip ICA latency (The default is 30 but I’ve seen it work on 50 as well), ActiveX redirection should not be used in environments where latency typically exceeds 50ms. We’ll talk about a few ways to monitor the counters that are used in this decision in the troubleshooting section.
We also want to render on the server side if something otherwise causes the redirection process to fail, such as
not having all requisite software and policies needed to implement the redirection process. Ritch will get into these requirements in more detail about these required components in the configuration section.
Now that we’ve established the general idea of HDX Flash Redirection, lets talk about why you would want to use HDX Flash. The biggest sell with HDX Flash is the ability to render content on the local device, and negates the negative affects of compression and queue and toss, which can result in quality issues we often see with server-side rendering
HDX Flash distributes multimedia computing load to endpoint devices Where resources are otherwise underutilized (especially fat clients).
All of these improvements to end user performance have just as many advantages in the datacenter by reducing multimedia delivery overhead
By sending the content to the client for rendering, we negate server overhead caused by rendering and compression.
This results in less server-side CPU utilization,
which results in less resources needed per session, and increases server density. Think about it this way, with server-rendered multimedia, the process of downloading, rendering, compressing and delivering content to end user wastes computing power. With HDX Flash, we use a hybrid model that still loads the web page on the server, but through redirection offloads a majority of the heavy lifting (rendering) to the client, and are instead, redirecting, rendering, and displaying.
Now we’re going to talk about the core components and processes that make HDX Flash Redirection work.
The main components of HDX flash include
ActiveX Flash redirection, which proxies the ActiveX Container (Pseudo Container) to the client device.
Content Fetching is another major component in HDX flash, and provides two ways to redirect Flash content. Both methods render Flash on the client, but server-side content fetching provides additional flexibility in corporate environments.
And last, Adaptive Orchestration provides the ability to dynamically switch between server and client rendered Flash by measuring network latency, and detecting problems in the redirection process.
Active X is a software module based on Microsoft&apos;s Component Object Model (COM) architecture. Component Object Model (COM) is a software architecture that allows applications to be built from binary software components. COM is the underlying architecture that forms the foundation for higher-level software services, like those provided by OLE.
Originally OLE ControlsActiveX controls were originally called &quot;OLE controls&quot; and used an .OCX file extension. They were Microsoft&apos;s second-generation component architecture (Visual Basic Controls (VBXs) were the first). OLE controls were renamed ActiveX and continued to use the .OCX name. See COM, OLE, COM automation, OCX and VBX.
OLE services span various aspects of commonly needed system functionality, including compound documents, custom controls, interapplication scripting, data transfer, and other software interactions. It enables a program to add functionality by calling ready-made components that blend in and appear as normal parts of the program. They are typically used to add user interface functions, such as 3D toolbars, a notepad, calculator or even a spreadsheet.On the Internet, ActiveX controls can be linked to a Web page and downloaded by a compliant Web browser. Such controls turn Web pages into software as if the program were launched from a server. Like any executable program running in the computer, ActiveX controls can perform any operation on your data. This is why the default configuration in most Web browsers is to prompt the user if an ActiveX control is being requested so the user can decide to download it or not (not always an easy decision).
ActiveX was introduced in 1996 by Microsoft as an outgrowth of Component Object Model (COM) and Object Linking and Embedding (OLE) technologies, and provides a framework for defining reusable software components in a programming language. Without going into too much detail about ActiveX, it should be understood that it utilizes serialized interfaces between the Control and Container.
So in the ActiveX Redirection process, the ActiveX Control runs on the ICA server,
and the Container runs on the client. We refer to these redirected components as
Pseudo server, which pretends to be the ActiveX Control, and Pseudo Container on the client side, which receives the redirected ActiveX calls. The server side implements an
Application hook, to be able to listen for Internet Explorer calls
Since ActiveX is a Microsoft implementation, HDX Flash inherently requires a Windows Operating System, and the Internet Explorer framework
An ActiveX control container supplies an environment in which an ActiveX control can run.
ActiveX containers manipulate, manage, and provide services to all the controls they contain. For example, containers supply controls with event handlers and deal with properties. ActiveX controls have become the primary architecture for developing software components for use in a variety of containers. For a control to operate well in different containers, it must be able to rely on a minimum level of container functionality, which in our case is Internet Explorer 7 and up
During the redirection process PseudoServer hooks Internet Explorer, and watches for Flash Player ActiveX controls. When it detects a Control, it first determines whether all of the required components are installed (ICA Version, IE version, Flash Player version (on both sides) registry/policy settings, etc.). Once it’s sure everything is properly configured, It steals the Class ID of the real ActiveX Container and
Redirects the instructions that were meant for the real ActiveX container, to the Pseudo (fake) container running on the endpoint device. It does this by tunneling the redirected interfaces in it’s own ICA virtual channel. This channel carries the remoted calls to and from the Pseudo ActiveX control. Since PseudoContainer hosts the client side flash player, it consumes the majority of the resources used in HDX Flash.
It’s worth noting that this process is separated for every browser tab or window to help simplify the design by launching matching client-side Flash Player host processes (PseudoContainer.exe) for each server-side Flash Player host process (iexplore.exe).
In order to make a remote ActiveX interface call, HDX Flash serializes the COM calls to and from the ICA client and server through a Virtual Channel called CTX Flash. This is the main reason why HDX Flash is sensitive to network latency between the ICA client and Server. The effects of network latency are directly proportional to the number of ActiveX interface calls
That take place between the browser and the Flash Player. Since the system of an ActiveX Control embedded in a browser is by its nature single-threaded, these calls must proceed serially; this roughly
equates the minimum delay to the product of the number of ActiveX calls required for a particular function (like the initial loading of the Flash Player, or the ActionScript in a Flash application) and the round-trip ICA latency in units of time. For example
if a particular flash video has 70 ActiveX interface calls, and round-trip network latency is 50ms, the delay would be roughly (70) x (50 ms) Delay = 4.5s Note that the latency that affects HDX Flash, and which is measured by the HDX Flash latency detection feature, is not raw network latency. Rather, it is end-to-end Virtual Channel latency (round-trip). If there is a delay between the HDX Flash Virtual Channel endpoint and the network (such as ICA commands buffered in the WD), it will affect the performance of HDX Flash and so is included by the HDX Flash latency detection feature.
Experience shows that there are two occasions during normal use of HDX Flash in which high latency can degrade user experience: During Flash Player start-up (and tear-down). These operations produce a high number of COM calls even with HDX Flash optimizations (~70 calls for start-up). Over a high latency connection, the result is that the web page will appear to pause for some seconds which the Flayer Player is instantiated. For some use cases, a delay during web page load caused by HDX Flash over higher latency networks is preferable to server-side Flash rendering: for example if playing a lengthy video it would be worth waiting a few extra seconds for the video to load in order to have a smooth, high-quality video rendering.
I’ll come back to network latency detection later on in this section, but first, let’s talk more about Content Fetching.
Content fetching is the process of telling the PseudoContainer where to pull the content from. Content fetching is broken up into what know as client-side, and server-side.
As the name implies, Client side content fetching fetches tells Pseudo Container to pull Flash content directly from the content provider. When Pseudo Server impersonates the ActiveX control, it
passes the original URL of the original content location to PseudoContainer. This is the default method, and provides the best performance and compatibility. This is also the default behavior, and should be used whenever possible for client-side rendering.
One of the major limiting factors of client side content fetching is that it needs to be on the same domain as the server for secure content (such as an intranet corporate web site) to be authenticated to the client. This limitation also comes into play if the user accounts on the client and server are different, which adds an extra layer of authorization to the process. This is where server-side content fetching comes into play.
In this scenario, the Server fetches Flash content on behalf of the endpoint (using the credentials of the server), and stores them in a local temporary directory.
The Pseudo Server then substitutes the URL of the ‘fetched’ content with file:// address in the redirected ActiveX calls, and serves as a middle man that temporarily hosts the content through the ICA session.
The main advantage of using server-side fetching is to allow the server to proxy all of the authentication requests as the ICA session user and computer account. It also provides
Limited access endpoints with the ability to render Flash content that it otherwise wouldn’t have access to.
Let’s see an illustration of this process..
In Client-Side content fetching:
PseudoServerInProc.dll hooks Internet Explorer on the ICA server
When Flash content is loaded in the session browser, the PseudoServer redirects the ActiveX COM calls to the client over the CTXFlash virtual channel
The CTXFlash VC is handled by the VDFlash virtual channel driver, which opens an interface to the Pseudo Container
PseudoContainer.exe ‘Fetches’ the flash content directly from the content provider, and renders it locally on the client
The rendered output is displayed on top of the ICA session window
In Server-Side content fetching,
PseudoServerInProc.dll hooks Internet Explorer on the ICA server
When Flash content is loaded in the session’s browser, the Citrix HDX Mediastream for Flash service first downloads the content from the provider
The server then substitutes the file location in the redirected ActiveX calls with the URL of the content to be accessed over the same CTXFlash virtual channel
PseudoContainer.exe then renders the flash content being hosted on the ICA server, and renders it locally on the client
The rendered output is displayed on top of the ICA session window
That should give you a strong understanding of what exactly content-fetching provides, and when it should be used. Now let’s move on to the Dynamic Blacklist
There are a number of cases in which HDX Flash might fail. Due to the nature of the feature it’s very difficult (if not impossible) to detect or prevent these failures proactively, so this is where Adaptive Orchestration relies on the Dynamic Blacklist feature to decide whether or not to redirect the content for a particular site
In this example, a problem in the redirection process causes the process to fail. Failures could include:
failed attempt to fetch content from the client.
The client device may not have access to the content server
An attempt to fetch content from a local file system path.
A crash or panic in the Pseudo Server
A crash or panic in the Pseudo Container
These failures are picked up by Pseudo Server,
Which takes the URL of the site that caused the problem and adds it to a registry key on the endpoint device, which is evaluated each time PseudoServer attempted redirects ActiveX Flash.
If the URL is present when the redirection process starts, PseudoServer will cancel the redirection process and allow server-rendered Flash to run instead, with the intent of preventing hitting the same problems with redirection on that particular URL.
This &quot;dynamic blacklist&quot; remember websites that provoke failures in ActiveX redirection, and direct PseudoServer to fallback to server-side Flash rendering for the current browser tab that provoked the failure, as well as future browser tabs that navigate the failing URL.
The current top-level URL of the offending browser tab is refreshed, and HDX Flash is not used for the reloaded page. Depending on the web site and Flash application, problematic behavior may be exhibited due to this refresh - for instance if the Flash Player was keeping context it would be lost. When the user browses to that URL for a period of time in the future (24 hours), HDX Flash will not be used.
an appropriate event log message is generated on the ICA server.
Latency between the ICA endpoint and ICA server is measured and compared the first time a particular browser thread (tab) encounters an embedded Flash Player. If the measured latency is over the threshold, HDX Flash will not be used for any Flash Player instances in the current browser thread (tab). If the latency is below the threshold, HDX Flash will be used for all Flash Player instances in the current browser thread (tab).
The network latency detection feature works by measuring round-trip latency in two different ways.
HDX Flash measures latency through a simple “ICA-ping&quot; sent over the HDX Flash Virtual Channel. It’s important to note that this ICA ping is affected by ICA session overhead, and other virtual channels that are in use. For example, if you had a USB device attached to the same session, with a higher Virtual Channel priority, the HDXFlash virtual channel packets might be queued, thus causing latency to be higher than actual ICMP pings to and from the ICA server.
The other method of determining latency is to measure ICA session latency by reading the &quot;Latency - Session Average&quot; performance counter of the &quot;ICA Session&quot; performance object.
PseudoServer then takes the lower of the two measurements, and compares the resultant latency to the configured threshold. If latency exceeds the configured threshold, we revert to server-rendered, to avoid problems with the redirection process. We also use a similar method to determine minimum available bandwidth, which has a default threshold of 500Kbps. Both of these checks must meet the configured threshold for HDX Flash to work.
Thank Kenny for the great technical deep dive into HDX MediaStream Flash Redirection!
Let’s keep thing going with a look at some configuration setting to make all this work.
XenApp 5 + or XenDesktop 4 + Server
Client device with Online Plug-in 11.2+
LAN connection &lt;30ms latency
IE7+ NOTE: Internet Explorer 9
Adobe Flash Player 10+ NOTE: Keep versions same
In order for HDX Flash to work, you’ll need to make sure these prerequisites are in place. Both client and server need to have Internet Explorer 7 or higher, and Adobe Flash 10 or higher. I’ve seen some issues where HDX Flash runs into problems when the Flash Player versions are different, so it’s definitely recommended to keep the Flash player at the same version between the two. You’ll also need to make sure you’re using a compatible ICA server and client for HDX Flash to work.
Many of you may be testing Internet Explorer 9 in your environments. Currently, Internet Explorer 9 is not supported with HDX MediaStream Flash Redirection.
The easiest way to configure &lt;&gt;server-side HDX Flash settings is to use the &lt;&gt;ADM template, which is included in the server install media.
&lt;&gt;Options here include enabling HDX Flash, enabling event logging, adding sites to the per-URL blacklist, configuring the network latency threshold (which is hard-coded at 30ms by default), and the ability to add sites to the Server-Side Content Fetching list.
&lt;&gt;These settings can all be configured in the registry as well, just opening the ADM template in notepad to see the corresponding registry keys and values for each setting.
With XenApp 6 and XenDesktop 5 some of the configuration settings are now included in the policies. Use the Delivery Services Console (DSC) for XenApp 6 deployments and the Desktop Studio Console for XenDesktop 5 deployments.
&lt;&gt;There are several ways to enable HDX flash on the endpoint device. &lt;&gt;Again, using the ADM template is the easiest way, though you can also enable HDX Flash using the the Desktop Viewer Toolbar &lt;&gt;, or the registry&lt;&gt;. Notice that the registry setting includes an additional option, called ‘Ask’ &lt;&gt; which will cause a pop-up window to open when Internet Explorer is started. This will prompt the user on whether or not they want to use HDX Flash. When you configure this option in Desktop Viewer, the preference is stored in registry and the key can be deleted to reset the preference to default.
&lt;&gt; Server-side content fetching needs to first be enabled on the client via Group Policy Object
&lt;&gt;The whitelist is a list of URLs with flash content you wish to be fetched from the server.
There are performance implications with server-side content fetching and it should be used only use it when it is an absolute necessity.
As Kenny mentioned earlier, HDX MediaStream Flash Redirection uses a &quot;dynamic blacklist&quot; to remember websites that provoke failures and HDX falls back to server-side Flash rendering for future requests to this failing URL.
Some customers stated they would rather HDX Flash didn’t work at all instead of falling back to server-side rendering due to resource constraints on their servers.
&lt;&gt;Use the following registry keys to disable Dynamic Fallback:
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HdxMediaStreamForFlash\Server\PseudoServer]
&quot;DynamicFallbackEnabled&quot;=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HdxMediaStreamForFlash\Client\PseudoContainer]
&quot;DynamicFallbackEnabled&quot;=dword:00000000
&lt;&gt;The Dynamic Blacklist can be simulated by killing the PseudoContainer process on the client. &lt;&gt;This can be verified by checking whether the URL was added to the dynamic black list of the registry.
The dynamic blacklist additions are placed in a per-user registry locations specifically for:
IE7 and IE8 in non-protected&lt;&gt; mode: HKEY_CURRENT_USER\Software\Citrix\HdxMediaStreamForFlash\Server\PseudoServer\DynamicBlacklist
And for IE8 in protected mode&lt;&gt;, the location is something like the following (note user SID specific path): HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\InternetRegistry\REGISTRY\USER\SID\Software\Citrix\HdxMediaStreamForFlash\Server\PseudoServer\DynamicBlacklist
We know that some websites with Flash content require a session cookie with identity or authentication states to be present. Cookie replication is a feature of HDX MediaStream Flash Redirection that is used with client-side content fetching to synchronize the cookies between the server and client.
What we see here is an &lt;&gt; application is running in the ICA session and the same cookie is being used by &lt;&gt;IE running on the server and by &lt;&gt; the flash player on the client device.
You might ask: What happens if Cookie Replication is not enabled and the user accesses a site like that? Well, in that case, the system will detect that the request is rejected by the web site, and SmartRendering will automatically revert to server-side rendering and add that URL to the blacklist. The user still gets a very good experience, but it puts more load on the server.
The synchronization of HTTP cookies is not enabled by default. Use the client-side configuration setting with the ADM template in the GPO to &lt;&gt; enable synchronization of the client-side HTTP cookies with the server-side.
Please consider enabling this option so that Flash content can be redirected to the client in more cases, thereby increasing server scalability.
The following are known limitations of HTTP cookie redirection:
&lt;&gt;Cookies marked with the HttpOnly attribute are not retrieved from the server.
&lt;&gt;Cookie synchronization occurs only in the server-to-client direction. Cookies set on the client by client-side initiated HTTP requests are not applied to the server.
&lt;&gt;Websites for which an HTTP cookie is modified or deleted by client-side initiated HTTP requests might not be handled properly because the corresponding server-side cookie is applied on the client even when the server-side value becomes obsolete.
&lt;&gt;In cases when there is a persistent client-side HTTP cookie set by local IE and there is no corresponding server-side cookie, the local client cookie will be used in the HTTP request made by the client.
Now that we know how to configure HDX MediaStream Flash Redirection let’s look at couple of issues you may encounter and review a couple of tools to assist you with troubleshooting.
In this troubleshooting section of the presentation, we will cover some utilities which can be used to monitor and troubleshoot HDX MediaStream Flash Redirection.
&lt;&gt;First we will cover the HDX Performance Monitor. &lt;&gt;Then we will look at the Windows EventLogs, &lt;&gt;tracing for the server-side and client-side HTTP headers. And finally&lt;&gt;, we will conclude with HTML debugging.
The HDX Performance Monitor is a utility provided by Citrix which is used to provide detailed information about the various HDX technologies, their performance and related diagnostics information. This utility is designed for XenDesktop versions 4 and 5 and for XenApp version 6.
&lt;&gt;Now let’s take a look at the information the HDX Performance Monitor provides for Adobe Flash.
From the HDX MediaStream for Flash section of the utility, we can tell:
&lt;&gt;If the feature is enabled on the server
&lt;&gt;If the Flash service is running
&lt;&gt;We can see an estimated latency measurement and whether that value meets the latency threshold that determines when Flash redirection is used
&lt;&gt;The version of Internet Explorer and Adobe Flash Player installed is noted and whether the versions are supported
&lt;&gt;And the number of instances of Internet Explorer using HDX MediaStream for Flash are displayed
The tool also offers the ability to shake all active Flash windows allowing you to know the location of all Flash windows.
We discussed dynamically blacklisted URLs earlier in the presentation. The HDX Performance Monitor for XenDesktop provides a list of dynamically blacklisted URLs.
&lt;&gt;Here you can see a list of URLs HDX MediaStream for Flash detected it had issues redirecting.
In a XenApp configuration, the Flash Network Performance page shows the live traffic between the XenApp Server and the Receiver running on the client device.
As we have shown here, the HDX Performance Monitor is an excellent tool that provides useful information and I’m sure you will want to add it to your troubleshooting arsenal.
It was mentioned earlier there is a policy setting to enable server-side event logging. I highly encourage you to enable this setting as it is low overhead and can provide valuable information when troubleshooting. EventLogging is enabled through the ADM template or by setting the registry as shown here. &lt;&gt;
&lt;&gt;In addition to enabling the server-side event logging, there is one more registry setting which will enhance the Windows Event Logging. In order to log all events, we will need to disable event throttling with the Event Throttling registry setting shown here. (&quot;EventTimeThrottle&quot;=hex(b):00,00,00,00,00,00,00,00) Registry setting.
Starting with XenApp 6 and XenDesktop 5, events relating to the Citrix HDX MediaStream Flash Redirection service is logged under &lt;&gt;Applications and Services Logs -&gt; Citrix -&gt; Multimedia -&gt; Flash -&gt; Admin
One note here about Windows EventLogging on Windows 7. If you don’t see any HDX related events on the Windows 7 client devices, use the &lt;&gt; Windows Events Command Line Utility with the “ep” command to display a list of publishers. Use the ‘im’ command to install the HDX Flash Event Messages manifest to register HDX related events in Windows 7.
One common issue with HDX MediaStream Flash Redirection and client-side content fetching you might see the client did not actually fetch and render the flash content on the client but rather fail to the server for rendering. This screen capture shows &lt;&gt;EventID 53 in the Application Log indicating, in this case, the &lt;&gt;network latency did not meet the default 30ms network threshold.
For those times when the HDX Experience Monitor or the Windows EventLogs don’t provide the answers to an issue, Citrix Technical Support may ask that a Citrix Diagnostic Facility trace be captured. A CDF trace is accomplished by using CDFContol.
CDFControl allows you to select the modules you’d like to capture. In the case of HDX MediaStream for Flash, there are three modules to capture. They are:
&lt;&gt;MF_DLL_FlashCore
&lt;&gt;MF_DLL_FlashTransport
&lt;&gt;MF_Service_CtcFlashSvc
Once the CDF trace is captured, a Citrix Technical Support engineer will analyze to determine the issue.
Real-time traces are essential for troubleshooting cases in which pseudocontainer.exe is halting, failing to start or just not performing the functions as it should. Client-side file tracing can be accomplished by configuring &lt;&gt; the File, Level and Flags settings in the registry of the client.
Once you have completed the tracing, you can obtain the trace file from the %USERPROFILE% directory for Pre-Windows Vista clients and %USERPROFILE%\AppData\LocalLow directory for Vista and later clients.
A word of warning: &lt;&gt; As it states here, Setting the log level to 9 traces everything and will greatly impact performance!
Also, please make sure you set the file dword back to zero after collecting the required logs. Trust me, if you fail to disable this and forget about it, at some point you’ll wonder why you’ve run out of disk space.
You may recall an issue last year where there were all of a sudden we weren’t able to play YouTube videos when HDX MediaStream Flash Redirection was enabled resulting in this very descriptive error message.
As you can see from this client-side file trace, there was a streaming error.&lt;&gt;
Further analysis shows that during a cookie sync &lt;&gt; required cookie information was not present. &lt;&gt;
This data helped Citrix Engineering determine that a change was made in the way YouTube handled cookies with streamed videos. Citrix Engineering was then able to write a Citrix Hotfix to address the new method YouTube initiated in handle cookies and properly render the videos with HDX.
Network capturing programs such as WireShark or NetMon can be used to view the HTTP traffic. A Web Debugger, like Fiddler shown in this slide, can also be used to dive deeper into http traffic. Fiddler acts as a proxy and logs all HTTP and HTTPS traffic between your computer and the web site. With Fiddler you can inspect all HTTP(S) traffic.
Microsoft Internet Explorer v8 includes the IE Developer tools which can be evoked by pressing F12 while in Internet Explorer. This screen capture depicts a capture of IE navigating to www.citrix.com. A search on &lt;&gt; the .swf file extension &lt;&gt; displays the Flash content being played.
In summary, if you require assistance from Citrix Technical Support assistance, please:
&lt;&gt;Capture any pop-up error or warning messages
&lt;&gt;Collect any eventlogs from the server and the client
&lt;&gt;Run the HDX Performance Monitor tool within the ICA session and collect any screen captures or use GoView to capture a video.
&lt;&gt;Collect server-side and client-side tracing
Receiving this information upfront will expedite resolution to your issue.
As we near the close of this presentation, we’d like to provide some additional information…
Citrix Engineering is working hard to enhance HDX technologies in general and HDX MediaStream Flash Redirection more specifically. Here are a few of the enhancements coming with Generation 2 later this year.
Here are few links to the resource used in creating this presentation and they will be available for download with the presentation.
Session surveys are available online at www.citrixsummit.com starting Thursday, May 26
Your feedback will help us improve future sessions. Don’t forget to pick up your complimentary gift at the registration desk
Presentations will be available for download starting Friday, June 3 from your My Organizer Tool.
On behalf of Kenny, we thank you for your time today! We will now open the floor for questions.
