Help! My Office 365 Suitebar turned black!

Recently I’ve been doing a lot of work in Office 365 for a client, and I must admit I’m loving it. No more fuzzing about with installations of Service Applications, or going in to IIS to see why the site isn’t performing the way it should – all of that stuff is managed by Microsoft for you. However, that also comes with a big ‘but’: forced updates.

Let me explain. In Office 365 updates are going to happen whether you like it or not. That’s all fine, and usually a great thing because it means you get all the new and shiny stuff quickly, while those with on-premises installations have to wait for a SP or even a next release. Microsoft introduced the ‘First Release’ feature which allows you to receive these new updates for a particular user (or tenant if opted that way) before it gets rolled out to your entire company or production tenant, which is a great feature and comes in handy when testing out new functionality or an upgraded UI. There are still some changes however that can have major impact on the UI of your SharePoint sites that are not pushed through the First Release function, nor are they communicated about in any way.

One such major UI changes occurred a few weeks ago, around the 25th of August 2015. Let me explain the scenario first, and then I’ll get into the details of the change (and how to fix it). We have several SharePoint Site collections that serve a different purpose. We have site collections that are meant purely for collaboration and contain team- and projectsites. Then we have site collections that are used for corporate communications, such as news, latest announcements, company history and vacancies, that kind of stuff. And lastly we have site collections meant for document management solutions. We opted to have as minimal customizations as possible, but we did want our end users to know which of the three intranet area’s they were currently visiting. We thought that theming (or Composed Looks) would be a great way of showing this. We created several color files and themes: blue; green and orange. The Suite bar would be the main way of determining which of the area you are visiting, and as an added bonus, it made communication about the new intranet a lot more clear (e.g. ‘Green’ received a major update today by allowing you to create your own team- and projectsites).

In came Microsoft and their forced updates. All of a sudden our themes were no longer applied to the Suite Bar. Everything else would still be visible, so links would still be a certain color and Page Titles were also still fully functional. The Suite Bar however was totally black, which is the default tenant setting. Our initial thought was that Microsoft must have had an update that contained a bug of some sort which is why this was no longer working. It wasn’t just for our own Themes, but the OOTB themes also no longer changed the Suite Bar color, so clearly something was going on. We opened up a premier support ticket and after a few days of investigating (for some reason they received lots of support calls about theming – geez, weird huh?) they replied the following:

Due to a multitude of customers’ request we changed the behavior.

What it comes down to is that customers want to keep the Suite Navigation bar the same across Site Collections regardless if a Site Collection administrator or a user wants a different theme.

Mainly because they want to keep the ‘Company’ color

Right. Okkaayyyy. It’s not a bug, it’s a feature! A non-communicated feature, which happened in our production tenant before it happened in our first release enabled test tenant. And it happened three days prior to going live with our ‘Blue’ intranet area, which was now no longer blue.

I can see the reasoning behind this ‘feature’. It does make sense to have one Office 365 company theme being pushed to your entire tenant, rather than let each site collection have their own color. I would have preferred it if they had gone about this a bit differently though. A few weeks prior to this change Microsoft added a new feature to the Company Profile – Theme section of Office 365:


Users can override a company theme in their Office 365 settings, but when this option is checked, those overrides are no longer valid. It would have made sense if they added a second check box here to ‘Prevent Site Collection administrators from overriding custom theming with their own theme’. That would enable tenant administrators to have control over the theming behavior, rather than the company theme being pushed down whether you like it or not. Alas, who knows, maybe Microsoft will add that second checkbox in the coming weeks or months.

Luckily there is still a way in which we can restyle the Suite Bar back to our ‘original’ color and that comes in the form of custom CSS styling. A few simple CSS lines will enforce the suite bar to turn back to the color of your choice. Using the CSS below, our Suite Bar turned back to an awesome shade of blue:

/* Fix the Office365 Suite bar */
.o365cs-base.o365cst .ms-bgc-tp,
.o365cs-base.o365cst .ms-bgc-tp-h:hover,,
.o365cs-base.o365cst .o365cs-topnavLinkBackground-2

I’m not a fan of !important – rather I try to avoid it at all times. However because the Suite Bar is loaded dynamically, it will reset back to black (or rather – the company profile theme color) if you don’t add it.

That’s it. You can add additional statements to this CSS to ensure the hover color is also set correctly, but in most cases this will be all. Simply add this CSS to any already referenced CSS file in your site collection. If you don’t have one yet, you can either use the Alternate CSS URL, or use CSS Injection techniques to make sure it is applied to every site within the site collection. In our case we already had a different CSS file for each section of the intranet, which were all referenced from a centralized location, so it wasn’t that much work. I can imagine however that if you have a multitude of site collections with a multitude of different Suite bar color, you have your work cut out for you. Oh well, I guess it’s not all peaches and cream being in Office 365 and having Microsoft manage a lot for you.


