Getting Started with Xendesktop 4 (Part 5)

If you would like to be notified of when Wilco van Bragt releases the next part in this article series please sign up to our VirtualizationAdmin.com Real Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:

Introduction

In the previous article we installed the required components for configuring our First XenDesktop Farm. We installed the Desktop Delivery Controller on the server, added the license file to the License Management Console and installed the Virtual Desktop Agent (VDA) on the client that will be our first virtual desktop. In this article we will configure the XenDesktop farm and corresponding components so at the end we have our first virtual desktop up and running and reachable by the end users.

Initial Desktop Delivery Service Console configuration

The first step we need to perform is the initial configuration of the administrative console of XenDesktop called Delivery Service Console. When you start the console for the first time (from the Desktop Delivery Controller server) the initial wizard will be started automatically. Check the box “Skip this screen in future” and continue with Next to perform the initial configuration wizard.


Figure 1: The first step in the initial configuration.

In the second dialog box you can select the components you would like to manage out of this console, because we installed all components on a single server we can select all available options.


Figure 2: Selecting the components that will be managed via the console.

Next you select the server which is hosting the Desktop Delivery Controller (DDC) role. Because we are running all components on one server you can use here “Add Local Computer” or use the Add button and specify the name.  You can add more servers if needed (and are available), but it is a best practice to use the console on the server and point to the same server.


Figure 3: Select the DDC to communicate between the console and the XenDesktop Farm.

Start the discovery by pressing the next button in the next window.


Figure 4: Preview of the Discovery.

The console will show all components and when that step is finished a new window will be displayed reporting that the initial configuration is completed.


Figure 5: Finishing the initial configuration.

After this initial configuration wizard it’s time to setup our first so called Desktop Group. A Desktop Group is an actual set of computers that can be assinged to a group of users. It’s possbile to create more Desktop Groups within one Farm. You could think of dividing the workstations with similar functionalities or a desktop group for a specific department. However in this Express edtion you can have a maximum of 10 desktops, so I will use one Desktop Group. From the console right click the Desktop Group icon and choose Create Desktop Group.


Figure 6: Create Desktop Group start-up.

The first window is just a informal informational window. Luckily you can check the box “Skip this screen in the feature”, so it won’t be displayed anymore if you create more Desktop Groups later.


Figure 7: The welcome screen of the New Desktop Group wizard.

XenDesktop supports two kind of virtual desktop deployed. The first method is called pooled. With this technique you define a group of computers which are all available for all assigned users. When a user connects to such a group the first available desktop will be assigned to that user. When the user log off any configuration settings are discarded (with the higher editions you can use Citrix User Manager to save/store such settings) and the virtual machine is brought back in his original state. So it’s available again to be assigned to a next user that would like to use a VM out of the pool. This technique looks close what Server Based Computing have been offering for so long, with the difference that this virtual machine is only for one user at the time.

The other scenario is called Assigned. In this configuration the XenDesktop administrator assigns a specific VM to a user in advance or when the user connects for the first time where he will be assigned to a desktop that will be his workstation. So when the user connects the second time (and later) he will be connected to the same virtual desktop again. In both situations the user connects always to the same virtual desktop.

In this part to the article series I will use the assigned option. I will assign the computer on first usage, so I can show you what happens with this option.

The dialog box offers a last configuration option called “Use Desktop Group for VM Hosted Apps”. This options is actually a feature of Citrix XenApp, which is using XenDesktop capabilities. For this artcile series this option does not apply. If you would like to now more about this option I would like you to refer to this article.


Figure 8: Selecting the assignement type.

In the next window you need to define which virtualization technology will be used to host the virtual machines. Citrix supports the three large hypervisors: VMware ESX/vSphere, Microsoft Hyper-V and logical XenServer. Support without a hypervisor is available via the None option, although you won’t leverage all advantages than of a higher edition of XenDesktop, however, for the free edtion there are not so many differences. In this part I will use the XenServer option because in the previous part we installed the XenServer as the hypervisor.


Figure 9: Selecting the assignement type.

When you have specified your hosting infrastructure, the DDC server then needs to have the ability to contact the hypervisor. Therefore you need to add at least one server in your hypervisor infrastructure (more are possible). I will enter the name of the XenServer previously installed and the root user with the corresponding password.


Figure 10: Specifying the host infrastructure details.

In the next window you need to add the virtual machines to the desktop group. If you have configured the hosting infrastructure correctly the wizard will search for virtual machines available on the hypervisor and you can select which ones you would like to add (in our example just one). If you have selected None in the previous window you need to specify which virtual desktops will be part of this Desktop Group by selecting the machines out of Active Dirctory.


Figure 11: Adding computers to the Desktop Group.

The next step is to specify which user can connect to the XenDesktop and will be assigned a virtual desktop when they connect.


Figure 12: Adding users to the Desktop Group.

After specifying the users you should label the Desktop Group. This name will be shown to the end-user via the several client connections, so label this group a logical name that users understand.


Figure 13: Naming of the Desktop Group.

Step 7 of the wizard offers the possibilty to assign a icon to the desktop group. Just as the previous configuration part this icon will be shown to the end users.


Figure 14: Specifying the icon for the Desktop Group.

The last step offers the possibility to disable the group initially so it won’t show up in the user’s directory. For example you can first communicate to the users that the group is available or configure other settings before you would like the users to connect. Selecting the option Configure Advanced settings for desktops in this group now would introduce two additional steps in the wizard. If you don’t select this option the group will be configured.


Figure 15: The last step or configure advanced publishing options.

When selecting the advanced publishing options two new dialog boxes are availble. Within the first one you can configure if the group is accessible via the Access Gateway and/or the other connections.


Figure 16: Configuration of connection types.

Within the last advanced configuration window you can specify the ICA encryption and the color depth support and advanced protocols (if necessary).


Figure 17: Client Options.

After the wizard completes, the desktop group will appear in the console. You should remember that both the assignment type and hosting infrastructure cannot be changed afterwards. In the figure below you will see that the virtual machine is available in the group and that the machine does not have a user assigned to it.


Figure 18: Desktop Group created and virtual machine displayed within this group.

Depending on your setup you need to add the XenDesktop farm to the Web Interface sites so the end users can connect to the infrastructure. If you have installed the Web Interface and the Desktop Delivery Controller on one server you don’t have to configure the Web Interface actually. This installation would configure the Web Interface automatically with a website that communicates with localhost (where the DDC is thus available). In other situations you need to add a XenDesktop Farm using the Citrix Web Interface Management. Since, I installed both components on the same server the configuration is already correct but I will show the minimal steps needed.

Therefore we start the Citrix Web Interface Management console and Create Site within the XenApp Web Sites.


Figure 19: Create Site within XenApp Web Sites.

First step is to set-up the IIS location by specifying the path and Name of the site.


Figure 20: Specify IIS location.

The next step is to define where authentication takes place. In this example we will use only a Web Interface, so authentication will take place at the Web Interface.


Figure 21: Specify Point of Authentication.

The next window is a review screen of the previous settings where you can go back to change the settings or move to the next step to create the actual site (I won’t provide a figure for this one). The next screen shows that the site is created and the next step is to configure the site (so we keep the option checked).


Figure 22: Site created and the option to configure this site now.
The next step is to specify the farm and the corresponding Desktop Delivery Controller (DDC) including the XML port (default 80) and transport type (HTTP).


Figure 23: Adding the XenDesktop farm to the Web Interface Site.

Next step is to configure the Authentication models. Several options are supported like pass-through, explicit, smartcard and more. For this article I will use the explicit option.


Figure 24: Configure Authentication methods.

You can restrict domains so that users don’t have to type in that field during logon or that only specific domain accounts can be used.


Figure 25: Domain Restrictions.

The following option configures how the Web Interface will look like. You have the choice between full and minimal, where logical the second one shows a limited interface.


Figure 26: Domain Restrictions.

The Web Interface can aslo be used by XenApp to stream application to end user devices, which can be configured in the next dialog box. For now the Online option is the best choice because we don’t have application streaming available within the Express edition.


Figure 27: Pulbished Resource Type

The last window shows again the settings which will be applied. By pushing Finish the web site is configured to be used by the end users to start a session to their virtual desktop. Of course the Web Interface includes many more settings but these irrelevant for this article.


Figure 28: Pulbished Resource Type

Conclusion

By configuring the Desktop Group and the Web Interface we are ready to start a session to the virtual desktop. However several more advanced settings can be set to improve performance. The next article will continue with setting up these advanced settings.

If you would like to be notified of when Wilco van Bragt releases the next part in this article series please sign up to our VirtualizationAdmin.com Real Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top