Reaching the Minion Agent Api from another machine, or scripting against it with -UseDefaultCredentials in PowerShell, runs into two separate walls: whether the Api is even listening where you're calling it, and whether your tool will send Windows credentials there at all. This page covers both -- what to change to open the Api up to the network on purpose, what Windows Firewall and the installer do and don't do for you, why PowerShell demands -AllowUnencryptedAuthentication for a non-localhost call, and what actually getting this onto HTTPS would take. For how to sign in itself, see Calling the API From Your Own Code.

Why a call to anything but localhost can get flatly refused

The safe default is loopback-only. Out of the box (a dotnet run/development instance, or any install from before a recent installer fix -- see below), the Api only answers localhost/127.0.0.1. Calling it by this machine's NetBIOS name, its FQDN, or any IP -- even from the same box -- gets refused outright, because nothing is listening on that address, only on loopback. That refusal is exactly what "the target machine actively refused it" looks like: not a firewall block, not a wrong password, just nothing bound there.

A current install may already be open. Recent versions of the Minion Agent Installer write the Api's listen address as every interface (0.0.0.0) automatically, on every fresh install and upgrade -- so a recently-installed or recently-upgraded Api is probably already reachable from other machines without touching anything. If yours isn't, either it predates that installer change, or the firewall (below) is still blocking it.

Where the listen address is configured

<InstallPath>\Api\appsettings.json

InstallPath is whatever you chose when you ran the installer -- its own default is C:\Program Files\MinionWare\MinionAgent, but yours may be different. The setting itself is the top-level "Urls" value.

Valid values for Urls

  • "http://localhost:5443" -- loopback only. Refuses everything else. The safe default.
  • "http://+:5443" -- listens on every hostname and every interface this machine has.
  • "http://0.0.0.0:5443" -- listens on every IPv4 interface (what a current installer writes by default).
  • "http://192.168.1.50:5443" -- listens on one specific interface's address only, nothing else.
  • Multiple bindings at once, separated by ; -- e.g. "http://localhost:5443;http://192.168.1.50:5443".

(5443 is the Api's own default port; use whatever port your install actually uses if it's different.)

After changing it, restart the service

The Api reads this file once, at startup, and caches it -- editing it live doesn't do anything until you restart:

Restart-Service MinionAgent.Api

The firewall is a separate step

Widening Urls only tells the Api to listen there -- it doesn't open anything in Windows Firewall, and the installer doesn't either. You still need to allow the port in yourself:

New-NetFirewallRule -DisplayName "Minion Agent Api" -Direction Inbound -Protocol TCP -LocalPort 5443 -Action Allow

Re-running the installer will overwrite a hand edit

An Upgrade or Clean Reinstall regenerates appsettings.json from scratch based on what you enter into the installer -- if you've hand-edited "Urls" to something the installer wouldn't produce on its own (say, one specific NIC address instead of every interface), expect to reapply that edit after the next upgrade.

Why PowerShell demands -AllowUnencryptedAuthentication

Invoke-RestMethod/Invoke-WebRequest in PowerShell 7+ refuse to send Windows-integrated credentials (-UseDefaultCredentials, or an explicit -Credential) to anything but localhost over a plain http:// connection, unless you say you mean it:

Invoke-RestMethod -Uri "http://your-minion-agent-server:5443/api/jobs" -UseDefaultCredentials -AllowUnencryptedAuthentication -Headers $headers

This is PowerShell's own safeguard against sending a Windows credential handshake somewhere unencrypted -- it has nothing to do with this Api specifically, and every example in this guide that uses -UseDefaultCredentials against the generic your-minion-agent-server placeholder carries the flag for exactly this reason. It goes away once the Api is actually served over https:// (see below); leaving it on an https:// call is harmless, just unnecessary. Signing in with an app account instead (a Bearer token, not Windows credentials -- see Calling the API From Your Own Code) never needs this flag either, since nothing about that flow routes through PowerShell's credential-transport check.

This opens plain HTTP, not HTTPS

Widening Urls this way exposes the Api over unencrypted HTTP to whatever it's now bound to -- there's no TLS configured anywhere in the Api today (no Kestrel HTTPS endpoint, no certificate). Anything sent to it once it's reachable this way, including a session token from signing in, travels in the clear on whatever network can now reach it.

Getting it onto HTTPS instead would take:

  1. A real certificate for the actual hostname or FQDN clients will call it by -- a cert issued for localhost won't validate once you're calling it by NetBIOS name or FQDN, and a self-signed one means every calling client has to be told to trust it explicitly.
  2. Server-side endpoint configuration -- Kestrel needs an HTTPS endpoint pointed at that certificate; nothing like this exists in the Api today. The Api already uses a LocalMachine-store certificate convention elsewhere (for command-text and credential encryption, a separate purpose from TLS) -- a server certificate would most naturally follow that same store-based convention rather than a loose .pfx file on disk.
  3. The same firewall step as HTTP -- whatever inbound rule opens the port is needed regardless of scheme.
  4. A decision on whether HTTP stays available too -- Kestrel can serve HTTP and HTTPS on different endpoints at once, so an internal loopback-only HTTP path could coexist with an HTTPS one for real network access.

None of this is configured out of the box today -- it's a deliberate, separate change, not a setting.

See also: Calling the API From Your Own Code, API Response Codes.