Archive for the ‘ Live@edu ’ Category

Career Changes

After many years of working with Microsoft as a contractor (vendor) I have finally caved-in. I am very excited to announce that I’ve accepted a full time position with Microsoft Corporation. As of January 4, 2011 I have joined Office 365 Deployment Team. The hiring process in Microsoft deserves a separate blog entry – it’s a long winding trail (more like an obstacle course) where coming out on the other end is its own reward. The lesson that I’ve learned (over and over again) is: patience is a virtue.

So… what does is mean for this blog. Well, being inside of the “mother-ship” and being part of the “mother-ship” is a little deferent from each other. As a Microsoft employee I represent Microsoft’s official “party line”, therefore some topics could be covered in slightly deferent manner. Naturally, I am expecting my perspective(s) to change a little bit, as I will become more exposed to the inner-workings of the “machine”. Nevertheless, I don’t expect any drastic changes; after all I was hired for who I am. Wish me luck, it should be a cool ride.

Live@edu OLSync on FIM 2010

This week I have completed yet another Live@edu engagement with FIM 2010. It appears that here in Schakra we are receiving more and more requests form Live@edu customers who are wanting to use FIM 2010 as a platform for Live@edu instead of ILM 2007.

Why FIM 2010 is not offered yet to Live@edu folks?

I have been asked by end-customers why Microsoft is not offering Forefront Identity Manager 2010 within Live@edu program.
The answer is rather simple. Live@edu is a marketing program that is offering variety of Microsoft products to educational sector for free. Most notable that is hosted Exchange 2010 solution; however there is plethora of other products that Microsoft is packaging under Live@edu umbrella. SharePoint Server, Online version of Office 2010, SkyDrive, Spaces, etc. As you can guess Live@edu team is NOT the owner of all those technologies. Each technology belongs to a team that develops and supports it; Exchange 2010 is naturally belonging to Exchange team, SkyDrive and Spaces are Windows Live team, and so on.

So why is it still ILM 2007? Answer is that when Exchange team started development of ELMA (thereafter OLMA) then GALSync and finally OLSync (finally for summer 2010 that is) when there was no FIM 2010 in site. Back two years ago when ELMA 1.0 was on the design board (I was part of the ELMA 1.0 team) the name of “Forefront Identity Manager” was not even conceived yet; it was ‘ILM 2’ at the time with no defined released date and no clear upgrade path available in writing. On top of that, as you know, Microsoft offers full-fledged Premier Support for all Live@edu customers (which is rather amazing, considering that this is free offer); So for “mother-ship” to offer something like that, it would take a lot of confidence in the product, and therefore offered solution got be tested and over-tested and tested again… hence the lag with the offer of FIM 2010 to Live@edu customers.

In the meanwhile, you can rely of Microsoft partners such as my company Schakra. Deconstructing OLSync and reconstructing it on FIM 2010 is something we certanly can offer. If you need/want your Live@edu or custom OLMA (Outlook Live Management Agent) solution running on Microsoft Forefront Identity Manager 2010, give us a call, we’ll be happy to help you setting things up and supporting it.

Converting Mailboxes to Mail-Users with ILM for Exchange 2003 AD

After couple of weeks of working with a client of mine in Boston area, I’ve learn more about Exchange 2003 than I care to learn, and wanted to share some snippets of information with my fellow-Outlookers.

Using ILM as a migration tool

First of all, I have to say that, for better or for worse, proverb "if all you have is a hammer, everything looks like a nail" applies very nicely to the method I am about to describe. In short, I have managed to set-up ILM server for the tasks that are traditionally done with other tools (mostly scripts). I cannot advocate this usage of the product, nevertheless if you are "fluent" with ILM you will find that this method have its advantages over any kind of script.
Firstly, ILM will provide you with staged environment. Any bulk operation that script would perform directly on your AD, ILM would stage and allow you to have a chance to analyze pending exports before actually committing changes to the directory. Secondary you will get to use managed code vs. script language, which is a better choice, in my honest opinion.
On the flip side, setting-up ILM just to perform migration process is an overkill. Not only you’ll need to install Windows Server, SQL Server, ILM Server, OL Sync with all dependencies and apply all Service Packs, you also need to install Visual Studio. All that takes time; if you don’t have that time (or desire to install all this stuff) you might want to consider using scripts which are not require any "infrastructure".

So what do we need to do?

In the scenario when school converting their student mailboxes from on-premise AD with on-premise Exchange 2003 to hosted Outlook Live solution, and intending to use OL Sync (GAL Sync) you will need to figure out how to convert existing student user accounts with mailboxes to mail-enabled users… in bulk. Reason being for this requirement is an OL Sync "rule". Outlook Live Sync will automatically create mailboxes in the cloud, based on your Active Directory information. Every mail-enabled user (an Active Directory user object with mailAlias and targetAddress populated) will receive corresponding mailbox in the cloud. However user with mailbox on-premise will NOT have a mailbox created in the cloud (which is understandable; there is no reason to have two mailboxes)
It is all sounding simple enough, until you are looking into details of such operation. How do we exactly going to convert thousands of users with mailboxes to mail-enabled-users?
Let’s flashback to year 2003… Exchange 2003 fully relied on AD to provide "key" attributes that will identify a user object as a mailbox-deserving or mail-enabled-user object. UI of Active Directory Users and Computers was taking care of all of those operations by simply pre-setting some attribute values in AD; in turn, Exchange 2003 would "sense" those values and act accordingly to create a mailbox or append mail-enabled user to its GAL. There were NO direct calls to Exchange server form the snap-in itself (to my knowledge). As it turns, all we need to do, it to figure out which attributes are responsible for identification of mailbox vs. mail-user and "voila" — we have got ourselves a conversion machine.

Outlook Cash

