Chef WebPI cookbook fails install in Azure

I setup a new Win2012 VM in Azure with the Chef plugin and have it connected to manage.chef.io. Added a cookbook which uses the WebPi cookbook to install ServiceBus and its dependencies. The install fails with the following error:

“Error opening installation log file. Verify that the specified log file location exists and is writable.”

After some searching it looks like this is not new in Azure based on this 2013 blog post - https://nemetht.wordpress.com/2013/02/27/web-platform-installer-in-windows-azure-startup-tasks/

It offers a hack to disabled security on the folder temporarily but I'm looking for a better solution.

Any ideas?

More of the log output -

Started installing: 'Microsoft Windows Fabric V1 RTM'

 .  

Install completed (Failure): 'Microsoft Windows Fabric V1 RTM'

 .  

WindowsFabric_1_0_960_0 : Failed.
Error opening installation log file. Verify that the specified log file location exists and is writable.


DependencyFailed: Microsoft Windows Fabric V1 CU1


DependencyFailed: Windows Azure Pack: Service Bus 1.1

 .  
 .. 




Verifying successful installation...


Microsoft Visual C++ 2012 SP1 Redistributable Package (x64) True


Microsoft Windows Fabric V1 RTM                    False


    Log Location: C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Web Platform Installer\logs\install\2015-05-11T14.15.51\WindowsFabric.txt


Microsoft Windows Fabric V1 CU1                    False


Windows Azure Pack: Service Bus 1.1                False


Install of Products: FAILURE
STDERR: 
---- End output of "WebpiCmd.exe" /Install /products:ServiceBus_1_1 /suppressreboot /accepteula /Log:c:/chef/cache/WebPI.log ----
Ran "WebpiCmd.exe" /Install /products:ServiceBus_1_1 /suppressreboot /accepteula /Log:c:/chef/cache/WebPI.log returned -1

Solution

A Chef contact (thanks Bryan!) helped me understand this issue better. Some WebPI packages do not respect the explicit log path provided to WebPIcmd.exe. The author should fix the package to use the provided log path when it is set. So the options became:

Have the author fix the package
Run Chef in a new scheduled task as a different user which has access to the AppData folder
Edit the cookbook to perform/unperform a registry edit to temporarily move the AppData folder to a location that the System user has access. Either in my custom cookbook or fork the WebPI cookbook.

Obviously, waiting on the author (Microsoft in this case) to fix the package would not happen quickly.

Changing how the Azure VM runs Chef doesn't make sense considering the whole idea is to provide the configuration at the time of provisioning and it just work. Plus changing the default setup may have unintended consequences and puts us in a non-standard environment.

In the short term, I decided to alter the registry in my custom cookbook.

registry_key 'HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders' do
    values [{
        :name => "Local AppData",
        :type => :expand_string,
        :data => "%~dp0appdata"
        }]
        action :create
end
webpi_product 'ServiceBus_1_1' do
    accept_eula true
    action :install
end
webpi_product 'ServiceBus_1_1_CU1' do
    accept_eula true
    action :install
end
registry_key 'HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders' do
    values [{
        :name => "Local AppData",
        :type => :expand_string,
        :data => '%%USERPROFILE%%\AppData\Local'
        }]
end

This change could also be done in the WebPI cookbook as well to fix this issue for all dependent cookbooks. I decided to not approach this until the WebPI team responds to a feature request for the framework to verify packages respect the log path instead.

http://forums.iis.net/t/1225061.aspx?WebPI+Feature+Request+Validate+product+package+log+path+usage

Please go and reply to this thread to try to get the team to help protect against this common package issue.