Welcome to MSDN Blogs Sign in | Join | Help

Introducing Terminal Services Easy Print: Part 2

[Part II in a series. Jump to Part I, Part II, Part III] 

In Part 1, we introduced the main benefit to Terminal Services (TS) Easy Print: a "driver-less" solution for printer redirection over a TS session. In addition, several other important changes have been made to improve printing redirection performance over TS. This post lists the changes and their benefits.

 

Change #1: New group policy to allow the redirection of only the default printer of the TS client machine.

            In the past, administrators have requested the ability to have their users redirect only the default printer on the TS client machine, and not all printers. To meet this request, we have introduced a new group policy (GP) to Longhorn Server. The GP is located under:

"Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection"

 

and named:

 

 "Redirect only the default client printer."

By enabling this GP on a TS server, an administrator will ensure that only the TS client's default printer will be redirected on the TS server, and not all printers.

            By having the ability to allow the redirection of only one printer, administrators may now allow printing redirection -- without taking the same scalability hit they would have by redirecting all printers. Also, administrators can avoid having printers installed that their users will most likely not want to use (such as the Fax printer that comes installed by default on Windows Vista).

            This policy will work with connections from any version of the TS client.

 

Change #2: Scope of redirected printers

 

In Windows Server 2003, administrators could see all redirected printers of every user. Also, if a user had multiple sessions open, redirected printers of all sessions would be visible to each individual session. In Longhorn Server, this is no longer the case. The visibility of redirected printers is limited to the session where they are installed.

The behavior is very similar to the behavior of redirected drives. Printers now have the Session SID set in the list of ACLs. Properties of this change include the following.

  • This ACL limits the printers from appearing in another session, even that of the same user. For example, say user1 has logged on to two different TS sessions (session 1 and session 2) on the same server. Redirected printers of session 1 will not be visible in session 2 and vice-versa.
  • There are no exceptions to the above rule. By default, anyone under the "Administrators" local group also will not be able to access the printer.
  • The users can change access to the printers by editing the permissions in the printer properties to be made accessible to other users.

This is a significant change from Windows Server 2003. Previously, redirected printers were visible to all sessions belonging to the same user as well as to all administrators on the server. Due to this new behavior, there has been a perceivable performance improvement in the enumeration of printers and in the logon time of new sessions.

 

Change #3: Per-session Default Printers

Another new feature in Longhorn Server is that the default printer is on a per session basis. In Windows Server 2003, the default printer for all sessions that share the same user was the same. In Longhorn Server, each session a user owns will have its own default printer set. Each session's default printer is independent of any other session's default printer, regardless of which user created the sessions.

As a result, the registry location holding information about the default printer is different. The per-session default printer is stored in the "Device" key at the registry location mentioned below. If the Device value is empty then it falls back to the per-user default printer key.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\SessionDefaultDevices\<SESSION_SID>

With this change to the registry location, Winspool APIs such as GetDefaultPrinter() and SetDefaultPrinter() should be used to query or set the default printer, respectively.

 

Change #4: Names of redirected printers are shorter.

            As the screenshots below show, the names of redirected printers have changed. In Windows Server 2003, if a user redirected a printer named "Canon Bubble-Jet BJC-1000", the TS session would display the redirected printer as "Canon Bubble-Jet BJC-1000 (from %CLIENT_MACHINE_NAME%) in session %Session_ID%", as shown in the screenshot below.

In Longhorn Server, the TS session displays "Canon Bubble-Jet BJC-1000 (%SESSION_ID%)" as shown in the screenshot below.

The shorter name helps make the experience more seamless and makes scripting easier.

Published Thursday, May 03, 2007 7:06 PM by termserv

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: Introducing Terminal Services Easy Print: Part 2

Hi, comments on each change below:

Change#1: This is an excellent start. I would consider adding more options. For example, choose whether to redirect local, network, default plus maximum of n number of printers.

Change#2: In general I like this, however, I have two issues:

1. How will an admin troubleshoot printing issues with redirected printers if they are unable to see them?

2. The default ACL for autocreated printers *should* be configurable by the admin. This will facilitate special cases where autocreated printers should have different permissions than the default. For example, you may want normal users to have more rights than default to their own autocreated printers.

The current printer permissions model is inconsistent with the rest of windows, for example, what if there was no way to set the default NTFS permissions for subfolders and files that are created within a particular folder--that is the situation now with autocreated printers.

Change#4: The naming scheme should be configurable by the administrator. It is fine to simply make a registry value for this, so that way you would not need to write a UI.

