Awhile back I wrote the blog post Provisioning Services 5.1 Specifiy Database Mirror Failover Partner…Huh? and got some good feedback from Pete Downing the Principal Product Manager for Provisioning Services.  In his comments on my blog post he mentioned that he would like to discuss my views on SQL Server database mirroring versus replication of the Provisioning Services database.  In this blog post I am going go over my views on database Mirroring versus Replication of the Provisioning Services database.

Provisioning Services 5.1 had a feature that would allow you to specify a database mirror failover partner when joining another Provisioning Server to the Provisioning Services farm.  This was an undocumented feature that I couldn’t get to work.  In the feedback I received from Pete Downing on my blog post he gave an explanation and more information on the specify database mirror failover partner feature.  Here is Pete’s comments on that blog post “Appreciate your detailed and direct blog post here. As PM of Provisioning Services I enjoy posts like this because they provide “real” feedback. What you are seeing is unfortunately a bug and we are addressing. You will notice that we will release a SP1 in the next few weeks for PVS 5.1, however, you will notice this feature will be removed. We decided to do this because our DB caching feature is solving the use-case we set out to solve for the time being. We are not ditching this feature and will re-introduce it in the next release of PVS. We would like to re-introduce with solid best practices and documentation. Essentially this feature was to be an easter egg for some end-users to test and unfortunately got too exposed.  Feel free to drop me an email where you feel very strongly about this topic. I’d love to discuss your view on mirroring versus replication.”.  This feature has been removed since the release of Provisioning Services 5.1 Service Pack 1. 

So before I state my views on mirroring versus replication, let’s go over SQL Server Mirroring and Replication.

SQL Server Mirroring

SQL Server Mirroring was first introduced in SQL Server 2005 and is also in SQL Server 2008.  SQL Server Mirroring has a principal and mirror SQL Server.  In some cases a witness SQL Server is needed.  Mirroring works on top of Log Shipping.  The database on the mirror SQL Server is offline until a failover is done.  Depending on which Mirroring type you use failover can be automatic, manual, or forced.  

There are 3 types of SQL Server Mirroring:

• High Availability – Automatic or Manual failover.  Has full transaction safety with a synchronous transfer mechanism.  A quorum and witness server are required.  SQL Express can be used for the witness server.
• High Protection – Manual failover.  Has full transaction safety with a synchronous transfer mechanism.  A quorum is required but a witness server isn’t required. 
• High Performance – Forced failover.  Doesn’t have transaction safety, has an asynchronous transfer mechanism, and neither a quorum or witness is required.

If automatic failover is used the mirror SQL Server database will automatically become active without having to restore logs with the help of the witness SQL Server.  When using SQL Server Mirroring the logs are continuously merged in the mirror database.  SQL Server mirroring offers a very minimal downtime and cost-effective solution while only targeting/mirroring a single database.

SQL Server Replication

SQL Server Replication allows for multiple synchronized sets of the same database to be online at the same time.  There are no standby servers when using SQL Server Replication.  The publisher and subscriber SQL Servers are both active.  Replication is basically copying and distributing data and database objects from one database to another database across local or remote data centers.  The data is synchronized between the databases to maintain consistency.  The remote data centers could be geographically dispersed across cities, states, or countries. 

There are 3 types of SQL Server Replication:

• Transactional Replication - Typically used in server-to-server environments.  Starts with a snapshot of the publication database objects and data.  Incremental changes are propagated to the subscriber SQL Servers as they occur.  Good for instances where the application requires low latency between the time changes are made at the publisher SQL Server and the changes arrive at the subscriber SQL Server.  Also good for instances where the application requires access to the intermediate data states.
• Merge Replication – Typically used in server-to-client environments.  Starts with a snapshot of the publication database objects and data.  Data changes and schema modifications made at the publisher and subscribers are tracked with triggers.  The subscribers are synchronized with the publisher and other subscribers when connected to the network.  Good for when subscribers need to receive data, make changes offline, and synchronize changes later with the publisher and other subscribers.
• Snapshot Replication – Distributes data exactly as it appears at specific moment in time.  It doesn’t monitor for data updates.  The entire snapshot is generated and sent to the subscribers when synchronization occurs.  Good for when data changes infrequently and replicating small volumes of data.

Each type of SQL Server Replication begins with an initial synchronization of the published database objects and data between the publisher SQL Server and subscriber SQL Servers. 

Provisioning Services with SQL Server Mirroring

A good use case for SQL Server Mirroring of the Provisioning Services database is within a single data center for redundancy where SQL Server clustering isn’t used.  A good example of this would be where the SQL Server is a virtual server and clustering is more complex in a virtual environment.  Especially if there isn’t an iSCSI SAN to use for the cluster shared storage.   Starting with Provisioning Services 5.1, enabling the Provisioning Services offline database support feature also adds redundancy if the Provisioning Services database server becomes unreachable or there is a hardware failure.  Using SQL Server Mirroring would add  an extra layer of database redundancy when used with the Provisioning Services offline database support feature.  SQL Server Mirroring of the Provisioning Services database would be a good use case in virtual environments.

I see a better use case for SQL Server Mirroring with Provisioning Services for disaster recovery sites.  Starting with Provisioning Services 5.0, a farm structure and sites were introduced.  In your Provisioning Services farm you could have two sites setup.  One site for production and one site for disaster recovery.  You could have a mirror copy of your Provisioning Services database and Provisioning Servers at your disaster recovery site.  When a disaster recovery test or actual disaster occurs, you failover to your disaster recovery Provisioning Services site and could be up with minimal downtime.  Same as XenApp when using zones and SQL Server Mirroring.   

I could see High Availability SQL Server Mirroring as the supported mirror type for the Provisioning Services database.  SQL Server Mirroring high availability would give the option of automatic and manual failover.  Having automatic failover would be good unplanned outages and manual failover would be good for planned outages when doing SQL Server maintenance or disaster recovery testing.

The biggest issue I see with changing Provisioning Services to be able to use SQL Server Mirroring is either changing how the registry entries for the database configuration are stored at HKLM\Software\Citrix\ProvisioningServices\Database since they are currently in some kind of has format or change the Provisioning Services/database configuration to use a ODBC DSN file like XenApp has for the IMA Data Store database.

