Archive for the 'Known Issues' Category

Fix PowerGUI shortcuts in Start menu


PowerGUI 3.0 accidentally shipped with Windows Start menu shortcuts being called just “Administrative Console” and “Script Editor”. Which means that if you are used to starting applications by typing keywords in Start menu, you won’t be able to find the tools by typing PowerGUI:


Open PowerGUI Script Editor (or native PowerShell command line), run the following command in the PowerShell Console window:

dir “$($env:ProgramData)\Microsoft\Windows\Start Menu\Programs\PowerGUI” | where {$_.Name -notmatch “PowerGUI”} | Rename-Item -NewName {“PowerGUI ” + $_.Name}

This will rename the shortcuts for you:


PowerGUI Editor 2.4 and AD cmdlets 1.4 compatibility issue

[UPDATE] This issue has been fixed in AD cmdlets 1.5.1 – please download the latest version of AD cmdlets here.

We have found a compatibility issue between PowerGUI Script Editor 2.4 and AD cmdlets 1.4 (these are the current versions at the time I am writing this post.)


You execute a script which is using QAD cmdlets. The first time the script executes fine. However when you try to execute it again, the script fails with the “Object reference not set to an instance of an object.” error.


The issue is related to the way QAD cmdlets are handling initialization and unloading of the snapin.


Set PowerGUI Script Editor to not reset PowerShell runspaces between the debug sessions:
1. Go to Tools / Options / Debug Options,
2. Select the Run all scripts in the same runspace option.
3. Restart PowerGUI Script Editor.

We are sorry for the inconvenience and are working on fixing the issue in the next releases.

Unblocking PowerGUI Add-Ons and PowerShell Modules

When trying to use a Script Editor add-on or a PowerShell module or script you downloaded from the internet, you might every now and then get an error message like this:

Import-Module : File C:\Users\dsotnikov\Documents\WindowsPowerShell\Modules\Add-on.HelpBrowser\Add-on.HelpBrowser.psm1 cannot be loaded. The file C:\Users\dsotnikov\Documents\WindowsPowerShell\Modules\Add-on.HelpBrowser\Add-on.HelpBrowser.psm1 is not digitally signed. The script will not execute on the system. Please see “get-help about_signing” for more details..At line:1 char:184+ @(‘C:\Users\dsotnikov\Documents\WindowsPowerShell\Modules\Add-on.HelpBrowser\Add-on.HelpBrowser.psd1’) | Where-Object { @(Get-Module | %{$_.Path} ) -notcontains $_ } | %{ Import-Module <<<<  $_ }    + CategoryInfo          : NotSpecified: (:) [Import-Module], PSSecurityExc    eption    + FullyQualifiedErrorId : RuntimeException,Microsoft.PowerShell.Commands.ImportModuleCommand

This happens when the downloaded file comes from the internet, is not signed and thus conflicts with your PowerShell execution policy (e.g. RemoteSigned).

If you do trust this particular add-on/module/script to not be malicious (comes from a trusted source, has been inspected and so on), the workaround is quite easy – simply right-click the file (or the entire zip file if the files were zipped) and click Unblock in the Properties dialog box:

(You can also unblock files from PowerShell command-line – and in bulk! – by using Remove-DownloadFlag from PoshCode module.)

Hope this helps!


PowerGUI Editor 2.1.1 and AD cmdlets 1.4 compatibility issue

[UPDATE] This issue got fixed in PowerGUI 2.2.

We have found that in some cases when you are using version 1.4.0 of QAD cmdlets inside PowerGUI Script Editor 2.1.1, and invoke a script with the cmdlets for the second time you may get the error: “Object reference not set to an instance of an object.

This is obviously very unfortunate and we are working on fixing the issue. In the meantime there are a couple of workarounds you can use:

A. Run Script Editor in MTA mode (if you don’t know what STA/MTA mean – this means that you would likely not notice any difference – but as a side-effect it might affect some script editor add-ons or your scripts using WPF)

To do this, just modify the PowerGUI Script Editor shortcut:

and add the -MTA switch to the command line:

B. Alternatively, you can set PowerGUI Script Editor to reset PowerShell runspace each time you start debugging:

1. In PowerGUI Script Editor, on the Tools menu, click Options,

2. In Debug Options, select Reset PowerShell runspace each time debugging is started.

Again, we appologise for the inconvenience and are working on a perminent fix.

AD PowerPack now compatible with cmdlets 1.2

If you upgraded to AD cmdlets 1.2 and noticed that some links and actions in PowerGUI’s Active Directory and Network PowerPacks stopped working.

