Deleting Agents

At Administration > Agents, you can delete the Agents in your environment.

Deleting Agents can be useful if Agents have become obsolete or if they, for some time, fail to synchronize with a Datastore in your environment. If you delete an Agent, but it manages to re-establish a connection to a Datastore in your environment, it will automatically be included again in the list of Agents.

  • The Agents Overview node shows a read-only overview of all Agents and their settings.
  • If you use identification method MAC address of the first enabled network interface and an Agent has multiple network cards, Workspace Control will use the MAC address of the first enabled network card, based on the order as defined on the agent by Microsoft Windows. You can find this order in Microsoft Windows by clicking Start > Settings > Network Connections > Advanced > Advanced Settings.
  • When using Workspace Control in combination with Citrix XenApp/XenDesktop 7.x, the XenApp version and Server farm columns in the Agents node and Agents Overview node will only contain data if the Agent is a member of a Citrix Delivery Group.
  • The FQDN column displays the Fully Qualified Domain Name, once the option Use computer's FQDN instead of domain\computername in Logs and Usage tracking has been enabled at Advanced Settings in the Setup menu.
  • The columns AppGuard version, NetGuard version, RegGuard version, ImgGuard version, and WebGuard version in the Agents node and Agents Overview node reflect the internal driver versions that Workspace Control uses. These version numbers can be used for troubleshooting purposes, should issues arise in your environment following an upgrade or downgrade or after installing a revision.
  • The Synchronization status column in the Agents node and Agents Overview node shows when the last synchronization of an agent took place and whether this was successful.
  • Licensing information is always updated immediately, irrespective of the settings that you specify.
  • When using Relay Servers, we recommend creating separate Workspace Containers for each subsite with different Relay Server lists. This way, it is easy to identify to which Relay Server an Agent or group of Agents normally connects.
  • An Agent can connect directly to the Datastore OR it can use Relay Servers.
  • An Agent configured to connect to Relay Servers will never connect to the Datastore directly. If it cannot connect to a Relay Server, it will use information stored in its local cache. An Agent configured to connect to the Datastore directly will never connect to Relay Servers. If its connections are not available, an Agent will use information stored in its local cache.
  • The Push change information option has been introduced in RES ONE Workspace 2015. To use this option successfully, all components must be running this version or higher.
  • On the Agents node, the value for Run Workspace Composer will not change when setting the registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell to pwrstart.exe or pfwsmgr.exe.
  • In VDI environments that use a non-persistent/pooled model, and where the Workspace Control Agent cache is stored on a persistent disk, most likely the latest versions of the UpdateGUIDs and Workspace Control policy settings are not in the registry of the golden image/template. Therefore, the cache will be updated with information from the Datastore or Relay Server, even though the most recent versions of the cache files are already present in the Workspace Control cache on the persistent disk. The update causes I/O load and network traffic. With the registry value LocalCacheOnDisk it is possible to make the cache independent of the Operating System's (OS) registry. Setting this registry value will convert the UpdateGUIDs and policy settings automatically from the OS' registry to two new XML files in the Workspace Control DBcache folder on the persistent disk: UpdateGUIDs.xml and Settings.xml. See LocalCacheOnDisk for more information.