In previous posts I, have already provided instructions and building blocks to automate the deployment of Citrix StoreFront and the XenDesktop Delivery Controller. While the automation of the deployment of Citrix Director is still in the planning stages, someone requested a building block for the deployment of the Citrix Virtual Delivery Agent. I started looking around other Ivanti/RES ONE Automation resources and I noticed that there isn’t much available. Sure, the unattended deployment is described very well in the Citrix Product Documentation. But ROA/IA building blocks for VDA deployment aren’t too common. Reason enough for me to create them.
I will give a small walkthrough of the automation steps and why I made certain decisions and of course instructions on how to import and use them. You can find the download link for the Ivanti/RES ONE Automation building block at the bottom of this blog post.
These modules have been tested on Windows Server 2016 and Windows 10 Enterprise (version 1703) and you can use the same module for the Desktop OS installation of the VDA and the Server OS installation.
Edit March 1st 2018:
The module has been tested with the Virtual Delivery Agent of Citrix XenDesktop 7.17 and Ivanti Automation 10.2.100.0 and works accordingly. The /enable_hdx_3d_pro switch is deprecated since 7.16 and is no longer a selected option by default in the module. However, I have kept it in to keep the module compatible with older 7.x versions (like the 7.15 LTSR version for example).
Edit January 30th 2019:
I have created a new version with the new switches/features of the Citrix Virtual Apps and Desktops version 1811 Virtual Delivery Agent as described in the docs page: Link
Building block is available for download below along with the old version.
Import the downloaded Ivanti/RES ONE Automation building block. When your datastore is using the new AES-256 encryption (ROA v10.1 and newer) it will ask you to specify the passkey of the building block. I have included this in a separate text file in the ZIP. If you don’t use this encryption you can just import it.
When it’s imported you need to change the following (global) variables in your Automation deployment:
Credentials for the account that will be used for software installation
Installation Account username
Username for the account that will be used for software installation
Installation Account password
Password for the account that will be used for software installation
Your software share, for which the installation account should have the appropriate rights
(And yes, there are three variables for the Installation Account. One for the complete credentials, one for just the username and one for the password.)
After that you can start scheduling. I have tried to add all the possible options and switches (let me know if I have forgotten anything). So when you schedule it, it will ask you to specify the following parameters:
Fill everything in to your liking. I have not tried every combination but the ones I did try worked accordingly. Just two remarks about them:
1. When excluding certain components, make sure you deselect the top ‘No exclusions’ checkbox.
2. When specifically including certain components, make sure you you deselect the top ‘No specific inclusions’ checkbox.
3. The VDATempLocations uses the /tempdir option of the VDA installation. I have tried this one multiple times but it doesn’t seem to do much. Temp files are still being placed at the regular temp location of the Windows system.
So add one or two delivery controllers, select if you want the VDA and/or Citrix Receiver, select the options, provide alternate install and logging locations if you wish, select the Automation agents and you are ready to go.
Like I have mentioned before: You can use this for the Server OS VDA’s and the Desktop OS VDA’s. It will install the VDA that matches your OS. If you want a Desktop OS VDA on a Server OS you can enable the servervdi option.
You might notice that the job will use a interactive logon on the target to install the VDA. I have not gotten it to work without it. It seems it wants to put some keys in your HKEY_CURRENT_USER hive and these are not available if you don’t run in interactively. The result is a half-installed VDA.
Try the deployment if you like and let me know if you have any problems.
Next on my list are the automated deployment of Citrix Director, Licensing and Provisioning Services (if Chris Twiest doesn’t beat me to it ;-)).
I will also be writing a blog about a VDI deployment script that I wrote for a customer together with Leon van Efferen. It can deploy VDI’s from a VMware ESX template on shared storage to the local storage of the hypervisors. After that it will add it to the PVS farm, the XenDesktop Machine Catalog and Active Directory. It can also spread the VDI’s evenly over multiple virtual networks while checking the current usage of each network (Yes, I’m enthusiastic about it because it was cool to build). Stay tuned.
DISCLAIMER: As with the other automation blogs I have posted: This is just my take on the automation of the deployment of the Citrix XenDesktop/XenApp Virtual Delivery Agent with RES ONE Automation. I’m not saying this is the best way. It is just one way to do it. So if you have any suggestions on how to improve these modules: I would be very happy to hear it. Also, feel free to use, alter or publish these building blocks for yourself.
Building block for Citrix Virtual Apps and Desktops 1811:
Building block for Citrix XenDesktop 7.17:
5,646 total views, 5 views today
I am receiving an “access is denied”error every time the job is about to install Citrix Virtual Apps and Desktops agent.
Installing the prerequisites (Visual C++) are completed without any errors.
The installation account has execute rights on the network share and is local admin on the reference machine.
Could yopu please help
I can help, no problem.
Is User Account Control active on your machine?
And do you have the complete error message for me?