I was on-site last week with one of our large Systems Integrator partners and they asked what recommendations we had for organizing the devices within the Provisioning Services console. Of course, working for Worldwide Consulting Solutions, I answered, "It depends".  Seriously, though, I reviewed their proposed XenDesktop design from a Provisioning Services view and developed a model which would work well as a XenDesktop farm scales. Keep in mind that this suggested organization is based on their design. Your design may work better with a different organization methodology.

Product Architectures

Since the organization is design-dependent, before explaining the Provisioning Services organization model, let me share with you the XenDesktop design that will be used for this model.

The design discussed here is referred to as the Modular Management (MM) design and the architecture is based on building a single XenDesktop farm out of smaller self-supporting Desktop Delivery Modules (DDM). Each DDM contains a group of virtual desktop hosts, a block of shared storage, and a set of provisioning servers to support the number of desktops hosted. This design also provides smaller units that can be managed through delegation. For the purpose of this blog, the example DDM contains four provisioning servers organized as a single site for fault tolerance, 20 XenServer hosts, and shared storage on a SAN. The diagram below provides a visual representation of a single DDM.

 

Taking that DDM structure and replicating it multiple times within a single XenDesktop farm provides a scalable platform for large XenDesktop installations. The multiple DDMs can then added to an existing XenDesktop farm infrastructure which would include Desktop Delivery Controllers, a Citrix license server, a clustered SQL database, and pair of Web Interface servers. The diagram below provides an example of what this Modular Management design might look like at the farm level.

Changing gears, a Provisioning Services farm is separated into several logical partitions that can be used to adapt to almost any environment. The highest logical partition is the farm. Within a farm are common components such as a SQL database server, a Citrix license server, a PXE server, and usually shared storage for vDisks, such as a SAN. Farms are partitioned into one or more sites. Each site contains provisioning servers, device collections (groups of target devices with common characteristics), and vDisk pools. The diagram provides a visual mapping of the different partitions and their relationships.


One of the reasons Provisioning Services was redesigned was to allow delegated administration at each of the partition levels. Most customers have a separation of duties between farm administrators, server administrators, desktop administrators, and help desk personnel. With this new partition design, the permissions can be granted at the farm, site, and device collection level. The delegation of duties in a customer environment will influence the design. The design in this blog supports delegated administration at all four levels: farm, server, desktop, and helpdesk.

Console Organization

Now all the core architecture is understood for both XenDesktop and Provisioning Services, we can begin to look at the organization of the items within the console. To simplify this, we will focus on a single XenDesktop farm that has three DDMs: DDM 1, DDM 2, and DDM 3 (Notice the space in the name of each DDM to distinguish the XD DDMs from the provisioning services objects which are named without the space). Each of these DDMs supplies a different operating system image. DDM 1 supplies Windows XP desktops, while DDMs 2 and 3 supply Windows Vista and Windows 7 desktops respectively. In the XenDesktop Access Management Console (AMC) the administrator has configured three Desktop Groups: Windows 7 Desktops, Windows Vista Desktops, and Windows XP Desktops as seen in the screen shot below.

Ideally, a single Provisioning Services farm is used to support a single XenDesktop farm, such that you have a 1:1 mapping between the two farm types. In the screen shot below of the Provisioning Services console, depicts the Provisioning Services farm name (XenDesktop3) that matches the name of the XenDesktop farm name as shown above.  

The screenshot above shows clearly the different objects available. Below I will discuss each one and explain how it maps to a DDM for management. 

Sites: Sites are created in the Provisioning Services console for each of farm DDMs.  The sites names will correspond to a single farm DDM. In the example, the site names are DDM1, DDM2, and DDM3 per our farm architecture above.  In other words, in this configuration the terms site and DDM can be used interchangeably when referring to objects within the Provisioning Services console.

Servers: The provisioning servers that are assigned to service a single farm DDM are then added to the appropriate site DDM in the Provisioning Services console.

Device Collections: Device collections contain all the target machines that are delivering a specific desktop image. Group similar images into a one device collection such that the entire group can be managed as single entity. This grouping will simplify management later when images need to be versioned or updated. In the example, since DDM 1 is responsible for delivering only Windows XP images, a single device collection, named Windows XP Desktops in the screen shot, can be used for all the hosts in DDM 1.  If DDM 1 had multiple images being delivered, then multiple device collections would be created.

Stores: vDisk stores are created for each of the DDMs: DDM1, DDM2, DDM3. The vDisks are then added to or created in the store for the DDM. The key here is that the corresponding servers in the DDM are assigned to the vDisk store so the vDisks are visible within the site. In the example, the DDM1 store would have the four provisioning servers assigned to DDM 1 would have check marks next to their names for that store. This will allow any of the provisioning servers for the DDM to serve up the vDisks contained in the store.

vDisk Store: The vDisk pool will include all the vDisk images that will be used by a site and shared among the provisioning servers supporting the DDM. The vDisk pool displays any images that are managed by a server in the site. In the example, vDisk pool DDM1 would contain the Windows XP images used for DDM 1 and Windows XP Desktops group. Likewise, vDisk pools DDM2 and DDM3 would contain their respective images for Windows Vista and Windows 7.

Delegated Administration

Keeping DDMs at the site level will allow administrators to leverage the partition-level delegated administration of the Provisioning Services console. Server administrators can be granted permissions over the DDMs they manage at the site level. Desktop administrators can be granted administrator permissions for the devices they manage by assigning them to device collections. Help desk personnel can be granted operator permissions on the devices at the farm, site, or device level. From a higher perspective, desktop farm administrators can be granted permissions for all the farms managed. The best part is that if an administrator has multiple farms to manage, they can use a single Provisioning Services console to manage all of them.

I hope you found this information useful. Follow me on twitter @pwilson98 to keep abreast of design and architecture tips for Citrix XenDesktop, Provisioning Services, and Password Manager (SSO) products.

In the previous Provisioning Services High Availability Considerations blog, I briefly spoke about using Provisioning Services 5.1 with read-only shared access to a SAN LUN(s). Now I will provide a step-by-step overview of how to implement this feature.

Let's start with pre-requisites that I mentioned in my last blog:

• You need to install Microsoft iSCSI initiator on all Provisioning Services servers that access the SAN.
• Private Image mode is not supported.
• If cache is located on server disk, a separate shared storage location that has read-write access is needed for write cache files.

Steps on the SAN:

You will need to create a volume on the SAN interface front end and then set access type for the volume to read/write, later you will make the volume read-only through NTFS attributes. In my example, I will use NetApp, your case might be different. The storage devices are called iSCSI targets and the clients are called iSCSI initiators.
 
Make sure it is online:

Now we move to the Provisioning Services server:

Initially, you will need to use iSCSI Initiator to login to the SAN volume on only one of the Provisioning Services server while in read/write mode. If you are using Windows Server 2008 the iSCSI software Initiator and components are built into the OS, if using Windows Server 2003 iSCSI software Initiator is available as a download package from the Microsoft website. In my example I am using Windows Server 2008, so I just enabled the service from the Admin tools.

 
Depending on your settings you may get a UAC warning, go ahead and approve. The iSCSI Initiator is our Provisioning Services server; under the general tab you will see the Initiator Name that you will need to provide as "Initiator" to your SAN. 

Go back to your SAN and add the "Initiator Name" to Initiator group:

