this post was submitted on 04 Sep 2023
16 points (94.4% liked)

Powershell

1023 readers
1 users here now

PowerShell (POSH) is a a task automation command-line shell and scripting language created by Microsoft. It became part of the FOSS community in 2016 and is now available across Windows, Linux, and macOS

Resources:


Rules:

Self-promotion rules:


founded 1 year ago
MODERATORS
 

I've always developed and ran scripts locally through VS Code. I'm just getting started with Azure Automation and am not a fan of waiting for the job to complete before seeing my results. In fact, it's very frustrating. I'd rather develop and test my script locally first before running it in Azure Automation.

I'm using a user-managed identity to run scripts against Exchange Online. VS Code has an Azure Automation plugin that provides an option to run script locally, but the script bombs out when attempting to use the user-managed identity, as the user-managed identity may only be run in Azure.

For those of you who use Azure Automation, I can't imagine that you develop significant portions of the script and wait for automation jobs to complete each time to verify changes.

How do you develop locally? Do you use an app registration w/ client secret in key vault and call that from your local machine? Do you have a process for developing locally for scripts that specify managed identities?

Thanks everyone!

you are viewing a single comment's thread
view the rest of the comments
[–] pwshguy 2 points 1 year ago (1 children)

Typically, when I have a script I need to test locally, I’ll comment out the identity connection command and just authenticate outside of my script. If I’m feeling real fancy, I’ll write a try/catch to attempt to authenticate first as the managed identity then if it fails prompt me for credentials. Not the most elegant solution, but it works.

try {
    Add-AzAccount -Identity -SubscriptionId $SubscriptionId -ErrorAction Stop | Out-Null
}    
catch {
    Add-AzAccount -SubscriptionId $SubscriptionId
}
[–] gregt8 3 points 1 year ago (1 children)

Makes sense. I found an environment variable that detects whether the process is running in Azure Automation, i.e. it's running in Azure Automation if the variable is defined:

Get-ChildItem -Path env:AZUREPS_HOST_ENVIRONMENT

This helped me provide some conditional control on when to use the managed identity and when to use my interactive credentials.

All the while I'm figuring out that using the Azure Automation plugin with VS Code is only useful for publishing code in runbooks; the extension doesn't provide an easy way to manage custom modules. And with the code I'm writing, I'm quickly finding that it won't be efficient to include everything in runbook files. So I'm now heading down the path of using a pipeline to publish my custom module to Azure Automation, then calling that module with a lightweight runbook.

Appreciate the guidance!

[–] pwshguy 2 points 1 year ago

Just a heads up, I received confirmation from the product team that the AZUREPS_HOST_ENVIRONMENT environment variable is going away. They are moving the backend to containers. Also, the COMPUTERNAME one that was always "client" is going to change too. The COMPUTERNAME will now be "Sandbox-###" with # being random numbers. I started using the code block below in my runbooks to find if they are running in Azure or hybrid worker/locally. It accounts for the current and the updates that will be rolling out in the near future.

$isHybridWorker = $true
if (($env:computername) -eq "CLIENT") {
    $isHybridWorker = $false
}
elseif ($env:USERNAME -eq 'ContainerAdministrator') {
    $isHybridWorker = $false
}
``