Using the Azure VM Role to Host SharePoint Functionality

I was recently asked by my manager, Vishwas Lele, to look into hosting SharePoint in an Azure VM Role as a part of a demo. Specifically, he wanted to see if it was possible to create a scalable cloud based Excel Services processing engine capability. After a bit of trial and error we found that it is possible, but you really need to be aware of what you are doing.

[Disclaimer]
I will caveat this by saying licensing considerations aside, doing this is at your own risk as VM Role state is not guaranteed to be maintained. That is, Microsoft could decide to move your image to another physical node and in doing so they will revert to your image baseline. Any customizations / configuration done when the node was brought up in Azure will be lost. As such, all state needs to be stored externally / configured prior to uploading your image / configured using an adapter or startup task. An alternative is to use the Azure Connect components to bring the cloud instances into your domain and host your sql server on premise. The downside though, is that you’ll be dealing with network latencies and still need to dynamically add / remove nodes from your farm. If you are looking to really host content in the cloud using SharePoint, then you’d be better off using Office 365 and SharePoint Online.

That being said, the process is pretty straight forward. The high level steps are the similar to what’s on MSDN. For the demo we:

1. Created the base VHD.
2. Installed the Windows Azure Integration Components.
3. Installed SharePoint bits using SQL Express.
4. Created a SharePoint farm using local accounts only (Requires PowerShell).
   1. Take note of the port used to host Central Admin as you’ll need to configure your Azure service definition with this port. (I’d recommend configuring it to use SSL)
   2. For our demo we configured the following service applications: State Service, Security Token Service Application, Secure Store Service, Application Discovery and Load Balancer Service Application, Excel Services Application, and PerformancePoint Service Application.
5. Created a web application on port 80 (I’d recommend configuring it to use SSL on port 443).
6. Configured Excel Services.
   1. Under Global Settings we configured the File Access method to use ‘Process Account’ and allowed enabled ‘Allow Cross Domain Access’.
   2. Under trusted file locations, we added an http location pointing to an unrestricted container in blob storage. This is so we don’t have to upload the workbook each time a new vm instance is brought online.
7. Uploaded the VM to Windows Azure using csupload.
   1. Note that we did NOT sysprep the image.
8. Created the service model.
   1. The service model should contain the two end points for central admin and the default web application.
   2. Note: It would be a really good idea to configure SharePoint to use SSL and add the certificate here as well, but we didn’t for this demo.
9. Deployed the deployment package and brought up a node instance in a hosted service.
10. Browsed to our central admin and default web application using the local accounts.

That’s it!

One thing we did find, is that the since the Azure load balancer is basically round robin, calls to excel services will fail if you have multiple instances of the VM Role configured in the same hosted service. The reason is that you get load balanced across multiple instances for each request and the Excel Services calls aren’t atomic. You could write your own service that wraps all the needed Excel Services calls into a since WCF call, or you can simply create multiple hosted services with one VM Instance in each. Then implement your own round robin scheme from the client.

Advertisement