Wednesday, 29 September 2010

Installation Manager for XenApp 6 – installing Acrobat Reader

Now we have Installation Manager installed, we should probably use it.  An MSI and MST file combination is a good standard install, so this is rolling out Acrobat reader to your Citrix servers.

Customising Acrobat Reader

  • Download Acrobat Reader – I got the latest version (9.3.4) from the Adobe website, after a little searching:
  • Also download the Adobe Customization Wizard 9:
  • Install the Adobe Customization Wizard on your PC – accept all the defaults.
  • Extract the EXE using this command: AdbeRdr910_en_US_Std.exe -nos_ne
  • Wait for the window that pops up to do its work…
  • You should then find the extracted files in this folder on Vista and Windows 7:
    %LOCALAPPDATA%\Adobe\Reader 9.3\Setup Files
  • Run the Adobe Customization Wizard
  • Open the AcroRead.msi you just extracted into Setup Files
  • Select Installation Options on the left – set to run Silently and Suppress Reboot


  • Select Shortcuts.  Remove the desktop shortcut.
  • Select EULA and Document Status.  Click the checkbox to suppress the EULA dialog
  • Select Online and Features.  Disable all features and all updates.
  • Exit from the application and it should ask you if you want to save changes to AcroRead.msi.  Say yes, and it will create the file AcroRead.mst in the same folder as the MSI file.  Move the contents of this folder to your shared fileserver ready for Installation Manager to use them.

Distributing Acrobat Reader using Installation Manager

  • Open Installation Manager
  • Click “Schedule MSI/MSP package…” on the right hand pane
  • Enter a name in the Task name box
  • In the Target List box, you can just enter the names of the servers to install to, separated by commas (no spaces).  Alternatively, click “Servers…”.  This will bring up a worryingly empty list.


  • Select Citrix Server Selector (assuming they are in a farm – otherwise use the Windows Server Selector) and click Add
  • Enter the name of a Citrix server (maybe the Data Collector?) in the “Server Address” box and click GO!
  • You should get a nice list of your servers and server folders.  Select servers (use CTRL to select multiple) and click “Add >” to select them.
  • Put the installation files you prepared earlier in a shared folder on a fileserver.
  • Select the MST and MSI files using the Browse buttons (or by just typing of course).
  • Enter a time for the install – or leave it as Now.
  • Select the checkboxes to log off users or reboot the server as needed.  With this install I am just denying logons.


  • Click the Advanced button and change the cache location for this task to the one on the shared file location which holds and MST and MSI.  I don’t know if this is necessary but without this change it seems to have trouble finding the task.  You can also change the retry settings here. By default it will retry every 10 minutes for 1 hour.
  • Click OK to schedule your install!
  • Right click the task every few seconds and select Refresh.  It should succeed – you also get the PowerShell code that is fired at the servers.

Distributing an MSP update

  • Once this is succeeded you should have Acrobat Reader 9.3.0 installed.  To update this to 9.3.4 (currently the latest), create a new task, as before.  This time, when you browse for the MSI file, change the drop down at the bottom to MSP files and you should see a list of MSP files:


  • Select (now for the annoying bit) the oldest.  In the case of this upgrade you need to update it to 9.3.2, then 9.3.3, then 9.3.4.  If you go straight for 9.3.4 it will fail with the status “Installation Failed: 1642”.  So select 9.3.2 and carry on.
  • You won’t need a transform for this so just select the right servers and change the Shared Folder under Advanced settings to be the one with the MSP in and run it.  It should work and you can check the installed version of Acrobat is upgraded. 
  • Repeat the process creating installation tasks for the 9.3.3 and 9.3.4 updates.  At least it will easy when the inevitable 9.3.5 comes along!

Installation Manager for XenApp 6 as a Published Application

From XenApp 5, Installation Manager is a nice name for what is in fact a package of MMC add-ins, powershell scripts and the Windows Task Manager.  The old Installation Manager from Presentation Server has basically been removed (let’s be honest, it wasn’t that great) and replaced with lots of standard Windows functionality.

Though everything is streamed, right, so you don’t need it anymore. Right?  Well, just in case…

