Office 365 SuiteBar becomes responsive

image_thumb.png

Quick heads up about some SuiteBar improvements which are worth knowing about.

Microsoft have recently update the Office 365 SuiteBar. As you can see in the image below the Application Launcher got a new visual which resembles the Windows 10 Start experience. You can now resize the tiles as well as drag and drop them into a desired order. The tiles can be small like my Twitter and TinyPng or massive wide ones like my Delve.

image

Overall the SuiteBar has now become a responsive experience. It changes and adapts depending on the screen width and this removes the need for any clever work around.

Examples:

SuiteBar at a full 1920 width

image

SuiteBar a little smaller. Notice how the Application Launcher jumps to the right now.

image

Between the sizes above their seems to be a tiny glitch in about a ten pixel range where extra buttons appear.

image

The new buttons don’t do anything at this point though.

Finally we get down into the smaller mobile sizes.

image

I hope you found this update useful and it gives you chance to remove any customisations you might have made for the responsive SuiteBar.

Adding Custom Tiles to the Office 365 App Launcher

image_thumb.png

Microsoft recently released a new feature so that as an Office 365 admin you can add tiles to the App Launcher.

 

Setting it up

Browse to the Admin dashboard for your tenant, from the left hand menu choose the ‘Company Profile’.

image

 

From the ‘Company Profile’ page select ‘Custom Tiles’ from the left hand menu.

image

 

The ‘Custom Tiles’ page is now displayed, and on very first load will be empty.

image

 

Click the ‘Plus’ to create a new tile.

image

 

You’ll notice that the information being requested is a lot simpler than the Azure AD application configuration. So in my opinion you may still want to opt for the Azure AD application root if you wanted to use groups/user assignment for the tile. This new Office 365 custom tile approach really only provides ‘add the icon’ style functionality. So in scenarios where you wanted to use a consistent name and icon for say a HR system where different regions had different urls/systems you’d still want to use the Azure AD root. Relying on this new Office 365 custom tile would need two tiles and both would show for everyone. As it stands today this feature is probably only useful for truly generic links such as the SharePoint root site collection (But why MS ignored that for so long has always baffled me).

Just before setting the tile information we need to make sure we have the logo somewhere, I always use Lego mini figures in this tenant so I uploaded a new picture to the assets library of the root site collection.

image

 

Once I have an image somewhere (it could have been located anywhere including externally from the tenant) I can enter the information to create the tile.

image

 

The new tile is now listed. Note that you can also edit and remove the tile from this screen.

image

 

Browse to your ‘MyApps’ page.

image

 

There you can see our newly created tile. From here the employee can decided to pin it the App Launcher.

image

 

They can also view details about the app.

image

 

We can see the new tile in the App Launcher.

image

 

So this is a neat new feature which will satisfy the common request to have a tile for the Intranet home page. While MS could hopefully go further in the future to allow employee and group assignment like the Azure AD apps.

Creating a simple redirect app for the App Launcher

image.png

As we saw from the previous article Adding GitHub to the App Launcher the Office 365 user experience now incorporates the App Launcher as a persistent navigation element across the whole suite. Combine this with the Access Panel in Azure and you have two simple ways to provide a user with a navigation item. As you can see from the screen shot below, including last articles addition of GitHub.

Imagine an organisation wants to take advantage of the App Launcher to provide a link to their users for the company public website. On the surface this isn’t such a bonkers request. Many organisations have some elements of their internal intranet hosted within Office 365 and often they require a link to the public facing sites as well. It makes sense then as the App Launcher provides a globally available menu system that the intranet owner might ask for this link to be provisioned. Ok so far, a sensible request by the stakeholder….

Well if we cast our minds back to the types of application that can be displayed:

  • Office 365 applications – If you are using Office 365 such as Exchange and SharePoint and the logged in user is assigned a license then these will appear. The user will be automatically signed in when they click any of the Office 365 apps.
  • Microsoft or Third Party apps configured with Federation based SSO – If an Azure admin has configured the app with single sign-on mode set to ‘Azure AD Single Sign-On’ then when a user clicks the app they will be automatically logged in assuming they have been explicitly granted access to that application.
  • Password based SSO without identity provisioning – These are applications the Azure admin has added with the single sign-on mode set to ‘Password based Single Sign-on’. It is important to realise that all users authenticated to the Azure AD will see these applications. The first time a user clicks one of these apps they will be asked to install a lightweight browser plugin for IE or Chrome. Once they restart the browser the next time they navigate to that app they will be asked to enter the username and password combination for that app. This is then securely stored in Azure AD and linked to their organisation account. The next time the user clicks that app they will be automatically signed in with the credentials they provided. Updating credentials in the third party app needs the user to update their Azure AD stored credentials from the context menu on the app tile.
  • Password based SSO with identity provisioning – These are applications the Azure admin has added with the single sign-on mode set to ‘Password based Single Sign-on’ as well as identity provisioning. The first time a user clicks one of these apps they will be asked to install a lightweight browser plugin for IE or Chrome. Once they restart the browser the next time they will be automatically signed in to the application.
  • Application with existing SSO solutions – These applications are configured with the sign-on mode set to ‘Existing Single Sign-on’. This options supports the existing methods of SSO such as ADFS 2.0 or whatever the third party application is using.

