Azure SDK 1.4 and IIS Logging

I was excited about the release of Azure SDK 1.4. With 1.3, I had to put in a workaround to ensure that the IIS logs were transferred to blob storage correctly (as they were in version 1.2). In the release notes for Azure SDK 1.4, this is included in the list of changes:

Resolved an IIS log file permission Issue which caused diagnostics to be unable to transfer IIS logs to Windows Azure storage.

If true, this means I can take out the startup task I put in (explained in this article)  to work around the problem.

Having learned never to assume, I decided to check out the new version and test two of my Azure instances – one that hosts a WCF service and one that hosts a web application.

I installed SDK 1.4, published the two cloud projects, and opened the URLs in the web browser. After navigating around a bit to create IIS logging, I put in some invalid links to generate Failed Request Logging. Then I used the  Cerebrata Azure Diagnostics Manager to check it out.

The good news is that the IIS logging has been fixed. It transfers to blob storage as it did in Tools/SDK 1.2.

The bad news is that the IIS Failed Request logs have NOT been fixed. I RDP’d into the instance, and had to change the ownership on the directory for the failed request logs to see if it was even writing them, and it was not. So there’s no change from SDK 1.3.

If you want to use SDK 1.4 and have IIS Failed Request logs created and transferred to blob storage correctly, you can follow the instructions from this article on setting up a startup task and remove the code from the PowerShell script that applies to the IIS logs, leaving behind just the code for the IIS Failed Request logs. It will look like this:

echo "Output from Powershell script to set permissions for IIS logging."

Add-PSSnapin Microsoft.WindowsAzure.ServiceRuntime

# wait until the azure assembly is available
while (!$?)
{
    echo "Failed, retrying after five seconds..."
    sleep 5

    Add-PSSnapin Microsoft.WindowsAzure.ServiceRuntime
}

echo "Added WA snapin."

# get the DiagnosticStore folder and the root path for it 
$localresource = Get-LocalResource "DiagnosticStore"
$folder = $localresource.RootPath

echo "DiagnosticStore path"
$folder

# set the acl's on the FailedReqLogFiles folder to allow full access by anybody.
# can do a little trial & error to change this if you want to.

$acl = Get-Acl $folder

$rule1 = New-Object System.Security.AccessControl.FileSystemAccessRule(
  "Administrators", "FullControl", "ContainerInherit, ObjectInherit",   "None", "Allow")
$rule2 = New-Object System.Security.AccessControl.FileSystemAccessRule(
  "Everyone", "FullControl", "ContainerInherit, ObjectInherit",   "None", "Allow")

$acl.AddAccessRule($rule1)
$acl.AddAccessRule($rule2)

Set-Acl $folder $acl

# You need to create a directory name "Web" under FailedReqLogFiles folder 
#   and immediately put a dummy file in there.
# Otherwise, MonAgentHost.exe will delete the empty Web folder that was created during app startup 
# or later when IIS tries to write the failed request log, it gives an error on directory not found.
# Same applies for the regular IIS log files.

mkdir $folder\FailedReqLogFiles\Web
"placeholder" >$folder\FailedReqLogFiles\Web\placeholder.txt

echo "Done changing ACLs." 

This will work just fine until they fix the problem with the IIS Failed Request logs, hopefully in some future release.