Provisioning Services with SQL Server Replication

The best use case I see for SQL Server Replication is when having a geographically distributed Provisioning Services farm.  Remember that starting with Provisioning Services 5.0, a farm structure and sites were introduced.  SQL Server Replication works perfect in this use case since all Provisioning Servers at each site are  connected to an active database instance.  Provisioning Servers connect to and use their local replicated database.  This works out great for sites that are on opposite sides of the country.  Like SQL Server Mirroring, the Provisioning Services offline database support features could be used along with SQL Server Replication to add an extra layer of database redundancy.  Same as XenApp when using zones and SQL Server Replication.

Disaster recovery is another good use case for SQL Server Replication of the Provisioning Services database.  In your Provisioning Services farm you could have two sites setup.  One site for production and one site for disaster recovery.  You could have a replicated copy of your Provisioning Services database and Provisioning Servers at your disaster recovery site.  When a disaster recovery test or actual disaster occurs, you can use your disaster recovery Provisioning Services site and could be up with zero downtime since replication allows for all Provisioning Servers at each site to be connected to an active database instance.  Same as XenApp when using zones and SQL Server Replication.

Just like the XenApp IMA Data Store database I see SQL Server Transactional Replication as the only supported replication type for Provisioning Services.  Transactional replication is a must since changes made at the publisher are immediately replicated to the subscribers.

The biggest issue I see with changing Provisioning Services to be able to use SQL Server Replication is that not all tables in the Provisioning Services database have primary keys set on them.  To use SQL Server Replication, each table has to have a primary key set on it to be able to be replicated.  So the database will have to be modified to have primary keys set on all the tables for SQL Server Replication to be an option.  Also there will have to be a process to set the replicated database as primary if the publisher SQL Server becomes unavailable in a disaster.  This method could be the same as with the XenApp IMA Data Store but then again, the Provisioning Services/database configuration would have to be changed to use a ODBC DSN file.

So in conclusion I see both SQL Server Mirroring and Replication as options for database redundancy in Provisioning Services.  Both options have a use case. Adding the feature to use SQL Server Mirroring, Replication, or both would cause some modifications to made to Provisioning Services and the backend database it uses.  I personally would like to see both SQL Server Mirroring and Replication as redundancy options in Provisioning Services.  Give the customer the option to choose which SQL Server redundancy option works best in their environment.  High Availability mirror option for SQL Server Mirroring and Transactional replication for SQL Server Replication.  Hopefully one or both of these options will be added to the next version of Provisioning Services.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.

This week Helge Klein started a Citrix products 2010 wish list.  Tim Arenz expanded on Helge’s wish list on his blog earlier today.  I want to expand on both Helge’s and Tim’s additions with my own wishes as well.  I’m sure they both don’t mind since Tim encourages other bloggers to continue adding to this list.  Like Tim, I encourage other bloggers to keep this wish list going.  Helge’s are in black and Tim’s are in red.  So here on are my additions in orange.

XenApp

• A version of XenApp that runs on Windows Server 2008 R2
• One console only, at least for XenApp
• PowerShell SDK for managing XenApp
• Realtime audio/video so that, for example, Microsoft Office Communication Server can be used well
• Migration tool that exports an old farm’s settings and imports them after optional transformation into a new far
• Consistent feature set among the XenApp versions (2003 / 2008 / 2008 R2)
  • Special folder redirection, power management, HDX Flash, etc
• A revamped Installation Manager on Windows 2008
• Report Center in Access Management Console/Delivery Services Console that links to EdgeSight/pull reports from XenApp management console
• XenApp Setup Wizard similar to XenDesktop Setup Wizard
• Integration with hypervisors similar to XenDesktop power on, power off, reboot, etc
• Folder inheritance of published applications in a folder- add a new server to a folder in the console and have applications automatically published on that server that are published to other servers in that folder
• Content redirection/file type association between seamless hosted and seamless streamed applications

Support for XenApp in SCCM (Microsoft System Center Configuration Manager)

• XenApp collections
• Add application hosting information to SCCM package
• Autonomic server load management to allow SCCM software distribution

VM Hosted Apps

• Session sharing (multiple applications per session/VM)
• Real application publishin
• Integration in XenApp management console

XenClient

• Release a first version, if only for enterprise volume laptops initially
• Make it run on any system that supports VT-D and TXT (trusted execution technology)
• Provide a private image mode: copy a VM to a client initially and then sync back differentially by creating snapshots that are stored on a server. A user would “own” a VM in this scenario and could store data and install applications in it, but updates/application installs could not be easily centrally managed.
• Provide a shared image mode: copy a VM to a client initially that is reset to its original state when powering off. Provide a second disk (VHD file) for persistent user data. In this scenario, users could not install applications, since the OS VHD gets reset constantly, but administrators could manage updates to the OS VHD centrally by distributing snapshots containing new applications or patches to the clients. All user data would have to be stored on a second partition.
• Optionally encrypt VHD files on the client (we are talking about laptops)
• Map the GPU to any VM. That way we could use a private VM (with GPU, for games, etc.) and a more secure business VM.
• Run applications from one VM seamlessly in the other VM (over ICA)

XenDesktop

• Make HDX media stream for Flash optionally work in such a way that we do not need internet access in the client’s site. Stream Flash through ICA from the server to the client and only render it on the client.
• PowerShell SDK for managing all aspects for XenDesktop
• Merge the XenDesktop Setup Wizard into the “Create Desktop Group” Wizard
• Windows Server 2008 support

Provisioning Server

• Give us a tool for automating the management/patching of PVS images
• Make it run in one of three modes:
  • Monitoring: Monitor external ESD server to determine if updates have been assigned to a machine
  • Scheduled: Periodically start the VM and allow the machine to update itself
  • Manual: Admin initiates VM start/stop for manually updating
• Give the tool a PowerShell SDK so we can program it
• Easy way to upgrade virtualization tools (VMware Tools, XenTools, etc) and Provisioning Server Target Device of a vDisk
• Provisioning Services Database Replication and or Mirroring

XenServer

