Back in the old days when you wanted to update a vDisk, you needed to make a complete copy of the current vDisk, then import it back into the vDisk Store, set it to Private Mode and link it to a Master device to apply your changes. After making all the changes, you needed to put the vDisk back to Standard Image mode and copy the complete vDisk to the rest of the Provisioning Services servers.

Now with Citrix Provisioning Services vDisk versioning you can add versions to your current vDisk. This method of updating the vDisk creates a delta file next to the vDisk itself. This delta file is usually considerable smaller than the complete vDisk file and you don’t need to change the vDisk mode to apply changes to it so that it can continue to be used.

My previous blog was about how to create a Citrix XenApp 6.5 vDisk. In this blog I will show you how to update this vDisk with Provisioning Services vDisk versioning and what steps you should always go through for Citrix XenApp 6.5.

Base

The first version, when creating the vDisk, is called Base (version 0). At file level, the Base consists of a .vhd file (the vDisk itself), a .pvp file (the vDisk properties file) and the .lok file (when the vDisk is in use).

Creating a vDisk version

The first step is to create a new version to the current vDisk, this will be version 1. To do that, open the Citrix Provisioning Services console, browse to the vDisk, right click on it and select Versions.

Click New

Version 1 is now created. Notice that the default access type is Maintenance. Click Done.

At file level you see that there is a *.1.avhd and a *.1.pvp file created. These are the “delta files” for Version 1, all new changes are saved in these files.

Prepare the XenApp Master server for the vDisk update

Just like when creating the vDisk, I use a dedicated XenApp Master server for updating the vDisk. This Master server has no other active user sessions and have no policies applied to it. But any server in the farm can be used to apply the updates as long as there are no active user sessions on it.

Within the Provisioning Services console open the properties of the “Master” server and change theType to Maintenance. Click OK.

Apply changes to the vDisk (version)

Make sure that the correct vDisk is linked to the XenApp “Master” server and start it.

Now that the vDisk version and the Master server are both in maintenance mode, a menu will appear at startup. Option 1 will start the server from vDisk version 1 in read/write mode. Option 2 will start the server from the base (read-only mode).

Press 1 and hit Enter

After the Master server is started, you can logon and apply the updates.

NOTE: Always reapply the steps that are needed to give certain software a unique ID or GUID as described in Step 6 AND always run the “Prepare this server for imaging and provisioning” wizard as described in Step 7 of this blog (link will be open in new window) before closing the vDisk / shutting down the master server.

After shutting down the master server, you see at file level that the *.1.avhd file has increased in size.

Test the new vDisk version (optional)

You have the ability to test the new vDisk version on different XenApp servers before promoting it to production. When promoting a vDisk version to test means also that you put it back to read-only mode, you can start multiple servers from a vDisk version in Test mode.

It is recommended to test the vDisk version on a server another then where you applied the updates. To promote the vDisk version to Test, do the following;

Open the Versions dialog of the vDisk and click on Promote. Select Test and click Ok.

Click Done

Open the properties of the Target Device you want to test de new vDisk version on and change the Type to Test. Click OK.

Now when starting the Target Device in Test mode, on startup there will be a menu appear. Option 1 will start the server from vDisk version 1 in read-only mode. Option 2 will start the server from the base.

Promote the vDisk version to production

When al tests are successful you can promote the vDisk to production (when not you can revert it back to maintenance and apply new changes). All servers assigned to this vDisk will boot the next time from the latest vDisk version with production state (until then they remain using the base version of the vDisk).

To promote the vDisk version to production, open the Versions dialog of the vDisk.

Select version 1 and click Promote.

Select Immediate or schedule the promotion for a later time. Click OK.

Click Done

If you have more than one Citrix Provisioning Services servers in your environment, don’t forget to copy the vDisk version to the other PVS servers. Check the vDisk replication status to see if all PVS servers are up-to-date.

vDisk version Merging

Each vDisk version depends on the underlying versions. For example, version 2 needs version 1 and the base to work well.

You can merge vDisk versions so that they are no longer dependent on underlying versions.

With Merging vDisk versions, you have two options;
–        Merged Updates – All updates from last base
–        Merged Base – Last base + all updates from that base

In this blog I will show you both options, starting with “Merged Updates”. For this examples I already created a second version so I can show you the difference better.

Open the vDisk Versions dialog and click Merge. Select Merged Updates and click OK

There will now be created a third version which contains both updates from version 1 and 2. This process takes a few minutes.

After a few minutes version 3 is ready.

When promoting version 3 to production, version 1 and 2 become obsolete and can be deleted safely. (Indicated by the red X)

To merge the base with all the updates, select the latest version and click Merge

Select Merged Base – Last base + all updates from that base and click OK

There will now be created a fourth version which contains the base and all updates. After a few minutes version 4 is ready.

When promoting version 4 to production, the base and version 3 become obsolete and can be deleted safely.

After deleting the base and version 3, only version 4 is left. This will be the new base. On file level you have now one big file again.

Share the post "How to update a XenApp 6.5 vDisk with Provisioning Services Versioning"

The following is a checklist for common items that should be implemented or considered when you need to install a Windows based cluster for a customer:

