If changes made to the attributes of print jobs contradict the printer's Filters and Restrictions, then the device displays an error, preventing the job from being released. Printers with Filters and Restrictions limit and control a user's ability to change the attributes of print jobs on such printers. Users who are able to release delegated print jobs originally printed by other users ( Users Details page > Advanced Options area, Allow this user to release jobs printed by others (Delegated print release)) are not allowed to change the attributes of such jobs at the device. However, it is recommended that you change the default settings and allow users to change the attributes of print jobs at the device if your Advanced Print Scripting:ĭoes not affect the attributes that can be changedĬonverts a print job to grayscale or 2-sided (users cannot contravene this change at the device anyway). Also, if your print scripts apply discounts, then if a user changes their print job attributes, the revised calculated cost will not apply the discount.
limits the amount of copies or pages of a document, then allowing a user to change the copies at the device will contravene that policy. For example, if a print policy Print policies allow you to remind users via popup to print duplex, route large jobs to dedicated high-volume printers, discourage users from printing emails, discourage printing web pages in color, and print policies can be implemented in PaperCut using advanced scripting. This ensures that users do not contravene existing print policies implemented via scripting. Unless your drivers are changing then rigging up a new print queue on a users machine should be quick and easy for most scripting languages to accomplish.When upgrading from PaperCut MF 18.1.4 or earlier, if Advanced Print Scripting is detected, then the default is NOT to allow users to change the attributes of print jobs at the device. Granted, you are still reinstalling the printers but the process can be done for users automatically which is likely the real concern you are trying to address with your question.
It also allows you time communicate and minimize the impact to your users incase they have apps with unusual printer requirements. This technique can let you pilot and control the rollout in manageable chunks so that your print server is not overwhelmed (we have disrupted prod with such migrations in the past). Customize the uninstall as necessary incase you want to give folks time to test on their own. If the machine has X printer then install y, uninstall x and switch defaults if necessary, rinse and repeat for all impacted printers.
Then run your script on the impacted machines via your software deployment system of choice. Set up a duplicate queue for each machine with the new name. Consider rigging up a powershell script to automate the migration for you.
0 kommentar(er)
