Ah bon ça fonctionne ça ?!
Et le PolicyExecution ne bloque pas le script ?
Je suis très étonné !
Ah bon ça fonctionne ça ?!
Et le PolicyExecution ne bloque pas le script ?
Je suis très étonné !
Effectivement comme tout script powershell, il y a la politique de sécurité qui s'applique.
Je ne suis pas calé sur ce domaine, je n'ai pas de problème sur mon poste.
Peut être faut il signer le script mais ça semble sortir de la question de départ non ?
RunOnce à des passes droits sur cette politique de sécurité ?![]()
Ce n'est pas un problème ça....
Il suffit de faire les bons tests et on traite tous les cas.
Lors de migrations de fermes TSE 2k3, où ActiveSetup n'existais pas, j'ai fais de superbes scripts justement pour récupérer et ré-appliquer des paramètres spécifique utilisateurs.
Qui en plus était propre à chaque user !
Donc lecture d'un coté avec SID associé et ré-écriture de l'autre avec création du profil si celui-ci était inexistant afin que tout soit totalement transparent pour l'UF.
Et donc j'ai traité tous ces cas de ruche déjà montés et autres et je n'ai eu aucun soucis à correctement tout appliqué.
Pour du traitement massif je préfère de loin cette méthode.
Maintenant je n'ai jamais de mettre un PS dans un ActiveSetup et je reste curieux sur l'executionpolicy.... On peux toujours rajouter le ByPass mais en ça m’étonne en terme de sécurité.
Edit : RunOnce je ne sais pas je ne l'utilise vraiment pas souvent....
Par contre scripts d'ouverture de session AD aucun soucis, c'est bypassé automatiquement, pas besoin de signé.
Parce que là après on rentre dans le lourd si on diot signé les scripts PS !
Si c'est des opérations simple rien n’empêche de lancer des vbs.
J'oubliai le cas des ruches corrompus, comment les as tu traités ?
Partager