Since applying the latest patch I’ve tried adding in a new web portal binding simply named http://octopus, prior to this patch I just had an IIS redirect with the same binding which redirected to http://servername:89 which worked fine.
There were two problems, the first was the service kept crashing due to the fact I forgot to remove the IIS binding, so there was a host/port conflict, it would be nice if Octopus was able to catch this rather than having to check event logs. This wasn’t a big issue and easy to fix, but thought it may be worth mentioning.
The bigger issue is that authentication using http://octopus just doesn’t seem to work. If I access the site using http://octopus it presents the login screen, I then login using my AD credentials, it successfully logs in but then shows a screen where I have no permissions to anything. If I then login using the URL http://servername:89 it logs in correctly with all the right permissions.
Thanks for that, it was a little more weird than that as my account did exist twice, but both were completely identical, even down to the case. One had an ID of 1 and another of 129, so I took a stab and deleted the 129 one, unfortunately that locked me out so I’m glad you provided the script above.
Using the script above it created ID 130 with once again the exact same details so I deleted ID 1 and everything seems ok now.
Ah! Great to hear it is sorted out … I’m not sure what was going on with the duplicate - perhaps applying the index change with duplicates already in the database caused something odd. Thanks for following up!
Here is a powershell script I use to detect duplicate binding conflicts prior to deploying the package… Make sure that your getting the correct StepName for the octopus parameters.