Recently I have been writing a PowerShell script to look at all different areas of an Office 365 tenant and produce a pretty little report. Because of the commands I want to run, my script requires numerous PowerShell modules. These include Azure AD, Power Apps, SharePoint Online, Microsoft Teams and Skype Online. It also requires a remote PowerShell session to Exchange Online and Compliance Centre. This has led me to realise just how messy administering Office 365 with PowerShell really is.
Before I even get into the heart of the issue with these modules, I first just want to call out the chaotic installation methods and naming of these modules. Nothing quite speaks to the seemingly siloed nature of Microsoft than these PowerShell modules. Some of these modules are available on PSGallery and some you have to download an executable from the web. Some of them run locally, while others run remotely. I am a simple man and I find this frustrating and confusing in equal measure.
A Pain in the Auth
The first step at the top of my script is to check that all these modules are installed. If they aren’t installed, I install them, but for some annoying reason, I can only do this for some.
The next thing I do is authenticate against the various workloads using all the different modules. Back in the day, this wouldn’t have been too much of a problem – I would have simply read in the credentials and used them to authenticate against the various workloads. Then MFA came along and ruined the party for everyone. Of course, I believe that MFA absolutely should be enabled for all Administrators in any tenant, however, it does make authentication in PowerShell a real headache.
When I run my script, I now have to enter my credentials and approve the MFA request on my phone seven times. SEVEN TIMES!!! I don’t have to do this in the browser so why on earth do I have to do it in PowerShell?
I honestly thought for a while that Graph API would be the saviour we needed. With its token-based authentication and no need to install any modules. This would be so slick and clean! But that dream fades as there is little sign of Microsoft extending Graph to the control and power offered in the individual modules.
To me, it seems that the increased security being offered for admin accounts in PowerShell, mixed with what seems to be a mixed bag of bits at Microsoft is the perfect storm of confusion. It makes me want to scream into my pillow, and I can’t imagine I am alone.
Shared Sessions?
What I think needs to happen is they need to break out the authentication entirely from each of the individual modules and make it stand-alone. Each of the individual modules could then use this authentication to make their own calls in a browser-like session. One session shared by all modules, surely that is possible? Especially if we were to pass the session in as a parameter, perhaps something like this:
$Login = Connect-Microsoft365
Connect-AzureAD -Auth $Login
Connect-MicrosoftTeams -Auth $Login
Or better still, the module could detect the presence of an existing session, much like in the browser. This would be the ideal in my eyes. Until then, I will continue with my Sisyphean life spent logging into Office 365.
Before I finish, I just want to say that I love PowerShell, despite its quirks, there isn’t much I would change about it. I often take what I like to call ‘PowerShell Holidays’ where I escape doing my actual work to write a PowerShell script. That being said, I do find myself tearing my hair our all too often when administering Office 365 with PowerShell.
Please Microsoft. Help me!
