Welcome Azure DevOps

Yesterday Microsoft announced a change in naming for VSTS, now branded as Azure DevOps. You can read most of the details in this blog post and if you are using VSTS right now you will not have a big impact in the future. Event is this is just a rebranding of the service, there are a couple of suggestion I’d like to give you to have a smoother transition.

Visual  Studio Team Services was rebranded in Azure DevOps, this will not impact your existing VSTS projects, but it is wise to start planning for a smooth transition.

First of all, if you still don’t use the new navigation, I strongly suggests to enable it, because it will become the default navigation in the future, and it is best to gain familiarity with it, before it will become the only UI available.


Figure 1: Enable the new navigation for the account

The nice aspect is that you can enable new navigation only for your account, then enable for all accounts in the instance. This will make the transition smoother, you can find key member of your teams that wants to try new features, let them explore it and after some time let everyone use the new interface, knowing that at least some core members of the team are well used to it. Planning for a smooth transition instead of having big bang day when everyone can only use the new UI it is a wise approach.

Another suggestion is starting to use the new links right now, if your account is https://nablasoft.visualstudio.com, your new URI will be https://dev.azure.com/nablasoft and it is already available for all of your accounts. You can expect that the old URI will work for a really long time, but it is better starting to use the new URI as soon as possible, to avoid having link in the old format that maybe will cease to work some years from now.

Another part of the service that is affected by change of uri is remote address of git repositories. Microsoft assures that the old url will remain valid for a long time, but it is good to spend 1 minute updating remotes to never worrying that some day in the future remotes uri can break.


Figure 2: Change the url of origin to adapt to the new uri of Azure DevOps Repositories.

Updating git remote address is a good practice to immediately start using the new and official link.

Thanks to git, the only thing you need to do is grab the new link using the new UI, and use the command git remote set-url origin newlink to update uri of the remote to the new one, and you can continue work as ever (the first time you will be prompted by a login because you never authenticated git to dev.azure.com domain).

Happy VSTS oops :) Happy Azure Devops

Gian Maria.

Use the right Azure Service Endpoint in build vNext

Build vNext has a task dedicated to uploading files in azure blob, as you can see from Figure 1:

Sample build vNext that has an Azure File Copy task configured.

Figure 1: Azure File Copy task configured in a vNext build

The nice parte is the Azure Subscription setting, that allows to choose one of the Azure endpoint configured for the project. Using service endpoint, you can ask to the person that has password/keys for Azure Account to configure an endpoint. Once it is configured it can be used by team members with sufficient right to access it, without requiring them to know password or token or whatever else.

Thanks to Services Endpoints you can allow member of the team to create builds that can interact with Azure Accounts without giving them any password or token

If you look around you find a nice blog post that explain how to connect your VSTS account using a service principal.

SAmple of configuration of an Endpoint for Azure with Service Principal

Figure 2: Configure a service endpoint for Azure with Service Principal Authentication

Another really interesting aspect of Service Endpoints, is the ability to choose people that can administer the account and people that can use the endpoint, thus giving you full security on who can do what.

Each Service endpoint has its security setting to specify people that can administer or read the endpoint

Figure 3: You can manage security for each Service Endpoint configured

Finally, using Service Endpoint you have a centralized way to manage accessing your Azure Subscription Resources, if for some reason a subscription should be removed and not used anymore, you can simply remove the endpoint. This is a better approach than having data and password or token scattered all over the VSTS account (builds, etc).

I’ve followed all the steps in the article to connect your VSTS account using a service principal, but when it is time to execute the Azure File Copy action, I got a strange error.

Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\AzureFileCopy\1.0.25\AzureFileCopy.ps1
Looking for Azure PowerShell module at C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1
Get-ServiceEndpoint -Name 75a5dd41-27eb-493a-a4fb-xxxxxxxxxxxx -Context Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.TaskContext
tenantId= ********
azureSubscriptionId= xxxxxxxx-xxxxxxx-xxxx-xxxx-xxxxxxxxxx
azureSubscriptionName= MSDN Principal
Add-AzureAccount -ServicePrincipal -Tenant $tenantId -Credential $psCredential
There is no subscription associated with account ********.
Select-AzureSubscription -SubscriptionId xxxxxxxx-xxxxxxx-xxxx-xxxx-xxxxxxxxxx
The subscription id xxxxxxxx-xxxxxxx-xxxx-xxxx-xxxxxxxxxx doesn't exist.
Parameter name: id
The Switch-AzureMode cmdlet is deprecated and will be removed in a future release.
The Switch-AzureMode cmdlet is deprecated and will be removed in a future release.
Storage account: portalvhdsxxxxxxxxxxxxxxxxx1 not found. Please specify existing storage account

This error is really strange because the first error line told me:

The subscription id xxxxxx-xxxxxx-xxxxxx-xxxxxxxxxxxxx doesn’t exist.

This cannot be the real error, because I’m really sure that my Azure Subscription is active and it is working everywere else. Thanks to the help of Roopesh Nair, I was able to find my mistake. It turns out that the Storage Account I’m trying to access is an old one created with Azure Classic Mode, and it is not accessible with Service Principal. A Service Endpoint using Service Principal can manage only Azure Resource Manager based entities.

