Customising the App Launcher– Part Two–Custom Tiles.

Back in December I wrote about the ability to customise the App Launcher, or Waffle as it lovingly known. The options were relatively limited unless you built your own app in Azure and deployed it to the organisation. However one request came up again and again, the ability to create a shortcut tile to a specific site or location inside the Office 365 tenant. Imagine being able to have a dedicated waffle link for the Marketing site, or perhaps a dedicated link through to a specific PWA instance.

Well in the past few weeks, a new feature has been added to Office 365 to allow an admin to create a link that they can then push out to everyone in the organisation. The feature is a little hidden, but incredibly valuable. For this post, we are going to create a dedicated link to one of my Project Online instances in my tenant.

The first thing we need to do is navigate to the Office 365 Admin Portal.

Office 365 Admin Center

In the portal, choose COMPANY PROFILE. You will be presented with some information about your institution, however we want to pick the Custom Tiles option on the left hand side.

Choose custom tiles

In this page we can add new custom tiles for use in our Office 365 tenant. Click on the + to add a new one.

Click Add

To add the custom tile, all you need to do is fill in the relevant information. The only tricky one is the Image URL, which needs to be a image that everyone in your Office 365 tenant can see. In this case, reading the help can really pay off as it tells you the icon should be 50 x 50 pixels and stored in SharePoint Online. Specifically the help suggests putting the image in a team site and generating an anonymous guest link that you can put in the Image Url section.

Configure the tile

Once you’ve pressed save, the custom tile is now ready for your users to pick up. By default the tile won’t be displayed in the App Launcher, each user will have to click on the My Apps link.

Choose my apps


find the tile and then click on the … and add it to the launcher.

Our Tile!

And tada!!


The quiet removal of My Tasks

One of the big things to happen in Office 365 whilst I was ‘offline’ was a quiet announcement about the removal of the My Tasks capability on your My Site. In case you hadn’t seen it, the My Tasks capability rolls up all tasks that have been assigned to you across SharePoint sites into a single view in your My Site.  I’ve posted on it a few times before with the work management tag and it’s a great capability. What makes it even more powerful from the end users points of view is when you can link it up with Outlook and get all the tasks rolling through into OWA or your mobile device.

Back in September, MS quietly posted a support article announcing that the feature would be deprecated over at .

The support article highlights that the Tasks link has been removed from the About Me section of the User Profile page, but can be reinstated easily if you want it back. The support article goes onto state that the capability will remain there for a year before it is removed and considered unsupported.

The article goes onto mention that the Sync with Outlook option is also being removed in the future, but doesn’t make it clear if this is just for the My Site capability or for the whole of SharePoint Online.

‘If you’re currently syncing a SharePoint tasks list to Microsoft Outlook, tasks will continue to sync for approximately one year following this announcement. The personal Tasks page will also continue to be available for one year. After that time, this functionality will be removed and will no longer be available or supported.’

If your using SharePoint 2013 on premises, then none of this matters for now as neither of these changes impact on premises SharePoint farms. If your an Office 356 user, I would be wary of building solutions leveraging this capability in the short term and be on the lookout for inevitable replacement and migration plan in the coming months.

TechEd Australia – Links from our SharePoint 2013 App Playbook Session

Today Brian Farnhill and I presented our session on Building Apps for SharePoint 2013 (with a little bit of Project Server thrown into the mix). The session was really well attended and we covered a heap of material on this massive topic. Unfortunately we ran a little overtime, so I’ll post a few of the demo’s I wanted to show up in the next couple of days.

In the meantime, I here are some additional links as promised to keep you going :)

Building apps

Publishing Apps

Updating Apps

Many thanks for those of you that came along, I will be posting up the video and slide deck in the next few days once it’s up on

Hiding & Disabling ribbon items in Project Server, Part II

In the last post, we covered a few things you will need to know when hiding or disabling ribbon buttons in PWA. In this post we will look at how to actually hide the buttons.

