Brief history of Live@edu management agent and how you can upgrade form one version to another

It will seem like a random entry into this blog, but it really is not. I was running with Microsoft’s Live@edu program for a very long while (and still actively working with it, in more of a partner / project management / role);  so I have fairly large number of ex-clients who are sporadically dropping me a note with a question; here is one of the question that I’ve got recently, perhaps my answer will shed some light on the brief technical history of live@edu program and it’s development

So here was the question:

When MAv3 first came out, the documentation provided only gave instructions for a new install, not an upgrade.  Do you have a set of instructions handy that you could share with me so that I could perform the upgrade in place?

And here was my answer:

First of all I have to denote that internally (to Live@edu program it is) most of the public milestones are marked by releases of MIIS/ILM management agents. Currently (the end of 2009) we are having an array of management agents released into the wild. Reason for counting milestones by MIIS/ILM management agent is rather simple. Once the back-end changes/enhances new management agent for automated provisioning of accounts need to be updated to use those new features. Hence the de facto naming convention:  MAv1, MAv2 and MAv3… I have heard people internally pronouncing it as "Ma-av One", "Ma-av Two" instead of "Em Ay One",  "Em Ay Two" ect ;

Well, quick answer to this question is "you simply can’t install new software on your side and call it done"; at least when we are talking about upgrade form MAv1/v2 to MAv3. Allow me to elaborate:

In the timeframe of "Hotmail" MAv1 and MAv2 communication between client and back-end server infrastructure was implemented in very direct fashion. Management agent would make two separate calls to Microsoft’s back end systems; firstly it would call to Windows LiveID servers and reserve/create the Windows LiveID for future mailbox. Upon (successfully) completion of that call another call to another web-service is initiated, this time it is Hotmail servers. Management agent provided Hotmail with newly created Live ID and initiates the creation of mailbox itself.

Sounds simple enough and reasonable logical; however, Hotmail and Live ID are two very deferent entities. Live ID is global identity provider / authentication system that serves hundred if not thousands services like Hotmail, Messenger, Spates, Sky Drive and now is open for anybody to consume the LiveID as an identity. The authentication methods and APIs exposed to external clients are world (or at least a blog post) in its own. So allowing external connection to back-end Hotmail takes an act of god, since it is a tap into the core of the Microsoft’s publicly available and highly exposed system. Going though legal processes and technical security hoops was a trip. You can see how why there was an static IP requirement and security certificate installation, permissioning, ect. On top of that it was taking physical time for Live@Edu team to actually negotiate on client’s behalf establishment of this type of connection to LiveID back-end.

After LiveID connection part of the equation was solved, Live@edu guys were negotiating a hole in the Hotmail defenses as well. There was no "blanket" agreement for everyone on live@edu side and Hotmail side, so all settings were processed manually during each client enrolment.

As you can see this process worked fine for a long while and was "technically correct" solution. Make right calls in the right order and voila – you have managed LiveID belonging to educational institution. However for Live@edu to scale this was less than acceptable. So there comes MAv3 timeframe:

Live@edu sponsored (more or less) a development that now called "Windows Live Admin Center" (Bing it here) It’s previous name was "Custom Domains").  In short Live@edu abstracted all back-end calls to LiveID and Hotmail via single API of "Admin Center". Admin Center got lots of documented (and rather simple to use) APIs that allowed user to make a programmatic call to a single web-service, create new LiveID and mailbox with a single call and not worry about any other details. Admin Center would create a LiveID, Hotmail mailbox and use blanket agreement between live@edu and those services to perform such operation. So no wait for Hotmail team, no wait for Live ID team, no need for IP registration, no need for proxies, everything was abstracted and accessible without dependencies of individual contracted between each Live@edu client and each back-end system in use. Admin Center is old news, we are talking like 2007 timeframe, but it is alive and kicking, you can take a look at those APIs here on MSDN.

At this time (September/October 2009) Live@edu moved-on way beyond the MAv3 with Admin Center APIs. Current hot pancake is "Outlook Live".  Outlook Live is a hosted Exchange 14 (Exchange 2010) solution. It is full-fledged and fully operational Exchange provided for students absolutely free. It comes with browser based OWA and can be hooked to fat Outlook and to whatever client you want. Even though I know the answer for the question "why this is free", it still boggles my mind. Not only you get full exchange with ever-growing mailbox quotas for free, but you also get all the admin management benefits with remote PowerShell and via web front-end.

So Outlook Live comes with its own Management Agent. It called ELMA (Exchange Labs Management Agent) [I’ve actually "fathered" this name for the product and it stuck! LOL] My little claim to fame!

By contrast to Hotmail MAs, Exchange team rejected the notion of connection to LiveID or to Admin Center from the ELMA. Outlook Live provided users with very rich interface via remote Power Shell. So all clients that are having Outlook Live as an email platform using ELMA which communicates directly with back-end Exchange farm (not Admin Center or LiveID web services or anything else);

In the last couple of years ELMA underwent several releases. Most current version (ELMA 4.0 which is in beta as we speak) shipped as part of a GalSync solution (complete unattendant synchronization between on-premises data-source(s) and hosted Exchange). That’s a whole separate topic of conversation or entire dedicated blog site.

Anyhow current ELMA is pure Power Shell commandlets based solution; ILM calls ELMA and it executes commandlets on remote server, which, in turn,  doing all the work on the back-end (call Admin Center, Live ID, Exchange back-end farm, Active Directory back-end or whatever they might need to call)

Returning back to your "conversion steps" question… as you can see it is a little tricky to simply re-install the Management Agent on your end and call it quits.

So why is the conversion process from "legacy" MAv1/v2 systems not straight-forward?  The most obvious reasons are:

a) "Admin Center" stores a cash of all users during creation of every account. So whenever account was created outside of those APIs those accounts will have to be ported on the back-end; which could be performed whenever you ask for it, but it is not something you can do from your end.

b) Service agreements between your institution and Hotmail/Live ID are already established. Those agreements will have to be broken and re-established via Admin Center in case of Hotmail offer or the Exchange in case of Outlook Live.

Both of those operations take time and have to be coordinated with all services as well as with your institution. I know for certain that it is more than possible to do, but you need to ask for it, and need to realize what it would take for your institution to migrate form legacy hotmail to Admin Center (MAv3) or to Outlook Live (Exchange 2010/ExchangeLabs/Exchange 14)

So now you know everything… and I am wondering whether I will get a call from somebody with request to shut-up. LOL

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: