Azure PowerShell needs a better debugger

I was on a pretty good pace writing posts for every month or so for this blog….until November, 2020.

That’s when I took on a new client who promptly had me working for two of their clients. One is an Azure customer; the other is a major government contractor that provided my first brush with AWS GovCloud. Today is the first day I’ve had to catch my breath before starting yet another gig…this time in GCP.

So I thought I’d write a post with some random thoughts…and some continued bitching about PowerShell and VS Code and the Azure PowerShell modules. Let’s start there.

I’m a PowerShell fanboy. I think it’s a great language and I use it every day for so many things. This blog has over 50 posts about PowerShell. Those posts remain among the most popular posts here as many of them are “how to” and explain how to use PowerShell in both AWS and Azure as well as some basic PowerShell concepts. (The post about arrays of PowerShell hashtables is an enduring favorite. And today, I was thinking about customized SNS messages in AWS Lambda with PowerShell and realized I’d done it before — and forgotten about it.)

But, sadly, the state of the DevOps toolset for PowerShell and Azure is, in a word, a disaster. And it’s been that way for years. Starting as early as 2017, I’ve had no end of issues with VS Code and the PowerShell extension. The latest fundamentally means one cannot debug an Azure Function in VS Code. Along the way, the PowerShell team has ignored or closed issues that made life very difficult for PowerShell users trying to use the VS Code extension in either AWS or, especially, Azure.

What the PowerShell team seems to miss in their race to make the language ubiquitous is that without a reliable debugger in VS Code, nobody will ever give up the ISE. And that means Windows PowerShell is forever. It means missing out on all the cool stuff the language has to offer since 5.1 (2016!) time frame. What a shame.

By abandoning the ISE and shipping a truly brittle and unreliable VS Code plugin and debugger as a “replacement,” the PowerShell team has tethered us all to legacy Windows PowerShell, making all the shiny new stuff in pwsh unobtanium. I’d take the limited (but reliable) ISE over all the fancy stuff in the VS Code plugin any day. In fact, maybe we should petition Microsoft to #ReviveTheISE for pwsh. That would be better than what we have now. I don’t understand how we got here — given that Microsoft has a long tradition of excellent developer toolsets.

Consider the implications for an Azure DevOps using Azure Functions and Azure Automation. The former is an attractive path for a PowerShell dev to ease into serverless automation. But without a way to reliably debug an Az Function combined with all that a data center dude/dudess has to learn (and unlearn) to code an Az Function, you can forget PowerShell folks suffering through a debugger itself in serious need of debugging.

As for Azure Automation, it’s got no debugging environment, is clumsy and feels ancient. Microsoft is still deploying it in new Azure regions, but I think that’s simply to support scheduled IaaS VM start/stop. (Have you checked out those runbooks? Do not ever model PowerShell code on those! 🙂 )

And, as of this date, basic stuff like Connect-AzAccount when Enable-AzContextAutosave is in effect is broken.

OK, fully ventilated on that until the next time I want to write an Azure Function in PowerShell or I have to login to an Azure account for the umpteenth time because I can’t save a context.

Here’s some quick hits:

• DigitCert continues to be among the most successful vendors at providing prompt, capable support I’ve worked with. A recent client had me back in 2017 updating certs on SSRS…ooops…I mean “Power BI Server” and implementing certs in SQL Server to force TLS connections. Just remember: if you need to do this (and based on traffic to that post, a lot of people still do), you must have a cert that has the FQDN of the SQL Server as the common name — not a SAN. And you must make sure to give MSSQLSERVER access to the private key. Just follow that post with this one update. When adding the permission to MSSQLSERVER you must add the service as “NT SYSTEM\MSSQLSERVER”.
• AWS GovCloud reinforces a point I made three years ago about the fundamental difference between AWS and Azure. A GovCloud account still requires a non-GovCloud account for its existence. An integrated directory would mean setting a bit somewhere in a tenant to enable/disable non-governmental functionality. And, what’s with not permitting Route 53 public zones in GovCloud? Is it that Route 53 isn’t secure? Or does AWS think that government agencies should use hosts files?

That’s it for now. I hope to find more time to blog — and get back to more technical how-tos — soon.