This is an example of microsoft not being very careful when releasing software. Key features get broken and priority is not given to fixing them.

In this case there is a mismatch between the recommended logging approach (log everything to the local event log and use DiagnosticMonitor to send to table storage) and the latest storage account bits. This shows a serious lack of attention to detail.
Azure is meant to be the bread and butter of microsoft. It should be a wonderful platform. However there has been too little attention given to things like documentation and sample code.

Update: They have now fixed this with SDK v2.0, looks like someone had jumped the gun with releasing new bits.

http://msdn.microsoft.com/en-us/library/windowsazure/gg433135

http://blog.syntaxc4.net/post/2012/02/01/windows-azure-storage-emulator-account-name-and-key.aspx

AccountName

devstoreaccount1

AccountKey

Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==

Here is a link to an article on efficiently querying azure diagnostics table.

The key piece of information is that the partitionkey is “0” + log capture time in ticks.

git clone https://github.com/WindowsAzure/azure-sdk-tools.git

Note that you need to use the command line git since tortoise git does not do https.

Here is a great article on querying the WadLogsTable

Here is the port conflict article that will prevent the compute emulator from starting.

This is however an old sdk and does not explain how to detect which ports are in use.

This is how to do it:

netstat -ano | find /i “listening”

The emulator uses the following ports:

15095, 15096, 15097, 15098, 15099, or 15100

As of the October 2012 SDK the emulator runs from the following location:

C:Program FilesMicrosoft SDKsWindows AzureEmulatordevfabric

Here is the given advice to correct this (not yet tested):

1. In the DevFc.exe.config file, locate the add port entry that contains the conflicting port value and modify the value to use a non-conflicting port. The DevFc.exe.config file entries that can be affected are:
   • <add key=”ManagementServicePort” value=”15095″ />
   • <add key=”RepositoryServicePort” value=”15096″ />
   • <add key=”AgentCallbackPort” value=”15097″ />
   • <add key=”AgentPort” value=”15098″ />
   • <add key=”PxeResponderPort” value=”15100″ />
2. In the DfService.exe.config file, locate the dfservice element and modify the ManagementServicePort or RepositoryServicePort attribute to use a non-conflicting port.
   • <dfservice ManagementServicePort=”15095″ RepositoryServicePort=”15096″ />
3. Press F5 to restart the application or run the CSRun Command-Line Tool.

However a restart of my machine cured this issue.

I suspect that it was caused by using on of the powershell scripts to start the emulator.

This is an article on logging and tracing in windows azure.

The author followed it up here.

Note that this was a 2010 article and Azure has moved on quickly so things could have changed.

The supplied Powershell scripts no longer exist.

The first gotcha that I have found is that the default connection string has moved so  the logging setup is:

public override bool OnStart()
{
// Set the maximum number of concurrent connections
ServicePointManager.DefaultConnectionLimit = 12;

TimeSpan tsOneMinute = TimeSpan.FromMinutes(1);
DiagnosticMonitorConfiguration dmc = DiagnosticMonitor.GetDefaultInitialConfiguration();
dmc.Logs.ScheduledTransferPeriod = tsOneMinute;

dmc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
DiagnosticMonitor.Start(“Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString”, dmc);

// For information on handling configuration changes
// see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

return base.OnStart();
}

Note with the recent update in Azure SDK 2.0 you will need to set the diagnostics level on the service configuration page.