While XenServer 5.5 has a pretty decent GUI, there are still a few tasks that we have to use the command line for. Resizing Storage Repositories would be one of those tasks. In my environment, we use a Fibre Channel SR in our main XenServer resource pool, so I can vouch that these steps will work for that type of environment.

Before starting with these steps, make sure you have actually resized the LUN using whatever software provided by your SAN vendor. This process is simply getting XenServer to recognize the change.

1. Open the console of your XenServer Resource Pool Master.
2. Run xe sr-list
3. Find the UUID associated with the name of the SR you wish to resize. Make note of the UUID (I just copy it).
4. Next, find the device name. To do this, run pvscan | grep <uuid> - The device name will look like /dev/sdb – Make note of this as well.
5. Run pvresize <devname>
6. Run xe sr-scan <uuid>
7. Verify that the SR shows the new size in XenCenter.

It’s a simple process, though I forget how to do it every time. Now it’s written down for all to see!

As an administrator of both XenDesktop and XenApp environments, I’m absolutely sick of multiple consoles. I’ve finally managed to easily integrate XenDesktop and XenApp administration into a single console (AMC). Unfortunately, we’re unable to integrate the “Presentation Server Console” that is still used for manging policies.

While alternative methods may exist, I know the following steps will work.

1. On your XenDesktop 3.0 Media, run autorun.exe
2. Select Install Optional Components.
3. Install Management Consoles.
4. Install XDE300AMC004 (Download here).
5. Open the Access Management Console, you should see Desktop Delivery Controller in the left pane. If you do, you may continue.
6. On your XenApp Media (I’m using 4.5 media) navigate to Administration\Access Management Console\Setup\
7. Run ASC_PresentationServer.msi
8. After following the prompts, you should now have Presentation Server as an option in the left tree below Desktop Delivery Controller.

If you also want other snap-ins you can find them on your media under Administration\Access Management Console\Setup\. There are snap-ins for Web Interface, etc. as well.

When configuring your vDisks in Citrix Provisioning Server, you’re able to define which mode you would like your vDisk to be in. While many people know the basic differences, not everyone understands how to leverage them in their environment.

Private Mode

Private mode puts the vDisk into a volatile state where a target device can make permanent changes to the vDisk. Changes are not stored in a write cache file, they are changed immediately. When a target device connects to the vDisk, it gains exclusivity and no other device may connect to that vDisk.

This mode is best used when a single user needs application install capabilities which need to persist through reboots and updates. This is idea for streaming an operating system to a physical target device in order to move their hard disk to the datacenter for data consolidation. This mode is also used to make changes to a vDisk that is otherwise in Standard or Difference mode.

Standard Mode

Standard Mode is the bread and butter of Provisioning Server. It allows for changes made by the user, but they do no persist through reboots. They are stored in a write cache file and cleared upon graceful shutdown. The location of the write cache file is defined on a per vDisk basis and can be placed on the Provisioning Server Disks, in the target device’s RAM or local disk – with options for encryption and maximum size (when placed in RAM).

Standard Mode is usually used when leveraging XenDesktop so that users receive a standardized desktop which they can make temporary changes to without affecting the experience of other users. This can also be used when streaming an OS to a desktop to turn it into a pseudo thin client.

Difference Mode

Difference Mode is an interesting mode. It’s not often used, as far as I know. It’s essentially a hybrid standard-private vDisk. The base of the image is standard, but the user can make changes which are stored in a write cache file just like standard, but they persist through reboots. When the target device is booted, it boots to the standard image and then the write cache file is applied like a delta file. The main issue with this is when a change is made to the standard base, it destroys the delta write cache files.

Possible uses include tech labs and classes where a standard environment must exist for all users, but users need to make changes as part of the curriculum. The instructor can then remove the write cache files and “reset” the environment. A serious time saver in that case.

Conclusion

I only listed a few short use cases in this post. I’m really curious how everyone leverages these modes in their environment – please share!

Citrix Provisioning Services (PVS) is a great tool that is what our local Citrix Sales Engineer calls “the Secret Sauce” behind XenDesktop. For those who are new around these parts, PVS is software that allows us to stream an Operating System to a PC, physical or virtual, ESX or Hyper-V or XenServer – anything that can PXE boot pretty much (including Thin Clients!).

Once you’ve made the plunge and start deploying or planning your PVS infrastructure, High Availability and Redundancy is going to be a top concern. Here are a few guidelines to help you plan. Let’s assume we have a single farm, single site, with 2 Provisioning Servers.

Shared storage is your friend with Provisioning Server HA.

vDisk Storage

Ideally, this should be on shared storage. Server should be able to communicate with the SAN/NAS/etc at high speed. Fibre Channel works great here (4Gbps). Alternatively, you can have identical vDisks available via the same drive letter on each of the servers.

Write Cache Location & Storage

The two types of write cache locations that are in play: Stored on PVS Disk and Stored on Client HD (ignore Encryption, it’s not really relevant here). Storing the Write Cache on the Client’s Hard Drive is fastest, and is what I would recommend, as the file is available independent of the provisioning server. Alternatively, you can store the write cache on shared storage that can be accessed by each server so that the target device can continue to function.

TFTP Server

This is the tricky part. The best way to handle this is with hardware load balancers, but for the sake of this article, I’ll give you some “rigging” solutions. You can run the TFTP service on both servers and use “round-robin” settings on your DHCP server. Also, you can use the Bootable Image tool included with PVS to create a Bootable CD that contains the bootstrap file (the same one that it can get via PXE). If you have a NetScaler in your environment, you can use it to ensure HA of TFTP (Thanks Bart Groot Zevert). I’m sure there are other ways as well, feel free to comment with suggestions.

Conclusion

As mentioned before, these are just some guidelines and tips to get you started on the right path. I’ll be more than happy to assist should you need assistance.

Planning for your new XenDesktop environment can be a tough process. Being a relatively fresh technology, there aren’t too many places to find straight answers regarding scalability. I intend on changing that. Here are a few helpful tips and straight answers to help you decide whether you have the hardware already, or need to purchase new. This will be a multi-part series, only some aspects will be addressed in this initial post.

Assumptions

• XenDesktop 3.0, Platinum Edition.
• XenServer 5.5.
• Provisioning Server 5.1.
• XenApp 5.0, Platinum Edition.
• Windows Vista Business (x86)
• 300 Users, all will use XenDesktop for OS and XenApp for Application Delivery.
• Endpoints are XP Embedded Thin Clients.
• Single Location, Single Data Center.
• Users occasionally want to access the environment from home.
• Users are “Task Workers”

While this scenario is pretty simple, I’ll be more than happy to help you with your questions in the comments, via Twitter, or e-mail.

In the next post, I’ll discuss Virtual Machine Specifications and choosing the right server specifications for your XenServer hosts.

When troubleshooting problems, it’s essential you have as much information is possible. Logging is the best passive way to achieve this. Even in 2009, we’re editing files in Notepad…

Virtual Desktop Agent Logging

1.     Create a new directory called c:\ctxlogging\. The Network and Local service accounts should have write access. If you are using standard vDisks, I recommend putting the log file on local storage so that it persists after log out.

2.     Navigate to c:\Program Files\Citrix\Virtual Desktop Agent\

3.     Open WorkstationAgent.exe.config with your Text Editor of Choice.

4.     Find the <appSettings> tag.

5.     Within the <appSettings> tag, insert the following two lines:

<add key="LogToCDF" value ="1"/>
<add key="LogFileName" value ="C:\ctxlogging\vda.log"/>

6.     Restart the Virtual Desktop to start logging.

Desktop Delivery Controller Logging

1.     Create a new directory called c:\ctxlogging\. The Network and Local service accounts should have write access.

2.     Navigate to c:\Program Files\Citrix\VMManagement\

3.     Open CdsPoolMgr.exe.config with your Text Editor of choice.

4.     Find the <appSettings> tag.

5.     Within the <appSettings> tag, insert the following two lines:

<add key="LogToCDF" value ="1"/>
<add key="LogFileName" value ="C:\ctxlogging\ddc_cdspoolmgr.log"/>

6.     Navigate to c:\Program Files\Citrix\Desktop Delivery Controller\

7.     Open cdscontroller.exe.config with your Text Editor of choice.

8.     Find the <appSettings> tag.

9.     Within the <appSettings> tag, insert the following two lines:

<add key="LogToCDF" value ="1"/>
<add key="LogFileName" value ="C:\ctxlogging\ddc_cdscntrl.log"/>

10.  You will need to reboot your DDC for this to take effect. If you have more than 1 DDC, perform these steps on all of them.

Some of the paths may vary depending on OS (x64) and whether you changed the default install paths during installation.

EDIT 8/23/09: Added CTX Article, http://support.citrix.com/article/CTX117452 and CTX Article for Enabling PortICA Logging http://support.citrix.com/article/CTX118837

The user Network Service will need Full Control over the log directory. While this is not officially documented by Citrix, it has been reported by others. (Thanks to Alistair Gillespie)

I’m often asked how to update a vDisk for use with XenDesktop, so I figured I should publish my answer.

These steps should suffice to answer most questions regarding updating vDisks for XenDesktop. I’ll be happy to assist you if you have more questions or require clarification. Just leave a comment.