Server 2k8 R2/Windows 7：GPO推送计划任务失效，本地创建可正常执行

Hey there, let's work through why your GPO-deployed scheduled task isn't running that EXE silently—even with domain admin rights. Those event IDs you shared give us a good starting point, so let's break this down step by step.

First, let's parse those logs:

• Event ID 200 confirms the task successfully launched a PowerShell instance for your Install Package task.
• Event ID 129 logs the process ID, so we know the PowerShell process started.
• Event ID 201 is "Task completed"—but if the EXE didn't actually run, the issue is almost certainly in how PowerShell is calling the EXE, not that the task didn't trigger.

Here are the most common pitfalls and fixes to check:

1. PowerShell Execution Policy Blocking the Run #

Even domain admins hit this: client machines often have a default Restricted execution policy that blocks script/command execution. Bypass this temporarily in your task's PowerShell arguments by adding -ExecutionPolicy Bypass. For example:

powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -Command "& 'C:\Full\Path\To\Your.exe' /quiet"

2. Incorrect Silent Install Parameters for the EXE #

Not every EXE uses /quiet or /silent—you need to use the official silent parameters for your specific application:

• MSI installers typically use /qn for fully silent, no UI.
• Some EXEs use custom flags like /verysilent or /install /silent.
  If you use the wrong flag, the EXE might try to pop up a UI, which gets stuck in the background since the task is running hidden—making it look like nothing happened.

3. Missing Absolute Paths #

When scheduled tasks run under admin/system context, their default working directory is C:\Windows\System32, not your deployment folder. Always use full absolute paths for both PowerShell commands and the target EXE. Never rely on relative paths here.

4. UAC Context Limitations #

Even with a domain admin account, if you don't enable Run with highest privileges in the task settings, UAC will strip elevated rights by default. This can block the EXE from making system changes, writing to protected folders, etc. Double-check this box in the task's "General" tab.

Quick Troubleshooting Steps to Validate #

• Disable silent mode temporarily: Remove -WindowStyle Hidden and add -NoExit to your PowerShell arguments. Manually trigger the task—this will keep the PowerShell window open so you can see any error messages (like missing files, permission errors).
• Test the command manually: Copy the exact PowerShell command from your task, run it in a domain admin PowerShell window on the client. If it fails here, the problem isn't the GPO or task scheduler—it's the command itself.
• Check PowerShell Operational Logs: In Event Viewer, go to Applications and Services Logs > Microsoft > Windows > PowerShell > Operational. Look for logs around the task run time—they'll show detailed errors if PowerShell failed to execute the EXE.

内容的提问来源于stack exchange，提问作者Victor Antifries