The problem when trying to delete VSTS ENVIRONMENTS

The Problem

Here's an interesting one relating to Visual Studio Team Services in Azure. A customer was trying to delete old test VSTS and associated Storage Account resources in Azure by logging into the visual studio portal and deleting the account. However, logging into Visual Studio as the admin user showed an error stating that the account did not have permissions to the VSTS instance!

 

Viewing the resources in Azure was not much better:

2.png

 

Clicking on Settings then Properties showed the following:

 

And the following error when clicking the Storage resource:

If we use PowerShell, we can see that the resources exist:

Name              : contoso

ResourceId        : /subscriptions/fbed7c4f-588f-4618-bfd7-432d6f3a864f/resourceGroups/VS-contoso-Group/providers/Microsoft.VisualStudio/account/contoso

ResourceName      : contoso

ResourceType      : Microsoft.VisualStudio/account

ResourceGroupName : VS-contoso-Group

Location        : westeurope

SubscriptionId    : fbed7c4f-588f-4618-bfd7-432d6f3a864f

Tags              : {}

Name              : contoso/Test1

ResourceId        : /subscriptions/fbed7c4f-588f-4618-bfd7-432d6f3a864f/resourceGroups/VS-contoso-Group/providers/microsoft.visualstudio/account/contoso/project/Test1

ResourceName      : contoso/Test1

ResourceType      : microsoft.visualstudio/account/project

ResourceGroupName : VS-contoso-Group

Location          : northcentralus

SubscriptionId    : fbed7c4f-588f-4618-bfd7-432d6f3a864f

 

So, the question is, how to delete them if Azure and VSTS were erroring but the correct account was being used? Eventually, Microsoft support were enlisted to help. Initially, they wanted to check that the account being used to try the deletion did have permissions on the object and on VSTS. (Yes, it most certainly does – it is a Global Admin and VSTS admin.) Eventually, the call had to be escalated to engineering and they also started by ensuring that the account being used to delete the object was the same one used to create the VSTS account. This time, however, they listed what the account was that was associated with the VSTS account and at first glance, it did indeed look like the correct account. Until it was noticed that the UPN suffix was wrong!

How it that possible? Well, this particular customer uses AD Connect (without password synchronisation) and ADFS to provide federated authentication using the internal AD. However, a few months back, they changed their UPN suffix (e.g. user@oldupn.com) to user@newupn.com). Everything had worked perfectly – until now! It appears that, oddly, VSTS does NOT use the user's GUID when authenticating, it actually uses the login name itself (user@contoso.com). So, VSTS was refusing to recognise user@newupn.com as a valid VSTS account, hence the deletion problem.

The Resolution

The resolution is a simple case of reverting back to the old UPN suffix temporarily, logging back in and trying again. (NOTE: If this is not possible – for example if the old suffix is no longer available -  Microsoft Support may be able to assist.) This is what Azure then showed

It was therefore possible to log into Visual Studio: https://.visualstudio.com/_projects successfully and delete the account in the visualstudio.com portal: