Guest Bloggers

An introduction to VMware View 3, Part 3 of 3 – Special Considerations and Best Practices

Roland van der Kruk — Mon, 26 Jan 2009 19:01:00 GMT

In this three-part article series, Roland van der Kruk, a freelance consultant in The Netherlands, takes a look at the new features of VMware View 3, as well as best practices learned while doing a deployment for a customer. Part 1 provides information and insight on new features, Part 2 looks at Linked Clones, and Part 3 (this article) will look at special considerations and best practices for deployment.

High available, secure remote access

Unfortunately, a high available configuration to access VMware View while being outside the corporate network can be very different between organizations. I have been doing some research reading the VMware VDM 2 Load Balancing Guide to find out more about load balancing and secure remote access. In today’s enterprise environments, gateway devices like Citrix Netscaler/Access Gateway or Cisco ASA are more or less common practice. They are configured as a mandatory termination point for sessions originating from outside the corporate network connecting to resources inside the corporate network.

Initially, two http sessions are set up between the client and the Connection Servers to which the load balancer redirected the client request. One session is for communication with the web page, the View Portal, and one is for the RDP connection that can be configured to be packed into http or https. By default, a Connection Server replies to the client http request with a response in which its own hostname is sent back to the client. Using the default configuration of a Connection Server would then result in having to open up the necessary ports on the firewalls between the Gateway device and all Connection servers as the client will try to communicate directly with the Connection Server once it received the Connection Servers’ hostname in the http response. In the configuration page of the View Administrator however, you can modify the default behavior by configuring an ‘External URL’ that will be given back to the client. The External URL will have to be configured on each Connection Server that you have.

Picture 16 – Part of the screen that appears when clicking a Connection Server and choosing ‘Edit’.

An External URL can be configured and also a direct connection to desktops, resulting in bypassing the Connection Server for direct communication with the virtual machine that a user needs. If you configure the External URL to be the DNS name of the load balancer, you will have two moments on which load balancing will take place; initially to set up the communication to the View Portal, and subsequently, if a session to a Virtual Machine is started.

According to VMware in the Load Balancing Guide, for proper load balancing to work the load balancer needs to be configured for SSL Offloading. SSL Offloading is necessary because a load balancer cannot see what’s inside an SSL request. All requests are coming from one Gateway device, which means that all the load would go to the initially chosen Connection Server. Also, sticky sessions need to be configured on the load balancer to support RDP connections over http. This means that SSL connections can be setup to the load balancer, but the load balancer will strip off the encryption and forward the requests to the Connection Servers as http. This actually means that communication from the load balancer to a Connection Server is going over HTTP where, for example, a cookie insert by the load balancing device will result in being able to provide RDP sessions consistently going to the same Connection Server

This also means two more things:
Username and password are passed to the Connection Server in clear text between the load balancing device and the Connection Server.

As the Connection Server is configured for http and not https, the RDP sessions will be packed in http as well. This might not be a problem because the connection from the internet to the Gateway device is already tunneled in https, but I wanted to point that out anyway.

Compared with Citrix Web Interface, where integrated logon with Kerberos authentication is an option, this seems like an issue that VMware could address better. Also to get a Cisco ASA to work, probably a View Plugin for ASA would be a GREAT idea...

Server Provisioning

When I made the comparison of View 3.0 with Citrix Provisioning Server, I wondered how View 3.0 could be used to deploy Terminal Servers or even Citrix Servers. The official line from VMware says that only Desktop Operating Systems are supported. I tried it for myself and, indeed, a Virtual Server with a snapshot and a View Agent installed is not ‘discovered’ in a desktop pool deployment wizard. Too bad, because a tool for cloning Citrix servers, like the one from CitrixTools.net could do a good job here, handling all Citrix specific services and settings with Sysprep being used by Virtual Center to deploy uniquely identifiably virtual machines. Active Directory policies could be adjusted to make all this work without further administrative interaction.

Maybe I’m going too far here comparing View with XenDesktop/Provisioning Server? I see a lot of similarity between the two products, even though entirely different techniques are used. I might say that putting OS changes in a ‘memory state cache’ as Provisioning Server does is a more elegant solution than creating and deleting snapshots, but the result can be the same; Instantly provisioned machines that are deleted as soon as they reboot.

Machine Account password

A virtual machine with a snapshot can only be used by View 3.0 (or probably VMware ESX) as a master image if the machine is joined to a domain. For this reason, I would apply the same local policy as I would normally do with a sequencing or packaging machine, and then disable Windows machine account password resets. If your company policy or personal preference requires machine account password changes, you can change the default ‘change password interval’ to the maximum of 999 days. Both of these options can be changed in the Group Policy editor:

Start/run/gpedit.msc >

Computer configuration/Windows settings/Security settings/local policies/Security options:

- Domain member: Disable machine account password changes - enabled

- Domain member: Maximum machine account password age – 999 days

Display Protocol

I have to mention that I was at least a little disappointed when I noticed that nothing was done about optimizing RDP. It is especially important if you plan to deploy Windows XP, which probably has the worst version of RDP still available, and you have to provide desktops to users over high latency connections. I must admit that I haven’t yet tested performance using RDP with a typical Indian latency of (so the story goes) up to 300 milliseconds, but I can image implementations being cancelled because of this shortcoming. The Group Policy Administrative Templates provided with View will really be necessary to optimize RDP as far as possible, but of course the advanced options available in ICA are really an entirely different story.

In the Reference Architecture Kit on the VMware site, VMware actually acknowledges this problem by stating that RDP is a good protocol for LAN connections or WAN connections with up to 150 ms latency. If you have to provide virtual desktops over high latency connections however, using RDP might not be a good idea. VMware mentions solutions like Sun Microsystems’ Appliance Link Protocol™ (ALP) used in Sun Ray™ thin client implementations and Pano Logic’s Console Direct, but getting into those is out of the scope of this document. I did find a network tool that can configure latency up to 400 ms, so I will test this in the near future.

Sizing

Also in the Reference Architecture Kit, a setup is described for separate ESX clusters for VDI. For my customer, I will also use separate ESX clusters. Although, since clusters cannot contain more than 8 nodes, my customer will have to change from their standard cluster configuration of 13 hosts per cluster. I found that approximately 17 power users can be placed on a machine with two quad core CPU’s and 24 Gb of memory. Because of the memory sharing feature, ESX even promises to be the best option on which to run VDI environments, as other hypervisors do not support memory sharing. I plan to use the same Virtual Center that I already have running for my server environment, which already is one of the largest in Europe. However I will probably have to keep a close eye on performance, as Virtual Center probably also has its limits.

User experience monitoring

When you are planning to use VMware View, I recommend looking at ‘User Experience Monitoring’ products. Products from eG Innovations and RTO PinPoint can provide valuable information on both frond end and back end performance, giving you great insight in what delay is caused where. Implementing that could save you a lot of time in the end.

A final word or two…

VMware did a good job with View 3.0. They put all configuration options for the View 3.0 product into one console, which is really excellent work. The console is intuitive and fast. Options are logically grouped and put into only four distinct console windows. The new linked clone technology is probably a bit harder to understand as consequences for disk space usage are not properly documented by VMware. (Linked clones were covered in Part 2 of this article series)

The term ‘persistent desktop’ needs some explanation because it can be misunderstood as a desktop for power users – like a dedicated desktop. In actuality, it means that all the desktops are kept in a consistent state by the administrator, which is certainly not a “power user” type desktop.

Furthermore, most essential options are available; universal printing, single sign-on, instant and automatic desktop creation, even the experimental ´offline desktop feature´ can be used. Unfortunately, optimizations on the RDP protocol are lacking, which in some cases might result in unworkable situations because of network latency. Customers using VMware ESX could strategically choose for View 3.0 because of the tight integration with Virtual Infrastructure. With the Premier license bundles that also includes ThinApp/Thinstall, the combination makes for a promising offering in the VDI market. I wonder what VMware´s next move will be.

Useful links

VMware VDM 2 Load Balancing Guide

Administration Guide - View Manager 3.0

VMware View Reference Architecture Kit

Part One of this article series

Part Two of this article series

Roland van der Kruk is a freelance consultant in The Netherlands. He currently works with server-based computing and desktop delivery solutions. Roland can be contacted by email at roland@sbcprojects.com or through his website at http://www.sbcprojects.com.

An introduction to VMware View 3, Part 2 of 3 – Linked Clones

Roland van der Kruk — Sun, 18 Jan 2009 13:56:00 GMT

In this three-part article series, Roland van der Kruk, a freelance consultant in The Netherlands, takes a look at the new features of VMware View 3, as well as best practices learned while doing a deployment for a customer. Part 1 provides information and insight on new features, Part 2 (this article) looks at Linked Clones, and Part 3 (released later this week) will look at special considerations and best practices for deployment.

Linked Clones

The big question to most people is probably: ‘What are linked clones and how do they work?’. Some of you may expect similar functionality to Citrix Provisioning Server where optimization in disk space can be significantly realized, and indeed VMware does somewhat the same, but with very different technology. Let’s see how VMware does it.

The essence of linked clones is Thin Provisioning; saving on expensive storage cost. Thin provisioning with View 3.0 can be realized using a “master virtual machine”, which is just a regular virtual machine that you create and then take a snapshot. That virtual machine will be used as the basis for rapid and thin OS deployment. Please notice that I mentioned a virtual machine “snapshot”, not a virtual machine “template”.

You prepare a virtual machine with the Desktop OS of your choice (Server Operating Systems are not supported) exactly the way that you like your master image to be. When all components and settings are properly set, you then have to install the VMware View Agent (which contains the components mentioned in the previous article), shut down the virtual machine and take a (first) snapshot. I might add that the master virtual machine has to be domain joined, for which I could not find the reason. After that, desktop deployment can start.

In the View Administrator console, choose the ‘Desktops and Pools’, as this is where desktops and desktop pools can be added and/or edited. In the right pane of the ‘Desktops and Pools’ tab, five other tabs appear, the most left being the ‘Desktops and Pools’ view. Here you can choose ‘Add’ to start a wizard that guides you through the steps necessary for adding a desktop or a desktop pool. The following choices are presented:

Individual Desktop, this option will start a wizard to provide users with access to a single virtual or physical computer on which the View Agent is installed.
Automated Desktop Pool, this option starts a wizard to automatically create one or more desktops in a pool. The explanatory text for this option states that desktops are based on “virtual machine templates,” which is wrong. You need to have a normal virtual machine from which you will take a snapshot (as mentioned above).
Manual Desktop Pool, this option will start a wizard to provide access to an existing set of virtual or physical PC’s that have the View Agent installed.
Microsoft Terminal Services Desktop Pool, this option starts a wizard to publish Terminal Server desktops to View Portal users.

I don’t want to get into details with every option mentioned, but continue with the most eye catching option, the Automated Desktop Pool. The automated desktop pool can consist of any number of persistent or non-persistent desktops.

After a persistent desktop pool is created and a user is assigned a certain desktop, the mapping between user and assigned desktop is written to the ADAM database (see Part 1 for more information on how ADAM is used). Every time the user logs on to the View Portal, the same desktop will be available and the state of the virtual machine is exactly the way he or she left it with the previous logoff. This option is similar to the ‘permanent disk’ in Citrix Provisioning Server. A persistent desktop pool can contain any number of desktops, and once created, the pool can also be edited to increase the number of desktops in the pool. In the wizard, as depicted below, the initial number of desktops to be created is set to 5, the total number of desktops in the pool is set to 100 and as soon as the number of available desktops falls below 5, the number of available desktops is matched to meet the configured criteria by creating more machines in the pool, until the maximum number of desktops in the pool is reached.

Picture 6 – Advanced configuration of the number of desktops in a pool in the Deployment Wizard

Both persistent and non persistent desktops can be created using the ‘linked clone’ technology, which in fact means that deployed desktops can be altered by assigning the desktops to a different snapshot or even to an entirely different virtual machine. The main difference between a persistent and a non persistent desktop is that persistent desktops can contain a second virtual disk to which the ‘Documents and settings’ folder is moved. User data is effectively put on another disk, so in case an administrator decides to assign a different snapshot or image to a user, all user data in the ‘Documents and Settings’ folder will still be available. Of course, this can also be accomplished by modifying the User Shell Folders of each user with Active Directory GPO or script to alter all default folders, but with the View 3.0 option, user data will be locally available, presumably resulting in better performance.

I wonder if this is really a useful option, as user data can only be reached by going to the machine itself and opening the folder, whereas with folder redirection, all user data can be redirected to a central network share, substantially simplifying central administration, in my opinion. If the central network share is located on fast NAS heads, performance might still decrease a little, but management of user data only locally available on virtual machines is not a very attractive option in larger environments.

Picture 7 – A separate disk for personal data, available in a linked clone.

What actually happens as the wizard is finished is that a copy of the master virtual machine is made, together with a copy of the snapshot. The size of the copies, however, is not a complete copy of the master virtual machine. I deployed a master image with a system drive of 20 GB with a snapshot, which resulted in a copy of 6 GB for the system drive and a few Kb for the snapshot.

Picture 8 - User data drive of a persistent desktop for a specific user.

The folders and disks are automatically created and the folders and files contain some GUID that is associated with master desktop and user.

