• View Communities
    • Citrix Developer Network
      The place for unfiltered straight talk on Citrix products. Blogs, code downloads, best practices, APIs, and more can all be found here.
    • Citrix Ready Community Verified
      Does it work with Citrix? Application compatibility questions are a thing of the past with the new Citrix Community Verified site.
    • Blogs
      Learn the latest from the Citrix employees who are building application delivery infrastructure technologies.
    • Blogosphere
      The Citrix Blogosphere is a window into the thousands of conversations taking place about Citrix and Application Delivery.
  •  Sign In
The Citrix Blog
Blogs for tag 'design considerations'

Permalink | Twitter Post to Twitter | Comments (0) | Views (8175) |

posted by Daniel Feller

I've been looking at the breakdown of a desktop in a series of blogs.   In the first blog, I talked about how every desktop starts with a base operating system.  The second blog talked about application delivery and integration into the OS. The third layer of a desktop is personalization.  Many people think that personalization is simply a user's profile.  Well, personalization goes well beyond that. 

Think, for a moment, about what you do to your laptop or desktop to personalize it for yourself. Ignore the whole concept of virtual desktops at this point.   I've done the following to my own Citrix laptop:

Settings: I've changed the default settings for, well, just about everything, operating system and applications.

  • Desktop background is Homer Simpson.
  • My computer icon is Homer and the Recycle Bin is Lisa (because Lisa is the environmental Simpson). 
  • I've configured my delivered applications with Citrix Visio stencils, Outlook with my personal signature, Office custom dictionary with terms like  XenApp, XenDesktop, XenServer, NetScaler and WANScaler. 
  • I've added numerous favorites into my browser

Local Applications: Even though I receive most of my applications from Citrix IT, I've also installed a few applications on my own.  

  • Video recording software: I continue to post video blogs and record configuration videos for Citrix solutions. I need a video recording solution not delivered by the IT department.
  • Video Player: I've had to install numerous codecs/video players for different Citrix Videos I've created
  • Instant Messenger: I've installed different IM programs so I can talk to coworkers
  • Browser: Not everyone uses Internet Explorer.  With Firefox, Chrome, and others different people want to use different browsers. 

Information (Data): The data category is very important for personalization. You want to make sure your data is available where you would normally place it.  When you do a Save in Microsoft Word, the application defaults to Documents. 

Attachments:  What attachments do you use on your desktop? I've connected different digital cameras, webcams, MP3 players, mobile phone and printers.  Although many might not be Corporate Approved, they have been needed from time-to-time. 

By modifying application and system settings, adding your own local applications, attaching different peripherals and creating, storing and access data, you have turned an otherwise standard desktop into your very own, personal desktop.   That was the easy part.  The hard part is how do we virtualize the personalization layer so it can be applied during logon and change an otherwise standard corporate desktop, to one that is completely inline with what the user requires?  I could spend an entire blog on each of these four items, which I might do in the future, but for now I'll summarize.

A major part of the personalization strategy is focused on Profiles.  Most people cringe when they hear profiles because of issues they've encountered with Terminal Services and XenApp.  However, think about why we had profile issues in a XenApp world? Users would log on to many XenApp servers at a time, resulting in their roaming profile being pushed to numerous servers. Then when you logged out, that profile was uploaded, resulting in 1 profile overwriting another profile.  With XenDesktop, how many virtual desktops will most people use at a time? One.  Because of this design consideration, many of the challenges for profiles would be non-existent. 

However, we still must setup profile correctly.  We need to make sure the profile are optimized so they load faster (which is possible with the help of the Citrix User Profile Manager).  Also, we need to make sure the profiles are configured in such a way that the special folders (Desktop, Favorites, etc) are redirected off of the virtual desktop and onto persistent storage (File server). I'm briefly talking about profiles because in order to do it correctly, you need to have a solid profile strategy, something too long to discuss in this blog posting.  Right now, we can't do everything we need in profiles.

For Attachments we have to rely on virtual channels between the user's endpoint and the virtual desktop.  Whenever a USB device is plugged into the endpoint, it should appear on the virtual desktop.  With XenDesktop, this is a work in progress. Some things work and some do not.  But now is a good time to generate your list of what devices are required so you are ready to test with subsequent versions of XenDesktop.

The final item, applications, is an interesting topic.  Applications  are a layer in the desktop but it is also part of personalization because users add their own apps to personalize the desktop.  Before we go to potential solutions, we need to determine if this is needed.  Do you want users to be installing untested, untrusted, nonstandard applications into your protected data center? Or should you require the users to install these types of applications on their own end point device, outside of the data center? This is the first decision. As part of the virtual desktop analysis, you will hopefully identify the non-IT applications. If certain applications are used by a number of employees, maybe IT needs to add these into the application layer and start delivering them as a corporate resource.  If not, users will install the applications on their own. If using pooled desktops in XenDesktop, those changes will be destroyed upon logout. This will cause frustration and disapproval of the solution.  You can either

  1. Grant certain users assigned virtual desktops instead of pooled.  With assigned virtual desktops, the desktop is never destroyed and only belongs to a single user, but this brings about a whole slew of issues around maintenance and management
  2. Train users to install the applications on their local end point device
  3. Use a some other solution that is not released yet that virtualizes any installed application and delivers to the user on future virtual desktops. I haven't seen anything like this yet.  Who knows what the future will hold.

Hopefully, this blog has shed some light onto the complexities of personalization.  I wish I could say Citrix has all of the solutions in XenDesktop right now, but I doubt many of you would believe me.  I can tell you that Citrix is working on this as this is the personalization discussion is a major piece of the virtual desktop puzzle. BTW, if you want to remember the the four areas of Virtual Desktop Personalization, just remember the LISA Areas for Personalization: Local applications, Information (data), Settings, and Attachments.  This goes hand-in-hand with the BART Principles of application integration for virtual desktops.

Daniel

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (0) | Views (8945) |

posted by Daniel Feller

In a previous post, I talked about the 3 layers of a virtual desktop (OS, Apps and Personalization) and spent some time discussing the must haves and might need items that should be part of the base OS build.  This time I want to talk about the second layer, application delivery. 

As you are probably aware, application delivery in a XenDesktop environment is done with XenApp.  Now, I'm not going to tell you about how cool XenApp is (I leave that to the product marketing people). What I do want to spend time talking about is how we choose the best application delivery technique for a virtual desktop, because XenApp gives us three options:

Installed

  • Applications part of the virtual desktop OS build
  • Processing occurs on the virtual desktop
  • Impacts processor and more storage required for deployment as base OS image also includes applications

Streamed

  • Applications streamed to the virtual desktop upon request
  • Processing occurs on the virtual desktop
  • Slightly higher utilization when compared to installed applications due to the streaming client
  • Base Operating System images and applications remain separate entities

Hosted

  • Applications run remotely on a XenApp server
  • Application processing occurs on XenApp server
  • Running multiple applications has little impact on virtual desktop utilization due to the hosted application client

So, how do you choose the best option? Simple, close your eyes and point to one.     This might work, but it probably won't give you the best results.  If I was designing a solution, I would want to base these decisions on the following criteria:


The Primary and Secondary options are general recommendations.  For base applications like Microsoft Office, it will be a decsion by the business whether streaming or installing makes the most sense. But remember, installing applications into the virtual desktop means that everyone assigned that OS will receive those applications.  Streaming and Hosting allows fewer base OS images while still allowing for dynamic application sets based on user credentials.  

If you think the criteria will be difficult to remembr, look at it this way:

  • Base applications
  • Anomalous applications
  • Resource intensive applications
  • Technically challenging applications

This is the BART Principles of Application Integration.  It is really amazing how much you can do in life by basing ideas on The Simpsons. 

Let me know your thoughts on the BART Principles. 

Daniel

Bart Quote: If I do something bad and there's no one there to catch me, does that mean I'm good?

Expand Blog Post
Permalink | Twitter Post to Twitter | Comments (12) | Views (35271) |

posted by Daniel Feller

Memory is a big concern for XenApp on a 32bit operating system like Windows 2003 Server.  In the default state, Windows 2003 can only "see" 4GB of memory, which is split up into two equal parts: Kernel Memory (2GB) and User Memory (2GB). Kernel Memory is further broken down into 4 other parts:

  • Paged Pool: Memory space used by the system and kernel level components that can be paged out of physical RAM and into the page file
  • Non Paged Pool:  A section of memory guaranteed to always reside in physical RAM and is used by the operating system for certain kernel level processes
  • System Page Table Entry : An index table that tells the operating system where the virtual memory actually resides in physical RAM or on the page file
  • System Cache: Maps open files in memory for better performance. This is where the registry hives are located as well

Once the system has started, the different sections of kernel memory cannot be re-allocated. The system tries to allocate these 4 areas appropriately, but they might require "tweaking". However, the four areas cannot all be set to the maximum level as that would go over the 2GB limit of kernel memory.

Many of you are probably saying, "But I can use the PAE switch on Windows 2003 to go above the 4GB limit". You are correct, you can go above the 4GB limit, but are you aware of the consequences of this action?

  1. You must be using Windows 2003 Enterprise or Data Center.  This setting does not function in Windows 2003 Standard.
  2. The PAE Switch does NOT change the kernel memory limitations of 2GB
  3. To use the extra RAM, more System Page Table Entry memory is used
  4. If you have more System Page Table Entries, you will end up with less Paged Pool, System Cache and Non Paged Pool

Talk about being between a rock and a hard place. Adding more RAM and enabling the PAE switch "might" give you more scalability but at a great cost for a more expensive operating system, more RAM and special optimization configuration analysis and implementation. The reason I said "might" give you more scalability is because you will now likely run out of kernel memory before you run out of user memory. So you just bought a more expensive operating system and more RAM that will sit there wasted. 

Now I know some of you will add a comment saying something to the effect that you are using the PAE switch and ended up increasing single server scalability by 60, 70, 80 or even 90%.  All I can say is congratulations and I applaud you  . You are lucky as you have the right set of apps for this to work as well as it has.  But I want you to think about going down a completely different route.  Virtualization...

Keep using Windows 2003 Standard but virtualize it with XenServer. Upgrade the RAM on the physical servers so it can support 2-4+ virtual servers. In the end, you will end up with a system that is more flexible, scalable and easier to manage. 

If you interested in learning more about sever virtualization for XenApp, then take a look at the following:

Daniel

Homer Quote of the Blog: "To be loved, you have to be nice to others EVERYDAY! To be hated, you don't have to do squat."

Expand Blog Post