Fix PowerGUI shortcuts in Start menu

ISSUE

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:

SOLUTION

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:

Passing parameters to -EncodedCommand

When invoking PowerShell from cmd/bat files -EncodedCommand is a great way to pass the actual PowerShell code to powershell.exe without worrying about escaping various special characters. This allows you to have just a single batch file (with no external PowerShell scripts whatsoever) which has PowerShell code right inside the file which looks something like:

powershell.exe -EncodedCommand DQAKAA0ACgAJACQAcABhAHIAYQBtAHMAIAA9ACAARwBlAHQALQBDAG8AbgB0AGUAbgB0ACAAJABlAG4AdgA6AFQARQBNAFAAXABwAGEAcgBhAG0AcwAuAHQAeAB0AA0ACgAJACIAUwBlAGUAIAB3AGgAaQBjAGgAIABwAGEAcgBhAG0AZQB0AGUAcgBzACAAUABvAHcAZQByAFMAaABlAGwAbAAgAGcAbwB0ADoAIAAkAHAAYQByAGEAbQBzACIADQAKAAkADQAKAA==

What I was recently pointed to, is that this approach has one limitation: how do you pass parameters to this PowerShell code? For example, say, cmd file gets parameters from command-line and wants to pass them to PowerShell – you obviously don’t know the values in advance so you cannot pre-encode them.

The easiest way that I found is: simply put the value from cmd file to a temporary file, and then read the file from PowerShell code.

So, for illustration purpose, my super-advanced PowerShell script will simply output the parameters:

    $params = Get-Content $env:TEMP\params.txt
    "See which parameters PowerShell got: $params"

As you can see, I am getting the parameters by reading the content of pre-defined file in %TEMP% location.

Now, let’s encode this by running:

$code = {

    $params = Get-Content $env:TEMP\params.txt
    "See which parameters PowerShell got: $params"
    
}

[convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($code))

In my case I got:

DQAKAA0ACgAJACQAcABhAHIAYQBtAHMAIAA9ACAARwBlAHQALQBDAG8AbgB0AGUAbgB0ACAAJABlAG4AdgA6AFQARQBNAFAAXABwAGEAcgBhAG0AcwAuAHQAeAB0AA0ACgAJACIAUwBlAGUAIAB3AGgAaQBjAGgAIABwAGEAcgBhAG0AZQB0AGUAcgBzACAAUABvAHcAZQByAFMAaABlAGwAbAAgAGcAbwB0ADoAIAAkAHAAYQByAGEAbQBzACIADQAKAAkADQAKAA==

Now we are ready to put this into cmd:

echo %* > %TEMP%\params.txt

powershell.exe -EncodedCommand DQAKAA0ACgAJACQAcABhAHIAYQBtAHMAIAA9ACAARwBlAHQALQBDAG8AbgB0AGUAbgB0ACAAJABlAG4AdgA6AFQARQBNAFAAXABwAGEAcgBhAG0AcwAuAHQAeAB0AA0ACgAJACIAUwBlAGUAIAB3AGgAaQBjAGgAIABwAGEAcgBhAG0AZQB0AGUAcgBzACAAUABvAHcAZQByAFMAaABlAGwAbAAgAGcAbwB0ADoAIAAkAHAAYQByAGEAbQBzACIADQAKAAkADQAKAA==

Basically, all I do is write the command-line arguments which the batch file got to a temporary file, and then invoke our PowerShell script.

And here’s the proof that this actually works:


c:\Scripts>pass-params.cmd Here are my parameters!

c:\Scripts>echo Here are my parameters! 1>C:\Users\dsotniko\AppData\Local\Temp\
params.txt

c:\Scripts>powershell.exe -EncodedCommand DQAKAA0ACgAJACQAcABhAHIAYQBtAHMAIAA9A
CAARwBlAHQALQBDAG8AbgB0AGUAbgB0ACAAJABlAG4AdgA6AFQARQBNAFAAXABwAGEAcgBhAG0AcwAuA
HQAeAB0AA0ACgAJACIAUwBlAGUAIAB3AGgAaQBjAGgAIABwAGEAcgBhAG0AZQB0AGUAcgBzACAAUABvA
HcAZQByAFMAaABlAGwAbAAgAGcAbwB0ADoAIAAkAHAAYQByAGEAbQBzACIADQAKAAkADQAKAA==

See which parameters PowerShell got: Here are my parameters!


Now you can have a single batch file, encapsulating PowerShell code and capable of passing parameters to it!

PowerShell for Multi-Factor Authentication solution updated

Another plug to my fellow Questees who have gone PowerShell (that’s the deal we have here at Quest – you add PowerShell to your product and get a special blog mention and lots of happy customers!). Quest’s Defender (Two-Factor/Multi-Factor Authentication solution) team has just updated their PowerShell module and there’s quite a few useful cmdlets for user provisioning, de-provisioning and general Defender auditing / administration.

For example, for User provisioning, there’s ability to batch-assign tokens to users and provide either unique Personal Identification Numbers (PINs) or set a known PIN to expire on first use so that end users can then create their own:

To assist with the de-provisioning of users accounts from Active Directory when a user has left the company simple commands such as Remove-AllTokensFromUser could be used to ensure all tokens that have been assigned to a user are removed.

For auditing and general administration a number of cmdlets are available, for example, it may be useful for auditing purposes to know which users have authenticated using Defender at any time or for a given period:

Here’s full list of what we’ve got in this release:

• Add-TokenToUser
• Add-TokenToUserBatch
• Find-DefenderToken
• Get-DefenderLicense
• Get-DefenderUsersLastLogon
• Get-TokensForUser
• Get-UnactivatedSoftwareTokens
• Get-UsersForToken
• Remove-AllTokensFromUser
• Remove-DefenderPassword
• Remove-PINFromUserToken
• Remove-TemporaryResponse
• Remove-TokenFromUser
• Remove-TokenFromUserBatch
• Reset-DefenderToken
• Reset-DefenderViolationCount
• Set-DefenderPassword
• Set-PINOnUserToken
• Set-TemporaryResponse
• Test-DefenderToken

As you can see this is a lot more than what we could previously provide with the AD cmdlets integration that we had.

You can get a free trial of Defender here.