PDQ Deploy console must be run as an administrator (Server 2012)
I get this error and I am following the documentation to my knowledge. Here is the scenario, do you have any experiences with this or a solution.
Our server admins require applications such as PDQ to run with a service account (svc.pdq) which has admin privileges on the server and on all client devices. However, they require that I login to the 2012 server with my credentials and not an admin to launch the console. Of course PDQ can use different credentials to deploy which are mine and on client machines I am an administrator. The server is the only place I cannot be an admin for security of that system.
We have followed the documentation guidelines for credentials where there is no mention here or in other places that PDQ requires an admin account to utilize the console. In fact it mentions the areas where a regular user account would need to write (db, repository and a few other places) which has been given to the regular user account. I still get the message "PDQ Deploy must be run as an administrator, please try again". I found an article reference in 2010 for support that refers to having to change the sqlexpress login credentials but PDQ now appears to use sqlite instead. I downloaded a management tool to open the db and see nothing of where I can put in that other clients on the system can use the db. The check must be happening against some parameter within the application code. I don't understand why PDQ cares if the console user is an admin as long as the background service is and the credentials to deploy have admin rights to the machine. This check or setting if being done by PDQ seems very odd to me.
I feel as if somebody has to have this working in a similar scenario out there somewhere because it is a pretty standard setup for an enterprise environment. Please help if you do. I really like the software and the staff here at Admin Arsenal is usually spot on for support but I cannot seem to get a good answer to my problem. Thank you in advance for any help you can extend and look forward to any responses or additional information you may need to help me out.
Comments
Hi Brad,
Jason mentioned the current ticket that you have asking this same question.
The requirement to run in elevated mode has been in PDQ Deploy since we merged the free and pro versions into one application back in 2011. If I recall the call out in the documentation regarding the permissions requirements to the database are there because a few of our customers had removed the default Administrator access to %ProgramData% to only allow specific accounts that, in their environments, didn't include the console or background service accounts.
The technical reasons for requiring that the console run in elevated mode are due to necessary access to HKLM, %ProgramFiles%, %ProgramData% and the fact that in early free app when someone wouldn't run the console as an administrator there were often authentication issues (even if the "deploy user" had admin rights) when it came to connecting to the remote target's Service Manager.
There are also other non-technical reasons for this requirement. If we didn't require the console to run in elevated mode then a regular user could open PDQ Deploy and simply start deploying software and even making changes to previously set credentials.
To help avoid confusion we will modify the documentation to specifically mention that elevated mode is required.
Hi Shane,
I appreciate the response from the team but I do think the approach is coming in the wrong direction. I mean that with all due respect because I have always appreciated the product capabilities and support your team has put forth in a relatively inexpensive package. To scale well and bring in the medium/large businesses that have strict security principles is where I have difficulties in the logic.
On the technical end those edits you mentioned has two points but think of the audience using the software:
a) Any admin should know how to change permissions where needed on the three locations
b) How does the logged in system user become problematic if the PDQ is really using the deploy credentials
c) An admin can set PDQ to run as admin by default without having to specify it each time
On the non-technical side:
An admin can easily restrict who can and cannot login to a workstation/server remotely or interactively. Using a group to allow logins is easy in any ldap structure and would keep regular users without the need to use PDQ off the system entirely.
So, I guess what I'm trying to convey is that all the concerns I've heard so far are negated by Administrators or PDQ clients following basic enterprise security principles in my mind. It seems to penalize the broader scope customers but like I said earlier I do like the value the software brings to the table. As I transition from a mindset of small shop to large shop myself I have struggled with conceptual changes to the models I had established but in the end I have to evolve. My questions were to hopefully express those views in a way that could entice positive change for the product. I do wish that instead of simply changing the documentation to reflect more accurate statements that the group would consider changing the operational model. Thank you again for the follow-up.
This is a huge problem for me also ... is this going to be fixed?
Since this server requires access to c$ of remote computers giving techs admin access to this box is a big issue
I have the same problem as we strive to implement a least permission environment.
What I cannot begin to understand is...
PDQ is such a great and useful product. It solves a lot of problems for us at a good price point.
That said, the individuals responsible for this part just plain and simple are dropping the ball. First, don't write information to protected locations and write them to more public locations for simply starting the app. Two, your customers know how to modify permissions as needed if you will define what is really taking place to cause it to happen. At least that limits scope versus the need to be an overall admin on a machine.
I'm just glad others have also thought this is an issue versus the alternative that I just was completely out of my mind.