Shame on me :) because I was aware of this limitation, but for some reason I completely forgot it this time.

Another sign of the problem is the error line telling me: Storage account xxxxxxxxx not found, that should ring a warning bell about the script not being able to find that specific resource, because it is created with classic mode.

The solution is simple, I could use a Blob Storage created with Azure Resource Manager, or I can configure another Service Endpoint, this time based on a management certificate. The second option is preferrable, because having two Service Endpoint, one configured with Service Principal and the other configured with Certificate allows me to manage all type of Azure Resources.

Configure an endpoint with certificate is really simple, you should only copy data from the management certificate inside the Endpoint Configuration and you are ready to go.

Configuration of an endpoint based on Certificate

Figure 4: Configure an Endpoint based on Certificate

Now my build task Azure File Copy works as expected and I can choose the right Service Endpoint based on what type of resource I should access (Classic or ARM)

Gian Maria

Where is my Azure VM using Azure CLI?

Azure command line interface, known as Azure CLI is a set of open source, cross platform commands to manage your Azure resources. The most interesting aspect of these tools is that they are Cross Platform and you can use them even on Linux boxex.

After you imported your certificate key to manage your azure account you can issue a simple command

azure vm list

To simply list all of your VM of your account.


Figure 1: Output of azure vm list command

If you wonder why not of all your VMs are listed, the reason is, Azure CLI default to command mode asm, so you are not able to manage resources created with the new Resource Manager. To learn more I suggest you to read this couple of articles.

Use Azure CLI with Azure Resource Manager
Use Azure CLI with Azure Service Management

If you want to use new Resource Manager you should switch with the command:

azure config mode arm

But now if you issue the vm list command, probably you will get an error telling you that you miss authentication. Unfortunately you cannot use certificate to manage your account (as you can do  with Azure PowerShell or Azure CLI in config mode asm). To authenticate with Azure Resource Manager mode you should use the command

azure login

But you need to use an account created in your Azure Directory, and not your primary Microsoft Account (at least mine does not work). This article will guide you on creating an user that can be used to manage your account. Basically you should go in old portal, get to the Active Directory Page and create a new account. Then from the global setting pane you should add that user to the Subscription Administrator group. Please use a really strong password, because that user can do everything with your account.

When you login correctly into Azure from CLI, you can use the same command to list VMs, but now you will see all VMs that are created with the new Resource Manager.


Figure 2: In arm mode you are able to list VM created with the new Resource Manager.

This happens also in standard Azure Portal GUI, because you have two distinct node for Virtual Machine, depending if they are created with Azure Service Management or Azure Resource Manager.


Figure 3: Even in the portal you should choose which category of VM you want to manage

Gian Maria

Where is my DNS name for Azure VM with new Resource manager?

Azure is changing management mode for resources, as you can read from this article and this is the reason why, in the new portal, you can see two different entry for some of the resources, ex: Virtual Machines.


Figure 1: Classic and new resource management in action

Since the new model has more control over resources, I’ve create a linux machine with the new model to do some testing. After the machine was created I opened the blade for the machine (machine create with the new model are visible only on the new portal) and I noticed that I have no DNS name setting.


Figure 2: Summary of my new virtual machine, computer name is not a valid DNS address

Compare Figure 2 with Figure 3, that represents the summary of a VM created with the old resource management. As you can see the computer name is a valid address in domain cloudapp.net


Figure 3: Summary of VM created with old resource management, it has a valid DNS name.

Since these are test VM that are off most of the time, the IP is chaning at each reboot, and I really want a stable friendly name to store my connection in Putty/MremoteNG.

From the home page of the portal, you should see the resource manager group where the machine was created into. If you open it, you can see all the resources that belongs to that group. In the list you should see your virtual machine as well as the IP Address resource (point 2 in Figure 4) that can be configured to have a DNS name label. The name is optional, so it is not automatically setup for you during machine creation, but you can specify it later.


Figure 4: Managing ip addresses of network attached to the Virtual Machine

Now I set the name of my machine to docker.westeurope.cloudapp.azure.com to have a friendly DNS for my connection.


How to connect existing VSO Account to new azure portal

With the new deploy of Visual Studio Online you can link your existing VSO accounts to your azure subscription so they will be available on new Azure portal http://portal.azure.com. You just need to connect to standard management portal (http://manage.windowsazure.com) and then add an existing VSO account to the list of available ones.


Figure 1: Use the New button in azure portal to add existing VSO account to new azure portal.

Your account is now connected to your azure account, now you should connect the account to your Azure Directory. This is not an automatic operation, you need to go to account details page and then ask to connect the account to your directory. After some time your account should be connected to Azure Directory


Figure 2: Your VSO account is now connected to My Default Directory

You should be now able to view your account in new portal http://portal.azure.com


Figure 3: My existing VSO account is now available in the new azure portal.

This is an important change for your account, because now all the users are taken from the Default Directory and existing users are not able to access anymore your service until you do not add them to your directory. This step is needed also to be able to connect to VSO with your corporate credentials, if your Azure Directory is synchronized with your Active Directory.

I strongy suggest you to read this fantastic post by Mitch Denny and also some interesting link to better understand how this works.

Gian Maria