It’s Christmas – festive tips for AppSense administrators

Christmas is here again…it seems to come around much faster these days. Maybe it’s because I’m getting older. It’s not going to be too much longer now before I have to edit my bio page to stop describing myself as “thirty-something” – how depressing 🙂

Anyways, in the spirit of the season of goodwill to all men (and women), let’s quickly compile a short list of little tips and tricks to give you AppSense administrators out there something nice for the holidays! These are just a quick list of things that I have in my notes that don’t justify posts in themselves – hope some of them are useful to you.

1.  Sort out your Active Directory

AppSense sits almost at the top of the stack, when it comes to your combination of technologies. So like Citrix, it tends to be hyper-sensitive to sub-optimal configuration of lower-level technologies – like Active Directory. Think of how many lookups you do that depend on AD – I can guarantee it will be a large number. If your AD isn’t performing, then how on earth do you expect AppSense to run well?

Fortunately Carl Webster did a great presentation on how to optimize your AD for use with XenApp and XenDesktop, and a lot of the points he makes are equally applicable to AppSense infrastructure. You can download Webster’s presentation here, or alternatively watch him delivering it in full (in his Tennessee drawl).

2.  Do a review of your use of Stop If Fails

Stop If Fails doesn’t really do what it says on the tin. Really, a better definition of it would be “do not execute child nodes if this Condition fails”. You can find nodes that won’t execute because of Stop If Fails – even if you want them to.

Richard Thompson and Gary McAllister both wrote blog posts describing this behaviour. Read their respective posts here and here to get a fuller understanding of how it works, and review your use of it.

3.  Configure your enterprise auditing correctly

I will do a fuller blog post on this subject soon (together with some archiving and cleanup scripts), but ensuring that your auditing is sorted out correctly is a surefire way to avoid some pain. Recently, I was working on an AppSense implementation where the license had expired, and it was a good couple of days before I actually realized that the reason Personalization wasn’t working was because of this. If the auditing had been configured correctly, I would have seen the alert for it and saved myself some time.

Configuring audit events to forward to event logs and/or other alerting mechanisms can also ensure that you have good visibility of the health of the AppSense infrastructure.

4.  Use the available GPO for Personalization Servers

I still see a lot of environments where, in the absence of load balancing solutions, the Sites List in Personalization Server is still being used for providing failover. Since 8.3 of EM you’ve had the option to do this via a GPO instead, which is in my opinion a much more robust way of providing this functionality. You can filter the policy at the GPO level or even deploy it through EM Policy itself, giving a lot more control over how you provide Personalization Server failover lists.

The following (stolen!) diagram illustrates how the policy fits in with the processing order

The following options should be used with the GPO:-

Specify list of personalization servers – Specify a list of personalization servers for endpoints to connect to and use as a failover list. The AEMP configuration server list is no longer needed if this GPO is active – you can disable Personalization within the configuration.

Select Enabled and enter the required server name(s). Each server must be preceded by http:// or https://, and where more than one server is required, separated by a comma. For example, http://appsense1,http://appsense2

Bypass server site processing – Normally, initial contact is made with the server listed in the AEMP file. Once contact is made, the database rules are evaluated to determine which server the client should connect to. Enabling this option means clients ignore the database site rules and connect directly to the server determined by Group Policy.

Select Enabled to bypass server site processing.

5.  Disable unneeded agents

I’ve also lost track of the amount of deployments I’ve seen where, for instance, the customer has all three agents deployed to their endpoints – but they’re only making use of Environment Manager. If you don’t have a configuration deployed for some of the agents, and you’re not intending to do so in the near future, then it would make sense to remove – or at the very least disable – the unused agent involved. This can only make the performance of your endpoints better!

On the flip side, be careful when disabling other system services so that you don’t affect AppSense. I once saw an environment where all the laptops had RDS disabled, and AppSense really seemed to struggle in that configuration.

6.  Self-Heal for networked files

Not being able to self-heal files stored on the network has been a bit of a pain occasionally for me with some applications. You may think that because this limitation is listed in the EM Console itself, there isn’t a way around it, but there is.