Blog: Microsoft Teams

We're working on testing and rolling out features of Microsoft Teams internally that will eventually allow us to migrate to Teams as our Enterprise Voice. During the process, one of my goals was to get the Calendar tab working inside the Teams client so that we could see and schedule meetings on our Outlook calendar from Teams. After a lot of reading and researching, it became apparent that the only way to get this working would be to enable Hybrid Exchange so that Teams (sitting in the O365 cloud) could talk to my mailbox (sitting on-prem).

I configured our Exchange server for hybrid connection and let it sit overnight (thanks to Microsoft replication delays). The next morning, as I started looking into this again, I got a message from a coworker about how nice and helpful the Calendar tab was. I hadn't received it, yet, but was excited that it had started rolling out. Several hours later, the tab still wasn't present for me, but for everyone else that I spot-checked, the tab had appeared.

Looking through the logs from my Teams client, the error message kept saying that my mailbox could not be found. Surely this couldn't be the case because my account was set up the same as everyone else. The only thing I could think of at the time was that it had to absolutely be a permissions issue.

Continuing research over the next day or two, I discovered that the error message actually was accurate. I had attempted to migrate my mailbox to Exchange Online on a whim, but when I licensed my account in O365 for Exchange Online, it started building a new mailbox automatically. Normally, Exchange Online is aware of synced accounts that have on-premise mailboxes and will not create a new mailbox in that instance. So somewhere in the syncing process, my Azure AD account and on-prem AD account were not completely talking to each other (which didn't make complete sense, because the password hash sync was still working fine).

I discovered that the sourceAnchor (ImmutableID / ms-DS-ConsistencyGuid) between the two accounts was different. Since it's impossible to update an ImmutableID attribute, I decided to update the ms-DS-ConsistencyGuid instead. Converting the ImmutableID from Base64 to Hex, you can then easily update the ms-DS-ConsistencyGuid on the source side.

However, before doing that, I needed to clean up Exchange in Azure. You see, even if you unlicensed a user for Exchange Online, Azure will only disconnect the mailbox and tombstone it for 30 days. I needed to purge the Exchange attributes on my AzureAD account so that I didn't have to wait 30 days.

https://techcommunity.microsoft.com/t5/exchange-team-blog/permanently-clear-previous-mailbox-info/ba-p/607619

The solution is simple: Connect to the MSOL service in Powershell (Connect-MSOL), run "Set-User <upn> -PermanentlyClearPreviousMailboxInfo"

It will then give you a warning that this is irreversible. Acknowledging that will fully purge the Exchange attributes and let you start over.

I then updated the ms-DS-ConsistencyGuid to be correct, forced a sync via AzureAD Connect, wait for replication, and then enabled my account for Exchange. No new mailbox was created, as expected, and after a few hours the calendar tab showed up in my Teams client!

As more and more offerings are moved into the cloud under subscription-based licensing, it's both becoming easier for people to take advantage of software that previously may not have been as readily available, and more challenging to find a solution that doesn't involve storing your data one someone else's hardware.

Office 365 is a great example of this as it really does seem like the writing is on the wall for non-subscription licensing of the Office Suite for on-prem installation of much of the server software platform. Granted, Microsoft does make it remarkably easy to just switch over to their platform and to use all the pieces of the software suite that have been designed to seamlessly work together, but there is always a concern (even if it's tiny) that your data is in someone else's hands.

Let's look at cloud hosting from a data availability vantage point instead. The cloud makes it incredibly simple to access the platform from practically anywhere in the world – provided thie service is online. In early February 2020, there was a global outage of the Microsoft Teams platform which brought a lot of this to light. If you were already logged in prior to the outage, you were good to go. Anyone else trying to connect up after the fact was in trouble.

The cause of the outage? https://twitter.com/MSFT365Status/status/1224351597624537088

That's right, even an incredibly large organization that spends billions every year, such as Microsoft, can forget to renew their certificates occasionally. Within a few hours, the renewed certificate was deployed across their vast infrastructure and the Teams service was brought back online. While I doubt that this certificate will ever be forgotten in the future, maybe Microsoft should take the advice of one of the responders to their announcement.  https://twitter.com/nunu10000/status/1224353813987053568?s=20 

As a consumer, my biggest takeaways are this:

The Good: The Office 365 platform is always up-to-date. Any security vulnerabilities are likely patched within a matter of hours rather than waiting on a change window once a month. New features are released regularly.

The Bad: Any outage on-prem and I have a general idea how long things will take to bring it back online. With cloud services, any outage is at the whim of the service provider.

The Ugly: Knowing the above, once you're on-boarded onto a specific platform, it's usually impractical to evacuate that platform and move to another with any sort of regularity. What is the magic number for downtime to make it worth the cost of migrating services? What about if you were unable to easily or cheaply move existing data off that platform during the migration (i.e. online archive/journaling solutions)?