Web Deploy – Common Errors
Written by Ronald Craft Saturday, 9 October 2010
Due to the complicated nature and the overall lack of documentation on web deploy and some issues with it this blog post is being written to help you understand some of the common errors and what they mean.
“Error: An unsupported response was received. The response header ‘MSDeploy.Response’ was ” but ‘v1′ was expected.
Error: The remote server returned an error: (401) Unauthorized.”
This means that you do not have access. On our newer servers web deploy is enabled from the Management tab in your website. Older servers require web deploy to be enabled for each account, so please submit a support ticket if you need it enabled. In order to verify whether you have it enabled already, open your control panel and navigate to Websites > Click the name of your website (domain.com for example) > Click the Management tab (if it’s there). There you will set a username and password for your both your web deploy and remote IIS user.
Error: The remote server returned an error: (503) Server Unavailable.
Web Deploy may not be setup or running on that server. Please contact us in order to resolve the issue.
An error occurred when the request was processed on the remote computer.
The server experienced an issue processing the request. Contact the server administrator for more information.
This is the most common error we see and, unfortunately, it does not tell you much. What this means is that, usually, you have successfully connected to the server, however for some reason your deployment failed. Usually, this means that you are attempting to do something that you do not have access to do (such as deploying to the root directory – which you need full control permissions in order to do and this must be granted by us). Please check your settings and ensure that everything is correct. Also, if you do contact us, providing a screenshot of your deployment settings (Service URL, Site/Application and Username/Password) will assist us in troubleshooting your issue.
Lastly, I want to talk about the SetAcl deployment handler. Once you decide to publish to your root directory you can do some damage by removing the permissions from your files/folders if you aren’t careful. In order to fix this each file/folder must be reclaimed and the permissions reset, which is quite a bit of work and very time consuming for us.
SetAcl can be found in your WAP project file.
What is SetAcl? It’s a provider that lets you set permissions on file system objects. Typically, this involves setting permissions on a sub-folder of your application, such as App_Data.
Let’s say you run this command:
msdeploy.exe -verb:sync -source:setacl -dest:setacl="Default Web Site",setacluser=ApplicationPoolIdentity,setaclaccess=Read
This command will give the ApplicationPoolIdentity Read access to the App_Data folder. Before it does that, however, it will clear existing permissions on the folder for the identity. This makes sense, since setAcl has to set the correct permissions and the only way to do that is to clear existing permissions for the identity. For example, if the ApplicationPoolIdentity had Read,Execute permissions before, now it will just have Read permissions.
In order to disable it, you edit the .csproj file and set:
or do this from the command line:
2. msbuild.exe myproject.csproj /p:IncludeSetAclProviderOnDestination=False
Following the above instructions will allow you to safely deploy to the root directory.