Some more troubleshooting with AppSense EM tools

Recently I wrote a blog about a slow logon process that I could troubleshoot with the EM Tools (http://blog.raido.be/?p=752) This time I have a user who logs on but does not receive any of his stored profile settings. Obviously the problem is that the personalization does not work. So I got the EM tools out again, to discover what the problem was.

I am assuming that you already know where to find the EM tools and how to install it. But if you don’t, I suggest that you read my previous blog. After installation I started the debug logging and logged on with a copy of the account of the user that did not have any personalization. Then I opened the EMmon tool to analyze the configuration. The pre-defined option “View personalization server latency statistics” is a good option to choose:

environment-manager-monitor

And I quickly discovered that the first connection to the personalization server went wrong:

troubleshouting-appsense-em-tools

So let’s look at the details to discover what exactly went wrong:

httpstatuscode400

What is important in the above details?

  • Server URL = correct, so it did receive the configuration through the EM policy.
  • Result = failed
  • Configuration Request = It knows the personalization server and is requesting the configuration file (ProfileConfig.xml) to the personalization server.
  • Duration = 27ms, so that’s to fast to be a timeout.
  • Description = Incorrect function – HTTP Status Code 400. Mmm… let me Google that. And the result is: “The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.”
  • Time = 11:14:20

Obviously this is an error that happened on the IIS site of the server, so I go and look at the IIS log (default path for this is: C:\inetpub\logs\LogFiles\W3SVC1). It is important to know that the IIS logfile defines the date and time to always be in GMT. This behavior is by design. So, it’s summer, I’m in Belgium, conversion of 11:14:20 would mean that GMT is 9:14:20. After analyzing the IIS log on the Personalization Server, I discovered that the “anonymous” attempts always reach the personalization server, but give a 401 error (This is because I had disabled anonymous logons on the personalization server). But the named attempts only reach the IIS server when it is successful (there is never a failed attempt when the user credentials are not provided)

My Failed attempt:

2015-07-09 09:14:19 10.190.9.244 POST /PersonalizationServer/config.aspx – 80 – 10.191.101.13 AppSense+WinHttpClient 401 2 5 0

A successful attempt:

2015-07-09 09:47:10 10.190.9.190 POST /PersonalizationServer/config.aspx – 80 – 10.191.101.13 AppSense+WinHttpClient – 401 2 5 15
2015-07-09 09:47:10 10.190.9.190 POST /PersonalizationServer/config.aspx – 80 <domain>\tst2 10.191.101.13 AppSense+WinHttpClient – 200 0 0 46

I compared my test account with the failing account. After some research I discovered that the token size of the failing account was too high:

The account that does not work:

  • Domain local groups: 248
  • Global groups: 144
  • Universal groups outside the domain: 0
  • Universal groups inside the domain: 2
  • Kerberos token size: 12288

My test account

  • Domain local groups: 23
  • Global groups: 13
  • Universal groups outside the domain: 0
  • Universal groups inside the domain: 0
  • Kerberos token size: 2224

If you also wish to analyze your token sizes in your domain, I suggest that you use following article http://www.jhouseconsulting.com/2013/12/20/script-to-create-a-kerberos-token-size-report-1041

By default the maximum token size of Windows is 12000 bytes. You can alter this number by configuring the MaxTokenSize registry key, but I would not suggest it because it brings extra complexity and slows down the logon process. If you wish to know more about tokens and token size, there is a very interesting article on the website of Windows IT Pro: http://windowsitpro.com/identity-management/care-and-feeding-active-directory-security-access-token

In case your environment needs to work with larger token sizes, here is what you’ll have to do:

  • On your endpoint and Personalization Servers, set the registry key HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize (DWord) to a value between 12000 and 48000
  • On your Personalization Servers, set the registry key HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\MaxFieldLength (DWord) to a value of ((4/3) * MaxTokenSize)
  • On your Personalization Servers, set the registry key HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\MaxRequestBytes (DWord) to a value of ((4/3) * MaxTokenSize)
2016-12-11T18:05:39+00:00 June 1st, 2016|
SecureLink

SecureLink

X