Oct 02 2022 10:02 AM
Microsoft.PowerShell_profile.ps1: Cannot dot-source this command because it was defined in a different language mode. To invoke this command without importing its contents, omit the '.' operator.
I am getting this error when I open my PowerShell anywhere... I have few scripts present in my PS Profile, but this is failing with error, and I can't import, its blocking me to even set a property.
$Host.Name = 'Test'
InvalidOperation: Cannot set property. Property setting is supported only on core types in this language mode.
Can someone please help me to get rid of this issue. Thanks!
Oct 02 2022 05:35 PM
Hi, Ravi.
If you run the following command, does it show as FullLanguage or another value? (I'm guessing it may be ConstrainedLanguage.)
$ExecutionContext.SessionState.LanguageMode
Incidentally, Name is a read-only attribute on $Host, meaning that won't work anyway.
If you were looking to change the windows title, you need to change $Host.UI.RawUI.WindowTitle:
$Host.UI.RawUI.WindowTitle = "Foo";
Cheers,
Lain
Oct 03 2022 09:59 AM
@LainRobertson - Yes, after some research, I also found that. It's in ConstrainedLanguage mode and not in FullLanguage. I am unable to change it to FullLanguage mode. Based on online articles, this will be temporary for the current session but for me it's everywhere and I am unable to change it.
Can you please help me to change it. Thanks!
Oct 03 2022 03:48 PM
Oct 03 2022 04:07 PM
@raindropsdev - Thanks for your reply. I tried to remove/disable Device Gaurd/App locker
2 Effective Ways to Disable Credential Guard Windows 10 (minitool.com)
Clear AppLocker Policy in Windows 10 | Tutorials (tenforums.com)
Many other ways but still no luck
Oct 03 2022 05:28 PM
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:
gpresult /h c:\data\rsop.html /scope computer /f
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.
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:
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
Oct 05 2022 06:24 PM
@LainRobertson - Thank you so much for the detailed explanation. I will look into this and see if that unblocks me and will update.
Oct 08 2022 10:47 AM
@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?
Oct 09 2022 09:32 PM
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:
#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;
#endregion
From 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
Oct 12 2022 04:31 PM
Thanks All for your help!
I had an internal discussion with my team, and we found that this occurred due to some internal security changes implemented after windows 22H2 update and resolved by following the troubleshooting steps.
Nov 07 2022 03:48 AM
Nov 07 2022 09:07 AM
In my case, its Microsoft Internal tools, agents running with some configs. was the issue. Updating those resolved for me. So, I can't provide those details it to the public.