Category Archives: Microsoft

VMware App Volumes Design Methodology

Though I do enjoy working with Unidesk when deploying virtual desktops, its inevitable that at some point, I’ll deploy applications to virtual desktops using VMware App Volumes.  To that end, I attended a 2 part webinar which went over some of the basics of the technology so as to gain some familiarity and insight into VMware’s application layering strategy.

App Volumes differs from Unidesk somewhat in that VMware recommends that multiple applications be grouped into “like” AppStacks.  For example, you may have:

  • An AppStack that contains the core or global applications required by all users
  • An AppStack that contains applications needed by a specific group/department
  • One-off AppStacks that contain applications those applications which may not be global or departmental, but needed for special use cases

The idea is to keep the number of AppStacks to a minimum.  Why?  My understanding is this…VMware App Volumes assigned AppStacks to Active Directory user groups, thus the application AppStacks cannot be added to a virtual machine until a user logs in.  At this point the Cloud Volumes agent will attach any AppStacks to which the user has permissions to the virtual desktop; thus,  the more AppStacks you assign to a user, the longer it could take for the logon process to complete and so it’s best practice to keep the number of AppStacks assigned to a given user around 10 if at all possible.

In Unidesk, there’s nothing stopping you from grouping applications together like this, but personally, I install each application into its own layer….I find this allows for greater flexibility or even creativity when building and deploying virtual desktops.  As opposed to App Volumes, Unidesk assigns applications to virtual machines and so the virtual machine is ready to go when the user logs in….no need to wait for additional layers after the user logs in.

So it appears to me, that more thought will go into designing App Volumes and to assist us, VMware has developed a 5-step design methodology:

1. Assessment

  • Which groups use which applications today?
  • How are applications delivered to the end user?
  • Are there existing application delivery mechanisms like SCCM, GPOs, ThinApp, or App-V?
  • Identify unsuitable applications, like Anti-Virus or any application that must be running even when no user is currently logged in.  This will help you to determine which applications must be loaded into the “master” or base image.
  • Determine what types of devices/OS’s App Volumes will be delivered to

2. Discovery

  • In the Assessment phase, you’ll determine the if an application packaging and deployment strategy exists – does the organization like it?  Is the existing strategy reliable?
  • If no application deployment mechanism exists, find the source media/installers and your license keys.  Does a KMS server exist?
  • Begin to consider application groupings
  • Who will maintain the AppStacks?  Will the desktop support team maintain them all or just the global AppStack?  Will each department have a point person in charge of maintaining the departmental AppStacks?

3. Plan and Design

  • Determine and create if necessary, required Active Directory user groups and their AppStack assignments
  • Determine which applications will be installing into the master image and which will be installed into AppStacks
  • Assign AppStacks to their appropriate Active Directory group
  • Who gets writable volumes?
  • Document AppStack update procedures
  • Determine pilot users

4. Build and Test

  • Determine success criteria and develop a test plan that accurately measures them
  • Deploy the solution to the pilot group and measure user acceptance for performance, manageability, and security against the success criteria
  • Create a punch-list detailing any deviations from the success criteria

5. Optimization

  • Review the punch-list and make any necessary changes.
  • Did App Volumes perform as expected?  If not, how can the overall process be improved?
    • Was the any effect on logon times?
    • Any confusion regarding the update process?
    • Are the “mixtures” of applications in each AppStack optimal or should the groupings be changed?
  • Test with pilot group after changes have been made and fine tune design based on UAT

As is the case with all technologies, a successful design methodology has a tremendous impact on the overall success on the deployment of that technology and VMware App Volumes is no different.  If you will be deploying VMware App Volumes, don’t rush through it and keep in mind the design methodology described above to increase your chances of success when rolling it out to your virtual desktops and end users.

Leave a comment

Filed under Microsoft, 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

Part 1 – SQL Database Mirroring for Citrix XenApp/XenDesktop 7.x – Creating the Database

In XenApp/XenDesktop 7.x environments, an often overlooked element of Citrix best practices is ensuring high-availability of the Citrix databases.  Personally, I blame this on the ease by which database high-availability could be enabled in XenApp 6.5. All you had to do was mirror the database, edit the DSN file to add a Failover Partner, then restart the IMA service and you’re done….nice and easy.

But in XA/XD 7.x, the process to setup database HA is much more involved and requires that all delivery controllers be disconnected from the existing database prior to configuring the mirror.  Written by Carl Webster, here is an impressive blog post that details the process of changing a production XA/XD site to use SQL mirroring.  If you are faced with this task, I hope your Citrix infrastructure is virtual and that you remember to take snapshots before starting.

What I’m going to do here, is detail the process to setup SQL database mirroring for XA/XD 7.x from the beginning. I’m going to break it into 4 posts so as to detail each step and to avoid a single post that’s longer than my attention span.  In my lab, I ran SQL Server 2012 on Windows Server 2008R2 Standard so what you see when setting up database mirroring may be slightly different that what is presented here.

First, a few things to remember when installing SQL, when you get to the Server Configuration screen:

  • On the Feature Selection screen, the only items needed to support database mirroring are Database Engine Services and Management Tools (Basic and Complete)
  • On the Server Configuration screen, configure the SQL Server Database Engine service to use a domain account and use the same account on all SQL servers (Principal, Mirror, and Witness servers).  I have seen documentation that says all (3) SQL services should be set to use the domain account but in my experience, I’ve had success when setting only the SQL Server Database Engine to use a domain account.
  • Set the SQL Server Browser service to Startup Type to Automatic


If you do not use a domain account for the SQL Server Database Engine service, the database mirror wizard will fail and you’ll likely see an error similar to that shown below as well as a MSSQLSERVER 1474 error in the Application Event Log


  • On the Database Engine Configuration screen, choose your preferred Authentication Mode.  Personally, I selected Mixed Mode because I like having the SA account as a fallback.  Under Specify SQL Server administrators, add the domain account used by the SQL Server Database engine service.

Now that SQL is installed, let’s create our Citrix database.

1. On what will initially be the principal SQL server, open SQL Server Management Studio

2. Right-click Databases and select New Database.

3. On the General page, specify a Database Name and then click Options.


4. On the Options page, you must set the Recovery model to Full in order to support Database Mirroring.  But what do you set Collation to?  Does it make any difference?

My Collation Story

I’m no SQL admin, I admit it!  I’m not ashamed of it….I don’t know if I truly understand the depth of the meaning of collation, nor if I even care to, but I think it has something to do with how data is sorted.  I can say this about collation, in terms of setting up a XA/XD environment, it does matter.  At this point of my installation, I decided to experiment a little bit by setting collation to different values to see how XA/XD would react when I tried to create my Site.  As it turns out, if the collation is wrong for XA/XD, you see an error message saying so, it specifically says that you must use a collation which ends with “_CI_AS_KS”.  In general, it is best to use a collation which ends with “_100_CI_AS_KS”.


HA!  So, what did I do when creating my database?  I set the collation to Latin1_General_100_CI_AS_KS which is in alignment with Citrix support article CTX127359, How to Configure XenDesktop for SQL Database Mirroring, which states in Step 1!!!, “Create an empty database on the principal with the Latin1_General_100_CI_AS_KS collation sequence.


Oh, but if only my collation story ended there…..let’s fast forward again to setting up the XA Site.  When running the XA Site Setup Wizard, you are prompted to specify the database server and the database name.  After doing so, you click Test Connection ensure connectivity to SQL.


With the collation set to Latin1_General_100_CI_AS_KS, I received an error that my account had insufficient permissions to access the database server:


Upon some troubleshooting and research, there was a suggestion to change the collation.  Change the collation!!  Why, it’s set according to documentation from Citrix as well as the error within XA/XD itself….I set it to what Citrix has asked for!  But I checked everything else I could think of and so, I decided to change the collation to Latin1_General_CI_AI_KS and wouldn’t you know it, the database connectivity test passed.

The good news…I had already setup my database mirror and was able to change the collation on the mirrored database without any problems, without having to delete my mirror and start from scratch, etc.

4. (continued from above) So the point of the collation story is this; when setting up your Citrix database, use the Latin1_General_CI_AI_KS collation method.


5. Click OK to create the new CitrixDB database.

With the database created, the next step (to be covered in Part 2 of this series) in setting up the mirror is to backup the database on the principal and restore it onto the mirror.


Filed under Citrix, Microsoft