Use a reviewed script with explicit input and output paths, meaningful error handling and a useful exit code. Store it in a protected directory that untrusted website users cannot modify. Give the task identity read access to the script and only the required access to its data and log destinations.

Select the intended PowerShell version. Windows PowerShell and a separately installed PowerShell 7 executable can load different modules, so record the actual executable path used during testing.

1. Open Task Scheduler and choose Create Task. Name the task clearly and record its purpose.
2. On General, choose the intended account and whether the task must run without an interactive sign-in. Confirm the required batch-logon right and any centrally applied restrictions.
3. Leave elevated privileges unselected unless the script's specific actions require them. Do not use SYSTEM merely to avoid investigating a missing file permission.
4. Create the required trigger and confirm its schedule and timezone assumptions.
5. On Actions, choose Start a program. Use the full path to the approved PowerShell executable.
6. Set arguments such as -NoProfile -NonInteractive -File "C:\Ops\Scripts\Check-Website.ps1", replacing the example with the reviewed script. Set Start in to its intended working directory.
7. Review conditions, maximum runtime, retry behaviour and what happens if another instance is already running. Avoid overlapping writes or repeated customer notifications.
8. Save using the supported credential prompt when required, run a controlled test and inspect both task history and the script's own log.

Check the result while the task account is not signed in. Use explicit network paths and the account's real network permissions rather than depending on a drive mapping from your desktop session. Preserve credentials through the approved secret mechanism, not command-line arguments.

In an authorised PowerShell session on the Windows Server, inspect the task you created. Replace the task name and folder with the actual values. These commands read the scheduled task; they do not launch its script or change its run-as identity.

Get-ScheduledTask -TaskName 'ExampleMaintenance' -TaskPath '\Nabtech\' |
  Select-Object TaskName, State, Actions, Principal, Triggers
Get-ScheduledTaskInfo -TaskName 'ExampleMaintenance' -TaskPath '\Nabtech\'

Read the result: Compare the executable, arguments, principal and last-run time with the intended design. LastTaskResult needs interpretation as the task's reported result, while the application's own output establishes whether the business operation succeeded. A task that never ran needs its trigger and conditions checked separately.

Keep script logs outside public website directories and avoid storing passwords in task arguments. Verify the account can read the script and access only required resources. Do not elevate the task to a powerful account merely to bypass a missing path or network credential.

• Configuring recovery for a Windows service
• Investigating a Windows service failure with Event Viewer
• Verifying Windows Server time synchronization
• Assign one billing owner to each recurring hosting service

• Microsoft: security contexts for scheduled tasks
• Microsoft: scheduled task actions

• Microsoft: scheduled task run information