When Console says it can't reach the Api, can't sign you in, or shows the wrong fleet -- what is actually going on, and how to fix it for your network.

How Console decides where to connect

Console is only a window. Every job, schedule, and report comes from a Minion Agent Api over HTTP, and Console needs to know that Api's address.

  1. On first launch it reads ApiBaseUrl from its own appsettings.json (default http://localhost:5443 -- the Api on the same box).
  2. That address is saved as an entry in your fleet list (Manage Fleets in the top bar), and from then on the saved entry is what Console uses at startup.
  3. If this box is a Node (not the fleet master), Console asks its local Api who the master is and switches to the master's address on every launch, saving it. You want this: a Node's own Api only knows about its own data; the master has the whole fleet.

Because of step 2 and 3, the address Console is using is not always the one in appsettings.json. To see the real one: Manage Fleets shows every saved address, and its Open Folder button takes you to the file that holds them. All of Console's settings live in one place, C:\ProgramData\MinionWare\MinionAgent\Config (AppConfig.json holds the fleet list). Older versions kept them in hidden per-user AppData folders; Console copies those across the first time it runs.

Problems and solutions

"Couldn't reach the Api" (connection actively refused)

The machine answered, but nothing accepted the connection. Check on the Api box, not the Console box:

Cause How to tell Fix
Api is bound to loopback only netstat -an shows 127.0.0.1:5443 instead of 0.0.0.0:5443 Set the Api's Urls in its appsettings.json to http://0.0.0.0:5443, then restart the Api service (services read config only at startup). Installs from the current installer do this for you.
Windows Firewall blocks the port Works with the firewall off Add an inbound rule once, from an elevated PowerShell: New-NetFirewallRule -DisplayName "Minion.Agent Api" -Direction Inbound -Protocol TCP -LocalPort 5443 -Action Allow. Check all three profiles (Domain/Private/Public); they can differ.
The name resolves to the wrong address ping box returns an address that isn't the one on your LAN (a virtual-switch or IPv6 address is common) Use the box's IP address instead of its name in Manage Fleets and in the installer's Fleet step.

"Couldn't reach https://...: The SSL connection could not be established" on sign-in

The address Console is using starts with https://, but the Api speaks plain http:// on 5443. The usual cause is an old saved fleet entry or a stale default from an earlier version. Fix it in Manage Fleets: edit the entry so it reads http://<server>:5443. The sign-in error now names the address it tried, so you can see this at a glance.

Sign-in with Windows identity fails or loops

Windows sign-in (Negotiate) needs a domain controller to vouch for you. If your boxes aren't on a domain, or are on one whose DC is unreachable, it can never work across machines. Use Sign in as... -> App Account (or Azure AD) instead. See the situation table below.

The server picker says one box but I'm seeing another box's jobs

The server picker in the top bar names the box Console is actually connected to, with its role -- for example 192.168.1.198 (Master). On a Node that has hopped to its master, the jobs on screen are the master's, and the picker says so; this box is only added when the connected address really is the machine you're sitting at. (Earlier builds labelled the master with the local machine's name -- if you see a label that doesn't match the jobs, update Console.)

Console shows the wrong fleet, or shows nothing

A saved fleet address has gone stale (the master was renamed, re-IP'd, or reinstalled). Console now recovers from this on its own -- see Automatic fallback below -- but you can also correct the entry yourself in Manage Fleets.

Your situation

You are... Windows sign-in across boxes What to use Addresses
Console on the same box as the Api Works Anything localhost is fine
On a domain with a healthy DC Works Windows identity, App Account, or Azure AD Names are fine
Domain-joined, but the DC is down/unreachable Doesn't work -- no Kerberos, no domain NTLM App Account or Azure AD Prefer IPs; name resolution is often broken too
Not on a domain (workgroup) Doesn't work across boxes App Account or Azure AD Use IPs, or add the names to each box's hosts file
Console on a workstation with no local Api n/a App Account or Azure AD Add the master in Manage Fleets using its address

This also applies to anything the Api or Worker does to another box using Windows identity. On a fleet with no working domain, the installer's Fleet step should use the SQL login option when it connects to the master's SQL Server.

Automatic fallback

If Console can't reach the address it has saved, it no longer stays stuck there:

  1. It tries the Api on this same box (the address in appsettings.json) -- the one place that's always right for a Node.
  2. That Api reports who the master is, and Console follows it there and saves the corrected address.
  3. If this box is the master, the local address is saved as the fleet's address.

You don't restart Console and you don't edit anything -- just sign in once it has found its way. If this box has no Api of its own (Console on a workstation), there is nothing to fall back to: Console keeps the saved address and reports it as unreachable, and you fix the entry in Manage Fleets.

Setting up a Node correctly the first time

In the installer's Fleet step choose Node and give the Master server (name or, safer on a shaky network, its IP) and the Port (default 5443). The installer builds the rest, and the master must already be reachable on that port, meaning the firewall rule above is in place on the master.

See also: Glossary for related terms, Fleet Job Sync, and Roles and Permissions.