PowerShell Language Modes

Language Modes in Windows PowerShell essentially define which elements of the PowerShell language can be used in a PowerShell session. As you’ve already discovered, the different language modes are documented publicly here. Language modes are intended to be specified as part of a session configuration file when a new PowerShell session is launched on a system.

Another way of setting the language mode for a PowerShell session would be to use either DeviceGuard or AppLocker in enforced mode with PowerShell 5+ and WMF 5+ or (more easily) to simply make use of a system environment variable called “__PSLockDownPolicy” to configure it. The system environment variable could be controlled on managed PCs in a variety of ways including via Group Policy.

There are two things to keep in mind regarding the use of language modes and the “__PSLockDownPolicy” system variable.

The first is that both the restricted language mode and constrained language mode could very likely have an impact on any SCCM scripts that use PowerShell or with any remote PowerShell management that you may be performing against systems. If scripts contain any scripting elements or code elements from other languages, they will most likely be prevented from running as expected. At its most restrictive setting (restricted and no language), script blocks aren’t allowed and/or the only thing that can be executed are cmdlets without any language elements at all.

The second thing is that when setting the language mode via the system variable, it will apply to all sessions started on that system and can’t be easily overridden on a user-by-user basis or a session-by-session basis. This means that it will affect built-in security principals as well as local users and would certainly have an effect on not only SCCM scripts and remote PowerShell management but other things like setting task scheduler to run as System and kick off a script at a pre-defined time.

The moral of the story is that while enforcing the PowerShell language mode on systems in an environment can reduce the potential for PowerShell to be used as an attack vector in malware or other exploits, it can have a pretty big impact on managing those systems via PowerShell for the purposes of good, not evil.