Introducing Terminal Services Easy Print: Part 2

Introducing Terminal Services Easy Print: Part 2

  • Comments 36

[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.

Leave a Comment
  • Please add 4 and 8 and type the answer here:
  • Post
  • 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!

  • 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.

  • 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

  • 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?

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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

  • MSDN - http://msdn2.microsoft.com/en-us/library/aa917490.aspx

    Thanks

    Gaurav

  • Correction - http://msdn2.microsoft.com/en-us/library/aa383503.aspx

    Thanks

    Gaurav

  • 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 ?

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

Page 1 of 3 (36 items) 123