In the earlier article series Failover (im)possibilities I wrote about the failover/load balancing possibilities in XenDesktop 7.x, where part 3 was about what is available in XenDesktop 7.7. In this article I will discuss the XenDesktop 7.9 release (and corresponding the 7.8 release when this applies) and will also go into a bit more detail what is expected in future releases (where possible).

In the second part I shared the scripts and RES One Automation Building Blocks to install unattended a PVS based XenDesktop 7.6 Server VDA. In part 1 the scripts for the Delivery Controller were shared. In this part three article I will show/share the unattended scripts for StoreFront and Director.

In part 1 I shared my unattended script for installing the Citrix XenDesktop Delivery Controller component including a small script to join an existing XenDesktop site. In this article I will share my scripts for the Virtual Desktop Agent (VDA) including the PVS Target Device software, VDA Optimization and Default User Profile Optimization. Those scripts are also available as a RES One Automation Building Block.

As many people already stated it’s important that you automate repeating tasks as much as possible. Therefore I already published articles in which I shared scripts to install unattended Citrix products like Citrix XenApp 6.5 and Citrix Provisioning Services 6.1. With the release of XenDesktop 7.x I see a shift that only the VDA component is installed unattended and most times the Delivery Controller, StoreFront are installed manually. Also several people already published blogs about the (basic) silent parameters of the XenDesktop installation. So you can wonder why I’m also publishing the scripts. Mainly because I also added additional installation checks including additional hotfixes and updates. I also have RES One Automation blocks available for the installation part of the VDA (including PVS Target Device software) and that part is not yet (much) available in other posts.

In the earlier article series Failover (im)possibilities I wrote down how fail-over could be done in the past (aka as the XenXApp 6.5 era), how it’s currently can be done (and what’s missing in comparison with the past) in XenDesktop 7.5/7.6, the near future based on current available Technology Previews (XenDesktop 7.7) and enhancements that Citrix could make in our vision. On 28 December 2015 Citrix released the XenDesktop/XenApp release. In this article I’m taking a look if the features available in the used Technology Preview are available/implemented as expected. Secondly I’m describing the (im)possibilities of the Zones feature that was mentioned about a month ago, which was not available in the (public) Technology Previews.

In this article series I’m describing the Failover possibilities within the XenDesktop product based on the server components. In part 1 <<LINK>> I started explaining shortly the differences between Load Balance and Fault Tolerance, followed to mention that one is none for the components. For each component at least two machines should hold the functionality. As the article is about (disaster) failover in the case of two or more datacenters the article continued quickly describing the component, where the past, the current situation, the near future and wishes per component are described. In part 1 the database and the access portal were discussed. In this article I will continue with the Published App/Desktops (aka VDAs) and the PVS infrastructure.

In the first part article I started describing the steps to select a monitor solution for a SBC/VDI infrastructure. In that first part I described the first two steps. The first step is determine the actual information needs, which leads to a wish list. This wishes are categorized on importance based on the MoSCoW principle. After all wishes are known step 2 can be done, checking if there is already a product and/or functionality is available within the organization that can fulfill the wishes. If a product is available you can stop the selection process and focus on implementing/improving the product or functionality already available. If the outcome is that additional tooling is required we can continue with step 3, which is actually the start of this second part.

Multi faction authentication (nowadays multifactor authentication) is becoming majority in the upcoming years. One of my favorite product is SMS Passcode, which is on the market for years. SMS Passcode offers multi factor authentication for a big range of available products/solutions in the market. Besides it is really easy to implement, within a few hours the environment is up and running. The default delivering method is sending a SMS via your own GSM modems. However within several datacenters the connection of GSM modem is difficult. Therefore SMS Passcode has the possibility to use an external SMS provider an alternative. However when you the companies offering a Desktop/Application as a Service the cost of the SMS (both with GSM model as SMS service provider) can be a bottleneck as the users don’t belong to the same organization (and cannot have a company subscription). However for this challenge SMS Passcode has a solution together with Acision (formerly named as MindMatics). In this article I will describe the solution and how to configure it.

