I've confirmed our script uses the recorded endpoint. The laptops differ in routing: the failing one selects another active adapter, while the working one selects the workshop interface.

Have the network owner assess and correct the identified route difference, then repeat the documented read-only check. That should settle the connection issue.

Too strong. Correct routing doesn't prove the controller service is available. You might just get a different failure.

@AmaraBarnes0600 Fair. I should've said it tests the routing lead. Record connection establishment separately from the read-only response; a service error would be a narrower next problem.

Would a successful ping help at all, then? I've got a folder of ping screenshots feeling increasingly decorative.

Limited reachability evidence. Ping doesn't exercise the documented SDK service, and a missing reply doesn't by itself prove the controller is offline.

On my laptop, office and workshop connections picked different routes to the same endpoint. The script hadn't changed; the active adapters had.

I'll retain the relevant adapter state alongside our selected-route information, making sure it describes the same laptop session in which the check fails.

Would a check with only the workshop connection establish the required fix, or does the normal multiple-connection setup still need review?

Use the network owner's documented diagnostic setup. A check with one connection doesn't establish the right configuration for normal use with both.

I've identified a specific routing difference between the laptops. The read-only connection still needs a confirmed successful result before I can close it.

@AaronBennett0697 That's useful progress, with the remaining uncertainty stated clearly: the route differs, but the check isn't confirmed successful.