Thank you for using the Support Forum. Please take a look at the solution for setting secure print as the default. You might also look at the firmware on the machines and update if necessary. Please test the firmware upgrade on one machine and see if it clears up the problem before you upgrade them all. If the problem continues please consider contacting your support centre for further assistance.
We have a number (40+) of ColorQube 9203's hosted on a Windows Server 2008 R2 print server for use by Windows 7 Enterprise x64 clients. The printers are shared using the latest (5145.1200.0.0) 9203 PCL6 and PS drivers. To comply with the particular organization's requirements, Secure Print is defined as the job type in the "Printing Defaults..." property dialog on the server.
When a desktop administrator adds a printer to a user's workstation, they walk the user through setting up their own Secure Print code - both through the Windows "Devices and Printers" wizard as well as through Outlook 2013's File -> Print -> Print Options.
This setup works great most of the time, but every now and then a user will create a Secure Print job from Outlook and the job will be held on the printer under the username of the server administrator who initially created the printer share (usually me). The users own Secure Print code will work to release the job, but since all such Outlook jobs are listed as "Microsoft Outlook - Memo Style" and all appear under my admin account, the user has to try each job in the list until they find one that accepts their PIN. This seems to affect both the PCL6 and PS drivers.
A temporary solution that the desktop admins have found is to go into the local Printing Preferences on an impacted machine, delete the Secure Print code, enter a new one (or the same one again), and Apply the changes. They point out that this "fix" often gets reset the next time the workstation is rebooted.
I will also note that we (server admins) tested on Friday mapping to the 9203s from a number of different workstations under a number of different accounts and were unable to reproduce the problem. The job were all held on the printer under the correct non-administrator username.
Is there anything else we can look into for a more permanent solution to this nagging problem?