Few months back, I did a quick review of the freshly GA’d PowerShell Core in the context of running your day-to-day Office 365 related tasks. As expected, it didn’t perform that well. Due to the various dependencies on the underlying .NET binaries, every Office 365 workload that required a module was a no-go when run in Core. Only the good old Remote PowerShell for Exchange Online worked, and only when using Basic authentication.
Well, things are slowly starting to change now. Although still not officially released, there is a new version of the AzureAD PowerShell module which adds support for PowerShell Core. How do I know that? Because this is what Azure Cloud Shell uses:
Yes, it’s a Preview version, as the name implies. But it most definitely isn’t a Private Preview version, or only available via the PSGallery Internal repository, as everyone using Azure Cloud Shell has access to it. And since you have the module installed in ACS, you can just grab it and start using it on any other endpoints utilizing PowerShell Core.
To get the module, simply copy it from the path shown above to your clouddrive directory, which is exposed into the Cloud storage File structure. Once the module is copied there, you can use any number of methods to export it, for example by clicking the Connect button from the Azure portal and copying the PowerShell cmdlet. Then, just start using it:
If you examine the module code, or simply browse the directory, you will notice that two versions of the binaries are provided, one for the “full” version of PowerShell, so .Net 4.7.1, and another one using .Net Core. We are more interested in the latter, which is automatically selected when you load the module in PowerShell Core host.
One of the improvements of this version is the option to trigger the OAuth Device code flow, which is a nice workaround to use on devices that cannot utilize the ADAL dialog for interactive login. In case you are not familiar with this flow, in a nutshell it allows you to use another device to complete the auth process. In fact, this is the default method used by Connect-AzureAD in this version of the module, as shown on the screenshot below:
Connecting via other methods, such as directly providing an Access token or using a certificate-based authentication should still be possible as well. Regardless of which method you use to connect, the most important part is that cmdlets actually run OK now, compared to the JSON exceptions that were being generated when using the GA version of the module. Thus, you can now perform pretty much any operation via the Azure AD module, with some examples shown below:
While this *is* still a preview, judging from the amount of debug information spilled by the module and the fact that you cannot actually find it yet in the PSGallery, the method used in this article should get you a viable solution for scenarios where you want to manage Azure AD outside of a “traditional” PowerShell console. Or you can just head over to https://shell.azure.com and use the module directly 🙂