This post was most recently updated on March 28th, 2023.

3 min read.

Whoops. This could happen to anyone since the Azure PowerShell (approximately) version 6.3.0 will cache your credentials between sessions without warning you. It’s really easy to run your commands with cached accounts and end up executing your scripts against the wrong environment.

In less serious cases, this means that you’ll end up running commandlets twice against the test environment, while you think you’re running them first against the test, and then production. In more serious cases, you’ll deploy your ARM templates or run your cleanup scripts against the wrong customer’s environment.

The root cause for the issue

Table of Contents

What Microsoft says:
In versions 4.4.0 and later (see https://github.com/Azure/azure-docs-powershell/blob/master/docs-conceptual/azurermps-5.7.0/context-persistence.md for more info), it’s been possible to cache your context. In some later version (probably 6.3.0) Microsoft flipped the switch to enable this by default – so now Azure PowerShell retains your context information automatically between sessions.

This means, that if you were running some AzureRM commandlets against Customer X’s environment, then shut down your machine for the night, and start running commandlets against Customer Y’s environment, you might use the context from yesterday – X’s environment.

I’ve done this. That meant I was provisioning new Azure artefacts into the wrong customer’s environment. Ouch…

So the way this has been implemented, is that Azure PowerShell offers a feature called Azure Context Autosave, which gives the following features:

Retention of sign-in information for reuse in new PowerShell sessions.
Easier use of background tasks for executing long-running cmdlets.
Switch between accounts, subscriptions, and environments without a separate sign-in.
Execution of tasks using different credentials and subscriptions, simultaneously, from the same PowerShell session.

So with Any AzureRM version after 4.4.0, you might be in danger, and for versions after 6.3.0, you’re definitely in danger of using this functionality in an unexpected manner. :)

To see which version you’re using, run this:

Get-Module AzureRM -ListAvailable

But what does this feature mean in practice? In short, if you run certain commandlets (like Add-AzureRmAccount) while it already has a cached account, it will use the cached one instead of the one you’re offering it.

Yeah, sounds unintuitive and kind of dangerous, but the intention was to make your life easier. Paving the way to hell and all that…

In short: it’s not a bug, it’s a feature.

A feature, that’s been a bit of a pain to at least yours truly. But how to work around it?

Solution

Okay, you probably don’t want to use the cached credentials when changing between customer environments. You’ll want to instead get rid of the cached credentials – but that can’t be done super easily.

Time needed: 5 minutes

Reset your Azure Remote Management Context

This solution presumes, that you already have AzureRM commandlets imported.
Running this shows you your current Azure Context:

<pre lang="powershell">Get-AzureRmContext </pre>

That one shouldn’t return anything when you open up a new session – but it sometimes does. And this might catch your scripts off-guard!
For initializing your context, especially in scripts that you’re distributing to someone else, it might be worthwhile to set your context to an empty one before your script creates one.
This commandlet will nullify the cached context by overwriting it with a new, empty one:
<pre lang="powershell">Set-AzureRmContext -Context ([Microsoft.Azure.Commands.Profile.Models.PSAzureContext]::new()) </pre>
Additionally, to disable this feature in the future, run this:
<pre lang="powershell">Disable-AzureRmContextAutosave</pre>
With that, you should be good. Just relaunch PowerShell, and the cache should be gone!

Note: The snippet above used to say “Disable-AzContextAutoSave”. That’s a valid command as well, but for Azure PowerShell (instead of Azure RM commandlets).

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)