The methodology I use for deploying and managing Citrix XenApp solutions has proven very successful over the years.
To maintain a homogeneous environment conducive to stability, utilisation of a well-defined and automated server build process is a best practice. Automated server builds can save countless hours when deploying new servers, rebuilding a problematic one, or addressing test requirements. A server build process is based on building servers from initial hardware configuration through to application installation and configuration. In most of my cases this is heavily used for Citrix XenApp rollouts.
There are many methods to accomplish an automated deployment; the most common are scripted builds, and imaged deployments. Each has their own benefits and pitfalls.
- Scripted unattended builds provide an extremely portable image, allowing the same base image to be deployed on the widest range of hardware and devices. Additionally, updating the image is simple, all application install scripts are in one place, and to add in additional hardware is as simple as inserting the correct drivers. The downside of scripted builds is that they are very expensive to develop, compared to manual builds, or imaging.
- Imaged builds provide an image that is portable within the boundaries of a hardware class. There are tools available that extend the support of an imaged build, by inserting device drivers external to the image, however these are primarily aimed at desktop devices. Imaged deployments are very quick to install, and contain all applications and customisations required. The downside of imaged builds is that they are very difficult to maintain, the update of an application requires the entire image to be recompiled, and to add new hardware requires substantial changes.
I am not a fan of imaged builds. I believe that it’s a cop-out for an Integrator/Consultant to implement imaged builds for clients. There is no excuse, and it shows a failure to fulfill a commitment to the client by not providing them with a flexibile and agile solution.
So clearly I deploy scripted unattended builds. But how do they work, and what do they offer? Glad you asked!
We had been deploying automated builds for years, but at the time our method was clunky, and required a lot of customisation to port between customers. So back in late 2005 I spent some time analysing the IBM ServerGuide, HP SmartStart and Dell OpenManage deployment methods. I pulled them appart and reverse-engineered them. In my opinion the IBM ServerGuide tools were far superior to the other two tier one Vendors. This had nothing to do with the fact that I was an IBM employee at the time, and was an honest assessment. So I wrote the initial part of the unattended build process based on the IBM ServerGuide deployment methods, using many of their tools. At the time I even managed to make contact with the team that wrote some of the tools, and they implemented a change that I requested so that I could use the same tool set for deploying Dell hardware too. That was really cool!
The automated server build process has been designed and developed to provide customers with several important mechanisms.
- Easy to add additional servers, knowing that new servers will have an identical build.
- Ensures that servers are built to vendor and industry best practice.
- Flexible customisation as it can easily be adapted with the emergence of service packs, hotfixes, new operating systems, updates in drivers and hardware, and new applications.
- A method of individual server Disaster Recovery.
- Making the server installations more efficient and repeatable by using a “set and forget” process, where a Systems Administrator can start the build process off and return about a hour or two later with a server that is more or less ready for production. No swapping media, adding drivers, typing in product keys, etc.
- Reducing the need for high level Windows skills at build time
- Eliminates the “human” factor.
The current build process currently caters for…
Operating Systems of:
-
Windows Server 2003 x86 Standard or Enterprise SP2
-
Windows Server 2003 x86 Standard or Enterprise R2 SP2
-
Windows Server 2003 x64 Standard or Enterprise SP2
-
Windows Server 2003 x64 Standard or Enterprise R2 SP2
Deployed as a:
-
Citrix XenApp server
-
Base (generic) server
-
Other – Note that other role types can easily be created based on the customers requirements
And it caters for real and virtual hardware such as:
-
IBM Systems x (xSeries) Servers
-
HP Proliant Servers
-
Dell Servers
-
VMware ESX and Server
-
Citrix XenServer
-
Microsoft HyperV
The front-end of the build process boots a WinPE 2.1 iso image, which will allow us to deploy both 32bit and 64bit Windows Operating Systems, and fully supports DFS locations for access to the “build” folder structures. It will initially prompt the user if they would like to build a 32-bit or 64-bit Windows Operating System. Then it boots the appropriate Windows Imaging (WIM) format file and loads a HTA form as per the screenshot below.
When you select “Start the build process…”, you are then prompted with a list of variables that will be set based on the information you entered. These variables are referenced throughout the build process.
It only takes a matter of hours to integrate the build process into a customers environment, removing a lot of the “pain” of building servers for new rollouts.
The automated build process contains the server operating system, drivers and service packs required to provide a stable base environment.
Now…I think you’ll agree that you get a lot of Intellectual Capital for that, so it’s not something we provide for free. You need to engage us in a project. Typically we build 5 days into a project to cover…
- The customisation.
- Updating of drivers.
- Updating of Vendor management tools, such as the IBM ServerRaid Manager, IBM Director agent, Broadcom Advanced Control Suite (BACS), Dell OpenManage Agents, HP Proliant Support Pack, etc.
- Integration of new service packs and hotfixes that are relevant to the Operating System, XenApp, etc.
But for this you get a first class process that very few Integrators/Consultants can provide.
Are you paying for something that is specialised? Absolutuely not. It is simply a bunch on Command Shell, VBScripts and PowerSell scripts that bring everything together. The executables used are free utilities and tools readily available on the Internet, and of course the IBM ServerGuide Scripting Toolkit. I have not developed anything.
So why continue to harp on about this now that Vendors like Citrix have released some great products such as their Provisioning Server product? Well…not all customers are interested at spending the “licensing” bucks to qualify for and implement such a product, so this build process will live on for a few more years yet 🙂
The process is solid and reliable. The next stage is to work on the automation of the Windows 2008 unattended build.
If you would like to know more about it, please feel free to contact me.
Thanks for reading.
Jeremy.
Jeremy Saunders
Latest posts by Jeremy Saunders (see all)
- Best Practice for the Active Setup StubPath value - September 25, 2023
- User Profile Migration Strategy and PowerShell Script with a User Interface - August 28, 2023
- Cold Starting and/or Hydrating Your Applications To Improve Their Startup Times - June 27, 2023