WMF 5.0 is RTM

Awesome news! The Windows Management Framework (WMF) 5.0 RTM is now available. Congratulations and credits go to the Windows PowerShell Team 😀

It is a huge milestone for the following reasons:

  • WMF 5.0 is ready for production environments except those listed on this page.
  • WMF 5.0 is now supported on all Windows platforms (Windows 7, 2008 R2, 2012, 8.1, 2012 R2 and 10)
  • This means that Microsoft will continue to listen to customers’ feedback and fix issues. (They have introduced a new UserVoice site)

  • WMF 5.0 will allow you to benefit from the newest features on all platforms. Adopting WMF5.0 will bring a new level of standardization whatever the underlying operating system.
  • There’s a pretty long list of features on the Download Center page, where you can download the WMF 5.0 binaries.
    I would like to emphasize on some major features that will for sure change the way we operate in IT: Desired State Configuration (DSC), Oneget aka PackageManagement, Pester and of course the hardened security layer built into WMF 5.0.

    Here’s WMF 5.0 RTM on Windows 8.1
    WMF5-RTM-W81
    Here’s WMF 5.0 RTM on Windows 7
    WMF5RTM-W7

  • Last but not least, Microsoft has provided Release Notes on this page and you can also contribute to these notes on github. The release notes also contain a pretty impressive list of Scenarios Enabled by WMF 5.0

Here’s a summary of what package should be installed on what operating system:

Operating System Architecture Package Name SHA256
Windows Server 2012 R2 x64 W2K12R2-KB3094174-x64.msu CFDA8048978708FE4F31ADB6C045E848DB4AF5DECF88F64E38AA511DB92E1D49
Windows Server 2012 x64 W2K12-KB3094175-x64.msu 2B3776EF5E36DA6B383B84CB1A7247FDAF327FA0AEEA9D8E26CEA69076D8EEAD
Windows Server 2008 R2 x64 W2K8R2-KB3094176-x64.msu 22D4A4FF739A3734E1EFA410BD9F745C668C31EFEEFFA170F7968D42022C641F
Windows 8.1 x64 W2K12R2-KB3094174-x64.msu CFDA8048978708FE4F31ADB6C045E848DB4AF5DECF88F64E38AA511DB92E1D49
Windows 8.1 x86 Win8.1-KB3094174-x86.msu 8E3A1414E57211623C2A6097DBDF982855F2E53FEE65859DFA36891BF0BE8E87
Windows 7 SP1 x64 W2K8R2-KB3094176-x64.msu 22D4A4FF739A3734E1EFA410BD9F745C668C31EFEEFFA170F7968D42022C641F
Windows 7 SP1 x86 Win7-KB3094176-x86.msu DFAC22163AA6C51EAF0F0AE59A3F9632558AA08229350D0F272D742BD02F7109

Special note:
If you want to generalize WMF5.0 on all downlevel operating systems, you’ll have first to deal the installation requirements.
The shortest way to install the .Net prerequisites is to download and install .NET Framework 4.5.2 that is an in-place upgrade of the .Net 4.x family.
The .Net 4.5.2 is actually following the Internet Explorer 11 support path.

Beginning January 12, 2016 only .NET Framework 4.5.2 will continue receiving technical support and security updates.

You can find more info on this topic on this page. I currently don’t recommend .Net 4.6 because of the limits enumerated by Aaron Stebner on this page.

The .Net 4.5.2 KB support page is here, and its location on the Download Center here.

Then, you’ve to install some security updates that targets .Net 4.5.2 (I’ve got 10 on Windows 7). After that, you’re in a good position to deploy WMF5.0 😀

Download Firefox

I’ve been using the ftp site of Mozilla for a few years to download Firefox releases and check their hashes.
Unfortunately, Mozilla decommissioned that site and left the following instructions on this page https://ftp.mozilla.org/pub/firefox/releases/latest/README.txt
MF-ftp

Here’s the function I quickly wrote to address these shortcomings:

#Requires -Version 3.0

Function Download-Firefox {
[CmdletBinding()]
Param(

[Parameter(Mandatory)]
[ValidateSet('Win32','Win64','OSX','Linux32','Linux64')]
[string]$TargetOS,

[Parameter()]
[ValidateSet('fr','en-US','en-GB')]
[string]$Language = 'en-GB',

[Parameter(Mandatory)]
[string]$TargetFolder

)
Begin {

    try {
        Get-Item $TargetFolder -ErrorAction Stop | Out-Null
    } catch {
        Write-Warning -Message "The target folder specified as parameter does not exist"
        break
    }

    Switch ($TargetOS) {
        'Win32'   { $OS = 'win'     ; break }
        'Win64'   { $OS = 'win64'   ; break }
        'OSX'     { $OS = 'osx'     ; break }
        'Linux32' { $OS = 'linux'   ; break }
        'Linux64' { $OS = 'linux64' ; break }
        default   {}
    }

    $URI = ('https://download.mozilla.org/?product=firefox-latest&os={0}&lang={1}' -f $OS,$Language)
    Write-Verbose -Message "Download URL set to $($URI)"
}
Process {

    $page  = Invoke-WebRequest -Uri $URI -MaximumRedirection 0 -ErrorAction SilentlyContinue -UseBasicParsing

    if ($page.StatusCode -eq 302) {

        $FileSource = $page.Headers.Location
        $FileName =  Split-Path ([uri]$page.Headers.Location).LocalPath -Leaf

        if (Test-Path -Path $TargetFolder -PathType Container) {
            try {
                Invoke-WebRequest -Uri $FileSource -UseBasicParsing -OutFile (Join-Path -Path $TargetFolder -ChildPath $FileName) -ErrorAction Stop
                Write-Verbose -Message "Successfully downloaded $($FileName)  from $($FileSource)"
                Get-Item (Join-Path -Path $TargetFolder -ChildPath $FileName)
            } catch {
                Write-Warning -Message "Failed to download $($FileName) from $($FileSource) because $($_.Exception.Message)"
                break
            }
        } else {
            Write-Warning -Message "The target folder specified as parameter should be a folder"
        }
    } else {
        Write-Warning -Message "Failed to query $URI. Return code was $($page.StatusCode)"
    }
}
End {}
} # end of function

Here’s how to use this function:

Download-Firefox -TargetOS Win64 -Language en-US -TargetFolder C:\ -Verbose |
Get-AuthenticodeSignature

Download-MF

About format-list

I’ve been recently asked, how the format-list cmdlet selects the properties to be displayed when I do ps | fl. Why do we have Id, Handles, CPU and Name? Where do these properties come from?

This question was already answered and demonstrated on the PowerShell Team’s blog a few years ago on this page.

I couldn’t remember immediately (my bad 😛 ) and I did the following to have a look at what the engine does under the hood 😀

Trace-Command { ps | fl } -PSHost -Name (Get-TraceSource|
? Name -notmatch "Consol.*").Name

default-fl-view-trace

To summarize, PowerShell starts by Plan A and looks for a list view definition in format files.
When Plan A fails, it reports:

FormatViewBinding Information: 0 : No applicable view has been found

Then it switches to Plan B and starts by exploring the Memberset “DefaultDisplayPropertySet” of the hidden MemberSet called PSStandardMembers.

MemberResolution Information: 0 : “PSStandardMembers” present in type table.
[…]
MemberResolution Information: 0 : Found PSMemberSet member: DefaultDisplayPropertySet.

There, it finds these 4 properties:

(ps | select -fi 1).PSStandardMembers.DefaultDisplayPropertySet

default-fl-view-defaultdisplay