cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2131
Views
10
Helpful
18
Replies

WAAS, Terminal Server, and printing

dkennedy99
Level 1
Level 1

Running 4.0.17 of WAAS with clients on the edge side running terminal server clients back to terminal servers on the core side. TCP optimization is occurring fine with port 3389 for TS sessions.

However, my question is about printing. I have TS clients and their network printers on the same subnet on the edge side with the terminal servers on the core side with the applications. It is on the terminal server session side where they are printing back to edge-side printers. I have tried both "socket" and "IPP" type of connections back to the edge-side print queues, but no printing output seems to be optimized. Only when using "IPP" on the print queues do I see connections to the printers as "Internal Clients".

How do I go about optimizing printing in this setup? We do have clients still printing locally in the offices so at least that part is working.

Regards,

David

1 Accepted Solution

Accepted Solutions

David,

What you are probably seeing is the CIFS protocol being extremely chatty across the WAN. Without being able to offload the round trips across the WAN, your server has to wait for each acknowledgement, and each round trip, even compressed, is limited by the latency.

I can offer 2 possible solutions in the upcoming WAAS 4.1 code:

1. Centralized Printing Optimization: Move the print queue to a DataCenter server and WAAS will optimize the traffic in both directions for both Local print jobs and DC to Edge Print jobs (you could even try that now).

2. New CIFS Application Optimizer+Virtual Windows Blade: New WAAS code will support bidirectional CIFS optimization (no more core/edge) and Windows Server Core 2008 to run local infrastructure services like Print. The print server will be more supportable and the new CIFS optimizer will optimize in both directions. This however requires new Hardware (WAE-674)...

Dan

View solution in original post

18 Replies 18

dkennedy99
Level 1
Level 1

One other important thing to note here is that the network printers are in the same VLAN as the WCCP redirected clients.

David,

Are you using the print server on the edge WAE? When the terminal server sends the print job to the print server, you don't see it optimized, correct?

Are you intercepting via inline or wccp?

Thanks,

Dan

Yes, using the print server on the edge WAE. When the terminal server sends the print job to the print server, I do not see optimization, but a pass-thru connection to an 'Internal Client' (when running 'sho tfo con sum').

Intercepting via WCCP.

David

I spoke with a TAC engineer and he stated that in this configuration (remote printers and WAE print server with core terminal servers) that the print jobs are somewhat compressed via CIFS (port 445), but not much. He didn't seem quite sure. I'm not quite convinced of this yet and would love to hear someone else's experience with optimizing large print jobs using WAAS.

I have also tested print queues in the core location that send to physical network printers in the edge side WITHOUT using a WAE print server, and the print jobs are 80-95% compressed. That's what I'm talking about.

So this means I'll have to create seperate print queues for people that want to print locally and core-side print queues for those that want to print from Terminal Server in the core location to get the speed and compression I'm looking for.

Has anyone else out there experienced something similar? Any suggestions?

David,

You are correct, if a print job is coming from the core to the edge, it will NOT be in the cifs optimizer. To be in the cifs tunnel, the request has to be intercepted originating from the client at the edge.

I'm still looking at the Term Server to Edge print queue optimization question.

Dan

Thanks, Dan. I work with a company that highly depends on printing as well as Terminal Server. I would prefer to consolidate print queues at the edge print server and not create redundant ones at the core on another fileserver.

David

Any update to this?

David,

Sorry about the delay, I've been out of hte office. What do you see on the core WAE for the connections?

Dan

IPs:

10.100.8.25=edge printer

10.104.160.225=core server

10.96.208.155=edge WAE

10.104.192.33=core WAE

I am seeing *a little* compression between the core host and the edge printer where the queue is hosted on the edge WAE. sho tfo con sum from core WAE:

10.96.208.155:13877 10.104.160.225:445 212248 00:14:5e:85:59:5d F,F,F,F

This method is VERY slow to print out LARGE pdf files.

However, when printing the exact same document to a local, core print queue (on a server, not the core WAE) pointed to an edge printer (without the edge WAE acting as a print server), it prints VERY fast.

sho tfo con sum from edge WAE:

10.104.160.225:4148 10.100.8.25:9100 73021 00:14:5e:85:51:53 F,F,F,F

It appears that direct, raw printing (port 9100) is MUCH better optimized that CIFS-based printing (port 445)?

David,

Can you try creating an Application Policy for the server with the source IP (10.104.160.225) and destination IP of the Edge (10.96.208.155) as optimize full, but not using the CIFS Application Optimizer? This will allow CIFS connection TO the server to be optimized, however CIFS connections from the server to the edge will only be optimize full (TFO/DRE/LZ). This will also give us an idea if it's the CIFS AO or the Samba Print Server causing the issues.

Thanks,

Dan

Okay. So I made a new App Policy under AllDeviceGroups resulting in:

classifier TS-Printing

match src host 10.104.160.225 dst host 10.96.208.155

exit

map basic

name Printing classifier TS-Printing action optimize full

Does this look right? Will I have to restart WAAS on each end before this takes effect or not?

When I tried to print again, this is what shows on the core WAE:

10.96.208.155:30981 10.104.160.225:445 297582 00:14:5e:85:59:5d F,F,F,F

That looks good...as soon as the edge and the cores have the policies, all new connections will use the policy, no need restart. Printing work OK or still slow?

Dan

Printing is still very slow, even when specifying a custom App Policy between core server and edge WAE for full optimization, and not using the CIFS accelerator.

When printing using the AppSocket policy, though, it is much, much faster.

Using different protocols (445 vs. 9100) I guess makes the difference here.

Any other suggestions before I consider this "it is what it is"?

David,

I hate to say die...or it is what it is. Can you try putting that same policy into Passthrough and see if it's better or worse?

Dan

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: