The Office 365 Network is born

Ensure that every escape route and exit is still clearly visible when the lights go out

I know some of you use the Yammer Office 365 Network to seek answers and to discover new knowledge. Microsoft, in their infinite wisdom, have decided to close that network. The closure is described in this article: Announcing the public preview of the new Office 365 Network online community . It is being replaced with a new publically accessible forum Office 365 Network . The forum is not built on Yammer and its usability is questionable at best though they do say they are working on that…

This is not a vote of no confidence in Yammer or a #yamexit. It is Yammer’s strength that has forced this move. By design, Yammer is not publically indexable by the likes of Google and Bing. The lack of unauthenticated discovery allows people to converse and collaborate in confidence, safe in the knowledge that their contributions will not surface in unexpected locations, be used out of context etc. There are those in Microsoft who feel that the lack of discoverability through search by non-authenticated users is a barrier that needs to be removed.

The shift to a new publically accessible platform will cause a change in the conversational dynamics. Whilst the platform is not intended for ‘break-fix’, they still want people to use the likes of Microsoft | Community (aka Microsoft Answers) for that, it is built on forum technology which, by design, lends itself to Q&A rather than collaborative discussion. Only time will tell if Microsoft manage to keep a lid on the ‘break-fix’ and are able to foster a sense of community. Another change in this area is that Microsoft will control the creation of groups. Inevitably this will keep the focus on the products rather than the wider issues and thinking that directly influences the usage and adoption of the products.

The platform also includes gamification and you can expect to be awarded badges for almost every action. Some will find this immensely irritating and others will revel in it. The value gamification brings to building a community is questionable but it’s one of the hooks Microsoft feel they need to get people to take part.

The question remains ‘how does this affect you?’

  • You have between now and the 1st of September to make the move to the new network
  • Conversations in the new network are public and you have reduced control over any content you share
  • Any member of your staff can participate, they do not need a work account (this has benefits as well as risks)
  • It’s up to you to preserve or migrate content from the Yammer Office 365 Network. Any knowledge that you wish to retain after 1st September needs to be copied out and be aware that Microsoft will not be providing tools to help you
  • The vast majority of groups will not be migrated so if you have one for collaboration, say with your Microsoft account team or a group of like minded individuals, you’ll need to find a new home for those conversations.
    • Now could be the time to switch on external access for Yammer in your home network and invite your partners to join you there
  • You should consider communicating to staff the presence of the new network and what it is intended to be used for. You could use the opportunity to reinforce desired behaviours e.g.
    • something is broken – raise a ticket
    • want something changed – raise a request
    • not sure or want to ask – use a Group in your own Yammer network
    • have something broken on a personal device – use
    • want to request a new feature (in a Microsoft product) – use UserVoice : Customer Feedback for Microsoft Office 365
    • want to take part in the product conversations – use Office 365 Network

You may be interested in the perspectives of others on this subject:


It will be interesting to watch how this venture unfolds.

Quote and sign credited to Seton and in particular their Luminous Exit and Path Marker Signs – Door Exit Route (Right)


The perfect serve of Yammer?

Recently, I’ve been wondering whether Yammer is being developed like ‘medicine’ or ‘Coca Cola’? I’ve been typing, deleting, typing, deleting and in the process I’ve started to challenge my own thinking. I feel that I’m going a little crazy with the thought process so I felt I’d throw the concepts out there.

  • Medicine – developed through thousands of hours of research and testing. Typically, highly consistent product that should only be consumed in the way it is intended.
  • Coca Cola – developed to a level of product consistency such that each one tastes the same wherever it is consumed but it can be consumed in a multitude of ways. You don’t find ice cream floating in medicine, or use it as cooking liquor to make a ham but you can still taste the Coke in both.

My thinking is that Yammer is not medicine which you have to consume as per the instructions. Yammer makes helpful suggestions in how it should be consumed, just like a Coke bottle has best served cold on it. Items like the Discovery feed are just that, helpful suggestions to how it should be consumed. Intended to guide you to an outcome.

Yammer is part of an ecosystem that is founded upon choice and interconnectivity. The risk is that Yammer ignores the choice and interconnectivity and positions itself as medicine. For example, connectors or shared storage using OneDrive would help with the choice and interconnectivity and just like Coke they will enable Yammer to be consumed in a multitude of ways. Conversely if Yammer where medicine you’d be forced to consume it in the browser or app with a propriety file management solution.

Then again Coca-Cola did start out as medicine


Search refiners are yesterday’s algorithm

A while ago I came to the conclusion that Delve is definitely the future of search in Office 365. Delve is great for the targeted, individual relevant search, connecting people to content and content to people through the Office Graph. I believe it is the future but it is not quite there yet. The missing component from an organisational perspective is the search view and experience that the organisation wants you to have – connecting you to content that it believes is relevant to you. Currently this is possible in Search using items like Promoted Results and Result Blocks? I know it is possible today, if you want to get your coding hands dirty and you implement your own take on the Office Graph, but hands up who wants to build their own version of Delve? It’s way too much work if you ask me!

Ok I hear you say, but what about refiners. Delve does not offer many of them. But then again what do refiners really do… Refiners are yesterday’s algorithm.

A not so deep dive into what is happening behind the scenes when you view a page in SharePoint Online [Part 3]

This is the final part of a three-part post where I present my take on what is happening behind the scenes when you view a page in SharePoint Online. In the first part I discussed the components that are needed to assemble a SharePoint page and how geography has effect. In the second post, I focussed upon the processes that make significant contributions to the performance of a SharePoint page. In this post I’ll continue the focus from part 2 and in particular highlight a feature that will affect choices made in the design of solutions like Intranets in Office 365.

Search powered pages

A common design pattern, especially in Intranets, is to use search parts to render content, for example to serve content that is relevant to the user viewing the page. The calls made by search add a premium to the page load time with the premium divided into two major elements: time to fetch the results and time to render them. Our Intranet home page makes extensive use of search parts and so it has been designed to make a single search call with the results then rendered in different parts in the page. This reduces the time to fetch the results with the process to render them optimised in code. In other areas of the Intranet the pages can contain multiple search parts which in turn will make multiple calls but the performance hit is mitigated as the remainder of the page content is relatively light and simple and therefore the page load times are not unduly impacted.

Works great on premises, fails you in the cloud

The design of our Intranet takes advantage of the SharePoint Rendition Engine to serve images. Renditions work by serving up different versions of images based on pre-defined image dimensions. This is especially useful in areas of the Intranet such as the Home page where a single image could be repeated twice within the page: as a carousel image and as a thumbnail in the carousel. This avoids situations where the full resolution image is downloaded, potentially multiple times, for resizing through JavaScript or CSS. An image rendition is created by SharePoint the first time someone visits the page holding the image. Subsequent requests for the same image, say when another person browses to the page, are much faster as SharePoint simply serves the stored rendition rather than creating and serving it. The SharePoint server responsible for the creation and storage of the rendition is the ‘Web Front End’.

When comparing performance between SharePoint 2013 and SharePoint Online there is a significant difference in the number of ‘Web Front Ends’. The result is that for SharePoint Online there is a delay in the serving of the image rendition. In a SharePoint 2013 environment there is a limited number of ‘Web Front Ends’ and so, in a relatively short period of time, they would have been visited by a large number of people with the result that the caches on each server will hold a complete set of renditions. In SharePoint Online there are many ‘Web Front Ends’, in fact probably too many to be visited a sufficient number of times and so each one will only hold a partial set of renditions. Additionally, for SharePoint Online, Microsoft have had to make some performance choices that result in the caches in each ‘Web Front End’ being very small (so cannot hold many renditions) and they are regularly cleared. This results in a high number of ‘cache misses’ when a rendition is requested in SharePoint Online i.e. it looks for the rendition but one is not available. A ‘cache miss’ forces the ‘Web Front End’ to create and serve a new rendition as if the server was being visited for the first time. This adds a minimum premium of 3 to 4 seconds of page load time. This post by Chris O’Brien goes into more detail and in a follow up post he offers a potential solution (which incidentally we are considering implementing)  .

Wrap up

I hope you have found this mini-series useful. To recap:

My summary from the first post was that we can only influence the Page Content as the reminder is controlled by Microsoft. However, we can make improvements through understanding where the content is served from. These improvements should optimise access to and transmission of content from the local touch points of the Microsoft Content Delivery Network as well as from the datacentre that is hosting the tenant.

In the second post I focussed on the consumer vs corporate user experience as well differences between web browsers. Each one has a major influence on performance or the expectations around performance.

In the final part I focussed upon design choices used in SharePoint Online and in particular SharePoint Renditions which makes a significant negative contribution to the performance of a SharePoint page. The impact of its contribution may affect your design choices say when creating an Intranet in Office 365. I strongly recommend reading the posts by Chris O’Brien for more detail [Posts #1 and #2].


A not so deep dive into what is happening behind the scenes when you view a page in SharePoint Online [Part 2]

This is the second of a three-part post where I present my take on what is happening behind the scenes when you view a page in SharePoint Online. Whilst the title describes the focus to be SharePoint Online, I do stray into other areas of Office 365 like Yammer and Exchange. In the first part I discussed the components that are needed to assemble a SharePoint page and how geography has effect. In this post, I focus upon the processes that make significant contributions to the performance of a SharePoint page.

Key influencers

Reviewing the data reveals that time to process an element has a greater influence on the performance of the page rather than the size of the page. For example, the typical file size of an image rendition, used say in a news article, is small, around 20Kb, but the time to process and serve it is long (typically 3s from request to receipt). Conversely the core SharePoint JavaScript file ‘O365ShellG2Plus.js’ is the largest single item, around 862Kb, though it is served very quickly in 0.87s. The speed to serve the file is a result of using the Content Delivery Network to provide the file from a location close to the person viewing the page. The rendition takes longer as it is served from the datacentre used by the Tenant.

Consumer vs Corporate

If your users are like our users, then they have performance expectations based on their personal devices and their own internet connections. These expectations are usually at odds to the performance they get when using a corporate device on a corporate network. This then puts Office 365 in a difficult position – they use it at home on their own iPad and it is blisteringly fast, they use it in the office on their corporate pc and it appears to be infuriatingly slow. You know that they are not comparing apples with apples but it’s a comparison that they’ll make so it needs to be managed as part of the adoption communications.

This can be illustrated using page load data. Ad hoc testing using a Corporate PC and a Consumer PC using the same user account, WiFi connection and similar build reveal a pronounced difference in payloads received:

page load 2

The analysis reveals two key differences:

  1. For the same page the downloads are much larger on the Corporate PC
  2. The download size differs by browser

Point 1 might be a quirk unique to us but I suspect we are not alone. The reason why, for the same page, that the downloads are much larger on the Corporate PC appears to be in how Internet Explorer 11 is handing JavaScript files. As mentioned earlier ‘O365ShellG2Plus.js’ is the largest single file at 862Kb. IE11 on a Corporate PC appears not to respect the compression applied to the file and so it downloads 862Kb. Chrome on the other hand on a Corporate PC respects the file compression and downloads the file in a compressed state and then inflates to 862kB when complete. The deflated file size transferred is 172Kb. IE11 on a non-Corporate PC also respects the compression and transfers 172Kb prior to inflation to 862Kb. Therefore, there must be something that is affecting IE11 – I suspect we have a setting enabled in IE that is not helping and if we’ve had need to set it then others have probably done the same.

I find the 2nd point a source of amusement – why does Chrome perform better than IE, surely Internet Explorer should be better as it’s a Microsoft product just like Office 365? It’s a question that I cannot answer. I cannot help but chuckle that when I visit our Developers and the likes of Yammer, it’s Chrome that I see on their screens but they are developing for Office 365… I’m hoping that Microsoft’s Edge browser will be a vast improvement.

Stay tuned!

My summary from the first post was that we can only influence the Page Content as the reminder is controlled by Microsoft. However, we can make improvements through understanding where the content is served from. These improvements should optimise access to and transmission of content from the local touch points of the Microsoft Content Delivery Network as well as from the datacentre that is hosting the tenant.

In this post focussed on the consumer vs corporate user experience as well differences between web browsers. Each one has a major influence on performance or the expectations around performance.

In the final part I will focus upon design choices used in SharePoint Online and in particular one that makes a significant negative contribution to the performance of a SharePoint page. The impact of its contribution may affect your design choices say when creating an Intranet in Office 365.


A not so deep dive into what is happening behind the scenes when you view a page in SharePoint Online [Part 1]

This is the first of a three-part post with my take on what is happening behind the scenes when you view a page in SharePoint Online. Whilst the title describes the focus to be SharePoint Online, I do stray into other areas of Office 365 like Yammer and Exchange. The posts are based upon a similar summary that I produced for our network analysts to help them put their analytics in context and help them focus on the elements that we could influence. I’m not a network specialist so I’ve pitched this at a level that I’m comfortable with and one that hopefully makes the subject a little more accessible for all.

Anatomy of a SharePoint page

When you view a page in Office 365 the elements are coming from across the globe and are assembled in your browser to create the page. This is best illustrated by an example using a fictional Tenant based in Western Europe and assuming your Tenant is based Microsoft’s Dublin datacentre:

Imagine if you where based in Glasgow and viewing a News Article in your Intranet. The article contains a Yammer feed. Then:

  • The Suite Bar, at the top of the page, is being served to you from London (which is your nearest Content Delivery Network point of presence – more about this later). A short hop of 345 miles using IP by Avian Carrier.
  • The notifications that appear under the bell icon in the Suite Bar are being served from Dublin as this is where your email lives. (247 miles)
  • The code that powers the SharePoint page is coming from London.
  • The content of the News Article is coming from Dublin as this is where your content lives.
  • The Yammer feed is being served from Chicago (Yes, that’s right, from over 3,665 miles away!)

If we extended the scenario, and you are now viewing the same page from an office in Adelaide, you can substitute London with Melbourne (a mere 452 miles away). However, the Dublin content will still come from Dublin and Yammer will still come from Chicago. That’s 10,317 miles to Dublin and 9,913 miles to Chicago!

My example is a vast over simplification so it’s worth saying at this point that associated with each element there are a number of transactions like checking your permissions to view the content, making sure you have a valid access token for Office 365 etc. Completing these transactions add to the time it takes the overall page to load.

Office 365 is architected in such a way that common, frequently used elements, like the Suite Bar, are distributed to points around the world for local collection. ‘One-off’ elements like the image in the page are not distributed as it is more efficient to serve them on-demand. Yammer and Sway are exceptions and they only live in one location. In the case of Yammer, the application is very complex and so, at the moment, it only resides in Chicago. Yammer might look basic in terms of functions and features but under the hood there are complex algorithms running that help tailor it you to etc. and this makes it a complex application to replicate in other data centres. You can find out where your data lives using ‘Where’s my data’.

“Ye cannae change the laws of physics”

Clearly, geography has a significant impact upon performance. All Office 365 content is securely transmitted via the Internet and the path it takes is often not the most direct. If your network has a hub and spoke arrangement, then additional distances are added to and from the hub. Undersea cables that carry the vast proportion of all internet traffic, snake their way around the world joining countries and continents and adding miles to the routing. Whilst light travels at ‎over 186,000 miles per second, Scotty often reminded Captain Kirk “Ye cannae change the laws of physics” and so there will always be a time premium the further away you are from the data. Microsoft overcome this to a degree by serving common, frequently used elements via a Content Delivery Network (CDN) for local collection. Items like page content including image renditions are not served via a CDN as it is more efficient to serve them on demand. However, for the Content Delivery Network to be effective the content should be served from a point that is closest to you. If your internet traffic is routed via your company’s regional data centre, say in a hub and spoke model, then sometimes the CDN content is served from a location that is close to the datacentre rather than the CDN end point that is closest to you. Elements like DNS geolocation can affect your email experience as it connects you via a Microsoft data centre that is close to where you actually are and then retrieves your email from your tenant datacentre utilising a fast datacentre to datacentre connection. This subject is covered in more detail in a Microsoft case study entitled ‘Optimizing network performance for Microsoft Office 365’. In the case study they highlight techniques like ‘split tunnelling’ and ‘on-sites edges’ as methods for improving performance. The case study also highlights the need to use the appropriate type of search web part and consider the site navigation methodology.

“Ah but it’s the size of the page…”

Returning to the example at the start it is possible to classify the elements in a typical Intranet page and detail the page payload sizes for the first (with the cached cleared) and subsequent visits (using cached content). It is also possible to identify the elements that you can influence (highlighted in bold) and the ones that you cannot. The figures in the table are real as I’ve taken them from the home page of our Intranet and they include the additional load generated by our analytics solutions Web Tuna and Google Analytics.

page load

[ Source of reference for the CDN details ]

Our contribution to the overall payload is:

  • First visit: 1161.94Kb or 15% of total for visit
    • [1395.75Kb less the Microsoft files of 260.42Kb]
  • Second and subsequent visits 156.729Kb or 79% of total for visit

Of all of the files that make up the Home page it is worth noting that ‘O365ShellG2Plus.js’ is the largest single file at 862Kb and it is produced by Microsoft. This file is one of the key building blocks used by SharePoint. The largest single file created by us is a minified JavaScript file which is 174Kb in size. This is not the largest element of the page content as this is the underlying SharePoint theme file at 260.42Kb which is produced by Microsoft.

Stay tuned!

In the second and third part I focus upon the processes that make significant contributions to the performance of a SharePoint page.

Workflow is a service and not a solution

A couple of posts by Simon Terry, where he describes how algorithms can be part of Working Out Loud and designing workflows for the people, sparked my thinking about how algorithms can reshape the way we work.

Over the last 3 years or so (as that’s how long I’ve been in ‘IT’) I’ve formed a stronger and stronger belief that workflow is a service and not a solution. In this space Microsoft are making some decent headway with PowerApps and Azure Logic Apps. These services allow people to build what they need around them to suit them. There is a level of platform agnostics that elevates these kinds of products to a level of collaborative service that cannot be fulfilled by an in product solution. People can now shape the flow. Leaving the products like Yammer and SharePoint to focus on what they are good at.

I deliberately made the 3 years’ reference as before that I was a Civil Engineer. As an engineer tailoring the workflow to suit both the people and process being undertaken was part of everyday life (sometimes at the collective subconscious level). Granted certain processes had to be conducted in a specific order or things would fail or worse still people would get hurt but often the flow of work would flex, change and adapt based on the people. What was truly amazing, when you stepped back, was how this would (normally) happen without intervention.

What surprised me about IT was that the attitude and solutions for workflow are years behind something as old as the building game. It is still about lining up the dominos and knocking them down in order. Try introducing variables to the workflow and the systems quickly fail, unable to reroute beyond simple branching logic or adapt when iterations are needed. Difficulty is people are, and cause, the variables.

I think elevating workflow to a position outside of the products into a service is the first step. Thereafter the real magic and people focus can be applied. Second step (which we can start to do today) is let people design the flow to match their needs and work style. Yes, the flow will pass through some stage gates (as that is what organisations demand) but the path will be a little less constrained. The third step is to apply some Delve-esque magic. Algorithms are learning how we work, with who, at what times and with what. Using the algorithm, we should be able to generate a work flow that matches the individuals involved: playing to their strengths, sequencing it to pick the right time for the task to be done, using their preferred communication method etc. At that point we will be getting close to construction in terms of a people centric workflow.



Imagine what could happen if we combine the insight from Delve Analytics with tools like Planner and PowerApps?

It’s not an Oscar but…

Just over 3-years ago I finished my last construction project. The construction market was deep in recession and I was struggling to see where the next opportunity would come from. I faced a choice, one faced by many of my colleagues, the choice to “stick or twist”. Some of my colleagues chose to “twist”, dusting off their CV’s and striking out for roles, typically outside of the industry. My choice was to “stick”, well at least with the same company, as there where opportunities if I was willing to move outside of construction. I took a gamble with a six-month secondment into our internal IT service.

For me, IT was a gamble as all of my formal training is in construction and engineering. I gambled on having some transferable skills coupled with a passing interest in technology. I felt that I offered great value as I could help the service with my experience in how colleagues actually used the technology provided to them. I’ve always had a passing interest in technology and I’ve tried to include it in my construction projects whenever I could – from the early days of installing the foundations to the Reading Room at the British Museum to the digital models used in my last project.

As it happened it took a while for me to understand which of my skills where actually transferrable. I extended my secondment several times before settling in my current role. It’s in this role where I have finally realised which skills are actually transferrable. It’s also this role that’s led to a moment of real pride. In fact, its generated the same satisfaction that I used to get when I walked around a completed construction project.

About 18-months ago, the decision was made to rollout Office 365. My role was to use my business knowledge to shape the solutions that we would provide through Office 365. One thing led to another and I found myself becoming deeply immersed in the product and the solutions. I even started to describe myself as a fledgling Enterprise Architect in my LinkedIn profile. I found skills that I learned from construction, like the ability to take a holistic view and the value of a good specification, helped me assimilate and understand the complexity and depth of Office 365. Similarly, there are parallels between how construction projects run and how IT deliver projects. On a construction site, the team would meet daily to discuss the tasks to be completed. The meetings would not have a name but typically the team would gather around the project plan or a set of drawings and work through the days and weeks ahead focussing upon the items to be built in the period. In IT, Developers do the same thing but call it a ‘daily stand-up’ and describe the process of focusing on the items to be built in a period as ‘Agile’.

In the last 12-months, I’ve become both architect and evangelist. I attribute a lot of my success to my involvement in the Office 365 Network. It’s through this network that I’ve been able to accelerate my learning, deepen my knowledge and crucially make contacts and friends with people who are on a similar journey. The Office 365 Network is built on a product called Yammer and I’ve taken to Yammer like a duck to water. Perhaps there is something in Yammer that appeals to the engineer in me and it certainly clicks with my personality type.

Unbeknownst to me, my contributions to the Office 365 Network had been spotted by staff in Microsoft. I suddenly became aware when a notification landed in my inbox just before Christmas. I had been nominated for consideration as a Microsoft Most Valuable Professional (MVP):

The Microsoft MVP Award is an annual award that recognises exceptional technology community leaders worldwide who actively share their high quality, real world expertise with users and Microsoft. All of us at Microsoft recognise and appreciate Simon’s extraordinary contributions.

I was flabbergasted and humbled by the nomination. To be perfectly honest I expected nothing to come of it. There are only around 4,000 MVP’s in the world and most have worked in the industry for years building up their knowledge, networks and reputation. I felt that I did not fit the mould. However, the emails kept coming from Microsoft and today one landed with the subject:

“Congratulations 2016 Microsoft MVP!”


Tonight I’m proud, engineer proud. 🙂


Triaging Yammer Embed

Yammer Embed should work but there are times when you could end up chasing your tail trying to understand why it does not work. This is especially true if you are new to using Embed. So I thought I’d put a post together that describes my triaging process when things go wrong.

Start from something that works!

Now I know it seems simplistic but the embed code is *code* and by its very nature sensitive to typo’s. Hence I recommend using the widget to generate code especially if you are new to it.

When triaging problem, I recommend starting with the Yammer Widget as it allows you to test Embed whilst ruling out SharePoint and other gremlins. It’s a relatively straight forward fill in the blanks exercise. I’d start with simply setting the Widget to display your home network. As shown below:

widget example


If you cannot get the Widget to work, then it is likely that you have either browser or network related problems. In the case of your browser make sure you are using a supported browser e.g. Internet Explorer 11. If you are using an unsupported browser (refer to the ‘Browser and system requirements’ section), then you can expect a degraded or non-existent Yammer experience. Yammer contains code that identifies the type of browser and modifies the Yammer experience accordingly e.g.

yammer ie9 example



If it is not the browser and the widget fails to work, then I’d start suspecting either a Service Outage (which you should be aware of as these are posted in the Office 365 Admin Centre) or a configuration issue with your network. Later in this post I describe a couple of methods for confirming the basic configuration of your network.

Use the code from the widget

Assuming that you can get the widget to work, the next step is to reuse the widget code in a SharePoint page. For this you need a page in your environment that is ‘straight out of the box’. By this I mean it does not have additional styling or code as you might find in an Intranet page. The reason for using a basic page is to rule out any issues like JavaScript or CSS clashes. I use the code from widget as it will be error free. A common mistake when hand coding embed script is to miss off a comma and a missing comma can be hard to spot!

In order to perform this test, you’ll need the code from the widget which has been topped and tailed with some additional code to tell SharePoint where to get the Yammer JavaScript file from and that it is code to be executed. If you need a point of reference for this take a look at the basic example at the top of my earlier blog post about using Yammer Embed.

I would conduct this test using a Content Editor Web Part (CEWP) and not a Script Editor Web Part (SEWP). Using a CEWP means that you can vary the code without losing access to the page you are testing it in! Trust me it is super annoying to paste some flaky code into a SEWP for you to lose access to the page and have to roll a version back (if you have versions enabled!) or worse still delete the page and start again.

You should be able to get the basic code to work and from there you can start testing in the target environment e.g. an Intranet page. If that fails, then you have a SharePoint configuration or code security problem.

Check your SharePoint configuration

I’ve only used SharePoint 2013 and SharePoint Online and Embed works fine in both environments. I have read reports from users of SharePoint 2010 that Embed can fail in that environment. In some cases, this is down to SharePoint rendering the page in such a way that the browser switches to a compatibility mode which is lower than the supported mode.

Another potential blocker to Embed working is whether third party code is allowed to execute in your SharePoint environment. At this point it would be worth following my network configuration checks before pointing your finger at your SharePoint Administrator!

Check your network

Network configurations and firewalls can introduce a level of variability and complexity that can seem daunting. However, there are some really simple steps that you can perform prior to involving your network administrator.

I’d start by checking that you can access:

You can do this test by pasting the address above into the address bar in your browser. The result should be that your browser will attempt to download a file:

yammer code


If that fails, then there is either a Browser trust issue or more likely your firewall is getting in the way. In this context I use the term ‘firewall’ quite loosely. The file could be blocked by your firewall, it could be intercepted by your anti-virus application, a proxy service might be getting in the way etcetera etcetera. If the JavaScript code cannot be loaded the Yammer Embed part will not work! It would be odd if you can get the Widget to work but not be able to download the file.


Go back to basics

If you’ve read this far and are still struggling to get Embed to work, then perhaps you need to take a big step backwards and get your network administrator to confirm that the basics required to get Yammer to work are also in place. This might seem odd, especially as you’ll no doubt be able to access Yammer through your browser but some networks are tightly nailed down. Microsoft recommend that to successfully use Yammer a number of addresses and rules are allowed through your network and firewalls. Some administrators do not like opening up all of the recommend connections and so it’s worth double checking that they have. As a point of reference the firewall and trust rules are detailed here . It’s worth them also checking the SharePoint requirements (listed on the same page several sections above the yammer ones).

As I mentioned earlier it might also be worthwhile talking with your SharePoint Administrator as they might have configured SharePoint to prevent the execution of code etc. If all else fails raise a support ticket with Microsoft.