Richard Siddaway's Blog

I’ve always maintained that the most important thing about PowerShell is what you can do with it. This is brought out in my book – Pro Microsoft Hyper-V 2019 – https://www.apress.com/gb/book/9781484241158 .

My co-author and I describe how to create and manage a hyper-V environment. We use many PowerShell examples but they’re all in the context of getting your job done.

PowerShell is an important tool for administering your environment but at the end of the day remember the job is administration not fancy code. Your code should be good enough to get the job done and then move to the next task. You can always revisit code and polish it later.

PowerShell v6.2 contains a number of experimental features including PSCommandNotFoundSuggestion

The idea of experimental features is to make the use of new features – especially those that may cause breaking changes optional. Feedback can be obtainied and the experimental features can be modified, moved out of the experimental state into the full release or even removed.

Use

Enable-ExperimentalFeature –Name PSCommandNotFoundSuggestion

to enable the feature. Then restart PowerShell.

Trying the new feature gave these results

PS> Get-Srvice

Suggestion [4,General]: The most similar commands are: Get-Service, Set-Service, New-Service, Get-PSDrive.

I expected Get-Service so that worked

Likewise

PS> Get-prcss

Suggestion [4,General]: The most similar commands are: Get-Process, Get-Alias, Get-Host, Get-Acl.

Looking for Get-Process – some of the other choices are very odd

Moving to native utilities

PS> pong

Suggestion [4,General]: The most similar commands are: popd, copy, move, ni, nv, oh, rni, rnp, sort, man.

I’d have expected to see ping in that list!

PS> Get-NtAdter

gives

Suggestion [4,General]: The most similar commands are: Get-NetAdapter, Set-NetAdapter, Get-Counter, Get-Item, Get-Date, Get-Member.

Expected Get-NetAdapter so that counts as a success.

Looking at aliases

PS> seloct

Suggestion [4,General]: The most similar commands are: select, sort, set, del, clc, sal, sl, sleep, start, sls.

PS> stv

Suggestion [4,General]: The most similar commands are: sv, stz, clv, ft, gpv, gv, nv, rv.

Needed to see select and stz respectively so that’s good.

One last utility

PS> ipconfog

Suggestion [4,General]: The most similar commands are: ipmo, ipcsv, ipconfig.exe, inmo.

ipconfig fits the bill.

For the most part the suggested commands seem to be reasonable and reasonably accurate.

Tab completion probably removes some of the usefulness of this option but I’d recommend enabling it and giving it a try

I’ve mentioned the PowerShell v6.2 experimental features before.

This blog post from the PowerShell team https://devblogs.microsoft.com/powershell/general-availability-of-powershell-core-6-2/

gives a good overview of the available experimental features.

I’ve already covered the use of the temp drive. The command not found suggestions and implicit remoting batching look like they could be useful.  The abbreviation expansion could make interactive use more efficient

Copy-Item seems to cause problems for many users.

I’ve written an article on the use of Copy-Item that you may find useful – https://searchwindowsserver.techtarget.com/tip/PowerShell-commands-to-copy-files-Basic-to-advanced-methods

The Powershell v6.2 release has just been made available on github – https://github.com/PowerShell/PowerShell/releases

The full release notes aren’t available on the Microsoft documentation yet – they should appear in the What’s New section of https://docs.microsoft.com/en-us/powershell/scripting/overview?view=powershell-6

The release notes on github indicate only one breaking change  – around the –NoEnumerate behaviour in Write-Output

There are some relatively minor cmdlet updates and fixes – nothing leaps out as a major issue.

You have six months to upgrade to v6.2 before the v6.1 support stops

Read-Host enables you to prompt for input for your functions and scripts. For instance I see a lot of examples of this sort of code:

$group = Read-Host -Prompt ‘Group Name’
Get-ADGroupMember -Identity $group

You should only use Read-Host as a last resort. The correct way to pass data into scripts and functions is by parameters. You can create a param() block in a script!

function Get-Members {
param (
[string]$group
)
Get-ADGroupMember -Identity $group
}

Use the function as:

Get-Members -group finance

The other advantage of parameters is that you do lots of clever validation on the values.

So, stop using Read-Host and use parameters – you know you want to.

The issue Scope issue with Install-Module that I discussed in recent posts is annoying because I know that I’ll forget about it and end up installing in the wrong place and have to uninstall and reinstall. Then I remembered PowerShell default parameters.

By adding the line

$PSDefaultParameterValues = @{‘Install-Module:Scope’=’AllUsers’}

into my PowerShell v6 profile I’ve removed the issue. Install-Module will always default to –Scope AllUsers and if I need to override it I can.

$PSDefaultParameterValues is a hashtable where the key is constructed from the cmdlet name and the parameter and a value is supplied.

I use the same profile for production and preview PowerShell v6 instances so all should be good – until there’s another change.

I was recently asked how to add user information – specifically first and last name – into computer description in Active Directory.

First get your user

$user = Get-ADUser -Identity FredBrown

Then add the information to the computer’s description

Set-ADComputer -Identity W10ProIp -Description “Used by $($user.Givenname) $($user.Surname)”

You need to use the subexpression – $() – syntax to resolve the values rather than getting references to the $user object.

Then test the description has been set

Get-ADComputer -Identity W10ProIp -Properties Description

If it was me I’d add the samAccountName or other unique identifier as name isn’t sufficient to uniquely identify the user

Further to my last post it appears that Install-Module in PowerShell v6.2 RC1 DOESN’T follow the rules. In an elevated session if the scope parameter ISN’T used it will install to $home\Documents\PowerShell\Modules

The default appears to be CurrentUser regardless.

You have to use -Scope AllUsers if you want it to install in C:\Program Files\PowerShell\Modules

Be aware of the Scope parameter when using Install-Module. The following rules apply:

Allusers scope installs to $env:ProgramFiles\PowerShell\Modules

CurrentUser scope installs to $home\Documents\PowerShell\Modules

NoScope defined:

– – For an elevated PowerShell session, Scope defaults to AllUsers

– – For non-elevated PowerShell sessions in PowerShellGet versions 2.0.0 and above, the Scope is CurrentUser

– – For non-elevated PowerShell sessions in PowerShellGet versions 1.6.7 and earlier, Scope is undefined, and Install-Module fails

PowerShell v6.2 RC 1 uses PowerShellGet 2.0.4 and PowerShell v6.1.3 uses version 1.6.7. You’ll see different behavior depending on PowerShell version so the advice is to use the Scope parameter to ensure the module goes where you intend.

I usually want my modules in Program files (Allusers) rather than my documents folder (CurrentUser).

The lesson seems to be to use the Scope parameter rather than relying on defaults