This is how to install IM on XenApp 6 and allow the management interface as a Published Application:

  • Download Installation Manager for Windows Server 2008 R2 from My Citrix and extract
  • On all the servers to receive deployments, install IMUtilities-x64.msi
  • Set up a network share that IM can use as a cache
  • On the server that will host the admin tools, install IMAdmin-x64.msi.  There is a 32-bit version as well, but if this is on a 2008 R2 server, you need the 64-bit one.
  • Search in vain through the Start Menu for a link to it.  There isn’t one.
  • Start, Run, MMC
  • Click File > Add/Remove Snap-In
  • Find Installation Manager and click “Add”
  • You will get prompted for your network location you created earlier


  • Click OK and OK to finish adding the snap-in – you should return to the MMC, now with the Installation Manager appearing on the left hand side, with the file server location you specified at the end of it.
  • Click File > Options to finish the configuration. 
  • Click Change Icon if you want to give it a more jazzy icon than the standard MMC one.  Click Browse and find an ico file – or load C:\Windows\System32\shell32.dll which has loads in it.  I went for a nice floppy disk icon from here!


  • Change the console mode from Author – “User mode – Full Access” should do.


  • Save it to the local drive of the Citrix server and log off.
  • Open the XenApp Delivery Services Console
  • Right click Application, select Publish Application
  • Enter Installation Manager as the Display Name.
  • Click Next and Next to confirm as an Installed Application, accessed from a server.
  • You actually run mmc.exe with the name of the MSC file you just created as an argument.  So, if you saved it as c:\installationmanager.msc, your command would be
    %SystemRoot%\system32\mmc.exe c:\installationmanager.msc


  • Click next, add the icon to your admin users and click next again.
  • Click Change Icon again to find a nice icon again if you want to for your published application.  Or pick a default one.  It depends how much you like icons. Personally I am not a big fan of half the management apps on the farm having the standard MMC icon, but maybe I think about it too much. 
  • Click next and finish to save the icon.
  • I would then edit its properties again and click the Limits tab.  Set it to only allow one instance per user – a second launch will not work as you already have that MSC file open.


  • Refresh the application list on your client PC and you should see your new Installation Manager icon.


Wednesday, 22 September 2010

Load Testing Outlook 2010 on XenApp – Hosted vs. Streamed to Server

After this initial test comparing the performance of Word 2010 Hosted against Streamed to Server on XenApp 6 showed some considerable advantages to using locally installed Office 2010 instead of Streaming it, I stepped up my testing and included Outlook 2010 instead.  The test was more intensive, moving between the different screens of Outlook (Inbox, Tasks, Contacts, etc) and creating and deleting items. 

Again, I set up EdgeSight for Load Testing to run 50 users on a single server – logging in at the rate of one every 20 seconds, staying logged in and “working” for 10 minutes and then all logging out in 3 minutes.  They once again looked nice when they were all logged in…


Outlook 2010 Hosted

Outlook 2010 performed very well on XenApp 6 when installed locally.  CPU time was quite acceptable throughout the test, being quite close to the performance of Word 2010 at the same load.  Memory usage was slightly higher than Word 2010, being about 7gb. 


Outlook 2010 Streamed to Server

Streaming added a couple of issues to the performance of Outlook 2010.  Firstly, the logon phase involved far more CPU activity, being flat at 100% for about the last three minutes.  CPU usage then remained very high through the phase of the test where Outlook was looping through simulated user activity, before dropping off nicely at the end of the test as the users logged off.  Memory usage was more worrying.  Its not that it was much higher than hosted – it was higher, though not substantially so.  The worrying part was that it increased through the 10 minutes after logons stopped as each OUTLOOK.EXE process slowly ate more RAM.  The Hosted Outlook processes did not behave in this way.  We tried this again over a much longer period with more users and this continued, Outlook using ever more memory until being logged off



This test was more conclusive than the Word 2010 test, with far more gap between Outlook 2010 when Hosted and when Streamed to Server.  Performance of the application when open did appear to be roughly the same, but with logon time more than double for the streamed application, this is not enough to justify streaming.  The higher CPU usage after logons stopped would indicate using Streaming to Server would reduce the number of active user sessions the server could support quite substantially and on this hardware could not be recommended.

Load Testing Word 2010 on XenApp – Hosted vs. Streamed to Server

As part of a decision on how to present Office 2010 to our XenApp 6 farm we benchmarked Office applications as Streamed and Hosted applications.  When we tried this on XenApp 5 with Office 2007 the difference between the two did not seem very great – this time around the Streaming version seems to put on some considerable load.

With each test we logged on 50 users in 16 minutes (one logon every 20 seconds) and ran them for 10 minutes, typing random text Word.  They then all logged out over a 3 minute period.  They look very pretty when they’re all running:


Word 2010 Hosted

The locally installed on the server version of Word 2010 performed very well.  It easily handled logins every 20 seconds with the CPU (on a medium spec dual processor server) at about 30% in the logon phase, 15% when all the users were logged in and a peak of over 50% during the rather rapid logoff. Memory usage peaked at about 6gb


Word 2010 Streamed To Server

The second test was using the same hardware, users and script as the first – but this time Word was streamed to the server.  The difference was apparent from the first login, which took a lot longer – about 25-30 seconds, almost double the Hosted logon time.  CPU usage was consistently 10-15% higher in the initial logon phase and then built alarmingly as the user count reached 50.  It then dropped off very nicely once the users were logged in.  Memory usage was higher, peaking at about 7gb.



Overall the Hosted version performed very much better than the Streamed to Server version with Word 2010.  As you might expect, most of the difference was in the logon phase, where CPU activity was much lower on the hosted version.  Logon times were also longer using Streaming, by at least 15 seconds.  This makes sense as the Streamed to Server version has a bit more work to do creating the Sandbox environment.  The lower memory footprint of the Hosted install overall might also mean that greater user density would be possible using Word 2010 installed directly on the servers.

However, the Streamed to Server version did have lower CPU usage in the later phases, so this test might be considered more even, depending on the pattern of your logons and logoffs.  It must be said that the test did not make an effort to push Word in this middle phase, it was just some light typing.  A more intensive test might show more difference at this point.

This test was conducted using v6 of the streaming client and profiler and XenApp 6 running on Windows Server 2008 R2 on a single dual core server with 12gb RAM.  The test was performed with EdgeSight for Load Testing v3.7.

Monday, 20 September 2010

XenApp 6 – Publishing a Delivery Services management console to non-admins

I’m assuming here you have a first line support and they can be trusted with logging off users?  We don’t want them reconfiguring the farm though, do we – they might get dangerous! 

Simple stuff really, but good to get right. Incidentally, this is to get the console working as a Hosted application – I would like to stream it really, and indeed had it streamed in XenApp 5.  I’ve not had any success streaming the updated version in XenApp 6 though.  If anyone has a working process, do let us know.

Publishing the Delivery Services Console (DSC)

  1. UAC – if this is enabled, disable it on the servers you will host the console from as this apparently can cause trouble with this application – according to various posts on the Citrix Forums site and this eDocs article.  I’ve not tried it personally, I have UAC off on my XenApp servers.
  2. Install the Management Tools on a live XenApp server that you want to publish them from.  If you have run the install manually, they’re on by default.  If you scripted it you might have well not installed them (best not to, really). On a XenApp Server without the DSC, click Start, Citrix, XenApp Server Role Manager and XenApp Server Role Manager.
  3. image

  4. Click Add server roles and admire the nice animated progress bar.

  5. Select your XenApp edition and accept the terms and conditions
  6. You probably have something like the screen below, with only XenApp selected.  Just click next to continue

  7. On Choose Role Subcomponents, make expand Default Conponents and you should see “XenApp Management” is ticked but not greyed – that means it is not installed, but will be.  Click Next, Next and Install to install the tools and their pre-requisites…~

  8. You should now see the folder Citrix > Management Consoles in the Start Menu.  Before you proceed, do you use Citrix Single Sign On?  If not, remove this from the console or it will keep prompting you about it.  Go to Control Panel, select Uninstall a Program.  Find “Citrix Single Sign-On Console 4.8” , right click and select Change.  On the screen that pops up, select Remove to get rid of it.

  9. Launch the Citrix DSC on your server.  You’ll be asked about “.NET Authenticode”.  If you are behind a Proxy I would disable this:

  10. The “Configure and run discovery” wizard should now run.  You should be able to click Next, Next, Add Local Computer, Next, Next and Finish to see your farm.
  11. Right click Applications and select Publish Application.  Configure it as an Application, Accessed from a Server and Installed rather than Streamed.  The location of the executable will be “C:\Program Files (x86)\Citrix\Citrix Delivery Services Console\Framework\CmiLaunch.exe”.  You should know the settings for the users who will see it and the servers to host it from.

