Microsoft Azure deprecations: API changes will break applications and PowerShell scripts Microsoft has deprecated two formerly key authentication APIs for Azure Active Directory and many scripts and applications will stop working after June 30th 2022, including older versions of official utilities. While it is Google that has the reputation for killing products, Google Cloud promised last month to keep its …
Yes but, it was old code.
You know, code that was written ten years ago ? It's rusty now.
Borkzilla doesn't give a flying fig about the efforts you have to make to continue working. Borlzilla knows best, and Borkzilla is all about innovating. If all that innovation makes you work overtime, it's a sacrifice Borkzilla is willing to make you make.
This post has been deleted by its author
It's become perfectly clear that users are not the folks IT is really there for. Its actual purpose, however is not entirely clear. Once you have your users on a subscription contract there's no obvious need from the revenue perspective to keep changing things in ways that given them problems, so there must be some other motivation. My impression is that it's arrogance, combined with a perceived need to keep the dev team occupied.
Although they clearly don't in many cases know what we really need, once they have us by the balls they cease to care about our hearts and minds, or even about whether their product actually serves its ostensible purpose..
"My impression is that it's arrogance, combined with a perceived need to keep the dev team occupied."
I always thought it was so MS could do press releases around whatever the "new" thing is they've done this week. It makes them look hip, like they're "leading" and "innovating", when all they're really doing is pointlessly screwing around with stuff that most of us are trying to use.
Whoever thought it was a good idea to let Microsoft become a cornerstone of the new Internet was a complete idiot. MS can't seem to stop piling more crap on, then changing the whole thing on a whim. It's highly annoying.
Indeed.
I've been getting the Azure-based Information RIghts Management module spun up to replace our older on-prem ADRMS system. Getting the on-prem file scanner setup and running has been a pain, because it's still using the Azure Information Protection(AIP) module, which was deprecated back in April; However, it's replacement (the Microsoft Compliance Information Protection) doesn't have nearly the same features, and in fact, still uses most of the AIP back-end code and data that is produced. It's... quite frustrating. Add to it the mess of documentation (multiple versions in multiple places, and a lack of coherency or combining things) and it goes from frustrating to aggravating.
(and even microsoft's own advocates and experts for the systems have trouble with it too.)
I've lamented the lack of coherent documentation a few times for different things. For example, a couple of times I've been trying to setup something where MS says "use Powershell", so I go looking for docs on how to do it in Powershell, but all I can find is a super-dense 40 page document about the underlying, obscure .NET class. Thanks, MS, that's helpful.
I now have something else to be thankful for - we aren't using any rights-management stuff here.
This is the fundamental problem with tools like PowerShell. PowerShell itself was only reluctantly trotted out because the gap between a genuine shell and the old MS-DOS command line had become such a yawning chasm that people needed to use non-Microsoft scripting tools to bridge it. Since Microsoft dislikes any part of the programming ecosystem it doesn't control then it does the 'embrace, extend, extinguish' trick. Many -- if not most -- programming shops will reflexively follow along so they gain control. But as they have done for literally decades confusion, tail-chasing -- but also revenue -- will follow in their wake.
(I've been working with, and around, Microsoft's programming ecosystems since the early 1980s and the only thing that's changed over these decades is the sheer amount of stuff that still mostly 'sorta' works.)
@Tim Anderson “I think the answer is they are currently deprecated, and they will be removed”
Maybe I am just nit picking here but that’s not how I see it. They have made an announcement that those APIs will be retired (removed) June 30th 2022.
So, unless they made an earlier announcement that they have deprecated those APIs then they are not currently deprecated. This is just a removal announcement, warning that there is less than a year to remove those API calls from your scripts.
As I said maybe I am just nit picking, still a good article. :)
Robert Martin, Martin Fowler, and many others, say 'program to an interface' (fowler) and 'never subscribe directly to someone else's framework' (martin). So, the rationale: build and use your own API to communicate with theirs. And use your Adaptive (design pattern: Adapter) Factory (design pattern: Factory) API religiously throughout all your client code. Or, in this case, PowerShell scripts. Which should use your own translating library. Yes, it's extra work. But becomes necessary sooner or later. This happens all the time. Nothing is immune: Azure, okta, AD, LDAP, CentOS vs Rocky Linux, Solaris v9-12, Perl v5 <-> v6, browser-based Javascript, Python v2.7 vs v3.6, or PHP4 vs PHP5 vs PHP6. Have fun with all that, man. Peace.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
