Project Honolulu
Published October 31, 2017The recent announced project Honolulu - https://blogs.technet.microsoft.com/windowsserver/2017/09/22/project-honolulu-technical-preview-is-now-available-for-download/ – is Microsoft’s new browser based Server management tool.
You can install it on Windows 10, Windows Server 1709 and Windows Server 2016, 2012 R2 and 2012
Honolulu is the proposed replacement for the MMC based tools we’ve been using since Windows 2000.
Honolulu functions as a gateway that uses Remote PowerShell and WMI over WinRM (WS-MAN) to manage servers. The gateway connects to an app on the server. You need PowerShell 5.0 or higher on the servers to be managed.
You can currently manage these areas through Honolulu:
Displaying resources and resource utilization
Certificate Management
Event Viewer
File Explorer
Firewall Management
Configuring Local Users and Groups
Network Settings
Viewing/Ending Processes and Creating Process Dumps
Registry Editing
Managing Windows Services
Enabling/Disabling Roles & Features
Managing Hyper-V VMs & Virtual Switches
Managing Storage
Managing Windows Update
There are some big gaps at present including:
Active Directory
DFS
DHCP
DNS
Clusters
WSUS
Is this a replacement for the RSAT tools – not at present.
These tools are still under development so this is an opportunity to help shape the next generation of tools. Be really nice if you can generate PowerShell scripts from the commands as you can with later MMC tools.
PowerShell v6: #2 Remoting
Published October 31, 2017Ask any number of users and you’ll get at least that many different answers but at its core PowerShell is an administration tool. To be effective your administration tools have to be able to access remote machines. RDP is the traditional way to do this for GUI bound admins – should that be the coding challenged? PowerShell remoting is the answer scripting and automation.
In PowerShell v5.1 you have a number of remoting options.
The simplest uses DCOM/RPC at the individual cmdlet level e.g. the *-process; *-service; *-computer cmdlets. This gives you ease of use but depends on you being able to use DCOM remotely. DCOM is blocked by default by the Windows firewall and isn’t a network (router) friendly protocol. The advice is to use it where you can if you need to but you’re better off using PowerShell remoting.
PowerShell remoting, introduced in PowerShell uses WS-MAN for communication with the remote server. Your target needs remoting enabled and the WinRM service to be running. Remoting is enabled by default in Windows Server 2012 and later but has to be enabled in all client versions of Windows and Windows Server 2008 R2 and earlier.
Within a domain remoting is easy because Kerberos authentication is available dramatically reducing the need for credentials. There are a few issues though. Remoting out or or into the domain can be problematic because Kerberos doesn’t support that. You need to use the trusted hosts option (not recommended) or certificate based remoting (safer but harder to configure). There’s also the double hop issue to contend with where you can’t issue a command from computer A that runs on computer B and accesses computer C. You can overcome this using CredSSP or an AD based delegation option.
PowerShell v3 brought a further expansion in remoting option with the introduction of CIM Sessions. These provide remoting options over WS-MAN for the CIM cmdlets (the WMI cmdlets use DCOM) that are analogous to the PowerShell remoting options.
In PowerShell v6 the remoting options change.
The DCOM based remoting option for individual cmdlets has been or is in the process of being removed.
WS-MAN based PowerShell remoting is still available between Windows machines – v6 to v6 or v6 to earlier PowerShell version or earlier PowerShell version to v6. Between Windows machines WS-MAN based remoting works as you would expect with all of the same issues you’ve come know and love through PowerShell versions v2-v5.1.
You also get Linux to Windows remoting over WS-MAN (basic and NTLM based authentication only). You need to install the OMI provider - https://github.com/Microsoft/omi/releases - and the PRSP package - https://github.com/PowerShell/psl-omi-provider.
PowerShell v6 has switched to using SSH as the primary communication protocol for remoting. SSH (using the OpenSSH project which isn’t currently production ready ) will be the focus of future remoting development. SSH based remoting works for Linux <-> Linux, Linux <-> Windows, Windows <-> Linux, Windows <-> Windows but its PowerShell v6 only and won’t be back ported (current team statement) to earlier versions of PowerShell.
SSH based remoting works in the scenarios given above – see demos from PowerShell Summit 2017 – but has issues. Its a very painful process to install and enable OpenSSH on a Windows machine. Doing this across your environment would be a huge job. There is an install script (incomplete last time I looked) and a chocolately package if you use that package management option but its still no where as easy as enabling WS-MAN based remoting.
SSH based remoting supplies a great option for the remoting into and out a domain scenarios but the current reduction in functionality available through PowerShell v6 compared to v5.1 means that while you can create a remote session to the machine you may not be able to do what you need.
If you have OMI installed on your Linux box you can make CIM calls to that box and establish CIM sessions. You won’t get much back as there aren’t the equivalent CIM classes for Linux boxes that you’re used to on Windows. Installing OMI is a pre-requisite for DSC for Linux.
Remoting in PowerShell v6 is changing – some changes are beneficial and some will cause problems as they are very definitely breaking changes from earlier version of PowerShell. If you haven’t investigated PowerShell v6 you need to do so. You need to determine what remoting options you need in your environment and how PowerShell v6, v5,1 WS-MAN and SSH are going to coexist or what subset of those options you’ll use.
PowerShell file extensions
Published October 30, 2017There are a number of file extensions associated with PowerShell. If you’re not aware of them they may cause you problems. You’ll commonly find these PowerShell file extensions:
.ps1 – a PowerShell script. May contain functionality such as functions or workflows. This is the most common extension
.psm1 – a PowerShell module file. Contains one or more advanced functions that are managed as a package
.psd1 – a PowerShell data file. Most commonly used as module manifest to control the .psm1 files that are loaded and the functionality that is exposed
.ps1xml – a PowerShell XML file. Used by the formatting and type systems e.g. Registry.format.ps1xml or types.ps1xml.
.pssc – a PowerShell configuration file. Created by New-PSSessionConfigurationFile when you want to define a constrained or restricted endpoint
.psrc – a PowerShell role capability file. Used during the creation of a JEA endpoint
.cdxml – a cmdlet definition XML file. Used by the PowerShell cmdlets-over-objects engine to publish a module created from a CIM class e.g. the NetAdapter module
Reverse DSC
Published October 30, 2017DSC is a configuration management tool that first appeared in PowerShell v4 and was refined in PowerShell v5/5.1. Major changes are coming to DSC of which more later. DSC takes a configuration and applies it to a server. What about the situation where you have an existing server and want to derive a DSC configuration for it. Various home grown methods have been discussed at the PowerShell Summit, amongst others, but now we have Reverse DSC - https://blogs.technet.microsoft.com/heyscriptingguy/2017/10/27/reverse-desired-state-configuration-how-it-works/
Reverse DSC is available for SharePoint, SQLServer, RemoteDeskTopSession and PSDesiredStateConfiguration. You do need the required resource module for Reverse DSC to work.
Reverse DSC uses the Get functions of resources to get the configuration information.
You get get hold of Reverse DSC, and contribute, at https://www.GitHub.com/Microsoft/ReverseDSC
PowerShell Attacks–advice on defending
Published October 28, 2017PowerShell Attacks–advice on defending from Lee Holmes – PowerShell security expert – is available at
https://blogs.msdn.microsoft.com/powershell/2017/10/23/defending-against-powershell-attacks/
Read, learn, inwardly digest and apply
Windows 2016 1709 release
Published October 27, 2017The Windows 2016 1709 release is the first of the semi-annual updates for Windows Server – interestingly its referred to as Windows Server 1709 in the documentation.
Its now available for download through your Software Assurance channels and Windows evaluation centre. MSDN subscribers can also get a copy.
A big surprise is that 1709 is Server Core only! You can’t get a GUI version. The suggestion is to use the (very) incomplete project Honolulu web browser based admin tool to manage the servers. More on that in another post.
Windows Server 1709 new features are described here
https://docs.microsoft.com/en-us/windows-server/get-started/whats-new-in-windows-server-1709
The standouts are the new features for containers and virtual machines.
Windows 10 Fall Creators Update
Published October 26, 2017The Windows 10 fall Creators Update arrived this morning.
After the usual long download, install and then updating bits after I first log on (that last bit is really irritating – thought it was going away) I got into the machine.
First impression is that there are some minor cosmetic changes. Some icons (extensions) appear on the Edge menu bar that I didn’t have before and don’t want now so I have to waste my time undoing changes Microsoft, in their infinite wisdom, have imposed on me because they know better than I do how I want to work! same with automatically adding the People icon to the taskbar. Stop changing my settings!
So what’s in FCU. Unless you’re a developer – on the surface there’s not a lot to be honest.
For Admins
https://docs.microsoft.com/en-us/windows/whats-new/whats-new-windows-10-version-1709
For developers
https://docs.microsoft.com/en-us/windows/uwp/whats-new/windows-10-version-latest
https://docs.microsoft.com/en-us/windows/uwp/whats-new/windows-10-version-1709-api-diff
Having feature updates every 6 months is a great idea but actually getting something useful would be better. Maybe some of the new features in PowerShell v6 being back ported would be a good one.
Monitor resolution
Published October 25, 2017A question on the forum about getting monitor resolution led to this code
Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorId |
foreach {
$filter = ("InstanceName = '$($psitem.InstanceName)'").Replace("`\", "`\`\")
$maxres = Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorListedSupportedSourceModes -Filter $filter |
Select-Object -ExpandProperty MonitorSourceModes |
Sort-Object -Property {$_.HorizontalActivePixels * $_.VerticalActivePixels} -Descending |
Select-Object -First 1
if ($psitem.UserFriendlyNameLength -gt 0) {
$name = ($psitem.UserFriendlyName -notmatch '^0$' | foreach {[char]$_}) -join ""
}
else {
$name = 'Unknown'
}
$props = [ordered]@{
Manufacturer = ($psitem.ManufacturerName -notmatch '^0$' | foreach {[char]$_}) -join ""
Name = $name
Serial = ($_.SerialNumberID -notmatch '^0$' | foreach {[char]$_}) -join ""
MaximumResolution = "$($maxres.HorizontalActivePixels) x $($maxres.VerticalActivePixels)"
}
New-Object -TypeName PSObject -Property $props
}
NOTE – we’re working in the root\wmi namespace not PowerShell’s default of root\cimv2
Use WmiMonitorId to get the attached monitors and for each of them create a filter using the instance name. You have to replace \ with \\ when dealing with WMI.
Use WmiMonitorListedSupportedSourceModes and expand MonitorSourceModes. use sort-object to find the maximum resolution (multiply horizontal by vertical)
Create an output object. I had to deal with the name of the monitor separately because one of my monitors didn’t have a user friendly name.
Results look like this
Manufacturer Name Serial MaximumResolution ------------ ---- ------ ----------------- GSM 22EA63 304NDJX51788 1920 x 1080 LEN Unknown 0 1600 x 900
PowerShell + DevOps Summit 2018 schedule
Published October 24, 2017The schedule for the 2018 Summit still needs a little bit of polishing to finish it but it's taking shape. I've started releasing information on sched.com that we're using for all our scheduling needs for the Summit. The one and only truth regarding the sessions and their times can be found at https://powershelldevopsglobalsummit2018.sched.com/
I'll be adding sessions over the next few days so keep checking.
I'm really excited about the schedule for the 2018 Summit. We'll have 4 rooms for sessions with many of your favourite speakers returning and many new speakers which is really good to see. The Community Lightning Demos return by popular acclaim and we'll be running an Iron Scripter competition as well. The PowerShell Team will be presenting all day Monday and at other sessions through out the Summit.
Registration opens 1 November and once you're registered through eventbrite your information will be sync'd to sched.com so that you can access the schedule and use the scheduling app.
PowerShell v6: #1 major differences
Published October 24, 2017In August 2016 PowerShell went open source. Since then we’ve seen 18 releases of alpha code and 8 beta release with another beta release imminent. This post - https://blogs.msdn.microsoft.com/powershell/2017/07/14/powershell-6-0-roadmap-coreclr-backwards-compatibility-and-more/ – from the PowerShell Team suggested a full release of PowerShell v6 before the end of 2017.
I’ve not written much about PowerShell v6 so far as its been rapidly changing but we’re beginning to see where PowerShell v6 is going. In this and a series of posts I’ll show you what’s different in PowerShell v6 – some good and some bad – what the important changes are and what impact that might have on your administration strategies.
The current version of Windows PowerShell – in Windows 10 and Server 2016 or WMF download is 5.1. As the above blog post states PowerShell 5.1 requires the FULL .NET Framework – currently 4.x – and will NOT receive major feature updates or low priority bug fixes (I read that as only security related bug fixes are likely).
PowerShell v6 is a fork of the v5.1 code but is based on .NET Core and will address bugs in the original 5.1 code, which won’t be ported back to PowerShell 5.1. PowerShell 6 uses .NET Standard 2.0 to provide binary compatibility with existing .NET assemblies which means that some but not all existing PowerShell modules will work under PowerShell v6.
PowerShell v6 isn’t an upgrade for PowerShell 5.1. It installs side-by-side meaning you can have multiple versions of PowerShell on the same machine.
Windows PowerShell (v1 – v5.1) is the Windows only version that shipped as part of the OS. PowerShell core (v6) is cross-platform with releases for Windows, Linux, macOS and docker - https://github.com/PowerShell/PowerShell
The major differences between PowerShell v6 and the Windows PowerShell you’ve come to know and love are detailed on the v6 release notes - https://github.com/PowerShell/PowerShell/releases. In summary these include:
Allow * to be used in registry paths – breaking change
Remove -ShowWindow from Get-Help – breaking change
Fix incorrect position of a parameter which resulted in the args passed as input instead of as args for InvokeScript() – breaking change
Enable transcription of native commands on non-Windows platforms
Add Remove-Service cmdlet
Added functionality to set credentials on Set-Service
Get-Date now supports more argument completion scenarios
Exclude -ComObject parameter of New-Object on unsupported (currently non-Windows)
Remove Workflows
Get-Content -Delimiter to not include the delimiter in the array elements returned
Add support for converting enums to string
Support SSH for remoting as well as WSMAN
Remove WMI cmdlets - CIM cmdlets are still available
Remove the *-Counter cmdlets
Move-Item cmdlet honors -Include, -Exclude, and -Filter parameters
Change positional parameter for powershell.exe from -Command to -File – breaking change
Make change across PowerShell to support case sensitivity on *nix
Putting & at the end of a pipeline will cause the pipeline to be run as a PowerShell job.
Add -Extension and -LeafBase switches to Split-Path so that you can split paths between the filename extension and the rest of the filename
Fix Get-Help to not return multiple instances of the same help file
Plus a whole load of smaller changes to enable PowerShell to work on Linux and macOS
These changes are in the pipeline
Rename powershell.exe to pwsh.exe - Linux admins don't like typing more than 4 characters at a time evidently
Standarize encoding for cmdlets that write to files
Remove the -ComputerName parameter from many cmdlets e.g. *-Service & *-Process so that individual cmdlet based remoting (over DCOM) isn't available. All remoting goes through SSH or WSMAN
There are also a few issues to consider:
Case sensitivity - Windows is case-insensitive but Linux and macOS are case sensitive. You need to use the correct casing on Linux and mac
File path delimiters - non-Windows must use /
File extensions - not usually used on non-Windows but are required by PowerShell e.g. .ps1 and .psm1
Aliases that match linux commands - ls, cp, mv etc - are removed on Linux and macOS
JEA isn't supported on non-Windows
Snapins aren't available on v6 so some functionality e.g. Active Directory cmdlets can't be used
PowerShell v6 is a major change – probably best regarded as a breaking change. I’ll investigate some of these issues in more depth in subsequent posts
This is a useful list of packages and resources irrespective of version- https://github.com/janikvonrotz/awesome-powershell