This article contains information about VDI-in-a-Box best practices for Active Directory, DHCP, and DNS Services.

Active Directory

There are several ways an administrator can ensure that a successful VDI-in-a-Box deployment is achieved when it comes to Active Directory. This article provides an overview of best practices for Active Directory, DHCP and DNS services.

Active Directory is not a requirement for VDI-in-a-Box as it can be deployed in Windows Work Group mode. However, Active Directory has many benefits including centralized management of users, groups, and security policies. VDI-in-a-Box does not require any changes to be made to any of the services discussed in this article. Using best judgment and determining the requirements for each deployment will help an administrator identify which of these recommendations are required.

Users and Groups

When using VDI-in-a-Box with Active Directory you should continue to manage users through Active Directory. Most of the users will already be members of AD Security Groups. This means you can simply add these security groups to VDI-in-a-Box and assign Desktop Templates to these groups instead of individual user accounts. VDI-in-a-Box allows an administrator to add both groups as well as users.

It is a good idea to add individual user accounts to VDI-in-a-Box instead of security groups when you are in a lab environment or test phase where only a few users will be accessing VDI-in-a-Box desktops. For a production environment with less than 20 users it is manageable to add users instead of security groups although it is not recommended. Active Directory is designed for central management and control of users, hence there is no need to manage users in two places.

VDI-in-a-Box 5.1 and later supports Active Directory default domain accounts and nested groups. You can now add Active Directory built-in security groups and user accounts to VDI-in-a-Box. This is a great solution if you plan to provide the same VDI-in-a-Box desktop template to all your users. Add domain users to VDI-in-a-Box and assign a desktop template to this group. You can also do the same for administrator, domain administrator and any other built-in accounts.

Nested Groups support is helpful when users are members of groups which in turn are members of other groups. When all the member users have access to the same VDI-in-a-Box desktop template(s) you can just add the main group containing all the other groups and user accounts. An example would be having an AD group called Sales. This group contains many member groups such as East Coast Sales, Midwest Sales, West Coast Sales. Each of these groups has members inside Sales, Field Sales, Sales Engineers, Lead Generation, and Channel Sales. Each of these groups contains multiple user accounts. Now, let us assume that you want to give the same VDI-in-a-Box desktop to all the sales employees, regardless of their location and specific role. You can simply add Sales to VDI-in-a-Box and assign a desktop template to this group. Now all the groups and user accounts under Sales will have access to this desktop template.

Virtual Desktops (Computer Objects)

Active Directory Computer Objects are created for each VDI-in-a-Box golden image and desktop template. Just like a physical computer each VDI-in-a-Box desktop requires a valid computer object and an account in the Active Directory for a trust relationship to exist and allow users to authenticate.

By default, all computers are placed in the Active Directory Computers container (with the exception of Domain Controllers). This also applies to VDI-in-a-Box desktops. It is recommended that a new Organization Unit (OU) be created for VDI-in-a-Box desktops. This allows for separation of virtual desktops and the ability to apply different group polices. VDI-in-a-Box desktops can be placed in different OUs at the golden image level. You can create different OUs and child OUs for each golden image if you desire. This is especially useful for Change Management and test environments.

You can specify the Distinguishing Name (DN) in the VDI-in-a-Box Golden Image Prepare step. For example, there could be a domain called company.com where you have created an OU called VDIdesktops. You would type the following DN into the OU field:
OU=VDIdesktops,DC=company,DC=com

VDI-in-a-Box will do the best to clean up Active Directory as computers are created and deleted to help reduce clutter and management effort. However, in some situations the compute objects may not have been cleaned up properly from Active Directory.

Group Policies

VDI-in-a-Box virtual desktops can have Group Policies applied to them just like any other desktop. Remember this when troubleshooting, as certain GPOs might interfere with VDI-in-a-Box virtual desktop behavior. For example, if you have a group policy that disables TCP ports 1494 and 2598, you will not be able to connect to desktops using HDX. The same applies for TCP port 3389 for Remote Desktop, or any other policy/setting.

To reduce problems and to prevent performance issues from occurring with VDI-in-a-Box virtual desktops, block inheritance of group policies that are not applicable. Use the best judgment to assure your virtual desktops are in compliance with IT and Security policies at your organization, but try to reduce the amount of policies being applied to the virtual desktops.

Most Group Policy troubleshooting can be conducted using standard Microsoft GPO troubleshooting steps and are not specific to VDI-in-a-Box virtual desktops. Tools such as RSOP (Resultant Set of Policy) and GPResult can help find the root cause to many Group Policy issues.

Forest and Domain Trusts

VDI-in-a-Box 5.1 now supports placing virtual desktops on a different domain other than where the user accounts reside. Prior to VDI-in-a-Box 5.1 you could only spec​ify one Active Directory domain for VDI-in-a-Box users and computers. For many users this new feature will not be applicable because there is only a single Active Directory domain for all computers and users, such as company.com. For some users the Active Directory forest or domain might have one or more trust relationships amongst different forests and domains. There are many reasons for doing this, primarily for security/isolation of different objects, but this is also useful when organizations want to share some data with another trusted organization.

For the purpose of VDI-in-a-Box you might have a scenario where there is one Active Directory Forest with multiple domains. A single domain, such as computers.company.com is used to store all computer objects, both physical as well as virtual, regardless of their location. A domain, such as users.company.com, has a trust relationship with domains, such as east.users.company.com and west.users.company.com. The actual user accounts are on the respective region’s user domains, but with properly configured trust relationship between the user domain and computer domain, users will be able to authenticate to computer objects residing in the computers.company.com domain.

In most cases these trust relationships are already established and functional, hence they will inherently work with VDI-in-a-Box. However, if you are setting up such trust relationships because of a VDI-in-a-Box deployment ensure that the trusts are configured properly per Microsoft documentation and best practices. As an example, users will not be able to authenticate if you establish a one-way trust relationship in the wrong direction.

Dynamic Host Configuration Protocol

VDI-in-a-Box requires DHCP for the virtual desktops to acquire IP addresses. You can provide the VDI-in-a-Box servers static IP addresses but the DHCP requirement is still applicable to the virtual desktops. In many cases, no DHCP changes need to be made to accommodate for a VDI-in-a-Box deployment, but these are some tips to ensure a smooth deployment.

Provide the VDI-in-a-Box servers and desktops their own VLAN to separate them from other machines. Aside from the security benefits, this allows you to make changes to DHCP and other services without affecting other computers on the network. This is not a requirement but more of a best practice recommendation to be followed whenever possible.

You will also want to change the DHCP lease duration. For Microsoft Windows Servers with the DHCP role, the default lease duration on a wired network is 8 days. If you have a big enough address space to accommodate for desktops being refreshed and acquiring new IP address this will not be a problem. However, if you either need to share the VLAN with other desktops or have a small address space, you might end up running out of available IP addresses. It is perfectly safe and actually recommended to reduce the IP address lease duration to a very short time such as a few hours. There is no specific time that works best for all environments hence use best judgment.

VDI-in-a-Box works with any DHCP server, not just Windows Servers with the DHCP role. Many users, use a Windows Server with DHCP services which integrates with other important roles such as Active Directory. However, VDI-in-a-Box supports other DHCP servers as well but you must take note of the DHCP capabilities. For example, if you have a consumer-grade router/switch it will have DHCP services but just the bare minimum and you cannot configure DHCP options, search domain and so on. These options are required in order for desktops to contact and join an AD domain. Most enterprise-grade switches and routers support these DHCP options and allow for desktops to join AD domains. There are also open source soft routers, such as pfSense, which can be used as a DHCP server. Again, if the server supports the required DHCP options for computers to join a domain it will work with VDI-in-a-Box.

Following is an example which demonstrates how to change the default lease duration on a Windows 2008 R2 Server:

1. Log on to the Windows Server and open Server Manager.

2. Expand DHCP Server > Domain > IPv4.

3. Right-click the Scope you want to modify and select Properties.

4. Change the Days | Hours | Minutes as required and click OK.

Domain Name System

VDI-in-a-Box desktops can be accessed using the Citrix Receiver, a web browser, or Java client. As with any other service you might want to provide an easy method to remember the name so users can access the available resources. There are multiple ways by which you can implement DNS.

If you are using VDI-in-a-Box 5.0.x or earlier without the Virtual IP feature you can use the DNS Round-Robin method. Simply create an A Record for each VDI-in-a-Box server IP address. This will work when your VDI-in-a-Box servers are functional, but DNS does not recognize the server health. So a failed server will result in some users being prompted with error when trying to access the logon page. You must manage these records as you add or remove servers from the grid.

VDI-in-a-Box 5.1 allows you to configure a grid-wide Virtual IP (VIP). This means that a single IP address can be used for user connections and to provide High Availability (HA) for users. Without a VIP you would typically create several A Records in DNS to point to a single DNS hostname, such as, vdi.company.com, to the VDI-in-a-Box server IP addresses. This method works but does not provide real HA because DNS does not monitor server health. The VDI-in-a-Box VIP provides HA and will change to a functional VDI-in-a-Box server if the original server listening to the VIP fails. This means you only need to create one A Record in DNS and point it to this VIP.

Following is an example which demonstrates how to use the VDI-in-a-Box Grid-Wide VIP.
Note: Only one DNS entry must be made pointing to this VIP.

VDI-in-a-Box Grid-Wide IP address found in the Advanced Properties menu:

DNS Manager on Windows Server 2008 R2:

You can also use the VDI-in-a-Box Java client on supported client devices for client-side HA. The Java client holds a list of all the VDI-in-a-Box server IP addresses in a grid. When a user connects, it will attempt a connection with the first IP in the list. If the first connection times out, then the Java client will try the next VDI-in-a-Box server until the user can authenticate. The Java client automatically updates the IP address list as VDI-in-a-Box servers are removed or added to the grid.

The Java client is accessible using a VDI-in-a-Box IP address, DNS hostname, or even the Grid-Wide Virtual IP by launching the link https://VDIIP/dt/vdiclient.jnlp or executing a command using Java Web Start. The following is the Java Web Start command:
javaws https://VDIIP/dt/vdiclient.jnlp. 

Note: VDIIP in the URL can be either the IP address of the VDI-in-a-Box Server, the DNS hostname of the VDI-in-a-Box Server or the Grid-Wide Virtual IP.

VDI-in-a-Box Java Client Logon Screen:

The preceding solutions, especially the VDI-in-a-Box grid-wide Virtual IP, meets the requirements of most users. However, you can also use a NetScaler with the Load Balancing (LB) feature to create a LB virtual server and add each VDI-in-a-Box IP as a service within this LB virtual server. The NetScaler LB uses a monitor to verify the health of each VDI-in-a-Box server and will not send any user requests to a particular server if the health check fails. Similar to the VDI-in-a-Box Grid-Wide VIP, only one DNS entry must be made which will point the DNS name to the NetScaler LB’s virtual IP. You can refer to NetScaler documentation for details on configuring the Load Balancing feature.

The following is an example of NetScaler appliance with a LB virtual server. The LB VIP is 10.207.83.138 and a single DNS entry would point vdi.company.com to this IP. The LB virtual server consists of each VDI-in-a-Box server in the grid and monitors their health.