So, one of the things I've been seeing float through my mailbox lately is the phrase "Remote PowerShell Debugging." It's mainly been in relation to a recent PowerShell-related product announcement from an ISV. Great product, no question, but I've gotten a ton of follow-up emails from colleagues about that particular feature. "They're saying they're the only ones who do remote debugging! Is it true? Is this that revolutionary?"
Well, yeah, kinda. The product in question is PrimalScript 2012, and it probably is the only product that does debugging of PowerShell scripts on a remote machine in quite the same way that it does. That is, you get a full IDE-based debugging environment: Click to set breakpoints, get variable values, all that stuff, and all from a script that's running on a remote machine. The only downside is that you have to install the product's "Remote Script Execution Engine" agent on the remote machine. That's what actually enables the debuggy-ness. Some folks will have no problem deploying that thing far and wide (you get unlimited use of the agent with your PrimalScript license), but some organizations will have a major issue deploying an agent like that - especially to servers. In fact, I hear people gripe so much about agents on servers that I wonder if many people at all will be abel to use it. Pity - it's a neat tool.
But that doesn't mean remote debugging is out of reach. After all, if a server is already running PowerShell, and if you can enable Remoting (which, remember, is turned on by default in Win2012, so you'd better come up with your plan for turning on Remoting pretty damn soon), then you've got some pretty aweomse remote debugging capabilities built right in.
Now, I'm not going to go through all of the permutations of this. But I'm gonna hit a couple. Let's say I'm on a Windows 7 machine, in PowerShell, and I have a server out there I want to run a script on - and I need to debug that script. Let's say I have a copy of the script on my computer, and it's named DebugMe.ps1. Let's say the remote machine is named DC01 (I happen to have a domain controller handy to test with in my CloudShare environment). Let's say the script looks something like this (I'm keeping this simple on purpose):
I hop into the console and run this:
That runs the script - but there's no debug output. Bummer. Now, you might think that the trick is to add "-Arguments Debug" to the Invoke-Command command-line. You'd be wrong; I tried that. You also just can't add "-debug" to Invoke-Command - that won't work either. The trick is to get into the remote computer's copy of PowerShell.
Shazam! (crack of thunder) I'm debugging on the remote computer. Using Write-Debug, I can "set breakpoints" inside my script anywhere I like. Unlike the breakpoints in an editor - and unlike PowerShell's PSBreakpoints (which editors often utilize under the hood) - my Write-Debug breakpoints stay with the script wherever it goes. I can turn them on or off by using or not using -debug when running my script. Love 'em.
But okay - perhaps you feel this is cheating. Doesn't the ISE let you open a tab to a remote computer? And doesn't the ISE to IDE-style visual debugging? Yes, it does both of those - but not at the same time. Which is really PrimalScript's point - they're giving you that sexy IDE-style debugging experience against a remote machine, something the native tools don't do. Yeah, it requires the deployment of an agent, which is too bad, because I think that'll keep a lot of folks from being able to use it. But those folks can always fall back on the lower-level, console-based debugging that I've shown you here, which can definitely be done remotely using the native tools.
Apr 24 2012, 04:54 PM