Ron Oglesby

Where is all this virtualization going?

2006-08-28T02:00:00Z

I sat down with a client the other day and was asked some pretty simple questions that couldn’t easily be answered. Those questions were, “So where is virtualization going anyway? Not in the next 12 months, but in the next 2-3 years? What should we know about virtualization that’s going to mean big changes like the first implementation we put in of our virtualization platform?”

This drove an interesting discussion with some follow up on my part in both research and some long thought over numerous cold beers and a whiteboard. Once I figured out where I thought it was going, I started putting my ideas into Word and figured more people than just me would be interested in where this is all going and why it’s important. Of course I have no crystal ball--this is just one guy’s opinion of where things are and where they will be going. (Feel free to comment with your thoughts.)

Right now you can talk to any company paying lip service virtualization or that considers themselves virtualization experts and they will begin to talk about the “future” of virtualization. Inevitably they all say some (or all) of the following:

Virtualization will expand beyond just servers and into the desktop realm. (Mostly people are talking about VDI here, and of course about five different packages for VDI have been released this year alone.)
Virtualization will take the next step into the enterprise expanding beyond server consolidation.
Virtualization technology’s next step is to get better performance from VMs to assist the move deeper into the enterprise.
Virtualization may act as a conduit for software vendors to deliver application appliances to you preconfigured and ready to go, You just modify some settings for your environment and you are up and running.
Built-in virtualization technology at the hardware level will take it to the next step. (Here we’re talking about processors that are moving system calls for VMs out of Ring 0 and into “Ring 1,” or Network adapters and HBAs that have built-in hardware hypervisors to allow for better control and resource allocation at that level.

Anyway, if you read this the way I do, I don’t see anything huge here. I mean when ESX really started making an impact in IT a couple of years ago it did so because it changed the landscape of IT infrastructure as we know it. It changed the way servers were provisioned and spec’d out, how they were purchased, and the number purchased. It changed every calculation we had been making from the cost of the servers to amount of HVAC, floor space, UPS capacity, power, network requirements, and storage we needed. It changed the mindset of architects and engineers when designing solutions and gave them options they never dreamed of. It allowed the businesses to drive down costs while still providing the same levels of service on a lot of applications all the while decreasing recovery time for individual applications both locally and during DR.

Do any of the “future of virtualization” statements above come anywhere near to having this kind of impact? Or does it really just extend the existing benefits a little bit without changing our mindset and the way we’re already doing things with our virtualization technology of choice?
In a drive-by world where everything is “what can you do for me today,” most people aren’t looking at the reality of this technology’s future. The reality is that sooner or later it’s going to be a commodity just like hardware. Face it, virtualization is just another way to supply hardware to an operating system and its applications. The future of virtualization isn’t in the stuff listed above. These items (for sure the hardware) will have an impact on how virtualization is done, but software that virtualizes hardware (in a couple of years) will be a commodity just like the hardware it runs on. When you select that software you will do so just like you purchase hardware. Right now I believe that the real race going on in the virtualization space isn’t about who can Vmotion or support four processor VMs, etc. The real race is about who has the first lightweight fully integrated hypervisor that is OEM’ed on servers and desktops. (That’s right, I said “desktops,” but we’ll get back to that in a minute)

When people talk about a hardware hypervisor (Microsoft, a hardware vendor, VMware, anyone), most people listening assume this is built right into the hardware and then you will install the OS’es right into this. Let’s be realistic. Even when it’s “built right into the hardware,” it’s still software. The line between hardware and software has blurred over the years with on-board BIOS’s for hardware components that are fully configurable and upgradeable. The only thing keeping them from being their own OS is that they can’t manage other hardware components and you can’t install an app to it.

Now let’s picture a world where you buy an HP server, with OEM’ed Qlogic HBAs, Intel or OEM’ed Intel nics, memory from HP or Crucial, or (insert favorite vendor here), processors from AMD or Intel, drives from... you get the picture. Even if the processors, NICs, and HBAs all had hardware hypervisors built-in to them, what controls those hypervisors and connects VMs to them? What connects a virtual machine to each of these components? Right now the closest thing to bare metal is ESX. And improvements to the hardware will make ESX’s performance even closer to raw hardware performance. But what is the future? The Future is a thin layer that is OEM’ed that can work with and control all these devices. It will not be as bulky as any Windows or Linux OS you have ever seen and will more closely resemble a glorified piece of firmware that boots and starts dividing up resources to whatever number of VMs you have running on the machine. Of course it will still have some type of interface while the server and its VMs are running, but it will be extremely lightweight and self-sustaining. This will come with every x86 server and desktop. What you will buy is not the hypervisor but the management tools that wrap around it. That is the key and this is where we bleed into desktops a bit.

Right now on a desktop you have a single OS. (Let’s not talk VMware workstation of Virtual PC for this article) with applications installed, Anti-Virus, Spy/Malware detection and removal software, an Internet browser, etc. What if your machine didn’t look like this? What if your machine looked like the image below?

In this example all four VMs would load at boot time. The network and security VM would be the first one up after the hypervisor loads. This VM will scan all traffic in and out almost like a network virus wall or a SMTP gateway server. It could be a one-stop shop for traffic scanning, IDS, IPS and even traffic scanning between VMs. This security VM may even be a VM that comes OEM’ed along with the hypervisor.

Next is your trusted desktop. This is where you work normally on your corporate LAN and interacted with trusted machines/networks. What machines and networks are trusted is configured in the security VM and is possibly centrally controlled by an administrator. The cool thing is that if this is a personal laptop or computer you may be able “outsource” your security by buying a subscription to “Symantec’s Security VM Package.” (I know, it’s a lame name, but it’s all I could come up with.) Anyway, the package may be purchased and delivered to the user to replace an existing one shipped by the hardware vendor (back to application distribution by VM appliance). They can then offer you a service where they update the VM (like getting new virus definitions) but in this case it’s virus, malware, spyware, firewall, etc., and it’s not tattooed in the trusted OS and can be hardened in ways that the trusted OS can’t while still remaining functional.

The trusted desktop is now behind a line of security that will protect it from the outside and from other VMs. Then you have a default non-trusted application VM. Maybe this VM runs applications like an Internet browser, media player, etc. This VM (or more likely its applications) is invoked whenever the user makes a call outside its trusted area or uses an application specifically configured for high security. This application is then presented to the trusted desktop (kind of like an ICA seamless window) but is actually running in another VM. The non-trusted application VM might not even have an entire OS like we know it. Instead this VM may be another VM Appliance that has a small OS that loads just enough to support that browser app and a few multi-media type apps and presents the screen (like ICA or RDP) into a window in the Trusted VM.

Finally, you’ll have the ability to add other VMs as needed. Maybe you’re contractor like I am and need a specific build with a specific virus package and hotfixes to connect to a client site. This hypervisor’s configuration would allow for that to be added, and may even have a rule base setup in the hypervisor that says, “When Contract A VM is turned on the trusted VM isn’t able to connect to the network.” Then when I am at the client site I invoke their VM (maybe by booting it, or maybe by simply using a hotkey sequence almost like an Alt-Tab) and I am ready. Their security team could even have these VMs preconfigured for delivery to contractors or even new employees. (There I go again with Virtual Appliances, only in this case it’s a home grown one.)

As you can see the concept laid out above would solve a number of issues and change the way we do desktops. It would increase security, allow for isolated work environments that are independent of each other and allow for minute control of the desktops at a level we don’t have now. In addition it would allow vendors numerous options, like delivering security packages in whole to a desktop and not worrying about “what rev of windows do they have, this doesn’t run on XP SP2” yet, etc. Hell the firewall VM may even be able to allow you to shut down network connectivity from that machine after so many days without an update. Wouldn’t that be cool!

Anyway, with the impact this could have on the desktop and the complexity that it would introduce from a management standpoint, I think you can see where I am going by now. Imagine the following environment at the server level:

A security VM independent of the hypervisor that can does IDS and IPS for all the VMs on the host along with acting as a network virus wall.
A configuration VM that manages the hypervisor on that box that is independent of the security VM but relies on it.
A VM appliance supplied by your backup vendor that you put on each server that acts as a backup job manager for each VM This would manage backup resources of VMs on that host ensuring that not all the bandwidth or processing resources were being hogged by doing a large number of VMs at once. It just detects the VMs running right now on that host and (based on configurations from the centralized management server) schedules and moves jobs accordingly.
A central management tool to handle the configuration of the hardware hypervisor, the management and interaction with the hardware, and the startup sequence of the appliance VMs that will support the application VMs you’ve installed.

Really, the numbers of things that can be done on the server side are endless, and I’ve just touched on a few. But the bottom line is that in the future the hypervisor will be a commodity. The future of virtualization is a lightweight hypervisor that will manage the hardware and its extended capabilities being built into NICs, HBAs, disks, processors, etc., to support numerous OSes/VMs on a single server. No hardware fix will show up to make Intel, Broadcom, AMD, QLogic, Emulex, all be managed the same way by some piece of firmware on the motherboard. Nope. It will be software and it will be installed on every server that roles out of HP or Dell or IBM. You may still choose to use only one OS but you don’t have to.

Now you may ask, “Who will provide it?” Who knows? My bet is VMware gets there first. They just have too much of a lead in second quarter of the game. Whoever does it will more than likely provide the hypervisor for little cost to the OEMs with each server coming with a limited single host management tool. Then you would be able to purchase the additional tools to provide management to large numbers of hosts, their VMs, and the appliances being installed. This of course is all in addition to the things that tools like VirtualCenter already do (Vmotion, resource balancing, VM provisioning, automated host recovery, etc.).

My guess is you will pick the hypervisor like you pick hardware vendors. You go into a shop with all HP servers and they basically run HP because they like the support, the tools available, the response they get from sales etc. You could say the same thing for an IBM or Dell shop. You will find the vendor that fits your needs and then buy in bulk. But the key will be the tools and mgmt options. You don’t find organizations buy 2 Dells this week, 4 HPs next week, 3 IBMs the following week. They purchase a standard and stick with it for they have found the vendor of a commodity that fills their needs. (I mean really is there that much difference between a dual proc box from any of the vendors?) The reasons for purchasing hardware will be stated for the hypervisor use in the future. It’s just going to be an extension of the server. The other things are what’s really important.

Citrix plans to enter VDI space: An analysis of their solution

2006-08-03T08:45:00Z

Since my last article on the Virtual Desktop Infrastructure (VDI) topic, I have received a number of e-mails. Some show interesting tips, some are just angry at life (and me specifically at the time of their writing), and some point out some interesting solutions that are trying to fill the ‘pie in the sky’ VDI solution I discussed last time.

Now personally, I haven’t seen a solution that makes me jump up and down saying “this is the end all be all for VDI!” However, I have seen some interesting takes on the problems I pointed out previously. Because of the e-mails and calls I received, I’ve decided to do a series of articles on the different VDI solutions available today. In this article I’ll discuss a solution (forthcoming) from Citrix for VDI implementations, and in future articles I’ll look at packages from Leostream, Propero, and any others I can get my hands on.

Before I get into the Citrix solution I need to qualify it some. First of all, the Citrix solution is not on the street yet (while the ones from Propero and Leostream are). Second, the Citrix solution I’m going to describe is a “stopgap” solution. Citrix is working on a full featured solution for release at some point in the future and is targeting a solution that covers most of what I described in the first article. The solution they are going to release now is a stopgap to help their existing customers with the VDI issues they face and is not meant as the end-game.

Okay, with the qualifications out of the way let’s talk about Citrix’s stopgap solution they’re calling the “Remote Desktop Broker” (or RDB). The concept with RDB is pretty simple; it’s an application that can feed parameters into the RDP client and provide you a way to manage connections and create resource pools of desktops (VMs, blades, etc.). The RDB application is installed on a Citrix Presentation Server and then published as an application. Users execute the application which then connects them to the type of desktop they (or the app) is configured for.

I’ll get into more detail on HOW it works in a second, but for now understand that it’s an application, not a server, and because of this is it uses a double-hop scenario with ICA connecting to the Presentation Server and then RDP connecting from the Presentation Server to the virtual desktop.

If you imagine an exiting Citrix environment (shown above) using an ICA client to connect to a Presentation Server, you’ll note that you have some of the items you need to provide a really solid VDI solution. You have a web interface that will allow for “publishing of the desktop,” you have the inherent SSL connectivity for remote users that Citrix already provides, and you have some session management and some tools to show connections and their status. So what’s missing? A way to pool desktop resources, handle peripherals, etc. Citrix’s RDB will handle some of this for you.

Citrix’s RDB will sit on top of your existing Citrix infrastructure. The concept is that the desktop broker application will be installed on your Presentation Servers. This application will communicate with an RDB database that will contain connection information for different pooled desktops. As pooled resources are used, they will be noted in this database so that the desktop is noted as “in use” and the next user will be routed to an unused desktop. If you look at the image above you’ll see that a connection will look something like this:

User connects to a Citrix Web Interface server (or uses some other Citrix client)
Based on the credentials, a published application is made available for that user (in this case the RDB application).
The user launches the RDB application and is connected to the Presentation Server via ICA
Once the application loads, the user is routed to virtual desktop based on information in the RDB application. This is basically passing parameters to the Microsoft RDP client on the Presentation Server to tell it what end desktop to connect to.

During execution RDB is going to check its database to determine which desktop is available from the pool the user is connecting to.
This information is passed to the RDB application which in-turn uses it to establish an RDP session to the Windows XP VM or blade.
When the application is closed the desktop is released.

In looking at this you’ll notice right off that be that this is a “one session for the price of two sessions” deal. It’s a double hop. While it gets you to the desktop, its obviously not the most optimal configuration around. Citrix knows this, and this isn’t their long term design, but with this should come some cautions.

Speed screen latency reduction features will not help here. Most functionality/assistance you get with speed screen latency reduction features focus on making the users think that latency is not effecting their ICA session. Basically it works by detecting the font and size and color of the text being typed in the Citrix session then instead of waiting for that text to appear on the client it shows it on the client before the round trip communication ever happens. In this case the RDP client is essentially an image or movie like application and typing within it is an image change, NOT text within a field or form on the Citrix server. (Check out this article for more details.)
Not all features available in Citrix will be available in the RDP session. There will be some features (noted later in this article) that you are used to with Citrix, but since it is not ICA to the XP Pro, it will not be full featured.

I could put a third point here about it being a double hop, and the cost of a Citrix license without getting full features, etc., but I think that’s implied with these two other cautions.

In caution number two I noted that you won’t get all of the features (Speed screen, good printer redirects, driver replication, pure session mgmt in the XP pro desktop etc), but you will get some. Citrix plans to offer the following:

Client Drives Access. Users can share drive mappings between their hosted desktop and server drives. I must note I had mixed results with Client drives mapped to the Citrix session then mapped to the XP Pro session, but server drives did show up in my XP Pro desktop.
USB Key Drives. Users can access USB devices through their hosted desktops; however, the key must be connected prior to session startup.
Audio. Users launching a hosted desktop the user can hear audio (for example, using Microsoft Media Player), though this may require some ICA channel reconfiguration if you use RDB on an existing application host.
Single Sign On. When the user logs into the Citrix Web Interface and connects to the published hosted desktop, they can be automatically logged into their virtual desktop using Citrix Password Manager. This one was kind of a pain for me as I do NOT use password manager and I was required to sign into the Web Interface and then Sign in again to the Virtual Desktop. (Suggestion: Password Manager for free would be nice!)
Printing. Users can print to locally installed printers as well as network printers. I had a couple of interesting issues with this that I believe are more related to the XP Pro desktop than the Citrix session. Again it leads back to not having a control agent with the XP Pro desktop and needing to do some manual configuration on the images used by the users.

The long and short of this solution is that it is a stop-gap. Basically it’s an application that will allow you to create pools of VMs or XP blades for your users, and use your Citrix servers as a proxy mechanism. Citrix is hoping that it can help its existing customers get over the big hurdles here by delivering a brokering mechanism and allowing them to leverage the existing Citrix tools to solve the other issues I’ve previously mentioned (secure remote access, web-based authentication, etc.).

The disappointment to me is that Citrix wasn’t out in front of this a long time ago. Last year at VMworld people were all over themselves talking about Citrix servers on VMs or about running VM workstation instances on Citrix (which, by the way, is a ridiculously stupid idea) instead of focusing on creating real VDI tools and solutions. Hopefully the time-to-market on this won’t be too long and the follow-on product that will solve most of this product’s issues will not be to long of a wait.

In my next article in the series I will take a look at Propero’s VDI solution. I was going to use Leostream’s solution first but had a slight issue with it during configuration that I will have to discuss during the article. As always, e-mail or post comments, I look forward to most of them. J

Virtual Desktop Infrastructures (VDI): What's real today, what's not, and what's needed

2006-07-20T11:00:00Z

Over the last several months, the concept of a Virtual Desktop Infrastructure (VDI) has become the buzzword in a lot of IT shops. Organizations are using (or looking to use) VDI to solve a number of issues they are facing. Of course, for the last year I’ve been talking about what VDI is missing in order to make it a real solution and why it can’t beat Terminal Server in a lot of cases. Well, maybe I have seen the light. I mean for some problems, VDI is a perfect fit. For others it’s not so perfect but is still being crammed in nonetheless because someone hates Citrix or TS (or just loves VMware).

In this article, we’ll quickly go through an example use case that a VDI solution will fit almost perfectly and the types of use cases where it doesn’t fit. (When VDI doesn’t fit it’s generally for cost reasons. I mean it would be great to have multi-node clusters for every server on the network but we don’t do it because of cost.) Once we look at the history of SBC and when to use VDI, I’ll then draw a “pie in the sky” VDI solution from the bottom level (the VMs) all the way to the top level (the management tools). I’ll note the components of the solution that are already available and, more importantly, describe in detail the components do not exist yet that are being looked at by numerous vendors.

Before we get started, I want to point out that a number of organizations are implementing or have already implemented VDI solutions. For the most part, these solutions have been cobbled together with scripts, snips of custom code, hacking of existing products, and of course good old duct tape. This article describes a theoretical solution that could be implemented by a single vendor or two with a couple of core technologies, I am NOT saying that the items I say don’t exist can not be accomplished with hacks and tricks—it’s just that no solution on the street has been developed as a package to address specific VDI shortcomings.

What is VDI?

First let’s describe VDI from a high level and compare it to more traditional server-based computing models.

The image on the right shows a traditional SBC model. The users all have access to a desktop GUI via an individual session on the terminal server. This server has a single OS installed; an instance of Terminal Services to provide the sessions and session management, and a set of applications that can be used by all the users on the server.

In the VDI model on the left, a single server is used again, but a hardware virtualization layer is added to this server in place of a more traditional OS like Windows Server. The Virtualization layer provides numerous Virtual Machines that are each supplied with an operating system, applications, and a unique GUI / desktop environment for each user.

As you can tell by the image, a VDI solution provides the same basic functionality of a traditional SBC solution. This functionality is (primarily) to provide a centralized desktop via a protocol like RDP or ICA. Besides the Virtualization layer and numerous OSes, the two solutions look almost identical. (The key word is ’almost’.)

With VDI you gain a couple of benefits that you cannot achieve in a SBC environment, including things like:

The ability to provide a unique environment for each and every user.
Each of these environments can be completely customized with different apps and settings without impacting other users.
Users can be granted more control of their own “virtual” desktop to allow them to install and modify applications if needed.
Applications that were not multi-user friendly (i.e. “we cant get this to run on Citrix”) can be run in this environment since each instance is just like installing the app on a new desktop.

The problems start when you think about the solution from its very basic components. Let’s say your boss decides that you need to provide 100 desktops to developer users in India. Each developer needs local admin rights, the ability to reboot the machine, install apps, etc. Basically every one of them must have their own machine. A few years ago the only way to do this would be to buy 100 desktops, stack them in a room or in the datacenter, load up PC Anywhere, Dameware or some other remote control solution, and tell them to go to town. Of course right now you’re frowning at the thought of this, but really is a VDI solution that much different? You still have the same number of OSes, you still have the same number of application installs, you still have to use some type of third party software to get your users connected to the machines, remote printing is going to be an issue and so are peripherals, etc... Starting to sound kind of lame, huh?

The truth is it’s not that lame. Virtualization has allowed you not to have to buy a hundred new boxes and instead get maybe 4, 5 or 6 servers and create the target machines as virtual machines. This, of course, could drop the solution cost pretty significantly.

This leaves you with several issues that need to be solved, including the connectivity, application installations, application upgrades, OS management, VM provisioning, load management, and of course performance monitoring/management and maybe even a number of peripheral issues. Also (with today’s virtualization technologies) you need to put those VMs (encapsulated in files) onto a SAN if you want redundancy. If not the loss of a single server can create the loss of a large number of VMs and their customizations from the users.

As you can see the basic infrastructure is available to provide the platform. The connectivity and management and other surrounding pieces are missing in order to make this a really competitive solution.

<Preachy Rant>
Before I get too far I should note that I believe that VDI is NOT a Citrix replacement in 95% of the use cases, but instead is a solution that fits specific needs and most likely will run side-by-side with terminal servers to fill these needs. VDI is a powerful/useful technology for UNIQUE desktops or apps that will not run on Citrix or on Citrix via an application virtualization software like Softgrid or Citrix’s AIE technology. If you want to host a call center and all the machines/desktops should be identical with little to no modifications possible, buy a terminal server, have it set up correctly, and save the money by using VDI for unique PC deployments or those “no way it runs on Citrix” applications.
</Preachy Rant>

Okay, so you’ve decided that you need to get these 100 desktops done, but PCAnywhere is so 1999 that you just have to jump on the VDI bandwagon. What issues / needs are you going to have to address, and where can the software come from to address these needs?

Let’s start with a “pie in the sky” view of a perfect VDI solution:

In the perfect VDI solution, you would see an easily managed (one or two tools) environment. If you use Citrix and Terminal Server as your starting point then it’s easy to see what you need. The Perfect VDI solution would have or support the following:

Session load balancing of “pooled” VMs that are identical.
Capabilities to have unique VMs for specific users and still allow them to connect to pooled VMs if needed.
A secure way to access these desktops remotely.
A management tool that would allow you to see/manage the following:

Locate users (which pooled VM are they connected to)
Show connection information (where are they coming from how long have they been connected)
Timeouts for session active and disconnected times
Ability to reset or remotely reboot a VM
Ability to pull a VM out of the pool for maintenance or troubleshooting
Centralized way of publishing and establishing security for the VDI connectivity

A connection method that allowed for the “easily” supported printing and peripheral environment.
Ability to add to the pooled VMs resources as load increases WITHOUT having numerous VMs sitting around idle and eating resources. This is akin to dynamic VM creation
A way to centrally patch and maintain the pooled VMs that is easier than managing a bunch of unique desktops.
Better peripheral support, specifically, printer mapping and management.

When you begin to look at the ideal VDI environment you begin to see it is almost IDENTICAL to a current Citrix or Terminal Server deployment except for the fact the VDI environment has an OS and app instance per VM. This is where the solution begins to loose some of its coolness. You now need to install an OS and its apps, and manage, update, and patch the OS, and the apps for each VM. There may be some ways to simplify that, but before we go there lets look at some of the key features that are needed in a perfect VDI solution, how they are being done today, and how they should be done.

Session load balancing of “pooled” VMs

In most VDI deployments this is not being done (or at least not being done well). In some cases administrators are manually mapping users to VMs by giving the user an IP address or computer name and having them connect via the RDP client. The connection method varies. Some use an RDP file deployed to the user’s existing desktop, some use thin client configured to use a CE based RDP to connect to the desktop, and some companies are hacking/faking out software used for load balancing TS sessions to load balance XP desktop sessions.

What we are talking about is a management tool that allows you to add a list of computer names into a central tool. You would assign that pool a name and then assign permissions to that pool to groups of users. Pie in the Sky would be to even select specific or users or groups of users and allow them to connect to the pool and give them the OPTION to save their VM for later use or not. This would give certain power users the ability to spawn a unique VM from the pool for later use where task-based workers may not receive the option at all. This could also be useful if you have a base image that all users would use (unique and pool users). In another case you could assign multiple groups of users to the pooled resources. Then have the option to allow a submit (unknown to them) to automatically be spun off into a unique VM where session settings and changes are saved. In this case each VM starts with the same base image but only groups or users that are assigned get to “keep” their VM from the pool.

Ability to have unique VMs for specific users and still allow them to connect to pooled VMs if needed

This may sound silly, but the concept of running multiple desktops (or applications) is nothing new. I mean let’s assume your environment grows a bit and you use VDI for some type of custom application that conflicts with everything including notepad. Now you have a user with a thin client (or fat) that connects to their custom desktop that they’ve been using for a month or two, they’ll also need access to the customer application and thus its pooled desktop. This needs to be done easily, meaning that you need an easy connection method, maybe a web interface that allows the user to select a desktop from the ones they are authorized to use or the ability to directly launch the second desktop from within the first (and still support any peripherals needed).

Right now people are using the RDP client to connect to an XP Pro VM. Then they are either establishing another connection with RDP client from their desktop or not doing it all. This will not work in the long run. (I once had to change about 500 users Program Neighborhoods over to published apps and NFuse because these multiple connections where a nightmare.) As VDI expands, this too will become a problem if there is no centralized brokering mechanism.

A secure way to access these desktops remotely

Let’s face it, a lot of the VDI solutions being implemented are for outsourced developers. Not all mind you, but enough that remote access (or should I say secure remote access) is an issue. The basic idea is that the end user needs a simple yet secure way of accessing the desktop that won’t require the hosting company to drop a bunch of software on the remote client. This screams clientless SSL VPN, or possibly SSL encryption built into the VDI desktop client. In addition it means a software package that is Internet facing that could (or should) integrate with some different types of backend directories (e-dir, AD, maybe throw in SecureID).

How are people doing it now? “Hopping” is the only way to describe it. In some situations companies are publishing the RDP client in Citrix. Users then come into a Web Interface server, login, run the RDP client published app, get routed through a Citrix Secure Gateway into a Citrix session running the MS-RDP client, and use it to launch the RDP session to the XP Pro machine. This is essentially a double hop. It works, but it causes overhead, requires a Citrix license just to run the RDP client, and is basically one session for the price of two. In other cases, companies are creating firewall rules and VPN connections to allow users to open TCP 3389 from their PC to the XP Pro box. When doing this it’s often a multi-step process for the end user (we know how that works out) or requires you drop a package on their desktop and support it.

What would be ideal? A single hop that integrates both the session brokering and session connectivity without a middleman. (Think of a secure connection to the XP Pro box that looks like an ICA session to a Citrix Presentation Server.)

I know, I know, I’m comparing a bunch of this stuff to Presentation Server. But hey, if something works, model after it, don’t re-invent the wheel.

A complete management tool for the environment

One of the funnier things I see in the VDI realm is that the Non-TS guys kind of have to re-invent all the hacks that Citrix and Terminal Server guys had to do in NT 4.0 and the early days of Server Based Computing. For you old timers, you’ll remember changing the “My “ icon on the session desktop to %username% on %computername%. Well I’ve seen them doing these in XP Pro VMs. Why? There is no management tool to easily tell you which user is connected to which VM, how long have they been connected, or what is the state of their session is.

These are simple things taken for granted in Citrix and TS since the tools have been there forever. A huge step in VDI would be a tool that looks like TSAdmin.exe or MFadmin.exe but is geared towards the VDI market. (Of course I just had to geek out and make a mock up one that you can see below).

Yeah, I know it looks like a TS admin tool, and it’s supposed to. The same concepts you’re familiar with in TS also apply here. The difference is that this tool would need to show the resource groups available, the individual virtual machines available, and of course the users connected to them. In addition I think such a tool (with the rest of the required infrastructure) should be able to:

Locate users (which pooled VM are they connected to)

Very important for troubleshooting and security reasons

Show connection information

Right now this is not being done or being done by login scripts that note the login time and username in a central access DB for logon and logoff times.

Should allow session shadowing

this could somewhat be done today with Dameware on the machine and the end user connecting via RDP

Timeouts for session active and disconnected times

Some would say you could use domain timeouts (and I already got an e-mail, thanks) but we are really talking about a session open for 29 hours by a single user. How do you know when that happens?

Ability to reset or remotely reboot a VM

Absolute must. I would say you need hooks from this tool to reboot the VM maybe suspend, obviously take it out of the pool of resources, and possibly to log the user off the VM cleanly. Right now people do this by accessing another tool (like with Vmware’s Virtual Center or VS 2005’s web interface, but I would want the application to be able to call the APIs and from this console handle the shutdowns and restarts)

Ability to pull a VM out of the pool for maintenance and or troubleshooting

Noted above but is a must.

Centralized way of publishing and establishing security for the VDI connectivity

Today people are basically doing a one-to-one ratio (VM:User) or hacking together load balancing from other tools. That’s great until you have a centralized way of getting at the desktops and need to restrict Suzie in accounting from seeing the comptrollers desktop remotely. I mean how many of you actually set the local logon rights on desktops? It would be a pain to manage on lots of images.

A connection method that allowed for the “easily” supported printing and peripheral environment.

Yeah. VDI is great until someone prints. Sure there are some ways to get network printers working easily, but then there is the guy in India with a brand new MFC made by some no name company in China, connecting to a desktop in London. Send his support call to Timbuktu because you’re not going to get that printer to work easily.

I would begin to look seriously at some third party companies like ThinPrint for solutions, because I just feel this is going to be a huge issue.

In addition to making printing at least meet the standards of today’s Terminal Server and Citrix environments, you’ll be looking for peripheral support so Suzie in accounting can sync her “CrackBerry” with her desktop. Don’t laugh! If you get VDI running, people will begin to ask for that stuff.

Ability to add to the pooled VMs resources as load increases WITHOUT having numerous VMs sitting around idle and eating resources

This is akin to dynamic VM creation. One thing that has always bugged me about VDI is that it FEELS like WinFrame. Basically if you need to support 30 Concurrent sessions you have to have 30 VMs sitting there whether all 30 are being used or only 2 are being used. Right now this is how most VDI solutions are setup

Now this may not seem like an issue but there is a reason that later version of TS moved to a listener model; it was to reduce the amount of resources used by idle sessions (and these were just virtual sessions within an OS, not the whole OS itself sitting there).

The solution would be to find a way to QUICKLY (read less than 15-30 seconds) provision a VM that’s ready for use. I’m not sure how to do this yet, but its one solution. Another solution (or workaround) would be to determine max load in the farm in any, (say 15 minute) period. If you could accept 6 new logons in 15 minutes then the minimum number of VMs available would be 6. When one is used by a user logging in, another would be created. The one being created would still have a 5 VM buffer before any users tried to get to it. Now this would be a pretty intense solution, and not elegant by any means, but it’s probably just one idea of 100 that other people have to solve this issue.

A way to centrally patch and maintain the pooled VMs that is easier than managing a bunch of unique desktops

Yeah, now you’ve just added a bunch of VMs to your environment that you need to patch and upgrade constantly. Sure you can dump WSUS in there for Patch Tuesdays, or you can use your existing SMS infrastructure, but there is obviously and added cost for this.

Today most people are doing that; using existing tools. Personally I think that if the previous issue is solved (a way to quickly provision VMs) then we will solve this. I mean if the VMs are built and broken down all the time, and when built come from a centralized template for the pool being published, then the template would just need to be updated and through the life of the VM (logon and logoff) the VM would be created with the new patches. This of course solves the problems for pooled VMs, but not unique ones. You still need to manage those just like desktops.

Conclusion

Will VDI take over the world? I doubt it. I think it will have its place just like other “Virtualization” technologies like Citrix and TS, Softricity and AppStream, etc. VDI has a place and will solve issues, but it’s just that—another solution to a problem. It’s not the solution to all of our problems. Right now VDI is in its infancy. Those that go down that road are bound to have to jump some serious technical hurdles to create an easily managed system. Just like the first multi-user systems, VDI will solve your problem today, but will be hard to manage compared to some other systems and require some learning curve for your staff. Hopefully over the next few months vendors will get on board and make some of the technology a reality. Citrix is supposedly working on something to help with brokering of the sessions in a more elegant fashion, but that is for another article.

If you have other VDI challenges or solutions you want to note, post to the comments section of this article. VDI is new, and no one has all the answers. That’s what makes it fun.

BriForum 2006 Video: Ron Oglesby on Citrix Large Farm Design

2005-11-14T00:00:00Z

Ron Oglesby is well-known for many reasons in this community, one of which is his experience with large server farms. (Hundreds of servers, thousands upon thousands of users.) In this session, Ron is going to share his experience with you and talk about what he learned about how Citrix REALLY works when it's put under pressure.

Here's his session from BriForum 2005.

Download the video of this session (WMV format - 67MB)

Download the audio from this session (MP3 format - 15MB)

Download the PowerPoint slides from this session (4MB)

How the Default Load Evaluator can Ruin your Day

2004-12-10T00:01:00Z

This is the true story of a Citrix administrator's worst day on the job. It's about how the loss of five Citrix servers in his environment brought the remaining twelve down, why the default load evaluator is to blame, and how you can prevent it from happening in your environment.

...So I get a call from a client asking me to perform a “root cause analysis” as to why their “entire farm” went down all at once. The words “root cause” coming from this client is pretty strange seeing how most days any problems they have are solved by a simple reboot of the offending server (but I digress). Anyway, I schedule the next day to come onsite and get a concall going to get some initial information.

It seems that the day before the entire farm became “unavailable” in the course of about 30 minutes. The event that seemed to start it was the failure of a single switch. Of course the obvious questions was, “Is your entire farm on that switch?” No, the farm was actually split across four major switches with a switch in each rack that uplinks to these four. The total number of servers in the farm was 18, with 17 hosting apps and a dedicated data collector. The 18 servers were split between 5 different racks because the environment had grown over time and it made sense to keep them separate in case of power loss to a rack or a SWITCH FAILURE in a rack.

After showing up on site, looking at the environment, reviewing the performance data on the servers just prior to “The Crash,” and asking a few simple questions, we quickly figured out what had happened. One simple failure and a couple of default settings had brought the entire farm to its knees.

Here's how it went down:

Switch in rack two fails. This disconnects the users that were attached to Servers 1 through 5. Average user load: 52 users per server.
These 250 odd users then attempt to reconnect to their application via the NFuse page.
The remaining 12 servers in the farm are running at about 51 or 52 users per server.
The Data collector looks at load and begins to distribute users to the server with the lowest load. Server 9 has only 45 users and begins to see a little of the black hole effect referenced in this article.
Server 9’s performance suddenly goes in the toilet. The other remaining servers follow shortly.
Within 10 minutes these 12 servers now have an extra 20-25 users per server trying to connect to them.
15 minutes into this a number of servers are no longer sending performance data or are sending data with “gaps” in it where the server seems to pause.
Users continue to disconnect and reconnect in an attempt to get to a “better server” which only worsens the problem due to the increase in logon and logoff processes.
30 minutes into this process the Citrix admin begins to disable logons to the server but finds a number of them unresponsive.
Well, let's just say its not a pretty afternoon.

So what happened? Some might say he didn’t have enough servers? But unless you go into DR mode who has an extra 25-30% capacity lying around? No, they had tested these servers and found that they could go up to 60 maybe 62 users before performance went in the toilet. But 70-75 users per server was just to much.

To understand what happened you need to look at the Citrix default load evaluator that gets used when you begin to use load balancing with default configurations. This load evaluator looks at one metric only: user count on the server. To make matters worse its default maximum is 100 users regardless of the hardware you have or the applications you are running. This basically means that the ZDC thinks the server can still handle new load until you reach 100 total users. So when this environment lost 5 servers at once the other 12 were asked to accept a load that they could not handle.

The cure to this problem is to setup an evaluator based on your maximum user load and possibly a couple of other metrics. If they had setup an evaluator with a max load of 60 or 62 (their theoretical maximum), the other 12 servers would have stopped accepting connections once they reached that point. Sure 100 or 120 users would have not been able to connect till the servers were brought back up, but it’s better than the almost 900 users that were affected that day for several hours.

Personally I would recommend that you set the user load on your new evaluator right at the point where performance starts to degrade. Sometimes an extra session or two can sneak in beyond the load evaluator settings. In addition I would recommend throwing in some other metrics like memory in use and processor utilization. These are nice generic metrics that almost any environment can use. If you happen to know your bottleneck on your servers use that metric in your evaluator too. The trick is to keep the remaining productive servers/users online even if you have a massive failure somewhere else.

These guys had run on the default evaluator for almost two years without a problem. Sure they would loose a server once in a while or roll one or two out for maintenance, but they never had lost five at once. Of course this situation also could have been avoided if their servers had been patched into more than the single switch in the rack, but then you could always have a power loss in the rack, or my personal favorite, the time a pipe above a server room broke and poured water directly onto two racks. Just because you make the NICs and power supplies and everything else redundant doesn’t mean things can't happen.

Scripting MetaFrame Data Store Printer Mapping

2004-06-28T00:00:00Z

This article is the third in Ron Oglesby’s “Scripting for MetaFrame” series.

In this series of articles I focus on how you can use scripting in a Terminal Server or Citrix MetaFrame environment to automate common and recurring tasks. This article shows a script that uses MFCOM to bulk delete all of the printer mappings out of the MetaFrame data store.

This script is generally used when you’re trying to clean up your environment. It was originally written for a farm that had an enormous list of printer driver mappings (over 1000) that needed to all be deleted to start fresh with a new mapping file. Deleting each of these mappings one at a time via the Citrix Management Console was out of the question, so we created two scripts to do it for us. The first deletes all the mappings from the data store, and the second re-importes a list of mappings from a text file. This allowed us to create a “gold” list of mappings, clean out the old garbage, and import our new mappings—all in a few minutes.

In this article we’ll take a close look at the script that deletes the mappings. Later in the article I’ll provide you with both the DelMap and AddMap scripts, but since they’re so similar I’ll explain only one of them but give you both. (Hey! A two for one... How cool is that?). Let’s get started by looking at the first section of our script:

<package>
<job id="Print Driver Mappings">
  <comment>
        File:           DelPMap.wsf
        Description:    Deletes all Print Driver Mappings from the MetaFrame
    farm Data Store.
        Requirements:   WSH 5.5 or higher.

  </comment>
  <runtime>
   <description>
               Deletes all Print Driver Mappings from the MetaFrame farm Data Store.
          on MetaFrame Servers in the farm. It will save current mappings
   in the OutPutFile for later use.
   </description>
   <example>                CScript //nologo DelPMap.wsf
</example>
  </runtime>
  <reference object="MetaFrameCOM.MetaFrameFarm"/>
  <script language="VBScript">

As you can see this is a WSF script using basic VBS. You can execute the script by using the “cscript” interpreter. Now let’s declare our variables. Nothing out of the ordinary here.

Dim fso, f, ts, LogFileName, OutPutFileName
Dim theFarm, theMappings, Map, sDriver, sPlatform, cDriver

Once the variables are declared we create (or connect to) the FileSystemObject. This will be used later on for logging purposes and to output the “old” mappings to a file for later retrieval.

Set fso = CreateObject("Scripting.FileSystemObject")

The first logic in the script parses the command line looking for an argument. The syntax of this script requires that you specify and output file to dump the current mappings to.

'*****************************************************
'Parse the command line
'*****************************************************

  Set Args = Wscript.Arguments
  If Not Args.Count = 1 Then
   Wscript.Echo "Usage: DelPMap.wsf OutPutFile"
   Wscript.Quit
  End If

Once we notice the argument we then create the output file if it doesn’t exist.

'*****************************************************
'create the OutPut file if it doesn't exist
'*****************************************************

  OutPutFileName = Args(0)
  If Not fso.FileExists(OutPutFileName) Then
   fso.CreateTextFile(OutPutFileName)
  End If
  Set f = fso.GetFile(OutPutFileName)
  Set ts = f.OpenAsTextStream(8, -2)
  ts.WriteLine(Now & " - Delete this line before using as an input file")
  ts.WriteLine("Server Driver=Client Driver - Delete this line before using as an input file")
  ts.close

If you notice we write a line “Server Driver=Client Driver - Delete this line before using as an input file")” This file will be written to the text file to let the next person running an AddMap script to delete the line before using this as an input file for importing printer mappings into the datastore.
Once the output file is created we then configure our log file name and create it. As you can see, this example is hardcoded to C:. This is sloppiness on my part. :-)

