Share via

Problem running a Powershell script via Task Scheduler

Kaplan, Andrew H 226 Reputation points
2026-02-19T19:03:37.0333333+00:00

Hello.

I am running a PowerShell Script that is designed to poll the vCenter server of our vSphere clusters. The script sends the results to the intended recipient as and attachment, and also outputs to an htm file. To run the script PowerShell 7 is required, and the PowerCLi module.

The command syntax used when running the script is the following:

.\VMwareDailyReport.ps1 -VCServer <vCenter server FQDN> -SMTPServer <smtp server address> -FromAddress <email address> -toAddress <email address> -ReportExport C:\Temp\romdcvcenterreport

When the script is run interactively it works without issue. However, when it is set up in Task Scheduler, the output file is generated, but the email with attachment is not sent.

Windows for business | Windows Server | Networking | Other
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Domic Vo 23,805 Reputation points Independent Advisor
    2026-02-19T20:58:38.3533333+00:00

    Hello,

    The behavior you’re describing is a classic difference between interactive execution and scheduled execution in Task Scheduler. When you run the script manually in PowerShell 7, the environment has your user profile loaded, including credentials, module paths, and any implicit authentication context. When Task Scheduler runs it, the job runs in a different security context and often without the same environment variables, which is why the report file is generated but the SMTP send fails.

    The first thing to check is the account under which the scheduled task is running. If it is set to “Run whether user is logged on or not,” the task runs in a non‑interactive session that may not have access to stored credentials or the PowerShell 7 path. Ensure that the “Program/script” field points explicitly to the PowerShell 7 executable, for example:

    C:\Program Files\PowerShell\7\pwsh.exe

    and that the “Add arguments” field includes the full path to your script and parameters. If you are currently calling the script directly, Task Scheduler may be defaulting to Windows PowerShell 5.1, which does not handle the PowerCLI module the same way.

    Next, confirm that the SMTP send portion of the script does not rely on interactive authentication. If you are using Send-MailMessage or a similar cmdlet, credentials must be explicitly provided or the SMTP server must allow relay from the scheduled task’s account. In interactive mode, cached credentials may allow it to work, but in scheduled mode those are not available. You can test this by running the script with -Credential parameters or by configuring the SMTP server to accept the scheduled task account.

    Finally, check the Task Scheduler history and the script’s error output. Redirect the error stream to a log file so you can see whether the failure is due to authentication, module loading, or path resolution. A common issue is that the PowerCLI module is not loaded in the non‑interactive session. To fix this, add an explicit Import-Module VMware.PowerCLI at the start of the script and ensure $env:PSModulePath includes the PowerCLI install directory.

    In short, the file output works because it doesn’t depend on external authentication, but the email send fails because Task Scheduler is running in a different context without the same credentials or environment. Align the scheduled task to run under PowerShell 7 with explicit module imports and SMTP credentials, and the email portion should succeed.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day.

    Domic Vo.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

  2. AI answer

    2026-02-19T19:03:48.5633333+00:00

    When running a PowerShell script via Task Scheduler, there are several factors that could affect the execution, especially when it comes to sending emails. Here are some troubleshooting steps you can take:

    1. Check Task Scheduler Settings: Ensure that the task is set to run with the highest privileges. This can be done by selecting the option "Run with highest privileges" in the task properties.
    2. User Profile Loading: If the script is configured to run under a specific user account, ensure that the user profile is fully loaded. Sometimes, scripts that rely on user-specific settings may fail if the profile isn't loaded correctly. You can create a dummy process to run under the context of the desired user account shortly before the scheduled script starts to ensure the profile is loaded.
    3. SMTP Configuration: Verify that the SMTP server settings are correct and accessible from the context in which the task is running. The script might work interactively but fail in Task Scheduler due to permission issues or network access restrictions.
    4. Error Logging: Enable logging in your PowerShell script to capture any errors that occur when the script runs in Task Scheduler. This can help identify if the email sending process is failing due to an error in the script.
    5. Test the Script: Before scheduling, test the script directly in PowerShell to ensure it runs without issues. You can also simplify the script to isolate the email sending functionality and see if that works when run from Task Scheduler.
    6. Check Task History: Use the Task Scheduler's History tab to check for any errors or warnings related to the task execution. This can provide insights into what might be going wrong.

    By following these steps, you should be able to identify and resolve the issue with your PowerShell script not sending emails when run via Task Scheduler.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.