In the same way as the previous blog post, some more automation to maintain a VDI/RDSH environment, and get back to a controlled and clean environment. This blog is a follow up to Remotely clean up Virtual Machines drives – XenDesktop , Expand virtual machines hard disk – automation , XenDesktop XenApp 7.x – vmware / ad / delivery group notes and descriptions sync . I had to automate an action to place ACLs on the D: drive using Powershell and icacls. This script is using XenDesktop / XenApp command to list all the Virtual Machines with SessionSupport value equal to SingleSession, it means the VDI only in my case. If you want to check the list of Virtual Machines you targeted you can use this command : If you want to target a specific XenDesktop Delivery Group, then just adapt the previous line : Once you know the target, you can execute the following script. Using this script assume Virtual Machines are switched on. If you have suggestion, and/or comment, share your though !
Following up the previous blogs XenDesktop XenApp 7.x – vmware / ad / delivery group notes and descriptions sync and Expand virtual machines hard disk – automation and continue in automated task, I had to clean up the D: drive of different XenDesktop Delivery Group. As there was no security restriction on the D: drive some users used it as a repository for some of their project... That caused some issues : Users complain of losing their working data from a session to another (pooled VDI, new logon = new vm) Some disk space notification where displayed to random users... Calls where raise to the helpdesk support team Beside hiding the D: drive to avoid non necessary access (ie : non system access) check this blog to do so : Citrix XenApp – Hiding system drives part 1/2 an automated task had to be performed to "clean" this D: drive The variable $XDDC is the FQDN of a Delivery Controler, $Exclusion is the files and folder you want to exclude from being removed. For example : the directories "logs" "pvsvm" "System Volume Information" "$RECYCLE.BIN" and the files "dedicateddumpfile.sys" "pagefile.sys" and "vdiskdif.vhdx" will be ignore from the delete process. Most of these files and directory are system protected anyway it's more to avoir error during script execution. Once you have a clear list of what you need and want to keep you can proceed to the next step. This script will clean everything which is not in the $Exclusion list so be careful when you run the script. This script assume all the targeted VM are switched ON of course. Leave a comment bellow if you have an idea how to improve this script !
Several times i had the need to synchronise Virtual Machine notes (vmware) with Active Directory Computer description. As in big environment, different team are managing each of these components, the need to be able to link an Active Directory computer account to a vm with XenApp / XenDesktop delivery group has often been seen as useful. Delivery group name : Desktop123 Virtual Machine note (vmware) : Desktop123 Active Directory account Description : Desktop123 The idea is to simply synchronise the information through the platforms so everyone knows quickly what machine does what. In this particular example that was about XenApp Servers and XenDesktop VDI. You will need a machine where : XenDesktop 7.x SDK (Powershell is installed) vmware PowerCli installed RSAT role deployed as well Thank to Rodolphe Herpeux who simplified the first version of this script I wrote.
Citrix will very soon offer a lot of scripts and tools to give the ability to migrate policies from a XenApp 6.5 farm to a XenApp 7.5, I'm currently testing all these Powershell script to check it out and maybe use it by including it in our migration process. What Citrix haven't give us yet is a tool to move an existing XenApp 6.5 server to a XenApp 7.5 Site, steps are fairly simple and can be automatize : Leave XenApp 6.5 Farm **Reboot** Uninstall XenApp 6.5 **Reboot** Install XenApp 7.5 VDA This is not what I recommend to do because removing a piece of software to replace by another always leave some dirty little things everywhere... This is the reason I prefer to start from scratch and migrate application; sometime it's not possible and we need to go fast, so these few steps are easy to customize and integrate in every deployment system in place. The first step is to leave the XenApp 6.5 farm : To complete this farm leave script, you need to reboot the XenApp server. The second step is to uninstall XenApp 6.5 using this command line : To complete this step the XenApp server needs to reboot again. The last step is to deploy the new VDA (XenApp / XenDesktop 7.5) using this command line : Update 25 April 2014 If you plan to move your XenApp 6.5 servers to XenApp 7.5 you need to clean a bit more than simply XenApp, I had a lot of comments about Edgesight agent, Citrix Profile Management etc... and my answer if yes you need to uninstall each of these component to avoid any conflict with the VDA. For example Esgesight can be uninstall using the following command line : This is it ! I think Citrix will offer a "graphic" tool in some point, but I needed to have that ready now, so I share it ! Resources : XenApp and XenDesktop 7.5 edocs XenApp Uninstallation Best Practices
This is a classic but needs to be written somewhere so I can find it again when I need it ! First thing, you need to add the XenApp Powershell snapin : Then you can use few very useful command to gather information and script your deployment / inventory. That's what you got access to, now I want to list hotfixes on XenApp servers, I used Get-XaServerHotfix "ServerName" The result format is not very useful and is about only 1 server in a farm of 100... And I was looking for all the servers which had the XA650R01W2K8R2X64061 hotfix installed I needed to have a list of all servers, only the machine name where this hotfix was installed. And the result look like this : This is simple and quite basic but it's very useful ! if you have any comment and/ or request, just drop me an email or comment !
AntiVirus software are always pain in the ass when it's about delivering desktops through golden images system like Citrix Provisioning Services. It's changing but still, in most of the company I'm working for there is always the AntiVirus dude who is yelling and requesting to be able to watch / watch and be able to know where the Antivirus software is deployed, if it's up to date and if all the machine are ok. Last blog I did about an antivirus was about Symantec SEP 11 (here) and Symantec did their job by understanding what was a virtual environment about with the version 12. With TrendMicro and ServerProtect, we're not there yet... Even if their product Office Scan seems to fit better the needs, today I had to deal with Trend Micro ServerProtect installed on the PVS golden images. The problem remain the same, a Trend GUID is created when installing the piece of software on the golden image but won't change across multi machine usage. The Trend GUID is located in the registry : HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\ServerProtect\CurrentVersion\SpntService\NS_GUID with a 75 long character chain. What I had to do : Create a 75 random character string Replace the registry value create a flag so the value won't change at each reboot So I did with my crappy PowerShell skills a very small script (and thanks to Livio @EldejiPoint for the cleanup ^^ ) So this script will be executed as a startup script for the computer (using GPOs) and by creating a trend.txt file on the fixed drive (d:\) the generated Trend GUID won't change upon the file is removed. I hope it will help !
Citrix XenApp 6.5 Hotfix Rollup Pack 3 is available since the 12nd of December 2013 (link) and I went through several deployment until today. I got this error on a worker server (PVS Golden image) while installing this update. The error : "Error 25822. Setup could not install the drivers required for this product." stop the installation process and rollback to the original state of the XenApp server. As the installation wen fine on other servers within the same farm, I chose to take some time to investigate this issue. First thing first, running the patch update by generating a log file with msiexec : and when i opened the log file i found the error : The installer stop because the file ctxsbx.inf is not found on the XenApp server, after a google search i found this old XenApp KB CTX121887. As mention in this kb I made a copy of this file on the target XenApp server from another one where the file is. It did work but after that the installer remaion stuck on drivers installation process and remain on loops. The only way to make sure my server would survibe this installation was to cancel everything, repair the XenApp installation and reboot the server at the end. Once the server was back online again, I tried to apply the HRP3 again and everything went finaly fine.
This one has been pain in the ass to find out... Since Java 7 (1.7_xx) the security and setting management is a total nightmare. This is so messy you can't find a reliable information on Oracle website... The worse thing is all the mechanism seems to change between versions... from 1.7_01 to _11 is one way to do thing and version after it's done another way... Here is the ugly pop up I want to eliminate from the user interface on the XenApp Desktop. To do so, I had to check every change within files, registry to finally find out everything was located in the registry for this version of java, JRE7 1.7_13... So I wanted to create a GPP to target user connected on the XenApp servers, here is my xml file created from a registry export : Next, I wanted to filter this GPP with a WMI filter, this WMI Query will look for locations of the JRE7 Folder on the System and if found it will apply the policy. And this works ! I didn't need to do anything with deployment.properties and deployment.config as described everywhere on the Oracle website... (This website is really pain in the ass to find good documentation...) I hope it will help, and I hope Oracle will stop to change the way we need to use to manage Java configuration....
I blogged about how to automate Citrix XenDesktop 7 deployment and database creation, and how to join and existing XenDesktop 7 site unattended, but now to continue and go a bit further in the automation process, I needed and wanted to know how to automate Hosting Configuration by Adding Connection and Resources to the DDC in an unattended way. This blog will cover creation process for XenServer 6.x and vCenter (vSphere) 5.1 since I don't have access to a Hyper-V (yet), I went over Citrix eDoc to check how I could do this and I found here : [link] Thanks to Livio for some PowerShell help :) It helps to understand whet need to be setup and after few tests I ended up writing this script to automate this part : This script have been tested with Citrix XenDesktop7 and XenServer 6.2 and vSphere 5.1
So auto-install and auto join an already XenDesktop 7 Site is cool but what if you need to automate the first DDC installation ? Here is how I did with help of a great blog (Timm Brochhaus) who made a script available for everyone, and I personally used it. Let's do it for a full automated installation, I will install all the components from XenDesktop 7. Timm Brochhaus wrote a very cool blog and give you the explanation about a script he wrote to automate this part with a very useful script. Juts don't forget to run this script in 32bit mode.... [link] I did use Timm's script and here is the result I got : 3 databases were created, one for the Site informations, one for the log informations and a last one for monitoring (edgesight-like) Now we are ready for the next step which is site creation with the command New-XDSite with the result : If I use the script Timm make available and use the same syntax, this is pretty easy to add this line and add what we need to automate DataBase creation + Site creation in one script : So now your XenDesktop 7 DDC is ready to work, you can launch the Desktop Studio console, you just need to create your Machine Catalogs and Delivery Groups etc... This next part of automation is in my next blog about XenDesktop 7