Office 365 SharePoint hybrid – what you DO and DO NOT get

As far as I can see, more and more clients are interested in “hybrid” these days – the idea of running some of their SharePoint sites in Office 365 (SharePoint Online), and some on-premises. For any organization where the I.T. group is thinking is “we like cloud, but not for everything”, the hybrid idea can be quite appealing. There can many reasons for hybrid – companies wanting to supplement their on-premises capability (perhaps for the “quick spin-up” that Office 365 offers, or to leverage particular features/functionality such as Power BI), companies doing phased migrations to the cloud, or companies with regulatory or data sovereignty constraints – hybrid can work well for these scenarios and more.

TechNet has some great coverage of hybrid configuration process (start with Hybrid for SharePoint Server 2013), but folks who are new to the landscape (especially less technical types) are often surprised by what you actually “get”, and what you don’t, in hybrid mode. Search is a particular area where you get a certain deal – and this may or may not match up with what users are expecting. This post started out as an exploration of that, but I realised that some folks might appreciate some background on hybrid before that, so I’ve split the content up into:

1. Office 365 SharePoint hybrid – what you DO and DON’T get [this article]
2. Office 365 hybrid and search – presenting results from both on-premises and SharePoint Online sites

In many ways, hybrid looks SO SIMPLE! I mean, as TechNet shows, you have some sites in Office 365 and some on-premises – frankly, my mother could probably architect this stuff, right?

In reality of course, there’s a HUGE amount to consider for a hybrid deployment! In a straight comparison of “100% on-premises”, “100% SharePoint Online” and hybrid, I think most would agree that hybrid is the most complex option. After all, you have to do all the on-premises planning (e.g. planning the SQL layer, planning for service applications etc. etc.), in addition to understanding how you will configure and use Office 365. Also, hybrid typically requires extra on-premises configuration (DirSync, maybe ADFS, and maybe reverse proxy infrastructure). And if you’re doing any kind of customisation, there is complexity there around how you build for on-premises vs. SharePoint Online (or perhaps your customisations need to always work in both) – the list goes on.

Hybrid – what you DO get

So, hybrid isn’t necessarily the magical solution it sounds like it could be. That’s not to say it’s not the right solution for you/your client – as an aside, it is for my current client. But it’s not a turn-key solution where you set “Mode = hybrid” and Office 365/SharePoint magically sets things up and all aspects of your deployment are covered. Instead, SharePoint hybrid really covers three areas:

• Search
  • Being able to search across both environments (with caveats – see later)
• BCS
  • Being able to access data in on-premises applications/systems from Office 365
• Duet integration (SAP)
  • Being able to access data in on-premises SAP from Office 365

And that’s really it.

It’s true to say that some aspects of SharePoint can easily be made to work in a way which suits hybrid – My Sites, for example, can be made to exist only in SharePoint Online (if that’s the preferred option) by redirecting the My Site host to the URL in the cloud.

But otherwise, that’s basically what hybrid looks like.

Hybrid – what you DON’T get

So now let’s think about what you don’t get through “native support” – in other words, things you will need to plan for and spend time implementing yourself.

You don’t get:

• Any kind of global navigation
  • A key issue here is the “Sites” page (where a user can find to links to”bookmarked” sites/documents i.e. things they have followed) – if a user follows a site/library/document in on-premises, that will NOT show up in the Office 365 sites page!
• Any kind of global site directory
  • Indeed, SharePoint 2013 no longer has an out-of-the-box site directory of course, it was removed from the product
• A joined-up social/newsfeed experience (if you are using SharePoint social rather than Yammer) across Office 365/on-premises – there are numerous issues here, but essentially any activity such as likes, comments, follows etc. in on on-premises environment will not appear in the newsfeed in SharePoint Online
• A great search experience
  • Instead, search results are displayed in separate blocks from Office 365/on-premises – more on this later
• Any kind of auto-deployment/synchronization of:
  • Branding
  • Master pages
  • Any other customisations packaged as (sandbox) WSPs
  • Taxonomy/Managed Metadata
    • There are numerous considerations here – all related to having two Managed Metadata Service Applications (one in Office 365 and one on-premises)
  • Content types
    • (And if you’re wondering if you can leverage the Content Type Hub, by “chaining” together an on-premise CT Hub with one in SharePoint Online – no you cannot)
  • Document templates (e.g. MyCompanyProposalTemplate.docx)
  • Many aspects of configuration:
    • e.g. Search settings (best bets, search suggestions, search schema such as managed properties etc.)
    • e.g. List and library settings (workflow, versioning settings, policies etc.)
  • Many aspects related to apps
    • Apps available in the App Catalog (because you cannot share an App Catalog between SPO and on-premises)
    • App settings (e.g. whether apps can be installed from the Store)
    • Apps which are being monitored
    • Authentication of provider-hosted apps across SPO and on-premises usually requires some planning
  • Some aspects of user profiles
    • Custom properties
    • Sync across Office 365 and on-premises profiles (i.e. you need to separately configure sync from AD to both locations)
  • [… and no doubt there are lots of other things to add to this list too]

Hopefully you get the idea - in summary, there really is only a minimal link between your Office 365 tenant and your on-premises SharePoint environment (covering search, BCS, etc.). If you need something in both places - and you often do – you’ll need to take care of that yourself.

The hybrid search experience

Search is high on that list of things which get “interesting” for hybrid. After all, your SharePoint sites are split across (at least) two environments, but you’ll usually want users to be able to search across all content easily – without having to go to two different search engines. Providing a global search can certainly be done, and if you’re new to this area there are several options (all of which require some configuration to be done in the on-premises environment at least):

• Outbound hybrid – search center in on-premises environment brings in results from Office 365
• Inbound hybrid – search center in Office 365 brings in results from on-premises environment (requires a supported reverse proxy device)
• Two-way hybrid – both search centers can display results from the other environment

Configure hybrid Search for SharePoint Server 2013 is the best place to start on TechNet.

In all cases, there are limitations - most folks don’t realise that there is no way to “merge” the search results together. There are two possible options:

1. Add a Promoted Result (i.e. a “best bet”)
2. Add a Result Block
3. [OK, so you can also transform the query and therefore change the results – but this doesn’t help in merging the search results.]

The Result Block approach will probably be the most common. But both this and Promoted Results are poor for the client who is expecting to “just search across everything and show me the most relevant things!” This is what the Result Block approach looks like (Office 365 Result Block in red, results from on-premises content in blue):

In other words, it’s very much like a “federated” search experience – the search is executed in two stages:

• The local SharePoint environment is searched and results returned
• The query is also “sent” to the remote SharePoint environment, and results returned

The page then loads and shows both sets of results (assuming some items match in both places). But this experience can raise some questions:

• How many results should be shown (from each source) on page 1?
  • HINT – you’re only allowed a maximum of 10 for a Result Block anyway :)
• What about paging? What happens when I go to page 2?
• How can I easily see more results from both sources?
• How do I determine which results are more relevant, from the local or remote environment?
• Are there any options for seeing the results in a more integrated way?

In my next post, I’ll talk about some options for merging the results – including how you might do it, caveats around this, and so on. But hopefully this post provides some background information on hybrid before then. If it sounds like I’ve painted a negative view of hybrid, that’s not my intention. It can work great, but I think it's worth noting these considerations - I do find many folks have expectations that don’t necessarily match how the bigger picture works in practice.