merge

Author: ErikjeMS

memdocs/intune/apps/android-deployment-scenarios-app-protection-work-profiles.md

@@ -30,20 +30,20 @@ ms.custom: intune-azure;workProfilesUpdate
 
 ---
 
-# Application protection policies and personally-owned work profiles on Android Enterprise devices in Intune
+# Mobile Application Management and personally-owned work profiles on Android Enterprise devices in Intune
 
 In many organizations, administrators are challenged to protect resources and data on different devices. One challenge is protecting resources for users with personal Android Enterprise devices, also known as bring-your-own-device (BYOD). Microsoft Intune supports two Android deployment scenarios for bring-your-own-device (BYOD):
 
-- [App protection policies without enrollment (APP-WE)](../apps/android-deployment-scenarios-app-protection-work-profiles.md#app-we)
+- [Mobile Application Management (MAM)](../apps/android-deployment-scenarios-app-protection-work-profiles.md#mam)
 - [Android Enterprise personally-owned work profiles](../apps/android-deployment-scenarios-app-protection-work-profiles.md#android-enterprise-personally-owned-work-profiles)
 
-The APP-WE and the Android Enterprise personally-owned work profile deployment scenarios include the following key features important for BYOD environments:
+The MAM and the Android Enterprise personally-owned work profile deployment scenarios include the following key features important for BYOD environments:
 
 - **Protection and segregation of organization-managed data**: Both solutions protect organization data by enforcing data loss prevention (DLP) controls on organization-managed data. These protections prevent accidental leaks of protected data, such as an end user accidentally sharing it to a personal app or account. They also serve to ensure that a device accessing the data is healthy and not compromised.
 
-- **End-user privacy**: APP-WE and Android Enterprise personally-owned work profiles separate end users content on the device, and data managed by the mobile device management (MDM) administrator. In both scenarios, IT admins enforce policies, such as PIN-only authentication on organization-managed apps or identities. IT admins are unable to read, access, or erase data that's owned or controlled by end users.
+- **End-user privacy**: MAM separates end user and organization content in managed applications and Android Enterprise personally-owned work profiles separate end users content on the device, and data managed by the mobile device management (MDM) administrator. In both scenarios, IT admins enforce policies, such as PIN-only authentication on organization-managed apps or identities. IT admins are unable to read, access, or erase data that's owned or controlled by end users.
 
-Whether you choose APP-WE or Android Enterprise personally-owned work profiles for your BYOD deployment depends on your requirements and business needs. The goal of this article is to provide guidance to help you decide. For more information related to managed Android devices, see [Manage Android personally-owned/corporate-owned work profile devices with Intune](../enrollment/android-enterprise-overview.md).
+Whether you choose MAM or Android Enterprise personally-owned work profiles for your BYOD deployment depends on your requirements and business needs. The goal of this article is to provide guidance to help you decide. For more information related to managed Android devices, see [Manage Android personally-owned/corporate-owned work profile devices with Intune](../enrollment/android-enterprise-overview.md).
 
 ## About Intune app protection policies
 
@@ -65,11 +65,11 @@ To see a list of apps enabled with APP, see [managed apps with a rich set of mob
 
 ## Deployment scenarios
 
-This section describes the important characteristics of the APP-WE and Android Enterprise personally-owned work profile deployment scenarios.
+This section describes the important characteristics of the MAM and Android Enterprise personally-owned work profile deployment scenarios.
 
-### APP-WE
+### MAM
 
-An APP-WE (app protection policies without enrollment) deployment defines policies on apps, not devices. In this scenario, devices typically aren't enrolled or managed by an MDM authority, such as Intune. To protect apps and access to organizational data, administrators use APP-manageable apps, and apply data protection policies to these apps.
+A MAM deployment defines policies on apps, not devices. For BYOD, MAM is often used on unenrolled devices. To protect apps and access to organizational data, administrators use APP-manageable apps, and apply data protection policies to these apps.
 
 This feature applies to:
 
@@ -78,8 +78,6 @@ This feature applies to:
 > [!TIP]
 > For more information, see [What are app protection policies?](app-protection-policy.md).
 
-APP-WE scenarios are for end users who want a small organizational footprint on their devices, and don't want to enroll in MDM. As an administrator, you still need to protect your data. These devices aren't managed. So common MDM tasks and features, such as WiFi, device VPN, and certificate management, aren't part of this deployment scenario.
-
 ### Android Enterprise personally-owned work profiles
 
 Android Enterprise personally-owned work profiles are the core Android Enterprise deployment scenario and the only scenario targeted at BYOD use cases. The Android Enterprise personally-owned work profile is a separate partition created at the Android OS level that can be managed by Intune.
@@ -88,7 +86,7 @@ An Android Enterprise personally-owned work profile includes the following featu
 
 - **Traditional MDM functionality**: Key MDM capabilities, such as app lifecycle management using managed Google Play, is available in any Android Enterprise scenario. Managed Google Play provides a robust experience to install and update apps without any user intervention. IT can also push app configuration settings to organizational apps. It also doesn't require end users to allow installations from unknown sources. Other common MDM activities, such as deploying certificates, configuring WiFi/VPNs, and setting device passcodes are available with Android Enterprise personally-owned work profiles.
 
-- **DLP on the Android Enterprise personally-owned work profile boundary**: Like APP-WE, IT can enforce data protection policies. With a Android Enterprise personally-owned work profile, DLP policies are enforced at the work profile level, not the app level. For example, copy/paste protection is enforced by the APP settings applied to an app, or enforced by the work profile. When the app is deployed into a work profile, administrators can pause copy/paste protection to the work profile by turning off this policy at the APP level.
+- **DLP on the Android Enterprise personally-owned work profile boundary**: With a Android Enterprise personally-owned work profile, DLP policies are enforced at the work profile level, not the app level. For example, copy/paste protection is enforced by the APP settings applied to an app, or enforced by the work profile. When the app is deployed into a work profile, administrators can pause copy/paste protection to the work profile by turning off this policy at the APP level.
 
 ## Tips to optimize the work profile experience
 
@@ -102,9 +100,9 @@ Android Enterprise personally-owned Work profiles and APP complement each other'
 
 ### Suppress APP policy for Android Enterprise personally-owned work profiles
 
-You may need to support individual users who have multiple devices - unmanaged devices in an APP-WE scenario, and managed devices with Android Enterprise personally-owned work profiles.
+You may need to support individual users who have multiple devices - unenrolled devices with MAM managed applications and managed devices with Android Enterprise personally-owned work profiles.
 
-For example, you require end users to enter a PIN when opening a work app. Depending on the device, the PIN features are handled by APP or by the work profile. For the APP-WE devices, the PIN-to-launch behavior is enforced by APP. For work profile devices, you can use a device or work profile PIN enforced by the OS. To accomplish this scenario, configure APP settings so that they don't apply *when* an app is deployed into a work profile. If you don't configure it this way, the end user gets prompted for a PIN by the device, and again at the APP layer.
+For example, you require end users to enter a PIN when opening a work app. Depending on the device, the PIN features are handled by APP or by the work profile. For MAM managed applications, access controls including the PIN-to-launch behavior is enforced by APP. For enrolled devices, the APP PIN may be disabled to avoid requiring both a device PIN and an APP PIN. (APP PIN setting for [Android](../apps/app-protection-policy-settings-android.md#access-requirements). For work profile devices, you can use a device or work profile PIN enforced by the OS. To accomplish this scenario, configure APP settings so that they don't apply *when* an app is deployed into a work profile. If you don't configure it this way, the end user gets prompted for a PIN by the device, and again at the APP layer.
 
 ### Control multi-identity behavior in Android Enterprise personally-owned work profiles
 
@@ -131,7 +129,7 @@ For example, customers in or have users in China can't use Android device manage
 
 ## Summary
 
-Using Intune, both APP-WE and Android Enterprise personally-owned work profiles are available for your Android BYOD program. To choose APP-WE or work profiles depends upon your business and usage requirements. In summary, use Android Enterprise personally-owned work profiles if you need MDM activities on managed devices, such as certificate deployment, app push, and so on. Use APP-WE if you don't want or can't manage devices, and are using only Intune APP-enabled apps.
+Using Intune, both MAM and Android Enterprise personally-owned work profiles are available for your Android BYOD program. You can choose to use MAM and/or work profiles depending upon your business and usage requirements. In summary, use Android Enterprise personally-owned work profiles if you need MDM activities on managed devices, such as certificate deployment, app push, and so on. Use MAM if you want to protect org data within applications.
 
 ## Next steps
 [Start using app protection policies](app-protection-policy.md), or [enroll your devices](../enrollment/android-enroll.md).

memdocs/intune/apps/apps-add.md

@@ -77,7 +77,7 @@ You can add an app in Microsoft Intune by selecting **Apps** > **All apps** > **
 > An LOB app is one that you add from an app installation file. For example, to install an iOS/iPadOS LOB app, you add the application by selecting **Line-of-business app** as the **App type** in the **Select app type** pane. You then select the app package file (extension .ipa). These types of apps are typically written in-house or as a custom app.
 
 ## Assess app requirements
-As an IT Admin, you determine not only which apps your group must use, but you also determine the capabilities needed for each group and subgroup. For each app, you determine the platforms needed, the groups of users that need the app, the configuration policies to apply for those groups, and the protection policies to apply.  
+As an IT Admin, you determine not only which apps your group must use, but you also determine the capabilities needed for each group and subgroup. For each app, you determine the platforms needed, the groups of users that need the app, the configuration policies to apply for those groups, and the protection policies to apply. For example, for enrollment types including Android personally-owned work profile, you may want to deploy a web browsing app to make sure users will have a way to open links. 
 
 Additionally, you must determine whether to focus on Mobile Device Management (MDM) or only on Mobile Application Management (MAM). 
 

memdocs/intune/apps/apps-deploy.md

@@ -8,7 +8,7 @@ keywords:
 author: Erikre
 ms.author: erikre
 manager: dougeby
-ms.date: 12/16/2021
+ms.date: 02/28/2021
 ms.topic: how-to
 ms.service: microsoft-intune
 ms.subservice: apps
@@ -132,7 +132,8 @@ The information in the following table can help you understand the resulting int
 > When conflicts occur in **Uninstall on device removal** setting, the app is not removed from the device when the device is no longer managed.
 
 ## Managed Google Play app deployment to unmanaged devices
-For Android devices in a non-enrolled [App protection policies without enrollment (APP-WE)](../apps/android-deployment-scenarios-app-protection-work-profiles.md#app-we) deployment scenario, you can use Managed Google Play to deploy store apps and line-of-business (LOB) apps to users. Managed Google Play apps targeted as **Available with or without enrollment** will appear in the Play Store app on the end user's device, and not in the Company Portal app. End user will browse and install apps deployed in this manner from the Play app. Because the apps are being installed from managed Google Play, the end user will not need to alter their device settings to allow app installation from unknown sources, which means the devices will be more secure. If the app developer publishes a new version of an app to Play that was installed on a user's device, the app will be automatically updated by Play. 
+
+For unenrolled Android devices, you can use Managed Google Play to deploy store apps and line-of-business (LOB) apps to users. Once deployed, you can use [Mobile Application Management (MAM)](../apps/android-deployment-scenarios-app-protection-work-profiles.md#mam) to manage the applications. Managed Google Play apps targeted as **Available with or without enrollment** will appear in the Play Store app on the end user's device, and not in the Company Portal app. End user will browse and install apps deployed in this manner from the Play app. Because the apps are being installed from managed Google Play, the end user will not need to alter their device settings to allow app installation from unknown sources, which means the devices will be more secure. If the app developer publishes a new version of an app to Play that was installed on a user's device, the app will be automatically updated by Play. 
 
 Steps to assign a Managed Google Play app to unmanaged devices:
 

memdocs/intune/apps/data-transfer-between-apps-manage-ios.md

@@ -66,7 +66,7 @@ Configuring the user UPN setting is **required** for devices that are managed by
      > Additionally, the app needs to be either installed from the Intune Company Portal (if set as available) or pushed as required to the device. 
 
      > [!NOTE]
-     > Deploy IntuneMAMUPN app configuration settings to the target managed app which sends data, not the receiving app. 
+     > Deploy IntuneMAMUPN app configuration settings to the target managed app which sends data. Adding the app configuration key to the receiving app is optional. 
      
      > [!NOTE]
      > Currently, there is no support for enrolling with a different user on an app if there is a MDM enrolled account on the same device.