• Implementing Red Hat Enterprise Linux 7 and CentOS7 Linux with Citrix XenDesktop 7.11

    As many of you know, I have a few documentation scripts freely available on my site. One of the scripts is for Citrix XenApp/XenDesktop 7.0 through 7.7. Citrix introduced so many changes in version 7.8, 7.9 and 7.11 (and who knows what changes are coming in the future?) that I had to fork (to use a GitHub term) the script. Now there is a separate script for XenApp/XenDesktop versions 7.8 and later. I am working very hard to make sure I document all the details available for all the possible Machine Catalogs and Delivery Groups. Recently Citrix released Linux Virtual Delivery Agent (VDA) 1.4. I was curious what the differences were when a Linux Machine Catalog and Delivery Group are added to Citrix Studio. Would my script handle the Linux information or would I be in for some work to make my script handle Linux. Time to find out.

    I know how to spell Linux and that is as far as my Linux knowledge went. First, I had to see what versions of Linux the VDA supported. Off to see what the Citrix documentation stated.

    The following Linux distributions are supported by the Linux Virtual Desktop product:

    • SUSE Linux Enterprise:
      • Desktop 12 Service Pack 1
      • Server 11 Service Pack 4
      • Server 12 Service Pack 1
    • Red Hat Enterprise Linux
      • Workstation 6.8
      • Workstation 7.2
      • Server 6.8
      • Server 7.2
    • CentOS Linux
      • CentOS 6.8
      • CentOS 7.2

    A fellow CTP works for Red Hat so I figured I would start with Red Hat Workstation 7.2. From beginning to end, it took me six hours to get a Linux desktop published and accessed via StoreFront 3.7. So now that I have a little bit of experience and know what is missing or doesn’t work in the Citrix documentation, I thought I would run through the entire process again using CentOS7 (since it is free and a kissing cousin to Red Hat Enterprise Linux) and, this time, document the process. I know there are others out there like me (scary thought) who would like to dip their toes into the Linux water and see what all the fuss is about this Linux VDA.

    I am using VMware vSphere/vCenter 6U2 as my hypervisor and a Synology 1515+ with 5TB of SSD storage for my datastore.

    I want to thank three of my fellow CTPs who know a lot about Linux for answering my hundreds of questions and reviewing this content: The World’s Oldest CTP Tobias Kreidl, Mr. Linux Tom Gamull and pseudo Klingon Chris Rogers.

    Note: I know some of you Linux people are going to complain and say; I should be doing all this work from the CLI in Terminal. Well, you are what is wrong with the world and why we cannot have beautiful GUIs. (Sorry WordPress does not offer a sarcasm font)

    Installing and doing the basic configuration of either version is very easy and all done during the installation process. I created a user and set that user as administrator.  The first thing I did after logging in was on Red Hat Linux was to register. Then on both systems, I went to Application -> System Tools -> Software Update to make sure my system was up-to-date.

    Figure 1
    Figure 1
    Figure 2
    Figure 2

    Next step was to follow the horribly laid out Citrix instructions for Preparing the Linux machine for Virtual Desktop installation. I will be following the instructions for RHEL7/CentOS7.

    I am sure it is bad practice but I am logged in as root so I don’t get a bunch of “you ain’t the owner of this here file” errors when I attempt to edit a file. To log in as root, logoff as the current user, select Not listed and enter root when prompted for a username.

    [Tobias: Alternately, if you have the privileges, you could just su to root. (Webster: Whatever that means)]

    Note 1: Enter all commands given in the following steps in Terminal while logged in as root.

    Note 2: Whenever a file is modified with gedit, Save the file and then exit gedit.

    Following these two Notes will save me a lot of repeated typing and then I will not have to be redundant and superfluous.

    https://docs.citrix.com/en-us/linux-virtual-delivery-agent/1-4/redhat/prepare-for-installation.html

    Step 1 Verify the network configuration

    Make sure your network interface is setup and has an IP address.

    Applications -> System Tools -> Settings -> Network

    Figure 3
    Figure 3
    Figure 4
    Figure 4
    Figure 5
    Figure 5

    Step 2 Set the hostname

    To ensure that the hostname of the machine is reported correctly, change the /etc/hostname file to contain only the hostname of the machine.

    Places -> Computer

    Figure 6
    Figure 6

    Double-click the /etc  folder, scroll down to the hostname file, right-click and select Open With gedit.

    Figure 7
    Figure 7

    Verify the computer name is correct and exit the editor.

    What you should see is what we Windows people call the NetBIOS name. It should not show the FQDN of the host.

    Stay in the etc folder.

    Step 3 Assign a loopback address to the hostname

    To ensure that the DNS domain name and FQDN of the machine are reported back correctly, change the following line of the /etc/hosts file to include the FQDN and hostname as the first two entries:

    127.0.0.1 hostname-fqdn hostname localhost localhost.localdomain localhost4 localhost4.localdomain4

    For example:

    127.0.0.1 vda01.example.com vda01 localhost localhost.localdomain localhost4 localhost4.localdomain4

    This one I don’t fully understand. The machine is not a member of a domain yet but the FQDN of the machine is needed here.

    There are two closely named files: host.conf and hosts. It is the hosts file that needs to be changed.

    Right-click the hosts file and select Open With gedit.

    Note: If you see Read-only next to the filename, you are not logged in as root and you cannot edit the file. Bad person. You didn’t follow my instructions before Step 1. Tsk, tsk.

    Note: We are ignoring IPv6.

    Here is my hosts file before and after my change.

    Figure 8
    Figure 8
    Figure 9
    Figure 9

    Step 4 Check the hostname

    Verify that the hostname is set correctly.

    A command prompt is needed. That means Terminal is needed.

    Applications -> Favorites -> Terminal

    Figure 10
    Figure 10

    Type in hostname and press enter. This should return what we Windows people like to call the NetBIOS name. It should not return the FQDN. That is next.

    Figure 11
    Figure 11

    Type in hostname -f and press enter. This should return the FQDN.

    Figure 12
    Figure 12

    Leave Terminal running.

    Step 5 Check name resolution and service reachability

    Verify that you can resolve the FQDN and ping the domain controller and XenDesktop Delivery Controller.

    Enter the following commands:

    nslookup domain-controller-fqdn

    ping domain-controller-fqdn -c 4

    nslookup delivery-controller-fqdn

    ping delivery-controller-fqdn -c 4

    Note: Those Linux people sometimes prefer to use dig instead of nslookup.

    Figure 13
    Figure 13
    Figure 14
    Figure 14

    Step 6 Configure clock synchronization (NTP)

    Citrix wants us to edit the /etc/chrony.conf file. You should be logged in as root still. Go back to what we Windows people call File Explorer. You should still be in the /etc folder. Right-click the chrony.conf file and select Open With gedit.

    Here is my before and after.

    Figure 15
    Figure 15
    Figure 16
    Figure 16

    After you save your changes and exit the editor the chrony daemon must be restarted.

    /sbin/service chronyd restart

    Note: As you can see in Figure 17, the RHEL7/CentOS7 preferred command is systemctl restart chronyd.service

    Note: If you are also looking at the Citrix documentation, you will notice many of the commands to follow are preceded by “sudo“. What is this sudo thing?

    There are two ways to run administrative applications in Linux. You can either switch to the super user (root) with the su command, 
    or you can take advantage of sudo. How you do this will depend upon which distribution you use. Some distributions enable the root 
    user (such as Fedora, Red Hat, openSuSE), while some do not (such as Ubuntu and Debian). There are pros and cons for each.
    
    Sudo stands for either "substitute user do" or "super user do" (depending upon how you want to look at it). What sudo does is 
    incredibly important and crucial to many Linux distributions. Effectively, sudo allows a user to run a program as another 
    user (most often the root user).

    Since we are logged in as root, there is no need to use sudo in front of all the commands. However, I will continue to use sudo because from what I was told, sudo logs all activity so it is good practice.

    Figure 17
    Figure 17

    Step 7 Install OpenJDK

    The Linux VDA is dependent on OpenJDK. The runtime environment should have been installed as part of the operating system installation.

    Confirm the correct version:

    sudo yum info java-1.8.0-openjdk

    Figure 18
    Figure 18

    The pre-packaged OpenJDK may be an earlier version. Update to the latest version:

    sudo yum -y update java-1.8.0-openjdk

    Figure 19
    Figure 19

    Set the JAVA_HOME environment variable by adding the following line to ~/.bashrc file:

    export JAVA_HOME=/usr/lib/jvm/java

    What the heck is “~/”? In Linux that is the user’s home folder. Every user has one including the root account we are logged in as.

    Tobias Kreidl provided me with a very quick way of adding that line to the user’s bashrc file:

    echo “export JAVA_HOME=/usr/lib/jvm/java” >> ~/.bashrc

    [Tobias: The other cool feature of this is that even if JAVA_HOME is defined earlier in the script, in Linux, whatever comes last will override anything defined earlier. It’s very cool if you want to also create variables that are combinations of earlier variables, so you can build up on all these.]

    Figure 20
    Figure 20

    [Chris: From Terminal, you can also use gedit ~/.bashrc and add export JAVA_HOME=/usr/lib/jvm/java to the bottom of the file.]

    To verify the line was added:

    gedit ~/.bashrc

    Figure 21
    Figure 21
    Figure 22
    Figure 22

    Open a new shell and verify the version of Java.

    Close Terminal and open a new Terminal session.

    Type the following in Terminal:

    java -version

    Figure 23
    Figure 23

    Step 8 Install PostgreSQL

    The Linux VDA requires PostgreSQL version 9.2 or newer on RHEL 7/CentOS7.

    Install the PostgreSQL packages:

    sudo yum -y install postgresql-server

    Figure 24
    Figure 24

    sudo yum -y install postgresql-jdbc

    Figure 25
    Figure 25

    The following post-installation step is required to initialize the database and ensure service starts on boot. This will create database files under /var/lib/pgsql/data.

    sudo postgresql-setup initdb

    Figure 26
    Figure 26

    Step 9 Start PostgreSQL

    For either version of PostgreSQL, configure the service to start on boot:

    sudo systemctl start postgresql

    sudo systemctl enable postgresql

    Figure 27
    Figure 27

    Check the version of PostgreSQL:

    psql –version

    Figure 28
    Figure 28

    Verify that the data directory is set using the psql command-line utility:

    sudo -u postgres psql -c ‘show data_directory’

    [Tom: The “(1 row)” returned means the command was successful.]

    Figure 29
    Figure 29

    Step 10 Prepare the Linux VM for the hypervisor

    Some changes are required when running the Linux VDA as a virtual machine on a supported hypervisor. Make the following changes according to the hypervisor platform in use. No changes are required if you are running the Linux machine on bare metal hardware.

    Since I am running vSphere 6U2, I am only showing the instructions for VMware.

    Fix time synchronization on ESX and ESXi

    If the VMware Time Synchronization feature is enabled, within each paravirtualized Linux VM you will experience issues with NTP and the hypervisor both trying to synchronize the system clock. To avoid the clock becoming out of sync with other servers, the system clock within each Linux guest must be synchronized with NTP. This requires disabling host time synchronization.
    Note: Both RHEL7 and CentOS7 installed the open-vmware-tools so the VMware tools would not install for me. Well, not without a lot of work so I decided to just leave that alone. My two VMs both show VMware Tools as “Guest managed” with the same IP Address even though both VMs had different IP addresses.
    Figure 30
    Figure 30
    Figure 31
    Figure 31
    If you are running a paravirtualized Linux kernel with VMware Tools installed do the following steps:
    1. Open the vSphere Client.
    2. Edit settings for the Linux VM.
    3. In the Virtual Machine Properties dialog, open the Options tab.
    4. Select VMware Tools.
    5. In the Advanced box, uncheck Synchronize guest time with host.
    Figure 32
    Figure 32

    Step 11 Add Linux machine to Windows domain

    There are a number of methods for adding Linux machines to the Active Directory domain that are supported by XenDesktop for Linux:

    • Samba Winbind
    • Quest Authentication Service
    • Centrify DirectControl

    Follow the instructions below for your chosen method.

    I used Samba Winbind that Citrix recommends even though the Red Hat documentation for joining their Linux version to a domain recommends against using Winbind.

    Samba Winbind had been a traditional way of connecting Linux systems to AD. 
    Winbind emulates a Windows client on a Linux system and is able to communicate 
    to AD servers. The recent versions of the System Security Services Daemon (SSSD) 
    closed a feature gap between Samba Winbind and SSSD and SSSD can now be used as 
    a replacement for Winbind. In certain corner cases, Winbind might still be 
    necessary to use but it is no longer the first choice in general.

    Install or Update Required Packages

    Install or update the required packages.

    sudo yum -y install samba-winbind samba-winbind-clients  krb5-workstation authconfig oddjob-mkhomedir

    Figure 33
    Figure 33

    Enable Winbind Daemon to Start on Boot

    The Winbind daemon must be configured to start on boot.

    sudo /sbin/chkconfig winbind on

    Note: The RHEL7/CentOS7 preferred command is systemctl enable winbind.service

    Figure 34
    Figure 34

    Configure Winbind Authentication

    Configure the machine for Kerberos authentication using Winbind:

    Note: The following command is one command broken into separate parts by “\”. There should be no blank lines between any of the lines.

    sudo authconfig \
    –disablecache \
    –disablesssd \
    –disablesssdauth \
    –enablewinbind \
    –enablewinbindauth \
    –disablewinbindoffline \
    –smbsecurity=ads \
    –smbworkgroup=domain \
    –smbrealm=REALM \
    –krb5realm=REALM \
    –krb5kdc=fqdn-of-domain-controller \
    –winbindtemplateshell=/bin/bash \
    –enablemkhomedir \
    –updateall

    Note 1: –smbworkgroup=domain -> domain is the lowercase NetBIOS name of the Active Directory domain

    Note 2: –smbrealm=REALM and –krb5realm=REALM  -> REALM is the UPPERCASE name of the Active Directory domain

    Note 3: –krb5kdc=fqdn-of-domain-controller -> FQDN of one of your Active Directory domain controllers. Preferably the one holding the PDCe FSMO role.

    Note 4: Here is the command for my Active Directory domain LabADDomain.com:

    sudo authconfig \
    –disablecache \
    –disablesssd \
    –disablesssdauth \
    –enablewinbind \
    –enablewinbindauth \
    –disablewinbindoffline \
    –smbsecurity=ads \
    –smbworkgroup=labaddomain \
    –smbrealm=LABADDOMAIN.COM \
    –krb5realm=LABADDOMAIN.COM \
    –krb5kdc=labdc1.labaddomain.com \
    –winbindtemplateshell=/bin/bash \
    –enablemkhomedir \
    –updateall

    BEFORE YOU RUN THE COMMAND, Citrix states the following:

    Ignore any errors returned from the authconfig command about the winbind service failing to start. 
    These are due to authconfig trying to start the winbind service without the machine yet being 
    joined to the domain.
    Figure 35
    Figure 35

    Open /etc/samba/smb.conf and add the following entries under the [Global] section, but after the section generated by the authconfig tool:

    kerberos method = secrets and keytab

    winbind refresh tickets = true

    From Terminal, type in gedit /etc/samba/smb.conf and press enter.

    Figure 36
    Figure 36

    Scroll down until you see the section [global] and then AFTER the line #–authconfig–end-line– add the two lines.

    Figure 37
    Figure 37

    The system keytab file /etc/krb5.keytab is required by the Linux VDA to authenticate and register with the Delivery Controller. The kerberos method setting above will force Winbind to create the system keytab file when the machine is first joined to the domain.

    Join Windows Domain

    This requires that your domain controller is reachable and you have an Active Directory user account with permissions to add computers to the domain:

    sudo net ads join REALM -U user

    Where REALM is the Kerberos realm name in upper-case, and user is a domain user with permissions to add computers to the domain.

    Figure 38
    Figure 38

    Configure PAM for Winbind

    By default, the configuration for the Winbind PAM module (pam_winbind) does not enable Kerberos ticket caching and home directory creation. Open /etc/security/pam_winbind.conf and add or change the following entries under the [Global] section:

    krb5_auth = yes

    krb5_ccache_type = FILE

    mkhomedir = yes

    Ensure any leading semi-colons “;” are removed from each of the three settings.

    From Terminal type gedit /etc/security/pam_winbind.conf and press Enter.

    Figure 39
    Figure 39

    These changes require restarting the Winbind daemon:

    sudo /sbin/service winbind restart

    Figure 40
    Figure 40

    Open /etc/krb5.conf and change the following setting under the [libdefaults] section from KEYRING to FILE type:

    FOR RED HAT: default_ccache_name = FILE:/temp/krb5cc_%{uid}

    FOR CentOS: default_ccache_name = FILE:persistent:%{uid}

    In Terminal type gedit /etc/krb5.conf and press Enter.

    Here are my before and after.

    Figure 41
    Figure 41
    Figure 42
    `Figure 42

    Verify Domain Membership

    The XenDesktop Controller requires that all VDA machines, whether Windows or Linux, have a computer object in Active Directory.

    Verify the machine is joined to a domain using Samba’s net ads command:

    sudo net ads testjoin

    Figure 43
    Figure 43

    Additional domain and computer object information can be verified with:

    sudo net ads info

    Figure 44
    Figure 44

    Verify Kerberos Configuration

    To verify Kerberos is configured correctly for use with the Linux VDA, check that the system keytab file has been created and contains valid keys:

    sudo klist -ke

    Figure 45
    Figure 45

    Run the Kerberos kinit command to authenticate the machine with the domain controller using these keys.

    The machine and realm names must be specified in uppercase, and the dollar sign ($) must be escaped with a backslash (\) to prevent shell substitution. In some environments, the DNS domain name is different from the Kerberos realm name; ensure the realm name is used. If this command is successful, no output is displayed.

    sudo kinit -k MACHINE\$@REALM

    For my machine:

    sudo kinit CENTOS72\$@LABADDOMAIN.COM

    Figure 46
    Figure 46

    Verify that the TGT ticket for the machine account has been cached using:

    sudo klist

    Figure 47
    Figure 47

    Examine the machine’s account details using:

    sudo net ads status -U user

    Where user is a user in your Active Directory domain.

    I got back a LOT of information.

    Figure 48
    Figure 48

    Verify User Authentication

    Use the wbinfo tool to verify that domain users can authenticate with the domain.

    The domain specified here is the AD domain name, not the Kerberos realm name. For the bash shell, the backslash (\) character must be escaped with another backslash. This command will return a message indicating success or failure.

    wbinfo –krb5auth=domain\\username%password

    Figure 49
    Figure 49

    To verify that the Winbind PAM module is configured correctly, logon locally with a domain user account that has not logged onto the machine previously:

    ssh localhost -l domain\\username

    id -u

    Figure 50
    Figure 50

    Check that the tickets in the user’s Kerberos credential cache are valid and not expired:

    klist

    Figure 51
    Figure 51

    Exit the session.

    exit

    Figure 52
    Figure 52

    Step 12 Install the Linux VDA

    https://docs.citrix.com/en-us/linux-virtual-delivery-agent/1-4/redhat/install-linux-vda.html

    Note: I will let you know the following instructions from Citrix do not work but we will still get the job done.

    Install the Linux VDA using yum:

    sudo yum install -y XenDesktopVDA-1.4.0.356-1.e17.x86_64.rpm

    Figure 53
    Figure 53

    Uh oh, now what. I turned to Google and asked “search linux yum for packages” from which the first hit was for CentOS.

    https://www.centos.org/docs/5/html/yum/sn-searching-packages.html

    Using the Advanced Searches on that page, I tried the following with no success:

    sudo yum search XenDesktop

    sudo yum provides XenDesktop

    sudo yum provides VDA

    Figure 54
    Figure 54

    Now what? As we American style football fans say, “Punt!”. Time to see if the Linux VDA is available on the XenApp/XenDesktop product download page.

    Using an internet browser in your Linux VM, log in to Citrix.com and go to the downloads page for XenApp & XenDesktop.

    Expand XenApp 7.11 / XenDesktop 7.11 and expand Components. There you will see the link to download the Linux Virtual Delivery Agent 1.4.

    Figure 55
    Figure 55

    Click that link, scroll down to and expand the option for your flavor of Linux.

    Figure 56
    Figure 56

    Click Download File under your flavor of Linux.

    Figure 57
    Figure 57

    Accept the License Agreement. Since we are logged in as root, select Open with Software Install (default) and clock OK.

    Figure 58
    Figure 58

    Click the Software option on the taskbar.

    Figure 59
    Figure 59

    Click Install.

    Figure 60
    Figure 60

    When the red Remove button appears, exit the XenDesktopVDA installation dialog and your internet browser.

    Figure 61
    Figure 61

    Before we continue, the Install screen showed the package name for the LinuxVDA. I just want to see if the yum search command will find that package.

    sudo yum search linuxvda

    sudo yum list citrix-linuxvda-rhel7-1.4.0

    sudo yum list citrix-linuxvda-rhel7-1.4.0.rpm

    None worked.

    Figure 62
    Figure 62

    Oh well, looks like Citrix wants to keep the Linux VDA to themselves.

    After all this work, I would recommend restarting your Linux VM just to make sure everything is fresh before the next steps.

    Update: Tom showed me how to find the Linux VDA package. Citrix changed the name but didn’t update their documentation! I know, shocking, isn’t it.

    sudo yum search citrix

    Figure 63
    Figure 63

    Now that we finally found the package, what version is it?

    sudo yum info XenDesktopVDA.x86_64

    Figure 64
    Figure 64

    Yes, that is the correct version. Citrix, update your documentation!

    If you want to install this package:

    sudo yum install -y XenDesktopVDA.x86_64

    Note: Notice there is no “.rpm” file extension.

    Step 13 Configure the Linux VDA

    After installing the package, you must configure the Linux VDA by running the ctxsetup.sh script. Before making any changes, this script will verify the environment and ensure all dependencies are installed. If necessary, you can rerun this script at any time to change settings.

    Prompted configuration

    Run a manual configuration with prompted questions:
    sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
    Figure 65
    Figure 65

    Answer each question asked. The Citrix documentation shows how to automate the script.

    When the configuration is complete, exit Terminal.

    Figure 66
    Figure 66

    We are now FINALLY ready to create our Machine Catalog.

    Step 14 Create Machine Catalog

    https://docs.citrix.com/en-us/linux-virtual-delivery-agent/1-4/redhat/configure-machine-catalog-and-delivery-group.html

    The process for creating machine catalogs and adding Linux VDA machines is very similar to the traditional Windows VDA approach.

    For creating machine catalogs that contain Linux VDA machines, a few restrictions differentiate the process from creating machine catalogs for Windows VDA machines:

    • For operating system, select:
      • Window Server OS or Server OS option for a hosted shared desktops delivery model.
      • Windows Desktop OS or Desktop OS option for a VDI dedicated desktop delivery model.
    • Ensure machines are set as not power managed.
    • As PVS and MCS are not supported for Linux VDAs, choose the Another service or technology (existing images) deployment method.
    • Do not mix Linux and Windows VDA machines in the same machine catalog.

    In Citrix Studio, right-click on Machine Catalogs and select Create Machine Catalog.

    Figure 67
    Figure 67

    Select Desktop OS and click Next.

    Figure 68
    Figure 68

    Select Machines that are not power managed and Another service or technology and click Next.

    Figure 69
    Figure 69

    Select the appropriate option and click Next. I am choosing Static as I only have one desktop and my Citrix Admin account will use it.

    Figure 70
    Figure 70

    Click Add computers…

    Figure 71
    Figure 71

    Enter the computer name and click OK.

    Figure 72
    Figure 72

    Click the  under User names.

    Figure 73
    Figure 73

    Enter the user name for this desktop and click OK.

    Figure 74
    Figure 74

    Click Next.

    Figure 75
    Figure 75

    Enter a Machine Catalog name, an optional Machine Catalog description and click Finish.

    Figure 76
    Figure 76

    The Machine Catalog appears in Studio.

    Figure 77
    Figure 77

    If you look at the Installed VDA version, it shows version 7.11.0.356 but we installed Linux VDA 1.4. Citrix has an article showing the mapping between the VDA versions.

    Step 15 Create the Delivery Group

    The process for creating a delivery group and adding machine catalogs containing Linux VDA machines is almost identical for Windows VDA machines. Refer to the online Citrix Product documentation for a more complete description of how to complete these tasks.

    For creating delivery groups that contain Linux VDA machine catalogs, the following restrictions apply:

    • For delivery type, select Desktops. Linux VDA machines do not support application delivery.
    • Ensure the AD users and groups you select have been properly configured to logon to the Linux VDA machines.
    • Do not allow logon of unauthenticated (anonymous) users.
    • Do not mix the delivery group with machine catalogs that contain Windows machines.

    In Citrix Studio, right-click on Delivery Groups and select Create Delivery Group.

    Figure 78
    Figure 78

    Verify the Linux desktop Machine Catalog is selected and click Next.

    Figure 79
    Figure 79

    If using Static Desktop, verify the User Assignment is correct and click Next.

    Figure 80
    Figure 80

    Since, at this time, you cannot do published applications with the current Linux VDA, select Desktops and click Next.

    Figure 81
    Figure 81

    Select the appropriate Users option and click Next.

    Figure 82
    Figure 82

    Click Add…

    Figure 83
    Figure 83

    Enter a Display nameDescription, select a User option, Maximum desktops per user, leave the Enable desktop assignment rule selected and click OK.

    Figure 84
    Figure 84

    Click Next.

    Figure 85
    Figure 85

    Enter a Delivery Group name, an optional Delivery Group description and click Finish.

    Figure 86
    Figure 86

    The new Delivery Group appears in Studio.

    Figure 87
    Figure 87

    Now to the last step, accessing the desktop through StoreFront.

    Step 16 Access the new Linux Desktop using StoreFront

    Log on to StoreFront using Active Directory domain credentials using a user who has access to the Linux desktop.

    Figure 88
    Figure 88

    My Red Hat Enterprise Linux and CentOS7 desktops appear as available.

    Figure 89
    Figure 89

    I can now launch both desktops.

    Figure 90
    Figure 90
    Figure 91
    Figure 91

    Step 17 What about the XenApp/XenDesktop V2 Documentation Script?

    Glad you asked since the entire purpose of this experiment was to make sure the V2 script handles the Linux VDA correctly. How does it do? Not bad if I say so myself (but I may be a tad biased).

    Figure 92
    Figure 92
    Figure 93
    Figure 93
    Figure 94
    Figure 94
    Figure 95
    Figure 95

    Bottom Line

    1. This was fun and I learned a lot over the three days I spent on this project. It really helps to have great friends like Tobias, Tom, Chris and all the people who responded on Twitter when I had questions.
    2. Citrix really needs to make this Linux VDA documentation more understandable for those who may want or need to test it for their business who, like me, may know nothing about Linux other than how to spell the name.
    3. Citrix really needs someone to actually step through their documentation and see what a PITA it is to use what they write.
    4. I prefer Red Hat Linux to CentOS because Red Hat just “feels” more polished and more “better” to this very non-Linux person.
    5. What is the point of all the manual steps? I thought those Linux people were supposed to excel in scripting and automation.
    6. If I cannot (yet) use MCS or PVS with the Linux VDA, how the heck do you do all these manual steps on hundreds of Linux desktops to get them ready for XenDesktop?

     

    About Carl Webster

    Webster is a Sr. Solutions Architect for Choice Solutions, LLC and specializes in Citrix, Active Directory and Technical Documentation. Webster has been working with Citrix products for many years starting with Multi-User OS/2 in 1990.

    View all posts by Carl Webster

    to “Implementing Red Hat Enterprise Linux 7 and CentOS7 Linux with Citrix XenDesktop 7.11”

    1. Zaheer Says:

      Hi Carl,

      How do i login as root in linux VDA??

      Its getting logged in as domain user..

      Reply

      • Carl Webster Says:

        I don’t know so I asked fellow CTP Tom Gamull who is a Linux expert. His response:

        You’d have to ssh but most people wouldn’t logon as root. They would run a sudo command or “wheel to root”. Since root is a Linux account I don’t see a way to map a user in ad to it from the Citrix vda side.

        Webster

        Reply

    2. Juan Perez Says:

      Hello Carl,

      Wondering if you have an update to this? I have a client with interest for a Linux deployment, but as you said in this post. If it can’t be managed with a single image method – whats the point?

      Reply

      • Carl Webster Says:

        I need to do a follow-up article using the latest RedHat supported version and the latest VDA and the latest instructions. From my understanding, the latest instructions are much easier but since I haven’t tried, I don’t know. Please remember, I can spell Linux and that is as far as my Linux knowledge goes. It helps that there are a few CTPs who have strong Linux experience.

        Webster

        Reply

    3. Tomasz Says:

      why this is present in every manual:

      echo “export JAVA_HOME=/usr/lib/jvm/java” >> ~/.bashrc

      if the deirectory even does not exist on any centos after java instalation?

      here is on centos 7:

      # java -version
      openjdk version “1.8.0_111”
      OpenJDK Runtime Environment (build 1.8.0_111-b15)
      OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)
      # ls /usr/lib/jvm/java
      ls: cannot access /usr/lib/jvm/java: No such file or directory
      #

      does the zombie JAVA_HOME export is valuable here at all?

      Reply

      • Carl Webster Says:

        Since I can barely spell Linux, I asked a fellow CTP who works for a Linux vendor.

        “…I’d imagine fedora, RHEL and CentOS use the default /etc/alternatives/java which is what the export should be set to”

        Webster

        Reply

    4. Sean Says:

      Very good info. Many thanks.

      Reply

    5. Sylvester Says:

      Hi Carl

      Great Post, after looking through the citrix documentation, this post helped alot!

      Thanks for that.

      Sylvester

      Reply

    6. Larry Lambert Says:

      Great article! Have you tried getting it to work with the FAS? Integration with FAS would allow SSO with Smart Card, which I am very interested in. Works great with Windows VDA.

      Reply

    7. Helmut Hauser Says:

      Hi Carl,

      Very nice article. +1.

      BTW
      Has anyone tried to get the 1.4 Linux VDA up and running on Ubuntu 16.04 LTS [Debian]? I know that this is not supported but it seems to work if you use alien to convert the RPM.

      Reply

      • Carl Webster Says:

        I am trying to test the VDA on Ubuntu. I believe my desktop is connected to my AD domain but when I go to run “id”, it does not work. I also cannot get any domain user to log on to the desktop. Until I can overcome that obstacle, I cannot continue.

        After working with Ubuntu and CentOS, I am still preferring RHEL. I may have to test on Fedora and see what happens.

        Thanks

        Webster

        Reply

    8. Tom Gamull Says:

      One note the command to add JAVA_HOME may be incorrect, you want to find out if there is a file there:

      ls -la /usr/lib/jvm

      see if there is a java reference.

      This linke may need to change, for example for RHEL7 defaults, it is /etc/alternatives

      -export JAVA_HOME=/usr/lib/jvm/java
      +export JAVA_HOME=/etc/alternatives/java

      Reply

    9. Martyn Dews Says:

      Hi Carl

      Great article. Thanks for sharing. As I hinted on Twitter, I decided
      the other day to have a run through this and see what all the fuss is
      about. I have a little Linux experience but I’m far from proficient
      however the Internet is a great source of knowledge for this sort of
      thing filling in the gaps where sadly the Citrix documentation lets us
      down. I share your comments around the documentation in that, while
      OK, could be much better. The simple act of an inexperienced person
      running through the document should be enough to pick out some of the
      errors; one being the mistake of the VDA being named wrong. I got stuck on that part too!

      An interesting exercise though and it was good to get some more experience of Linux.

      Reply

    Leave a Reply