Configuring Citrix XenDesktop 5.6 HDX Adobe Flash Redirection

HDX MediaStream Flash Redirection allows Adobe Flash animations, videos and applications to be redirected directly and played on a VDI user’s local device such as a thin or thick client rather than rely on server side rendering with the video transferred from the VDI to the Citrix Receiver on the user’s local device. Flash Redirection helps reduce server and network load, resulting in greater scalability while ensuring a high definition user experience.

In order for Adobe Flash to be successfully redirected to the user’s local thin client device such as the HP t610, the Adobe Flash Player installed onto the device must be the same or newer version of the Adobe Flash Player installed onto the VDI. An example of a working configuration would be:

Thin Client: Adobe Flash Player Plugin 12.0.0.77

VDI: Adobe Flash Player ActiveX 11.7.700.272

An example of a configuration that wouldn’t work would be:

Thin Client: Adobe Flash Player Plugin 11.7.700.272

VDI: Adobe Flash Player ActiveX 12.0.0.77

It’s important to note the following:

The thin client only needs to have the Adobe Flash Player Plugin installed and the VDI only needs to have the Adobe Flash Player ActiveX 12.0.0.77 installed in order for the flash redirection to work so while the other components are installed both devices, they are not required.

There is no harm with installing the extra components so I usually go ahead and install both the ActiveX and Plugin onto the thin client as such:

• Adobe Flash Player Plugin 12.0.0.77
• Adobe Flash Player ActiveX 12.0.0.77

The same can be done with the XenDesktop VDI:

• Adobe Flash Player Plugin 12.0.0.77
• Adobe Flash Player ActiveX 12.0.0.77

Once the appropriate Adobe Flash Players are installed on the VDI and Thin Client, the following prompt from the Thin Client will be presented as soon as you attempt to play a flash video from within the VDI:

By selecting Yes, optimize content and then clicking on the OK button, flash videos from within the VDI will be redirected to the local thin client.

If the Adobe Flash Player versions do not meet the requirements as outlined in the the requirements section of this document, the following window with the Yes, optimize content grayed out will be displayed:

To verify that Adobe Flash is being redirected to the local thin client, launch the HDX Monitor for XenDesktop:

Ensure that the Adobe Flash node is labeled as Receiver is compatible:

If the Internet Explorer is set up to redirect flash, you should immediately notice the following change when IE is launched:

Receiver is compatible
Flash redirection is active

In addition to the change in text as demonstrated above, you can also click on the icon to review the Internet Explorer details that the HDX Monitor has detected:

**Note that it is important for the State to be labeled as Active when the flash video is displayed in the browser or when it is playing to ensure that flash is indeed redirected.  If you notice that the State is labeled as Idle then flash isn’t redirected.

Another way to verify that the flash is redirected locally to the client is to click on the Shake active Flash windows which would shake the flash video window.

Citrix XenDesktop 5.6 HDX Adobe Flash Redirection’s State is Idle and does not redirect Adobe Flash video

Problem

You’ve installed Adobe Flash Player onto your Citrix XenDesktop 5.6 VDI as well as your thin or thick client and verified that the version on the thin / thick client is the same or newer version of Adobe Flash Player than the XenDesktop VDI but while testing Adobe Flash Redirection, you notice that the HDX Monitor for XenDesktop displays the Adobe Flash node as:

Receiver is compatible
Flash redirection is idle

Clicking on the Adobe Flash node displays:

• State as Idle
• Internet Explorer compatibility as IE 9 is supported
• Adobe Flash Player as Installed
• Service status as Running
• IE instances using Flash redirection as 0

Right clicking on the video does not display Citrix Media Stream in the menu:

Solution

One of the reasons why you would encounter this is if you’ve installed the following components:

Thin Client: Adobe Flash Player 12 ActiveX

Citrix XenDesktop 5.6 VDI: Adobe Flash Player 12 ActiveX

The setup above may seem logical but while this would allow the VDI to detect the settings as shown in the Problem section, the Adobe Flash within the VDI will continue to be rendered at the server and not on the thin client.

To correct this issue, install the Adobe Flash Player 12 Plugin onto the thin client as shown here:

With the following installed:

Thin Client: Adobe Flash Player 12 Plugin
Citrix XenDesktop 5.6 VDI: Adobe Flash Player 12 ActiveX

… Adobe Flash should now be redirected with the Adobe Flash node displayed as:

Receiver is compatible
Flash redirection is Active

Clicking on the Adobe Flash node should now display:

• State as Active
• Internet Explorer compatibility as IE 9 is supported
• Adobe Flash Player as Installed
• Service status as Running
• IE instances using Flash redirection as 1

Citrix XenDesktop 5.6 HDX Adobe Flash Redirection Crashes Internet Explorer 9 (IE9)

Problem

Environment:

Citrix XenDesktop Version: 5.6

Citrix XenDesktop VDA Agent Version: 5.6.300