For example, I would like the option to specify a naming scheme of %PRINTERNAME% %USERNAME% for those cases where legacy applications expect a consistent printer name. This ability has been requested many times in the newsgroups.

Of course when the above naming scheme is in use the restrict each user to a single session *may* be mandatory (not sure if it still will be given your switch to per-session printer visibility)

I think a REG_SZ value where we could specify the naming scheme would be nice, here are a few sample values:

%PRINTERNAME% %USERNAME%

%PRINTERNAME% (%SESSION_ID%)

%PRINTERNAME% on %CLIENTNAME% (%SESSION_ID%)

Not mentioned in this post, but what about configuring the maximum bandwidth consumed by printing? This is important in environments with limited bandwidth.

Thank you for all of your hard work!

Thursday, May 03, 2007 6:39 PM by TP

# re: Introducing Terminal Services Easy Print: Part 2

TP, thanks for your feedback. The one question I can immedietely answer is "what about configuring the maximum bandwidth consumed by printing?"

Please look at http://blogs.msdn.com/ts/archive/2007/04/09/bandwidth-allocation-for-terminal-server-connections-over-rdp.aspx

Although the solution in that post is not perfect (printing bandwidth is lumped with all other redirections), this will hopefully be helpful.

Thursday, May 03, 2007 6:46 PM by Zardosht Kasheff [MSFT]

# re: Introducing Terminal Services Easy Print: Part 2

You are welcome. Thanks for the link--I read that before.

The new bandwidth allocation will help in some scenarios, but [if I understand it correctly] will not help much in the case where the server's connection is limited.

For example, one user prints a large job and consumes a large percentage of available bandwidth on the server's side. It would be nice to limit the amount of bandwidth each user can consume with print data. If it would be easier for you to apply the limit to all non-video traffic then that would be acceptable.

Otherwise people need to purchase a packet shaping device or other bandwidth management software to limit each connection.

Does the above make sense, or is my understanding incorrect? I admit I have not tested the new allocation mechanism yet so I cannot speak with authority.

Thanks.

-TP

Thursday, May 03, 2007 8:42 PM by TP

# re: Introducing Terminal Services Easy Print: Part 2

I dont understand why that solution would not work for you. You say it would be easier to "apply the limit to all non-video traffic". That is exactly what the solution does. FlowControlDisplayBandwidth is for video data, and FlowControlChannelBandwidth is all non-video data.

Say you set FlowControlChannelBandwidth to 10 and FlowControlDisplayBandwidth to 90. By doing this, a user's huge print job will take at most 10% of the bandwidth. That leaves 90% of the bandwidth available for display data. This seems to be the "limit to all non-video traffic" that you are looking for.

Why will this not work? What scenario fails? By the case "where the server's connection is limited", do you mean the server's bandwidth is limited?

Thursday, May 03, 2007 8:59 PM by Zardosht Kasheff [MSFT]

# re: Introducing Terminal Services Easy Print: Part 2

I said "*If* it would be easier for you..." as opposed to having granular limits for each virtual channel (printing, drives, etc.).

The solution may work--I have not tested it yet. I don't know the implementation details of the bandwidth allocation.

Is it per RDP connection or is it applied across ALL RDP connections?

For example, say you have a TS server behind a 1024Kbps Internet connection and 20 remote clients each with a 4-15Mbps (download) cable/FIOS Internet connection. One or two users print a large document concurrently.

How much bandwidth will be available for the remaining 18 users who are not printing? Will the server effectively limit the *total* server-wide printing bandwidth to 307Kbps (30% of 1024Kbps)?

Or will the server apply the bandwidth allocation only on an individual connection basis, in which case the two printing users could consume enough bandwidth to increase latency for *all* connected users.

Thanks.

Friday, May 04, 2007 12:36 PM by TP

# re: Introducing Terminal Services Easy Print: Part 2

Is it per RDP connection or is it applied across ALL RDP connections?

[makarand] bandwidth distribution in TS is per connection, meaning distribute the bandwidth within a connection among various channels. so the solution we have does not address the scenario you mention. but I think its the stack beneath us that is responsible for the distribution between connections. the problem is similar to having two applications using the bandwith and the distribution between them.

Tuesday, May 08, 2007 3:59 PM by Makarand [MSFT]

# re: Introducing Terminal Services Easy Print: Part 2

All the limitations of EasyPrint are already addressed through 3rd party products like triCerat's ScrewDrivers.  And those products aren't limited to Longhorn.

I wouldn't expect MS to add a ton of features to EasyPrint... that's outside their motive of creating it in the first place...  a basic "fix"... not an enterprise printing solution.

