Installing and Configuring Citrix XenApp/XenDesktop 7.6 (Part 5)

In this final article in this series we will look at some advanced configuration options of the XenDesktop Infrastructure.

Introduction

In part four we configured a Delivery Group and discussed the setting which can be configured. With the creation of the Delivery Group, the XenDesktop infrastructure can be used by the end-user to start a Desktop or Applications. We will start with showing users starting a Desktop or Application on the XenDesktop infrastructure in this part. We will also go through some more advanced configuration options of the XenDesktop Infrastructure.

 

Connecting to the XenDesktop Infrastructure

In the previous articles we configured XenDesktop in such a way that it’s ready to allow users to start-up a session on the VDA. Connections are set-up via the Citrix StoreFront component. This can be done by configuring the Citrix Receiver to contact the StoreFront server or entering the URL of the Receiver for Web. For this article I’m using the last option, so I open a browser and enter the URL. A page will be shown where you need to enter the credentials and password.

Figure 1: The start site of the Receiver for Web connection option
After logging on, the user will be presented with the Desktop and/or Published Applications which were assigned to his account. When the user has a Desktop assigned to his account, an icon on the Desktop tab will be shown (by default this is shown first, but this can be adjusted in the StoreFront configuration).

Figure 2: Desktop tab of the Receiver for Web
When the user has (also) Applications assigned, those will be shown on the App tab. Different from the Desktop tab the icon(s) are not shown directly. The user (by default) needs to add the application to this tab. The user needs to choose the + sign at the left part of the site.

Figure 3: Apps tab of Receiver for Web
After choosing the plus sign a new pane is shown, where the user can select the applications he would like to be shown on the Apps tab so he can start those applications.

Figure 4: Selecting applications to be shown on the Apps tab.
By clicking the icon on the Desktop of the Application the session will be set-up. In figure 5 you will see the full Desktop of the end-user connected.

Figure 5: Citrix XenDesktop desktop session
While we have a user connected to our XenDesktop infrastructure, the basic installation and configuration is finished. It’s out of scope of this article to describe all the possible configurations options in a real detailed level, however I would like to go one step further than the basic configuration we have done up till now to touch some additional configuration steps.

Citrix Policies

Since XenApp 6.x you can configure Citrix policies via two methodologies and these options are still available in XenDesktop 7.x. You can configure policies via the management console or via Group Policy Object in Active Directory. Again there is no good or bad way; it depends on the infrastructure and the organization which makes more sense. The settings are exactly the same and also the way they are applied is the same. Settings are available in two flavors: user settings and machine settings. In previous version those were shown separately, however in XenDesktop 7.6 they are both shown and you define later if only one flavor should be applied. I see both advantages (you are not searching between the two policy flavors for a specific setting) as disadvantages (configuring the filters for the policies will need more attention). One last tip is to only select the version and VDA type you have in your environment, so not applying policies are not shown anymore. As mentioned earlier it’s too much to discuss the policies in more depth. If this is of interest to you let us know so we can write an article about policies as I did in the past for one the previous Citrix products.

Figure 6: Citrix XenDesktop policies

Logging

In XenApp 6.x version logging was introduced. In those versions the option was disabled and you need toed enable and configure it manually. In XenDesktop 7.x the option is enabled by default. However you may want to adjust the default configuration. This can be done on the Logging component in the Studio Console like changing the database (specify a specific logging database), the actions which can be executed when the database is not available or completely disable logging. In the same windows the logged actions are shown and reports can be created.

Figure 7: Citrix Logging

Delegation of Control

Citrix products are well known of their advanced delegation of control. XenDesktop 7.6 shows that this it still the case. Within the product, already 6 different roles are created but you can add additional roles. The role can be fully adjusted to your organization needs. Secondly you can create scopes. Per scope you can configure which Machine Catalogs and/or Delivery Groups belong to this scope. Via scopes you can divide the XenDesktop infrastructure in multiple instances for administration purposes. The roles and scope come together at the administrator tab. Here you specify which AD user or group will be assigned to which scope with which role. In other words you can really create a very detailed delegation of control within XenDesktop.

Figure 8: Citrix XenDesktop Delegation of Control

Controllers

In this part of the Studio console you can check if the Controllers are updated and in the case a controller has failed you can remove the Delivery Controller out of the XenDesktop database.

Figure 9: Citrix XenDesktop Controllers

Hosting

Within Hosting you can configure your hypervisor platform. In most cases you will configure this component when you are using the Machine Creation Services (MCS) feature. MSC uses the information specified at this component to create and maintain the virtual machines. XenDesktop support all important hypervisor platforms including the corresponding management tooling. Logically you need to specify a user account that has the required permissions to execute the actions on the hypervisor layer and you need to specify the corresponding network and storage requirements. It will also be used if you enable Power Management options within the Citrix Policies. If you don’t use MCS or Power Management you do not need to configure this component even if your environment is running on a virtualized infrastructure. For example when using PVS (Provisioning Services) and do not want Power Management you can leave this part empty.

Figure 10: Citrix XenDesktop Hosting

Licensing

The Citrix Licensing component is a separate installation. As mentioned in the first part you can install this also on a Delivery Controller. Whether you have installed it separately or on the same server in previous (XenApp) versions you need to start the specific Citrix License Server console to see licensing information. In XenDesktop 7 this kind of information is also shown in the Studio Console. You can also add licensing, change the license server or change the product version out of this part. I personally really like that this information is shown in the same console.

Figure 11: Citrix XenDesktop Licensing

StoreFront

Maybe you would expect that at this part you can configure the StoreFront configuration, but you should use the StoreFront Console for this. Within the Citrix Studio console you can “only” specify StoreFront Stores. The configured Store can be used to assign to a Delivery Group. At this Delivery Group the Citrix Receiver will automatically be configured based on the selected StoreFront URL. The actual StoreFront URL is stored within the StoreFront component. Assigning a StoreFront URL is useful in scenarios where there are more Machine Groups or an old environment which host another (set of) application(s).

App-V Publishing

Figure 12: Citrix XenDesktop App-V Publishing
The last component in the Studio Console is App-V Publishing. I already touched it quickly earlier. Here you can specify your App-V infrastructure (Management and Publishing server). If you have configured your App-V infrastructure, XenDesktop can contact the App-V infrastructure to automatically create Published Applications based on App-V 5 packages. If using Published Applications in combination with App-V this is a real nice feature. It does not configure an App-V client installed in the XenDesktop VDAs, this needs to be done via the App-V 5 PowerShell scripts.

Figure 13: Adding App-V applications using App-V Publishing

Citrix Director

For those that are familiar with earlier releases of XenApp, notice that the Citrix Studio console does not contain any administration actions (think of user sessions, remote assistance and so on). For this kind of task Citrix created the Citrix Director. The Citrix Directory is based on a website, so you don’t need to install a client to use this. Just type the URL http://FQDN/Directory into a browser. After entering the user information the daily activities can be executed out of this console. On the Citrix blog a very good article series about the Directory is published, so please check that article series for all the details about Citrix Directory.

Figure 14: Citrix Directory

Conclusion

With this fifth part we are finalizing the article series about Installing and Configuring XenApp 7.6. We started a session as a user to show that the basic configuration was completed. Secondly we briefly touched some more advanced configuration options available within XenDesktop. Some of those configuration options can be discussed in much more detail, but that was the scope of this article series. If you are interested in more detailed information let us know, so we know what interests you to write more in-depth articles about XenDesktop.

Installing and Configuring Citrix XenApp/XenDesktop 7.6 (Part 4)

In this part we will continue with the basic configuration, starting with creating a Delivery Group.

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

 

Introduction

