How to Link Existing Visual Studio Online with Windows Azure

I was trying to link my Visual Studio Online (formerly Team Foundation Service or TFS Online) tenant to my Windows Azure subscription and stumbled through some items that are not well documented. The main problem I ran into was that Visual Studio Online only used Microsoft Accounts and in my case my Windows Azure subscriptions are setup using Office 365 accounts and not Microsoft Accounts. The next problem I ran into was that account owner set on my Visual Studio Online wasn’t the account I thought it was so I need to find a way to update the account owner before I could proceed.

Microsoft Requirements to Link Visual Studio Online with Windows Azure

  • Windows Azure subscription can’t be linked to MSDN benefit. If this is your case you need to create a new Pay-As-You-Go subscription.
  • Microsoft Account used for Visual Studio Online needs to be the subscription Service Administrator or a Co-Administrator on the subscription.

Part 1 – Add / Adjust Microsoft Account users in Visual Studio Online

  1. Log into your Visual Studio Online tenant https://XXXXX.visualstudio.com/ using a Microsoft Account with admin access.
  2. Click on gear icon to Administer Account

  3. On the Administer your account screen, click on “Manage collection security and group membership”.

  4. On the Security screen, confirm you are on “Project Collection Administrators” and click “Members”.

  5. On the Members screen, confirm the Microsoft Account you want to set as owner is listed. If not click on “Add” to add the Microsoft Account.

Part 2 – Adjust Visual Studio Online owner (if current owner is incorrect)

  1. Log into your Visual Studio Online tenant https://XXXXX.visualstudio.com/ using your Microsoft Account that is the owner. If you are not sure which account is the owner you can follow these same steps but you will not be able to update until you are logged in as the account owner.
  2. Click on gear icon to Administer Account.

  3. On the Administer your account screen, click on “Settings”.

  4. On the Settings screen, click on the “Account owner” drop down and select the correct account. — Side note: Another problem I ran into is that I have several Microsoft Accounts that I use. The display name for a few of these turns out to be the same my name. This drop down only shows display name, so I had to try a few times to get the correct one. L

  5. Click the save icon.

Part 3 – Add / Confirm Microsoft Account is a Co-Administrator on the Windows Azure subscription

  1. Log into your Windows Azure subscription https://manage.windowsazure.com as the service administrator. In my case this is an Office 365 account.
  2. On the left hand side navigation, click on “Settings”.

  3. On the Settings screen, click on “Administrators”.

  4. On the Administrators screen, if the Microsoft Account is already listed as an Account Administrator or Co-Administrator then you are done with this part. Skip to Part 4.
  5. If you want to add a new Co-Administrator, click on “Add”.

  6. On the Add a Co-Administrator screen, enter the valid email address that is the same as the Visual Studio Online tenant owner, select which subscriptions this account can co-administer, then click on check mark icon to save.

Part 4 – Link Visual Studio Online to Windows Azure subscription

  1. Log into your Windows Azure subscription https://manage.windowsazure.com as the same Microsoft Account that is the owner of Visual Studio Online tenant.
  2. On the left hand side navigation, click on “Visual Studio Online”.

  3. On the Visual Studio Online screen, click on “Create or Link a Visual Studio Online Account”

  4. This will open the “New” menu.

  5. Click on “Link to Existing”
  6. On the Link to Existing options, confirm the correct Visual Studio Online tenant is displayed, then pick which subscription you want to bill Visual Studio Online services to. You can later unlink your Visual Studio Online account and relink to a different subscription but any licensing purchased will not be refunded.

  7. Click on “Link Account”

  8. Windows Azure will show that it is linking the Visual Studio Online tenant.

Part 5 – Confirm and Manage the Visual Studio Online tenant account related settings.

  1. Log into your Windows Azure subscription https://manage.windowsazure.com as any Service Account or Co-Administrator account that has access to the same subscription as setup with Visual Studio Online.
  2. On the left hand side navigation, click on “Visual Studio Online”.

  3. On the Visual Studio Online scree, you should see the linked Visual Studio Online tenant.

  4. Click on the name of the Visual Studio Online tenant.
  5. Main page looks like this.

  6. Dashboard page looks like this.

  7. Scale page looks like this.

Good Practices for Managing Microsoft Azure Subscriptions

We’ve published some updated guidance for Service Admin account management based on the new RBAC access control techniques now available in Azure. While the classic non-RBAC portal is required, the content in the post here is still very relevant though!

Overview

Over the years it has been drilled into me to use “Least Privilege” access whenever and however possible. Least Privilege is all about limiting users, systems, and services to only those privileges which are absolutely essential to get the job done. Microsoft Azure should be no different and some would argue even more important when it comes to Least Privilege. However what tends to happen in the cloud space is business units want to avoid/bypass IT Departments and setup in the case of this article Microsoft Azure subscriptions without much thought. This can lead to incorrect users having access to production services and once discovered is hard to correct as once services are deployed you can’t easily move services between subscriptions.

Microsoft Azure Subscription Components:

Enterprise Administrator

Standard Customer – Not Applicable

Enterprise Agreement Customers – The Enterprise Administrator has the ability to add or associate Accounts to the Enrolment, can view usage data across all Accounts, can view the monetary commitment balance associated to the Enrolment, and can provide Account Owner visibility to view charges.

There is no limit to the number of Enterprise Administrators on an Enrolment.

Account Owner

Standard Customer – The Account Owner is the Microsoft Account (formerly Live ID) or Azure Active Directory (AAD) Account that is responsible financially for the Microsoft Azure monetary commitment. Microsoft will send invoices to the email address associated with the Account Owner. The Account Owner can add Subscriptions for their Account, update the Service Administrator and Co-Administrators for an individual Subscription and view usage data for their Account.

Enterprise Agreement Customers – this definition changes slightly. The Account Owner (by default) will not have visibility of the monetary commitment balance unless they also have Enterprise Administrator rights. An Enterprise Administrator can choose to grant the Account Owner the rights to view the monetary commitment.

There is a limit of 1 Account Owner for each Account.

Subscription

A Subscription is a billing container for deployed Microsoft Azure services.

There is a limit of 1 Service Administrator for each Subscription.

There is a limit of 200 Co-Administrators for each Subscription.

Service Administrator

The Service Administrator can perform all functions within a Subscription including add/remove Co-Administrators. By default the Service Administrator will be the same as the Account Owner.

Co-Administrator

A Co-administrator can perform all functions within a Subscription except change the Service Administrator and add/remove other Co-administrators.

Use Multiple Microsoft Azure Subscriptions

Multiple Subscriptions allow a company to easy view billing for each Subscription and limit who can access the Microsoft Azure services associated with that subscription.

An example of using multiple subscriptions might be:

Subscription 1

  • Name: “Company – Project 1 – Development”
  • Service Administrator: Development Manager
  • Co-Administrators: Developers on Project 1

Note: A developer may not need to be a Co-Administrator but instead only require a Management Certificate as explained below.

Subscription 2

  • Name: “Company – Project 1 – Test”
  • Service Administrator: Test Manager
  • Co-Administrator: Testers on Project 1

Subscription 3

  • Name: “Company – Project 1 – Pre-Production”
  • Service Administrator: IT Manager
  • Co-Administrator: Senior IT Support Team (Level 3)

Subscription 4

  • Name: “Company – Project 1 – Production”
  • Service Administrator: IT Manager
  • Co-Administrator: Senior IT Support Team (Level 3)

Use Descriptive Names for Microsoft Azure Subscriptions

When it comes to naming a Microsoft Azure subscription, it is good practice to use descriptive names.

I typically recommend the following format, but as long as you develop a format that works for your company go for it.

My Recommendation:

<Company> – <ProjectName> – <Environment>

Explanation of My Recommendation

<Company> is the name of your company. You might be wondering “Why would I add my company name to my company’s Subscriptions that seems a little overkill”. The reason I recommend this is if/when you hire a contractor or outside company to assist you with your Microsoft Azure services you will most likely need to make then a Co-administrator on a particular Subscription. When that contractor/company logs into the Microsoft Azure portal they see a list of all subscription they are associated with. So they might see: CustomerASubscription1, CustomerASubscription2, CustomerBSubscription1, etc.

If you named your Subscription “Development” and some other company named their Subscription “Development” then the contractor/company would see “Development” and “Development” in the list. To me that adds a risk where they could accidentally perform some action on the wrong Subscription. The risk is pretty small as they would more than likely also need to know the service name such as storage account “XYZ”, but still a risk is a risk and when possible should be mitigated.

<ProjectName> is the name that your project is known by. You might have one project that is all about your company’s intranet which is called “Inside” and another project that is all about your company’s public web site. In this case you might have one set of service for “Inside” where you use “Inside” as the project name and another set of services for your public website where you might use the name “PublicWebsite” as the project name.

Now you might be thinking “That seems like I might end up with a lot of Subscription in the end which is pretty overkill”. Yes, you are correct you might, but then again I would rather have a lot of Subscriptions that I can control access to over, say, one big Subscription called “Production”. Plus do I really want the administrator of ProjectA having full access to ProjectB services in Production?

<Environment> is the name I choose to use because in most of the deployment of Microsoft Azure services I have worked with, that really is what it turns out to be. A group of Microsoft Azure services that all form part of “Development”, “Test”, or “Production”.

NOTE: I don’t recommend using an environment name of “Staging” because I feel that it can become confusing when Windows Azure deployments have two slots “Staging” and “Production”.

Use Named User Accounts

A named account is an account that is associated to a single person and typically named in such a way as to identify that person. Example: First.Last@outlook.com instead of SweetGuy88@outlook.com. You might know who SweetGuy88 is today but in six months times I bet you forget who that is and have to run around trying to figure it out. Save yourself the hassle and used named accounts day 1 where possible.

Another thing I recommend is that you setup named accounts @ your company name instead of @hotmail, @outlook, etc. When you setup a Microsoft Account, you are required to verify your identity which means Microsoft sends an email to first.last@company.com that you must click verify before the account is considered verified. When I use contractors or outside companies I recommend that they setup the accounts to be the same as the work email address I know them by. This helps me as an administrator identity who is inside my organisation and who isn’t.

Establish Guidelines for Microsoft Accounts (formerly Live IDs)

Microsoft Accounts are out of your company’s control for the most part. As such I recommend you establish some guidelines for Microsoft Accounts that you try and push your users to adopt. It would be nice if Microsoft had a way to setup Enterprise Microsoft Accounts that as an Enterprise I could better control. Federation with Microsoft Azure Active Directory helps in this matter but does not solve the problem 100%.

The Guidelines I personally use are:

  • Use a strong password. Example: 16 characters long with mixed case and numbers. The longer and more complicated the better. If this account is associated with your production Windows Azure subscription, then this account can access not only the Microsoft Azure services (Stop/Delete services) but also has access to all the data in your storage accounts within the associated Subscription.
  • Use a named account. Use an account name that is easy to identity. first.last instead of SweetGuy88.
  • Link to your company email. This way the account will have to be verified using a company email address they have access to. Also if the person leaves your organisation you may in some cases be able to reset the password if required.
  • Change Passwords Regularly. This is always a good practice but is becoming harder and harder to do when we have so many passwords to remember. If remembering passwords becomes an issue a tool such as LastPass or KeePass might provide assistance.
  • Add Alternate email address. I also associate with my Microsoft Account another email address so that if I forget my password, I have another ways to get back in.

Use Microsoft Azure Affinity Groups

Microsoft’s Definition – Affinity groups allow you to group your Microsoft Azure services to optimize performance. All services within an affinity group will be located in the same data center. An Affinity Group is required in order to create a virtual network.

Why is this a good practice? Originally when Microsoft Azure datacentres were built, latency between different parts of the datacentres could be high. Today this is less of a reason to use Affinity Groups as Microsoft datacentres are now built in a way to keep latency down. Affinity Groups are now used mainly to simplify deployment of services, instead of having to pick both a Region and Subscription you only need to pick an Affinity Group. Affinity Groups are used in all of Microsoft’s backend management logic of Microsoft Azure. When services are moved, restarted, restored, etc. an Affinity Group is taken into an account and treated as a set of services and kept close together and in the same physical datacentre. Once services are deployed you can’t move services easily into an Affinity Group.

Use Management Certificates

Microsoft’s Definition – Management Certificates permit client access to resources in your Microsoft Azure subscription. Management certificates are x.509 v3 certificates that only contain a public key, and are saved as a .cer file.

If a person requires the ability to deploy or change services running in Microsoft Azure but does not require access to the Azure Management Portal, then provide them only a Management Certificate. This scenario is common with a large development teams. A developer that needs to deploy to Microsoft Azure services through a tool such as Visual Studio may only require a Management Certificate.

NOTE: There is a limit of 100 management certificates per Microsoft Azure subscription. There is also a limit of 100 management certificates for all Subscriptions under a specific Service Administrator’s user ID. If the user ID for the Account Administrator has already been used to add 100 management certificates and there is a need for more certificates, you can add a Co-Administrator to add the additional certificates.  Before adding more than 100 certificates, see if you can reuse an existing certificate. Using Co-Administrators adds potentially unneeded complexity to your certificate management process.

Standard Customer – Good Practice Setup

Standard Customer - Good Practice Setup

Enterprise Agreement Customers – Good Practice Setup

Enterprise Agreement Customer - Good Practice Setup

Summary of Good Practices

  1. Use Multiple Microsoft Azure Subscriptions
  2. Use Descriptive Names for MicrosoftAzure Subscriptions
  3. Use Named User Accounts
  4. Establish Guidelines for Microsoft Accounts (formerly Live IDs)
  5. Use Microsoft Azure Affinity Groups
  6. Use Management Certificates.
We’ve published some updated guidance for Service Adminaccount management based on the new RBAC access control techniques now available in Azure. While the classic non-RBAC portal is required, the content in the post here is still very relevant though!