Pro Microsoft Hyper-V 2019
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.
PSCommandNotFoundSuggestion
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
PowerShell v6.2 experimental features
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
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
PowerShell v6.2 release
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
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.
Powershell default parameters
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.
Putting user information into computer description
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
Install-Module in PowerShell v6.2 RC 1
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
Install-Module Scope parameter
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