None of these sound like a ‘simple’ type of hyperlink navigation item do they? They all assume the need for some kind of sign-on or application.

So at the time of writing this article there is no way to add a simple static url into the icons. Microsoft might pull this feature in at some point in the future, but for now we need something sensible to help us implement it.

NB: When researching this challenge I did stumble upon one blog article which was suggesting using jQuery to inject items in the html of the App Launcher. While in reality the author had it working it would be something I’d steer well clear of for the following reasons:

  • Microsoft ‘own’ the UI/UX for the App Launcher which means they can make breaking changes any time they like leaving you with a broken implementation at best
  • The article could only get this to work across SharePoint Online as the author could inject the required script. This meant that users outside of SharePoint lost this set of icons in things like Exchange.

So where does that leave us? Simple really we need an application registered with our Azure Active Directory which can redirect the user.

Creating our redirection app

So we have two options for this, manually craft an Application and register it with our Azure AD Applications or use the Visual Studio tools to help. For this article we’ll opt for the Visual Studio root and rather explain what’s happening behind the scenes as we go.

So lets get going by cracking open Visual Studio 2013.

Lets create a new MVC Web Application called ‘SimpleRedirectorApp’ and click OK.

image

image

Lets be good citizens and change our app to use SSL. Change the Project property to SSL Enabled to true.

image

Then copy that URL into the properties page on the Web tab.

image

Save the project and run it.

At this point you should see the normal templated MVC page running on your localhost under SSL.

image

So at this stage we have a basic MVC web application up and running. Now lets switch into our Azure portal and take a look at the applications listing.

This is all the applications I have configured in the Azure Active Directory. You’ll notice from the screen shot below our new app is not yet listed in the applications and thus Azure and the App Launcher no nothing about it.

image

If we were doing this manually we would go through the steps to ‘Add’ the application here. For this run through we’re going to jump back to Visual Studio.

We are going to use the Office365 Tools to add a connected service which wire up our app the associated Azure AD for us.

So from the context menu of the project chose ‘Connected Service’.

image

Click ‘Register your app’.

image

Sign in with a user who is an Azure AD admin / Tenant admin which is normally one and the same.

image

This will then show you information about your application.

image

Click ‘App Properties’ and make any changes from single to multi tenant if you require.

image

Note that the URLs are being displayed which match where our App will run from at the moment. When you choose to publish these elsewhere for Production you update these values.

Now when this wizard finishes it has done a few things. Firstly its added a set of things to the web.config file to store the Client Id etc.

image

Next if we switch back to our Azure Portal you’ll see the App is now being listed.

image

Clicking in we can view the settings that have been made.

image

One of the things we can’t do from the Visual Studio tools is set the Logo for the App. This is important to do as it’s the visual icon in the App Launcher. So click the ‘Upload Logo’ from the menu bar.

image

Choose an image which matches the specifics in the dialog box. I’m going to be linking to my companies website so created a quick icon based on our logo.

image

Scrolling down you can see the URLs listed and the permissions the App needs to run. Notice at the moment we don’t ask for anything other than delegated permissions on the Azure AD to enable SSO and read the profile of the user. That’s all we need.

image

Once the App is configured we need to assign users to it so it shows up for them. So click the ‘Users’ tab and find the user you need to assign. As you can see from the screenshot I’m just going to assign myself it for now. Once highlighted click ‘Assign’ from the menu bar.

image

Now when you browse to your Office 365 tenant and open the ‘My Apps’ page you can see our new App listed. As you can see from the screen shot below.

image

At the moment we have to manually ‘pin’ this new app ourselves Sad smile hope Microsoft add features to do this from the portal at some point.

image

So now it shows up in the App Launcher. Hooray you say… click it and what happens… we get the boring old MVC default page in a new tab. (assuming you still left the app in debug, remember its localhost at the moment).

image

So only one more step to go. Lets make our App go where it should, to the all important public website.

Open the HomeController.cs and find the Index method.

Change it from this

image

To this

image

We changed the result object to the RedirectResult type and provide it the url of our public site.

Now rerun our localhost app and it should redirect straight to the website.

image

Now when we click the App from the App Launcher we get a new tab and the App handles the redirection to the specified site.

Happy stakeholder Smile

As I mentioned earlier one of the best things about this approach is that it is truly suite wide as you can see from the screen shot of the users Calendar below.

image

In a more detailed scenario you might want to add more features to the redirection app and make it configurable without hard coding, but this was the basic how to Smile.