Thursday, 10 December 2015

AppSense Management Center Best Practices

This post contains best practice guidance for implementing Management Center. It is not intended to be definitive guidance and should be used as a guideline for building and maintaining Management Center.

This post will contain the following sections:

  • General Guidance - providing some high level guidance
  • Configuration - providing guidance related to settings within the Management Center console
  • Conclusion

General Guidance

Single role servers (dedicated Management Servers) are preferred over servers hosting both Personalization and Management Server role. However small environments may opt to install both roles on two servers and use the failover lists to make Server 1 the primary Management Server and secondary Personalization Server and Server 2 the secondary Management Server and primary Personalization Server.

Wherever possible ensure a second server is implemented and listed within the Failover Servers list which will be used by endpoints if the primary server fails.

The biggest cause of ad-hoc issues, particularly in the early stages of an implementation are the fact that the license has expired. Always ensure a valid license is available and installed within the Management Center.

A configuration account and a service account are the minimum number of service accounts required to configure a Management Server. The configuration account must have DB_Creator and Security_Admin roles on the Microsoft SQL Server during the initial configuration. These roles can be removed once the environment has been configured. The service account requires no specific SQL Server roles assigned as the required database roles will be created and assigned by the configuration account.

The Service Account must be a member of the ManagementServerService role which is a database role created by the Configuration Account during the initial database configuration. This role must remain in place permanently.

Service account passwords should either be set to not expire (less secure) or a documented process be implemented to review and update the service account passwords.

Always ensure an Active Directory group is added to the Management Server and has the Server Administrator role assigned to them.

By default, the Management Center database is configured with with its recovery model set to Full. Unless SQL Mirroring or AlwaysOn is being implemented customers should set this to Simple.

Always ensure you have a verified backup that can be restored in the event of a failure or corruption. In the event that one is not available deployed agents and licenses can be recovered from however configurations, and particularly historic configuration, are more difficult to obtain. At a minimum ensure all configurations are regularly backed up.

In order to perform push installations of the Client Communications Agent (Also known as Deployment Agent), client access credentials are required. This account must be a member of the Administrators group on the endpoints that will be targeted as the account is used to copy a boot strapper into the Admin$ share on the client machine. In addition, the firewall must allow File and Printer sharing on the endpoint.


The AppSense Management Center is easier to manage and maintain with as few Deployment Groups as necessary. This is primarily because any change in configuration, auditing setting, etc will need to be configured on all other groups that the change applies to. For example, if a customer decides to implement 6 deployment groups and want to audit 9000 events the customer will need to enable this setting on 6 groups. If they later decide not to audit the setting or audit another they will need to make the change on 6 groups. That being said, sometime you just have to have 6 deployment groups. Typically the following items define the number of deployment groups required:
  1. Large numbers of endpoints - Customers should avoid managing more than 30,000 endpoints in a single deployment group
  2. Different platforms with different deployment settings - for example, customer deploying both XenApp and Laptops are likely to require different agent and configuration deployment settings as XenApp servers are unlikely to be rebooted outside of scheduled maintenance windows. 
  3. Different agent or configuration assignment - Customers may not be licensed to run certain products on certain platforms or may not wish to only deploy specific products to specific platforms. For example, a customer may want to deploy Performance Manager to its XenApp estate but not to its Virtual Desktop Infrastructure. 
  4. Different Support / Management Teams - A customer may have different teams managing different infrastructure and as such different configurations assigned to each. For example, a customer may have a Desktop team who managed Laptops and Desktops and a Citrix team who manage the XenApp infrastructure. 
Endpoint Polling should be set to an reasonable value. By default the Endpoint Poll is set to 1 hour with a 20% variance. This effectively means that every an endpoint will poll at startup and then every 48 to 72 minutes thereafter in case there is a configuration change. Majority of customers manage their configuration change using a change control process and as such there is no requirement for a device to poll every hour (give or take). In this case the poll could be increased to a much higher value which will ultimately have a positive effect on the Management Server. Best practice is to ensure that the poll is never set to less than 1 Hour in a production environment and irrespective of the poll value set a variance should always be implemented. 

The appropriate value for the upload poll is slightly more complex to determine. Increasing the poll period will result in a larger quantity of data being uploaded less frequently whereas decreasing the poll period will result in a smaller quantity of data being uploaded more frequently. A customer should determine what they intend to do with the auditing data and if there is a desire, and the manpower, to address events soon after they're received the customer should lower the upload poll. Conversely if there is no desire to address incoming alerts and they're intended for reporting purposes only there is no reason to upload them any more regularly than the default schedule. Regardless of the method chosen it is important to implement a variance to avoid a scenario whereby numerous devices are attempting to poll at the exact same time. High Priority events are uploaded to the Management Center immediately over HTTP/S and are controlled by a registry value (priority filter) on the endpoint.

The Native configuration option allows administrators to specify a local folder to store the configuration files. This setting is recommended for non-persistent VDI and provisioned XenApp servers that have a persistent vDisk associated with them. By configuring the configuration to be stored on a persistent vDisk the endpoint will not need to download a new configuration each time the endpoint boots up in the event that the deployed configuration becomes out of sync with the configuration installed on the base image. Additional security is included whereby the folder that the configuration will reside in will be modified to ensure local users cannot access the file. 

Agent and Configuration installations can be performed by the Management Center, and its client agent. The options associated with when these installations are performed can be controlled from the Installation tab of a deployment groups settings and are individual to each deployment group. These settings should be defined by the customer however the following should not be implemented:
  • Agent installation should never be configured for any non-persistent platforms (e.g. Virtual Desktop Infrastructure or Provisioned XenApp Servers) as this could result in an endless reboot loop. 
Avoid auditing high volume events (e.g. 9001, 9015) wherever possible. These typically provide little value and will prevent users provide seeing important events (e.g. 9000, 9023) as these will be hidden within all of the high volume events. In addition, the database will grow extremely quickly and become unmanageable. 

Use Latest Version should not be configured on any production deployment groups because this could result in a configuration being deployed accidentally and may result in inconsistencies within an environment. Instead a defined version should be implemented with the version number being incremented through a controlled change management process which includes roll back steps, etc. 

Membership Rules

Membership rules should be used to ensure endpoints are assigned to the correct deployment group on first registration. This will avoid a considerable administrative effort in moving machines to the correct groups later particularly in environments with multiple deployment groups. Customers implementing membership rules typically do so using NetBIOS name matches with wild cards to match devices to a group. An example can be seen in the screen shot below:

By default the Management Server will periodically discover computers from Active Directory. This functionality can be disabled by deselecting the Automatically discover computers setting within the Membership rules page. This is recommended for all customers except those looking to perform push installation of the Client Communications Agent from the Management Center. 


As with all best practice, it does not fit all scenarios. There are cases where ten deployment groups is essential as are there cases where high volume logs must be enabled. These should merely be used as a guideline where, in a perfect world, all would be adopted. 

If you would like to discuss any of the items above or have any items to add to the list please get in touch with me and I will gladly add them to the list.