Master & Cmd-R

Office 365 Password Reset (self-service options)

Option 1: “I know my password, but want to change it”

The 2010 version (wave 14) of Office 365 didn’t have a self service option for end users to change their passwords, and required them to send an email to their administrators if they wanted to make a change. Thankfully, the 2013 update of Office 365 has added that functionality right into the portal, and made this process much easier for the end user.

Here’s how you do it:

1. From anywhere in the Office 365 portal, click the gear icon beside your name, then click Office 365 Settings:

5-27-2013 3-49-05 PM

2. Select the password option on the left hand side of the screen that comes up

5-27-2013 3-49-59 PM

3. Type in your old password, then type your new password in and confirm it in the box below. Click Save and you’re done!

5-27-2013 3-50-29 PM

This is an option I’ve been wanting to see since the day I started using Office 365, it’s a huge time saver and it eliminates the need for users to ask an administrator every time they need to reset their password. Note that if a user has forgotten their password, they will still need to use the second option to get it reset.

Option 2: “I forgot my password!”

Office 365 (2010 version) never used to allow users to reset their passwords, unless they were administrators. If an administrator needed to reset their password, they could do so from the logon screen by clicking on Can’t access your account? If your users have forgotten their password, they can use this option to request a password reset.


Once here, you can fill out the password reset form and click Next. This will email a temporary password to the email address that you specified when your account was set up as an administrator.

If you were not an administrator in your Office 365 tenancy, you would get this response:

5-27-2013 6-36-40 PM

