NodePilot 1.2.24

A single fix, found by running the Engine Switcher against a System Center Orchestrator installation whose Web API build cannot answer the job query the switcher was sending.

Fixed

The Engine Switcher no longer uses the OData in operator to read active SCOrch jobs. Switching to System Center Orchestrator aborted after the SCOrch services had already been started, and the fail-closed cleanup then stopped everything again:

SCOrch returned a malformed ScorchJob response from
http://localhost:81/api/jobs?$filter=Status in ('Pending','Running'):
Expected depth to be zero at the end of the JSON payload. BytePositionInLine: 68
Body: {"@odata.context":"http://localhost:81/api/$metadata#Jobs","value":[

The body really was 68 bytes. Some Web API builds accept that filter, begin the response, and then abort it before the first job. The jobs endpoint returns a deferred collection, so the query runs only while the serializer is already writing value — by then the response is committed and the failure can no longer be reported, which leaves a semantically truncated payload under HTTP 200. api/runbooks and api/runbookServers answered normally on the same installation, so nothing was wrong with the port, the authentication or the database.

The shipped activeJobsPath now reads:

api/jobs?$select=Id,RunbookId,Status&$filter=Status eq 'Pending' or Status eq 'Running'

eq/or is equivalent and works across builds. $select additionally limits the response to the three fields the switcher actually reads, which cut the body from 8832 to 1482 characters on the affected installation. The set of job states is unchanged, and no $top was added — the service caps $top at 50 while the reconciler needs every active job.

An installation that already has a configuration file keeps its own value: activeJobsPath is read verbatim, so update engine-switcher.json by hand, or replace it with the template shipped in this release. docs/engine-switcher.md now records why the in operator is avoided, so it does not get reintroduced.

Verifying this download

Every file below is listed in NodePilot-1.2.24.SHA256SUMS.txt, the publisher certificate included.

Get-FileHash .\NodePilot-1.2.24.zip -Algorithm SHA256

The installers and the standalone switcher are Authenticode-signed with the NodePilot release certificate:

Subject     CN=NodePilot Release Signing
Thumbprint  277EAB317A581C88302CE92BE805938C86B4650D

Compare that thumbprint against nodepilot-release-signing.cer, attached here:

(Get-PfxCertificate .\nodepilot-release-signing.cer).Thumbprint
$sig = Get-AuthenticodeSignature .\NodePilot-Server-Setup-1.2.24.exe
$sig.SignerCertificate.Subject
$sig.SignerCertificate.Thumbprint

Get-AuthenticodeSignature reports Status: UnknownError, and that is the expected result — the certificate is self-signed, so its root is in nobody's trust store and no chain can be built. What carries the meaning is the pair above: the signer's subject, and a thumbprint equal to the certificate shipped alongside. The checksum file proves the download is intact; the thumbprint is what proves who built it.

SmartScreen

Windows SmartScreen warns on first run of a downloaded installer — "Windows protected your PC". That is expected and unrelated to the signature: the release certificate is self-signed and carries no reputation, so signing does not silence it. Choose More info → Run anyway. SmartScreen ignores antivirus exclusion lists entirely; see the deployment guide for the full explanation.