Programming:Windows PowerShell

From Wiki
Revision as of 12:46, 21 June 2016 by Deoren (talk | contribs) (Fixed header level for bit check)
Jump to: navigation, search


Leave out column headers in output

Here is an example of querying the Services list, limiting the results to 10 items and then sorting them, all as as stream of values:

Get-Service | Select-Object -First 10 -ExpandProperty DisplayName | sort

This gives a bare list like so:

ActiveX Installer (AxInstSV)
Adobe Acrobat Update Service
Application Experience
Application Identity
Application Information
Application Layer Gateway Service
Application Management
ASP.NET State Service
Windows Audio
Windows Audio Endpoint Builder

The -ExpandProperty parameter takes the value of an incoming object, enumerates its values and outputs each of those values as a single record on the output stream. By pointing it at a scalar property (a property that is not a collection), you get the raw value and not an object with a single property.


PowerShell v2, ForEach loop statement with null/empty lists

As I write this, I'm still using Windows 7 as my predominant Windows OS and I am learning PowerShell. Windows 7 comes with PowerShell v2.0 out of the box, so unless I take the time to install something newer, I can count on PowerShell v2 to be present on Windows 7 and Server 2008 R2 systems that I manage.

Unfortunately, PowerShell v2's ForEach statement has a nasty bug that will cause it to execute once when it encounters a null value. This bit me repeatedly until I found a blog post which clarified that I wasn't imagining things. The fix is to make sure that you don't give the ForEach statement an empty collection.

Here is an example of doing so based on some code I'm working with (remember, I am a newbie):

$installed_app_versions = GetInstalledAppVersions $AppName

