Cannot dot-source this command because it was defined in a different language mode.

Microsoft

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!

11 Replies

@RaviKiranS 

 

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

 

LainRobertson_0-1664756954836.png

 

 

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

@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!

Here it says that it's activated automatically when Device Guard is enabled: https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/

Can you try disabling Device Guard and/or Applocker?

@RaviKiranS 

 

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:

 

LainRobertson_0-1664839106706.png

 

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:

 

LainRobertson_1-1664839701391.png

 

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.

 

LainRobertson_2-1664841135171.png

 

 

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:

 

  1. Open an administrative command prompt;
  2. Run gpedit.msc;
  3. Navigate to Computer Configuration\Windows Settings\Security Settings\Application Control Policies\AppLocker\Script Rules;
  4. Right-click the Script Rules node and choose Create New Rule...;
    LainRobertson_3-1664841716526.png

     

  5. Click Next on the Before You Begin welcome page;
  6. 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:
    LainRobertson_4-1664842033171.png

     

  7. On the Conditions page, choose Path (we're going to take the easy option here);
  8. 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:
    LainRobertson_5-1664842489296.png

     

  9. Click the Create button;
  10. 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;
    LainRobertson_6-1664842634970.png

     

  11. You should now see a single rule targeted to your account as per the example below:

LainRobertson_7-1664842747716.png

 

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:

 

LainRobertson_8-1664843036601.png

 

And when you open a new PowerShell session and check the value of $ExecutionContext.SessionState.LanguageMode, it should now show as FullLanguage.

 

LainRobertson_9-1664843101608.png

 

But if you're not using group policy or an aligned MDM then your issue may be altogether different.

 

Cheers,

Lain

@LainRobertson - Thank you so much for the detailed explanation. I will look into this and see if that unblocks me and will update.

@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 :sad:

 

What can I do here next?

@RaviKiranS 

 

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;
#endregion

 

From which an example of the output is below.

 

LainRobertson_0-1665376074808.png

 

 

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

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.

Hi @RaviKiranS, even I have been facing this issue post 22H2 upgrade and landed up here for a solution, would you be able to share the troubleshooting steps here so that people like me can also be benefited from it?

Hi @prasannamiskin 

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.