Saturday, March 09, 2013

Finding Office 365 Cmdlets–It shouldn’t be this hard

I’m working on some courseware for Office 365, Microsoft’s online office product. I have a small business subscription - www.reskit.net, for example is the hosted SharePoint external facing site, and you can get me at tfl@reskit.net. I love the product as it was pretty easy to setup, and works well in practice.

Last week, in preparation for an upcoming training course I began documenting how to get it all setup. I have the cmdlets on MY local workstation, but need to show delegates how to find, install and use them on their systems. I spent several days trying to find these cmdlets – and even went so far as opening a support call with Microsoft, although 2 days later I’ve still had no reply.  But after some considerable amount of effort, I’m sorted. Let me show you how I , finally, got things sorted:

I started at the MS Online Portal and click on the Setup/Overview which brings up this window:

 

image

Easy, you might think, just click on Learn More link for Module For PowerShell (highlighted above). Ok – So I click on this link and get this:

 image

The page has moved. Nothing new, you might say, as Microsoft does this thing all the time. But good on Microsoft for pointing out where the content was moved to! I figure things have changed in Microsoft’s haste to get the new versions of Office 365 out and it may take a while (Ed: 3 weeks??) for the first page to point to the right place. But the redirect link is better than a 404 – so I click that redirection link and get this:

image

Hold on. I wanted the Office 365 cmdlets not the Azure AD cmdlets. Now it may well be that it’s Azure that ultimately manages O365’s AD. But how do I know? What I am looking for is not what I’ve found. Heck, if I wanted Azure cmdlets, I’d have searched for Azure in the first place, not Office 365. And worse, these have been relocated too! But  there’s a relocation link so maybe not al is lost.

So I click on the link but that just takes me back to the parent node in the table of contents! I’m not going to repeat my rant about the lousy skins MS have foisted on hapless users and how poor the decision to scrap the Class skin was and how hard the TOC now is to use. But even putting that to one side, pointing to a TOC parent doesn’t make much sense.  But then I look carefully at the resultant page:

 

image

Notice the little note (highlighted above) that says the cmdlets have been renamed. Why couldn’t the very first page on the Online Portal have mentioned this? Or on then first redirection (these content has moved and has been renamed). So the mystery is getting closer to being solved.

So off I go, download these ‘new’ cmdlets (which don’t sound like what I need, but I’m willing to try). But when I try to install the cmdlets, I get told it needs the MSOID Client. So I find that, install it, and try to install the cmdlets again. Whoops – it turns out I need the old .NET framework (I am working on Server 2012 for all these demos). And for reasons best know to some pointy haired boss, the 3.51 Framework has been removed, by default, from Server 2012. So I search out the ISO image, and do the magic incantation:

Add-WindowsFeature NET-FrameworkCore –Source d:\sources\sxs

With that loaded, I try to install the Cmdlets again, the installation succeeds. So off I go looking for the Azure AD cmdlets – but there aren’t any. The module loaded was NOT named Azure (as the web pages seemed to indicate I needed), but MSOnline (which of course is what I wanted all along). But they work. HORRAY. But it took days of effort and following what looks like very incorrect links – I just wanted Office 365 stuff, not Azure, or a lesson in MS product naming (i.e. Office 365 is Azure, except when it isn’t, etc., etc.)

Note to Microsoft: you really need to do a better job here. Please fix the original page to a) point out the right cmdlets, b) point out the renaming and c) that there are pre-reqs and where to find them. Finally, please put the renaming front and centre – especially when what was renamed wasn’t actually renamed. Folks (and I know I am not the only one) get confused with stuff like this.

Summary: It’s taken 4 days of looking and searching to find something that doesn’t sound right, but ends up being so. It really shouldn’t be this hard. I wonder if the new Office 365 exams will test the skills that are REALLY needed to install these cmdlets? Smile

Technorati Tags:

6 comments:

RoHeVe said...

It is even weirder :) Office 365 seems not realy a product, but refers to a suite of other products that are connected (MSonline,now renamed; Exchange Online; Sharepoint Online; Lync Online).
When you start using Office 365, you instal the Microsoft Online Signin Assistant and then install the Microsoft Online Powershell Administration module (now renamed to something Azure Directory, which is actuall also exists for login, but is again a different thing).

They packages yoou need used to be linked to on the office 365 portal pages, but as you discovered, the links go nowhere usefull now.

Also If you install DirSync you need to ignore all things mentioned as pre-requisites for the other 'servers' like ADFS. It is not mentioned NOT toinstall MSOL Signin Assistant, but because you did install this prerequisites a few times for other servers, you tend to automagically do that when preparing your server for DirSync too. However, the dirsync installer installs those themselves and reports a FAIL if you already installed the MSO Siginin Assistant, without any other clue as to what happened (it even removes all logging when rolling back what it did). As it turns out, the package in the dirsync installer was slightly older that the downloaded and installed standalone package. As Microsoft did not publish version information for the downloads, it is a bit of black magic.

RoHeVe said...

It is even weirder :) I.m.h.o. Office 365 seems not really a product, but refers to a suite of other products that are connected (MSonline,now renamed, to log in; Exchange Online; Sharepoint Online; Lync Online).

When you start using Office 365, you instal the Microsoft Online Signin Assistant and then install the Microsoft Online Powershell Administration module (now renamed to something Azure Directory, which actually also exists for login to the azure portal, but looks like a different thing).

They packages you need used to be linked to on the office 365 portal pages, but as you discovered, the links go nowhere usefull now.

Also, if you install DirSync you need to ignore all things mentioned as pre-requisites for the other 'servers' like ADFS. It is not mentioned NOT to install MSOL Signin Assistant, but because you did install this prerequisites a few times for other servers, you tend to automagically do that when preparing your server for DirSync too. However, the dirsync installer (the 64-bit version you got when downloaded between feb 2012 and okt 2012 at least) installs those themselves and reports a FAIL if you already installed the MSO Siginin Assistant, without any other clue as to what happened (it even removes all logging when rolling back what it did).

As it turns out, the package in the dirsync installer was slightly older that the downloaded and installed standalone package. As Microsoft did not publish version information for the downloads, it is a bit of black magic.

Unknown said...

One other note, I am still sitting on a WIndows XP box and while there seem to be installs for the Powershell and all the components for XP out there, I can't seem to find an XP version for the AD Module. Really frustrating. Why buy a house if you can use the furniture! Really! Bringing in my W7 box tomorrow. It really shouldn't be this hard though. >:(

Unknown said...

Though Powershell, SignIn Assistant and all the requirements work under XP I have search high and low for the Azure AD Module for XP and get zilch. Very frustrating to build a house where the furniture doesn't fit. >(

Thomas Lee said...

Lori.
Amusing that you post this comment today, the day Windows XP goes end of life. If you want to use Office 365 cmdlets, you need a later version of Windows.

Thomas Lee said...

Lori - thanks for your second post. To some degree, I think about your house comment a little like I think about my first house. I first bought a house in 1977. It had 'solid fuel' central heating (aka a fireplace and a hot water boiler). The only way to have heat all the time in the winder was to have a fire going in the fireplace - but that meant stoking the fire every 3-4 hours and adding more coal. To resolve the issue I had to upgrade. If you want to use the latest and greatest software, the vendor will often demand a minimum OS - in the case of some MS products, MS is demanding Windows 8.1 (eg PowerShell v5 beta). It's the price of progress - for me to be able to use the new version, I have to upgrade my OS from Windows 8. I do feel you pain. But as I have said elsewhere - it's time to move on.