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.

On one of my projects we are using Citrix Provisioning Services (PVS) for our XenApp 6.5 environment. At this project several teams are responsible for the different stages in the infrastructure (DTAP, Development, Test, Acceptance and Production).

After a while one of the guys of the test environment came to me asking me how and why we are using fixed IP addresses within the PVS image. I told me that this could not be the case as the design was written based on a DHCP based IP address and I was pretty sure that none of this colleagues in test has the knowledge available to configure fixed IP addresses within the possibilities PVS is offering. In this article I will start describing which documented options are available within PVS to use a fixes IP address within the PVS image, followed by showing the magic unknown feature in Citrix Provisioning Service the test colleague encountered accidently.

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).

In the first part article I explained the current infrastructure and the requirements the organization had for the new environment, while I started describing the project using the biggest discussion points in the second article and third article. In this fourth and last article I will describe the latest discussion points (SSL Gateway and Outbound Connections) and the experiences so far.