Automated workflow to update internal flash servers now broken. Again.

I use a Powershell-based system to detect new versions of Adobe Flash Player. In a nutshell, when a new version is detected as having been released, the script Invoke-WebRequests the fp_background_update.cab file from the Adobe distribution server, then unpacks it on my internal Flash update servers, which then allows the multiple thousands of machines I manage to update their version of Flash like good little soldiers. Simple, efficient, hands-off. It's worked like a champ for well over a year.

Not anymore.

Since this latest round of changes on the back end, my Powershell script cannot download the fp_background_update.cab file anymore, even using the link (https://fpdownload.macromedia.com/get/flashplayer/distyfp/current/win/fp_background_update.cab) from the shiny new distribution page from this latest round of changes to how Adobe distributes things.

This happened the last time y'all radically changed how the file was gotten, but at least that iteration included a GUID parameter that I could stick on the web request and have it work. Not so much this time. You've successfully locked everything behind a login wall, but you've given no ability to handle that login programmatically. (Personally, I don't see how locking this file behind a login wall is useful to either Adobe or we who make use of it. Everything is signed inside the CAB file, and it's being downloaded from an Adobe server, so the "we're preventing malwarez" argument doesn't fly.)

Please advise about what I need to do to get this method working again. I would really, truly, strongly prefer that the answer not involve a human needing to do anything at all after updating the script. Quite frankly, I have enough else to do, and this entire internal Flash server setup was supposed to make my life simpler. Up until the other day, it was doing just fine in that regard.

Thank you in advance for your assistance.

--Brian