Thursday, May 10, 2007 2:41 PM by Peter B.

# re: Introducing Terminal Services Easy Print: Part 2

Peter, we would like to know from your testing of TS Easy Print, what are the limitations of the solution? The solution is still in beta and hopefully we can address those, if any.

Thank you.

Tuesday, May 15, 2007 10:15 AM by Gaurav Daga [MSFT]

# re: Introducing Terminal Services Easy Print: Part 2

It would be easier for testing if we had a Vista and XP Pro client, as it's not very practical testing with LHS as the client.

Tuesday, May 15, 2007 10:28 AM by Patrick Rouse

# re: Introducing Terminal Services Easy Print: Part 2

Other client support is in the works and will be announced when available, but the behavior of the feature is the same on all client platforms. We understand that using LHS as a client is not a real end user scenario, but it would be great if for early testing feedback, if you can use this platform and provide us input on the feature. Thanks.

Tuesday, May 15, 2007 2:27 PM by Gaurav Daga [MSFT]

# re: Introducing Terminal Services Easy Print: Part 2

Hi,

Where I can read about RDP Protocol ? We need to write a Virtual Channel to record the session for future playback.( like an session_yyyy_mm_dd.avi )

Regards,

Alexnaldo Santos

Monday, June 04, 2007 6:49 AM by Alexnaldo Santos

# re: Introducing Terminal Services Easy Print: Part 2

Tuesday, June 05, 2007 5:28 PM by Gaurav Daga [MSFT]

# re: Introducing Terminal Services Easy Print: Part 2

Tuesday, June 05, 2007 5:31 PM by Gaurav Daga [MSFT]

# re: Introducing Terminal Services Easy Print: Part 2

Where I can read about RDP Protocol ? We need to write a Virtual Channel to record the session for future playback.( like an session_yyyy_mm_dd.avi )

you mean to offer the same function as Citrix does ?

Friday, August 31, 2007 11:28 AM by Frederic

# re: Introducing Terminal Services Easy Print: Part 2

I like Terminal Services in my daily work. That's useful.

Wednesday, September 05, 2007 12:05 AM by 同声传译

# Introducing Terminal Services Easy Print: Part 3

In Part 1 , we introduced the main benefits of Terminal Services (TS) Easy Print: a “driver-less” solution

Friday, October 05, 2007 5:48 PM by Terminal Services Team Blog

# re: Introducing Terminal Services Easy Print: Part 2

Easy Print looks interesting, but I'm trying to figure out whether it will help with my own situation:

I have printer which is a couple of years old, connected to my print/file server. There are various client PCs including a Windows Vista system.

My problem is that Windows Vista drivers are not available for my printer, so I can print from every computer except my Vista PC. This is irritating because every time I want to print a document (e.g. a Word document) I have to share it with (or otherwise copy it to) one of my Windows XP computers, then print it from there. This also means I have to install the relevant application on the XP machine.

I'm not using Terminal Services (I'm just using simple file and printer sharing) and I know that this isn't the scenario Easy Print is designed for, but it sounds as though it could solve my problem. Any comments?

Monday, November 26, 2007 10:23 AM by Andy

# re: Introducing Terminal Services Easy Print: Part 2

Andy, as you said, Easy Print is not designed for your scenario. Easy Print is used only for redirecting printers over a remote desktop connection to a Windows 2008 Server. Regular file and print sharing does not use Easy Print at all.

Monday, November 26, 2007 1:43 PM by Eric Holk [MSFT]

# Printing preview

Hi all, this functionality is already implemented in Citrix client printer mapping, but one of problems is the printing "preview" on server side, this means that printing preview is made on client side ?

You may confirm that the printed document will be exactly as i see in the server side preview?

Thank you, i like Windows Terminal services!!!

Friday, November 30, 2007 1:33 PM by Corrado

# Problems using Easy Print

When trying to RDP map a Brother HL-2140 the server responds "Unable to find driver. Please contact your administrator."

If I understand correctly the server should use the "Easy print" driver when the driver does not exist.

Can anyone help?

I'm using Windows 2008 RC1 as a server and another Windows 2008 RC1 as a client.

Saturday, February 02, 2008 5:37 AM by Asger Hvam

# re: Problems using Easy Print

I have read that it requires RDP 6.1. I have looked for it and can not find RDP 6.1 is even released yet for XP or Vista.

More info found:

http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2436869&SiteID=17

I really wanted to test this too as it is a factor in upgrading to 2008 server.

Wednesday, February 27, 2008 8:15 PM by James

# re: Introducing Terminal Services Easy Print: Part 2

