2

I face the the following problem: We have one Windows domain with an application running in an user context of user of this domain (let's call this domain "A"). This Windows service has to print to an printserver of one or more domains (let's call this domains "B", "C" and so on) where no trust is between this domains. The Windows service is not possible to switch to another user context.

Is there anything like an proxy server that can handle the authentification to the other domains? Or did I miss another solution? Maybe I did not see the wood for the trees.

Some more background information to make things more clear:

  • There are < 1000 printers on the printserves in the "B"
    • This Domain "A" is just the first domain I have to make print work
  • Adding a printserver to Domain "A" is a no go
  • Why not print directly to the printer? – Greg Askew Oct 22 '15 at 14:09
  • @GregAskew To make things more clear. There are < 1000 printers just in the first domain where I have to make printing work. The business expectation is that the uses hit the print button in the application and paper comes out of the printer. – Marcel Janus Oct 22 '15 at 14:19
5

Use the Internet Printing role.

Have not used this role yet, but if you can print via internet, you can print via intranet ;) You should be able to set up a printer that connects via HTTP to the print server of the untrusted domain. Clients need the Internet Printing feature, which should be installed by default.

| improve this answer | |
  • That sounds like a solution. Thank you! I'll keep you up to date – Marcel Janus Oct 22 '15 at 14:49
0

If there are no special restriction enforced by the company who "owns" the printers and the printers are not under heavy usage, you may easily add the printer directly to your print server, too.

Restrictions could be that printing is only allowed during certain hours or certain users. Or anything that is not allowed to be delegated to your domain, by the "owners". Another restriction could be that the printers require authentication so that it is impossible to bypass the printserver and send the job directly to the printer.

Heavy usage would be a problem, because now you have two print servers with two queues. So if I start two jobs and you start two jobs 20 seconds later, it could result in a mixup between the jobs. Instead of having a Queue of AABB, it could result in ABBA (hehehe) or ABAB.

If both do not apply, just add the printer to your printserver by ip-address or hostname.

| improve this answer | |
  • Thank you for your fast response but adding a printserver to the domain is not possible from various reasons. Mixing up print jobs would be a catastrophic because of the personal data on the output. Do you have another idea? – Marcel Janus Oct 22 '15 at 14:30
  • Another idea would be trying to connect to the print server by SMB and connecting to a particular printer. Maybe you can re-share that printer across your domain. You would need a user account from the untrusted domain, of course. Have never done this, could be impossible. But you may try fiddling around with it. – Daniel Oct 22 '15 at 14:56
0

A solution I have used in several occations, when printing from one company to another company. On the server generating til print, you make a printqueue with the driver appropriate to the printer supposed to receiving and print the print. Use a Unix print port (LPR - port)if not installed allready you have to install it on the windows server. set the port up to IP adress og receiving server and queuename of the printer. On the receiving server set up a queue with the name use on portsettings of the transmitting server. Use the Generic text only driver, which let the print pass through without changes, set portsettings here as you would normally do TCP/IP port.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.