I'm trying to connect to a Azure Service Fabric cluster from an Azure Automation PowerShell Runbook. I know there's a Hybrid Runbook-approach that possibly can resolve this (c.f. this) but for reasons specific to the project I'm working on I would prefer not to use it.
Instead I have used the method described here to import the SF modules into my automation account. This makes the Connect-ServiceFabricCluster cmdlet available to me but when executed it fails to connect. I have set up a non-secure test cluster and this is the runbook code:
Import-Module "ServiceFabric" # not sure this is needed...
$connectionName = "AzureRunAsConnection"
# Get the connection "AzureRunAsConnection "
$servicePrincipalConnection=Get-AutomationConnection -Name $connectionName
"Logging in to Azure..."
Add-AzureRmAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
"Test connecting to cluster..."
Connect-ServiceFabricCluster -ConnectionEndpoint
'[myclusterendpointurl]:19000'
"Done!"
When run in the Test-pane (or run as a regular job, doesn't matter), three attempts to execute the script is done with this logged to the output each round:
Logging in to Azure...
Environments
------------
{[AzureChinaCloud, AzureChinaCloud], [AzureCloud, AzureCloud],
[AzureGermanCloud, AzureGermanCloud], [AzureUSGovernme...
Test connecting to cluster...
until it finishes with an error:
The runbook job was attempted 3 times, but it failed each time. Common
reasons that runbook jobs fail can be found here:
https://learn.microsoft.com/en-us/azure/automation/automation-troubleshooting-automation-errors
The Connect-method just seems to time out without logging anything to the output. What goes on here?
Related
In PowerShell you can do the following:
$result = Connect-AzAccount `
-SubscriptionId $SubscriptionId `
-TenantId $TenantId `
-Credential $credential `
-ContextName $contextName `
-Scope Process `
-ServicePrincipal
As per the doc, if you specify the -Scope Process the Az Context will be bound to that specific PS Process.
Determines the scope of context changes, for example, whether changes apply only to the current process, or to all sessions started by this user.
Is there any way of replicating this behaviour with az cli?
My use case
I will connect to Azure from a Jenkins job. If I start two jobs, maybe one of them will disconnect via az logout -u <user> and affect the other job.
I would like to isolate the az cli session.
I haven't personally used it yet, but according to this GitHub issue which links to this documentation, it should be possible using a process scoped environment variable.
Unfortunately, there is not such an equivalent feature as -Scope Process in Azure CLI, all the available parameters here.
https://learn.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az_login
I am trying to connect to azure cosmosdb from my local machine via powershell but every command I tried to run it returns the "Argument passed in is not serializable."
Here are a few of my commands,
Get-AzCosmosDBAccount -ResourceGroupName "cosmosbackup"
Invoke-AzCosmosDBSqlDatabaseThroughputMigration -ResourceGroupName "cosmosbackup" -AccountName "liabilitydata" -Name liability
New-AzCosmosDBSqlContainer -AccountName "liabilitydata"-DatabaseName "dailyliability"-ResourceGroupName "cosmosbackup"-Name schemes -PartitionKeyPath /Id -PartitionKeyKind Hash
Get-AzCosmosDBSqlContainer `
-ResourceGroupName "cosmosbackup" `
-AccountName "liabilitydata" `
-DatabaseName "dailyliability"
All of them fail for the same reason Argument passed in is not serializable.
Am I missing something? Please help
The issue here is that you need to set the context for running the script,
Step 1 : Connect with your Azure account
Connect-AzAccount
Step 2 : Pass the resource group and the cosmosdb account name as follows,
Get-AzCosmosDBAccount -ResourceGroupName cosmosbackup
I am following the MS guide located here and everything goes through correctly until I have to actually log in. The pop up window appears for my creds and validates them, but powershell doesn't seem to notice.
So it goes Install Module, Import Module, Verify Version, Log in. See below for what happens on the last two steps.
PS C:\WINDOWS\system32> Get-Module AzureRM -ListAvailable | Select-Object -Property Name,Version,Path
Name Version Path
---- ------- ----
AzureRM 6.3.0 C:\Program Files\WindowsPowerShell\Modules\AzureRM\6.3.0\AzureRM.psd1
PS C:\WINDOWS\system32> Connect-AzureRmAccount
Account :
SubscriptionName :
SubscriptionId :
TenantId :
Environment :
PS C:\WINDOWS\system32>
Of course, this prevents me from doing very much else with Azure from that point forward.
Edit: Issue appears on multiple workstations
I got this same issue. I have two users like many of you: the Azure user that is the "Work" account, and then the "Personal" account which is also created automatically by Office365 and Azure. I was getting the issue when I tried to use my "personal" account, in which I have some subscriptions added (delegated).
After trying lots, what worked for me was to login to the "Work" account when the "Connect-AzureRmAccount" command asks for an username/password. Then, I again use the command "Connect-AzureRMAccount", but this time I entered the personal account, and it finally worked.
Picture here
Edit: A better way I found later was this, as I manage a lot of subscriptions/tenants from a single account (delegated access):
Put the “tenantid” into a variable (you can get this ID on the Azure Portal, in my case, on the option to change directories):
How to get your tenant's IDs quickly
$tenantId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Login specifying the TenantId:
Login-AzureRmAccount -TenantId $tenantId
Example 2
This behavior happens when you run
Clear-AzureRMContext -Scope CurrentUser
I'm not sure why and im attempting to debug on how to fix the issue. A work around is to close the powershell window and reopen a new powershell windows that does not have this command ran.
Running the command
Enable-AzureRmContextAutosave -Scope CurrentUser
Fixed the issue for me. This will autosave your context for every powershell session. If this is not desired you can run the command
Enable-AzureRmContextAutosave -Scope Process
which will save the azure context for only the process. Otherwise you will need to handle
You can try this...
Install-Module PoweshellGet -Force
Set-ExecutionPolicy -ExicutionPolicy Remotesigned
Install-Module AzureRm
Import-Module -Name AzureRm
Login-AzureRmAccount
You can use the below link to install latest PowerShell version:
https://github.com/Azure/azure-powershell/releases
And then use something like this in order to automatically pass in the username password, and skipping the UI:
$azureAccountName ="enter username here"
$azurePassword = ConvertTo-SecureString "password here" -AsPlainText -Force
$psCred = New-Object System.Management.Automation.PSCredential($azureAccountName, $azurePassword)
Login-AzureRmAccount -Credential $psCred
Have you tried the following:
Import-Module Microsoft.Powershell.Security
$azureAccountName ="enter username here"
$azurePassword = ConvertTo-SecureString "password here" -AsPlainText -Force
$psCred = New-Object System.Management.Automation.PSCredential($azureAccountName, $azurePassword)
$decrypt = $psCred.GetNetworkCredential()
$ptpass = $decrypt.Password
Write-Output "Logging in to Azure using $azureAccountName with a password of $ptpass"
Login-AzureRmAccount -Credential $psCred
If you receive an error with this code, please comment with the entire error message.
The only thing i can think of is the below
You maybe using Azure Service Management (Azure V1 / Azure Classic) which uses a different module to Azure Resource Manager (ARM , Azure V2).
To install Azure Service Management Module:
Install-Module Azure -AllowClobber
Allowing clobber because you already have AzureRM Module installed
Import Azure Module to PowerShell:
Import-Module Azure
Logs into ASM:
Add-AzureAccount
Shows you all subscriptions
Get-AzureSubscriptions
Selects the Subscription you allocate to work within
Select-AzureSubscription
Answered something similar in the below Thread:
Login-AzureRmAccount return subscription but Get-AzureSubscription return empty
Hope this helps
You can try logging in using the Service Principal credentials.
Service principal is an application created under Active Directory to which you can apply permission rules.
$pscredential = Get-Credential
Connect-AzureRmAccount -ServicePrincipal -ApplicationId "http://my-app" -Credential $pscredential -TenantId $tenantid
Refer here for more details.
Using the new Azure portal, I am trying to add a powershell runbook that will start a specific VM. This is not something that will be run in powershell from my PC, it will instead run as an ARM job. I can't seem to find a way to successfully login.
If running from my desktop in powershell I can just call Login-AzureRmAccount and it will launch a login dialog before running any further steps. From what I've read on the web it seemed that what I needed to do was add a credential to my automation account, retrieve it and then call the same Login method. I've now done that, but still can't log in.
Import-Module AzureRM.Compute
$AutomationCredentialAssetName = "automation"
$Cred = Get-AutomationPSCredential -Name $AutomationCredentialAssetName
Write-Output $Cred
Login-AzureRmAccount -Credential $Cred
Start-AzureRmVm -Name 'myvmname' -ResourceGroupName 'myresourcegroupname'
The credential is being retrieved correctly (get's written to output) but the call to the Login-AzureRmAccount fails with:
Login-AzureRmAccount : unknown_user_type: Unknown User Type
At line:10 char:1
+ Login-AzureRmAccount -Credential $Cred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Add-AzureRmAccount], AadAuthenticationFailedException
+ FullyQualifiedErrorId : Microsoft.Azure.Common.Authentication.AadAuthenticationFailedException,Microsoft.Azure.Com
mands.Profile.AddAzureRMAccountCommand
If I don't attempt to log in first I get a message telling me to call Login-AzureRmAccount first.
How do I authenticate from within a runbook so that I can run automation tasks? What am I doing wrong?
We have subsequently discovered the the automation account created a connection when created that can be used to login:
$connectionName = "AzureRunAsConnection"
try
{
# Get the connection "AzureRunAsConnection "
$servicePrincipalConnection = Get-AutomationConnection -Name $connectionName
"Logging in to Azure..."
Add-AzureRmAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
}
catch {
if (!$servicePrincipalConnection)
{
$ErrorMessage = "Connection $connectionName not found."
throw $ErrorMessage
} else{
Write-Error -Message $_.Exception
throw $_.Exception
}
}
At a guess you are trying to log in with a Microsoft account, which can only be done interactively (as it needs to redirect through live.com). You will need to create a user within the tenant (Active Directory) that you are authenticating against in order for non-interactive login to work.
The easiest method to make this work is to create an account in the old portal (the new portal doesn't support Active Directory management yet) and then to add that user as a co-administrator in settings > administrators.
You can create a user through Powershell, and assign much more granular permissions, but while you're working your way around things it is probably easier to stay within the portal.
There is no significant difference between a user created through the old portal and one created via AzureRm commands.
I just encountered the same problem and while the information posted here was helpful it didn't solve the problem completely.
The key insight I needed was that in order to use Azure Cmdlets one has to configure a 'Run as Account'. (See https://learn.microsoft.com/en-us/azure/automation/automation-sec-configure-azure-runas-account)
It can be set up under Account Settings section of the azure automation account.
Once you have the 'Run as Account' you can use the method proposed by BlackSpy to log in. Namely:
# Get the connection
$servicePrincipalConnection = Get-AutomationConnection -Name AzureRunAsConnection
"Logging in to Azure..."
Add-AzureRmAccount `
-ServicePrincipal `
-TenantId $servicePrincipalConnection.TenantId `
-ApplicationId $servicePrincipalConnection.ApplicationId `
-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint
Hope this might help someone.
The official advice is to use a ServicePrincipal for automation - you can either use Secret or Certificate credentials with a service principal, and certificates work the best.
It is still possible to use a work or school account for automated login (Login with just -Credential), but this requires that your organization does not require two-factor authentication. It is unfortunately not possible to use a Microsoft Account for this - microsoft accounts require user interaction for any login.
I have a script scheduled in task scheduler and triggered at "System Startup".
The script does the following:
adds a remote machine to domain,
move it to specific organizational unit,
add it to group,
then add it to elastic load balancer
and restart the computer.
I want the instances launched by autoscaling to execute this script at system start up and get configured automatically as specified above.
This script executed on all test machines but the execution failed on instances launched by Auto Scaling. When i stopped the same machine and restarted it, the script executed.
Here is my script:
if ((gwmi win32_computersystem).partofdomain -eq $true) {
}
Else{
$name=gc env:computername
$secpasswd = ConvertTo-SecureString "Password" -AsPlainText -Force
$mycreds = New-Object System.Management.Automation.PSCredential("abc\user",$secpasswd)
Add-Computer -DomainName abc.com -OUPath "OU=POC,DC=abc,DC=com" -Credential $mycreds -force
add-adgroupmember -id POCGroup -members "CN=$name,OU=POC,DC=abc,DC=com" -Credential $mycreds
Set-AWSCredentials -AccessKey ************* -SecretKey ***************
$id=(New-Object System.Net.WebClient).DownloadString("http://169.254.169.254/latest/meta-data/instance-id")
Register-ELBInstanceWithLoadBalancer -LoadBalancerName "loadbalancer" -Instances "$id" | out-file elbInstance.txt
Restart-Computer
}
i don't think that there is anything to do with the script as it worked when i manually stopped and started the machine in AWS.
Please guide me. Am i missing something?
I searched but could not find anything similar to this.
Any help will be greatly appreciated.
Thanks in advance!
Given that you have specified that you are confident about the Script. The chances are the problem is with the AMI - while you create the AMI; you need to explicitly enable the "User Data Execution" - in EC2 Config Service.
Detailed information of how to do is here in this link - http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/UsingConfig_WinAMI.html