As mentioned a few days ago, Microsoft will enable the Outlook Newsletters feature in August for all users who have both Exchange and SharePoint service plans.
The license requirements are described in the documentation about Outlook Newsletters.
Newsletters is available to be enabled for any users with valid Microsoft Entra ID accounts who have both an Exchange Online mailbox and access to SharePoint. Exchange Online standalone plans that do not have access to SharePoint are excluded.
Then I asked myself: Why does Outlook Newsletters require a SharePoint service plan?
The reason is explained here:
Draft Newsletters and comments on Newsletters are stored in SharePoint Embedded.
In this case, users need a SharePoint Plan 1 or Plan 2. A SharePoint Kiosk plan, which is included in Frontline licenses (like F1 and F3), is not supported for SharePoint Embedded containers, at least in theory. With Microsoft, enforcement of licensing requirements isn’t always consistent; sometimes the system just creates the container, regardless of whether the assigned license technically qualifies.
When users create a new Outlook Newsletter (not a new edition), SharePoint provisions a new SharePoint Embedded container with the name of the newsletter.
Users with the SharePoint Embedded Administrator or Global Reader role can find these containers in the SharePoint admin center by filtering for ‘Outlook Newsletters’. The newsletter authors are assigned as the owners of the container.
The container application ID for Outlook Newsletters is 155d75a8-799c-4ad4-ae3f-0084ccced5fa.
You need the corresponding application ID to list all Outlook Newsletter containers using SharePoint Online PowerShell.
The ContainerId points to my Microsoft 365 Newsletter (demo) container. As usual, Microsoft still doesn’t provide a valid OwningApplicationId in the results. This appears to be a challenging issue, one that has been there since Microsoft introduced SharePoint Embedded containers.
When users upload content to a newsletter edition, Outlook stores it in the associated SharePoint Embedded container. Currently, only image uploads are supported, but if Microsoft expands support to include videos or other file types in the future, these containers could grow rapidly.
Microsoft states that the container is intended to store draft versions of newsletter editions, but in my testing, the files remain even after the edition is sent.
Neither users nor SharePoint admins have direct access to these containers, which means the stored content cannot be deleted. Yes, you can delete the container, but doing so will also delete the entire newsletter.
Microsoft has still not provided an API to access or manage the containers provisioned by its own services, although they mentioned plans for Q4/2024.
The core issue with SharePoint Embedded Containers
The core issue with SharePoint Embedded containers is their impact on your SharePoint storage and the limited administrative control Microsoft provides. If you’re using these containers, there’s only one party that benefits: Microsoft
An area Microsoft gives you no real control over:
- Every SharePoint Embedded container counts against your organization’s SharePoint storage quota.
- SharePoint Embedded containers don’t support storage quotas and can grow up to 25 TB, as each container is essentially a non-accessible SharePoint site collection. Microsoft confirms this behavior in their documentation for Loop containers. It applies to all types of SharePoint Embedded containers.
Loop workspaces have a maximum size of 25 TB. This limit can’t be increased or decreased.
- SharePoint Embedded containers bypass all tenant-wide SharePoint storage limits, growing unchecked while quietly consuming your available capacity.
In my view, a SharePoint Embedded container is a storage bomb that consumes resources uncontrollably.
For Outlook Newsletters, I strongly recommend:
- Limiting who can create new newsletters.
- Changing the OutlookNewslettersAccessLevel setting in your default OWA policy to ReadOnly.
Set-OwaMailboxPolicy -Identity "OwaMailboxPolicy-Default" `
-OutlookNewslettersAccessLevel "ReadOnly" `
-OutlookNewslettersReactions <DefaultOff | DefaultOn | Disabled> `
-OutlookNewslettersShowMore <DefaultOff | DefaultOn | Disabled>OutlookNewslettersAccessLevel
The OutlookNewslettersAccessLevelAccess parameter specifies the access level in Outlook Newsletters.
Valid values are:
- NoAccess: No access to Outlook Newsletters in the New Outlook for Windows or Outlook on the web. Users can still read email messages sent or forwarded to them.
- ReadOnly: Read newsletters and browse pages in Outlook Newsletters.
- ReadWrite: Full authoring permissions to create pages and newsletters in Outlook Newsletters.
- Undefined: This is the default value. Currently, this value is equivalent to NoAccess.
