Post is updated, see comments at the end of the post.
We’re really getting close to the go live of Office 365 and I am, and I guess a lot of you are as well, preparing to launch a couple of Intranets and sites. As you know by now there are some major differences between SharePoint 2010 on-premise and SharePoint Online in Office 365. And there are also some more subtle ones that jumps up right in your face.
Today we were designing a topology for an intranet and we thought that we could use Search Scopes to search and aggregate data. Site Collection Search Scopes are available in SharePoint Online, but you cannot access the Search Service Application and create global Search Scopes. That’s fine, we’re in a megamulti-tenant environment here. Search Scopes are very convenient to use when you would like to do a search for a specific type of documents or information since you can create Property Query based Search Scopes. This is how it looks like in a standard on-premise SharePoint 2010:
So I tried to do the same thing in Office 365! And found out that a Property Query is not possible to create. You can only create Search Scopes based on the Web Address/URL! Sigh! I can’t really see why this is disabled (see update below). Yes, I understand that they won’t let us create Managed Properties, but this is to sneaky!
So back to the drawing board for me!
Update!
After some discussions on Twitter with SharePoint Master2 Mirjam van Olst the actual answer wasn’t that far. She led me to the SharePoint Server 2010 capacity management: Software boundaries and limits document on TechNet (which I read a gazillion times lately when studying for the MCM). This document clearly states that the Threshold is “200 site scopes and 200 shared scopes per search service application” and “Exceeding this limit may reduce crawl efficiency and, if the scopes are added to the display group, affect end-user browser latency. Also, display of the scopes in the search administration interface degrades as the number of scopes passes the recommended limit.”. This of course does not work in a multi-tenant environment. Notice that it’s only a threshold.
But! Why can we create URL based scopes? To find out I created two different scopes in an on-premise box and took a peek on the SSA admin database (I only looked, no hands!). All scopes global or site collection scoped are stored in the SSA admin database and compiled every 15 minutes. Both property query rules and URL rules are treated the same. That lead me to the lovely SharePoint protocol specifications, and specifically the MS-CIFO which describes the index files. This document describes how the scopes are handled in the index, using the Scope Index File format (.bsi files). My interpretation of the specs are that these files in the index are used when querying using a specific scope and therefore affecting the crawling since they are index files and behaves just like any index with merges etc. I didn’t go any further…
I still cannot tell for sure why URL rules are allowed, but my best guess is that they do not affect performance in the same way as property based rules are. So in Office 365 URL rules can be used. Also, since URL based rules are not that useful they will not be used as much anyways…
/end update
(Notice that I didn’t mention “cloud” anywhere…dang, I just did…)