• VM-based snapshot and not disk-based snapshot
• Easy way to revert to taken snapshots
• Memory sharing / ballooning / over commitment (for VDI)
• Thin provisioning for block-based storage repositories
• Possibility to separate management and XenMotion network interface
• Advanced template management
  • Integration of Sysprep, possibility to change hostname, ip, etc
• Administrative Delegation
• Wake On LAN of XenServer VMs
• Move VMs/VDIs to storage repository without having to turn off VM and copy – Storage XenMotion

Workflow Studio

• More development/example workflows
• More integration with Citrix products – XenDesktop, etc

Various

• Release Branch Repeater as a virtual appliance. Better make it available for all three important hypervisors.
• Release a virtual appliance version of Access Gateway that can serve as a true replacement for CSG (Secure Gateway). For that, it needs to be free or very cheap at least. And better make it available for all three important hypervisors.
• Consistent management console for all versions of Access Gateway
• Citrix Receiver framework for the Mac and Linux platform
• Integration of all Citrix agents/clients/plug-ins into Merchandising Server
• NetScaler VPX virtual appliance for Hyper-V
• Merchandising Server virtual appliance for ESX

Please keep this wish list going.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.

With each release of a Provisioning Services Target Device update, hypervisor virtual machines tools update, or network drivers update we are tasked with upgrading the Provisioning Services vDisk and what method to use to complete the upgrade.  In this blog post I am going to go over the options for upgrading Provisioning Services vDisk Target Device software, Virtual Machine Tools, and Network Drivers.

Why can’t Target Device software, Virtual Machines Tools, and Network Drivers just be upgraded while the vDisk is online?

Provisioning Services Target Devices network boot to access their assigned vDisk on the Provisioning Servers.  This relies heavily on the Target Devices network connection to remain in constant communication with the Provisioning Server it is accessing for its vDisk.  If the communication is broken, the Target Device will pause or even worse, cause the Windows blue screen of death we all love to see.

When the Target Device initially boots it uses network/PXE boot to the contact the Provisioning Server and access its assigned vDisk to boot into a Windows Operating System with the Target Device software installed.  The Target Device software is the Provisioning Services client software that is used by Windows once the Target Device has booted into a Windows Operating System.  The Target Device software stays in constant communication with the Provisioning Server while the vDisk is online.  

The Target Device software relies heavily on the network card and network stack of the Target Device.  If anything changes with the network card or network stack (drivers, settings, state, etc) while the Target Device is accessing the vDisk, then communication with the vDisk will be broken and the Target Device will most likely blue screen.  Updating the Target Device software, virtual machine tools, or network drivers all effect the Target Devices network card/network stack and cannot be done while the vDisk is online.

What options are there for updating vDisk Target Device software, Virtual Machine Tools, and Network Drivers?

As of today there are three main options for updating vDisk Target Device software, virtual machine tools, and network drivers.  All three options are done offline and you should always make a backup copy of your vDisk before doing any of these options.  You can use the Reverse Image, Hyper-V Direct VHD Boot, or XenServer Direct VHD Boot options to upgrade vDisk Target Device software, virtual machine tools, and network drivers.

Reverse Imaging

Reverse Imaging has been around the longest for updating vDisk Target Device software, virtual machine tools, and network drivers.  The process is pretty straight forward and requires a locally attached disk on the Target Device.  When you first create a vDisk you image the locally attached disk to the vDisk.  Reverse Imaging is imaging the vDisk back to the locally attached disk. 

Reverse Imaging Process:

1. Boot to the vDisk in Private or Standard Mode.
2. Make sure the locally attached disk is marked active in Disk Management and make note of the drive letter.
3. Run XenConvert or the Image Builder Utility (C:\Program Files\Citrix\Provisioning Servers\bnimage.exe) and image back to the locally attached disk.  Make sure when using XenConvert to reverse image choose From Volume To Volume on main XenConvert screen.  Then select the appropriate drive letters on the Convert Volume to Volume screen.  Example vDisk is C:\ and local attached disk you are reverse imaging to is E:\.  So you would select C: as the Source Volume and E: as the Destination Volume.
4. Reboot and change the BIOS to boot from local disk instead of network boot.
5. Boot to local disk.
6. Uninstall Target Device software and install new Target Device software, update virtual machine tools, or update network drivers.  If you are updating a combination of the three or just updating virtual machine tools and/or network drivers make sure to uninstall the Target Device software, update virtual machine tools and/or network drivers, and then install Target Device software.
7. Change the Target Device to boot from hard disk in the Provisioning Services Console.
8. Create a blank vDisk and assign to the Target Device or use the existing assigned vDisk (make sure you have a backup copy and no other Target Devices are accessing the existing vDisk) in the Provisioning Services Console.
9. Change the vDisk to Private Mode in the Provisioning Services Console.
10. Reboot and change the BIOS to boot from network instead of local disk.
11. Run XenConvert and image back to the vDisk.
12. Shutdown the Target Device and change it to boot from vDisk in the Provisioning Services Console.
13. Change the vDisk to Standard Mode in the Provisioning Services Console.
14. Assign the vDisk to Target Devices in the Provisioning Services Console.
15. Boot Target Devices and test.

Hyper-V Direct VHD Boot

Hyper-V Direct VHD Boot is a newer option of updating vDisk Target Device software, virtual machine tools, and network drivers since Provisioning Services 5.1.  If you are using or have a Hyper-V server around this a really nice option.  See the Citrix blogs for the Hyper-V Direct VHD Boot option.

XenServer Direct VHD Boot

XenServer Direct VHD Boot is another newer option of updating vDisk Target Device software, virtual machine tools, and network drivers since Provisioning Services 5.1.  If you are using or have a XenServer around this another really nice option.  See the Citrix blogs for the XenServer Direct VHD Boot option.  There is more information in the Citrix forums.  See the Citrix forums for Using XenServer and NFS to update PVS device target software.  Citrix has posted a knowledgebase article for this as well.  See CTX123395 – How to Update Provisioning Server Target Device Software using a Network File Share with XenServer.

As you can see you have a few options for updating vDisk Target Device software, Virtual Machine Tools, and Network Drivers.  If you have Hyper-V or XenServer in your environment then you have some very nice options without having to Reverse Image your vDisks.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.