In the third part of this series we started with the installation of the VDA component. The machines running this VDA component are the actual machines the user will execute their (daily) tasks on. After the VDA installation part, we started with the basic configuration of a XenDesktop site by configuring a Machine Catalog.

 

Creating a Delivery Group

When a Machine Group is available it is possible to create a Delivery Group. A Delivery Group is a collection of Desktops and/or Applications, which can be used on the machines added to the Delivery Group out of a Machine Catalog. Just as with the Machine Group you can use the option within the actions pane or the right mouse button menu.

Figure 1: Create a Delivery Group

The wizard also starts with an explanation of the Delivery Group option, you can check the option 'Don’t show this again' so that his information is not shown next time.

Figure 2: Getting started with Delivery Groups

The first step is to select the Machine Catalog that will be used for this Delivery Group. All available Machine Catalogs will be shown and you select which one you would like to use. Next you need to provide the amount of machines from the Machine Catalog that will be added to this Delivery Group. I advise to assign all machines in the Machine Catalog to one Delivery Group to keep the infrastructure simple and understandable.

Figure 3: Assigning a Machine Catalog to a Delivery Group

Secondly we need to select if this Delivery Group will be used to provide Desktops, Applications or both.

Figure 4: Delivery Group Delivery Type

The next step is to assign users to this Delivery Group. Those users will be able to access the selected delivery types. During this installation wizard the users will be added to all selected Applications. Later on, you can change this assignment. In this window we also see one of the new options in XenDesktop 7.6: the possibility to allow access to anonymous users to the Delivery Group (as mentioned you also need to configure your StoreFront correctly for this feature).

Figure 5: Assigning users to the Delivery Group

When you have selected Applications during the Delivery Type the next step is to select which applications should be published. The wizard tries to determine which applications are available, but you can provide an application manually. When you have App-V Publishing configured, App-V packages can also be selected (I will discuss the App-V Publishing later in this article series).

Figure 6: Selecting applications for publishing

When you are using silos (nowadays different Delivery Groups) you can configure a StoreFront Store, this Store will be configured within the Receiver on the machines in the Machine Catalog automatically. 

Figure 7: Configure StoreFront automatically within Receiver

The last step is to provide a Delivery Group Name, Display Name and a Delivery Group description (optional). The Display Name is shown to the end user, while the Deliver Group Name is used for the administrator view within the Studio Console.

Figure 8: Delivery Group Summary

The wizard will create the Delivery Group and when this process is finished the Delivery Group will be shown within the Studio Console. Within the console additional settings can be configured on the Delivery Group. You need to select the Delivery Group and select Edit Delivery Group (available in the Actions pane or again the right mouse button menu).

Figure 9: Edit Delivery Group

Within the Edit window several new options are available and logically also settings that we already configured during the wizard.

For example, Users and Delivery Type were already showing in the wizard. Out of this configuration screen you can change the users or the Delivery Type. From the Delivery Type you can also change the Display Name (for the end-users) of the Delivery Group. A new configurable option is Application Prelaunch, which was not shown in the previous wizard. This is a new functionality in XenDesktop 7.6, which was also available in XenApp 6.5. With Prelaunch, a session is alreadystarted for the user, while the user did not select any applications. When the user selects an application later, from an end-user perspective, the application starts directly.

By default Prelaunch is not configured, here you can change that behavior. I must say that I really like the implementation of this feature. You can configure it for all users configured to the Delivery Group or a specific group (of users). You can also specify the time a session will stay active when pre-launched. By default it’s configured for 2 hours, personally I think that is a pretty long period. Optionally you can also specify additional rules to end the prelaunched (unused) session if the load on the machine is getting too high.

Figure 10: Configure Application Prelaunch

