screenshot1.pngscreenshot2.pngI upgraded TFS 2015.3 to 2017 with bindings on both HTTP (port 8080, default settings) and HTTPS. Now I removed HTTP binding form the IIS and reapplied the Public URL (via Administration Console -> Change Public URL).
When I remove HTTP binding on TFS 2017 Application Tier and leave only HTTPS binding some of the content still wants to be accessed via HTTP. Most of the TFS application tier works normally (as it uses relative addressing). However, build-related stuff and build extensions somehow want to get their icons from HTTP (port 8080). I checked the HTML/JS source and I found that _vssPageContext variable still holds configuration where URLs are pointing to old (HTTP) configuration.
Later I re-enabled the HTTP bindings in IIS just to make the TFS work and I noticed a lot of warnings and errors due to HTTP / HTTPS mixup (I access TFS via HTTPS, however some content is still accessed via HTTP):
Mixed Content: The page at 'https://xxxx.xxxxx.xxxx/tfs/TFSDefault/Project/_build/definitionEditor?definitionId=113&_a=simple-process' was loaded over HTTPS, but requested an insecure image 'http://xxxx.xxxxx.xxxx:8080/tfs/TFSDefault/_apis/distributedtask/tasks/9fcb05af-0ffe-4687-99f2-99821aad927e/0.1.1305/icon'. This content should also be served over HTTPS.
WebSocket connection to 'ws://xxxx.xxxxx.xxxx:8080/tfs/signalr/connect?transport=webSockets&clientProtocol=1.5&contextToken=412c3608-de3b-4dab-a00d-bf5c13728d97&connectionToken=OoSymcl1qzWg%2BrHB9pzSBpb%2BdHVywo7NNUWN5xMx3Z51p9ZdZQ14wvoQKXqxB%2Bvo66eTap4iUdlqzHR1hJNUf%2By8oFUaudlkCbQIZjHQhLBHsEWtcLdfLlL7MAevl4h0My1yQA%3D%3D&connectionData=%5B%7B%22name%22%3A%22builddetailhub%22%7D%5D&tid=7' failed: HTTP Authentication failed; no valid credentials available.
I have also recycled the application pool and rebooted the server - without success.
Added a solution by Chandru Ramakrishnan · Mar 01 at 02:50 PM
I see the problem - it's the LabAccessMapping - do you need that? If not removing it will be the simplest. Run this on your configDB.
declare @t typ_StringTable
Added a solution by Zvonko Boštjančič · Mar 06 at 04:06 PM
I believe we are almost there. Using your solution helped a lot - now all URLs in HTML and JS code are HTTPS URLs. Why did the "LabAccessMapping" messed up the URLs?
There is still one issue: Authentication of web sockets connection fails. See the attached screenshot.
The protocol used for web sockets connection is WSS and the connection is now properly established via secure protocol. I do not understand why the authentication failed.
Added a solution by Russell Tolley · Feb 28 at 11:45 PM
We were only able to reproduce this issue internally when the Public URL is configured with 'http' (and port 8080) instead of 'https' (and port 443). In that case the fully-qualified URLs were "downgraded" to HTTP because the incoming HOST header is used to select the Access Mapping and the Access Mapping specifies 'HTTP'. As you said, this only affects a few things (since most web links are relative).
You mentioned having reapplied the public URL from the Admin Console (and restarting the application pool). Can you double check the Admin Console to see if it accepted the HTTPS change to the Public URL setting? I am wondering if it might still have HTTP.
Added a solution by Zvonko Boštjančič · Mar 01 at 07:06 AM
As far as I can see in Admin Console, HTTPS change has been accepted to the Public URL setting.
The screenshot of current application tier settings is attached. Please note that HTTP binding is enabled for TFS to work normally.
Icons not visible on TFS2017.1/RC2
TFS 2017.1 notification management ERROR
Cannot add TFS server group to Access Level
Licence Using at TFS 2017 Report