Carl Webster Accessibility Statement

Carl Webster is committed to facilitating the accessibility and usability of its website,, for everyone. Carl Webster aims to comply with all applicable standards, including the World Wide Web Consortium’s Web Content Accessibility Guidelines 2.0 up to Level AA (WCAG 2.0 AA). Carl Webster is proud of the efforts that we have completed and that are in-progress to ensure that our website is accessible to everyone.

If you experience any difficulty in accessing any part of this website, please feel free to email us at and we will work with you to provide the information or service you seek through an alternate communication method that is accessible for you consistent with applicable law (for example, through telephone support).

  • Running PowerShell Scripts As a Scheduled Task

    February 27, 2018


    Probably the second most frequently asked question I receive about the various scripts is how to run a script as a scheduled task. I asked my most thorough script tester to document how he accomplished this task so a “regular” person could explain the process. This article is about how he accomplishes this task using his words and screenshots.

    David McSpadden works for a financial institution and uses almost every documentation script available on this site. When he tests a script, he tests every output option and just about every possible combination of parameters. David emails me a copy of every report he runs for every script he tests. Currently, I have over 1,000 sample reports from David.

    OK, on to the process David uses to run the Active Directory Health Check script as a scheduled task. The only things I have changed from the email David sent me is blacking out his employer’s name and letting Grammarly do its thing.

    Note: In David’s text, CW is me and MS is my PowerShell mentor Michael B. Smith.

    Ok, First off you must have the PowerShell working first. Get all bugs worked out so you can manually execute the ps1 a million times with no errors.

    To do this, I have created a scripting environment.  C:\tmp\Scripts

    In this example, I will show the AD Health Schedule.

    Create a batch or dos command script in the c:\tmp\Scripts\AD_Health_Check folder called for lack of a better name pc-adHealth.bat.

    Figure 1
    Figure 1

    This bat file will be used in the scheduled task later.

    The bat file is simple and only has the following reference in it:

    echo on
    powershell.exe -NoLogo -File "c:\tmp\scripts\AD_Health_Check\ad health check v2 parms.ps1"

    You can see this is calling Webster’s admin script.

    The reference PowerShell is as follows:

    (I have tested 1 million times to make sure it is still working.)

    cd c:\tmp\scripts\"AD_Health_Check"\
    .\"ADHealthCheck_v2.ps1" -CP "Sideline" -CN "David's Employer" -UN "David McSpadden" -All -Log -CSV -Mgmt -Folder \\localhost\c$\tmp\scripts\"AD_Health_Check"\foldertest -PDF

    This PowerShell script puts a copy of the PDF output in a static location. I have a script that runs on my SharePoint the goes around and picks up all these admin script outputs and places them in the correct location on the SharePoint server for all the admins to reference.

    Now to schedule this, I am only scheduling the bat file we created previously, and I am running the task under my user profile.

    Trying to run it under admin remotely did not place nice with me so after much reflection and a big thick bat from MS and CW I went with my user profile.  (Also a KB article I cannot find again. But MS and CW reviewed it as well.)

    Figure 2
    Figure 2
    Figure 3
    Figure 3
    Figure 4
    Figure 4
    Figure 5
    Figure 5
    Figure 6
    Figure 6

    I am running these once a week and they haven’t failed yet.

    **side note

    For that matter, can now use my Enterprise Scheduling software SMA Opcon by executing “c:\tmp\scripts\AD_Health_Check\ps-adhealth.bat” as [David’s AD Account] in the context of the Windows machine where the .bat file is hosted.  (SMA has a hook on the machine that allowed running in the context of a signed-on user.)

    [end of David’s email]

    If you have another method for running any of the scripts as a scheduled task, send me an email of how you handle the process and I will add it to this article.


    Webster and David

    About Carl Webster

    Webster is a Sr. Solutions Architect for Choice Solutions, LLC and specializes in Citrix, Active Directory and Technical Documentation. Webster has been working with Citrix products for many years starting with Multi-User OS/2 in 1990.

    View all posts by Carl Webster

    5 Responses to “Running PowerShell Scripts As a Scheduled Task”

    1. René Says:


      is there a way to make a shedule task with the taskoption “Run whether user is logged on or not”?
      I have big problems with the “PVS_Inventory_V5_Signed.ps1”-Script. If i open an powershell with the serviceAccount, the script passed sucessfully. if i try to use the shedule task, the task never ends and i dont see any error. Only the word process is running the hole time.




      • Carl Webster Says:

        From Guy Leech:

        It depends on what account you have set the scheduled task to run as. My daily checks script which uses the PVS cmdlets works fine when set to “Run whether user is logged on or not”. That script uses Set-PvsConnection which can take credentials if necessary but hopefully the account you are running the scheduled task as has PVS rights.

        If scripts like this run but never finish it suggests to me that they are prompting for authentication but as they are running lights out, that authentication prompt never shows and thus never happens – I’ve seen it with Connect-VIServer with PowerCLI.




    2. Guy Leech Says:

      I use “bypass” in my scheduled task command line because the scope of that is just this invocation and I trust my own scripts (generally!). The unfortunate problem with PowerShell execution policies is that they are relatively easily circumvented. They can be useful to stop accidental execution of a potentially malicious script by a normal user but once you’ve got admin rights execution policies can easily be bypassed.

      When I’m setting up XenApp servers, I’ll generally set the policy to Restricted or AllSigned but for the latter you’ll need your own code signing certificate to sign any script you want to run.

      I wouldn’t sweat over it – for a non-admin user, unless you’ve got weak permissions or aren’t patched, what’s the worst that can happen? For admin users, as I’ve already said, execution policies are all to easy to circumvent.


    3. Rob Ingenthron Says:

      Thanks for the post! You didn’t mention anything about the PowerShell execution settings or signing. I don’t think that you can just run these scripts as scheduled tasks without addressing the execution policy, and that’s an area I don’t fully comprehend. (Everyone here just sets everything to either “bypass” or “unrestricted”.) I just saw your second post on this topic but it just has “bypass”. I hope you can add another post to discuss running these tasks more securely with PowerShell. (Is bypass the best option?)

      BTW, I ran across another site that has an interesting post regarding bypassing the execution policy:


      • Carl Webster Says:

        You can always run the Signed versions of the scripts. That way, there is nothing to bypass.



    Leave a Reply