Android 14 - Android Enterprise WiFi Profile Issues - Microsoft Intune

[Isaac_luna]

With the latest Android 14 - new Microsoft Intune Android Enterprise device enrollments are not receiving the WiFi configuration profile. Android 13 and later will receive the WiFi profile and connect to the hidden SSID with no issue.

[Lizzie]

Hello @Isaac_luna,

Welcome to the Customer Community. 

Just an initial thought on this, I wonder if configuring to add the domain name, as talked about in this community post, may help here? 

Thanks,

Lizzie

[Isaac_luna]

Hi @Lizzie.

Thank you for this recommendation. We have our WiFi config profile set up with the CA root and server domain names.

Isaac

[Oski_92]

hello @Lizzie,

I have the same problem as Isaac.
On devices enrolled in Intune, with Android 13, update to Android 14, and it continues to work fine.
On devices with android 14, enrolling it, it fails.

in the Wifi profile we also had the Radius servers and the root CA certificate

in the settings, User certificates, we see that the WiFi certificates aren't being installed.

thanks

[davidtse916]

We are having the same issue on our Samsung devices with Android 14. The same SCEP & Wi-Fi profile works fine on Android 13, but it's hit & miss on Android 14 (OneUI 6) devices 😞

[davidtse916]

We have found a workaround to our Wi-Fi (EAP-TLS) issue by adding the Root CA Cert in our Samsung KME (Knox Mobile Enrolment)'s profile just to make sure the cert is deployed and trusted by the device before SCEP & Wi-Fi profile is deployed to the device. According to Microsoft, if the SCEP / Wi-Fi profile arrives before the Trusted Certs profile, the Wi-Fi (EAP-TLS) won't work until the device re-check with Intune again (next check-in is 8 hours away, and no you can't do manual sync for corporate-owned, fully managed user devices)

[mattdermody]

Intune doesn't offer the ability to have payload installation priority or prerequisites to install one payload before the other is attempted? It also doesn't allow for force syncs on fully managed devices? If both of those are true I'm adding them to my long list of reasons why Intune should not be used for fully managed Android devices. So many organizations fall into the trappings of Intune not realizing how ineffective it is at managing line of business devices. I can't imagine telling and end customer they'll just have to wait another 8 hours and see if it works the next time in a mission critical environment. 

[SzymonKonczynsk]

Hi, has anyone solved this problem? 

[Oski_92]

hello,

it seems that there has been a modification by google, and there is a limit of characters in the total of the radius servers.

modify the radius servers, adding only the subdomain, this way it is working fine for us:

radius servers:

contoso.contoso2.com
cantasa.contoso2.com

replace by:

*contoso2.com

I hope it helps you

[Schwerdti]

I was also facing this issue. Key point in my case was to add an UPN in the linked SCEP certificate - e.g. like this:

The Wi-Fi profile looks like the following. From my point of view, key points are:

• define radius server name (there might also be a character limit as mentioned by @Oski_92, to avoid issues you might just use the TLD like "contoso.com")
• select Root certificate for server validation (not the server certificate of the RADIUS itself)
• sometimes identity privacy is needed

[Schwerdti]

* domain without subdomain (not TLD)