It shouldn’t have been this difficult.

One of the metaphorical hats I wear at work involves taking care of a lot of the “scripting” in our remote management & monitoring (RMM) system. They call it “scripting” but this isn’t like Bash or PowerShell or Python, it’s just a workflow of prebuilt steps in the RMM software. I enjoy getting to play in this part of the system… most days.

We’re using ConnectWise Automate, which used to be LabTech before being absorbed by one of the two main 900lb gorillas in the managed services space (the other being Kaseya). While “Cee Dubya” can be slow to make improvements, they do provide updates every few months and usually those updates come with welcome features. Every now and then there’s a problem, which brings us to this week.

Recently they released an update which broke one obvious feature (the desktop app’s single sign-on functionality, the official workaround for which is “use Edge instead of Firefox or Chrome as your default browser,” hahahahahaha NO) and, we later discovered, one much-less-obvious feature: The scripting engine’s ability to download files from websites.

We… kind of really need that ability. Losing it breaks the bulk of our software deployment scripts, and would you like to hazard a guess as to what’s the biggest use we have for the scripting system? Yes indeedy! We deploy a lot of software for our clients! And doing that by hand across nearly three thousand machines would suck!

At first I was annoyed but not panicking. We have options. Given that we’re trying to standardize on PowerShell for more of our (actual) script needs, it made sense to start there. The “cmdlet” called Invoke-WebRequest should have done the trick, and since PowerShell is available on every Windows machine we manage, leveraging that seemed like the simplest fix possible. So earlier this week I replaced all of the “File Download URL” script steps with PowerShell commands running “Invoke-WebRequest” and leaned back in my comfy chair to bask in the accolades. And it seemed like my simple (but tedious) fix was all it took.

Until it wasn’t.

Today I learned that if you’re using “native” PowerShell on Windows 10/11-class machines, there’s a problem with Invoke-WebRequest: It relies on the built-in Internet Explorer/Edge browser setup. And if Edge has been removed, well, Invoke-WebRequest breaks. If there’s anything else wrong with the IE/Edge setup, Invoke-WebRequest also breaks. I discovered this the hard way, as is the norm, when a bunch of software deployment scripts started throwing errors.

OK, fine, I have a fallback position already in place: I’ve been deploying PowerShell 7 (aka PowerShell Core) for a couple of years now. Research indicates that Core doesn’t have the same IE/Edge dependency in its version of Invoke-WebRequest. Fantastic! All I have to do is check for “pwsh.exe” in the right location, then use that to issue the cmdlet, and everything’s great.

But… what if PS7 isn’t available yet? No problem! We just use a script to download and install… oh. Hmm. Download.

And that brings me to “curl.” Conventional wisdom is that Windows 10 & 11 come with curl.exe available out of the box. Conventional wisdom seems to be a bit mistaken, since my tests of calling curl.exe to pull down the PS7 installers led nowhere. But hey, you can download curl for Windows in 32-bit and 64-bit flavors! Excellent! Which means my solution looks a bit like this in most of the Automate scripts which call for file downloads from websites:

1. Check for PS7’s executable. If present, use Invoke-WebRequest via that executable.
2. If missing, bail on the process and instead run the PS7 deployment script, which…
3. …uses “curl” (staged on the Automate server itself) to pull down & install the relevant PS7 MSI for the environment (32/64-bit)
4. That script notifies me of the install event, complete with installation log so I can confirm success.
5. Go back and attempt the initial script again.

Great, but getting to this point ate up most of my week so far, and retrofitting all of those software deployment scripts a second time was tedious as heck. Is it vacation time yet?

Oh, right. My vacation will be spent moving into the new house. Sigh. C’est la vie.

(I can hear some of you asking, “If you can stage curl on the Automate server, why not just stage all the other software you need to download, or at least the PowerShell installers?” Curl is tiny. The PS7 MSIs are ~100MB each. And every time you use a staged download from the Automate server it chews up a chunk of the server’s bandwidth. It’s possible, we have proved through painful experience, to render your Automate server inaccessible by trying to push downloads to hundreds of endpoints. This is why we have a software staging website now, and why we need to be able to download files from websites in scripts.)