• • Work profile – in this mode of management the end user self-initiates enrollment with a device they own. The enrollment process creates a new, MDM-managed work profile on the device that sits alongside the user's personal profile. The work profile is managed by the IT admin and the personal profile is not. This provides both privacy assurances to end users because their personal profile remains unmanaged, and data protection assurances to the IT admin because the work content is containerized and manageable.

• Device owner – in this mode the device is fully managed (it is analogous to supervised mode on an iOS device). Device owner mode is unique in that there are two main deployment scenarios that can be configured when devices are in this mode: Dedicated devices, which are userless, heavily-locked down kiosk-style devices ideal for task worker usage, and Fully Managed devices which are associated with and user's AAD account and are intended for core productivity usage (calling, messaging, Outlook, Office apps, and so on). Enrollment of device owner devices is also unique in that the device must be fully factory reset to be enrolled.

1. 1. Blank NFC tags. I used NTAG216 NFC tags, however you may use any tags that you'd like. One thing to remember is NFC cards come with varying amounts of capacity in bytes. You'll want to be sure that you buy ones with enough byte capacity to store all the NFC data necessary for enrollment. The amount of capacity you'll need varies depending on how many options you put into your NFC data, but at minimum you'll need 561 bytes. More will be required if you add Wi-Fi connection options. The NTAG216 tags I used have a usable capacity of 888 bytes.

1. Once you have the blank tags, you'll need something to imprint/write the correct data onto the tags. You may use any NFC tool that you choose as long as it's capable of writing NFC tags with an arbitrary mimetype. I demonstrate the process later in this post using the NFC Tools PRO app from the Play Store.

• The NFC data that will be written to the NFC tags needs to be of a very specific format and will contain a lot of boilerplate data.
• There is a portion of the tag data that you can copy and paste directly from this post because it will be identical for every Intune enrollment.
• There is also part of the tag data that must be changed to match the enrollment token generated in your Intune tenant.
• Finally, there are optional NFC data parts that you can choose to use if you want to use the tag to automatically turn on Wi-Fi during the NFC provisioning process.

android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION=https\://play.google.com/managed/downloadManagingApp?identifier\=setup android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM=I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME=com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver

android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE=com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN\=NMEFNXHOVYMEMSSLBRSR

android.app.extra.PROVISIONING_WIFI_SSID="MSFTGUEST" android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE=NONE android.app.extra.PROVISIONING_WIFI_PASSWORD=

1. Under the Write tab, select Add a record
2. Scroll to the bottom and select Data: Add custom record
3. In the content-type field enter "application" in the first text box and then "com.android.managedprovisioning" in the second (without the quotes)

android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION=https\://play.google.com/managed/downloadManagingApp?identifier\=setup android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM=I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME=com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE=com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN\=LSKDINVIGHNCTXNZQDIS android.app.extra.PROVISIONING_WIFI_SSID="MSFTGUEST" android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE=NONE android.app.extra.PROVISIONING_WIFI_PASSWORD=

1. In the Data: field enter the big NFC data blob that you formatted in the step above. It should look close to this:
2. Tap OK

1. Tap Write
2. Bump your device against your blank NFC tag

1. Factory reset the device (this is a necessary step for any device owner provisioning)
2. Once the device is reset and is on the initial welcome screen, bump the device against your NFC tag
3. Tap OK

1. Navigate to portal.azure.com, locate and select Azure Active Directory
2. Select Groups > New group
3. Group type should = Security
4. Provide a name for the group such as "Android Enterprise Kiosk Profile"
5. Membership type = Dynamic device
6. Select Dynamic device members

1. Find and select Microsoft Intune from portal.azure.com
2. Under device enrollment > Android enrollment select "Kiosk and task device enrollments"
3. Create a new enrollment profile by selecting "Create"
4. Provide a name and select an expiration date for the Token (this can be used to register devices with a token or QR code if necessary)

1. Navigate to the Managed Google Play account by selecting Mobile apps > Managed Google Play > Open the managed Google Play store
2. Search for and add the "Managed Home Screen" app and additional apps you'd like on the locked task screen for the device.
3. Sync with Managed Google Play within Intune and assign the apps and/or weblinks to the kiosk group created earlier.

1. Under Mobile apps in Intune, assign the apps to the Azure AD group we created earlier ("Kiosk and task device enrollments" in my case), including assigning the Managed Home Screen.
2. In the configuration profile we'll create next, under kiosk add the same apps, except the Managed Home Screen (leave the Managed Home Screen out of the configuration profile).

