Tuesday, 26 March 2013

Detailed overview of AppSense DesktopNow Components

Several of my posts talk about various components within the AppSense DesktopNow Suite. In the interest of not having to re-type them each time this post will serve as a high level overview on the DesktopNow suite.

This post does go into a little more detail than most would need but it should serve as a good basis to pull all other posts together.
AppSense Management Server (AMS)

The AMS is a Microsoft IIS server that manages and maintains Agents, Configurations, Licenses and provides auditing and reporting capabilities. The CCA is responsible for communication between the endpoint ans the AMS.

All network communication between the endpoint and the AMS uses standard http ot https. Agents and configurations use Microsoft Background Intelligent Transfer Service (BITS) to transfer agents and configuration files to endpoints. As a result environments with BITS restrictions may experience performance issues when deploying agents and configurations to endpoints. This must also be taken into account when designing the load balancing infrastructure that is used for the AMS. Typically session persistence should be enabled to ensure clients maintain the connection to a single AMS server for the duration of the BITS transaction.

The AMS is typically a stateless server that stores no user data and can easily be replaced with another in the event of server failure.

AppSense Personalization Server (APS)

The APS is a Microsoft IIS server responsible for user personalization data. Personalization data is the actual registry keys and values as well as files that make up the users profile.

The EMA is responsible for communication between the endpoint and the APS. All network communication between the endpoint and the APS uses standard http or https and files below 2kb are compressed to minimise the impact on the network.

The APS which an endpoint or user should connect to is specified in one of four locations, namely: Computer Group Policy, User  Group Policy, Computer Registry or the Environment Manager Configuration file. See my previous post titled Specifying Personalization Servers for more information on these.

The APS is typically a stateless server that stores no user data and can easily be replaced with another in the event of server failure.

AppSense Client Communications Agent (CCA)

The CCA is an agent which runs as a Windows service on all managed endpoints. The CCA is only required if the AMS is used within an environment.

The AMS is specified during installation of the CCA using the web_site parameter. On connection with the AMS the membership rules will be evaluated to determine the deployment group the client should fall into. The client then registers against that deployment group and the following values are written to the clients registry:
  • machineid - A unique identified for the endpoint.
  • groupid - The unique identifier for the endpoints deployment group.
The endpoint will connect to the AMS at regular intervals based on the machine poll and upload poll periods defined within the endpoints deployment group. 

At machine poll the endpoint will send a list of installed packages to the AMS which will be compared against what is assigned to the deployment group any variances will be downloaded and installed as per the configured installation schedule. 

At upload poll the endpoint will upload a compressed file containing all events that have occurred that are configured within the deployment groups enterprise auditing configuration. Care must be taken when defining upload poll periods and the associated enterprise auditing configuration as these could have a significant on the scalability of the AMS.

AppSense Application Manager Agent (AMA)

The AMA is an agent which runs as a Windows service (AppSense Application Manager Service) on all endpoints which have AppSense Application Manager installed.

The AMA is primarily responsible for:
  • Application Entitlement (Whitelisting and Blacklisting)
  • Windows Privilege Management (User Rights Management)
  • Device Based License Control
  • Trusted Ownership Checking
  • Application Network Access Control
Application Manager has a number of hooks which it uses to hook into processes but primarily relies on  the AppInit_DLLs registry key. There are some limitations to this method which include:
  • No control over what Application manager is hooked into
  • Doesn't get pulled into all processes
  • Potential interference from other vendors
The AMA historically had no server backend however AppSense recently introduced a feature called Rights Discovery Mode that allows endpoints to publish information on what applications require administrator rights back to a server. The server is not described in this article as it differs from the AMS and APS and will be described separately in a future post. 

The AMA relies on a local configuration file which is stored in the configuration folder under:
  • %ALLUSERSPROFILE%\AppSense\Application Manager
AppSense Environment Manager Agent (EMA)

The EMA is an agent which runs as a Windows service (AppSense User Virtualization Service) on all endpoints which have AppSense Environment Manager installed.

The EMA is primarily responsible for:
  • Applying Environment Manager Policy actions configured within the Environment Manager configuration file.
  • Managing the Windows desktop look and feel (Desktop Settings)
  • Managing user certifications
  • Managing user application customisations
Environment Manager historically used AppInit_DLLs to inject PVCLoader into processes to determine whether they should be managed or not. If an application was managed it would inject PVC.dll into the process. When Environment Manager 8 Feature Release 1 was introduced some time ago AppSense moved to a driver called AsVfxLdr.dll. 

When a process starts EMLoader.dll is injected into the process which informs the EMCoreService that an application has started. EMUser then checks the ProfileConfig.xml file, which is downloaded at logon, to determine whether the application is managed or not. If the application is managed PVC.dll is injected into the process and all included registry keys and folders which are written to will be captured within the AppSenseVirtual cache. When the user exits the application (and no grouped applications are still running) the data is uploaded to the APS. When the user re-launches the application the data will be synchronised down again. 

The AppSenseVirtual cache can be moved by modifying the dbo.Global table within the Personalization Server database.

By default an archive is taken daily at 1am and 5 archives are retained. An archive is taken if an application has been opened on a given day so if a user is off work for two weeks they will not be included in the daily archive task. The archive is invoked by the AppSense Background Service which is also used when performing upgrades, etc. Default archive times can be changed by modifying the DailyArchiveStartTime and NumberOfArchivesToKeep entries in the Personalization Server global settings table.

One thing worth noting is that Environment Manager 8 feature release 1 saw the introduction of a new logoff mechanism where AppSense reverted to using local group policy to start a batch file which performed all logoff actions. This introduced two potential issues:

1. Microsoft Security Templates disable processing of local group policy by default.
2. The file could be edited if a user had sufficient access to the correct folder.

The EMA relies on a local configuration file which is stored in the configuration folder under:
  • %ALLUSERSPROFILE%\AppSense\Environment Manager
AppSense Performance Manager Agent (PMA)

The PMA is an agent which runs as a Windows service (AppSense Performance Manager Service) on all endpoints which have AppSense Performance Manager installed.

The PMA(PMAgent.exe) is primarily responsible for:
  • Monitoring and dynamically managing resources
When a user logs on PMA creates a helper process called PMAgentAssist within each session. PMAgentAssist is responsible for the following:
  • Informing PMA of any minimised, foreground and background states
  • Informing PMA when the session is idle
  • Informing PMA when the session is locked or unlocked
  • Per Application memory usage
Performance Manager includes two filter drivers; PmOptimizer.sys and PmUserMem.sys. These drivers are responsible for:
  • redirecting to optimized dlls and disk scheduling
  • stopping any new application launches is a user has exceeded their user memory limit has been exceeded.
The PMA relies on a local configuration file which is stored in the configuration folder under:
  • %ALLUSERSPROFILE%\AppSense\Performance Manager
I'm not going to go into much more detail than this but if you still require more information feel free to reach out to me.