Archive for the ‘SharePoint’ Category

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

SharePoint 2013 Ratings and Internet Explorer 10+

18 March 2014 7 comments

You may have noticed that the star ratings have changed in SharePoint 2013 to utilise the theme of the site, or you may not.  If you haven’t seen them they look like this…


Well most of the time they look like that. But sometimes, when using IE10 or above, they look like this…


So what is going on here?  After some looking at the code, decompiling, investigating it seems to be an sequencing problem.  Here’s my breakdown.

The RatingFieldControl renders the following HTML:

<span id="RatingsCtrl_ctl00_PageOwnerRviewDateBar_..."></span>
<script type="text/javascript">
    EnsureScript('SP.UI.Ratings.js', typeof(SP.UI.Reputation), function() {
        // Do Stuff
<div style="display: none;">
    <img id="RatingsLargeStarFilled.png" src="themedfile"></img>
    <!-- other img tags for different parts of the ratings -->

Well obviously it is is a little more, I’ve distilled it down to the basics.  The first span is filled in by the function included in the script tag.  The last hidden div is used for the script to populate the image files that are required.  And therein lies the problem.

When using fiddler to investigate the problem with rendering in IE10. I could see that the loading sequences when I pressed enter in the address bar vs pressing the refresh button vs using IE8/9 were different.

When the display bug occurs it appears that the EnsureScript, which is part of the Script on Demand libraries, executes immediately since SP.UI.Reputation is already loaded.  This means that when the script goes to find the images it can’t find them because they haven’t been rendered to the page yet.  The simple fix is for Microsoft to change the rendering sequence for their control, as there are private methods involved it isn’t possible for us to just overwrite the render method, and even if we did then our control wouldn’t be the one used in most cases.

There are two solutions I can think of:

1. Calculate the themed source files and specify the images yourself.  This is probably not ideal as a change in the theme will change the files you want to point to, and these can’t be predicted.

2. Re-execute the script after the page has completed rendered to the browser.

I’m going to look at using option 2:

Without going into full details, here is the solution add this JavaScript to the page (I already have jQuery library loaded):

$(function () {
    if (SP.UI.Reputation != null) {
        $('[id^=RatingsCtrl_] ~ script').each(function() { 

How does this solve the problem?

The first line is shorthand for wait for the document.ready event so ensures the script isn’t loaded until after the page has finished loading.

The IF statement detects if the SP.UI.Ratings.js. I could use the EnsureScript here as well, but by checking this way, if the script is still waiting to be loaded then the emitted script above will still be waiting to execute so we won’t need our little hack.

The function line 3 calls the RatingsHelper method responsible for the reading of the img tags for use by the script and thus forces these to be reloaded.

The last block finds, using jQuery selectors, the script blocks associated with the Ratings controls and executes these statements again.  Forcing the display of the star ratings to be updated correctly.

And there you have it, the simplest hack I could find to correct what could easily be done by Microsoft switching a few lines of code around.

Categories: Programming, SharePoint

Automating SharePoint build and deploy #NZSPC

This year I presented at the New Zealand SharePoint conference how to build and deploy SharePoint solutions automatically with TFS.  Here is the presentation.

Categories: Presentation, SharePoint

New Zealand SharePoint Conference

18 February 2013 Leave a comment

I just thought I’d confirm here that I’ll be speaking at the New Zealand SharePoint Conference this year in April, make sure you grab your tickets now.

SPC NZ 2013 Im speaking

Categories: Life, SharePoint


31 January 2013 Leave a comment

So awhile ago I mentioned automated versioning of components during a TFS Build.  At the time I suggested Chris O’Brien’s approach, which is a good simple approach.  However, if you want something a bit more powerful take a look at TSVersioning.

TFSVersioning is a codeplex project that has heaps of versioning goodness and good documentation to match.

It is really easy to add to build process just following the instructions they have given.

When using this with SharePoint projects the only limitation I found was that you needed to apply the Assembly Version Pattern which obviously you don’t want to do with SharePoint.  This appears to be a limitation in one of the embedded XAML files.

If you want to remove this limitation then just do the following.  Download the source code (I’m using the version.) and open the solution in Visual Studio.

Find the VersionAssemblyInfoFiles.xaml file and open up the designer.

Find the node that task that says “Validate then process Build Definition Values”.  Chagne the “Or” in the condition to an “And” so it reads “String.IsNullOrWhiteSpace(AssemblyVersionPattern) And String.IsNullOrWhiteSpace(AssemblyFileVersionPattern)”.


Compile the project and use the DLL instead of the one included in the package.

The other XAML and flows already allow you to specify either the AssemblyFileVersionPattern or AssemblyVersionPattern, just not this flow.

Note:  Version 2 has been released for TFS2012, I do not know if that version has this limitation or not.

Categories: Programming, SharePoint

Automating SharePoint build and deployment–Part 4 : Putting it together

6 December 2012 Leave a comment

This is the fourth, and probably final, in a multipart post about automating the build and deployment of SharePoint solutions.  The other blog posts are:

In this post we will put all these bits together to form one process from check-in to deployed solution.  Again as in the rest of this series this post is going focus on the principles behind this task, and how we went about it.  It is not going to give any code.

The parts

So far we have built an automatic deployment script, got automated builds happening that build the package for deployment.  Now we need to get the automated build triggering a deployment into a staging or test environment.

We could use the lab management features of TFS Team Build to handle this, and that would be good way of going.  But the approach we decided to use was chosen as the only dependant tool is PowerShell, the other active components can be replaced with anything that will do that task, which there are a few to choose from.

For our team, in order to leverage the work that had been done by other teams just before us we decided to use TFS Deployer to launch the deployment based on changes to the build quality.

PowerShell Remoting

In order to allow TFS Deployer to do its job we need to enable PowerShell remoting from the build server (as the client) and our target SharePoint server (as the server). 

To setup the SharePoint server open an elevated PowerShell prompt and enter the following commands:

Enable-PSRemoting -force
Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000
Enable-WSManCredSSP -Role Server

This script enables remoting, increases the size of the memory available and then allows the server to delegate authentication to another server.   This enables our deployment script to issue commands on other parts of the farm if required.

The build server is our client so there is a little more work to do from the client.

# Enable Powershell remoting on server
$SharePointServer = "SharePointServer"
Enable-PSRemoting -force
Set-Item -force WSMan:\localhost\Client\TrustedHosts $SharePointServer
Restart-Service winrm

# Enable client to delegate credentials to the a server 
Enable-WSManCredSSP –Role Client –DelegateComputer $SharePointServer

#Also need to edit Group Policy to enable Credential Delegation

Further information on this entire process can be found at Keith Hill’s blog

TFS Deployer – The agent in the middle

TFS Deployer is the tool we have chosen, it is not the only one, to detect the change in the Build Quality and launch the scripted deployment on the chosen environment.

TFS Deployer had got a good set of instructions on their project site.  To simply our environments we run TFS Deployer on the build server.

In order to simplify the process for our many clients and projects we have TFS Deployer call a generic script that first copies the project specific deployment, after interrogating the $TfsDeployerBuildDetail object for the location of the files.  It then calls that deployment script to execute the deployment.

The project specific script file is also reasonably generic.  It first copies the packaged output (see previous posts) to the target server.  It then remotely extracts the files and executes the deployment scripts from inside that package.  Of course, in this scenario we know all the parameters that need to be passed so we can conveniently bypass any prompting by supplying all the parameters needed.


That ends the series.  Unfortunately it has been code light, as I was working through the process and trying to capture the philosophies rather than the actual mechanism.  Hopefully you have learnt something from reading these posts and picked up a few tips along the way. 

As stated in the first post the purpose of this series was to put together and understand our build framework and requirements so that I could build a new version using the TFS Build workflow mechanism.  I believe I now have that understanding, so I can start that work.  Perhaps doing that work will lead to a few more blog posts in the future.

Automating SharePoint Build and Deployment–Part 3

22 November 2012 Leave a comment

This is the third in a multipart post about automating the build and deployment of SharePoint solutions.  The other blog posts are:

  1. Introduction
  2. The Deployment Package

In this post we will look at the build itself.  Again as in the rest of this series this post is going focus on the principles behind this task, and how we went about it.  It is not going to give any code.


If we are doing SharePoint solutions, surely a quick build from the Visual Studio environment, and a package from there, will produce the correct output for us.  Why should we go through the pain of automating the build process?

That is a very good question.  Here are a few reasons:

  • Ensure that the code can be built consistently from any development machine
  • Ensure that everything required for the build are in the source control repository.
  • Ensure that what is in source control builds.
  • Ensure regular testing of the build process.
  • Ensure rapid resolution of a broken build.

But of course it comes back to down to the big three we mentioned in a previous post:  Simplify, Repeatable and Reliable.

Simplify – Because in this case we are simplifying the work we need to do, and the associated documentation required.

Repeatable – Because we need to be able to repeat the process.  Maybe the build won’t be built again for a year, but we need to ensure that when that time comes we can do it.

Reliable – Because as long as it builds the output is known to be built the same way, and in the same order.

But the most important reason of all.  It is not hard to set up.


The build process only needs to do one thing.  Change the source code to the deployment package we talked about in the previous post.

One of the advantages of automating everything is that we can ensure that all parts in the process are tagged and labelled so that we can find the exact code that was used to generate the components running in production. 

In order to do that we are going to need the following actions performed:

  1. Automatic increment of a version number.
  2. Labelling the source code with the above version number.
  3. Stamping of all components with the build name, and version number.
  4. Build of the source code
  5. Package the built binaries into WSP packages, for SharePoint.
  6. Package of the WSPs, and our Deployment scripts into the package.

That seems like a lot, but as you will see most of that can be performed by the Team Foundation Build services.

How? – Building the solution

Team Foundation Server (and the service offering) make this a really easy task.  From Team Explorer just expand the build node, right click, select “create a new build definition…” and follow the wizard.

There are a few extra things that you will need to do to build SharePoint projects though:

  1. SharePoint assemblies need to be on the build agent.  Chris O’Brien has this covered in his post Creating your first TFS Build Process for SharePoint projects.  While not recommend to install SharePoint on the build server, we have installed the binaries on the server but NOT configured it as a farm, which would kill the performance of the server.  We also install Visual Studio, but this again is not necessary or advisable.  I suggest that you follow the How to Build SharePoint Projects with TFS Team Build on MSDN as that provides  good alternatives and clearly lays out the process.
  2. /p:IsPackaging=True needs to be added to the MSBuild arguments parameter so that TFS will tell MSBuild to also perform the SharePoint packaging tasks and create the WSPs.

How? – Versioning

Every .Net assembly contains two version numbers: the assembly version, which is used in the strong name and thus needs to be bound into a lot of the element.xml files.  And the file version number, which is just that a number.

Therefore for our purposes the file version number is adequate, not to mention less complex to implement, to track the running components back to the source code.

We will also need to use the version number as part, or all, of the build number and ensure that the source code repository is labelled with the build number as well.  Fortunately TFS Build already performs these actions for us.

Chris O’Brien has a simple workflow extension, and instructions, based on another derivative work.  For further information and for how to extend the TFS build template to include this versioning see part 6 of his continuous integration series.

How? – Packaging

Once the build has done the work of building the assemblies and the SharePoint packages the next step is to package these artefacts into the deployment package we mentioned in the previous post.

The team I was part of did this in the old TFS 2005 format (which used MSBuild) by extending the PackageBinaries target.  In addition we were able to separate the definition of the package from the creation of the package by using MSBuild include files.   This has made the solution developed incredibly easy to implement and highly reusable even though it is in the MSBuild format.

To integrate this with the newer TFS build workflows we just need to modify the build workflow to call this target at the appropriate place, after the components have been built.

The process for packaging is really quite simple:

1. Build the package in a staging directory structure by copying the output files from the appropriate place.

2. Zip up the staging directory.

3. Ensure that the zip file is included as a build output.


Last words

So now we have talked about the overall strategy, the deployment package and how we create the deployment package.  In the next post we will tie all the parts together to show how we can get all the way from the code to the running SharePoint server, every, or almost every, time that someone checks in some code.