This is really just a “note to self” because I always forget where this settings lies.
Activate On Default is property of a feature. You can find it by opening the Feature Designer and then looking in the properties window. It is the first property under the SharePoint section.
This property determines whether the feature will be activated when the solution is activated. My preferred approach when developing a publishing portal that requires web templates, is to only have the ‘web templates’ feature activated this way and have any/all other features activated along with the root site web template.
Note that this property has no impact on the set of features which are activated when deploying the solution via Visual Studio. You can configure this somewhat using the ‘Active Deployment Configuration’ property of the project. You can try something like the following from Mavention for more granularity: Mavention – activating selected features
For solutions that are contained in a single site collection, or span a small number of site collections, or are in a tenant where the other solutions are not trusted or are unknown, then I have a strong preference to use site collection scoped search schema rather than tenant scoped.
Side note: I am yet to come across a situation where I would use site scoped search schema. In my mind, the existence of search schema at this level only serves to confuse.
Search Schema hierarchy is SharePoint Online. There is also site scoped search schema at lowest level which is not present here.
For those that aren’t fully aware, search schema (the set of managed properties that are accessible via the search framework) can be provisioned at the tenant, site collection, or site scope. These scopes are hierarchical such that managed properties are inherited from the tenant scope down to the site scope but can be overridden along the way. There are some good articles that delve into this in more detail.
By provisioning search schema at the site collection level you are mitigating the risks of errors related to other solutions changing the properties which your solution relies upon. This is especially relevant in SharePoint Online where all solutions in the tenant have to share a common set of RefinableTypeXX managed properties.
There are some important exceptions, of course.
People Search, a.k.a User Profile Search, a.k.a Local People Results
In SharePoint Online, people properties are indexed on a very slow schedule. We requested more information from Microsoft regarding this and were told that this schedule is ‘confidential’. I have found that when using site-collection scoped managed properties it can take *weeks* for them to get populated. I have found much better (although still poor) performance using tenant scoped properties (usually within a few days). Assuming you do require custom search schema for people properties I would still recommend provisioning all remaining managed properties (all those not mapped to people properties) at the site collection level.
Many site collections
Of course, having many site collections which require the same search schema is valid reason to go tenant scoped. This is purely due to management of the properties going forwards. A solid scripted deployment procedure should not care if you are provision search schema to 1 or 50 site collections – but anyone maintaining the solution will definitely care if they have update 50 schemas manually, or are suddenly required to script something which they feel should be *easy*. Even in this scenario you should still consider how much you trust other solutions in the tenant against the impact of finding out that one day your managed properties are mapped incorrectly. Depending on your solution this could lead to errors that are left undetected, or conversely obviously break your home page.
In SharePoint Online I have detected a bug that prevents the suite bar logo (configured in the o365 tenant admin center) from being rendered after applying a theme with a non-default colour scheme. The logo is not just hidden or not visible; the HTML is no longer rendered to the page at all.
NOTE: This issue has been raised with Microsoft and they have acknowledged it as a bug. They have told is that a fix is planned for June 2015 and should take a couple of weeks to reach all tenants.
Update 06/08/2015
I was advised last week that a fix this issue had officially started rolling out. Today I can confirm that one of our test tenants no longer exhibits this behavior! At the time of writing some of our tenants have not yet received the fix, but it is definitely rolling out and should be with you soon if not already.
When exactly is this occurring?
There is a colour scheme file that nominated as the default for each master page. Only when using this colour scheme in conjunction with the given master page will the logo be present. Specifically, only a colour scheme which is nominated as the default colour scheme will show the suite navigation logo.
This is unrelated to any customisation work and can be observed on any OOTB SharePoint Online publishing site.
The default colour scheme for a given master page is nominated within that master page’s preview file. The preview file is the one which sits alongside the master page in the master page gallery and has the same name name as the master page but with an extension of ‘.preview’ instead of ‘.master’ (e.g., seattle.preview). The first line of the contents of this file identifies the default colour scheme for the master page. When this colour scheme is applied, the theming engine assumes that the CSS is already themed appropriately and does *not* act.
Identifying the default colour scheme for a master page
I still want the logo on every page, what can we do?
As I have said, a fix is on the way – just wait a few months!
We can inject the logo using JavaScript (or CSS, but we were unable to achieve a CSS only solution which meets our responsive design requirements)
It is against best practice
This approach is brittle as the suite bar is a living, changing thing – Microsoft is updating it all the time and any changes they make will likely break this functionality.
The logo will no longer be configurable via tenant admin settings.
We can create and use multiple master pages – one for every theme colour
Partially defeats the purpose of master pages which is to maintain all common pages elements in a single place.
Master pages may fall out of synch
Adds complexity for support
I want to reproduce this myself, how do I do it?
Create an new site collection in a tenant that has a suite navigation logo configured, using the Publishing Site template
Note that the logo is present
Via Site Settings, “Change the look”
Choose the “Office” composed look
[Specifically, we want the seattle master page and colour pallette 001]
Change the colour scheme to anything except the default
Apply the look
Note that the logo is no longer present
Re-apply the theme with the default colour scheme and logo will reappear
