Further Experiences with TFS 2010 Beta 2 on Amazon EC2

A few weeks ago I published a post containing my experiences trying to build a Team Foundation Server 2010 Beta 2 instance on Amazon Ec2. Since then I’ve used the instance I created a number of times, but not without struggles. Due to a number of reasons each time I wanted to use my TFS instance (to do productive work) I found that I had to fight with the configuration a fair bit in order to get all the windows services running properly.

So after battling with the TFS 2010 instance that I setup on Amazon Ec2 for about two weeks now, I’ve made some amendments to the build that seems to have stabilised the environment a little.

  • Disable the automatic generation of the computer name for new instancesWhile for a lot of EC2 usage scenarios it makes sense to create a new dynamic computer name for each instance created, for a lot of Microsoft server based products it causes a number of difficulties. Specifically, connection strings and hard coded URLs seem to be littered throughout configuration files and security settings. A colleague of mine recently hit the same problem in MS CRM, and I would expect to see similar issues in SharePoint, BizTalk Server etc.

    For Team Foundation Server 2010, the issues I hit was the database connection string for the TFS web services was set to the machine name by default – this one was easily fixed. The more significant issue I faced was that the SQL Server security settings were all based around windows users in the format {machinename}\{user}. The result was when I setup a new instance all the SQL Server security roles were based on the previous machine name and had to be reset before Team Foundation Server could connect.

    Thankfully Amazon has provided us with a relatively straight forward mechanism to force the same computer name to be maintained. There is a property in the config.xml file (C:\Program Files\Amazon\Ec2ConfigSetup) called Ec2SetComputerName. If this is set to disabled then the computer name set when the AMI is bundled will be maintained. An even easier mechanism (that I didn’t discover till much later) is the EC2 Config Service Settings (Ec2ConfigServicesettings.exe) utility in the same folder that wraps these configuration settings.

  • Turn off automatic sysprep of new instances. Even with Ec2SetComputerName disabled, if sysprep is enabled for the machine then a randomised instance name will still be assigned. Interestingly, this is of a different format to the normal instance names … but nonetheless this is still less than ideal for an instance we are going to want to create several times.

    Using the Ec2 Config Service Settings utility again, disable the Sysprep option from the Bundle tab. Under the covers, this will update the BundleConfig.xml file.

  • Setup the program / data Elastic Storage Block drive to be automatically assigned the appropriate drive letter based on its volume name.

    One of the other issues I have hit was getting the timing right for attaching the Elastic Storage Block (ESB) drive that I’m using for data when initiating a new instance of my Team Foundation Server AMI. If this is attached too soon then it may get automatically assigned to the D: drive. The result of this is quite severe;

    • None of the services will start, since SQL Server is expecting the data files to be on E: drive
    • The Windows page file is expecting to run on D: drive – so a large page file is suddenly loaded onto our relatively small data drive
    • The Ec2 instance storage (normally the D: drive) is not initialised and remains as an inactivate drive that needs to be manually mounted and formatted.

    Thankfully, Amazon has an answer for this issue as well. Provided we give our ESB drive an appropriate name (in my case, I’ve renamed it to DataVolume), we can use the same Ec2 Config Service Settings tool we used above to force the volume to use a specified drive letter when it is remounted in future.

  • Disable all drives on MagicDisc. Similar to the problem I encountered with the Elastic storage block drive being assigned to the D: drive, if MagicDisc is still enabled then this will get automatically assigned to the next available drive letter. As this is mounted before the instance storage, the first MagicDisc drive gets assigned to D: drive. Rather than uninstall completely, I’ve just disabled all drives before bundling the AMI (right click on the tray bar icon, select ‘set number of drives’ then ‘disable’).
  • Unrelated to the stability issues I was hitting, I’ve also installed the Visual Studio 2010 Express tools for Web Development. My next project is likely to be looking at setting up Team Foundation Server event subscriptions for changed work items, so having the development tools on the same box should be useful. One important observation though … of the 10GB hard disk made available by Ec2 … I’m now down to 1.5 free on C: drive … 😦

There is one issue I don’t have a fix for yet … and I’m not even sure that it’s an issue … but anecdotally I believe I’m also having trouble with the permissions assigned to the built-in Network Service account on my elastic storage block drive. A couple of times the SQL Server services have failed to start due to the Network Service account not having enough rights to the data directories. I’m going to keep an eye on this for a while, but for now I’m just re-assigning ‘modify’ rights whenever I come across this issue. I’m wondering if it’s worth using a local service account rather than Network Service … but it’s not causing me enough issues to want to rebuild the instance yet again (it’s been 5 times so far!!!).

I’m sure that there are still a few more idiosyncrasies that I need to iron out before I’m totally happy with this build … but at least I’m starting to feel a little more comfortable that when I start the instance I can use it productively within half an hour or so – rather than having to mess around with the configuration every time.


    • Hi Peter. Thanks for the feedback!

      You should be able to rename the volumns in the “My Computer” view.
      1) Open windows explorer.
      2) Right click on the Elastic Storage Block drive (probably E: drive) that you want to rename
      3) Click on Rename and give your ESB volume a unique name.

      Does this resolve the problem you are having?



  1. So I have installed TFS 2010 on Server 2008 DataCenter AMI provided by AWS. I have VS 2010 RC installed on my company computer. When I try to connect using the http address supplied during installation on EC2, it says the name cannot be resolved.

    I think my issue is that I don’t know how/where to add users to connect.

    Please advise!

    • Hi,

      Sorry about the delay in getting back to you.

      When you describe the problem as being “the name cannot be resolved” are you referring to a networking error (eg, IE doesn’t get to your EC2 TFS web sites at all), or an issue with the web site itself (eg, you see the TFS website, but can’t authenticate)?

      Assuming the problem is networking related, I would start with the following as troubleshooting steps

      • Does the URL you are using still match the public facing URL for the instance? Have you restarted the instance in the meantime and therefore ended up with a different URL? The URL should look something like “ec2-###-###-###-###.compute-1.amazonaws.com”
      • Have you tried connecting via IP address rather than domain name? Make sure you are using the ‘Public’ IP address provided by EC2, not the Private one.
      • If you ping the domain name provided by EC2, does it resolve to an IP address? (The ping will always fail to return, but you should get an IP address displayed)
      • Have you assigned the correct Amazon security groups to your instance? Is port 80, 8080 and 443 configured in the security groups to allow access from your IP address?

      Hopefully this helps get you started on resolving the issue. Please let me know if this doesn’t help (or even if it does!) or if I’ve misunderstood your problem.



Leave a Reply to Nick Hoggard Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s