Deploy to Virtual Directory of Default Web Site

I’m trying to deploy using the “IIS Home Directory” feature, and I am specifying the home directory like this:

Default Web Site/NuGetServer

I get the following error:

start-webitem : Cannot create a file when that file already exists. (Exception from HRESULT: 0x800700B7)
At C:\Program Files (x86)\Octopus Tentacle 2.0\Agent\Scripts\Octopus.Features.IISWebSite_BeforePostDeploy.ps1:138 char:5

  • Start-Website $WebSiteName
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : InvalidOperation: (:slight_smile: [Start-WebItem], COMException
    • FullyQualifiedErrorId : InvalidOperation,Microsoft.IIs.PowerShell.Provider.StartItemCommand
      Script ‘C:\Program Files (x86)\Octopus Tentacle 2.0\Agent\Scripts\Octopus.Features.IISWebSite_BeforePostDeploy.ps1’ returned non-zero exit code: 1. Deployment terminated.

It appears that no matter how I set the feature settings, Octopus Tentacle is trying to create a new Web Site, rather than adding files to an existing site.

In this case, it tries to create a new web site called “NuGet”, which is odd, because the only place that “NuGet” is used (not “NuGetServer”), is in the project settings: the project is named “NuGet Server”.

Hi - according to this SO post, the error you mention sometimes indicates a port/binding conflict:

(Might be a long shot.) If that doesn’t immediately ring any bells, could you please:

  • Set OctopusPrintVariables and OctopusPrintEvaluatedVariables to True in the project’s variables
  • Create and attempt to deploy a new release
  • Collect the ‘Raw’ log output from the Deployment task page (link upper right)

Also knowing the Windows and IIS versions you’re using would be handy.

Just to help me get on the same page, where did you determine that the attempted website name is ‘NuGet’?

Thanks in advance!

I’ve attached the log file.
Windows 2012, IIS 8.0

I know that its trying to create a web site named “NuGet” because it actually does create a website name “NuGet” on the server (which I didn’t ask for). It also tries to bind it to port 80, and fails (because the Default Web Site is already bound to that port).

ServerTasks-672.log.txt (10 KB)

Thanks for the extra info. The problem seems to be that both IIS Web Site and IIS Home features are enabled; these are actually supposed to be mutually exclusive - you can simply disable the IIS Web Site feature and your deployment should work.

We have a ticket down to clarify the naming of these - essentially “Home” is for IIS 6 and where VDIRS are being used. IIS Web Site supports IIS7+, but doesn’t yet handle VDIRS.

Sorry about the confusion, please let me know if this doesn’t get the ball rolling.


Well, the IIS Web Feature was disabled. I even re-enabled it, unchecked the box, and then disabled it again, and I am still getting the same result.

From the ticket, it appears that you are saying that for IIS 8, I cannot create a virtual directory, or a web application under an existing site?

Yikes! :slight_smile:

Have you created a new release each time after changing the deployment process or variables? If not, we’ll keep using a snapshot of the process/variables taken when the release was created, which might explain this behaviour.

The task log you sent doesn’t include the output that should appear with OctopusPrintVariables and OctopusPrintEvaluatedVariables enabled - is it possible to create a fresh release and deploy it so we can capture this?

The IIS Home feature is compatible with IIS6+, so both of those things can be achieved with IIS8, sorry again for the lack of clarity.

To save on the typing :slight_smile: my Skype username is the same as my email username, feel free to add me as a contact if you’d like to screen share or chat through this.


OK, deleted the release, and created a new 1.0. This seems better, now the error is:

Failed: IIS site Default Web Site/NuGetServer
Updating IIS website named 'Default Web Site/NuGetServer’
Could not find an IIS website or virtual directory named ‘Default Web Site/NuGetServer’ on the local machine. You need to create the site and/or virtual directory manually. To turn off this feature, use the ‘Configure features’ link in the deployment step configuration to disable IIS updates.

This seems to be telling me that the deployment will not create a Virtual Directory or Web App, it will only update it if I’ve created it manually. If this is the case, you may want to document this better, as well as the “snapshot” functionality when changing a deployment step.

At any rate, when I create the Virtual Directory in IIS, and then do a deployment, the deployment succeeds.

I want to point out that if I do have to create my own Virtual Directory before deploying, IIS requires me to specify a dummy physical directory to point to, which gets changed immediately after the deployment succeeds.

Excellent! Glad to hear we cracked it.

The snapshot warning appears on the bottom of the “Deploy release” page right next to the “Create deployment” button, but it is easy to overlook, especially if you’re pushing deployments from Team City or another CI solution. I’ll have a think about what we might do here.

Regarding manual site creation/dummy directory, this is one of the things we’d like to improve by expanding the newer IIS Web Site feature to cover VDIRs; ideally these two features will eventually merge and cut out any ambiguity here.

Have a good day!