SharePoint Saturday NL 2015 Slidedeck now available

On the 6th of June I had the pleasure of presenting at the SharePoint Saturday NL event. It was the first time presenting for me, and I had a blast doing it.

Thanks everyone who attended! If you have any feedback I would love to hear it, either here or through twitter @vverbeek87.

Below you’ll find the slides used for the session:


Debugging a solution with multiple SharePoint Apps

In a very large environment it is not uncommon to have Visual Studio solutions that contain multiple different projects. However, when you’re working with these individual projects, you want to be able to quickly debug your specific project. I recently discovered, that when you do this in a solution that contains a Provider Hosted App, switching to and from the Provider Hosted App for debugging purposes, has some very specific gotcha’s…

Let’s create an example to see what I mean. I create a new solution with a provider hosted app (ASP.Net Web Forms Application). After the solution has been created, I add an additional project. This time it’s a console application. The solution structure, still very basic, now looks like this:


Let’s say I’m going to work on the Console Application first. So I right click on the project and select ‘Set as startup project’. I hit F5, and the console app launches and everything is working great. The debugger is properly attached, and my breakpoints (if I’d have any) are properly hit.


Now the Console application is absolutely perfect, and I want to continue working on my Provider Hosted Application. This is where the trouble begins… Which project do I set as startup project? First let’s see what happens when I set the PHApp project as startup and hit F5. So far so good… Visual Studio installs my app in my SharePoint site, launches IE and reverts us back to the apps default page. However… None of the breakpoints set in my PHAppWeb projects are being hit. Sure, IIS Express launches the web and handles the execution, but not being able to debug through your code makes things quite difficult doesn’t it?!

Breakpoint not hitting

Let’s see what happens when we set the PHAppWeb project as the StartUp project. I hit F5 once again, and great; my symbols have now been loaded! But wait… nothing else happens. Your default browser is not starting, and there is no way for us to reach the code unless we want to manually browse to the apps’ start page. That’s no good either!

So, what other choice do we have? The answer is in the solution properties. Right click on the solution and select ‘Properties’. In the ‘Startup project’ tab, you have the option to select multiple startup projects at once. So let’s select that option, and specify the PHAppWeb first with a ‘Start’ action, and the PHApp second, also with the Start action configured. The end result should look like this:


Now when we hit F5, the PHAppWeb is launched, symbols are loaded, and then the app is installed to SharePoint. Once that is done, the browser will start up and asks you to trust the app and then redirects to the apps’ start page. Exactly the way we want it to! Unfortunately, you’ll have to manually change this every time you set a different StartUp project.

So, in short, if for whatever reason your Provider Hosted debugging experience is a bit buggy, make sure to check the Solution Properties and check if both the AppWeb and the App project are configured with a ‘Start’ action. Gotcha!

Inconveniently working with App Permissions

Whenever you create an app, you have to think carefully about the permissions that the app needs on order to function correctly. Some apps can execute actions based on the permissions that the user has, but for other apps the app needs its own set of permissions. That is the case for example when you are working with remote event receivers in a provider hosted app.

When it relates to content creation, an app can request four different sets of permissions:

  • Read; (which corresponds to the default Reader permission level)
  • Write; (which corresponds to the default Contributer permission level)
  • Manage; (which corresponds to the default Designer permission level)
  • FullControl; (which corresponds to the default Full Control permission level)

These four different sets of permissions can be requested in one of four scopes:

  • List;
  • Web;
  • Site Collection;
  • Tenant;

It is important to note that whenever your app requests the ‘FullControl’ permission set, that particular app cannot be uploaded to the SharePoint Store.

During the development of your app you might have to switch the permission level that your app requires. On MSDN Microsoft explains how to change the apps permissions after it has already been installed. You can do so by navigating to http://<yoursharepointsite>/_layouts/15/AppInv.aspx , enter the app’s ID and update the XML related to the permission request. However, recently I found out that this in fact does not work in all cases. In one of our apps we used remote event receivers to create a new subweb, which requires the FullControl permission level. Currently we only had the Manage permission, so we had to change that. Updating the app and then re-trusting it unfortunately still resulted in a ‘You do not have the required permissions for performing that action’ error.

Following the above mentioned steps for updating our apps permissions also did not work. In fact, the only way to get the new permissions working properly, was to delete the entire app and then install it again. After that our new subwebs were properly created.

In short; there appears to be a bug in updating the permission request when developing your app and deploying it in an Office 365 developer site. In order to get the new permission request functioning properly, remove the app from your site and reinstall it. Gotcha!