Binding is configured as:
Found binding: @{protocol=http; port=80; host=alpha.somesite.com; thumbprint=; requireSni=False; enabled=True}
The website and application pool are created successfully but when it gets to the binding section it fails with the following error message:
Comparing existing IIS bindings with configured bindings…
17:44:10 Info | Found configured binding which is not assigned: http *:80:alpha.somesite.com
17:44:10 Info | Existing IIS bindings do not match configured bindings.
17:44:10 Info | Clearing IIS bindings
17:44:10 Info | Assigning binding: http *:80:alpha.somesite.com
17:44:10 Info | Attempt 1 of 5 failed: Object reference not set to an instance of an object.
We were having the same issue after upgrading from octopus 3.2.6 to octopus 3.2.8.
Retrying did not work for us so we had to dig deeper and find our problem.
Turns out in our situation that we had to manually add an http binding on port 80 for the site then retry on the octopus deploy and then it worked for us.
After some more research we found that using the step “Deploy a Nuget Package” with the feature “IIS Bindings” is the cause of this.
In that IIS Binding feature we configured the default http protocol on port 80 with host url and no ip address assigned (leaving it blank). This worked fine in Octopus 3.2.6 and before, but after upgrading to 3.2.8 it causes this error to occur.
Hope this scenario can help you guys out finding the problem.
I retried the task multiple times, but it always fails at the binding step. We haven’t done a clean install in some time so I can’t say for sure, but this seems to be a related to upgrading to 3.2.8 which we did this week. I tried both leaving the IP blank in the binding (its not required in the UI) as well as using *. Both resulted in the error above. I will try adding a binding manually so we can move forward. This should be easy for the support staff to reproduce when you have a clean install of IIS on Windows 2012 R2. Shane - I can send you the entire log privately if you think it would be helpful.
After a little more research I think there is bug in the UI around IP address. On the sites that were failing the message in the log looked like this:
Found binding: @{protocol=http; port=80; host=alpha.mysite.com; thumbprint=; requireSni=False; enabled=True}
On the sites that worked the binding looked like this:
Found binding: @{protocol=http; ipAddress=*; port=80; host=alpha.mysite.com; thumbprint=; requireSni=False; enabled=True}
or
Found binding: @{protocol=http; ipAddress=; port=80; host=alpha.mysite.com; thumbprint=; requireSni=False; enabled=True}
Notice how the ipAddress parameter is missing (null) in the first message. In the cases where that was the issue I deleted the binding in the UI and recreated it. By default it set the IP address to * where in the initial state (when you first setup a NuGet Package and say you want to include the website options) the IP address is null. This leads me to believe there is a bug in the UI where the IP address is not being set correctly and removed from the collection.
So if you have this issue to fix it - remove the binding in the UI and recreate it and then validate the log message includes the ipAddress parameter.
[New-ItemProperty], NullRefere