This is an error message that sometimes you might see when you published your site with WebDeploy. Yeah, we know WebDeploy sometimes is hard and not so easy as you think, but if you have problem with your current provider, you can consider our hosting plan. We support WebDeploy and we are Microsoft certified partner. Ok, let’s go to the problem:

“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. So, you need to create ticket to us and then we will set a username and password for your both your web deploy and remote IIS user.

Maybe you find another problem like this:

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:

1. <IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>

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.

Hope this article will help you if you find problem like above.