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

Powershell

1023 readers
2 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
[–] [email protected] 3 points 1 year ago (1 children)

Still no responses? That's kinda scary...

I know this place is very FOSS-heavy, but as another guy that's basically balls deep with Microsoft (I may have that around the wrong way) I'm surprised.

Then again debugging is ...complex - I can't understand why you'd want an automation layer around it

[–] gregt8 2 points 1 year ago (1 children)

My challenge is that I'm used to developing scripts locally with an account that has privileged access. The development time w/ debugging is fast, as the account has immediate access. With Azure Automation, I have to wait for a cloud job to complete, and sometimes this takes a minute or two. That's too long for me to execute and wait for the results.

I would rather develop locally using a privileged account and then push to Azure Automation when I'm confident that my script logic is executing as expected.

I think I found a way around the issue. In my script logic I can test for the PowerShell profile path. In Azure Automation, the profile path references 'ContainerUser'. When running locally my profile path references my local directory. If the profile path references ContainerUser then I can specify to use the user-managed identity; otherwise, I'll use my interactive credentials, e.g. a PowerShell session that I have previously established locally with Exchange Online.

[–] [email protected] 0 points 1 year ago

Doesn't sound like a way around the issue, sounds like that was the issue.