Using the PowerShell method to get local computer user and group membership from the Check if user is a member of the local~ post, here's some conditional PowerShell logic that will help.
You only need to...
Set the local group names to check membership against within the $groups = variable values
- Enclose each value in a double quote and separate each by a comma
Set the Switch values to match the values set in the $groups variable keeping enclosed by double
quotes
- Each of the values expression logic should point to correlated LGPO import file
Standardizing the local group names, and the local policy import folder structure, should help keep the logic simplified and easy to scale up (or down) for your needs. This will at least take care of the trivial part of the logic you need to get going in the right direction to get a working solution.
Obviously, you should test this first and adjust the logic or use another variation of it that'll work best in your case, but this should handle the task accordingly for your local computer policy needs at a minimum.
PowerShell Script
$user = "$env:COMPUTERNAME\$env:USERNAME"
$groups = "User Policy 1","User Policy 2","User Policy 3"
$groups | % { Process {
If ( (Get-LocalGroupMember $_).Name -contains $user ) {
$group = $_;
switch ($group)
{
"User Policy 1"
{
##LGPO.exe /u path\registry.pol
Start-Process LGPO.exe "/u C:\Policies\User\UserPolicy1\registry.pol"
break;
}
"User Policy 2"
{
Start-Process LGPO.exe "/u C:\Policies\User\UserPolicy2\registry.pol"
break;
}
"User Policy 3"
{
Start-Process LGPO.exe "/u C:\Policies\User\UserPolicy3\registry.pol"
break;
}
}
}
}};
Running as a logon script
Since you are using Windows 10 Enterprise and you need this to run as a logon script, it's easy to setup a logon script that will run for every user that logs onto the machine using a local group policy setting.
I'll outline one way to run logon scripts via local group policy below. However, I'm not certain if the applied LGPO policy will affect it so test and see how it goes.
There could be trouble with this after rebooting and an LGPO policy is applied. If so, you could also put the logon script configurations into the LGPO policy definitions too. This will help ensure the logon script configurations are reapplied after LGPO applied policies update.
You should test both reboots, and logoffs and logons without a reboot to help see what it'll take.
- Run
gpedit.msc and then navigate accordingly via User Configuration | Windows Settings | Scripts | and then
double click Logon. Select the PowerShell Scripts tab and
then press the "Add" button and then type in the full path to
the logon script location in the Script Name field and plug in
-ExecutionPolicy Bypass into the Script Parameters field.
Supporting Resources
An Alteration—Startup Script (Bonus OP Material)
The OP determined that LGPO.exe could not stay on the machine(s) it was run so adjusted logic to:
- Check if the user is part of the corresponding group
- Under
C:\Windows\System32\GroupPolicyUsers create a folder
with the name matching the SID of the account
- Manually copy
Registry.pol to this location SID created locations
It turns out, configuring a Logon Script will not run the PowerShell script with elevated privileges. However, running it as a Startup Script under Computer Configurations/Windows Settings/Script/Startup works fine.
There is a caveat for newly created user profiles per machine with an applicable policy, the policies for the user will not be effective until a reboot occurs after the account profile is created.
