We are starting work on enabling Sitefinity Search on Windows Azure cloud environments. The main goal of this feature is to enable the use of Sitefinity Search - indexing and performing search in cloud environment. For the purpose of this we intend on integrating with external search services such as Apache Solr or ElasticSearch.
We would be happy to hear about your use cases and requirements for setting up Sitefinity Search in Windows Azure deployments.
We will be posting updates on the feature in this thread. You can subscribe and follow it for updates.
While you're working with Search, please add Search widget templates.
This is great news. Its been an outstanding issue for a while.
Yes I would love to see Azure Search as an option as well.
Search to work for Sitefinity running on Azure Websites. Not Cloud Service.
I wrote a post on how I currently achieve it
Multiple instances of Azure websites.
I would love to see more support for Sitefinity in Azure in general. For example extending the Sitefinity cache to use The Azure cache so we can run it on many instances.
Please also consider Azure Search as well.
Thank you for the suggestion Jason. We will put this on the list of possible solutions as well.
Very interested in the integration with ElasticEearch in Azure.
We have decided that our main focus will be integrating with the Azure Search service. The integration with Azure search will also be functional in non-Azure deployments. Apart from integrating with this search service will will be also investing time in making sure that the Sitefinity Search API allows developers to plug into external search services with minimal implementation.
For anyone willing to preview this feature - we will push a preview build for this feature in the beginning of November.
We are ready with the preview build. Please note that this build is intended only to preview the support for Windows Azure search feature and should not be used in any projects that are in production or under active development. This build does not contain other upcoming features, the only difference with Sitefinity 7.2 is the support for Azure Search. In order to run the preview build you will need a valid Sitefinity 7.2 license. Further information on what's included in the preview build can be found below:
This feature allows the use of Sitefinity Search in Windows Azure cloud service deployments. However the feature can also be utilized in other deployment scenario - for example VPS or Load Balanced environment. In order for the Sitefinity Search to be running on Windows Azure, an instance of Azure Search must be created. Details about creating such service can be found on the azure website: http://azure.microsoft.com/en-us/services/search/
After the search service has been set there are few settings that need to be considered:
These two properties will be needed for Sitefinity to connect to the Azure Search and fetch / push data to the cloud service.
In Sitefinity we have introduced a new basic settings section which allows choosing of the following options:
If AzureSearchService is chosen, there will be options to enter the URL / IP address where data will be sent and also API key. In both fields, the data should be corresponding with the data from the Azure Search service that was previously created.
After the changes are successfully saved, a search index can be created, which will exist in the cloud.
For the Azure Search we use 3rd party SDK, built to provide usable API for the Azure Search calls. The SDK is called RedDog.Search. The SDK and its API are open source. We plan repacing the RedDog.Search SDK once Windows Azure releases officially supported SDK for Azure Search.
The search result contains 2 results if we search for thread or post.
As the exceptions are not handled (yet) there might be YSODs (e.g. if there is an Azure connection error).
You could check Error.log file for possible problems.
This is the interface of the application service (in contrast to a web service) in Sitefinity responsible for full-text search capabilities of the system.The default implementation, coming with Sitefinity out-of-the-box is based on Lucene.Net and keeps the search indexes on the disk.
By implementing this interface and replacing (using ObjectFactory.RegisterType) the default implementation with a your custom one, you can make Sitefintiy talk to a different search backend, like ElasticSearch, Apache Solr, SharePoint Search, etc.
Sitefinity calls the UpdateIndex method of the registered (your) implementation on each item creation/modificaion, providing a collection of IDocument instances to be added/updated into the index.
Sitefinity calls the Search methods of the registered implementation each time the user uses the built-in search box widget. If you ensure that the built-in search box and search results widget are not used in your site you can skip implementing those and use your custom widgets to directly query the search backend of your choice.
The Search method takes ISearchQuery as a parameter. In the default implementation the query is created and it's ISearchGroup groups are built using IQueryBuilder's BuildQuery method. You can add/remove groups to the query once its built.
ISearchGroup - Contains ISearchTerm and ISearchGroup enumerations. When building the search expression, the goup's Operator is used between the terms/groups.
ISearchTerm - Describes a search term with it's Field and Value.
MySearchResults : SearchResults
MySearcher : SearchResults.ISearcher
.control = control;
var control =
var service = Telerik.Sitefinity.Services.ServiceBus.ResolveService<ISearchService>();
var queryBuilder = ObjectFactory.Resolve<IQueryBuilder>();
var searchQuery = queryBuilder.BuildQuery(query, control.SearchFields);
searchQuery.IndexName = catalogue;
searchQuery.Skip = skip;
searchQuery.Take = take;
searchQuery.HighlightedFields = control.HighlightedFields;
// Contains the default filter - by current language
var currentFilter = searchQuery.Filter;
var myDatesFilter =
myDatesFilter.Operator = QueryOperator.And;
// Here we add a clause, that only results for the last 10 days will be displayed
, DateTime.UtcNow.AddDays(-10), FilterOperator.Greater));
// Persist the language filter, if exists
searchQuery.Filter = myDatesFilter;
IResultSet result = service.Search(searchQuery);
hitCount = result.HitCount;
You can download the preview build from here.
A sandbox is also available here: http://azuresearchpreview.cloudapp.net/.
Okay so it seems to behave just as poorly as Lucene
Is this a gimpy azure&lucene thing or a sitefinity thing? Like Christopher should come up in the results without the user needing to put in a wildcard character (Chris*). More along the lines of the Google-Like...but just curious.
In fact this is the default behavior. It will be a breaking change if we change it but you could easily substitute the ISearchService implementation and provide your own. (e.g. derive from AzureSearchService and change the implementation of the Search method as you prefer.)
I agree with Steve. I would say that it is worth introducing this as a breaking change. Take full advantage of the new abilities at the start.
Do a targeted survey of customers.
Or provide two versions. Azure Search with the old way or Azure Search with the new.
We will change the default search behaviour. We are thinking of always using starts with for search terms. So when you type in Chris it will also return results for Christopher.