Setting up TeamCity 8 on an Azure Virtual Machine

Create a VM in Azure

The first thing we will do is to create a VM in Azure. I recommend to follow the Microsoft tutorial on the topic. The important steps are:

  1. How to create the virtual machine. (I chose “Windows Server 2012 R2 Datacenter” from the gallery.)
  2. How to log on to the virtual machine after you create it.
  3. How to attach a data disk to the new virtual machine. (We should add the extra storage right away, because then we can put Teamcitys builds and artifacts on that disc.)

Did the 3 previous steps from Microsofts tutorial go smooth? Great! Let’s get started with the TeamCity-stuff. We are going to some downloading, so you could look at how to disable Internet Explorer Enhanced Security Configuration (IE ESC) in Windows Server 2012 to make it a bit easier to do the downloads.

Install TeamCity

First item to download is the newest version of TeamCity (8.0.5 as of writing).

TeamCity 8

Start the installer and we are of to a classic next-agree-next-next-finish installation. After you agree to the “License Agreement” lets change the destination folder to the drive we attached. In my case the destination folder ended up being F:\TeamCity. Install the default selected components, and on the next step I chose to install the ProgramData on the F-drive as well, like this F:\ProgramData\JetBrains\TeamCity. Next the installer starts.

Configure

After the installer is finished you can choose the server port, I stayed with the standard port 80. In the “Configure Build Agent Properties” window I took the easy way out, save and close. Then on “Select Service Account for Server”, change it to run under the SYSTEM account. If you use the same user as you logged on to the remote desktop with, you will get an error with insufficient rights to run a service. Please read this post/answer on Stack for an explanation on the difference between running under system account and user account. On the next window you choose what user account the BuildAgent runs under. Use the SYSTEM account here as well. Start Build Agent service and Start TeamCity Server service? Sounds good! And lets agree to open TeamCity Web UI after setup is completed.

Let’s just proceed with a fresh installation. Read and agree to the license, and create your TeamCity administrator account. This is the administrator account, so you should consider to create another account for yourself later, and not use the admin account as the default one.

Access TeamCity from the web

Now let’s check if we reach the TeamCity Web UI from outside Remote Desktop. Minimize the Remote Desktop and fire up your browser of choice. Remember the name you gave your VM in Azure? My VMs name was danmuskbuildserver. So I try to hit the adress http://danmuskbuildserver.cloudapp.net Hmm… No luck right?

Server firewall

Let’s head back into the Remote Desktop and open up the firewall settings (Server Manager -> Tools -> Windows Firewall with Advanced Security). Click on “Inbound Rules” as we want to add one. Click “New Rule…”, select “Port”, next, select “TCP” and in “Specific local ports” enter the same port number we chose back in the installation of TeamCity. I stayed with port 80. Click next, and select “Allow the connection”, and apply this rule to all. Name it for example “TeamCity Web UI”. Now try access your cloudapp.net url again. Still no luck?

Azure endpoints

Add endpoint

Add endpoint

Log back into the Azure portal, and click on your VM instance, and on the top line click on “Endpoints“. What port was it again? As for the firewall rule, I stayed with port 80. Let’s add that as one of our endpoints. In the “Add Endpoint” modal “Add a stand-alone endpoint”, click next, and in the next step choose “HTTP” from the Name-dropdown. The adding of the endpoint can take some time, so lets wait a little bit before retrying to access our cloudapp.net url.

Login

Success! We are now prompted with the loginpage to our TeamCity server. We are now able to access our TeamCity server from the wide wide world of web.

Before you start using TeamCity, you should consider setting up a external database. As it says on the Global Settings page:

For production purposes it is recommended to use a standalone database which provides better stability

So there it is. My first blog post… Jazz hands!

Cut to... Jazz hands

Cut to… Jazz hands

You may also like...

  • torque

    This looks really cool, I’m thinking about doing this. Where do you put your build server? Do I need to install VS onto the VM?

    • danmusk

      Hi torque,

      We have a buildserver running on an Azure VM.

      I try to avoid installing VS on the VM where TeamCity runs. I like to keep a clean environment as possible. Check out my post on “How to build ASP.NET applications in TeamCity with MSBuild Tools 2013 and .NET Framework 4.5 SDK”. In that setup I use the MSBuild Tools 2013 instead of installing a full version of Visual Studio.

      Regarding creating an extra disk on the VM. In the article I linked to, it shows how to create a 5 gb disk. I would create it a bit bigger, but it depends on how many builds and artifacts you are planning on having. If this step is at all necessary, it depends. I like to have my data stored on another disk than the OS, but that’s just me. You could absolutely skip this step and be happy with the 127 GB OS disk.

      Cheers for the feedback

  • torque

    I don’t see why you need to create a separate data disk. Seems like the default OS disk is plenty large at 127 GB. Why add the 5 GB extra disk for the TC builds and artifacts?

  • Karl Gjertsen

    Great article and helped me to set up TeamCity 9 on an Azure VM. Thanks.

    • danmusk

      Thank you for your comment, glad I could help. Was there any differences worth noting in the guide re TC9 instead of 8?

      • Karl Gjertsen

        The main difference is the change in the UI of the Azure portal!
        TeamCity is up and running, Octopus Deploy was a littl eharder, but I am almost there now.

  • Vladislav Kurkotov

    Hi there. Thank you for the post. I didn’t now about endpoints. And by the way, I think it is better to use WS 2008 R2 because it eats less memory.