Archive for September, 2015

Automatically signing into Yammer Embed from SharePoint Online

21 September 2015 1 comment

So Microsoft have dropped the SharePoint Yammer app and are advising you to use the Yammer embed libraries to embed your Yammer feeds in your SharePoint site.  Sweet you think I can do that you set it up embed it on your page and everything works fine.

For the first day.  After that you find that you just have the Yammer Login button and you have to click that and sign-in once a day, or more, to get the feeds to work.

Does this sound familiar?

Maybe you raise a ticket with Microsoft but the only answer you get back is “it is by design”, like that is any help.

Well after one, now ten, of those calls and still being told it is by design I now agree with them it is by design, and with some small tweaks you can get it to sign-in seamlessly almost all of the time.  (I say almost because I’m sure there are some cases where it won’t) and surprisingly it isn’t the only service that is affected.  I’ll explain.  But first let me set up the environment.

The SharePoint I’m going to focus on is SharePoint Online.  The licence includes Yammer Enterprise and that is also setup.  Single sign-on has been setup for the Office 365 tenant.  In my case, the customer in question was also using AD FS to provide a seamless sign on experience.

Happy Days

Time for a picture:


Ok.  So you can see, that the happy day scenario (i.e. no cookies, first time access or similar) the flow is like this.

User hits SPO (1), it says “I don’t know you visit  (MSO)”.

Browser redirects to MSO (2).  (at this point, perhaps after a few more redirects) the user is directed to the organisation sign-in server (Corp) (3) and the chain bubbles back with each node receiving the user identity (4 & 5) and setting a cookie so they can remember who it is.

Now the user is back in SPO the Yammer Embed attempts to load.  Yammer doesn’t know who the caller is so it redirects the user to MSO (7).

MSO knows who the user is, thanks to the previous call, and returns this information to Yammer.

Yammer now displays the feed requested.  This is the same, or similar, for other services that are included in the SPO display such as the SuiteLinksBar ( part of the Office 365 header) which comes from (Portal) (8).

Sad Days

Ah.. that is how it should work, and it does for 8 to 12 hours.

Another picture.


The user requests a SPO page.  SPO still has an active identity so doesn’t redirect to MSO and just serves the page. This includes a Yammer feed.  Yammer has forgotten who the caller is so redirects to MSO to find out.  This is as per the happy day flow.  But now the cookie that MSO held with the identity has expired.  (That is an assumption, don’t repeat it as fact.  Whether or not it is because the cookie expired or the token MSO received from Corp was given has ended it’s lease, the result is the same.)  MSO does not know who is making the call.  Here is where it goes bad. 

This time instead of MSO redirecting the user to Corp it just returns to Yammer without an identity token and Yammer displays a sign in button.  (A similar pattern happens for Portal)

This actually makes sense (hence by design) as MSO at that point doesn’t have control of the user interface so can’t really prompt the user or direct the user away.  Bummer but that is how it is.

So why didn’t SPO’s identity expire?  The SPO team, to keep the experience nice will keep their identity cookie fresh so the user isn’t repeatedly asked to sign-in.  In fact all the services in this process do that. Yammer, SPO, the Portal and any other services or add-ins you’ve included on the site are the same.  The problem is without the regular call backs to MSO the cookies on the frontend expire later than the MSO ones so some services will still load, others won’t.

Keeping MSO Identity Fresh

Is there anyway to keep MSO cookie/token fresh?

Yes, Microsoft have some documentation buried deep that has a solution but is almost impossible to find.  But you can find it here, in section 6.4.  The technique is called a “smart link”.  The idea is simple, provide a short, really friendly URL, that redirects to the very unfriendly URL that SPO sends to MSO when there are no cookies present.

I was recently asked, if it really mattered since the user didn’t see anything different.  YES it does, it makes a huge difference as I’ve just explained.

The smart link is the concept anyway.  We don’t actually need to use the precise URL we use a smarter variant.  The URL we want to smart link is:

You will need to adjust the highlighted parts for your environment.  The WHR parameter tells MSO where the Corp AD FS server is.  The WREPLY parameter tells MSO where to redirect once the identity has been confirmed.

By using this smart link as the browser home page, or by using it as the published link to access the SPO site you ensure that MSO first has a chance to revitalise its cookies/tokens and then when it is asked can provide the identity of the caller to any service that requests it.

There are some instances where this is probably not going to work, like someone who only accesses SPO by opening documents.  But if this link is their home page then the chance of that is highly unlikely.

What about on premises

If you are on premises environment is setup to use Windows Authentication directly then it probably won’t work. 

If you have Yammer SSO set to authenticate using an on premises AD FS server and have your SharePoint environment authenticating with the same AD FS environment then, yes you probably can use this technique. Just use fiddler to find the URL for your environment and you can smart link people to that and it should have the same result.


Complex problem, simple work around.  That is all, my customer went from walking away from Yammer embedded feeds to embracing them more, all because they didn’t have to sign-in every time they wanted to see one.

Categories: SharePoint