Ubuntu 9.10に対するCitrix Linux Clientインストールメモです。

1.  まずクライアントをダウンロードします
   • http://www.citrix.com/English/ss/downloads/details.asp?downloadId=3323&productId=186&c1=sot2755
2. 以下のようにディレクトリを作成します。
   • mkdir /tmp/citrix/
3. ダウンロードしたファイルを上記ディレクトリにコピーします。
4. ファイルを展開します。
   • gzip -d linuxx86-11.0.140395.tar.gz 
   • tar xvf linuxx86-11.0.140395.tar 
5. 以下のようにセットアップコマンドを起動します。
   • sudo ./setupwfc
6. 以下のようにインストーラーの指示に従います。

Citrix Receiver for Linux 11.0 セットアップを行います。

Copyright 1996-2009 Citrix Systems, Inc. All rights reserved.

Citrix、Independent Computing Architecture (ICA)、Program
Neighborhood、MetaFrame、および MetaFrame XP は米国およびその他の国
における Citrix Systems, Inc. の登録商標です。Citrix Receiver、
Citrix XenApp、XenDesktop、Presentation Server、Citrix Access Suite、
および SpeedScreen は、米国およびその他の国における Citrix Systems,
Inc. の商標です。
Microsoft、MS、MS-DOS、Outlook、Windows、Windows NT および BackOffice
は、米国およびその他の国における Microsoft Corporation の登録商標または
商標です。

その他のすべての商標および登録商標は、該当する各社の財産です。


セットアップ オプションを選択してください。:

 1. Citrix Receiver for Linux 11.0 のインストール
 2. Citrix Receiver for Linux 11.0 の削除
 3. Citrix Receiver for Linux 11.0 セットアップの終了

オプション番号を入力してください。 1-3 [1]: 1

Citrix Receiver for Linux をインストールするディレクトリを入力してください。
[デフォルト /usr/lib/ICAClient]
インストールを中止する場合は "quit" を入力してください。:

Citrix Receiver for Linux 11.0 のインストールを選択しました。 /usr/lib/ICAClient.

インストールを続行しますか？ [デフォルト n]: y

CITRIX(R) ライセンス契約書

本コンポーネントの使用については、本コンポーネントと共に使用いただく
Citrix 製品に適用される Citrix ライセンス契約の条件に従います。本コン
ポーネントは、当該使用製品と共に使用いただくためにのみライセンスを許
諾されるものです。

CTX_code EPEUC_T_A42236

オプション番号を選択してください。:

 1. 同意する
 2. 同意しない

オプション番号を入力してください。 1-2 [2]: 1
インストール中 ...

使用可能なディスク容量をチェックしています ...

    使用可能なディスク容量 4898092 K
    必要なディスク容量 6267 K


続行中 ...
ディレクトリの作成 /usr/lib/ICAClient
コア パッケージ ...
ファイル許可を設定中 ...

Web ブラウザと統合中...
Web ブラウザが見つかりました。

統合が完了しました。
Citrix Receiver を KDE および GNOME に統合しますか? [デフォルト y]: y
GStreamer でこのクライアントからのプラグインを使用しますか? [デフォルト y]: y

セットアップ オプションを選択してください。:

 1. Citrix Receiver for Linux 11.0 のインストール
 2. Citrix Receiver for Linux 11.0 の削除
 3. Citrix Receiver for Linux 11.0 セットアップの終了

オプション番号を入力してください。 1-3 [2]: 3
Citrix Receiver for Linux 11.0 のセットアップを終了します。
 

なお、自分のホームディレクトリでインストールファイルを実行しようとすると以下のようなエラーが出力されます。

No target hinst.msg found under /home/masao/ダウンロード for ja_JP.UTF-8
Trying English...
Could not find hinst.msg under /home/masao/ダウンロード for en

One of the most common requests from XenServer customers is for a web interface, so that they can manage their VMs from a browser. I'm pleased to say that I've found one!

Since the last months Citrix and Novell worked closely together to provide a solution for customers with Novell eDirectory in place. For the Desktop Delivery Controller and the Virtual Desktop Agents Citrix announced an official support statement which could be found here: http://support.citrix.com/article/CTX123281

Costumers with a synched Active Directory / eDirectory only have to be aware of their GINA chaining. http://community.citrix.com/display/ocb/2009/05/07/XenDesktop+and+Novell+eDirectory

For environments where no Active Directory is in place Novell Open Enterprise Server with Domain Service for Windows (DSfW) http://tinyurl.com/yze7y65 have to be installed and configured before XenDesktop.
Due the fact, that DSfW only accepts Kerberos and no NTLM calls the XenDesktop Active Directory Wizard should not be used to prepare the OU.

You'll need to configure the DDC and VDA without using an OU:
http://support.citrix.com/article/CTX118976

I've developed a little cool tool to configure both components using a simple GUI.

On the Desktop Delivery Controller:
1.Set Desktop Delivery Controller without AD OU to enabled
2.Press Set DDC Config Button

On the Virtual Desktop Agents (WinXP,Vista, Win7)
1.Enter the FQDN of the DDC(s)
2.Press SET VDA Config Button

For those of you who would like to set the DDC configuration by using ZENworks or Group Policies I've added an ADM Template (FarmControllers.adm) into the Novell Integration Tool folder.

Download: Novell Integration Tool

Note: This tool is not supported by Citrix Support and if you have any issues try to configure the VDA manually using regedit or leave me a blog comment.

Citrix Education is hosting the following 1-hour virtual sessions to scope the next generation of XenServer training:

• For Citrix customers: Tuesday, November 17, 1:00pm Eastern/10:00 Pacific
• For Citrix partners: Wednesday, November 18, 1:00pm Eastern/10:00 Pacific

If you would like to participate in one of these sessions, then email me at mark.carter@citrix.com for registration information. In your email, state whether you are a customer or a partner and what level of XenServer experience you have.

Each session is limited to 5 participants, so don't delay!

Also, feel free to email me if you would like to participate in this discussion but cannot attend one of the scheduled sessions. Citrix Education will look to schedule additional sessions depending on interest and availability of participants.

Thank you for your interest, and we look forward to hearing your input.

Recently several customers and integrators have asked me about the ports used by XenDesktop and whether or not Citrix recommends changing them. Since the ports used by Citrix products are well documented in CTX101810, I will leave that topic alone. However, in this blog I will provide some guidance around the ports you can change, where the change can be made, and whether it is a good idea to do so.  Like any good news story, the information is provided in order of relevance.

Due to the amount of content, I have decided to break this blog into multiple parts, starting with the core XenDesktop farm ports. I will tackle the supporting technologies like Provisioning Services and the XenDesktop Setup Wizard later.

Note:   To make the port number change obvious I have used 5555 in all the screen shots below. Clearly, bad things would happen if you set all the components to the same port value.

Virtual Desktop Agent (VDA)

The VDA communication is actually two one-way communications between the Citrix Desktop Delivery Controller Service running on the Desktop Delivery Controller (DDC) and the Citrix Desktop Service running on the desktop.  The significance of that statement is that the two ports can be set independently and do not have to be the same. To confuse this more, the default for both ports happens to be port 8080 which is the default for the Microsoft Windows Communication Foundation (WCF) services used by XenDesktop. Since port 8080 is used by other services, such as internet proxies or McAfee, I highly recommend changing this port on both sides of the communication.

Desktop Delivery Controller WCF Port

During the install of the DDC, the WCF port for the Citrix Desktop Delivery Controller Service is automatically set to 8080 and cannot be changed. To change the port, wait until after the installation is complete. Unfortunately, you cannot change this directly from the Add/Remove Programs Control Panel. Instead, you need to run the DDCServices.msi package from the installation media. Choose Modify, click Next, and then set the new port number. Click Next then Install to finish the wizard. I recommend rebooting the server after this change. The screen sequence is shown below.

Virtual Desktop Agent WCF Port

Changing the WCF port on the Virtual Desktop Agent side can be done either during the initial install or afterwards using the Add/Remove Programs control panel applet. To change it afterwards, open Add/Remove Programs, choose the "Change" option for the Citrix Virtual Desktop Agent, select Modify, click Next, click Next on the Custom Setup screen, enter the port number and then finish the wizard. The initial sequence looks similar to the DDC install and is shown below. 

Although in the examples above I have set the ports to be the same for both components, this is not a requirement.

Database

For security reasons, many institutions run SQL Server on a port other than 1433. If you are running the database on a different port, you can specify this information either during the setup by selecting the Client Configuration button on the ODBC setup screen and entering the new database port. Below are the screen shots for changing the ports during the installation for SQL Server.

Alternatively, you can directly edit the C:\Program Files\Citrix\Independent Management Architecture\MF20.DSN file that is used by the IMA service. For a SQL server, you would just add the line Address=servername,port to the file.  Restart the Citrix Independent Management Service for the change to take effect. Below is a sample MF20.DSN file where I have specified a different tcp port for the SQL server.

[ODBC]
DRIVER=SQL Server
UID=XDSQL
Trusted_Connection=Yes
DATABASE=XenDesktop
WSID=XDDDC4
APP=Citrix IMA
SERVER=SQLSVR1
Address=SQLSVR1,5555 

Session Reliability

Session reliability is another port that companies often modify to increase security for remote access. Unlike the ICA port number, this port can easily be changed by a setting in the Access Management Console. When session reliability is enabled, the ICA client tunnels its ICA traffic inside the Common Gateway Protocol (CGP) on the session reliability port. The XTE service will then unpack the ICA packets and forward them to the ICA listener port on the server.  If you change the session reliability port, you cannot just stop and restart the IMA and XTE services instead you will need to reboot the server. The session reliability port can be changed in the farm properties as shown in the screen shot below:

Virtualization Infrastructure

Changing the port of the API communications is not recommended.  However, if you have changed the inbound port for the API on VMWare Virtual Center or XenServer, you can configure XenDesktop by specifying the new port number on the location URL for the Access Management Console and the Setup Wizard as shown in the screen shot below.

IMA Ports

Changing the IMA ports (2512/2513) used by the farm for communication is not recommended. The primary reason I do not recommend changing the IMA port numbers is because the vast majority of quality assurance testing is done with the default port numbers. However, if you feel so inclined, you can use the IMAPORT.EXE utility to set the IMA ports for the IMA service and CMC to different values. After running this utility, you will need to restart all the Citrix services or just reboot the server.

XML Service

The XML Service port can be changed on the Desktop Delivery Controller. However, changing the XML service port is not recommended as there have been several reports of strange behaviors after changing it. If you must change the port number, you can use the CTXXMLSS.EXE command-line utility to do so and use the same XML service port for all DDCs in the farm.

That is all I have time for now. I hope to the have the next set of ports for the supporting technologies out by the end of the month. If you found this helpful and would like to be notified of future blogs postings, please follow me on twitter @pwilson98. 

Citrix Support is focused on ensuring Customer and Partner satisfaction with the support of our products. One of our initiatives is to increase the ability of our Partners and Customers to leverage self-service avenues for finding answers and resolving problems. A key area that the Support teams focus on is development of troubleshooting and health checking tools.

Following on from my last post about the Citrix Printing Tool another recently released tool from Citrix Support is the Citrix Quick Launch Tool.

This tool offers a simplified and easy to user interface to connect to any XenApp server or its published applications over the ICA protocol.

You can download the Citrix Printing Tool here.

Also find below a video by the tools developer Frederic Serriere, providing an overview and demo of the Citrix Quick Launch Tool.

David
Twitter - http://twitter.com/citrixreadiness
Citrix Support on Facebook - http://www.facebook.com/citrixsupport

Free, online training course CEV-100-2W Getting Started with Citrix Essentials for Hyper-V, has been updated to include Windows Server 2008 R2 features and enhancements. Updates include:

• Integration with Windows Hyper‐V R2
• Enhanced support and integration with Microsoft's System Center Virtual Machine Manager (SCVMM) 2008
• Site recovery used to protect your virtual machine deployment with a replicated failover site in the event of a catastrophic event
• Improved virtual machine template management, and other ease of use improvements

Get started at http://www.citrix.com/ehvtraining

I got an interesting item in my inbox from a friend who was speaking with VMware about their VDI solution.  He asked me if the information VMware was telling him was true. He was especially curious because he knew I wrote the Citrix XenDesktop Enterprise Designreference architecture that VMware was referencing to talk about how much better View was. VMWare's approach is laughable.  They are taking a detailed consulting design document  and trying to compare it to the VMware View reference architecture, which if you read it like I have (wasted 2 hours of my life), you will quickly see it is high-level and full of marketing spin and provides no insight.  I, on the other hand, was trying to provide all of you in the community with insight into how to design a large, and complex customer environment with XenDesktop.  Anyways, I told him the angle they were using and he thought it was ridiculous.  I was going to leave it at that, but I've been seeing and hearing more about it from others so I thought I would provide all of you with the same information.  Let's break it down: 

Scalability:

• Misconception: VMWare says that XenDesktop has poor hypervisor scalability. They say that on a 16 core server XenDesktop can only support 40 users (3 users per core). 
• Truth: The XenDesktop reference architecture for the hosted virtual desktops is 8 cores, not 16.  In the design phase, we estimated 40-50 VMs per server, which averages to 5-7 virtual desktops per core.  We were a little conservative as we were not sure how the unique applications would impact the system.  But you can look at Project Virtual Reality Check scalability white paper to get a good comparison of XenServer and ESX.  Although the design VMWare references was for XenServer, the same estimates would have been used if the hypervisor was running ESX.

Storage:

• Misconception: VMware likes to say that XenDesktop is a storage pig in that we need a lot of storage associated with each virtual desktop. 
• Truth: This particular design had a requirement to keep a few system items persistent across workstation reboots so we recommended the creation of a local, persistent disk of between 3-5GB to store items like event logs, performance metrics, antivirus definitions, etc.  This is not NAS/SAN storage; it is the storage on the physical XenServer.  Think about it. You buy an 8 core server, install XenServer, which is small, and the rest of the local storage is wasted.  We utilize that for the persistent store of the virtual desktops.  This means we cannot do XenMotion on the virtual desktops, but most customers I've spoken to do not have this requirement.  After looking at VMware's reference architecture I don't see any level of detail as to the amount of storage they require.  I wonder why not. 

Workloads:

• Misconception: VMware states that they can get more users on a hypervisor than we can.
• Truth: This is all around scalability tests, which I'm not a fan of.  I can easily find you 5 tests that show XenServer is better and another 5 that shows ESX is.  The VMware reference architecture had users connected for 14 straight hours, seems like a long workday to me. I have a question for VMWare: What company did you create this architecture for where users would work for 14 hours? Please tell me as I do not want to work there.  As we all know, the most typical system hit is during startup and logon. So by expanding the session time from a few hours to 14, the overall average utilization rates can be significantly lowered, thus providing an inaccurate estimate to the hardware
• Truth: The Citrix Reference Architecture made estimates based on the applications and expected real user workload, not simple apps and 14 hour workdays.  VMware's reference architecture was based on standard scalability samples shown below. If this was an actual user workload, I totally want to work for that company because that job looks so easy:
  • Microsoft Word - Open/minimize/close, write random words/numbers, save modifications.
  • Microsoft Excel - Open/minimize/close, write random numbers, insert/delete columns/rows, copy/paste formulas
  • Etc

