Monday, 23 December 2013

It's Christmas - some festive tips and tricks 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 did 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

The following options should be used:-

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 overridden by the list created.

Select Enabled and enter the required server name(s). Each server must be preceded by http://, 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.


The problem is simply permissions-related - the Self Heal Action runs as SYSTEM and therefore doesn't have network access. In order to get around this, you can add computer accounts to the ACL for the network share (and files) you wish to self-heal. You can use the Domain Computers group, a custom Computer Group, or simply individual accounts if that suffices.

7.  Automation in the Server Configuration Utility

I touched on this briefly in a previous post, but since AppSense released Management Center 8 FR 5 you can now manipulate the SCU through PowerShell. This is handy for those of you cloning, provisioning or requiring automation around the back-end servers. It is covered in detail in the Management Center 8 FR 5 Scripting Guide (may require login).

8.  Avoid Trusted Ownership issues in Application Manager

When you configure the list of Trusted Owners in Application Manager, be aware that nesting does not apply. So, for instance, if user joe.bloggs is a member of the BUILTIN\Administrators group, and the BUILTIN\Administrators group is listed as a Trusted Owner, this does not automatically confer Trusted Owner status to joe.bloggs. Therefore any files explicitly owned by joe.bloggs will not be allowed to execute, and Rules Analyzer will detect a Trusted Owner violation.

You must add each Trusted Owner explicitly to the list that you wish to configure.

9.  Disable Data Collection where it is no longer necessary

The Data Collection feature of Personalization Server is very handy. But I've seen a lot of  instances recently where it has been left turned on once the application discovery phase is finished. Data Collection puts an overhead on your Personalization database performance, so if you're not using it any more, turn it off! You can always turn it back on when needed, or better still, use a separate Personalization Group.

10.  A little Christmas gift

It wouldn't be Christmas without a little gift of some sort - so here (courtesy of Aaron Parker, who originally passed this across to me last year - thanks Aaron) is a list of Windows profile locations to help you out with Personalization. It's by no means comprehensive, but it should prove useful in some situations. Here's the link:-



So, that's it from me until after Christmas (although as I am on holiday, I will no doubt be putting out some material between Christmas and New Year, in order to avoid the streams of relatives). Hope some of these little tips are useful to some of you out there in your quest to better support your AppSense users!

Merry Christmas!

1 comment:

  1. James,

    Great article. 10 things to check in the new year !

    Best wishes for you and your family.

    ReplyDelete