Installing and Configuring Citrix XenApp 6.5 (Part 1) Introduction The first part of this series describes the installation steps of the first server (which will create the XenApp environment) and the following server that will join the XenApp environment afterwards. Preparations Citrix XenApp needs to have a database in which the (static) settings are stored. For a small environment an SQL express can be used, which will be located at the first server you install. This works fine, but has some disadvantages. First of all, this server is important and should be available as much as possible (Citrix XenApp servers have the ability to work without a database for 96 hours). Secondly, the server also has the SQL database role, so should always have resources available to carry out the tasks for this role. Therefore a dedicated SQL server is advised, when one is available. When you are planning to have more than 10 Citrix XenApp servers, Citrix advises to use this dedicated SQL Server even if one is not available. When using a dedicated SQL server, the database should be created in advance via the normal SQL steps. Both SQL and Windows Authentication can be used. Figure 1: Creating the SQL database for the XenApp 6.5 environment. Installation Part 1 If you have installed an earlier release of Citrix XenApp you probably remember that you have to provide a lot of configuration settings during the installation phase. From XenApp 6 Citrix changed this behavior by separating the actual installation and the phase to set-up or connect to the XenApp environment. Also with previous versions several prerequisites should be installed in advance before the XenApp installation could be performed. Nowadays, all these prerequisites are embedded in the installation phase. In other words if a prerequisite is not available it will be installed automatically. However, this requires some additional
reboots, so depending of the infrastructure you could install some of those prerequisites in advance (like the RD Session Host role and.net Framework). In this article, I will not install these in advance as to show you the full installation process. The installation process can be started either using the autorun functionality or starting the setup.exe from the folder XenApp Server Setup. Figure 2: Starting the setup using the Autorun functionality. As mentioned earlier on, install will detect if any prerequisites are not available yet. Because I did not configure anything in advance a message will be shown that.net Framework 3.5 SP1 is not installed. Choose OK to install.net Framework 3.5 SP1. Figure 3:.Net Framework 3.5 SP1 is not installed. The installation process will install.net Framework 3.5 SP1 automatically. After this installation the actual XenApp installation will be started showing the XenApp Server Role Manager. Via Add Server roles the installation wizard continues.
Figure 4: The first XenApp installation Window The first setting is about the version of XenApp you are using. Depending of the version, some options in XenApp will not be available and some components/products are (not) shown. In this article I will use the Enterprise version. Figure 5: Choosing the XenApp edition. The license agreement is shown next, accept the agreement and continue.
Figure 6: Accepting the license agreement Depending of the selected edition of XenApp, you can choose which components you would like to install. The options you choose during the installation should depend on the size of the infrastructure. License server: This component is needed once per organization. Normally this will be installed separately on an existing IIS server (which is a requirement), and on a dedicated server or combined with the Web Interface. The License server is there to make sure that the XenApp product (and other Citrix products) can function with the correct licenses. XenApp: This is the actually XenApp component, publishing applications and/or desktop to the end-user. Web Interface: This is a component that provides end-users access to the Published Applications/Published Desktop using a portal website and/or Service site (formerly known as PNAgent). Secure Gateway: The software based solution to provide secured access to the XenApp environment via SSL. Power and Capacity Management Administration: the software package to manage the option to shut down and start-up Citrix XenApp servers depending on the amount of users connecting to the farm. EdgeSight server: The back-end component of the Citrix Monitoring product. For larger infrastructures the components will be installed separately on different servers, but in very small environments the various components can be shared. I would like to advice to separate the XenApp role whenever possible. The License server and Web Interface can be combined perfectly. If a Secure Gateway SSL solution is deployed, it can be combined with Web Interface and so on. Because this article is about installing and configuring XenApp, I will select the XenApp role only.
Figure 7: Choose XenApp Roles After choosing the XenApp role several sub components can be selected. XenApp Management: This is the administrator console for the XenApp farm. This can be installed on every server or just one. I personally prefer to install the console on all servers. Windows Desktop Experience Integration: This component is related to Published Desktop and makes the look and feel of this desktop look like Windows 7. XML Service IIS integration: In small environments and where the Web Interface is installed (which requires IIS), this option should be selected so that XenApp can share ports with IIS. EdseSight Agent/Single Sign-On Plug-in/Power and Capacity Agent. When deploying/using one of these functionalities, the XenApp server should have the agent software installed, and can be accomplished by selecting the corresponding agent in this selection window. In this article, I will not use any of the agents or the IIS integration feature; however, I will install the console and the Windows Desktop Experience feature.
Figure 8: Choosing sub roles of XenApp As stated before, the installation will take care of the prerequisites. The installation wizard will show all prerequisites that will be installed and any related reboots if required. Figure 9: Review prerequisites.
Before the actual installation process starts, a simplified view will be shown, displaying the prerequisites, sub-components and roles that will be installed by the installation process. Figure 10: Enumeration of the components that will be installed. A reboot is required which is shown in the progress window. After closing the progress window using the Finish Button, the required reboot will be shown in the XenApp Server Role Manager. Choose this reboot option to really restart the server and choose Yes to the prompt if you really want to reboot the machine.
Figure 11: A reboot is required to continue with the installation. Figure 12: Reboot the server using the XenApp Server Role Manager. The XenApp Role Server Manager will load and shows that the installation can continue. Choose the option to continue the installation.
Figure 13: After the reboot, the XenApp Server Role Manager shows that the installation can be resumed. Again the components that will be installed are shown (the components that were installed before the reboot are not shown anymore). Click the Install button to continue. Figure 14: Components can be installed. After a while all components are installed and the Finish button will be shown.
Figure 15: All components are installed. The last step of the installation is specifying the license server. Independent of where you installed the license server, you need to specify this part. Figure 16: Specify Licensing question Enter the name of license server. Note, that the default communication port is 27000.
Figure 17: Specify the license server name and communication port. Next step is about the type of licensing used. In this article, I will use XenApp but the choice depends on the licenses you have purchased. Figure 18: Select the correct license model.
The above shown steps are exactly the same for all XenApp servers. When the license configuration is selected, a configure option will be shown. This configuration will start the process to create or join farm with all corresponding configuration settings. This part of the configuration will be described in the next article of this series. Figure 19: Licensing configured, it s time to configure the XenApp server to create or join a farm. Conclusion In the first part of this series, I described and discussed the installation steps of a Citrix XenApp 6.5 server. In the second article I will show you the steps required to create and join a Citrix XenApp farm. Creating a XenApp Citrix Farm The first server you install (well actually the first server you start the configuration process) will always create the Citrix XenApp farm for your infrastructure. We ended the first article with the figure showing the configure option in the XenApp Server Role Manager. When you choose configure the XenApp Server Configuration Wizard will be started. Sometimes you need to minimize the XenApp Server Role Manager window, because the XenApp Server Configuration window will be placed behind that window.
Figure 1: Choose Configure to start the XenApp Server Configuration. The first step in the XenApp Configuration wizard is to choose to set-up a new server farm or add the server to an existing farm. Because this is our first server, we choose Create a new server farm. Figure 2: Create a new farm or join an existing farm.
Every farm should have a (unique) name, so the first step in the farm creation is to give the farm a name. Also the account that will be the first Citrix Administrator needs to be specified. By default, the user which is logged in and starting the wizard will be filled in automatically, but the user can be changed when needed. Afterwards, more accounts/groups can be added via the XenApp AppCenter console. Figure 3: Providing the XenApp Farm Name and the first Citrix administrator account. The next question is about the database. As explained in part 1 use a normal SQL server when possible, only use the SQL express option when the farm is relatively small and you don t have an SQL server available. I will choose Existing Microsoft SQL Server database.
Figure 4: Choosing the SQL database After choosing an existing Microsoft SQL Server database, we need to provide the settings for the SQL server like the SQL server name, the name of the (predefined) database, and if you are using Windows or SQL authentication for the database. For this article I m using SQL authentication.
Figure 5: Specifying the SQL details. The next step is to specify the account which will be used to access the database. As I selected SQL server authentication in the previous step I need to fill in the account created on the SQL server. Don t forget to add the domain name when you are using Windows authentication.
Figure 6: Providing the username and password for access to the database. Because Shadowing of users is forbidden in some countries you can enable or disable shadowing during the initial configuration process. When disabling shadowing here, there is no possibility to enable it again (only by reinstalling the whole server). So if regulations allow it enable shadowing here, but configure it later using Citrix policies.
Figure 7: Enable or Disable Shadowing The next window actually consists of four configuration options. The first tab called Data Collection is always grayed out for the first server. For the second and following server this option is configurable and I will describe it later on in this article. At the XML Service tab you can change the XML port if you want to change the default port. On the third tab Receiver you can configure the Service Site, it can be useful if you publish a desktop and have some silos for specific applications. With the Service Site this application can be shown within the desktop. But for other use cases you can leave this part empty. On the last tab you define which users will be added to Remote Desktop Users group and which are able to access the server later on.
Figure 8: Configure Advanced Server Settings All necessary information is collected and the process of creating the farm will be started by pressing the Apply Button. Figure 9: Start the process of creating the farm
During the process the progress is shown. At the end the server configuration a successful message is displayed and via the Finish button the process will be ended. Figure 10: Configuration successfully After this wizard you will see that within XenApp Server Role Manager a reboot option will be shown. After the reboot the XenApp farm is functional and you could configure the farm using the consoles. Figure 11: Reboot the server to apply the configuration. But before we start the consoles and configure the Farm, in this article series we will first add a second server to the farm. Because Citrix splits the installation and initial configuration, the installation steps are the same as the first server as described in part one.
After the installation, Figure 1 of this article will be shown at this server to perform the initial configuration of the server. Also Figure 2 will still be shown, however then we need to choose the option Add this server to an existing server Farm. Figure 12: Choosing Add this server to an existing Farm. Next, we need to select which database we are using. Logically this depends on the decision made when configuring the first server. As we used a dedicated SQL for the first server I chose Existing Microsoft SQL Server Database.
Figure 13: Choosing the SQL server to use. Next step is providing the information of the SQL server and the name of the database used for the XenApp Farm on this SQL server. Also the way the database will be accessed (using an SQL account or Active Directory account via Windows Authentication). Logically the same information needs to be filled in and used by setting up the farm.
Figure 14: Providing SQL information. To access the database using the selected authentication method, the username and password need to be provided. Be sure to test the connection in advance, otherwise you can get an error message later on.
Figure 15: Providing SQL logon credentials to access the XenApp datastore. Just like installing the first server you need to specify if you would like to enable or disable shadowing. Only select disable if regulations state that shadowing cannot be used. In other circumstances select allow shadowing and configure the behavior later using the Citrix policies component.
Figure 16: Enable or Disable the possibility to shadow a session. When installing the second or following server you can decide to configure the server to act as Session-Host only server. When configured as Session-Host only server, the server can never get the Data Collector role, so it will only host Published Applications and/or Published Desktops. This can be configured on the tab data collection of the XenApp Configuration. On this tab you can also configure a Zone Name. When you enter a non-existing zone name, this zone will be automatically created within the farm. The other three parts are already described earlier in this article, so I will not mention these again here.
Figure 17: Configuring the server as a session-host mode only server and specify a custom zone name. Before the real configuration starts, all configured settings are shown once again, so you can check if everything is filled correctly. By pressing Apply the configuration will be set.
Figure 18: Summarizing all configured settings, before applying them to the server. Via the below shown window the progress will be shown. When the complete configuration is applied you can press Finish.
Figure 19: Configuration is applied. You will return into the XenApp Server Role Manager, after a few seconds the view will be updated and the reboot option will be shown. Choose the reboot, so that the configuration will become active. A restart confirmation will be shown, choose Yes to really restart the server. Figure 20: Choose reboot to activate the configuration and join the Farm.
After the reboot the server is joined to the farm. When you have many servers to install, it is a good idea to automate the installation and configuration process of the Citrix XenApp servers. I already wrote an article series about it published on VanBragt.Net Virtualization Centre if you are interested in reading more about the possibilities to install and configure XenApp silently. Conclusion In this article I explained how to set-up the XenApp Farm using the first installed server. Secondly we walked through the steps to join the second and following servers to the XenApp Farm. The next article in this series will continue with the configuration possibilities within the XenApp product. In the previous articles, I described the installation steps for Citrix XenApp 6.5. In this third part, I will start describing the configuration possibilities. The Citrix AppCenter Console Citrix has been promising for years that there would be one management console for Citrix XenApp which in that time was still known as Presentation Server. From version 6 there is actually one console (almost, protocol configuration is still done in a separate GUI). In XenApp 6.5 the console is named Citrix AppCenter. The first time you start this console the initial configuration wizard called Configure and Run Discovery will be shown. The first window is just informational, so you can continue with Next. In the second window you need to specify one or more Citrix XenApp servers that will be used to connect to the database. You can easily add the local server via the button Add Local Computer or add servers manually via the Add button, where you have to type in the server name. If you have the XenApp console as a published application over multiple servers, you can type in LOCALHOST as a server name. In that case, it does not matter on which servers the console is actually started. Figure 1: Adding XenApp servers in the Configure and run discovery The next steps are actually just pressing the next button to start the discovery and at the end the console will display your installed XenApp environment. You will get a message that there are no published applications configured and you can use the Migration Center to import those from your current Citrix environment. The Migration Center is not part of this current article series, but if there is interest for an article just let me know. When the console is fully started we can start configuring the XenApp environment. Administrators
The first option available in the console is Administrators. Here you can configure delegation of control within the AppCenter console. During the installation we used the initial administrator (by default it is the account that was running the installation wizard), so this account should be used to start the console. By using the right mouse button menu on the Administrator name in the left pane, you can add additional administrators. Configuration is divided in two parts, specifying the user(s) or group(s) that will have AppCenter rights assigned to (tip: use the Operating System User Selector), and secondly you specify the rights to that user(s)/groups(s). There are three options available: Read Only, Full Administration and Custom. Most of the times you probably use Custom, because you can configure exactly what rights the user(s)/group(s) will have. Remember that some options are offering the same functionality available in different levels. Good examples are the Session settings, which are both available in the Applications and Servers levels. I m not going to discuss the possible permissions one by one, because the names are selfexplanatory. Remember that every custom configured administrator needs to have at least the right Log on the Management Console available under administrators. Figure 2: Configuring custom administrator settings Logically, you can alter the settings by selecting the user(s)/groups(s) and then select administrator properties. The same configuration windows will be shown to you. Applications This is probably the most used part in the management interface. Here you can configure and alter Published Applications and/or Published Desktops. You can create folders in this view. This is just for a logical order and is not used anywhere else. Sometimes people think that the folder structure is used for displaying the applications in the Web Interface view and/or the placement in the Start Menu when using PNAgent. You can create Published Applications (or Published Desktops) via the menu of the right-mouse
button directly in the root or in the create folders. The first page of the wizard is an informational welcome screen. The second screen asks for a Display Name and an application description, this information is shown to the end-user so configure these with care. The display name is used in the Web Interface (WI). In the third frame you need to decide what you are going to offer to the end-users. There are three possibilities: o o o Server Desktop: By choosing this option a Full Desktop will be shown to the end-user. This is the best choice if you offer all the applications within the Citrix environment. From an end-user perspective the environment looks like they are working on a local desktop (dependent on how you configured the Desktop Optimization Pack). Content: Publishing content like a document, video or website instead of an application. I don t see this option used a lot, but the possibility is there, for example: a user s guide or an intranet webpage. Application: Using this option you are publishing an application. The best option if the user also has local applications. In this way (when using the seamless publishing mode) the application is displayed within the user local desktop. The way the application is offered to end-users differs based on the configuration options below. First you have the application type: Accessed from a server: This is the traditional XenApp method. The Published Application is actually running on the XenApp servers and offered as a (seamless) application to the local client. You can use an Installed Application (locally installed or third party application virtualization) or Streamed to Server (using Citrix Application Virtualization). Streamed if possible, otherwise accessed from a server: With the option by default the Citrix virtualization package will be used locally on the client. So the application is actually started on the local client and use local resources. If this scenario is not possible the application will be started on the XenApp environment, where similar to Accessed from a server can be a local installed application or Citrix virtualized application. Streamed to Client: The virtualized application is running locally on the client only. Figure 3: Configuring custom administrator settings The next steps are different, based on the chosen application type. Except for the Server Desktop the next step is to specify the location of the content, the executable of the application or the Citrix Application Virtualization Package. When you only use the Application Virtualization part you need to configure the offline-usage, while the other option asks you to specify the XenApp servers the application or the desktop should be assigned to (this can also be assigned to worker groups, which I will explain later). For all options the next step is to specify the users which are allowed to start and use the application. At the shortcut presentation you can change the icon, and specify the client application folder (this one is used for the folders in the Web Interface). When using the PNAgent for publishing an application in the start menu of the user you should fill the Application
shortcut placement according to the organization needs. These settings are the last for basic configuration, but you can check the option Configure advanced application settings now to further configure the environment. The first advanced setting is called Access Control and offers the possibility via which Citrix connection methodologies the application can be started. The options are Access Gateway Advanced edition (including filters) or all connections. I prefer to use the Citrix policies for the overall settings and only change the settings on Published Application level for specific needs. Secondly you can configure content redirection which allows specifying which file types should be assigned to the application. Figure 4: Configuring content redirection Next is the Limits tab, where you can configure how often the application can be started. You can configure if the application is allowed over the whole farm or limit the application to be started once per user. Also the Client options like client audio, connection encryption and if the session should be waiting or not waiting before the printers are created. The last tab is Appearance where you can configure how the Published Application is shown to the end user. I prefer to use Full Screen (for Published Desktops) or percentage of the client desktop for Published Application (using 95% or 99%, depending on the customer needs). Nowadays 32 bit is the way to go, because appearance is very important to end-users. If needed you can configure title bar and maximize the application at start-up. Most settings can be changed using the application properties; however some settings can only be adjusted via the Other Tasks options. The Change Application Type is the most important because it changes the way the application is started as described before. Also, out of the Other Tasks you can create a Pre-Launch application for the pre-launch feature in XenApp 6.5, attach a specific Load Evaluator to the Application and import/export the settings (as a backup). Conclusion In this article I started configuring the Citrix XenApp environment. I described the options and settings for Administrators and Published Application. In the upcoming article I will continue with the other available configuration options. Load Balancing Policies This option is only available in the Enterprise or higher editions. This makes it possible to divide sessions over Worker Groups based on four filters; Access Control, Client IP Address, Client Name and Users. Based on one or a combination of these filters you can specify to which Worker Group(s) based on priority the user will be assigned to. Also this component can be used to specify the
way the Citrix Application Virtualization will be delivered/started. I wrote a detail article about Load Balancing policies earlier, which can be found on my website VanBragt.Net Virtualization. Figure 1: Load Balancing Policies Load Evaluator Although the names are pretty similar and Load Evaluators are often called Load Balancing by Citrix administrators/consultants, the Load Evaluator has another goal than the just described Load Balancing policy. The Load Evaluator determines the load per Citrix XenApp servers based on load evaluator rules. By default two Load Evaluators are available; Default (based on User load and Load Throttling) and Advanced (based on CPU utilization, memory utilization, Load Throttling and Page Swap). Both have some downsides, so often a new custom load evaluator is created. My best practice is to use a combination of the rules User Load (where the value should be determined by performance tests), Memory Usage, CPU Utilization and Load Throttling. Because CPU Utilization and Memory Usage have a dynamic character I only want that those rules to come into play when the usage is pretty high. So for the no load setting, I use a pretty high value like 70 or 80 percent, causing that User Load as the rule that is used in normal situations. I will explain this a bit more, because there is alot of confusion amongst admins about the way the load is calculated. Out of the rules, the most high value will be used combined with the averages of the other rules (which are multiplied by 0,1). So in my best practices the User Load will have the highest value by default or CPU or Memory should have a high value.
Figure 2: Custom Load Evaluator Policies From XenApp 6.5 the policies have changed a lot. The first big change is the way that you configure the policies. In previous versions this could only be done within the Citrix Management Consoles, but nowadays you also configure the policies within Active Directory. Logically you should make a decision to use one of the possibilities, because it cannot me combined. Advantages for Active Directory are that settings can be shared over multiple Citrix farms and the AD method is always used to deploy the policies (also if you configure them in the Citrix console). Advantages for using the Citrix console is independency of AD (if you do not administrator AD for example) and it s clear that the policies are for which XenApp farm (if multiples are configured). Policies can be applied on two levels, on machine or user level (same as Active Directory GPO s works). Multiple policies can be configured, which can be assigned via Filters and Priorities. Using the priorities part settings can be overruled by a higher priority. Filtering on machine level can be based on AD Organizational Unit and/or Worker Groups. It s good to know that several configure options are nowadays embedded in the policies part were in earlier versions those were available as separate options in the console. Some examples are the Load Evaluator assignment on server level, reboot configuration, licensing, Health Monitoring and Recovery, CPU/Memory optimization and so on. The second level is on user level. Logically on the User Level the same concept is used for prioritization and filtering. However more filters are available: Access Control With this option the policy can be applied or denied based on defined Access Control conditions, which can be defined in the Access Controller of the Access Gateway. Branch Repeater Using this filter setting will be applied based on the way the client connects, via a branch repeater or without a branch repeater. Client IP address Based on (part of) the client IP addresses the policy will be applied or denied. Wildcards can be used for defining sets of clients to apply or deny the policy. Some use cases are settings defined for WAN connections, External Access (if Access Control is not in place), specific department/location settings and so on. Client Name
Using (part of) the client name to apply or deny the policy. Again wildcards can be used to define a group of client. Can be used for different settings per client type (laptops, desktop and thin clients), specific department configuration or similar use cases. Organizational Unit Just as the default user policies for Active Directory are functioning, the policy is applied or denied based on the location of the user within the AD Organization Unit schema. User or Group Filtering of the policy is based on users or groups. This can be both local or Active Directory users or groups, where it makes sense to use Active Directory Groups for this kind of filtering. Worker Group In this way the user policy will be applied based on the server the session is started. So if the server is member of the configured Worker Group the policy will be applied or denied. Figure 3: Citrix User policies Filters I m not going to discuss all policy settings one by one this time. If there is interest we can make a separate article series for it. Worker Groups Also introduced in XenApp 6.0 are the Worker Groups. A Worker Group is actual just a group of servers. A server can be a member of one, none or multiple Worker Groups. Worker Groups are often used for combining similar servers used to assign the same configuration. For example you can assign a Published Application to a Worker Group. If a server is added the Published Application is automatically available on that server (or the other way around). Also applying Citrix Policies using Worker Groups is a nice opportunity, especially because a server can be assigned to more Worker Groups. I use this concept to add the server out of production using a Load Evaluator (now only configurable using the Machine Policy part) and Worker Groups (see this article for more info). Also using the Load Balancing Policies defined Worker Groups are required. Zones Nowadays Zones are only used for organizing the communication traffic between Citrix XenApp servers (and specifying the Data Collector preference per zone). By default all Citrix XenApp servers are communicating with each other in a zone. When a Citrix Farm is divided over multiple locations (with limited bandwidth) it can be important to limit the traffic between those locations. By
creating a zone for each location, traffic between the zones is limited where only one server of each zone communicates. The other servers only communicate directly with the servers within the same zone. The Election Preference can be configured per zone. This determines which server will hold the Data Collector role. Each zone will have one server that will hold that role. If that server is unavailable an election will be performed and based on the election preference of the server a new server will be selected to host the role. Figure 4: Set Election Preference ICA Listener Configuration As stated earlier there are still a few settings outside the management console for specific configuration. The ICA Listener is the most important, because this is the only place where you can configure the session limits for end disconnected session and active session limit. In Citrix policies are the same settings available but those only apply to XenDesktop. I don t recommend to change other settings within this ICA Listener Config.
Figure 5: ICA Listener Configuration SpeedScreen Latency Reduction Manager Not used a lot anymore, but with this utility you can change specific settings like enable local text echo and mouse click feedback and the latency threshold settings. Only change this for specific needs. Citrix SSL Relay Configuration Communicating between the XenApp Farm and the access technologies like Web Interface, Secure Gateway, Access Gateway or Cloud Gateway, by default, plain XML/HTTP traffic is used. This can be secured using SSL traffic. With the Citrix SSL Relay Configuration you can configure the SSL settings for the XenApp servers for securing the communication between the configured servers and the access technologies. Conclusion In this last part I continued describing and discussing the configuration possibilities of XenApp. With this article series I showed and described the basic installation and configuration of a XenApp environment based on XenApp 6.5.