Category Archives: Citrix

Update a Static/Dedicated MCS Image (vSphere)

The other day I made a change to the “master” machine that was initially used for the deployment of several MCS static/dedicated desktops. When I went to deploy additional desktops, I expected the changes to persist from the master. Guess what? That was not the case. But WHY?

If you pay close attention when you initially deploy the image, you will notice that MCS will do a full VMDK copy of your snapshot chain into a folder of every datastore that is defined in your hosted XenDesktop environment. This makes desktop creations extremely quick when scaling out additional VMs because it 1) negates the need to potentially copy VMDKs across datastores during desktop creation and 2) negates the need to consolidate snapshots during creation. The folder will typicially be the machine catalog name + basedisk + random datastore identifier assigned by XenDesktop. This applies to all MCS images; static and pooled.

We obviously want to keep the master of dedicated machines up-to-date to avoid unnecessary SCCM pushes, Windows updates, missed software, etc. when we deploy new desktops. Unfortunately Citrix does not give a GUI option for this, like we get on our pooled desktops in Studio:

So, what is almost always the method of action when no GUI option is available? That’s right – PowerShell!

There are two main things to consider here: the “Provisioning Scheme” and the new “Master Image.” The provisioning scheme name almost always matches the machine catalog name. It keeps track of the master image location and some other metadata. The master image is just the snapshot of your master machine that MCS does that full VMDK copy to each datastore that we talked about earlier.

Let’s get right to it. First, open PowerShell on your DDC, and get the provisioning scheme name and the current snapshot that is being used for the master:

add-pssnapin *citrix*

Get-ProvScheme

This will return two very important things for each MCS machine catalog: 1) the ProvisioningSchemeName and 2) the MasterImageVM. You will notice that this contains the name of the snapshot that mirrors the name you provided in vSphere, followed by .snapshot. This makes it easy to locate! Let’s assume our current snapshot is named “v1” and our master is named “XDMaster1.” So the MasterImageVM should look like:

XDHyp:\HostingUnits\<Cluster Name>\XDMaster1.vm\v1.snapshot

Note: If your VM is in a resource pool, this path will also contain that as a “directory.”

We will create a snapshot named “v2” on the master and make some changes, updates, etc. and shutdown the master. Let’s verify that XenDesktop now sees this snapshot in our hypervisor environment:

get-childitem -path “XDHyp:\HostingUnits\<Cluster Name>\XDMaster1.vm\v1.snapshot”

You will see that v2.snapshot is now a child item of your v1.snapshot! Good deal! So how do we point MCS to this snapshot? Simple:

First, let’s make it easy on ourselves and create a couple of variables. The two important ones that I touched on earlier: ProvisioningSchemeName and MasterImageVM:

$ProvScheme = “Windows 10 Static”

“Windows 10 Static” will be the ProvisioningSchemeName from earlier, or usually the name of your Machine Catalog.

$NewMasterImage =  “XDHyp:\HostingUnits\<Cluster Name>\XDMaster1.vm\v1.snapshot\v2.snapshot”

That will be the full path to your new snapshot. Remember to use get-childitem to ensure that the DDC sees your new snapshot.

Now, we will use the Publish-ProvMasterVMImage cmdlet to wrap it all up!

Publish-ProvMasterVMImage -ProvisioningSchemeName $ProvScheme -MasterImageVM $NewMasterImage

After running this command, pay attention to your vSphere tasks. You will see a temporary VM get copied, VMDKs get copied to the various datastores, and you should finally get a response from PowerShell that states 100% completion and where the new master image location points.

If you see the dreadful red text, pay attention and make sure you got your paths correct. It is easy to mistype the XDHyp path, forget quotes, etc.

I hope this post thoroughly covers how to update your master image on a static/dedicated Machine Catalog delivered via MCS! Thank you, PowerShell!

Citrix XA/XD SQL Mirroring