# The 'foreach' loop construct will loop once if the array is null in PowerShell v2, so we have
# to guard against that possibility
if ($installed_app_versions -ne $null) {
    foreach ($app in $installed_app_versions)
            $app_package_guid = $app | Select-Object -ExpandProperty PSChildName
            $app_package_name = $app | Select-Object -ExpandProperty DisplayName

            # Using Write-Output to add "blocking" characteristic to the removal command
            # so that PowerShell waits for it to complete before running the next
            echo "`n[i] Uninstalling $app_package_name ..."
            RemoveAppVersions $app_package_guid


This seems to work well and appears to be best practice.

Run PowerShell script under 64-bit process even when parent process is 32-bit


  1. Batch script is executed from a 32-bit process and does some prep work
  2. Same script needs to run a PowerShell script which will need to see both the 32-bit and 64-bit view of the registry

You will get a 32-bit version of PowerShell from a 32-bit process (by default)

If the batch script does any of the following the result will be a redirection to the 32-bit PowerShell executable:

  1. powershell.exe -executionpolicy bypass -File SCRIPT_NAME.ps1 -Parameter1 "Value1" -Parameter2 "Value2"
    • see section below for why we're bypassing the execution policy
  2. %windir%\System32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -File SCRIPT_NAME.ps1 -Parameter1 "Value1" -Parameter2 "Value2"
    • System32 is the directory for 64-bit executables (yeah, I know the name implies otherwise)
  3. %windir%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -File SCRIPT_NAME.ps1 -Parameter1 "Value1" -Parameter2 "Value2"
    • SysWOW64 is the directory for 32-bit executables

Option 1 lets the OS resolve the path to powershell.exe. If you call powershell.exe from a 64-bit process (native cmd.exe on a x64 box for example), you get a 64-bit version of PowerShell. If you call it from a 32-bit process, you get a 32-bit version of PowerShell. Option 3 is just giving up an explicit request for a 32-bit version of PowerShell.

Getting a 64-bit version of PowerShell

Thankfully Windows provides a way to bypass the automatic "helpful" redirection of requests for 64-bit executables to 32-bit executables. To do this, reference the %windir%\Sysnative folder from a 32-bit process. A 64-bit process (AFAIK) is not provided access to this virtual folder.

Here is an example of determining the path to a 64-bit version of PowerShell from a 32-bit command-prompt:

set POWERSHELL_EXE=%windir%\system32\WindowsPowerShell\v1.0\powershell.exe

:: Using the 'Sysnative' folder will help you access 64-bit tools from 32-bit code
:: Note: the 'Sysnative' folder is ONLY available on a x64 Windows Vista or newer
IF /i EXIST "%ProgramFiles(x86)%" set POWERSHELL_EXE=%windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe

Now when you use %POWERSHELL_EXE% in the batch script (32-bit command-prompt) the 64-bit version of PowerShell is used and any PowerShell scripts which need access to both 32-bit and 64-bit views of the registry should have it.

How can I tell if my PowerShell session is 32-bit or 64-bit?

Here is the command/output for a 32-bit PowerShell session:

PS C:\Windows> Get-Variable PSHome

Name                           Value
----                           -----
PSHOME                         C:\Windows\SysWOW64\WindowsPowerShell\v1.0

and the command/output for a 64-bit PowerShell session:

PS C:\Windows> Get-Variable PSHome

Name                           Value
----                           -----
PSHOME                         C:\Windows\System32\WindowsPowerShell\v1.0


Execution Policy

PowerShell x86 and x64 have different policies

This had me scratching my head until trial/error got me past it. It wasn't until later that I stumbled across a blog post which clarified that the x86 and x64 versions of PowerShell each have different execution policies. Setting the policy for one does not set it for the other.

These are the registry values where the chosen policy settings are stored:

  • x64: HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy
  • x86: HKLM\Software\Wow6432Node\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy

I expect the paths are subject to change for a future PowerShell edition.

Setting policy for both x64 and x86 versions of PowerShell

Using PowerShell

Tested on a x64 Windows 7 OS, but presumably this works the same up to Windows 10.

  1. Run x86 version of PowerShell with elevated rights
    • "Run as Administrator" with UAC enabled
    • "Run as different user" with UAC disabled
  2. Run Get-ExecutionPolicy to examine the current policy
  3. Run Set-ExecutionPolicy VALUE to set VALUE as the policy
    • Current valid values:
      • Unrestricted
      • RemoteSigned
      • AllSigned
      • Restricted
      • Default
      • Bypass
      • Undefined
  4. Run x64 version of PowerShell with elevated rights
  5. Repeat the steps for the x86 version of PowerShell
Using reg.exe

Example of setting the execution policy for 64-bit systems (remotely) using the reg.exe command-line tool:

for /f %i in (\\utilityserver\servers.txt) do reg add \\%i\HKLM\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell /v ExecutionPolicy /t REG_SZ /d VALUE /f

Setting the value locally is handled roughly the same way:

reg add HKLM\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell /v ExecutionPolicy /t REG_SZ /d VALUE /f

Bypassing the PowerShell Execution Policy


  1. Batch script runs which does some prep work
  2. Same script runs a PowerShell script to do some heavy lifting
  3. PowerShell script completes and batch script performs cleanup work

I need this process to work everywhere the batch script runs and I don't know in advance what the Execution Policy will be. Sure, I could add registry settings before calling the script, but I want to just bypass the policy for a short time so my PowerShell script can be executed properly. Here is what appears to work just fine on a Windows 7x64 system:

powershell.exe -executionpolicy bypass -File SCRIPT_NAME.ps1 -Parameter1 "Value1" -Parameter2 "Value2"

SQL Server

List enabled SQL Server Agent jobs

# Load required assembly
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO') | out-null

# Create new object/connection
$sqlsvr = New-Object ('Microsoft.SqlServer.Management.Smo.Server') "LOCALHOST"

# Examine object
$sqlsvr.JobServer.Jobs | Where-Object {$_.IsEnabled -eq $FALSE} | Select Name,LastRunOutcome,LastRunDate

Active Directory

Look up Active Directory group members

I found this tip on

Import-Module ActiveDirectory
Get-ADGroupMember "MyADGroupName" | Select-Object name | Sort-Object name

If you wish to expand all group members from any included groups, run the command like so:

Import-Module ActiveDirectory
Get-ADGroupMember "MyADGroupName" -recursive | Select-Object name | Sort-Object name

and if you wish to instead list by Distinguished Name use this:

Import-Module ActiveDirectory
Get-ADGroupMember "MyADGroupName" -recursive | Select-Object distinguishedName | Sort-Object distinguishedName

An alternate approach is to use dsquery and dsget from the Remote Server Administration Tools (RSAT) package:

dsquery group -name "MyADGroupName" | dsget group -members -expand

With the current set of options the list of users will be by Distinguished Name.

Look up group memberships for user account

Import-Module ActiveDirectory
Get-ADPrincipalGroupMembership username | select name
Domain Users
Domain Computers
Workstation Admins
Company Users
Company Developers

Copy all users in one group to another group

AFAIK, both groups have to be created in advance.

Import-Module ActiveDirectory
Get-ADGroupMember -Identity GROUP-A | Add-ADPrincipalGroupMembership -MemberOf GROUP-B