Running a Bamboo CI Server Remote Agent on a Windows Server (Cloud)

This post is dedicated to all the lost souls out there of people who try to get a Bamboo Remote Agent Windows server to work.

We scratched our heads for about a week trying to figure out why things didn’t work for us. Atlassian’s documentation and knowledge base were not helpful and we were basically on our own.

Our overall feeling was that Windows is not a first-class citizen of Bamboo. Bamboo Agent was designed for *nix and as a matter of fact, the very same agent runs on Windows – with the help of Cygwin. If you browse the agent’s code (C:\opt\bamboo-elastic-agent in the agent’s Windows host) you’ll see .sh scripts and more *nix stuff. Oh, and take NUnit as another example: Bamboo’s documentation clearly addresses it, but there’s one problem: NUnit is not installed on the default Bamboo Agent Windows AMI.

Also, Atlassian could have done much better in being responsive to their user base. Take this documentation page for instance – One question asked in 2012, one in 2013 and one in 2014. In 2015 someone wrote “3 questions here and not a single response from Atlassian.”.

Luckily for you, we have managed to solve two hard issues we have had and I hope that this post will come up in your Google search and it will save you that precious time that we have spent.

First off: How should I setup my Windows Bamboo agent?

Atlassian offers two methods – one using its own Windows stock image (ami-dbe295e1), and another one which is to manually install the agent and all prerequisites yourself.

The first method is the one I would highly recommend you to go by, as the second one requires lots of careful steps to do and much more error-prone.

You’d only want to use the second method if you already have a working server for your build tasks that has lots of custom software & setup.

So, we start by using Bamboo’s Windows Stock Image. We launch an instance via the Bamboo administration interface and happily get Remote Desktop access to it (the IP and the Administrator password are given in the Instance Details screen in the Bamboo administration interface).

Shortly after Windows loads, the Bamboo Agent program is supposed to kick off; Bamboo’s cloud service will interact with it and is supposed to show you that the agent is Idle on the Bamboo administration interface.

First problem: The agent is never “Idle”. It shows “Pending” forever.

The agent gets running using Windows Task Scheduler – there’s a task called “Start Bamboo Agent” that is triggered by the Microsoft-Windows-NetworkProfile/Operational Windows event – it should basically start when Windows starts.

The problem is that it fails to start. The reason is that (looks trivial but oh boy, how long it was to figure it out) when the Atlassian guys created this AMI, they setup a Windows user named Bamboo which is the user that runs the agent, but that user’s password was set to expire after some time, despite no UI to show it. So when Task Manager attempted to start the Bamboo agent on behalf of the Bamboo user, it failed because that user could not do stuff before they have changed their password.

Solution: Go to Computer Management -> Local Users and Groups -> Users -> Bamboo, go to Properties, untick “User must change password on next logon” and tick “Password never expires”. Then quickly confirm that it’s working by going to the relevant task in Task Manager and manually running it.

Save the result as a new AMI, and configure Bamboo to use your new AMI rather than their Windows stock image.

Second problem: MSBuild fails

Well, this can happen from a whole lot of legitimate reasons like dependencies missing etc. but there might be a wall you’d hit and by the time of this writing there’s no resource on the Internet to point to the right solution:

On a very high level, we had one job that pulls the most recent files from our remote GIT repository and another one that runs MSBuild on a .NET solution file.

In one of the build steps we’ve got this error:

SGEN : error : Could not load file or assembly ‘…….’ or one of its dependencies. Access is denied.

Turns out that Bamboo set some bizarre restrictive permissions on the folder they’re working on (C:\build\_plan_name_1) and somehow their own permissions were not sufficient.

Solution: We had to change both the directory’s owner and some of the permissions of the Bamboo user on that directory. This can be done by applying these two commands, ideally as a job on its own – after pulling recent changes from the remote repository, and before running MSBuild:

takeown /r /d y /f .
icacls . /t /grant Bamboo:F

Note: instead of . (current directory) you can put a more specific one, to narrow permission and ownership changes to minimum.

Conclusion

Hopefully these two solutions will help some poor guys out there and save them some precious time and frustration.

I hope that Atlassian will take Windows more seriously with Bamboo. Otherwise it doesn’t seem like really is the perfect tool for building Windows / .NET based stuff.

If you’ve made a good use of this post please comment 🙂