Post to Twitter
As many of you know, I'm not a Ft. Lauderdale or San Jose based Citrix employee. I work out of the grand Citrix office in Minneapolis (my basement). I've been a remote Citrix person since I started here almost 10 years ago. And I can tell you this, being a virtual worker used to suck pretty bad. Sure I could use any XenApp application over my internet connection effectively, but what was missing was being able to have an active part in brainstorming meetings and the feeling of being part of the team. I can't tell you how many times I've been in a meeting when people started white boarding. Not much for someone on the phone to do. Nothing to look at, nothing to see, nothing to contribute.
I tried to travel to Ft. Lauderdale once a month and this was pretty effective. Unfortunately, as we all experienced, the economy crumbled and so did travel budgets (which was my only monthly escape from cold Minnesota winters).
This got me thinking about virtual workers. What do they need to be effective and still feel like a member of the team? What have we done in our group to make our virtual workforce more effective? From a user's perspective, they only need a few things:
- Resources
- People Interaction
These are actually pretty easy to come by nowadays.
First, let's start with resources.
That was then...
- I had to have a local install for most of my apps. Sure I could have used XenApp, but many times I was disconnected from the internet and out of luck.
This is now...
- I now use Application Streaming. Many of my applications are streamed down to my laptop. I figure that 90% of the applications I use are streamed, while the remaining 10% are not because they require a backend data connection in order to function. What's the point in streaming something for offline use if it requires a backend data connection? I don't see one.
What about people interaction?
That was then...
- Trying to have discussions with coworkers was done via phone and required my own business line (Costs $$$).
- Trying to work on the same doc was done by XenApp shadowing.
- Trying to whiteboard was a joke (have you ever tried it with your mouse? I don't recommend it)
- Trying to get peoples facial expressions/reactions was impossible. At one point I went 6-9 months without seeing my boss or other coworkers.
This is now...
- Voice conversations no longer requires a separate business line. If I'm just doing a one-to-one conversation, I can use EasyCall. If I'm taking part in an online meeting, I can simply use the integrated VoIP functionality within GoToMeeting. No more long distance charges for me
- Collaboration on the same doc is now easy with GoToMeeting. Anyone can modify the one open document and comment on the fly.
- White boarding is done online, but instead of using a mouse we use sketch pads (Wacom, AIPTEK, UC-Logic). I even used mine during a recent Citrix TechTalk on offline mobility. And my manager just used it during a brainstorming meeting. Much more effective (and entertaining because my boss is not a very good artist.)
- Face-to-face conversations are done with video conferencing (Microsoft Communicator, TokBox, Oovoo). Actually makes you feel like you are part of the team.
- Quick conversations are done via any number of Instant Messenger providers
- Training is done online and collaboratively. One of my coworkers used video conferencing and GoToMeeting to train others that were located on a different continent. The feedback was extremely positive because the webinars was much more interesting when you can see everyone else.
Things have definitely improved for virtual workers. The technology has matured and become more integrated, which is making our lives easier. Are any of you virtual workers? What enhancements/technologies have you found to be helpful?
If you are interested in more information regarding virtual workers, take a look at the materials on this site.
Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
The following is the Q/A session from the XenApp: Fact vs. Fiction - The Truth about App Compatibility with Citrix TechTalk. For those of you who missed it or are wondering where to get materials, they can be found here:
Q: does the appcompat site differentiate between verification with xenapp hosting versus xenapp streaming?
A: Yes. In the platform column, you can see the product and whether it was hosted or streamed
Q: does per user image mean per user per app or per user for all apps
A: Per user per app. Essentially, within the user's profile, you will have a GUID on the file level the registry level. Each GUID corresponds to 1 app. As this information is stored in the user's profile, you get down to 1 user and 1 app personalization.
Q: Is streaming licensed for XenApp 4.5 EE?
A: Yes. Enterprise and Platinum edition of XenApp 4.5 and 5 gives you App Streaming
Q: What is the difference between Stream to XenApp and Application Isolation?
A: Application streaming utilizes isolation environments. In older versions of XenApp, you could install applications into an isolated environment. The Isolation Environments are now only available as part of Application Streaming.
Q: Your Twitter site.
A: http://twitter.com/djfeller
Q: Daniel...need to know what hardware you use for your home setup? how many boxes do you have?
A: My personal lab setup is very simple and not a typical implementation. I'm only looking at functionality and not scalability. Two powerful workstations (Quad core, 8GB RAM, 500MB storage). Both systems are configured with XenServer. I also have a 1TB Debian Etch system I use for XenServer shared storage. Within XenServer, I have 1 Domain Controller (SQL and File share), 2 PVS servers, 4 XA servers, 2 WI servers, 2 XD servers, 10 Vista and 10 XP workstations, 1 App Profiler
Q: It sounds like when streaming, the application runs on the client. If so, doesn't this defeat the purpose of XenApp ?
A: You can actually stream applications to the client (client-side app virtualization) or to the XenApp server (server-side app virtualization). App streaming helps overcome app compatibility issues on either location. Doing client-side allows you to use some of your workstation's power and allow you to continue using the application if the network link is broken. While XenApp streaming allows you to centralize hosting, better scalability, and better security, plus all the other benefits of XenApp.
Q: Do you recommend streaming for PACS app with high resolution graphic and clips
A: I would test to see if it will stream. Some applications just won't stream, especially if they have a Windows service or drivers. Now if the app can be streamed, then you will need to see if the app performs adequately on XenApp with the graphics. I've seen many people have PACS on XenApp with great results when they use the SpeedScreen Progressive Display technology.
Q: For offline... how much disk space for your apps. Slide 27 / 28?
A: Depends on the application. Some examples from my apps: Office is 1.1GB in size. Adobe Acrobat is 160MB, Firefox is 12MB. Remember, these are the sizes of the app profile that is copied to your local workstation for offline mobility.
Q: Would apps that require back-end connections work offline? It seems this should not without being connected to the network/internet... correct?
A: Correct. There is another TechTalk (XenApp: Take Your Data with You: App Streaming ) that talks specifically about App Streaming and offline mobility and covers this item. But long story short, apps that require backend data shouldn't be streamed for offline as they will more than likely be useless (although there are exceptions). If the app syncs when back online, then you can stream for offline (Outlook is perfect example).
Q: We're using linux and MS based Neoware thin clients almost exclusively. What problems does this present?
A: Well, you can still do server-side application streaming. Right now, the streaming plugin (offline apps plugin) is only available for the Windows platform. Many of the thin clients also use an OEM version of Windows XP or do not include enough hard drive space to store the application cache. You might want to look at XenDesktop which would give these users a desktop-like experience if that is what you are looking for.
Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
I am very excited to announce the release of a Reference Architecture for an enterprise XenDesktop environment. Many times when you see reference architectures, the paper is very high-level and provides minimal details. Well, this document is completely different. It is based on a customer environment with 10,000 users spread across four data centers. It includes many of the challenges we architects must design around including, multiple data centers, worldwide design, thousands of users, remote users, etc.
The design focuses on the following topics:
• Virtualization Infrastructure
• OS Delivery
• Application Delivery
• Desktop Delivery
• Desktop Design
• Business Continuity
Within the subsections, you can read about the environment design, capacity planning, hardware design and storage design as well as a host of other items. As this is based on a customer environment, some details had to be removed and generalized.
As you read through the document, you might think "Why did they do it that way?" Where possible, we tried to follow best practices, but with any environment, the nuances required we deviate from the preferred path to alternate paths. You will probably have questions, comments and challenges with the way we designed the environment, which is why I'm going to start a blog series around the key design areas so all of you can comment and we can discuss. Should be an interesting series. Make sure you grab the design document (CTX121478), and Stay Tuned...
Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
In Provisioning Services for XenApp Best Practice #5, I wrote about application streaming integration. I talked about two different options:
1. Stream on-the-fly: which results in the vDisk write cache growing as the application is streamed
2. Pre-cache: which stores the application cache within the vDisk, but helps to reduce the size of the vDisk
Both of these options had their issues. Option 1 would grow your write cache quickly, especially on XenApp servers hosting tons of applications. Option 2 creates a link between the vDisk and applications, which adds another step to application updates.
I received many suggestions and alternatives, some were quite interesting 
. The one that resonated the most was to store the application streaming cache on another disk that is not delivered via Provisioning services.
- Physical Servers: You would use the physical disks installed into the physical servers
- Virtual Servers: You would use a virtual disk assigned to the virtual machine (preferably shared storage so you can still do XenMotion).
This setup doesn't really change our architecture in that many implementations have a non-Provisioning Services disk associated with each server to store items like event logs, local databases, write cache and pagefile (as explained in BP 8?).
Honestly, I haven't had the opportunity to set up an environment like this in a large environment, so I didn't want to offer it as a best practice yet. But I've had many of you say that this is about the only way you deliver XenApp images with Provisioning Services and have had no issues with the environment from configuration or maintenance. I've always thought this provided the best solution as it overcomes many of the lingering challenges of option 1 and option2. So, how do you do this? It is actually pretty easy:
- Make sure you have an NTFS disk associated with the physical server (physical disk) or virtual server (virtual disk)
- With the Provisioning Services image in private-image mode, change the location of the Application streaming cache location
- Launch C:\Program Files\Citrix\Streaming Client\ClientCache.exe
- Change the client cache directory to the virtual or physical disk
- Shut down and place vDisk back into standard image mode
When you boot, and launch your applications, your application cache is now stored on the physical/virtual disk that is not erased during reboot. What does this get you?
- Faster application launch after server reboots because the application cache is not erased
- Easier application maintenance because the application cache is not included within the vDisk
But this configuration does come at a price. You have to have a persistent disk associated with each physical and virtual server. Although this cost is pretty small as most Provisioning Services/XenApp implementations already have a local disk to store local monitoring databases, event logs, etc.
My list is now empty, but will post new topics as they come in. Feel free to tweet me some ideas on Twitter.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drive
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more
By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly. I'm a little biased, but I think it is a good one.
Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
One of my biggest gripes about Terminal Services and XenApp was that once I disconnected from the network, I could no longer use my applications. This was a major pain as I spent a lot of time on airplanes. During my 3-4 hours flights as well as 1-3 hrs sitting in the terminal, I was unable to get any work done (although I did get a lot of reading done). My problems with XenApp wasn't just limited to airports and airplanes, but also included remote connectivity. As I'm a remote employee, I spend most of my time working from my home office. There were many cases where I just wanted to spend 1 minute to look something up in a local file. But because my applications are hosted from XenApp, that 1 minute actually took 3-5 minutes (authenticate to employee portal, launch XenApp application, open file and wait for the file to be transferred from local workstation to XenApp server).
I got frustrated and installed my applications locally. This was wonderful. All of the frustrations I've had were almost gone. But this now caused new challenges. I now had to manage and maintain my applications. I had to install appropriate hotfixes/service packs. I also had to troubleshoot application issues, not something I enjoy doing. (Why does it always seem like your applications fail when you need to use them the most?) Well, believe it or not, XenApp actually allows offline access to your applications. You get to use your XenApp applications while your network is not connected, while you have absolutely no connection to the XenApp infrastructure. This sounds like a good deal. I get local usage and I don't have to worry about maintenance.
How does it work? How do you implement it? What best practices should be followed? All of these questions are the basis for an upcoming TechTalk on offline mobility with XenApp. In this TechTalk session, you'll learn about:
• How XenApp users can take their applications with them, disconnected
• How offline XenApp users are kept current
• How to eliminate app conflicts without stress
• How to follow the best practices while delivering offline applications
• How application streaming can help simplify your Vista and Windows 7 migration
Hope to see you at this TechTalk on Friday, June 5th at 1PM Eastern time.
Daniel - Lead Architect - Worldwide Consulting Solutions
You can follow Daniel at http://twitter.com/djfeller
You can read Daniel's blogs at http://community.citrix.com/blogs/citrite/danielf
XenApp admins are a creative group of people. I used to be a XenApp admin and I remember having to do tons of things to an application to get it working correctly on XenApp (but back then it was called WinFrame and MetaFrame, not even MetaFrame XP). Back in the day, applications were not built to execute on a multi-user system like XenApp. In fact, many applications today, especially those home-grown applications, are problematic on XenApp. This is where the creative XenApp admins come in. They developed numerous tweaks, configurations, hacks and custom solutions in order to get an application functioning properly. Of course this made the environment much more complex to build and maintain.
But just getting applications functioning on XenApp is just part of the problem. I remember hearing people ask about running different high-graphics or video applications on XenApp and thought, ARE YOU NUTS? ICA was built to only send those screen changes down to your video display, but with video the entire screen is changing. Talk about chaos.
THAT WAS THEN. THIS IS NOW. Things have changed for the better. Application issues are more of a myth nowadays. With new XenApp features, many of the application challenges that plagued XenApp environments are being eradicated. But unfortunately, many of you have experienced application issues years ago and haven't looked at those applications since. So I'm asking that we spend an hour going through the XenApp features focused on application compatibility in an upcoming TechTalk session.
I plan to discuss the technologies that make application compatibility easier, which will also help simplify your XenApp architectures. We will go through many of the challenges you all have experienced and talk about how these are now easily overcome. So I encourage you to attend this TechTalk session called: Fact vs. Fiction - The Truth About Application Compatibility and XenApp.
Can't wait to see you there on Wednesday, May 27, 2009 at 1PM eastern time.
Daniel - Lead Architect - Worldwide Consulting Solutions
"Learn from the past, live in the moment, and plan for the future"
Follow me in the blogs: http://community.citrix.com/blogs/citrite/danielf
Follow me in Twitter: http://www.twitter.com/djfeller
The whole concept of a standard image used across multiple end points is a great idea. Think about it, 1 image for hundreds/thousands of servers. Talk about simplicity. I only have to make updates once and every server has the same update. Every server is identical. This makes scaling up the environment easy. Of course there are some challenges, as many of you have pointed out after my very first blog posting where we spoke about vDisk type. That challenge is that the "write cache" is destroyed upon server reboot.
For the most part, this is a good thing. Those changes gives each XenApp server a personality. I don't want my XenApp server to have personalities. Its kind of like running Microsoft Word one day and it is using United States English and then the next day it uses United Kingdom English. This little personality change doesn't seem to be a big deal, but it is. For example, I like my words to use the letter Z. I believe you spell color without the letter U. I believe neighborhood is spelled without the letter U too. Of course this is a simple change for a user, but we shouldn't make our users do this. But there are some changes on XenApp servers which are valuable (many of you have pointed them out to me) like event logs and performance metrics.
So how do I use a standard image but still allow these important items to remain persistent across server reboots? Some of you have raised good points on this, especially around the use of differential disks, but the problem with differential disks is that the differential cache will go away if the base vDisk is changed. So, differential disks do not really help us out that much. What we can do instead, which again some of you alluded to, is to use a local disk.
Now I bet some of you have alarms going off in your head and are thinking, "Hey, I thought the benefit of Provisioning Services is that I don't need local disk". Well, you are 100% correct, that is one of the benefits, but there are more like standardization and synchronization but will leave that for a marketing-type blog. But with standard images you do lose some items like persistent storage of event logs, metric databases, etc. But if we allocate a local disk to the server, we can redirect the storage of the persistent data. BTW, this works when XenApp is virtualized on XenServer and when XenApp is on bare-metal.
You do this by doing the following:
- Your virtual machine must have 2 virtual disks assigned. Remember if you want to do XenMotion, the second virtual disk must be on shared storage. How large you might ask? For XenApp, a 4GB partition is a good starting recommendation, but with most decisions, it depends.
- Build XenApp on the first disk and format the second disk NTFS so it shows up in your system (use basic disk and not dynamic).
- Change the storage paths of your persistent databases, event logs and anything else to the second virtual disk.
- Build your vDisk from the C drive, but not the second drive. When done, shut down the virtual machine.
- Detach the OS virtual disk from the virtual machine, but leave the second virtual disk attached.
- Clone the virtual machine including the virtual disk.
- Now stream the vDisk image to this new virtual machine. Your event log should be stored on the virtual disk instead of within the write cache.
So now we are using a base vDisk for our image and still allowing persistent data storage. And what's more, you can also use that persistent disk to be the write cache storage location as well. Just tell Provisioning Services to store the write cache on local storage, and the persistent disk will hold that information for the server's session.
My list is now empty, but will post new topics as they come in. Feel free to tweet me some ideas on Twitter.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly. I'm a little biased, but I think it is a good one.
Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
This best practice was requested by a comment on a previous blog posting. With Provisioning Services, we are able to use a single image for hundreds of XenApp target servers. Making a change to the image is a big deal because every XenApp server will use the new image after a reboot (of course this is also a huge benefit). How do we keep control over these images and make sure you don't break your entire environment with a new update?
Truthfully, it is a fairly straight forward process, but just like all processes, you need to follow them if you want things to go smoothly. High-level process overview is in the following figure:
These are all logical systems, meaning that they could be virtual servers, physical servers, different volumes on the same storage infrastructure. The recommended process is as follows:
- When you have a valid vDisk on your production Provisioning Services server, make a copy of it and store it in your library. The library is just that, a location where you keep the current and old revisions of vDisk images.
- When you need to make an update, copy the vDisk from your library to your test environment Provisioning Services server.
- Make your changes in the test environment. When the changes are done, update the revision number and filename of the vDisk. Copy the vDisk back into your library and to the production Provisioning Services server.
- Tell the production Provisioning Services server to auto-update vDisks. This is actually a really cool feature. The auto-update process will automatically update the vDisk file of all affected target devices upon next reboot. How can you tell which target device will be updated? By the Class information. Each target device and vDisk file has a Class field. The class fields are the link for auto-updates. Provisioning Services will look to see if there are any vDisks with a higher revision number (which there is as we just updated the vDisk and incremented the revision number). Provisioning Services then checks the Class of the vDisk. Any target device with the same Class will receive the new vDisk upon next reboot. This is a great way to simplify the management of your XenApp farms.
Ok, so we updated our XenApp servers with a new vDisk, but what happens if there is a problem with the vDisk updates? Have you ever installed a hotfix to find out it broke other things? I bet so. If you followed the process outlined above, you have a build in rollback feature by doing the following:
- You make a copy of the previous vDisk image from your library to the Production Provisioning Services server.
- You increment the revision number on the old vDisk image to a number that is higher than the updated vDisk image.
- You implement the auto-update feature of Provisioning Services
- Reboot the XenApp servers
As you can see, the processes for updates and rollbacks are very similar and it works great. Stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly. I'm a little biased, but I think it is a good one.
Daniel - Sr. Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
As many of you who follow my blog postings will realize, I love talking about Provisioning Services
- Provisioning Services Best Practices (6, 5, 4, 3, 2, 1, plus more to come)
- Quickly deliver XenApp Servers with Provisioning Services
- Use Provisioning Services to Create XenApp Swing Servers
I've spent a significant amount of time discussing best practices for integrating XenApp and Provisioning Services and thanks to many of you and your questions, I've been able to create and define new best practices; all of which will make it easier for you two simplify you XenApp environments.
If you are still wanting more information on the Provisioning Services for XenApp, then I highly recommend you attend this recently released TechTalk. For those of you who have attended my TechTalks before, my goal is to explain the how's, the why's and the when's for creating a solution of your own. This TechTalk is no different as I go through the following topics
- How Provisioning Services overcomes many of the ongoing challenges associated with XenApp environments
- How to create and deliver a set of XenApp servers with Provisioning Services
- How to design a Provisioning Services solution while following recommended best practices
Who do I recommend that should watch and listen to the TechTalk? Well, the following is a good idea:
- Anyone who is trying to design a Provisioning Services for XenApp environment
- Anyone who has heard of Provisioning Services and thought it sounded intriguing
- Anyone who has a XenApp environment and wants to makes management easier
- Anyone who knows already knows a lot about Provisioning Services. You might learn something new, or you might be able to provide me with some of your thoughts/insights.
After watching the TechTalk, feel free to post a question or comment on this blog as I'm always interested in hearing your thoughts, suggestions and recommendations.
BTW, you can reach me on Twitter at http://www.twitter.com/djfeller or on the blog site http://community.citrix.com/blogs/citrite/danielf
So, set aside 60 minutes, grab some food, go to this TechTalk link, sit back, relax and enjoy.
Daniel - Sr. Architect (Worldwide Consulting Solutions)
Pagefiles, partitions and drives are an interesting combination of items to talk about regarding Provisioning Services and XenApp. Each one will have a direct impact on your environment. First, let's be clear, Provisioning Services does support many of these items, but when I design a Provisioning Services solution (or any solution for that matter), I'm always reminded of a message a professor told me once. The professor was a fan of the group KISS and he always wanted you to follow the KISS motto... "Keep It Simple Stupid", but I'll be a little more polite and say "Keep it Short and Simple". Keeping it simple is how we will design the following items.
Pagefile
The first area deals with the page file. Before we got into provisioning and virtualization, I would see many people put the page file on a different drive letter than their OS or applications. At first glance you would think, OK, they want the page file to respond fast. But the page file was only on a different drive letter at the logical layer. At the physical layer, the page file was still on the same physical disk as the other partitions. So, my question was "Why are you moving the page file? You are causing yourself more work for no benefit." The same holds true in Provisioning Services.
The pagefile is undergoing constant modification by the operating system. As physical memory is paged, it is stored in the pagefile. Upon reboot, the contents of the pagefile are not important, and it is overwritten on subsequent startups. In a Provisioning Services environment, the pagefile will be located on the vDisk, but any change made to the file will be recorded in the write cache, because the vDisk image is read-only. Assigning the pagefile to a different partition within the vDisk is not recommended, because there is no speed benefit. You are just causing yourself more work.
Multiple Partitions
On the heels of the page file decision is whether to use multiple partitions. Does this look familiar?
- One Partition Server
- Partition 1: Operating System, Pagefile, Applications
- Two Partition Server:
- Partition 1: Operating System, Pagefile
- Partition 2: Applications
- Three Partition Server
- Partition 1: Operating System
- Partition 2: Applications
- Partition 3: Pagefile
Provisioning Services can deliver an image with one or two partitions, but not three. Plus, based on the Pagefile section above, there is no gain from having a separate pagefile partition on a provisioned XenApp server as the pagefile changes will be stored in the write cache.
Although two partitions are supported, it does increase the complexity of the environment and does not offer any performance benefit to the environment. There is a Citrix article (CTX116698) that explains how to provision a server with multiple partitions, but why go through the hassle. Keep It Simple.
Drive Remapping
Finally we get to remapping XenApp server drives. Remember, this is when you change the C drive of the XenApp server to the M Drive. D becomes N and so on. Why would you do this you might ask? Well, the most common justification for this design consideration was for users to have their client drives mapped within their XenApp sessions as C and D. However, this approach should be re-examined. Remapping server drives is not considered a best practice for XenApp environments because:
- Drive remapping is no longer an option in XenApp 5 running on Windows 2008 Server.
- Giving users access to their local C and D drives within a XenApp session is considered a security risk. If the applications are hosted on the XenApp servers, the data should be in the data center for best application performance.
- It makes the environment more difficult to setup, maintain and troubleshoot
So remember, Keep it Short and Simple (KISS):
- Page file: don't create a special vDisk partition
- Partitions: Use a single partition
- Drive Remapping: Don't do it.
What do you think? Agree or disagree? BTW, we will be revisiting the page file topic again in an upcoming blog when we discuss Local Database Storage. How does the page file fit with local databases? Well, you will just have to stay tuned.
As always, stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
As we continue to discuss Provisioning Services best practices for XenApp, I want to talk about a question I hear a lot, especially when people see the value of Provisioning Services and XenApp Application streaming "Should I pre-deploy my streamed applications into the Provisioning Services vDisk?" If Provisioning Services wasn't in the picture, I would say let the streaming infrastructure manage the application streaming delivery, but Provisioning Services must be taken into account because the act of application streaming has a direct impact on the provisioned server.
The streamed application is a change to the base vDisk image. These changes are stored within the write cache for each provisioned XenApp server. Depending on the size of the application, the simple process of delivering an application on top of a Provisioning Services' streamed XenApp server can make the write cache grow by many gigabytes as shown in the following diagram:
Using a provisioned XenApp server will generate the typical swap and temp files, which will be added into the write cache. When a streamed application is requested the first time, the application profile is delivered to the XenApp server from the Application Hub in a compressed format (.CAB files). The application profile is delivered and then decompressed so it can be utilized. This process adds information to the write cache.
Depending on the write cache option selected, this could have a significant impact on the usability and speed of the XenApp server. If the write cache size is a concern, then a pre-delivery option exists that will reduce the size of the write cache. This process is shown in the following figure.
In this example, the vDisk image has a pre-delivery of the streamed applications. Users still have to access the applications as before, but the applications are already on the vDisk so the application stream process is complete. This removes the application CAB files and the decompressed application cache from the write cache. This also speeds up the application stream process because the application is already present on the vDisk, although this is a minor concern due to the XenApp servers and Application Hub server residing on the same high-speed network.
The challenge with doing the pre-cache of the streamed application is that each time a streamed application is updated (which could be often), the application cache within vDisk image should also be updated (at least that is the assumption). This adds more steps into the application update process. But I don't believe every application update requires an update to the application cache on the vDisk, only major updates are a concern.
For example, if an application has a new patch or a new file update, simply updating the application profile will be adequate. When a user tries to start the application on a provisioned XenApp server, most of the application cache is correct except for a file or two. Those two items will be updated from the application hub, and will only slightly increase the size of the write cache. However, if a large update to an application is performed, like adding a service pack to Microsoft Office, then it would be advantageous to refresh the application cache on the vDisk because these updates impact a large percentage of the files in the cache. When the application is executed, all of the updated files will be streamed down and placed in the write cache.
As always, stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
How many of you have worked with or started designing a XenDesktop solution? Chances are you have tons of questions about the best way to design the environment for growth, scalability and stability. I know this because I, like so many others, are asked the same questions. For example
- Should I install or stream applications into the virtual desktop?
- Where should the Provisioning Services write cache go?
- How should I design my Web Interface implementation to provide seamless integration without causing confusion for my users?
- How do I provide better availability to the TFTP server used to deliver the Provisioning Services bootstrap file?
Thomas Berger and I started gathering these questions to build the XenDesktop Design Handbook. The current release of the Handbook is focused on Operating System, Application and Virtual Desktop delivery design decisions, but this is only a start. Over the coming months, we will continue expanding into different design decision areas commonly discussed in a XenDesktop solution including: virtualization infrastructure and implementation practices. We will discuss the Citrix Consulting Best Practices about these topics and encourage you to submit your related questions . Thanks and we look forward to hearing from you
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
Here we are again, for another Provisioning Services for XenApp Best Practice. This best practice focuses on integrating applications into the vDisk image. Pretty simple Yes or No answer.
But this is one of the major challenges with creating a base XenApp image is determining what to include and what not to include. Of course, you need the operating system and XenApp and Provisioning Services tools, but beyond that what is recommended and why? Take the following scenario: due to business reasons, an environment has three sets of XenApp servers hosting different line-of-business applications. All three line-of-business applications are dependent on Microsoft Excel for viewing and editing integrated spreadsheets. Should Microsoft Excel be part of the base image or should it be a streamed application? There answer is... there is no right or wrong answer; it is all dependent on other factors within the environment. Don't you just love answers like that?
The decision to include core applications is oftentimes a result in the belief that the base image should contain the greatest number of items that are common between XenApp servers. If every server requires the same application, more network bandwidth will be used when the application is streamed to every server as part of the application streaming process. Also, application streaming, in the default configuration, does not initially start as fast as a previously installed application because the application must be sent across the wire. Thus, users will experience latency while the application is streamed for the first time (this latency can be overcome with application pre-caching, as explained in the Application Cache section).
There is also a business aspect to this decision. In some organizations, one set of administrators is responsible for applications and another set is responsible for the XenApp configuration. By separating the applications from the base image, the technical solution can align more closely with the organizational structure of the business.
| Base Image Application Inclusion |
Base Image Application Exclusion |
|
|---|---|---|
| Benefits |
|
|
| Concerns |
|
|
Regardless of the decision on which applications to include and exclude in the base image, the following are general best practices for the base image:
- All relevant operating system and XenApp hotfixes and service packs should be included in the base image.
- The most common operating system and XenApp configuration should be used for the base image. If 80% of the servers require a specific setting while another 20% do not, the base image should include the special setting.
- The base image should include all appropriate XenApp plugins. If application streaming will be used, the streaming plugin should be installed as part of the base image.
- Depending on the usage of server certificates, the appropriate root certificate should be part of the base image.
What do all of you think? Do you install the common applications into the base vDisk, or do you rely on XenApp application streaming? How many unique XenApp images do you have in your environments?
As always, stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
We are moving down the best practices road and now we come up to Active Directory. This, of course, is just a recommendation as I know everyone's AD structure will be different. But let's start out with a long-standing best practice... XenApp servers have warranted their own organizational unit within Active Directory for organizational and policy enforcement purposes. The recommendation has also included breaking out specific XenApp roles or locations into their own OU. Each identical group of servers would have the same policies applied. Typically, this creates an Active Directory structure like the following:
With the inclusion of Provisioning Services into the XenApp architecture, this recommendation does not change. In fact, this best practice becomes even more important because there will probably be special policy settings specifically for provisioned servers. Depending on how Provisioning Services is integrated with XenApp will help to determine if new OUs are required.
- If the OU contains a set of XenApp servers all provisioned with the same vDisk, then any Provisioning Services related policies can be applied to the entire OU.
- If the OU contains provisioned and non-provisioned XenApp servers, all hosting the same applications, then a new OU should be created that contains only the provisioned XenApp servers.
- If the OU contains provisioned and non-provisioned XenApp servers hosting different applications, then multiple OUs should be created containing only identical servers.
With Provisioning Services, the XenApp OU structure might resemble something like the following:
Each OU contains:
- Similar servers: Applications, infrastructure components, XenApp components
- Similar delivery processes: Provisioned or not provisioned
Please comment with your thoughts or if there is another best practices you are wondering about. The list has already grown based on feedback from previous blogs. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Many of you tuned into the TechTalk webinar over a month ago when I spoke about how to integrate applications into a virtual desktop. If you didn't attend the live event, you can still listen in to the recorded version of it. It sounds like an easy topic, right? "Just install them stupid!" Of course that approach does work, but is it the best approach? Many of us are long-time XenApp people. We see the value with virtualizing applications in XenApp. We've already spent lots of time, money and sanity to get our XenApp environments tricked out so it is running smooth. So I'm here to tell you, leverage it. Just because you are going to do a virtual desktop solution does NOT mean you have to throw away your XenApp environment. That is just crazy.
Before you start on the XenDesktop build out, take a look at the just released Reference Architecture. You can share and streamline your XenDesktop environment by using and sharing your XenApp environment. Some of the XenDesktop components can be shared with XenApp components. Which ones? How about the license server, data store or Web Interface?
Also, the integration must be streamlined. You don't want to make your users jump through 20 hoops before they get to their applications. They will be tired and hate the solution, resulting in your project failing. Make it look like the following diagram... Simplified user perspective
The user authenticates once, and they get a standard desktop image that is personalized with their unique set of applications, automatically.
Next, which apps go where? This is a big question. Do I let my XenDesktop users simply connect to hosted XenApp applications? If that is your objective, then why are you using XenDesktop? Truth be told, some applications work better on a desktop OS. But these applications can still be delivered via XenApp. Focus on application categories of Base, Anomalous, Resource Intensive and Technically Challenging. These categories will guide you to the best solution.
Click for larger image
Interested in building the XenDesktop/XenApp solution? Then grab the Implementation Guide. Step-by-step instructions (with pictures) that shows you how to leverage your XenApp environment for XenDesktop. If you are really good and just need a high-level guide, then grab the Getting Started Guide
The important thing to remember is don't throw away your past successes to build something new. Leverage your past success to make your future success easier.
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
In the previous Provisioning Services with XenApp best practice blog, I spoke about the type of vDisk to use (the feedback was great. So much so that I've added new items for future best practices discussions). If you are going down the route of using a standard image, you must make another decision. This is probably one of the most commonly asked questions regarding Provisioning Services for XenApp environments, where do I place the write cache? The goal is to select a location that gives you the best performance without sacrificing other important items like fault tolerance or scalability. What makes this such a challenging discussion is the number of options we get.
- Target Device (Physical XenApp or Virtual XenApp) - RAM
- Target Device (Physical XenApp or Virtual XenApp) - Local Storage
- Target Device (Physical XenApp or Virtual XenApp) - Shared Storage
- Provisioning Services - Local Storage
- Provisioning Services - Shared Storage
Each write cache storage option has many different benefits and concerns, especially for the XenApp workload. For most XenApp environments, the best solution will be the one that takes on the following characteristics:
- Fast: XenApp requires a solution that responds quickly as XenApp is maintaining live, interactive user sessions. Any delays in the write cache might be noticeable to the users.
- Dynamic: XenApp servers are delivering many different applications and supporting many different users. Each user and application will have an impact on the write cache. The amount consumed will change day-to-day. The risks of exhausting write cache space would be detrimental to the success of a XenApp environment.
- Available: XenApp servers must be protected from environment failures, because each server is supporting many users simultaneously. The write cache solution selected should be one that does not impact high-availability options from functioning.
Target Device - RAM
Definition: The first option for write cache storage location is the target device's RAM. A portion of the target device's RAM is set aside and used for the write cache.
Benefits: The main benefit for using the target device's RAM is it provides the fastest type of write cache.
Concerns:
- A portion of the RAM cannot be used for the server workload. RAM is often better used for XenApp applications or user sessions than for write cache. Plus, using RAM to support the write cache is more expensive than using storage.
- Part of the challenge with using RAM as the write cache storage is determining the amount of RAM required. Provisioning Services can set aside a certain portion of RAM for the write cache, but what happens when the RAM runs out? The write cache is critical to the stable functioning of a provisioned server. When available write cache is exhausted, the server can no longer make changes, which results in a server failure. If the write cache size is not estimated correctly, using a Target Device's RAM might pose detrimental to the stability of the environment.
Target Device - Local Storage
Definition: The second option for write cache storage location is the target device's local storage. This storage could be the physical disk drives on the physical server, or it could be the virtual disk on a virtual server
Benefits:
- This solution does not require additional resources, in that most physical servers being provisioned already have local disks installed and unused.
- Although target device local storage is not as fast as RAM, it still provides fast response times because the read/write to/from the write cache is local, meaning that the requests do not have to cross the network.
- Trying to estimate the size of the write cache is difficult and if done incorrectly, can result in server failure. However, local storage typically provides more than enough space for the write cache, without requiring the administrator to estimate space requirements.
Concerns: If the target device is virtualized, using local storage will prevent live migration processes from succeeding because the storage is not shared across virtual infrastructure servers, like XenServer.
Target Device - Shared Storage
Definition: The third option for write cache storage location is on a shared storage device attached to the target device. This solution is usually only valid for environments virtualizing the target device with a solution like Citrix XenServer. This storage is assigned to each virtual machine from a shared storage repository.
Benefits:
- Although target device shared storage is not as fast as RAM or target device local storage, it still provides fast response times. If the shared storage infrastructure is a SAN or NAS, the reads/writes will still perform adequately because the optimized shared storage infrastructure will help overcome the time added for traversing the network.
- Although the configuration of this solution requires the identification of the shared storage size, the costs associated with over-estimating are not nearly as detrimental as overestimating with RAM. Storage costs are significantly cheaper than RAM so a sizeable buffer over the space estimates is of little concern.
- Because the target device's storage is accessible from multiple virtual machines, virtual server live migration, like XenServer XenMotion, is viable.
Concerns: This solution requires the setup and configuration of a shared storage solution. However, if XenServer is already being utilized, the same shared storage solution can be used for the write cache storage.
Provisioning Services - Local Storage
Definition: The fourth option for write cache storage location is on the Provisioning Services' local storage. This storage uses the physical disks installed within the Provisioning Services.
Benefits: This solution is extremely easy to setup and requires no additional resources or configuration within the environment.
Concerns:
- Requests to/from the write cache must cross the network and be serviced by the Provisioning Services streaming service. Because the write cache is across the network, servicing write cache requests will be slower than the previously mentioned options.
- The streaming service is responsible for sending the appropriate parts of the vDisk to all target devices. Having the write cache on the Provisioning Services server will negatively impact the server's scalability because the streaming service must also service the write cache requests.
- Provisioning Services includes a high-availability option, but in order for this solution to function, all Provisioning Services servers must have access to the vDisk and the target device's write cache. When the write cache is stored on one Provisioning Services server's local storage, this makes it impossible for other Provisioning Services servers to gain access, thus denying the ability to enable Provisioning Services high-availability.
- Although disk space is fairly inexpensive, chances are the Provisioning Services does not have an extensive supply of storage space. With each Provisioning Services server supporting a few hundred target devices, it is quite possible the total write cache could exceed hundreds of gigabytes of storage space. This could result in exhausting all local storage on the Provisioning Services server causing a server failure.
Provisioning Services - Shared Storage
Definition: The fifth option for write cache storage location is on the Provisioning Services server's shared storage. This option utilizes a share storage solution that is connected to the Provisioning Services server.
Benefits:
- The shared storage solution allows for Provisioning Services high-availability as each server can access the vDisks and the write cache.
- Size concerns are mitigated because shared storage devices typically contain significant amounts of storage and can be expanded easily.
Concerns:
- This is one of the slowest solutions because requests to/from the write cache must cross the network and be serviced by the Provisioning Services streaming service. The Provisioning Services server must then forward the write cache requests onto the shared storage, thus resulting in two network hops for the write cache.
- Provisioning Services scalability is impacted as the streaming service is responsible for handling Provisioning Services write cache requests and forwarding them onto the shared storage.
- The solution requires the installation and configuration of a shared storage solution into the environment. If one is already present, then this concern is mitigated.
Best Practice:
Based on the aforementioned criteria and the explanation of the different options for write cache, XenApp servers provisioned with Provisioning Services are best suited for
- Virtual XenApp Server: Target Device - Shared Storage
- Physical XenApp Servers: Target Device - Local Storage
Please comment with your thoughts or if there is another best practices you are wondering about. The list has already grown based on feedback from previous blogs. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
Daniel
Follow Daniel's Blog: http://community.citrix.com/blogs/citrite/danielf
Follow Daniel on Twitter: http://www.twitter.com/djfeller
Finally, XenApp server farms are going to be easier to manage. Am I the only one jumping for joy? As many of you have heard by now, XenApp Platinum is going to include Provisioning Services. This is an announcement I've been waiting for, for quite a long time. Provisioning Services is a great secret weapon for maintaining any system, but I'm going to focus on is XenApp. If you want a great overview of what Provisioning Services will do for you, take a look at Vinny Sosa's blog. What I want to focus on are the best practices for integrating Provisioning Services for XenApp.
The first best practice, is one you need to decide very early on in your build-out... What type of vDisk should you use? Private, Standard or Differential. Take a look at the three options below:
| Standard Image | Private Image | Differential Image | |
| Description | Each target devices stores vDisk writes in a unique change file that is destroyed upon each target device reboot. | Each target device has a dedicate vDisk image configured in a read/write fashion. All changes are part of the vDisk. | Each target device stores vDisk writes in a unique file that is kept upon subsequent reboots, allowing the server to keep configuration changes, until the base vDisk is modified. |
| Benefit |
|
Complete personalization of the environment because all changes are stored, but at a cost of storage and support. | Allows for greater levels of system personalization by not discarding system-level changes upon subsequent reboots. |
| Recommendations | Standard images are a recommended best practice for XenApp servers. XenApp servers delivering the same applications should be:
|
There is little need for Private Images in a XenApp environment because of the differences each image will take. This will go against the core best practice of consistency. | Differential images are appropriate for a small subset of use cases where users have the need to install their own applications. In a XenApp environment, this is not recommended. Once the base vDisk is modified, the differential image is destroyed and the user must rebuild their personality into the target device. |
Standard Image is the way to go. The benefits are great. They align completely with the best practices for XenApp servers... Consistency. The standard image is the key to consistency. But how can a single image be used for multiple XenApp servers? If I install the operating system and XenApp onto a base image and then use the same, exact image to hundreds of servers, aren't there issues with farm membership, especially as each server has the same name?
This is the really cool thing about Provisioning Services. Within the console, you define each target device with a name and a MAC address. The MAC address links the defined target device within the Provisioning Services console to the actual physical/virtual server. Whatever name you enter will become the actual computer name of the streamed server. The Provisioning Services streaming service inserts this identification information into the stream. So, Provisioning Services takes care of the computer name, but we still have to deal with XenApp farm membership.
Included in the base image, along with the operating system and XenApp, is the XenApp Prep Tool. Immediately before you create your base image, you run the prep tool. This tool does exactly what you think it should do, it prepares the XenApp server for streaming by removing items (local host cache, Resource Manager local database), stopping services (IMA Service, Citrix SMA service) and a whole slew of other things. The XenApp Prep tool also creates a new service so when the base image is streamed to any target, the XenApp Prep service starts and begins the personalization and integration into the XenApp farm. It does a whole bunch of things, but of importance is the changing of the STA ID (they have to be different), updates certain registry keys to force the XenApp server to request updates to the local host cache, recreates local XenApp databases, and restarts XenApp services. I've left off a few items, but essentially what happens is when the XenApp services start, they will try to communicate with the XenApp farm. If the server does not have a presence in the farm yet, it will automatically be added. If the server has a presence, it will simply receive its local host cache from the data store automatically. If you want to get more information and the XenAppPrep tool, get it from here:
If you want to see it in action, take a look at this video
Please comment if there is another best practice you are wondering about. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Plus more if we get some good ideas on other areas of focus.
Daniel
Follow Daniel's Blog: http://community.citrix.com/blogs/citrite/danielf
Follow Daniel on Twitter: http://www.twitter.com/djfeller
When you hear the term "Cloud Computing", do you see the big, beautiful, puffy white cloud we typically see on a calm summer day or do you see a dark, menacing thunderhead that spells impending doom? Probably a little bit of both (isn't that always how life is?). Cloud Computing has great potential to provide significant savings and automation to any business' IT environment, so why haven't you started moving to the cloud? Probably because some things scare the hell out of you, like the following:
- Security: Do I really trust a third party to hold my corporate data? Many cloud computing providers have extensive security processes in place to help mitigate this concern, but this data is the lifeblood of your organization. If it is stolen, your entire business might be at risk. It doesn't matter how many assurances you have from a 3rd party, losing the data might spell the demise of your organization or open you up to expensive lawsuits.
- Compliance: Depending on your organization, you might have to adhere to different restrictions to gain a certain compliance certification. Ever hear of PCI-DSS or HIPAA? These are the ones most people think of, but there are many more depending on your industry. How easy will it be for you to prove you are in compliance when you systems are in the cloud?
If these are some of your major concerns with moving to the cloud, does that mean you are stuck running your IT like you have been, or is there still a way for you to implement cloud-based efficiencies into your own IT environment?
Let's make this simple, cloud computing is essentially using technology to provide a dynamic, scalable computing environment where resources are virtualized and delivered over the Internet securely. OK, definitions are always good, but how do I put this into practice? By using the Citrix Delivery Center. The CDC is a set of solutions that, when integrated, provides a virtual, dynamic, scalable application delivery solution securely over the Internet. An application is simply what you need to do your job, which could be a web application, windows application or even a desktop.
Let's break the key areas of cloud computing down further:
- Virtual: This is an easy one. First, you virtualize your servers in the data center. This will allow you to more fully utilize ALL of your hardware resources. Through XenServer virtualization, which is free by the way, you can use all of your server for any number of different workloads at the same time. You bought the hardware, might as well use it without waste.
- Dynamic: An SAP server is not just an SAP server. A XenApp server is not just a XenApp server. These servers can be anything you want them to be based on the current business situation. Need a new XenApp server, no problem, just use Provisioning Services, which is part of Citrix Essentials for XenServer or Hyper-V, to deliver a new XenApp server in 30 seconds. Need to reduce the number of XenApp servers while adding capacity to SAP? Use Provisioning Services to do just that without adding new hardware. The time it takes to build a new SAP or XenApp server is roughly 30 seconds and this entire process can be automated by designing appropriate workflows for your business with Workflow Studio.
- Delivery: The first question is what do you want to deliver? Desktops or applications? How about both? Use the underlying virtual and dynamic infrastructure to deliver a virtual desktop (XenDesktop), which is correctly populated with the right applications for the user with XenApp application delivery. Not into virtual desktops yet? No problem, but I bet you are using applications. Use XenApp to dynamically deliver the applications to any endpoint.
- Scalable: Scalability means getting the most bang for the buck. First, you need to use the infrastructure that is best aligned with your delivery solution. Are you using XenApp for application delivery, then your most scalable solution is XenServer due to the optimizations to make XenServer optimized for the XenApp workload. What about web applications? Many of the communication tasks a typical web application does can be offloaded by NetScaler. This means your web server can support many more users because the expensive processing tasks are handled by the optimized NetScaler.
- Security: Last but not least is security. Remember, a cloud is going over the internet and you had better make sure your communication is secured. NetScaler has the Access Gateway functionality to provide SSL-VPN access. If you are only delivering desktops and applications with XenDesktop and XenApp, your environment is even more secure because all traffic occurs on two ports (ICA and CGP). This means there is no need to install a full-blown SSL-VPN client on your devices. All you need is a web browser. Don't forget about your data, that is your lifeblood. Use NetScaler to create policies to disallow saving files on the endpoint, or printing, or even running certain applications from unapproved locations. Last, but definitely not least, are the web applications the organization is delivering. We need to make sure sensitive information is kept hidden, like social security numbers and credit card numbers. We also want to make sure our web applications are hit by different web attacks, like SQL injection, cross-site scripting, etc. The Application Firewall component of NetScaler protects us.
Does it seem like a lot to take in? Remember, the goal is to turn your environment into an enterprise cloud, which requires you to re-think how you deliver applications to your users. Of course you get the most cloud-like environment by doing the entire suite but the nice thing about the Citrix Delivery Center is that you can pick and choose the options you need. They all plug into each other to create a unified enterprise cloud environment. I encourage you to take a closer look at the Citrix Delivery Center to see what you can do to your IT environment to achieve the efficiencies of enterprise clouds.
Daniel
Q: Any recommendations for hosting or streaming components such as .NET, Oracle Drivers, MQ drivers, teradata, DB2, etc ?
A: Many core OS components will need to be installed as part of the base image. Things like anti-virus, drivers, .NET.
Q: Is there a place to find this "Leverage Existing Infrastructure" slide or the info later on?
A: Yes. In the next few days there will be 3 articles released to the knowledgebase called: Simplifying Application Delivery to the Virtual desktop (Reference Architecture, Getting Started Guide and Implementation Guide). The item you are interested in will be part of the Reference Architecture.
Q: Can you elaborate on the nature of the Citrix Receiver? One of the main benefits to XenDesktop, supposedly, is that it's clientless. It seems that the Citrix Receiver is a client...
A: Nothing is clientless. Even a web browser is a client. But in order to get to a virtual desktop, you will need a client application, the Citrix Receiver. Now the nice things about the Receiver is you aren't forced to install 20 different clients. This one client will provide you with all the features needed to receiver your virtual desktop.
Q: Could we possibly see a demonstration of a virtual desktop session?
A: You can take a look at the items on this page: http://www.citrix.com/English/ps2/products/demo.asp?contentid=163057#top
Q: If we pre-cache the app on the VDisk - aren't we coupling the app with the vDisk.
A: Not really. I consider installing an application to be coupling the app to the vDisk. Doing a pre-cache just optimizes the write cache so the app starts faster. Remember, with streaming, the application is not installed and you only see the applications you have been granted. Now if you have pre-cached an application and you now have an application update, do you update the pre-cache? Depends, of course. If the update is major, meaning it changes many files, then I would update the pre-cache because these updates will cause the write-cache to expand. However, if the update is minor, meaning it only changes a few files, just update the application profile package and forgo the pre-cache updates. When the pre-cached application starts, the updates will be streamed down to the virtual desktop. This will increase the size of the write-cache, but because the updates are so small, the write cache growth will be small.
Q: Do you maintain a list of applications and how resource intensive they are?
A: There is a Citrix site called Citrix Ready (CitrixReady.com). There are a fair amount of applications listed on that site.
Q: For those of us who have not moved into the XenApp Realm yet and are trying to determine which product meet our needs, is there a better source of information, or a 'buyers guide' that helps us determine the correct path, XennApp, XenDesktop, etc?
A: See if this document helps: http://www.citrix.com/%2Fsite%2Fresources%2Fdynamic%2Fsalesdocs%2FXenApp-XenDesktopTogether.pdf
Q: How many users can access a single vDisk from Provisioning Server with XenDesktop? An example...How many Provisioning and DDC servers will I need for 500 employees vs 1001+ Employees?
A: Take a look at this recently completed scalability document. http://support.citrix.com/article/CTX119775
Q: If I still have to manage the client why would we want to create XenDesktop? I am not seeing the return based on the large infrastructure this will require to install.
A: Excellent question. There are many scenarios where it makes sense. Below are a few, but there are many more. It all depends on your business and challenges experienced with the distributed computing model. # Forgo workstation upgrades but still utilize the latest Operating System and applications. Ever run Vista on an old workstation? You can now
- Use Desktop Appliances: They are slim devices that simply connect to a virtual desktop
- Remote users: Use your home computer without having to install apps or copy company data
- BYOC: Bring Your Own Computer allows you to use your own personal workstation while still having a secure and separate corporate computing environment.
Q: Since streaming is regarded as a primary delivery recommendation, how do you get the network team on board since they occasionally present resistance towards this distribution method
A: Yes, working with the network team is critical. How much data do you think is transferred just to boot the OS? Remember, we ONLY stream the parts needed. So even though Vista is gigs in size, we are only streaming about 180 MB of data. XP is roughly 90MB. However, for enterprise deployments, you would want the physical design of the environment to have both ends of the stream to be in close/fast proximity. The Provisioning Server should be located on the same high-speed network as the XenServers that will receive the stream for the virtual desktops. This helps control where the network usage is going to occur.
Q: You mentioned that if there are applications that need a lot of resources and they are installed on XenApp server they could hog the XenApp server. Does XenApp have an HA (high availability) architecture that would allow distribution of the XenApp load dynamically to hot standby XenApp servers?
A: XenApp does have a powerful load-balancing solution to distribute load based on any number of configurable parameters (CPU, memory, page swaps, user load, etc). However, these algorithms only come into play during the start of a new session. Once your session is on a XenApp server, that session remains on the XenApp server until the session is closed. So, you could wind up with a bunch of users on a XenApp server (which is good), until someone runs a resource intensive application that can potentially slow down the entire server because resources are shared.
Q: You recommended Stream Applications for Base, Anomalous and Resource Intensive apps. Stream from where, from XenApp?
A: Yes, application streaming comes from XenApp. The XenApp servers will manage application enumeration and launching. If you select a streamed application, you will obtain the stream from the Application Hub (like a file server) controlled by XenApp.
Q: What is a hosted application?
A: A hosted application is one that executes remotely on XenApp. All resources used are resources on the XenApp server.
Q: What happens when Provisioning Server goes down? Are existing workstations cached and still working and only new stream requests are impacted? Or are all workstations down?
A: Because there is no local disk on the provisioned desktops, if Provisioning Server fails, the desktop pauses until the stream is reestablished. This is why we recommend turning on the HA option for Provisioning Server. This will help overcome this potential risk.
Q: When pre-caching the streamed apps, would you recommend storing those in the base OS vdisk or in a separate disk attached to the VMs?
A: Pre-cache into the OS vDisk.
Q: When Streaming apps, will I run into problems when I have a suite of applications that make calls to each other. I.E. MS Office, Email and Document Management Systems?
A: Not with XenApp 5 application streaming. In previous versions, applications could not talk to applications in different streams, but that challenge was overcome in XenApp 5. So if you put Word, Excel and PowerPoint in separate application streams, they can still work together.
Q: Would this work for remote users, or is network connectivity required
A: Right now, you need a network connection. But Citrix has announced Project Independence which provides a client-side hypervisor where we can think about doing offline virtual desktops. Take a look at the video: http://community.citrix.com/display/xd/independence
Q: What is the process for preparing an application for streaming?
A: You need to run through the installation of the application with the Streaming Profiler. The profiler will take the installation and create an application package used for application streaming. Once the profile is created, you simply publish it like any other XenApp application.
Q: What is the typical time to first launch for a streamed application?
A: It depends on the application size and the network speed. When properly configured, the actual streaming of the application should be very fast, one or two seconds)
Q: What type of apps are not appropriate for this solution?
A: There are still some issues with applications that install services on the system or install OS-level items (.Net, drivers, etc) . Many of the other challenges have been overcome.
Q: Are streamed applications isolated to the extent that they are not aware of and cannot interact with another streamed application?
A: Yes and no. Yes in that what you say is correct. Streamed applications do not interact with other streamed applications. However, in XenApp 5 you can configure rules for the applications so they can talk to other streamed applications. It is a pretty cool feature that overcomes some major challenges with application streaming.
Daniel
For those of you who were not able to attend the live event or wish to re-watch it, you can get to the recording by going here: http://www.citrix.com/English/NE/events/event.asp?eventID=1685355
Q: Where can I get NeScaler training
A: You should check out the Citrix Training website for information on classes and locations. (http://www.citrixtraining.com/courses/courses/index.cfm)
Q: Is there Web Interface and XML Broker Monitors part of Citrix Access Gateway Ent.?
A: Access Gateway Enterprise Edition is a component on the NetScaler platform. In order to use Access Gateway functionality along with the load balancing functionality, you will need to have the correct license for the NetScaler platform. Please take a look at the Citrix NetScaler Editions description (http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=1683492)
Q: In the demo being shown, if the application is only available via the Minneapolis datacenter, but the user is closer to the Ft Lauderdale datacenter, is it possible to configure the NS/AG to redirect the connection to the Minneapolis NS pair instead?
A: Excellent question. The challenge with your question is that NetScaler does not know which application you intend to launch when it decides the most appropriate data center. Even if the NetScaler sends you to the Ft Lauderdale data center, you will still be able to launch an application only available in the Minneapolis data center, but you still have your SSLVPN session going to Ft. Lauderdale.
Q: If you have redundant WI and/or XML Broker servers set up does NS determine that the Primary has gone down and alert the admin that redundancy is no longer there?"
A: These should be SNMP traps that you could pick up with a management tool to alert the administrator.
Q: What happen if we have two sites with different subnets and we have two DNS over NAT?
A: Two sites with different subnets, NAT, etc is fine. Your configuration will just be different and include different addresses. With multiple DNS servers, you just need to make sure that the fully qualified domain name you setup as part of Global Server Load Balancing is configured on both DNS servers to point to the NetScaler devices, which are the authoritative DNS servers for that domain name.
Daniel
