Slow printer access Via Terminal server Network printer vs local

[Jerry Alan Braga]

We have 2 terminal servers in which we run our applications. The printers
on the terminal servers are mapped via login script to a central print
server. All of the servers are running windows 2003 SP2 (not R2). We have
be noticing printing lag and from what I see there seems to be a big
difference in the time it take to communicate to a networked printer from
the terminal server between using a networked version of the printer via the
print server and adding the printer locally to the terminal server and
creating the network port directly to it.

If I right click on the shared version and click properties it takes on
average approx 5-7 seconds to bring up the dialog box
If I right click on the local version and click properties it takes on
average approx .5-1.5 seconds to bring up the dialog box

Any ideas why such a difference, I was told that using the network version
if the recommended way of printing via terminal servers in a windows env.

The printer(s) are hp in this case a hp1320 and the drivers installed are
certified against windows2003 terminal server according to the hp docs.

 

[Jeff]

The shared version properties shows you the properties that the print server
has for the printer so when you look at the properties the print server has
to return the settings to you, whereas the direct approach to the IP is an
actual instance of the printer that is controlled by the terminal server
itself, in essence making the terminal server the print server for that
specific printer connection.

"Jerry Alan Braga" wrote:

> We have 2 terminal servers in which we run our applications. The printers
> on the terminal servers are mapped via login script to a central print
> server. All of the servers are running windows 2003 SP2 (not R2). We have
> be noticing printing lag and from what I see there seems to be a big
> difference in the time it take to communicate to a networked printer from
> the terminal server between using a networked version of the printer via the
> print server and adding the printer locally to the terminal server and
> creating the network port directly to it.
>
> If I right click on the shared version and click properties it takes on
> average approx 5-7 seconds to bring up the dialog box
> If I right click on the local version and click properties it takes on
> average approx .5-1.5 seconds to bring up the dialog box
>
> Any ideas why such a difference, I was told that using the network version
> if the recommended way of printing via terminal servers in a windows env.
>
> The printer(s) are hp in this case a hp1320 and the drivers installed are
> certified against windows2003 terminal server according to the hp docs.
>
>
>

 

[Jerry Alan Braga]

however, I have another printer that is a hp 4100 and the same operation has
almost no difference between local vs network.

What is the recommended way to run printers in a terminal server environment
when you have more than 1 ts that users can login to with a common set of
network printers.

Currently our print legacy in our applications is not acceptable.

"Jeff" <Jeff@discussions.microsoft.com> wrote in message
news:EE83E31D-C1DF-4D11-9475-0116CA3D1D07@microsoft.com...
> The shared version properties shows you the properties that the print
> server
> has for the printer so when you look at the properties the print server
> has
> to return the settings to you, whereas the direct approach to the IP is an
> actual instance of the printer that is controlled by the terminal server
> itself, in essence making the terminal server the print server for that
> specific printer connection.
>
> "Jerry Alan Braga" wrote:
>
>> We have 2 terminal servers in which we run our applications. The
>> printers
>> on the terminal servers are mapped via login script to a central print
>> server. All of the servers are running windows 2003 SP2 (not R2). We
>> have
>> be noticing printing lag and from what I see there seems to be a big
>> difference in the time it take to communicate to a networked printer from
>> the terminal server between using a networked version of the printer via
>> the
>> print server and adding the printer locally to the terminal server and
>> creating the network port directly to it.
>>
>> If I right click on the shared version and click properties it takes on
>> average approx 5-7 seconds to bring up the dialog box
>> If I right click on the local version and click properties it takes on
>> average approx .5-1.5 seconds to bring up the dialog box
>>
>> Any ideas why such a difference, I was told that using the network
>> version
>> if the recommended way of printing via terminal servers in a windows env.
>>
>> The printer(s) are hp in this case a hp1320 and the drivers installed are
>> certified against windows2003 terminal server according to the hp docs.
>>
>>
>>

 

[Jeff]

Re: Slow printer access Via Terminal server Network printer vs loc

I guess it would depend on your situation. In my situation I have several
Terminal Server Farms with several TS nodes in each farm. I use IP printing
on all my terminal nodes and restrict publishing the printer share to Active
Directory through GPO for my terminal OU's. I then will use the
printmigration tool to restore my printers to each node so all the nodes in
each farm are identical (farm specific, not all farms have the same printers,
but all nodes in each specific farm are identical) each week from a restore
performed on my "main" (the one I choose to make the most up-to-date)
terminal node in each farm. This also removes the terminal server printer
instances from being able to be searched for. Of course, I block GPO from
running for users when connecting to terminal servers and I control all
settings through other means. I also use roaming terminal profiles as well.

Lots of typing just to say, it depends on your implementation and situations
with apps, GPO, authorities, and other parameters

"Jerry Alan Braga" wrote:

> however, I have another printer that is a hp 4100 and the same operation has
> almost no difference between local vs network.
>
> What is the recommended way to run printers in a terminal server environment
> when you have more than 1 ts that users can login to with a common set of
> network printers.
>
> Currently our print legacy in our applications is not acceptable.
>
> "Jeff" <Jeff@discussions.microsoft.com> wrote in message
> news:EE83E31D-C1DF-4D11-9475-0116CA3D1D07@microsoft.com...
> > The shared version properties shows you the properties that the print
> > server
> > has for the printer so when you look at the properties the print server
> > has
> > to return the settings to you, whereas the direct approach to the IP is an
> > actual instance of the printer that is controlled by the terminal server
> > itself, in essence making the terminal server the print server for that
> > specific printer connection.
> >
> > "Jerry Alan Braga" wrote:
> >
> >> We have 2 terminal servers in which we run our applications. The
> >> printers
> >> on the terminal servers are mapped via login script to a central print
> >> server. All of the servers are running windows 2003 SP2 (not R2). We
> >> have
> >> be noticing printing lag and from what I see there seems to be a big
> >> difference in the time it take to communicate to a networked printer from
> >> the terminal server between using a networked version of the printer via
> >> the
> >> print server and adding the printer locally to the terminal server and
> >> creating the network port directly to it.
> >>
> >> If I right click on the shared version and click properties it takes on
> >> average approx 5-7 seconds to bring up the dialog box
> >> If I right click on the local version and click properties it takes on
> >> average approx .5-1.5 seconds to bring up the dialog box
> >>
> >> Any ideas why such a difference, I was told that using the network
> >> version
> >> if the recommended way of printing via terminal servers in a windows env.
> >>
> >> The printer(s) are hp in this case a hp1320 and the drivers installed are
> >> certified against windows2003 terminal server according to the hp docs.
> >>
> >>
> >>
>
>
>