RAM:

• Misconception: The amount of RAM that VMware recommends in their reference architecture is nuts.  They say they can get 96 users on a server with 96GB RAM.
• Truth: If you subtract the hypervisor overhead you are looking at "USABLE" RAM of about 800MB per virtual desktop.  I say usable because ESX has probably enabled memory ballooning.  It is true that XenServer does not have memory ballooning, but I would recommend customers disable this feature for virtual desktops.  On XenDesktop projects that use the ESX hypervisor, I also recommend disabling this feature.  Users and desktops are more dynamic than server workloads, meaning the RAM consumption is going to fluctuate greatly.  If RAM starts to decrease to the critical threshold, what happens to the hypervisor?  It must free up memory by paging this to disk.  Isn't this an intensive system process that consumes more resources at a time when resources are scarce?

End Points:

• Misconception: Vmware talks about the end points and only focus on thin clients and end points that we can repurpose with a Linux OS or locked down Windows OS. What about the newer end points that organizations have already spent money on? 

• Truth: With VMware View you still will connect to the VDI desktop and idle your local hardware. Seems like a lot of wasted desktop resources to me.  XenDesktop, on the other hand, allows you to re-use those desktops as a local streamed virtual desktop. Don't be fooled, there is more to desktop virtualization than VDI.

Provision:

• Truth: Closer to the end, the reference architecture talks about the time to provision X number of linked clone desktops.  I'm not sure if this is automated or if an admin has to do each desktop one-by-one. I'll give VMware the benefit of doubt here and say it is automated, but taking 161 minutes (2 1/2 hours) to provision 500 virtual desktops seems long to me.  I personally don't think this metric is important, even though XenDesktop is measured in seconds.  If it is automated, you do all of this in the build out phase and not in production. So the time it takes is irrelevant to me. Why did they choose to include it? No idea

So my advice to anyone who is still reading this blog... Take everything you get with a level of skepticism.  Do your own due diligence and look at the details to see if things were glossed over or if an in-depth analysis and design was completed.  That recommendation even includes the materials I post.  I try to be open and honest in my blogs, white papers, TechTalks and videos, but I am a little biased to Citrix because they pay my bills. 
If you want to discuss more, or have further questions, then Ask the Architect

Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• For the latest desktop virtualization information visit the Ask the Architect - Next-Generation Desktop site
• Questions - Then Ask The Architect

I had the pleasure of attending Gartner's Symposium and IT Expo in Orlando in October. Other than talking to a lot of customers and partners, I took time off between booth hours to attend sessions and I was especially interested in anything labeled "Cloud".
Gartner defines Cloud computing as a style of computing, where elastically scalable IT services are delivered to customers using Internet technologies. This is one definition, and there are nuances between private cloud services (which corporate IT can build inside of companies to be more responsive to business needs) and public cloud services, which will enable companies to rid themselves of IT and consume services from providers - just like manufacturers stopped having their own on-premise power generators and are now consuming power from a utility. As a member of the Citrix Consulting organization, I was curious to see what the thoughts on a transition to the cloud would be. There is a lot of press and talk about the cloud itself at this time and it is not surprising that Gartner sees Cloud Computing on top of the Hype Curve with at least 2 yrs to wider spread adoption. Before that can happen though, we will have to move through the trough of disillusionment, but after we get over the mild hangover, we can talk shop.
Gartner looks primarily at three different types of cloud providers:

• Infrastructure. Think providers of server on storage capacity a la Amazon EC2 and S3.
• Middleware: Think providers of application developer platforms like Google Apps and force.com.
• Applications: Think providers of applications that often run on the Middleware layer, such as salesforce.com, web-based email etc.

The piece that I was missing in the Gartner discussion was the Desktop in the Cloud, or Desktops as a Service (DaaS). Given that the public cloud mantra is still a bit in the future, this is not surprising, but the thought raises some interesting questions.
Unlike moving a few apps playfully to a cloud provider in non-production environment, moving a desktop into a public cloud requires a bit more thought. For one thing, the desktop must deliver the business applications and those apps often times need to talk to databases and file shares to be useful. Companies may actually keep this portion on-premise for the time being, so long as the communication from the cloud back to the datacenter performs reasonably well and can be secured properly. Consulting hint: Test the end to end response time to assess if this is feasible for your specific scenario. Given multiple regulatory questions such as "Who owns the data in the cloud? Who ensures compliance?" I would expect a lot of the backend data to remain in the corporate datacenter initially, even as desktops move to the cloud. Over time, networks will continue to provide ever increasing capacity and reliability, so the application latency introduced by backend resources is probably not necessarily going to be a showstopper.
So, let me go out on a limb and predict the future for Desktop in the Cloud (hosted virtual desktops running on shared infrastructure, accessed by end-user over public networks, used as the primary means to do work):

