Forum Discussion
Running PowerShell scripts using Group Policy
Hi,
I need a PowerShell script to run each time one particular domain user logs in. However, the script does not appear to run at all even though the group policy is applied to the computer.
The script is configured at User Configuration > Policies > Administrative Templates > System > Logon:
Run these programs at user logon:
powershell.exe -ExecutionPolicy Bypass -WindowStyle Minimized -File "C:\ProgramData\Some Folder\MyScript.ps1"
The script outputs a log but the log has not changed since the script was last ran manually a few days ago. I have not seen the script execute automatically at logon.
Thank you!
Rob
Hi, Rob.
It may just be the phrasing, but you mention that you have the group policy applying to a computer, not the user. If that is indeed the case then that is not going to work.
The group policy would need to target the user, not the computer.
Superficially, this sounds more like a group policy question rather than a PowerShell question. You may want to check for more detailed group policy information under the GroupPolicy node within Event Viewer, under the Application and Services\Microsoft\Windows branch.
Cheers,
Lain
Hi Lain,
Thank you for your reply!
As I stated above, this script needs to run every time one particular user logs in. Not every user and not the computer itself.
I tried to find a Group Policy community here but I cannot find one. Honestly, I'm not sure exactly where the problem lies. The script can be executed from the command line but nothing happens if GPO is expected to run the script.
The only thing I have found so far in searching is that it's recommended to use the full path to powershell.exe in your command line. I'm attempting to do this now but I am having issues remoting into the affected client to check the result. I will look at Event Viewer as you suggested above.
Thank you,
RobHey, Rob.
I don't want to get into group policy too deeply as it's off-topic for this particular forum, but in short, if you're trying to target a user - be that a single user or ten thousand, the group policy needs to target their Active Directory user object, not the computer.
The basic rules of thumb for group policy are:
- A single group policy object (GPO) should only target a user or computer, not both;
- The opposing half should be disabled, meaning if you're changing settings in the Computer Configuration node then the User Configuration settings section should be disabled;
- While the GPO starts off by default being scoped to the Authenticated Users security group, it's common to change that scope to target a more specific group of computers or users, and it's this step you want to be leveraging to target your user.
There is a special exception to these basic Microsoft guidelines called "loopback processing" but that's too deep to get into here on the PowerShell forums.
As a quick demonstration of the above basic guidelines, here's some screenshots.
Organisational unit structure design
Here, you can see Active Directory computer objects are being kept separate to user objects, as is recommended. You can also see GPOs specific to each object type on each, which correlates to point 1 above.
Disable the unused section within the GPO
From the picture above, the "Client - Default" GPO targets computer objects meaning the User Configuration settings section should be disabled, which you can do from within the GPO editor as shown below:
Or from the Group Policy Management Console as shown below:
For GPOs targeting user objects, it's the same thing in reverse.
Scoping GPOs to specific groups, computers or users
As mentioned, GPOs begin their life scoped to the Authenticated Users group, as shown below (taken from the GPMC):
This next GPO has been altered to be scoped to a group named "Print Servers" which contains computer objects:
This next GPO targets specific computer objects individually:
Lastly, and this is the one of most interest to you, I'd say, this shows a GPO scoped specifically to me as an individual, which is what you mentioned is your scenario:
Putting this together
- You want a GPO where the Computer Configuration node is disabled;
- You want to scope the GPO to the specific user you're targeting, not the Authenticated Users group;
- You want to link the GPO to the organisational unit under which the specific user account you're targeting lives.
If you want to only execute this script when this specific user logs onto a specific computer, you'll need to get familiar with the loopback processing article I linked up top, and you'll also need some logic within the script to detect the targeted used. This is more complex than is worth covering here in a PowerShell forum.
With respect to the point about using the full path to PowerShell, generally, that's not needed as powershell.exe features in the system path. However, as is often the case, things can go wrong with such settings and so it doesn't hurt to use the full path to powershell.exe. But as I say, this isn't typically necessary either.
There are other considerations that do more directly relate to PowerShell such as shell environments, AppLocker and the constrained language mode (which funnily enough also relates to AppLocker despite impacting PowerShell functionality.)
But these are complex diversions that may not relate to your issue. For now, I'll just link constrained mode:
Alternative methods
Group policy preferences
You could also consider using a Scheduled Task group policy preference that launches at logon.
I'm a bit wary of this as there's been a long-standing bug with scheduled tasks defined in group policy preferences but it does remain as an option.
User account logon script
This might actually be your easiest option unless there's some reason it's unsuitable to your needs.
Summary
A script specified in the User Configuration of a GPO that is targeting a computer account will not work - excluding the loopback processing scenario.
The GPO needs to target the user account, not a computer account.
Computer scripts only execute during boot up.
User scripts only execute during logon from the Ctrl + Alt + Del screen (excludes unlocking - it needs to be logging on from scratch.)
It would also help to provide a useable example of your script as working in an interactive session doesn't always translate to working during computer start-ups, user logons, scheduled tasks, etc.
Cheers,
Lain