At one of my customers there were needs for additional insights in their Citrix XenApp infrastructures. I was assigned the task to do a research of products that could fulfill the gap they currently have. When I just got this assignment I was wondering how I should start with this task. After I came up with the plan I thought it would be nice to write it down in an article series. The article series will exist of two components. The first article(s) will describe the process and the used techniques/methods and my experiences of selecting a monitor solution for SBC/VDI infrastructures (personally I think this can be used for almost any product selection, but that’s up to you). The second component will exists of providing more information of three products, which I have looked at more in-depth during this assignment. In this part 1 I will start with describing the first components about the process, methods and experiences, which I have divided in five steps.

In this article (series) I will describe and discuss the PVS components you should consider when creating a PVS design. In part 1 I discussed a PVS Farm, Site, Device Collection, View, Store, Database and Load Balancing. In the second part I will continue describe design consideration for PVS components.

At one of my customers we build a XenApp 6.5 environment, where the XenApp Session Hosts were running on local storage of the Hypervisor (VMware ESX 5.5). At this customer the hypervisor and Citrix XenApp were maintained by separate teams. The hypervisor team was used to use shared storage and the vMotion capabilities of ESX for their maintenance tasks on the ESX host during daily operations. However now the virtual machines were running local storage this technique could not be used anymore and the hypervisor team found it difficult to fulfill their maintenance tasks.

After some discussion we agreed that the process should be as easy as possible (without less inference of the XenApp team) and that it should be possible to do the maintenance during daily operations. The first step was adding additional capacity, so maintenance during the business hours was possible. Secondly I wrote a set of small simple scripts that the maintenance can be done without less interaction between the teams and user impact is minimal. In this article I would like to share those scripts with you including explaining what they are doing.

Updated on 22 December 2015 with some small adjustments (removing old files and wait timeout to check if the server is online again)

Some years ago I already published a reboot script for XenApp 6.5. Also Citrix did a good job to make the reboot possibilities within the Citrix policies more flexible and robust. The only real disadvantage is the possibility to disable the logon possibilities 60 minutes before the real actual reboot take place. However this can be overwritten using a specific registry key, which is not well known or documented (HKLM\Software\Policies\Citrix\IMA\Restart Options\Disable Logons\RebootDisableLogonMinutes. When migrating from XenApp 6.5 to XenApp/ XenDesktop 7.x you will probably be a bit disappointed. In this article I will starting describe the reboot possibilities in XenApp/XenDesktop 7.x out of the box, followed by explaining a script that I have written to satisfy more requirements.

Every product has his oddities, which can be time consuming if you are not familiar with those characteristics of the product. Also XenApp 6.5 has some of those characteristics which are not well-known or not documented well in the Citrix documentation or specific situations I have encountered at customers environment. In this article I will write down situations encountered at XenApp implementations at customers including a solution, work around or the way you should work with it.

Just as almost every product and solution PVs can be set-up and configured so the PVS infrastructure is high available. Within the PVS infrastructure there are several components related to the High Availability of PVS. Some of these components like PXE and TFTP are well described in several good articles for creating a High Available solution. However within the PVS infrastructure there are also some components/configurations settings that are not much mentioned around the HA topic, but can have a big impact on the High Availability of your PVS infrastructure. In this article I’m going to describe which components should be taken into account, why and how you could/should use them in a High Available PVS infrastructure.

In the article series Unattended Installation Citrix Provisioning Services I already touched the PowerShell possibilities of PVS showing how to configure farm and server settings via PowerShell. In the same project I already wrote some additional PowerShell scripts to partly automate some tasks within the PVS infrastructure, so no mistakes could be made. Although they are not rocket science I decided to share them, as some commands are not fully obvious when reading the PowerShell Guide.