• Desktop in the Cloud will first be adopted by small businesses or for desktops with a limited number of apps. Host a desktop with a web browser, office productivity software connected to a cloud-hosted web server (or entirely web-based email) and maybe include software such as Quickbooks and you have a repeatable, low cost desktop that can be used from the office or from home for a low monthly charge. Employees use their own personal PC or laptop to access this environment and gone are the days where everyone directs their PC troubles to the guy or gal in the office who happens play video games in the evenings.
• Gartner stated in one session that ISVs will have to become good service providers to prepare for cloud computing. I actually disagree with that statement - it reminds me of the days when software vendors aspired to be ASP's. ISV's will have to provide software and licensing that is conducive to a cloud model. The software licensing will have to change to allow for hosting in the cloud and a subscription-based pricing model. Software and data ownership will need to be figured out and the cloud provider with the most straight forward legal terms will have a leg up.
• Desktops delivering a few critical apps will be next. Think call centers or the healthcare vertical. Those are fairly simple desktop implementations without a lot of application complexity or a requirement to let traveling users connect or work offline.
• Enterprise Desktops (those delivering pretty much any app and connect to a myriad of complex application back-ends) will be the most challenging and probably take the longest to achieve widespread adoption in a cloud model. One can imagine the offline use case being solved by streaming an offline operating system to an endpoint, and some of the emerging file synchronization solutions in the cloud ensuring that all corporate data is properly synchronized between online and offline usage.

One of the items that the industry hasn't figured out yet is a service level agreement (SLA) standard for virtual desktops. We have SLA's for servers and applications, but not for desktops, whose users are a lot less forgiving for latency for basic desktop interactions or the inability to access them. To establish and enforce SLAs for the desktop, end-to-end monitoring solutions are key that allow both the provider and the customer to pull reports on response times and overall system performance.

I remember one additional line from the Gartner Symposium keynote. According to their surveys, some 60% of CEOs believe that IT is constraining their business. What that tells me is that business leaders will need to have more trust in their cloud provider than they have in their own IT. Therefore, I predict that the Desktop as a Service providers of tomorrow will be the large system integrators. They are already trusted by many corporations to run IT end to end and have the expertise and backend capability to deliver hosted services with strong SLAs and security.

Florian Becker
Director, Worldwide Consulting Solutions
Follow me on twitter: @florianbecker

Xen Cloud Platform (XCP) 0.1 is an effort by several community members to create a complete open source virtual infrastructure solution (Hypervisor + Management Toolstack) as a reference architecture for cloud deployments.
This 0.1 release provides a stable platform on which to build, and to provoke community discussion about the final form that XCP 1.0 should take. Developers, testers, and users are all invited to try the XCP 0.1 solution and help drive the community toward the future release of XCP 1.0.

The base platform proposed contains the following features:

• Latest Xen 3.4.1
• Linux 2.6.27 Kernel
• Windows PV Drivers, Microsoft Certified (Binary Only)
• XAPI Enterprise-class Management Tool Stack
  • VM Lifecycle: Live snapshots, checkpoint, migration
  • Resource Pools: Safe live relocation, auto configuration, DR
  • Host Configuration: Flexible storage management, networking, power management
  • Event Tracking: Progress, notification
  • Secure Communication using SSL
  • Upgrade and Patching Capabilities
  • Real-time Performance Monitoring and Alerting
• Basic SR-IOV Support
• CDROM and Network Host Installer
• Full Featured "xe" CLI and web services API

For more information, please visit these sites:

General Product Info - http://www.xen.org/products/cloudxen.html
XCP Roadmap - http://www.xen.org/products/cloud_roadmap.html
User and Developer Support - http://www.xen.org/products/cloud_support.html
Source and Binary Distributions -http://www.xen.org/products/cloud_source.html
XAPI Toolstack Developer Guide - http://wiki.xensource.com/xenwiki/XAPI_Developer_Guide

All questions on the XCP 0.1 release should be directed to these mailing lists:

XAPI Toolstack Questions -xen-api
Developer Questions - xen-develwith XCP in subject line
User Questions -  xen-userswith XCP in subject line

Citrix Support is focused on ensuring Customer and Partner satisfaction with the support of our products. One of our initiatives is to increase the ability of our Partners and Customers to leverage self-service avenues for finding answers and resolving problems. A key area that the Support teams focus on is development of troubleshooting and health checking tools.

One of the most recent tools to come out of Citrix Support is the Citrix Printing Tool.

The Citrix Printing Tool helps configuring and troubleshooting the Citrix Printing subsystem on XenApp, XenApp Online Plugin, and XenDesktop products.

You can download the Citrix Printing Tool here.

Also find below a video by the tools developer Frederic Serriere, providing an overview and demo of the Citrix Printing Tool.

David
Twitter - http://twitter.com/citrixreadiness
Citrix Support on Facebook - http://www.facebook.com/citrixsupport

I wanted to take a moment and provide some thoughts around selecting the correct logoff behavior for your XenDesktop environment. When working with a pooled desktop environment, the administrator can choose between restarting the virtual desktop at logoff and doing nothing.  Below is a screen shot of the two settings I am referring to for a pooled desktop group:

When selecting a logoff behavior, administrators should consider the operating environment since selecting the wrong logoff behavior could have a negative impact on your user experience. In order to see how this could be the case, let's first look at the logoff process and then apply it to a simple customer scenario. Here are the steps executed when "Restart the virtual desktop" is selected for the desktop group and the user logs off:

