Emplacement d'exécution du script de connexion Windows 10

Je cherche des informations sur les modifications qui auraient pu être apportées à la façon dont les scripts d'ouverture de session GPO sont exécutés dans Windows 10 par rapport à Windows 7.

J'ai un script d'ouverture de session (powershell) configuré via GPO pour Windows 7. Lors du test d'une image Windows 10, ce script semble d'abord être copié dans le dossier temporaire de mon profil local (c:usersmyaccountappdatalocaltemp ) avec une chaîne aléatoire pour un nom (dyyxi3ra.i2u.ps1) avant son exécution. C'est un problème parce que le logiciel de gestion que nous utilisons le bloque via la règle qui est mise en place. La règle est en place et vient de le découvrir sur mon image de test Windows 10 (7 bourdonne toujours).

Quelqu'un sait-il, est-ce un comportement attendu et s'agit-il d'un changement par rapport à Windows 7? Google n'a pas été utile, et TechNet était comme chercher une aiguille dans une botte de foin dont je ne suis pas sûr que la botte de foin existe encore.

Merci d'avance.

ETA: Cela semble être un comportement normal. À l'ouverture de session a la deuxième fois, j'ai reçu un message similaire indiquant qu'un script était bloqué et une chaîne aléatoire différente.ps1. Il essayait à nouveau de s'exécuter à partir du dossier temporaire du profil local.

Je vais tester en signant mon script, mais je dois d'abord mettre à jour mon certificat de signature de code. J'espère que le problème concerne la stratégie d'exécution et que cela résoudra le problème.

ETA2: Dans mes tests, il semble que chaque fois qu'un script stocké à distance est exécuté, il copie quelque chose (le script lui-même?) vers un fichier temporaire dans le dossier temp du profil local. Scripts d'ouverture de session inclus. Si quelqu'un pouvait me diriger vers une documentation à ce sujet, j'apprécierais.

ETA3 : Mise à jour sur les résultats obtenus jusqu'à présent...

Cela semble être un changement entre Powershell V4 et les versions antérieures et V5. J'ai installé WMF5 sur mon appareil Windows 7 et après cela, je peux dupliquer le même comportement que celui que je vois sur l'appareil Windows 10.

J'ai trouvé un article qui explique quelque chose de similaire à ce que je vois, mais ils utilisent AppLocker.

Https://www.sysadmins.lv/blog-en/powershell-50-and-applocker-when-security-doesnt-mean-security.aspx

Je pensais que Bit9 détectait peut-être le mode de langue powershell et le déclenchait, mais changer le mode de FullLanguage en ConstrainedLanguage ne semble pas faire de différence dans mon environnement.

Https://technet.microsoft.com/en-us/library/dn433292.aspx

Je ne sais pas si c'est déclenche n'importe quoi dans l'esprit de quiconque, mais l'invite de commande Powershell déclenche une notification Bit9, alors que Powershell not ne le fait pas. J'ai exécuté get-module dans les deux pour voir quels modules sont chargés et comparé cela entre les appareils. Au moins un des appareils ne charge aucun module au lancement, donc j'exclus un module comme étant le coupable. Quelle est la différence entre powershell.exe etSE qui pourraient provoquer le déclenchement d'une application de liste blanche d'application?