Upload Automox agent logfile to Azure Storage Container
So i was looking for a quick way to retrieve a log file of an automox enabled system without physical or netwerk access. It had to be lean mean and fast so i came up with this solution to upload the logfile to a azure blob storage container using a sas-token.
only fill out the url variable before the slash and sas token variable and you are good to go!
Evaluation code
exit 1
Remediation Code
if ($PSVersionTable.PSVersion -eq "2.0")
{
Write-Output "This worklet requires PowerShell version 3.0 or higher!"
exit 0
}
else {
$Policy = "RemoteSigned"
If ((Get-ExecutionPolicy) -ne $Policy) {
Set-ExecutionPolicy $Policy -Force
Write-Output "Changed execution policy to 'RemoteSigned'. "}
i know this is my own worklet but can I pick the brains of the community. On some host the worklet does not run properly and results in failed upload. When I manually run the script on the machine it works like a charm but only as worklet it does not work, what is the best way to troubleshoot this?
Typically when something runs manually but not through a worklet it’s because the worklet runs as System whereas when you are running it manually it’s running as the currently logged in user (you). That means that some environment variables might not exist when running as System, so that’s one place to start. You can try hardcoding any of those in a test worklet for the machines that aren’t working, just to isolate that as the possible cause.
Another way to see where a worklet is failing is to send more info to Write-Output for troubleshooting and tracing, such as verifying that variables exist and are set to the value you expect. We’re planning to integrate some of that into the worklet environment, but in the meantime you can do manual trace output commands.
I feel a bit stupid but not the best scripter out there, what would be the best way to approach this? What can I add to the worklet to get that?
Agreed that this is likely an issue with NT Authority\SYSTEM but more likely for permissions to the network share/cloud container.
Since most of the time, you’ll be provisioning access to a user account, not a device account–the system account will not be able to access the network resources that you can when you run it yourself.
For instance, where you reference $env:computername - you could hard code that to the name of the machine you are having issues with, or you could add:
Write-Output $env:computername
to the remediation script to see what shows up in the Details field after you run the worklet, to make sure that variable exists and has the value you expect.
That’s a very good point - I didn’t think about permissions when logged in as System vs user.
I’m using a SAS token so that is not user or machine bound 🙂 will try the other tips. Will running the script as a scheduled task as system have the same outcome for troubleshooting purposes? Also, the experience seems inconsistent so far, some machine work like a charm others don’t
If a device has never run IE under any user profile, Invoke-RestMethod or Invoke-WebRequest will usually fail its connection. Try using the “-UseBasicParsing” switch to allow your request to work without configuring IE. Quick note, this switch is used as default in PowerShell 6.0 and higher, but remains for backwards compatibility in previous versions.
Here is a generic example to see if it helps:
Invoke-RestMethod -UseBasicParsing -Uri $uri -Method Put -Headers $headers -InFile $file
I found the issue it was caused by execution policy on the machine that prevented the script from running. after changing this it worked like a charm 🙂 embedded a check and change in the script to check the policy and change it if needed to remotesigned and write this back to the activity report.
