We are trying to execute a powershell script that will import a scheduled task to non domain and domain joined computers in our organization. The task is simply to disable wifi adapter when an ethernet cable is connected. I exported the task as a .xml and then can get the task to run as admin and complete successfully. However when we attempt to run logged in as normal user, the UAC box pops up asking for admin username and password. I created the task as both domain admin and local admin accounts and tried both, with same result when running the .bat as normal user.
This is my script so far (I have no previous experience in writing powershell):
Copy-Item -Path D:\WiFi -Destination C:\PCM\Utils -Recurse;
schtasks /create /tn "Ethernet On-Disable Wifi" /xml "C:\PCM\Utils\WiFi\Ethernet On-Disable Wifi.xml" /ru Domain\admin /rp domainpw;
schtasks /create /tn "Ethernet Off-Enable Wifi" /xml "C:\PCM\Utils\WiFi\Ethernet Off-Enable Wifi.xml" /ru Domain\admin /rp domainpw;
*
I'd like to be able to run this as %computername%\localadmin as that account is on all laptops...
The first line copies a folder with the .xml from a thumb drive to a folder on laptop. Then it creates the tasks. If I am logged into the laptop as admin, the batch runs fine, but as a local user, it fails with the following:
Error Image
Basically, it copies the folder fine, then ERROR: Access is denied.
I'm pretty sure its because the user logged in does not have rights to create the task. Is there a way to have the task run as localadmin and complete?
We run this .bat file to fire off the .ps1 from the folder that gets copied to laptop.
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& 'D:\WifiTask\WifiTask.ps1'"
pause
Sorry if the description of this issue is vague or confusing, just trying to learn as I go....thanks
No, a normal user will not be able to create a system scheduled task without getting prompted for elevation by UAC.
For domain computers, you could try:
Group policy to create the scheduled task
Group policy to run your script as the local system user
Script that connects to computers as Admin user and pushes your xml and wifitask.ps1 like Invoke-Command
Off-domain PCs are more difficult, you would want to do it the same way you currently install other software. Manually run as-admin? Software deployment agent? Remote management tools?
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 have a windows service that runs and manages multiple processes.
All the processes are running under the user account as per the task manager details tab. So one of the processes is executing a PowerShell script to do some operation that requires a local user account.
I tried logging $env:username, it says the PowerShell script is executed under the system account.
If I manually start the process without any help from the windows service then the PowerShell script executes successfully and also logs that the $env:username is locally logged in user account.
Note: the windows service is starting those processes using CreateProcessAsUser method which supposedly starts the child process under local user account. But somehow it seems that the task manager shows its running under user account but behind the scenes, it's running under the system account.
Can anyone tell me how I can execute the script under a local user account?
The cmd that I use to run the PowerShell script is
Powershell.exe -NoProfile -ExecutionPolicy Unrestricted -Command ../powershellscript.ps1
I'm attempting to run a Powershell script as the SYSTEM account as a scheduled task, and the task runs OK, but the script runs incorrectly because it does not load some Citrix Powershell snap-ins that are needed when run as SYSTEM, but runs OK as my user account.
The script does a check to load the Citrix snap-ins, but those do not appear to work when run as SYSTEM.
if ((Get-PSSnapin "Citrix.Common.Commands" -EA silentlycontinue) -eq $null) {
try { Add-PSSnapin Citrix.* -ErrorAction Stop }
catch { write-error "Error Citrix.* Powershell snapin"; Return }
Is there anything special I need to do to get those Snap-ins loaded correctly? I'm calling the script like this, if it matters: powershell.exe -executionpolicy bypass -file C:\path\to\script.ps1.
EDIT: From running (Get-PSSnapin -registered).count as both SYSTEM and my user account, I can see that the snap-ins are loaded correctly, but still can't figure out why the script behaves differently.
OS is Server 2016, version 1607, this is the script: https://gist.github.com/4oo4/85cec464e123d7f2793745e662d6e7ab
This isn't the answer why your specific script doesn't work under the SYSTEM account but explains how you might troubleshoot your (or any other) PowerShell Script under the SYSTEM account.
Give a man a fish, and you feed him for a day. Teach a man to fish,
and you feed him for a lifetime.
The whole thing around this, is that you can actually open a interactive PowerShell command prompt under the SYSTEM account were you probably not aware of.
Run PowerShell as SYSTEM
There are a few ways to start a interactive PowerShell command prompt but probably the easiest one is using PsExec.
Using PsExec
Download
PsTools
Extract PSTools.zip and just copy PsExec into your executable path
Run PowerShell as Administrator (accept the User AccountControl prompt)
In the PowerShell administrator window, give the command: .\PsExec -i -s -d PowerShell
A new PowerShell command window will open:
(Type WhoAmI to confirm the current account)
From here you can troubleshoot the specific script:
Are there any errors when running the specific script?
Does it hang or crash at a specific command?
Are there any differences with running it under a user account?
If it appears that the script runs actually fine in the SYSTEM window, then I would check for any errors in the Task Scheduler:
Select Task Scheduler Local - Task Scheduler Library in the left pane
Select your task in the middle top pane
(Make sure you have Display All Task History in the right pane Enabled)
In the middle bottom pane check the events in the history tab
According to documentation, get-scheduledjob only returns scheduled jobs where owner is the current user. Other scheduled job commandlets like set-scheduledjob also only work for scheduled jobs where owner is current user. This makes it impossible for non owners to get job status, modify the job (such as setting other credentials), etc.
In a proper IT organization, I'm going to say its crucial for these jobs to allow adminstration from various administrators.
Am I missing some way to administer, review results, etc (other than looking directly at the powershell output files in the owner's appdata)?
To clarify - I'm looking for a method to work with Powershell created and administered ScheduledJobs. If you modify the scheduled task that executes the scheduled job through the UI, schtask or other scheduled task specific tool, you'll get unexpected results. If you change owner/credentials, the scheduled task will fail. You can use UI/schtasks to change schedule without causing any problems. In addition to changing owner, I want to get at the results of get-job in order to monitor the jobs progress.
The only way I have ever been able to get this to work using Powershell was by invoking the schtask.exe utility:
Note: "/U" is for local administration and "/RU" is for remote administration, also "/S" is not needed with working locally.
Create by importing an XML previously exported from Task Scheduler
[string]$string = 'schtasks.exe /create /RU yourdomain\username /RP $password /TN Task-Name /XML "D:\Path\To\ExportedXML.xml" /S ServerName'
Delete:
[string]$string = 'schtasks.exe /delete /RU yourdomain\username /P $password /TN Task-Name /S ServerName /F'
Query:
[string]$string = 'schtasks.exe /query /RU yourdomain\username /P $password'
Run Locally:
Invoke-Expression -Command $string
Run Remotely:
Invoke-Command -ScriptBlock {$string}
I've written a few PowerShell scripts for managing scheduled tasks (they use the TaskService COM object):
Rename Scheduled Tasks in Windows 7, Windows Server 2008, and Windows Vista
How-To: Use PowerShell to Report on Scheduled Tasks
Updating a Scheduled Task's Credentials
Bill
I'm trying to put in place some monitoring for Windows Task Scheduler, I have a Powershell script that runs the following:
$serverName = hostname
$schedule = new-object -com("Schedule.Service")
$schedule.connect($serverName)
$tasks = $schedule.getfolder("\").gettasks(0)
$tasks |select name, lasttaskresult, lastruntime
This returns a list of scheduled tasks on the server it is run on, the last task result and last run time. The purpose for this is to return a dataset to our monitoring solution (Geneos) which we can use for alerting.
We have a large Win2008 estate, so I want the script centralised allowing any of the Geneos probes to call it and return a dataset for their host. To do this I wrapped the powershell in a .bat file which does the following:
\\fileserverhk\psexec.exe -accepteula -u admin -p "pwd" powershell.exe cpi \\fileserverhk\scripts\TaskSchedulerMonitor.ps1 -Destination C:\Monitor\TaskSchedulerMonitor.ps1
\\fileserverhk\psexec.exe -accepteula -u admin -p "pwd" powershell.exe -ExecutionPolicy Bypass -File C:\Monitor\TaskSchedulerMonitor.ps1
The First step copies the .ps1 file locally to get around Powershell not trusting UNC paths and the second part runs the script.
If I run the .bat file manually from a test server it executes fine (this is logged in under an admin account). However, when I fire the .bat file via Geneos (which runs under the SYSTEM account) I get:
Access is denied.
PsExec could not start powershell.exe:
So basically my question is, how do I get PsExec to switch user when it is run under the SYSTEM account? Even though PsExec has the credentials set for another account, there is obviously something preventing it from changing when run under system.
I read to try running it with the -h switch but I get the below error:
The handle is invalid.
Connecting to local system...
Starting PsExec service on local system...
Connecting with PsExec service on <server>...
Starting powershell.exe on <server>...
Error communicating with PsExec service on <server>:
In addition to the above error, I end up with the PSExec and powershell processes hung on the remote machine. The interesting part is I can see the PSExec and PSEXEC.SVC running under SYSTEM and the powershell running under admin, so it's almost there, but something isn't quite right there.
We managed to get there using a powershell wrapper on the Windows schtasks command (link here). Schtasks can be run under the SYSTEM account and will return all the necessary task information, so we no longer needed to faff about with permissions, and no more clear text passwords on the environment (bonus).
We wrapped:
schtasks.exe Query /FO CSV
in a powershell script, and used PS to format the output into the csv style expected by Geneos.