I'm trying to give my RDP Clients only 1 option to print.  I've set the GP for Redirect only Default Printer and Removed the "Add Printer" icon from the print dialogue box.  How can I hide the Microsoft XPS Document Writer Printer from their view?  I tried deleting just the printer and the driver as well as, deleting the printer and leaving the driver, but that leads to no print option at all.  Also how can I remove the "Print to File" option on the print dialogue box as well?

Wednesday, April 30, 2008 11:26 AM by Marc

# re: Introducing Terminal Services Easy Print: Part 2

i am having problem printing PCL file with

easy print env' (2008 ts, winxp sp3 .net 3.5,easy print enable client)

doe's anyone know if easy print support PCL

Printing ?

yuval.

Sunday, May 18, 2008 2:14 AM by yuval

# re: Introducing Terminal Services Easy Print: Part 2

I would like to use TS Easy Print to redirect a print job and then save it as a file, such as PDF or XPS, or any other format.  I have not been able to get the XPS printer to do this. Although it does say it is redirected, it wants to save the print job on the server, not the client.

Wednesday, May 21, 2008 12:00 AM by Dave Ames

# re: Introducing Terminal Services Easy Print: Part 2

we are having a problem printing to the non default printer on a xp sp3 .net 3.5 when the application knows the printer name.

.device ="printer (redirected 3)"

it will redirect to the default printer. if we use printer dialog to select it work fine

if client is xp sp2 and rdp 6 prints fine except no easy print

Friday, June 13, 2008 10:10 AM by tim spero tim@timspero.com

# re: Introducing Terminal Services Easy Print: Part 2

I ran into an issue with HP LJ 2420 PCL 6.  Printer is not redirecting, when I set their HP LJ 4200 PCL 6 as default, it works as it should.  Seems to be an issue here,  Client has xp sp3 and .NET 3.5.

Thursday, July 03, 2008 12:12 PM by Marc

# TS EasyPrint (продолжаю разбирать вопросы)

Во время моего доклада “Безопасный удаленный доступ к приложениям” было задано несколько вопросов по...

# TS EasyPrint (продолжаю разбирать вопросы)

Во время моего доклада “Безопасный удаленный доступ к приложениям” было задано несколько вопросов по...

# re: Introducing Terminal Services Easy Print: Part 2

Hi,  

I am using remoteapp for Microsoft Great Plains and CRM.  I have an issue when trying to print.  The last user who signs into the GP or CRM sets the default printer.  So every single time a new user signs in they have to change the printer.  The users local default printer is not being set as the default printer in the application its just using the printer of the last signed in user.  How do I fix this.

Friday, March 27, 2009 10:03 AM by PxPx

# re: Introducing Terminal Services Easy Print: Part 2

Unable to see images... Looks like the link to your picture location is broken.

Monday, June 08, 2009 5:16 PM by Dan Stolts

# Introducing Terminal Services Easy Print: Part 3

[Part III in a series. Jump to Part I , Part II , Part III ] In Part 1 , we introduced the main benefits

Friday, June 12, 2009 12:56 PM by Terminal Services Team Blog

# Introducing Terminal Services Easy Print: Part 1

[Part I in a series. Jump to Part I , Part II , Part III ] Historically, printing redirection has been

Friday, June 12, 2009 12:57 PM by Terminal Services Team Blog

# re: Introducing Terminal Services Easy Print: Part 2

EDIT:  I found the solution.  I disabled in the Group Policy "Use Terminal Services Easy Print printer driver first" under

"Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection".  Now below problem is solved for ALL the client PCs trying to print to their local printer via TS.

ORIGINAL PROBLEM:

I have a workstation with windows xp servicepack 3 and .net 3.5.  In the remote session all my redirected printers show up but when I try to print out of them, no page comes out of the printer with no error as well. However, the redirected printer HAD been working fine via TS a month ago.  I don't know why it wont work now.  I tried another computer (at home) with the same specs above and my redirected home printer wont print.  Further exploration...no PC running RDC connecting to our Win Server 2008 64Bit via TS will successfully print via redirected printer.  Yet...the macintosh's RDC 2.0 will print via TS redirected printer every time still to through this same server.  I've upgraded to Win Serv '08 RC2.  No help.  Ran every update possible on the clients.  No help.  Checked the Group Policy, Easy Print is engaged and clients have no boxes checked for disabling printers, audio, etc.  

I'm going to try disabling Easy Print, install the client printer driver on the server, and see how that goes.  I tried with Easy Print ENABLED to do the above, but no help.

Wednesday, October 07, 2009 12:24 PM by David Officer of Goldendale, WA

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker