This post has been republished via RSS; it originally appeared at: ITOps Talk Blog articles.
PowerShell provides an effective way to run queries or actions at scale, whether that's against Azure resources, Azure Active Directory identities or Office 365 environments (including Exchange Online, SharePoint Online and Microsoft Teams). The first step is connecting PowerShell to your tenant and subscription with valid credentials, using the "Connect-AzAccount" command. So what happens if you hit an error with that very first step?
The warning sign
In PowerShell, I ran the "Connect-AzAccount" command, visited the website and entered the provided (redacted) code. The login process seemed to then authorize my username and password without error, but there was something strange in what was returned (see if you can spot it, below):
This was a slightly tricky question, as you may not be able to tell that I haven't blacked out the SubscriptionName or TenantID for security reasons. They appeared blank.
This account has access to multiple subscriptions in a single tenant, so before we start issuing commands, we need to set the context. Usually one is picked up by default but you can use the same process to switch to a different subscription or tenant if needed. In this case, with none selected, I issued the next command "Set-AzContext" and provided the -SubscriptionID that I wanted the commands to act against, only ....
Denied!
Troubleshooting
On hitting this error I did what most seasoned IT Professionals would do - I searched the internet for the phrase "failed to acquire token silently as no token was found in the cache the refresh token had expired due to inactivity".
No matter what permutation I used of these search terms, the limited results I did find were related to API calls or application errors. Not at all helpful in this context (see what I did there?).
What was helpful was this Doc regarding Azure PowerShell context objects. It didn't specifically list the above error, but it did give me the PowerShell credentials equivalent of "turn it off and back on again" - the "Clear-AzContext" command!
After running Clear-AzContext, I was able to re-run Connect-AzAccount and pick up a default context successfully, then run my commands.
Conclusion
What caused this error to fire? I have no idea. It's one of those scenarios where the cost benefit analysis doesn't really stack up to investigate it further. It was likely a one-off incident on my particular PC and I could invest a ton of time in trying to reproduce it or troubleshoot it - or I could accept that I found a quick and easy fix. If it does re-occur or if we get an outpouring of comments that it happens to other people all the time too, then it might be worth looking into further.
But for now, I'll take the win that clearing the cache was enough to pull down a new, valid authentication token. And it is worth the time to blog about it, for the next seasoned IT Professional that encounters the same thing.
Yours in troubleshooting,
SCuffy.