1. Within Intune select Device configuration > Profiles > Create Profile
2. Select Properties > Platform = Android Enterprise, Profile type = Device restrictions
3. Under settings select Kiosk > Kiosk mode: either select Multi-app or Single app kiosk. For this post I've selected Multi-app kiosk.
4. Select Add and add the apps previously added to Managed Google Play that were synced with Intune. Remember, do not add the Managed Home Screen app (otherwise it will show up as an app on the screen of the kiosk device which isn't necessary).

Tap on the screen six times
	I tapped 5 times and it's asking me for 1 more tap
Needs to download the QR reader app before QR code scan	Connect to Wi-Fi so we can download the QR reader
Once connected to Wi-Fi the device checks for updates	Downloading Google Play Store
Checking device info…	Installing QR Reader
Once the QR Reader is installed it will use the camera to scan the QR code under the Android enterprise enrollment profile created earlier	QR code is accepted and we're prompted to continue setting up the device.
Updating the Google Play Store again which is connecting to the Managed Google Play store	Downloading Google Play services…
Uploading Google Play services…	Finish device updates
Registering the device with Intune	Intune device configuration policy we created earlier is now applied
The Managed Home Screen is applied and the apps we assigned earlier are shown on the locked down kiosk screen.

• Windows 10, 1709 or later
• PowerShell

Did you know that Microsoft Operations Management Suite (OMS) offers many other management and monitoring solutions including update management for Windows, Surface Hub monitoring, Security and Audit information and many more. For more details please visit: https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-add-solutions

If you’re utilizing Microsoft Cloud App Security in your environment today and would like to learn more about automatic log upload for continuous Cloud App Security reports please visit: https://docs.microsoft.com/en-us/cloud-app-security/discovery-docker

The following walks through setting up the Container Monitoring Solution in Azure to monitor a Docker container used for Cloud App Security automatic log upload hosted on an Azure VM.

Requirements

• Microsoft Azure
• Microsoft Operations Management Suite (OMS)
• Docker running on the platforms listed here: https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-containers
  

Assumptions for this post

• Docker containers are deployed for use with Cloud App Security automatic log upload: https://docs.microsoft.com/en-us/cloud-app-security/discovery-docker

Let’s get started…

Here’s a look at the Ubuntu VM with Docker used for Cloud App Security automatic log upload:

If you have an Azure subscription log in, select “new” from the upper left, and search for “container monitoring solution”:

Select Container Monitoring Solution and Create to add it to your OMS workspace:

Once the instance of Container Monitoring Solution is added, sign-on to your host where the containers are deployed and follow the instructions to install the OMS agent used for monitoring the host: https://github.com/Microsoft/OMS-docker#supported-linux-operating-systems-and-docker

You’ll run a script that is discussed in the link above to install the OMS agent:

Once the installation in complete, navigate back to the OMS admin portal and look for a new tile called “Container Monitoring Solution”:

Select the tile and view the status of the containers on the host:

From the information provided, I can see I have a failure with my Cloud App Security Log Collector (i.e. I named the container “LogCollector”)

When we drill down into the failure I can see that the which container is failing and other details:

Monitoring Docker containers using Microsoft OMS as well as the containers used for log collection for Cloud App Security was really simple and I encourage everyone to deploy OMS today.]]> https://docs.microsoft.com/archive/blogs/cbernier/add-windows-defender-browser-protection-to-chrome-with-intune Wed, 25 Apr 2018 19:56:57 GMT https://blogs.technet.microsoft.com/cbernier/?p=8215 I recently read a really great post by Martin Bengtsson about utilizing Configuration Manager (SCCM) to force installation of the Windows Defender Browser Protection extension for Chrome. So I decided to take a different approach and deploy the extension utilizing a PowerShell script deployed through Microsoft Intune.

To learn more about the Windows Defender Browser Protection for Google Chrome please visit: https://chrome.google.com/webstore/detail/windows-defender-browser/bkbeeeffjjeopflfhgeknacdieedcoml

Assumptions

Windows 10 device enrolled in Intune

Let’s get started

I created the following PowerShell script to add the Defender Chrome extension as a registry entry:

New-Item -Path HKLM:\Software\Policies\Google\Chrome -Name ExtensionInstallForcelist –Force

$RegKey ="HKLM:\Software\Policies\Google\Chrome\ExtensionInstallForcelist"

Set-ItemProperty -path $RegKey -name 1 -value "bkbeeeffjjeopflfhgeknacdieedcoml;https://clients2.google.com/service/update2/crx"

I saved the script as a .ps1 file and added to Intune utilizing the steps below:

Name the script, upload, and save

Assign the script to a group

Sync your Windows 10 device with Intune

Sync the device with Intune 

Registry Before sync

Chrome without Defender browser protection

Registry after sync

Chrome with Defender browser protection

Once Chrome is launched, the extension is automatically downloaded to the extension directory and added to Chrome.

Chrome extension directory

