Azure has PowerShell (?!)

“Oh c’mon, Kevin.. Everybody knows you can use PowerShell against Azure…”

Yeah, sure.  But did you know that they’ve finally added the preview for using a PowerShell shell right from the browser?

“No! Do tell!”

For a while now you’ve had the ability to click what looks to be a command-prompt icon in the upper-right-hand corner of your Azure portal window.

Shell Icon

That opens up a terminal-like window at the bottom of the browser, and you’re in a BASH session.  There’s a drop-down at the top of that windows that suggested that you can choose between BASH and PowerShell, but PowerShell was “coming soon”.  Well, soon was this week.

Shell Choices

Setting it up is fairly straightforward.  When you select PowerShell as the chosen shell, you are given a notice about the fact that you’ll need a dedicated storage account associated with this capability.  This storage will be used to host your default cloud drive file share. 

Note: Other than in this file share, there is no persistence between terminal sessions.   More about this later.

Configuring Storage

As you see above, I didn’t have storage created for this, so after selecting my subscription, it created a storage account for me.  I didn’t select the Show advanced settings option, but if I had I would have been able to choose existing or create new resource group, storage account, and file share.  

When I was done, I had a default resource group created to host that storage account.

Resource Group Created

The shell windows displays the status of the configuration, which does take a minute or two…

Configuring the PowerShell terminal session for the first time

And when you’re done, you’ve got a shell of POWER!

All done configuring

Notice at the top that can also now select between BASH and PowerShell, you can reset the session, click to common help topics, or manage settings (which as of right now is just manipulating the text size and providing feedback to Microsoft).

“Cool!  So what can you do with it?”

I haven’t gotten that far.. but let’s try a couple of things to see what the environment looks like.  Let’s start with a simple Get-Service cmdlet.  It actually took about 5 seconds to respond, but when it did it came back with what I expected…

Running Get-Service

I have to assume that I can do Azure PowerShell commands, like listing the resource groups using Get-AzureRmResourceGroup

Typical Azure cmdlet

The capture above is truncated because I thought I shouldn’t give you a list that also contains my subscription ID and other groups.. but trust me that this worked as expected.

“You mentioned that you have a file share created in storage.  How do you get to that?”

You’ll notice that you start out in the Azure: drive.  From here you can navigate to and manage Azure resources:

Navigate to Azure resources

But if I want to get to the file system of the local machine, I can go $Home

File system of the machine running my terminal session

Notice that I cd $Home, which brings me to a profile folder for my current session.  Yes, it’s basically the default folders you’d see on a Windows Server 2016 machine (because, under the hood, that’s what it is!).  However (and this is important).. putting items in any of that file system other than the linked folder CloudDrive will not persist from one session to the next.  So, I cd .\CloudDrive\ and I’m now placed in the file share of my persistent storage.  Whatever I do there will be persisted for me.

As an exercise for you, try creating a simple text file (echo “Hello, world!” > hello.txt) into both the Documents folder of the server, and of the root of the ./CloudDrive folder.  Log out of Azure, and then back in and into your PowerShell terminal window, and see which file is still there when you get back.  (NOTE: maybe you’ll get lucky and get the same machine if you do it right away.  But if you wait 30 minutes for the VM to time-out, I bet the file in the Documents folder will be gone, but the CloudDrive file will still be there.)

Happy geek!

For more official information, check out the announcement from the Azure Blog, plus the full Overview of Azure Cloud Shell (Preview), and Features & tools for PowerShell in Azure Cloud Shell.

Have you tried this yet?  What do you think?  Shoot me your questions and/or comments below.

DSC: Cut to the Core

PowerShell SuperheroThis is an interesting development.  I had a good friend and respected local technologist mention this to me the other day, and he wasn’t happy.  “Why would they take away features?  Just to be ‘consistent’?”  Apparently his take on this is that Microsoft is reducing something that was powerful down to a subset of its former usefulness. 

Here’s what he was referring to…

In a DSC future direction update on the PowerShell Team Blog the other day, Microsoft announced a new direction for DSC.  For those not familiar with DSC, it stands for Desired State Configuration.  According to Jeffrey Snover (the architect of PowerShell), PowerShell DSC was the whole reason why PowerShell was invented.  We want the ability to define and apply a configuration as a “desired state” to a machine (or machines), and have it applied consistently and, optionally, perpetually.  Write up some simple text, and “Make it so.”, with all the benefits of text (source control, among others). 

Initially, of course, PowerShell DSC was addressing the configuration of Windows-based servers, but it was no secret that, being built with standards in mind, it was built to support the ongoing configuration of Linux workloads as well.  In fact, this really caused two worlds: PowerShell DSC for Windows and PowerShell DSC for Linux, because both had their own unique set requirements, dependencies, supporting frameworks, and allowed commands.  Somewhat understandable, sure.  Feature parity?  Um, no.

So now Microsoft announces “DSC Core”.

“What is DSC Core?”

I’m glad you asked.   It is “a soon to be released version of DSC that aligns with PowerShell Core”

“PowerShell Core?  What’s that?”

PowerShell Core is the open-source cross-platform version of PowerShell that runs on Windows, Mac, and Linux.  It runs on top of .NET Core…

“.NET Core?  What the…”

Yeah.. okay.  .NET Core is “a general purpose development platform maintained by Microsoft and the .NET community”. 

“Oh, I get it.”

You do?  Okay.  Well, anyway… back to DSC Core.  DSC Core (built using PowerShell Core which is built upon .NET Core) now becomes a common, cross-platform version of PowerShell DSC.  

From the “Future Direction” blog post:

“Our goals with DSC Core are to minimize dependencies on other technologies, provided a single DSC for all platforms, and position it better for cloud scale configuration while maintaining compatibility with Windows PowerShell Desired State Configuration.”

So this subset (if we can call it that) will still be compatible with PowerShell, but it won’t have the large numbers of unique Windows dependencies bogging it down. 

“What about compatibility?  What about the CmdLets?  Will they be the same, or will I have to use different ones?  What about DSC Resources?  Will they have to be recreated?”

All of those and a few other questions (like what to do about Pull Servers) are addressed in the “Future Direction” blog post.

So, “Why would they take away features?  Just to be ‘consistent’?” 

What do you think?  Feel free to discuss/rant/pontificate in the comments section below.

And again, read the full article on the PowerShell Team Blog