1. Number of Cluster Nodes - typically this is (2) nodes but can go up to (4) node configurations within OpSource.
   
2. Number of NIC's - Network interfaces are often bonded together for fault tolerance.  But, for a cluster, we usually require additional dedicated interfaces for cluster traffic.  As a result, the recommendation is usually (2) NIC's one for internal cluster traffic and the other NIC for external application traffic.
   
3. Windows OS Type - When installing a cluster, you are REQUIRED to install Windows 2003 Enterrpise 32-bit or 64-bit
   
4. Shared Disk Partition(s) - A part of clustering involves usually a shared volume that is used to "float" amongst the nodes in a given cluster.  Disks that are to be used for clustering then are required to be seen and owned by all nodes participating in the cluster.  So, we typically use hte following mediums to achieve this:
   
   1. DAS Storage via SCSI or SAS cable
      
   2. SAN Storage via Fiber
5. SAN Storage Configuration - SAN storage LUN's should be created as distinctly separate LUN's so the proper redundancy can be achieved when a disk fails.  This will prevent all partitions created for a cluster to be on the SAME LUN and thereby causing a bigger outage event of one of the disks were in a failed state for whatever reason.
   
6. DNS Naming - All names used by the cluster MUST be in DNS as both A and PTR records.  This also includes any virtual or cluster management names setup for use by the cluster.  If these names are not present, naming issues usually result and cause weird connection errors within the cluster.
   
7. Networking Configuration - By nature of the cluster, a minimum of (2) networks should be defined for a proper cluster configuration. One of these networks can be the TRUST VLAN setup by default.  The other usually is a private non-routed network used solely for cluster communication.  If there are (2) nodes in a cluster, you may opt for a cross over cable to achieve this.  Otherwise, configuring a flat VLAN with no routing will suffice. 
8. Uninstalling Internet Explorer Security Component - These add-on components usually cause major issues when installing the application portion of software specifially when an application tries to connect via CIFS or UNC to the remote server to run the installer.  Uninstalling this component takes these sorts of issues out of the picture.
   
9. Security Patches - All cluster nodes should be at the same patch revision to ensure the same operating environment is maintained when failing over from one node to another.
   
10. Creation of AD SSO Objects - For any cluster setup, at a bare minimum, (1) service account is REQUIRED to act as a dedicated account that is not a named user so that the cluster can function across all nodes with the appropriate rights.  Additional accounts are typically added as it applies to the application needs.  For example, MSSQL usually requires 2-3 accounts for various services it maintains.
    
11. Assignment of Admin Rights to AD SSO Objects - Assigning administrative control or the like to the service accounts used for cluster operations is imperative to a properly configured setup.  Avoid adding individual accounts on a per server basis but rather assigning them to AD Security Groups and then assigning those groups access to what is needed on the target cluster nodes.

The Microsoft Distributed Transaction Coordinator (MSDTC) is a transaction manager that permits client applications to include several different data sources in one transaction and which then coordinates committing the distributed transaction across all the servers that are enlisted in the transaction. A lot of people ask why we need to install MSDTC prior to installing SQL Server. If you are using distributed transactions or running SQL Server on a cluster, this is definitely a must. SQL Server uses the MSDTC service for distributed queries and two-phase commit transactions, as well as for some replication functionality.

Configuring MS DTC in Windows Server 2003 clusters as defined in this Microsoft KB article is not pretty straight-forward. Windows Server 2008 made it simpler by providing a more straightforward process with fewer steps and less configuration.

To install and configure MSDTC:

1. Open the Failover Cluster Managementconsole on any of the cluster node.
2. Under the cluster name, right-click on Server and Applications and select Configure a Service or Application. This will run the High Availability Wizard

   

3. In the Service or Application dialog box, select Distributed Transaction Coordinator (DTC) and click Next.

   

4. In the Client Access Point dialog box, enter the name and IP address of the clustered MSDTC. This should be a different IP addresses and host name from the one that the Windows Server 2008 cluster is already using. ClickNext.

   

5. In the Select Storage dialog box, select the disk subsystem that will be used by MSDTC. These disk subsystems have to be defined as available storage in your cluster. In the example below, I have used the disk volume F:\ and left the disk volume E:\ for SQL Server later in the installation process. Click Next

   

6. In the Confirmation dialog box, validate the configuration you have selected for MSDTC and click Next

   

7. In the Summary dialog box, click Close. This completes the installation of MSDTC on the cluster.

You can validate your installation of MSDTC by expanding the Services and Applications node and check the cluster name of MSDTC.  Make sure that all of the dependency resources are online

Installing SQL Server 2008 on a Windows Server 2008 cluster

You've gone this far, don't stop now. Only after we have managed to prepare everything can we proceed to install SQL Server 2008 on this cluster. Since we've already installed .NET Framework 3.5 with Service Pack 1 and Windows Installer 4.5 from Part 1, we no longer have to worry about them as they both are prerequisites whether you are doing a single server or a cluster installation. There are two options to install SQL Server 2008 on a cluster. The first one is by using the Integrated failover cluster install with Add Node option and the second one is the Advanced/Enterprise installation option. The process outlined below will take into account the first option.

