Merge branch 'main' into release-cm2203-tp

Author: v-alje

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-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 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#app-we) 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. 
+
+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/lob-apps-macos.md

@@ -39,13 +39,18 @@ ms.collection:
 Use the information in this article to help you add macOS line-of-business apps to Microsoft Intune. You must download an external tool to pre-process your *.pkg* files before you can upload your line-of-business file to Microsoft Intune. The pre-processing of your *.pkg* files must take place on a macOS device.
 
 > [!NOTE]
+> Uploading *.pkg* files in the **Add app** pane is in public preview.
+>
 > Starting with the release of macOS Catalina 10.15, prior to adding your apps to Intune, check to make sure your macOS LOB apps are notarized. If the developers of your LOB apps did not notarize their apps, the apps will fail to run on your users' macOS devices. For more information about how to check if an app is notarized, visit [Notarize your macOS apps to prepare for macOS Catalina](https://techcommunity.microsoft.com/t5/Intune-Customer-Success/Support-Tip-Notarizing-your-macOS-apps-to-prepare-for-macOS/ba-p/808579).
 > 
 > macOS LOB apps have a maximum size limit of 2 GB per app.
 > 
 > While users of macOS devices can remove some of the built-in macOS apps like Stocks, and Maps, you cannot use Intune to redeploy those apps. If end users delete these apps, they must go to the app store, and manually re install them.
 
-## Before your start
+## Before you start
+
+> [!NOTE]
+> Using the Intune App Wrapping Tool for Mac is not required when uploading *.pkg* files. Uploading *.pkg* files in the **Add app** pane is in public preview.
 
 You must download an external tool, mark the downloaded tool as an executable, and pre-process your *.pkg* files with the tool before you can upload your line-of-business file to Microsoft Intune. The pre-processing of your *.pkg* files must take place on a macOS device. Use the Intune App Wrapping Tool for Mac to enable Mac apps to be managed by Microsoft Intune.
 
@@ -87,10 +92,15 @@ You must download an external tool, mark the downloaded tool as an executable, a
 
 ## Step 1 - App information
 
+> [!NOTE]
+> Uploading *.pkg* files in the **Add app** pane is in public preview.
+>
+> The **minimum operating system** for uploading a *.pkg* file is macOS 10.14. Upload a *.intunemac* file to select an older minimum operating system.
+
 ### Select the app package file
 
 1. In the **Add app** pane, click **Select app package file**. 
-2. In the **App package file** pane, select the browse button. Then, select an macOS installation file with the extension *.intunemac*.
+2. In the **App package file** pane, select the browse button. Then, select an macOS installation file with the extension *.intunemac* or *.pkg*.
    The app details will be displayed.
 3. When you're finished, select **OK** on the **App package file** pane to add the app.
 
@@ -103,7 +113,7 @@ You must download an external tool, mark the downloaded tool as an executable, a
     - **Minimum Operating System**: From the list, choose the minimum operating system version on which the app can be installed. If you assign the app to a device with an earlier operating system, it will not be installed.
     - **Ignore app version**: Select **Yes** to install the app if the app is not already installed on the device. Select **No** to only install the app when it is not already installed on the device, or if the deploying app's version number does not match the version that's already installed on the device.
     - **Install as managed**: Select **Yes** to install the Mac LOB app as a managed app on  supported devices (macOS 11 and higher). A macOS LOB app can only be installed as managed when the app distributable contains a single app without any nested packages and installs to the */Applications* directory. Managed line-of-business apps will be able to be removed using the **uninstall** assignment type on supported devices (macOS 11 and higher). In addition, removing the MDM profile removes all managed apps from the device. The default value is **No**.
-    - **Included apps**: Review and edit the apps that are contained in the uploaded file. Included app bundle IDs and build numbers are used for detecting and monitoring app installation status of the uploaded file. Included apps list should only contain the application(s) installed by the uploaded file in **Applications** folder on Macs. Any other type of file that is not an application or an application that is not installed to **Applications** folder should be removed from the **Included apps** list. If **Included apps** list contains files that are not applications or if all the listed apps are not installed, app installation status does not report success.<br>Mac Terminal can be used to lookup and confirm the included app details of an installed app.<br>For example, to look up the bundle ID and build number of Company Portal, run the following:<br>    *defaults read /Applications/Company\ Portal.app/Contents/Info CFBundleIdentifier*<br>Then, run the following:<br>    *defaults read /Applications/Company\ Portal.app/Contents/Info CFBundleVersion*
+    - **Included apps**: Review and edit the apps that are contained in the uploaded file. Included app bundle IDs and build numbers are used for detecting and monitoring app installation status of the uploaded file. The app listed first is used as the primary app in app reporting. <br>Included apps list should only contain the application(s) installed by the uploaded file in **Applications** folder on Macs. Any other type of file that is not an application or an application that is not installed to **Applications** folder should be removed from the **Included apps** list. If **Included apps** list contains files that are not applications or if all the listed apps are not installed, app installation status does not report success.<br>Mac Terminal can be used to lookup and confirm the included app details of an installed app.<br>For example, to look up the bundle ID and build number of Company Portal, run the following:<br>    *defaults read /Applications/Company\ Portal.app/Contents/Info CFBundleIdentifier*<br>Then, run the following:<br>    *defaults read /Applications/Company\ Portal.app/Contents/Info CFBundleShortVersionString*
     - **Category**: Select one or more of the built-in app categories, or select a category that you created. Categories make it easier for users to find the app when they browse through the company portal.
     - **Show this as a featured app in the Company Portal**: Display the app prominently on the main page of the company portal when users browse for apps.
     - **Information URL**: Optionally, enter the URL of a website that contains information about this app. The URL appears in the company portal.
@@ -146,8 +156,9 @@ The app you have created appears in the apps list where you can assign it to the
 
 [!INCLUDE [shared-proc-lob-updateapp](../includes/shared-proc-lob-updateapp.md)]
 
-> [!NOTE]
-> For the Intune service to successfully deploy a new *.pkg* file to the device you must increment the package `version` and `CFBundleVersion` string in the *packageinfo* file in your *.pkg* package.
+To update a line-of-business app deployed as a *.intunemac* file, you must increment the package `version` and `CFBundleVersion` string in the *packageinfo* file in your *.pkg* file.
+
+To update a line-of-business app deployed as a *.pkg* file, you must increment the `CFBundleShortVersionString` of the *.pkg* file.
 
 ## Next steps