Running PowerShell Startup (Logon) Scripts Using GPO

Windows Group Policy allows you to run various script files at a computer startup/shutdown or during user logon/logoff. You can use GPOs not only to run classic batch logon scripts on domain computers (.bat, .cmd, .vbs), but also to execute PowerShell scripts (.ps1) during Startup/Shutdown/Logon/Logoff.

In modern versions of Windows, you can directly run logon/logoff PowerShell scripts from a GPO editor (previously it was necessary to call the .ps1 file from the .bat batch file as a parameter of the powershell.exe executable).

Run the Domain Group Policy Management console (GPMC.msc), create a new policy (GPO), and assign it to the target Active Directory container (OU) with users or computers (you can use WMI GPO filters for fine policy targeting). Switch to policy Edit mode.

You must select a GPO section to run the PowerShell script, depending on when you want to execute your PS1 script:

• If you want to run a PS script when a user logon (logoff) to a computer (to configure the user’s environment settings, or programs: for example, you want to automatically generate an Outlook signature based on the AD user properties, customize screensaver or Start screen settings), you need to go to the GPO section: User Configuration -> Policies -> Windows Settings -> Scripts (Logon / Logoff);
• If you want to run the PowerShell script at a computer startup (to disable legacy protocols: NetBIOS and LLMNR, SMBv1, configure computer security settings, etc.) or prior to the computer shutdown, you need to go to the GPO section with the computer settings: Computer Configuration -> Policies -> Windows Settings -> Scripts (Startup / Shutdown).

How to Run PowerShell Scripts on Windows Startup with Group Policy?

Suppose, we have to run the PowerShell script at a computer startup. Select the Startup policy, and go to the PowerShell Scripts tab.

Now you need to copy the file with your PowerShell script to the domain controller. Copy your ps1 file to the Netlogon directory on the domain controller (for example, \\woshub.com\netlogon).

Since we configure the Startup PowerShell script, you need to check the NTFS “Read&Execute” permissions for the Domain Computers and/or Authenticated Users groups in the ps1 file permissions.

Now click Add and specify the UNC path to your ps1 script file in Netlogon.

If you run multiple PowerShell scripts through a GPO, you can control the order in which the scripts are executed using the Up/Down buttons.

To correctly run PowerShell scripts during computer startup, you need to configure the delay time before scripts launch using the policy in the Computer Configuration -> Administrative Templates -> System -> Group Policy section. Enable the “Configure Logon Script Delay” policy and specify a delay in minutes before starting the logon scripts (sufficient to complete the initialization and load all necessary services). Usually, it is enough to put here 1 or 2 minutes.

On Windows Server 2012R2 and Windows 8.1 and newer, PowerShell scripts in GPO are run from the NetLogon directory in the Bypass mode. This means that PowerShell Script Execution Policy settings are ignored. If you want to run a script from a different shared folder, or if you still have Windows 7 or Windows Server 2008R2 clients on your network, you need to configure the PowerShell script execution policy.

By default, Windows security settings do not allow running PowerShell scripts. The current value of the PowerShell script execution policy setting can be obtained using the Get-ExecutionPolicy cmdlet. If the policy is not configured, the command will return Restricted (any scripts are blocked). The security settings for running the PowerShell script can be configured via the “Turn On Script Execution” policy (in the GPO Computer Configuration section -> Administrative Templates -> Windows Components -> Windows PowerShell). Possible policy values:

• Allow only signed scripts (AllSigned) – you can run only signed PowerShell scripts (“How to digitally sign a PowerShell script?”) — this is the best option from a security perspective;
• Allow local scripts and remote signed scripts (RemoteSigned) – you can run any local and signed remote scripts;
• Allow all scripts (unrestricted) – the most insecure option, because allows running any PowerShell scripts.

If not one of the settings of the PowerShell scripts execution policy is suitable for you, you can run PowerShell scripts in the Bypass mode (scripts are not blocked, and warnings do not appear).

To do this, run the PowerShell script from the Startup -> Scripts section. In this section, you can run your PS1 script by calling the powershell.exe executable (similar to the script described in the article). Set:

• Script Name: %windir%\System32\WindowsPowerShell\v1.0\powershell.exe
• Script Parameters: -Noninteractive -ExecutionPolicy Bypass -Noprofile -file %~dp0MyPSScript.ps1

In this case, you are forced to allow any (even untrusted) PowerShell script to run using the Bypass parameter.

Reboot your computer to update the GPO settings and check that your PowerShell script runs after Windows boots.

Run Windows PowerShell Script at User Logon/Logoff

Let’s look at how to automatically run a PowerShell script when a user logs into (or logs out) Windows.

If you need to run the script not at computer startup, but after the user logs into Windows (for each user on the computer), you need to link the GPO to the Active Directory OU with users. In this case, the PowerShell script needs to be configured in the User Configuration section of your GPO.

In this example, I will use a simple PowerShell script that writes the user’s login time to a text log file.

1. Copy your PowerShell script file to the\\woshub.com\NETLOGON\ folder on the Active Directory domain controller;
2. Go to User Configuration -> Policies -> Windows Settings -> Scripts -> Logon;
3. Go to the PowerShell Scripts tab and add your PS1 script file (use the UNC path, for example \\woshub.com\NETLOGON\UserLog.ps1 );
4. Re-login the user on the target computer;
5. Your PowerShell script will be launched automatically via GPO when the user logs in;
6. You can verify that the user logon script was executed successfully by the Event ID 5018u nder Microsoft-Windows-GroupPolicy/Operational section of Event Viewer:

   Completed Logon script for woshub\jsmith in 11 seconds.

   

If you want the user not to be able to access his desktop until the script is finished, you must enable the GPO parameter Run logon scripts synchronously (Computer Configuration –> Administrative Templates -> System -> Logon). In this case, the explorer.exe process will not start until all policies and logon scripts have been completed (this increases the user logon time!).

Note that the script runs with the current user permissions. If the user has administrative privileges on the computer and the User Account Control (UAC) settings are enabled, the PowerShell script cannot make changes that require elevated privileges.

In order to run PowerShell logon scripts with elevated user permissions, you can use the Scheduler Tasks.

1. Create a new Task Scheduler job under User Configuration -> Preferences -> Control Panel Settings -> Scheduled Task;
2. On the General tab, specify that the task will be started on behalf of the current user %LogonDomain%\%LogonUser and enable the Run with highest privileges option;
3. On the Trigger tab, specify that the task should be started At log on;
4. Specify the path to your PowerShell script file on the Actions tab:

Action: Start a program
Program/Script: C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
Add Arguments (optional): -ExecutionPolicy Bypass -command "& \\woshub.com\Netlogon\Your_PS_Script.ps1"

Such a PowerShell script will run as an administrator (if the domain user is added to the local Administrators group).

Some logon scripts need to be run for each user only once at the first login to the computer (initialization of the working environment, copying folders or configuration files, creating shortcuts, etc.). Here is a simple trick that allows you to run a script only once using GPO.