'*****************************************************
'define the log file name here
'*****************************************************

LogFileName = "c:\DelPMap.txt"

'*****************************************************
'create the log file if it doesn't exist
'*****************************************************

Now that our log files and output files are created we then begin to access the MetaFrame farm object:

'*****************************************************
' Create MetaFrame Farm Object
'*****************************************************

  Set theFarm = CreateObject("MetaFrameCOM.MetaFrameFarm")
  if Err.Number <> 0 Then
   WScript.Echo "Can't create MetaFrameFarm object"
   WScript.Echo "(" & Err.Number & ") " & Err.Description
   WScript.Quit Err.Number
  End if

Then we initialize the farm:

'*****************************************************
' Initialize the farm
'***************************************************** '

  theFarm.Initialize(MetaFrameWinFarmObject)
  if Err.Number <> 0 Then
   WScript.Echo "Can't Initialize MetaFrameFarm object"
   WScript.Echo "(" & Err.Number & ") " & Err.Description
   WScript.Quit Err.Number
  End if

After that we verify that the current user executing the script is a citrix administrator. If not, the functions in the script will fail so we want to stop it here. Also (if haven’t noticed yet) this format so far follows the examples in the Citrix SDK pretty closely. (You can download the SDK for free from the Citrix Developer Network.)

'*****************************************************
' Check Citrix Admin Credentials
'*****************************************************

  if theFarm.WinFarmObject.IsCitrixAdministrator = 0 then
   WScript.Echo "You must be a Citrix admin to run this script"
   WScript.Quit 0
  End If

Now that all that beginning stuff is out of the way the script gets more interesting. First, we initialize the PrintDriverMappings within the farm. If we can’t access the mappings the script quits. After that we start a simple FOR loop. For each print driver mapping it finds in the farm, it gathers the following information:

Server driver name
Server driver platform
Client driver name

We then delete the mapping and write it to the output file in this format:

ServerDriverName=ClientDriverName

This is the same format that can be used as an input file for the script that re-adds the mappings.

'*****************************************************
' Read and delete the driver mapping
'***************************************************** '

  set theMappings = theFarm.WinFarmObject.PrinterDriverMappings
  if Err.Number <> 0 Then
   WScript.Echo "Can't Initialize PrintDriverMappings object"
   Wscript.Echo "(" & Err.Number & ") " & Err.Description
   Wscript.Quit Err.Number
  End If
  For each Map in theMappings
   sDriver = Map.ServerDriverName
   sPlatform = Map.ServerDriverPlatform
   cDriver = Map.ClientDriverName
'   wscript.echo sDriver & ", " & sPlatform & ", " & cDriver
   Map.Delete
   Set f = fso.GetFile(OutPutFileName)
   Set ts = f.OpenAsTextStream(8, -2)
   ts.WriteLine(sDriver & "=" & cDriver)
   ts.close
   If Not Err.Number = 0 then

