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.

When configuring Citrix Provisioning Services you will find the Advanced button within the properties of each PVS servers. There are pretty some settings available within this advanced part and when you are going to search for documentation you will find out that not much information is available about those settings, nor about what the setting is about or which value should be configured on which circumstances. When I was writing a detailed design I talked to several people and even those who changes the default values could not really explain why did choose the specific setting. I dived into this advanced settings and what I could find about these settings are written down in this article (as promised in the presentation PVS Design Decisions and Real Life Experiences).

In the previous Unattended Installation Citrix Provisioning Services articles I explained how PVS can be installed automated via scripts. In this part I’m going to describe some of the peculiarities I have encountered with the unattended installation of Citrix Provisioning Services.

Currently many VDI implementations are based on the so called persistent VDI methodology. The user gets a (virtualized) desktop in the data center, which is installed and configured (mainly) via the traditional available deployment systems. When I’m talking and discussing about Persistent VDI’s my alter-ego is banging against the door again. In this opinion article I will describe my vision why my alter-ego is coming back when talking about Persistent VDI.

In larger infrastructures there is already a monitor product available like HP Open View, Tivoli Monitoring and Microsoft System Operations Manager. Many Citrix administrators have a kind of love-hate relationship with such products. They provide lots of interesting information, but can be overwhelming and last but not least the required agent is not easy to install and/or stable. At one of my project the monitoring team was not confident that the agent of that product was suitable to install on the Citrix XenApp Session Host as those were provided by Citrix Provisioning Services (PVS). Logically we would like to have monitoring of these servers in place, so we needed to find a solution which can be used together with the monitor product. Finally the solution leads to a general way to monitor Citrix XenApp server without installing a monitor agent on the Citrix XenApp Session Host.

In the previous Unattended Installation Citrix Provisioning Services articles I explained how PVS can be installed automated via scripts. In most cases these articles are enough for most infrastructures. However if you would like to set-up more PVS environments it would be nice if could reuse the scripts and/or the answerfiles by making them variable. For one of my customers this was the case and I did that using PowerShell (their default scripting language). So actually this third part is more a PowerShell for dummies articles (I do not have much PowerShell knowledge, but this assignment showed me how powerful PowerShell is) than about the unattended installation but it gives a good insight in the possibilities.

With Citrix Provisioning Services the client (called target device) need to use “something” to connect to the PVS server to start the streaming process of the operating systems within the vDisk to target device. The default connection is using the PXE technique combined with TFTP, but Citrix also offers another technique called Boot Device Manager (BDM). In this article I will go both options using pros and cons (through my eyes) and how you can work around the cons (of both techniques). At the end I will give my vision which technique to use (in which scenarios).

Unattended installation of Front-End products like Citrix XenApp 6.5 or Windows 7 is really commodity nowadays. Unattended installations of back-end components are done less, which is actually logically. Such components are not installed in large amounts and are only executed once (per version). However more and more back-end components can be installed silently, mainly for the large enterprises. For such environments where the amounts of servers are higher, the efforts to set-up an unattended installation are worth doing those actions in comparison with manually install those servers. Citrix Provisioning Services (PVS) offers unattended installation and configuration and at one of my project we needed to install more than 10 Provisioning Services servers. This is definitely a use case to use the unattended possibilities of Citrix Provisioning Services. In this article I will explain how you can install Citrix Provisioning Services unattended including my experiences with it so far.

For the last years BYOD is a hot and trending topic, many many articles are writing about it. Actually if you search for my chosen title many article can be found, in which the answer to the question about BYOD will be there for a long(er) time.

As this is a 100% opinion article I will start with writing down the pros and cons of BYOD trough my eyes. Followed I will write down (again through my eyes) reasons why BYOD can be sees as a hype or a reality. Finally I will write down my vision of BYOD.

One of the remarks the RDS Team got out was the difficulties IT departments had was the installation of the RDS components. It was unclear which components were needed/required and where they should be installed. Because Microsoft is aiming with RDS is created on the low complexity environments, it will become more important to provide clear guidance of the installation steps. The RDS team reacted on this remark by adding a complete new feature within the installation part for creating RDS Deployment Scenarios. In this article I will describe those scenarios and how they can be implemented.

Although User Environment Management (UEM) becomes more and more important in almost every company it is getting easier to convince the IT people and management of purchasing the UEM. However there are still people who just see such a product as a logon script replacement, which can also be done using scripting or Group Policy Preferences. I’m not writing this article to discuss or argue about that statement as you can do actually a lot of the same configuration with scripts or Group Policy Preferences for the basic set-up like printer assignment, network mappings and so on. However UEM products offer much more other functionalities like Profile Management, E-mail management, Trouble Shooting tools, Performance Management and additional Security Management. This last one can be a real important added value for lot of companies, but is often not taken into account by the decision to use/purchase a UEM product. In this article I will focus on the security part showing/describing the features available in RES Workspace Manager 2012 (most of those features are also available in other UEM products as well) and provide you with use cases where those features were implemented and created an added value for that company.