The working laptop selects its wired interface. The failing laptop selects a virtual adapter after sign-in. Its wired address remains correct, which is all our notes had checked.

Our station-user check caught an environment difference too; get IT to examine that adapter's route instead of changing the controller to suit a laptop that has wandered off.

Is the virtual adapter part of something people actually need? We once removed an apparently spare connection and broke the test software that used it. IT put it back, naturally, and our mystery returned.

Chen, the adapter belongs to a local test environment used on this laptop. Isaac, the earlier ping was before sign-in finished. I have no successful ping recorded during the failed service check.

So keep the test environment. Ask IT to resolve the overlapping address range.

Aaron, has overlap actually been confirmed? A preferred route can be wrong for other reasons; I skipped from adapter to cause myself there.

No. I should have said check for overlap.

Jonas, does the loan laptop run that test environment too?

It does not. IT has now found the test environment uses an overlapping subnet. They are arranging its replacement range and checking the applications that depend on it.

That explains the route selection you observed. Retest after the managed configuration change, including sign-in and starting the local test environment. Both are part of normal use here.

And run the actual documented check, not just ping; the service request is what you need back.

The changed configuration keeps the controller route on the wired interface after sign-in. The documented check succeeds. The local test environment also starts, although its application checks are still with IT.

Nice. Does it survive a restart?

Use the ordinary workshop account for that repeat.

Restart and workshop-account repeat both succeeded, with the test environment running. IT has completed its application checks too. I have added the route comparison to our laptop handover.

Who gets called if the virtual adapter comes back with its old range after an update?

IT owns the test-environment configuration and has recorded the required range in its rebuild instructions. Thanks, Chen; removing the adapter would have broken the other work on this laptop.

Close the laptop issue with those results. The original timeout text did very little to identify it; your before-and-after route and service checks will be more useful next time.