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:
- Install PowerShell – Instructions for Windows, Linux, and macOS
- PowerShell Galley Your one-stop shop community and Microsoft modules.
- PowerShell Repository – View the PowerShell source code, report issues, or contribute to the project yourself.
- PowerShell Community Call – Hear from and talk directly to the product team on the 3rd Thursday of every month
- PowerShell in Visual Studio Code – It’s time to say goodbye to ISE
Rules:
- Be civil (aka don’t be a jerk). Remember there are people from all walks of life, all with different levels of expertise. You can disagree with someone, but please be civil when doing so.
- Adhere to the Lemmy Code of Conduct
- Follow all programming.dev rules
- Posts must relate to PowerShell or the PowerShell ecosystem.
- Use code blocks to make things easier to read.
- Memes and humorous posts are allowed but try not over do it. And keep them relevant to PowerShell
- No discussion about piracy or hacking.
- If someone provides an answer that solves your problem, please reply, so others know what the solution was. ^And^ ^so^ ^the^ ^person^ ^who^ ^suggested^ ^it^ ^gets^ ^that^ ^oh^ ^so^ ^sweet^ ^shot^ ^of^ ^dopamine.^
- If you find a solution to your problem by other means, please take your time to write down the steps you used to solve your problem in the original post. You can potentially help others having the same problem!
Self-promotion rules:
- Self-promotion content must be marked as [OC]
- Do not SPAM. Content must be PowerShell related.
- Only 10% of your contributions can be self-promotion. In other words, 90% of your contribution must not be self-promotion.
- Personal blogs are not considered self-promotion, at this time, as long as they are free to access and relevant. Please do not abuse this.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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:
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!
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.