Office 365 and on-premises Exchange offer some native means of protection against losing precious data. Lately, a lot of changes have been introduced in the Exchange Security & Compliance Center. A retention policy and a litigation hold can be used to add a layer of protection against data loss. At first glance, they seem similar: they both are accessed from Office 365 Security & Compliance Center and serve the same purpose. However, in the table below you can see that there are some differences and they are not minor.
This article shows, step by step, how to easily migrate Exchange public folders to an Office 365 shared mailbox using CodeTwo Migration software. The article also contains a guide on how to create a shared mailbox in Office 365 and how to access it from a mobile device.
Why migrate public folders to a shared mailbox?
You might wonder why should you even bother. How is this migration better than a straightforward transition to the target server public folders? There are two reasons why you might prefer shared mailboxes over public folders:
- You can easily access shared mailboxes via a mobile device
- They can let you save money, as shared mailboxes do not require separate licenses in Office 365
No matter what the reason is, recently more and more companies decide to migrate their organizations to Office 365. And as the businesses operate in the cloud, companies more frequently ask for the steps to go further and migrate from one Office 365 organization to another.
But surprisingly there is no convenient native way to perform this type of move. Even Microsoft suggests using a third party tool to accomplish this administration task. Having this in mind, I will show you how to easily migrate mailboxes between Office 365 tenants using CodeTwo Office 365 Migration.
Disclaimer: This article is not an “Email Spoofing 101”. Spoofing examples are presented only for testing and prevention purposes.
Ensuring email security might be one of the most important and most difficult tasks an administrator must face. Every day, servers process thousands of emails and controlling such a big mail flow is not easy. No wonder hackers focus on this channel when they plan attacks. They use various tricks to make users think that opening a suspicious attachment is a good idea.
One of the tricks they use is email spoofing.
Personal Storage Table files (PST) were introduced to the Microsoft world back in times of Exchange 4.0, as Outlook exclusive, storage files. They were meant to store individuals’ non-enterprise data coming from IMAP and POP3 mailboxes. Soon enough that became a quick fix to stacked up corporate Exchange Servers allowing users to store excess mailbox data to their local drives. What seemed like a brilliant solution, soon proved itself to be quite the opposite. In this article, I’ll show you why it is a bad idea to use PST files as a backup for your Office 365 data.
PST files were never meant for across network management
Any type of an over network management of PST files is an unsupported, highly not recommended, and time-consuming process, often resulting in corrupted files. Its administration over LAN or WAN is very heavy on servers causing network overheads and even server crashes. Learn more about it from the Microsoft Knowledge Base. Having multiple operations like this proceed simultaneously also significantly slows you’re your computer operations down. There is no possibility to automatically synchronize these files between devices in Microsoft Outlook. And saving them to the Cloud results in nothing more but an overfilled cache.
Once you have completed a hybrid configuration in your company, it turns out that the job is not done yet. After a quick verification whether the hybrid is set up correctly, you notice that some of the users are not synchronized properly. And if that is the case, you need to do some additional adjustments. If you hit the roadblock during the synchronization it is most probable that the problem will be related to user synchronization between local Active Directory and Azure AD. Common causes for this are:
- Lack of rights to Organizational Units (OU) or AD objects (users, groups or computers) for a service account used by Azure AD Connect (AAD Connect)
- The improper scope of objects synchronized with Office 365. In other words, perhaps an OU that contains a certain user object, group or computer was not selected in the AAD Connect configuration wizard.
You can encounter these problems when you run the synchronization from on-premises AD to Office 365. But this can also happen the other way round when you run the synchronization from Office 365 to on-premises AD or in both directions. Look at the most common scenarios here:
- A user has an Office 365 account and no local AD account;
- A user has an account in Office 365 and in local AD (this user had two accounts before the hybrid configuration was implemented to have access to services offered by Office 365);
- A user has an account in Office 365 with an Exchange Online license assigned as well as an account in local AD with an on-premises Exchange mailbox (a single user has two separate mailboxes).
In this article, I will show you how to manage these situations in an environment with hybrid configuration and Centralized Mail Transport enabled.
A user has an account in Office 365 but not in local Active Directory
For some of you this may sound a bit disturbing, for some may be exaggerated, but preserving emails is one of the essential tasks any business should be aware of. In most organizations, emails hold very important or even critical data, which guarantee business continuity. That is why having a backup copy of emails seems to be something obvious, but it also seems to be underestimated at some point.
Outlook rules help users organize their mailboxes. Thanks to them, sieving spam from important messages can be more automatic and users mailboxes can look less chaotic. That is the bright side of Outlook rules. The less bright side is that users highly depend on them and every time there is an issue concerning the rules, admins find themselves to be in the eye of the storm. You can remain calm, though, as I will show you how to manage users’ Outlook rules using PowerShell. But first, you have to know the difference between the two types of those rules, to learn what you can do with PowerShell and what requires a direct intervention in the users’ email clients.
Server-side rules vs. client-side rules
Outlook rules can be either server-side or client-side. Understanding the differences between them is crucial for an admin, as the type determines when they are executed and which cmdlets can be used to manage them.
When you set up a company-wide email signature on Exchange or Office 365 using, e.g. the built-in transport rules feature, you will probably want to verify whether it is correctly added to messages.
The most straightforward and foolproof method is for users to send a test email to you so you can check it.
Or, if you feel like taking a crowdsourcing approach, just have each user send the email to themselves and check the details, etc. personally.
The problem with both those methods is that they rely upon users correctly understanding your request, complying with it and carrying it out properly, all without assistance. Realistically, you have a higher chance of randomly meeting Bill Gates walking down your street with a pet iguana on a leash, than for all 3 of these circumstances to come together magically.
As in many cases, here also PowerShell scripts can save you a lot of time and effort.
Thanks to PowerShell, you can easily verify the activity on a shared or a user’s mailbox on Exchange (on-premises and Online).
The cmdlets that come in handy in this situation are:
- Get-MailboxStatistics, which lets us check the Last logon time on a mailbox,
- And, of course, Get-Mailbox