Troubleshooting: Slow Logins with Environment Manager

Version 2

    Finding your baseline

    When it comes to login times we all want the same thing, speed! The faster the better! So when you come across users who are seeing slow login times it’s a pressing issue, it can often be tricky to determine the cause or where to start, especially if your environment is running layers of different technologies. This short guide will hopefully save you countless hours troubleshooting slow logins when using Environment Manager (EM).

    The first thing you need to do is find out what your baseline login time is. The baseline is the time it takes for a user to login when AppSense is disabled or not installed in your Environment, if you are unable to uninstall AppSense I would advise disabling the following service on an Endpoint.

    • AppSense Environment Manager User Virtualization Service

    Once the service is disabled, login to an Endpoint several times as a standard user taking note of how long each login took, collect these times and find the average, this will then provide you with a baseline login time. Comparing the baseline time alongside the average time of a login when AppSense is installed or enabled will tell you whether EM is slowing the login times down, and if so, by how much.

     

    Isolate the cause

    If you see that login times are greatly reduced when EM is uninstalled or the service is disabled, this would suggest a component of the EM is impacting your login times, in order to find out which component of EM this is you will need to begin your investigation with some basic isolation testing. It’s important to understand that EM has essentially two main components which could impact on your login times, these are Policy and Personalization. It’s very easy to isolate each of these components separately to see how they individually impact login times, to do this follow the steps provided below starting with isolation for Policy.

     

    Isolation for Policy

    To test whether the source of the slowness is due to Policy please follow the steps below.

    1. Open the Environment Manager Console (by default opening the console loads a blank/empty configuration)
    2. With the Blank Configuration loaded, navigate to the “Manage” tab and click the option “Personalization Servers”
    3. Enter the name of your Personalization Server(s) into the interface and click “OK”

    NOTE: This step only applies if you are using Personalization in your Environment

    1. Save this configuration by navigating to “File” and “Save/Save As”

    NOTE: If you are using the AppSense Management Center as your deployment method you can save the configuration in the Management Center. If you are not using the Management Center as your deployment method, you may want to Export the configuration as an MSI to install manually on an Endpoint (Please ensure any previously Installed configurations are removed first)

    1. Deploy this Blank Configuration to a machine via your chosen method i.e. the Management Center or manually

    Now the Blank Configuration with Personalization enabled is deployed to an Endpoint, login several times as a standard user taking note of how long each login took, once you have an average, compare this time against the baseline time and the average slow login time when your Production Configuration with Personalization enabled is applied.If you find the login times have decreased considerably compared when the Production Configuration with Personalization enabled is deployed, this indicates the Policy settings which are configured in the Production Configuration are causing the increase in login times, if so please review the section of this article titled “Policy is the cause” below. However, if the login remains slow this may indicate that Personalization is the cause, as such you will need to complete the Isolation for Personalization steps below.

     

    Isolation for Personalization

    To test whether the source of the slowness is due to Personalization please follow the steps below.

    1. Open the Environment Manager Console
    2. Open the Production Configuration which is deployed to Endpoints where slow logins have been reported
    3. With the Production Configuration loaded, navigate to the “Manage” tab and click the option “Personalization Servers”
    4. Remove your Personalization Server(s) from the interface and click “OK”
    5. Save this configuration by navigating to “File” and “Save/Save As”

    NOTE: If you are using the AppSense Management Center as your deployment method you can save the configuration in the Management Center. If you are not using the Management Center as your deployment method, you may want to Export the configuration as an MSI to install manually on an Endpoint (Please ensure any previously Installed configurations are removed first)

    1. Deploy this configuration to a machine via your chosen method i.e. the Management Center or manually

    As with the “Isolation for Policy” steps, an average login time will need to be gathered. With the Production Configuration with Personalization disabled deployed to an Endpoint, login several times as a standard user taking note of how long each login took. As before, once you have an average, compare this time against the baseline time and the average slow login time when your Production Configuration with Personalization enabled is applied.If you find the login times have improved compared when the Production Configuration with Personalization enabled is deployed this indicates that Personalization being enabled is causing the increase in login time, if so please review the section of this article titled “Personalization is the cause” below.

     

    Personalization is the cause

    During a user login Personalization will be restoring profile data captured in the users assigned Windows Settings Groups, if the profile data being restored is made up of a large number of individual files, like those pesky cookies!! Or the files themselves are considerably large, often you will find this is the cause of the slowness. One thing which can be ruled out as a cause for slow logins is Personalized application data, this is synced on use and as such will not affect logins. To troubleshoot Windows Settings Groups causing slow logins follow the steps below.

    1. Create a new Personalization Group
    2. Move this Group to the top of the Personalization Group list
    3. Add a Membership rule for a test user (1)
    4. Ensure no Windows Settings Groups are assigned to the new Personalization Group
    5. Login as the test user (1) several times, recording the time to login to collect an average (ignoring the first login time)
    6. Using a different test user (2) add them to your affected Production Personalization Group
    7. Login as the test user (2) several times, recording the time to login to collect an average (ignoring the first login time)

    If you find the average login times have increased considerably for test user (2), this suggests the data captured in one of the Windows Settings Groups assigned in the Production Personalization Group is the cause.To investigate further, begin by adding one-by-one the Windows Settings Groups assigned to your Production Personalization Group into the new Personalization Group, logging in several times between each change, noting whether the last Windows Settings Group to be added increases the login time.If you discover there is no significant increase in login time between the test Personalization Group and the Production Group, this would suggest an issue within the data the affected user has captured.

     

    A Windows Settings Group is the cause

    If a Windows Settings Group appears to be the cause, please follow the steps below.

    1. If the Windows Setting Group is a custom group (i.e. non default) review the Registry and Folder/File Includes. Begin removing each Include from the Custom Windows Settings Group one at a time logging in several times as an affected standard user, noting whether the last change improved the login time
    2. If the Windows Settings Group is a default group, this would suggest an issue within the data the affected user has captured

    Data is the cause

    If data captured in the Production Personalization Group appears to be the cause, please follow the steps below.

    1. Ensure you have a backup of an affected users Personalization profile
    2. Using Personalization Analysis, delete the user’s data for each Windows Settings Group one at a time logging in several times as an affected standard user per change, noting whether the last change improved the login time
    3. Once you find the Personalization Group whose data was causing the slow logins, you need to review the Includes for this group as you may be capturing extraneous data

    Policy is the cause

    When Policy is the cause it is almost always due to Actions set to run under the Logon triggers. However, in some cases the issue may lie with Actions elsewhere in the Policy. To troubleshoot which section of the Production Policy Configuration is the cause please follow the steps below.

    1. Disable all of the nodes active under the Logon Triggers in the Production Policy configuration, save and deploy the Configuration. Login several times as an affected standard user, noting whether disabling the nodes under the logon triggers improved the login time. If this did not improve the slow logins, begin disabling any other nodes listed under the remaining Triggers until the login time improves
    2. Once you have isolated the cause of the slow login to a particular Trigger, begin enabling the nodes under this Trigger, logging in several times as an affected standard user, noting whether the last change caused the login time to increase. You can use this method of enabling and disabling nodes and actions to isolate which action is causing the problem, once the action has been identified you can disable the action and/or review whether it could be optimized