Configuring non-administrator access

  1. In the DSC as a Farm Administrator, right click Administrators (immediately under your farm name) and click Add Administrator

  2. On the Select Users screen, add in the users or groups that will be helpdesk users on the farm.  Use an AD group for this, so in the future you just have to add a user to this group.  It might be an idea to present the published icon to only this group as well.
  3. You then get options to create the users as View Only (pretty useless), Full Admins (overkill!) or Custom.  Choose Custom.

  4. You now get a very nice console which by default gives your users no permissions (you’ve got to admire that kind of attitude).  Go through the tree and turn on anything you want to give out.  For instance, if your helpdesk users are only going to log users off and reset sessions, click the Servers or Applications tabs and click the appropriate check boxes.  On Applications and Servers folders, make sure you include “View Server Information” or “View Application Information” otherwise the users will have the permission to configure settings but not to see the interface to do so. 

    If you have subfolders in Servers and Applications, click “Copy to Subfolders” after doing this to copy those permissions down – if you want to do that of course.  You might have servers you don’t want anyone to administer but you.  When you create folders in the future, remember to allow them to inherit permissions.

  5. If you want to change these permissions in future, just right click the entry in the Administrators section of the DSC and select Administrator Properties and the Permissions tab on the left.
  6. Your non admin users should now be able to launch the DSC, run “Configure and Run Discovery” as you did (clicking Add Local Computer to connect to the farm) and see the elements you selected for them.
  7. If your users get the error “Errors occurred when using [servername] in the discovery process” and when you double click it you see the error “This user account is not an administrator of the farm”, make sure that the user has the right “Log on to Management Console” under the Administrators section.


Friday, 17 September 2010

Hosting the Internet Explorer 9 Beta in XenApp 6

image Installing beta software on your XenApp farm might sound like a bad idea – because it probably is actually.  Still, if you have a server that you can use to host test applications for a while before being wiped it could be a good way of satisfying the curiosity of some users without them trying to install it on their main desktops.

This took a lot more messing about than I was expecting, I thought it might be worth sharing this in case anyone else is trying the same thing.  I’d be very interested in how other people felt IE9 Beta worked on XenApp as well.

Pre-requisites and the Beta Service Pack

To install IE9 on your XenApp 6 2008 R2 server, first you need the pre-requisites:

The pre-reqs for IE9 Beta are generally on this page:

You should just need the one in near the end of the list for Windows Server 2008 R2.  Personally I could not get the IE9 beta to recognise that it was installed though and had to go even further into Beta territory by installing the Windows Server 2008 R2 Service Pack 1 beta!

Download from this site: (click the second green Get Started Now button…)

After a reboot I had an upgraded Windows 2008 R1 SP1 beta server!  I’m really not going to put this into live service without a rebuild…


You are now ready to install the IE9 pre-req update.  Go to this site:

and click the link “download the x64 SP1 beta package now”


Install and reboot.


Installing IE9 Beta

You should then be able to download the IE9 beta – get the x64 version from here:

Scroll to the bottom of the screen to the server section and download the version for Windows Server 2008 R2 64-bit


And run the executable!  Follow the installation through, with the above updates it should succeed.  Reboot at the end of the install.




Publishing IE9 Beta to the farm

After a reboot I did indeed have IE9 installed locally…


Finally, I published an IE9 as a Hosted Application on my XenApp 6 farm (launching from "C:\Program Files (x86)\Internet Explorer\iexplore.exe").  I put a start page on the end of the address as well to give the users something nice to look at.


Fixing the server!

Sadly, when I came to test the application as a Citrix app I found it would not work.  I tried publishing both IE9 x86 and x64 and even tried Notepad with the same impact – when it connected my server would drop all its external connections and become unmanageable until rebooted.  Also, Windows was worryingly claiming that Remote Desktop Services was unlicensed.  I assume this is all because SP1 is not ready for launch yet. I went into Control Panel and into Programs and Features and Installed Updates then removed the beta Service Pack then rebooted again!


I then removed the update KB2259539 that I installed earlier and installed the one for 2008 R2 without the beta service pack and rebooted.  Again.

And it works!  I have IE9 published on the Citrix farm, from a server which I still wouldn’t trust with anything else but that is more stable than when it had SP1 beta (which is NOT ready for a XenApp Server trial!). 

A quick test revealed that HDX MediaStream for Flash still works in the IE9 beta, which is a bonus.  Seems very fast and stable.  And a bit like Chrome…

Tuesday, 14 September 2010

Profile Management 3.2 – bug fixes and a name change!

image The marketing department of Citrix have struck again and renamed “User Profile Manager” to “Profile Management”.  Why?  Honestly I don’t know why they bother.  Apparently this has been the case for some time, its such a pointless change I only just noticed.

Profile Management (for those not using it) is a much more intelligent way of handling user logons than either Mandatory (which is a bit harsh) and Roaming profiles (which tend to bloat and corrupt more than is good).  There are plenty of third party alternatives, but this is included in your Citrix license and is a lot better than nothing.  It allows you to specifically exclude HKCU registry settings and files from the user profile at logoff, have your Citrix profiles all in one place (if you want – or in the users’ home folders) and cope well with multiple logons and logoffs at the same time without profile corruption.  A good recent feature has been “Active write back”, which when enabled will only pull some of the profile over to the server at logon and write files back to the profile store as and when they are created rather than all at logoff.  This improves logon and logoff time but just as importantly helps protect your data against a server crash.

Profile Management 3.2 is available to download through My Citrix.  Documentation for it is here.

It can be installed on Windows 2003 Server, but requires these hotfixes or the installation will fail and rollback:

Anyway, the bug fixes in the new version (replacing v3.1.1) of what I will continue to call UPM for at least one major version after this sound nice to have.  Note that for at least one of them to take effect you need to import a new ADM into your Group Policy. 

Issues fixed in Profile Management 3.2

  • If profile streaming and active profile write back are used, Profile management might unnecessarily copy unchanged files from monitored directories to the roaming profile store.


  • If a folder name is specified in the Folders to mirror policy that does not exist verbatim in the user's profile (for example, if the folder name is misspelled), the user session can wind up locked unexpectedly. The issue occurs because the service continues to attempt to locate the non-existent folder during logoff and eventually becomes unresponsive. The service starts again after a certain winlogon time-out period but then the user session is locked by winlogon.


  • When a user logs on to a computer running Version 3.1 of profile management and then to a computer running an earlier version, such as 3.0, an entry should be logged on the computer running the later version, stating that a server with an earlier version pf Profile Management exists on another server and specify that server name. Instead, the log entry states: "An older version of Profile management is running on server <Unknown>."


  • Applications can become unresponsive without logging any error messages when the cachefill mechanism conflicts with anti-virus software settings. This enhancement adds an Event Viewer message indicating the problem.


  • When Profile management is installed on the terminal servers, Wbemtest.exe reports new user objects. However, when users log off, the report is not updated and user objects remain on the root\rsop\user namespace. With this fix, Wbemtest does not show a namespace for the user after logoff if Delete local profile during logoff is enabled.


  • When the usn journal is deleted and the Profile management service restarted, a "CJIncreaseSizeIfNecessary" error is written to the Event Log. With this fix, the error is replaced by a warning as Profile management enables journaling.


  • Two or more Profile management 3.x sessions running concurrently can break backward compatibility with earlier versions of Profile management.


  • In scenarios with Profile management Version 3.1, the Delete locally cached profiles on logoff (Citrix User Profile Management GPO) setting enabled, and the Application Data folder redirection (Microsoft GPO) setting enabled, an error occurs when a new user makes the second attempt at launching the same Microsoft Office application. To resolve the issue, enable the Delete Redirected Folders setting available after importing the new .adm template.


Tuesday, 7 September 2010

Checking HDX MediaStream for Flash on XenApp is working

HDX MediaStream for Flash on XenApp is great.  It makes Flash content render really fast, saves CPU time on your sever and has a cool name. 

There are a few gotchas that can trip it up though, and if all its conditions are not satisfied it will fairly silently not work and render Flash on the server instead, causing poorer user experience and server slow down.  This guide should include all the pre-requisites to it working:

There are a few ways of checking it is working in a XenApp published Internet Explorer window.

CPU Activity

Simple one – look at Task Manager on your client and server PCs when intensive Flash content is playing – one will probably have high usage against your user and that should be the client if HDX is working.

Task Manager

Still in Task Manager, while you are looking at Flash content, look for PseudoContainer.exe both running and probably using CPU time.  If PseudoContainer.exe is not running and you have Flash content being delivered by a XenApp server, its not using HDX.


Look for the Cyan

The HDX client uses Cyan as a background colour when its working.  Go to a flash site and resize the window by dragging its side out.  You should see a momentary flash of a light blue colour at the side as you do, like below:


Use the HDX Experience Monitor for XenApp

This is the last word in telling whether HDX is active and working.  Download this tool:

Note this needs the Citrix Receiver to work, so if you don’t have a Merchandising Server, this is a good time to build one!

Install on the XenApp Server you are hosting Internet Explorer from – install the x86 version if you are deploying the x86 version of IE as a Citrix Application. 

Make this available as a Hosted Application (configured to only run one copy per user):


And run it in the same session as Internet Explorer.  If it sits on a screen waiting for performance monitor counters, you may have installed the wrong version (the x64 edition did this on my server).  It also won’t work in an RDP session.

If you launch this first it should say under Adobe Flash that “Receiver is compatible” (if it is!) but that “Flash redirection is not active”.  Once you launch IE in the same session and view Flash content it should change to active.


If you click the Adobe Flash entry you should see more details about HDX on this connection.  In this case, everything is fine except the network latency, which is too high and will block HDX from working.  This threshold can be configured in the Policies section of the XenApp 6 management tools for the farm.


Finally, there should be a Diagnostics section at the bottom of the screen.  Click “Run HDX Flash System Verifier” to launch a very useful tool that will check all the pre-requisites on your client PC.  This takes several minutes to run so be patient – it should tell you why HDX is not working if it still mysteriously is not.


HDX MediaStream for Flash on XenApp 6

HDX MediaStream for Flash (let’s just call it HDX, okay?) is a very good recent feature of XenApp.  It crept into XenApp 5 in the second and third feature packs and is installed by default in XenApp 6.

And its quite cool – well, most of the time.  Essentially it offloads the processing of Flash content from the server to the client when using a Citrix distributed copy of Internet Explorer.  The result is that the playback on the client PC is noticeably better than without it in most cases.  It also hammers the CPU of the client PC instead of the CPU on the server so should improve the user experience for everyone else too and help get more users per server.

Despite being installed by default in modern clients and on XenApp 6 servers there are a few things that might trip it up.  If any of these occur the client will generally silently fall back on the standard way of processing Flash content on the server.

For HDX Flash processing to work all these must be true:

Server Side Requirements for HDX

  • The components must be installed on the server.  They are in by default but can be removed.  If you need to re-install them, get them from the “HDX MediaStream for Flash\X64” folder on the XenApp 6 media. 
  • HDX can be blocked by policy on the server.  To check this, open your XenApp 6 admin tools (the DSC in its current name!).  Click Policies and edit the computer policy that applies to your server – Unfiltered if you have configured no other ones.  Under ICA > Multimedia find the HDX MediaStream Multimedia Acceleration policy.  If unconfigured, this will be on.


  • The Flash 10.1 client must be installed on the XenApp 6 server.  This is true even if you are streaming IE plug-ins I’m afraid – it needs to be installed “properly”.

