Android Galaxy XCover 7 problems with .local adress
Hello we are facing a problem some of our Samsung Galaxy XCover 7 devices can only resolve an internal server with a .local address very slowly. This means that we cannot use the resource, as high latency leads to the connection being terminated. We use our own DNS server which comes with DHCP. If I change the DNS server manually using an app, but to the same DNS server that also comes with DHCP, we can reach the address without any problems and without long latency. (This happens over a VPN tunnel to the dns server) Does anyone have ideas?
Application report not getting collected on Xiaomi mix fold devices
We have couple of users who have the Xiaomi Fold device and in the application report section of status report notifications we are only getting the android device policy app. None of the other applications are getting returned. Is this a known issue? How can we debug the issue? I was not able to see anything obvious in the device logs. We are getting the full application report for the other devices.
Impact of Intune's NFC restriction setting on IC card reading and Nearby Share
Hello, I'm managing Android Enterprise devices via Intune and would like to confirm the behavior of a specific device restriction setting related to NFC. ■ Device: AQUOS wish4 (Android), enrolled as a fully managed device ■ Policy applied: Device configuration profile with "Beam data using NFC (work-profile level)" set to Block ■ Policy configuration path in Intune Admin Center: Microsoft Intune Admin Center > Devices > Manage devices > Configuration Platform: Android Enterprise Profile type: Template > Device restrictions Configuration settings > General - Beam data using NFC (work-profile level): Block ○ Background and expectation: My understanding is that this setting is intended to block NFC-based data transfer (i.e., Android Beam) within the work profile. However, I initially assumed it might also block general NFC usage, such as reading contactless transit cards or using mobile wallet services. ○ Test scenario and results: After applying the policy to a fully managed AQUOS wish4 device, I observed the following: The NFC toggle remains available and functional under: Settings > Connection settings > More connection settings > NFC I installed an app that reads contactless transit cards used for public transportation (e.g., Suica or PASMO in Japan) and confirmed that it successfully retrieved the card balance via NFC ○ Interpretation: Based on this behavior, I suspect that the policy only affects the deprecated Android Beam feature, which used NFC for peer-to-peer file sharing. It does not block general NFC functionality such as card reading or mobile payments, nor does it impact newer sharing technologies like Nearby Share or Quick Share, which rely on Bluetooth and Wi-Fi Direct. ■ Questions: Is my understanding correct that "Beam data using NFC (work-profile level)" only restricts Android Beam functionality and does not affect general NFC usage? Is there a way to restrict Nearby Share / Quick Share on fully managed Android devices via Intune, or would that require a different configuration or approach? Any insights, documentation references, or shared experiences would be greatly appreciated. Thank you!
Unable to install certificates for WiFi
Our MDM is using an internal app to install certificates that can be managed by our platform. The problem is when trying to set up corporate EAP-TLS networks, the device is unable to use the installed certificate for WiFi authentication. We see that identity certificates that can be installed programatically via DevicePolicyManager.installKeyPair(ComponentName admin, PrivateKey privKey, Certificate[] certs, String alias, boolean requestAccess) are installed under User Credentials settings section but for VPN and apps usage, not for WiFi, which is what the network configuration is expecting. Is there any other Android SDK API we can use in order to install the certificates for WiFi usage? Many thanks.
Barcode setup without ENROLLMENT_TOKEN
Hi We are preparing to enroll over 600 Zebra and Honeywell barcode scanners into Microsoft Intune. These devices are distributed across more than 250 locations and span over 35 distinct configuration profiles. To ensure a smooth rollout, especially for our non-technical users, we aim to automate the enrollment process as much as possible—minimizing manual input and reducing the risk of user errors, including Wi-Fi setup. Our intended workflow is for users to simply scan a QR code at the initial "Hi there" screen. This QR code should contain the necessary Wi-Fi configuration and trigger device provisioning via the Google Zero-Touch portal, bypassing the setup wizard entirely. However, when we generate a QR code using the following JSON configuration, the Wi-Fi settings are not being applied as expected. After the QR code is scanned, the device proceeds to the Wi-Fi setup screen, where users are required to manually enter the network configuration. According to Google’s documentation, the EXTRA_ENROLLMENT_TOKEN is optional. Is it possible to fully automate this step without including the token, or is it required in practice for the Wi-Fi configuration to be applied correctly? Any help would be much appreciated—thank you! { "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver", "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg", "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup", "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": { "android.app.extra.EXTRA_PROVISIONING_WIFI_SSID": "**SSID**", "android.app.extra.EXTRA_PROVISIONING_WIFI_PASSWORD": "**PASSWORD**", "android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE": "WPA", "com.google.android.apps.work.clouddpc.extra.EXTRA_PROVISIONING_SKIP_USER_CONSENT": true, "com.google.android.apps.work.clouddpc.extra.EXTRA_PROVISIONING_SKIP_USER_SETUP": true, "com.google.android.apps.work.clouddpc.extra.EXTRA_PROVISIONING_SKIP_ACCOUNT_SETUP": true, "com.google.android.apps.work.clouddpc.extra.PROVISIONING_SKIP_EDUCATION_SCREENS": true } }
Google Messages App: SMS to shortcode not able to send
Our Provider (Vodafone Germany) is using a SMS shortcode number to be able to order an upgrade on dataplans by sms. Once the monthly contract plan (e.g. 1 GB) have been used users will receive a sms from 70997 to inform that you can answer the SMS with "1" or "2" to restore your data connectivity. We ran into the issue that the Google Messages app seems to have some sort of bug with sending SMS to this kind of shortcode number as it alway says "Not sent" in red error text. Provider tech support told me that the Google messages app is prefixing the number with "49" resulting in a wrong / unknown number (4970997). They cannot fix that from their side as the issue is within Google messages app and asked me to install a 3rd party messages app.... *ugly* Is this something I can request to investigate from here? I will also create a case with Samsung tech support as we are mainly using Samsung devices as our corp. device fleet. Thank you! Kind Regards Daniel