When Its Not Quite A Licensing Issue...

Sometimes, a Windows XP boxes seem to have trouble connecting to a Terminal Services (aka Remote Desktop Services) server.  The user sees an error about the server being out of licenses and the server reports errors that the workstation couldn't get a license. 

At first glance, you think you need to buy more licenses, but it might turn out that you have plenty availble.  The reality is that it's probably the client machine that needs tweaking, not your server.

Pop over to your client machine, fire up REGEDIT and delete HKLM\Sofware\Microsoft\MSLicensing\Store\LICENSExxx.  Take out all the license keys under the store.

The client machine will get new keys when it connects successfully the next time around.

App-V vs. Terminal Services – Which one, when?

Both App-V and Terminal Services/Remote Desktop Services can reduce the amount of time an IT Professional spends installing, managing and troubleshooting applications on desktops. Both technologies allow you to install, upgrade and manage an application in one place (on a server) and allow multiple users access to those applications. And then the similarities start to end.

Terminal Services/RDS is based on session hosting. The users must establish a session with the host server to access the application. Depending on what version of Windows Server you are using, the applications can appear on the desktop seamlessly using either RemoteApp or other 3rd party technologies. While this is great for workers who are located locally in the office or are regularly connected via the Internet from another location, the applications are not accessible when the client machine is working offline.

App-V streams the packaged applications to the client machine, which are then cached locally for use while working on or offline. The applications can be managed and updated on the server side and the client machines receive updates when they reconnect. This allows for better control of the overall software lifecycle and ensures that every client is running the approved version of any given application.

When it comes to support for legacy applications, especially those that will not run on Windows 7, App-V isn’t necessarily going to be the solution. Any application streamed from App-V must be sequenced and packaged for the destination operating system, though I've heard of some success with XP-sequenced apps working on Windows 7, so your mileage may vary. App-V requires the applications to interact with the client operating system in order to take advantage the local system resources. This is also important for applications that must interact with each other and with the local drivers on the machine, to deliver an experience similar to having the application installed in the traditional fashion.

If you have an application that won’t run on Windows 7, you’ll have to turn to a solution other than App-V. If you already have a legacy Server 2003 Terminal Services infrastructure in place that can deliver the application, it might be easier and more cost effective to look at using that instead of deploying MED-V. (See my post on TS vs. MED-V in April.)

Legacy applications aside, what if all your applications are Windows 7 ready? Can RDS make more sense than App-V?

First, you have to consider your users. Do the work online or offline? Do you have the RDS infrastructure to support having EVERYONE access applications during the work day? Having everyone access hosted applications is resource intensive on the server. If you currently have an implementation that used for only a few remote workers or for little used applications you’ll have to look closely at how much those servers will be able to support. App-V might be a better fit if you want to take advantage the resources on the local machines instead.

You can also combine App-V with Remote Desktop Services to make better use of server farm resources. Ultimately, there are a lot of different ways to deliver software to your end users and it doesn’t have to involving managing applications on each desktop.

Techbunny at Windows Intelligence

If you were down in Burlingame, CA at the Windows Intelligence conference today, hopefully you enjoyed the event put on by Quickstart Intelligence. I did two presentations, Deploying Windows 7 and a server session on Remote Desktop Services and Terminal Services. You can download them by clicking on the links or in the find them in my "downloads" section in the sidebar. (Slides are in PDF format.)
There were also several sessions by Ed Horley and Steve Evans, as well as Chris Henley, Chris Avis and Harold Wong from the Microsoft's Technet Evangelist Team. You can find out more about where to find Chris, Chris and Harold next at www.technetevents.com.

Can MED-V take on Terminal Services?

Had a great conversation with an MMS 2010 attendee while I was helping man the Windows Manageability booth at the Expo Pavilion this week. We were discussing his existing applications, moving to Windows 7 and he asked “When is it appropriate to use MED-V, since I already have a legacy application on Terminal Services?”

Microsoft Enterprise Desktop Virtualization is a great way to manage the deployment of applications that will not run on Windows 7, but run on Windows XP. By providing a managed, virtual, integrated copy of Windows XP running inside Windows 7, users can still access a legacy application seamlessly from their desktop.

However, MED-V is not the ultimate solution to getting legacy applications to run on Windows 7 indefinitely. Its a way to get Windows 7 onto desktops without being held back by a specific application that is not yet ready to be upgraded, replaced or phased out of use.

