#Azure powershell and the Run Login-AzureRmAccount to login issue


I use Azure powershell almost every day, as a matter of fact I constantly keep it updated using the powershell integrated oneget module (i.e. the ability to use the install-module and update-module cmdlets). I’m literally working with 10s of tenants and much subscriptions, switching back and forth with the proper credentials.
Not a nice experience, but it works and let you manage the artifacts on Azure efficiently and rapidly.
Until you start to get the “Run Login-AzureRmAccount to login” invoking specific cmdlets, when you know that you just logged on and that other cmdlets are working just fine. Always in a hurry I tried all the workarounds you can find in the community space, but in the end none of them was resolutive in my case. It seemed to fix it for a while, but then after a few hours the issue was there again.
So I took the time to investigate what was going on, trying not to invest too much time reverse engineering the Azure powershell assemblies.
The solution I found and that seems to work after a couple of weeks relates to the infamous DLLs hell scenario that used to afflict the Windows operating system.
The culprit is ADAL or better the DLLs related to this technology. ADAL is the authentication assembly used by Azure powershell.
Unfortunately almost every Azure powershell module brings in its own copy, searching for Microsoft.IdentityModel.Clients.ActiveDirectory.dll on my systems returned 207 different instances of the dll and 11 different versions.

If you want to try your own:

$res = get-childitem -path '\' -filter Microsoft.IdentityModel.Clients.ActiveDirectory.dll -recurse
write-host $res.count
$res | select @{Name='Version';Expression={$_.VersionInfo.FileVersion}} | sort Version -Unique

It happens that sometimes the dll loaded is not from the AzureRM.profile module directory, when this happens even if the loaded DLL version is correct (= to the AzureRM.profile one) some cmdlet fails.
How can you know you’re in this situation? Just run:

[appdomain]::currentdomain.getassemblies() | where {$_.ManifestModule -ieq 'Microsoft.IdentityModel.Clients.ActiveDirectory.dll'} | ft manifestmodule, location -autosize

if the DLL location doesn’t match the AzureRM.profile directory you’re in my case.
Don’t ask me why some cmdlets are not working, probably they’re incorrectly assuming the loaded DLL is the one in AzureRM.profile. I hadn’t the time to dig further.

The solution is to remove the module the dll is loaded from with uninstall-module and then reinstall it again with install-module. Again don’t ask me why, if it works it is fine for me, I really don’t have the time to investigate.

Hope this helps.
Daniele

Advertisements

,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: