Tag Archives: powershell

tech

The Future of PowerShell:

PowerShell, Microsoft’s scripting platform, is significant for several reasons. It is critical to Microsoft’s strategy of reducing dependence on a GUI in Windows Server. It is also a key piece in automating IT administration, which is fundamental to business agility.

The platform was invented by Microsoft’s Jeffrey Snover, now Technical Fellow and Lead Architect for the Enterprise Cloud Group. The evolution of PowerShell has gone hand in hand with the company’s broader strategy for Windows and Azure, guided by Snover as architect.

PowerShell is everywhere in Azure Stack, Microsoft’s packaged version of Azure for running on-premises, and presumably in the online version of Azure as well. There are an “average 472 cmdlet calls” when a VM is created, according to Snover’s keynote at the recent PowerShell Europe conference in Hanover.

The PowerShell team is now apparently part of the Azure Management Team within Microsoft.

What is happening with PowerShell? The main thing to understand is that Microsoft has forked the platform. Windows PowerShell is the Windows-only version, while PowerShell Core is cross-platform on Windows, Mac and Linux. Windows PowerShell is based on the .NET Framework, while PowerShell Core is based on .NET Core.

The situation with this is odd, in that Windows PowerShell is installed by default in Windows Server and the one that most people use; but PowerShell Core is the one that is under active development. This is explained here. Snover emphasised in his keynote that Windows PowerShell is done:

image

Note though that PowerShell is modular, and although the Windows PowerShell engine is not being developed, new or enhanced modules will still appear. In fact, they are likely to run both on Windows PowerShell and on PowerShell Core. Like all forks, there will be some pain over compatibility versus using the latest features as the Core platform evolves.

If you want to try PowerShell Core you can download it here. However it is of limited use for day to day work unless you also install and activate a module called WindowsPSModulePath which you can get from the PowerShell Gallery. This lets you use all your current Windows PowerShell modules, subject of course to compatibility.

image

So what is next for PowerShell? Snover’s ambition for the platform, he said, is to manage any server or service, from any client, running on any cloud (or on-premises, any hypervisor).

Much of what is interesting is not so much new features in PowerShell itself, but additional modules or other utilities.

PSSwagger is helpful for creating modules: it will create a PowerShell module from a Swagger API (a popular standard for specifying RESTful APIs).

CloudShell is a command shell for Azure which you can run from a web browser.

Windows Admin Center, formerly known as Project Honolulu is a browser application for managing servers (and some desktops). You can open a PowerShell session directly from the browser. In addition, it is PowerShell that enables much of the other functionality.

image

As for Microsoft’s plans for PowerShell Core, Snover refers to this site which sets out the company’s strategic investments. These include help system improvements, a GUI framework for the console perhaps like Curses on Linux, a mechanism for PowerShell to prompt for install (as in Bash) when a command is not found, but a module containing that command is known to exist, and Just Enough Administration (JAE) on Linux.

At the PowerShell conference Principal Software Engineer Steve Lee talked about a PowerShell Standard Library, which itself targets .NET Standard 2.0, for module authors to use when creating modules so they will work cross-platform.

PowerShell and Microsoft’s platform

One of the intriguing things about Microsoft’s evolution is its embrace of both Linux and cross-platform. PowerShell is one small part of this, but fits in with that strategy. We should no longer think of Microsoft’s platform as based on Windows, even though of course it mostly runs on Windows today. The OS is becoming less important as the company focuses on services and applications.

The further implication is that cross-platform support is not just a nice-to-have feature for pieces like .NET Core and PowerShell Core, but essential for Microsoft itself as it integrates multiple operating systems in its cloud platform.

While we tend to applaud cross-platform support as a good thing, it is not without pain. PowerShell is a case in point. Windows PowerShell is at the same time the current thing, and the thing that is no longer evolving.

PowerShell and IT admins

PowerShell is an essential skill for Windows IT admins. On Office 365, for example, there always seem to be things you can do in PowerShell that you cannot easily do though the GUI, and even where you can, it often pays to use PowerShell because you can script and automate common operations. The same is true for Azure.

Not everyone loves PowerShell as a language. Some complain of its verbosity. It can also be prickly to work with. It is not at all English-like, making it less accessible for beginners than most scripting languages.

It is however well suited to its purpose, which is what counts.

microsoft, powershell

PowerShell documentation stubs: frustrating for users

I’ve been writing a piece on PowerShell, Microsoft’s generally excellent scripting and automation platform. PowerShell is also largely open source, in its cross-platform, PowerShell Core guise.

Of course I went straight to the official documentation as part of my research. Looks good; but I was puzzled. I would find a promising topic like Object Pipeline, which says:

In this chapter, we will describe how the Windows PowerShell pipeline differs from the pipelines of most popular shells, and then demonstrate some basic tools that you can use to help control pipeline output and also to see how the pipeline operates.

Then I clicked around to read the chapter, and struggled to find the content.

Eventually I figured out the problem, by going to the GitHub repository for the documentation. This content is not yet written. Microsoft’s JuanPablo Jofre has written stubs, either with the intention of completing them later, or perhaps in the hope that the community will step up and help.

Open Source is great, but the user experience of finding stub documents in official documentation, that is not clearly marked as such, is frustrating.

I do not recall this kind of issue in Microsoft documentation written in the old closed-source world, which makes me wonder if the documentation team is under resourced – though the most important part of the documentation, the cmdlet reference, is pretty good in my experience.

My view of PowerShell is that it is now a critically important part of the Microsoft platform. It is not only a tool for managing Windows Server, but also for Microsoft’s online services such as Office 365, Azure Active Directory and other Azure services.

It is worth getting the documentation right.

software development

Mysteries of trapping errors in PowerShell

4 Comments

As everyone in IT knows, sometimes tasks that you think are quick and easy turn out to take longer.

Today I experiences a small example. I have a scheduled PowerShell script that copies a large file. I wanted to enhance the script so that I would receive an email stating whether the copy succeeded and when it completed.

The original script, for the sake of the example (it is actually a little more involved) is this:

Copy-Item somefile somefile.bak
"Clean up"

where “Clean up” represents some code that runs after the copy completes.

Now, by default a PowerShell may continue if it hits an error other than a syntax error. Again for the sake of the example, I will add a line which echoes text to represent the code that send an email. If you run this script:

Copy-Item somefile somefile.bak
"Clean up"
”Send email: File copied successfully”

then the email gets sent whether or not the copy succeeds. Here is what happens if somefile does not exist:

image

Not much use. The solution, I thought, was to use PowerShell’s trap statement. This catches the exception you specify, or all exceptions, and runs some code. You can also use the break or continue keywords to determine whether the block of code in which the exception occurred continues with the next statement, or exits immediately. You can read about trap here. I therefore wrote a script that looks like this:

Function CopyIt {

trap {return "Error copying file: $_"; break;}

Copy-Item somefile somefile.bak
return "Copy successfully completed"
}

$result = CopyIt
"Clean up"
”Send email: $result”

What I could not figure out though was that even when the copy failed, the script still sent me a success message:

image

I assumed I was misunderstanding how trap works. The output shows, in this example, that an ItemNotFoundException is thrown, so the trap should be triggered, right?

Wrong. In the case of non-terminating errors  (PowerShell jargon) you have to specify the ErrorAction. The default ErrorAction is “Continue”. Therefore I had to modify the script like this:

Copy-Item somefile somefile.bak -ErrorAction stop

Now I get an email with a failure message if the copy fails:

image

All very obvious to PowerShell experts; but it seems to me that PowerShell makes it easy for the unwary to write scripts that fail silently. You are unlikely to see the red text when your script is running on a server.