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.

Why I've given up on Firefox

Before anyone goes off the deep end on the title let me make one thing crystal clear: I HATE IE.

Recently I've been using a lot of different browsers, and let me say that in most cases they work identical to each other. Understand I don't go digging into code or bug chase things. A browser to me is like a ohm meter, how it works is not as important as it works as it's supposed to and how I need it to. So having said that I've come to the conclusion that those that are guardians of the Mozilla code, that is at the core of Firefox, just don't give a rats patoot that issues that are rendering it unusable for a few of us are, well, important.

Case in point: I use in regular rotation a laptop that runs Vista Business x64. Yeah, yeah, don't gasp and don't judge, it is one of the most stable systems I've had. (We are not going to digress into a pro/con Vista discussion so shush.) Not to mention it's AMD and dual core (real dual core mind you) and more than enough memory.

The only problem is when Firefox fires up.

Understand that this is also an HP unit and so it has the HP Protection Suite installed. Again don't get side tracked, I like the options and I love the bio-metrics because in cases where I can do so, I prefer technology to deal with security (go figure) and not rely on my memory of password. So here is where the problem comes about. In just about all cases firing up a browser is not an issue ... unless it's Firefox then things get weird. I see a spike in CPU and then a constant load of at least 50% across both cores. Add in any additional apps and I'm at 100% and the system crawls. Close FF and all is fine again.

I've traced this problem to the unfathomable fact that the HP suite and FF just don't get along. The only work around's are disable the suite or stop using FF as my primary browser. Hmmmm, stop using the tool that saves me from typing more passwords in or stop using one of half a dozen browser that, though I really like, is causing the actual issue (no other browser does this).

Chrome, your it.

I can only hope that someday, at some point the great folks doing the coding for FF will see the light and actually test the next iteration ... but I've been waiting a long time for that and so far, at now version 17, it's just more of the same fail.

Ah well.

Understand that this isn't the only reason I've called it quits for FF, just an example. Oh sure I could go into the seeming indifference to cranking out version after version for no reason save to break add-ons, the continual ability to break more than they fix, or the fact that it continues to be at war with Flash, Java, and a few other plugins. But isn't one example enough?

Oh sure I'll still use it on occasion but as my default? Nope, it's over.

Good luck FF, hope that I can come back to you someday but I need an ohm meter that works.

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.