Legal Hold can be used as an alternative to using third-party backup solutions since all emails are retained and cannot be deleted by the user or admin, except by retention policies.
Admins can place mailboxes on litigation hold or in-place hold. When you place content locations on hold, content is held until you remove the hold from the content location or until you delete the hold.
Litigation hold in O365 originally only existed for Exchange Online mailbox data, but has been extended to SharePoint Online, Teams, OneDrive, etc.
The user you wish to place on hold must a subscription that includes at least Exchange Online (Plan 2). This includes the following online licenses:
- Microsoft 365 E5
- Microsoft 365 E3
- Office 365 E5
- Office 365 E3
Users in subscriptions that include Exchange Online (Plan 1) can also be put on hold if the user has the add-on Exchange Online Archiving
. Holds only apply to mailbox data with this license.
One great advantages of hold is that the user account can be deleted after they leave the company and the data will still be preserved for eDiscovery. So you won’t be burning a license for a user who does not access their mailbox any longer.
For more information about litigation or legal hold in Office 365, read In-Place Hold and Litigation Hold in Exchange Server.
In many projects where I am involved, group-based license management involves a basic part.
Setting up the pilot users, the production groups of users and of course, defining the license assignment that should be applied to each group.
For smaller tenants with simple requirements license management is not a big deal, but as you can imagine for larger tenants, automation is essential, and scripting could be a good approach, but sometimes could be challenging when complex licensing scenarios appears.
So what we can do in those cases? Use Azure AD Goup license Management! It’s a great solution included in our subscriptions and the only requirement that we have is to have Azure AD Basic, which always it is included
Ok, sounds great but what about limitations?
- Nested Groups: are not supported. If you try to apply a license to a nested group, only the first-level user members of the group will have the licenses applied.
- Security Groups: You can ONLY assign license to security groups. Security groups can be synced from on-premises or you can create security groups directly in Azure AD. Also you can go ahead with O365 groups, is it a supported scenario
- Inheritance: Inherited group licenses cannot be modified directly on a user. Not supported… if you need to change a license from a user, you will need to delete this user from the group
- Office 365 Admin Portal: no support for group-based licensing. You will have to administer it through Azure Portal. Remember, AAD are shared between O365 and Azure
- Conflicting service plans: Some service plans are configured in a way that they can’t be assigned to the same user as another, related service plan. For example: The E3 product contains service plans that can’t overlap with the plans that are included in E1, so the group license assignment will fail. To resolve this issue, you need to disable conflicting features.
- Dependencies: for example, licencing group could have a feature enabled that was dependent on another that wasn’t enabled.
That’s all for now!