Office 365: Naming Your Tenant

 When setting up your account in Office 365, it’s important to consider what you want to name your tenant before you make your account live. “Tenant,” you ask? If you’re not familiar with this term, think of it this way: Office 365 is a multi-tenant cloud, which basically means that the one huge cloud domain ( has many tenants, or clients – kind of like a big apartment building with multiple apartments.

When you create your Office 365 account, you set up your domainsuch as And here’s the important bit – once you’ve chosen a name, you can’t change it!

According to Technet:

The name of the tenant appears in Lync invites and SharePoint Online, but Microsoft does not currently have tools to rename a tenant or migrate data from one tenant to another. If you change your mind later, you have to create a new tenant and manually move your data and settings.”

Even though you will add your own domain and use it for Exchange and Lync, whenever you send out a Lync invite it’s going to be coming from (for example). And while you can name your Public SharePoint site to whatever you’d like, your internal SharePoint site is going to be Not very pretty, and bound to cause some trouble when users have to try and remember that URL.

So take some time when setting up your tenancy and make sure that your domain name makes sense and isn’t too long or confusing to your users – you’ll be glad you did!

Exchange Migration Errors

Recently while performing a migration from Exchange 2003 to Office 365 (wave 15), I ran into a few mailboxes that were failing the migration with the following error:


The error sounds pretty straightforward, and the general recommendation on the community forums is to delete these accounts and start over. Makes sense… these are user accounts that were created before I started the migration, so maybe they were corrupted? …except for the fact that there were some other users that had previously been created whose mailboxes were migrating just fine. So I checked the accounts in Office 365 and sure enough, their user accounts did not have Exchange Online enabled!


I enabled their Exchange Online licenses, and they were caught in the second round of the migration… might not be the solution for everyone, but definitely a sweet little fix!

Office 365 Email Migration Options

This is not meant to be an exhaustive, how-to post… just more of a run through of the different strategies available for migrating to Office 365 from various email platforms, and my experiences with them.

1. Exchange to Office 365

This is the smoothest method available – if you have Exchange 2007 or later,* Office 365 will auto-detect your settings and migrate your mailboxes to the cloud with minimal fuss. And (even better), this also grabs your distribution groups and email aliases on your mailboxes! Definitely my favourite way to go if I have access to an on-premise Exchange server to migrate from.

* Exchange 2003 requires manual setup, and is a little tricker to set up – but once you have your connection, works just as well as the newer versions.

2. IMAP Migration

IMAP Migration is what you’d use if you were going from another hosted provider – whether they be Google Mail, or even another hosted Exchange. This method of migration has several drawbacks, and is my second least favourite method of migrating mailboxes into Office 365.


  • These drawbacks include:
    • IMAP migration will only grab the inbox and Mail enabled folders – it will not pick up your calendars or contacts, so you’ll need to manually export those to a CSV or ICAL file.
    • Requires setting up a CSV file with email addresses and credentials for all the mailboxes to be imported – there is no intelligence to find your mailboxes and distribution groups.
    • Migration control is funky – once you’ve started a migration, it needs to run a full pass at all the mailboxes before it will start over and rescan the mailboxes. This means that if you’ve found errors (of which there will be plenty), fixed them and then re-ran your migration, it simply picks up where it left off – it doesn’t go back over and rescan your mailboxes for changes.
    • It takes a long time – a small migration of around 35 users ran for almost two weeks on its initial scan without ever completing its initial pass. By the time we were ready to cut over MX records and go live, we still needed to manually export and import mailboxes.
    • As I’ve mentioned before, there is no graceful way to stop the migration – deleting the migration batch will not run a final sync… very frustrating!

    And a couple of gotchas:

    • Won’t copy any folders with a forward slash (/) in its name.
    • Won’t copy any items larger than 35MB, and it won’t tell you what it’s skipped… it’s just a fun mystery for you to explore!


3. PST Capture

Microsoft provides a free PST import utility called PST Capture – and while it sounds like a great idea, especially in an environment where you have a lot of PSTs to upload, it is not without its own batch of headaches.

First, you need to install the PST Capture Console on a host computer – then, you install a PST Capture Agent on all the computers that you want to be able to scan for PSTs. Once you have these two components in place, the agents will report back to the console with all the PSTs that they’ve found that need to be imported. Oh, and did I mention that you need to have a copy of 64-bit Outlook installed? 32 bits need not apply!

In my experience with this tool, I found it very unreliable – even after jumping through all the required hoops to have it working on your network, it would fail on every attempt to upload a PST into Office 365. Overall, a lot more frustration then there needs to be… which brings me to my tried and true, “if all else fails do this” option.

4. PST Export /Import

If you do not have the ability to migrate from an on-premise, Exchange 2007 or greater server, this is THE ONLY OPTION I would consider. Mind you, it’s not completely automated, and it requires you to set up users, aliases and distribution groups beforehand. However, it just works! All you need to do with this procedure is walk up to each desk, export their Outlook profile to PST (which catches mail, calendar, tasks, and contacts). Once you have a PST sitting on their PC, create a new profile that connects to Office 365 and import that PST. Once you’ve started importing the PST, you can move on to the next computer and repeat the process.

The beauty of this procedure is that you don’t need to worry about when it gets up into the cloud – it might take a while to get all the information uploaded, but your user is working in the meantime, and all their data is at their fingertips. You even have the ability then to import their autocomplete data, earning their undying affection and names like “Superhero” and “Rock star” 😀

TL;DR? My final suggestions are simple – if you have the option to do a clean migration from Exchange 2007 or newer… do it. It works well, and is (mostly) stress free. If you have any other scenario, export mailboxes manually to PST and import them into clean Office 365 profiles. You’ll be glad you did.

Lync calls not routing properly

One of the biggest issues we’ve had in our new Lync 2013 installation is that calls will not route to a user when their presence shows them as in a meeting – this was an obvious frustration, because it means that the more often than not, the person whom you are in a meeting with can’t get through to you at all!

As a workaround, you had to set your presence to “Available” if you were expecting a phone call for a meeting – by no means a true, or long term solution.

It turns out that this is not a bug, but a configuration issue – According to this TechNet article the Parallel call routing method adheres to a user’s status, and will not send calls to them if they are in a meeting. Switching the call routing method to Attendant changes that behavior and allows calls to route through regardless of their presence. In fact, the only status that Attendant will not route calls through on is “Do Not Disturb”.

Here’s how you change this in the Lync Control Panel:

Click on Response Groups, then Group:

Response Group

Select the Group that you want to modify and change the routing method to Attendant:

Click Commit to save your changes.

Just to make sure your changes take effect immediately, restart your Response Group Service on your Front End server.

Problem Solved!

How to wrap up an Office 365 IMAP Migration

On a recent migration from hosted Exchange to Office 365 using an IMAP Email Migration, we ran into a bit of an issue when trying to complete the migration:

There’s no way to stop it gracefully!

It turns out that Microsoft has removed the Stop button, and have deprecated the PowerShell cmdlet Complete-Migration (see below).



Why is this a problem?

Well, the Stop command (or the Complete-Migration command in PowerShell) is supposed to contact the server and run one last sweep through the mailboxes for any changes that have happened since the migration started. Once it runs that final sweep and syncs any changes, it stops the migration and sends a report to whomever you have specified at the beginning of the migration. Since this is no longer an option, Microsoft suggests letting the migration run completely through and then waiting 24 hours after cutting over your MX records to allow it run another sweep.

However, an IMAP migration can take a very long time to complete, and it won’t run a second pass at your migration until it has completed at least once. So, if you’re under the gun and trying to complete your migration before the end of the month in order to avoid another billing cycle for your client on their old Exchange provider, you’re going to have to come up with a Plan B.


Now what? What’s my Plan B?

The answer is simple – backups! Make a backup of your OST files (Export to PST from Outlook). Once you’ve set up the Office 365 Outlook profile, you can import from the PST and it will sync up into Office 365 at its own comfortable pace, getting you out from under the gun and enjoying your weekend.

Once you’re happy that you have all your mailboxes backed up, you can pause the migration and click the delete button in the Exchange Control Panel. The does the equivalent of the Remove-MigrationBatch PowerShell command, but it does not sync any changes in your mailboxes on the server.

My final opinion:

The IMAP migration process has more glitches and gotchas than it’s worth – and here’s why:

  1. It won’t copy over calendars and contacts, so you’re forced to migrate those manually
  2. It won’t copy any folders with a forward slash in its name (/)
  3. It won’t copy any items larger than 35MB (this is the official MS word, but rumors on the community forums are that it can skip file sizes as small as 30MB – Your mileage may vary)
  4. Unlike a migration from On-Premise Exchange, it won’t tell you what has been skipped, or why
  5. It can take forever! A simple migration of 35 users ran for over a full week (168 hours) without completing a full sweep

From now on, any migrations out of a Hosted Exchange provider that I need to do, I’m going to be exporting Outlook profiles and importing them for each user. This plan of attack might take a while to get up into the cloud, but for the most part your users are not going to mind – they have everything on their computers in their Outlook profiles, and it will sync up to the cloud with no further interaction on your part. Just make sure that you have cut the MX records over first and waited a while to catch any email stragglers.

Good Luck, Have Fun!