Fix StrictMode error on COM-handler task actions in Get-GmsaScheduledTask #1

Merged
hannah-vernon merged 1 commit from fix/comhandler-action-strictmode into dev 2026-06-30 16:20:59 -05:00

What does this PR do?

Fixes a Set-StrictMode -Version Latest failure in Get-GmsaScheduledTask.ps1 when a
Scheduled Task uses a COM-handler action.

Scheduled Task actions come in two CIM types:

  • MSFT_TaskExecAction - exposes Execute, Arguments, WorkingDirectory.
  • MSFT_TaskComHandlerAction - exposes ClassId, Data (no Execute).

The Actions block read .Execute unconditionally. Under StrictMode, accessing a property
that does not exist is a terminating error, so any host with a COM-handler task (for example
the built-in .NET Framework NGEN tasks) failed with:

The property 'Execute' cannot be found on this object. Verify that the property exists.

This adds a StrictMode-safe Get-CimPropertyValue helper that probes PSObject.Properties
before reading, and reports ActionType plus ComClassId / ComData alongside the existing
exec fields.

Fixes #

How was this tested?

  • Parser validation - 0 errors for the changed .ps1 file
  • Manually tested on a host with 230 tasks, 114 of which use COM-handler actions (via
    -Recurse). Before: threw on the first COM-handler task. After: all tasks report without
    error, COM-handler actions show their ActionType and ComClassId.

Checklist

  • I have read the Contributing Guide
  • Changes are focused - one logical change per PR
  • Comment-based help updated for any changed parameters or behavior (no parameter change;
    behavior note covered by the new ActionType / COM fields)
  • Documentation updated (if user-visible behavior changed)
  • No commented-out code or debug leftovers
## What does this PR do? Fixes a `Set-StrictMode -Version Latest` failure in `Get-GmsaScheduledTask.ps1` when a Scheduled Task uses a COM-handler action. Scheduled Task actions come in two CIM types: - `MSFT_TaskExecAction` - exposes `Execute`, `Arguments`, `WorkingDirectory`. - `MSFT_TaskComHandlerAction` - exposes `ClassId`, `Data` (no `Execute`). The Actions block read `.Execute` unconditionally. Under StrictMode, accessing a property that does not exist is a terminating error, so any host with a COM-handler task (for example the built-in `.NET Framework NGEN` tasks) failed with: > The property 'Execute' cannot be found on this object. Verify that the property exists. This adds a StrictMode-safe `Get-CimPropertyValue` helper that probes `PSObject.Properties` before reading, and reports `ActionType` plus `ComClassId` / `ComData` alongside the existing exec fields. Fixes # ## How was this tested? - [x] Parser validation - 0 errors for the changed `.ps1` file - [x] Manually tested on a host with **230 tasks, 114 of which use COM-handler actions** (via `-Recurse`). Before: threw on the first COM-handler task. After: all tasks report without error, COM-handler actions show their `ActionType` and `ComClassId`. ## Checklist - [x] I have read the [Contributing Guide](../CONTRIBUTING.md) - [x] Changes are focused - one logical change per PR - [x] Comment-based help updated for any changed parameters or behavior (no parameter change; behavior note covered by the new `ActionType` / COM fields) - [x] Documentation updated (if user-visible behavior changed) - [x] No commented-out code or debug leftovers
Get-ScheduledTask actions can be MSFT_TaskExecAction (Execute/Arguments/
WorkingDirectory) or MSFT_TaskComHandlerAction (ClassId/Data). The Actions block
read .Execute unconditionally, so under Set-StrictMode -Version Latest a task with
a COM-handler action threw 'The property Execute cannot be found on this object.'

Add a StrictMode-safe Get-CimPropertyValue helper that probes PSObject.Properties,
and report ActionType plus ComClassId/ComData alongside the exec fields. Verified
against a host with 114 COM-handler tasks: all now report without error.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
hannah-vernon/GmsaScheduledTaskTools!1
No description provided.