Hopefully you are enjoying the numerous benefits of deploying XenDesktop 7 in your environment and having a great time using the troubleshooting and monitoring console – Director! I wanted to take some time to describe the most fundamental feature in Director – the user name search!!
For a Director Administrator, being able to easily get to the details of a user’s session/machine is of utmost importance. The “Search for users” control in Director UI is designed to exactly give this ability to administrators.
Helpdesk admins can find the search control on the Helpdesk landing page and rest of all administrators can find it on both the landing page as well as on the upper right corner of every page.
In XenDesktop 7, the scope of search is users. Admins can search for a specific user by typing a search token in the search box. The search token can be the beginning of either the user’s first name or last name or the display name or the windows account name.
For example consider a user below:
First name – Sai
Last name – Peyyeti
Display name – Sai Peyyeti
Account name – saip
The possible search tokens can be “s”, “p”, “sa”, “pe”, “sai”, “pey”, “saip”, “sai p”, “sai pe”, etc.
Director will display the above user for any of these various tokens. Apparently the bigger the search token the lesser the number of results as it would help Director isolate the exact user. The search results will look like “Display Name (Domain Name\Account Name)”
To help understand what Director is actually doing when searching for a specific user, let’s talk about what is happening behind the scenes. At the time of login Director creates a connection to the global catalog server of the administrator domain (who is logging into Director) as well as the global catalog server of the Director machine domain. In some cases both the user and machine domain will be same. For such a case there will be a single connection to the global catalog server. The reason for opening a connection to a global catalog is because a global catalog is designed to handle and respond to Domain Controller queries in a faster manner. Particularly in a multi domain scenario, it is faster to get information about domain objects from a global catalog server than from individual domain controllers.
When an admin types a search token, Director sends an LDAP query to the global catalog server. The LDAP query translates to this – Return all users whose first name or last name or display name or account name starts with the particular token. These results also come in sorted order (sorting is done based on account name) and are returned to the admin.
So many customers have asked, what if my Active Directory is a little complex and my XenDesktop deployment is not that straightforward? Director has been designed to provide customizations for such deployments as listed below. These are provided as configurable application settings in IIS for the Director webapp. You can use inetmgr to launch the IIS manager and go to the application settings of the Director webapp to make these changes. Note that you will need to restart the Director AppPool to make the changes into effect.
- Disable forest wide search – By default Director performs a forest wide search of the logged in admin and Director machine’s domains. In some situations it might not be necessary to get forest wide results and a domain wide search results might be enough. To achieve this, create an entry called Connector.ActiveDirectory.ForestSearch and set it to false in the Director Application Settings in IIS. This solution can also be used in a rare case where the search fails or takes too long because of sub-domains which are non-functional in a forest.
- Adding multiple domains for search – By default Director searches the global catalog of the logged in admin’s domain and Director machine’s domain. This can be extended to other domains that are not present in the forests of admin’s domain or Director machine’s domain. This can be done by appending coma (,) separated domain names to the entry called Connector.ActiveDirectory.Domains. e.g: (user),(server),domain1.xyz. The assumption here is that the forest of the logged in administrator domain is trusted by the forest of the additionally added domain if it is different. Director interprets the “(user)” text as “search in the logged in admin’s domain (forest)” and the “(server)” text as “search in the Director machine’s domain (forest)” and any remaining names (braces not needed) as “search in the xyz domain (forest)”. As mentioned above search is done on domain level instead of forest if Connector.ActiveDirectory.ForestSearch is set to false.
- Return lessor or more number of search entries – By default Director returns a total of 20 user search entries at max. Suppose if there is a need to increase this result count (e.g: if there is a difficulty in typing an accurate user name), this can be configured via the UI.GlobalSearchMaxResults entry. This value is set to 20 by default which is recommended as it has been arrived at based on extensive testing for optimal UI experience.
Hope this information is useful and also gives some insight into how Director search works.