To install SQL Server 2008:

1. Run setup.exe from the installation media to launch SQL Server Installation Center. Click on the Installationlink on the left-hand side
2. Click the New SQL Server failover cluster installation link. This will run the SQL Server 2008 Setupwizard

   

3. In the Setup Support Rules dialog box, validate that the checks return successful results and click Next.

   

4. In the Product Key dialog box, enter the product key that came with your installation media and click Next.

   

5. In the License Terms dialog box, click the I accept the license terms check box and click Next. You probably haven't read one of these, but if you feel inclined go for it.

   

6. In the Setup Support Rules dialog box, click Install. Validate that the checks return successful results. If the checks returned a few warnings, make sure you fix them before proceeding with the installation. An example of this is the Network binding order. The public network cards should be first on both nodes. Also, you can disable NETBIOS and DNS registration on the network cards to avoid network overhead. Be sure to check your binding order as well.  For more details on the network binding order warning, see Microsoft KB 955963.

   For the Windows Firewall, make sure that you open the appropriate port number on which SQL Server will communicate. You can do this after the installation. Alternatively, you can disable Windows Firewall during the installation and enable it later with the proper configuration. Click Next to proceed.

   

7. In the Feature Selection dialog box, select only the components that you want installed. For the Shared feature directory, you can keep the default path if you have sufficient disk space on your C:\ drive or anywhere that is alocal disk as this will be used by the SQL Server installation process later on. The directory for the clustered database engine will be different. Click Next.

   

8. In the Instance Configurationdialog box, enter the SQL Server Network Name. This is the name that will be available on the network for the clients. This will vary depending on your selection of whether it is a default or named instance. In this example, default instance is selected.

   A couple of things need highlighting in this section. By default, the instance name is used as the Instance ID. This is used to identify installation directories and registry keys for your instance of SQL Server and is helpful when you want to run multiple instances in a cluster. This is the case for default instances and named instances. For a default instance, the instance name and instance ID would be MSSQLSERVER. To use a non-default instance ID, you should select the Instance IDbox and specify a value.

   The section on Detected SQL Server instances and features on this computer would make sense if there are other SQL Server instances running on your server.

   

9. In the Disk Space Requirements dialog box, check that you have enough space on your local disks to install the SQL Server 2008 binaries and click Next.

   

10. In the Cluster Resource Group dialog box, check the resources available on your Windows Server 2008 cluster. This will tell you that a new Resource Group will be created on your cluster for SQL Server. To specify the SQL Server cluster resource group name, you can either use the drop-down box to specify an existing group to use or type the name of a new group to create it. Click Next.

    

11. In the Cluster Disk Selection dialog box, select the available disk groups that are on the cluster for SQL Server 2008 to use. In this example, two clustered disk groups – APPS and APPS2 – have been selected to be used by SQL Server 2008. I will be using one disk resource for the system databases while the other one for the user databases. Click Next.

    

12. In the Cluster Network Configuration dialog box, enter the IP address and subnet mask that your SQL Server 2008 cluster will use. Deselect the checkbox under the DHCP column as you will be using static IP addresses. If you have not disabled your IPv6 adapters and protocols, it would be better to uncheck the row for IPv6

    

13. In the Cluster Security Policy dialog box, accept the default value of Use service SIDs (recommended). In Windows Server 2003, we specify domain groups for all SQL Server services but in Windows Server 2008, this is the recommended option. For more information on using service SIDs for SQL Server 2008, check out this MSDN article

    

14. In the Server Configuration dialog box, enter the credentials that you will use for your SQL Server service accounts in the Service Accounts tab. In the Collation tab, select the appropriate collation to be used by SQL Server. Note that the startup type is set to manual for all cluster-aware services and cannot be changed during the installation process. Click Next.

    

15. In the Database Engine Configuration dialog box, select the appropriate Authentication Mode. If you want to add the currently logged on user to be a part of the SQL Server administrators group, click the Add Current Userbutton.

    

    On the Data Directories tab, enter the path where your system and user database files will be created. This will default to the first shared disk in the cluster so in case you want to change it to the other shared disks to be used by SQL Server 2008, modify accordingly. If you intend to use the new FILESTREAM feature, click the FILESTREAMtab and set the appropriate configurations. Click Next

    

16. In the Error and Usage Reporting dialog box, click Next.

    

17. In the Cluster Installation Rules dialog box, verify that all checks are successful and click Next.

    

18. In the Ready to Install dialog box, verify that all configurations are correct. Click Next.

    

19. In the Complete dialog box, click Close. This concludes the installation of a SQL Server 2008 Failover Cluster

    

At the completion of a successful installation and configuration of the node, you now have a fully functional failover cluster instance. To validate, open the Failover Cluster Management console, and click on SQL Server (MSSQLSERVER) under Services and Applications. Make sure that all dependencies are online

Although we do have a fully functioning SQL Server 2008 failover cluster, it does not have high-availability at this point in time because there is only one node in the failover cluster. We still have to add the second node to the SQL Server 2008 cluster. In the last part of this series, we will add the second node in the failover cluster and install the latest cumulative update