I want to get app insights of all the subscriptions available in the portal but whenever I run the script
$resources = az monitor app-insights component show | ConvertFrom-Json
I get app insights only for the same subscription every time , even during the time when I change the subscription through the script
Set-AzContext -SubscriptionName "some-name"
the whole script goes like this
Set-AzContext -SubscriptionName "some-name"
$resources = az monitor app-insights component show | ConvertFrom-Json
So even if I change the subscription name to something else suppose "some-name1"
still I am getting the app-insights for subscription "some-name"
This is by design.
While you could switch the context in a script, searches across multiple subscriptions are easier and much, much faster using the Resource Graph.
PowerShell Query:
Search-AzGraph -Query "resources | where type =~ 'Microsoft.Insights/components'"
Azure CLI Query:
az graph query -q "resources | where type =~ 'Microsoft.Insights/components'"
Both options should get you all Application Insights resources across your tenant.
For more details, please see the Starter Resource Graph query samples.
On a side note I would also recommend to stick to either Azure CLI or Az PowerShell. While the choice of language is personal preference, sticking to one of the two decreases the dependencies. If you stick to Azure CLI, the only prerequisite is having the Azure CLI binaries installed. If you stick to Az Modules in PowerShell, you don't need Azure CLI but only the Az Modules. Mixing both makes the code more difficult to port to other machines.
So, if using the Az Modules was preferred, instead of...
$resources = az monitor app-insights component show | ConvertFrom-Json
I would recommend:
$resources = Search-AzGraph -Query "resources | where type =~ 'Microsoft.Insights/components'"
The issue you're experiencing with the Set-AzContext command is that it only sets the subscription context for the current PowerShell session.
The az monitor app-insights component show command is running in a separate process or thread, so it is not able to see the updated subscription context set by the Set-AzContext command.
To work around this, you can pass the -Subscription parameter to the az monitor app-insights component show command, like so:
$resources = az monitor app-insights component show --subscription "some-name1" | ConvertFrom-Json
This will ensure that the az command is running with the correct subscription context, and you will get the app insights for the correct subscription.
Related
I've run into a snag with my powershell script that builds an azure function & all its dependencies.
This is what's happening: (i'm doing it manually here to demo...)
I request the storage account information like this:
PS C:\Users\me\> Get-AzStorageAccount -ResourceGroupName widget-resource-group
StorageAccountName ResourceGroupName PrimaryLocation SkuName Kind AccessTier CreationTime ProvisioningState EnableHttpsTrafficOnly LargeFileShares
------------------ ----------------- --------------- ------- ---- ---------- ------------ ----------------- ---------------------- ---------------
widgetx4ge6v27rlgdk widget-resource-group eastus Standard_LRS StorageV2 Hot 2022-03-10 2:00:26 PM Succeeded True
It comes back with the correct information. So then I try to get the connection string like this:
PS C:\Users\me> func azure storage fetch-connection-string widgetx4ge6v27rlgdk
Cannot find storage account with name widgetx4ge6v27rlgdk
But it says it can't find the storage account.
The actual code looks like this:
# Look up function app name that was dynamically created by ARM template:
$AZ_FUNCTION_APP = Get-AzFunctionApp -ResourceGroupName $currentEnv.AZ_RESOURCE_GROUP_NAME
#look up the storage account name for this resource group.
$AZ_STORAGE_ACCOUNT = Get-AzStorageAccount -ResourceGroupName $currentEnv.AZ_RESOURCE_GROUP_NAME
Write-Output $AZ_STORAGE_ACCOUNT.StorageAccountName
# Get new connection string for the storage account.
func azure storage fetch-connection-string $AZ_STORAGE_ACCOUNT.StorageAccountName
When the code runs, everything works until the call to "func azure storage fetch-connection-string".
Any tips on what I'm missing?
Edit 1
In case it helps, this logic works just fine when I run it against Tenant 1, Subscription A. But for Tenant 1, Subscription B it bombs.
I've made sure the service account principle it runs under is contributor on both subscriptions.
And for what it's worth, the script is able to create the resource group and many of the resources inside. It's just hat when I try to get the connection string, it bombs. It also bombs further down in the script when it tries to deploy the functions in my function app. The error message though is similar - it complains that it can't find the function app that I just finished creating.
Edit 2
So I figured out the problm but not sure how to fix it in a nice / simple way.
For 90% of the script, including login, i'm using the new Az Powershell modules. However, the "func azure" tool relies on login information provided by the az cli. (that seems to be cached??)
To get you on the same page, here's the relevant part of the code in the script:
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $AZ_DEPLOYMENT_CLIENT_ID, $Secure2
#Connect
Connect-AzAccount -ServicePrincipal -TenantId $AZ_TENANT_ID -Credential $Credential
#OPTIONAL - List the subscriptions available to the current User
Get-Azcontext -ListAvailable
#Set the subscription context to subscription 2
Set-Azcontext -Subscription $AZ_SUBSCRIPTION_ID -Tenant $AZ_TENANT_ID
#Create a new resource group
New-AzResourceGroup -Name $AZ_RESOURCE_GROUP_NAME -Location $AZ_RESOURCE_LOCATION -Force
New-AzResourceGroupDeployment -ResourceGroupName $AZ_RESOURCE_GROUP_NAME -TemplateFile (Join-Path $PSScriptRoot "./artifacts/widget-resources.json")
# Look up function app name that was dynamically created by ARM template:
$AZ_FUNCTION_APP = Get-AzFunctionApp -ResourceGroupName $AZ_RESOURCE_GROUP_NAME
#look up the storage account name for this resource group.
$AZ_STORAGE_ACCOUNT = Get-AzStorageAccount -ResourceGroupName $AZ_RESOURCE_GROUP_NAME
Write-Output $AZ_STORAGE_ACCOUNT.StorageAccountName
# this is where it is failing because it is using a subscription that is visible to az cli.
func azure storage fetch-connection-string $AZ_STORAGE_ACCOUNT.StorageAccountName
Here's what I did to troubleshoot from a powershell cli:
az account list
That returns this:
{
"cloudName": "AzureCloud",
"homeTenantId": "asdf-asdf-asdf-asdf-12312312313",
"id": "[guid]",
"isDefault": false,
"managedByTenants": [],
"name": "subscription-1",
"state": "Enabled",
"tenantId": "[our-tenant-id]",
"user": {
"name": "[another-guid]",
"type": "servicePrincipal"
}
}
When I ran the above command, it only returned one subscription called "subscription-1" for discussion purposes. It isn't/wasn't the one that the rest of the script was working with. The rest of script was dealing with subscription 2
As I test, I added the following lines of code just before call func azure storage:
az login --service-principal --username $AZ_APPLICATION_CLIENT_ID --password $AZ_SECRET --tenant $AZ_TENANT --allow-no-subscriptions
#set the subscription we want to use
az account set --subscription $subscription2
func azure storage fetch-connection-string $AZ_STORAGE_ACCOUNT.StorageAccountName
And now it finds the correct subscription and resource group / storage account. And now when I run az account list again, it shows me both subscriptions.
One addition comment / observation. Once the az login / az account set has been run with the desired subscription id, i've noticed that I can remove the az login and account set logic from the script and it just uses the cached values. I'm not saying this is what I want to do ... cuz I think it' best to be explicit. But just an observation which explains what bit me in the first place.
So my question is... is there anyway to avoid having to log in twice - once with az cli and another time with the Az Powerhsell modules?
I'm thinking of just abandoning the Az Powershell module and just rewriting everything in just az cli.
But asking the community to see if there's a better way to do this.
EDIT 3
Based on the docs for the azure core functions tools, technically I should be able to use the powershell modules or the cli:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-run-local?tabs=v4%2Cwindows%2Ccsharp%2Cportal%2Cbash#publish
"You must have the Azure CLI or Azure PowerShell installed locally to be able to publish to Azure from Core Tools."
Yes, using a mix of azcli and azure powershell, as they are their seperate entities in their own right, you would need to login to each of them individually.
And yes, you are right its better to ditch of them and choose one or the other ! Just much cleaner that way
The issue was that the azure core functions tool is using the cached az account list to find my resources.
So in other words, unbeknownst to me, the func method was using az cli, whereas the rest of the script is using the new Az Powershell modules.
For now, I've just rewritten everything in az cli syntax, and am happy with that. But per the docs it seems that the azure core functions tools should be able to work with either az cli or az powershell. Will open a separate question that addresses that point. For now, my script is working again.
If there any way can deploy the resources to different subscription from one centralized deployment console?
I'm planning create the resource monitoring dashboards in different subscription, as of now manually I'm importing the JSON configuration file into different subscription and changing the resource values.
Looking for the solution kind of centralized deployment.
You can do this using Azure Powershell or the Azure CLI. In order to change subscriptions, an Azure PowerShell Context object first needs to be retrieved with Get-AzSubscription and then the current context changed with Set-AzContext.
$context = Get-AzSubscription -SubscriptionId ...
Set-AzContext $context
For Azure CLI you can do:
az account set --subscription "My Demos"
CLI also lets you scope deployments to Subscriptions or Management Group. An example would be:
az deployment sub create --location <location> --template-file <path-to-template>
https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-cli
like to know all the sites in Azure that are currently associated to our Azure Tenant includes full URL,azure web apps,azure SQL,Storage accounts,Datalake,Cosmosdb,container registries
Tried Get-AzureADTenantDetail and also az resource list but not able find it
Any Powershell script will help
You can use
Azure CLI
az resource list
Powershell
Get-AzureRmResource
You can use Get-AzureRmResource to get the list of resources in an Azure Subscription. By default this Cmdlet will list all resources in an Azure Subscription. To get a list of certain resource types, you can specify an OData filter query.
For example, the Cmdlet below will list all storage accounts and webapps in an Azure Subscription:
Get-AzureRmResource -ODataQuery "ResourceType eq 'Microsoft.Storage/storageAccounts' or ResourceType eq 'Microsoft.Web/sites'" | ft
You will need to find the proper resource type values for each kind of resource that you want to find.
Another thing to notice is that this Cmdlet is scoped to a single Azure Subscription. If your Azure Tenant serves as authentication/authorization source for multiple subscriptions, you would need to run this Cmdlet for each subscription separately.
If you have multiple tenants, you can switch between tenants and get resources within them (subscription by subscription) via
connect-azaccount -Tenant [different tenant id]
$context = Get-AzSubscription [subscriptionid in different tenant id]
set-azcontext $context
get-azresource > resources.tenantname.subcription.txt
where tenantname and subscription are the names of the tenant and subscription in english form (instead of id's).
you should probably not use those azurerm commands anymore, they will stop working sometime in 2024. use the az equivalents (basically replace azurerm with az (yeah, i could delete urerm but that seems weirder!))
I am trying the available Microsoft gallery script [https://gallery.technet.microsoft.com/scriptcenter/Export-Azure-Resource-092b9c2a#content] but it's running on subscription level and it's hanging in the middle. Looking for the solution from PowerShell or Microsoft Graph API to pull the required RBAC roles from Subscription, resource groups and each resource level.
Because the command in the script lists all role assignments in the selected Azure subscription by default. You just need to use the parameters e.g.-ResourceGroupName, -Scope in the command, then you will be able to do what you want.
Besides, in your script, it uses old AzureRm command Get-AzureRmRoleAssignment, it was deprecated. I recommend you to use Get-AzRoleAssignment.
For more details, see this link: Get-AzRoleAssignment.
to achieve that you just need to use Get-AzRoleAssignment together with a filter:
Get-AzRoleAssignment | Where-Object { $_.Scope -match 'resource_group_name' }
I wanted to stop web jobs with a certain name that are currently running on all apps in an app plan in Azure. I prefer PowerShell, but Azure PS module is lacking compared to az cli, so I ended up with the following, which feels really clunky:
Get-AzWebApp
|
where ServerFarmId -EQ '$appPlanId'
|
select Name, ResourceGroup
|
% {az webapp webjob continuous list --name $_.Name --resource-group $_.ResourceGroup --query '[].{Id:id}' | ConvertFrom-Json}
|
% {az webapp webjob continuous stop --webjob-name $webjobName --ids "$($_.Id)"}
I'd appreciate advice on better approaches.
As I known, you can use two APIs below of WebJobs API for Continuous Jobs to realize your needs in PowerShell.
List all continuous jobs
Stop a continuous job
For how to call these APIs above, you can refer to the Sample of using REST API with PowerShell.
Meanwhile, please see the document Deployment credentials to know how to use the credentials in the REST calling. And you can refer to my answer for a similar SO thread Unable to access admin URL of Azure Functions to know how to get the credential parameters.