I’m super excited to announce the public availability of Azure Search Client Library, a client library which works as a wrapper around the REST API available for the Azure Search Service.

This library intends to make you development tasks easier when it comes do doing any management or querying related tasks on your Azure Search indexes. The client library is available on NuGet (https://www.nuget.org/packages/AzureSearchClient) and the current version is 0.5.5355.2536. I’ve also written a short Getting Started-like documentation which is available at

Among others, this NuGet package is also my first and foremost ever NuGet package publicly made available on NuGet.org so I’d appreciate it even more if you’d leave comments on whatever you’d like to see next in the package.



Today Microsoft announced a ton of new services available within Azure, and one of the services which excite me most is the new Azure Search Service. Even though it’s still under preview, I have had the chance to test it throughout the last couple of months and let me tell you: if you’ve been struggling to get a performance search service but still minimize the maintenance cost, the right answer might actually be here!

The idea of Azure Search Service is to make it easy for developers to create search mechanisms inside their apps, whether they are desktop, web or mobile applications. Moreover, by saying easy, I actually mean that using Azure Search Service, developers don’t have to worry about complex management tasks (index creation, document updates, index updates etc.) or complex infrastructure tasks.

Creating a new Search Service is as easy as accessing the Azure preview portal (http://portal.azure.com) and selecting New > Search. In the new blade, simply enter a name for your service (your service name will be used as a hostname for your service, so if you’ll use a service name such as ‘AzureSearchTest’, you’ll end up requesting azuresearchtest.search.windows.net. You’ll also have to choose a pricing tier from the two available: Free or Standard. They differ by the number of documents one can store inside the service, the number of indexes that can be provisioned and by how resources and allocated to the service (might either be shared – in the case of a free tier – or reserved a.k.a. dedicated – in the case of a Standard pricing tier). Moreover, choosing the Standard pricing tier you’ll also get the option of scaling up the service by up to 36 search units.

By scaling a service, you can choose to either increase the number of replicas you get for your service, and thus support more requests (searches) per second, and/or you can choose to increase the number of partitions your service uses and thus increase the number of documents allowed withing your service.

There’s great documentation of the Azure Search Service REST API on the azure.com website here: http://azure.microsoft.com/en-us/documentation/services/search/.

Also, I’ll very (very very) soon post an updated regarding Azure Search Service that will most likely make your .NET developer life even better. Stay tuned!



Should you see your geo-redundant storage accounts marked as degraded in the Azure Preview Portal, don’t worry about it: there was a indeed a bug the team has already fixed just about this: grs standard storaged accounts were marked as degraded even though they were working fine.

Here’s a link to a forum topic around this matter: http://social.msdn.microsoft.com/Forums/en-US/9df38284-179f-4a8a-9c5f-0b5995262a7f/preview-portal-standardgrs-storage-accounts-appear-as-degraded?forum=windowsazuremanagement