I've recently upgraded a client's workstations to brand new computers, with Windows 7 Professional. The server is still Windows Server 2003. The server has 2-3 file shares that get mapped to users' workstations as drives.

The client has also upgraded from Acrobat 6.0 to 9.0 Pro. Since the upgrade, when the client tries to print to the Adobe PDF printer (aka convert something to PDF via the printer interface), it gives an error in the queue if the file is being saved on the network drive. If I instead provide a local path, the file "prints" fine.

Additionally, if I change the Adobe PDF printer's settings to "don't spool, print directly to printer", it prints to the network share fine, but then it resets that setting every time.

Things I've checked for:

  1. Permissions on the network share. The user and the computer has full access. We even gave the "Everyone" ibject full access.
  2. Reinstall Adobe Acrobat Pro 9.0
  3. Run updates to upgrade to 9.3.4

Has anyone else bumped into such a problem? The support fellows from Adobe are just taking me around in circles. They don't seem to have a clue either.

link|improve this question
feedback

2 Answers

The other thing is, if I change the Adobe PDF printer's settings to "don't spool, print directly to printer", it prints to the network share fine, but then it resets that setting everytime.

Well I'm guessing that when you print directly to the printer, the print driver is loaded up in the process that is printing (and with the same security token as the user that invoked the process), and if you're using the print spooler then it's being loaded up as SYSTEM. SYSTEM and LOCAL SERVICE will not authenticate with the computer credentials, so when the spooler tries to write to the network share it can't authenticate and fails.

Run PROCMON and watch for denied writes to your network share while printing. See which process is writing it, and under which user.

link|improve this answer
feedback

So I finally got around to doing a procmon diagnosis of this, and I see there is a error on the "CreateFile" call by the acrotray.exe (the adobe acrobat "tray" program). Another humourous thing is that it tries to spit out a .log file of a error print, which also gets denied cuz its trying to write to the same shared folder (for the same reasons).

In the procmon list, the CreateFile call's 'RESULT' is NAME_NOT_FOUND. Does that help at all? I'm not too familiar with win32 programming API to know off the top of my head why that would happen. So any help would be useful.

Meanwhile I'll try and read some win32 docs.

link|improve this answer
also I don't see any option to attach the procmon log file, so let me know and I can share/send it to whoever as needed. – Archit Baweja Nov 22 '10 at 17:25
feedback

Your Answer

 
or
required, but never shown

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