What PowerShell Commands Do You Use Most Often?

I saw this question in a twitter thread. And a good one it is too. My immediate reaction was: Get-Module, Get-Command, Get-Help, and Get-Member. But those are my most  valuable. So what were my most USED? Turns out there’s a script for that:

PS [C:\foo> ]> Get-MostUsedCommands
Count Name
----- ----
1442 git
832 cd
578 ls
353 f
243 cc

I have uploaded this script to the Spiceworks script library at https://community.spiceworks.com/scripts/show/4644-get-the-most-used-powershell-commands - Feel free to download that code and play with it!

But if you are impatient and want the code, here it is:

Function Get-MostUsedCommands {
   <#
.Synopsis
    Gets most used PowerShell commands
.DESCRIPTION
    Uses the parser and command history to construct a list of the
    most used commands and returns a sorted list. The -TOP parameter
    tells how many results to return.
    Based on a tweet by @stevenjudd
.EXAMPLE
    PS [C:\foo> ]> Get-MostUsedCommands

  Count Name
   ----- ----
    1442 git
     832 cd
     578 ls
     353 f
     243 cc
.EXAMPLE
    Another example of how to use this cmdlet
.INPUTS
    Inputs to this cmdlet (if any)
.OUTPUTS
    Output from this cmdlet (if any)
.NOTES
    Works in Windows PowerShell 5.1, PowerShell 7 Preview 1.
#>
   # Define the parameters
   [CmdletBinding()]
   Param (
     [Alias("GMUC")]
     $Top = 5 # top number of results to return 
   )

  $ERR = $null
   [System.Management.Automation.PSParser]::Tokenize((Get-Content (Get-PSReadLineOption).HistorySavePath), [ref]$ERR) |
     Where-Object { $_.Type -eq 'command' } |
       Select-Object -Property Content |
         Group-Object -Property Content |
           Sort-Object -Property Count, Name -Descending |
             Select-Object -Property Count, Name -first $Top
}         

Using PSEdit from the PowerShell Console - There's a script for that!

The PowerShell ISE has a neat built-in function, PSEDIT. It brings one or more files up into exit windows. I used to use this a lot (in the days before I discovered VS Code!). The PSEDIT function used the $PSISE object to add the files into edit windows. But this does not work from withing the PowerShell console.

But as ever, there's a script for that!  Just add the following function definition into your PowerShell 5.x console:

Function PSEDIT {
[CmdletBInding()]
param([Parameter(Mandatory=$true)]$filenames)
foreach ($filename in $filenames) {
dir $filename | 
  where {!$_.PSIsContainer} |
     %{
        start-process $Pshome\powershell_Ise.exe $filename
      }
   }
}

Once you restart PowerShell, you now have that command avaialble in the console.

Of course, in PowerShell 7, this function does not work since there is no PowerShell ISE V7. In PowerShell 7, you should be using VS Code. Once you install VS Code, typing Code $FileName just works as you would expect - and either start a new instance of VS Code with that file or add the file to an open instance. Very civilised - and another reason I love VS Code.

First Steps with With PowerShell 7

In my last blog post, PowerShell 7 Is Here - Getting Started, I showed how you can install PWSH 7 and associated tools. I have had some good feedback on that post so it all seems to work (today!).

Having run the Install-PWSH7 script, which you can find at: https://community.spiceworks.com/scripts/show/4638-install-powershell7, you should now have PowerShell 7 Preview 1 on your system.

The first thing to notice is that the executable is now pwsh.exe. Also, the home directory, aka $PSHOME is now: C:\Program Files\PowerShell\7-preview. What this provides is a mechanism to run multiple versions of PowerShell side by side. On my system, I have PowerShell 5.1, 6.2 and 7.0. If you use the MSI to install PowerShell 7, the installer updates your environment path so you can easily find PWSH.EXE.

The next thing to notice is that there are a lot fewer modules immediately available. Since PowerShell 7 is installed in a different folder, modules you may have with PowerShell 5.1 are not visible. One thing I had to do was copy over my personal modules.

The next thing I found is that some modules do not load naturally. So for example, you can not just use Import-Module to import the ServerManager module. The solution to this is to use the Windowscompatibility module you can find on the PowerShell Gallery. Amongst other things, this module uses implicit remoting to access Windows PowerShell cmdlets from PowerShell7, for those modules that are not compatible directly. 