Client Side Requirements for HDX

  • The Flash 10.1 client needs to be installed on the Client PCs as well – all of them.  Without it, HDX will not do anything.
  • Your Online plug-in version must be at least v11.2
  • As well as the client being up to date, it needs to have been installed with the right switches to include the “Flash” element.  If you just installed with no defaults you should be fine, but if you installed with switches then you need to include the Flash switch.  The easiest way to find if your client should work is to look for the file “PseudoContainer.exe” in the Citrix client install directory.  This is C:\Program Files\Citrix\ICA Client by default (in the x86 version on 64-bit clients).  If PseudoContainer.exe is not on your system HDX will not work.
  • The client must confirm that HDX can execute.  See below for an alternative, but by default the user will get the following prompt when trying to access flash content for the first time in a session:


Turning on HDX by default on Client PCs

An alternative to that rather rubbish box (which is, to be fair, useful when testing to easily determine whether HDX is improving your user experience) is to use group policy on your client PCs.  On a PC which has the right client installed (so, it has a PseudoContainer.exe file), look for this file:

C:\Program Files\Citrix\ICA Client\Configuration\en\HdxFlash-Client.adm

Import into the computer group policy for your desktop PCs using Group Policy Management.  Edit the policy settings at Computer configuration > Administrative Templates > Classic Administrative Templates > HDX MediaStream For Flash – Client


Change the top setting to be Enabled and “Always”


Friday, 3 September 2010

Installing Merchandising Server 2.0

Merchandising Server is a fairly recent addition to the XenApp suite and one which I have held off implementing a while, for a couple of reasons.  The first is that frankly, I have enough XenApp servers now thanks very much, and the second is that its use in life appears to be limited to supporting the Windows and Mac editions of the Citrix Receiver.

We have a big implementation of the Agent which works very nicely so I had no need for the Receiver, so no need for the Merchandising Server.

But then the newly released HDX Experience Monitor for XenApp only supports the Receiver and I need that, so here we go.

By the way, here’s the Citrix eDocs site for Merchandising Server:

Downloading the Merchandising Server

The Merchandising Server is unusual in that it comes as a XenServer or VMware exported VM.  The VM is actually a 1GB CentOS 5 machine which comes all ready to configure, so the process can be over remarkably fast.  I started with little idea what I was doing at about 9am and had a working system before lunch, hopefully these notes will help someone get it done a bit faster. 

These download links will require a valid logon to My Citrix.

XenServer download:

VMware download:

The main server download is a “bz2” file – 7zip should be able to extract this for you, its about 4gb extracted. There is also a plug-ins ZIP file which is worth downloading, though not essential.

I’m assuming here that you have a XenServer machine – mine is a slightly old XenServer 5.5 server so all the instructions are for the XenServer edition, I doubt the VMware edition is much different.

Importing the VM into XenServer

Firstly, setup your XenServer machine and XenCenter client tools on your workstation, if you don’t have these.  Your XenServer host will need 1gb of spare memory and 20GB spare storage. 

Right click your XenServer in XenCenter, Import VM:


Browse to the extracted xva file and click Next


Click Next and Import to select the host and storage repository.  Select the networking – link it to your real network.  It won’t use DHCP, so until you give it an IP it won’t do anything.

Click the Logs tab in XenServer to import:


At this point I have had the unhelpful message “This file could not be imported”.  I downloaded the whole file again and extracted it with 7zip instead of WinRAR, then I imported it again using locally installed XenCenter tools and a Console session, rather than XenApp streamed tools in an RDP session.  I don’t know which of these steps fixed it, but it imported fine the second time. 

A successful import should take about 10 minutes.

Once the server is imported it should start automatically by default.

Select your Server in XenCenter and click the Console tab to view its setup functions

Configuring the Merchandising Server’s Network Configuration

You will need to know the Hostname you want to use for the server, and IP addresses for the server, its netmask, DNS server IPs and the gateway IP to get the server working.  You should now see the following screen in your Console window:


Click 1 and enter a hostname and domain, then follow the menu through to steps 2-5 to complete the rest of the networking.  When you’re done, press 9 to save the changes:


Type yes to confirm, then enter a new root password.  The system will reboot and return to the menu

To finish this section, update the XenServer tools while you have chance.  Click the DVD Drive drop down menu and select xs-tools.iso.  In the rebooted server’s Console window, select 8 for Diagnostics.  You will now see these options:


Select 3 and press y to start the upgrade – this will cause one last server reboot.  In the Search tab of your XenServer’s host you should now see CPU and memory usage for the new guest OS.


You are done with XenCenter now and can close it.  The rest of the config is in the web interface.

Configuring the Merchandising Server

Before you can use the web interface, you may need to configure the DNS record to point to the IP that you have the server.  Pick something friendly as the DNS name as this could be something you’ll expect users to remember.  Mine is called “xenmerchant”

You will get a certificate error as it starts with a self signed certificate with less than a month left to run:


After accepting the certificate you get put into the default download page.  You don’t want this, so remove the download part of the URL – you want http://servername/appliance

You should now get this:


Username: root

Password: C1trix321

Once logged in click Change Root Password first – enter a decent password.


Working up the menu, click Configure AD


Fill this in, using a service account on your Active Directory that has a non-expiring password.  This should be a non admin user and only needs to be a member of Domain Users.  These are some example settings – obviously, change your source name to a domain controller, the Bind DN and Bind Password to your non admin user and Base DN to the Distinguished Name of your domain. 


Click Save and Sync.  The Sync will take a few minutes and you might need to wait for it to complete.


Click Permissions and enter your administrators name (your name?), then click Search.  Select yourself and click Edit.  Give yourself Administrator privilege and Click Save.  Set up any other admins you need.

Click Log off and Log in again with your domain username and password.  Your username should be in the form DOMAIN\username.

You finally see all the options and it should look like this:


Adding plug-ins

Merchandising Server appears to be basically a mechanism to get a real Citrix client to your users, and so it doesn’t do much without any plug-ins.  You can download clients directly from the Citrix site (although of course you can only really get the latest client from the Citrix site itself).  If you do this, remember to get the metadata file too.

Once you have the XML and executable file for the plug-in, click Upload in the plug-ins section and select them.  You should not normally have to change the metadata (though you can).  Once the upload is complete it will be present in Uploaded Plug-ins.  Don’t worry about the fact you have not configured the client yet – you will configure the essentials later.

Otherwise, just click Get New under the plug-ins section.  It should detect the available plug-ins and download them – assuming it understands your internet connection.  Personally, my proxy server foiled it.

Creating Rules and a Delivery

Now you have a plug-in uploaded to the server, its ready to be able to deploy it. 

Click Rules under Deliveries.


You might have lots of rules here – of course you might not care who downloads clients from your server and might just put in one very permissive rule.  In my case I only care that the PCs are domain computers, so I just selected Computer Domain Membership.  You might want to create rules for specific groups of users of operating systems, such as Mac users.

Click Save

Click Create / Edit to set up a Delivery.


Enter sensible values for this – have a think about the Completion Text, the users will see it!

Click the Plug-ins tab at the top and click Add to select the plug-in that you want to distribute.  Note this can be a delivery to Uninstall a client as well as Install it.

Click the Configuration tab – this will look different depending on what was in the Metadata file for the client you just selected.  In the case of my Online plug-in, it asks me to supply the Web Interface Server URL.  This field is required.

Click Rules and select one of the Rules you created earlier.  Note if you checked the Default Delivery button on the first page, this page doesn’t do anything.

Click the Schedule tab and then button and if you are happy to save it without scheduling it for a specific time.

Using the server

That’s the easy bit.  Go to the website from a PC and enter the DNS name you created earlier.


Agree to the Terms of Use and click Download to start the installation of the Receiver.  This will require Firefox 2 or IE7, .NET Framework 2 and local admin rights – at least for the install.  After installation the Receiver will be able to keep the clients up to take based on the rules and deliveries you specify.