Over a month ago I was in some conversations with some fellow Citrix consultants on Twitter about how they use XenAppPrep when updating provisioned XenApp servers.  There has also been some forum postings on this subject as well.  This is also a topic of conversation with customers who are testing Provisioning Services with XenApp.  In this blog post I am going to go over some XenAppPrep options when updating provisioned XenApp server images.

What is XenAppPrep?

XenAppPrep is like Sysprep for XenApp servers that are going to be provisioned with Provisioning Services.  It generalizes a XenApp server for creating a master Provisioning Services image.  XenAppPrep is installed and ran on a XenApp server before XenConvert is ran to make a Provisioning Services vDisk image.  XenAppPrep runs as a service and controls XenApp services when the XenApp server boots.   For a full description of XenAppPrep and how to use it see the Citrix knowledgebase article CTX116063 – XenAppPrep Integration Utility for XenApp and Provisioning Services.

What is the process when updating provisioned XenApp Provisioning Services vDisk Images?

I have seen several Citrix support forums postings about this and also had some conversations on Twitter about this.  There are multiple ways of doing this.

One option is to rerun XenAppPrep and the Provisioning Services Target Device Optimization Utility every time you update your master in private mode before changing it back to standard mode.  This process involves stopping the XenAppPrep service, deleting the XenAppPrep service and running XenAppPrep again.  This process can be scripted and ran each time after making updates in private mode before changing back to standard mode.  See the following example script:

REM Script by Jarian Gibson for Provisioning Services for XenApp with XenAppPrep
REM Run this script after making updates in Private Mode before shutting down and putting back into Standard Mode.
REM Make sure XenAppPrep is installed.
REM ***************************************************
REM This section will stop the XenAppPrep Service, delete the XenAppPrep service, run XenAppPrep /PVS for XenApp to get ready standard mode, and launch the Target Device Optimizer
Net Stop XenAppPrep
SC Delete XenAppPrep
REM Add /MSMQ after /PVS if using Smart Auditor XenAppPrep /PVS /MSMQ
“C:\Program Files\Citrix\XenAppPrep\XenAppPrep.exe” /PVS
“C:\Program Files\Citrix\Provisioning Services\TargetOSOptimizer.exe”
REM Server is ready to be shutdown and be put in Standard Mode
Pause
REM ***************************************************

Another option is to change the XenAppPrep service to manual startup mode, have a group policy startup script detect whether provisioned XenApp server vDisk is in standard or private mode, and start or not start the XenAppPrep service depending on the vDisk mode.  Using this option takes advantage of the personality.ini file that gets created on the root of the target device’s system drive every time it boots.  The personality.ini contains information such as target device name, write cache type, etc.  You can also add custom fields on each target device in the personality tab in the Provisioning Services console for scripting other processes.  A good example would be for pre-caching streamed applications at startup depending on which streamed applications are published to the XenApp server.  You can add personality string with a name and strings for UNC paths to each streaming profile (separated by commas) in the personality tab.  The pre-cache startup script reads the personality.ini, reads the strings for streamed application profiles, and pre-caches those streamed applications when the server boots.

For reading the vDisk mode, the personality.ini has a string called $WriteCacheType.  $WriteCacheType is equal to a number that corresponds to what mode the vDisk is in.  See the following for $WriteCacheType values.

0 = <Private image>

1 through 7 = <Standard Image>:
1 (Server Disk)
2 (Server Disk Encrypted)
3 (RAM)
4 (Hard Disk)
5 (Hard Disk Encrypted)
6 (RAM Disk)
7 (Difference Disk)

By setting the XenAppPrep service to manual and using a group policy startup script to read the personality.ini file you can control whether the XenAppPrep service starts or doesn’t start depending on the vDisk mode.  The following example script reads the personality.ini file, detects the vDisk mode to start or not start the XenAppPrep service, and writes a Windows Application Event Log entry.

@Echo off
REM Script Jarian Gibson for Provisioning Services and XenAppPrep
REM Add this script as a startup script in Group Policy.
REM Set the XenAppPrep service to manual startup.
REM ***************************************************
REM This section will check to see the PVS vDisk Mode.
REM If the PVS vDisk is in Private Mode, then the XenAppPrep service will not start.
Type C:\Personality.ini | FIND /I “$WriteCacheType=0″ >nul
If %errorlevel%==0 (
Echo “Warning: Private Mode vDisk – XenAppPrep Service Will Not Start”
REM Write Warning to Windows Application Event Log
eventcreate /t warning /id 100 /l application /so XenAppPrep /d “Private Mode vDisk – XenAppPrep Service will not start.”
GoTo NoXenAppPrep
)
Net Start XenAppPrep
Echo “Info: Standard Mode vDisk – XenAppPrep Service Will Start”
REM Write Info to Windows Application Event Log
eventcreate /t information /id 100 /l application /so XenAppPrep /d “Standard Mode vDisk – XenAppPrep Service will start.”
:NoXenAppPrep
REM ***************************************************

Now XenAppPrep is not your only option when using provisioned XenApp images.  Pierre Marmignon has another tool called the XenApp Cloning Tool on his site, CitrixTools.net.  His tool works for provisioned and non provisioned XenApp cloning.

Update: As of XenAppPrep 3.0.0, you no longer need to stop and delete the XenAppPrep service before running XenAppPrep /PVS after updating your provisioned XenAppPrep image to re-seal it before deploying the updated image.

As you can see you have a few options for XenAppPrep when updating provisioned XenApp images.  What are method are you using when updating provisioned XenApp images?

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.

Recently I have worked with Hyper-V and SCVMM in my lab to get more hands on with Hyper-V R2. I also recently started working with XenDesktop and Hyper-V using the lab manuals I received when I attended Citrix and Microsoft VDI Training back in November. Using XenDesktop with Hyper-V is a pretty straight forward process. In this blog post I am going to go over the process of using XenDesktop with Hyper-V.

XenDesktop Delivery Controller and Hyper-V

Allowing the XenDesktop Delivery Controller (XDDC) to manage virtual desktops on Hyper-V, you need System Center Virtual Machine Manager (SCVMM)  in your environment.  You need to install the SCVMM console on your XDDC. 

The requirements for the SCVMM console when used with XenDesktop are:

• Windows 2003 (XenDesktop limitation)
• .Net 2.0 – XDDC install installs .Net 3.5 SP1
• Powershell 1.0 or greater

You can install the SCVMM console before or after installing the XDDC.  If you install the SCVMM console before installing the XDDC, the XDDC install will automatically install the SCVMM plugin to allow you to choose Microsoft Virtualization for the hosting infrastructure when creating a desktop group.

If you install the SCVMM console after installing the XDDC, the XDDC install will not install the SCVMM plugin and you will not be able to choose Microsoft Virtualization for the hosting infrastructure when creating a desktop group.

 To add the SCVMM plugin for the XDDC after the XDDC install, you need to do the following:

1. Go into Control Panel
2. Click Add/Remove Programs
3. Select Citrix Pool Management
4. Click Change next to Citrix Pool Management
5. Click Next on Welcome to the Citrix Pool Management Setup Wizard screen
6. Click Modify on Citrix Pool Management Setup Modify, Repair or Remove installation screen
7. Change the Microsoft SCVMM Plugin to Will be install on the local hard drive on the Citrix Pool Management Setup Custom Setup Screen and Click Next
8. Click Install on the Citrix Pool Management Ready to Install screen
9. Click Finish on the Completing the Citrix Pool Management Setup Wizard
10. Now you should be able to see Microsoft Virtualization for the hosting infrastructure when creating a desktop group

See the following screenshots to modify the XenDesktop installation for Microsoft virtualization

Provisioning Services, XenDesktop Setup Wizard, and Hyper-V

Allowing the XenDesktop Setup Wizard to communicate with/create desktops on Hyper-V from your Provisioning Servers, you need to also install the SCVMM console on your Provisioning Servers.  Your Provisioning Servers can be Windows 2003 or 2008 with Powershell 1.0 or greater (Download and install for Windows 2003 or install as a feature for Windows 2008).  Once you have the SCVMM console installed, you can create desktops using the XenDesktop Setup Wizard on your Hyper-V infrastructure.

As you can see, using XenDesktop with Hyper-v is pretty straight forward.  A lot easier if you install the SCVMM console before installing the XenDesktop Delivery Controller.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.

Using EdgeSight in provisioned XenApp environments can be tricky if you don’t follow the proper installation steps.  Monitoring provisioned XenApp servers is pretty straight forward and easy to setup with minimal requirements.  In this blog post I am going to go over what the requirements are for provisioned XenApp servers and how to setup the EdgeSight for XenApp agent.

What is required to use the EdgeSight for XenApp Agent when provisioning XenApp servers?

The EdgeSight for XenApp agent requires a local persistent disk when used in provisioned XenApp environments.  What this means is you need to setup a local disk, whether streaming XenApp to virtual or physical machines, for the EdgeSight data.  This local persistent disk is already setup if you using the Standard vDisk mode with write cache on target device hard drive.  If don’t have this setup, you are either placing the Provisioning Services write cache in the target device RAM or on the Provisioning Servers/shared location. 

Along with EdgeSight data, you can also store Windows Event Logs, Crash Dumps, Windows Page File, and Application Streaming rade cache on the local persistent disk.

Installing the EdgeSight for XenApp Agent

Installing the EdgeSight for XenApp Agent is the same process as installing it on a non provisioned XenApp server except for the following:

• When installing the EdgeSight for XenApp agent, the vDisk must be in Private Mode.
• At the Agent Location dialog, change the default location  of the data files folder to your persistent local disk.  Default location is C:\Documents and Settings\All Users\Application Data\Citrix\System Monitoring\Data\ for Windows 2003 or C:\ProgramData\Citrix\System Monitoring\Data for Windows 2008.  Change this to your local persistent disk.  For example if my local persistent disk is E:\, I would change the data files folder to something like E:\Citrix\System Monitoring\Data.

• When the install completes, click NO when prompted to reboot.

• Set the Citrix System Monitoring Agent service startup type to Manual.

• Reboot

If you accidentally reboot before setting the Citrix System Monitoring Agent service startup type to Manual, see the EdgeSight Install Guide pages 47 to 48 for steps to clean up the XenApp for EdgeSight Agent install.  Starting the Citrix System Monitoring Agent while in Private Mode can cause registry settings to be generated that only apply the vDisk image that is in Private Mode that are pushed out to all Target Devices when the vDisk is change back to Standard Mode.

Now before shutting down the XenApp server and placing the vDisk image back into Standard Mode, you have two options:

• Change the Citrix System Monitoring Agent service startup type to Automatic so the service starts automatically in Standard Mode.
• Leave the Citrix System Monitoring Agent service startup type to Manual and control service via startup scripts.

I like to control the service via startup scripts so the Citrix System Monitoring Agent service only starts when the vDisk is in Standard Mode.  See the following example script that detects the vDisk mode and only starts the Citrix System Monitoring Agent service if the vDisk is in Standard Mode.  The script will also write and event to the Windows Event Log.

@Echo off
REM Script by Jarian Gibson for Provisioning Services and EdgeSight
REM Add this script as a startup script in Group Policy.
REM Set the Citrix System Monitoring Agent service (EdgeSight) to manual startup.
REM ***************************************************
REM This section will check to see the PVS vDisk Mode.
REM If the PVS vDisk is in Private Mode, then the EdgeSight service will not start.
Type C:\Personality.ini | FIND /I “$WriteCacheType=0″ >nul
If %errorlevel%==0 (
Echo “Warning: Private Mode vDisk – Citrix System Monitoring Agent Service (EdgeSight) Will Not Start”
REM Write Warning to Windows Application Event Log                         
eventcreate /t warning /id 100 /l application /so EdgeSight /d “Private Mode vDisk – Citrix System Monitoring Agent Service(EdgeSight) will not start.”
GoTo NoEdgeSight 
)
Net Start RSCorSVC
Echo “Info: Standard Mode vDisk – Citrix System Monitoring Agent Service (EdgeSight) Will Start”                             
REM Write Info to Windows Application Event Log                          
eventcreate /t information /id 100 /l application /so EdgeSight /d “Standard Mode vDisk – Citrix System Monitoring Agent Service(EdgeSight) will start.”
:NoEdgeSight
REM ***************************************************

This script can be combined with my script from my previous blog Updating Provisioned XenApp vDisks: To XenAppPrep to not to XenAppPrep? to detect the vDisk mode and only start the XenAppPrep service and Citrix System Monitoring Agent service if the vDisk image is in Standard Mode. 

@Echo off
REM Script by Jarian Gibson for Provisioning Services for XenApp with EdgeSight and XenAppPrep
REM Add this script as a startup script in Group Policy.
REM Set the XenAppPrep service to manual startup.
REM Make Sure EdgeSight Agent for XenApp Agent is installed, set service to manual startup, and local database files are on local PVS cache disk.
REM ***************************************************
REM This section will check to see the PVS vDisk Mode.
REM If the PVS vDisk is in Private Mode, then the Citrix System Monitoring Agent Service(EdgeSight) and XenAppPrep service will not start.
Type C:\Personality.ini | FIND /I “$WriteCacheType=0″ >nul
If %errorlevel%==0 (
Echo “Warning: Private Mode vDisk – Citrix System Monitoring Agent Service (EdgeSight) and XenAppPrep Service Will Not Start”
REM Write Warning to Windows Application Event Log                         
eventcreate /t warning /id 100 /l application /so EdgeSight_XenAppPrep /d “Private Mode vDisk – Citrix System Monitoring Agent Service(EdgeSight) and XenAppPrep Service will not start.”
GoTo NoEdgeSightXenAppPrep 
)
Net Start XenAppPrep
Net Start RSCorSVC
Echo “Info: Standard Mode vDisk – Citrix System Monitoring Agent Service (EdgeSight) and XenAppPrep Service Will Start”                             
REM Write Info to Windows Application Event Log                          
eventcreate /t information /id 100 /l application /so EdgeSight_XenAppPrep /d “Standard Mode vDisk – Citrix System Monitoring Agent Service(EdgeSight) and XenAppPrep Service will start.”
:NoEdgeSightXenAppPrep
REM ***************************************************

So as you can see, using EdgeSight with provisioned XenApp Servers is pretty straight forward as long as you following the proper installation steps.  Just make sure you have a local persistent disk for the EdgeSight database files, do not reboot when the EdgeSight for XenApp agent install completes, and set the Citrix System Monitoring Agent service to startup type to Manual.  Using the script examples above you can control the services thru Group Policy startup scripts.

Update: As of EdgeSight 5.2 Service Pack 1, you no longer need to set the Citrix System Monitoring Agent Service to manual.  The EdgeSight Agent is smart enough to detect the vDisk mode and won’t start in Private Mode just like it does with the EdgeSight for Virtual Desktop Agents in XenDesktop.  Thanks to Joe Shonk for pointing that out.

How do I use the EdgeSight for XenApp Agent with provisioned XenApp Servers in Private Mode?

All you have to do is set the REG_DWORD IgnorePVSMode to 1 in the registry at HKLM\Software\Citrix\System Monitoring\Agent\Core\4.00.  Thanks to David Sachon from Citrix for helping me out in the Citrix Support Forums.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.

Resizing a Provisioning Services vDisk is pretty straight forward.  You can use VHDResizer with diskpart or attach the VHD in Windows Server 2008 or Windows 7 and extend the volume through Disk Management.  Carlo Costanzo has a good blog post on using the diskpart method.  You can follow Carlo on Twitter @ccostan for VMware and Citrix information.  In this blog post I am going to go over the steps for resizing a Provisioning Services vDisk using Windows 2008 Disk Management to extend the volume.

If your Citrix Provisioning Servers are running on Windows Server 2008, you can attach a Provisioning Services vDisk and extend the volume once you resize it with VHDResizer.  You can also do the same for a Windows 7 or Windows Server 2008 Provisioning Services vDisk directly booting to the vDisk in Private Mode.  The Citrix Knowledge Center has a support article, CTX118608 - How to Resize a Provisioning Server 5 Virtual Disk, for using VHDResizer to resize the vDisk VHD file.

How to resize a Provisioning Services vDisk using Windows Disk Management

Make sure you make a copy of you vDisk (.VHD and .PVP files) prior to resizing.

1.  Download VHDResizer and follow the steps to resize the Provisioning Services vDisk in Citrix Knowledge Center Article CTX118608 - How to Resize a Provisioning Server 5 Virtual Disk.

2.  Open Computer Management from Start > Administrative Tools and expand Storage to access Disk Management

3.  Right click Disk Management and select Attach VHD

4.  Browse to the VHD file and click OK

5.  Right click the imported VHD and select Extended Volume

6.  Click Next on the Welcome to the Extend Volume Wizard screen

7.  On the Select Disks screen the amount of space you want to extend the drive to and click Next

8.  Click Finish on the Completing the Extend Volume Wizard

9.  Now you should see the VHD extended to a larger size

10. Detach the VHD by right clicking on it and select Detach VHD

11. On the Detach Virtual Hard Disk prompt Click OK and make sure Delete the virtual hard disk after removing the disk is not selected.

12. Import the vDisk into your Provisioning Services farm and you should see the vDisk with the extended larger size.

You can now boot the vDisk to make sure the Operating System sees the new size properly.  This same method also works when directly booting from a Windows 7 or Windows Server 2008 vDisk in Private Mode to extended to a larger size.  Follow the same steps above for resizing the vDisk, import the resized vDisk into your Provisioning Services farm, boot the vDisk in Private Mode, and extended the vDisk.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.

When using EdgeSight in provisioned XenDesktop environments you have a few options when using the EdgeSight for Virtual Desktops Agent.  Monitoring provisioned XenDesktop environments is pretty straight forward and fairly easy to setup with minimal requirements.  In this blog post I am going to go over what the requirements are for provisioned XenDesktop environments and how to setup the EdgeSight for Virtual Desktops agent.

What is required to use the EdgeSight for Virtual Desktops Agent when provisioning XenDesktop desktop images?

The EdgeSight for Virtual Desktops agent requires an EdgeSight Agent Database Broker and an Agent Data File Share for EdgeSight data or local persistent disk when used in provisioned XenDesktop environments.  What this means is you need to setup an EdgeSight Database Broker and an Agent Data File Share for EdgeSight data or a local persistent disk attached to each XenDesktop desktop instance, whether streaming the XenDesktop desktop image to virtual or physical machines, for the EdgeSight data.

The EdgeSight Agent Database Broker is a separate instance from your EdgeSight server that runs on a Windows server 2003 (SP1 or later) or Windows Server 2008 virtual or physical machine.  Depending on the size of your XenDesktop infrastructure you may have a single or multiple EdgeSight Agent Database Broker instances.  The EdgeSight Agent Database Broker on a Windows server can broker about 80 EdgeSight for Virtual Desktop Agents.  I have read that the EdgeSight Agent Database Broker can also be installed on a Windows workstation virtual or physical machine and supports about 40 EdgeSight for Virtual Desktop Agents but the install guide only talks about using Windows Server.   When you are using Standard vDisk mode with the write cache on a shared location from your Provisioning Servers or in the target device RAM, you will need to use the EdgeSight Agent Database Broker and the Agent Data File Share for EdgeSight data.

The local persistent disk is already setup if you using the Standard vDisk mode with write cache on target device hard drive.  If don’t have this setup, you are either placing the Provisioning Services write cache in the target device RAM or on the Provisioning Servers/shared location.  Along with EdgeSight data, you can also store Windows Event Logs, Crash Dumps, Windows Page File, and Application Streaming rade cache on the local persistent disk.

Installing the EdgeSight Agent Database Broker

Installing the EdgeSight Agent Database Broker is pretty straight forward except the following:

• When installing the EdgeSight Agent Database Broker, the XenDesktop Farm name or Desktop Group name must be specified on the Agent Location dialog.  In smaller farms this can be the XenDesktop Farm name but in larger farms Desktop Group names should be used.  Remember whatever you enter in Pool Name field needs to be entered on the Advanced Settings install dialog when installing EdgeSight for Virtual Desktops Agent.

• Setup the Agent Data File Share for EdgeSight data with the following permissions:
  • Authenticated Users need the following Share permissions
    • Change and Read
  • Authenticated Users need the following NTFS permissions:
    • List Folder/Read Data
    • Read Attributes
    • Read Extended Attributes
    • Create Folders/Append Data
    • Delete
    • Read

Installing the EdgeSight for Virtual Desktops Agent to use with EdgeSight Database Broker

Installing the EdgeSight for Virtual Desktops Agent to use with the EdgeSight Database Broker is pretty straight forward except for the following:

• When installing the EdgeSight for Virtual Desktops Agent, the vDisk must be in Private Mode.
• At the Advanced Settings dialog, you must enable Configure the agent for virtual desktops.  When you enable Configure the agent for virtual desktops you must also enter the Agent Data File Share where the EdgeSight data will be stored, the Pool Name (XenDesktop Farm or Desktop Group name depending on the size of your farm but must match what you entered during the EdgeSight Agent Database Broker), and the EdgeSight Agent Database Broker server.

• Once the EdgeSight Agent Database Broker, Agent Data File Share for EdgeSight data, and EdgeSight for Virtual Desktops Agent are install and running, you should see a folder and file structure like the following on the on the Agent Data File Share for EdgeSight data:

Installing the EdgeSight for Virtual Desktops Agent to use with a local persistent write cache disk

Installing the EdgeSight for Virtual Desktops Agent is the same process as installing it on a non provisioned XenDesktop desktop except for the following:

• When installing the EdgeSight for Virtual Desktops Agent, the vDisk must be in Private Mode.
• At the Agent Location dialog, change the default location of the data files folder to your persistent local disk.  Default location is C:\Documents and Settings\All Users\Application Data\Citrix\System Monitoring\Data\ for Windows XP or C:\ProgramData\Citrix\System Monitoring\Data for Windows 7.  Change this to your local persistent disk.  For example if my local persistent disk is E:\, I would change the data files folder to something like E:\Citrix\System Monitoring\Data.

• At the Advanced Settings dialog, leave Configure the agent for virtual desktops unchecked.

How do I use the EdgeSight for Virtual Desktops Agent with provisioned XenDesktop desktops in Private Mode?

All you have to do is set the REG_DWORD IgnorePVSMode to 1 in the registry at HKLM\Software\Citrix\System Monitoring\Agent\Core\4.00.  Thanks to David Sachon from Citrix for helping me out in the Citrix Support Forums.

For more information see the Citrix Blog post – How to EdgeSight While you XenDesktop and the Citrix Knowledge Center article CTX124851 – EdgeSight for XenDesktop Best Practices.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.

In December of 2009 I wrote about Upgrading Provisioning Services vDisk Target Device Software, Virtual Machine Tools, and Network Drivers.  In that blog post I wrote about using the Reverse Imaging, Hyper-V Direct VHD boot, and XenServer Direct VHD boot options for updating Provisioning Services vDisk Target Device Software, Virtual Machine Tools, and Network Drivers.  With the recent releases of Provisioning Services 5.6 SP1 and XenServer 5.6 FP1 I decided to test out using XenClient to update the Provisioning Services images.  In this blog post I am going to go over another option for updating Provisioning Services vDisk images using XenClient.

Since The Citrix Blog post came out on How to run a NetScaler VPX on XenClient RC2 I have been thinking about other ways to use XenClient for a testing/lab tool and/or as a maintenance tool.  When updating  Provisioning Services images I have set up a single Hyper-V server at customers with XenDesktop deployments on VMware for the Hyper-V Direct VHD boot option, used the XenServer Direct VHD boot option by setting up a XenServer NFS storage repository, and have even thought about dual booting my laptop with Windows 7 and Windows Server 2008 for the Hyper-V Direct VHD boot option.  I have even considering installing Hyper-V on Provisioning Server for the Hyper-V Direct VHD boot option thanks to my friends over at The Generation V and their blog post Using Hyper-V for PVS vDisk Offline Maintenance.  Now with XenClient there is another option for maintenance on Provisioning Services images.

How to update Provisioning Services images using XenClient