The same applies to Application Lingering. This is also a new feature in XenDesktop 7.6, which was also available in XenApp 6.5. With Session Linger the session of the user won’t be closed directly when the user closes the application on the machine. In the case of using Published Application the user does not have to wait to create a full new session when switching between Published Applications. Just like the Application Prelaunch the option is disabled by default. When you enable Application Lingering you can specify the time interval the session should be kept alive. Again the default time interval is pretty long (8 hours). The session can also be closed by specifying maximum load values allowed, before lingered session will be shutdown.

Figure 11: Configure Application Lingering

The next option is called User Settings. Here you can edit/set-up the description of the Delivery Group, but also other settings we could not configure during the wizard like the amount of Desktops available per user and securing the ICA traffic.

Figure 12: User Settings

The StoreFront tab shows the same options as during the Delivery Group creation wizard, while Access Policy offers new settings. Within Access Policy you can configure how the Delivery Group may be accessed. Only via the Citrix NetScaler Gateway or also other possibilities like directly through Citrix StoreFront.

Figure 13: User Settings

The last configurable item is configuring a Restart Schedule. You can create a pretty flexible reboot schema based on a start time and an interval time. You can send users a message that the machine will be restarted within the specified timeframe.

Figure 14: Restart Schedule

On the Applications tab of the delivery group (available when you selected as Delivery Type Applications or Desktops and Applications). Out of the Actions pane you can add additional applications to the Delivery Group. Also just like the Delivery Group per Application, you can configure additional options via the properties of the application.

Figure 15: Application view within the Delivery Group

Within the first configurable item called Identification we can change the Application Name (both from an end-user or administrator perspective). Here we can also add a description or keywords. Those keywords are useful when connecting via StoreFront and users can search for applications.

Figure 16: Application view within the Delivery Group

Within Delivery the application icon can be changed, an optional application category can be filled in and we can add a shortcut to the user’s desktop.

Figure 17: Delivery application properties

At the location tab we can specify the exact location of the application including the command line argument and working directory.

Figure 18: Application Location configuration

Already discussed during the Delivery Group Wizard, by default the Published Applications are assigned to the user group selected during the wizard. Happily Citrix currently offers the option to assign an application to a specific group or users. This can be done in the Limit Visibility part, where you can configure which user could use this application.

Figure 19: Application Location configuration

The last configurable option is the File Type Associations. Here you can configure which file type extensions should be configured for the Published Application.

Figure 20

We have now configured the Delivered Group completely. It is now possible for a user to connect to the XenDesktop infrastructure and can start a Desktop and/or Published Applications.

Summary

In this part we configured a Delivery Group and discussed the setting which can be configured. With the creation of the Delivery Group the XenDesktop infrastructure can be used by the end-user to start a Desktop or Applications. In the next part we will start with showing users starting a Desktop or Application on the XenDesktop infrastructure followed by some advanced configuration options of the XenDesktop Infrastructure.

Installing and Configuring Citrix XenApp/XenDesktop 7.6 (Part 3)

In this third part we will continue with the installation of the VDA agent, followed by the creation of a basic XenDesktop environment.

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

 

Introduction

In this first part of the article series we installed the Desktop Delivery Controller role, while in the second part we executed the initial setup of the first and following Desktop Delivery Controllers and the Citrix StoreFront basic configuration. In this third part we will continue with the installation of the VDA agent, followed by the creation of a basic XenDesktop environment.

 

Installation of the Virtual Desktop Agent

There are two VDA installations available: One installer for Windows Server OS and one installer for Windows Desktop OS. The installation wizard checks the OS and only shows the available VDA option. The Windows Server OS VDA is supported on Windows 2008R2 SP1, Windows 2012 and Windows 2012R2. The VDA Agent for Desktop OS can be installed on Windows 7 SP1, Windows 8 and Windows 8.1. In this article I will also show the installation steps for the Windows Desktop OS, but I will use the Window Server OS VDA for the purpose of this article (almost all license editions support the Server OS features). The set-ups are pretty similar, so it also does not make a big difference. I will mention which part is Desktop OS only.

Figure 1: XenDesktop Installation Wizard start-up screen

