TFS 2015 to Azure DevOps 2019 In House

We decided to do this upgrade. There is considerable support for the "dry-run" option, with actual choices around dry-run built into the installer. Nonetheless we are going to a new machine, so essentially we are doing a dry run anyway. If something blows up we can turn on the old server and it's like it never happened. Right?

Not sure actually. There was little documentation on this exact scenario, but we copied the databases across, turned OFF the trusty TFS 2015 machine, and proceeded optimistically. We restored the databases into a new SQL instance and then ran the mu_azure_devops_server_2019_update_1_x64_web_installer against them. Side note: we had Reporting Services and Analytics Services running in TFS 2015, but seldom used that functionality. So following the tried and true KISS principle, we wanted to not load those up this time. How would the installer react to an instance that had those services, and a new environment that did not? Quite well, in fact. We left this box unchecked:

The installer chugged away and eventually got across the line. And now the fun begins. Even though we knew that any XAML builds had reached end-of-life, and we had been switching them over solution by solution - even the new style (what was once referred to as vNext) would not/could not run on the older build agents, and the seductive Update All Agents button in the DevOps interface would not work.

Yeah, this one here. Not.

So, we would need to set up a new build agent and environment fresh, and this turned out to be the most niggly part of the entire process. Perhaps these notes will save you from the sharp end!

You download the agent - essentially a zip file - in a well documented process.

see: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops

1. Authenticate with a personal access token (PAT)

The Personal access token (PAT) authentication piece of the agent install - well, Microsoft wants you to host all this in the cloud, and the documentation reflects it. So the page we were following portrays this PAT step as logging into https://dev.azure.com/{your_organization}

NO, in your case, if you are using an on-prem server, this will be generated at the local Azure DevOps portal. The word Azure is a misnomer really, as none of the infrastructure is actually running in Azure.

2. The config.cmd step of installing the agent - Server URL

This is a pretty good walkthrough of the process https://www.clouddev.engineering/azure-devops-microsoft-hosted-and-self-hosted-build-agents/ and they explicitly say they are using a Windows 10 workstation, but alas the PAT generation still assumes you going to the Azure DevOps portal, instead of your local portal. AND when you get to the step to run .\config.cmd the steps required are glossed over.

You will be asked for the URL for your DevOps services. This CANNOT be http as that will be rejected as insecure. Enter Server URL > if you put http://XXX here, you will still be prompted to Enter Authentication Type > PAT, enter the PAT and then you will get the response

____

Basic authentication requires a secure connection to the server.
Failed to connect. Try again or ctrl-c to quit

____

So the next thing you might try is https://your_local_devops_url  or maybe you will try to do 

https://your_local_devops_url/tfs/your_collection 

GOTCHA - An error occurred while sending the request. Failed to connect.

OOTB there is no https binding on the on-prem DevOps install! 

The above screenshot shows failed connection from Agent to DevOps. This is running in Powershell and gives minimal error guidance, so you can be excused for thinking your problem is the PAT whereas you need to go to IIS and add an HTTPS binding.

3. config.cmd - Server URL gotcha #2, using an IP address

So you install a certificate:

If, like us, you next tried to connect using an IP address, you will get a further error. Because the IP address does not match the name on the certificate, you are getting the standard warning that would be visible in a browser NET::ERR_CERT_COMMON_NAME_INVALID

Only you can't see this, as you are in powershell.

If you are seeing this error:

__

An error occurred while sending the request.
Failed to connect. Try again or ctrl-c to quit

__

Make sure you configure a binding that matches your certificate, add the URL in your internal DNS, and use this custom URL when setting up the build agent.

Only then will the config.cmd step complete. When you get over these hurdles, the new agent will complete and appear in your DevOps agent pool, which leads us to

4. A Bonus tip

If you have an existing agent pool, which you do if you are upgrading from TFS 2015, put this new agent in the same pool. you can then delete the old agent and all your pipelines will revert to the new one. If you put the 2019 agent in a new pool, thinking that might be cleaner, you will need to reconfigure the Pipelines and/or individual builds in order to switch them over. Depending how many you have, this could be not fun.

You may need to tweak some of the steps in your builds anyway, because the new agent directory structure uses directories named \a and \s so if you have mentioned the likes of \staging those paths will need to be edited. 

Hope this helps.