Using Group Policy to Deploy a Windows PowerShell Logon Script


Summary: The easiest way to deploy a Windows PowerShell script to users is to create a Group Policy logon script.


Microsoft Scripting Guy Ed Wilson here. Oh…my eyes feel like they are glued to my eyelids. I am not a night owl, unlike the female who inhabits the house in Charlotte, who seems to enjoy howling at the moon on a regular basis. Anyway, I do like to read, and I found a fascinating book about Shakespeare for American readers at the library yesterday, and as soon as I began reading it, I felt compelled to finish it. Now it seems I must pay for my indulgence.

I received an email from one of my friends in Monterrey, Mexico, who was asking about running a script on his workstations to empty the recycle bin. I told him the best way to do this would be to configure either a logon or logoff script via Group Policy. I was in Monterrey several years ago and have taught VBScript, WMI, and Windows PowerShell workshops down there. It is a great town with excellent cuisine. Whenever I think of Monterrey, I am reminded of the Cerro de la Silla, which is shown in this photo I took during my last visit.

Photo Ed took of Cerro de la Silla

I woke up this morning with a plan. I wanted to configure the Get-ProcessStartUpTimes.ps1 script I wrote last week in a Weekend Scripter article to run on every computer on my network each time a user logs onto the network. In addition, because the Windows Search index service that exists in Windows 7 does not exist on servers, I need to ensure that the script does not run when someone logs onto a server.

To do this, I decided to create a new Group Policy object (GPO) and link it to my domain in my forest. In the Group Policy Management Editor, I right-click the domain, and then click Create a GPO in this domain. This is shown in the following image.

Image of start of process to create GPO

Right-clicking the newly created GPO in the Group Policy Management Console and clicking Edit opens the Group Policy Management Editor, which is shown in the following image. Because I am interested in tracking not only processes that start after the user logs onto the computer but also processes that start before the logon screen, I configure a logon script for the user. There are startup and shutdown scripts that can be configured in Group Policy that are assigned at the computer configuration level, but they would not be the best place to obtain the information I’m looking for. To set a user logon script, open the User Configuration node of the Group Policy Editor, click Windows Settings and then click Scripts (Logon/Logoff).

Image of Scripts (Logon/Logoff) window

I double-click Logon in the right side of the pane, and click the PowerShell Scripts tab as shown in the following image.

Image of Logon Properties

From here, I click Add, and click Browse. The Add a Script dialog appears. The Browse button opens a Windows Explorer window that is centered on the SysVol share for my domain. The cool thing is this is a great way to copy the script to the SysVol share, and I drag and drop my Get-ProcessStartUpTimes.ps1 script into the Logon script folder.

Image of dropping script into Logon script folder

Because I do not want the script to run on my servers, I need to create a WMI filter. To do this, I right-click the WMI Filters node in the Group Policy Management Console and click New. The dialog appears that is shown in the following image. After adding my WMI query (tested using the Get-WMIObject cmdlet), I click Save.

Image of creating WMI filter

The last thing I do is go to the AuditProcessStartUp GPO that I had created, and select the FilterWorkstation WMI filter I created.

Image of selecting the WMI filter


Well, that is it. The GPO is now created, and I need to allow it to replicate among my various domain controllers. Tomorrow, I will create a Windows PowerShell script to connect to the network share and to parse the process objects.

We invite you to follow us on Twitter or Facebook. If you have any questions, send email to us at, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.


Ed Wilson and Craig Liebendorfer, Scripting Guys


Discussion is closed. Login to edit/delete existing comments.

  • Josh Smith 0

    I know this is an older article, but I found it interesting. Wanted to note that the “Image of Logon Properties” image is broken.

  • James Robinson 0

    Powershell execution policy needs to be set on the end clients to be at least Remote-Signed. This can be included in your GPO.
    Otherwise, you can use a batch script that calls the Powershell script using the -ExecutionPolicy Bypass switch to enable only this one script to be run outside of the normal execution policy.
    A good explanation is availble here:

    • J S 0

      At least these days, gpscript runs powershell with execution policy bypass, according to command line process auditing in the security log (

      New Process Name: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
      Creator Process Name: C:\Windows\System32\gpscript.exe
      Process Command Line: -ExecutionPolicy ByPass -File popup.ps1

      Although in my case, I had to enable user loop processing, since the group policy wasn’t in the same ou as the users. (admintemp\system\group policy\configure user group policy loopback processing mode\merge)

Feedback usabilla icon