I have a Microsoft account that is the administrator for a number of subscriptions. I was trying to create a Redis cache to use for ASP.NET Session Storage for a recently created subscription. That subscription is not my default.

Problem description:

I created a new Redis Cache on a subscription that was not my “primary” subscription using the new preview portal. When creating the cache the system asks to assign it to a resource group – the one I selected was the Cloud Service I intended to access the cache from. Once the portal reported that the cache was successfully provisioned the problems started.

I could not connect to the Redis cache – even telnet reported that the remote port was closed

I could not view the details of the cache, or any item in the new portal at all (though the regular Azure portal did work)

I could not use PowerShell to access the Redis cache because I was getting an error:

Get-AzureRedisCache : AuthenticationFailed: The access token is from the wrong issuer 'https://sts.windows.net/[tenant-guid]/'. It must match the tenant 'https://sts.windows.net/ [different-tenant-guid]/' associated with this subscription.

Thanks to the errors in PowerShell I decided this error was something to do with authentication during provisioning. I decided to create a new account that was defaulted to the correct subscription/tenant and see if I could access the Redis Cache that way – if only to delete it.

Create a new Azure Active Directory
It doesn’t matter what you call it, you can delete it later – I used “blahblah234”

Create a new account in the new AD and assign it an administrator role (I used Service Administrator)
Again, call it anything – I used “administrator”

Set the Subscription’s directory to the new directory
This should trigger a reload of the whole environment with the directory filter set to the new one. If not be sure to switch to the correct directory using the “Subscriptions filter” at the top of the window

Add the new account as an administrator of the subscription
For the “Email address” just put the account name you created in step 3 followed by the directory name from step 2, in my case that’s administrator@blahblah234.onmicrosoft.com; then tick the subscription to assign them to – there’s probably only 1 at this point if you’re following the directions

This should create us a new account who’s associated with the correct subscription/tenant.

I used this new account to log into the new portal (https://portal.azure.com) and lo, and behold, the portal behaved properly allowing me to view, and delete, the Redis Cache.

This isn’t the end of the tale though since the new portal still didn’t work for me even if I changed the directory to the new one (or my default). Based on a suggestion from technical support at Microsoft I went to go “Restore default settings” but that did nothing – by which I mean clicking the button caused no action. I checked in IE’s console/debugger and there were no errors, but nothing was happening either.

I logged out of the new portal, changed the directory for the subscription back to my default one, then logged back into the new portal – still borked. In frustration I clicked the “Restore default settings” madly a dozen or so times and somehow it worked and the portal reloaded. After that things seem to be OK again… for now.

I have since deleted the account and directory I created to repair the problem.

Conclusion:

I’m a little disappointed here that Microsoft can call their Redis Cache service “Gold” when the tools to create and manage the service are “Preview” and clearly still buggy. I think if you’re going to call something “Gold” that should include all the moving parts and not just the service itself. I could not have managed this repair with the guidance from Chase Miller at Azure Technical Support who pointed me at the PowerShell commands for Redis (that I wasn’t able to find on my own) that are hiding in plain view.