How To Deploy A PowerShell Script In Active Directory Using GPO
So you want to write a cool PowerShell script and share it with your entire Active Directory domain? Awesome, this is a great learning experience. You get to learn about System Administration, PowerShell, and most importantly a little bit of System Security. Now, without further or due, let me show you How To Deploy A PowerShell Script In Your Active Directory Environment Using A Group Policy Object.
Step 1. Create A Share Folder
The first step is to make a shareable folder on a server that everyone in your domain can access. I am currently logged into my Domain Controller (Windows Server 2019). Go ahead and open your File Explorer and create a folder somewhere in the C:\ drive. You can name this folder anything you want, but I am naming mine “IT”. This folder is just for organization, it is not the folder we will configure to share. Reference the image below, for help.
Now create a subfolder inside of your “IT” folder and name it “PowerShell_Scripts”. If you copied me exactly, then your final folder path should be:
C:\IT\PowerShell_Scripts
Reference the image below.
Now we need to enable sharing on our subfolder settings. Right click the “PowerShell_Scripts” subfolder and click “Properties”. Then click the “Sharing” tab and choose the “Advanced Sharing” option. Reference the image below.
You will then need to check the box that says “Share this folder”, and will be prompted to name the share folder. You can keep the default share name, or name it whatever you want. I am naming mine ‘PowerShell_Scripts”. After naming the share folder, click “Apply” . Reference the image below.
Next we need to change the permissions of this share folder to make it more secure. In the Advanced Sharing options that you are still in, click the “Permissions” button. Then remove “Everyone” from the “Group or user names” section.
It it very important that the “Everyone” group does not have permissions to your shared folder because this would include giving access to unauthorized users. This is one way that Malware can spread because it is often programmed to look for network shares on your system. After removing the “Everyone” group, your share permissions should be empty like in the image below.
At this point, you can add “Domain Computers” and “Domain Users” to the share permissions. Both the “Domain Computers” and “Domain Users” groups should have read permissions only. Reference the image below.
Now click “Apply” and “Okay” until you are back at the properties page. From there, click the “Security” tab and we will make some changes here. Reference the image below to locate the “Security” tab.
From within the “Security” tab, make sure that the “Everyone” group is NOT listed under the “Groups or user names” section. If “Everyone” is listed, you need to remove it from this section, as well.
Now click “Edit” and add both “Domain Computers” and “Domain Users” to the “Groups or user names” section. Also, make sure that “Read and Execute”, “List folder contents” and “Read” are the only permissions checked for both “Domain Computers” and “Domain Users”. Reference the image below if you need help.
When your permissions look like the picture above, you can click “Apply” and then “Okay” and then go back to the “Sharing” tab. Take notice the new Network Path:
\\WIN-DC-SERVER\PowerShell_Scripts
This indicates that the folder can now be accessed by other computers in the Network. Let’s test that out on a Windows 10 Client computer that is joined to our Active Directory domain.
I’ll log into a regular, non-administrator account named “Billy Bob”. If we configured the share folder correctly, then Billy Bob should have access to the “\\WIN-DC-SERVER\PowerShell_Scripts” folder from his own domain computer (the Windows 10 Client). Reference the images below to see if it worked.
Notice in the picture above that you can access a Network Share Folder by typing the \\hostname\folder information into the Search Bar at the bottom.
From the image above, you can see that we successfully configured our share folder, and Billy Bob has access to it from his own domain computer. So let’s move onto Step Two of deploying a PowerShell script in our Active Directory environment.
Step 2. Create Your PowerShell Script(s)
The next step is to make a really cool PowerShell script. I have the perfect PowerShell script and it’s called “deviceName.ps1”. This script helps a non-technical user find their computer name in the case that an IT Help Desk employee is requesting it for troubleshooting purposes. Some users may have issues finding their computer name or IP address, and this can drastically slow down the remote-troubleshooting process.
My PowerShell script actually displays the user’s computer name as a pop-up alert message so that the user doesn’t have to search for it. All the user has to do is click the program located on their desktop and a window will pop-up, displaying their computer name. The user might have to press “Y” to confirm the PowerShell command, but that is okay. The IT Help Desk will most likely be able to instruct the user on how to press the “Y” key (hopefully).
Reference the picture below to see an example of the “deviceName.ps1” script being executed.
Creating The PowerShell Script
Open up Notepad and copy the PowerShell script from the image, below. When you are done, save the file to the Desktop as “deviceName.ps1”. This will save your file as a PowerShell script. Remember that PowerShell scripts have a “.ps1” file extension. Reference the image below.
The lines that begin with “#” are comments and they will not effect what your script does. It is good practice to comment out a few lines in your code and include information about the script itself (Date, Author, Script Language, Purpose, etc.)
The only two lines in our script that are functional are the last two lines:
Add-Type -AssemblyName PresentationFramework
[System.Windows.MessageBox]::Show($env:computername)
I encourage you to do your own research on what these two lines of PowerShell code do. I will, however, tell you that the “$env:computername” is an environment variable that holds the computer name. That is why you interact with this variable in our script.
Make sure you test your script by right-clicking on the script and choosing “Run with PowerShell”. Below is an example of the code working and displaying the computer name as a pop-up window.
Once you ensure your “deviceName.ps1” script runs successfully, you need to move it to your “C:\IT\PowerShell_Scripts” share folder so that all domain users have access to it. Reference the image below for help.
Creating A PowerShell Script For Your PowerShell Script
Now we need to create another script that checks if the “deviceName.ps1” program is already located on the user’s desktop. The new script will copy the script over from the share folder if it is not present on the user’s desktop. This is actually easier than you think, so let’s begin. Go ahead and open up Notepad and copy the script you see below.
Once you are done copying the above script, save it as “deviceName_deploy.ps1” and save it to your “C:\IT\PowerShell_Scripts” folder.
I highly encourage you to research what this code does because the syntax is fairly simple. Basically, the script checks if a file exists, and if the file does not exist, then the script will copy the file to your desktop. This is how we will deploy our script onto every user’s desktop when they login.
Now we will test our script to ensure it works. First, ensure that you do not have a copy of “deviceName.ps1” on your desktop. At this point, both of the PowerShell scripts we have written should ONLY be saved onto the “C:\IT\PowerShell_Scripts” folder. Once you ensure the script is not on your desktop, search for the “\\WIN-DC-SERVER\PowerShell_Scripts” folder and open it.
Inside the folder, locate the “deviceName_deploy.ps1” file and right click it and choose “Run with PowerShell”. If you are prompted to confirm you want to run the command, choose “Y” for yes. If you did everything correctly, your script should now run and copy the “deviceName.ps1” program onto your desktop. Reference the images below if you need help.
The script works! The last step is to make a Group Policy Object in Active Directory that will automatically run our deployment script whenever users login.
Step 3. Deploying Our Script With An Active Directory Group Policy Object
We’ve reached the last step of deploying the PowerShell script in our Active Directory domain. Open the “Group Policy Management” tool. Reference the image below.
Under “Domains” right click on your domain (mine is mydomain.com) and choose the option to “Create a GPO in this domain, and Link it here…” Then you will need to name your Group Policy Object. It is helpful to name your Group Policy Objects by what their purpose is in your domain. That being said, I am naming my Group Policy Object “PowerShell Script Deployment: deviceName.ps1”. Reference the images below for instruction.
We now need to edit our Group Policy Object. Right click on the group policy object that we just made and choose the “Edit” option. The “Group Policy Management Editor” tool will appear, and this is where we will edit our Group Policy Object. The Group Policy Management Editor can be seen in the image below.
From within the editor, you need to locate the correct setting for Windows Logon/Logoff scripts. To do so, follow the path below:
User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff)
We want our script to execute whenever a domain user logs on to their computer, so we will double click on the the “Logon” option. The “Logon Properties” window will popup, and from here you need to click the “PowerShell Scripts” tab at the top. I am using a PowerShell script, but you can instruct Active Directory to run other scripts, like batch files for example. Reference the image below for visual direction.
Click the “Add” button, and then click “Browse”. Reference the image below.
From here, a file selection window will appear. Copy and paste the “deviceName_deploy.ps1” file from “\\WIN-DC-SERVER\PowerShell_Scripts” into this location. DO NOT change the path, this is the path of the Group Policy Object. Reference the image below for visual instruction.
After copying the script to this location, click “Open” and the file selection window will close. then “Apply” the changes in the next window and click “Okay”. You should see your script added to the PowerShell scripts list in the “Logon Properties” window. Reference the image below for visual instruction.
You have now finished editing the Group Policy Object and can exit out of the “Group Policy Management Editor” tool. However, we now need to go back into the Group Policy Management tool and check one last setting.
From within the Group Policy Management tool, click on your newly created Group Policy Object (the powershell script deployment) and check the section that says “Security Filtering”. This section should have the “Authenticated Users” group listed, that way all users who authenticate into our system will be effected by the Group Policy Object. Reference the image below for visual instruction.
We are almost done! Now we need to force update all the Group Policy Objects in our domain. You can do this by opening PowerShell and running the following command:
gpupdate /force
Group Policy Object updates take about 90–120 minutes to take effect. By running the above command, the Group Policy Objects will take effect, immediately. Reference the image below.
Step 4. Restart Your Computer
That’s right, we are done. All we have to do now is restart our computer and make sure our script deploys within our Active Directory domain. Before you restart, make sure “deviceName.ps1” is not located on your desktop. Both PowerShell scripts should only be located in the Network Share folder.
Now restart your computer and when you log back in, you should have a copy of the “deviceName.ps1” file located on your desktop. You should also try running the file to make sure everything works. Reference the image below.
It worked! The script was successfully copied onto my desktop when I logged into my domain controller. I also tried running the script, and it was successful.
Lastly, we need to log into a different domain computer with a different user account to test whether the file is copied to their desktop, as well. To do this, we will log into a domain user account that has never logged into this domain. This user account we will log into is: (agaliano). Reference the images below.
Wow, it worked! Our PowerShell script is deployed onto each user’s desktop when they log into the domain. Now the IT Help Desk has a useful script they can use to speed up troubleshooting.
You should be proud of yourself. We learned a lot, and now you know how to deploy software to an Active Directory environment. We talked a little about the following concepts: Active Directory Administration, PowerShell Scripting, File System Security
Thank you for learning. Please press the “like” button on this article and share this article with others that are trying to learn and work in the Information Technology industry.
If you do not already have one, you should truly consider creating an Active Directory Lab environment. There are trillions of resources that can help you create an Active Directory Lab environment. Also, check the links below for resources that can help you learn more Active Directory Administration.
Links:
https://medium.com/@dante.falls/active-directory-home-lab-setup-88afee6fbaaf
https://medium.com/@dante.falls/active-directory-for-beginners-ed71fa414769
https://activedirectorypro.com/deploy-software-exe-using-group-policy-part-2/#step-2