To (hopefully) clarify the components, the following Virtual Center folder arrangement is depicted:

.jpg">

Picture 9 - Virtual Center containing all folders necessary for a View 3.0 deployment.

The above picture shows that

VMware virtual machine templates can be used to deploy master images
Master images with at least one snapshot are best placed in a separate folder to make sure you don’t mix things up
Linked Clones are best placed in a separate folder, where subfolders can be created to place non persistent and persistent linked clones
You can (and probably will) have other virtual pc’s or virtual servers in your Virtual Center
On the bottom of Picture 9 the automatically generated folders are shown, which are all created by View 3.0 as a result of a desktop pool deployment wizard in the View Administrator console. A replica folder and a source folder are created for each desktop pool that uses linked clone technology. All folders created automatically are fully managed by View 3.0 and are only to be administered through the View Administrator console.

Linked Clone disk characteristics

So, how does View 3.0 handle disks and disk space for linked clones?

In my tests I created a Windows XP SP2 image with a system drive of 20 GB. In the Automated desktop pool wizard, I chose to configure 5 linked clones, where initially 1 linked clone was created immediately after finishing the wizard, and where always 1 desktop would be available for new user logon until the maximum number of desktops in the pool has been reached. Also I chose to create a separate User data disk of 2 GB for the ‘Documents and Settings’ folder to be placed.

Picture 10 - Step in deployment wizard where OS Data and User Data stores can be selected with.

After finishing the wizard, a replica folder and a source folder are created which are used as templates, of which clones are created by View 3.0

Picture 11 - Replica folder of an automated, persistent desktop pool, derived from a 20 GB system disk

Picture 12 - Source folder of an automated, persistent desktop pool with a configured user data disk of 2 GB

Picture 13 – System disk of a linked clone, available to an end user using a system disk of 20 GB

Picture 14 – User data disks, mapped as D-drive in the users’ virtual desktop, for two users with a maximum of 2 GB per user

In the table below, all components are mentioned to deploy at least one desktop pool based on one Desktop Operating System. The ‘linked clone system disk’ will initially be around 100 MB and can grow up to the original size of the Master VM. A Desktop Refresh (discussed below) can be scheduled or executed manually to return the linked clone system disks to its’ original size.

System disk of Desktop OS template, used to create ‘Master Image Virtual Machines’	20 Gb
System disk of a ‘Master Image Virtual Machine’, containing a Desktop OS including (a) snapshot(s)	20 Gb
Replica folder and source folder derived from the ´Master Image´, created for a desktop pool with an unlimited of linked clones	6 Gb
Linked clone system disk per OS	100 MB - ??
Linked clone user data disk per user	2048 MB (configurable)

Table 2 – Linked Clone disk size example

Desktop recompose, refresh, rebalance

At all times, deployed desktops can be altered when created using the linked clone technology.

A Desktop Recompose means that a deployed desktop state is altered. It can be assigned a different snapshot of possibly even entirely an different master virtual machine.

A Desktop Refresh means that a linked clone desktop is brought back to the state of initial roll out. This actually means that the system disk is reverted to the moment it was deployed, including its size and contents. If a separate user disk was used in the deployment wizard, all user data on that disk remains intact.

A Desktop Rebalance means balancing virtual machine disks across available data stores (LUN’s). If a VMware ESX data reaches its capacity, a rebalance can take care of automatic data migration of deployed virtual machine disks to different ESX data stores.

Picture 15 - View on a persistent desktop in the ‘Persistent’ desktop pool, which can be removed, reset (OS reset), edited (recomposed or refreshed) or rebalanced

Linked clones, persistent desktops and OS maintenance; 1 + 1 + 1 = 1?

Another thought came to mind worth mentioning. In my test I created a desktop pool with the combined technologies of linked clones and persistent desktops. Of course on these desktops, I do have to perform maintenance, as Microsoft hotfixes come out the second Tuesday of the month and who knows what else needs to be updated. Initially I thought I could use the linked clone technology for this; update my master virtual machine with hotfixes, take a new snapshot and link all deployed desktop to the new snapshot. If all is well this will work, however, what happens to my ‘persistent desktops’ if I do that? In fact, all users having made changes to the OS (I chose to allow certain users to install their own applications) lose their OS customizations and their applications.

After linking desktops to a new snapshot, it appears that the only thing that is really persistent about the ‘persistent desktop’ is what is on the user data disk, which contains the ‘documents and settings folder’ and maybe some data, but not the entire installed application the user needed. Ergo, if I want to maintain my OS with hotfixes using linked clone technology or ‘Desktop Recompose’, while at the same time keeping users’ customizations to the OS, I will have to use a tool like SMS/SCCM, Radia or whatever your standard corporate application distribution method is. My question then is: what does ‘Persistent Desktop’ really mean?

I performed one more test to see how intelligent the linked clone snapshotting technology really is when it comes to managing disk space. I started off with a Persistent Desktop:

- System disk: 230 MB

After I logged on as an administrative user, I copied an installation of Eclipse, sized 354 MB, to the System disk of my virtual machine.After the file copy, my System disk looked like this:

- System disk: 607 MB

I decided to delete the Eclipse folder. After deletion, the system disk looked like this:

- System disk: 607 MB

Conclusion: The Eclipse folder doesn’t seem to be deleted and the data is still available in the snapshot.

I decided to copy the exact same Eclipse folder again to the same destination on the system disk, which then looked like this (I also tested another destination; c:\temp, which had the same result):

- System disk: 623 MB

Apparently, some check was done as the linked clone disk reused the data that was marked as ‘deleted’.

After I removed Eclipse again, the system disk looked like this:

- System disk: 640 MB

Now since Eclipse is deleted off disk and the system disk still has the size of 640 MB, which means the data is still there, maybe the snapshot technology is intelligent enough to mark the space as deleted so it can be filled up with other data. I copy some other data to the system disk that is smaller than the size of the data that could be ‘marked for deletion’. After copying a 219 MB folder, the disk looks like this:

- System disk: 852 MB

Conclusions:

Providing linked clones to users that have full control to the system, resulting in user initiated changes to the OS like copying data, removing it, etc., will end up in a system disk that eventually has a bigger size than if the OS was provided to the user without the linked cloning technology.
If a View Administrator decided to refresh the OS because he added some hotfixes or extra software, all user modifications to the OS are deleted. In fact the System Disk is simply deleted and a new linked clone is generated off the new state of the ‘master image’.
What ‘Persistent desktop’ actually means is that the state of a disk provided by a View Administrator is ‘persistent’. A desktop can be made persistent by recomposing or (scheduled) refreshing the deployed linked clones, resulting in exactly the state that a View Administrators expects it to be. From the view of end users using Linked Cloned Desktops, no persistence can actually be guaranteed, because all user actions will be undone by ‘Desktop Refresh’ or ‘Desktop Recompose’.
As soon as user modifications to the System Disk need to be persistent, no linked clone technology should be used. Instead, 1-on-1 desktops need to be provided, in which deployment tools like SCCM or Altiris will have to be available to maintain the system.

An introduction to VMware View 3 features and best practices, Part 1 of 3

Roland van der Kruk — Thu, 15 Jan 2009 14:50:00 GMT

In this three-part article series, Roland van der Kruk, a freelance consultant in The Netherlands, takes a look at the new features of VMware View 3, as well as best practices learned while doing a deployment for a customer. Part 1 (this article) provides information and insight on new features, Part 2 looks at Linked Clones, and Part 3 will look at special considerations and best practices for deployment.

Introduction

Early December 2008, VMware released their new product for the VDI market, VMware View 3.0. As a rather substantial update to the former version, VMware VDM 2.0, apparently the product name also had to undergo a change to underline the differences between the new product and its predecessor. In this article I will discuss the (new) features in View 3.0 and the way they work. I will first describe the components on which the product is based. Then I will focus on the different deployment types possible with View 3.0 and what happens during and after deploying different types of ‘desktop pools’.

My experience with the new product is mainly based on an implementation that I did for a customer, who had a specific use case to provide desktop operating systems to developers around the globe. I will sometimes refer to other use cases as there are quite a few, however perhaps the biggest question that everyone probably has will remain unanswered, as the technology that makes up VDI is still developing. Where we can speak of an accepted and well known technology like Citrix XenApp, VDI is not nearly there yet. The question of how VDI will result in better return on investment than desktop deployment methods being used for many years now is not clear. It all depends on use cases and things like high availability requirements and hardware cost. Financial differences and justifications for using VDI or a traditional desktop model are not discussed in this article.

Let’s first start with a description that VMware uses to describe the product and take it from there.

VMware describes View 3.0 as follows:

‘The Next Generation of VDI, delivering rich, personalized desktops to any device with all benefits of centralized management’.

View 3.0 was created using different technologies that are found in other VMware products. Examples of technology used in View 3.0 include snapshotting as seen in VMware Workstation (see picture 1); VMware OS cloning as used in ESX; and Tomcat is used for the Web based administration console, which we have seen before in the free VMware Server product (including the “self-signed, untrusted certificates” ‘feature,’ which is enabled by default ;-).

Managing View 3.0 is fairly straightforward. It is quite easy to use once you are accustomed to the components and terminology used with this product. Troubleshooting might turn out different, so let’s hope this product is as stable as should be.

Picture 1 - Snapshotting in VMware Workstation

VMware View 3.0 only supports VMware Infrastructure and is not a hypervisor-independent product. In fact, due to the new technologies that were added to View 3.0, it also imposes some requirements to the Virtual Infrastructure you are using. Before installing the first bit of View 3.0, you should check the version you are running on. View 3.0 is supported starting with VMware Infrastructure 3.02, however VI 3.5 u3 is recommended since linked clones are supported, which is probably the part raising most questions but also promising the best use cases. Both ESX 3.5 as ESX 3.5i can be used for View 3.0.

Components and terminology

Although setting up View 3.0 in fact can be quite straightforward, at first I found it difficult to figure out which components were doing what, communicating where, and for what purpose. I will try to explain the product by naming and describing all of the important components and terms used in the product.

View Connection Server

A connection server is a server acting as desktop broker. It facilitates two web sites; one for users that want to access a virtual desktop and one for administrators managing the View 3.0 environment. The Connection Server communicates with Active directory and maps Active Directory users and groups to virtual desktops and desktop pools. This information, together with configuration data, is stored in a local LDAP database, for which VMware decided to use ADAM (Active Directory Application Mode). The ADAM database can be viewed through the locally installed ADAM AdsiEdit.

Although the choice for ADAM as a database seems a good choice, unfortunately this also causes confusion, as with ADAM, a second LDAP database is introduced next to Active Directory. Confusion can arise when looking at the log messages in the Event log of the View Administrator console, where sometimes errors point to the ADAM LDAP database, while the actual error might be caused in communication towards Active Directory or vice versa.

When the Connection Server software is installed, the ‘VMware View Connection Server’ service is added, running under ‘local system’.

View Replica Server

The installation package for the Connection Server also contains the installation source for the ‘View Replica Server’. A View Replica Server is a Connection Server with its own replica of the ADAM database stored locally. All configuration data and changes are instantaneously replicated to all replica servers, resulting in entirely independent Connection Servers, being able to act on their own in case of failure of other replica servers.

View Security Server

The installation package for the Connection Server also contains the installation source for a ‘View Security Server’. A View Security Server acts somewhat like a Citrix Secure Gateway Server (the free software version) and is typically placed in a DMZ. Installation is very straightforward and the only important thing to configure is a 1-on-1 connection to a View Connection Server. After having connected a Security Server to a Connection Server, all instances of all Connection Servers are added to the configuration of the Security Server, not introducing awkward availability situations where a Security Server is available but its attached Connection Server is not. No ADAM database is stored locally and in fact the Security Server only function is to tunnel communication from the outside world users to the internal Connection servers over SSL. By simply entering the hostname of the security server in a web browser, the View Portal page is displayed, which actually is the View Portal page of a connection server.

View Portal

View Portal is the web page that facilitates users in accessing their desktops and is run on the Connection Server. After pointing a web browser to https://connectionservername, a logon screen appears in which all domains are available that are trusted by the domain to which the Connection Server was added. View Portal is the default web page on each Connection Server and is secured with self-signed certificates out of the box. Unfortunately with View 3.0, access to the View Portal is still not possible from Windows Server 2003 R2 machines, as was the case with VDM 2. Surprisingly enough, it is possible to access virtual desktops from Windows Server 2003, but only with the View Client software installed.

View Administrator/View Manager

The console from which all View management can be done, like View configuration, desktop deployment, user session management and log event viewing has in fact two names; ‘View Administrator’ and ‘View Manager’, as can be seen when the web based console is started. To start managing View 3.0, point a web browser to https://servername.domain/admin. Make sure you read that correctly; it is NOT https://servername.domain/adm, a little something that could eat you up for awhile if you don’t pay attention ;-). View configuration is done from one console that contains all possible configuration settings; a relief if you are accustomed to the different consoles that Citrix offers with their VDI product :) (see picture 2). Licenses, the connection to the Virtual Center server(s) and the account to perform all necessary actions in Virtual Center, the accounts to use that have permissions to add computer accounts in Active Directory, smart card support, a current usage overview, session timeout settings, SSL communication to the broker, login messages and more, it can all be accomplished using this one console which is even conveniently arranged. Hurray for VMware!

