Blog posts tagged with 'xendesktop'

I spent most of the week before last at Synergy in Houston, co-presenting a breakout session on XenDesktop architecture, and in a number of customer and partner meetings. Most of the time, however, I demo-ed XenDesktop to the public in the technology lab - or at least, that was the plan.

In reality, a lot of the time I actually ended up using pen and paper to sketch out XenDesktop, and how the various components that make up this product work together to deliver an end-to-end desktop virtualization story. Once the basic ideas behind XenDesktop got across, it was a lot easier to walk through the UI and demo the product. The other Citrites at the XenDesktop booths had exactly the same experience of typically setting up the scene before delving into details.

So I thought I'd try recording what I did in Houston as a little video - it's a bit rough round the edges, and it doesn't cover the full gamut of what XenDesktop can do (it doesn't talk about how you can assign individual virtual desktops to users, for instance), but it'll help explain some of the principles and ideas behind XenDesktop, and perhaps also shows where and how it differs from other VDI solutions.

PS: Sorry for my handwriting - it's never been very good...
PPS: XenDesktop (including the free Express edition) is now available for download from mycitrix.com

If you have followed the discussions in the XenDesktop forums, or - even better - if you've tried the beta version of XenDesktop, you'll be aware that it integrates with Active Directory. Indeed, in particular the Desktop Delivery Controller (DDC - the component responsible for brokering end users to their virtual desktops) has a strong dependency on AD, and stores some data in AD that relates to security and determines how virtual desktops discover and communicate with desktop delivery controllers. Several questions have come up on this integration, and on what is actually stored in Active Directory. This post will show in more detail what's going on under the covers. Just a note of caution: the information in this post reflects the beta release of XenDesktop; however we're not expecting major changes in this area in the final release.

When you install a DDC server, an "AD set-up wizard" will start towards the end of the installation. When you install the first DDC in a farm, the wizard will ask you for the location of an OU, and will populate it with the data that XenDesktop needs to link up virtual desktops and DDCs, and to secure their communication paths. Whenever you install an additional DDC or remove one, the wizard will also start, and add or remove the DDC-specific information from that OU, although you won't typically see this, because it happens without the wizard GUI actually popping up. You can also run the wizard manually at any time, it's installed in the start menu on a DDC, and you can also run it from the command line (c:\program files\citrix\xendesktop server\adsetup.exe; use the 'rungui' option to start the GUI wizard).

When the wizard is running for the first time, it asks you to choose an OU for that farm, as shown in the previous screen shot. Every DDC farm needs a separate OU. The OU can be at an arbitrary level of a domain, and the OU does not need to contain the computer accounts for either the virtual desktops or the DDC servers (although it'd be best practice for the DDC servers to live in the farm's OU). If the user running the wizard has sufficient privileges, they can choose to create a new OU (tick the check box in the wizard). Alternatively, a domain administrator can pre-create an empty OU, and give the XenDesktop administrator running the wizard sufficient delegated privileges over that OU (you'll need 'create child' permissions). In that case, you should select that empty OU in the wizard by using the AD browser, as shown in the example above.

Now let's look at the data that shows up in the OU after the wizard has completed. The following screen shot shows that the OU contains one security group, one service connection point (SCP), and a container that contains another service connection point object:

The 'Controllers' security group is used by virtual desktops to ensure that only authorized DDCs that are members of the farm can broker and control connections (I'll explain how virtual desktops figure out where to find this security group in a moment). Whenever a DDC invokes one of the web services implemented by the virtual desktop, the VDA (Virtual Desktop Agent, the XenDesktop component that you install on a virtual desktop) will check that the caller is a member of this security group. When you add DDCs in the AD set-up wizard, as shown in the following screen shot, one of the things it does is to add the computer account for the DDC into this security group. Because the OS service that invokes web services on the VDA runs using the NetworkService predefined account on the DDC, the VDA will see incoming calls as using the DDC's computer account. You need to exercise caution in which computer accounts are made a member of this group, because all VDAs in your farm will trust these computers to control them.

Next, the farm's OU contains a 'Farm SCP'. This is an object that contains some markers in the keyword attribute, which define the enclosing OU to be a XenDesktop OU. The keywords include a couple of GUIDs as well as the name of the farm prefixed by XDFarm:, as shown in the following screen shot.

By virtue of being a marker, the farm SCP allows the VDA installer to present a list of farms that the virtual desktop can join: when the installer runs, it searches the global catalog for all SCPs that contain the XenDesktop GUID in their keywords, and lets the user select one of the farms. This results in a registry entry being written to the registry on the VDA, as shown in the following screen shot. The FarmGUID contains the AD GUID of the OU that contains the farm SCP chosen in the installer (i.e. the OU's objectGUID attribute). You can also set this after installing the VDA, and we'll provide a group policy template that you can use to set an equivalent registry entry through policies.

If you need to find this GUID, it's also displayed in the farm's read-only properties in the AMC, as shown below:

The final piece of information stored in the farm's OU lives in a separate 'RegistrationServices' container. This contains one SCP object per DDC in the farm, and the SCP object's name is the GUID of the computer object in AD that represents the DDC (in my example, my server called ddc.martinm.local is represented by the DDC$ object in the Computers container, and that object's objectGUID attribute contains the value 84d879b8-...). This is the second piece of data that the AD set-up wizard writes to the OU when a new DDC is added. The SCP again contains a number of GUIDs and other information in its keywords attribute that mark it as a XenDesktop server SCP; this is similar to the farm SCP. In addition, it also contains the URL and binding information of a 'registration' web service that runs on every DDC, and which VDAs use to register themselves with the farm. The AD set-up wizard creates the SCP for each DDC and gives each DDC write access to its SCP. Every time the DDC starts it validates that the information in the SCP is still accurate, and updates it if necessary (e.g. if you change the TCP port used by the DDC).

Using this information, a VDA on a virtual desktop gets linked into the farm as follows: the VDA starts up, reads the farm OU GUID from its registry. It then attempts to bind to AD through LDAP, and checks that the OU is indeed a valid XenDesktop farm OU (by checking the farm SCP). It then enumerates all registration service SCPs by querying AD for all SCPs with the right keywords (GUIDs), scoped by the farm's OU. Finally, it reads the registration web service address from the SCPs it finds. This way, it ends up with a list of web services that it can invoke to register with a farm. If the server it is registered with fails, it can simply pick another one.

Finally, here's a list of other AD-related information that's relevant for XenDesktop:

• You don't have to use the AD set-up wizard. If you want to, you can create all the objects in the farm's OU manually, e.g. through tools such as AD explorer. However, you should be careful to get the keywords in the SCPs right (all GUIDs are constant, but the farm name must be correct), and you need to be careful with who has permissions to change these objects, as mentioned above.
• While the farm OU, computer accounts, and user accounts can all live in different AD domains, all these domains must be in the same AD forest - VDAs and DDCs must be able to resolve each other's identity (Windows Communication Foundation uses Kerberos to authenticate machines), and of course end users must be able to log on. You must also run the AMC on a machine that is a member of a domain that is trusted by the AD domains containing the computer and user accounts (or run it with a user account that is trusted), otherwise it will not be able to resolve user and computer names and you'll end up with SIDs displayed instead. 
• XenDesktop supports all AD functional levels. However, if you're running in Windows 2000 mixed mode, restrictions on the scope of security groups mean that the farm OU and the DDC computer accounts must be in the same domain (as pointed out above, it'd be best practice to put the DDC computer accounts into the farm OU anyway).
• The names of the objects in the XenDesktop farm OU are hardcoded and cannot be changed. We have found that some AD environments have very strict policies as to where objects, in particular security groups, can be located and how they are named. If the 'Controllers' security group is not suitable in your environment, you can use an arbitrary security group located anywhere in your forest instead. To do this, you must create this group according to your AD policies, populate it with the computer accounts of the DDCs in your farm, and then set the following registry entry on all the VDAs in your farm: the key HLKM\Software\Citrix\ADConfig needs to contain a string value called ServersGroupGuid, and the contents of this value must match the objectGUID attribute of the custom security group (without curly brackets). You can also set this registry entry on the DDC servers, before installing the DDC software: if you do so, the AD set-up wizard will add and remove the DDC computer accounts from the right (i.e. your custom) security group automatically.
• For mutual machine authentication through Kerberos to work, the DDC and VDAs must be able to resolve each other's DNS names; also, Kerberos is quite picky and you'll encounter authentication errors if there's a significant clock skew between the machines (the default settings allow the clocks to drift by up to 5 minutes).
• If you run your virtual desktops as VMs and suspend them for prolonged periods of time, they may get out of sync with computer password changes made by the domain controller. There are a range of Microsoft KB articles on this topic which you may want to check out (be aware of the associated security risks, though). The good news here is that if you use Provisioning Server, it can take over AD computer account management for you, so you don't have to worry about this.

It's been a long long time since my last post, and much has happened since then in the desktop virtualization space, both for Citrix and in the wider industry. At the time of my last posting (December 2006, no less!) we were seeing the first attempts to virtualize Windows-based desktops, using home-grown and relatively simple "brokers". Typically, they would use straight-forward one-to-one mappings between end users and their virtual desktop, perhaps based on the user's login identity and their virtual desktop's IP address.

Since then, we have made great strides to deliver more sophisticated solutions for desktop virtualization, and a first batch of products have been released from vendors such as VMware (VDM, courtesy of their acquisition of Propero), Quest (via ProvisionNetworks), Leostream, and others (there's a good overview available from it2.0). And of course we delivered Desktop Server 1.0 last year, and have now just made a beta version of XenDesktop 2.0 available for download.

A great deal has happened here beyond the obvious name change, and our vision for this product has undergone major shifts over the past year or so. I'd like to use this post to bring you up to speed on how XenDesktop differs from Desktop Server and also many of the other desktop virtualization products.

First and foremost, while Desktop Server 1.0 was a broker that mapped end users to virtual desktops, XenDesktop provides a much more comprehensive approach to delivering desktops. A broker by itself is all very well. It allows you to migrate desktops into the data center, with all the benefits this brings in terms of preventing data loss (remember all those news stories about stolen laptops and hard drives and optical discs getting lost in the post?), reducing downtime, and gaining visibility and manageability - provided you have appropriate tools and processes in place to manage the sprawl of what will typically be VMs that host your virtual desktops.

Of course a desktop virtualization strategy can also introduce new headaches. For instance, you need to think hard about what moving your end users' desktops into the data center means for the security of other assets in the data center - you'll probably want to consider a strategy that fences off virtual desktops from other services and data hosted in the data center. More than that, though, moving desktops into the data center by itself doesn't solve some of the big management problems - you still need to worry about image management, patches, anti-virus, and on top of that you have to keep an eye on the health of the desktop virtualization infrastructure, whether this be XenServer, VMware, blade PCs, or other desktop hosting technologies. Finally, all the images for your virtual desktops need to be stored somewhere, and with multi-GB disk images, this quickly adds up to a substantial storage cost.

XenDesktop includes technology that will help you to tackle these complications, and help you get a long way towards reaping the promised benefits of desktop virtualization (well, that's my sincere hope anyway). Here's how we envisage a successful desktop virtualization strategy to play out:

1. Lock down your end user's endpoint devices, or better yet, replace them by Desktop Appliances (the new term for thin clients that are specifically designed to take advantage of desktop virtualization). This minimizes the maintenance overhead and reduces the risk of end users misconfiguring or otherwise breaking their devices. We've designed XenDesktop's end-user UI so that this step becomes as painless as possible for end users: after switching on their device, end users enter their credentials and XenDesktop takes over, connecting them straight to their virtual desktop. Depending on your deployment, this uses a combination of Web Interface and Program Neighborhood Agent technology under the covers, but this is entirely transparent to end users.
2. Take advantage of the migration to centrally hosted desktops and consolidate and rationalize the OS images for your end users. Ideally, you should end up with a small number of "golden images" that contain only the base operating system, as well as perhaps a few universal applications that all your users need, e.g. a standard browser or email client. The idea here is to separate the base OS from applications and user data, and hence make it an entity that can be maintained and managed independently and separately, and hence more effectively. Citrix Provisioning Server (also known as PVS - you may be familiar with it under its previous label of "Ardence") provides the required technology here, and is conveniently included in XenDesktop.
3. PVS is used to create and store golden images, which are then shared among VMs, or even blade PCs. In other words, if you have 100 users all using the same base OS, you only need to store the image on disk once and PVS will stream it to the VMs hosting your virtual desktops, on demand. The VMs (or blade PCs) themselves can be entirely diskless, and this can add up to a tremendous saving in storage cost. What's more, PVS makes managing golden images is made a lot easier as well: if you need to patch your base OS with the latest service pack, you only do this to the golden image. Restarting the VMs suffices to apply the new image across the board. And if the service pack update goes wrong - no problem, it's trivial to switch back to the previous version of the image. PVS and XenDesktop will also automate the management of AD computer accounts, hence there's no need for sysprep or other tools, and adding a new virtual desktop is done in seconds: create a new diskless VM, add it to PVS' client list, and let PVS manage the new desktop's AD account.
4. So now you have a very manageable environment that you can use to deliver generic desktops based on golden OS images to your end users. But your end users will need applications to carry out their daily work (remember, don't include too many apps into the base OS image, because then you need to manipulate that image every time you need to change or update one of these apps). This is where application streaming or "client side virtualization" comes into play; I've briefly touched upon this in my previous post: using XenApp technology, you can deliver applications transparently to your end users, without having to touch or "pollute" the golden image. This allows you to get away with a small number of golden images, even if your users have differing needs with respect to the applications they access: just let XenApp (or alternative technologies) deliver applications to users based on demand.
5. Finally, users also need to store data and configuration or personalization settings. Again, these must be separated from the base OS and also the applications, in order to make the entire system manageable and effective. Right now, you'll have to use off-the-shelf solutions like Windows roaming profiles to store and manage data and settings separately, but naturally we recognize this as a gap and are working towards offering a solution that's integrated with XenDesktop in the not too distant future.

To recap, XenDesktop has evolved significantly from a broker into a fully fledged desktop virtualization solution that combines a broker, ICA's high-performance remoting protocol (courtesy of PortICA), virtualization infrastructure (and before you ask: yes, XenDesktop works well with a VMware and Microsoft virtualization infrastructure as well, although of course we'd prefer you to use the XenServer technology that's included in XenDesktop), image management and OS streaming, a set-up tool for wizard-driven provisioning of diskless VMs with OS streaming, and more. If you want to dig deeper, check out the official XenDesktop product site where you can also download the beta, and join the discussion forums for support.

For my next post I'm planning to go a bit more technical and describe one of the areas that has generated many questions for the beta: how XenDesktop works with AD.

If you have followed recent Citrix announcements and a number of blogs and other postings, you probably already know that we are working on a product line in the Desktop Infrastructure (VDI) space, codenamed Trinity (by the way, Dynamic Desktop Initiative or DDI, is Citrix name for VDI). As the product architect assigned to Trinity, I intend to post here occasionally to keep you up to date on our plans and progress. As always with this type of blog, please note that much of this information is about work in progress, and I certainly cannot commit to dates or promise that certain features will make it into a final product.

With that out of the way, I would like to devote this first post to a brief overview of where and how Trinity originated, and then talk about the first couple of deliverables in the Trinity product line. Some topics I had in mind for future postings include thoughts and impressions from VMworld 2006, which I attended last month, my view on where we are as an industry with VDI, and a more detailed dissection of the various types of virtualization that are part of, or relate to Trinity. Do let me know if there are any topics you are particularly interested in, and I will try to cover them if I can.

Trinity did not just start out of the blue recently at Citrix; in some form or fashion, its roots reach all the way back to 2003, when product idea #408, on demand access to desktops was submitted. In fact it is quite likely that ideas in this area had been floating around well before that submission. The gist of that product idea pretty much covers what subsequently became known as VDI. Oh, and by the way, we are up to product idea #2098 in the meantime.

In any case, some initial investigation efforts were kicked off in our Products group, and I remember a presentation that Richard Mazzaferri and Anatoliy Panasyuk gave to the UK engineering team, outlining the concepts of brokered access to virtual desktops. This sparked quite a few I like one of them, please comments from our development team.

I do not have much visibility on what happened subsequently, except that there was never really any resource available to work on it in more detail, until things started to bubble up again early this year, which was also when Trinity was coined as a project name. After a more detailed architecture and design had been worked out, there was a bit of to-and-from between the various engineering sites in Citrix, until eventually we ended up with engineering resource being provided in both the Sydney and the Chalfont sites.

Now to complicate matters a bit, there is a second strand to the Trinity lineage, which has also been going for some time, originating from the project Dart (which was never released but influenced a number of other Citrix products such as Access Essentials, or the Access Management Console but I digress). After several iterations, this culminated in the Remote Desktop Broker (RDB) for Presentation Server, which was released earlier this year as the first Citrix DDI deliverable. You can read all about RDB in a FAQ on the Citrix web site, but in a nutshell it allows you to publish an RDP proxy component on a Presentation Server, which will route the connecting user to their virtual desktop based on a configuration of virtual desktop pools that an administrator controls through a management GUI.

All this begs the question, how all these things fit together, and what we are planning for the next couple of Trinity releases. Assuming that you have a basic understanding of Remote Desktop Broker, this can be summarized as:

We target a first release of Trinity for the first half of next year, based on Remote Desktop Broker that you have already seen. It will build on the existing combination of CPS + RDB but re-engineered to deliver an integrated product and improve the administrative experience by delivering consistent access to both shared and dedicated desktops. Maybe a word about nomenclature here: shared desktops are what you are already used to from CPS published desktop feature, while dedicated desktops are single-user OSes, whether they run on physical hardware or as a virtual machine image. Terminology hasn't been finalized yet, though. We are also working on a simpler licensing scheme for this release of Trinity, but details are still being finalized.

In the meantime, we are working on the second release, which is currently slated for release in the second half of next year. This is when we will integrate PortICA, and thus deliver the benefits of ICA that can get lost in RDB double-hop solution. While the ICA stack for dedicated desktops will certainly be big news for this release, we are also planning to take advantage of the server-side infrastructure that we built for Presentation Server to bring you an integrated, seamless experience for both administrators and end users. Our goal is to make it as simple as possible for end users to access their desktop, building upon the existing application delivery infrastructure, i.e. Web Interface, PNAgent and the like. On the other hand, administrators will be able to benefit from the same tools and features that they are used to from Presentation Server.

So much for the marketing piece - I'll flesh out our current plans for the second Trinity release in a bit more technical detail in a future post, but until then I be interested to hear your views on Trinity, VDI, DDI, RDB, or any other three-letter acronym.

Note: I hand-edited this post since it seems to have been badly garbled during the transition to our new blogging platform. I haven't materially altered its content though (although some parts of it are now a bit out of date).

In a previous article, I claimed that DDI (the Dynamic Desktop Initiative) is Citrix' version of VDI (Virtual Desktop Infrastructure). A few people have rightly pointed out that this is not entirely true, and I want to spend a few moments to clarify how the DDI vision differs from VDI. I hope that this will also explain the relationship between Trinity and few forms of that are currently in circulation.

The major difference between DDI and VDI should be clear from the choice of terms and acronyms: while virtualization clearly plays a big role in VDI, the more generic term is used DDI. This highlights that we envisage Trinity to be a generic desktop brokering solution that is not intimately tied to a particular virtualization solution to deliver desktops as virtual machines. More specifically, VDI is of course a VMware term, hence in a strict sense a VDI solution would require desktops to execute on top of VMware Virtual Infrastructure. However, it is straightforward to generalise the concept other virtualization vendors such as Microsoft or XenSource.

Back in Trinity land however, there is no dependency on VMware or any other virtualization vendor. Instead, Trinity operates on desktops, or workstations as we prefer to call them, regardless of the underlying execution environment. Hence Trinity can just as well broker access to a rack of physical blade machines hosted in the data center, each running its own copy of the OS, or even to the PC under your desk, should the Trinity administrator decide to make it available through the broker. (If you thinking that this strays into GoToMyPC territory then you are not far off, although of course Trinity is an in-house deployment and not a service offering like the GoTo family of products.) Lastly, Trinity also offers access to a published server desktop using traditional CPS functionality as explained in my previous post. We are currently working on the right terminology to differentiate these types of desktops, and to highlight their differences in terms of and typical use cases; once this has settled down a bit, I share it on this site.

So, to come back to virtualization, and its relationship to Trinity; maybe it is best to approach this by differentiating the various types of virtualization. Unfortunately, there seem to be nearly as many definitions of virtualization around as there are vendors in the space. I try to stick to the Citrix view of virtualization here:

• Application virtualization is our term for the type of remote access offered through CPS and similar solutions (confusingly, I have also seen this referred to as desktop virtualization). Trinity complements this type of virtualization nicely: while Trinity can broker access to, and deliver a desktop, the apps that you run on the desktop may very well be delivered as virtualized applications from a remote server. Consider a typical Citrix-internal use case scenario: enterprise applications such as SAP and tools for tracking product defects are delivered through our in-house CPS farms. There is no reason why you cannot do exactly the same thing if your primary desktop has been delivered through Trinity. In fact, we are starting to investigate how we can improve the performance of virtualized application delivery in this ICA double-hop or pass-through environment.
• I have also heard application streaming - as per Citrix Tarpon or Microsoft SoftGrid - referred to as application virtualization. Regardless of terminology, again there is a fit with Trinity, since application streaming can be the perfect method for delivering applications to a desktop brokered through Trinity. Especially in an environment where desktops run as VM images, streaming applications makes image management a lot less complicated. There was a good example of application streaming used in a customer case study at VMworld 2006 -look out for the slides and podcast of session MED0062.
• Machine virtualization is the technology VMware, Microsoft, XenSource, and others use that makes physical machine resources available to multiple virtual machines. It can provide the infrastructure upon which you build a Trinity solution. Running the brokered desktops as VMs has cost and management advantages over using physical machines (that being the VDI pitch), but machine virtualization can also be used to optimize the Trinity server infrastructure. Just like we see a number of customers run CPS and other Citrix servers in virtual machines, I would expect the same to happen for Trinity servers.

So there you have it: while Trinity doesn't depend on a particular virtualization technology or platform, it can integrate and take advantage of in several flavours of virtualization. And while Trinity is thus virtualization-agnostic, we would expect that the majority of non-server desktops brokered through Trinity will be running as VMs, for the aforementioned cost and manageability reasons. As for the Trinity team, this means that we will strive to provide the required integration between Trinity and popular virtualization platforms to ensure that you can manage both the brokering and machine virtualization aspects of a Trinity deployment smoothly and efficiently.

Finally, a brief update on what's been happening in the team: we are now busy designing and prototyping the major building blocks for the second Trinity release targeted for late next year. We are taking advantage of some the newer technologies such as WCF, to reduce the time spent prototyping, and in a recent demo I have seen the first direct ICA connection to Windows XP running within a VM. In reality, this was missing a lot of the required server-side infrastructure, but it was a cool demo and by the way, in case you missed it: Citrix has just bought Ardence (Brian Madden has a good overview of their technology and some of its benefits in a CPS environment - and as you would expect he has already posted his analysis of this announcment). Now we can start planning in more detail how this will play with our Trinity designs. More on this, I hope, after the Christmas break.

Note: I hand-edited this post since it seems to have been badly garbled during the transition to our new blogging platform. I haven't materially altered its content though (although some parts of it are now a bit out of date).