This page refers to an older version of the product.
View the current version of the online Help.

User Personalization Architecture

Environment Manager User Personalization utilizes a three tier architecture.

In this section:

• Introduction
• Tier 1 - Client Endpoint
• Tier 2 - Personalization Server
• Tier 3 - SQL Server
• Azure SQL as a Service Compatibility

Introduction

Collectively, the components of the standard architecture are known as a site. Sites provide a logical grouping of users; for example, by area of business or geographical location. For organizations with more than one site, the same architecture is used for each site, linked via their SQL servers through replication.

It is not a requirement that each branch site has a dedicated SQL server. However, performance is improved as traffic is contained within the Local Area Network (LAN) and does not have to travel across the Wide Area Network (WAN).

In the diagram below, the system consists of two sites; the default site and an optional branch site.

The client endpoints on a site communicate with their Personalization Server every time one of the following events occurs:

• Logon - When a user logs onto a managed endpoint, the Environment Manager Package (AEMP) file is loaded. If user personalization is enabled, the user is connected to the Personalization Server detailed in the configuration. User, endpoint and software version details are passed from the endpoint to the server which determines the site and personalization group that the user belongs to. A personalization configuration is passed back to the client on the managed endpoint by the Personalization Server. This configuration file describes the personalization settings for the user and includes details of managed applications and certificates for the user.

  Windows Settings are synchronized and applied to the endpoint to complete the user personalization logon.

• Application Start - When a user launches an application on the endpoint, it is paused briefly to allow Environment Manager to perform the required virtualization actions.

  Details of the application are analyzed and Environment Manager checks to see if User Personalization is enabled and that the application should be managed. For non-managed applications, any policy configuration actions are applied and the application continues without User Personalization settings being managed.

  For those applications which are managed, a configuration file specific to the application is created which details the file and registry inclusions, exclusions and a subset of the Global Properties as configured in the User Personalization database.

  Environment Manager Policy Configuration is notified of the start of the process and any relevant Policy actions are replicated on the virtual cache.
  Whilst the application is running and the user continues to change user personalization settings within it, any changes are virtualized and written to the personalization cache on the endpoint, rather than into the physical registry or file system.

  For application groups configured in Environment Manager, the Personalization database is only synchronized when the first application in the group is started. Synchronization is not performed when the other applications in the group are launched.

• Application Stop - When an application is closed, the Personalization Server is notified and a copy of any modified personalization settings is stored in the SQL database. If the process is the last within a group to exit, or the last instance of a managed process of similar applications, synchronization of the cache occurs back to the server.

  If an application is closed when other applications in the same application group are still open, synchronization to the database is not performed. Only when the last application in the group is closed is the database synchronized.

  For more information see Application Groups.

• Logoff - When a user logs off any managed applications still running are stopped by Windows and the logoff completes as normal before the Environment Manager logoff screen displays. The application, desktop and certificate settings are synchronized with the database and the local virtual cache is cleared. Once this is complete the Environment Manager logoff screen is removed from display and the Windows logoff is completed as normal.

  If Local Cache is enabled, the local virtual cache is not cleared to enable the user to maintain their settings once disconnected from the corporate network.

• Configuration Poll - Changes can be made to user personalization configurations by administrators whilst users are logged on. A configuration poll is performed at a predefined interval which picks up any configuration changes and applies them to the managed endpoints. The polling interval is set in the console using the Advanced Settings.

The virtual cache on the endpoint is the root folder for all User Personalization data where virtualized files and registry settings are stored prior to synchronization with the Personalization database. The data for each setting and managed application is stored here and kept up to date by synchronization with the Personalization database.

The virtual cache is a hidden folder located at C:\AppSenseVirtual on every managed endpoint.

Each of the above events creates a synchronize request where the client ensures that the local virtual cache is up to date with the SQL database. Every time an application starts or stops, the software ensures that the SQL database and local virtual cache are synchronized.

Tier 1 - Client Endpoint

The client endpoint hosts the user’s logon session. Within the session is the Environment Manager software containing the User Personalization modules which monitor changes that the user makes to managed applications and communicates these back to the Personalization Server.

The client endpoints can be any combination of hardware and software that is capable of running a windows session:

• Standalone desktops, laptops and tablet PCs
• Terminal Servers
• Microsoft Hyper-V

Tier 2 - Personalization Server

The Personalization Server is implemented as an Internet Information Services (IIS) Website and acts as the broker between the endpoints and the Personalization database. It enables access to the database from multiple clients to be controlled from one place. The Personalization Server can verify the identity of the clients before processing requests so clients do not need to be added as users to the database.

Status Request

To test whether a Personalization Server is installed, running and to test the database connection, enter the following URL in your internet browser, replacing <SERVER> with the name of the required server.

http://<SERVER>/PersonalizationServer/

The status.aspx file for a server shows whether the server connection was successful and further details about the connection, database and server.

Load Balancing Status Request

If using a load balancer monitor to check the server status page (status.aspx) where the server is set to Windows Authentication, the monitor must provide Windows credentials in the HTTP headers or the server will respond with an "unauthorized" reply. As an alternative, use one of the following methods, appropriate to your setup should be used.

To check the health of load balanced servers use the following methods, appropriate to your setup.

IIS7 - Windows Server 2008 and R2

Use the following URLs in an internet browser, replacing <SERVER> with the name of the required server:

• http://<SERVER>/PersonalizationServer/dbmonitor.aspx - Checks the connection with the database. Returns "OK" if the database can be contacted and "FAIL" if it cannot.
• http://<SERVER>/PersonalizationServer/pingmonitor.aspx - Checks whether the personalization server address is reachable returning "OK" if successful. No response indicates an error.

IIS6 - Windows Server 2003

For IIS6, the SetMonitorAnonymousIIS6.vbs script must be used to set up dbmonitor.aspx and pingmonitor.aspx for anonymous access. For further details, contact Support.

Tier 3 - SQL Server

Holds information related to personalization sites and servers, users and groups, applications, endpoint configuration data and user personalization data.

Personalization Server data is organized and stored in tables on the SQL server in the following logical groupings:

• Personalization Data - Contains data relating to the user, including group membership details and controls the data for managed applications. Application data is updated here each time a managed application is opened or closed.
• Site Membership - Houses the Site Membership information which communicates details of which Personalization Server the user should be connected to. Once connected, configuration information is retrieved including details of includes and excludes for registry items and folders.
• User Group Assignment - Defines the group to which a user belongs which in turn controls which applications are managed for the user in addition to their Windows Settings.
• Authorized Users - Contains tables which control who is authorized to connect to the Personalization Server and what they are able to do when connected.
• Archiving - Stores the archive data from the Daily and Demand archiving SQL Agent jobs in two tables relating to Application Profile and Application Data archives.

• Auditing - Used to setup and configure the auditing events that are raised internally and control what and to where, events are raised. From this, the required alerts and reports are generated by the Management Center.

  See the Management Center help for further information.

• Managed Application Settings - Contains details of all registry and folder include and exclude paths for each application and application group.
• General Settings - Contains system and user defined global properties for key and value pairing including console version, timeouts and archiving information. Installation information including an upgrade history and is maintained by the Ivanti Server Configuration Portal.

SQL Server AlwaysOn and Mirroring

SQL Server AlwaysOn is the preferred SQL Server technology to support High Availability/Disaster Recovery scenarios and User Workspace Manager 10.x servers have been optimized to support this technology.

SQL mirroring is available for User Workspace Manager 10.1 FR1+ customers who are currently in the process of transitioning to Always On technology. For more information, see the User Workspace Manager help.

Azure SQL as a Service Compatibility

It is now possible to deploy the Personalization database as an Azure SQL database. Previously it was necessary to have an Azure virtual machine running Microsoft SQL server. This new feature means that you no longer need to use virtual machines to manage your SQL database in Azure. The steps required to prepare, configure and deploy a new or existing database into Azure are described in the following Ivanti Community document: DOC-73044

Configuration and management of the database continues to be done via the Server Configuration Portal (SCP) and we still support on-premises and Azure virtual machine SQL server installations.