MS Print servers

Stuck at the moment. I can map the printer fine if I connect through the VIP (eg. \\192.168.0.10 and double-click on the printer). But if I map the FQDN (eg. \\virtualserver.mydomain.com and double click on the printer) I get the error "Operation could not be completed (error 0x00000709). Double check the printer name and make sure that the printer is connected to the network."

 

 

This is Win2K8. Registry settings DisableLoopbackCheck, DisableStrictNameChecking, and OptionalNames are set. F5 Service Ports 0 (All services) are set on the Virtual Server and Pool config. Not sure what to do at this point, would appreciate any help! I have access to the F5 and the servers.

 

 

I'm in the process of building a new 2008 print server environment and wanted a better health monitor for print services. Following the instructions in the article below, you can create a health monitor for anything that can be queried via WMI (windows service state, cpu, memory, etc.). The title is kind of misleading as the benefits go much further than just terminal services monitoring, but the info is huge for me. Figured it was worth pointing out....

 

 

http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/1086419/Monitoring-Windows-Terminal-Services-from-BIG-IP.aspx

 

Hi again,

 

I have to make a little correction on my second last post. Today we realized again problems and it wasn't working anymore (not sure why this happens today).

 

But we found the critical option on the LB, it's the Address Translation, which is enabled by default. It needs to be disabled for the MS printing service. All other settings can stay on its default values, no TCP- or fastL4 profile modifications and also SNAT can be used.

 

Based on the findings from Meena, that the IP-address in the TCP-data part will be used I thought it shouldn't matter if this option is enabled or not (so I choose the default setting).

 

To summarize my findings:

 

- we are using 9.3.1 and w2k3

 

- print server with loopback adapter (same IP as the VS)

 

- enable "Client for MS networks" and "File and Printer Sharing" on the loopback adapter

 

- the two Registry tweaks are NOT implemented

 

- VS and poolmembers with the "any"-port option

 

- disable Address Translation on the VS

 

- all other settings on the LB can stay at its default value or can match you individual preferences

 

- if the Default Gateway of the print server is not pointing to the LB, I prefer to enable SNAT to have a clear traffic flow and no asynchronous routing (makes things complicated especially during troubleshooting), but it will also work with SNAT disabled (doesn't matter from a technical point of view)

 

 

Ciao Stefan :)

 

Hi Chris,

 

the affected cluster is running on 9.3.1

 

Further tests and optimizations are not planned, but with the default fastL4 profile TCP optimization is already at its best.

 

 

Ciao Stefan :)

 

Stefan, that's good to know. What Big-IP version are you running? I never thought to test using a standard config after upgrading. I think I was on 9.4 for the original setup. Since you got it working with a standard config, are you going to test tcp optimized profiles and one connect?

 

 

Chris

Hi Meena,

my question was not if SNAT is technical required, but if it's also working with SNAT enabled.

As I mentioned in my previous post, MS printing service has nothing to do with nPath routing. Based on the findings with the destinationIP in the TCP header and data part, the only requirement is the loopback adapter on the print servers.

I tested this with my server guy and I can confirm now, that it is still working with basic and default Loadbalancer settings, following is our current setup:

virtual mltprtp01 {
   destination 10.10.10.10:any
   snat automap
   translate service enable
   persist source_addr
   pool printer_cluster_mltprtp01
   vlans Productie enable
}

I also get confirmed from the server guy, that he is not using the two mentioned Registry tweaks. The print servers are running on w2k3.

Maybe this is helpful and interesting for someone else as well.

Ciao Stefan üôÇ

No SNAT needed! The original client IP is preserved and the return traffic from the print server goes directly to the client. F5 just does the transparent load balancing.

In the meanwhile I got feedback from the server guy and he got it working now.

 

He enabled "Client for MS networks" and "File and Printer Sharing" on the loopback adapter and printers can now be mapped.

 

This is maybe interesting for someone else.

 

Btw. he mentioned that the two Registry tweaks were only implemented on one print server and the other one is working fine as well. But maybe this depends on the OS of the print server. I don't know which version they are running.

 

Thx all for the great support here.

 

 

Ciao Stefan :)

 

The way I remembered why npath routing is needed is because the packet capture showed that the F5 will NAT the IP address in the tcp header but not on the tcp data. TCP data still showed the virtual server address. So, when the request is sent to the print server with the virtual server address, the print server rejects it.

 

 

When you configure a loopback address on the print server which is the same as the virtual server address, the print server will accept the request because it knows that as a loopback address.

 

 

 

We had frequent issues with that design where the server group had to restart the services or the server but now it seems to be ok. Most of the problems were related to the config on the server side.

 

 

 

Meena

 

 

 

 

 

 

 

VIP in the same subnet shouldn't be an issue. Your config looks fine to me. I can remember having the same issue you are dealing with. I just can't remember the change that fixed it. If you can't see the windows config though, I'd just about guarantee that is where your problem is.

 

 

Chris