This blog post is about Team Foundation Server (TFS) and is about the situation where you need remember to update your TFS Agent settings.

I will assume that you already have TFS setup and are just using HTTP and want to make things a bit more secure with HTTPS. I am also assuming that you will be using port 443 for HTTPS traffic.

To update TFS to use HTTPS you need to do a couple of things:

1. Have a legitimate certificate installed on the server that you can bind to
2. Have an IP address on the server and have firewall access setup to that IP address on port 443

So in IIS we will add our new binding to our Team Foundation Server website:

We will now go into TFS Administration Console to change our public URL. The added HTTPS binding will have flowed through from IIS and you should now see it in the bindings.

 

 

So now we have HTTPS working for our TFS instance. Users can connect to the new URL and we can utilise URL rewriting to direct anyone who forgets and uses HTTP.

Except our first nightly builds failed…

Looking at the diagnostic logs on the agent we can see the following (note the time is UTC time):

[2017-12-07 13:30:05Z ERR Program] System.Net.Http.HttpRequestException: An error occurred while sending the request. —> System.Net.Http.WinHttpException: A security error occurred at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Net.Http.WinHttpHandler.<StartRequest>d__101.MoveNext()
— End of inner exception stack trace —
at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.<SendAsync>d__3.MoveNext()
— End of stack trace from previous location where exception was thrown —

The logs also showed that the agent was trying to go to the old address. So it was a simple change to the agent settings to point to HTTPS address.

Browsing to where the agent is installed we can now edit the .Agents file:

Within the .agent file we will change the following setting:

serverUrl: https://YourURL/tfs/

Kick off a queued build and it works as intended.

Yip.

 

This blog post is around the situation where you have SSRS setup to use HTTPS and thus using a certificate and the certificate expires (or just needs replacing). We had caught the initial error via our Continuous Monitoring of the SSRS site — basically when the certificate expired we got an exception and alerted on it.

The client installed a new certificate but the issue arose where in Reporting Service Configuration Manager we went to use the new certificate but when we chose it we got this error:

“We are unable to create the certificate binding”

And Reporting Service Configuration Manager removes the HTTPS binding.

We checked and the certificate is installed correctly.

So we looked in SSRS logs:

C:\Program Files\Microsoft SQL Server\MSRS11.<instance>\Reporting Services\LogFiles

It is amazing for a reporting system how badly errors are reported in the log files. Basically there was nothing in there at all:

rshost!rshost!964!12/11/2017-08:13:47:: e ERROR: WriteCallback(): failed to write in write callback.
rshost!rshost!2aa4!12/11/2017-08:13:47:: e ERROR: Failed with win32 error 0x03E3, pipeline=0x00000002780A7D80.
httpruntime!ReportServer_0-33!2aa4!12/11/2017-08:13:47:: e ERROR: Failed in BaseWorkerRequest::SendHttpResponse(bool), exception=System.Runtime.InteropServices.COMException (0x800703E3): The I/O operation has been aborted because of either a thread exit or an application request. (Exception from HRESULT: 0x800703E3)
 at Microsoft.ReportingServices.HostingInterfaces.IRsHttpPipeline.SendResponse(Void* response, Boolean finalWrite, Boolean closeConn)
 at ReportingServicesHttpRuntime.BaseWorkerRequest.SendHttpResponse(Boolean finalFlush)
library!ReportServer_0-33!2aa4!12/11/2017-08:13:47:: e 

--- End of inner exception stack trace ---;

We knew that HTTP was working all good so SSRS itself was “ok”. So on a hunch we decided to see if the old certificate was still lying around bound to something and so using netsh:

So we then removed the binding — which was safe enough as only SSRS was serving web requests on this server — IIS was not being used at all.:

netsh http delete sslcert ipport=[::]:443

We could then bind the new certificate in Reporting Service Configuration Manager:

 

So hopefully if you get this type of error you too can solve it nice and quickly and have your web service URL and Report Manager URL nice and secure again…

Yip.