Now there are fixes available for both of the packs: just download and re-import them and you will get all the functionality back.

For those interested, the issue was related to AD cmdlets 1.2 losing Connection property in all their objects. This property was extensively used by our PowerPacks to provide for simultaneous work against multiple directories (e.g. test and production, AD and ADAM, or just multiple domains or forests).

AD cmdlets team is by the way working on a 1.2.1 patch release which would get the property back, but we thought we would provide a fix on PowerGUI side too.

As a free bonus AD PowerPack has a few other nice features:

  • Moved “Managed Domains” from the Network PowerPack to this PowerPack
  • Added top level Configuration node to allow you to set global settings that define what domain to connect to, what account to use, what properties to retrieve by default for each object type, what page size to use, what size limit to use and whether or not to perform searches across the entire forest or only the domain you connect to
  • Added several child nodes to provide fast access to common objects that users want to retrieve, including Locked Users, Disabled Users, Expired Users, Security Groups, Distribution Lists, Domain Controllers, and Exchange Servers
  • Fixed Empty Groups node such that it only returns truly empty groups (those which have no members and that aren’t set as primary group for any user or computer)
  • Added Unlock user action (this was overlooked in early releases)
  • Added Search… node to allow users to search their current Active Directory domain or the entire forest to which it belongs for objects by type and/or name

Here are the links to read more and download the updated Active Directory and Network PowerPacks.

PowerGUI and CTP3

PowerShell team has just posted the latest pre-release drop of the upcoming version 2 – and they did in on track with the timeline they announced back in November.

The current version of PowerGUI (1.5.3) which you can download from is in general compatible with CTP3 but does have a few issues. For example, the editor works fine and you can get syntax highlight and intellisense for new cmdlets, but step-by-step debugging might leave awkward yellow marking on previous steps. 😉

These issues are obviously fully fixed in the upcoming 1.6 release which is coming out literally in a matter of days now. Stay tuned. 🙂

Tags: , , , , ,

$input gotchas

$input (a.k.a. “dollar input” or “input variable”) is one of those esoteric parts of the PowerShell language that create a lot of confusion. In fact just today there was a discussion on how it actually works on the PowerShell MVP mailing list. We even had to read the documentation to figure it out. 😉

Anyways, basically $input in an enumerator which provides access to the pipeline you have.

So basically if you have a function which sums up the elements from the pipeline you can have something like:

