Tag Archives: Citrix

CentOS 7 and Citrix – ctxvda status error

Over the course of the last few weeks, I’ve gotten an opportunity to explore building and publishing Linux virtual desktops using Citrix XenDesktop 7.11.  Now, I’m no Linux admin/expert which means configuring all this has been challenging at times even with the resources available on the web. Though the Linux VDA will support Red Hat, SUSE, and CentOS, I chose CentOS as my starting point because it’s free in that it does not require additional licensing to use beyond a 60-day demo period.

With that, my starting point for configuring CentOS 7 with XenDesktop 7.11 was the Citrix blog Installing the Linux VDA on Red Hat or CentOS 6.  I highly recommend this blog if you are new to Linux and need a launching pad from which to start your own feasibility testing for publishing Linux via Citrix.

Upon completing the installation of the Citrix VDA and executing ctxsetup to customize the VDA, I waited patiently (2 minute of hitting refresh) for the machine to register with the delivery controller but it never did and so commenced my Linux troubleshooting career.

1. On my Linux workstation, I started a terminal session and ran the command service ctxvda status to see if the VDA service was running:


2. So the VDA service failed to start….but why?  Next I reviewed the VDA log file to see a reference to Citrix KB article CTX119736:


Sweet!!!!  My solution is waiting for me….all I have to do is find the article and my issue will be resolved very shortly and I’ll be accessing my virtual desktop in no time.  BUT, if you try and find CTX119736, you’ll likely encounter the following:


3. Though I couldn’t find CTX119736, the more time I spent looking for it, the basic troubleshooting starting points became somewhat clear and really they are not that much different for Windows hosts….check the time, check the network, check name resolution, etc.  What I found going through those steps is that the time, the network and name resolution worked from the Linux workstation side, but the delivery controller could not ping the Linux workstation by name.  Looking at DNS on the server side revealed that though the workstation retrieved a DHCP address, a host (A) record was not created for it in DNS, thus the delivery controller could not communicate by name.  The DHCP scope options were set to dynamically update DNS records for clients that do not request updates.


4. I rebooted the Linux workstation and after doing so, the Citrix VDA service started and it successfully registered with the delivery controller.


I was surprised that a name resolution issue kept the ctxvda service from starting altogether and it was one of the last basic options I checked.  I figured that if DNS/name resolution was the issue that the ctxvda service on the Linux workstation would start, but that registration would fail.  However, when troubleshooting ctxvda service errors from this point forward, name resolution will be my first test.

Leave a comment

Filed under Citrix, Linux, VDI

The Death of Citrix Provisioning Server?

I won’t go into great detail in regards to benefits of layering technologies when deploying VDI solutions.  I will say, and perhaps this is an oversimplification, that the goal of any layering technology (such as Unidesk or VMware App Volumes) is to simplify the deployment, management, and updating of operating systems and applications that comprise a virtual desktop environment using a building block approach.

In my head, I visualize OS and application layers as Lego’s.  I think of the OS layer as that big green piece which serves as the foundation and the smaller blocks, representing the application layers, are used to build whatever my mind imagines. Though I may have a finite number of pieces, I can use those pieces in an infinite number of ways.

So, what does this have to do with Citrix Provisioning Server?

Citrix Provisioning Services (PVS), often referred to as the “secret sauce” of any XenApp/XenDesktop deployment, provides a streaming service which allows physical or virtual computers to obtain an image from the network. When using PVS, an administrator prepares a Master Target Device for imaging by installing an operating system and any required applications on that device.  A vDisk image is created from the Master target device’s hard drive and saved to the network.  The Provisioning Server(s) are then configured to stream the vDisk to configured target devices on demand, in real time.

To date, PVS has been the primary method of deploying, managing, and updating server images to ensure consistency throughout the XenApp environment.  However, going forward, will PVS continue to be the primary method used to deploy new XenApp servers and ensure consistency throughout the environment?  As good as PVS is, I’ve encountered 2 main problems in which it is used in XenApp environments:

1. Gold image sprawl

  • Even in the most basic PVS environments, organizations will inevitably have multiple master images.
    • Some applications won’t work together with others and so multiple master images need to be created to separate applications which don’t necessarily mix well.
    • Multiple images may be created to support the publishing of different versions of the same application, for example, Office 2010 and Office 2013.  Since they cannot exist on the same server/image, a new image would be needed to publish both Office 2010 and Office 2013 simultaneously.
    • In regards to the previous two bullet points, I’ve assumed an organization has chosen to simply publish applications, but what if XenApp is used to publish desktops and different departments have different applications?  I know you can get crafty and “hide” the Program Files menu as well as the C:, using application publishing the Receiver to place application shortcuts on the desktop and I have seen customers do that to avoid deploying a master image for each unique use case….but I’ve also seen others deploy separate gold images to meet the need to each department.

