Using a Port Scanner to Validate Hexnode UEM Network Connectivity

At a Glance

In a UEM environment, a pending command usually indicates that the endpoint has not yet acknowledged, received, or reported completion of the command. The cause may be network-layer blocking, device offline state, OS throttling, push notification delay, or platform-specific restrictions. Hexnode UEM relies on outbound device connectivity to Hexnode cloud services and platform notification services such as APNs, FCM, WNS, and MQTT. These services help wake devices or notify them to check in with Hexnode for pending commands, policies, or actions.

A port scanner is a critical diagnostic tool used to test these precise network pathways, verifying whether a local firewall, web proxy, or ISP is silently dropping required traffic. Rather than guessing why a fleet is unresponsive, IT administrators use port scanning to validate whether an endpoint can successfully resolve hostnames and reach necessary cloud infrastructure. This guide details how to leverage port scan results to troubleshoot network-layer blocks, validate security rules, and restore Hexnode connectivity across your enterprise.

Note: Port scanning is a network-layer diagnostic. It helps prove whether required pathways are reachable, but Hexnode command execution also depends on device state, enrollment, push services, certificates, permissions, OS restrictions, and action-specific prerequisites.

What a Port Scanner can and cannot Prove

A port scan is an invaluable diagnostic step, but it must be interpreted correctly. It validates network reachability, not OS-level application behaviors.

Hexnode-Specific Port Validation Matrix

When troubleshooting device unresponsiveness, do not test blindly. Map the symptom directly to the required cloud infrastructure protocol.

Network Vantage Point: Where to Run the Scan

A massive administrative blind spot is testing from the wrong network layer. A successful scan from an IT administrator’s unlocked laptop does not reflect the reality of a restricted kiosk endpoint. You must scan from the exact vantage point of the failing device.

Operational Troubleshooting Workflow

When a Hexnode action fails, follow this structured workflow to isolate the network variable:

1. Identify the Failed Action: Determine if the failure is platform-specific (e.g., only Apple devices failing points to APNs) or universal (points to baseline HTTPS/DNS).
2. Match to the Port Matrix: Identify the required ports (e.g., 5228 for FCM, 5223 for APNs) using the validation matrix above.
3. Execute from the Correct Vantage Point: Use a port scanner (like nmap, Test-NetConnection, or Network Utility) from a device on the exact same network segment as the failing endpoint.
4. Validate Outbound-Only Traffic Paths: Ensure you are testing outbound connections to Hexnode domains. UEM architectures do not require inbound firewall ports to be opened.
5. Check for Proxy/SSL Decryption: If the port is open but the device remains offline, verify if your firewall is performing Deep Packet Inspection (DPI) or SSL Decryption. TLS inspection or certificate substitution can break platform notification services because devices and services expect trusted end-to-end TLS sessions.
6. Verify Hostname Resolution: Run nslookup on the endpoint to ensure the network’s DNS server is successfully resolving Hexnode and OEM notification domains.

“Port Open But Hexnode Still Failing” Diagnostics

Network administrators often fall into the trap of over-trusting a clean port scan. If the scanner shows green but the UEM action still fails, investigate these hidden causes.

Defensive Scanning Bounds & Glossary

Defensive Boundary: Port scanning in a UEM troubleshooting context is strictly defensive. You are validating authorized outbound communication lines to known Hexnode and OEM infrastructure. Avoid aggressive or broad scanning against third-party or Hexnode-owned infrastructure. Limit testing to authorized connectivity checks for required ports and domains, and coordinate with your security/network team if deeper testing is required.