How to Diagnose and Fix Windows Azure Development Storage Service Issues

On this thread in the forum Frank Siegemund posted some great guidelines on how to diagnose and resolve issues related to using the development storage services on Windows Azure.

I had a quick chat with Frank and asked him if I could repost that info in blog format.  Here it is, very useful:

Let me provide some general guidelines on how to diagnose and resolve issues when using the development storage services. 

The assumption is that you are using the StorageClient sample library from the Windows Azure SDK for accessing the storage services.

(a) If your first access to any storage service fails, it could be due to any of the following explanations:
    (1) the service is not started (local development storage scenario)
    (2) you did not configure account information or storage endpoints correctly in the configuration files for your service
    (3) there is an error reading the account information

(b) The easiest thing to check is issue (a1). 
    (1) Make sure the development storage tool is running (icon in the status bar; if not you can run it over the entry points in the Start menu)
    (2) Make sure all services are running; right-click the development storage item and bring up the UI; the status for all services must be "running"
    (3) If you use table storage locally, make sure that you selected the right database; again in the Development Storage UI you can see which database is selected in the Name column in the table storage row. The development storage has certain restrictions with respect to the table name; follow the instruction in the Windows Azure documentation.
    (4) to make sure everything is in a initial state you can reset all services in development storage using the UI
    (5) In rare cases you might have to clean up some port reservations by running: netsh http delete urlacl url=https://+:10002/

(c) Checking issue (a2) requires you to look at the configuration files. There are two kinds of configuration files: The csdef/cscfg files for your service and the application configuration files (app.config, Web.config).

When you use StorageClient, the StorageAccountInfo class will look into all of these files. In most cases you want to use the standard configuration strings (which make is easier to access the configurations from StorageClient). The standard configuration strings are as follows:

DefaultQueueStorageEndpointConfigurationString = "QueueStorageEndpoint"; 
DefaultBlobStorageEndpointConfigurationString = "BlobStorageEndpoint"; 
DefaultTableStorageEndpointConfigurationString = "TableStorageEndpoint"; 
DefaultAccountNameConfigurationString = "AccountName"; 
DefaultAccountSharedKeyConfigurationString = "AccountSharedKey";

Be aware that when you configure endpoints with StorageClient in your configuration file, the account name is not part of the endpoint, but is specified separately!

Here are two samples of a configuration in a cscfg file:

<ConfigurationSettings>

<Setting name="TableStorageEndpoint" value="https://127.0.0.1:10002/"/>  

<Setting name="BlobStorageEndpoint" value="https://127.0.0.1:10000/"/>  

<Setting name="AccountSharedKey" value="FjUfNl1…HHOlA=="/>  

<Setting name="AccountName" value="devstoreaccount1"/>  

</ConfigurationSettings>

and

<ConfigurationSettings>

<Setting name="TableStorageEndpoint" value="https://table.core.windows.net/"/>  

<Setting name="BlobStorageEndpoint" value="https://blob.core.windows.net/"/>  

<Setting name="AccountSharedKey" value="FjUfNl1KiJ…OHHOlA=="/>  

<Setting name="AccountName" value="myaccountname"/>  

</ConfigurationSettings>

Again: note that the account name is not specified in the endpoints.

(d) Dealing with issue (a3) requires you to look at your code. In StorageClient, the class to use to read in configuration settings for accessing storage services is the StorageAccountInfo class. It has static methods that access the standard configuration strings (see above; this is used most often) or other configuration strings that you can specify explicitly.

Be aware that the class looks up configuration settings in app.config/Web.config and in the settings that you provide for your service in the .csdef/.cscfg files. If the same configuration string is present in multiple files, the specifications in the .csdef/.cscfg files are always the ones that are considered most relevant.

Comments

• Anonymous
  November 01, 2008
  Jim posted some helpful information that Frank Siegemund wrote to respond to an issue someone was having

• Anonymous
  December 17, 2008
  Wanna learn about the future of software + services well wait no longer Windows Azure is here and below