An example of using this is the Get-EventLog cmdlet. By default, running this cmdlet results in errors. But by using the Import-WinModule Microsoft.PowerShell. Management command you can access the windows event log, like this:

For more information on this module, see https://github.com/powershell/windowscompatibility.

So far, the following modules need to be loaded using Import-WinModule:

• ServerManager
• ADDSDeployment (and even then some cmdlets do not work properly).
• DHCPServer

And finally, there are some things that are either not going to be supported or, arguably, are broken. So far, Windows.Forms, DSC and Workflows are not supported. Support for forms should come in later releases, prior to RTM.

With respect to Active Directory, I've worked out how to promote a server to be the first DC in a new forest but so far, I can not add a second DC to that initial domain. Still playing with that.

Another thing I found that is, arguably broken, is that the System.IO.DirectoryInfo object, returned from Get-ChildItem/GetItem cmdlets has changed the way it returns the parent directory. In PowerShell 5.1, the Parent property is just a relative path,, whereas in later versions this property returns the full path.  This will break some scripts. 

PowerShell 7 Is Here - Getting Started

Like many IT Pros, I’ve been waiting on the first builds of PowerShell 7. Late last week Steve Lee on the PowerShell team inside Microsoft published a road map to PowerShell 7. And on Friday I finally got access to the code! YEAH. It took some playing around with the code, but I now have a basic development environment up and working. And of course, there’s a script for that.
The environment for PowerShell 7, at least for me, includes downloading the latest build and installing Visual Studio Code as my main IDE. Here’s my getting started script:

# 1. Fix Execution polity then install latest versions of Nuget and PowershellGet
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process -Force
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force
Install-PackageProvider Nuget -Force |
  Out-Null
Install-Module -Name PowerShellGet -Force –AllowClobber 


# 2. Setup C:\Foo to hold stuff. ignore the error if it already exists,
#    then set location to C:\Foo
New-Item -Path C:\Foo -ItemType Directory –EA 0
Set-Location -Path C:\Foo

# 3. Install PowerShell 7
#    For now, load the preview version.
#    Based on: https://www.thomasmaurer.ch/2019/03/how-to-install-and-update-powershell-6/
$URI = "https://aka.ms/install-powershell.ps1"
Invoke-RestMethod -Uri $URI |
  Out-File -FilePath C:\Foo\Install-PWSH7.ps1
C:\Foo\Install-PWSH7.ps1 -UseMSI -Preview -Quiet


# 4. Download and save Install-Vscode script from PSGallery
Save-Script -Name Install-VSCode -Path C:\Foo

# 5. Now run it and add in some popular VSCode Extensions
$Extensions = "Streetsidesoftware.code-spell-checker",
              "yzhang.markdown-all-in-one",
              "davidanson.vscode-markdownlint"
$InstallHT = @{
   BuildEdition = 'Stable'
   AdditionalExtensions = $Extensions
   LaunchWhenDone = $true}
.\Install-VSCode.ps1 @InstallHT 

# 6. Install WindowsCompatibility module
# the ServerManager module
Install-Module -Name WindowsCompatibility -Force

In step 1, I update the execution policy, and install the latest versions of the NuGet package provider and get the latest PowerShellGet module. Windows 10 ships with older versions of these tools so updating them is a good thing to do. With step 2, I create a  local folder, C:\Foo, which is where I put stuff.  Feel free to change either or both of these steps to suit your needs. IN step 3, I download and run a script to install PowerShell 7 on the local system.  The code here is a slightly more long-winded (but possibly more easily understandable) version of a one-liner posted by @Steve_MSFT. 
In step 4, I download a script that installs VSCode and in step 5, I run the script. This installs the latest stable version of VSCode along with three useful extensions. Adjust this list as appropriate.                 
Lastly, in step 6, I install the WIndowsCompatibility module – which is going to be useful in order to use PowerShell 7 to support a wider set of modules/cmdlets.  I plan to highlight this in coming blog articles.
Now that you have PowerShell 7 land VSCode, you need to set VSCode to a) use your colour scheme of choice then set the version of PowerShell you want VS Code. On my workstation, here’s how that looks:

So now that you have both PowerShell 7 and VS Code installed, it’s time to start getting used to the new version. My next post is going to be around installing AD, and the issues arising (along with solutions where possible).