2. Complexity

  • Though its true PVS makes deploying and managing XenApp easier, it can be complex in its own right
    • If a customer has no previous experience with PVS, I have experienced longer learning curves when deploying and attempting to teach the technology to new administrators.  I say attempting because I realize part of the problem in “getting” PVS may be in my teaching.  Regardless, it can take some time for the “light bulb” to go off and the administrator to feel confident in using the technology.
    • Depending gold image sprawl, you may also see PVS sprawl.  If the number of gold images and/or the number of user connections increase, you’ll likely need more Provisioning Servers to do the work.

Toward the end of last year, upon thinking of an upcoming project and the number of master images I’d need to support the various application mixtures, I had the thought that my life would be much easier if I could use application layering (specifically Unidesk in this case) to deploy my XenApp servers, avoiding PVS altogether.  In fact, I went so far as to open a case with Unidesk asking if this were possible, here’s the actual question I asked Unidesk support:

I got to thinking, “Is there any way I can use Unidesk to build Citrix XenApp servers?  And once I assign the layers to these servers, can I then publish them out like I would a typical XenApp scenario?  Can I replace Provisioning Server with Unidesk?”

Maybe I don’t love PVS as much as the next guy….but I thought, “O, to eliminate PVS!  O, to avoid the complexity of multiple master images! O, to be able to deploy XenApp servers using application layering!”….that may be somewhat of an embellishment, but the thought was a good one.  I firmly believed that if I could deploy XenApp servers with layers, I could eliminate gold image sprawl and the complexity of PVS.

Well unbeknownst to me, Unidesk and VMware, through App Volumes, thought the same thing and now (or very shortly), I will be able to use both Unidesk and VMware App Volumes to deploy XenApp servers using OS and application layering! Because layering separates the OS from the applications, an organization should be able to consolidate their PVS images into a single OS template (big green Lego pad) and then use application layers (Lego blocks) to construct and customize the XenApp server based on its specific purpose or use case.

Granted, layering won’t eliminate server silos; if you need to simultaneously publish Office 2010 and 2013, you’ll still need a group of XenApp servers with an Office 2010 application layer and another group with Office 2013, but layering will eliminate the need for multiple master images to support such a scenario.  Additionally, when using layering technologies to deliver XenApp, complexity is reduced since a PVS infrastructure, and all that it entails, is no longer required.

Think of the voice of the narrator from the old Batman TV show….”Is this the end of PVS?!”  I’ll commit to doing my part but ultimately, you’ll be the one who determines the answer.

Leave a comment

Filed under Citrix, Unidesk, VDI, VMware

Part 4 – SQL Database Mirroring for Citrix XenApp/XenDesktop 7.x – Installing Citrix XenApp

This post will conclude the series which looks at database mirroring for Citrix XA/XD 7.x environments.  The previous posts are as follows:

Here, I’ll briefly cover the installation of the first delivery controller and verify that the mirror is detected by Citrix.

1. In terms of the installation of Citrix, overall I accepted the default options but I did uncheck Install Microsoft SQL Server 2012 SP1 Express on the Features screen since the database was mirrored on SQL Servers.


2. After the installation is completed, launch Citrix Studio.  Under Site Setup, click Deliver Applications and Desktops to your users.


3. On the Introduction screen, enter a Site Name and click Next.

4. On the Database screen, for the Database server location, enter the principal SQL server.  Under Database name, enter the SQL database name as created earlier and then click Test connection.


5. When prompted that the services could not connect to the database, click OK.


6. When prompted that the database connections tests have passed, click Close.


7. When returned to the Database screen, click Next.

8. On the Licensing screen, specify the appropriate license configuration and click Next.

9. On the Connection screen, specify the path and credentials to the virtual infrastructure and click Next.  Below is an example of connecting the Site to a VMware vSphere infrastructure:


10. On the Resources screen, specify the Cluster and virtual networking for virtual machines then click Next.


11. On the Storage screen, select the storage devices to be used by virtual machines and click Next.


12. On the App-V Publishing screen, make the appropriate selection (Yes or No) and click Next.

13. On the Summary screen, click Finish to build the site.  It may take some time for the Site Setup Wizard to complete its tasks….be patient.


When the site has been successfully created, click Configuration and verify the Server and Mirror Server Addresses as shown below:


With that, the Citrix database and site are configured according to best practices.  Again, you can configure mirroring after the initial site creation process, but you may find it easier and safer to perform this process prior to rolling it out into production.

Leave a comment

Filed under Citrix, Microsoft

Part 3 – SQL Database Mirroring for Citrix XenApp/XenDesktop 7.x – Establish the Mirror

In parts 1 and 2, I’ve setup the Citrix database and performed a backup and restore in order to support database mirroring for redundancy in the Citrix environment.  In this post, I’ll setup SQL database mirroring.

When setting up database mirroring, you have the potential to specify (3) SQL servers:

  • Principal Server – MANDATORY – Server on which the database is currently in production (read-write)
  • Mirror Server – MANDATORY – Server on which the database is currently read-only
  • Witness Server – OPTIONAL – a SQL instance that monitors the servers and performs automatic failover should the principal server become unavailable.  A witness server, which can run SQL Express, is required to support automatic failover of the database.

Though I won’t recommend it, in my lab, I had the following setup and had no problems establishing the database mirror:

  • SQL Server 2012 SP2 running on my Principal and Mirror servers
  • SQL Express 2008R2 running on my Witness server

To setup SQL Database Mirroring

1. On the Principal server, open SQL Server Management Studio and expand Databases.  Right-click CitrixDB and select Tasks | Mirror


2. On the Database Properties | Mirroring screen, click Configure Security.


3. On the Configure Database Mirroring Security Wizard screen, click Next.

4. On the Include Witness Server screen, click Yes and click Next.


5. On the Choose Servers to Configure screen, select Witness server instance and click Next.


6. On the Principal Server Instance screen, the principal server should be filled out correctly so click Next.


7. On the Mirror Server Instance screen, Connect to the appropriate mirror server instance and click Next.


8. On the Witness Server Instance screen, Connect to the appropriate witness server instance and click Next.


9. On the Service Accounts screen, enter the appropriate domain level account for all services and click Next.  The accounts should be the same for all servers….and though I used the administrator account here, I wouldn’t recommend it in full production.


10. On the Complete the Wizard screen, click Finish.


11. Once the endpoints have been successfully configured, click Close.


12. On the Database Properties pop-up, click Start Mirroring.


13. When returned to the Database Properties | Mirroring screen, ensure the database Status reads Synchronized: the databases are fully synchronized and click OK.


14. The success of the mirroring operation can be further verified in SQL Server Management Studio as shown below:


At this point, the database is mirrored.  The next post, the final one of this series, will detail the setup of the first Citrix XA/XD delivery controller.

1 Comment

Filed under Citrix, Microsoft

Part 2 – SQL Database Mirroring for Citrix XenApp/XenDesktop 7.x – Backup and Restore

In Part 1 of this series, I looked at the steps required to create a blank database which will be mirrored and used to support, in my case, a XenApp 7.6 environment.  In this post, that discussion continues and we’ll look at the next step in the mirroring process, backing up the database on the principal server and restoring on the mirror.

On the Principal SQL Server

Perform the following steps on the principal SQL server:

1. Open SQL Management Studio and expand Databases.  Right-click the Citrix database and select Tasks | Back Up

2. On the Back Up Database screen, set the Backup type to Full and then set the Destination.  Here, I simply backed up the database (with a .bak extension) to the SQLBackup directory I had previously created on the local disk.  Click OK to start the backup; it should not take more than a few seconds to complete.


3. Click OK when the backup completes successfully.


4. A second backup of the Citrix database is required to backup the transaction logs.   Thus, right-click the Citrix database once again and select Tasks | Back Up

5. On the Back Up Database screen, set the Backup type to Transaction Log and then set the Destination.  **When specifying the file name, be sure to use the .trn extension.  Click OK to start the backup; it should not take more than a few seconds to complete.


6. Copy the .bak and .trn backup files from the principal to the mirror server.


On the Mirror SQL Server

1. On what will be the mirror SQL server, open SQL Management Studio, right-click Databases and select Restore Database.


2. On the General tab, under Source, select Device and browse for the backup files that were copied to the mirror server.


3. The information concerning the backup file is displayed as shown below….DO NOT CLICK OK, click Options.


4. Set the Recovery state to RESTORE WITH NORECOVERY and then click OK to perform the restore.


5. Click OK when prompted that the database has been restored.

Next, you’re to restore the transaction logs using the same process, however let me share my:

Restoring Transaction Logs Story

Yes, by all accounts you should be able to restore your transaction logs using the same process as restoring the database itself, but that wasn’t the case for me and it looks like it may be a SQL 2012 “bug”….anybody can correct me if I’m wrong in saying that.

When I attempted to restore using the same steps as above while selecting my .TRN backup, I received an error in SQL stating Unable to create restore plan due to break in the LSN chain.  Awesome!


A quick search revealed that I was not the only one to have this problem.  Several posts commented that though the Restore Database method would fail, the following methods were successful:

  • restore via SQL Query/command-line
  • restore using “Restore Files and Filegroups” option

6. To restore the transaction logs, right-click Databases and select Restore Files and Filegroups


7. The process from this point is basically identical but does look slightly different.  As before, on the General page, select the transaction log backup (.TRN) as the source Device but DO NOT CLICK OK.  Click Options, and select the RESTORE WITH NONRECOVERY option as shown below, then click OK.

8. When prompted that the database has been restored, click OK.

This completes the steps required to backup the database on the principal server and restore onto the mirror server.  In Part 3, we will setup the database mirror.


Filed under Citrix, Microsoft