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

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:

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:

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...;
   

    

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:
   

    

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:
   

    

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;
    

     

11. 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