same cable, different laptop, no status read

Mine has an older settings file in the launch folder. Address in that file differs from the card. That explains something, although correcting it hasn't made the status call work yet.

One wrong setting found, then. Can IT try the actual service connection from yours? You'll need the connection details from the manual for that; ping won't cover it.

The shortcut target too, please. I want to know which copy it opens. Add the SDK version while you've still got the working laptop beside you.

I've arranged to keep it while we compare them. We've captured versions, interface details and launch paths. The versions differ, but IT says the failed service connection happens before the application gets a response. No conclusion about the SDK yet.

I'd stay with IT on that failed connection for now. Swapping SDKs at the same time will make this a pain to follow.

Our laptop had an approved firewall rule tied to one program location. Moving the program broke the connection. Ask IT to inspect the rule and logs on yours; don't turn the firewall off just to see a green box.

IT found a blocked connection for our current launch path. The allowed entry refers to the previous installation. They're reviewing the rule against the documented service. At least there is a specific failure now.

That log is useful. Capture which program was blocked as well as the destination; otherwise the next reinstall may send you round again.

What's the borrowed one launching from, the current install folder or the old one? Worth checking its shortcut while IT has the two machines in front of them.

Keep the old and revised settings identifiable. You'll need to know which test used which configuration.

Working laptop uses its approved current path. IT updated our specific rule and the identity read now returns. We've labelled the captured settings by test, so I can finally tell which screenshot proves what.

Did it survive a normal laptop restart? A working session isn't much comfort if tomorrow's shift gets the old shortcut again.

Try the operator's usual login after that restart. Easy to forget whose account you're using when IT has been working on the machine all afternoon.

Let whoever normally uses the bench open it from the recorded shortcut and do the read-only check. That catches the small setup assumptions you stop noticing after working on it for days.

Two operators have now done that after separate restarts using their normal accounts. Both got the identity response. The obsolete shortcut is removed by IT and the bench card points to the maintained instructions. Closing this one.

Bet you're glad to give that laptop back. I'd leave the bad settings file and old shortcut names in the fault notes, in case somebody restores an old backup.