I'm having trouble with a PowerShell script that I've set to run at computer startup via Group Policy. The script's purpose is to manage printer installations, and it's stored in a shared folder. The script starts by logging its actions and tries to remove an old printer before mapping a new one. However, while it runs smoothly when executed manually after logging in as a user, it fails to remove the old printer or add the new one when launched from the GPO. I'm curious if there's an issue with permissions or timing during startup. Should I consider placing the script on the local machine instead?
5 Answers
It sounds like the script is running under the system account when initiated by GPO, which could be causing the printer installation to fail. Many printer installations require user account permissions, so switching the script to run at user logon could resolve your issue. Also, have you considered using Group Policy Preferences to manage printers? That might simplify the process! Check out the documentation for more details.
Just a thought – check if the network share is accessible when the script runs. With feature updates, Windows might execute startup scripts before the network is fully available, especially on SSDs with fast booting. If you're using Windows 11, you might also run into problems with guest authentication, so consider using a DNS name for your server and adjusting access rights.
You should definitely be cautious about writing to sysvol from a client machine. That's not something we allow in our setup as it can lead to security issues. It's generally better to keep such scripts organized in a secure location that only servers can access.
I created a GitHub repository for deploying printers in a more automated fashion across our network. It leverages security groups and OU membership to control printer access, and it automatically removes printers no longer accessible to users. If you're interested, I can share the link and some setup screenshots!
I had a similar setup where I used a logon script that allowed users to change their printers without needing elevated privileges. It worked well but did require users to log in first, which could take a while. It might help to review whether your users have the necessary rights to install printers. That could be a factor if the current system doesn't allow it.
But don't forget, if users lack admin rights, they won't be able to install printers anyway. You might need to find a different approach.