XenApp 6 server in wrong worker groups


A XenApp 6 server may ignore a work group after the renaming the worker group


This is caused because the server fails to update the registry key with the worker groups it belongs to.


To verify the list of worker groups a server belongs to check the registry key HKLM\SOFTWARE\Wow6432Node\Citrix\IMA\WorkerGroups It contains a list with all the worker groups that the server is member of.


To ensure that the server recognizes the new worker group name; remove the server from the worker group, check the registry used in troubleshooting and wait for the worker group to be removed from the list, note that at this time the old name will be showing in the registry; if the worker group isn’t removed from the registry you can remove it manually.

Once the worker group isn’t present in the registry, add the server back to the worker group list. Wait for a few seconds and check the same registry key again; the correct worker group should be displayed now.

Servers not present in EdgeSight


When a new server is commissioned from a template/image, after booting it might not be displayed in EdgeSight or a server that was being shown disappeared in replacement to the newly commissioned server.


The symptoms above can be caused if the EdgeSight agent as the wrong company information, in the registry, or the server is trying to use a guid that is being used by another server.


The two key aspects to verify is if the server has the wrong company information in the registry and/or the GUID is duplicated.

Wrong company information

Verify that the registry key Company has the correct value.

On 32bit systems check HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\System Monitoring\Agent\EdgeSight, on 64bit systems check HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\System Monitoring\Agent\EdgeSight.

Duplicated GUID

If the registry key is correct, then verify that the server isn’t trying to use the GUID of another server. Open EdgeSight.ini located on “C:\Documents and Settings\All Users\Application Data\Citrix\System Monitoring\Data or C:\ProgramData\Citrix\System Monitoring\Data, depending if it’s Windows 2003 or Windows 2008.

Check that the SInstance used by the server isn’t assigned to another server. A way to find what are the GUIDs known to edgesight is to query its database

-- Lists servers with their department and guid
SELECT m.name, i.instid, d.name AS 'dept', i.[guid]
FROM [instance] AS i
LEFT JOIN machine AS m ON m.machid=i.machid
LEFT JOIN dept AS d ON d.deptid=i.deptid
ORDER BY d.name, m.name

This should give you and idea of what servers are in conflict, if it doesn’t the you need to check each server individually.


The solution depends on the problem noticed while trouble shooting. It can be one or both.

To correct a wrong company value open the registry editor expand the keys used in troubleshooting and edit the Company key, changing it’s value to match your environment.

If the server is using a GUID that is already taken by another server; then connect to the server, stop the Citrix System Monitoring and Firebird Server – CSMInstance services, then using notepad open EdgeSight.ini located on “C:\Documents and Settings\All Users\Application Data\Citrix\System Monitoring\Data or C:\ProgramData\Citrix\System Monitoring\Data and remove the value of SInstance; close notepad saving the changes and start both Citrix System Monitoring and Firebird Server – CSMInstance services.

NOTE: It can take up to 24 hours before the server is displayed in EdgeSight.

Fixing the template

The following is a set of recommended changes to the golden template used to provision server with Citrix EdgeSight Agent installed. I’m also assuming that the server is running Windows 2008.

1) Verify that the value of company in the registry has the desired value.
2) Stop the Citrix System Monitoring service.
3) Stop the Firebird Server – CSMInstance service.
4) Delete RSDATR.FBD located at C:\ProgramData\Citrix\System Monitoring\Data\
5) Edit EdgeSight.ini located at C:\ProgramData\Citrix\System Monitoring\Data\ and remove the value of SInstance.
6) Shutdown the server and create the template.

NOTE: These steps should be done before shutting down the server and creating the template.

Shadow permissions on XenApp6

On XenApp 6 non-admin users cannot shadow user sessions although permissions were given to the user at the farm level. This happens because the user doesn’t have Remote Control rights on the ICA listner on the server.

Changing permissions

Start the ICA Listner configuration from Start\Citrix\Administration Tools; note that the application takes a couple of seconds to start.

Once the ICA listener configuration has started, select the desired listener, ICA-TCP by default, and press Security.

From the permissions window for the selected listener press Advanced.

Once the Advanced Security Settings for ICA-TCP is open you will need to, add the security group and give it Remote control rights as follows. Press Add… to open the Select user, Computer, Service Account, or group window.

Type the name of the group, HELPDESK press Check Names to verify and then press OK.

Now from the Permission Entry for ICA-TCP window, verify that you’re setting the permissions to the right group, by checking the name and tick the Allow box for Remote Control and press OK.

Note: DO NOT tick any other boxes.

Once the Advanced Security Settings for ICA-TCP is active, verify that the HELPDESK group is in the list with Allow and Remote Control. Press Apply and OK.

Press OK to close any other window that was still open.

The changes take immediate effect on new connections and there is no requirement to restart services or reboot the server.