1. Create a new virtual machine on XenClient (Hard drive size doesn’t matter size disk will be deleted after virtual machine creation and select Create VM & Install OS later).
2. Get the IP address of your XenClient machine.  To do this you can hit Ctrl+Shift+T to break out to the terminal on your XenClient machine and run ifconfig.
3. SSH to your XenClient machine (login with the password set up during install) and change directory to /storage/disks to get the UUID of the virtual machine’s VHD  file you just created in step 1.  If you have more than one virtual machine on your XenClient machine you can also open the /config/vms/ *.db files and look for the virtual machine name and disk 1 values to get the VHD UUID.
4. Make a copy of the vDisk image (.VHD and .PVP files) you want to update.
5. Copy the vDisk image VHD file over to your XenClient machine (using a secure file transfer tool such as WinSCP) /storage/disks directory.
6. Follow the instructions in Citrix Knowledgeable Article CTX127075 – Attempting to Use a Virtual Hard Disk on XenClient 1.0 Creating using XenConvert or from a Pre-Release XenClient System Fails with Error Code 199 or the XenClient virtual machine will not boot and you will get Error Code 199.  Rename the VHD using the same UUID.vhd file name from step 3.
7. Boot the virtual machine in XenClient.
8. Update the XenServer tools (Remove Provisioning Services Tools, install XenServer tools, and reboot) and then Provisioning Services Target Device software (Reboot after install).
9. Check Provisioning Services Target Device NIC binding by running Program Files\Citrix\Provisioning Services\BindCfg.exe and then shut down the virtual machine.
10. Copy the vDisk image VHD file back to your Provisioning Services vDisk store.
11. Rename the vDisk image VHD file back to match the name of .PVP.
12. Import the vDisk into the Provisioning Services console.
13. Assign the vDisk image to a Target Device.
14. Boot the Target Device and test to make sure everything is working fine. 
15. Assign to the remaining Target Devices and boot or reboot them to get the updated vDisk image.

I have tested this process with Windows XP, Windows 7, and Windows 2008 R2 images running on XenServer 5.6 when I upgraded from XenServer 5.6 to XenServer 5.6 FP1 and Provisioning Services 5.6 to Provisioning Services 5.6 SP1. 

So now you have another option for updating Provisioning Services images.  If you have a desktop or laptop with XenClient installed, try out this process the next time you need to upgrade XenServer tools or Provisioning Services Target Device software.

Citrix Provisioning Services 6 has an issue with target devices getting a black screen or the target devices stop responding on reboot.  This issue is caused by a DHCP lease issue with Provisioning Services 6.  See Citrix Knowledge Center article CTX132133 – PVS 6.0 Targets Might Boot to a Black Screen and Stop Responding for more info.  So what happens if your Target Devices are having the issue and you are not able to use them anymore?  In this article I am going to go over how to fix your Provisioning Services image.

With some help of the Citrix Support Forums post – Streamed Desktops Black Screen after Booting, I was able to fix the issue in the lab and in a customers environment.  So far I have tested and confirmed three fixes for the black screen issue.  The fourth fix I have not fully tested yet but should work.  Before doing black screen fix #1 or #2, make sure to change your DHCP scope for your target devices to unlimited as stated in the Citrix Knowledge Center article above or the issue will happen again.

Black Screen Fix #1 – Mount the vDisk on a Provisioning Server in your environment and clear the DHCP info from the registry.  Before doing the following procedure make sure to make a backup copy of you vDisk(s).  Follow the instructions with screenshots below for this.

1.  Right click on your vDisk and select Mount vDisk.  The icon next to the vDisk should change to show that it is now mounted to the Provisioning Server.  In Windows Explorer the vDisk will mount using the next available drive letter.

2.  Open the Registry Editor and load the system registry hive from E:\Windows\System32\Config\System.  In this example the vDisk mounted with E as the drive letter.

3.  Clear the data for DhcpDomain and DchpNameServer in CurrentControlSet001\services\Tcpip\parameters in loaded registry hive.

4.  Check each registry key and clear the data for DhcpDefaultGateway, DhcpDomain, DhcpIPAddress, DhcpNameServer, DhcpServer, DhcpSubnetMask, and DhcpSubnetMaskOpt under CurrentControlSet001\services\Tcpip\Interfaces.  Repeat for each key under the Interfaces key.

5.  Repeat steps 3 and 4 for the CurrentControlSet002\services\Tcpip\parameters registry hive.

6.  Unload the registry hive loaded in step 2 and close the Registry Editor.

7.  Right click on your vDisk and select Unmount vDisk.  The icon next to the vDisk should disappear to show that it is now unmounted from the Provisioning Server.  In Windows Explorer the vDisk should no longer appear.  In this example drive letter E should no longer appear.

8.  Boot the image to make sure it boots without the issue.  Repeat the process for each vDisk image having the issue.  Remember to make a backup copy of your vDisk images beforehand.

Black Screen Fix #2 – Change the Provisioning Services Target Devices to another vlan in your environment.  Using this fix may require some network changes along with changes to your firewall and Access Gateway configuration for remote users.

Black Screen Fix #3 – Leave the Provisioning Services Target Device software at the 5.6.x version.  While upgrading Provisioning Services from 5.6.1 to 6 in a customers environment, I did not see this issue when the Provisioning Servers were upgraded to 6 and the target devices were left on 5.6.1 for several weeks.  In this environment the DHCP lease was set to 1 day.  The issue did not start appearing until the images Target Device software were upgraded to 6.0.

Black Screen Fix #4 – Use direct VHD boot to boot the vDisk image and revert the Provisioning Services Target Device software to a 5.6.x version using Hyper-V or XenServer direct VHD boot.  This fix is still being tested but should fix the issue.  You could also stay with the 6.0 target device software and combine fix #1 (without mounting the vDisk image on a Provisioning Server) and #4 to fix your vDisk images.

After performing any of the fixes above, your Provisioning Services Target Devices should now boot without having the black screen issue.  Hopefully Citrix has a Provisioning Services 6 Target Device fix soon so target devices no longer require an unlimited DHCP lease.  I also hope this issue is only affecting your XenDesktop vDisk images and not your XenApp vDisk images since your XenApp target devices should have a DHCP reservation.

If you have found this article interesting or if you have any other insights, please feel free to leave comments on this article.