Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

PDQ Deploy to change folder permissions at the user level

Hello Everyone, 

I am using a powershell script via PDQ Deploy to edit the permissions on a folder on a users computer. I have a script running in VS that prompts for username, hostname, and it can build the path and work correctly. Example - 

$ACLPath = "\\$hostname\c`$\users\$username\AppData\Roaming\TestFolder"
 
I'm trying to fully automate this, with the end result being able to deploy this to entire PDQ Inventory groups to "open" or "close" user access to this folder.
 
My idea for the PDQ job is to remove the "prompt" for username and hostname. With PDQ, I should be able to use some form of "C:\Users\$env:username" to build the path instead. 
 
The problem: 
Since I use the $env:username, I can't set the PDQ job to run as deploy (admin) user, I need to run it as Local Logged on User... which doesn't have the permissions to edit the folder. But if I run the job as Deploy user, it will pull the admin username, and won't be able to make the correct path. 
 
I'm completely open to suggestions on this one, as I'm a bit stumped on how I can use it with PDQ. 
 
 
Thanks!
1

Comments

3 comments
Date Votes
  • Thinking at a high level (because I couldn't write it from scratch myself yet), how about:

    1. Run a script as the logged-on user to get their name, profile path, etc and write it where all users can read it
    2. Run a script as an admin to read the information gathered in Step 1 and act upon it

    There must be places in the registry or filesystem where all user accounts have both read and write access.

    2
  • Mike, I want to give you a big thank you. This resolved my ticket. Here's how I got it to work:

    Part 1
    Step 1, it uses "Local Logged on User", does a test path for C:\_A\username.txt and creates it if it needs to.
    Step 2, it uses $env:username to write the username.

     

    Part 2 then reads that file, writes it to a variable and uses Deploy User to set the permissions for the folder.
     
    Part 3 deletes the file (used in case more than one person use this computer). 

     

    (I created 2 scripts, one for locking the folder down, and the other for giving full control to the user). 

     

    1
  • That's a clever solution. Thanks for sharing!

    0