1. Virtual Desktop Agent notifies the Desktop Delivery Controller of the user logoff event.
2. Desktop Delivery Controller initiates the shutdown and restart via the pool management service.
3. If the DDC contacted is not the farm master then the request is routed through IMA to the farm master and then executed.
4. The farm master sends a desktop shutdown command to the hosting infrastructure. 
5. If the idle pool count is not met the Desktop Delivery Controller then sends a startup command for the desktop to the hosting infrastructure.
6. The desktop boots up, and if streamed from provisioning services anywhere from 90MB (XP) to 220MB (Vista) of data will be sent over during the boot process for the desktop.

When the logoff behavior is set to "Do nothing" the following sequence is executed for each user logoff.

1. Virtual Desktop Agent notifies the Desktop Delivery Controller of the user logoff event.

Probably obvious now is that a significant amount of overhead is avoided by not restarting the desktop each time a user logs off. Now the question for administrators is "when does not restarting the desktop make sense?"  In most situations, restarting the desktop is the best answer. However, there are some situations where restarting the desktop after each logoff will impact the user experience. Consider the following basic XenDesktop configuration:

• 2 Desktop Delivery Controllers
• 500 virtual desktops hosted on 10 servers in a single resource pool
• 2 Provisioning Servers hosting a single Windows Vista vDisk used by all 500 desktops

If the 500 desktops in above example are supporting 1200 users across three shifts (400 desktops per shift) then during a shift change the amount of overhead caused by restarting the desktops could be significant and easily introduce user logon delay. When 400 users logoff in a relatively short time span, say 15-20 minutes, you would end up with 400 desktop boot processes occurring. If we pick the longer 20-minute interval, and assume even distribution (best case), that is 20 desktops per minute that will need to reboot (400 desktops/20 minutes).

If you are using Provisioning server to deliver Windows XP desktops, you have 90MB of data traversing the wire for each of those desktops and considerably more for later desktop operating systems. In addition, some hosting infrastructures have a limitation of how many desktops can be started within a given time period for a single resource pool or server. Furthermore, if the XenDesktop farm master is throttled (usually by a registry setting for performance reasons see the XD Best Practices Guide) and has a limited number of outstanding VM management commands then the 400 restart commands will get queued thus further slowing the end user's response time.

As the number of virtual desktops in the environment increases, the impact of a restart becomes more noticeable. For instance, if we were considering 5,000 desktops across 2 resource pools with the same 3 shifts and 80% utilization, the number of desktops being rebooted in a short time span becomes 4,000. Even splitting this across 2 resource pools would lead to 100 desktops per minute rebooting in each resource pool.

In contrast, setting the desktop group to "Do nothing" provides a much faster response for the users during shift changes and taxes the network and disk infrastructures less. In addition, if the user is routed back to a desktop they have been to before, the user profile update is faster since the entire user profile will not need to be created and loaded.

Of course, like any architecture decision, it has tradeoffs. By not rebooting the workstations at every user logoff, the write cache file for the provisioning services will grow larger than it would if the workstation was rebooted more often. How much larger, really depends on the environment. In addition, if the users are local administrators on the desktops, then user security is at risk because any files left by other users would then be visible to anyone logged on.

In this case, to mitigate the write cache file issue, I would leverage something like Workflow Studio to reboot the 20% of unused desktops in between shift changes. To prevent users from gaining access to left over files, you could not make users local administrators or employ a profile management solution in conjunction with redirected folders to keep the sensitive data stored on remote drives and/or remove the data at logoff.

So, now you have another perspective around designing a XenDesktop farm and something more to consider during your configuration. If you found this posting valuable and would like to be notified of future blogs, please follow me on twitter @pwilson98.
 

VDI is not stupid. Recently, Eric S. Perkins on his blog proclaimed that VDI is Stupid. Well, actually, the way our competitors have been treating VDI is problematic; which might have led to Eric's assertion that VDI is stupid. So, I want to take this opportunity to go over some of his concerns.

One important point on VDI - VDI is not merely another server workload and must not be treated as such. This is perhaps why many of our competitors' VDI implementations have failed and have also created significant costs for their customers. Furthermore, VDI is not for every user in the enterprise - it is best suited for certain environments.

Desktop virtualization, on the other hand, is a more comprehensive solution that encompasses VDI. By separating the three core components of the desktop - OS, apps, and user profile - into three different layers, desktops are managed centrally and dynamically assembled for users regardless of the location and device the users are logging in from. The separation of the three core layers provide tremendous flexibility for IT to manage users desktops.

Citrix has been in the desktop virtualization space for a long time (admittedly we never talked about it as desktop virtualization) and have various forms of it available to our customers. Beyond VDI, Citrix FlexCast allows IT to delivery desktops to all users desktops in different scenarios:

