User Profile
Alex_Muc
Level 2.3: Gingerbread
Joined 2 years ago
User Widgets
Contributions
Re: Work profile on S25 Ultra
Particularly for such problems, you can use the Knox Admin Portal as a company to create tickets for Samsung. (And ideally, bug reports and the reproduction steps are supplied directly 😁) But I would bet that someone has already done this and Samsung is working on the problem. 😃Re: Work profile on S25 Ultra
You could use the TestDPC to test if creating a work profile generally works on the S25 Ultra. If there are also problems with the TestDPC, the problem does not necessarily have to be with Intune. In the post you shared, some people actually tried this and also had problems with the TestDPC. The S25 series is not yet listed as ‘Android Enterprise Recommended’, but I wouldn't worry about that. The certification will probably still take some time. And even when Samsung did release devices without ‘Android Enterprise Recommended’ in the past, the devices worked perfectly with Android Enterprise. I probably will be able to test it with a Galaxy S25 in a week. I really hope that we don't find any major bugs. 😅 However, I am a little sceptical after the many Android 15 delays and news like this. Since Android 16 is already planned for release in Q2/2025, I find the many postponements due to OneUI7 very unfortunate on Samsung's side.Re: Galaxy S25
The S25 receives software updates for 7 years. However, the release interval may change from monthly to quarterly after 4 years. Samsung publicly lists until when devices receive updates. (Curiously, this is missing for the S25) https://www.samsungknox.com/en/knox-platform/supported-devices Information on the current release intervals and the fixed CVEs can be found here: https://security.samsungmobile.com/workScope.smsbRe: (COPE) Hide app in work profile
Yunchuan Hm, that could be a bug in the newer model. It doesn't seem to be due to the configuration and we don't have any problems with Android 14. Have you ever requested a bug report / verbose logcat logs from the customer? Ideally, you might see errors there. The policy controller triggers the action and the system gradually works through the necessary steps. Maybe an error occurs during a single action, as a result of which the app remains visible in the launcher. But that's just a guess for now. For example, these are two of many pieces of information when Google Meet is deactivated in the Work Profile (=userId 10): 02-28 12:18:37.159 1167 31382 I PackageManager: setApplicationHiddenSettingAsUser, packageName: com.google.android.apps.tachyon, userId: 10, hidden: false, callingUid: 1000, callingPackage: system 02-28 12:18:40.827 1167 1367 I SettingsProvider: onPackageRemoved (userId 10) PackageName = com.google.android.apps.tachyonRe: (COPE) Hide app in work profile
Yunchuan Can you say what the customer's purpose is for “LEAVE_ALL_SYSTEM_APPS_ENABLED:true”? Is there a included non-system app that would otherwise not be available? Or is a certain system app simply no longer available in the Work Profile? Has the customer tested the policies with devices from another OEM? Can apps be deactivated correctly in the Work Profile? I don't know the current status at Ivanti regarding CustomDPC vs. AMAPI. If a CustomDPC is still in use, we actually have a good comparison with WorkspaceONE. However, I cannot reproduce the problems described. We have the option to blacklist apps. (For Work Managed and in the Work Profile) This uninstalls (non-system) apps. System apps are blocked and hidden. However, you can also explicitly enable system apps if, for example, they have been deactivated via the DPC Extra. For example, we would only need “LEAVE_ALL_SYSTEM_APPS_ENABLED:true” for Work Managed devices if an OEM supplies a non-system app that is not available in the PlayStore.Re: Why is the Google Play organization ID different depending on where you look?
okmickthere are good reasons why we are asking explicitly. So far, EMM registration, email and OrganizationID were a 1:1:1 relationship. It was simply impossible to have two EMM registrations or OrganizationIDs with one e-mail address. Therefore, there is no harm in double-checking this, even if you may see it differently. Hence two further questions: When did you do the EMM registration? Do you have a Managed Google domain? Because the only other thing that comes to mind is the topic: [Product Update] Configure and bind multiple Android Enterprise Mobility Management providers | Android Enterprise Customer Community - 910Re: (COPE) Hide app in work profile
I don't know the exact configuration in Ivanti (/Mobileiron) for blacklisting apps. For Android Enterprise / Work Profile you can set up an app control and block specific app IDs. If apps are disallowed via App Control, they can no longer be used in the Work Profile. This might help: https://help.ivanti.com/mi/help/en_us/cld/admin/ivanti/91/all/en-us/Allowed_apps.htmRe: Fleet device settings
Is there a way to use Custom Settings profile to set this on devices? The Custom Settings Profile in WS1 UEM has a rather specific purpose. WS1 UEM sends configurations (/profiles) as XML data to the CustomDPC (“Hub”). The Hub then applies the configuration to the device using the appropriate APIs. These XML data can be edited manually using the custom settings. This is usually used when new functions have been implemented in Hub but cannot yet be configured with the WS1 UEM interface. The custom settings can therefore only be used to set settings that are explicitly built into the Hub. Unfortunately, it is not possible to change individual system settings.Re: Managed Google Play private app not available on Corporate-owned devices with work profile
Are the two devices the same device type / device model? I've seen this kind of behavior in the past when an app is restricted to certain display sizes via manifest.xml. (I am thinking of this) Such apps could be installed manually as apk, but Google Play refused to install them. I am not aware that an app can be restricted to certain Android management modes via manifest.xml / Managed Play. A privateApp available for an OrganizationID is generally available to the UEM. The UEM then releases the app for certain GoogleUserIDs/GoogleDeviceIDs in the background, making the apps available on the devices in Managed Play. (at least with the EMM API) Either the app assignment is not quite right, or the app is not compatible with certain devices.Re: Why is the Google Play organization ID different depending on where you look?
I also suspect, like jasonbayton, that different Google accounts are being used for the comparison. Have a look in the Intune settings to see which Google account is used for the Managed Google Play / EMM registration. The OrganizationID from the iFrame belongs to this account. This should be the relevant organizationID for the software vendor.Re: Google Play services for AR (ARCore) is not available as a Managed Play Store app
dhitomi I did not see the app in the search results on unmanaged devices. The app is available for Managed Play, but since the app is probably excluded in the search, it cannot be explicitly assigned via MDM. For testing purposes, you could use the developer options of the web browser to trick the search in the iFrame and open the app entry in the iFrame. Open the Google Play iFrame Right-click on any store entry (image or text) -> Inspect Replace the AppID in the html-code with com.google.ar.core Open the modified link in the iFrame Original link <a href="/managed/apps/details?id=com.android.chrome"><div class="WsMG1c nnK0zc" title="Google Chrome">Google Chrome</div></a> Modified link <a href="/managed/apps/details?id=com.google.ar.core" data-focusid="19"><div class="WsMG1c nnK0zc" title="Google Chrome">Google Chrome</div></a>Re: How to obtain the eSIM EID (Embedded Identification Document) from a device with DO (Device Owner) active?
Michel I asked Samsung in January if they will add the EID retrospectively. We were not the first customer to ask, but I have not yet received a proper answer. With WorkspaceONE, we can also report the EID of Apple devices without any problems. For Android, the reporting of SIM cards still needs to be improved. I am curious to see if the EID can then also be reported there. Otherwise, the EID is often (Samsung & Pixel devices) printed as a barcode on the device boxes.Re: Google Play services for AR (ARCore) is not available as a Managed Play Store app
It looks as if the AR Core is generally excluded from the search results. Presumably because the installation is performed automatically in the background on compatible devices. Is the customer really sure that the app is not installed in the background? The AR Core is more of a headless app and does not have an app icon in the launcher. In my case, the AR Core is installed in all areas of BYOD devices / COPE devices. (Personal Space, Private Space, Work Profile) I don't have a fully managed device to hand at the moment.Re: How can I become Enter the Android Enterprise EMM community and become Android Enterprise Partner？
The reasons for a rejected application to the Partner Program can probably only be answered directly by Google. Maybe the requirements for the desired partner type are not met in the application. There are several partner types in the Partner Program. (OEMs, EMMs, Resellers, etc.) The requirements for each partner type can be found here: https://developers.google.com/android/enterpriseRe: Sporadic problems with Managed Google Play after enrollment
We have a workaround that works reliably for us. If we trigger an app installation command on an affected device via UEM, the problem is as soon as the command from UEM arrives at Google Play. You can see that something is happening in Google Play when the installation is triggered. All you have to do is close Play and reopen it. The collection is then displayed immediately.Re: Shared AFW device
A mutli-user setup is not very simple and the options may differ greatly depending on the UEM manufacturer. Work Managed is a basic requirement. You cannot use a Work Profile. I am aware of two technical approaches that could cover such scenarios. In both cases, the app from the UEM manufacturer locks the device and requires a user login to continue. If no user is logged in, a login screen for the user credentials is forced. The device is usually configured for a staging user. "Native Android Check-In Check-Out" With a native approach, a secondary user is set up on the device when logging in. The logged-in users therefore have a very native experience and the user data is very well separated from other users. However, I have no experience of whether the user is deleted again when they log out. If so, users may be busy setting up the apps for every shift. Multi-users are an optional feature for OEMs. Samsung, for example, has only implemented multiple users on tablets. Technical information about Multi-Users: https://developer.android.com/work/dpc/dedicated-devices/multiple-users "Kiosk App" Some UEM manufacturers have a kiosk application that can be used as an app launcher. Ideally, the app then has multi-user functionality. In this case, however, users do not have a native interface. It is also technically challenging for the manufacturer to ensure that all personal data is deleted when the user logs out. (Calls, messages, accounts, local files, etc.) I saw on your profile that you use Intune. Maybe someone here has experience of what Microsoft's solution looks like here. 😀Re: Do you really need a long pass code on Android?
Bigdogburr wrote: Periodic pass code changes (every 90 days, etc.): Not required. Only force changes when a known compromise is detected. In the past, I have seen quite wild actions by people who had to change their passwords every 90 days. Especially when people were prevented from using “too similar” passwords, passwords ended up on pieces of paper. Some of them were pinned directly to a computer screen. 🤓 I am glad that various security authorities have moved away from this recommendation and instead recommend more complex passwords. As a user, you don't necessarily know whether your own password for an account has been affected by a data leak. I think it's pretty good that Chrome warns you when logging in if it appears in a data collection. You can then change passwords accordingly.Re: Sporadic problems with Managed Google Play after enrollment
I was able to reproduce the problem today after several attempts. In the case of an issue, an update from Google Play seems to help. (Google Play > Settings > About > Update Play Store) On my test device, the problem was resolved about 3 minutes after enrollment. During this time, a Play Store update from 41.1.19-31 to 44.4.19-31 was installed. Since there is a workaround / solution, I will not open a ticket with Omnissa. They would most certainly not open a ticket with Google in that case. Flo If Ivanti has a ticket with Google and you need more logs, I could send you Verbose logs.
