Utilisation de la méthode PowerShell pour obtenir l'appartenance à un groupe et à un utilisateur d'un ordinateur local à partir de la base de données des utilisateurs. Vérifier si l'utilisateur est membre du groupe local~. voici une logique PowerShell conditionnelle qui vous aidera.
Il suffit de...
-
Définir les noms des groupes locaux dont l'appartenance doit être vérifiée au sein du groupe $groups = valeurs des variables
- Chaque valeur est placée entre guillemets et séparée par une virgule.
-
Régler le Switch pour qu'elles correspondent aux valeurs définies dans le $groups maintien de la variable entourée d'un double guillemets
- Chacune des valeurs de la logique d'expression doit pointer vers le fichier d'importation LGPO corrélé.
La normalisation des noms de groupes locaux et de la structure des dossiers d'importation des politiques locales devrait permettre de simplifier la logique et de l'adapter facilement à vos besoins. Cela permettra au moins de s'occuper de la partie triviale de la logique dont vous avez besoin pour aller dans la bonne direction afin d'obtenir une solution fonctionnelle.
Il est évident que vous devez d'abord tester cette méthode et ajuster la logique ou utiliser une autre variante qui fonctionnera le mieux dans votre cas, mais cette méthode devrait au moins permettre de répondre aux besoins de votre politique informatique locale.
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;
}
}
}
}};
Exécution en tant que connexion script
Puisque vous utilisez Windows 10 Enterprise et que vous avez besoin que cela s'exécute en tant que script de connexion, il est facile de configurer un script de connexion qui s'exécutera pour chaque utilisateur qui se connecte à la machine à l'aide d'un paramètre de stratégie de groupe local.
Je décrirai ci-dessous une façon d'exécuter les scripts de connexion via la stratégie de groupe locale. Cependant, je ne suis pas certain que la politique LGPO appliquée l'affectera, alors testez et voyez comment cela se passe.
Il pourrait y avoir des problèmes avec ceci après le redémarrage et l'application d'une politique LGPO . Si c'est le cas, vous pourriez también mettre les configurations de connexion script dans les définitions de politiques LGPO également. Cela permettra de s'assurer que les configurations script sont réappliquées après la mise à jour des politiques appliquées par LGPO.
Vous devez tester à la fois redémarrages, déconnexions et connexions sans redémarrage pour voir ce qu'il faut faire.
- Exécuter
gpedit.msc et naviguer en conséquence via User Configuration Windows Settings Scripts | et ensuite double-clic Logon . Sélectionnez l'option PowerShell Scripts et puis appuyez sur le bouton " Ajouter "et tapez ensuite le numéro de téléphone de la personne à contacter. chemin complet vers le script de connexion script. dans l'espace Script Name et de brancher -ExecutionPolicy Bypass dans le Script Parameters champ.
![enter image description here]()
![enter image description here]()
Ressources d'appui
Un script d'altération-démarrage (Bonus OP Material)
Le PO a déterminé que LGPO.exe n'a pas pu rester sur la (les) machine(s) où il a été exécuté, de sorte que la logique s'est adaptée :
- Vérifier si l'utilisateur fait partie du groupe correspondant
- Sous
C:\Windows\System32\GroupPolicyUsers créer un dossier dont le nom correspond au SID du compte
- Copier manuellement
Registry.pol vers cet emplacement Emplacements créés par le SID
Il s'avère que la configuration d'un Logon Script n'exécutera pas le script PowerShell script avec des privilèges élevés. Cependant, en l'exécutant en tant que Startup Script sous Computer Configurations/Windows Settings/Script/Startup fonctionne bien.
Il y a une mise en garde pour les profils d'utilisateur nouvellement créés par machine avec une stratégie applicable, les stratégies pour l'utilisateur ne seront pas effectives tant qu'un redémarrage n'aura pas eu lieu après la création du profil de compte.
