Wednesday, October 06, 2004
Point and Print connections loose devmode.
Users keep loosing thier duplexing options from our samba print queues. I haven't solved the problem, but this is what I've learned.
We provide print queues that are described by Microsoft as "Point 'n Print".
A point 'n print queue spools print jobs that have been formatted by the workstation.
The workstation learns how to format the job by downloading a print driver during the first connection.
The print driver doesn't automatically know if it can submit duplex jobs, however. It's up to the print server to hand off the driver, but also hand off some subsquent info about what options on the print device are available. Like a duplexer or extra paper trays or evelope feeders.
So when a user makes a printer shortcut in their account, they are storing three things
- The UNC path to the print spool- \\SAMBASERVER\printername
- A copy of the print driver, a file that they will carry around in their profile
- some device configuration options which modify how the driver will appear to them. This is stored in the Windows registry in long unfreindly string:
HKEY_CURRENT_USER\Printers\DevModePerUser\"\\SAMBASERVER\printername"
That last bit is what keeps vanishing. That's what puts a check in the duplexing checkbox.
The problem seems to be that workstations are somehow not setting that registry key, or are overwriting the user's version of that key.
The machine stores the devmode in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Print\Providers\LanMan Print Services\Servers\[server name]\Printers\[name of queue]\Default DevMode
I'm thinking, in looking at some computer registries, that the problem might be that the comptuer is looking to saint.env.duke.edu for the devmode information, rather than nicknet.env.duke.edu, which is a virtual samba server on saint.
But I can't tell for sure. One user told me that her duplexing comes and goes from certain machines. I'm not sure what we'd have to clear out to get those bad settings from the local system, or if moving nicknet to another server will fix it.
Users keep loosing thier duplexing options from our samba print queues. I haven't solved the problem, but this is what I've learned.
We provide print queues that are described by Microsoft as "Point 'n Print".
A point 'n print queue spools print jobs that have been formatted by the workstation.
The workstation learns how to format the job by downloading a print driver during the first connection.
The print driver doesn't automatically know if it can submit duplex jobs, however. It's up to the print server to hand off the driver, but also hand off some subsquent info about what options on the print device are available. Like a duplexer or extra paper trays or evelope feeders.
So when a user makes a printer shortcut in their account, they are storing three things
- The UNC path to the print spool- \\SAMBASERVER\printername
- A copy of the print driver, a file that they will carry around in their profile
- some device configuration options which modify how the driver will appear to them. This is stored in the Windows registry in long unfreindly string:
HKEY_CURRENT_USER\Printers\DevModePerUser\"\\SAMBASERVER\printername"
That last bit is what keeps vanishing. That's what puts a check in the duplexing checkbox.
The problem seems to be that workstations are somehow not setting that registry key, or are overwriting the user's version of that key.
The machine stores the devmode in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Print\Providers\LanMan Print Services\Servers\[server name]\Printers\[name of queue]\Default DevMode
I'm thinking, in looking at some computer registries, that the problem might be that the comptuer is looking to saint.env.duke.edu for the devmode information, rather than nicknet.env.duke.edu, which is a virtual samba server on saint.
But I can't tell for sure. One user told me that her duplexing comes and goes from certain machines. I'm not sure what we'd have to clear out to get those bad settings from the local system, or if moving nicknet to another server will fix it.
