Keeping PDQ safe from human error.

0

I have a package called "New PC Build" that contains a number of nested packages (adobe, office, AV, Firefox, Chrome... you get the picture). I use this package to quickly build a new PC (I bet you didn't guess that by the package title). Anyway, this last week that package was somehow deployed to our entire network. I came into work, logged into a server and asked "who installed office on this server???" and then realized it was on other servers as well. You know that feeling you get that silently screams "OH #&$^!!!" - yeah... I got that feeling. Quickly it dawned on me that PDQ might have something to do with it so I opened up PDQ and low and behold my "New PC Build" was actively being applied to everything in the domain (the thin clients loved it). After my initial panic, I found that the good news is that it didn't hurt anything at all (Praise God!). Manufacturing production wasn't impacted, non of the users complained about anything (all 200 of them). I even had less support calls then i normally do but I had a lot of clean up to do (servers and undergarments). Thin clients just had to be rebooted (love those little guys). I also happen to abort the job before it hit all the servers but there was still a mess.

So naturally I had to wonder how in the heck did this happen. According to PDQ support, it was launched by "administrator". I'm not sure how I managed to run it but I must have. Non of my fellow IT peeps ever get into the PDQ server. It had to be me. All of which leads to the question about how to lock down PDQ deploy enough to keep accidents from happening again.

So far this is what I have come up with.

  1. Create a desktop service user account that only has local admin access to desktops and NOT servers. Likewise I would also create a Server service account for server management.

  2. Review each package to make sure that the package is limited to windows 10. I only have 2 packages that can be used on both PCs and servers. One package schedules a reboot and the other package triggers windows to check for updates.

What are your thoughts?

Cancel
login to comment
0

Best options is to setup inventory collections and use deploy package conditions. Setup collections in Inventory for current and out of date software and set the package to only deploy if the device is a member of the out of date group. You can also expand this by creating collections for AD OU, have a "new computer" OU that will deploy the package.

Cancel
login to comment

Reply