In Access Gateway I have two session policies bound to the Access Gateway Virtual Server.  One session policy is for the Citrix Receiver and the other session policy is for Web Interface ICA/HDX access only.   No issues with connecting to the environment using the Citrix Receiver or Web Interface ICA/HDX access only.  I recently enabled the option to use VPN or Web Interface ICA/HDX access with Client Choices by using AAA Groups with a session policy in Access Gateway for testing.  VPN and Web Interface ICA/HDX access worked fine but I could not logon using the Citrix Receiver.  I tested the Citrix Receiver from the iPad and Android mobile devices.  See the screenshots below for the different errors on each device.

Citrix Receiver error on the iPad.

Citrix Receiver error on Android.

After reviewing my configuration, a session policy conflict was found between the Citrix Receiver session policy bound to the Access Gateway Virtual Server and a session policy bound to an AAA Group.  The session policies both had the same priority of 0.  See the screenshots below for the Access Gateway Virtual Server and AAA Group session policies configurations.

Access Gateway Virtual Server session policies.

Access Gateway AAA Group session policy.

After some configuration changes and testing, there are two ways to fix the issue.  One option is to make the AAA Group session policy a lower priority by giving it a higher priority number than the Access Gateway Virtual Server Citrix Receiver session policy.  The other option is to configure the AAA Group session policy with a policy expression of REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver.  See the screenshots below for the AAA Group session policies configuration options.

AAA Group lower priority session policy

AAA Group policy expression session policy

By using either of the options above for the AAA Group session policy, you should now be able to connect using the Citrix Receiver without any errors.  I wish Access Gateway had a resultant set of policy tool like XenApp and XenDesktop has.

• Anonymous Deliveries – This fixed one issue I had with users getting the Citrix Receiver logon prompt after pushing the Receiver via script, SCCM, etc.  There was a workaround for it, but you had to revert back to an older Citrix Receiver client.  This new feature allows you to deploy the Citrix Receiver without having a user logon.  Instead a system token is used.  Nice feature for deploying the Citrix Receiver to managed machines without prompting for credentials after the install, machines outside of your domain, or unmanaged devices like BYOC.
• Enhanced Roaming – Improves the roaming for Citrix Receiver by using beacon websites to avoid users getting authentication messages.
• Improved Usability – Improved error reporting and improved reporting for Active Directory syncing.  This is another nice new feature.  I have had issues with the Merchandising Server for VMware losing sync with Active Directory.  Hopefully this improved logging gives more insight into what’s going on.
• Receiver for Windows 2.0 Packager – Allows use of an external download page to download and install the Citrix Receiver with the secure access plug-in.  Windows and Mac Receivers are included in the download.
• Receiver for Admins – Receiver package that can be installed separate of the Merchandising Server but only works with the Merchandising Server 2.0. 

I really like the Merchandising Server and Receiver.  I like how I can centrally manage and deploy Citrix plug-ins as well as the Microsoft App-V plug-in based on different rules and deliveries.  I am starting to use the Merchandising Server and Receiver on deployments more and more.  Installing the Receiver and deploying the plug-ins makes Citrix client management easy.   

Where I see the Merchandising Server needs room for improvement are secure LDAP authentication, backup/recovery/failover, and SSL certificate support on the administration functions.  Also where is a Merchandising Server for Hyper-V download? 

Currently the Merchandising Server does only does LDAP authentication insecurely.  So what if you are using the Merchandising Server in a secure environment or putting the virtual appliance in the DMZ?  The Merchandising Server needs this feature for deployment in secure environments and when being placed in the DMZ.   

Right now the only backup/recovery of the Merchandising Server appliance is thru hypervisor snapshots/backup.  What if the something gets corrupt though?  Where is the export/import configuration feature?  Like others I have had issues with the Merchandising Server for VMware.  After working with Citrix support on some of the issues I was experiencing with Merchandising Server for VMware (locking up, losing AD sync, and/or not boot properly) it was found that there was an issue with the earlier build of the Merchandising Server for VMware when it was first released.  My only option was to download the appliance again and start from scratch.  So if there is an issue with the build, how would a snapshot/backup on the hypervisor side help with that?  At a minimum Merchandising Server needs an export/import configuration feature.  I have submitted this as a feature request so hopefully this gets added in a future Merchandising Server release.

So what about high availability?  High availability is not so critical since existing users will be unaffected since Receiver plug-ins that have already been deployed before the Merchandising Server went down will work fine but Receiver plug-ins updates can’t be deployed.  While the Merchandising Server is down new users can’t download the Citrix Receiver and plug-ins.  Now the nice thing about Merchandising Server 2.0 is that the token for anonymous deliveries can be copied to another Merchandising Server.  This could possibly be a secondary, standby, or backup Merchandising Server.  All you have to do is copy and paste the token from one appliance to another.  Make sure you keep your token documented somewhere just incase your Merchandising Server has issues and you have to start over.  What would be a nicer feature above that would be maybe some kind of sync between two Merchandising Servers.  Maybe an active/passive setup with failover that keeps all settings/configuration, downloaded plug-ins, and token in sync.

Only 1024 bit SSL certificates are supported on the 2.0 release.  This means you can only create a certificate request from the Merchandising Server in 1024 bit.  The documentation is a little misleading because it states only 1024 bit SSL certificates are supported.  The issue with this is that SSL CA vendors are starting to no longer sell 1024 bit SSL certificates, only 2048 bit and higher since 1024 bit SSL certificates will not be supported after 2010.  So I called Citrix support to talk about this and even though the documentation says 1024 bit support only, you can create a 2048  bit SSL certificate on another machine and import it into the Merchandising Server.  I used an IIS 7 box to create the certificate request, exported it to a PFX file, converted the PFX file to PEM format, and uploaded it to the Merchandising Server appliance.  Hopefully in the next release of Merchandising Server this will be addressed.  Now if you are using an internal CA like Microsoft Certificate Services this is not a big issue unless you are also managing the Receiver and plug-ins on machines that are not domain members and/or external to your network.  Managing and deploying internal CA root certificates can be a pain in that scenario.

Hyper-V support.  Why isn’t there just a download for Merchandising Server for Hyper-V?  Why do I have to convert the Merchandising Server for XenServer to Hyper-V?  There were instructions for this on the Citrix Blogs but has been taken down.  The instructions are posted at Enabling Citrix Merchandising Server paravirtualized vm to run on Hyper-V.  Converting the Merchandising Server for XenServer to Hyper-V is unsupported.  So if you have any issues after converting the XenServer virtual appliance to Hyper-V you are on your own. 

Where I see the Receiver needs room for improvement on the user experience side is authentication.  The issue with getting a Citrix Receiver logon prompt after a push install  via script, SCCM, etc in 1.2 was a pain.  Why can’t the Receiver have pass thru authentication like the XenApp online plug-in has?  The option to have pass thru authentication for devices with domain membership along with the prompt and anonymous/system token authentication for devices without domain membership is needed.  The same goes for the Dazzle plug-in.  This would probably take some Citrix XML integration/communication like the Web Interface has.  On second thought why not just combine Merchandising Server and Web Interface into a single virtual appliance?  Manage client plug-ins and user interfaces from a single instance.  On the other hand I guess authentication could be a use case for Password Manager/Single Sign-on if the customer has Platinum licensing but what if they don’t?

If you are configuring the Receiver for anonymous deliveries with a system token, the Receiver can’t be downloaded and installed from the Merchandising Server.  It has to installed by script, SCCM, etc.  The XenAppBlog has a very good blog post on how to do this.  See How to deploy Citrix Receiver for logon information after .mSI install.

Like I said above I really like the Merchandising Server and Receiver.  I like the improvements in version 2.0.  I hope Citrix keeps making the Merchandising Server and Receiver better.  I really hope a supported Merchandising Server for Hyper-V is released along with an export/import configuration, secure LDAP authentication, 2048 bit SSL support, and pass thru authentication for the Receiver in a future release.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.

XenApp

• A version of XenApp that runs on Windows Server 2008 R2
• One console only, at least for XenApp
• PowerShell SDK for managing XenApp
• Realtime audio/video so that, for example, Microsoft Office Communication Server can be used well
• Migration tool that exports an old farm’s settings and imports them after optional transformation into a new far
• Consistent feature set among the XenApp versions (2003 / 2008 / 2008 R2)
  • Special folder redirection, power management, HDX Flash, etc
• A revamped Installation Manager on Windows 2008
• Report Center in Access Management Console/Delivery Services Console that links to EdgeSight/pull reports from XenApp management console
• XenApp Setup Wizard similar to XenDesktop Setup Wizard
• Integration with hypervisors similar to XenDesktop power on, power off, reboot, etc
• Folder inheritance of published applications in a folder- add a new server to a folder in the console and have applications automatically published on that server that are published to other servers in that folder
• Content redirection/file type association between seamless hosted and seamless streamed applications

Support for XenApp in SCCM (Microsoft System Center Configuration Manager)

• XenApp collections
• Add application hosting information to SCCM package
• Autonomic server load management to allow SCCM software distribution

VM Hosted Apps

• Session sharing (multiple applications per session/VM)
• Real application publishin
• Integration in XenApp management console

XenClient

• Release a first version, if only for enterprise volume laptops initially
• Make it run on any system that supports VT-D and TXT (trusted execution technology)
• Provide a private image mode: copy a VM to a client initially and then sync back differentially by creating snapshots that are stored on a server. A user would “own” a VM in this scenario and could store data and install applications in it, but updates/application installs could not be easily centrally managed.
• Provide a shared image mode: copy a VM to a client initially that is reset to its original state when powering off. Provide a second disk (VHD file) for persistent user data. In this scenario, users could not install applications, since the OS VHD gets reset constantly, but administrators could manage updates to the OS VHD centrally by distributing snapshots containing new applications or patches to the clients. All user data would have to be stored on a second partition.
• Optionally encrypt VHD files on the client (we are talking about laptops)
• Map the GPU to any VM. That way we could use a private VM (with GPU, for games, etc.) and a more secure business VM.
• Run applications from one VM seamlessly in the other VM (over ICA)

XenDesktop

• Make HDX media stream for Flash optionally work in such a way that we do not need internet access in the client’s site. Stream Flash through ICA from the server to the client and only render it on the client.
• PowerShell SDK for managing all aspects for XenDesktop
• Merge the XenDesktop Setup Wizard into the “Create Desktop Group” Wizard
• Windows Server 2008 support

Provisioning Server

• Give us a tool for automating the management/patching of PVS images
• Make it run in one of three modes:
  • Monitoring: Monitor external ESD server to determine if updates have been assigned to a machine
  • Scheduled: Periodically start the VM and allow the machine to update itself
  • Manual: Admin initiates VM start/stop for manually updating
• Give the tool a PowerShell SDK so we can program it
• Easy way to upgrade virtualization tools (VMware Tools, XenTools, etc) and Provisioning Server Target Device of a vDisk
• Provisioning Services Database Replication and or Mirroring

XenServer

• VM-based snapshot and not disk-based snapshot
• Easy way to revert to taken snapshots
• Memory sharing / ballooning / over commitment (for VDI)
• Thin provisioning for block-based storage repositories
• Possibility to separate management and XenMotion network interface
• Advanced template management
  • Integration of Sysprep, possibility to change hostname, ip, etc
• Administrative Delegation
• Wake On LAN of XenServer VMs
• Move VMs/VDIs to storage repository without having to turn off VM and copy – Storage XenMotion

Workflow Studio

• More development/example workflows
• More integration with Citrix products – XenDesktop, etc

Various

• Release Branch Repeater as a virtual appliance. Better make it available for all three important hypervisors.
• Release a virtual appliance version of Access Gateway that can serve as a true replacement for CSG (Secure Gateway). For that, it needs to be free or very cheap at least. And better make it available for all three important hypervisors.
• Consistent management console for all versions of Access Gateway
• Citrix Receiver framework for the Mac and Linux platform
• Integration of all Citrix agents/clients/plug-ins into Merchandising Server
• NetScaler VPX virtual appliance for Hyper-V
• Merchandising Server virtual appliance for ESX

Please keep this wish list going.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.

Downloading and extracting the Merchandising Server virtual appliance

1. Logon to MyCitrix
2. Choose downloads and select Citrix Receiver
3. Click Merchandising Server 1.1 – Virtual Appliance
4. Click download next to Merchandising Server 1.1 and accept the End-User License Agreement to download the compressed virtual appliance package
5. Extract the compressed virtual appliance package.  You can extract it with Bzip2 from the command prompt: bzip2-105-x86-win32.exe -d citrix-merchandising-server-1.1.0.xva.bz2

Importing the Merchandising Server virtual appliance

1. From XenCenter right-click on your resource pool or XenServer host and select Import VM
2. On the Import Source screen click Browse to browse to the citrix-merchandising-server-1.1.0.xva file and click Open.
3. Make sure Exported VM is selected as the Import Type and click Next.
4. On the Home Server screen select the resource pool name to not designate and home server or select a server in the resource pool to designate a home server and click Next.
5. On the Storage screen select the storage repository for the virtual appliance and click Import.
6. On the Network screen select the interface and network for the virtual appliance and click Next.
7. On the Finish screen leave the check in the Start VM after Import and click Finish.
8. Wait for the import to finish and verify it completed successfully.

Updating the Merchandising Server virtual appliance XenServer tools

From the XenCenter console tab of the Merchandising Server virtual appliance virtual machine you can see Citrix Merchandising Server network configuration screen and menu.  There is an option to update the XenServer tools by typing 8 for Diagnostics and then 3 for XenTools upgrade.  After selecting those options for XenTools upgrade you will be presented with a warning screen about setting the DVD drive for the virtual machine to xs-tools.iso and that this will update XenTools and then reboot the system.  This actually does nothing.  See the screenshots below for the screens you will see. 

Since using the XenTools upgrade menu option from the Diagnostics menu didn’t work I had to upgrade the XenServer tools manually.  Follow the steps bellow to upgrade the XenServer tools manually.  This is done from the console tab of the Merchandising Server virtual appliance virtual machine in XenCenter.

1. Enter 1 to change the hostname of the Merchandising Server virtual appliance
2. Enter a new hostname
3. Enter 9 to save changes
4. Type yes to confirm updates and reboot the virtual appliance and make sure to change the password when it prompts you to
5. Make sure the xs-tools.iso is selected in the DVD drive for the Merchandising Server virtual appliance virtual machine
6. Enter 8 for the Diagnostics menu option
7. Enter 4 for Appliance Terminal menu option
8. Enter root for the username and then your password you changed in step 5
9. Use the commands below to update the XenServer tools from the appliance terminal, hit enter after each command, and restart the virtual machine after completion 

cd /mnt

mkdir xs-tools

mount /dev/xvdd /mnt/xs-tools – the following message is ok – mount: block device /dev/xvdd is write-protected, mounting read-only

cd /mnt/xs-tools/Linux

bash install.sh

y

See the screenshot below for an example of the commands above for updating the XenServer tools manually.

After rebooting you should be able to change the IP Address, Netmask, Gateway, and Domain Name System settings.  I had an issue after updating the XenServer tools where the IP Address, Netmask, and Gateway wouldn’t stay after rebooting the Merchandising Server virtual appliance virtual machine.  I had to change those network settings manually by editing ifcfg-eth0 in /etc/sysconfig/network-scripts using the Appliance Terminal option from the Diagnostics menu.  You can use the editor of your preference.  I used vi.

To edit ifcfg-eth0 do the following:

vi /etc/sysconfig/network-scripts/ifcfg-eth0

change BOOTPROTO=dhcp

to

BOOTPROTO=static

IPADDR=x.x.x.x

NETMASK=x.x.x.x

GATEWAY=x.x.x.x

Save the changes and reboot the Merchandising Server virtual appliance.  See the screenshots below for a before and after example of ifcfg-eth0.

You may also have to use the Citrix Merchandising Server Network Configuration menu to re-apply the Hostname and Domain Name System entries.  After doing so make sure save the changes and reboot the virtual appliance.  Now you should be able to setup and configure your Merchandising Server virtual appliance from the appliance web page.

There is also a Citrix blog post on converting the XenServer virtual appliance to use on Hyper-V.  See the Citrix blog post Merchandising Server on Hyper-V for the conversion process.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.