Adobe Flash Player Version on VDI: 12.0.0.77

Adobe Flash Player Version on VDI: 12.0.0.77

Internet Explorer Version: 9.0.8112.16421

You’ve recently updated the Adobe Flash Player on the Citrix XenDesktop 5.6 VDI and HP Thin client t610 from 11.7.xxx.xxx to 12.0.0.77 and noticed that as soon as you use Internet Explorer 9 to browse a page with an embedded Adobe Flash video:

Internet Explorer has stopped working

A problem caused the program to stop working correctly. Please close the program.

Close the program

The following error is logged in the Application log of the VDI:

Log Name: Application
Source: Application Error
Event ID: 1000
Level: Error

Faulting application name: iexplore.exe, version: 9.0.8112.16533, time stamp: 0x52f1fb14

Faulting module name: PseudoServerInproc2.dll, version: 6.3.300.17, time stamp: 0x51bb6818

Exception code: 0x4000001f

Fault offset: 0x0010987f

Faulting process id: 0x530

Faulting application start time: 0x01cf481e433dff05

Faulting application path: C:\Program Files (x86)\Internet Explorer\iexplore.exe

Faulting module path: C:\Program Files\Citrix\ICAService\PseudoServerInproc2.dll

Report Id: 86127455-b411-11e3-804a-0050569116f7

 

Solution

Option #1:

A search on the internet brought me to the following forum post:

http://discussions.citrix.com/topic/339058-oops-you-did-it-again-ie9-crashes-after-flash-upgrade-119900117-xa65/

… where users indicated that reverting back to 11.7.700.169 corrected the problem so I went ahead and tried reverting back to 11.7.700.272 as shown in the following screenshots:

http://get.adobe.com/flashplayer/

**Note that it is important to run the uninstall executable first or you’ll receive the following error:

The installation encountered errors:

The version of Adobe Flash Player that you are trying to install is not the most current version. Please visit the Player Download Center to obtain the latest, most secure version.

Reverting the Adobe Flash Player to an earlier version stopped Internet Explorer from crashing:

Option #2:

Not being satisfied with reverting to an earlier version, I decided to test upgrading the 5.6.300 VDA agent to the latest 5.6.400 version:

… and noticed that this also fixed the issue.

Removing the “Set expansion server” setting for a Exchange Server 2010 distribution group that is still referencing an Exchange 2003 Server

Problem

You’ve just completed migration an Exchange Server 2003 organization to Exchange 2010 but noticed that emails to some distribution groups are not being delivered.  After reviewing the distribution groups, you notice that the Set expansion server setting for the distribution group is still referencing the Exchange 2003 Server:

The easy fix is to simply uncheck the Set expansion server, click OK and you’re on your way. 

The challenge by doing it this way is if there are either a lot of distribution groups set this way or there are so many distribution groups that it would take too much time to determine which ones have this set.

Solution

The way to automate the process as many would know is to use the PowerShell cmdlets.  To determine which distribution groups have this set, we can use the Get-DistributionGroup cmdlet as described in the following TechNet article:

http://technet.microsoft.com/en-us/library/bb124755(v=exchg.150).aspx

The attribute we’re interested in is the ExpansionServer attribute as shown here:

Get-DistributionGroup -identity “S2 Students” | FL

We can alternatively use the following cmdlet to list all of the groups by their DisplayName and ExpansionServer attribute only but the problem by doing it this way is that it would list groups with no ExpansionServer set as well:

Get-DistributionGroup | FL DisplayName,ExpansionServer

To refine the search, we can use the -filter switch as such:

Get-DistributionGroup -Filter {ExpansionServer -like '/o=EDUCATION*'} | FL DisplayName,ExpansionServer

Other methods that would achive the same results is to use -eq switch for a exact search or the -ne (not equal) switch as such:

Get-DistributionGroup -Filter {ExpansionServer -ne $null} | FL DisplayName,ExpansionServer

With the cmdlets used to retrieve the distribution groups with an expansion server set, we can now use the Set-DistributionGroup cmdlet as described here:

http://technet.microsoft.com/en-us/library/bb124955(v=exchg.150).aspx

… to remove the ExpansionServer attribute.  To do this for a single distribution group, use the following cmdlet:

Set-DistributionGroup -Identity "BUT" -ExpansionServer $null

To do the same for all of the distribution groups, use the following cmdlet:

Get-DistributionGroup -Filter {ExpansionServer -like '/o=EDUCATION*'} | Set-DistributionGroup -ExpansionServer $null

This cmdlet will ask you to confirm for each which is useful if you want to be sure you don’t inadvertently set other distribution groups to null but if you’re sure that all of the returned distribution groups should have their ExpansionServer attribute removed, you can simply use the letter A response to set all of the groups in one shot.

Once the above cmdlet successfully executes, the distribution group’s Advanced tab should display the Set expansion server setting as such: