• Status: Solved
  • Priority: Low
  • Security: Public
  • Views: 53
  • Last Modified:

Trouble running a Powershell script from a scheduled task.

Hi Guys,
I'm hoping that someone can help with this Scheduled Task/Powershell issue I'm having as I'm a little stumpted.
First off, let me explain the current setup we have.
All our machine are currently attached to employer's Office 365 Azure Domain - as a result we don't have any way to apply GPOs and centrialize changes. Therefore if we want to make any changes we have to go around and make it on each machine. Currently I've written a small Powershell script that makes a couple of registry entries for us and that's been applied on each machine. However this means if we have to make a change to it, we need to replace that script with a different one on every box. So my line manager tasked me with writing a new script that would pull down a Powershell script from our file server, so we could update just that one and then have every machine pull that down and run it. Becuase we might not see these machines for some time, we agreed that the best method was getting this script to run as a scheduled task on log of any user.
The scheduled task is set to run as a local adminstrator account (have tried it using SYSTEM, but to no affect) and is triggered to run at any user logon; it's action is to start powershell.exe with the following arguement: -ExecutionPolicy Bypass c:\<folder>\<file>.ps1. Now I know this process works as I use the exact same method to run powershell scripts at the moment.

This script creates a temporary mapped drive and downloads a file from there; I know the script works, because if I run it from within Powershell ISE or just run it in explorer it runs and copies down the file, it just won't work when called by task scheduler.
When I initally created the script I had it map the drive using one of the DNS name of the fileserver it's pulling it from (it now uses both) and it used the local user's creadentials to map the drive, I've since modified the script to use both DNS names and to pull the user's credentials from the machine (just to be sure), but it still won't work as a scheduled task.
The task itself reports that it's run fine, so I'm guessing it's something to do with how Powershell interacts with Task Scheduler; is it somehow using the credentials for the task in Powershell?
I've attached a sanitized .txt version of the script for you to look at in case I've made an error there. Any advice/suggestions would be gratefully received.
Mark Taylor
Mark Taylor
  • 4
  • 3
1 Solution
The issues I see.
 - You create new PsDrives, but never use them.  You just call the direct UNC path in later commands.
 - In the last two commands, the wrong type of double-quotes are present.  They're the "pretty" ones that things like MS Word will use.  These commands will also use the credentials that the task is running with.

Before you use any path in a scheduled task (particularly if it is to a remote system), it's always best to test it (using Test-Path).  If is doesn't work, write a note out to a local log file so you can review.
Mark TaylorIT TechnicianAuthor Commented:
Thanks, I'll try those tweaks once I finished moving stuff into storage....
Odd that it does work when not as a scheduled task.
Were you using a different account than your own to run the scheduled task?
Account permissions are typically the issue when a script that accesses network resources is run as a scheduled task and doesn't work as expected.
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

Mark TaylorIT TechnicianAuthor Commented:
well I've reduced the script to this:

# copies target file, over writes version in c:\<folder> regardless
Copy-Item "\\<server>.<domain>.<loc>.<loc>\<share>$\<script>.ps1" -Destination C:\<folder>\ -force

# copies target file, over writes version in c:\<folder> regardless - alternate version in case drives are mapped to <server>.<azure>.net
Copy-Item "\\<server>.<azure>.net\<share>$\<script>.ps1" -Destination C:\<folder>\ -force

but it still won't download the file when run as a scheduled task, but will when you run the PowerShell script manually.
I think footech is right and it's something to do with the account.

The task runs using the credentials of the local admin account, which isn't on the domain where the file is downloaded from. I'm hoping that the script would use the credentials entered for drive mappings (that are on the same server) to authenticate with, but that might only be happening when the script is manually run.
I'm hoping that the script would use the credentials entered for drive mappings (that are on the same server) to authenticate with, but that might only be happening when the script is manually run.

From what I recall, your commands never make use of the drive mappings (I can't see now because it looks like you removed the attachment from your question).  If you create a new PSDrive (e.g. "newdrive"), then you have to reference it in the Copy-Item command for it to be used.  Just because you created it doesn't mean it will be used automatically.  Something like
Copy-Item "newdrive:\<script>.ps1" -Destination C:\<folder>\ -force

Open in new window

Mark TaylorIT TechnicianAuthor Commented:
ah. I'll try that then (when I get the chance) and let you know what happens.
Showed how to make actual use of the PsDrives created.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now