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.

Experiences in Project Consulting

Well been a while eh? I'm still out here just been a tad busy. Thing is I've had tons to say but not much time to say it. Time to get back on that horse. I'll be posting a few things encountered and some new tips ... but what am I going to talk about today?

It's taken me days to get to this and I really wanted to post something right away but felt I needed to cool off. Good idea. So now that I have ...

As a consultant we all expect a certain amount of professional curtsy. We all believe that each of us are able to do what is needed and can handle anything thrown our way. We believe that our fellow consultants are as good as us and we are "The Team" that gets called in to fix the unfix-able, to build environments that are shining examples to all others. For the first time my faith was shaken in that regard. I guess it can't be helped, when you work at as many places as I have you're bound to find a few small minded people even in our field. It was just a shock ... but let me lay it out.

I was called in to a major project to deploy applications via ThinApp to be used in a VDI rollout. First off I'm not terribly strong in ThinApp but I'm not unskilled in it and I was assured that I was not going to be the only asset. So I go in with high hopes and looking forward to brushing up on things. From day one the outgoing Citrix "expert" took a dislike to me. I asked too many questions about the current environment it seemed. Of course that's what I was there for so you can imagine my surprise at the claims of me being snobby and sarcastic (well I'm kind of naturally sarcastic but hey). This was a first for me and usually the team works things out but this person made it their job to undermine the team dynamics.

If you hadn't already figured it out, things went south. The "expert" had the ear of the PM, that and a sudden change in marching orders gave the person an insider's edge. I was forced to move on. Again another first after so many successful projects and great teams that I've worked with.

So what do I take away from this? First off, define and gain acceptance of your place, goals, and actions in the team. Second is communication, but in a way that shows engagement and not just noise. We as independent and autonomous minded folk occasionally fail to remember that though we are working our butts off, to some it can look the opposite. Finally, and here's the hard part, if you feel the team is not in sync and/or maybe you're not a good fit, determine if you need to pass the baton. If you decide that it's not going to work, don't waste time trying to make it work, it won't and it can damage your sense of well being. In my experience I got some good time in but ultimately is was wasted effort project wise. Other projects will come along. Trying to hold on to a failing position can be a negative down the road. Take the high road when possible.

I hope it all works out for the project. The remaining team should be able to pull it off, and I'm sure that they will bring in other assets. I believe that all experiences are learning experiences and this was just another one. I still got four weeks of paid training that got me back up to speed on the latest in VMware. That was worth it alone.

So ... on to the next adventure!

NetScaler Fundamentals - Day 1

First off want to say great class and the instructor, Richard Nash, is a great guy and easy to talk to.

So I took this class because a) I need to understand just what is going on in these devices and b) every time I deal with a NS device it's like Sanskrit and not a single one is set up the same way.

I'm going to keep this short and sweet: if you have the opportunity to take this class, do it. If you already know NS then fine, no real need, but if you've been seeing these devices (and I mean any of them, both VPX and MPX) and you have issues understanding just why someone did what they did, or you setting up more and more of these and just playing it by ear, then you should run to this class.

Now I wouldn't advocate flying from Tuscon (sorry Mike) but hey to each their own. :D

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.