Perhaps a disadvantage would be that no real delegation of control can be configured; either you are a View administrator or you are not. No room for user session management only, or permissions to only modify specific desktops or pools; one down for VMware…

The four tabs in the administration console are:

Desktops and Pools - An overview of all desktop pools and other resources like Terminal Severs or bare metal pc’s, which can also be offered to users if the View Agent is installed. If the tab for Desktops and Pools is selected, sub windows appear on which all active sessions, accessible desktops, offline desktops and desktop policies can be viewed and managed.
Users and Groups - An overview of desktop entitlements to Active Directory users and groups
Configuration – All configuration for View 3.0 can be done here as mentioned before
Events - All events about desktop pool creation, desktop refresh etc. Events can be searched and filtered on number of days through the always-good-to-know symbol that VMware uses to show that more options are available: the triangle ;-) which looks like this:

Picture 2 – VMware View Administrator, configuration tab

Picture 3 - An view on the ‘Desktops and Pools’ tab in the View Administrator console, showing two desktop pools; one non persistent, one persistent

View Composer

View composer is a separate piece of software that has to be installed on the Virtual Center server if you want to use linked clones. Prior to doing that, a database needs to be created for which I used an MS SQL 2005 database, but SQL Express is also supported. You might consider using a separate account for the View Composer to run under, however I used the Active Directory Service account that Virtual Center is running under and granted the account dbowner rights on the LinkedClones database.

While installing the View Composer software, the ‘VMware View Composer’ service is added as a Windows Service, however I could not finish the installation until I changed the logon credentials to run under the same account that ‘VMware Virtual Center Server’ service is running on. In the Administrators’ guide for View Manager 3.0, page 104 or in Table 1 below, you can see exactly which permissions are needed for View Composer to work.

Privilege	Group Privilege(s) to Enable
Folder	Create Folder
Data store	Browse Data store, File Management
Virtual Machine	Inventory Configuration State
	Provisioning > Clone
	Provisioning > Allow Disk Access
Resource	Assign Virtual Machine To Resource Pool
Global	Enable Methods, Disable Methods

Table 1 - View Composer Account – Minimal Privileges in Virtual Center

View Agent

View Agent is the component that you install inside the virtual machine that you want to use as a master VM. With the machine that you decide to make the ‘Master Virtual Machine’, you can deploy other virtual machines that are cloned from the Master VM. The VMware view agent consists of the following components:

Picture 4 – Custom setup window of the View agent which is installed on the master VM

· VDM Secure Authentication – This feature will install a piece of software that handles single sign-on. A user has to enter his credentials either on the View Portal or in the View Agent that is installed locally on his computer, and these credentials can be passed to the virtual desktop provided by View 3.0. This works in conjunction with the View Client, in which you can configure to use SSL for your communication or not.

· USB Redirection – This feature handles connections from the clients’ desktop USB devices to the virtual machine. I’ve already found out that HP USB keyboards with integrated smart card readers are not supported and requested an update for that particular device. There are probably more devices that are not yet supported, so make sure you test the devices that you might plan to use in your company’s View 3.0 future.

· VMware View Composer Agent – This feature needs to be installed if you plan to use linked clones, more on that in Part 2 of this article.

· Virtual Printing – This feature installs ThinPrint universal printing software. I found version 7.8.0.3 of the ThinPrint Output Gateway, dated 07/12/2007 and version 1.0.0.11 of the PostScript driver, which is more recent, dating from 6/18/2008. I concluded that with advanced multi-functional devices, not all options like stapling your papers are supported, in contrast to the Citrix Universal Printer driver, in which you can open the client devices’ local printer properties window and access all options available in the native client driver. However, most options like paper size, orientation and duplex printing are available with the Virtual Printing feature.

View Client

View client is the component that end users have to install on their own system. With this client, USB redirection and single sign-on are supported. The View client installation package is automatically pushed if users having logged on to View Portal do not have the Client installed. The installation is straightforward, but unfortunately not available as web plug-in, so administrative permissions are required for the end user to install it. The view agent looks a bit like the regular RDP client from Microsoft; you start the client, enter the connection server that you want to logon to and after successful authentication, available resources are displayed in the View Client (see picture 5).

Picture 5 – Logon screens of the View Client, which needs to be installed on the client pc of end users.

Part 2 will be released in the next few days and cover Linked Clones. Part 3, available early next week, will discuss VMware View 3 best practices.

How to Deploy the XenApp Web Plugin (ICA Web Client) v11 via Web Interface 4.6 and Web Interface 5.0

Katie Koepke — Mon, 10 Nov 2008 22:20:00 GMT

For those who would like a quick “Google-able” article on how to deploy the new XenApp Web Plugin (formerly known as the web client) this is the article for you.

To do this, you basically follow the instructions from CTX114097, “Deploying the Web Client 10.1 for Windows through Web Interface 4.6” but with a few modifications.

First, download the XenApp Web Plugin from Citrix.

For Web Interface 4.6

Rename XenAppWeb.msi to Ica32Web.msi.
Copy Ica32Web.msi to \Program Files\Citrix\Web Interface\4.6.0\Clients\ica32. (Create the ica32 directory if it does not exist.)
From a command prompt run iisreset.

For Web Interface 5.0:

Copy XenAppWeb.msi to \Program Files\Citrix\Web Interface\5.0.1\Clients\ica32.
(A rename of the file is not necessary.)From a command prompt run iisreset.

Automatic Deployment and Installation of the Web Client

Web Interface 4.5 was the last version of Web Interface where automatic deployment and installation of the web client was an option. This is due to increased browser security in Internet Explorer and Vista making this capability too difficult. That said, you can only configure "automatic detection" in versions 4.6 and 5.0 as described above, versus "automatic deployment."

You should run Web Interface 4.6 instead 4.5 but if you must know how to configure automatic deployment, refer Citrix's article "How to Deploy the ICA Web Client Through Web Interface 4.5."

*Special thanks to Bertine Luzincourt and Scott McDonald from Citrix for their help!

Vista Aero Glass for VDI: What's real today

Glenda Canfield — Sun, 24 Feb 2008 22:00:25 GMT

Recently at the Citrix Summit I collaborated with the Citrix Multimedia Virtualization Team to present a demo using XenDesktop / PortICA to deliver Vista Aero Glass from HP 2500 series blade PCs to HP's t5730 (XPe) / t5735 (Linux) thin clients. (PortICA is "port ICA," which is a Citrix implementation of the ICA protocol being served by a Vista workstation for VDI scenarios. The demo we presented was completely dependant on PortICA which requires XenDesktop. This is not officially supported by Citrix or HP at this time.)

I also participated in a panel discussion with two members of the Citrix's Multimedia Virtualization team: Derek Thorslund, Product Strategist, and Juan Rivera, Sr. Development Manager. We discussed Project Apollo as well as the various protocols and what the use case would be for each. If you attended Summit you should be able to download the video recording and slide deck from the session. (Session ID 806 - Multimedia Requirements for Desktop and Application Virtualization)

In this article, I would like to discuss a bit about how this demo worked and review some of the technical components required to deliver a Vista Aero Glass desktop to a remote client. Before I do this, let's review the two different protocols that I'll reference:

Citrix Project Apollo (PortICA, via the Thin Wire Virtual Channel): Project Apollo is currently pre-alpha, but my understanding is that the graphics travel inside the ICA Protocol over the Thin Wire virtual channel. Glass graphics are compressed on the backend (or the VDI instance, in this case of a blade PC or workstation blade) and then decompressed on the client side using a CODEC that will probably be embedded in the ICA Client. The Connection Broker for this will of course be the XenDesktop broker.

HP Remote Graphics Software (RGS): HP's RGS is a protocol that allows realtime remote access to graphics over a LAN providing a local user experience. RGS uses a proprietary HP3 CODEC. A key benefit here is if you're using a pure HP-based solution, this protocol can be brokered by SAM (Session Allocation Manager, a broker which is sold with HP solutions only.)

Both of the above protocols work in essentially the same way. They're both screenscrape-based protocols. The graphics are compressed on the backend resource and decompressed on the end point using a CODEC. Both PortICA/Apollo and RGS are capable of remoting Vista Aero Glass to NON-Vista Aero end points. (UPDATE: Since writing this article, HP contacted me to clarify that remoting Aero Glass is not "officially" supported over RGS, despite the fact that the lead RGS developer told me otherwise. So take that for what it's worth!)

What's the difference between a Blade PC and a Workstation Blade?

Now that we've looked at the protocols, let's look at something else that I'll discuss in this article: "Blade PCs" and "Workstation Blades." Most people probably use the two terms interchangeably, but hardware vendors like HP do not. To HP, these are two different things. The main difference is the hardware specs of the two, although there's a cost difference as well. (Although in reality, any high-end graphically-intense VDI solution is going to be expensive. In most cases when it comes to a solution around high-end graphics, money is not the key factor and the decisions are based on performance and end user experience/perception.)

HP 2500 series "Blade PC"

AMD Athlon 64 X2 3000+ dual-core processor
80GB Serial ATA 5400 RPM hard drive
1GB DDR2 SDRAM PC2 5300 (667 MHz) expandable to 4GB (2 SODIMM slots)
Two Broadcom 590 10/100 Integrated NICs, capable of PXE Boot
Embedded ATI DirectX 9-compliant graphics card

HP Documentation indicates this is “ideal for knowledge workers requiring cost effective access to many applications with increased graphics”.

HP xw460c "Workstation Blade"

1 or 2 Intel Xeon dual-core processors running at up to 2.66 GHz
NVIDIA Quadro FX high performance graphics adapter
Up to 16GB of ECC, DDR2 memory running at 667 MHz
Two 1 GB/s NICs
1 to 2 high-speed Serial Attached SCSI disk drives

HP Documentation indicates this is “ideal for engineers, designers, and traders with applications requiring more demanding 2D/3D graphics and/or the support of more than two displays”

As you can see, a "Workstation Blade" is a much higher-end device, with more processors, more RAM, and a SCSI disk. It is truly an Engineer's Workstation in a blade form factor, whereas a "Blade PC" is more like a typical end-user's computer.

The collaboration between HP and Citrix

What made the collaboration between HP and Citrix on Project Apollo interesting in my mind are two things:

The first is that most servers do not have a GPU in them, and even if they did, you cannot share the GPU in a hypervisor solution because of I/O issues. So to provide a full multimedia experience you only have two “realistic” choices: a blade PC or a workstation blade because each is a 1-to-1 connection which means each user gets their own GPU. You must have a resource on the backend that is Vista Aero Glass capable in order to deliver it to an end point such as a Thin Client. (Of course it's also necessary to have an protocol algorithm that can support it, i.e. PortICA or RGS.)

NOTE: For those of you unfamiliar with the recommended hardware requirements for Vista Aero Glass, they are a 1GHz processor, 1GB of RAM, and a DirectX 9-capable 3D graphics system.

The use case for this would be end users who are working with graphically-intense applications. As the .Net 3.0 architecture becomes more widely adopted and more WPF and 3D applications are deployed, people will be forced to migrate to Vista to take advantage of them. It is not currently possible to get this experience from XP. Nor can you get it from Vista in a virtual machine because Aero Glass is not supported in VMs. Most users are leveraging productivity applications today so for the most part hypervisor-based VDI is sufficient to meet their needs.

However, the more common VDI becomes, the use case for Blade PCs and Workstation Blades will become more compelling as a solution. Certainly some of the existing barriers to adoption will be a thing of the past. The way I see it, with servers becoming more commoditized (with the advent of hypervisors in general, but especially with the embedded hypervisor), the more important the end user experience will become. That means MULTIMEDIA!

A potential road block that I see is having a broker to manage the connections. I understand that at this time the only qualified connection broker is HP's SAM Broker. A key benefit here is if you're using a pure HP-based solution, the RGS protocol can be brokered by SAM (Session Allocation Manager). Both RGS and SAM have been fully qualified on both the HP Blade PCs & Workstation Blades. Today you can remote Vista Aero to XP with RGS but it is not available for Thin Clients.

The second interesting thought is the idea of delivering Vista Aero Glass to a thin client, particularly a Linux-based thin client. Linux is becoming a very attractive option for customers as VDI is becoming more popular simply because the idea of paying for a license for two Microsoft operating systems is unappealing to pretty much everyone. There are also a lot of customers who look at Linux and think “zero maintenance.” In some cases they see that as being more important--more so even than the cost of two Microsoft licenses. A barrier here is end user acceptance. You have to get buy-in from them for this to be successfully deployed. I can say having worked with Linux thin clients, most are starting to look and feel closer to Windows but there is still a marked difference in how you navigate.

I see a great future for VDI, but until the server GPU I/O problem is solved Blade PCs and Workstation Blades are really the only viable solution if you want a complete Vista Aero Glass and Multimedia experience in a VDI scenario. Both HP (RGS) and Citrix (PortICA) are doing some pretty cool work around this and I find it intriguing that it will soon be possible to get a Vista Aero Glass experience using Blade PC's/Workstation Blades to deliver a real-time multimedia experience to a Thin Client, whether it is XPe or Linux.

VB Script to Backup / Restore CPS policies

Mark Elliott — Thu, 06 Dec 2007 06:31:46 GMT

In response to several requests in our forums, Mark Elliott has written a couple of VB scripts that backup and restore policies stored in a Citrix Presentation Server 4.0 or 4.5 farm.

The backup script is pretty straightforward. It allows you to parse two (optional) parameters:

Logging detail level
XML file name the policy information is written to

The restore script has some more parameters, all of which are optional. For example, you can:

Specify the logging detail
Whether or not to apply the policy filter
Whether or not to overwrite a policy if it already exists
The name of the XML file that you're restoring (from the backup script)
The policy name (if you only want to restore a subset of the policies in the XML file)

Download a ZIP file containing these two scripts here.

How to Automate the Backup of a SQL Server 2005 Express Data Store

Katie Koepke — Mon, 07 May 2007 07:13:31 GMT

I recently built a Presentation Server 4.5 (PS 4.5) farm where the decision was made to use a SQL Server 2005 Express database as the IMA data store. When it came time to create an automated backup of the data store, I soon realized the process was not at simple as creating a SQL job in a friendly GUI as with a full-blown SQL Server install, or running DSMAINT BACKUP. This article describes how automate the backup a SQL Server Express data store without having to purchase a third-party tool or without having to learn SQL programming. That said, this document is intended for the non-SQL savvy administrator unfamiliar with creating T-SQL statements.

As you may know, it’s very easy to install and use a SQL Server Express database as your data store since Citrix provides at custom batch file in the PS 4.5 Support folder. Running \Support\SqlExpress_2005_SP1\SetupSqlExpressForCPS.cmd automatically installs and configures a SQL Server Express instance named CITRIX_METAFRAME. By default, three SQL Server Express configuration tools (SQL Server Configuration Manager, SQL Server Error and Usage Reporting, and SQL Server Surface Area Configuration) are also installed on the server, but none of these can be used to configure a backup.

Creating the Database Backup Script

For further SQL Server Express management options download and install SQL Server Management Studio Express . This is a free tool from Microsoft and will be used to create a script to backup your data store.

Once the tool is installed, launch Microsoft SQL Server Management Studio Express and connect to the CITRIX_METAFRAME instance.
Expand Databases and you will see the MF20 database. (This is the default name of the database that was created when creating the Presentation Server farm.)
Right click the MF20 database and select “Tasks | Backup”. A dialog box appears allowing you to define different options such as what type of backup (full or differential) you want to do, backup destination etc. Configure the available options as desired then click the “Options” page on the left-hand column. Continue configuring options accordingly. For example, you may want to select “overwrite all existing backup sets.”
Once all desired options are set, select “Script | Actions to File” and enter a desired file name, for example, “DatastoreBackup,” and specify the location where to save the file.

This creates a .SQL file which scripts the options you defined in the prior step. The contents of your .SQL file may look like this:

BACKUP DATABASE [MF20] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\MF20.bak' WITH NOFORMAT, INIT, NAME = N'MF20-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO

To test your .SQL file run the following from a command prompt.

sqlcmd -S .\CITRIX_METAFRAME -i "C:\<enter path to .sql file>\DatastoreBackup.sql"

If the MF20.bak file was created with the correct data and time stamp then you know your script works. By default the MF20.bak is located in C:\Program Files\Microsoft SQL Server\MSSQL\MSSQL\Backup. (This folder might be “MSSQL.1” or “MSSQL.x” depending on what else is on your server.)

Automating the Database Backup

You can automate the backup process by creating two Scheduled Tasks.

SQLCMD Scheduled Task

First, create a Scheduled Task to automate the .SQL script created above. Use the Scheduled Task Wizard and when asked to select a program browse to use browse to C:\Program Files\Microsoft SQL Server\90\Tools\binn\ SQLCMD.exe. Define the Schedule Task parameters accordingly and click “Finish”.
Go the properties of the newly created Scheduled Task and edit the Run command as such.

"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE" -S .\CITRIX_METAFRAME -i "C:\Program Files\Microsoft SQL Server\DatastoreBackup.sql"

Copy MF20.bak Scheduled Task

Next, create a simple batch file to copy the MF20.bak from the local server to a network share located on server being backed up regularly. For example, create a file named, “CopyMF20bak.cmd”, with the following contents.

copy "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\MF20.bak" "\\<servername>\<sharename>\"

Lastly, create a simple Command Prompt Scheduled Task and configure accordingly. (Make sure to run this Scheduled Task after the SQLCMD Scheduled Task.) Go to the properties of the newly created Scheduled Task and edit the Run command to point to the location of CopyMF20bak.cmd (or your respective batch file name).

Resources

http://www.sqldbatips.com/showarticle.asp?ID=27
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=487021&SiteID=1
http://msdn.microsoft.com/vstudio/express/sql/download/

Login Consultants releases free tool for converting MSI packages to SoftGrid sequences!

Jeroen van de Kamp — Tue, 06 Mar 2007 12:10:00 GMT

Now that Softricity has been acquired by Microsoft and its price has been decreased so much, interest for SoftGrid is rapidly growing. Most enterprises have invested in MSI-based application packaging, and converting these packages into SoftGrid sequences can be laborious. To address this, Dennis Damen and Rodney Medina have created the SoftGrid Migration tool (SMGT). The SoftGrid Migration Tool is an add-on for the native SoftGrid Sequencer that helps you quickly “convert” existing automated application setups to SoftGrid Virtualized Applications (a.k.a. "streams" or "sequences") with the least possible amount of user intervention. This tool can be a huge benefit if you're planning to integrate SoftGrid with an existing software distribution sytem like SMS or Altiris. (If you want to virtualize applications that only have a manual setup, we still recommend using the native SoftGrid Sequencer.)

When using the SoftGrid Migration Tool for converting applications the SoftGrid sequencing, best practices still apply. (Check out Microsoft KB article 932137 for a list of sequencing best practices.)

The SoftGrid Migration Tool was written in Visual Basic 2005 and requires the .NET Framework 2.0 or higher in order to work. It's very easy to use:

From the zip file, copy the SGMT.exe, defaults.ini, and SettingsChanged.exe to the sequencer machine and start the SGMT executable.
Add the automated application setup(s) that needs to be converted to one virtual application.
Enter the appropriate SoftGrid Sequencing settings.
Click Start.
When done, copy the content of the entered output path to the SoftGrid Server’s content folder.
Import/Add the application to the SoftGrid Management Console.
Always test the application afterwards!

The tool is 100% freeware and available from Login Consultants download section (free registration required).

Updated: Lanmanserver and Lanmanworkstation Tuning

Michel Roth — Tue, 20 Feb 2007 00:00:00 GMT

Fileserving in Windows environments is usually of critical importance. After all, if you can't reach your files or have to wait five minutes every time you browse a share, the heat starts to build up in the IT department.

File serving is more than just saving a file to your home directory. I wrote a two-part article on MSTerminalServices.org on file serving and Terminal server environments. I suggest you read that article (Part 1 and Part 2 ) first to get a feel for the proper context of this article.

One of the main reasons I wrote that article is that fileserving can easily become a bottleneck if not configured properly, especially in Terminal Server environments.

To solve these performance problems, you sometimes have to tune the fileserver (lanmanserver) and the “fileserver-client” (lanmanworkstation). However, this isn’t for the faint of heart and can cause huge problems if you do it wrong. Unfortunately, documentation on these tuning parameters is rather scarce.

So in this article, I’ll try to explain what the important parameters are, what they do, and how they relate to each other. Once you know this, you'll be able to tune your fileserving environments yourself.

Before we jump into this, please note that there are also a great deal optimizations that you can do in the "Terminal Server Terminal Server Client" hemisphere. Although the basic fileserving principles also apply in that area, this article is not meant to help you perform those optimizations. Also, there is a lot of additional tweaking you can do in other parts of the (Terminal Server) registry. I've purposely left these optimizations out because I wanted this article to focus on the performance of Fileserving components only.

This article was written assuming you’re running Windows 2000 (SP4+) or Windows Server 2003, Service Pack 1.

Core Components

Before we get down and dirty, we need to take a look at the core components that the Windows file serving environment is made of. File serving in Windows is a classic example of a Client-Server mechanism. All you have to do become a file server is to check the box “file and printer sharing for Microsoft networks” in the network connection properties box. On the other end all you have to do to “use” this file server is to check the box “client for Microsoft Networks”.

Both the server and the client components are run as a service. Not surprisingly, this is the "Server" service for the server component and the "Workstation" service for the client components.

Settings for these services are stored in the Windows registry. For the Server service this location is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver. The corresponding location for the Workstation service is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation.

Lanmanserver

By default, the lanmanserver registry key on a freshly installed Windows Server 2003 Service Pack 1 machine looks like this:

The first sub key we encounter is the “AutotunedParameters” key. If you look at it you'll see that it's empty. Don’t worry--it’s supposed to be empty. This registry key exists because, by default, the Server service is auto-tuning. This means that every time the system boots, the server takes a look at the hardware configuration and incorporates any changes in the configuration of the Server service. Changes in hardware that are monitored are the amount of memory and the number of processors. There’s even a formula for it:

(4*(MB*SMBServerPerfSetting)*OSVersion/1)*(#Processors)

where:

MB = Megabytes RAM on the server
SMBServerPerfSetting = .5 if "Minimize Memory Used"
SMBServerPerfSetting = 1 if "Balance"
SMBServerPerfSetting = 2 if "Maximize Throughput for File Sharing"
OSVersion = 2 if running NTServer with > 16MB RAM
#Processors = is the number of processors in the system

In the formula you’ll notice that it refers to the SMBServerPerfSetting. This brings us to the only GUI ‘tool” native to Windows that you can use to “tune” the Server service. When you select the properties of a connection and then select the properties of “file and printer sharing for Microsoft networks”, you should end up with a window like this:

This is where you can optimize the Server service for a specific role. Consequently, if you do the numbers you’ll see that the higher you set the SMBServerPerfSetting, the higher the outcome of the formula is. But what is this number? Good question.

This number represents the value Windows will use for the MaxWorkItems, an important value in tuning the Server service. However, MaxWorkItems is just one of the parameters you can set to tune your fileserver. Let’s take a look at the (registry) values.

Parameters

Before we begin discussing the relevant parameters you can use to tune the Server service you should know that you should create them in the parameters sub key of the lanmanserver registry key. Let’s take look at the most important parameters:

MaxWorkItems

As said, MaxWorkItems isn’t the only thing tuning the Server service. It is one of the most important parameters though. What does this parameter mean? Well, MaxWorkItems specifies the maximum number or work items (receive buffers for file requests) that the Server service is permitted to allocate at one time. If this limit is reached, you get really bad performance out of your file server on even no performance (new connections to the file server are denied).

Possible values: 1-65535

InitWorkItems

This configures the number of work items allocated to a processor during startup. (The "initial" work items.) If this number is too low, it can significantly reduce performance or even deny new connections to the file server.

Possible values: 1-512

MaxMpxCt

This parameter permits a fileserver to provide a suggested maximum number of simultaneous outstanding client requests to itself. During negotiation of the Server Message Block dialect on this initial connection, this value is passed to the client's redirector where the limit on outstanding requests is enforced. A higher value can increase server performance, but requires more use of server work items (MaxWorkItems).

Possible values: 1-65535

MaxWorkItems and MaxMpxCt Relationship

The value for MaxWorkItems must be at least four times as large as that for MaxMpxCt. For example, if MaxMpxCt has a value of 4096, then MaxWorkItems needs to have a value of at least 16384.

MaxRawWorkItems

This value determines the maximum number of raw receive buffers that a server can allocate. If this limit is reached, server performance may be degraded.

Possible values: 1-512

MaxFreeConnections

This value controls the number of free connection blocks that are maintained for each endpoint.

Possible values: 2–4096

MinFreeConnections

This value specifies the minimum number of free connection blocks to be maintained for each endpoint. This setting can sometimes dramatically improve performance.

Possible values: 0–256

SizReqBuf

This specifies the size of a WorkItem (see MaxWorkItems) that the Server service uses. Small WorkItems use less memory, but large WorkItems can improve performance.

When running applications that use a lot of copy or move functions to a remote server (profiles anyone?), the speed at which this function completes is determined by network speed (of course) and by the SMB size. By increasing this WorkItems size, you will allow the server to complete its file copies faster. This will increase the performance of the application making the copy/move calls.

For computers running Windows Server 2003 and with 512 MB or more of physical memory, the default size of the request buffers is 16,644 bytes; for servers with less physical memory, the default size is 4,356 bytes. If this entry is present in the registry, its value overrides the default value.

Possible values: 1-65535

Lanmanworkstation

This key is where all the configuration data for the Workstation service is stored. The lanmanworkstation key by default, looks like this on a freshly installed Windows Server 2003 Service Pack 1 machine:

As you can see, there’s no “AutotunedParameters” here. However, there is a "parameters" sub key in which we can do some tuning. It is not uncommon (especially in Terminal Server environments) to have to tune the Workstation service to alleviate performance problems. This is due to the nature of Terminal Servers. My article on MSTerminalServices.org discusses this in detail, but in a nutshell it’s like this: the workstation service was (and is) designed for a single workstation (like your desktop). However, a Terminal Server can easily host 50 desktop sessions, but unless you do manually intervene this server most likely is still configured just as your desktop would be. It’s pretty obvious that this could lead to some performance problems.

Parameters

Although there aren’t that many important parameters like in lanmanserver, there are still a few parameters of the Workstation service you should definitely know about.

MaxCmds

Specifies the maximum number of network control blocks that the redirector can reserve. The value of this entry coincides with the number of execution threads that can be outstanding simultaneously. Increase this value to improve network throughput, especially if you are running applications that perform more than 15 operations simultaneously.

MaxCmds actually serves the same purpose as the MaxMpxCt on the Fileserver. Not surprisingly these two parameters have a special relationship. It’s like this: whenever an SMB session is setup (i.e. a shared file is accessed), the SMB session is negotiated. During this negotiation the Fileserver passes down the value of MaxMpxCt to the client (a Terminal server for example). The client then compares this value to his own MaxCmds value. The lower of the two values then is used to set a maximum on the number of outstanding client requests to the File server.

Possible values: 1-65535

MaxThreads

The MaxThreads specifies how many threads are allowed to run at once. (Each thread allows one outstanding operation.) By increasing this you can increase the amount of simultaneous work. Each extra execution thread will take 1 Kbyte of additional NonPaged pool memory.

Possible values: 1-255

MaxCollectionCount

Specifies the amount of data that must be present in the buffer of the redirector to trigger a write operation. If the amount of data in the buffer meets or exceeds this value, then it is written immediately. Otherwise, it is retained in the buffer until either more data is added or the value of the CollectionTime entry expires.

Possible values: 1-65535

Monitoring

Problems stemming from poor fileserving performance can sometimes be a bit tricky to pinpoint. One way to make sure is by using good ol’ perfmon. The problem with interpreting perfmon counters is that you can never know what the "right" value is unless you have baselined your environment properly. So what to monitor and how to interpret those values is entirely up to you. However, there are some counters you can monitor that I can give some basic tips on. Configure perfmon to monitor the following counters:

Physical Disk

You can measure this on the Terminal Server as well, but you should start at the file server. If the queue length is more than one for a sustained period of time, then your disks are hyperventilating. Give them some air: up your I/O throughput. Look on the software-side: are you paging a lot? (that'll kill your I/O throughput right there) or is your system disk heavily fragmented? Or on the hardware side: buy faster disks (15K SCSI) or upgrade your RAID controller.

Redirector

This is something you should only measure on your Terminal Server(s). You should monitor the "current commands" in the Redirector object. If the value is higher than 20 during sustained periods of time then you could have a bottleneck.

Server Work Queues

The Server Work Queues object should be monitored on the File server. You should monitor the "Available WorkItems" counter. Sustained values smaller than ten mean that the File server is running out of work items. When it does, performance really starts to plummet. Make sure this doesn't happen by upping the MinFreeworkItems value.

Server

In this object there's a counter called "Work Item Shortages". This value represents the number of times no work items were available or couldn't be allocated to service a file request. Obviously if you see any other value than zero, you need to start worrying. Upping the InitWorkItems or MaxWorkItems could help out here.

Again, there's so much more you can monitor but interpreting the results depends heavily on your environment. Just browsing the performance monitor objects I mentioned and playing around with it will give you a lot more information.

Tuning

So what do I set these registry values to? Unfortunately it’s not that simple. For starters, it depends on your specific environment. Also, an unfortunately side effect of almost every one of these registry values is that when they are increased, they consume more kernel memory. Seeing as (the lack of) kernel memory is often a bottleneck in scaling up in Terminal Server environments, you should be very careful in adjusting/creating the registry settings we discussed. If you are not careful, you could end up having more performance problems than you started out with. You need to know why.

Tuning LanManServer and LanManWorkstation in the registry, requires the use of more Non-Paged Pool memory. This can be a real issue on the File Server (LanManServer). Let me briefly explain where Non-Paged pool memory fits into the whole “2GB-Kernel--Memory-Bottleneck-Of-32-Bit-Windows”.

When you have a 32 bit operating system, this means that you have a 32 bit address space. That translates to 4GB of addressable memory space (2 to the power of 32). This 4GB is evenly shared between the user mode and kernel mode. User mode is the memory space that applications run in and kernel mode is used by the system for everything else. This 2 GB kernel mode memory is divided into several areas, amongst which is the NonPaged Pool. Because there’s only 2GB to share, the NonPaged pool gets configured with a maximum size at boot time. By default this is 256 MB. This 256 MB is the area in which you should perform your (LanManServer) tuning.

Why should you worry about this 256 MB? Well, because if the NonPaged pool is depleted then your system usually becomes unresponsive until some NonPaged pool becomes available again. So how does this apply to LanManServer tuning? Well, if you tune LanManServer in such a way that it allocates memory than the NonPaged pool has available and you indeed use up ALL of that allocated memory then you have effectively pushed Windows beyond its limits.

So what should you do? A safe way of doing it is to tune LanManServer in such a way that it can never deplete the NonPaged pool. The amount of memory LanManServer allocates in the NonPaged Pool is primarily determined by two parameters: MaxWorkItems and SizReqBuf. So if you set MaxWorkItems to 8192 and SizReqBuf to 16644 (default) (which in reality is 20480 due to tracking overhead) the amount of memory LanManServer will allocate is (8192 x 20480 bytes) 160 MB. This fits nicely into the 256 MB NonPaged Pool area.
So it basically boils down to this: If you have more than 512 MB of memory in your Terminal Server (which is every Terminal Server on earth and adjacent planets) then SizReqBuf starts out at 16644. This allows you to push the MaxWorkItems value to 8192. If you try higher numbers to create more of these similar sized WorkItems AND your File Servers tries to use these, you run the chance of running out of NonPaged Pool.

So there is however a decent chance that having 8192 WorkItems does not cut it for you. This is when the bits start to hit the fan. If you’re in that rather sad place, you really have only three options, with option 3 being the safest choice:

Try making the size of the WorkItems smaller (trough the SizeReqBuf parameter) so you can safely set higher MaxWorkItems values. For example: If you set SizReqBuf lower to 8322 (plus a overhead of 3836 makes 12158 bytes) then this would allow you to have 13800 WorkItems ( 160MB / 12158 bytes).
You could even try to up the MaxWorkItems and SizeReqBuf values further with the risk that you run out of NonPagedPool. Now, you should also know that you can tune the Kernel Mode memory in such a way that more memory is allocated to the NonPagedPool. The downside to this is of course is that this memory is taken away from other parts of the Kernel Mode memory. I wouldn’t go there if I were you (unless you’re up there with the likes of Mark Russinovich).
Make sure that less Work Items are demanded from the File Server. This is a topic on its own but quick suggestions are: limit folder redirection (especially Application Data) or / and distribute File Services (put for example home directories on one Fileserver and redirected folders on another).

.ADM Templates

I have provided two .adm templates, one for lanmanserver and one for lanmanworkstation. I've separated these purposely because the lanmanserver adm template should be applied to your File Server and the lanmanworkstation adm template should be applied to your Terminal Servers.

Thincomputing.net Lanmanserver Tuning.zip

This template (download) contains all of the Lanmanserver parameters discussed in this article. When you import the ADM template and enable the policy, it will set the following parameters to the maximum recommended, safe values:

MaxWorkItems
InitWorkItems
MaxMpxCt
MaxRawWorkItems
MaxFreeConnections
MinFreeConnections
SizReqBuf

These optimizations should applied to your FILESERVER, not your Terminal Server. I've included the possibility to 'undo' the optimizations made the template. You can do this by selecting -Undo Lanmanserver Optimizations- and REBOOTING.

Thincomputing.net Lanmanworkstation Tuning.zip

This template (download) contains all of the discussed Lanmanworkstation parameters in this article. When you import the ADM template and enable the policy, it will set the following parameters to the maximum recommended, safe values:

MaxThreads
MaxCollectionCount
MaxCmds

These optimizations should applied to your TERMINAL SERVER, not your File server. I've included the possibility to 'undo' the optimizations made the template. You can do this by selecting -Undo Lanmanworkstation Optimizations- and REBOOTING.

Final Thoughts

Although some settings have been improved in Windows 2000 and even more in Windows Server 2003, I must say that I’m a bit disappointed that file serving problems like I discussed in the article are still quite common in Terminal Server environments. These problems have been around just as long as Terminal Server has, and one would think these problems would at least be a lot less common, but maybe that’s just my point of view.

Microsoft, finally, recently has published an excellent article which discusses these issues in very good detail. This article isn’t just about Terminal Server environments but it is still the best article Microsoft has ever written on the subject. Bookmark KB317249.
I hope that this document has provided you with enough knowledge to combat file serving performance problems.

There’s however a good chance that these problems with the file serving components of Windows will relatively soon be something of the past or at least be a lot less common. Windows Vista and Longhorn server will incorporate many changes, amongst which are major revisions in the file serving components. For example Vista comes with a major revision of the SMB protocol identified as SMB 2.0. The current protocol (SMB 1.0) was built to support file-serving solutions a couple of decades ago and was based on the assumptions existing then.
These are some of the key enhancements in SMB 2.0:

SMB 2.0 supports an arbitrary, extensible way of compounding operations to reduce round trips. This makes the protocol less chatty as compared to SMB 1.0. Chattiness of SMB 1.0 has often been a major pain point.
SMB 2.0 supports much larger buffer sizes compared to SMB 1.0.
SMB 2.0 greatly grows the restrictive constants in the protocol, so we never need to worry about the protocol itself being the limiting factor for scalability. This includes increasing the number of concurrent open file handles on the server, and the number of shares that a server can share out, among other things.
SMB 2.0 supports durable handles that can withstand short network glitches.

All these enhancements in SMB 2.0 will result in better performance and security over LAN and WAN.

Sounds good huh? I’ll believe it when I see it, but the file serving future looks bright!

How to use hot-pluggable client USB storage devices with Citrix Presentation Server

Dennis Damen — Thu, 15 Feb 2007 00:00:00 GMT

A lot of people have been complaining about USB disk support in Citrix Presentation Server. When a user connects a USB drive while working in a Citrix ICA session, the drive will not become visible in that session. While Microsoft has already added support for this in their RDP protocol, Citrix lags behind on implementing this in ICA.

While researching the possibilities of adding support for this ‘hot plugging’ myself, I stumbled upon a great tool called ‘USBDLM’ written by Uwe Sieber. By default, Windows allocates the first available drive letter to an inserted USB storage device which makes management of this device somewhat troublesome. USBDLM installs as a service on a Win32 client and enables YOU, the administrator, to predefine where and how USB disks are made available to your operating system using a simple ini-file. (Just the way we like it!)

While reading the manual, I also came across the possibility to mount USB storage devices to a predefined folder. This is when I realized that this tool could be of great value to the Citrix community. Below you will find a set of instructions on how to make hot plugging USB disks possible within your environment.

The How to Guide

First of all, download USBDLM from http://www.uwe-sieber.de/usbdlm_e.html, extract it, and follow the simple steps as described below. Mind you, USBDLM is NOT free for commercial use so please read the license agreement.

Step 1: Edit the configuration file (on the client)

In the UBDLM directory you will find a USBDLM_example.ini file. Copy this file, rename it to “USBDLM.ini,” and open it using notepad. Scroll down to the [setting] part and add the “ForceDriveLetters=1” setting. Now, scroll down to the [DriveLetters] section and change the “Letter1=” to “Letter1=C:\USB\%DiskName%”. Make sure you save the ini file in ANSI format. UNICODE is not supported.

Step 2: Creating a mount folder (on the client)

As said, USBDLM is able to mount a USB storage device to a folder instead of assigning a drive letter to it. To enable this feature we need to pre-create a folder where USBDLM can mount the USB storage device. Following the previous step we need to create a folder called “C:\USB”. The folder %DiskName% will be auto-created.

Step 3: Making all USB storage devices available through one drive letter (on the client)

Substitute the folder that we created in the previous step using the user’s login script. CMD-based login scripts could add the following line: “SUBST X: C:\USB”. From now on all client USB devices will be available though this drive letter.

Step 4: Enable Client drive mappings (on the server)

There are a number of ways to enable client drive mapping for your Citrix farm. Use the method that best suits your environment.

Step 5: Log on to Citrix farm

Log on to your farm with client drives enabled. The substituted drive will be visible as a normal client drive. Now insert your USB storage device and wait for the contents to show up.

Here's a screen shot from the client showing the local USB device and the remote folder.

Have fun!

Are thin client devices still relevant in a world of $300 Dell PCs?

Michel Roth — Fri, 26 Jan 2007 11:00:00 GMT

I know I’ve ranted about this before but I’m going to have to do it again. Earlier this week I received an email from Dell about their latest offerings. My entire home lab is Dell-based. Why? Because they're cheap and reliable. Anyway, in the email I got they were offering a PC to me (as a consumer) for €249 (which is about $325). The specs of this machine are:

AMD AthlonTM 64 3200+ processor
XP Home
512MB DDR2 533Mhz
80GB SATA (7,200rpm)
Integrated nVidia 6150-LE_Nforce
48x CD-RW/DVD Combo

So nothing fancy right? Sure, if you look at it in terms of a game PC for home. But what if you look at it as a thin client or a company PC? Just to compare prices: one of the better and cheaper thin clients out there in my mind is the Wyse S10. These go for $289 (list price).
So if you think about it, for about thirty bucks extra you could have a fully-fledged PC in stead of a thin client. Now I have always been a strong believer in thin clients mainly because of the following advantages:

No moving parts, so a longer lifespan
Lower investment (purchase cost)
Security: no data is on the device
Lower Power Consumption
Almost no management cost (dumb device)

But if you take a look at these arguments today, this is what it looks like:

No moving parts, so a longer lifespan

True. Say that a PC lasts 3 years and a Thin Client 5 years. Even if this were to be true this does not do you that much good. Unless you’re using a Thin Client to Telnet into your AS400 system then even Thin Clients get overage at about three years. Examples:
New OSes (Windows XPe, Windows CE, Linux) that require more resources that the Thin Client eventually can’t provide.
New other software: ICA Clients, RDP 6 Client, ThinPrint clients etc. that require more resources that the Thin Client eventually can’t provide.

New peripherals become a commodity and users need to use them. The Thin Client might not be able to provide in this, certainly not at the hardware level.

Most important of all: the use of Server Based Computing environments is getting more and more graphically intense. Like I said, if you only use telnet then you’re fine but the reality is that once your environment offers a Windows Server 2007 Desktop with Word 2007 and Internet Explorer 8 then your Thin Client is toast.

Lower investment (purchase cost)

Well this is what started me on this rant. This used to the case but not anymore. It’s quite obvious that in this day and age Thin Clients are almost priced the same as a regular PC. Even though I am not a Thin Client vendor, I can not imagine that a company like Dell can produce a full sized PC for the same (or sometimes even a lower ) price as a Thin Client. I think that there should be a way to build a decent[/u] Thin Client for under $200. I emphasize the word decent because the are some Thin Client out there that do cost about $200 but frankly: they suck bigtime.

Security: no data is on the device

True but if you design your environment right then there should also be no data on your “Fat Client”. You can use group policy to lock them down as tight as you want.

Lower Power Consumption

This is true. Especially when you’re using a lot of thin clients, this can make for quite a bit of savings. However, the biggest power consumer in desktop PCs--the CPU--is using less and less energy. If you do the math I think that this advantage will get smaller as time goes by.

Almost no management cost (dumb device)

Historically this has been dubbed as the biggest money saver. And it is true. For example, some Wyse thin clients only require a network connection (and a configured FTP server) to work. So they literally work out of the box without any configuration. And of course on a thin client there is little a user can mess up. They cannot play solitaire on it and then can’t use it to install their favorite fileshare software. These advantages almost make it sound like it’s impossible to secure fat clients. I think this stems from the fact that around when Windows 2000 (Terminal Services) came out this was indeed the case. Group Polices and stuff like that were new. But these days, if you do it right, you can configure a Fat Client in such a way that it can only serve the purpose that you want it to. You could go even further and turn it into a Thin Client, by installing Windows FLP or using Thin Client server for example.

So these were the “advantages” of using Thin Clients. What about the drawbacks? Well, there are two major drawbacks to using Thin Clients

Usually Thin Clients have poor video performance
Thin Clients are very inflexible

Usually Thin Clients have poor video performance

This really is a big problem. Even the best of the Thin Clients (and by this is do not mean a Thin Client with a $300 PCI-X Graphics Card added ) have moderate graphical capabilities at best. The Dell PC I referenced to can have up to 256MB video memory and performs much better. This is really important issue because the end-user experience is very much dependent on the way the screen “performs.” You could be the only user on a Terminal server with 8 CPUs and 16 GB of RAM and be running Internet Explorer and still get “bad performance.”

This is a phenomenon that is becoming more and more common since the way server-based computing is being used is getting more and more graphically intense. Think about it: five years ago broadband internet, 100 page PDF papers and skinned applications were extremely rare. These days the local senior citizens association has a huge flash-based website, every single emailed document or flyer is a PDF file and the most popular text editor by Microsoft is “skinned” by default in Office 2007. So you WILL need video power to cope with all of this and this isn’t one of the strengths of Thin Clients.

Thin Clients are very inflexible

In today’s world, companies require that their infrastructure is dynamic and allows it to cope with changing business demands. This is not something that rimes with Thin Clients. The software (firmware) on the Thin Clients cannot (or hardly) be updated on demand. Usually you’re dependent on the vendor to release new firmware updates. Also, hardware upgrades like more memory or a faster CPU are usually impossible to do. Fat clients (like the aforementioned Dell) are able to cope with change. Software and hardware can be upgraded in any way the IT department pleases. Also, take into account technology like application streaming (Softricity, Citrix Streaming Server) or even OS streaming (Ardence). These technologies will co-exist or even integrate with server-based computing. Fat clients will be able to use these technologies without any adjustments. Thin clients will not be able to do so.

Conclusion

In today’s and future server-based computing environments, it seems like thin clients are losing their advantages. Todays technology allows for you to design fat client configurations in such a way that they provide the same benefits that thin clients do while still delivering better video performance and providing the necessary flexibility. So unless thin client vendors are able to start producing good thin clients at low prices, I think the future of thin clients look bleak.

Application Publishing: Comparing Longhorn Terminal Services to Citrix Presentation Server

Katie Koepke — Tue, 14 Nov 2006 09:10:00 GMT

It’s now common knowledge that one of the biggest new features of Terminal Services in Windows Longhorn Server is the ability to “publish applications”. But how does publishing applications in Longhorn compare to publishing applications in Citrix Presentation Server? This article answers this question by comparing the application publishing functionality between Windows Longhorn Server (August 2006 CTP version) and Citrix Presentation Server 4.0.

To begin, it’s important to clarify the terminology. As technologists familiar with Citrix products, Citrix terminology has become the de facto industry standard. What Citrix calls a “Published Application”, Microsoft refers to as a “Remote Program”. In this sense a Remote Program from the user’s perspective is an application running remotely on a server, but it means the same thing as Published Application. This article will refer to both terms.

Moving forward, after installing Windows Longhorn Server, you’ll naturally need to install Terminal Services. In Windows 2003 this is done via Add/Remove Windows Components, whereas in Windows Longhorn, Terminal Services is added as a “Role”. This is done by simply running the Add Roles Wizard in Server Manager. (Note that the Server Manager of Windows Longhorn is totally different from the Server Manager of the NT 4.0 days.)

When it comes time to “published applications” in Longhorn, Server Manager can also handle this functionality or you can use the Terminal Services Remote Programs (TSRP) MMC snap-in. When compared to Citrix’s Presentation Sever Java Console, Longhorn’s Server Manager provides a similar look and feel, however, when solely administering remote programs you may opt for the TSRP console.

Server Manager

Terminal Server Remote Programs MMC Snap-in

Creating a Remote Program

To create remote program (or “published application”) in Longhorn Server, you can use either the Server Manager or the TSRP MMC to launch the Remote Programs Wizard. This wizard is similar to Citrix’s Application Publishing Wizard. In short, the Remote Programs Wizard is made up of three easy windows: a welcome screen, a list of preconfigured remote programs to choose from or the option to browse to an executable, and a confirmation screen. The second window is pictured below.

Creating a Remote Program adds the program to what Microsoft calls the “Allow List”. You can view all of the available Remote Programs in the Allow List on a given Terminal Server through Server Manager or the TSRP MMC. Unlike Citrix Presentation Server where you can assign individual Published Applications to specific servers, an Allow List of Remote Programs must be created for each Terminal Server. If you have multiple Terminal Servers that require the same Remote Programs, you have the option of exporting and importing Allow Lists from server to server. Again, this can be done via Server Manager or the TSRP MMC. Another distinct difference worth mentioning is that when creating a Published Application in Citrix Presentation Server, a farm is automatically available as part of the Presentation Server’s “out-of-the-box” functionality (even if it’s a farm of one server). When publishing applications, this allows you to simply choose which server you would like to publish your application on. With Longhorn Server, a Terminal Server farm must be configured separately either using a 3rd party load balancer or using Windows NLB. (To have the ability to reconnect to a disconnected session and share a session when launching more than one application on a Terminal Server, Session Directory, which is somewhat like Citrix’s Data Collector, must be in place. Session Directory will be discussed further in a future article.) The bottom line is without manually configuring a Terminal Server farm when creating a Remote Program, you only have the option of “publishing” or allowing that program on each specific Terminal Server.

Permissions to Remote Programs

For a user to have permission to access a Remote Program, the given Remote Program must exist in the Terminal Server’s Allow List, Remote Desktop connections must be allowed, and the user must be a member of the Remote Desktop Users local group. Adding the Terminal Services role to a server automatically changes the System Properties - Remote Desktop settings from, “Don’t allow connections to this computer” to “Allow connections from computers running any version of Remote Desktop”. The former can also be configured through Local or Group policy. The final step in regards to permission is to ensure the user is a member of the Remote Desktop Users group.

You lose some granularity in controlling who has permission to Remote Programs in comparison to how Citrix Presentation Server handles who has permissions to Published Applications. With Presentation Server you can control access by the application, whereas Longhorn Server gives access to all applications in the Allow List on a given server. With Longhorn you can restrict who has access by the server, using policy etc., however, it’s not on a per-application basis. Naturally you can also leverage security groups, however, this still does not allow you to restrict access per application with the same ease as in Presentation Server’s published applications.

Methods of Accessing Remote Programs

There are three different ways you can provide access to Longhorn’s remote programs: by creating an RDP package, creating an MSI package, or accessing the Remote Program through TS Web Access. These methods will be discussed in more detail in a future article, however, here is a brief summary.

An RDP package creates an .rdp file which essentially acts the same as an ICA file and establishes a connection directly to the remote program when you double click it.
An MSI package creates an .msi file which can be installed on the client machine. This creates a shortcut to the Remote Program either on the client’s desktop and/or in the client start menu, similar to the Citrix Program Neighborhood Agent (PNA).
A Remote Program can be accessed via TS Web Access which is similar to Citrix’s Web Interface.

By default, access to Remote Programs in the Allow List via TS Web Access is enabled. Of course you could always establish an RDP session to a Terminal Server desktop and launch programs as if you were connected to a published desktop.

By the way, there is a default Remote Program available that essentially publishes an RDP connection called a “Remote Remote Desktop Connection” (a “double hop” from one server to another). I think it would be fun to call it a “Really Remote Desktop Connection”.

Configuration Options when creating Remote Programs

When compared to publishing applications in Citrix Presentation Server, there are very few configuration options possible at the point of creating a Remote Program through the Remote Programs Wizard. However, many options can be configured after the fact through policy. For example, with Presentation Server you have the option of defining color depth and encryption level when publishing the application. When creating a Remote Program you do not have the option to define color depth or encryption level when “publishing” (or allowing) the program, but you can configure these settings later through Local or Group Policy in Computer Configuration | Admin Templates | Windows Components | Terminal Services | Terminal Server etc.

With regards to Session Window Size, in Citrix Presentation Server this can be defined in the Application Publishing Wizard, however, the Remote Program by default will launch in a resizable window. For the Remote Programs to launch seamlessly, you must launch the program using the RDP 6.0 client. If you are using the older RDP client the program will still launch in a resizable window, but it will be displayed within an outer shell (which is also resizable). This more cumbersome and not as pretty than if you were using the newer client.

Both Published Applications in Citrix and Remote Programs in Longhorn have the option of changing the icon associated with the program as well as defining command line arguments to use with the program through their respective publishing wizards. Citrix’s Publish Application Wizard allows you to limit the number of published application instances allowed to run in a server farm and limit the number of instances of each application per user. In Longhorn, the number of connections to a server can be limited through policy, but connections to a specific application cannot be defined. (Again, you can get creative with Security Groups but it’s not as straightforward as with Citrix Published Applications.) Another feature the Publish Application Wizard allows is the ability to assign a CPU priority level as well as Access Control (if you are using Advanced Access Control with the Citrix Access Gateway) whereas no similar options exist for Longhorn Remote Programs. In addition, file type associations can be defined in the Publish Application Wizard whereas if you’d like to define file type associations or “client file extensions” for Remote Programs, you do when creating an MSI package versus at the point of allowing (“publishing”) the Remote Program.

Finally, Local Policy or Group Policy for Remote Programs and Citrix Policy for Published Applications can be used to configure multiple options such as connection level settings, device and printer settings, security, session time limits, etc.

Summary

Citrix’s Published Applications and Longhorn’s Remote Programs have some similarities, and naturally, some differences. Presentation Server’s Published Applications have more options when using the Published Application Wizard and they offer more granularity, particularly when targeting an individual application. Longhorn’s Remote Programs offer a very simplified wizard while having the option to configure additional settings using Local or Group Policy. Published Applications in general allow more flexibility and more exhaustive “out-of-the-box” options. That said, Longhorn’s Remote Programs are a huge enhancement to the Terminal Services of the past and provide a great option for those who don’t need the enhancements and expense of Citrix.

Resources

Microsoft's Complete Longhorn Terminal Server Feature List
More Longhorn Terminal Server details uncovered in yesterday's product group chat
Introducing the Windows Server Code Name "Longhorn" Operating System
Terminal Services in Windows Server “Longhorn” Beta 2
Microsoft TechNet Terminal Services support forum
Session Directory and Load Balancing Using Terminal Server
Step-by-Step Guide for Windows Server Longhorn Beta 2 Terminal Services Remote Programs, Daniel H. Brown, Tessa Wooley, Linda Caputo

Citrix Printing: Brush up on the basic best practices

Kevin Buchaniec — Wed, 23 Aug 2006 02:00:00 GMT

Being around Citrix for a while, one of the things that you’ll notice and continues to hold true is that printing is still one of the biggest challenges. With each release, Citrix touts that printing is better. However, reality sets in and you soon find out that you’re in the same boat again and you’re forced back to old school printing configurations.

Don’t be mistaken, the EMF printing model of Citrix Presentation Server 4 is a good move. It has given back your server’s horsepower from the days of when a single logon or print job would spike your processors, or even worse, clog the user’s virtual channel. Most of the problems occur when administrators expect that printing will work out-of-the-box and are unfamiliar with how to properly set it up. Further, many of the helpful printing sites seemed to have ventured off topic, adding additional content and making it difficult to find a clear, concise, guided approach in how to set up printing.

Once again, if you’ve been around Citrix for a while, you should know these best practices and how to set up printing, but a re-fresher never hurts. This guide is mainly written for the new Citrix administrator either setting up an environment or even trying to fix an existing one. Although you can debate some these recommendations, they have been successfully deployed in environments with 50,000 named users.
Before you start the journey of setting up Citrix printing, you need to know what makes up the system and how they work together.

Printing Components

Basically, there are six main areas or components that you need to be concerned about. These are:

Server Side Printers, which includes print drivers that are installed on the Citrix server.
Client Side Printers are printers that are both locally attached and network attached that are defined on each client workstation.
Management Console Settings are configurations that are made in the Presentation Server Java Console. These include Citrix policies and driver mappings.
Wtsprnt.inf is a text file that resides on each Citrix Presentation Server that contains the re-mapped printers for the farm.
Wtsuprn.inf is a legacy text file equivalent of the wtsprnt.inf file. This may still exist if the servers have been upgraded from previous Citrix releases. Unlike the wtsprnt.inf, this file can vary from server to server.
NTPrint.inf is a configuration file that has information about all drivers that shipped with the server operating system that can be loaded.

Printer Auto-Creation

Now that you’re a little more familiar with the components, it’s time to look at how they interact with each other. When a client first connects, Citrix initiates a sequence to auto create the necessary server side printers. For it to be successful, these printers need to correspond with the client side ones and the printer driver name on the client must match (exactly) a printer that is defined in either the registry or one of the .inf files. It parses these files, listed below (in order):

wtsuprn.inf (if it exists)
wtsprnt.inf
The registry
ntprint.inf

If a match is found, it bails out of the sequence. There are several other sub-steps, but they’re really not that important, nor is it necessary that you know them. It should also be noted that:

The process is done for each printer defined on the client.
For the most part, locally attached client printers auto-create faster than the network ones.
The first printer that connects, even though it may not be defined as the user’s default, becomes the temporary default in the session until the actual default is mapped.

Best Practices

Seeing the components and the process Citrix uses to connect printers, it’s still a challenge to have consistent and reliable printing. Yes, EMF performance enhancements have been great, but it’s consistency, or lack there of, that generates the most support calls (which, without a doubt, is the bane of the Citrix admin’s existence). It’s usually easier in a controlled environment, however, in an environment where a strict printing standard can’t be adopted, it’s a nightmare. Properly setting up your environment is a must and regardless of how it’s done, it needs to include the following:

Avoid loading third-party print drivers--especially drivers that are not specifically documented to be compatible with terminal services. This has, was, and still is the number one cardinal rule. Back in the NT 4.0 TSE days, third-party drivers accounted for most of the BSoDs. These days, the “good” news is that it may only cause your spooler to tank out.
Remove all version-2 drivers. These types of drivers run in kernel mode and cause serious issues with the servers. Stick with Version-3 drivers which operate in "user mode."
Use native Windows 2000 or Windows 2003 OS drivers for all printers, even if some functionality is lost. This includes using them over the Universal Print Driver.
If additional functionality is really needed, map the client driver to another Windows 2000 or Windows 2003 OS driver that offers similar functionality. This isn’t always possible, but most users are satisfied with just being able to print and don’t mind killing an extra tree or two because duplex printing isn’t available.
Disable the loading of drivers on demand and/or importation of drivers from the client. This is important in keeping your environment clean and free of third-party drivers or other unwanted drivers.
Keep the combination of drivers and/or re-mapped drivers to minimum. The more places to parse during printer auto-creation, the longer the logon may take.
Ensure users have write access to %systemroot%\system32\spool on the server. Problems usually occur with overzealous, Sarbanes-Oxley compliant lock-down admins applying security settings.
If possible, print directly to the printer or print server and not through the virtual channel. Sorry, Citrix is meant to be thin--why clog the pipe with a print job if you don’t have to?
Old print jobs in the spooler should be cleaned up periodically. This should be done through a common maintenance script.
Do not load Hotfixes because they are available. Ensure it fixes something that is actually broke. Basically, if it ain’t broke, don’t fix it.

Step by Step

Using all of this information, it’s time to put it to together and build a solution around it. Working under the assumption that you’re setting up a new environment and a have clean slate. Start by:

Setting up your policy
Installing your drivers
Re-mapping your printers

Create Your Farm Print Policy

Your farm’s print policies will vary in your particular environment and will always be dictated through the needs of your user base. The following settings seem to be the sweet spot for most farms that have users coming in from the Internet on untrusted clients. It uses native drivers over the UPD, and is applied to all servers as a default.

Printing	Setting	Configuration
Client Printers/Auto-creation	Enabled	Auto-create all client printers
Client Printers/Legacy client printers	Enabled	Create old-style client printers
Client Printers/Printer properties retention	Enabled	Held in profile only if not saved on client
Client Printers/Print job routing	Enabled	Always connect indirectly as a client printer
Client Printers/Turn off client printer mapping	Not Configured
Drivers/Native printer driver auto-install	Enabled	Do not automatically install drivers
Drivers/Universal driver	Enabled	Use universal driver only if requested driver is unavailable

Drivers

Remarkably, you can run your entire farm with less than 25 drivers and all third-party drivers can and should be removed. These drivers ship with the operating system and serve as a good base for any environment.

Canon Bubble-Jet BJC-210
Canon Bubble-Jet BJC-4000
Generic / Text Only
Epson Stylus COLOR ESC/P 2
HP Color LaserJet
HP Color LaserJet 4500
HP DeskJet
HP DeskJet 550C
HP DeskJet 850C
HP DeskJet 855C
HP LaserJet
HP LaserJet Series II
HP LaserJet 1100 (MS)
HP LaserJet 2100
HP LaserJet 4
HP LaserJet 5
HP LaserJet 6P
HP LaserJet 4000 Series PCL
HP LaserJet 8100 Series PCL
HP OfficeJet
Lexmark Optra
Lexmark 1020 Color Jetprinter

The easiest way to load these is to simply walk through the “Add a printer” wizard one-by-one. You can get creative and write a script however you only need to do this once because they can be replicated. The drivers can also be integrated into your Citrix base build.
So that additional drivers don’t accidentally get installed, it’s also a best practice that you rename %systemroot%\inf\ntprint.inf to ntprint.old.

Replicating Drivers

Using Citrix’s print driver replication feature, the drivers can be loaded on one of your servers and then replicated to all of the servers in the farm. In larger Citrix Farms, replicating drivers can cause performance issues, so you may want to create a print package that can be redistributed.

Creating a package is a simple process:

Start with a clean, freshly installed server
Copy the directories and files from %systemroot%\system32\spool\drivers
Export HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3
Write a wrapper script similar to:

REM Backup Files and Registry
@IF NOT EXIST MD c:\temp\printback
@XCOPY /E /H /Y %systemroot%\system32\spool\drivers c:\temp\printback\
@REG EXPORT "HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3" c:\temp\printback\printers.reg

REM Removing Print Drivers
@REG DELETE "HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3" /F
@RD /S /Q %systemroot%\system32\spool\drivers\color
@RD /S /Q %systemroot%\system32\spool\drivers\w32x86

REM Installing New Print Drivers
@XCOPY /E /H /Y color %systemroot%\system32\spool\drivers\color
@XCOPY /E /H /Y w32x86 %systemroot%\system32\spool\drivers\w32x86
@REG IMPORT PrintDrivers.reg

REM Restore
REM @XCOPY /E /H /Y c:\temp\printback\color %systemroot%\system32\spool\drivers\color
REM @XCOPY /E /H /Y c:\temp\printback\w32x86 %systemroot%\system32\spool\drivers\w32x86
REM @REG IMPORT c:\temp\printback\printers.reg

@NET START SPOOLER

Bundle it all together as a self executing zip file. InstallShield Packager for the Web (if you can still find it) is a great utility for this type of work.

Re-Mapped Drivers

Now that you have a good driver base, it’s time to re-map to them. You can do this a couple of different ways. Downloading and importing somebody else’s remapping file isn’t necessarily the best since your environment is more than likely unique. You’re bound to get a number of unnecessary re-mappings, thus violating best practice #6. Under that premise, the easiest approach is to use Doug Brown’s Advanced Print Manger (APM) from http://www.dabcc.com/apm . If you get the answer “it’s not in the budget,” then the re-mappings will have to be done manually using two different processes:

Manual Process #1

Filter the event view for printer failures – 1106 and 1007 messages
Parse through it and just grab the printer name.
Look up the printer at www.printingsupport.com and find a comparable driver
Create a text/inf file and manipulate so it resembles a wtsprnt.inf.
Import using qprinter /IMPRMAPPING C:\MyMappings.INF

Manual Process #2

Dump the event view for printer failures – 1106 and 1007 messages
Look up the printer at www.printingsupport.com and find a comparable driver
Re-map them one-by-one in the CMC.

Six out of Seven Citrix Admins agree: stick with APM. It’s easier to use and you’ll be done in half the time. It polls the event logs for failed mappings and displays them in a consolidated, readable format along with a suggested re-mapping.

If a recommendation isn’t available, the following table can be used as a simple guide or starting point for re-mappings. Of course you’ll need to test them to ensure they work. Further, since support is being added for a printer that is currently unavailable to the user, adding these mappings during production hours is a minimal risk.

Printer Type	Remaps to
Default	HP LaserJet HP LaserJet Series II HP LaserJet 4 HP LaserJet 5
Amyuni	HP LaserJet 5
Brother	HP LaserJet 4
Canon Bubble-Jets	Canon Bubble-Jet BJC-210 Canon Bubble-Jet BJC-4000
Epson	HP LaserJet 4 HP LaserJet 5
Epson Stylus	Epson Stylus COLOR ESC/P 2
HP DeskJet Series	HP DeskJet HP DeskJet 550C HP DeskJet 850C HP DeskJet 855C
HP LaserJet Series	HP LaserJet HP LaserJet Series II HP LaserJet 4 HP LaserJet 5
HP LaserJet 1000 series	HP LaserJet 1100 (MS)
HP LaserJet 2000 series	HP LaserJet 2100
HP LaserJet PCL Series	HP LaserJet 4000 Series PCL
HP OfficeJet Series	HP OfficeJet
Lanier	HP LaserJet 4000 Series PCL
Konica	HP LaserJet 4
Lexmark Default	HP LaserJet 4
Lexmark Jetprinter series	Lexmark 1020 Color Jetprinter
Lexmark T Series	HP LaserJet 4 HP LaserJet 5
Lexmark Z Series	UPD
Lexmark Optra Series	Lexmark Optra
Ricoh	HP LaserJet 4
Color Printers	HP Color LaserJet
PDF Writers	HP LaserJet 5 HP Color LaserJet 4500
Fax Printers	Generic / Text Only

Conclusion

As mentioned in the beginning of this article, the above printing configuration has been field tested several times over, from MetaFrame 1.8 all the way to Presentation Server 4.0. Once it’s set up, the administrative overhead is minimal, with only the occasional new mapping being added. Wrapping a process around it might prove to beneficial as well. But this still proves to be the most reliable approach for printing in Citrix. Maybe they’ll prove it wrong in 4.5.

Microsoft reduces Softricity Licensing pricing by almost 85%

Michael Burke — Tue, 08 Aug 2006 06:30:00 GMT

Microsoft’s acquisition of Softricity is now complete and there are some major changes to the licensing for SoftGrid. In a LiveMeeting Monday, Microsoft identified some key changes--some that are already in place and others that are coming.

New Pricing

The biggest change comes with the new pricing that Microsoft announced this past Friday. All SoftGrid products have been consolidated into the following two licenses. These prices reflect an almost 85% reduction in client licensing costs alone.

Product Description	MSRP (US$)
SoftGrid Desktop License	$36
SoftGrid CAL for Terminal Services	$20

There are only two licenses available--the SoftGrid Desktop License and the SoftGrid CAL for Terminal Services. The Universal Desktop license is no longer available.
The SoftGrid platform, Sequencer, ZeroTouch and Microsoft SMS Extensions are all included in both licenses.
Under the new EULA, SoftGrid CALs for Terminal Services are no longer licensed on a concurrent user basis. They are now licensed the same way as Microsoft Terminal Server CALs--either per-user or per-device.
Minimum order quantities have been reduced to 5 licenses.

Softricity Software Assurance (SA) Agreements

Many changes have been made to the Softricity Software Assurance program. For the most part, there is no more SA being sold Softricity Licensing, with the exception of existing customers re-ordering product. Details are below:

New Customers

Software Assurance is suspended. SA will no longer be offered on new sales of SoftGrid licensing.
Hotfixes, patches and minor updates will still be provided for now, but no major revisions to product.
Customers will be able to purchase support incident packs to open support cases will Softricity. The Support Pack SKUs are not yet available, but should be by the time the product ships at the end of September.

Existing Customers

Existing agreements due to expire will not be renewed or extended. Microsoft is in the process of integrating the Softricity SKUs in with their Volume Licensing program and Microsoft’s “SA” will be available in the first half of 2007.
Existing customers will get upgrades to product provided their support agreement is still valid at the time the update is released (i.e. Vista-compatible version).

Existing Customers Re-Ordering Licenses

Only existing customers can purchase SA for re-orders on an existing agreement until either July 1, 2007 or the date their agreement expires, whichever comes first.

Release Schedules/Timelines

The Softricity name is staying for now. Microsoft feels that the Softricity brand has a lot of recognition in industry and is planning to capitalize on it. On the slides in the presentation, the logo now reads “A wholly owned subsidiary of Microsoft Corp”.

August 1, 2006 – new pricing/EULA is in effect. Existing customers’ re-orders can be fulfilled, and new orders can be placed, however new code will not ship until the end of September.
August 4, 2006 – Interim code released to support POCs (version 4.0.0.585; not supported for Production environments).
September 29, 2006 – Target date for revised code and fulfillment (production release). This release will not include ZeroTouch, most likely as a result of crucial open-source code being removed from the product.
Fall 2006 – ZeroTouch functionality will be released. The current version of ZeroTouch (1.11.99) will not be supported in the 9/29/2006 release. Customers wishing to deploy ZeroTouch will need to wait until it is released in the Fall.

Also in the Fall of 2006, Microsoft is expected to announce projected Volume Licensing offerings and upgrade paths.

First Half of 2007 – Microsoft Software Assurance will be available through the Volume Licensing programs. Microsoft is also expected to make the SoftGrid Platform available to all Microsoft channels for resale.
July 1, 2007 – All existing Softricity SA agreements will expire. SA will only be available via the Microsoft Volume Licensing programs.

What this means to the Industry

First, since SA is now defunct, there is no definitive answer from Softricity on how new customers will get updates to the software as there is no maintenance agreements available. The same also applies for customers whose maintenance expires before the expected release of Volume Licensing SA information.

Next, the product roadmap is unclear. Prior to the acquisition, Softricity's #1 goal was to have context communication working between virtual environments. Softricity does such a great job of isolating applications that it's almost a detriment. Now, Microsoft's focus is clearly on a 64-bit version and a Vista-compatible client. Beyond that, there is little information on where the product is going.

Microsoft obviously has serious competition with Altiris, and this acquisition is clearly meant to close the gap. Altiris' SVS is a direct competitor of Softricity, but now that the pricing is so low, it may give Microsoft an advantage.

In terms of Citrix Streaming Server (aka Tarpon), Softricity is now the first product that directly competes with Citrix. Presentation Server was always an "add on" to Terminal Server. However, customers will now have a decision to make between software virtualization platforms. It will be either Citrix OR Microsoft, but not both. I am curious to see how this will affect (if at all) the relationship between Microsoft and Citrix.

More Longhorn Terminal Server details uncovered in yesterday's product group chat

Katie Koepke — Wed, 02 Aug 2006 09:30:00 GMT

As many of you know, the Microsoft Terminal Server Product Team hosted a live chat yesterday. There were a lot of great questions and it was a great opportunity to interact directly with the Terminal Server group. A PDF transcript of the chat is available above, and highlights are covered in this article.

The experts present in the chat from the Terminal Services Product Team included:

Ted Kummert -- Vice President of the Security, Access and Solutions Division
Chandra Shekaran -- Product Unit Manager of Terminal Services
Maxim Oustiougov -- Program Manager with Microsoft's Terminal Services team
Alex Balcanquall -- Product Manager for Terminal Services
Tad Brockway -- Group Program Manager, for the Terminal Services Product Development
Nelly Porter -- Lead Program Manager on Terminal Services team
Joy Chik -- Development Manager for Terminal Server
Guaray -- Program Manager in the Windows Terminal Services team
Samim Erdogan -- Program Manager with the Terminal Services Team

So what’s the latest with Longhorn Server? Let’s start by taking a brief look at what we learned from the last live chat held on this topic in September, 2005.

Application Publishing with client-side file type associations
Seamless Windows
A Terminal Server Gateway (TSG)
Intelligent Avalon/WinFX Remoting
A Unified Management Console
Redirection of Plug-n-Play devices with UDMF drivers
Major Reworking of the Logon Process
Per-User Licenses will be Tracked
Web interface
RDP 6
A Refined Windows System Resource Manager (WSRM)
WMI Interface for Everything
RDP Virtual Channel Tuning.

The above features are discussed in more detail here.

After reading this list of features, a common question is (and has been), “is Microsoft trying to compete with Citrix, its own ISV partner?” Tad Brockway reiterated Microsoft’s position on this question in yesterday’s chat saying,

Citrix will continue to add great value on top of our Longhorn Server feature set. It's our goal, for Longhorn, for customers to have the basic features in-the-Windows-box for scenarios of small to medium scale and complexity. So, Longhorn Server will include features, like: Remote Programs and a Terminal Server Gateway for VPN-less access to TS resources. In terms of deployment scenarios, our ISV partners will add value on top of these features as well as our existing features.

This is a good perspective for us, the system engineers, to keep in mind as our managers and clients ask us why Microsoft is adding some of the same features as Citrix.

What we learned from the August 2006 chat…

Beyond the features discussed in the September 2005 chat, we learned of some additional features slated to be released with Windows Longhorn.

Softricity Acquisition

Microsoft’s acquisition of Softricity has been a hot topic as of late and in yesterday’s chat the community was able to ask if there were any plans to incorporate Softricity specifically with Terminal Server. (Until now the rumor had been that Softricity would be incorporated with the SMS group.) While no specifics were released on how Softricity will be built-in to Microsoft products, Chandra Shekaran indicated that there will be involvements with Terminal Services. When asked specifically how the Softricity acquisition will affect Terminal Services in Longhorn, Chandra provided us with this insight:

In the medium term, one should expect TS Application Compatibility and efficiency of TS deployments to significantly improve. That said, we just closed on the acquisition and haven't finalized product evolution or announced licensing plans going forward. We will announce more details in the next couple of weeks.

It will be interesting to hear how Softricity may interact with Terminal Server in the future.

Monitor Spanning

Whether or not multi-monitor support would be supported in Longhorn Server was another popular topic. Longhorn Server and the RDP 6.0 client will not provide multi-monitor support, but will provide “monitor spanning.” So what’s the difference? With monitor spanning, the system only "sees" one display. Therefore if you had two monitors, your start menu taskbar would stretch across both screens. You would have some ability to move and resize windows to one monitor or the nother, but the system only sees it as one display. A popup message would appear "on the seam" in the middle of your display, half on one monitor and half on the other.

With true multi-monitor support, using the same example of two monitors, the system would see the extra display and therefore your taskbar, and pop up messages etc., would appear only on your primary display. You would be able to maximize windows within their specific display without having them stretch across both.

The new RDP client will allow you to invoke monitor spanning from the command prompt via mstsc.exe /span.

Terminal Server Web Access (TS Web Access or TSWA)

Terminal Server Web Access provides a web interface to remote programs. (TS Web Access is to Remote Programs as Web Interface is to Published Applications. S.A.T. flashback anyone?) Tad made a good analogy comparing TSWA to OWA (Outlook Web Access).

TS Web Access can be configured in two modes; Simple Mode and Group Policy Mode. Simple mode is configured per Terminal Server and Group Policy Mode, as you may expect, is configured in Active Directory Group Policy. Samim went on to explain:

In TSWebAccess: There are two modes: Simple Mode and GP (Group Policy) mode. In Simple mode, it is possible to point the TSWebAccess page to a particular TS installation or deployment. You can use multiple TS Servers in this mode as long as the servers are all in a farm accessible with the same DNS name. In the GP mode, the app definitions come from Group Policy.

Profiles

There is an indication, based on today’s chat, that there is going to be a big overhaul to profiles. (Woo hoo!) Alex Balcanquall states,

I am not sure what we have announced but yes profiles and folder redirection have been enhanced. For example profile sync has been vastly improved and is more efficient, almost all folders can be redirected and sync is super efficient for off line files; the new profile service ensure profile corruption is mitigated in most scenarios. Basically vastly improved.

Will roaming profiles as we know them (slow and prone to corruption like an Enron executive) soon be a thing of the past?

Enhancements to RDP and WPF Remoting

There were a handful of audio-video improvements announced to release with the next version of the RDP client. Among them, ClearType support and 32-bit color depth in RDP. In addition, Microsoft announced that they are working on enabling audio redirection for MIDI formats.

Another popular topic in the chat was how Windows Presentation Foundations (WPF) Remoting, also known as Avalon/WinFX Remoting, will work in Longhron. Just so we have all the terminology out there, WinFX technology is now referred to as the ".NET Framework 3.0." Aero-Glass, which was referred to in the chat as well, is one theme available in WPF. What is WPF Remoting? In short, WPF Remoting changes how and where an application is rendered and presented to the user via Terminal Services. You can read more about it about this here.

Advantages to WPF Remoting include:

Less network bandwidth utilization
A more seamless client experience. For example, remote applications will feel more integrated with the client.
Less server load since less rendering is not taking place there.

On the other hand, the main disadvantages to WPF Remoting is that you must have a client that's running WPF, either Vista or a Windows XP with the WinFX / .NET Framework 3.0 update.

The big question is "will WPF Remoting be released with Longhorn?" Previously we thought this answer was "yes." However, when the question was asked, “What support will Longhorn Terminal Services provide for Avalon-based applications?” The response given was,

Yes, we are working to support Aero-Glass via RDP, when connecting from a Vista client. …. We have more work to do and we haven't yet targeted a specific release vehicle. (Tad Brockway)

Based on this answer it doesn’t sound like the WPF Remoting capability will be released with Longhorn as was originally thought. Perhaps it will arrive later in the form of a Service Pack?

RDP Client Versions and Updates

Of course many of these new features will require a new RDP client. Tad Brockway elaborated on how the new client for Windows XP, SP2 will be made available—via Windows Update!

When we ship Vista, we will make an updated version of our TS Client available via download from Windows Update ... for Windows XP SP2 clients. Similarly, when we ship Longhorn Server we will update the client that is available via Windows Update ... for Windows XP SP2 and Vista clients. This approach will result in supported Windows clients to get access to the new features in Longhorn Server. Current plan is for the Vista SP1 OS to include the version of the TS Client that we ship with Longhorn Server, automatically, so no download will be required for Vista SP1 clients.

TS Gateway Single Sign On update.

The upcoming arrival of Microsoft’s TS Gateway (TSG) product, similar to Citrix’s CSG product, is no surprise. The chat, however, revealed some additional information about the product which is worth noting. For example, the question was asked if a TSG server can exist outside of a domain. Alex explains that,

The TSG can be standalone if needed - but this means you would need local accounts on the TSG. The other alternative is to put the TSG in the internal network and use an SSL terminator in the DMZ instead.

The drawback of having a TSG standalone server is that local credentials would be necessary and Single Sign On (SSO) would not be possible without a 3rd party tool. So what's the deal with SSO? The question was posed whether SSO would be possible between TSWA, TSG, and the TS Server? Tad fielded this question.

In Longhorn Server, we implemented a Network Authentication feature so that your local credentials that you provided at the login screen are automatically forwarded (securely of course) to the Terminal Server. This feature effectively enables SSO from the TS client to the TS server. We do not have a true integrated SSO solution that crosses TS Web Access, TS Gateway, and the Terminal Server. However, we do a pretty good job of supporting credential caching and if it is allowed via your admin would enable an 'SSO experience' for many scenarios. It isn't something we would refer to as SSO, of course.

Another cool piece of information shared a couple of times throughout the chat was that the TS Gateway would work connecting to Windows 2000 and 2003 Server in addition to Vista and Windows XP clients. The ability to connect to desktops and not just servers could be profound with respects to VDI!

In summary, there is a lot of added functionality in Longhorn Server to look forward to. A big thank you is extended to this panel of experts who took time to chat with us!

Additional Resources

A great document on the features included with Longhorn Server is available from Microsoft here.

Some great Step-by-Step guides to installing and configuring Longhorn, Remote Programs, and the TS Gateway are available for download here.

Chat with Microsoft Terminal Server Product Group.pdf