Category Archives: Office 365

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: http://www.runasradio.com/Shows/Show/508

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: http://graph.microsoft.io/en-us/docs/overview/hybrid_rest_support

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!

-CJ

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 (graph.microsoft.com) 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: https://graph.microsoft.com/beta/$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: https://github.com/LoungeFlyZ/MSGraphMetadata

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

https://github.com/LoungeFlyZ/MSGraphMetadata/commit/207346e2daed2d5553d6e655f8d9c3da4a33f830#diff-d6a067e9fd824380cf1a162010b163d6

MS Graph Diff

Simplifying Office 365 Unified API calls with Postman and OAuth 2

The Office 365 Unified API at graph.microsoft.com 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

GET Me

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

OAuth2

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: https://www.getpostman.com/oauth2/callback

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: https://login.windows.net/common/oauth2/authorize?resource=https%3A%2F%2Fgraph.microsoft.com
Access Token URL: https://login.windows.net/common/oauth2/token
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.

AccessTokens

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 graph.microsoft.com 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.

http://www.microsoftcloudshow.com/podcast/Episodes/036-interview-with-rob-howard-of-the-office-365-api-team

-CJ

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!

-CJ

SharePoint/Office 365 at Build 2014

I’m heading to the Build conference next week in San Francisco, YAY my first //build ever.  We have a bunch of great developer related content for SharePoint and Office 365 there.  Don’t worry if you have not developed for SharePoint or 365 before, there is content to get you up to speed!

Here are the sessions:

Building Connected Productivity Apps Brian Jones
Office Power Hour – New developer APIs and features for Apps for Office Rolando Jimenez Salgado
SharePoint Power Hour – New developer APIs and features for Apps for SharePoint Rob Howard
SharePoint 2013 Apps with AngularJS Jeremy Thake
Building Enterprise Social Apps with Yammer Jose Juarez Comboni
The brand new OneNote service – reach the massive user base with your apps. Gareth Jones
Developing Office 365 Cloud Business Apps Dan Fernandez
Deep Dive into Mail Compose Apps APIs Andrew Salamatov

Also Office 365 will have a booth so come and visit the booth and connect with the speakers and the team from Redmond.

SharePint @ //build, Wed at 7pm @ Chieftain Irish Pub

see you there!

-CJ

Hola Microsoft

Back in November 2011 I said “Adios Microsoft” and left to start the US office for Provoke Solutions. I can’t believe it has been over two years since then.  Time has flown by!

Well all things come to and end and on the 10th of March I will rejoin Microsoft.
I have thoroughly enjoyed my time with Provoke.  On Nov 1 2011 I literally unloaded a car full of things and set up myself in an office in Bellevue as employee #1.  We have achieved some amazing things since then and I am personally very proud what we accomplished. It’s been very personally rewarding, challenging and character building. Running a small business is hard, but a lot of fun all at the same time. I was fortunate enough of having the backing from our New Zealand based team so I never felt like it was just me.

But now I am ready for my next chapter.

I am heading back to a familiar but different team from my last stint at Microsoft, the Office 365 team. I will be leading a team to help to make Office 365 a great place for developers, software vendors (ISVs), development houses (“System Integrators”) and others to customize, extend and build software for Office 365 and constituent products on-premises.

MSBadge

This opportunity was too good to pass up.  The chance to work on the worlds #1 leading productivity software and to help take developers and ISVs along for the ride! Couple that with a unique time in computing history as the paradigm shift of cloud computing takes hold and it makes for a very unique opportunity that I couldn’t resist.

They had me at “helping developers”.

The current story for developers building for the cloud in 365 is only in its infancy and I am very much looking forward to being involved and helping as much as I can.

I know lots of people out in the community, the SharePoint community especially, who are very passionate and vocal about the issues they are facing with development for Office 365 today.  I know fully well what many of the issues are, however, as always, I look forward to talking with as many people as I can and working on these issues together.  It needs to be a collaborative effort and it wont happen over night.  But it will happen.

I am really looking forward to the SharePoint Conference in Vegas next week!

-Chris.

Sandbox code is “deprecated”, long live the Sandbox

we have deprecated the use of custom managed code within the sandboxed solution – Brian Jones, Principal Program Manager, Apps for SharePoint

