I was working with the NetScaler wizards to provide Load Balancing and GSLB services for a XenApp 6 environment the other day. The NetScaler VPX was placed in front of a multi-server XenApp farm to provide load balancing.

The wizards do prompt for the applications and site path to create out-of-band monitors that determine if the back end XML Broker and Web Interface (WI) systems are intact. This was functioning as expected, and was working well.

As I worked with a colleague we got involved in a “Health Check” discussion. With the many possible combinations of user groups contolling access to their associated applications, it was apparent that it would not be possible validate all combinations.

In my configuration, I had the users set up in their appropriate Active Directory groups – London and Sydney – and had the WI systems functioning appropriately. The configuration paralleled that referenced in my June 2010 TechTalk.

During my validation exercises I encountered a problem, however.

In my haste, I had overlooked setting up the appropriate group membership for one of the users. Because my WI servers were configured to deliver published applications to members of only specific Active Directory groups, this “groupless” test user was experiencing a failure.

I took a look at the error message presented. It simply stated that “There are no resources currently available for this user”. My load balanced WI servers were fairly straight forward with typical default configurations.

While I was looking for the cause of this issue, it struck me that a non-technical end-user might have an issue with this kind of message .

How was that user to know what to do? I clearly had to change the message – especially in an operational existing XenApp infrastructure.

I knew that the WI configuration could be changed to provide more meaningful information. But I remembered that in a previous BLOG Self Serving Configurations I spoke to pushing out a generic “We’re Down” error page in the event of a back end response failure.

This situation was different, however – since the WI did correctly send out a page with normal status codes.

What I thought would be more appropriate in this kind of situation was to tell the user who to contact, and to provide that user with all the details that the helpdesk would ask for. Specifically, I wanted the NetScaler to change the informational text to provide the contact information, the date and time, and which back-end server issued the response. That last piece was important, since this was a load balancing environment.

What I wanted to state was something like the text to the left.


Causing this message text to be changed in the NetScaler meant that I did not have to go back to reconfigure every WI system. It was another example of using the NetScaler to offload back end services and configurations. And I could do it without interrupting the applciation delivery services.

Three Steps to Do It for All Servers.

I had four WI servers. So I used a centralized NetScaler Rewrite functionality to insert the desired additional text into the page if the error message was present in the response stream from the back end WI server.

There were three NetScaler configuration steps:

  1. Create the Action (What to do),
  2. Create a Policy (Under what circumstances to do it)
  3. Bind the Policy (Against which application to check the Policy).

Lights, Camera, and ACTION!

The NetScaler Rewrite Action dialogue has a few options. While there are several ways to achieve what I wanted, I chose the REPLACE_ALL option. It seemed that this was the easiest because I could simply replace the standard WI issued text with my own. This facility also allowed me to add NetScaler system variables such as time and date, and the back-end server IP address.




So I used the NetScaler Graphical User Interface (GUI) and filled in the form:

The Name of the Action object, of course.

Then I specified that the NetScaler should look no further than 20K into the response.

Then I specified the replacement text as a string. I used some minor HTML formatting (We already know that I’m no web designer!) to break the lines.

And I also added the HTTP.RES.DATE and the SERVER.IP.SRC variables to provide the time, date, and back end server information.

In the Pattern box, I specified which text should be replaced.

And lastly, I added a comment. We all know from experience that this part would never happen in a production environment, right?

So the above Action tells the NetScaler what to rewrite as it scans the responses from the back end.







When is a Good POLICY!

The next step was to create a NetScaler Policy. This would be the trigger that invokes the Action.

A fairly straight forward dialog provides drop down lists and text boxes that are set to invoke the action at an appropriate time.

I gave it a meaningful name ErrorRewritePol.

Then I selected the previously created object from the Action drop-down list. This is fairly obvious.

To optimize the scanning, however, I picked a subset of the error message. With some experimenting, I noticed that the presence of the “no resources” was sufficient to invoke the Action. So I set that string as the selection criteria. This is a balance between extending the scan to the full character string versus preventing false alarms (invalid “hits”).

I also found that I had to look into 20,000 bytes of the response for the string. That’s a pretty deep scan. But knowing that the user interaction with the WI is limited, I knew that the added processing load in the NetScaler would be tolerable.

And, once again (rarely seen in production configurations) I added a comment.

So the above Policy tells the NetScaler when to look at a responses to see if it is eligible for rewite processing.

In a BIND!

While I was pretty proud of my handy-work – changing response pages – I realized that these checks should not be invoked on a galactic basis. Not even on a NetScaler system-wide basis! This logic was relevant only to the WI response traffic.

So I set the Bind for the Policy only to the WI Load-Balancing Virtual Server that provides access to the back-end WI servers. This was done simply. The self-explanatory graphic follows.






Rather subtly highlighted are two important elements in the Bind activity.

  1. In the Virtual Server object, I selected the Rewrite (Response) tab.
  2. The policy selected from the drop-down list was the ErrorRewritePol policy that I created in the previous step.

So the above Bind tells the NetScaler which application to scan for rewrite eligibility.

TaDa!

I reran the test using that orphaned user that had no AD group membership, and thus matched none of the group affiliations in the WI configuration.

This was the result.







Conclusions

Can an equivalent function be performed in the Web Interface configuration? Certainly. But that means changes to each instance of the WI server.

Performing this function, centrally, in the front-end NetScaler allows systems administrators to implement such changes dynamically, across the entire farm.

Additionally, the message can be easily changed in the event of a catastrophic error as appropriate.

So, the next time you have a need to override the behavior of an application, think about doing it in the front-end NetScaler.

In Closing

As usual, you comments are welcome.

Follow me at Twitter

Or send me email