azure runbook get who executed the job - azure

I was working with azure runbooks in automation accounts for quite a while but recently I was tasked to identify who was executing the runbook.
I noticed that there is a fied called "Executed by" when you get information from a job, but seems that field is being removed by MSFT.
Checking the logs I can see the calls to the runbook but the job id stated in the log doesn't match the one in the jobid in the runbook inside the automation account.
I was wondering how can I match an execution on a runbook with a entry in the log.
any idea with powershell or by calling the REST API directly?
Thanks!

You can get the user who started the Automation job using the startedBy field returned in the Get-AzureRmAutomationJob and REST API.
This will require passing in the job id, which you can get using:
$PsPrivateMetadata.JobId.Guid

Related

Getting job owner from Databricks CLI

I'm trying to obtain the owner of a list of jobs on databricks using CLI. The issue is, the command databricks jobs list doesn't have any information related with that, any suggestions?
Thanks in advance!
You need to use Permissions API for that. Specifically the Get Job Permissions Levels API. Just do a GET request against endpoint https://<databricks-instance>/api/2.0/preview/permissions/jobs/{job_id}/permissionLevels - replace {job_id} with actual Job ID

Azure Automation: Run PowerShell after AD user added

I'm reviewing Azure Automation, but I couldn't find out if it is possible to run a PowerShell script whenever a new user is added to Active Directory? The scenario I'm researching is whenever a new Office365 account is added through admin.microsoft.com then I want to configure some email preferences for this user. I have my PowerShell script tested already (so these preferences should be set correctly), but now I'm trying to find out how exactly this script should be executed right after account is added.
Thanks,
You can inspect the Azure AD Audit logs for new user creation. You can export the Diagnostic Settings (logs) to Azure Monitor (see doc).
The following is an idea but I never tried it myself:
In Azure Monitor -> Logs you can find for example this query:
Modify it according to your needs and create an alert rule. In the alert rule, you can set up an action group that triggers your automation account with the PowerShell script.

Request timing out when exporting Azure resource group in powershell

I want to export an ARM template for a resource group in Windows Azure. I'm using the Azure Powershell module.
Whenever I try to export the resource group using Export-AzResourceGroup, the cmdlet fails with the following error:
Export-AzResourceGroup : Operation failed because a request timed out.
I have inspected the web traffic with Fiddler and I can see that the actual HTTP call to Azure is completing successfully, it's just taking a long time. So it's not a matter of e.g. extending the timeout on the ServicePointManager.
Is there any solution or work-around to stop this cmdlet timing out?
This issue maybe occurring due to a previous version of Az powershell module. Please update your Az module to the latest version and try again.
Also make sure you have the write permissions in the directory you are trying to create the json file.
Meanwhile, you can create the template from the portal just to check if the json file is getting created successfully:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/export-template-portal#export-template-from-a-resource-group

Automation account rerun, a jobshedule already exist

I have created a CD pipeline in Azure DevOps that will deploy an Azure Automation account and a runbook , shedule , jobshedule through ARM templates.
All working fine except when rerunning the template. My template is a part of a large deployment process that is still under construction so until the total scope is finished the ARM template that creates the runbook, shedule, jobshedule will rerun with every release.
The problem right now is the following: Whenever I rerun the template with a new release pipeline, I receive following error
A job schedule for the specified runbook and schedule already
exists.
At first I tried to be smart so added a GUI before the name of my jobshedule but the shedule itself attaches the runbook with the shedule and the deployment was smart enough to figure it out that the shedule was already connected to the runbook. Is there a way of making this still within the DevOps mindset / process so that I can rerun my templates with no problem.
The workaround solution I have created atm is to delete the shedule at every deployment but that seems like a very bad workaround.
Related feature request from UserVoice / feedback forum is here that's currently in triaged state.
Job Schedule id need to be unique for each deployment as per azure documentation.

VSTS Build Succeeded even ARM Template was invalid

Am working on Azure Resource Manager Templates(ARM Templates) and VSTS CI&CD. With the help of ARM Templates, I want to deploy AKS (Azure kubernete Service). So before going to deploy, I need to validate my ARM Template in the CI-Build by applying a PowerShell task. But here, at the time of validating my ARM Template “It’s not stopping CI-Build even when the validation fails”. Its giving output as “Validation Completed” as shown in the below picture . Is there any solution to resolve this issue, i.e. I wanted to stop my CI-Build running if any validation fails.
Not sure how does your powershell script look like. But according to the screenshot, the powershell script is executed successfully without any error code return. You can update your powershell script to check the validate result and set the exit code to "1" if the result is "InvalidTemplate". This will make the powershell task fail when the template is valid.
Looks like the resource is defined multiple times in the template. You can remove it and its always a good practice from the PowerShell script to use Test-AzureRmResourceGroupDeployment and validate if the template is valid and has obtained all its parameters and then deploy using New-AzureRmResourceGroupDeployment
Like Eddie said you can try this inside a try{} catch block and return an exception or an exit code to make the VSTS Build pipeline fail, if the script fails.

Resources