Zoom Room devices intermittently disconnecting

One of the [few] positive things about the Poly appliances is their unencrypted logs (Neat, Logi, etc will not allow you to view your device logs directly). You should still be able to connect to the appliance web UIs and pull logs while these errors are present (if you can’t - bingo, you’ve got some genuine network issues to address) - from there, you should be able to see if the device is privy to any anomalies that may affect upstream behavior at the time that these errors are showing. 
In my experience, the 5003 errors can stem from a broad set of triggers (we’ve also gone through periods where they are more prominent - the issue tends to mysteriously disappear) and ‘network connection’ issues as reported by Zoom are only the tip of the iceberg that Zoom has access to. For instance, if a Zoom Rooms compute/appliance loses power during a call, Zoom will log it as a network connection failure - yeah… technically true from Zoom’s perspective, as the network connection DID fail, but the error itself is downstream of the actual root cause.

No happy-lights on the NIC indicates a ‘true’ network and/or hardware problem. Regardless of whether or not that device can connect to Zoom cloud, it should be sending/receiving packets on your local network.

As for logs, I would absolutely expect to see something that references this.

For Poly appliances, the first place you’re going to want to look is the ‘messages’ logs (view in VScode or another IDE rather than notepad to make your life easier). These logs roll over and increment, so the higher the appended number is, the older the log is. If the issue starts in the middle of the night and you pull logs in the morning, there’s a chance you won’t even have the start-of-incident logged due to all of the noise.
Logs might just get you to the time of when the issue started, rather than the root cause (if the issue is with your network, that might not be captured here, but you’ll know WHEN the issue started and can dig into network logs at around that same timestamp).

Another important thing here - enable ‘Internal Storage Logging’ on the Poly device while working through this issue. This ensures that if the device gets power-cycled (unexpected power loss - and since you can’t reboot via the UI when this is happening, that’s what you’re doing), logs will be cached.