This is Intune related but could probably apply outside the scope of Intune as well.
I wrote a PowerShell script that downloads a folder from an Azure blob storage and extracts the content. Within the extracted folder is another PowerShell script that I want to run.
The PowerShell script is deployed in Intune and runs successfully all the way up to the point where the second PowerShell script runs. From the log, it's running into a permission issue.
Scripts deployed through Intune are ran as administrator/system and don't require any local policy change to allow the execution of PowerShell scripts on the device. However on the device, the user account is only a standard user so they don't have permissions to execute PowerShell scripts. In the first script, I've included the "Set-ExclusionPolicy Bypass" command already.
I need to be able to deploy the script from Intune to the local device and essential run another script as the local user (non administrator account). I thought maybe I needed the local user to be included in the local administrators group to be able to run the second script but that did not work either.
Also read somewhere that PowerShell can run PowerShell scripts from other PowerShell scripts directly. The only time you need Start-Process for that is when you want to run the called script with elevated privileges (which isn't necessary here, since your parent script is already running elevated).
^^^Is this my issue? My script does include "Start-Process" to run the next powershell script.
Script below for reference.
New-Item -Path "C:\IT Drivers" -ItemType Directory ;
Invoke-WebRequest - Uri 'https://xyz.zip' -OutFile "C:\xyz.zip" ;
Expand-Archive -Path "C:\xyz.zip" -DestinationPath "C:\";
Set-ExclusionPolicy Bypass ;
Start-Sleep -Seconds 30 ;
Start-Process powershell "C:\xyz.ps1"
Any guidance would be appreciated, thank you!
Related
I've created numerous scripts in PowerShell that are working as intended if I execute them directly, however, when I try and setup a schedule to run these in Task Scheduler (to run with highest privileges) it doesn't seem to be running anything at all.
I'm running the following in my actions:
powershell.exe -ExecutionPolicy Bypass -File C:\PS\Mailboxes\CheckForwardingList.ps1
I'm getting a "Last Run Result" of 0x0 and the particular purpose of the above script is to generate a TXT file from EXO which it then mails out via SMTP and I've yet to receive any emails and I also don't see any TXT being generated in the folder where the script is located.
I do have two additional scripts setup which aren't running but once I've addressed the issue on the above this should quickly rectify the problems.
I like to test my PowerShell scripts from a command prompt first.
For example a script called C:\Tests\Test-PowerShellScriptsRunning.ps1 that only contains the following one liner helps me to test if scripts can run successfully on a machine
Write-Host -ForegroundColor Yellow "If you see this, then your script is running"
Next, I run this script from a command prompt, to get the syntax right in my scheduled task:
powershell.exe -nologo -file c:\Tests\Test-PowerShellScriptsRunning.ps1
Of course, you can add the -Executionpolicy bypass parameter, but I prefer to test the execution policy first.
However, as you are running a script that connects to ExchangeOnline, I suspect it has to do with the user you are running this task under. Does the script run if you run this task under your credentials or are the credentials stored on the system or in the script?
You might want to check this article to see how you can register an app and authenticate without storing your credentials on the machine to run the script unattended: App-only authentication for unattended scripts in the EXO V2 module
I am experiencing below issue when I run the batch script as administrator. When I
ran the same script normally, there were no issues.
Please share some thoughts on this issue.
snapshot of the error
When you run as administrator, the user session changes from your user session to one based in %SystemRoot%\System32. What you need to do is get the path of the current invocation of your Powershell script and make it the path of your build1.ps1 script:
$ScriptPath = Split-Path $MyInvocation.InvocationName
& "$ScriptPath\build1.ps1" -Target prepare-qa
This way, regardless of user, the script is executed in the proper location.
When you open powershell as a user, the default directory is C:\Users\MyName.
When you open powershell as an admin, the default directory is C:\WINDOWS\System32.
In your script, try using Set-Location C:\Users\myusername or where ever your script is located. Or, fully qualify the script's path.
I am attempting to configure some powershell/view powercli scripts for our VMware horizon environment. I have a powershell script that works properly to query the horizon instance and check machine states. However, when I try to run this as a scheduled task using a service account, it seems to fail to import a module, as a command is unrecognized ("The term 'Connect-HVServer' is not recognized as the name of a cmdlet, function, script file, or operable program.")
I tried profiles as well, didn't matter.
What I observed is that if I open powershell as the user in question (run as different user > authenticate as service account), leaving that powershell instance open will allow the scheduled task to run as expected. However, if i close the powershell instance, the scheduled task fails. This is obviously not viable since the goal is for this script to run on a schedule without the service account (or any account) being logged into the windows server at the time the powershell script gets run.
The problem you're running into is environment variables. In the course of running as a user versus running as machine, the PSModulePath environment variable changes to include user-directories for user-scoped module installs. You should install PowerCLI machine-wide.
Alternatives (these assume your service account has admin privileges):
Modify your $Env:PSModulePath in the script to include each user's module path
Specify the path in an Import-Module statement in your script before you use any of the cmdlets
Example of the first alternative:
foreach ($user in (Get-ChildItem -Path C:\Users)) {
$Env:PSModulePath += ";$($user.FullName)\Documents\WindowsPowerShell\Modules"
}
Example of the second:
Import-Module -Name 'C:\Users\KnownUser\Documents\WindowsPowerShell\Modules\PowerCLI'
I want to have my batch file run a remote powerhell script.
I have Powershell \ip\Myscript.ps1
But it asks me for do i want to run this remote script.
I want to bypass this. with a -confirm:$false
How can i use that in a batch.
You got a few options here.
Copy the .ps1 file to a local directory and then call it via
Powershell. An ugly hack, but sometimes necessary if Execution Policy must not be changed.
Sign the .ps1 file. A huge pain in the backside.
Tell Powershell not to worry about Execytion Policy. The easy and dangerous way: powershell -executionpolicy unrestricted \\server\share\someScript.ps1.
I have an powershell script saved in a .cmd file that downloads a file from the web and then unzips it. My azure web role executes it upon startup. This is the script:
powershell -ExecutionPolicy Bypass -c $(New-Object Net.WebClient).DownloadFile('URL.zip', 'FILE.zip') ;
(New-Object -com shell.application).namespace('c:\FOLDER').Copyhere((New-Object -com shell.application).namespace('FILE.zip').items())
When I run the script via Azure startup tasks:
The first part of the script works. The file is downloaded. The second part of the script which unzips does not run.
When I run the script via the command line when remoted into the VM:
The entire script runs.
I therefore know this is not a syntax error. The only difference I can think of between the two cases above is a permissions issue. But, I am running powershell with -ExecutionPolicy set to Bypass, which is the highest permission level. Anybody have any ideas? Thanks!
Change the command so that the output of the command is dumped into a file. Something like this should work
<YOUR_COMMAND> > out.log 2> err.log
Run the task again and checkout the output in the logs.
Also, you are using relative paths rather than absolute ones. The scheduled task probably run with the windows system folder as its working directory, so you may be getting a permissions error from that. Try using an absolute path to a directory you created.