Recently I encountered situation where it was discovered that we were missing a RADIUS server FQDN in the allowed servers list on some machines which was causing them to fail to connect to the 802.1x secured network and as a result they were stuck with connectivity on our Guest/Remediation VLAN.
Historically we had this configuration deployed through a Win32 app containing a PowerShell script and the exported XML of a functioning Ethernet Adapter connected to 802.1x, it appeared that we had two revisions of this file with the newer one containing the missing FQDN. Turns out it had been deploying to new machines but was failing silently to update the XML on existing machines with the older file revision.
Earlier this year Microsoft made available a new configuration profile called Wired network, this profile allows you to more easily configure these settings without having to export the XML file from a working machine.
This new policy in addition also provides a graphical means to set the Root certificates for server validation and select the Client certificate if using SCEP or PKCS.
In our environment the Trusted Certificate and SCEP configuration profiles that import/generate these certificates are bound to a dynamic user group, originally the Win32 app applying the XML was bound to a dynamic device group.
When we tried to migrate devices from the Win32 app to a Wired network configuration profile we encountered an issue where devices were stuck with a pending status and were not receiving the profile, this remained the case for 96+ hours.
After chatting to Microsoft Support and trying a few other options we found that when scoping a Wired network configuration profile to a device group where the linked trusted certificates and SCEP configuration is scoped to a user group it prevents the configuration from being deployed at all.
Microsoft do recommend in their Knowledge article for Wired networks to use the same groups across the configuration profiles to ensure that the certificates are present when referenced by the Wired network profile however it did not highlight the behavior when mixing device and user groups between these.
In closing, if you’re encountering an issue where a Wired Network configuration profile (or likely a Wireless one too for that matter) just isn’t deploying to endpoints, make sure you are using either device group targeting or user group targeting across all policies involved (Trusted Certificate/SCEP/Wired Network) .