Where to start?

Irrespective of whether you wish to hide or disable a button in the ribbon, you will need to follow the same basic process by building a solution in Visual Studio that will deploy your ribbon customisation.

To start, open up Visual Studio and choose to create an Empty SharePoint Project.

Create Empty SharePoint Project

Enter a name and then click on OK. You will then see the SharePoint Customisation Wizard, enter the local site you wish to use for debugging and choose to ‘Deploy as a sandboxed solution’.
SharePoint Customisation Wizard

On clicking finish, Visual Studio will create a solution ready to be customised.

To start with we need to create a feature,  this is a logical container for our customisation and allows the user to turn on and off the customisation by activating and deactivating the feature. To do so, right click on Features in the solution explorer and choose Add Feature.

Add Feature

A feature will be created and Visual Studio will show a page where you can enter information about the feature such as the name, description and the scope. In this case we are going to choose Web (for an individual site) as we want this change to deploy only to the /PWA site and not all the children sites.

Hidebutton Feature

Next we want to add an element to the solution, this is where the real work is done and contains the XML that will be used to configure our ribbon.

To add an element, right click on the project name, choose Add, New Item

Add New Item

In the dialog that is displayed, scroll down and select Empty Element and give it a name.

Add Element

Once you click add, the element will be created.

Blank Element

Now the empty element is created, all that is needed is to add the relevant XML to either disable or remove the button.

Disabling a button

For this example, we shall be disabling the EPT Change button from the Project Centre ribbon. To do so we need to know the ID of the item as defined in the ribbon so we can build up some XML that defines what we want to do to that item. To find the ID, we need to look through the PWARibbon.xml file, which can be a bit daunting, but after a while you will understand the structure and finding the Id’s will become simple.

SharePoint ribbon customisations use a defined XML schema which describes the structure and behaviour of the ribbon and the items that make it up. In order to disable the EPT Change button, we need to override the current structure and behaviour to change the configuration of what the button will do, in this case, pointing to a command that doesn’t exist.  In doing so, the ribbon will disable the button for us, giving us the desired effect.

To get the various attributes of the button, the PWARibbon.XML is your friend, containing all the configuration information you will need. In this case I have taken the configuration of the button and changed the command to point at a non existent command, which will cause the button to be disabled. This XML then needs to be put in the Element.xml file ready to be built, but more on that later.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="">
			Title="Disables the EPT Change button in the Project Center Ribbon">
				<CommandUIDefinition Location="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change">

Removing a button

The XML code required to remove a button is simpler. Instead of defining the XML for the whole button, all that is required is to redefine the CommandUIDefinition as per below.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="">
				<CommandUIDefinition Location="Ribbon.ContextualTabs.ProjectCenter.Home.ChangeProjectType.Change" />

When PWA parses the XML it uses this to remove the button as key items are not defined. Once again, all that is required to remove the button is to move this XML into the Elements.XML file and save ready for building.

In both cases, if you wish to hide or disable more than one button, you will need to duplicate the Custom Action mark up and change as necessary for each button.

How to Build

Finally once the configuration is completed, all that is required is to build and deploy the solution. To do so, right click on the project name and choose build, if everything is ok, you should see something similar to this in the build output:

Build Succeeded

If the build fails, then there may be a problem in your code. I have packaged the code up I used to build this post into a zip file which is available from my Skydrive account so you can compare or copy.

Once the build is successful you can deploy the solution by right clicking on the solution name and choosing deploy. VS 2010 will then deploy the solution to the site you entered for debugging and activate the solution in the site collection.

Activate Feature

Once the solution has been activated, you should see the changes to the ribbon in Project Center.

As you can see from above, creating a custom feature to hide or disabling buttons in the ribbon is relatively simple once you have the basic structure in place. Hopefully this post has explained how to build these customisations for use in your next project or internal implementation.