So here's another rant about Microsoft inconsistency and UN-usability of their products (sorry but I cannot hold this anymore)..
Since it's been introduced years ago, Microsoft Powershell looked very promising, with its CMDLet approach to reuse scripts, not only for sysadmin tasks, but for almost everything Microsoft.
There is only one problem with it (still nowadays): inconsistency.
The reason why I say this, is because most of the times (I am serious, most of them) I try to use Powershell, I get the famous error message:
The term '[Put your Powershell Module name here]' is not recognized as the name of a cmdlet, function, script file, or operable program.
That seems like a trivial error, so the next thing to do is to install the missing module.
This generally requires a few steps:
- Figure out which module contains the command you are trying to run (not always straightforward).
- Figure out which version of the module contains the exact command you try to run (different versions of Powershell (several available by now) might use slightly different syntax or parameters in commands...
- Install the module (assuming you already installed all its dependencies, otherwise it won't install).
Besides the poor documentation about the different modules for each version, etc., the main issue is that even following the above steps meticolously, won't guarantee that you can finally run your command.
In fact, it turns out that doing a quick search on my machine for "Powershell", I have more than 10 folders containing Powershell modules...
C:\Program Files\WindowsPowerShell C:\Program Files (x86)\WindowsPowerShell C:\Program Files\Microsoft Azure Active Directory\Powershell C:\Program Files\Microsoft Application Insights\Status Monitor\PowerShell C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell C:\Program Files (x86)\Microsoft SQL Server\140\Tools\PowerShell C:\Program Files (x86)\Microsoft SQL Server\130\Tools\PowerShell C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Powershell C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\jgvvk40b.4cw\Starterkit\Extensions\powershell C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\4gsxi3yc.1xk\Starterkit\Extensions\powershell C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\uqch3mzq.qv5\Starterkit\Extensions\powershell C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\5rr1fg2l.ml1\Snippets\PowerShell
And of course each one is not visible to the others..
The obvious questions are: why each single (Microsoft) application installs yet another folder and cannot reuse a main one? And why 2 versions, 32 and 64 bit? And why the new installation can't take care of cleaning up/upgrading what's already installed?
Don't even bother answering, as nothing new here...
And on top of this PowerHell, I decided to skip my machine altogether, and rely on the "official" Microsoft Cloud Shell, which is basically Powershell baked into Azure.
Well, surprise surpise, even there, running the command "New-AzureADPolicy ..." returns the same old error:
The term 'New-AzureADPolicy' is not recognized as the name of a cmdlet, function, script file, or operable program.
You would think that Azure Active Directory CMDLets are installed in Azure.. wrong!
At least not for the AzureADPreview one..
Fair enough, so I ran the command: Install-module AzureADPreview
No luck, same error, even after installing the right module...
Now, eventually after lots of wasted time, I managed to run the command inside Powershell ISE (yet another different way of running Powershell scripts...), and have my policy created in Azure...
But still, go figure, Microsoft...
