For one of my customers I needed to set-up a Citrix FAS environment for using SAML authentication to achieve a single username and password (and providing this information once). To verify that the goals would be reached I first set-up Citrix FAS into my own (demo)environment, followed by a production environment on the customer infrastructure. I did this based on instructions created by fellows in the Citrix community and logically the Citrix documentation. In this article I’m not going to create another configuration article as those are already available. I will point you to these articles and share in this article tips and tricks of occasions I encountered. Most are already available somewhere on the Internet, but it is scattered and not always issue to found.

As a consultant I’m mostly engaged at the larger companies (large for the Dutch market) the Citrix Cloud was not come along my path a lot. Logically I followed the progress and enhancements made to the services. Recently I got involved at a smaller customer with currently did not have a Citrix environment yet (the party they acquired are using Citrix, so that’s why Citrix came into play). A perfect fit for Citrix Cloud as the environment is pretty small and the IT organization is not really familiar with Citrix. As size does not matter, the organization had to comply with specific regulations that are similar as Enterprise organizations.  However during the design phase and Proof of Concept phase we found out that there are still gaps between the on-premises and the cloud offering, that could cause that the Citrix Cloud solution is not ready yet for all/your organization(s).

In the earlier articles I wrote down how to install unattended the XenDesktop components. The article was based on the versions of XenDesktop 7.6 till XenDesktop 7.15 (dependent of the article).

It has been a while that I updated this article series. In this (small) article I will describe the uninstallation options for the most current version out there 7.15 CU2 and 7.18 (CR).

In the second part  we discussed the steps under the hood for each MCS deployment type when creation the machine catalog, when VDAs are added and what happens when the user session is ended. In this part we will continue with the steps when updates are required on the base disk and more detailed information about the configuration settings during the Machine Catalog wizard.

In the first part article we discussed the first steps for creating and maintaining Citrix Machine Creation Services (MCS). We talked quickly about creating the master image, followed by the available MCS deployment type with their characteristics. In this article we will discuss what happens under the hood when creating a MCS machine catalog per deployment type.

Citrix Machine Creation Services (MCS) is already available for a pretty long time. Developed as an alternative for Citrix Provisioning Services (and a reaction to VMware Linked Clones). A topic for discussion between the MCS proponents and the PVS proponents. Loved by the easiness to use it, however also not much documentation available about it (because of the easiness??). In this article I would try to demystify Machine Creation Service, based on practical experiences with (troubleshooting) MCS at a customer.

Probably most people would say this is no brainer and actually it is. Of course the type of disks used for your VDI infrastructure matter for the user experience and performance of VDIs. In this article I will do a walk-through of a PoC where we have been required to investigate the impact of the disk performance on a VDI infrastructure.

XenServer is primarily being used as a hypervisor platform for XenDesktop VDIs. Although the installation of XenServer 7 is not really difficult it would be nice when installing multiple XenServer hosts that you can automate the installation part. In this article I will describe the possibilities of creating an (almost) unattended installation of XenServer 7.x I will both touch XenServer 7.0 (which we made of a customer. Long story about certification processes of software being used) and the latest version 7.2 (which also applies to 7.1).

In the earlier articles I wrote down how to install unattended the XenDesktop components. The article was based on the versions of XenDesktop 7.6 till XenDesktop 7.13 (dependent of the article). Currently Citrix is releasing every quarter a new version, so it’s time to update the articles with the new installation information of later release(s) based on XenDesktop/XenApp 7.14 and XenDesktop/XenApp 7.15.

In the earlier article series Failover (im)possibilities I wrote about the failover/load balancing possibilities in XenDesktop 7.x, where part 5 was about Desktop 7.12. In this article I will discuss the XenDesktop 7.13 and 7.14 release and will also go into a bit more detail what is expected in future releases (where possible).

At almost every project start one of the first questions how many users the environment can handle or how many hardware should be ordered so all users have a good user experience. It is probably the most difficult to answer at the start of a project. Probably if you give the right answer, which is it depends, you will get the question you have experiences in other organizations and aren’t there benchmarks or best practices available. In this article I will try to explain my vision that you cannot determine this at the start of the project, based on my practical experiences at several projects.

With the release of Citrix XenDesktop/XenApp (I will use XenDesktop for the further article) 7.6 FP3 Citrix introduced the Long Term Service Release (LTSR) and the Current Release (CR) lifecycles. Now we are sometime further it is good to take a look how this introduction involved and what should be considered for choosing one of the release cycles. In this article I will start describing what both releases actually means and provides the point that you should consider for choosing which release cycle for you organization.

In the earlier articles I wrote down how to install unattended the XenDesktop components. The article was based on the versions of XenDesktop 7.6 till XenDesktop 7.11 (dependent of the article). Currently Citrix is releasing every quarter a new version, so it’s time to update the articles with the new installation information of later release(s) based on XenDesktop/XenApp 7.12 and XenDesktop/XenApp 7.13.

At one of my projects we were discussing the high level design decisions and one of the discussion topics were setting-up the Delivery Controllers high available and redundant. During the talk we discussed the necessity of using Load Balancer appliances in front of the Delivery Controller. Based on that talk I thought it was a good idea to write an article about this topic including my opinion.

Logically we need to start which communication streams are being used to the Delivery Controllers which should be taken into account. Communicating to the delivery controller has three communication streams.

• Virtual Delivery Agent (VDA) communication

• StoreFront communication Application enumeration/ICA file creation (XML broker)

• NetScaler (and StoreFront) STA communication

Let’s dig deeper in each communication stream.

In the earlier article series Failover (im)possibilities I wrote about the failover/load balancing possibilities in XenDesktop 7.x, where part 5 was about Desktop 7.11. In this article I will discuss the XenDesktop 7.12 release and will also go into a bit more detail what is expected in future releases (where possible).