It’s been a long time coming and widely anticipated that this announcement would come at some point.  It’s great to see the announcement and the clarity many have been asking for.

I feel like I’m in a good position to comment on this and give some background about why I think deprecating code based sandbox solutions is good idea. I was on the SharePoint engineering team when the sandbox was being built and for a period of time I was the Program Manager for the feature.

Background:  Sandbox solutions in SharePoint were introduced in SharePoint 2010.  They allowed a packaged set of assets and code to the uploaded to a SharePoint site.  That can consist of declarative components like XML for adding things like List Templates, as well as compiled code for things like Web Parts or Event Receivers.

When the Sandbox was being designed and built it was about 2 – 3 years prior to SharePoint 2010 being released. Azure, and cloud computing in general, either didn’t exist or was in its infancy. SharePoint needed a way to upload customizations/components to SharePoint sites where the administrators were not comfortable with installing Farm Solutions aka. Full trust solutions. Microsoft itself was a perfect example of this.  If I built a web part I, as a Microsoft employee at the time, couldn’t load that onto our SharePoint sites that MS IT ran.  No 3rd party web parts or products. This was a common problem in many large organizations and we heard about this time and time again with customers.

Sandbox Solutions were the answer. They allowed users to upload a solution and have SharePoint run it while it being controlled, secured and run in a sandboxed process. The main thing this gave SharePoint was the ability to isolate the code in that solution and ensuring that if it crashed or was badly behaved that it didn’t break the rest of the SharePoint environment.

The problem was that Sandbox Solutions was a feature added in Windows SharePoint Services (WSS) and that was a different product from SharePoint Portal Server (SPS) that built on top of WSS.  The API set in the Sandbox that was available was limited to WSS APIs and even then only a subset of them. There were good reasons for this, but at the end of the day it was very limiting for people.  Ideally it would have been great to have lots of SPS APIs available too. But that didn’t happen (different story).

So that is the background about how/why Sandbox came about.

… now fast forward to today …

In a nutshell the Sandbox was a good solution to the problem faced when it was designed. However, it’s not a great solution to the problem given the technology we have today.

Why is it no good today you ask?

A lot happened after the Sandbox was designed and built.  Cloud computing took off, new advances in code in all sorts of places got easier e.g. isolated apps on a phone.  A lot was learnt. 

In short its my belief that SharePoint shouldn’t have been trying to replicate an isolated code hosting environment.  That is reinventing the wheel and there are other teams at MS who build products to do this extremely well already.  Namely IIS and Azure.

Think about that for a second.  Imagine being given some arbitrary code and told to run it, but doing it in a way that was safe, secure, manageable and fault tolerant.  It’s actually quite a tough challenge. If you say it’s easy then you should try doing it instead of talking about it 🙂 (tip with wider life applicability too)

So today MS clarified that SharePoint was getting out of the code hosting game.  Why?  Because it was limited and there are better solutions to this problem today. 

The new SharePoint app model is designed to solve this by moving “sandbox” code to an alternative host e.g. IIS or Azure or <insert thing that runs code here>.

Sandbox code might be “dead”, but the new app model IS the new Sandbox!

I see the reasons why the sandbox came about the same as I do for the new app model.  They are solving the same problem.  How do you allow someone to customize, extend and build new things on SharePoint without compromising the integrity of SharePoint itself?  That is the goal.

Today in SharePoint 2013 and Office 365 we have the ability to build solutions that use this new app model.  Sure, it’s not perfect in the APIs it provides and there is plenty of scope for adding things.  I am certain it will evolve to cater for more of these things over time.  That said, it is MUCH better suited for the long term.  I for one am loving the ability to use all the latest dev tools and technologies in Azure that were not possible in SharePoint previously.

The app model may not be applicable or possible to be used for everyone today and that is fine. It’s going to develop and that will change over time would be what I bet on.  But it is the right path moving forward.  This might cause some pain for people in the short term and I understand the frustration people have with changes like this. But I would MUCH rather have to deal with this change than be limited to a inferior set of capabilities in the longer term.  This is the right move long term (in my humble opinion).  Short term pain, long term gain.

Getting SharePoint out of the code hosting solution was the right things to do and I applaud the team for clarifying there position on this.

I look forward to the SharePoint Conference in March where hopefully (fingers crossed) we will hear more about the future of the new app model and how it will address its shortfalls today.

-CJ