Why are you not using the cups printer drivers in the cups enviroment there are both x64 and i386 versions and gets round the issues with broken drivers and allows cups features to be passed to windows.
-----Original Message----- From: Nick Couchman <nick.couch...@seakr.com> Sent: 20 May 2010 19:10 To: samba@lists.samba.org; Mike Rambo <mra...@lsd.k12.mi.us> Subject: Re: [Samba] Samba + CUPS > > Have you looked at granting rights like: > > net -U"ADuser" rpc rights grant "ADdomaingroup" SePrintOperatorPrivilege > > There are several different privileges that can be granted in this manner. Thanks, Mike, I actually figured out the issue, thought I'm not sure why this is the case. According to the current Samba startup and documentation, the "printer admin" option is deprecated; however, setting this option (in addition to admin users) seemed to make things work. So, I'm not sure what is supposed to replace the "printer admin" option (perhaps the RPC rights you mention above??), but it seems it's still necessary to make things work correctly. By the way, the user account in AD (and NT4) is in the Domain Admins group and the Enterprise Admins group, so these rights should already be granted. I'll double-check when I get a second, though. On to my next question. I'm in an enterprise environment where I'm using CUPS + Samba to serve out printers to my entire organization. Most of these printers are network-attached, and some of the more recent drivers expect to be able to communicate directly with the printer, instead of talking through the CIFS service. Some of the drivers allow you to point it at a specific IP/hostname, however, others try to communicate automatically by grabbing the Port information from the printer. Since Samba doesn't truly give the port that the printer is connected to, this is proving to be problematic for a couple of my printers. When you use Windows Server as a print server, it seems like, instead of directing printing through it, all it does is give the printer definitions to the client, and allows the client to communicate directly with the printer. I can see where this behavior would be undesirable in many situations - if you're truly trying to control printing, manage access, and centralize things, this doesn't really accomplish that task. However, with the issue I mention above with printer drivers requiring bi-directional communication to function properly, it seems this is the behavior that I actually need. Does anyone know if it's possible to have Samba pass through the "real" port information? I've tried to use the "enumports command=" option in smb.conf and list out ports, but this just seems to give a short list of Local Ports to the computer, and doesn't really allow you to enumerate things like Standard TCP/IP Ports. Ideas? Suggestions? Work-arounds? Advice? Thanks! -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