• For task workers sharing a similar set of applications, the most secure, cost-effective approach is Hosted Shared Desktops.
• For office workers who need more personalized desktops, Hosted VM-based VDI Desktops is often the best approach. By running each user's desktop in a dedicated virtual machine, this option combines the benefits of central management with full user personalization.
• For technical workers and power users who run professional graphics applications such as CAD/CAM, GIS; Hosted Blade PC Desktops ensures dedicated processing power for each user.
• Local Streamed Desktops leverage the local processing power of rich clients, while centralizing single-image management of the desktop. This is a quick and cost-effective way for anyone to get started with desktop virtualization by leveraging existing PC resources while keeping datacenter overhead to a minimum.
• Virtual Apps to Installed Desktops offer many of the ROI and management benefits of a fully virtualized desktop with minimal setup costs. Although virtual apps run on the local device, they managed centrally.

Regardless of what type of virtual desktop you pick for your users, user experience is the most important aspect of desktop virtualization. Based on Citrix's 20 years experience working with the end users, we are very sensitive to how users interact with their work environment. So when we created XenDesktop, a huge focus is placed on making the user experience much better than a local PC - with our HDX technology.

With regards to VDI being just another propaganda or niche solution. Gartner estimates by 2013, the desktop virtualization market will be at $65billion. And we are seeing this explosive growth at Citrix. There are real business issues our customers are addressing with desktop virtualization. You can see all these real world testimonials on our website.

Hey, everyone. I have posted a new how-to video on configuring cookie consistency using the Application Firewall feature of Citrix NetScaler.

I based my tutorial on a lab exercise that I took from the recently released CNS-300-21 Advanced Administration for Citrix NetScaler 9.0 Platinum Edition instructor-led training course. Click here if you like the video and are ready to take your NetScaler skills and knowledge to the next level.

Administrators are used to the idea, that running applications under Application Streaming will permit poorly written applications to run in a multi-user terminal services environment.   For example, if the application wants to write to the \Windows directory, no problem; the application will believe that it wrote there and later if it reads the same stuff, it will see what it put there and generally, the application will work. What is less known is that that Application Streaming and XenApp publishing can be used to reduce the rights of the application at execution so that it has a reduced chance of hurting the machine.

Privilege vs. Isolation

Isolation and "privilege" are different things. Running the application "isolated" does not mean that the application can't do powerful things.   An administrator privilege ISOLATED application CAN still perform privileged operations such as adding new users to the machine, marking them as administrators and adding them to the remote desktop group where the evil doer can then remotely login, as a non-isolated administrator and easily do evil things. 

Not a problem for XenApp hosted execution

To be clear, none of this is important for XenApp hosted execution.  Here, the user is already a user and stripping power from the user to get them to user power is a "nop" because they were a "user" to start with.  This discussion of "privilege" reduction is more of a Windows XP client side, or hosted desktop statement where "admin" power users are the norm.   On Windows XP, unless you're very good at locking down the machine the end user will be running as an "Administrator" and this is not desired.  How can you make this happen as little as possible?  How can you get MOST of the applications to run with the least privilege possible?

Brain damaged applications

Some applications even CHECK to see if they are admins and refuse to run if they are not.   Awesome!  If you can't figure out how to code it, demand admin rights machine wide!    You can easily hit a situation where 90% of your desktop applications will run fine without admin rights, yet you have no choice but to make the user a full blown administrator because some small subset of the applications demand admin rights; or perhaps, even really need them.

What about the "normal" applications that don't need admin rights, or at least don't need admin rights when run under isolation?  It would sure help if we could at least make the "all powerful" user be a "lowly user" for the purposes of the majority of application execution, even if the user is really an administrator.  You can, and XenApp makes this easy.  First, some history.

DropMyRigthts

Go back in time and take a look at this 2006 technet article from Microsoft on Least User Access and a description of the DropMyRights utility by Michael Howard.   Excellent stuff and here is a related set of blogs from Aaron Margolis of Microsoft who seems to have a passion for running apps as a user!   The output of this early work was a command line utility called DropMyRights which would duplicate the user's logon token, strip the powerful rights - and then use the modified token to launch the application.  Good stuff.  As an example, here is the .BAT file I used to use to launch MS Outlook.

• dropmyrights "%PROGFILES%\Microsoft Office\OFFICE11\OUTLOOK.EXE"

The idea of running apps on forced user privilege on Windows XP was not unique to App Streaming, but we did wrap pretty GUI around it and wrapped application publishing around it to make it easy to use - and then we didn't tell anyone it was there.  To be fair, most of the usage was server side, so it wasn't as important, but hosted desktops are changing this.

The XenApp publishing system makes this dropping of user rights accessible via easy to use GUI.

Access Management Console

Here's the AMC screen that controls this setting.  Notice that this "stripping of rights" is controlled in the AMC - not in the streaming profiler.  Could it be controlled in the profiler?   Sure.  Both of these tools are nice GUIs which could accomplish the same goal, so yes, it could be controlled in the profiler, but it isn't.  One could even make a really good argument that it is in the wrong place and SHOULD be in the profiler because this is where the admin is that knows more about the application.  I would agree, but it wouldn't matter, it's still in the publishing console whether or not this seems like the right place.  

 
When I wrote the draft for this post, I did it in a place without internet access, so I couldn't easily check the default.  I wrote that SURELY! the default is that we strip the rights before launching the app.  Surely, Shirley, what ever you call it, the default is the other way; by default, the launch leaves the user's token alone and launches the app using what ever power the user has according to logon.  If you CHECK the box, then the Access Management Console tells the Citrix IMA to tell the Citrix Web Interface to tell PNAgent to tell the Streaming Client that it should strip power from the user for the purposes of running this stream to client application.  Where the application will permit it, You should set the checkbox.

XenApp server side, it won't change anything;XenApp Client side, it will ensure that the application is launched using a user token that has "lower power".  Lower power is better...

Here are some other writings on Application Streaming related to this:

•  Enhancing the Security of Application Streamingfor Desktops

Enjoy!

Joe Nord

Citrix Systems Product Architect - Application Streaming

先週はITPro EXPO 2009のCitrixブースにご来場いただきありがとうございました。また関係各位にご協力いただき大変感謝しております。なお、同イベントにおいてXenDesktop 4がITPro EXPO Award 2009のZDNet Japan賞に選ばれました。スタッフのみなさんで徹夜して準備した甲斐がありました。

http://itpro.nikkeibp.co.jp/article/NEWS/20091030/339835/?ST=keitai

The Citrix Workflow Studio Evaluation Virtual Appliance (EVA) is now available. This EVA provides you with 30 days to evaluate a pre-configured virtual machine running Windows Server 2008 that has Workflow Studio 2.0 already installed and configured with all activity libraries and the sample workflows from CDN. Download the EVA and review the Getting Started guide .

If you have any questions leave a comment or contact me directly

While a mandatory based profile solution was the original approach (something we leveraged in the earliest releases), we are not going to return to that method. Let me explain why and get your thoughts and opinions on this.

One request that has been commonly voiced has been around a mandatory style implementation. While previously we had leveraged a mandatory profile as the base, for many reasons we moved away from that approach. One key reason was to save time that the merging process required (the copying of the mandatory down first and then copying of all the net changes). All in the spirit of logon speed. Another key reason is that it really was not a mandatory profile anymore. Profile management captured all the net changes from that base mandatory. So no settings were enforced or re-written at next logon. Basically it was a holder of starting settings when a profile was loaded. But the net changes were always re-applied over the base so nothing was ever enforced. So in the end, you needed to leverage Group Policy to enforce any permanent settings anyway.

It's also been explained that having a mandatory approach enables customers without Group Policy delegation to have a means to control the profile settings. And mandatory by itself is a great solution albeit the limitations on the breadth of personalization - which the amount of personalization afforded by a mandatory solution is probably adequate for many scenarios. While you can redirect folders like My Documents, Favorites, Cookies and others, the ability to change anything registry related is prevented e.g. wallpapers, application configurations and such. But if you try to combine this with something like Profile management to enable those changes, how are you going to restrict what does not get saved? You would need to create an exclusion list of all the settings you want enforced (and thus excluded from being saved). Doable on a few settings but it will get unwieldy really fast. And I am willing to bet it's going to be harder than Group Policy to manage before long. In the end, it seems capturing all the settings and using Group Policy to enforce setting as required is the way to go and thus the direction for our profile management solution.

Finally, let's address the capability of having a base profile to start with. We do offer a template profile capability which you could think of as a Global Default User profile. When a user logs onto Windows and does not have an existing profile (be it local, mandatory, roaming or TS), Windows creates a new profile for that user based on the Default User profile located on that current machine. The fun of this is unless you want to sync all the Default User profiles across all the machines a user might likely log onto for the first time, the starting profile will different (although often only slightly) from user to user. Might not be a big deal initially or on smaller scales, but will be more problematic as your environment expands and grows.

The purpose of the template profile is to enable a consistence starting point for a new profile being created no matter the machine. The template profile can leverage a copy of the mandatory profile you use today but you just need to rename the NTUSER.MAN back to NTUSER.DAT (so no you can't use the same one as both the template and a mandatory). And the template profile has to be complete (e.g. the entire directory structure and NTUSER.DAT). Also keep in mind that this is used for profile creation. So changing the template is fine, but only affects new profile being created and not existing ones. Need to change or enforce a setting for all users? Then we are back to using Group Policy for those situations.

So that is where we stand today with our Profile management feature (a feature of both XenApp (Enterprise and Platinum) and XenDesktop (Advanced, Enterprise and Platinum). Of course this is always open to debate and discussion if you have scenarios that illustrate weaknesses to this approach that Citrix should pay more attention to addressing.

DABCC will be hosting a webinar Nov 4, 2009 on Web Interface customization leveraging Extentrix Web Optimizer ... details here: http://www.dabcc.com/media.aspx?id=647

You can register through the above link. Key topics covered:

– Make your Web Interface "look and feel" consistent with your corporate and intranet web sites
– Quickly add custom graphics and themes
– Simple and easy to use interface and available quick start templates get you up and running quickly
– Unrivaled support for mobile devices

Have you ever wanted to take a peek inside a training manual before registering for an instructor-led training course? You now have the opportunity with the our new Courseware Peek Inside online feature. This feature is currently available for the new CNS-300 Advanced Administration for Citrix Netscaler 9.0 Platinum Edition. Click here to check it out, and stay tuned as we roll this feature out for our other instructor-led training courses!