Not all PowerShell shells are equals

I’ve been recently involved in fixing 2 issues for my colleagues.

  • The first issue
    • Context
    • My colleagues send an message with a link that points to a script located on a shared drive to help our users reinstall their software.
      Our users just click on the link in their Outlook and got a message saying:
      \\servername.fqdn\share\softwarename\install.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/

    • Issue
    • Users use Outlook that is a 32-bit process. If they click on link that points to a script, it will spawn a 32-bit console and run a 32-bit powershell.exe child process.
      It appears that the ExecutionPolicy isn’t defined in the 32-bit PowerShell and set to its default value: “Restricted” although it’s defined in the 64-bit Powershell.
      Needless to say that you cannot run a script with a restricted execution policy.

    • Solution
    • While there are many ways to solve this issue, we’ve decided to address the issue when computers are provisionned. The post-install of a workstation runs a 64-bit PowerShell script where we’ve just added:

      C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe { Set-ExecutionPolicy -ExecutionPolicy 'RemoteSigned' -Force -Scope LocalMachine }

      The above solution just writes the missing ExecutionPolicy value in this registry key:

  • The second issue
    • Context
    • We’ve a short quick and dirty Pester test to perform some operational validation of our configuration. We’ve decided to add a quick test about the execution policy value for a 32-bit PowerShell. But other tests failed and that was unexpected because they don’t when they are executed in a 64-bit PowerShell console.
      The error message thrown was:
      CommandNotFoundException: The term ‘Get-LocalGroupMember’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct a
      nd try again.

    • Issue
    • As you can see, there isn’t any Microsoft.PowerShell.LocalAccounts module in the 32-bit modules location. It means that you cannot use the Get-LocalGroupMember cmdlet in a 32-bit PowerShell console.

      I started to compare the module names like this:

      Compare-Object (dir $PSHOME\Modules -Directory).Name `
      -DifferenceObject (
      dir "$($PSHOME -replace "system32","syswow64")\Modules"`

      Yes, on my 1803, this is the list of 64-bit only modules:

      • AppBackgroundTask
      • AssignedAccess
      • ConfigCI (or CIPolicy?)
      • HgsClient
      • Microsoft.PowerShell.LocalAccounts
      • NetworkSwitchManager
      • PcsvDevice
      • PersistentMemory
      • ProcessMitigations
      • PSWorkflow
      • PSWorkflowUtility
      • SmbShare
      • SmbWitness
      • StartLayout
      • WindowsSearch
      • WindowsUpdateProvider
    • Solution
    • Well, it depends how far you want to go. I’ve chosen to execute only Pester tests in a 64-bit PowerShell console and do the following:

       It 'WMF local machine 32-bit execution policy should be set to RemoteSigned' {
         Get-ItemProperty -Path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell' `
         -Name 'ExecutionPolicy' -ErrorAction SilentlyContinue
        ).'ExecutionPolicy' -eq 'RemoteSigned'| 
        should be $true

      The above registry key exists only when it’s executed in a 64-bit shell.

      Who executes Pester tests in a 32-bit shell when you run a 64-bit OS?
      My above unit test doesn’t handle gracefully the 32-bit issue and will actually throw an error if it’s executed in a 32-bit shell.

About the Turkish-I Problem

  • Context

We’ve got some computers located in Turkey. My colleagues started to execute some PowerShell code in the end-user context/session/environment.
They had the following code and noticed that the regular expression on line 5 doesn’t match when the culture is set to tr-TR

(Get-Content -Path $FilePath -ReadCount 1 -Encoding UTF8) | 
ForEach-Object {
 $line = $_
 if ($line -match "^([A-Z0-9_]+)=(.*)$") {
  $k = $Matches[1]
  $v = $Matches[2]
  if ($Keys -contains $k) {
   $myData.$k = $v.ToString().Trim()
  } elseif ($WarnIfUnknown) {
   Write-Warning "Unknown ini key '$k' in file '$FilePath'"
 } else {
  Write-Warning "Wrong line '$line' in file '$FilePath'"
  • Problem

What happens is actually well documented on this page:

By default, when the regular expression engine performs case-insensitive comparisons, it uses the casing conventions of the current culture to determine equivalent uppercase and lowercase characters.

However, this behavior is undesirable for some types of comparisons, particularly when comparing user input to the names of system resources, such as passwords, files, or URLs. The following example illustrates such as scenario. The code is intended to block access to any resource whose URL is prefaced with FILE://. The regular expression attempts a case-insensitive match with the string by using the regular expression $FILE://. However, when the current system culture is tr-TR (Turkish-Turkey), “I” is not the uppercase equivalent of “i”. As a result, the call to the Regex.IsMatch method returns false, and access to the file is allowed.


Here’s the same example in PowerShell to showcase what happens:

NB: It uses a function named Using-Culture that you can find on this page.

  • Solution

The solution is provided on the same page that documents the above problem:

Instead of using the case-insensitive comparisons of the current culture, you can specify the RegexOptions.CultureInvariant option to ignore cultural differences in language and to use the conventions of the invariant culture.

Using-Culture -Culture 'tr-TR' -ScriptBlock {

As you can see, it returns now true instead of false:

How could my colleagues solve their issue?
Well, they should use the RegexOptions.CultureInvariant option to ignore cultural differences when they perform their regular expression match.
They cannot use the -match operator anymore and have it populate the $Matches automatic variable when the input is scalar.
Instead of the -match operator, they should use the .Net [regex] object to be able to specify the RegexOptions.CultureInvariant option:

(Get-Content -Path $FilePath -ReadCount 1 -Encoding UTF8) | 
ForEach-Object {
 $line = $_
 if ([regex]::Matches($line,'^([A-Z0-9_]+)=(.*)$',513)) {

  $k,$v = [regex]::Matches($line,'^([A-Z0-9_]+)=(.*)$',513) | 
  Select-Object -ExpandProperty Groups | 
  Select -Last 2 -ExpandProperty Value
  if ($Keys -contains $k) {
   $myData.$k = $v.ToString().Trim()
  } elseif ($WarnIfUnknown) {
   Write-Warning "Unknown ini key '$k' in file '$FilePath'"
 } else {
  Write-Warning "Wrong line '$line' in file '$FilePath'"

PowerShell Conference Book #PSConfBook

Have you ever been tasked to remove admin privileges to your users or asked to implement a least privilege approach?

Removing User Admin Rights Mitigates 94% of All Critical Microsoft Vulnerabilities.
I wouldn’t be as assertive as this headline about the percentage. I prefer to say instead that removing admin rights reduces the attack surface and that the likelyhood your computers would be far more resistant when there’s a 0day is much higher.

Removing admin rights is for sure a recommended best practice:

Restrict users’ permissions to install and run software applications, and apply the principle of “least privilege” to all systems and services. Restricting these privileges may prevent malware from running or limit its capability to spread through a network.


source: The above slide is from Ivanti

Have you ever seen anything else than just recommendations and guidelines about how to implement a least privilege strategy?
Have you been able to locate any detailed starting guide about this topic?

I propose a basic detailed least privilege implementation example in a chapter of the PowerShell Conference Book

Are you looking for more good reasons to buy this book?

I’d like to personally thank Mike F Robbins, Michael T. Lombardi and Jeff Hicks.