Back to your Provisioning Services server, from the iSCSI Initiator Properties you need to go to the Discovery tab and add the portal by specifying the IP address to the iSCSI target:
When the LUN first appears on Windows you will have an uninitialized volume, therefore you have to switch it Online and let it get initialized. Next step you need to do is format the volume:Once you formatted the volume and assigned a drive letter/mount point, next step you will copy all the vDisk image files (.vhd) and associated properties files (.pvp) to the volume, no need to copy the Lock files. Before you copy the files, make sure all properties for the vDisks that will reside on the volume are set correctly (including High Availability).
Next step is to make the volume read-only. You can use diskpart.exe, verify the volume number, select it and then set the attribute to read-only. In case you want to verify if it was set correctly you can type "detail volume" and verify that "Read-only" is set to "Yes".

Now you will log off from the volume on that one Provisioning Services server, from the iSCSI Initiator click on "Details" and then" Log off..."

In case you get an error message about the volume being in use, go to Disk Manager and switch that disk Offline.You will log on to the target again and make the volume a persistent target.  You must log off and then re-login to the volume to get NTFS on the server to re-read the volume attributes, so that it will recognize the volume as read-only. Making the volume a persistent target will ensure the volume is accessible when the server reboots: 

Just mount the iSCSI volume on all the other Provisioning Services servers; it is now safe since the volume is set to read-only. Also, in order to facilitate your job, have all servers to mount the volume using the same drive letter or mount point; if not you will need to adjust that from the Provisioning Services Console. You should be all set after creating a store and pointing the Path to the SAN volume and adding the vDisk to the pool. Don't forget if you are using Difference disk mode you must enter a default write cache path for the store that does not point to the read-only SAN volume, this also applies if you are going to use write cache on the PVS server (cache on server disk).

You might be thinking, what if I am using a NetApp array as the back-end storage attached via Fibre Channel? There is no reason why this should not work since the LUN appears as a drive to Windows, so Provisioning Services should have no problem using it. When using Fibre Channel the iSCSI initiator is not required, so vendor specific software for the FC device should be used.

If you want more details about this subject, I encourage you to watch this TechTalk session called:  "Simplifying Implementation of Provisioning Services"

"Elisabeth Teixeira - Principal Engineer - Worldwide Technical Readiness

Follow me on Twitter: http://www.twitter.com/lizteixeira

Follow me in the Blogs: http://community.citrix.com/blogs/citrite/elisabetht

"bnsmdf.sys" driver is a simple scsi miniport filter driver that is responsible for handling /reporting device power state change, device error or status change, etc.  Please check if it happens on some specific hardware or all machines. Also, are they using target-side cache for this?

 "bnsmdf.sys"ドライバは、シンプルなscsiミニポートフィルタドライバで、デバイスの電源状態の変更、デバイスのエラーなどを

処理し、レポートします。

特定のハードウェアに依存するかどうか、複数のマシンで発生するのかを確認します。

また、キャッシュの設定について確認します。

[質問]
キャッシュ方式をローカルHDDキャッシュにして起動したのですが
サーバサイドキャッシュになってしまいます。
[回答]
PVS のターゲットデバイスが起動する際に、ドライバの起動時
（起動の途中で画面背景が黒から青に切り替わる時）に
サーバのレスポンスが悪い場合に、Write Cache が "Local-HDDキャッシュ"
から　"サーバキャッシュ" へと切り替わることがございます。
これは現在のPVSの実装による、期待する動作となります。
サーバキャッシュへスイッチされるトリガーとなる条件は、
ローカルキャッシュのHDDがフルになる場合です。
この機能がない場合、PVS のクライアントソフトウェアは、
キャッシュへデータ書き込みがこれ以上できなくなった際に、
ターゲットデバイスが適切に機能し続けることができなくなるためです。
RAM キャッシュでは、BSODを起こさないように、
PVS のクライアントソフトウェアは、ライトキャッシュがサーバに
移動されることで、PVS のクライアントソフトウェアが復旧し、
機能し続けることができます。この移動がなければ、
ターゲットデバイスはハング、またはBSODを起こすことになります。
 
参考までに、英語の情報も添付いたします。
参照ください。
The condition that triggers the switch to Server cache is when the hard drive on the local cache becomes full. Without this feature the target device would discontinue to function properly when the PVS client software could not write any more data to the cache. Unlike Ram cache, the condition results in a BSOD, the PVS client software is able to recover and continue to function once the write cache is moved to the server. Without this move the target device may hang or cause a BSOD.
 Linux については、Windowsとは異なり、クライアントローカルDiskキャッシュからサーバキャッシュへスイッチする機能は、サポートされていません。
参考:
Linux client does not support cache failover from the local HDD to the server.

"Citrix Provisioning Services 5.1 Administrator's Guide"
"Citrix Provisioning Services 5.1 Installation and Configuration Guide"

 http://support.citrix.com/product/provsvr/psv5.1/#tab-doc

If you select Standard Image and Cache in target device RAM, select the cache
size in megabytes.
The max size of the RAM write cache is determined by the registry setting
WcMaxRamCacheMB in the BNIStack Parameters. This is a DWORD
parameter. If the registry entry does not exist, then the default value used is 3584
MB.

 Standard Image と Cache in target device RAM　を利用している場合、キャッシュサイズをMBで設定します。

RAMの書き込みキャッシュの最大値は、 BNIStackパラメータのWcMaxRamCacheMBレジストリで決定されます。

これは DWORD値です。もし設定されていない場合は、デフォルトで3584MBです。

This setting enables the bootstrap to work with newer Windows OS versions
and is enabled by default. Only disable this setting on older XP or Windows
Server OS 32 bit versions that do not support PAE, or if your target device is
hanging or behaving erratically in early boot phase.
 

ターゲットデバイスの起動初期のフェーズでターゲットデバイスがハングする、または予期しない動作をする場合、

PVSトラブルシューティングの確認事項

PVS のstream.logログ、および Target Device のVirtual Disk Status のStatistic の
取得をお願いいたします。

○ stream_logについて
注意：PVS 4.5 SP2 または PVS 5.0 SP1a 以降のみ詳細なログが取得可能です。
それ以前のバージョンではログが取得できませんので、ご注意ください。
PVS 4.5 SP2の場合

　C:\Program Files\Citrix\Provisioning Server\stream_log.config 、
PVS 5.0 SP1a以降の場合
　C:\Documents and Settings\All Users\Application Data\Citrix\Provisioning Server\stream_log.config

または　PVS 5.1以降の場合(Provisioning Services Consoleから設定することもできます)
　C:\Documents and Settings\All Users\Application Data\Citrix\Provisioning Services\stream_log.config
において、ログのレベルをより詳細なTRACEへ変更し、クライアント起動時のログを取得ください。
例：
　<level value="ERROR" />
を
　<level value="TRACE" />
へ変更します。

○ 起動のタイミングの詳細
起動時のどの段階で発生しているのかわかりましたら、詳細をお教えください。
DHCPサーバからのクライアントのアドレス取得、
PVSとの接続（PXE Bootstrap よりVerbose Modeを選択することで詳細アドレスを表示）、
または、vDiskよりのOSの起動。
起動のタイミング
下記の起動時の流れの中で、どの時点で発生しますでしょうか。
(例：Vista SP1 の場合）
 電源On
 　↓
 DHCPサーバからのクライアントのアドレス取得
 　↓
 Citrixのロゴ表示
 　↓
 PVSに接続し以下のメッセージが表示される。
 　Connecting to the Provisioning Server.
 　virtual disk found.
 　
 Verbose Modeの場合は　IPアドレスが表示
 　↓
 真っ黒画面表示
 　↓
 Vistaのスプラッシュ画面表示(起動バーが流れる画面)

たとえば、まず切り分けの判断基準
Power ONからDHCP, DHCP Optionをゲットするまで→DHCPサーバー
NBPファイルを落としてくるまで→TFTPサーバー
NBPファイルを読み込み、PVSにLogin Request, MACからvDisk Assignmentをゲットするまで→NBPファイル
StreamServiceからvDiskをストリームしてOS軌道まで→StreamService

○ ネットワークの構成
単独の閉じられたネットワークでも事象は発生、確認されていますでしょうか。
また、以下の点も確認いただけますでしょうか。
1. DNSサーバーの設定
 vDiskのネットワークプロパティの設定において、
 DNSサーバーのアドレスを設定する（動的に取得しない）場合の動作の違い。

2.DHCPサーバ上のスコープOption66,67について
 PXE Serviceを使用とのことですが、ブートサーバーホスト名および
 ブートファイル名を設定する場合の動作の違い。

Microsoft DHCPサーバーのDHCP PXEオプションを追加する方法
http://support.citrix.com/article/CTX118513
How to Configure Option 60 on a DHCP Server
http://support.citrix.com/article/CTX115212

3. Provisioning Serverの推奨ネットワーク設定
 http://support.citrix.com/article/CTX118706

 Large Send Offloadオプションについて
 Provisioning Server Target Devices Lock up Shortly Before or After Logging on to Windows
 http://support.citrix.com/article/ctx116814
 Registry Settings to Improve Failover Times
 http://support.citrix.com/article/ctx119223
 The Image Build Process Takes a Long Time to Complete
 http://support.citrix.com/article/ctx115658

○ PVS のネットワークトレースの取得
Wireshark (http://www.wireshark.org/) をPVS サーバーにインストールし、
クライアント起動時のPVS サーバーからのネットワークのすべてのパケットを
すべてキャプチャーします。
その際のログを保存いただき、返信いただければと存じます。
ネットワークの状況がクライアントの起動に影響していないかどうか確認できることを
見込んでいます。

○ NICのドライバーおよびROM
マシン製造元またはNIC製造元にもお問い合わせいただき、
NIC の最新のROM、および NIC の最新のドライバーへアップグレードし、
動作を確認ください。

Citrix Provisioning Server 5.0 (SP1, SP1a) Installation and Configuration Guide
http://support.citrix.com/article/CTX117917
Network Card　PXE 0.99j　以降

○ Citrix Knowledge Center
http://support.citrix.com/product/provsvr/psv5.0/topic/troubleshoot/
http://support.citrix.com/product/provsvr/psv4.5/topic/troubleshoot/

○ローカルHDDキャッシュ

PVSクライアントをVdisk（Standardモード、EncryptedローカルHDDキャッシュ）から起動し、

何らかの処理により、おそらくOut of Virtual Memory が発生し、ハングアップしてしまう。

おそらくは、Virtual Memory の管理系かと思われるが、開発元では原因究明できていないようです。

回避策は、 ページファイルの配置場所を、デフォルトのCドライブからDドライブ（ローカルHDD）に変更。

Mid May I presented a methodology to successfully migrate physical PCs to a virtual desktop environment delivered by Citrix XenDesktop. The key area of focus was thereby around the planning and performing of a migration.

During this TechTalk, not all questions could be answered and therefore, I would like to share the related information below. In case you miss a question not being answered or have further questions, please use the comments field and I will get back to you.

Since many of the attendees asked for the presentation, you can download it from here.

I hope the migration methodology provides guidance during a transition from physical PCs to virtual desktops and don't skip the planning phase since this will ensure a successful migration.

Tarkan

Follow me on Twitter: http://twitter.com/TarkanK

Questions & Answers

Q: What is the best practice for implementing XenApp to deliver applications? A physical or virtual server?

This is a good question. In the past, we followed a best practice "never ever" virtualize a Terminal Server or XenApp server since real-time work was impacted. However, virtualization of workloads made so much progress that this is negligible compared to the benefits you can gain with it. Therefore, if you have a virtualization infrastructure based on XenServer, I would recommend using virtual machines to provide XenApp since you will benefit from the XenApp specific optimizations on XenServer as well as have a more dynamic server management rather than being dependent on a physical machine. Other benefits are definitely around hardware savings, power and cooling costs (even though you will have probably a bigger box for the virtualization infrastructure).

Q: From the application delivery perspective, the slides suggest that streaming is the primary (and recommended) method. Hosted seems to be a secondary method. Why is it *not* recommended to put the "Core" (Office, Adobe Reader, etc.) applications installed on the Virtual Desktop?

The easiest way of delivering apps is probably by installing them into the virtual desktop and you are good to go. There is nothing against this approach. Using this approach for core applications such as Microsoft Office, Adobe Reader is definitely doable; especially considering the fact of Microsoft Office 2007 updates being integrated into the Microsoft Windows Update mechanism simplifies the Office update process.

However, reasons for primarily recommending streaming as the choice for even core apps is mainly driven by the following points:

• Allows virtual desktops being slimmer, especially if hosted apps are used, increasing the number of concurrent virtual machines on a virtualization host.
• Central delivery of applications to virtual desktops, physical desktops, and XenApp servers.
• Simplifies virtual desktop OS maintenance and upgrades

The key for a successful app delivery strategy is that it needs to meet your requirements for app criticality, app type, update frequency, resource usage, and compatibility. Considering these areas may even lead to an app delivery solution leveraging all three methods. My coworker Daniel Feller already created a blog Simplifying Application Delivery into the Virtual Desktop that gives some insights as well.

Q: What is the tested maximum number of Windows XP virtual desktops in a single XenDesktop farm?

We are conducting regular tests based on the latest XenDesktop release version to verify scalability of a XenDesktop farm. However, bear in mind the fact that XenDesktop is a collection of components that interact with each other and each components scalability such as Desktop Delivery Controller, Provisioning services, and virtualization infrastructure may impact the overall architecture. The most recent test results (that were shared during the Citrix Synergy session "iForum221 - Advanced strategies for virtual desktop scalability") simulated a XenDesktop farm with a 9 am logon storm scenario. In this scenario, the XenDesktop farm could easily handle 4,500 logons to virtual desktops within 15 minutes and the peak CPU utilization was at 60% and memory at 2 GB (used hardware specs: dual quad-core, 1.8 GHz, 16 GB RAM). Once the Desktop Delivery Controller brokered a connection, it is not very active. Therefore, the next stop for scalability to look for is Provisioning services and the virtualization infrastructure. In this case factors such as used server hardware or virtual server configuration impacts the scalability and the virtual desktop type (user, OS, workload).

Q: Migrating from physical desktops to virtual desktops, how do you calculate how many users you can get on a server?

This is exactly the point, where the assessment as part of the planning phase is important to have. Therefore, you should assess the following:

• Target virtual desktop OS type - Windows XP, Windows Vista, or Windows 7
• Desktop hardware requirements (CPU, memory, network) to apply the right configuration to virtual machines
• Storage space

Based on this information and the target server hardware running the virtualization infrastructure will allow you a better sizing estimate. Better is to run a scalability test on at least a single server.

Q: Where would you start the migration process for a company with 200 users and 7 different departments?

As part of the migration planning, one action item is definitely to define the migration process. To do so, there are some factors influencing this process, which is not solely depending on the number of users or departments:

• Hardware refresh requirement
• OS upgrade requirement
• User groups
• Maintenance schedules

This should allow the prioritization of where to start and how to sequence the migration process.

Q: Users will want their music files (currently stored on desktop). We have cheap disk but it's only available as NFS (putting this on the SAN is not an option due to expense of storage and low business value of the MP3s). Any idea how we could make this work, maybe by dynamically creating an NFS mount for each user, say an E drive?

One key benefit of XenDesktop is the user experience provided by HDX (High-Definition user eXperience). Leveraging this capability allows mapping of USB drives or local drives of an endpoint into a virtual desktop running in the datacenter. This provides users' access to their files, in this case MP3s and therefore, IT does not need to handle this. However, IT should consider related security measurements and the impact on LAN/WAN usage if users have large files to copy.

Q: Can you share a base image disk among multiple desktops?

This is the key benefit of Provisioning services to provide a vDisk to be shared by multiple desktops. These are the available vDisk types:

• Standard Mode - read only OS image and shareable with multiple desktops
• Private Mode - read/write OS image and is assigned to a single desktop (not shareable)

Q: Is there some type of sysprep or utility that needs to be run every time the vDisk is opened up? Does Provisioning Server handle this and dynamically provide a Windows hostname when a Virtual Desktop is booted up?

Provisioning services does not require sysprep to allow sharing of a single vDisk by multiple virtual desktops. Once the "golden" image has been created, Provisioning services takes care about computer accounts and the computer account passwords within the Active Directory. This is also the reason, why Provisioning services should be setup with domain administrator rights. A more comprehensive overview of this process is described in the Provisioning services Administrator's Guide - section "Managing Domains and Active Directory Integration".

Q: If the master image gets updated on Saturday after all users have logout, will there be any delay in OS delivery when the users come in next Monday?

If the master image has been updated on Saturday and you know how many logons you have simultaneously on Monday, you can adjust the setting "Idle Pool" of a Desktop Group. This Desktop Group setting allows you to configure how many idle desktops (booted and waiting at the Windows logon screen) you want in your pool at certain times of the day. You can also configure a peak period to cover the time at which most users will be logging on to their desktops. This period starts at the beginning of your business day.

Q: How do you manage (add/delete) applications on the golden image? Is there a tool to do this?

Due to the fact that the golden image is a read only OS image and this golden image needs to be started in Private Mode (read/write). If the OS or applications need to be updated in the golden image, the best approach is:

1. Take a copy of the file and rename it to reflect a newer version
2. In Provisioning services, change the newer version of the golden image into Private Mode
3. Assign this golden image to a virtual machine and boot from it
4. Apply required changes and updates
5. Shutdown virtual machine
6. In Provisioning services, change the updated golden image into Standard Mode and assign it to the virtual machines

There is also a way to automate the assignment if the Provisioning services option "Automatic Updates" is selected and versioning of golden images is used.

Q: Is there a way to have two (2) different DHCP´s with only one XenDesktop farm?

Sure, however the DHCP scopes should not conflict in order to avoid duplicate IP addresses. As part of a redundant DHCP solution this would be Microsoft best practice called split scope DHCP.

Q: How is a dual monitor connected?

There is no requirement for any specific configuration on the endpoint device to support dual or multiple monitors for a virtual desktop. Multiple monitors are detected on endpoint device and virtual desktop is displayed across all monitors. A single virtual desktop can span up to 8 monitors in a rectangular shape (e.g. 1x8, 2x4), where each monitor must have the same resolution.

Q: How do I solve the road warrior without Internet? Is there a checkout feature available today or being planned?

At the current stage XenDesktop does not have a feature to support offline usage of virtual desktops. However, the showcased XenClient during Citrix Synergy will provide this capability in the near future. This is being developed as Project Independence.

In Provisioning Services for XenApp Best Practice #5, I wrote about application streaming integration. I talked about two different options:

1. Stream on-the-fly: which results in the vDisk write cache growing as the application is streamed
2. Pre-cache: which stores the application cache within the vDisk, but helps to reduce the size of the vDisk

Both of these options had their issues. Option 1 would grow your write cache quickly, especially on XenApp servers hosting tons of applications. Option 2 creates a link between the vDisk and applications, which adds another step to application updates.

I received many suggestions and alternatives, some were quite interesting . The one that resonated the most was to store the application streaming cache on another disk that is not delivered via Provisioning services.

• Physical Servers: You would use the physical disks installed into the physical servers
• Virtual Servers: You would use a virtual disk assigned to the virtual machine (preferably shared storage so you can still do XenMotion).

This setup doesn't really change our architecture in that many implementations have a non-Provisioning Services disk associated with each server to store items like event logs, local databases, write cache and pagefile (as explained in BP 8?).

Honestly, I haven't had the opportunity to set up an environment like this in a large environment, so I didn't want to offer it as a best practice yet. But I've had many of you say that this is about the only way you deliver XenApp images with Provisioning Services and have had no issues with the environment from configuration or maintenance. I've always thought this provided the best solution as it overcomes many of the lingering challenges of option 1 and option2. So, how do you do this? It is actually pretty easy:

1. Make sure you have an NTFS disk associated with the physical server (physical disk) or virtual server (virtual disk)
2. With the Provisioning Services image in private-image mode, change the location of the Application streaming cache location
   1. Launch C:\Program Files\Citrix\Streaming Client\ClientCache.exe
   2. Change the client cache directory to the virtual or physical disk
   3. Shut down and place vDisk back into standard image mode
      
      
      When you boot, and launch your applications, your application cache is now stored on the physical/virtual disk that is not erased during reboot. What does this get you?

• Faster application launch after server reboots because the application cache is not erased
• Easier application maintenance because the application cache is not included within the vDisk

But this configuration does come at a price. You have to have a persistent disk associated with each physical and virtual server. Although this cost is pretty small as most Provisioning Services/XenApp implementations already have a local disk to store local monitoring databases, event logs, etc.

My list is now empty, but will post new topics as they come in.  Feel free to tweet me some ideas on Twitter.

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drive
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more

By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly.  I'm a little biased, but I think it is a good one.

Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

The whole concept of a standard image used across multiple end points is a great idea. Think about it, 1 image for hundreds/thousands of servers. Talk about simplicity. I only have to make updates once and every server has the same update. Every server is identical. This makes scaling up the environment easy. Of course there are some challenges, as many of you have pointed out after my very first blog posting where we spoke about vDisk type. That challenge is that the "write cache" is destroyed upon server reboot.

For the most part, this is a good thing. Those changes gives each XenApp server a personality. I don't want my XenApp server to have personalities. Its kind of like running Microsoft Word one day and it is using United States English and then the next day it uses United Kingdom English. This little personality change doesn't seem to be a big deal, but it is. For example, I like my words to use the letter Z. I believe you spell color without the letter U. I believe neighborhood is spelled without the letter U too. Of course this is a simple change for a user, but we shouldn't make our users do this. But there are some changes on XenApp servers which are valuable (many of you have pointed them out to me) like event logs and performance metrics.

So how do I use a standard image but still allow these important items to remain persistent across server reboots? Some of you have raised good points on this, especially around the use of differential disks, but the problem with differential disks is that the differential cache will go away if the base vDisk is changed. So, differential disks do not really help us out that much. What we can do instead, which again some of you alluded to, is to use a local disk.

Now I bet some of you have alarms going off in your head and are thinking, "Hey, I thought the benefit of Provisioning Services is that I don't need local disk". Well, you are 100% correct, that is one of the benefits, but there are more like standardization and synchronization but will leave that for a marketing-type blog. But with standard images you do lose some items like persistent storage of event logs, metric databases, etc. But if we allocate a local disk to the server, we can redirect the storage of the persistent data. BTW, this works when XenApp is virtualized on XenServer and when XenApp is on bare-metal.
You do this by doing the following:

1.  Your virtual machine must have 2 virtual disks assigned. Remember if you want to do XenMotion, the second virtual disk must be on shared storage. How large you might ask? For XenApp, a 4GB partition is a good starting recommendation, but with most decisions, it depends.
2. Build XenApp on the first disk and format the second disk NTFS so it shows up in your system (use basic disk and not dynamic).
3. Change the storage paths of your persistent databases, event logs and anything else to the second virtual disk.
4. Build your vDisk from the C drive, but not the second drive. When done, shut down the virtual machine.
5.  Detach the OS virtual disk from the virtual machine, but leave the second virtual disk attached.
6. Clone the virtual machine including the virtual disk.
7. Now stream the vDisk image to this new virtual machine. Your event log should be stored on the virtual disk instead of within the write cache.

So now we are using a base vDisk for our image and still allowing persistent data storage. And what's more, you can also use that persistent disk to be the write cache storage location as well. Just tell Provisioning Services to store the write cache on local storage, and the persistent disk will hold that information for the server's session.

My list is now empty, but will post new topics as they come in.  Feel free to tweet me some ideas on Twitter.

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.

By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly.  I'm a little biased, but I think it is a good one.

Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

This best practice was requested by a comment on a previous blog posting. With Provisioning Services, we are able to use a single image for hundreds of XenApp target servers.  Making a change to the image is a big deal because every XenApp server will use the new image after a reboot (of course this is also a huge benefit).  How do we keep control over these images and make sure you don't break your entire environment with a new update?

Truthfully, it is a fairly straight forward process, but just like all processes, you need to follow them if you want things to go smoothly.  High-level process overview is in the following figure:

 
These are all logical systems, meaning that they could be virtual servers, physical servers, different volumes on the same storage infrastructure. The recommended process is as follows:

1. When you have a valid vDisk on your production Provisioning Services server, make a copy of it and store it in your library.  The library is just that, a location where you keep the current and old revisions of vDisk images.  
2. When you need to make an update, copy the vDisk from your library to your test environment Provisioning Services server.  
3. Make your changes in the test environment. When the changes are done, update the revision number and filename of the vDisk. Copy the vDisk back into your library and to the production Provisioning Services server.
4. Tell the production Provisioning Services server to auto-update vDisks.  This is actually a really cool feature. The auto-update process will automatically update the vDisk file of all affected target devices upon next reboot.  How can you tell which target device will be updated?  By the Class information.  Each target device and vDisk file has a Class field.  The class fields are the link for auto-updates.  Provisioning Services will look to see if there are any vDisks with a higher revision number (which there is as we just updated the vDisk and incremented the revision number).  Provisioning Services then checks the Class of the vDisk.  Any target device with the same Class will receive the new vDisk upon next reboot.  This is a great way to simplify the management of your XenApp farms.

Ok, so we updated our XenApp servers with a new vDisk, but what happens if there is a problem with the vDisk updates?  Have you ever installed a hotfix to find out it broke other things? I bet so.  If you followed the process outlined above, you have a build in rollback feature by doing the following:

1. You make a copy of the previous vDisk image from your library to the Production Provisioning Services server.  
2. You increment the revision number on the old vDisk image to a number that is higher than the updated vDisk image.
3. You implement the auto-update feature of Provisioning Services
4. Reboot the XenApp servers

As you can see, the processes for updates and rollbacks are very similar and it works great.  Stay tuned for more best practices regarding Provisioning Services and XenApp.  

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.

By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly.  I'm a little biased, but I think it is a good one. 
Daniel - Sr. Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

Pagefiles, partitions and drives are an interesting combination of items to talk about regarding Provisioning Services and XenApp. Each one will have a direct impact on your environment.  First, let's be clear, Provisioning Services does support many of these items, but when I design a Provisioning Services solution (or any solution for that matter), I'm always reminded of a message a professor told me once.  The professor was a fan of the group KISS and he always wanted you to follow the KISS motto... "Keep It Simple Stupid", but I'll be a little more polite and say "Keep it Short and Simple".  Keeping it simple is how we will design the following items.

Pagefile

The first area deals with the page file.  Before we got into provisioning and virtualization, I would see many people put the page file on a different drive letter than their OS or applications.  At first glance you would think, OK, they want the page file to respond fast. But the page file was only on a different drive letter at the logical layer. At the physical layer, the page file was still on the same physical disk as the other partitions.  So, my question was "Why are you moving the page file? You are causing yourself more work for no benefit."  The same holds true in Provisioning Services.  

The pagefile is undergoing constant modification by the operating system. As physical memory is paged, it is stored in the pagefile. Upon reboot, the contents of the pagefile are not important, and it is overwritten on subsequent startups. In a Provisioning Services environment, the pagefile will be located on the vDisk, but any change made to the file will be recorded in the write cache, because the vDisk image is read-only. Assigning the pagefile to a different partition within the vDisk is not recommended, because there is no speed benefit. You are just causing yourself more work.

 
Multiple Partitions

On the heels of the page file decision is whether to use multiple partitions.  Does this look familiar?  

• One Partition Server
  • Partition 1: Operating System, Pagefile, Applications
• Two Partition Server:
  • Partition 1: Operating System, Pagefile
  • Partition 2: Applications
• Three Partition Server
  • Partition 1: Operating System
  • Partition 2: Applications
  • Partition 3: Pagefile

Provisioning Services can deliver an image with one or two partitions, but not three. Plus, based on the Pagefile section above, there is no gain from having a separate pagefile partition on a provisioned XenApp server as the pagefile changes will be stored in the write cache.
 
Although two partitions are supported, it does increase the complexity of the environment and does not offer any performance benefit to the environment. There is a Citrix article (CTX116698) that explains how to provision a server with multiple partitions, but why go through the hassle.  Keep It Simple.  

 
Drive Remapping

Finally we get to remapping XenApp server drives. Remember, this is when you change the C drive of the XenApp server to the M Drive. D becomes N and so on.  Why would you do this you might ask?  Well, the most common justification for this design consideration was for users to have their client drives mapped within their XenApp sessions as C and D. However, this approach should be re-examined. Remapping server drives is not considered a best practice for XenApp environments because:

• Drive remapping is no longer an option in XenApp 5 running on Windows 2008 Server.
• Giving users access to their local C and D drives within a XenApp session is considered a security risk. If the applications are hosted on the XenApp servers, the data should be in the data center for best application performance.
• It makes the environment more difficult to setup, maintain and troubleshoot
   

 So remember, Keep it Short and Simple (KISS):

• Page file: don't create a special vDisk partition
• Partitions: Use a single partition
• Drive Remapping: Don't do it.  

 
What do you think? Agree or disagree? BTW, we will be revisiting the page file topic again in an upcoming blog when we discuss Local Database Storage.  How does the page file fit with local databases? Well, you will just have to stay tuned.

As always, stay tuned for more best practices regarding Provisioning Services and XenApp.  

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.

Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

As we continue to discuss Provisioning Services best practices for XenApp, I want to talk about a question I hear a lot, especially when people see the value of Provisioning Services and XenApp Application streaming "Should I pre-deploy my streamed applications into the Provisioning Services vDisk?"  If Provisioning Services wasn't in the picture, I would say let the streaming infrastructure manage the application streaming delivery, but Provisioning Services must be taken into account because the act of application streaming has a direct impact on the provisioned server. 

The streamed application is a change to the base vDisk image. These changes are stored within the write cache for each provisioned XenApp server.  Depending on the size of the application, the simple process of delivering an application on top of a Provisioning Services' streamed XenApp server can make the write cache grow by many gigabytes as shown in the following diagram:

Using a provisioned XenApp server will generate the typical swap and temp files, which will be added into the write cache. When a streamed application is requested the first time, the application profile is delivered to the XenApp server from the Application Hub in a compressed format (.CAB files).  The application profile is delivered and then decompressed so it can be utilized. This process adds information to the write cache.
Depending on the write cache option selected, this could have a significant impact on the usability and speed of the XenApp server.  If the write cache size is a concern, then a pre-delivery option exists that will reduce the size of the write cache. This process is shown in the following figure.
In this example, the vDisk image has a pre-delivery of the streamed applications. Users still have to access the applications as before, but the applications are already on the vDisk so the application stream process is complete. This removes the application CAB files and the decompressed application cache from the write cache. This also speeds up the application stream process because the application is already present on the vDisk, although this is a minor concern due to the XenApp servers and Application Hub server residing on the same high-speed network.
The challenge with doing the pre-cache of the streamed application is that each time a streamed application is updated (which could be often), the application cache within vDisk image should also be updated (at least that is the assumption). This adds more steps into the application update process.  But I don't believe every application update requires an update to the application cache on the vDisk, only major updates are a concern. 

For example, if an application has a new patch or a new file update, simply updating the application profile will be adequate.  When a user tries to start the application on a provisioned XenApp server, most of the application cache is correct except for a file or two.  Those two items will be updated from the application hub, and will only slightly increase the size of the write cache. However, if a large update to an application is performed, like adding a service pack to Microsoft Office, then it would be advantageous to refresh the application cache on the vDisk because these updates impact a large percentage of the files in the cache. When the application is executed, all of the updated files will be streamed down and placed in the write cache.

As always, stay tuned for more best practices regarding Provisioning Services and XenApp.  

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.

Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

Here we are again, for another Provisioning Services for XenApp Best Practice.  This best practice focuses on integrating applications into the vDisk image.  Pretty simple Yes or No answer.

But this is one of the major challenges with creating a base XenApp image is determining what to include and what not to include.  Of course, you need the operating system and XenApp and Provisioning Services tools, but beyond that what is recommended and why?  Take the following scenario: due to business reasons, an environment has three sets of XenApp servers hosting different line-of-business applications.  All three line-of-business applications are dependent on Microsoft Excel for viewing and editing integrated spreadsheets.  Should Microsoft Excel be part of the base image or should it be a streamed application?  There answer is... there is no right or wrong answer; it is all dependent on other factors within the environment. Don't you just love answers like that?

The decision to include core applications is oftentimes a result in the belief that the base image should contain the greatest number of items that are common between XenApp servers.  If every server requires the same application, more network bandwidth will be used when the application is streamed to every server as part of the application streaming process.  Also, application streaming, in the default configuration, does not initially start as fast as a previously installed application because the application must be sent across the wire.  Thus, users will experience latency while the application is streamed for the first time (this latency can be overcome with application pre-caching, as explained in the Application Cache section).

There is also a business aspect to this decision. In some organizations, one set of administrators is responsible for applications and another set is responsible for the XenApp configuration. By separating the applications from the base image, the technical solution can align more closely with the organizational structure of the business.

	Base Image Application Inclusion	Base Image Application Exclusion
Benefits	Base image and applications included in a single server role, which will allow for the fastest rebuild and delivery times. * Less network bandwidth is used because the applications are already present in the base image and no additional installations are required.  The complete image can be deployed during off hours so as to not impact availability of the XenApp servers during the day.  * Application startup time is shorter because the application is already part of the image and does not need to be streamed.	With fewer items included in the base image, maintaining the image is easier as only the core operating system and XenApp are provisioned initially.* XenApp base images are managed with one set of tools, and applications and corresponding updates are managed with a different set of tools.  This makes it easier to have multiple administrators responsible for different areas of expertise. * XenApp silos become a thing of the past. A single XenApp server image can be used to deliver any application at anytime.  A single image to maintain for the entire XenApp farm greatly simplifies support
Concerns	Core application versioning changes can impact the base image.  For example, if all servers require the same version of Microsoft Excel, no issues are raised.   However, when individual application upgrades occur, some applications might require Excel 2007 while others require an older version. This would have a profound impact on the contents of the base image. Modifying an application within an image will impact all servers that rely on the image. This might require different levels of change control for applications that are integrated with the base image and applications that are not integrated. More images to maintain, which can make support more difficult, although the number of Provisioning Services images is still far fewer than the number of images required for other server build solutions	Streaming applications will increase network utilization during startup, although this can be mitigated with application pre-caching.  In the default configuration, the first user starting an application will notice a pause before application startup as the application is streamed to the server.  This can be overcome with application pre-caching. Not every application can be streamed. Although XenApp streaming has improved to include more applications, there are some that cannot be streamed because they require special functionality

Regardless of the decision on which applications to include and exclude in the base image, the following are general best practices for the base image:

• All relevant operating system and XenApp hotfixes and service packs should be included in the base image.
• The most common operating system and XenApp configuration should be used for the base image. If 80% of the servers require a specific setting while another 20% do not, the base image should include the special setting.
• The base image should include all appropriate XenApp plugins.  If application streaming will be used, the streaming plugin should be installed as part of the base image.
• Depending on the usage of server certificates, the appropriate root certificate should be part of the base image.  

What do all of you think? Do you install the common applications into the base vDisk, or do you rely on XenApp application streaming? How many unique XenApp images do you have in your environments? 

As always, stay tuned for more best practices regarding Provisioning Services and XenApp.  

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.

Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

We are moving down the best practices road and now we come up to Active Directory.  This, of course, is just a recommendation as I know everyone's AD structure will be different.  But let's start out with a long-standing best practice... XenApp servers have warranted their own organizational unit within Active Directory for organizational and policy enforcement purposes. The recommendation has also included breaking out specific XenApp roles or locations into their own OU.  Each identical group of servers would have the same policies applied. Typically, this creates an Active Directory structure like the following:

 
With the inclusion of Provisioning Services into the XenApp architecture, this recommendation does not change. In fact, this best practice becomes even more important because there will probably be special policy settings specifically for provisioned servers. Depending on how Provisioning Services is integrated with XenApp will help to determine if new OUs are required.

• If the OU contains a set of XenApp servers all provisioned with the same vDisk, then any Provisioning Services related policies can be applied to the entire OU.
• If the OU contains provisioned and non-provisioned XenApp servers, all hosting the same applications, then a new OU should be created that contains only the provisioned XenApp servers.
• If the OU contains provisioned and non-provisioned XenApp servers hosting different applications, then multiple OUs should be created containing only identical servers.

With Provisioning Services, the XenApp OU structure might resemble something like the following:

Each OU contains:

• Similar servers: Applications, infrastructure components, XenApp components
• Similar delivery processes: Provisioned or not provisioned
  

Please comment with your thoughts or if there is another best practices you are wondering about. The list has already grown based on feedback from previous blogs. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus

Daniel - Sr. Architect

Follow me on Twitter: http://www.twitter.com/djfeller

In the previous Provisioning Services with XenApp best practice blog, I spoke about the type of vDisk to use (the feedback was great. So much so that I've added new items for future best practices discussions).   If you are going down the route of using a standard image, you must make another decision. This is probably one of the most commonly asked questions regarding Provisioning Services for XenApp environments, where do I place the write cache?  The goal is to select a location that gives you the best performance without sacrificing other important items like fault tolerance or scalability.  What makes this such a challenging discussion is the number of options we get. 

• Target Device (Physical XenApp or Virtual XenApp) - RAM
• Target Device (Physical XenApp or Virtual XenApp) - Local Storage
• Target Device (Physical XenApp or Virtual XenApp) - Shared Storage
• Provisioning Services - Local Storage
• Provisioning Services - Shared Storage

Each write cache storage option has many different benefits and concerns, especially for the XenApp workload. For most XenApp environments, the best solution will be the one that takes on the following characteristics:

• Fast: XenApp requires a solution that responds quickly as XenApp is maintaining live, interactive user sessions. Any delays in the write cache might be noticeable to the users.
• Dynamic: XenApp servers are delivering many different applications and supporting many different users. Each user and application will have an impact on the write cache. The amount consumed will change day-to-day. The risks of exhausting write cache space would be detrimental to the success of a XenApp environment.
• Available: XenApp servers must be protected from environment failures, because each server is supporting many users simultaneously. The write cache solution selected should be one that does not impact high-availability options from functioning.
  

Target Device - RAM

Definition: The first option for write cache storage location is the target device's RAM. A portion of the target device's RAM is set aside and used for the write cache.

Benefits: The main benefit for using the target device's RAM is it provides the fastest type of write cache.

Concerns:

• A portion of the RAM cannot be used for the server workload. RAM is often better used for XenApp applications or user sessions than for write cache. Plus, using RAM to support the write cache is more expensive than using storage.
• Part of the challenge with using RAM as the write cache storage is determining the amount of RAM required. Provisioning Services can set aside a certain portion of RAM for the write cache, but what happens when the RAM runs out? The write cache is critical to the stable functioning of a provisioned server. When available write cache is exhausted, the server can no longer make changes, which results in a server failure. If the write cache size is not estimated correctly, using a Target Device's RAM might pose detrimental to the stability of the environment.

Target Device - Local Storage

Definition: The second option for write cache storage location is the target device's local storage. This storage could be the physical disk drives on the physical server, or it could be the virtual disk on a virtual server

Benefits:

• This solution does not require additional resources, in that most physical servers being provisioned already have local disks installed and unused.
• Although target device local storage is not as fast as RAM, it still provides fast response times because the read/write to/from the write cache is local, meaning that the requests do not have to cross the network.
• Trying to estimate the size of the write cache is difficult and if done incorrectly, can result in server failure. However, local storage typically provides more than enough space for the write cache, without requiring the administrator to estimate space requirements.

Concerns: If the target device is virtualized, using local storage will prevent live migration processes from succeeding because the storage is not shared across virtual infrastructure servers, like XenServer.

Target Device - Shared Storage

Definition: The third option for write cache storage location is on a shared storage device attached to the target device. This solution is usually only valid for environments virtualizing the target device with a solution like Citrix XenServer. This storage is assigned to each virtual machine from a shared storage repository.

Benefits:

• Although target device shared storage is not as fast as RAM or target device local storage, it still provides fast response times. If the shared storage infrastructure is a SAN or NAS, the reads/writes will still perform adequately because the optimized shared storage infrastructure will help overcome the time added for traversing the network.
• Although the configuration of this solution requires the identification of the shared storage size, the costs associated with over-estimating are not nearly as detrimental as overestimating with RAM. Storage costs are significantly cheaper than RAM so a sizeable buffer over the space estimates is of little concern.
• Because the target device's storage is accessible from multiple virtual machines, virtual server live migration, like XenServer XenMotion, is viable.

Concerns: This solution requires the setup and configuration of a shared storage solution. However, if XenServer is already being utilized, the same shared storage solution can be used for the write cache storage.

Provisioning Services - Local Storage

Definition: The fourth option for write cache storage location is on the Provisioning Services' local storage. This storage uses the physical disks installed within the Provisioning Services.

Benefits: This solution is extremely easy to setup and requires no additional resources or configuration within the environment.

Concerns:

• Requests to/from the write cache must cross the network and be serviced by the Provisioning Services streaming service. Because the write cache is across the network, servicing write cache requests will be slower than the previously mentioned options.
• The streaming service is responsible for sending the appropriate parts of the vDisk to all target devices. Having the write cache on the Provisioning Services server will negatively impact the server's scalability because the streaming service must also service the write cache requests.
• Provisioning Services includes a high-availability option, but in order for this solution to function, all Provisioning Services servers must have access to the vDisk and the target device's write cache. When the write cache is stored on one Provisioning Services server's local storage, this makes it impossible for other Provisioning Services servers to gain access, thus denying the ability to enable Provisioning Services high-availability.
• Although disk space is fairly inexpensive, chances are the Provisioning Services does not have an extensive supply of storage space. With each Provisioning Services server supporting a few hundred target devices, it is quite possible the total write cache could exceed hundreds of gigabytes of storage space. This could result in exhausting all local storage on the Provisioning Services server causing a server failure.

Provisioning Services - Shared Storage

Definition: The fifth option for write cache storage location is on the Provisioning Services server's shared storage. This option utilizes a share storage solution that is connected to the Provisioning Services server.

Benefits:

• The shared storage solution allows for Provisioning Services high-availability as each server can access the vDisks and the write cache.
• Size concerns are mitigated because shared storage devices typically contain significant amounts of storage and can be expanded easily.

Concerns:

• This is one of the slowest solutions because requests to/from the write cache must cross the network and be serviced by the Provisioning Services streaming service. The Provisioning Services server must then forward the write cache requests onto the shared storage, thus resulting in two network hops for the write cache.
• Provisioning Services scalability is impacted as the streaming service is responsible for handling Provisioning Services write cache requests and forwarding them onto the shared storage.
• The solution requires the installation and configuration of a shared storage solution into the environment. If one is already present, then this concern is mitigated.

Best Practice:

Based on the aforementioned criteria and the explanation of the different options for write cache, XenApp servers provisioned with Provisioning Services are best suited for

• Virtual XenApp Server: Target Device - Shared Storage
• Physical XenApp Servers: Target Device - Local Storage
  

Please comment with your thoughts or if there is another best practices you are wondering about. The list has already grown based on feedback from previous blogs. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.
  

Daniel

Follow Daniel's Blog: http://community.citrix.com/blogs/citrite/danielf

Follow Daniel on Twitter: http://www.twitter.com/djfeller

Finally, XenApp server farms are going to be easier to manage. Am I the only one jumping for joy?  As many of you have heard by now, XenApp Platinum is going to include Provisioning Services.  This is an announcement I've been waiting for, for quite a long time.  Provisioning Services is a great secret weapon for maintaining any system, but I'm going to focus on is XenApp.  If you want a great overview of what Provisioning Services will do for you, take a look at Vinny Sosa's blog.  What I want to focus on are the best practices for integrating Provisioning Services for XenApp. 

The first best practice, is one you need to decide very early on in your build-out... What type of vDisk should you use?  Private, Standard or Differential.  Take a look at the three options below:

	Standard Image	Private Image	Differential Image
Description	Each target devices stores vDisk writes in a unique change file that is destroyed upon each target device reboot.	Each target device has a dedicate vDisk image configured in a read/write fashion. All changes are part of the vDisk.	Each target device stores vDisk writes in a unique file that is kept upon subsequent reboots, allowing the server to keep configuration changes, until the base vDisk is modified.
Benefit	Servers revert back to a consistent, optimized and approved state after each reboot Storage requirements are reduced as the write cache is reset after each reboot	Complete personalization of the environment because all changes are stored, but at a cost of storage and support.	Allows for greater levels of system personalization by not discarding system-level changes upon subsequent reboots.
Recommendations	Standard images are a recommended best practice for XenApp servers. XenApp servers delivering the same applications should be: Consistent so users do not experience differences between servers Optimized to allow for the best application response times and processing speed In an approved configuration, especially for industries requiring strict enforcement of standards for certification or compliance.	There is little need for Private Images in a XenApp environment because of the differences each image will take. This will go against the core best practice of consistency.	Differential images are appropriate for a small subset of use cases where users have the need to install their own applications. In a XenApp environment, this is not recommended. Once the base vDisk is modified, the differential image is destroyed and the user must rebuild their personality into the target device.

Standard Image is the way to go.  The benefits are great. They align completely with the best practices for XenApp servers... Consistency.  The standard image is the key to consistency.  But how can a single image be used for multiple XenApp servers? If I install the operating system and XenApp onto a base image and then use the same, exact image to hundreds of servers, aren't there issues with farm membership, especially as each server has the same name? 

This is the really cool thing about Provisioning Services.  Within the console, you define each target device with a name and a MAC address. The MAC address links the defined target device within the Provisioning Services console to the actual physical/virtual server.  Whatever name you enter will become the actual computer name of the streamed server.  The Provisioning Services streaming service inserts this identification information into the stream.  So, Provisioning Services takes care of the computer name, but we still have to deal with XenApp farm membership. 

Included in the base image, along with the operating system and XenApp, is the XenApp Prep Tool.  Immediately before you create your base image, you run the prep tool. This tool does exactly what you think it should do, it prepares the XenApp server for streaming by removing items (local host cache, Resource Manager local database), stopping services (IMA Service, Citrix SMA service) and a whole slew of other things.  The XenApp Prep tool also creates a new service so when the base image is streamed to any target, the XenApp Prep service starts and begins the personalization and integration into the XenApp farm.  It does a whole bunch of things, but of importance is the changing of the STA ID (they have to be different), updates certain registry keys to force the XenApp server to request updates to the local host cache, recreates local XenApp databases, and restarts XenApp services. I've left off a few items, but essentially what happens is when the XenApp services start, they will try to communicate with the XenApp farm.  If the server does not have a presence in the farm yet, it will automatically be added. If the server has a presence, it will simply receive its local host cache from the data store automatically.  If you want to get more information and the XenAppPrep tool, get it from here:

If you want to see it in action, take a look at this video

Please comment if there is another best practice you are wondering about. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:

• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Plus more if we get some good ideas on other areas of focus.
  

Daniel

Follow Daniel's Blog: http://community.citrix.com/blogs/citrite/danielf

Follow Daniel on Twitter: http://www.twitter.com/djfeller

 

By: Vinny Sosa with contributions from Pete Downing

On Monday, February 23rd, Citrix announced the release of XenApp 5 Feature Pack. This release includes a whole slew of features designed to save customers money. In total, XenApp 5 Feature Pack adds over $340 dollars of combined license and subscription advantage value. But one of the most beneficial things we added to our Platinum edition is Provisioning services.

Single Image Server Management

Prior to XenApp 5 Feature Pack, many customers scripted their installs or created multiple server images to help them manage their XenApp hosting server implementation. Scripted installs can be cumbersome to create and they're definitely not for everyone. Plus, they typically do not reduce implementation time, they just automate the process. Now, if you've got application silo's, scripting application installs can also add another layer of complexity on top of the server install automation process. Of course you could also use an ESD solution to get the apps on the server as well, but you get the point - layers of complication that don't really save time or effort.

Creating standardized server images helps address some of the server management issues by giving admins a standardized image to build XenApp servers from. If you're technical, you understand the process of generalizing a server image using such command line tools as "sysprep". This is a great solution for small implementations but with larger environments, application silo's tend to lead to multiple server images that need to be managed. With multiple server images come multiple updates and points of management when anything needs to be changed. This can include something as simple as tweaking an application setting or hotfixing a server. It's these small tweaks and changes that also make it difficult to maintain a scripted install type of solution over the long-term.

Enter XenApp Provisioning services.

Long awaited as a component of XenApp since as far back as I can remember, Provisioning services enables you to PXE-boot your servers from a single, generalized XenApp server image. It's cuts server implementation time because you can bring up a new XenApp server in the time it takes to boot up - no need for an install, no need for additional configuration. If you need to update your server configuration, no problem, and no need to modify an install script. Simply open your standard image, install the Hotfix and reboot your servers - it's that simple.As if that weren't enough, something really cool happens when you bring together the four key technologies included in XenApp 5 Feature Pack - the XenServer virtualization platform, Provisioning services, Load testing and Application streaming. I like to call it just-in-time server provisioning. You might also have heard it referred to as build-to-order server provisioning. Here's how it comes together:

• Create Physical and Virtual Images - Use vDisks to create physical server images and use XenServer to create virtual images for later provisioning. XenServer, now free, lets you virtualize your XenApp hosting servers (workloads). With this you can convert a single physical server with lots of idle capacity into two or more virtual servers that are running at full capacity. Hence, you can always give idle capacity to the users, apps or lines of business that need it most. This is very helpful in cases where server silos might still be necessary, since idle capacity is rampant in these kinds of deployments.
• Benchmark Your Images - Test the performance of your standard server image, both as a virtual server and as a physical server, using Load testing services. This will tell you how many users you can support so that you know exactly how much capacity you are adding or taking away every time you provision or deprovision servers.
• Provision Your Servers - Use Provisioning services to start-up new physical or virtual servers using your standardized server image(s) (the one(s) you already benchmarked with Load testing services).
• Stream Applications - Streaming applications to virtual servers means that you no longer have to maintain multiple server images for your server silos. In fact, it means that server silos are likely a thing of the past in your environment. Let's say you have a user trying to access SAP. You've added new servers because it's quarter-end and you need more capacity. The user get's load balanced to one of your new servers and SAP is automatically streamed to the new server the first time it is accessed. Every subsequent user that accesses SAP on that server will no longer have to stream it again. You've just completely bypassed the need to install applications all together.
• Self-heal Your Environment - Application self-healing is an automated benefit of streamed applications. Basically, if an application is corrupted or starts to misbehave, the next user to access it will start a repair request and it will be fixed for all users on the same server. If you continue to have problems with any of your servers, simply reboot them and Provisioning services delivers a squeaky-clean image in the time it takes to boot up.
• Fail-over Seamlessly and Gracefully - If you need to move your XenApp implementation to a DR site or you need to perform hardware maintenance, you now have two options. You can use XenMotion, included with XenServer for free, to seamlessly move your virtual servers between different physical servers without even shutting them down. You can also use Provisioning services to move physical or virtual servers to a new location or physical server as well.

Essentially, this all adds up to the most dynamic application delivery system on the market today. Want to learn more?. Download the XenAppPrep tool for Provisioning services,at CTX116063. Also, check out Citrix.com/upgradetoxenapp5. Stay tuned for weekly blogs on XenApp 5 Feature Pack. As always, let us know your thoughts, questions and feedback below.

• Part 1: Citrix Releases its own Economic Stimulus Plan with XenApp 5 Feature Pack
• Part 2: Manage your entire server farm from a single image with XenApp 5 Feature Pack
• Part 3: Profile Management, new in XenApp 5 Feature Pack! When does it make sense for your business?
• Part 4: Single Sign-on for any user! New in XenApp 5 Feature Pack! 
• Part 5: XenApp 5 Feature Pack Transforms Server Sizing from an Art to an Exact Science!