Function Sum {
    $sum = 0
    $input |  foreach { $sum += $_ }

1, 2, 3 | Sum

Easy. In fact if you have ever added any script actions or links in the PowerGUI admin console, this is basically what you use to get access to the selection from the central grid.

Now, there are a couple not so obvious gotchas here:

1. Enumerator is not an array

Suppose you want to know how many objects you get from the pipeline – a totally valid question. Maybe your function is supposed to only get one.

You just do $input.Count and… get nothing. Such property does not exist. This is an enumerator and it simply does not have such a property.

OK, you say, let’s wrap it into an array and we’ll learn the size:


This works… Kind of… If you modify our example above to:

Function Sum {
    "Number of elements: " + @($input).Count
    $sum = 0
    $input |  foreach { $sum += $_ }
    "Sum is: " + $sum

1, 2, 3 | Sum

You get:

Number of elements: 3
Sum is: 0

The first line is correct – we had 3 elements. But why the heck is the sum 0 now?

Well, $input is an enumerator, and when you use it – you get to the next element. So once we used it to create a temporary array we got to its end. To fix it, simply reset it back:

Function Sum {
    "Number of elements: " + @($input).Count

    $sum = 0
    $input |  foreach { $sum += $_ }
    "Sum is: " + $sum

1, 2, 3 | Sum

Now we are good again:

Number of elements: 3
Sum is: 6

2. Just using $input holds the pipeline till all objects are collected

This second one was spotted by Per here. He tried using $input and noticed that his function did not get executed until the whole pipeline was processed (that is his function was not invoked for each element one by one, but rather for the whole collection) – read his post for details.

This happens because according to PowerShell help:

“In the Process block of a function, $input contains the object currently in the pipeline… If the function does not have a Process block, the value of $input is available to the End block, and it contains all of the input to the function.”

So basically the reason for the code above to process the whole collection (rather than go item by item) is that we did not have a process block inside the function, so if you care about item by item processing – go with the process block, if not – feel free to use $input.

And by the way, inside the process block just stick to $_ like this:

Function Sum {
  begin { $sum = 0 }
  process { $sum += $_ }
  end { $sum }

1, 2, 3 | Sum

Using $input inside process is a hustle and Oisin promised a post on his blog on the reasons why. 😉

Tags: , , ,

New patch for AD cmdlets

There is a new patch available for AD cmdlets. It fixes two pretty important issues:

This patch was released as a maintenance release 1.1.2 and was published on September 8. If you downloaded the setup after that date you probably have the version already (just look up the Support information in Control Panel / Add/Remove Programs). If not – download the latest build and install on top of the version you are using – this will upgrade your installation to the patched version.

I want to say thanks to the team which quickly released the patch is demonstrated the commitment to fixing the issues for which they cannot provide a workaround – way to go!

Tags: , , , , , , ,

Select-Object vs Add-Member

Let me be clear on this one: Select is bad, Add-Member is good. 😉

OK, OK, this is not a one-size-fits-all answer, and there are plenty of scenarios in which Select-Object is useful, but in a lot of cases it is being misused. The most frequent one, when someone tries to use Select-Object or Format-Table to add a new attribute to the displayed objects. In that particular scenario these two cmdlets basically create one-time-use disposable objects for a quick output, while Add-Member adds an additional property and preserves the original objects for subsequent use.

A quick example, let’s say you want to see the Primary Group for your AD users. Primary group can be calculated by merging account domain SID and primary group ID so you probably end up with something like:

$PrimaryGroup = Get-QADGroup $($user.Sid.AccountDomainSid)-$($user.PrimaryGroupId)

Now, to add a column to the user output you could use Select-Object or Format-Table and supply the additional value using a hash-table parameter:

Get-QADUser | Select Name, @{Name=PrimaryGroup;Expression={(Get-QADGroup $($_.Sid.AccountDomainSid)-$($_.PrimaryGroupId)).Name}}

Get-QADUser | Format-Table Name, @{Label=PrimaryGroup;Expression={(Get-QADGroup $($_.Sid.AccountDomainSid)-$($_.PrimaryGroupId)).Name}}

(Note a small gotcha by the way: the column name is Name for Select-Object but Label for Format-Table ;))

However, both of these operations have a very important side effect – they kill the original objects and create new disposable ones instead. The collection you get is basically just a formatting thing which you can no longer use in other operations (e.g. pipe to yet another cmdlet).

Select-Object cmdlet changing the object type and losing all other properties

Select-Object cmdlet changing the object type and losing all other properties

For example if I use the Select code above in a PowerGUI script node I will indeed get the output in the grid, however, if you pay close attention (click the image to see the detail) you will see that I cannot add any other columns to the grid (and see for example users’ phone numbers), and the Actions pane to your right is empty – the usual actions for user objects are not there. 😦

Enter Add-Member. This cmdlet is a complete opposite to Select and Format-* – it adds a new member to the objects while preserving all other properties and the object type.

So if instead of the code above we use something like:

Get-QADUser | Add-Member -Name PrimaryGroup -Value {(Get-QADGroup $($this.Sid.AccountDomainSid)-$($this.PrimaryGroupId)).Name} -MemberType ScriptProperty -Force -PassThru

Add-Member adds a new property to PowerShell objects while preserving everything else

Add-Member adds a new property to PowerShell objects while preserving everything else

We get a nice set of objects with all user properties there and the new one added. As a result, inside PowerGUI admin console you see this new column, but can still add any other columns and perform any usual actions – check out the right-hand pane!

Tags: , , , , , , , ,

Script to export column selection

We (with a little help of Aleksandar ;)) have uncovered an issue in the way export functionality works in PowerGUI 1.5.1 – basically column selection and order may not get preserved newly added nodes and links. This can be pretty frustrating because people importing your powerpack may not get the exact look and feel you had when exporting it.

However, the good news is that you don’t have to wait for our next release to have this fixed. Posted to the script repository is a script which fixes the issue for you!

Basically, in this script, I am taking advantage of the open-source nature of PowerPacks and PowerGUI configuration. Both are just XML files, so I:

  1. Go through the PowerGUI config file and grab all the column information for each type, and store it in a hash table.
  2. Then I go through the powerpack file, and if I find a node or a link with no columns specified, I check whether my hash table has info for the type.
  3. If it does, I create the corresponding XML structure and insert it into the node/link XML element.

So if you are exporting any PowerPacks with version 1.5.1 or participating in the PowerPack challenge, this script may come handy. Just change the filepaths in the beginning of the script and run it.

Here’s the script: update-columnsinpowerpack.ps1 – let me know if you have any questions or issues with it.

Tags: , , , ,

My Recent Tweets


The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

January 2023

%d bloggers like this: