Setting for servers.json

Good Evening All,
I looking for the settings too connect for remote instances of CTW from a management box.
The background is I have CTW running on server core, and not all features are available through the GUI on core, presume there are some .Net assemblies missing that are required.
Anyway I’ve updated the servers.json on a server running desktop experience server, the remote servers are displayed in the gui, but when I try to connect I get ‘The server connection could not be competed. Check the service is running and the connection details are correct’ message.
I can confirm the service is running, port 9696 is open, so a process of elimination it must be the connection details, but there doesn’t seem to be any documentation on this, any help would be appreciated.
Thanks

Hi, that feature is very much a work in progress and you shouldn’t rely on it, there’s no documentation because it only exists for experimental work, we should really remove the option from the production version of the app.

We don’t currently do any testing or development for Windows Server Core and we don’t really support it.

However, to get a remote connection to work you currently either need to connect using a user that’s in the Administrators group on the target machine or you need to disable authentication (which you can’t easily do and you wouldn’t want anyway). You will need to change the serviceconfig.json on the target machine so that the listener binds to the machine IP address instead of localhost, then restart the certify service. You would then open port 9696 on the windows firewall for local network connections only (do not expose this port to the internet).

To test you can remotely talk to the service you should find that you can open browser and connect to http://:9696/api/system/appversion - once that works you can edit servers.json to add your remote server.

Your servers.json confif entry will look something like:

  {
    "Id": "1d0fb2df-85c1-4fda-b5ab-96f6b48e9a80",
    "DisplayName": "<MACHINE FRIENDLY NAME>",
    "UseHTTPS": false,
    "Port": 9696,
    "Host": "<machine ip>",
    "DateLastConnected": null,
    "Mode": "direct",
    "Authentication": "default",
    "ServerMode": "v1",
    "IsDefault": true
  },

It’s worth noting that in most of my tests for this feature I’m working with server instances running in docker/linux so I don’t know how it will behave on Server Core. Interested to find out!

Thanks for reply webprofusion, I followed your instructions, and got the gui working on a remote machine. The servers are a workgroup so not domain joined, so I created a local user account with the same name and password as the domain account and added it to the local administrators group. I was pretty close with syntax of the serviceconfig.json and servers.json, just had to update the target to the local IP.
I had already updated the firewall with port 9696, but there must another port used because with the firewall enabled the gui wouldn’t connect remotely, if you know which others ports that might be, I will test, because otherwise it worked great remotely. I know you don’t specifically support server core, but as MS are pushing it as the default option maybe some further testing is in order, I’d be happy to help in any way I can.
Thanks

Thanks, I tried to get it working myself yesterday but it fell down at the authentication. Only TCP port 9696 is used by default although the service can re-negotiate the port if something else is using that - port changes (if any) are written to serviceconfig.json - you can also try binding to the fully qualified machine hostname (e.g. yourserver.yourdomain.com) instead of the IP because if your local IP is different externally that could cause issues.

If you can connect from powershell then the UI should work as well:

Invoke-RestMethod -Uri http://<your-service-host>:9696/api/system/appversion -UseDefaultCredentials

The longer term plan is for the central server to be able to setup users and then remote UI can connect using a shared token, ideally I’d like it to also use client certificates (issued by the central server then installed on the client) for mutual tls. Currently though the feature is tied to the centralised server version development which is currently on a slight pause while other things (build systems etc) are improved.

I do agree it would be great to directly support server core.