Building XenApp Servers in 30min

So you're tasked with setting up multiple servers and don't want to be there till the wee morning hours. Significant others can be such a pain! :D

Some will say that making a "gold image" of a XenApp server is the best way to do this but I find there are issues with the xenappprep/sysprep method. One of them is that with that method there is a lot of post reset "cleaning" that needs to be done. With that it can make the whole process longer than you might feel it should have taken.

In the method I'll outline shortly we will still be using a template with an OS pre-installed but from there we will be doing things a bit different. One thing that is assumed is that we will be joining the server(s) in question to an existing farm. If you are setting up a new farm then this all should be after the initial server is setup and your farm is communicating properly. DO NOT try and use this process for setting up a first server and farm.

Prep Work

Okay first you have your farm running (first DC is up and you have access).
Next you have a template for a bare bones Win 2008 R2 Server that is OOBE set.
Finally you have copied the MF20.dsn from the first server to the location that the install media is.

Let's Get Going

Create a VM from template and configure what's needed (vCPU, Mem, Storage, IP, Name, Activate!!!!) and make sure it connects to domain and is accessable (basic stuff I know but always good to remind yourself).

Once the server is up and running, oh and you can do several of these pretty easily at the same time, time to put in roles. The key to doing this fast is scripting and knowing what needs to be added. Here are the basic roles that need to be added:

Add-WindowsFeature XPS-Viewer -restart -logPath C:\role_install.log
Add-WindowsFeature SNMP-Services -restart -logPath C:\role_install.log
Add-WindowsFeature AS-Net-FRAMEWORK -restart -logPath C:\role_install.log
Add-WindowsFeature GPMC -restart -logPath C:\role_install.log
Add-WindowsFeature RSAT-ADDS-Tools -restart -logPath C:\role_install.log
Add-WindowsFeature Desktop-Experience -restart -logPath C:\role_install.log
Add-WindowsFeature RDS-RD-SERVER -restart -logPath C:\role_install.log

The server will need to reboot about two times since Desktop Exp and RDS both need reboots to complete. this should happen even if the -reboot switch would normally suppress it so don't be alarmed.

Once the roles are in place we install XenApp. In this I usually install session-host servers and not full. They use a bit less memory and are a bit more "hardened" as the tools that are normally there are not. No console or policy tools so if something "bad" should happen, the server can't be used to exploit further into the farm.

So with that in mind, this is what I use to install:

Start-Process "\\<server>\<volume>\<source dir>\XenApp Server Setup\bin\XenAppSetupConsole.exe" -ArgumentList /install:XenApp /exclude:XA_Console /Advanced /logfile:C:\xa_install.log -NoNewWindow -Wait

For those that want full server capability, remove the  /exclude:XA_Console part from the command line. 

Then to configure:

Start-Process "C:\Program Files (x86)\Citrix\XenApp\ServerConfig\XenAppConfigConsole.exe" -ArgumentList /ExecutionMode:Join /ImaWorkerMode:True /ZoneName:<zone> /DsnFile:[drive]:\MF20.dsn /OdbcUsername:[dsadminuser] /odbcPassword:[password] /AddAnonymousUsersToRemoteDesktopUserGroup:False /AddUsersGroupToRemoteDesktopUserGroup:False /ProhibitShadowing:False /ProhibitRemoteControl:False /ForceShadowPopup:False /ForceShadowLogging:True /CustomXMLServicePort:8080 /CreateAnonymousUserAccounts=False /RemoveAnonymousCitrixAccounts:True /LogFilename:C:\xa_config.log -NoNewWindow -Wait

Again if you want a full XA server with all the tools and capable of being a DC, remove /ImaWorkerMode:True  from the command line.

A couple of things about the configure part. The DSN file should be located on a mapped drive, UNC paths don't seem to work well for that setting. Coulld be just bad luck on my part but then again ...? The script also does something that I found hugely useful, it eliminates all Anon accounts that seem to always be added no matter what you say during a GUI install. Finally being able to preset the XML port prevents a common mistake of setting the wrong port during a typical setup.

After that you should have a "clean" and brand new XA server ready for work!

Additionally you will want to run HRP03 with something like:

Start-Process "msiexec" -ArgumentList "/p [drive]:\<source>\XA650W2K8R2X64R01.msp /qn /passive /norestart /Liewa C:\hrp_install.log" -NoNewWindow -Wait

You will note that though I said this all is scripted, I didn't provide the script ... well I'll leave that to the class to figure out. :D

Peace.

Page / Swap Files and you - Part 1

Hey another "part 1" article!

Okay, so I have a bad track record ... but I'm going to keep trying!

On a couple of occasions I've been asked "what should page files be set to" (I say page file because it invariably is a Windows deployment we are discussing). My answer is "depends." There are quite a few greatly detailed articles about how page files work etc so I'm not going to go over them here. Google (or Bing (ick)) them and have fun with the feeling of your head exploding. For my part lets keep it digestible and focused on virtualization.

VM level

So this most often comes up cause someone foolishly allocated 30gb to the main partition and now you're in a storage hole. Anyone who doesn't know the "60/x/x" rule needs to be educated ... but I digress. So going back the question is how much page file is needed. In the past the rule was always 1.5 x physical memory. This rule came about for various reasons but one of the main ones was that 4gb was the nominal limit for server memory. Giving it a big page file help performance (research 'commit charge' for more on that). The other reason, though less heavily used, was the fact that when a memory dump happened (BSOD) you needed a page file big enough to take it.

In this day and age of x64 and super high limits (if you can call them limits) on memory begs the question: do we stick with the rule? Short answer: yes. Long answer: well yes but if we are talking a really big amount then maybe no. Example: a file server is usually a 2/1/4 (cpus/cores/RAM) affair, this results in a page file size of 6gb. Not so bad and within reason. Now lets look at a virtualization server. Example: a XenApp server is typically a 2/2/16 which would result in a page file (using the old rule) of 24gb. Whoa!

So on the latest x64 OSes we have a quandary! Okay, not really cause there is an easy way to figure out what is really needed. Remember the first reason we noted, well that part is not needed quite as much with so much physical memory available. So the dump is the key and here's a question: how much memory is really needed for a dump. Turns out a lot less then maybe it used to need. Try 1/3 of what you might think. So here's what I'd suggest:

Physical Mem
2 to 8 GB == 1.5 x RAM
10 to 16 GB == 0.75 x RAM
18 to ? == 0.5 x RAM

It generally works and makes sure that there is enough page file for a typical kernel dump in the larger ranges. The storage foot print is reasonable so things don't get out of hand. Of course you can still use the 1.5x rule and be just fine if you have storage to burn.

In the next part we go to the host level!

Peace.

Solving Java issues on XenApp Servers (Part 1)

Recently I was troubleshooting an issue with Java on a provisioned server. The problem manifested by the user being asked to install Java when a particular UI interface was called that in turn invoked Java to display a Gannet table of appointments. As the user did not have elevated rights any attempt to install failed. Simply refusing to install also caused the function to fail. After much trial and error I determined that this was a result of two issues.

When a user connects to a Java app that user session, in normal conditions, it will try and determine if Java is installed. It does this by checking if it has a path to the \bin folder and if it has access to the cache folder. If either fails it will then attempt to install Java, however this is not possible for Citrix users normally as it will try to install on the hosting server.

What has to be done, to make Java applications work in Citrix, is to ensure that when a user connects they are able to satisfy the Java run-time requirements. To do this several changes need to be made on the hosting server so that both the run-time files are seen by the user session and that the cache is not in a location that requires privileged rights to access.

On the host XenApp server (provisioned or standard) the following needs to be done:

1. Make a note of the version(s) of Java currently installed. Download the offline installer(s) for those versions.
2. Log off all remote user sessions to ensure a clean uninstall.
3. Uninstall all Java versions currently installed on the server.
4.  Delete old file locations if any. These are often found in the following locations: C:\Program Files (x86)\Java\<version> or C:\Program Files\Java\<version>
5. Starting with the oldest (lowest numbered version) install using TS-Install or “change user” process. 
1.  If the version(s) of Java installed are pre version 6u20 you will need to make the ‘C:\Windows\Sun\Java\Deployment’ manually. This is important for supporting clients that have more current version installed locally. 
6. Once all versions are installed, you will need to change the default location for the Java cache folder. To do this:
1. Make a new folder: C:\JavaCache, make it R/W for “Everyone”. 
2. Create a file named ‘deployment.properties’ which should include the information of all Java versions installed as well as the location of the cache folder. Example:
3. Save the file, see step ‘f’ for location.
4. Create a file named ‘deployment.config’. This will have to be done for each version location and for use in ‘C:\Windows\Sun\Java\Deployment’
5. In each file you need to add the path for the properties file. This will depend on where the file is in relation to the version. Example:
6. Save file, see below for location.
7. Each of these files will need to be saved in the C:\Windows\Sun\Java\Deployment folder and C:\Program Files (x86)\Java\<version>\lib for each version.
7. Entry needs to be added in the servers PATH variable pointing to the /bin directory of each version. Example: C:\Program Files (x86)\Java\jre1.6.0_05\bin;C:\Program Files (x86)\Java\j2re1.4.2_19\bin
8. Navigate to the server configuration and access the User group rights. Ensure that either:
1. The Remote Users Group is included in the Users group or,
2. The User group includes the same user groups that are a part of the Remote Users Group.
9.  Close all. Proceed with the process of sealing the image if the server is provisioned.

What the above does is redirect the user session to a cache that doesn’t require elevated rights to access (such as the default). This along with the path changes allows the client to see that Java is installed and that the cache is available.

For verification, navigate to a Java app that is served from the configured XenApp server. Once opened access the Java Control Panel located in the System Tray, right click and select Open Control Panel. If properly operating you should be able to see the Java cache path properly configured.

If using roaming profiles you might need to reset (move or delete) the store profiles where ever they are stored.

In part two I will outline the other problem that showed up regarding Java interaction and an issue with XenApp configuration of SFTA.

Peace.