Get-Command -Module AzureRM.Profile. You're seeing it correctly - it doesn't have a Logout-AzureRmAccount, Disconnect-AzureRmAccount, Remove-AzureRmAccount or even Remove-AzureRmContext commandlets! That's a lot of fun :)

Oh no! PowerShell cached my Azure credentials and I messed up wrong customer’s environment!

This post was most recently updated on October 8th, 2019.

Reading Time: 3 minutes.

Whoops. Could happen to anyone, since the Azure PowerShell since (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 test, and then production. In more serious cases, you’ll deploy your ARM templates or run your cleanup scripts against wrong customer’s environment.

Root cause for the issue

What Microsoft says themselves:
In versions 4.4.0 and later (see 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: Reset your Azure Remote Management Context

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

This solution presumes, that you already have AzureRM commandlets imported.

Running this shows you your current Azure Context:


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:

Set-AzureRmContext -Context ([Microsoft.Azure.Commands.Profile.Models.PSAzureContext]::new())

How to stop PowerShell from caching your credentials in the future?

Additionally, to disable this feature in the future, run this:


With that, you should be good. Just relaunch PowerShell, and 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).

Sources and further reading

0 0 vote
Article Rating
Notify of
Inline Feedbacks
View all comments
Henrique Fogaça

The last cmdlet is wrong, should be Disable-AzureRmContextAutosave.
But everything else helped fix an issue, thanks!