Back: Set References


Service Configuration Files (Cloud and Local)

NOTE: You can edit these files through the role configuration UI or directly.  These instructions will only deal with the UI approach.

  • Configuration page / Diagnostics
    For Local configuration, select UseDevelopmentStorage=true.
    For Cloud configuration, select one of your Azure storage accounts.
  • Settings page
    • managerPrimaryStorageAccount – this is a storage account that WAMR will use for its own needs.
    • autoscaling – this is a storage account for the use of the WASABi system
    • Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString – this should already be set from the previous section
    • RDP settings – when you deploy to Azure, be sure you reconfigure the RDP settings to your own requirements
  • Local Storage – when you export your database with this tool, it exports to your local storage.  Set the size of a file system storage resource named “ExportLocation” to a size sufficient to export your database.  The maximum local storage available to a role instance depends on the size of the VM (number of cores).  These values are listed here.
  • Certificates
    • AzureTableWCFDataService – this is the name of the service in my test system.  It’s the “service to be scaled” by WASABi. Rename this certificate to something suitable for you and insert the thumbprint of the management certificate for the subscription that it’s installed in.
    • Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption – this certificate is for RDP into the WAMR role instance.  When you upload the solution with Visual Studio and reconfigure RDP, your own RDP cert will be set up here.
  • Virtual Network – no settings
  • Caching – no settings


Adding the new tasks for handling deployments required adding a few settings:
wamrDeploymentsStorageAccount, wamrDeploymentsContainer, wamrDeploymentsStorageAccountAlias

Similarly, the CopyBlob task required a couple:
AccountAliasA, AccountAliasB


It’s easiest to modify these settings with EnterpriseLibrary.Config.  If you’re taking the manual approach, you’ll want to eyeball the app.config and modify according to your own environment.

Visual Studio 2012 implementation

The things to look for are the blob container name’s and storage account’s in the autoscalingConfiguration section.

Visual Studio 2010 implementation

You’re basically starting from scratch with VS2010.  Copy sections out of the downloaded app.config and tailor similar to the guidance for VS2012.

Here’s a link to the schema of the autoscalingConfiguration Element.


Because WASABi was compiled with a dependency on the older Storage Client libraries, assembly binding statements are needed when working with the 1.8 SDK.


When switching over to the 2.0 SDK, it became necessary to add another assembly binding – this time for ServiceRuntime. 


This file describes to WASABi the various services and roles within those services that you want to auto-scale.  It also defines the storage accounts that you will be pulling diagnostic information from.  This file contains credentials for your storage accounts, so take appropriate measures to protect it.

NOTE: WASABi was designed to operate on multiple services and roles.  As you can see from the design of the service-definition.xml file, all the information needed to identify the services and roles within those services-to-be-scaled is defined.

  • <subscription> elements
    Fill in the subscription ID of the subscription that contains the “services to be scaled”.  Another attribute of this element is the thumbprint of the management certificate of that subscription. This is the same thumbprint that you inserted into the Service Configuration files. 

    NOTE: In an Azure worker role, the default certificate location is LocalMachine.  On your developer workstation, it’s CurrentUser.
  • <service> elements
    • dnsPrefix – the DNS Prefix of the “service to be scaled”. 
    • slot – Production or Staging
    • scalingMode – Scale
  • <role> elements
    • alias – the name that is referenced in the rules-store.xml file (a few lines down in this page)
    • roleName – the actual name of the “role to be scaled”
    • wadStorageAccountName – an alias that is referenced in the <storageAccount> element (below)
  • <storageAccount> elements
    • alias – matches the wadStorageAccountName from above
    • connectionString – your account name and account key. 

      NOTE: this is the storage account that will contain the diagnostics information output by the service:role above
  • <queue> elements – while not in my example, you can scale a role based on the depth of the queue that feeds it tasks. 

For full documentation of the schema of this file, see: Service Information Schema Description


The rules store file will work as is for an initial test.  It’s set with guard rails set and 1 and 3 – meaning that your role won’t be scaled below 1 or above 3 instances.  It’s also set to scale up if the CPU goes above 75% and down if it goes below 50%.

Here’s the full documentation of the rules store schema: Rules Schema Description

Next: Functional Capabilities

Last edited May 30, 2013 at 7:39 PM by sebastus, version 4


No comments yet.