Forum Discussion
MicrosoftCannot dot-source this command because it was defined in a different language mode.
You may or may not have the capacity to fix this depending on the cause.
If the cause is linked back to domain group policy or MDM (such as InTune) policy, it may get to the stage where you need to ask your organisational administrators for assistance.
But first, you need to be able to prove the cause or they won't listen to you.
If you take a look in Event Viewer under Applications and Services Logs\Microsoft\Windows\AppLocker\MSI and Script, perform a search for __PS.
You will find an entry, it's just a question of whether it's an error type (which will cause ConstrainedLanguage mode to be applied to applicable users), or warning/information (meaning AppLocker is not the cause of ConstrainedLanguage mode.)
In this example, I've staged a policy-based error so you have an example to refer to:
This is proof of the impact but not the cause.
I don't work with InTune but you can use the following process to check if the source of the configuration is coming from group policy:
- Open an administrative command prompt;
- Run the following (being sure to use a directory relevant to your system);
gpresult /h c:\data\rsop.html /scope computer /f
- Open the file (c:\data\rsop.html in my example) and check to see if a policy is being enforced (Enforced = True) as the example below shows:
In my contrived example, you can see on the right hand-side the name of the policy impacting my client is "Clients - Forums".
The end result of this policy is that when I launch PowerShell, I am put into ConstrainedLanguage mode.
Armed with these two pieces of information, you can ask your organisational administrators for assistance. But have a read of the next section before you do.
Additional information
This is only relevant if your policy is coming from group policy (GPO), not an MDM (i.e. InTune) - which may or may not be the same (I have no idea.)
With group policy, the AppLocker client-side extension is a bit different from most others (Windows Firewall is another one similar to AppLocker) insofar as it merges rules (not the enforcement settings though) from multiple group policy objects, and this behaviour can work to your advantage - if you have local administration rights on your computer.
You can see this behaviour shown in my example above, where that the enforcement settings come from the GPO named "Clients - Forums" but the rules come from a GPO named "Clients - Default".
What this means is you may be able to add an "allow" rule via local group policy which will get you out of ConstrainedLanguage mode.
Steps:
- Open an administrative command prompt;
- Run gpedit.msc;
- Navigate to Computer Configuration\Windows Settings\Security Settings\Application Control Policies\AppLocker\Script Rules;
- Right-click the Script Rules node and choose Create New Rule...;
- Click Next on the Before You Begin welcome page;
- On the Permissions page, it defaults to Everyone. This is where you need to show some responsibility and change Everyone to your own account (or something relatively granular). Leaving Everyone or other far-reaching security principals in place here would be irresponsible and may cause earn you the ire of policy administrators, so don't abuse the trust here:
- On the Conditions page, choose Path (we're going to take the easy option here);
- On the Path page, you're going to use the value from the Event Log error show above, being sure to truncate the file name after the static prefix and terminating the path with a wildcard as shown below:
- Click the Create button;
- You will probably get the following dialog pop up. Be sure to answer No as there is no reason to create the default rules, which again may only irk the policy administrators;
- You should now see a single rule targeted to your account as per the example below:
If you close the group policy editor (as this completes the process), you should find the new rule applies within seconds.
If you open a new PowerShell session now, you should find that in Event Viewer, you now have an informational event rather than an error when searching on the same __PS value as above:
And when you open a new PowerShell session and check the value of $ExecutionContext.SessionState.LanguageMode, it should now show as FullLanguage.
But if you're not using group policy or an aligned MDM then your issue may be altogether different.
Cheers,
Lain
MicrosoftLainRobertson - Thank you so much for the detailed explanation. I will look into this and see if that unblocks me and will update.
- RaviKiranS
LainRobertson - I verified the steps/details you had provided but unfortunately, I don't see any error eventlog which blocking the __PS* policy just like you shown.
Also, gpresult doesn't even list the windows/security policies
What can I do here next?
I'm rather surprised to hear there were no relevant events within the AppLocker\MSI and Script node as that's a common reporting point for both AppLocker and Windows Defender Application Control (WDAC). That also leaves me a little short on other ideas, since it sounds like it's being set outside of policy.
In no particular order, here's some thoughts:
- ConstrainedLanguage mode is the only language option on ARM/Windows RT platforms:
about Language Modes - PowerShell | Microsoft Learn - Check any relevant PowerShell profiles to ensure ConstrainedLanguage hasn't been assigned somewhere within:
about Profiles - PowerShell | Microsoft Learn - Ensure your virus scanner isn't perhaps preventing those __PSScript .ps1 and .psm1 files from executing;
- Finally, I've quickly put together a "hack" script that collects some meaningful information in relation to WDAC. It isn't very granular as it's only intended to help identify which areas could use further exploration.
Get-WDACInfo.ps1
#region Preamble. # We're only interesting in testing against Windows 10 or later. $NTBuildString = (Get-CimInstance -ClassName Win32_OperatingSystem -Property Version -ErrorAction:Stop).Version; $NTBuildParts = $NTBuildString.Split("."); $NTMajorVersion = $NTBuildParts[0].ToInt32($null); if ($NTMajorVersion -lt 10) { throw "This script can only be run on Windows 10 or later."; } # Since we're already checking versions, see if we're on Windows 10 1903 or later. $IsLegacy = $false; if (($NTMajorVersion -eq 10) -and ((Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" -Name "ReleaseId").ReleaseId.ToInt32($null) -lt 1903)) { $IsLegacy = $true; } #endregion #region AppLocker policy check. # See if AppLocker group policy enforcement has been applied. Write-Warning -Message "AppLocker policy enforcement."; [PSCustomObject] @{ IsAppLockerEXEEnforced = (1 -eq (Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe" -Name "EnforcementMode" -ErrorAction:SilentlyContinue).EnforcementMode); IsAppLockerScriptEnforced = (1 -eq (Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Script" -Name "EnforcementMode" -ErrorAction:SilentlyContinue).EnforcementMode); } | Out-Default; #endregion #region CI Policy registry data. Write-Warning -Message "CI Policy registry data."; Get-ChildItem -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CI\" -Recurse -ErrorAction:SilentlyContinue | Where-Object { ($_.ValueCount -gt 0) -or ($_.SubKeyCount -gt 0) } | Out-Default; #endregion #region WDAC policy file(s). Write-Warning -Message "WDAC policy file detection."; if ($IsLegacy) { [PSCustomObject] @{ IsCIDefined = (Test-Path -Path "C:\Windows\System32\CodeIntegrity\SiPolicy.p7b" -ErrorAction:SilentlyContinue); IsCIApplied = IsCIDefined; } | Out-Default; } else { [PSCustomObject] @{ IsCIDefined = $null -ne (Get-ChildItem -Name -Path "C:\Windows\System32\CodeIntegrity\CiPolicies\*" -Include "*.cip" -Recurse -ErrorAction:SilentlyContinue); IsCIApplied = $null -ne (Get-ChildItem -Name -Path "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\*" -Include "*.cip" -ErrorAction:SilentlyContinue); } | Out-Default; } #endregion #region WDAC Event Log stats. Write-Warning -Message "Relevant Event Log stats."; $LogNames = @( "Microsoft-Windows-AppLocker/MSI and Script", "Microsoft-Windows-CodeIntegrity/Operational" ); $LogNames | ForEach-Object { Get-WinEvent -ListLog $_ | Select-Object -Property LogMode, IsEnabled, LogName, RecordCount; } | Out-Default; #endregionFrom which an example of the output is below.
If either of the settings I've boxed in green have a value of True, policy probably is the cause even if you're not seeing relevant errors in the event logs. If they're both False as mine are, then my best guess is the PowerShell profiles or session configuration file (though I don't see such files commonly used.)
While I'm quite familiar with AppLocker, I'm quite unfamiliar with WDAC, meaning you might also get some mileage on this issue through asking in an InTune forum, too.
The option you'd be asking them about is option 11 from the following table, where if it's coming back with a value of "enabled", then it is not the cause of your problem, where "disabled" would mean it is.
Cheers,
Lain
LainRobertson Thx for this intense work. It helped me a lot!
Just a few things to mention:
- changes to AppLocker Rules do not apply instantly but only on User-Logon or restart of all explorer.exe-instances.
- If AppLocker rules are not set by GPOs but only local, they can be removed by right-click on Applocker in gpedit.msc and select 'cleanup policy'
- besides there is a bug in windows 11 which makes AppLocker keep the cache after deleting the rules so you have to delete all files within: '%windir%\System32\AppLocker\', '%windir%\System32\GroupPolicy' and '%windir%\System32\GroupPolicyUsers'
- ConstrainedLanguage mode is the only language option on ARM/Windows RT platforms:
