Category Archives: Office 365

Measuring cloud market share. A pet project.

For a while I have had a desire to measure who is winning market share in the cloud. Microsoft vs. Google vs. Amazon vs. Others. I finally got some time over a few weekends to build an app to help me do that.

Here it is:

Underwhelming huh!

It’s pretty early days 🙂 I am no web developer that is clear! LOL. But the idea was to get something basic working and then go from there.

My goal is simple. Add data, detection techniques and interesting ways to visualize/slice and dice the data so that i can keep an eye on movements in market share. For now that just means some basic pie charts. But longer term I hope to add graphs showing historical data and trends that show movements over time. It’s currently keeping all that data but not showing it (my frontend web skills are weak).

In time I would like to add:

  • Authentication provider market share (e.g. Azure AD vs. Okta)
  • Top 1 million domain market share
  • Domain lookup with historical data
  • Productivity suite market share (e.g. O365 vs. GSuite)
  • Meeting solution market share (e.g. Teams vs. WebEx)
  • Information on other cloud software a company uses (e.g. Docusign vs. Adobe sign)
  • More … 😉

I have a whole raft of ideas, but time is really the limiting factor for implementing things.

How it works. I give it lists of domains that i want it to analyze and it goes of and analyzes them in a number of ways using DNS, IP addresses and a ranger of other detection techniques. It stores the results and does a bunch of stats aggregation. The app just shows this aggregated stats data.

It all runs in Microsoft Azure (of course) and consists of .Net core containers running in Azure Kubernetes Service and Azure Table Storage for keeping the data. I took inspiration from Troy Hunt and his post: Working with 154 million records on Azure Table Storage – the story of “Have I been pwned?” and tried to keep it cheap to run, fast and easy to maintain 🙂 It’s a side interest project after all.

I’m keen to hear what you would like to see from this. Follow and tweet @CloudMktShare with your ideas and suggestions.


Office 365 development Slack

imageMany years back a small group of friends started the Office 365 developer slack network.  A bunch of people joined and then it rapidly went nowhere Smile

I think that is a crying shame. 

I recently joined a Slack network for Kubernetes and its a fantastic resource for asking people questions, working with others on issues you are having and generally learning and finding things.

Office 365 development has changed a lot over the years and people are finding new ways of doing things all the time. The Microsoft Graph is taking off in a HUGE way, SPfx is becoming a viable way to build on the SharePoint platform, Azure AD is the center of everything in the cloud for MS and the ecosystem is heating up with amazing new companies and products springing up.

Anyway … I miss having a Slack network for Office 365 development chats with people.

You can join the O365 Dev Slack here if you feel the same way …


Importing and Exporting photos from Office 365 and Active Directory

Photos in Office 365 are a pain. This is because there are currently three(!) main places photos are stored in Office 365:

  • SharePoint Online (SPO
  • Exchange Online (EXO)
  • Azure Active Directory (AAD)

If you are syncing profiles using AD Connect those profiles are being synced into AAD. From there they take a rather arduous and rocky path to EXO and SPO via a number of intermediatary steps that may not work or may only complete after a period of time. e.g. from EXO to SPO photos may only sync if someones photo has not been set directly in SPO and a rather profile property attribute is not set correctly.

Needless to say it can be very hard to work out why you have one photo in AD on-prem, one in AAD, one in EXO and another in SPO … all potentially different!

At Hyperfish we built our product to push photos to all the places they should go when someone updates them. This means that when someone updates their photo and that update is appoved that it will be resized appropriately for each location and then saved into AD, EXO and SPO immediately. This results in the persons photo being the same everywhere at the same time. Happy place!

However, we have some customers who want to bulk move/copy photos around between these different systems to get things back in order all at once. To do this we created a helpful wee commandline utitility that we have published the source code for on GitHub and a precompiled release if you dont want to compile it yourself.

Photo Importer Exporter

Creative naming huh! 🙂

The Photo Importer Exporter is a very basic Windows command line utility that lets you:

  • Export photos from SharePoint Online
  • Export photos from Exchange Online
  • Import photos to Active Directory
  • Import photos to SharePoint Online
  • Import phtoso to Exchange Online

All you do is Export the photos from, say, Exchange Online (the highest resolution location) and it will download them all to the /photos directory. Then you can Import them to, say, Active Directory and the utility will resize them appropriately and save them to AD for you. Simple huh.


It’s a work in progress and we will be adding bits to it as we come accross other scenarios we want to support.

But for now you can grab the code and take a look, suggest additions, make pull requests if you like, log issues … or just use it 🙂

Happy coding,

RunAsRadio: Keeping Active Directory Data Up to Date with Chris Johnson

I recently sat down with Richard Campbell on the RunAsRadio podcast to talk about the state of directories, why people profile data is a critical component of SharePoint and Office 365 deployments and how Hyperfish can help organizations with their profile and directory mess.

Listen here:

Microsoft Graph spanning on-prem and online!

One of the most interesting announcements, at least in my mind, this week from Ignite 2016 was the news that Microsoft is adding support for Microsoft Graph API in hybrid deployments.

This means you can call the Microsoft Graph API like you would normally for Office 365 based mailboxes, for example, but have it actually connect with a mailbox that resides in an on-prem exchange server!

Let that sink in for a moment. That is pretty sweet!

Typically, if you have an application that is not deployed behind the firewall, i.e. inside the orgnaizations network, you couldnt call things like SharePoint or Exchange APIs without doing network gymnastics like VPN, reverse proxy or putting holes in your firewall (yuk).

Now with this hybrid support in the graph you can simply call internet based REST APIs and Microsoft is doing the work of facilitating that communication back to the on-prem resource.

Currently in Preview the graph only supports Mail, Calendar and Contacts in this hybrid configuration right now, however I can only imagine that more support for other endpoints like Users, SharePoint etc… will come at some point.

You also have to have Exchange 2016 CU3 servers deployed on-prem to get this support and sync your AD to Azure AD as authentication is managed this way.

You can read more about these re-reqs here:

I think this is a huge benefit for those who are looking to build applications or cloud services that connect to data wherever that sits.

Couple of interesting scenarios to think about:

  • Mobile app that works outside the firewall was either not possible or too hard due to connectivity issues.
  • Cloud service web apps that you want to connect to on-prem data
  • Tools and Apps that can now work with data either in Office 365 or on-prem


This to me is a huge step in the right direction for Microsoft in their quest to make developers lives better in a hybrid world.

Hybrid is not a transitional state. For many it’s the end state. 
John Ross and Randy Drisgill

I’m looking forward to more endpoints coming online in the months ahead!


Microsoft Graph and what’s changing…

One of the pet peeves we heard no end of complaints about when i was at MS was the lack of a decent Change Log. Even just one targeted at developers. It might seem strange to people why MS haven’t done that for the whole of Office 365, but lets just say its a really hard nut to crack.

That said the great team working on the Microsoft Graph ( APIs have been doing a nice job on the Office dev blogs keeping us up to date on changes going on in the run up to the APIs release last week.

One of the other things I have been doing to see what is changing in the API as it’s been changing is to keep an eye on the $metadata endpoint. $metadata describes all the entity types, properties and relationships etc…

It’s available via the API when you call:$metadata

The document can be quite large and manually finding changes in it is pretty painful. Diff to the rescue! You can use your favorite diff tool to see what has changed from one copy to the next.

GitHub also does reasonable diffing. I am going to try and keep a copy of the $metadata document in GitHub that people can take a look at.

The repo is here:

Here is a link to the current diff between the /v1 API and the /beta API as of Nov 23 2015.

MS Graph Diff

Simplifying Office 365 Unified API calls with Postman and OAuth 2

The Office 365 Unified API at is a nice API to work with Azure AD and Office 365 from a single API endpoint. Authorized via OAuth 2 flows and all REST/JSON etc… Pretty much as you would expect as a developer.

There are a few ways to play around with the API.

Simplest: Graph Explorer

Harder: Use a tool like Postman

Postman is pretty slick. It lets you craft HTTP requests, their headers, parameters, body etc… and get responses back formatted in various ways. Postman 3 also supports OAuth 2 flows to help simplify the process of authenticating against and API, so you dont need to do all the various hops and token copying between requests.

OAuth 2 + Postman + Office 365 unified API

Here is how it works.

1. Go install postman 3 first

2. Set up a GET request to get your profile details from Azure AD


3. In the authorization area pick OAuth 2 from the dropdown


4. Next you need to go and register an app, if you haven’t already, in order to get a Client ID and Secret. There are instructions on doing that here.

Note: for the REPLY URL field you need to specify:

When complete make a note of the client id and secret as you will need them shortly.

5. Back in Postman enter the following details for each of the OAuth parameters:

Authorization URL:
Access Token URL:
Client ID: (the one you got in the previous step)
Client Secret: (the one you got in the previous step)

Notice at the end of the Authorization URL you need to include the “resource” parameter. This is required with O365 and indicates what endpoint you are trying to get access to.

6. Click the “Get access token” button to initiate the authentication and authorization flow. Postman will pop up a window that will direct you to log into Office 365 and let you consent to the application being given the appropriate privileges.

When complete you will see the OAuth access token, scopes etc… that were returned.


Type in a name for this token and save it. Then for all subsequent requests you can attach that token to your request like this.

1. make sure your URL is set
2. attach the token to the header of the request
3. execute the request

MeR equest Results

All things going well you will get back a nice JSON response with your profile information included.

Hopefully helps simplify calling the endpoint, playing with requests and not having to deal with all the icky OAuth goo along the way.

Happy coding!

Bro Down

@MSCloudShow – Ep 40 – Talking to Wictor Wilen about Hosting SharePoint VMs in IaaS

Episode 40 of the Microsoft Cloud Show podcast is now available. In this episode AC & I talk to Wictor Wilen about using Microsoft Azure VM’s to host their SharePoint virtual machines & farms.

Be sure to download the recorded show here: Episode 40 – Talking to Wictor Wilen about Hosting SharePoint VMs in IaaS

MS Cloud Show – Ep36 – An Interview with Rob Howard of the Office 365 Developer Platform Team

I had a chance to sit down with Rob Howard on the Office 365 Developer Platform team here at Microsoft and ask him about his history with SharePoint, what’s changing about the way MS builds products now we live in a services/cloud world and throw in a question about what the one thing he would change in SharePoint if he were to do it again.

Rob and I get to work together a lot at Microsoft and he is one of the nicest and most knowledgeable people on all things Office 365 / SharePoint development.


Office 365 – Developer and Ecosystem team update

The 10th of June will mark 3 months since I returned to Microsoft.  It’s fair to say it’s been a major whirlwind!

Coming back to a company is a funny thing. A lot is the same, but so so much is different. I am on the Office 365 team and there are many familiar faces from my previous time at Microsoft, but so many new ones too.  It’s great!  The team rocks, the group rocks and the product(s) are the best in the world.

I lead a small team (me + four others) called the Office 365 Developer and Ecosystem team.  Our goal is to care about developers who want to building on our technology.  The team is made up of amazing superstars, namely Dave Pae, Jeremy Thake, Sonya Koptyev and <to be hired> (this TBH is not a superstar since they don’t exist yet).

So what have we been up to you may ask?

All sorts of things! 🙂  Primarily the team have been planning for the 12 months. We have lots of things to accomplish and we have been working out what the big priorities will be, who will tackle them and what we need to do to make it all work.

Roughly those things fall into these big high level categories:

  • Develop a great Office 365 ecosystem (developers and partners)
  • Train developers
  • Move solutions/product in the cloud
  • Community engagement

The first one is all about building an amazing set of partner companies that have products and services for Office 365. The Ecosystem. We make sure individuals and companies have all the things they need to be successful.  That includes understanding what is possible, why they would want to build for Office 365, how to do it and how to attract customers and build a great business. We have been working with our Developer and Platform Evangelism (DPE) counterparts to work out how they will help us scale out to touch thousands of developers and ISVs this coming year to train them on building for Office 365 and building great solutions and products for it.  We have an amazing set of partners building Apps, Products and Solutions for SharePoint and Office 365 already, but we want to ensure they are successful both in a technical sense and a business one which will grow a healthy and vibrant partner ecosystem.

Next its all about training developers.  We hear all the time that it’s too hard to find skilled developers. We aim to do this via a number of channels such as the Microsoft Virtual Academy, Ignite training events, Developer Camps, Channel 9 and conferences worldwide.  The team don’t necessarily do it all themselves!  We work with lots of people both inside Microsoft and outside to design, develop and deliver all the developer training material we need and then push it out to people through all those channels.

We know that LOTS of customers (> ~80% in the case of SharePoint) have customizations or custom code they have made on premises and that for them to move to the cloud they need those things plus many of the ISV solutions they rely on today.  We are working hard on making sure that we have the guidance, tools and training for those who want to move now, or just want to start building those customizations in a way that will make it easier to move when they are ready down the line.  For some customers this will be a way off, and we know that, but for those that want to move now we would like to help them do that.

Community is hugely important to us.  Not only in actual size, but also in importance.  We will be spending a lot of time engaging with people, talking about the issues they are facing and taking feedback.  This means you will see us presenting at conferences, participating in community activities online and generally just being “out there”.  The power of the SharePoint community came not from Microsoft, but from the participants and we don’t pretend that we can make a great community … but we can help support one.

Those are the big high level categories of things we will be working on.  That is by no means exhaustive, but it should give you an idea of what we are thinking about.

There are some more tactical things that we have heard a LOT of feedback about from developers and ISVs.  Namely a process around telling developers what is coming and when, so they can test their code and build new things based on new features coming.  All I can say for now is that we are working hard on this problem. We are going to publically have a plan of record that anyone can read to see what is in the pipe for developers. We are also running a closed small pilot to allow ISVs to get access to Office 365 tenants that get updates first. This means ISVs can test their products prior to the changes rolling out to all customers around the world.  Our goal is to one day be able to offer that to any customer, but for now it’s a small closed group to learn about what they need, how we manage the feedback/issues that come up and some of the logistics of the whole exercise.

There are of course lots of other things we are working on that we can’t talk about just yet and those will have to wait for another day 🙂

We have seen some incredible milestones in the past 3 months for Apps in Office 365 too:

  • > 1,000,000 launches a week of Apps for SharePoint in Office 365!
  • > 850 apps in the Office Store
  • 30 Ba ba Billion API calls a month

I hope this has given a bit of insight into what I have been working on since my return to MS 3 months ago.  We have SO much to do and really we are just gearing up for an amazing year ahead.  I couldn’t be happier with how things are shaping up.

Be sure to follow @OfficeDev for updates!