On October 9th I’ll speak at the Coding Serbia conference in Novi Sad about Design Patterns For Scalable Microsoft Azure Cloud Applications. The session starts at 11:00 AM.
See you there!
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.
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
If you’ve ever received support from the Microsoft Azure Support team on Hosted Services/Cloud Services, you might want to know that the great team that supported you (which, by the way, in order to offer 24/7 support is deployed around the world!) has used a tool which allows them (and since last year, you too) to debug slow performance, hangs, manipulate HTTP traffic, analyze network performance, transfer files, recall a debugged machine from the load balancer, check the defined inputs on your service’s roles and so on.
Please be advised that this is actually an in-house tool developed by Microsoft and is arguably, the most handy tool to have whenever something works unexpected in your cloud environment.
Hope you’ll find it useful at some point.
I recently worked on a presentation seminar about Microsoft Azure related functionalities and I remembered that there’s a set of all the marketing symbols used around Azure which is extremely useful for scenarios like mine. There it is: http://www.microsoft.com/en-us/download/details.aspx?id=41937
Hopefully this helps you out.
In April of 2013 we held the first Global Windows Azure Bootcamp at more than 90 locations around the globe! This year we want to again offer up a one day deep dive class to help thousands of people get up to speed on developing Cloud Computing Applications for Windows Azure. In addition to this great learning opportunity the hands on labs will feature pooling a huge global compute farm to perform diabetes research!
Today I am proud to announce that I am going to both host and speak at the GWAB 2014 event in Oradea, RO. Here’s the conference link: http://gwabor.azurewebsites.net
See you there!
I’ve been scrathing my nerves trying to get around an Azure Cache relates situation that I came across in one of my recent projects.
There are multiple caching scenarios and options available for Azure, but I’m going to talk about this in a different post. For now, just keep in mind that I decided to go with a dedicated co-located role for caching, which basically means a different VM that serves all the caching request. I’ve also configured the caching clients (all the pieces of code that request cache) to use the caching cluster configured on that Azure Caching Role.
In order to configure that particulat scenario, you have several options available for importing the references (.dlls) and configuring your configuration files (mostly web.config sections), but the most common and simple usage scenario is to go with the NuGet Package Manager and install the Windows Azure Caching package.
As of 31st of July, the latest version of WAC package is 184.108.40.206. Moreover, if you search around your favourite search engine a little, you’ll come across an article mentioning the WAC package and that you should configure the NuGet package Manager to show pre-release versions of the package as well. This article was posted somewhere in late-June. IMHO, once I saw 220.127.116.11 was already a stable release, I was amazed and pleased by the hard work of the Azure team at Microsoft.
After installing the package, I got this strange exception in my code:
There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable, which could be caused by busy network or servers. For on-premises cache clusters, also verify the following conditions. Ensure that security permission has been granted for this client account, and check that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the serialized object size sent from the client.). Additional Information : The client was trying to communicate with the server: net.tcp://MvcWebRole1:24233.
The inner exception stated:
No such host is known
Unfortunatelly, both exceptions are extremely generic, considering the cache cluster name is configured corrently and running smoothly (you can always use the Azure emulator to confirm). However, the code just decided not to run.
After a little more research, I found out that MS also announced the new SDK, namely Windows Azure SDK 2.1. However, this time they didn’t do all the usual marketing campains for some reason that I’m not really aware of. I also found out that the latest release of the WAC package only works with that specific SDK (apparently reading the NuGet package description is required ), so here I am, running this line of script in the Package Manager console and making everything work:
Install-Package Microsoft.WindowsAzure.Caching -Version 18.104.22.168
I hope this post finds you in good peace and helps you solve similar problems in a shorter period of time!
P.S.: sometimes (random cases), the script for installing the WAC package (v. 22.214.171.124), after uninstalling WAC 126.96.36.199 fails. Don’t worry though, since the web.config file is correctly modified by the WAC installer and all the references exist and are correctly included in the project.
One other situation I recently came across was regarding WIF and the pipeline security applied to it. Basically, due to up-scaling a project from one server (I know…) to multiple-instances, the app kept going into infinite redirect loops (HTTP 302), thus not allowing users to wander around the app. The case like this:
1. The user first visits the page
2. The user clicks anything in the page
3. The app goes into infinite 302.
The situation was cause by the security mechanisms the make the ASP.NET session authentication secure. Basically, by default, the DPAPI security providers are used. This basically states that for every single new session, a random key is generated that the user can wander around. That key is normally kept in the session providers, but is related to the keys used by the machine. Obviously, in a webfarm scenario (such as a multi-instance cloud service), DPAPI is useless and causes a CryptographicException to be thrown, since the FedAuth cookie gets encrypted by one machine and when you redo a request to your app, the cookie can no longer we decrypted.
If, for any case, you have a custom error page and if you, like in my case, must have the security mechanisms inside a Master page and mostly if the Error page inherits the Master page, you will, like me, get an infinite redirect loop (302).
The solution to this is to configure (using the web.config file) your IIS machines to use another security pipeline mechanism, such as MachineKey encryption. Moreover, it is obviously required to configure a static machine key and validation key, yet most Google-related results for this situation fail to remember that such a setting is required. Otherwise, the different machines in the web farm still get different keys and the FedAuth cookie won’t decrypted, failing in the CryptographicException all over again.
The required configuration for web.config for replacing your DPAPI security mechanisms with MachineKey cryptography is:
<add type=”System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />
<remove type=”System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />
As for the machine key, you have to choose an appropiate key size (only HEXA-DEC chars), as mentioned on this MSDN article on machinekey configuration in ASP.NET 2.0 (I know it’s old, but it’s still valid for ASP.NET 4.0).
Choose an appropriate key size. The recommended key lengths are as follows: