Surface Hubs on wired 802.1x may experience intermittent connectivity issues

During regular usage of the Surface Hub on a network that has 802.1x enabled but not enforced, you may observe intermittent SfB issues (mid-call media failures, or 100% packet loss for media sessions and then re-establishment of those sessions) or frequent DHCP requests originating from the Hub.

Depending on how the 802.1x network infrastructure is configured, it may request any capable device to authenticate on a regular basis (re-authentication interval). The Hub has been capable of 802.1x since the Windows 1703 update, but without further configuration, it will only try this authentication with the machine auth defaults (and no specific domain credentials/certificates) of the Wired AutoConfig service (dot3svc). When the authentication request fails, the Ethernet adapter then re-initializes and connects as an un-authenticated device. This reinit can take ~30 seconds, during which time the device will appear to have no connectivity and would interrupt any activities currently relying on that network connection.

As of the November 2017 Cumulative Update (KB4048954), the 802.1x behavior of a Surface Hub can be configured via MDM policy, by setting the OMA-URI ./Vendor/MSFT/SurfaceHub/Dot3/LanProfile to an XML file compliant with the LANProfile Schema. If configuring the Hub to authenticate as per the documentation is not desired, 802.1x can also be disabled via MDM policy, which would then set LanProfile equal to:

<?xml version="1.0" encoding="UTF-8"?>
<LANProfile xmlns="https://www.microsoft.com/networking/LAN/profile/v1">
   <MSM>
       <security>
           <OneXEnforced>false</OneXEnforced>
           <OneXEnabled>false</OneXEnabled>
       </security>
  </MSM>
</LANProfile>

The policy status in your MDM solution may report deployment errors, but the disabled 802.1x state can be verified from the Surface Hub's event logs and from observing the network behavior.