Hope you have an excellent time in Amsterdam. Wish I was there.
I recently re-experienced a very annoying behavior in Powershell User Logon Scripts.
I needed to use a GPO for fixing several issues on registrykeys, local files and some other small tasks on a bunch of machines. The easiest way for this task was to deploy a Group Policy with a User Logon Script (the registrykey is in the logged on users hive).
All worked fine for most users, but our servicedesk started complaining about very long logon times. It turned out they loaded their Powershell profile with all Active Directory and MSOnline modules, including a connection setup to the tenent and a session import, resulting in Powershell loading all these very usefull tools in the logon process just to set my minor tasks and killing off the session after successfully applying the settings.
Of course it’s better practice to load what you need from the console or a script importing the nessesary modules, but administrators will never have control over the $profile of all users. Hense I’m still not able to understand, why the Powershell Script option in Group Policies in general are not run with a hardcoded -NoProfile in stead of the opposite.
Of course I can run an ordinary script, calling Powershell with the -NoProfile switch, but that is a bit altmodish.
Does anyone know, why Powershell Scripts in Group Policies was implemented like this?