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.

Introduction

In part 3 of the article series we started looking at boot(storm) scenarios. I described the four scenarios and the environment. Also the results of the first two scenario were discussed. In this last part I will continue with the remaining boot(storm) scenarios and will compare the results of the boot scenarios with the Citrix theory.

In this article series I will go into detail about resource usage of PVS servers. In the first part I described the theory values Citrix is using/advising for the components CPU, Memory, Disk and Network. The article series continued with taking a look at the real life resource usage of PVS servers. In this part we will take a look at resource usage of the PVS servers during boot(storm) scenarios.

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.

In this article series I will go into detail about resource usage of PVS servers. In the first part I described the theory values Citrix is using/advising for the components CPU, Memory, Disk and Network. Also physical versus virtual is touched briefly. The article series will continue with taking a look at the real life resource usage of PVS servers. In this part we will take a look at the resource usage during daily operations.

In almost every current XenDesktop/XenApp project for a specific period some applications are not available on the new platform, which are required by a group of users. A decision could be to let those workers do their work on the current/old platform. However most organizations don’t want that because the users don’t have access to new technologies of versions of other applications. In most cased the customer is looking for a way to offer access to those applications within the new platform. In this article I described the possible access methods to those applications running on a legacy environment, followed by the technical options to provide the access (including the advantages and disadvantages).

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.