Though running Citrix XenApp 4.5 – formerly Citrix Presentation Server 4.5 – on XenServer 4.1, the new virtualization platform from Citrix, might be a likely topic for a Citrix Training Center blog, today the Citrix story I have to tell is actually about running XenApp 4.5 on VMware’s Virtual Infrastructure 3 (VI3), because that’s what the customer was doing.
Apparently there’s a new industry coming up that is projected to bloom into a hundred and sixty billion dollar industry, soon, called “infrastructure on demand”.
The task was to create a “button” to press that would provision Citrix server vm’s, apps installed, Citrix software installed, configuration complete and documented, immediately, and while many of my peers approach this from a scripting point of view, with Windows sysprep utility and Enteo software complicating the process, I decided to see if I could get a citrix-vm clone going, having been hanging around training centers for the past 15 years and dealing with ghost issues all this time, having seen an older MetaFrame XP advanced admin course that bulleted a full page with what to watch out for when cloning Citrix servers, and knowing that the current version of the CCIA books say several times that Citrix supports cloning.
I Googled the issue and found very little from Citrix specifically, understandably with their big push for XenServer. Still, there were a few bloggers who’d tried it, and a couple of Powerpoints by VMware and Citrix from a couple of years ago, and I gave the new software a try at the old tricks.
I used Citrix XenApp 4.5 Feature Pack 1 (FP1), on a Windows 2003/R2 base server, in a Windows 2003 AD domain. The VMware box was ESX 3.5 on a powerful Dell box, with Virtual Center 2.5 installed on a vm inside the ESX box, as the cloning feature is exclusive to the Virtual Center, not available on ESX 3.5 being managed directly as a standalone host.
After building the domain controller, TS and Citrix Licensing on that DC, installing SQL Express on the DC, and configuring AD appropriately for Citrix (see blog article on this site….), I built the prototype Citrix server, installing Terminal Services and XenApp 4.5.
That much is standard stuff you’d do on day one of a Citrix class, or day one or two of an implementation. The only modifications here, creating the “golden template” from which all future Citrix servers will be cloned, is that
1) The balloon memory driver feature of vmtools should be left out of the Citrix server image.
2) The Resource Manager feature is de-selected, as EdgeSight will be used to monitor the performance of the Citrix Servers, as well as load test and optimize them. (If Resource Manager were to be left installed, the local resource manager database would need to be deleted before cloning, while the Resource Manager service was stopped.)
3) Each vmdk needs two full gig of RAM,and there should be two vmdk’s, one for the system, at about 10 GB, and another for applications. The page file should go on the second vmdk.
4) The Microsoft utility “UPHClean” should be installed, and any profiles should be cleaned up before cloning – ideally no profiles will ever have been created on the golden template.
5) Several settings in Terminal Services that are relevant to the Citrix implementation can be configured either in GPO’s or in the Terminal Services configuration (TSC) tool on each server. Since in the Windows 2000 days there was no option for Terminal Server GPO’s, and since we’re cloning anyway, out of nostalgia I set the security in the TSC – specifically locking down the RDP listener to admins only (big default security hole!), and configuring disconnect timeouts and shadow settings.
6) The applications installed were Microsoft Office 2003 and the Microsoft CRM client, and Adobe Reader. They were installed using “TRANSFORMS” files from Microsoft, edited in ORCA.
7) Administrators for the farm need to be set as Domain Admins, if that hasn’t already been done; there will be a problem if the domain admin can’t manage the farm.
8 ) With the Platinum license, the Citrix server has to be patched and the new Access Management Console (AMC) has to be downloaded, and the server inside the new AMC has to be set to “Platinum”, about twenty-five minutes of tedious work that can be washed away by the new cloning process, as long as it is endured during the creation of the golden template.
9) One more thing on the golden template – the “newsid” utility from Microsoft should be easily accessible on the local hard drive, because there will need to be a rename of the server before it hits the network. The “querydc” utility is also quite useful (see the blog on advanced IMA) and so might as well be included in the template as well. Any other custom utilities should be added at this point.
When the golden template is finally perfect, and has been tested, any WebInterface or pnagent site should be deleted, as it can be re-created much more easily than all those others in the clones can be deleted.
Finally in the Virtual Infrastructure client, in the virtual Center “data center”, the XenApp server can be “cloned to template”.
To see the template, switch to the “Virtual Machines and Templates” view in the Inventory of the Virtual Infrastructure Client (VIC). Right clicking on the template object offers either cloning, or “deploying” a virtual machine from a template. The “deploy” is the common option used in vmware, and requires sysprep files copied to the vmware virtual center server, and a customization wizard with ten screens full of questions. The purpose of this exercise was to get the job done as fast as possible. So the other option, “clone”, is like the old ghost technology. It just makes a copy of the original, and you are on your own as far as customizing it properly.
The clock, so to speak, starts ticking when I click “clone”. I take all the potential issues into account. I tested my server in a test lab and then production, and the test results held up. The design scaled well, with the template converted to a vm temporarily to get updates to the CRM client before going back into the “Templates” view. The clock starts ticking now, and the clock ends when I have a second server in the farm, apps installed, best practices configured, and in the domain properly, in a scalable model, which happens to be about twenty five minutes later.
First, I disable the NIC, logged into the console of the new server in Virtual Center. Can’t have this thing on the network yet.
Second, I run “newsid” from the local hard drive of the new clone. While getting a new sid, it also renames the computer to whatever we want – here we name it the same as the name in virtual center.
When the virtual center server reboots after newsid, log in as the local administrator and change to a workgroup, from the domain. Then enable the NIC, change the IP address and configure IP, then re-join the domain.
Log in as the domain admin now, launch a command prompt, and invoke the “change farm” utility, by typing “chfarm”. This will allow the server to be (temporarily) placed in a stand-alone “test” farm with a local MS Access database.
When the IMA service starts successfully – about two minutes later – then restart the change farm utility, this time joining the production farm as if for the first time.
The final catch, though, is that the super-critical-for-printing system account that’s supposed to be local to every Citrix 4.5 server. The “ctx-cpsvcuser” account, is corrupt. One way to fix this is to go in to the printers and drivers section of the windows server, remove the Citrix Universal Printer, and delete the corrupted account from the permissions tab in the TSC under the ICA listener.
Then go to “Add/Remove” programs, click on the “Citrix Presentation Server 4.5” entry, and click “change/remove”. On the following screen, faced with “Modify, repair, or remove”, choose “repair”. Browse to the MSI on the Citrix server CD, and wait. Seven or Eight minutes can go by, but when it’s over, the driver AND the user account are fixed.
The apps need to be modified to run on the new server as well, and the custom load evaluator has to be applied to the new server manually.
Finally, the Citrix server is moved into the appropriate Organizational Unit (OU) in the domain, applying all security and profile optimization settings.
And we have a new workhorse in the farm, hitting the ground running, about twenty five minutes after the clock started running.
Was this information helpful? Feel free to share your comments/experiences below.