Considerations For Deploying Live@edu–Part 1: Identity Management

Whether you’re starting from scratch, or looking at a migration, deploying Live@edu can quickly become a very big deal if you don’t plan for the future. Since joining the UK Education Team here at Microsoft I’ve had a lot of opportunities to speak to customers who have been through the process. Recently I visited Llantwit Major School in South Wales to help hands-on with their deployment of Live@edu. I spent time discussing the options for deployment and helping them plan; now I’ll share what I’ve learned with you so that you can plan your Live@edu deployment more effectively.

Identity Management

I can’t have a single conversation about deploying ‘cloud’ services these days without talking about ID management. When you provision users in Live@edu you immediately begin creating another island of identity to manage. How you decide to manage that is very important. Some food for thought:

  • How will you provision your users? The most popular ways are by using a CSV file, or a piece of software like Identity Lifecycle Manager (ILM) with Outlook Live Directory Sync. The CSV file option either through PowerShell or the Exchange Control Panel is free, but is the most manual way to manage identity and requires the most amount of on-going time to configure. ILM, however, is very automated and the process for managing your joiners and leavers can be simplified greatly using software like this to manage that task.

IdLifeMgr07_bL OR powershell OR IE-symbol_rgb

  • How will you manage passwords? It is possible to make use of the Password Change Notification Service (PCNS) with ILM to synchronise passwords, making it much easier for your end users as they only need to manage one password. This can reduce the impact on your helpdesk and is less confusing for your users. By default there is no synchronisation of passwords between your on-premise directory and Live@edu; without PCNS users would have to manage two sets of credentials. Single-Sign-On (SSO) is also an option; integrating Live@edu into a portal or VLE such as Moodle or SharePoint using the SSO Toolkit removes the need for users to know their Live@Edu password, or their username!

  • Which namespace will you use? Many schools have a single namespace, for example “”, with both staff and students having email addresses in this format. Equally, many schools opt to migrate their students first, keeping their staff on-premise. This presents a big question: who keeps their existing email address, and who gets a new one? The good news is that it is possible to share an SMTP namespace between two mail servers, so your users can be split between your local mail server and Live@edu while still keeping their existing email addresses. If you’re not looking at doing an all-in jump to the ‘cloud’ this shared-address-space scenario will make it far easier for your users as they can keep their already established identity while taking advantage of the enhanced features of Live@edu.

  • What will you do with your leavers? Many universities foster a strong and active relationship with their alumni, but in schools this is not often the case. When students come to leave your institution what will you do with their identities? You could de-provision them, removing their mail and giving them the choice of keeping their SkyDrive and other Windows Live content by choosing a new email address

These are just four things that you should consider when thinking about the identity management of your Live@edu deployment. There are many more things that may be peculiar to your institution, and the points above are by no means exhaustive but they are worth giving a few moments thought as a good, well thought out, deployment will benefit you and your users much more in the longer term than a hasty one.

If you’re looking at deploying Live@edu why not check out, a great forum where you can ask questions and get advice from other Live@edu users as well as Microsoft staff.

Comments (1)

  1. Zag says:

    I really don't get why Microsoft can't offer a small tool to synchronize with Active directory.

    Or even build it into the next active directory product like you did with exchange.

Skip to main content