3

I'm currently learning how to create azure environments using powershell Resource Management cmdlets.
The classic way of working had no problems, I could use Add-AzureAccount and it would allow me to access my subscriptions.

However, with the new Resource Manager cmdlets, when I use Add-AzureRmAccount I get either one of two errrors.

When using stored credentials using $Cred = Get-Credentials, and then logging in using Add-AzureRmAccount -Credential $cred I receive the following error:

Accessing ws metadata exchange failed.

When using the login prompt. Which means I just type in Add-AzureRmAccount and it forwards me to my company SSO page. In which I log in successfully. I get the following error:

An error occurred while sending the request.

When I tried to use the cmdlet from home, using vpn to connect with the same laptop that I was using before. I can connect perfectly using Add-AzureRmAccount and following the logon prompts. Using the stored $credentials still fails with the metadata exchange error.

I'm assuming that the stored credentials method is failing because it can't redirect to the SSO without the interactive prompt.
However I'm unsure what might be causing the interactive logon to fail, as I can clearly reach the SSO, and the Add-AzureAccount cmdlet works on the same machine.

What is the difference between the Add-AzureAccount and the Add-AzureRmAccount cmdlets that might be causing this?

UPDATE:

The full stack trace error is:

Message        : An error occurred while sending the request.
Data           : {}
InnerException : System.Net.WebException: The remote server returned an error: (407) Proxy Authentication Required.
                    at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
                    at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
TargetSite     : Void ThrowForNonSuccess(System.Threading.Tasks.Task)
StackTrace     :    at Microsoft.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
                    at Microsoft.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(Task task)
                    at Microsoft.Azure.Subscriptions.TenantOperationsExtensions.List(ITenantOperations operations)
                    at Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient.ListAccountTenants(AzureAccount
                 account, AzureEnvironment environment, SecureString password, ShowDialog promptBehavior)
                    at Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient.Login(AzureAccount account,
                 AzureEnvironment environment, String tenantId, String subscriptionId, String subscriptionName,
                 SecureString password)
                    at Microsoft.Azure.Commands.Profile.AddAzureRMAccountCommand.ProcessRecord()
                    at System.Management.Automation.Cmdlet.DoProcessRecord()
                    at System.Management.Automation.CommandProcessor.ProcessRecord()
HelpLink       :
Source         : Microsoft.Threading.Tasks
HResult        : -2146233088

It looks like my error is firewall related.
I'm unsure why the one command (Add-AzureRmAccount) encounters the error while the older version (Add-AzureAccount) does not.

5
  • need more detail from the errors. Post the output of this $error[0].exception | fl -f
    – Colyn1337
    Dec 24, 2015 at 14:43
  • is there a proxy/ firewall in between trying to read the encrypted traffic? I've seen all sorts of weird issues when companies "inspect" the secured traffic.
    – Jim B
    Dec 25, 2015 at 9:41
  • Most likely the difference between the cmdlets is that the new one is using a web based api.
    – Colyn1337
    Dec 28, 2015 at 13:09
  • @Colyn1337 Thx, found a solution now.
    – Reaces
    Dec 30, 2015 at 11:51
  • @JimB Apparently the proxy server when in the office is a different one to the one that is used when accessing through VPN. The difference in their configuration means I needed to connect differently.
    – Reaces
    Dec 30, 2015 at 11:52

1 Answer 1

1

Based on the comment made by Colyn1337 about the difference being likely a web based api.
And the authentication error being related to a proxy server not authenticating correctly.

A similar question on stackoverflow where a different, also web based api cmdlet, had a similar error, provided the solution.
As mentioned in the answer there I simply have to add the following code at the start of my scripts:

[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .