September 15, 2013 Leave a comment
I posted “Office 365 and PowerShell” a few weeks back and since then have been digging into the various ways PowerShell helps manage Office 365 installations. You’ll find a robust command set that can automate a wide number of deployment and management operations.
Setup (was) pretty straightforward the last time I did it (a few months back): download and install the Microsoft Online Services Sign-In Assistant for IT Professionals Beta and the appropriate cmdlets (please see my prior article) and you’re ready to go.
Now, I’ve rebuilt my system since then, so it’s time to do it over again. However, this time, I had mixed results. I installed the RTW version of the Online Services Assistant with a reboot. Then, I ran the installation program for the cmdlets .. then I got this:
“In order to install Windows Azure Active Directory Module for Windows PowerShell, you must have Microsoft Online Services Sign-In Assistant version 7.0 or greater installed on this computer”
Huh? :: mutter :: Didn’t I just do that?
So, after a lot of uninstalls, reinstalls, reboots and more reinstalls, I ascertained there is a system check between the Beta and RTW bits that is failing. Some Bing-ing, Google-ing and swear-ing .. I came across a social post on MSDN: “Cannot install Azure Active Directory Module for Windows PowerShell. MOSSIA is not installed”, installing the Beta and then the RTW, but with an added registry fix that increases one parameter to the later version to satisfy the system check.
The fix seems to work, and the author of the post provided two .reg files: one to make the change and the other to undo it. My suggestion (as Microsoft will certainly distribute newer versions) is to perform the Beta and RTW installs, then export the registry settings so you can revert, just in case.