Show HN: Windows Automation Tool – System Center Orchestrator Replacement NodePilot launched as an agentless Windows workflow orchestration tool positioned as a modern, open replacement for Microsoft System Center Orchestrator, importing native .ois_export XML runbooks with activities, links, conditions, global variables and Published Data references. The tool runs PowerShell, file, registry, service, REST and SQL operations over WinRM without agents on targets, and includes an opt-in MCP server (nodepilot-mcp) exposing 102 tools across 10 groups to Claude Code, Claude Desktop and other MCP clients. NodePilot also offers AI-assisted authoring against OpenAI or local Ollama, LM Studio and vLLM, plus a Grafana stack with 10 pre-provisioned dashboards and JWT/RBAC security with Admin, Operator and Viewer roles. Agentless Windows workflow orchestration — a modern, open replacement for Microsoft System Center Orchestrator. Design, schedule, debug, and observe multi-step automation in your browser. Run PowerShell, file/registry/service operations, REST calls, SQL, and more across your Windows estate over WinRM — no agents on the targets. See SCOrch import, the Workflow Designer, execution history, Live Ops, logs and AI chat in action. English captions, no audio. Browse screenshots NodePilot is a drop-in modern alternative for organizations stuck on legacy SCOrch — same agentless model, same target audience sysadmins automating Windows estates , but built on a current stack with a UX that doesn't feel like a 2010 MMC snap-in. Highlights - Your SCOrch runbooks import directly — native .ois export XML, with activities, links, conditions, global variables and Published Data references translated into NodePilot's data bus. How it works coming-from-system-center-orchestrator . - Visual designer — drag-and-drop canvas with 27 activity types, 6 triggers, typed nodes, a visual condition builder, and a seven-cluster toolbar that puts every editing affordance one click away. - True parallel engine — event-driven scheduling loop with real fan-out / fan-in, three junction modes waitAll / waitAny / waitNofM , per-step DI scope, and skip propagation. - Step debugger — breakpoints, conditional breakpoints, step-over, live variable inspector with runtime overrides , and time-scrubbing replay in the Gantt timeline. - Real-time UI — SignalR streams step status, output, and variables to every connected client as the workflow runs. - Agentless remote execution — WinRM + PowerShell SDK; localhost runs in-process without WinRM. - AI-assisted authoring — generate PowerShell scripts and entire workflows from natural language; works against OpenAI or local Ollama / LM Studio / vLLM for zero-egress setups. - Global AI chat — a read-only assistant available from the bottom-right chat button and its own page /ai-chat , sharing conversations, drafts and ongoing answers across navigation. Answers use admin-switchable knowledge sources: documentation, operational data scoped by folder permissions, source code, and read-only SQL against the database. Every source is opt-in; the chat never executes or publishes anything. - Operations CLI np — full-featured command-line client login, run, watch, audit, lock/publish, import/export , published as a self-contained folder you put on PATH . - Drivable by AI agents — an opt-in MCP server nodepilot-mcp exposes NodePilot to Claude Code, Claude Desktop and any other MCP client — 102 tools over 10 groups, HTTP-only against the same REST API, with destructive operations gated. - Batteries-included observability — opt-in OpenTelemetry + Prometheus exporter, plus a hardened, loopback-bound Grafana stack with 10 pre-provisioned dashboards Mission Control, Workflows, Activities, WinRM, Triggers, API, Runtime, Security, AI, Database . Startup requires a unique NODEPILOT GRAFANA ADMIN PASSWORD — Compose fails closed while the password is missing, rather than coming up on a default credential. - SCOrch-style edit lock — atomic per-user check-out / publish flow, 423 Locked enforced by every mutating endpoint, force-unlock for admins with audit trail. - Workflow versioning — every edit is snapshotted; one-click rollback; visual diff between any two versions. - JWT + RBAC — Admin / Operator / Viewer roles, BCrypt passwords, account lockout, DPAPI-encrypted credentials, output redaction, SSRF guards, per-IP rate limits, and an audit-event alert source that pages on failed logins, lockouts, break-glass sign-ins and privilege changes without a SIEM. - AD SSO Preview opt-in — hardened LDAP/Kerberos, OIDC + SCIM, server-side sessions and directory-backed RBAC complement Active/Passive HA , secret providers and ECS-JSON SIEM logging. Production status remains Preview until the real AD/Kerberos/LDAPS field gate passes. See docs/enterprise-features.md https://github.com/Sev7eNup/NodePilot/blob/main/docs/enterprise-features.md . - Production-grade deployment — turnkey PowerShell installer for Windows Service under a gMSA , direct Kestrel HTTPS, install/data-dir split, in-place upgrades with auto-rollback. SCOrch is not going anywhere: System Center 2025 Orchestrator https://learn.microsoft.com/en-us/lifecycle/products/system-center-2025-orchestrator shipped in November 2024 with mainstream support to January 2030 and extended support to January 2035. If you run it today, you are not on a deadline — so this is not a migration pitch. What has not moved is authoring. The web console added in 2022 runs and monitors runbooks; it cannot build them. Writing one still means the desktop Runbook Designer, on a machine with the client installed — and once it is written, there is no version history, no diff between two states, and no rollback. NodePilot is built for that gap: the same agentless model, the same job, the same people, with the editor, the debugger and the version history in a browser. Your runbooks come with you. NodePilot reads SCOrch's native .ois export XML directly exports from 2012, 2016 and 2019 all parse and turns runbooks into workflows: - Activities are mapped, not dropped. Roughly forty SCOrch type names translate directly — scripts and programs, the file, folder, archive and text-file activities, Query XML , Query Database , Query WMI , Invoke Web Services , Send Email , Start/Stop Service , Restart System , Generate Random Text , the Monitor activities that have a NodePilot trigger, and the Runbook Control set Initialize Data , Return Data , Junction , and Invoke Runbook , which SCOrch writes as Trigger Policy including the arguments passed to a child runbook. - Published Data becomes the data bus. SCOrch's \ d.T.~Vb/{GUID}\ d.T.~Vb/ references are rewritten into NodePilot's {{globals.Name}} and {{step.param.field}} syntax, resolving through a readable name derived from each activity rather than a bare GUID. Where the two products name the same value differently the field is translated too, and where SCOrch published something NodePilot has no equivalent for, the reference is reported instead of quietly pointing at the nearest-looking name. This is usually the part that makes a migration expensive. - Branches keep branching. Compare Values becomes a decision , and the links that read its result are re-pointed at it — a comparison whose outcome nothing could read would leave every branch behind it dead. - Links, conditions and global variables come across , including on-success / on-failure links, the TRIGGERS filter logic, and whether a link matched all or any of its filters. - Every runbook is runnable on arrival. NodePilot starts a workflow from a trigger node, and a SCOrch runbook invoked by another needs no trigger of its own — so one is added and wired to the entry activities. - Nothing disappears silently. An activity the importer cannot map becomes a disabled placeholder carrying the original type name and its full property list; a mapping that cannot fill a required setting degrades to one too, rather than leaving a node that looks configured and does nothing. The import report names every lossy translation: a reference to a field the NodePilot activity does not publish, a reference across parallel branches SCOrch's data bus is run-scoped, NodePilot's is ancestor-scoped , a remote step with no target machine, a dropped run-as account, an approximated schedule, and any link that ended up unconditional. - Your folder tree comes with you. A SCOrch export carries the structure its console showed — for runbooks and for global variables — and the import rebuilds both below the destination you pick, reusing folders that are already there. Re-filing a few hundred workflows by hand is work a migration should not create. - The canvas looks like your runbook. SCOrch positions activities as small icons on a tight grid; NodePilot draws cards several times that size, so the coordinates cannot be copied as they are. The graph is scaled uniformly instead — a similarity transform, so every distance keeps its ratio and the arrangement is the one its author drew, just larger. Links are then made to read as curves rather than the angular loop the designer draws for an edge running backwards: a pair stacked in one column docks top-to-bottom without either node moving, and anything else is nudged apart horizontally. Rows are never touched. Where the arrangement cannot be reproduced activities sharing a position, or spaced too tightly for any usable canvas the import says so and falls back to a left-to-right layout. Import from the UI, from POST /api/workflows/import-scorch , or from the CLI: np workflow import-scorch --file .\runbooks.ois export Treat the result as a reviewed draft, not a finished migration. Imported workflows arrive disabled, credentials are never reconstructed SCOrch encrypts them , and anything the report flags needs a decision. After review, activate a workflow explicitly through POST /api/workflows/{id}/enable or np workflow enable