In addition to configuration, Configuration Manager will also perform remediation if this is something you’re more concerned with, SCCM is the best path to go currently. Again read Martin Bengtsson’s detailed post for insight on deploying and remediating for the Windows Defender Browser Protection for Chrome extension through SCCM.]]> https://docs.microsoft.com/archive/blogs/cbernier/windows-10-group-policy-vs-intune-mdm-policy-who-wins Mon, 02 Apr 2018 21:35:31 GMT https://blogs.technet.microsoft.com/cbernier/?p=7995  

When I speak with organizations about managing Windows 10 devices with Microsoft Intune there is a concern about disruption of current projects to deploy new OSs, patches, etc.  When moving to Intune for managing Windows devices, Intune will leverage the built-in MDM agent vs. having to install another agent to manage Windows 10 devices.

With modern management of Windows 10, the process of updating and upgrading Windows 10 devices is seen as continual process.  Updating Windows doesn’t have to be seen a massive project, evaluate your current processes for updating Windows and look at updating Windows 10 as an ongoing predictable process for IT and end users.  In addition your users and company benefit from the latest security features built into Windows 10.

Managing Windows policies are also a concern when moving to a newer OS.  Traditionally, configuration policies are managed by Group Policy, however Modern Management of Windows 10 with Microsoft Intune also has a set of policies, even policies that are duplicative of Group Policy (where applicable, not all Group Policies are available via MDM or CSP).  In environments where Group Policies are deployed and managed by Intune there’s the question of which policy wins.  The following describes which policy wins according to Windows 10 version.

• Windows 10 versions 1709 and earlier Group Policy will override MDM policies, even if an identical policy is configured in MDM.
  
  
• Windows 10 version 1803 and beyond there is a new Policy CSP setting called ControlPolicyConflict that includes the policy of MDMWinsOverGP, where the preference of which policy wins can be controlled, i.e. Microsoft Intune MDM policy.

For more details about the new ControlPolicyConfict setting please visit: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-controlpolicyconflict#controlpolicyconflict-mdmwinsovergp

What happens to the policy if the device is unenrolled from Intune?  If applicable, Group Policy will re-apply the policies in this scenario.

Setting up a policy

In the link above, the “scope” of the policy is set for “device” so we’ll need to target the policy at the device scope. 

To learn more about user and device scopes please visit: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-configuration-service-provider#policy-scope 

Since the ControlPolicyConfict policy applies to the device, we’ll have to utilize the following string: ./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName to configure the policy. 

 

Next replace AreaName/PolicyName with ControlPolicyConflict/MDMWinsOverGP

After the modification to the string, the policy should look like the following: ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP

Creating the policy

Let’s create a new policy in Intune to control the GP vs. MDM winner

1. Navigate to portal.azure.com and locate Intune
2. Select “Device configuration à Profiles à Create profile”
3. Under Platform select Windows 10 and later
4. Under Profile type select “custom” and “add”
5. Name the custom setting with something intuitive
6. For OMA-URI add the policy OMA-URI string: ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP
7. For Data type select Integer and add the number 1

Supported values for this policy are as follows:

0 (default)

1 - The MDM policy is used and the GP policy is blocked.

Let’s take a look how the policy is applied

1. On the Windows 10 device, select the Windows icon > Settings > Accounts > Access work or school à under the account name select Info
2. Sync with Microsoft Intune by selecting “Sync”
3. Once the Sync as completed select “Create report”

• Once the report is completed a folder will open containing an .html file
• Open the .html report and search for “MDMwins”

GP Setting before the MDM policy takes place :

MDM setting after the policy is applied (note: Windows 10 1803 is required to override the GP):

Let’s take a look at a report in Intune regarding the policy and if it was successfully applied.  This useful to make sure the policies are actually applying or not.

Logging

Being able to investigate modifications to a device is extremely important, especially when troubleshooting. 

In event viewer we can access the event where the policy was applied as shown below.  However digging through events, especially across multiple devices, can be a difficult process.  This is where Microsoft Operations Management Suite (OMS) comes in.

Logging with Microsoft Operations Management Suite (OMS)

Within OMS there is the Log Analytics solution to manage logs from devices with the OMS agent installed.  I won’t go into details about installing the OMS agent, however I will say it’s straight forward.  Once the agent is installed (which I have it installed on all my devices so I can look at label changes with Azure Information Protection (see my previous post) and other aggregated information) we’ll need to grab the proper even log source name and populate that in Log Analytics.

Find and copy the event log source or name: Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider

Paste the event log path in Log Analytics to “Windows Event Logs under Settings > Data > Windows Event Logs” as shown below:

Give the logs a few minutes to sync from the device to OMS, then run the query below in log analytics analyzer and look for the MDMWinsOverGP policy created above:

For more details about Windows 10 MDM logging please visit: https://docs.microsoft.com/en-us/windows/client-management/mdm/diagnose-mdm-failures-in-windows-10

Evaluating existing Group Policies to determine migration to MDM

Use the MDM Migration Analysis Tool (MMAT) to evaluate which Group Policies have been set for a target user/computer and cross-reference against its built-in list of supported MDM policies.

Download the MDM Migration Analysis Tool (MMAT): https://github.com/WindowsDeviceManagement/MMAT

For additional details about creating custom ADMX policies please view the following two great videos:

Enable ADMX backed policies in Intune: https://www.microsoft.com/en-us/videoplayer/embed/bdc9b54b-11b0-4bdb-a022-c339d16e7121

 

ADMX backed policy import example: https://www.microsoft.com/en-us/videoplayer/embed/a59888b1-429f-4a49-8570-c39a143d9a73

Keep up to date with MDM policies and other features via What’s new in MDM enrollment and management

https://docs.microsoft.com/en-us/windows/client-management/mdm/new-in-windows-mdm-enrollment-management

That’s it, we’ve learned that there is a new policy added to Windows 10 1803 that will control if MDM policies win over Group Policies (where applicable, not all Group Policies are available via MDM or CSP), how to investigate policies via event viewer, and aggregate those logs using Log Analytics (OMS).

Organizations using Windows Information Protection (WIP) may experience issues accessing the Intune Company Portal app.  Fortunately, exempting Intune Company Portal app and any other application from a WIP policy is straight forward.

To learn more about creating Windows Information Protection policies please visit: https://docs.microsoft.com/en-us/windows/security/information-protection/windows-information-protection/create-wip-policy-using-mam-intune-azure

Let’s get started

By exempting an application the following pertains:

If you're running into compatibility issues where your app is incompatible with WIP, but still needs to be used with enterprise data, you can exempt the app from the WIP restrictions. This means that your apps won't include auto-encryption or tagging and won't honor your network restrictions. It also means that your exempted apps might leak.

Source: https://docs.microsoft.com/en-us/windows/security/information-protection/windows-information-protection/create-wip-policy-using-mam-intune-azure#add-apps-to-your-allowed-apps-list

Since the Intune Company Portal App doesn’t store any sensitive company data, exempting it shouldn’t be an issue, however always check in with your security team to make sure.

The first step to exempting the Intune Company Portal App for Windows is to locate the app in the store.  I’ve done this for you below and even though the app may be accessed from the consumer and business store, all we really care about is the AppID at the end, i.e. “9wzdncrfj3pz”. 

As we can see, the AppID is the same regardless of what portal it was accessed from:

Windows Store Intune Company Portal app: https://www.microsoft.com/en-us/store/p/company-portal/9wzdncrfj3pz

Windows Store for Business Intune Company Portal app: https://businessstore.microsoft.com/en-us/store/details/company-portal/9wzdncrfj3pz

Creating the WIP exemption policy

To create an app policy within Intune to exempt the Intune Company Portal app navigate to portal.azure.com à Intune à Mobile Apps à App protection policies à Add a policy

1. Give the policy a name and select Exempt apps
2. Select Add apps
3. From the drop-down menu select Store apps

At this point you’ll need to have some information handy about the app.  Fortunately, there is an easy method of extracting this data using the URL below.  I’ve already accessed the URL below; however, you can do this for any store app to find the name, publisher info, and product name.

Access following and replace the ID with the ID of the app you’d like to exempt, in this case, the Intune Company Portal app ID: 9wzdncrfj3pz

https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9wzdncrfj3pz/applockerdata

For more details about accessing app package info please visit: https://docs.microsoft.com/en-us/windows/client-management/mdm/get-product-package 

The following is the output you’ll see in the browser in JSON format:

{

  "packageFamilyName": "Microsoft.CompanyPortal_8wekyb3d8bbwe",

  "packageIdentityName": "Microsoft.CompanyPortal",

  "windowsPhoneLegacyId": "0b4016fc-d7b2-48a2-97a9-7de3b5ea7424",

  "publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"

}

Now that we have the JSON information about the Intune Company Portal store app (using the URL above), we need to add that data to the policy as shown below. 

Once finished adding the information, select OK and assign the policy.  On the Windows device, either wait for your devices to sync with Intune of force a sync from Settings à Accounts à Access work or school.

Once the policy updates you’ll be able to access the Intune Company Portal app:

If you’re interested, I go into detail about WIP a previous post: https://blogs.technet.microsoft.com/cbernier/2017/05/19/windows-information-protection-explained-windows-10-creators-update/ 

That’s it, if you’re not utilizing Windows Information Protection today, I highly encourage everyone to look into the benefits of protecting corporate information across personal and corporate owned devices with Intune, including Windows, iOS, and Android.