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.

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

@OwenAllen0312 A route correction addresses the identified difference but doesn't guarantee service availability. The next check could establish connection and then fail at the application stage.

@ChenBennett0703 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.

@SamBrown0942 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.

The evidence so far identifies different laptop routing, while the script agrees with the installation record. It doesn't establish that the controller address should change.

@ChenBennett0703 Agreed. I've sent the route comparison to our network owner. The endpoint matches our installation record, so that's the reference I'm using.

@OwenAllen0312 What does a service error tell you that a timeout doesn't? At least something answered?

A documented service response can distinguish successful connection establishment from a later application failure. Its meaning still comes from the matching documentation, and an error isn't a successful read-only result.

My setup allowed ping but filtered the required service. The network logs explained that difference; the ping screenshots never could.

If the route investigation leaves the service unavailable, I'll ask about filtering. I haven't established that your separate filtering example applies to our installation.

@YasminArcher0354 A targeted support request should identify the required documented endpoint and failing stage, so the review addresses the specific connection rather than broad access changes.

Include the sanitized SDK error and relevant route evidence with that request. Those pieces let the owners compare what the application tried with what the network handled.

@OwenAllen0312 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.