After migrating scheduled tasks from an old Windows Server 2008 cluster to a new one (also Server 2008 non-R2), we noticed the Task Scheduler attempts to launch each task three times simultaneously. This occurs regardless of whether we configure the task to queue new instances (Event ID 324) or stop existing ones (Event ID 323).

• Tasks configured with "Stop existing instance" still spawn multiple processes
• Identical tasks work correctly on other clusters
• Behavior persists when moving tasks between nodes in the new cluster

Current Task Settings:
- Allow task to be run on demand
- Run if missed scheduled start
- Stop after 1 hour runtime
- Force stop if needed
- AC power requirement
- Stop on battery power
- Conflict resolution: Stop existing instance

First, check for hidden duplicate triggers that might not be visible in the GUI:

schtasks /query /tn "\Client Reporting" /v /fo list

Then examine the actual task definition XML:

schtasks /query /tn "\Client Reporting" /xml > task.xml
notepad task.xml

The issue might stem from how the cluster handles task synchronization. Check these registry values:

reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration

Create a wrapper script to enforce single instance execution:

@echo off
setlocal
set lockfile=C:\temp\reporting.lock

if exist "%lockfile%" (
    echo Task already running >> C:\logs\reporting.log
    exit /b 1
)

echo %date% %time% > "%lockfile%"

REM Main task logic here
call reporting_main.bat

del "%lockfile%"

• Recreate tasks from scratch instead of migrating
• Update to Server 2008 R2 or newer
• Implement custom mutex in task scripts

Add this PowerShell snippet to log task execution attempts:

$logPath = "C:\logs\taskscheduler.log"
$taskName = "Client Reporting"
$now = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

if (-not (Test-Path $logPath)) {
    New-Item $logPath -ItemType File
}

Add-Content -Path $logPath -Value "$now - Attempt to start $taskName"

---

After migrating scheduled tasks from an old Server 2008 cluster to a new one (non-R2), we're encountering a peculiar issue where the Task Scheduler attempts to launch three instances of each task simultaneously. The system generates either Event ID 324 (queuing) or 323 (stopping existing instance) depending on the conflict resolution setting.

The affected tasks share these common settings:

• Allow task to be run on demand
• Run task as soon as possible after a missed schedule
• 1-hour execution time limit
• Force stop if unresponsive
• AC power requirement
• Trigger: Daily, hourly execution
• Action: Executes a .bat file

Several factors could contribute to this behavior:

1. Cluster resource arbitration issues
2. Task definition corruption during migration
3. System time synchronization problems
4. Permission inheritance discrepancies
5. Hidden duplicate triggers

First, export the task definition for inspection:

schtasks /query /tn "\Client Reporting" /xml > task_definition.xml

Then check for hidden triggers using PowerShell:

$task = Get-ScheduledTask -TaskName "Client Reporting"
$task.Triggers | Format-List *

Create a wrapper script to enforce single instance execution:

@echo off
setlocal
set lockfile=C:\temp\task_%TASKNAME%.lock

if exist "%lockfile%" (
    echo Task already running >> C:\temp\task_log.txt
    exit /b 1
)

echo %DATE% %TIME% > "%lockfile%"

REM Your original batch commands here

del "%lockfile%"

Verify these registry values match across cluster nodes:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Schedule

When tasks fail over between nodes, residual states might cause multiple launches. Implement this cluster-aware check in your batch file:

for /f "tokens=2 delims=:" %%a in ('hostname') do set NODE=%%a
if not "%NODE%"=="ExpectedNodeName" (
    echo Wrong cluster node >> C:\temp\node_check.log
    exit /b 1
)

For more robust control, consider rewriting the task as a PowerShell script with proper mutex handling:

$mutex = New-Object System.Threading.Mutex($false, "ClientReportingTask")
if(-not $mutex.WaitOne(1000)){
    Write-Output "Another instance is running"
    exit 1
}

try {
    # Task implementation here
}
finally {
    $mutex.ReleaseMutex()
}

After implementing fixes, monitor with:

schtasks /query /tn "\Client Reporting" /v /fo list
Get-WinEvent -LogName Microsoft-Windows-TaskScheduler/Operational -MaxEvents 50