Table of Contents
A Better Mode for Yammer
Recently, Office 365 Notification MC206406 announced the Native Mode Alignment Tool. A Yammer network can be in one of three modes:
- Native mode for Microsoft 365.
- Non-native mode. All Yammer external networks are in this mode. As of January 2020, all new Yammer enterprise networks start in native mode (and can’t change to any other mode).
- Hybrid mode.
Native mode supports the best interoperability between Yammer and the rest of Microsoft 365.
- Yammer communities and users are managed through Microsoft 365 administrative tools. Microsoft 365 Groups (previously Office 365 Groups) are used to manage the membership of Yammer communities and Yammer respects the Microsoft 365 group creation policy. Yammer network admins need to be assigned the appropriate Microsoft 365 permissions to manage the membership of communities they do not own.
- Microsoft 365 resources like a SharePoint Online team site are configured for each community. All the files uploaded to a Yammer community are stored in a document library in its team site.
- All communities can use Microsoft 365 Live Events.
- Yammer generates compliance records for conversations. The compliance records for a discussion are stored in the group mailbox belonging to the Yammer community and are indexed and discoverable by Microsoft 365 content searches.
The last point was the thing that spurred me to action as I was keen to see how Yammer generated compliance records. More about this topic can be found here.
Plan to Move to Native Mode
Moving a Yammer network to native mode is not something that you do on a whim. It is a one-time irreversible process performed using the native mode alignment tool. Some planning is needed to prepare your network for the transformation.
I had started on the path when Yammer first embraced Microsoft 365 Groups and Azure Active Directory. The tool would now migrate the remaining parts of my tenant’s Yammer network to be in full Microsoft 365 native mode.
I was initially (often) confused when I looked at the Network Admin section for my Yammer network (Figure 1) as it appeared that the network was already in native mode. Some online advice persuaded me that this wasn’t the case, so I proceeded.

Running the Native Node Alignment Tool
The tool checks all the settings in a network and makes whatever changes are needed to transition to native mode (Figure 2). For instance, all Yammer users must have Azure Active Directory accounts, all communities must be connected to Microsoft 365 Groups, and all files must be stored in SharePoint Online.

If necessary, the tool makes changes to objects or removes items (like external users or users who can’t be found in Azure Active Directory) to make the network compliant. When the process is complete, you cannot change back to another mode. See this page for more information.
Duplicate Groups Created by Migration Runs
Although my network was small, the migration did not go smoothly. The tool got hung up on a group that didn’t have an owner and some members and went around in circles for a while before Yammer engineering did the necessary magic to allow everything to finish. The migration stopped and restarted several times, and as a result I ended up with several copies of some communities that were converted to Microsoft 365 Groups.
I ran this PowerShell command to find the Microsoft 365 Groups configured for Yammer. The key point is that the GroupSku property is set to Yammer.
Get-UnifiedGroup |? {$_.GroupSku -eq "Yammer"} | Sort Alias | Format-Table Alias, name -AutoSize
And found instances like this where the same group had been recreated several times.
Alias Name ----- ---- yammeddocs yammeddocs_497b0e85-0496-4ba0-bdaf-e311e952276a yammeddocs445 yammeddocs445_ba491901-4772-47fc-bc7a-7b45d9a16129 yammeddocs761 yammeddocs761_ccf11f4c-1486-4c48-82ad-2287b04041d5
The original group is likely to be the one with the alias without the numbers added to the end to make it unique. Before deleting anything, it’s a good idea to check that you can remove the other groups.
Cleaning Up Duplicate Groups
During a successful transition, some information is transferred to the group mailboxes used by Yammer communities. Knowing this, I used the Get-ExoMailboxStatistics cmdlet to check each group to find out where content existed. In this example, I use the group identifier as the identity to check what’s in a group mailbox.
Get-ExoMailboxStatistics -Identity 5aabcff4-118b-40f4-a033-2fd1c8d7cf6e | FOrmat-Table DisplayName, ItemCount, TotalItemSize DisplayName ItemCount TotalItemSize ----------- --------- ------------- Office 365 Questions 24 953.8 KB (976,714 bytes)
After checking several groups, a clear pattern emerged where the duplicate (bad) copies of migrated groups held no content, so I cleaned up by deleting them with the Remove-UnifiedGroup cmdlet:
Remove-UnifiedGroup -Identity yammeddocs445_ba491901-4772-47fc-bc7a-7b45d9a16129
This command soft-deletes the group, so if you make a mistake, you can restore it for up to 30 days. When this period elapses. Microsoft 365 permanently deletes the group and all its associated resources.
Identifying Yammer-enabled Microsoft 365 Groups
I also found that the Get-UnifiedGroup cmdlet supports a new method to find Yammer groups with the command:
Get-UnifiedGroup -Filter {ResourceBehaviorOptions -eq "YammerProvisioning"}
Because this command uses a server-side filter, it is much faster than fetching all Microsoft 365 Groups and using a client-side filter to check the value of the GroupSku property as explained above. However, not all Yammer-enabled groups are reported by looking at the ResourceBehaviorOptions. It seems like Yammer communities that already used Microsoft 365 Groups before the migration had the property configured while communities converted to Microsoft 365 Groups during the migration did not. Perhaps some background process will update the property for the other groups over time.
Annoying Sign Outs
One thing I’ve noticed since the migration to native mode is that Yammer is very quick to sign users out of a session. In non-native mode, Yammer would stay connected in a browser session for weeks. Now, sessions last hours before a new sign-in is needed. It would be good if Yammer worked the same way as other Microsoft 365 apps and respected whatever token refresh period is defined for the tenant.
On the upside, everything else is working just fine.
We don’t cover much about Yammer in the Office 365 for IT Pros eBook. We include the important stuff where appropriate. Maybe native mode will encourage us to do better.
Very helpful article! Can I ask how long the migration process took? I am in a similar position and looking to migrate 16 communities over to the new native mode. Thanks!
It’s been a while, but I recall that the migration took a couple of hours.
Thanks Tony, appreciate the response. Did you export / back-up your data prior to the migration? It looks easy enough to export network data, but there isn’t an option to import it should anything go wrong and it’s a bit of a grey area in the documentation. I know I should trust the migration tool, but I always prefer to have a back-up plan. Thanks!
I didn’t backup anything because I didn’t have much in Yammer at the time.
Great article!! @tony – Do you know there are any powershell/API available for Yammer O365 Native mode? Right now, we have restrictions for end users to create the teams or Groups but there is no restriction for yammer groups creation (non-native mode). We would like to automate the provision of Yammer Groups for end users in Native mode. I’m not finding any Graph APIs or powershell for the same.
I’m afraid that I don’t know how to create Microsoft 365 Groups provisioned for Yammer. I know how to find the groups used by Yammer https://office365itpros.com/2020/08/27/find-yammer-groups-powershell/ but there must be some secret sauce applied in the background when these groups are created.