Next, we have a IF statement that checks for success or failure and writes it to the log file.

'*****************************************************
'write failure into log file
'*****************************************************

   Set f = fso.GetFile(LogFileName)
   Set ts = f.OpenAsTextStream(8, -2)
   ts.WriteLine(sDriver & "=" & cDriver & " Mapping Deletion Failure ****")
   ts.close

   Else
   '*****************************************************
   'write success into log file
   '*****************************************************

   Set f = fso.GetFile(LogFileName)
   Set ts = f.OpenAsTextStream(8, -2)
   ts.WriteLine(sDriver & "=" & cDriver & " Mapping Deletion Successful")
   ts.close

end if

Next 'Map

'*****************************************************
'End the Script
'*****************************************************

WScript.Echo "Script Complete, Log file written to: " & LogFileName

</script>
</job>
</package>

At the end of the script we simply echo that the script is complete and show the user the log file location. A great thing you can do with this is to get a new mapping list together, test it, make sure its perfect, then (in a matter of minutes) completely clean up your old mappings and replace them with new ones.

Below you’ll find the complete code for both the DelMap and AddMap scripts. Happy scripting!

<package>
<job id="Print Driver Mappings">
  <comment>
        File:           DelMap.wsf
        Description:    Deletes all Print Driver Mappings from the MetaFrame
    farm Data Store.
        Requirements:   WSH 5.5 or higher.

'*****************************************************
'Parse the command line
'*****************************************************

  Set Args = Wscript.Arguments
  If Not Args.Count = 1 Then
   Wscript.Echo "Usage: DelPMap.wsf OutPutFile"
   Wscript.Quit
  End If

'*****************************************************
'create the OutPut file if it doesn't exist
'*****************************************************

'*****************************************************
'define the log file name here
'*****************************************************

LogFileName = "c:\DelPMap.txt"

'*****************************************************
'create the log file if it doesn't exist
'*****************************************************

'*****************************************************
' Create MetaFrame Farm Object
'*****************************************************

'*****************************************************
' Initialize the farm
'***************************************************** '

'*****************************************************
' Check Citrix Admin Credentials
'*****************************************************

  if theFarm.WinFarmObject.IsCitrixAdministrator = 0 then
   WScript.Echo "You must be a Citrix admin to run this script"
   WScript.Quit 0
  End If

'*****************************************************
' Read and delete the driver mapping
'***************************************************** '

    '*****************************************************
    'write failure into log file
    '*****************************************************

    Set f = fso.GetFile(LogFileName)
    Set ts = f.OpenAsTextStream(8, -2)
    ts.WriteLine(sDriver & "=" & cDriver & "    Driver Mapping Deletion Failure ******* ")
    ts.close

   Else
    '*****************************************************
    'write success into log file
    '*****************************************************

    Set f = fso.GetFile(LogFileName)
    Set ts = f.OpenAsTextStream(8, -2)
    ts.WriteLine(sDriver & "=" & cDriver & "    Driver Mapping Deletion Successful")
    ts.close

end if

Next 'Map

'*****************************************************
'End the Script
'*****************************************************

WScript.Echo "Scipt Complete, Log file written to: " & LogFileName

</script>
</job>
</package>

Here is the AddMap script and a sample input file for it. Notice that the input file has no quotes around the driver names. It’s simply a client driver name followed by an equal sign and a server driver name. The output from the DelMap listed above creates a file exactly like this. In addition, you could modify the DelMap script so it DOESN’T delete the mappings and instead just records them to the output file. This will then allow you to edit the text file and get ready for the deletion and re-importation for the mappings.

Input file sample:

HP LaserJet 4/4M=HP LaserJet 4
HP LaserJet 4P/4MP=HP LaserJet 4P
HP LaserJet 4 Plus/4M Plus=HP LaserJet 4 Plus
HP LaserJet 4Si/4Si MX=HP LaserJet 4Si
HP LaserJet 4V/4MV=HP LaserJet 4V
HP LaserJet 5/5M - Enhanced=HP LaserJet 5
HP LaserJet 5/5M - Standard=HP LaserJet 5

AddMap.wsf Script

<package>
<job id="Print Driver Mappings">
  <comment>
        File:           AddMap.wsf
        Description:    Adds Print Driver Mappings to the MetaFrame farm Data Store.
        Requirements:   WSH 5.5 or higher.

  </comment>
  <runtime>
   <description>
               Adds Print Driver Mappings to the MetaFrame farm Data Store.
   </description>
   <example>                CScript //nologo AddPMap.wsf InputFile
   InputFile must be in the format ClientDriver=ServerDriver
   with no spaces around the equals sign
</example>
  </runtime>
  <reference object="MetaFrameCOM.MetaFrameFarm"/>
  <script language="VBScript">
        Dim fso, f, ts, LogFileName, Args, InputFileName, eqCount
                Dim theFarm, theMap, sDriver, sPlatform, cDriver, OSVer
  set fso = CreateObject("Scripting.FileSystemObject")
  OSVer = "1"

'*****************************************************
'Parse the command line
'*****************************************************

  Set Args = Wscript.Arguments
  If Not Args.Count = 1 Then
   Wscript.Echo "Usage: AddPMap.wsf InputFile"
   Wscript.Quit
  End If

'*****************************************************
'Verify Input File
'*****************************************************

  InputFileName = Args(0)
  If Not fso.FileExists(InputFileName) Then
   Wscript.Echo "The input file is not found."
   Wscript.Echo "Usage: AddPMap.wsf Inputfile"
   Wscript.Quit
  End If

'*****************************************************
'define the log file name here
'*****************************************************

LogFileName = "c:\AddPMap.txt"

'*****************************************************
'create the log file if it doesn't exist
'*****************************************************

  If Not fso.FileExists(LogFileName) Then
   fso.CreateTextFile(LogFileName)
  End If
  Set f = fso.GetFile(LogFileName)
  Set ts = f.OpenAsTextStream(8, -2)
  ts.WriteLine
  ts.WriteLine(NOW)
  ts.WriteLine("Server Driver=Client Driver, Success/Failure")
  ts.close

        '*****************************************************
' Create MetaFrame Farm Object
'*****************************************************

'*****************************************************
' Initialize the farm
'***************************************************** '

'*****************************************************
' Check Citrix Admin Credentials
'*****************************************************

  if theFarm.WinFarmObject.IsCitrixAdministrator = 0 then
   WScript.Echo "You must be a Citrix admin to run this script"
   WScript.Quit 0
  End If

'*****************************************************
' Create PrintDriverMappings object
'*****************************************************

  set theMap = CreateObject("MetaFrameCOM.MetaFramePrinterDriverMapping")
  if Err.Number <> 0 Then
   WScript.Echo "Can't create PrintDriverMapping object"
   Wscript.Echo "(" & Err.Number & ") " & Err.Description
   Wscript.Quit Err.Number
  End If

'*****************************************************
' Input and add the driver mapping
'***************************************************** '

  Set objTextStream = fso.OpenTextFile(InputFileName, 1)
  Do Until objTextStream.AtEndOfStream
   Mapping = objTextStream.ReadLine
   eqCount = InStr(Mapping, "=")
   cDriver = Left(Mapping, (eqCount-1))
   sDriver = Right(Mapping, (Len(Mapping)-eqCount))
   theMap.ServerDriverName = sDriver
   theMap.ServerDriverPlatform = OSVer
   theMap.ClientDriverName = cDriver
   theMap.Save
'   wscript.echo cDriver & "=" & sDriver
   If Not Err.Number = 0 then

    '*****************************************************
    'write failure into log file
    '*****************************************************

    Set f = fso.GetFile(LogFileName)
    Set ts = f.OpenAsTextStream(8, -2)
    ts.WriteLine(sDriver & "=" & cDriver & "    Driver Mapping Addition Failed ******* ")
    ts.close

   Else
    '*****************************************************
    'write success into log file
    '*****************************************************

    Set f = fso.GetFile(LogFileName)
    Set ts = f.OpenAsTextStream(8, -2)
    ts.WriteLine(sDriver & "=" & cDriver & "    Driver Mapping Addition Successful")
    ts.close

end if

Loop 'objTextStream
objTextStream.Close

'*****************************************************
'End the Script
'*****************************************************

  WScript.Echo "Scipt Complete, Log file written to: " & LogFileName

  </script>
</job>
</package>

Basic KIX Login Script for Citrix Users

2004-06-11T06:30:00Z

This article is part of Ron Oglesby's Scripting for MetaFrame Series.

In this series of articles I focus on how an you can use scripting in a Terminal Server / Citrix MetaFrame environment for common and recurring tasks. This article covers the basics of using a KIX login script to configure your Citrix users’ environment.

As an administrator, you have a choice of many different scripting languages. My personal favorite (and the favorite of many Citrix admins) is KIX (available for free). While VBS has its place and is perfect for administrative tasks, KIX is the true king for logon scripts in MetaFrame. Its ease of use, the fact it’s a simple (and forgiving) language, and its focus on modifying the user’s environment make it perfect for MetaFrame and Terminal Server users.

Before we get into some of the common functions you’ll perform for the users, let’s start with some basic logic for your script. A really good practice is to break your script into two parts: initial user configuration and logon settings.

The first part of a KIX script is usually the initial configuration of the user. These are settings that your only need to run once if using roaming profiles or local profiles on a single server. Such settings might include:

Configuring the Outlook profile
Setting certain registry entries for applications
Copying a file into the user’s home directory

The second part of the script is used for settings or processes that need to be run at each time the user logs on. These settings may include:

Updating a file based on time or date for the user
Changing frequently modified registry entries or application settings to reflect new or modified values
Checking for and installing printers into the session
Mapping drives

The reason I like to break these into two parts is for speed. While you could run both parts of the script every time the script is run, I like to run the “run once” type of settings only once. Basically I create a registry key for the user during the script and use version info to determine if they have run the latest version of the script. If they have, the script can skip the “run once” section. If they haven’t, they run the entire script and get the new settings. This allows you to speed up your logons a little, which is always important in a Citrix environment.

Okay, let’s move on to the script itself. First of all, you should keep a history of the script within it. The extra lines in the script won’t affect performance. I keep a simple version number at the beginning of my logon scripts:

;*************************************************************************

;************* logon.KIX configures the user's profile *****************

;************* Ver 1 Base Build. Outlook settings and printers *****************

;************* Ver 1.1 disables the adobe splash screen *****************

;************* Ver 1.2 disables autoload of IM *****************

;************* Ver 1.3 disables autoload of IM when Outlook is launched *****************

;************* Ver 1.4 Enables outlook to attach EXE and URL files **********

These numbers can then be used as the value for the registry key the script checks, and creates or modifies.

The first step in my script is to check for the current version of the script that this user has run:

$VER = ReadValue ("HKEY_CURRENT_USER\Software\RapidApp","Version")

This command sets the variable “$VER” equal to the value of a registry key by using a simple ReadValue command. The format for this command is as follows:

ReadValue (“Hive\key\subkey\subkey”,”Value you wish to read”)

It’s so simple it’s sick. I now know that the variable $VER is equal to the value set in the users’ registry location HKCU\Software\RapidApp\Version. At this point we can throw a quick IF in there to see if the user is current or not:

IF $VER=1.4

GOTO ALWAYS

ELSE

GOTO RUNONCE

ENDIF

Here we check to see if they have a value of 1.4. If they do I send them to the “ALWAYS” section of my script that runs each time a user logs on. If that registry value does not equal 1.4 then they run the next section (“RUNONCE”), then continue onto “ALWAYS”. (For brevity I have changed my scripts here and made them very simple to use. The scripts below may not represent the version descriptions above)

:RUNONCE

;*************************************************************************

; Outlook Config

$OTLK = ReadValue ("HKEY_CURRENT_USER\Software\RapidApp","Otlk")

IF $OTLK<>1

Run "d:\Progra~1\Micros~1\Office10\Outlook.exe /ImportPRF D:\admin\scripts\Outlook.prf"

WriteValue("HKEY_CURRENT_USER\Software\Rapidapp","Otlk", "1", "REG_SZ")

ENDIF

Notice here that I check to see if their Outlook profile has ever been configured. If not I launching Outlook with an Import PRF switch. Most of my remote users use a desktop and this is a simple and easy way to do it. Another way to do this (in new versions of Office) is to simple set a key in a specific spot in HKCU for IMPORTPRF with a value of the location of the PRF. This will configure outlook to use the PRF file the first time they launch it too.

Continuing in the “run once” part of the script, I then begin to set some registry keys I need for certain applications. As you can see below I assume that the keys I want are not there so I create them then writing the value I want. The great thing about this is that if the key (folder) does exist the addkey will just fail and the script will continue on to write (or overwrite) the value I am importing.

;*************************************************************************

; Disable Splash screen for adobe reader ADDED WITH VER1.1

AddKey("HKEY_CURRENT_USER\Software\ADOBE\Acrobat Reader\5.0\AdobeViewer")

WriteValue("HKEY_CURRENT_USER\Software\ADOBE\Acrobat Reader\5.0\AdobeViewer","DISPLAYABOUTDIALOG", "00000000", "REG_DWORD")

AddKey("HKEY_CURRENT_USER\Software\ADOBE\Adobe Acrobat\5.0\AdobeViewer")

WriteValue("HKEY_CURRENT_USER\Software\ADOBE\Adobe Acrobat\5.0\AdobeViewer","DISPLAYABOUTDIALOG", "00000000", "REG_DWORD")

;*************************************************************************

; Disable the IM auto-loader ADDED WITH VER 1.3 and 1.4 for published apps

DelValue("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run", "MSMSGS")

AddKey("HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\IM")

WriteValue("HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\IM","Enabled", "00000000", "REG_DWORD")

;*************************************************************************

; Enables a user to see and attach EXEs and URLs within outlook

WriteValue("HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\SECURITY\","Level1Remove", "exe;url", "REG_SZ")

;**************************************************************************

; Write the version info into the registry.

AddKey("HKEY_CURRENT_USER\Software\RapidApp")

WriteValue("HKEY_CURRENT_USER\Software\RapidApp","Version", "1.4", "REG_SZ")

Notice how the AddKey, WriteValue, ReadValue commands and syntax within KIX are simple and self-explanatory. Part of the appeal of KIX is that it is very simple to use but still offers great power for modifying the user environment. If you are going to use KIX I highly recommend getting the KIXtart.CHM file that is floating around on the internet. It’s a nice help file with samples for each command and function in KIX.

In addition, right at the end of the first section of the script I update the version info in the user’s registry. This is what allows us to limit its use and thus speed up the logon.

With all of the basic configuration and registry keys I want added to the user I now move onto my “ALWAYS” Section. This section will run every time regardless of version of the script. Here I map two drives (drives used by applications only run from Citrix), add two printers, set a default printer for users in my Chicago office, and I replace a file (and ini) in their home dir and put their Windows username in a specific value in the INI. This INI gets changed about every three days so I have found this a simple way to keep up with it.

:ALWAYS

;*************************************************************************

; Map drives for Citrix users.

USE L: /DELETE

USE K: /DELETE

USE L: \\RAFS1\DOCs12

USE K: \\RAFS2\DJQ

;*************************************************************************

; Set the 4000 and 4500 printers for the Chicago Users

IF INGROUP("CHIUsers")

addprinterconnection("\\RAFS1\HP4000")

addprinterconnection("\\RAFS1\HP4500")

setdefaultprinter("\\RAFS1\HP LaserJet 4500")

ELSE

? "Non-Chicago User"

ENDIF

;*************************************************************************

; Copy the DOCs12.ini and modify username settings

COPY “\\RAFS1\Source\W2HCM.ini" "%homedrive%%homepath%\windows\DOCs12.INI"

WriteProfileString("%homedrive%%homepath%\windows\DOCs12.ini","Session","User")

:END

As you may have noticed I have no error handling in this script. Basically this script is so simple that not much is needed. But as you get more advanced and start creating more detailed scripts you may need to build in some error checking.

Anyway, basic KIX logon scripts are easy to do and allow you to do almost anything to the user’s environment. Here I’ve shown you how to map drives, read and write registry values, copy files, modify INI files, setup printers, check for group membership and even use version controls to speed up the logon process. Below is the complete sample script. Obviously there is much more you can do with KIX (MUCH more) and in a future article we will go into more detailed and interesting KIX scripts.

;*************************************************************************

;************* logon.KIX configures the user's profile

;************* Ver 1 Base Build. Outlook settings and printers

;************* Ver 1.1 disables the adobe splash screen

;************* Ver 1.2 disables autoload of IM

;************* Ver 1.3 disables autoload of IM when OutLook is launched

;************* Ver 1.4 Enables outlook to attach EXE and URL files