As you probably know, SQL is one of the foundations of a successful Citrix deployment. All transactions processed in a XenApp/XenDesktop environment must go through SQL (Citrix brought back connection leasing in 7.6 to temporarily workaround a SQL outage). SQL mirroring is Citrix’s recommended method of a highly available deployment. It also seems to be the cheapest and easiest to deploy. SQL mirroring must be application-aware, meaning that it doesn’t use any sort of VIP to trick the application into thinking that either SQL server can represent the same instance. Citrix will actually know and auto-detect that another database on another server will be used as a failover during the site creation.

I will start off by saying that I am no SQL guru; I know a few basic queries, join concepts, etc. Many Citrix admins aren’t SQL experts either, so we typically leave any sort of SQL-related stuff to the database guys. Well, I went ahead and gave SQL mirroring a shot myself in a recent deployment, and I was actually surprised by how easy it was! I must stress that setting it up the first time during the initial deployment looks way easier than re-configuring after the site has been deployed/pushed to production. So, I recommend doing it right the first time, as going back and re-configuring will introduce downtime to the environment.

So, let’s start with a brand new deployment – before you even touch the Citrix layer, SQL must be taken care of first. This is done with SQL 2014 on Server 2012R2. You will need 2 servers running SQL standard and 1 server with SQL Express acting as the witness. The witness can typically be installed on a multi-role server, such as a delivery controller, to save resources if needed. Since this is a standalone SQL environment just for the Citrix servers, we will keep the name at the default instance.

Start off by installing SQL Standard on both servers. You will need the database engine, client/server components, and COMPLETE management tools. I realized afterward that the install of basic management tools will not include the mirroring options/tools within Mgmt Studio. After that is complete, install SQL Express on your witness.

We will call the principal (primary) database server SQL1, mirror will be SQL2, and witness will be SQL3.

Let’s start by creating a SQL database on SQL1 with the full recovery model. Make sure that the Collation is set to Latin1_General_100_CI_AS_KS in order for Citrix to properly interact with it.

1

Set Is Read Committed Snapshot On to True after the database is created. This will improve performance and you will not get a warning when the site database is setup.  See here for Citrix article on this.

2

Do a full backup of SQL1 by right-clicking the database and go to backup. Make note of the location.

3

Copy the .bak to the same location on SQL2. Open up management tools on SQL2 go to the Databases folder (you should not have any databases on SQL2 yet!) and go to Restore Database…

4

Under the Restore Database options, make sure that RESTORE WITH NORECOVERY is selected in the recovery state. This is a very important step that is often overlooked, and will result in an error when attempting to initiate the mirror.

6

Okay – that essentially sums up the preparation process for the mirror, so we’re about halfway there! Now it’s time to actually initiate it. On SQL1, right-click the database and go to Tasks > Mirror. This will take you to the Mirror properties of the database.

7

** If the mirror properties do not show up, that usually means that you have not installed the complete set of management tools; only the basic. Go back and edit the existing SQL instance, just adding the complete management tools.

Before we start the mirror, we have to configure the security settings for it. Go ahead and click that so the security wizard comes up. Mirroring defaults to TCP 5022, so ensure that appropriate firewall rules allow this connection (including your witness instance!), on top of your basic SQL ports.

You should breeze through this wizard, ensuring that you specify the correct SQL server instances.

8 9 10 11 12

You will be prompted with a pop-up menu after the security wizard. Go ahead and click Start Mirroring to initiate the process:

13

Bam! You have just successfully setup a SQL mirrored instance. You will notice that the mirror properties will show the state of the mirror instance, so this status page is usually a good place to start when troubleshooting issues.

14

If you happen to run into an error during the initialization, particularly a 1418 error, follow this blog for some good pointers.

All righty – go ahead and start your new site setup. When asking for the instance / database in Studio, make sure and point to SQL1 (principal) for your databases. It will automatically configure your connection strings to use SQL2 as the failover. Please note that we used a single database for the site, logging, and monitoring. It’s usually best practice to have these in 3 separate databases, so you will need to configure the mirroring for each database using the above steps.

When completing backups, log round-ups, etc., make sure and use your principal for the backup source. Do not backup the mirror.

Thanks for reading – I hope this helps!

Expanding a Citrix PVS VHD Image

Ah, Citrix Provisioning Services… argumentatively one of the most ingenious technologies when it comes to Citrix’s XenApp/XenDesktop suite. PVS gives administrators the ability to install application updates, perform image maintenance, maintain version control, etc. without ANY service interruptions to production virtual desktops. On top of that, the cache-to-RAM/overflow-to-disk option (7.1) gives storage administrators a huge relief, since all VM “writes” are written to a cache pool, located on the RAM of the virtual machine! (Read more here):

http://blogs.citrix.com/2015/01/19/size-matters-pvs-ram-cache-overflow-sizing/

However, I have noticed one major flaw in PVS, and that is the ability to expand the base image VHD (the read-only copy that everyone is steaming from). Is it doable? Yes. Is it supported by Citrix? No (CTX118608). Is it way more difficult than it should be? Maybe. That really depends if you have decided to go to a 16MB vs. 2MB dynamic block size. Although you [theoretically] get better performance out of the 16MB block size (and sacrifice a small amount of storage, since you’re eating up the entire 16MB block, per each written block), you do lose the ability to natively manage the VHD utilizing diskpart or Hyper-V, because Windows is not compatible with the 16MB-blocked VHD! Does Citrix have this documented anywhere? Absolutely not.

If you’re lucky enough to have the 2MB block size, you can simply create a new merged base of your image, rename the VHD and PVP files, and delete the LOK file. You will then want to delete the version in the Versions window. This will delete the version from the PVS database, but since you’ve renamed it, it will not delete the VHD.

Afterward, run diskpart:

diskpart
Select vdisk file=”[Location of VHD]”
list vdisk
expand vdisk maximum=[#ofMB]

You can then exit diskpart and expand the partition by mounting the VHD and expanding it in disk manager. Then take the disk offline and unmount it. Afterward, you can import the disk back into PVS.

Now, the really tricky part is expanding the VHD when you have the 16MB block size. If you try and mount the VHD like we did the 2MB-blocked one, you’ll get an error about the disk being corrupted. The only way is to convert this back to the 2MB VHD. So, how can we do that?

First, you will need to utilize a tool called CVhdMount.exe, in combination with the disk tools found in Hyper-V. Chances are, your PVS server does not have the Hyper-V role installed, so you will need to put this tool on your Hyper-V server. This tool can be found in Program Files\Citrix\Provisioning Services on your PVS server. You will also need to install the drivers found in Provisioning Services\Drivers on your Hyper-V server so that it can work with these special VHDs. Copy both the CVhdMount.exe and drivers folder to the Hyper-V host. The rest of the instructions are on Hyper-V.

Next, right-click cfsdep2.inf and hit install. Then, in device manager, add legacy hardware manually, as a storage controller.  Click Have Disk… and point it to CVhdMp.inf. This will install the Citrix Virtual Hard Disk Adapter so that CVhdMount.exe has the instructions on how to operate.

Afterward, run CVhdMount.exe -p 1 “[path to VHD]

You’ll get a magical message that the bus interface has been opened with device serial #1. Now, open up disk manager, and you will see that the disk is there! Set the disk to Offline so we can perform the VHD conversion, without risking the chance of corruption.

Next, in Hyper-V manager, select New > Hard Disk and create a dynamic VHD. Instead of creating a new blank virtual disk, copy the contents of an existing physical disk (your magically attached VHD!). This could take awhile, depending on the specs of your Hyper-V host. After the new 2MB VHD is created, edit the disk using Hyper-V manager to expand it to the new appropriate size.

Copy the VHD over to your PVS storage, import it in the PVS Console, and you should now see your new 2MB-blocked VHD!