I’ve been using ConnectWise Control for years and its great. But the lack of any published API or Plug-and-play PowerShell module for it has really put a damper on my experience. Its time to change that with ConnectWiser.
The Past
ConnectWise Control (CWControl, Control, or just CWC) is awesome. It’s cheap. It’s lean. Its vulnerabilities get resolved in a timely manner. Oh, and did I mention that it’s freaking powerful? Seriously, I love CWC. The backstage feature alone is what I would call ‘killer’ that any replacement has to have a viable answer to. I love that I can get a real gui session on computers, without having to interact with the user session at all.
It’s had all of these features for many years! In fact, I’d say that it really doesn’t need to make any huge improvements during the next 5 years in order for me to still be perfectly happy to pay for it. But that stability also means that some of the old gripes about ScreenConnect (before it was bought by ConnectWise) are still relevant today.
For example, it doesn’t have any published API. So what, you ask? Well, that means that I can’t automate my life with it. I’d love to be able to get notified when Bob’s computer comes online today so that I can go take care of X or Y. And I can only do that if they create a solution or I have a flexible tool that can use an API to create that solution myself.
In the past, I’ve looked for some published API that I could use, only to find nothing. I’ve looked for PowerShell modules, only to find that they don’t work for my environment. So what’s a sysadmin to do? Well, it is 2024 after all, so why can’t the sysadmins rise up and do our own bidding?
The Present
The BEST way that I’ve found to interact with Control using PowerShell is Chris Taylor’s module, ConnectWiseControlAPI. The problem with it is that it doesn’t work instances that use 2FA/MFA. As I am used to a hosted instance of Control that requires MFA on all users, this module was incompatible with my environment.
When I looked at the module again yesterday because I was hoping it had made progress, I noticed that there was an issue filed about the lack of MFA support. And I noticed that work had been done by people to attempt to solve the issue. And I noticed that Chris has not been active in the issue at all.
One of the commenters created a fork of the module and added MFA support. The catch is that you have to put your MFA root token (the thing that MFA QR codes are made from) into the PowerShell session. This approach works (though, its debatable if you should be doing it) if you are using a OTP token, but it doesn’t work if you use the email option for MFA or one of the other authentication methods like Yubikey.
The way this approach works is to generate a OTP passcode every 60s (or every command if more than 60s have elapsed since last use) and add that passcode to the headers of every request. Talk about MFA abuse! And yet, when using the web version of ConnectWise, you don’t have to put in creds every minute. So why should the API have to do the same?
A Better Way
I opened up my trusty dev tools and looked at the actual network traffic during login from the web and noticed that the web version uses a different login flow than the ConnectWiseControlAPI module. And this flow works with MFA just fine. And its not anything crazy looking either. Just a different endpoint to hit to create a session and then reuse that session for all the web calls in the module.
It took me a minute to get it all dialed in, but I was able to make ConnectWiseControlAPI successfully submit the authentication bits to the alternate endpoint and use a WebSession for all its API calls in the module. I didn’t have much hope that Chris would merge these changes in quickly, so if I wanted to benefit others, I’d have to share the work myself. All that was left was publishing the dirty bits of how to hack the module or run some random one-liner to mimic the PowerShell module process.
I really don’t want sysadmins to have to run random one-liners from Github just to get a module. I don’t want to do that either. And I certainly don’t want sysadmins to have to go edit modules by hand to add in patches, even if they are small. The long-term pain and troubleshooting just make that approach untenable, so I resolved to release my own fork of ConnectWiseControlAPI to share the power easily. That’s where ConnectWiser comes into play.
The Future
ConnectWiser builds on all the awesome work that Chris has done. And extends it so that you can EASILY use your existing credentials with any MFA authentication provider for ConnectWise Control within PowerShell. I did take the time to get a proper Invoke-Build process in there too, which will make future contributions from me or from others a lot easier too.
Going back to my example from the beginning of this post: what can I do to get notified when a specific computer comes online? Easy to do with my regular credential now.
Or what about using my powershell console to quickly see all computers that Bob is currently logged in to? Easy again. All thanks to ConnectWiser, the wiser way to use ConnectWise Control!
Wrapping Up
There are some changes that I will be making to the module in the near term. I need to get it to a v1 release first. Then I can work on breaking changes towards a v2 release. But all that is already mentioned on the roadmap from the project site.
If you are sitting there wondering what the heck is going on with my version numbers, then I’ll refer you to my post, Minor Versions Are Useless.