Recently, I’ve been working on trying to finish up a migration from Exchange Server 2010 to Office 365. There are potentially numerous mailboxes that aren’t used and those won’t be migrated to Office 365 because there’s no sense in paying for licensing for them. How do you determine what mailboxes are in use? First, use implicit remoting to load the Exchange cmdlets locally. Years ago, I would install the Exchange cmdlets locally, but it was brought to my attention that it’s unsupported, at least according to this article: Directly Loading Exchange 2010 or 2013 SnapIn Is Not Supported.
One of the companies that I support is currently in the process of migrating from an on-premises Exchange Server environment to Office 365. They’re currently running in hybrid mode. While it seems like wanting to know what mailboxes still exist onsite versus which ones are in the cloud would be an all too common task, there doesn’t seem to be an easy way to get that information with PowerShell. You would think that you’d be able to run a PowerShell command and it would return the results.
You’re the administrator of an on-premises Exchange Server 2010 environment that’s in Hybrid mode. After migrating a few users to Office 365, you start receiving complaints that they’re no longer able to send emails as their departments group. First, follow the instructions in one of my previous blog articles to Connect to Office 365 using PowerShell. The following command grants John Doe the ability to send as the Facility Services group in Office 365.
There are several scenarios where you might need to assign an Office 365 license to a user. The specific scenario in this blog article is that you’re migrating an Exchange Server 2010 on-premises environment to Office 365. The Exchange Server is already in hybrid mode. Users have been automatically created in Office 365 by synchronizing them from your on-premises Active Directory environment using Azure AD Connect. Users who haven’t already had their mailbox moved to Office 365 will first need an Office 365 license assigned to them, and before a license can be assigned to them, a usage location must be set on their individual account.
I’ve recently been working on a project to migrate an Exchange Server 2010 environment to Office 365. As with Exchange, there are several things that simply can’t be done from the GUI in Office 365. This means that if you’re the Office 365 administrator for your company, you’ll need a certain level of proficiency with PowerShell to effectively do your job . While not requirements, this blog article is written using Windows 10 Enterprise Edition version 1803 and PowerShell Core version 6.
You’ve implemented Azure AD Connect to synchronize accounts in your on-premises Active Directory environment to Azure AD. If you took the defaults while running the setup wizard for Azure AD Connect, then everything in your Active Directory environment is synchronized. If you decided to filter the synchronization later to only specific OU’s (Organizational Units) in your Active Directory environment, you could run into a scenario where the number of deletions exceeds the default threshold of 500 objects.