There is another thing to remember. Prior to migration, teaching staff could have emailed to a student from their Outlook. That operation was performed as from on-premise to on-premise email operation. After migration is done, should a teacher use Outlook to email to the same student again, he/she would likely to use "auto-complete" feature that will pick previously resolved address for a student, which would be incorrect, since on-premise mailbox for that particular user is no longer present in on-premise Exchange. It was replaced with mail-enabled user object; As a result, message will bounce back and teacher will likely to make a phone call to tech support.
Boston colleagues of mine, did not fancy the idea of talking with their teaches all that much, so we had to figure out how to solve this dilemma during migration.

So what did we actually do?

Outside of running IMAP mail-content migration process and providing password synchronization between on-premise and the cloud (Outlook Live) environment for all new and existing users and figuring-out email flow during split-namespace scenario, we had to figure out how to convert existing users with mailboxes (MBX) to mail-enabled-users (MEU).

Deleting attributes:

As I have mentioned before several attributes in AD are responsible to "linking" mailbox in Exchange 2003 mail-store with an actual user account. Delete or modify those attributes and Exchange mailbox will lose its "connection" to the user in AD. Augment some user attributes and Exchange 2003 will identify that user account as a mail-enabled user object, which will be displayed in local GAL (visible to all teaching staff, which will keep mailboxes on-premise)
So what are those magic attributes?
Before somebody in Exchange team or Microsoft legal team gives me a call and kills me, I want to say that if you are about to perform this operation – you are doing it at your own risk. I (or anybody else to my knowledge) cannot guarantee that this will work for you. So please test and do plenty of backups before editing your production directory.

To "sever" user form his/her on-premise mailbox I’ve deleted values in following attributes form every student account:
homeMTA; homeMDB; mDBUseDefaults; mail; msExchHomeServerName; msExchMailboxSecurityDescriptor; msExchMailboxGuid; msExchALObjectVersion
To mark user as a "mail-enabled-user":
I’ve set value of Windows Live ID for each particular user to "targetAddress" attribute and to "mail" attribute
I’ve set "mailNickname" attribute value to be user’s ‘left’ side of the Windows Live ID value (to the left form @ sign)
I’ve set value of "false" to "iMAPIRecepient" attribute (this was optional)
To address "Outlook Cash" issue (see above):
I’ve stored value of "legacyExchangeDN" and added that value with a prefix of "X500:" as one of the entries in "proxyAddresses" attribute.


All that was performed with ILM 2007 with a single Active directory Management Agent configured to import and export mentioned-above attributes, and rather simplistic extension code that ensured formatting attributes.
It took several days to go through procedures and meetings, however in the end we have had clean conversion and good tractability – thanks to ILM logs with every operation on every object being captured.
ILM provided nice platform for reviewing upcoming changes on user objects as well as a way of communicating with AD

Relieving the pain of EASI IDs

While deploying Outlook Live with power-shell CSV parser (CSV_Parser.ps1) at the customer site I’ve learned firsthand that dealing with EASI (Email As Sign In) IDs is a pain in a rear. To my knowledge there is no easy way to enumerate all pre-existing Live IDs that have been reserved by individual students before the university registered a domain for usage with Live@edu program; therefore during initial deployment administrators likely to see several "Alias already reserved as EASI ID" errors.
I would strongly recommend using -LogDirectory switch with your CSV_Parser.ps1, to capture all events, successful and otherwise, during your deployment. Generated log file is very useful for post-processing and analysis; You should also know that you’ll be seeing rather bulky log file containing more information that average administrator cares about. What administrators should really care about is to capture all IDs that have NOT been successfully provisioned, and retrieving that information form the log is rather tedious exercise for a human.
Ta-Da! Behold the ErrorParser.PS1 script that doesn’t mind digging through very large logs and picking all failed-to-provision-IDs!
Here is the URL for downloading:
Many thanks are going to the in-flight internet access and hellishly long flight-time from the East Coast to the West Cost of The United States of America. As a true-to-the-core-geek that is bored to tears during cost-to-coast flight, I’ve found pleasure in writing a PowerShell script (no comments please!  LOL) which is attached to this post. Feel free to download and use it for all your re-provisioning correction-measures needs.
You might also want to read following article about evicting or importing EASI IDs:

Group Management in Live@edu

First thing I want to mention is that topic of Group Management is an ongoing work in progress. I suspect that subject of Group Management will be at best incomplete and probably will become obsolete faster than any other topic that I’ve recorded in the series of podcasts for Live@edu partners. Nevertheless, I would like to present my take of Group Management within Live@edu program to anybody who is interested in the subject

This podcast was recorded shortly after release of R4 (Release Four) version/wave of Outlook Live offering and reflects present state of offerings (Late 2009/Early 2010) regarding group management within Live@edu.

I am touching on dynamic group management with PowerShell with Exchange 2010 (core product behind Outlook Live) as well as more custom approach to group management with ILM 2007 (and theoretically with FIM 2010, if you wish) called Group Populator.


GAL Sync vs. OL Sync vs. OLMA vs. ELMA (have I missed anything?)

If you are looking into this your search engine must caught one of the key words in the title. At the time I was recording this podcast the R4 release (is this is a tautological statement?) of Outlook Live just have been released and I was flying around The World to promote Outlook Live and educate Microsoft Partners on new features and specifics of Outlook Live program.

I encourage you to take a look at this podcast if you are trying to understand what exactly Outlook Live offering(s) are/is and how it is deferent form custom Identity Management solution.

I believe that understanding all your options and clearly grasping underlying technologies in every offer from Live@edu team will essentially produce better-built end-client solutions and in the end will culminate in the better end-user (student) experience.

Take look at "GAL Sync 2010 / Outlook Live Sync Intro":


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