Enabling Yammer Enterprise with SSO in dev/test Office 365 environments

This is the 3^rd article in my Challenges in Office 365 development – and how to address them series. Today we’ll focus on Yammer – for my team, it’s increasingly common to do small bits of development around Yammer, and so having the right set-up in dev/test environments starts to become important. This could be non-coded approaches such as use of the “Yammer Embed” approach such as showing the feed for the “Development” group in Yammer on their team site home page, or using Yammer for comments on an intranet page. But we also find ourselves implementing simple things with the Yammer API, such as automatically adding users to a Yammer group when they are granted access to a team site. With these cases, you really want the behaviour in test environments to be exactly the same as in production. But before we go any further, let’s put this in context of the overall series content:

• Challenges in Office 365 development – and how to address them (background)
• Implementing AD integration with Office 365 using a sub-domain for dev/test
• Enabling Yammer Enterprise with SSO in dev/test Office 365 environments (this article)
• Using Azure Deployment Slots to implement dev/test/production ALM for Office 365 apps and SharePoint Add-ins

Why Yammer Enterprise is important in dev/test environments

Let’s be clear, it *is* possible to develop for Yammer without having Yammer Enterprise – and the two scenarios I mentioned above can indeed be accomplished with the free version of Yammer. But it’s also fair to say you’ll hit some trade-offs around user identities and single sign-on (SSO) between Office 365/Yammer. If you have multiple Office 365 environments (e.g. dev/test/production), you’ll most likely be in a situation where only production has the true user experience that end users will see. This might be acceptable to you, but equally it can make things challenging for testing (“OK, but just imagine you don’t have to sign-in here!”)
Specifically, the things you’ll miss without Yammer Enterprise are:

• Users have to manually register with the Yammer network (or be invited) using their e-mail address – this step will create their Yammer profile
• Single sign-on will not work – any Yammer functionality on your pages (e.g. a feed, or a “Like” button) will show a link to sign-in to Yammer, and navigating to the main Yammer site will also require sign-in, rather than just automatically passing you through
• All of the Yammer features which come with Yammer Enterprise, such as the reporting and administration tools

On a related note, developers using Yammer Embed will notice the “use_sso” flag on the JavaScript object in the Embed code (see https://developer.yammer.com/docs/single-sign-on). From memory, even with Yammer Enterprise enabled this has to be set to “true” to avoid the behaviour listed in the 2^nd bullet point above.
Also, it’s probably also worth mentioning that there are different flavors of SSO with Yammer. Here I’m referring to “Office 365 SSO with Yammer”, but note it was always possible to implement a form of Yammer SSO before Office 365 came along – this was typically using a SAML-based IdP (such as ADFS) for both Yammer and your other corporate systems. Depending on your organization’s situation, even if you use Office 365 you may actually find that you can actually only use “plain” Yammer SSO, rather than Office 365 SSO (e.g. you have users without e-mail addresses or multiple Yammer networks). See https://support.office.com/en-us/article/Office-365-sign-in-for-Yammer-b1745e3c-d4d7-4e20-a155-ebf85106b998 for more info.

A note on licensing and other pre-requisites

So, we’d like to use Yammer Enterprise even in dev/test environments if possible. However, this does require licenses for any user who will access Yammer since we’re going beyond the free version. Consider the following:
· If your dev/test Office 365 tenant is on an Enterprise plan (e.g. E1, E3) your users will automatically have a Yammer license – these do not need to be assigned in the Office 365 tenant admin screens
· If you’re on some other kind of plan (e.g. a SharePoint-only plan such as SharePoint P2), then you can “additively” pay for individual Yammer license as a bolt-on – these do need to be assigned to individual users
In addition to licensing, another key pre-req is that Yammer Enterprise can only be activated on an Office 365 tenant which is integrated with a custom domain - in other words, your user accounts will be “chris@mycompany.com” rather than “chris@mycompany.onmicrosoft.com”. This would either be done in the normal way during the initial set-up process, or for dev and test environments you could use the approach I discuss in Implementing AD integration with Office 365 using a sub-domain (for dev/test)
But assuming licensing and domain integration are in place, you’re good to go with Yammer Enterprise.

HOW-TO: configure Yammer Enterprise for an Office 365 environment

Go to Office 365 tenant admin dashboard, then click “Included Services”, then on the right of the page, click “Yes, activate Yammer Enterprise for my network”:

You’ll then be asked which domain you want to use for Yammer – assuming you only have one verified/integrated domain, you’re simply confirming you want to proceed:

At this point, the Yammer network provisioning process starts:


Once complete and you see the above message, you should be able to click the “log in to Yammer” link and sign-in. On the next screen, some home realm discovery stuff kicks in and detects that you can be signed-in on your current identity without providing a password:

From there you can complete the sign-up wizard – adding any Yammer colleagues, joining/starting groups, and adding a profile photo:

And voila – you now have Yammer Enterprise!

If you haven’t done already, you should switch the Office 365 tenancy to use Yammer for social:

Once all these steps are complete, you’ll know the Yammer network is a Yammer Enterprise because you should see the additional administration tools:

Summary

So that’s how to enable Yammer Enterprise in an Office 365 tenancy being used as a dev or test environment (or production for that matter – the process is the same). If you go through this process, your dev/test Office 365 environments should behave just like your production environment. This can often be an important point for testing, especially around mobile devices and other non-domain joined devices, and especially where Yammer Embed or any custom Yammer functionality has been implemented.
This series will continue to discuss options and techniques for improving Office 365 development. Other posts:

• Challenges in Office 365 development – and how to address them (background)
• Implementing AD integration with Office 365 using a sub-domain for dev/test
• Enabling Yammer Enterprise with SSO in dev/test environments (this article)
• Using Azure Deployment Slots to implement dev/test/production ALM for Office 365 apps and SharePoint Add-ins