Performance issues seen after upgrading to AM 10.1 Feature Release 1

Version 3



    After an upgrade to AM 10.1 FR1, you may see various performance issues with the Application Manager service enabled, such as:


    • Slow logons
    • General poor performance around file operations, especially noticeable in situations where there are a large number of IOPS.


    Through testing, you may find that you can resolve this issue through any of the following actions:


    • Disabling the "AppSense Application Manager Agent" service on the endpoint.
    • Disabling the "Application Access Control" feature within your configuration, found under "Manage > Advanced Settings > Functionality" within the console.
    • Disabling the "Change a file's ownership when it is overwritten or renamed".
    • Unloading the "AMFileSystemFilter" driver by running "fltmc unload AMFileSystemFilter" from an elevated command prompt.


    Also, you may have upgraded from AM 10.1 to negate this issue as described in the following article, with no improvement seen:


    Application Manager 10.1 - Renaming files takes 4+ seconds




    The original issue outlined in the knowledge article above was seen to be caused by VMWares' "vsepflt" driver, which is part of the vShield feature - and you will also note that the issue is resolved when running " "fltmc unload vsepflt" from an administrative command prompt.


    To improve the behaviour caused by this driver during logon, we have added code into AM 10.1 FR1 to negate this behaviour when either of the following settings are enabled in your configuration (Found in the console under "Manage > Advanced Settings > General Features"):


    • Ignore restrictions during logon
    • Ignore restrictions during Active Setup


    If either of these options are unchecked in your configuration, you may still see the same performance issues during logon and/or Active Setup respectively.


    Also, there will be no improvement to any performance issues seen after logon and Active Setup are complete, even with the two options above enabled.


    Development have investigated this issue and found that this issue is caused by unexpected behaviour within VMWares' "vsepflt", therefore if you are still seeing issues at this point we would recommend contacting VMWare support to investigate further.