The first question in the installation wizard is about the way the VDA will be provisioned. When using Citrix deployment techniques like MCS (Machine Creation Services) or PVS (Provisioning Services) you will install the VDA in the master image only and the Citrix should take care that the machine is unique. When you don’t have such a deployment you choose that the machine connects directly to a server machine itself. I don’t want to make this article series too complex, so I won’t use MCS or PVS so we only focus on XenDesktop 7.6.

Figure 2: Create a Master Image or Connect Directly to a server machine

In the Desktop OS installation wizard one additional step is shown; do you want to use VDA for HDX 3D Pro. If you do want HDX 3DPro logically, you need to select this option, but also ensure that the required (hardware and software) components are in place. As already mentioned, I actually use the Server OS installation for this article so I don’t have to actually choose an option.

Figure 3: HDX 3D Pro in the Desktop OS VDA installation

The following step is again available in both installers, where you choose which core components need to be installed. The Virtual Delivery Agent is logically required; you can choose if you would like to install the Citrix Receiver also. Be careful with this one as it installs a Receiver 4.x version (which does not support the PNAgent functionality anymore).

Figure 4: Choosing the Core Components to be installed

Next we need to provide the Delivery Controllers. The wizard offers four options:

• Do it later

Do not provide a delivery controller at this moment. You need to use one of the other possibilities after the installation of the VDA agent.

• Do it manually

Provide the Delivery Controllers during the wizard, actually now. This is the easiest method, but less flexible. When you provide the role Delivery Controller to other servers, you need to change the settings locally on each VDA agent.

• Choose locations from Active Directory

You can add a Service Connection Point (CSP) and a security group to Active Directory, so the VDA can get the Delivery Controller more dynamically. I would suggest using this option in large production environments.

• Let Machine Creation Services do it automatically

Machine Creation Services (MCS) can provide the Delivery Controller information, you can only use this option if you use MSC to deploy the VDA agents.

Figure 5: Providing the Delivery Controllers information
The next step is providing which features should be installed/enabled. Really consider the option Optimize performance and read the corresponding knowledgebase article (http://support.citrix.com/article/CTX125874) in advance. It’s possible that the optimization conflicts with requirements in your organization, as it’s fully focused on the best performance not about offered visuals and/or functionalities. I would normally enable the other options by default.

Figure 6: Deciding to enable which features
To communicate with the Delivery Controller to offer the Remote Assistance feature and to use Real Time Audio, several communication ports are required. Just as with the Delivery Controller installation you can set those Firewall Exceptions manually or automatically during the installation process.

Figure 7: Configuring the Firewall
A summary is shown with the installation settings provided including the destination location of the actual installation.

Figure 8: Summary of the VDA installation wizard
Just like the Delivery Controller wizard, a nice process window will be shown during the actual installation phase.

Figure 9: Finish installation VDA
When not using PVS or MSC technology you will install the VDA on more servers or desktops to create a pool of available machines. When the VDA’s are installed we can start configuring the XenDesktop environment. As shown earlier you can do that via the initial set-up, which creates the basic configuration. I have chosen to create it manually to provide a better insight of what needs to be configured.

Creating a Machine Catalog

The first step is to create a Machine Catalog. You should see a Machine Catalog as a group of VDA which will be pulled out this Catalog during further configurations. During this further configuration those machines will be picked automatically (you cannot select which VDA you would like to use), therefore it’s a best practice to create a Machine Catalog which holds VDAs offering the same configuration. Creating a Machine Catalog is done through the Studio Console, where both the Actions menu in the right pane, as well as the rightmouse menu can be used to start this task.

Figure 10: Starting tthe Create Machine Catalog
The first screen of the Machine Catalog Setup describes pretty well what you should have done before starting this wizard. However if you have done this before you probably don’t want to see this information anymore, happily you have the option available not to show this screen anymore.

Figure 11: Introduction Machine Catalog Setup
Secondly you need to choose if the Machine Catalog exists of Server OS VDAs of Desktop OS VDAs. It’s not possible to mix and match those types of OS together in one Machine Catalog. As I installed the VDA on a Server OS I will check Windows Server OS.

Figure 12: Selecting Operating System VDAs
After selecting the Operating System you need to provide information about machine management. As seen in the VDA agent XenDesktop 7.6 can be combined with Citrix technologies MCS and PVS and XenDesktop should know which technique (if any) you are using. When you select one of these technologies you can also choose to use Power Management. As in this article I don’t use MCS or PVS, I need to select another service or technology.

Figure 13: Machine Management options
Next step is to add the VDAs in this Machine Catalog. This screen really depends on the Machine Management option you are using. For example: within a PVS machine management you will see your PVS infrastructure Device Collections and you need to pick a device collection. Because I’m not using any machine management technique I have to select the machines based on Active Directory. Also you need to provide the version of the VDAs. Preferable you will use the VDA 7.6 version, but you can also use VDA that still have the older VDA running (in an upgrade scenario).

Figure 14: Adding machines to the Machine Catalog
Although the last screen is called Summary you still need to provide information. The first part indeed shows a summary of the earlier configured settings, however you also need to provide a Machine Catalog Name and an optional description for recognition of the Machine Catalog.

Figure 15: Summary and providing the Machine Catalog name
The summary page also mentions that a next step is required to complete the deployment by assigning this Machine Catalog to a Delivery Groups. That’s exactly the next step we are going to execute in the next part of this article series.

Summary

In this third part we started with installing the VDA component. The machines running this VDA component are the actual machines the user will execute their (daily) tasks on. After the VDA installation part, we started with the basic configuration of a XenDesktop site by configuring a Machine Catalog.

Installing and Configuring Citrix XenApp/XenDesktop 7.6 (Part 2)

In this part two of our article series I will continue with the initial set-up of the XenDesktop 7.6 infrastructure.

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

 

Introduction

I started this article series trying to explain that XenApp 7.5 and XenDesktop 7.5 are actually the same product and therefore also the same installation and configuration steps apply. After this explanation I described the installation steps of the Delivery Controller.

 

Initial Set-up for first Delivery Controller

In part one of the article series I installed the Delivery Controller software. As shown in part one you can start Studio for this initial setup directly. When you unchecked that option, you can just use the Studio Console to start the initial set-up.

When Studio starts it offers three options: Site Setup, Remote PC Access and Scale your deployment. I won’t discuss Remote PC Access in this article series and as this is our first Delivery Controller we need to choose Site Setup by selecting the option Deliver Applications and Desktops to your users.

Figure 1: Initial start-up of Citrix Studio, choosing Deliver application and desktop to your users to set-up the XenDesktop infrastructure

The Site Setup wizard starts by asking you to either create an empty configured Site or to create a fully configured site. For this article I will use an empty, unconfigured site as this makes is easier to explain the configuration out of the console in this article series.

Figure 2: Site Setup Introduction: empty site or a fully configured site

The next step is specifying the databaseserver and databasename. As this is the first Delivery Controller, a database will not be available. You can specify a name for the database (the wizard will suggest one based on the Site Name filled in the previous screen). There are two options to create the database, you can continue the wizard or create a database script. The database script can be used to provide it to the database administrator if you don’t have (enough) rights on the database server to create the database via the installation wizard. I have enough rights, so for this article I will use the option to create the database via the installation wizard.

Figure 3: Providing database server and database name information

Continue with the wizard. A message will be shown that the database is not available and that via the OK button the database can be created.

Figure 4: No database was found, create the database automatically?

Providing the license information is the next step. If you already have a license server running, you will probably have to update your current license server software with a new version. As shown in part 1 you could have also installed the license server on the same machine. You can also use the 30-day trial (you don’t have to specify a license server at all using this option).

Figure 5: Providing license information

After the licensing information a summary is shown before the actual configuration starts. In this screen Citrix also asks if you don’t mind sending statistics and usage information.

Figure 6: VDA Installation Summary

During the configuration phase a progress bar is shown.

Figure 7: Studio Configuration progress bar

When the progress bar disappears the site is created. In the Studio Console all kind of options are available. We will come back to this part later in this article series. First we will add a second delivery controller.

Figure 8: XenDesktop Side created on the first Delivery Controller

Initial setup following Delivery Controller(s)

As mentioned in part one, the Delivery Controller is the heart of the XenDesktop infrastructure, so logically you want this component highly available and fault tolerant. This can be done pretty easily; just add one or more Delivery Controllers to the infrastructure.

Also for these Delivery Controllers this is done by starting the Studio console. For adding a Delivery Controller to the just created site we need to choose the obvious button: Connect this Delivery Controller to an existing Site.

Figure 9: Connect this Delivery Controller to an existing Site

The first step is to specify a Delivery Controller in the site this Delivery Controller should be joining.

Figure 10: Select Site

After the Delivery Controller made a connection with the specified Delivery Controller, Studio asks if you would like to update the database automatically. If you choose No the wizard generates an SQL script, which can be used to add the Delivery Controller information into the database. When you chooses Yes the database will be updated automatically.

Figure 11: Update the database automatically or manually

When the database is updated the server is added as a controller within Citrix Studio and also the Studio on the added Delivery Controller will show the site information. Again for now we will leave the Studio console and execute the basic configuration of the StoreFront component, so users can connect to the environment at the end of the article series.

Figure 12: Update the database automatically or manually

Also to configure the StoreFront component you need to start the corresponding console called Citrix StoreFront. As this is the initial set-up the easiest way to set-up is to use the Create a Store button in the main window.

Figure 13: Citrix StoreFront console first start-up

With this button the Create Store wizard will be started. The first step is providing a name for the Store, this name will be shown to the end users and will be part of the URL.

Figure 14: Citrix StoreFront Store Name

The second step is providing the earlier installed and configured Delivery Controllers. With the StoreFront 2.6 release Citrix finally made it more clear which type you have to choose as StoreFront also supports older XenApp releases. For XenApp/XenDesktop 7.6 you logically need to choose XenApp 7.5 (or later), or XenDesktop. Also remember that the Delivery Controller without additional configuration communicates over HTTP.

Figure 15: Providing the Delivery Controllers

Finally you need to provide the way StoreFront provides access to the environment. Three options are available below Remote Access: None, No VPN Tunnel and Full VPN Tunnel. You will choose None if you would like to use the StoreFront without a Citrix NetScaler Gateway, in other words the end-user will directly type in the URL of the StoreFront server for example for internal access. When using the Citrix NetScaler Gateway you will choose between No VPN Tunnel or Full VPN Tunnel, where No VPN Tunnel will be used providing access to the XenDesktop infrastructure only and a Full VPN, as the name applies, will set-up a standard VPN connection tunnel.

Figure 16: StoreFront (Remote) Access

After pushing the Create button the Store and Corresponding website is created. In the window mentioning the successful creation of these, the URL to be used for WebAccess is also shown. It’s worth mentioning that during the initial set-up of the Delivery Controller, a StoreFront configuration is alsoexecuted. I guess the wizard “noticed” that StoreFront is also installed locally and is automatically configured. So if you install StoreFront on the same server, you don’t have to execute the above shown steps.

Summary

In the first part of the article series, the installation of the Desktop Delivery Controllers was discussed, in this part we executed the initial setup of the first and following Desktop Delivery Controllers. The last topic was the basic configuration of the Citrix StoreFront component, so that at the end of the article series users cannot connect to the XenDesktop infrastructure. In the upcoming part we will continue with the installation of the VDA agent, followed by the creation of a basic XenDesktop environment.

Figure 17: StoreFront Store created