Azure Deployment Errror with IISConfigurator.exe 2.5

Question

Hi:
I recently upgraded from Azure SDK 2.2 to 2.5.  I have everything running OK locally in the compute and storage emulators.  However, when I create a package and attempt to deploy to Azure, I get the following error:
The file provided is not a valid service package. Detailed error code: WTAB-Manager.Web Invalid application runtime
- a runtime component is missing:/base/x64/IISConfigurator.exe,WTAB_Service_Role Invalid application runtime
- a runtime component is missing:/base/x64/IISConfigurator.exe,WTAB_Worker_Role Invalid application runtime
- a runtime component is missing:/base/x64/IISConfigurator.exe.
The long running operation tracking ID was: b3d96f5d5c58858ea7485215887d4513.
The IISConfigurator.exe's are in the directories where they have always been (see screen shot).  They are now version 2.5 and there are different files for the x86 and x64 directories.
Can anyone help me solve this problem?
Thanks!
TerryL

Answer 1

Hi Terry,
Thanks for posting here.
To work around this issue you have to restart the WAD diagnostics agent after IISConfigurator has setup IIS.  When the WAD diagnostics agent starts up again it will query the IIS Management Service for the IIS log file location and will get the correct
C:\Resources\directory\{deploymentid.rolename}.DiagnosticStore\LogFiles\Web location.
The two ways to restart the diagnostics agent are:
1.Reboot the VM.  This can be done from the portal or from an RDP session with the VM.
2.Update the WAD configuration, which will cause the diagnostics agent to refresh it’s configuration.  This can be done from Visual Studio (Server Explorer –> Cloud Services –> Right-click a role –> Update Diagnostics –> Make any change and
update) or from Powershell (see this post).
One problem with these two options is that you have to manually do this for each role/VM in your service after deploying.  The bigger problem is that any operation which recreates the Windows (D: drive) partition will also reset the IIS log file location
to the default %SystemDrive% location which will cause the diagnostics agent to again get the wrong location.  This will happen to all instances roughly once per month for Guest OS updates, or randomly to single instances due to service healing (see this
and this for more info).
I suggest you to check this troubleshooting for Azure SDK 2.5 with IIS configurator.
http://blogs.msdn.com/b/kwill/rss.aspx
Hope this helps you in fixing the issue.
Girish Prajwal