Moving Yammer Networks to Native Mode for Microsoft 365

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.