But what if you already have the application available through Terminal Services? You may be running Citrix on Server 2003 Terminal Services. Or maybe the application will run on Vista and can be deployed using Server 2008 TS RemoteApp. Both those options are easier to manage than deploying and managing a host of extra virtual Windows XP machines on your network, especially if you already have an appropriate Terminal Services environment available.

MED-V is a tool to consider if you are Software Assurance customer, because access to the MDOP tools cost only about $7-8 per desktop. This can be cheaper than the cost of Terminal Service or Citrix CALs, unless of course, you already own those CALs.

MED-V and Terminal Services aren’t competing solutions for the same problem. But they can help you accomplish the same goal – getting your users working on Windows 7.

When Easy Print Doesn’t Print

Terminal Services 2008 introduced Easy Print, a feature that doesn’t require print drivers for local printers to be installed on the remote terminal server. Instead Server 2008 redirects the default printer from the local machine and utilizes the locally installed driver.

While this works well for a lot of printers, printers that need legacy or specialty drivers (like those handy multi-function printers), may result in print jobs are garbled or use incorrect fonts.

The first troubleshooting step should be to update the the print drivers on the client computer, but if this isn’t possible, the default behavior of Easy Print can be overridden with some registry keys and some GPO settings. Also, in some cases, the correct print driver still produces bad print results so you’ll need to use a different driver.

The following steps will override Easy Print, utilizing a driver installed on the server instead AND force a substitution with a different driver.

First, you’ll want to create a special INF file that lists the printers your want to specify alternate drivers for. You’ll reference this INF file in some new registry entries on the server. Follow the format used in the following example:

;NTPRINTSUBS.INF

;Printer mapping file for client-side to server-side drivers

[Printers]

"OEM Printer Driver Name" = "Windows Server 2008 Driver Name"

For example:

"HP DeskJet 720C Series v10.3" = "HP DeskJet 722C"

The left side of the equation is the exact name of the printer driver associated with the client printer that is being redirected to the server. The right side of the equation is the exact name of the server-side driver that is installed on the terminal server. You’ll have to check your printer driver properties to make sure you have the names right.

Next, you’ll need to add a few registry values to your terminal server.

1. Locate the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd registry subkey.
   
2. Add the following values:

   Name: PrinterMappingINFName
   Type: String (REG_SZ)
   Value data: Name of the .inf file to which you want to redirect lookups. (Example - c:\windows\inf\ntprintsubs.inf)

   Name: PrinterMappingINFSection
   Type: String (REG_SZ)
   Value data: Name of the section in the .inf file to which you want to redirect lookups. (Example – Printers)

You must restart the Print Spooler service on the terminal server for the changes to take effect. If you need more details about this process, check out Event 1111 – Terminal Services Printer Redirection on TechNet.

Finally, you’ll need to adjust or create a group policy that will alter the behavior of Easy Print for all of your TS users. There are several additional policies that can be enabled to tweak how client machines handle Easy Print. The one you want to adjust “Use Terminal Services Easy Print Print Driver First” and you’ll want to disable it. This will force clients to look for appropriate drivers on the server first and only use Easy Print if no suitable driver is found. It doesn’t disable Easy Print entirely, just makes it the second choice.

Depending on which OS you are using as your GPO management workstation, you’ll have to look in for the policy in one of two places. The discrepancy is related to the renaming of “Terminal Services” to “Remote Desktop Services” with Windows 2008 R2. The registry settings that the policy adjusts are the same.

• For Vista or Server 2008, go to Computer Configuration –> Policies –> Administrative Templates -> Windows Components –> Terminal Services –> Terminal Server –> Printer Redirection.
• On Windows 7 or Server 2008 R2, go to Computer Configuration –> Policies –> Administrative Templates –> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host ->Printer Redirection.

In our case, we were unable to find the setting at all using Windows Vista and we don’t have a Windows 2008 server running GPMC to compare it too. However, we simply made the adjustment using a Windows 7 workstation instead. For other troubleshooting tips with Easy Print, check out the RDS Team Blog.

Red Arrows on connected Terminal Services Users

Now that I've been actively working to move people from our aging Citrix setup to Server 2008 Terminal Services, I've been spending some more time in Terminal Services Manager. While there, I've noticed that outside of my adminstrator level account, all the connected users have an icon with a red down arrow next to them.

My first thought was that it was a licensing issue, so I checked the terminal services licensing server. We license by device and everything seemed to be in order. My next stop was a search on the internet, where I turned up this lone post on eggheadcafe.com. The reply about it being a "known issue" is not terribly outdated so I'm just going to let the red arrows be for a while and move on to other things.

Pacific IT Professionals Meeting Tomorrow

Don’t forget the PacITPros regular meeting this Tuesday (tomorrow!) at 6:00pm.

I’ll be doing a quick presentation regarding Remote Desktop Services (on Windows 2008 R2) and we’ll also be hearing from Ed Horley on Windows 7 Deployment and an overview of the Application Compatibility Toolkit.

This meeting is a Microsoft STEP event, so be sure to check out the details and RSVP!

Terminal Services 2008: When its not your print job

I got wind of an interesting problem at work recently. I wasn’t involved in troubleshooting it at the time, but I still think it’s worth a post in case it ever comes up again for someone.

We’ve been rolling out the pilot of our Terminal Services 2008 remote access solution and are now doing the necessary tweaks and repairs that come from having people actually work the system. All our users (terminal services or otherwise) get an automatically mapped printer that emails the user a PDF of whatever they printed. Some users had reported they weren’t getting their PDFs delivered via email and others were getting PDFs that didn’t belong to them.

Turns out there is a known issue with Vista and Server 2008 where “print jobs may have incorrect owners” when using a shared printer. As stated in the KB article, every print job that is sent from this print client has the same owner in all print queues. The owner is the first user who sends a print job from this client after the printer server is restarted. The problem occurs because the print job is sent in the wrong remote procedure call (RPC) context.

While this usually isn’t a big problem (outside of others potentially being able to manage another person's print job), but when it came to our PDF printing process the owner of the print job is used to determine the email address of the recipient. The knowledge base article includes a link to request the hotfix and applying it did solve the issue.

Terminal Services RemoteApp – Bumps in the Road

This month I’ve been trying to nudge the project of moving to Windows Server 2008 Terminal Services RemoteApp forward at the office. The goal is to get away from using a version of Citrix Presentation Server to access applications over the Internet. The needs of our office have changed and the new features with Terminal Services in Server 2008 make this something we want to adopt instead.

However, nothing is without an occasional bump in the road. Here a couple of ours:

Bump #1 - No way to filter which applications users see on the RemoteApp webpage.

I know this feature was added in Server 2008 R2. Unfortunately, we have to stick with the Server 2008 “classic” due to an important 32-bit application that does not install or run properly under WoW. We debated the importance of filtering the application list and decided it wasn’t a deal breaker. Or we can look at some third-party workarounds.

Bump #2 – Users with passwords set to “enforce change at next logon” can’t get past the TS Gateway.

We have to remember to handle first time password changes for users who only be using RemoteApp by NOT checking the enforcement box and instructing them on how to change there password after they launch an application. (CNTL + ALT + END does the trick from any launched application.)

Bump #3 – No support for Macs with the Mac version of the RDC client.

Ouch. We only have a few employees that use a Mac at home and we’ll have to continue offering GoToMyPC to meet their needs. Not what I’d like to do, but hopefully support for the Mac will come along soon.

Bump #4 – Limitations with multi-monitor support.

Microsoft KB925876 gives some of the details of what type of multi-monitor support is available with Server 2008 Terminal Services and should automatically support spanning if your monitors meeting the configuration requirements. Those rules are: the total resolution on all monitors must be under 4096 x 2048 pixels; the monitors must have the same resolution; the monitors must be aligned side-by-side; and the far left screen has to be the primary one.

This is pretty limiting, especially if you have a laptop connected to an external monitor and want to take advantage of both screens. Or have monitors set up in configuration where one is turned vertically. Or any other number of possible configurations. Windows 2008 R2 improves on this as well, but as noted in #1, we just can't quite use that yet.

So yes, we've got a few bumps, but nothing that would keep us moving forward with the project at this point. Our remote access isn't supposed to be used by someone as a long-term way to work, nor is used with a frequency that demands extra capital expenditures to overcome a few relatively minor issues.

PacITPros February Meeting

Yesterday evening, I gave a short presentation at the monthly Pacific IT Professionals meeting on Windows Server 2008 Terminal Services. Highlights included some of the changes, feature improvements and cavats between Server 2003, Server 2008 and Server 2008 R2. If you attended and would like a copy of my slide deck, click here. Also look for a post tomorrow that covers some of the highlights of the presentation.

There were two other great presentations at the meeting. Ed Horley presented on Network Filtering and Joanie Rhine from Microsoft presented on the most recent Security Intelligence Report. Their presentations will be available on the PacITPros website.

TS RemoteApp, Group Policies, Internet Explorer Zones

It wouldn't be work if we didn't have more than one different, yet similar, things going on in the office at any given time. The disaster recovery user testing is drawing to a close and I'll be the first to admit that opening it up to users has certainly been a learning experience. (More on that later.)

Meanwhile, in an attempt to phase out our Citrix Remote Access farm, we've started to "soft-launch" our production version of Windows 2008 Terminal Services using Terminal Services Web Access and RemoteApp. Two applications we are publishing as remote applications are our financial system and our timecard system. We succeeding in getting both these applications mostly running in our disaster recovery lab last month, but our production version of Terminal Services is a different animal.

In the disaster lab, I didn't configure any special group policies that affected Internet Explorer or any other functions. The setup was just by the basic configuration wizards for Terminal Services, TS Gateway and RemoteApp. Our production version of Terminal Services was set up "by the book" (particularly this book) with lots of security customizations added on with group policies. I'm all for tightening things down until people squeal and then loosening things up as needed and my co-worker had done just that with this installation.

Today, I tested out the timecard application that requires a Java plug-in. The plug-in automatically initializes on our regular desktop machines without issue. On the Terminal Server, which is running the Enhanced Security Configuration, the name of server hosting time timecard web page must be part of the "Intranet" security zone in IE.

Easy fix... except I don't have access to the "Tools - Internet Options" pages in Internet Explorer with my regular user account. That's a group policy setting. Or rather, 3 group policy settings. Because the options available in group policy have grown as each new OS has been introduced, there are several places you can enable, disable and tweak various aspects of what IE menus are available to users. It took me several visits to our Terminal Services policies to restore access to the "security" tab of Internet Options.

Sure enough, once I added the proper web server to the Intranet list, the plug-in initialized. But we don't want to have to explain this to each and every user when they access remote applications for the first time. So next up was getting those setting to automatically configured for each new user.

Our first stop was Group Policy Preferences, which allows for configuration of much of the Internet Options tabs, but not any of the lists for Intranet, Trusted or Restricted sites - how frustrating. But those are simply registry keys, which can be added "a la carte" with Group Policy Preferences as well. The end seems near.

A quick search yields this MSDN article, Adding Sites to the Enhanced Security Configuration Zones. We ended up adding registry keys for both the regular non-ESC domains and the ESC domains because our testing showed that my user account put zone additions in the regular domain area and my co-worker's went in the EscDomain registry area. (The dword hex of 1 means "Intranet zone", use 2 for "Trusted" sites.)

• [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\timecard]
  "http"=dword:00000001
  
  
• [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\timecard]
  "http"=dword:00000001

We didn't experiment further with the "Domain" vs "EscDomain" mystery, instead just added registry keys to cover all our bases for the time being. Now the only thing left is to decide if we want to take away those IE Options pages that I added back in for testing. Jury is still out on that one.

Enabling Terminal Services ActiveX on IE7

As great as Windows 7 is turning out to be, many companies with Server 2008 Terminal Services Web Access (or plans to move to Remote Desktop Services in the near future) will likely have users connecting from home with Windows XP and Internet Explorer 7 for foreseeable future. However the Terminal Services ActiveX control required by TSWA is disabled by default in XPSP3 as a security measure. This control in needs to be explicitly enabled in IE7 in order to use the web access features of Server 2008.

Usually you can enable or disable an ActiveX control in IE using the "Manage Add-Ons" tool, but it's likely that you willl be unable to see the TS specific control in IE7 on XP SP3 in that tool. The workaround is to delete the two following keys from the registry:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{7390f3d8-0439-4c05-91e3-cf5cb290c3d0}
• HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{4eb89ff4-7f78-4a0f-8b8d-2bf02e94e4b2}

Once you delete these keys, the required ActiveX control should be enabled in IE7.