Android + Intune = Android management

When I speak with organizations who are considering Android devices there’s usually the question of, “which management option should we choose?”. The answer to the question requires a clear understanding of the scenarios the organization would like to bring under management such as personal devices or corporate devices or even purpose-built devices (e.g. inventory scanners, digital signage, etc.).

There are many different versions of Android from many different OEMs and choosing and supporting each version can be challenging. However, as I’ll discuss later in this post, Android enterprise aims to address OEM fragmentation while providing a variety of management options. Fortunately, Microsoft Intune will address various Android management methods available today including those offered with Android enterprise, so let’s look at how Android management is accomplished with Intune.

The table below walks through each available Android device management scenario, how Microsoft Intune supports it, as well as items to evaluate when considering each option.

Device Management Type Enrollment Type Intune Management
Android Device Admin
Considered legacy administration, the Android device administration API has provided APIs to manage the Android device since Android 2.2. The issue with device admin is there are only so many management APIs available, the user experience is challenging, and according to Google, device admin will be depreciated in 2019. With Android Q, device admin will not be available at all.Device Admin requires an Android device to be enrolled via an MDM and requires various administrator permissions during certain enrollment scenarios. As such, device admin offers insufficient privacy for BYOD, insufficient management capabilities for corporate owned devices, and a poor user experience all around. In addition, device admin is less secure than Android enterprise and device admin is not ideal for an environment requiring minimal or no touch enrollment.To learn more about device admin deprecation please visit: https://developers.google.com/android/work/device-admin-deprecation
Intune supports devices enrolled with device admin on Android 4.4+

To enroll a device to Intune using device admin please visit: https://docs.microsoft.com/en-us/intune-user-help/enroll-your-device-in-intune-android

In addition, Intune App Protection policies are supported with device admin (or without enrollment): https://docs.microsoft.com/en-us/intune/app-protection-policy

For BYOD, Intune App Protection policies are a great choice as the policies protect the corporate data at the app layer without requiring the user to enroll their device.

Samsung KNOX Standard
With Samsung devices, Samsung added their own management APIs which expands the management capabilities for devices enrolled with device admin.  An example is managing the email profile for the native email app on a Samsung device.KNOX is only available with certain Samsung devices so utilizing other OEM devices would require device admin or Android enterprise.Note: Samsung has announced the unification of KNOX and Android enterprise. More details may be found here: https://www.samsungknox.com/en/blog/android-enterprise-and-samsung-knox-your-questions-answered-hereSamsung also offers KNOX Mobile Enrollment (KME) which allows for automatic enrollment of devices even after a reset. KME is supported starting with Android 2.4 and KME is beneficial for mass enrollment of devices without having to touch each one. Devices may be manually and/or added through a carrier to an MDM. After which, users will experience a streamlined enrollment process which removes the touch points required by device admin.KNOX Mobile Enrollment is only available with Samsung devices so if no touch enrollment is needed for other device OEMs, Android enterprise may be an option.To learn more about KNOX Mobile Enrollment please visit: https://www.samsung.com/us/business/solutions/samsung-knox/mobile-security-solutions/knox-mobile-enrollment/
Intune supports KNOX standard without additional licensing for KNOX. However, KNOX also requires Device Admin enrollment as well. Once a device is enrolled with an MDM the end user will also see prompts about KNOX after which both device admin and KNOX policies may be deployed to the device. KNOX Mobile Enrollment streamlines the enrollment process by enrolling the device automatically.

To learn more about enrolling a device that supports Samsung KNOX with Intune please visit: https://docs.microsoft.com/en-us/intune/android-enroll#end-user-experience-when-enrolling-a-samsung-knox-device

In addition, Intune App Protection policies are supported with Samsung KNOX: https://docs.microsoft.com/en-us/intune/app-protection-policy

Intune supports KME and to learn more about setting up KME with Intune please visit: https://docs.microsoft.com/en-us/intune/android-samsung-knox-mobile-enroll

In addition, Intune App Protection policies are supported with devices enrolled with KME: https://docs.microsoft.com/en-us/intune/app-protection-policy

Up to this this point we’ve reviewed traditional management methods available on Android as well as enrolling and managing Android devices with Intune. However, if you’ve noticed, there seems to be a theme throughout and it’s around Android enterprise. It appears all paths are leading to Android enterprise so let’s learn about what Android enterprise is and how Intune will assist with managing devices enrolled using Android enterprise.

Android enterprise

There are two primary modes of management under Android enterprise (AE). Work profiles for BYOD and Device Owner for corporate owned devices.  More details on Android Enterprise device ownership please visit: https://developers.google.com/android/work/requirements 

Android enterprise
Android enterprise (AE) offers a variety of management scenarios for certified devices providing more robust management APIs over device admin. Although Android enterprise is supported on Android 5.0+, Google recommends 6.0 or later.Once a device is enrolled in an MDM such as Intune, Android enterprise has the concept of a work profile (formerly Android for Work) that separates or containerizes corporate applications and data on a personal device. The managed profile contains corporate data and allows only applications within the work profile to access the data within while leaving personal data separate. To learn more about work profiles please visit: https://support.google.com/work/android/answer/6191949?hl=enIn addition to work profiles, Android enterprise offers Device Owner mode where corporate owned devices are enrolled with an MDM and managed based on the purpose their intended for. To learn more about Android enterprise management for company-owned devices please visit: https://www.android.com/enterprise/management/To provision the device owner mode the device must be factory reset, unfortunately there are no migration paths to device owner mode from device admin. The provisioning process may be driven by NFC, QR code, or zero-touch. Previous versions of Android such as 5.0 and 5.1 can use an activation code to begin the enrollment process.For more details about device provisioning please visit: https://developers.google.com/android/work/prov-devicesTo learn more about AE management scenarios please visit: https://www.android.com/enterprise/management/Note: as stated previously, moving from device admin to Android enterprise requires a factory reset. Consider the ramifications of already deployed devices to end users and in the workplace before beginning a migration. A strategy of enrolling new devices with device owner while continuing to manage existing devices enrolled with device admin may be an option. Through attrition, devices will onboard using Android enterprise. As mentioned earlier, with Android Q, device admin will not be an option.
Intune supports Android enterprise purpose-built device management including single-use and work profiles which aligns with many organizational use cases.

Details on how to configure Intune to and manage devices supporting Android enterprise are below.

Management of Android enterprise managed profiles and other details may be found here: https://docs.microsoft.com/en-us/intune/android-enterprise-overview

Connect Intune to Android enterprise:

https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

Android enterprise single-use (Kiosk) devices Intune enrollment: https://docs.microsoft.com/en-us/intune/android-kiosk-enroll

In addition, Intune App Protection policies are supported with Android enterprise: https://docs.microsoft.com/en-us/intune/app-protection-policy

Applications, including LOB apps are published through managed Google play.

Selecting an enrollment option

Choosing an enrollment option really depends on the scenario and what your business requires. For example, if your devices require minimal or no touch enrollment you may consider KNOX Mobile Enrollment and/or Android enterprise. Since Android enterprise appears to be OEM agnostic, if the plan is to have various device OEMs deployed, devices supporting Android enterprise may be an option. However, if devices are used for kiosk, digital signage, ticket printing, inventory scanning, Android enterprise would be something to investigate as well. If devices are personal devices (BYOD), I recommend looking at Intune App Protection for unenrolled devices and/or Work Profiles. Lastly, before selection consider the short- and long-term ramifications of one option over another.

That’s it! We’ve reviewed the options available for Android enrollment and Intune, documentation on how to enroll Android devices, and the future of Android management through Android enterprise.

Windows Autopilot – check those logs…

Windows Autopilot is a Windows 10 feature that enables organizations to pre-register devices either through an OEM or manually.  When users receive a Windows 10 device that is registered with Autopilot and turn it on, they’ll walk through a streamlined and customized out of box experience (OOBE).  In summary, Autopilot helps to reduce the costs (and in some cases, infrastructure) of deploying devices to users.

If Autopilot were to run into an error there are several methods to check what and why issues occurred. Michael Niehaus has several posts about troubleshooting Autopilot including a recent blog post outlining new methods of accessing information to investigate Autopilot. Refer to Michael’s posts for detailed information on how to troubleshoot Autopilot.

In this post I’m sharing a simple script I wrote (based on the info Michael Niehaus outlined in his post) to view aggregated information about Autopilot from the registry and event viewer. In addition to registry and event viewer info, deeper investigation steps may be pursued with ETW.

 

Let’s get started

Requirements

  • Windows 10, 1709 or later
  • PowerShell


PowerShell Script

Feel free to modify the script to suite your needs such as remotely pull information from devices, etc.

The script is straight forward, first it looks for the Windows 10 version, i.e. 1709, and if it’s greater than or equal to “1709” it runs through both steps and pull registry and event logs. If the installed OS is greater than “1709” it will only pull event logs for 1709 as registry entries didn’t show up until 1803. Lastly, the script only pulls the latest 10 events, however that is easily modified.

 

#Get Windows Version
$WinVersion = (Get-ItemProperty -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion” -Name ReleaseId).ReleaseId
Write-Host “”
Write-Host WindowsVersion= $WinVersion

if ($WinVersion -ge ‘1709’)

{
Write-Host “”
Write-Host “AutoPilot Registry Entries”
Get-ItemProperty ‘HKLM:SOFTWAREMicrosoftProvisioningDiagnosticsAutoPilot’
}

if ($WinVersion -gt ‘1709’)

{
#Show AutoPilot events
Write-Host “AutoPilot Event Logs”
Write-Host “”
Get-WinEvent -MaxEvents 10 -LogName ‘Microsoft-Windows-Provisioning-Diagnostics-Provider/AutoPilot’
}

 

Let’s see it in action:

Below are the results of a device not deployed with Autopilot.  As we can see there’s not much to look at or troubleshoot…

clip_image002[6]

Let’s take a look at a device deployed with Autopilot (notice the new setup screen that shows up in 1803)

clip_image003

The results of the script shows more information that may be utilized when troubleshooting Autopilot errors:

clip_image004[6]clip_image005

Microsoft Cloud App Security log collector + OMS = Docker container monitoring

Need a quick method to monitor Docker containers? How about monitoring the Docker container that is utilized for automatic log upload for Microsoft Cloud App Security? If so, try out Microsoft OMS Container Monitoring Solution to monitor your docker containers including continuous log collectors using Docker in Microsoft Cloud App Security! 

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

Assumptions for this post

 

Let’s get started…

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

clip_image002

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

clip_image004

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

clip_image006

clip_image008

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:

clip_image010

 

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

clip_image012

 

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

clip_image014

clip_image016

clip_image018

 

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”)

clip_image020

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

clip_image022

 

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.

Add Windows Defender Browser Protection to Chrome with Intune

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:SoftwarePoliciesGoogleChrome -Name ExtensionInstallForcelist –Force

$RegKey =”HKLM:SoftwarePoliciesGoogleChromeExtensionInstallForcelist”

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:

clip_image001

Name the script, upload, and save

clip_image002[4]

Assign the script to a group

clip_image003

Sync your Windows 10 device with Intune

clip_image004[4]

Sync the device with Intune 

clip_image005

Registry Before sync

clip_image006[4]

Chrome without Defender browser protection

clip_image007

Registry after sync

clip_image008[4]

Chrome with Defender browser protection

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

clip_image009

Chrome extension directory

clip_image010[4]

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.

Windows 10 Group Policy vs. Intune MDM Policy who wins?

 

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.

 

 

 

image

 

image

 

 

 

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”

 

image

 

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

 

image

 

GP Setting before the MDM policy takes place :

clip_image007

 

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

image

 

 

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.

 

image

 

 

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.

 

 image

 

 

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

 

image

 

image

 

 

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

 

image

 

 

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:

 

image

 

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).

 

 

Windows Information Protection – adding the Intune Company Portal for Windows as an exempt app

As of January 2019 this is no longer necessary as the Intune Company Portal app is now included in the default list of protected apps.



2019-01-03_12-52-07

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.

 

image

 

 

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

 

image

 

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.

 

Scan file servers, network shares, and SharePoint with Azure Information Protection Scanner

 

With GDPR just around the corner (May 2018), organizations are heads down identifying data, creating compliance processes, and hiring additional resources to lead the compliance and reporting required by GDPR.

In a previous post I reviewed GDPR as well as the technologies and services Microsoft offers to assist with discovery, managing, protecting, and reporting on data.

For this post I’ll expand on the topic of scanning file servers and SharePoint servers using a the Azure Information Protection Scanner or AIP Scanner.

 

Scanning SharePoint Server and File Shares

Azure Information Protection includes a scanning tool called the Azure Information Protection scanner or AIP scanner.  The AIP scanner is used to comb through file shares and SharePoint and identity and/or classify + protect data.

 

The scanner runs as a service on Windows Server and lets you discover, classify, and protect files on the following data stores:

  • Local folders on the Windows Server computer that runs the scanner.

  • UNC paths for network shares that use the Common Internet File System (CIFS) protocol.

  • Sites and libraries for SharePoint Server 2016 and SharePoint Server 2013.

Source: https://docs.microsoft.com/en-us/information-protection/deploy-use/deploy-aip-scanner 

 

Once the AIP scanner is deployed, use it to report on information you’re looking for and when discovery is complete, run the AIP scanner and apply classification with or without protection across those files.

The classification labels and encryption policies come from the Azure Information Protection service in Azure.  Labels may be defined with or without encryption.  At a minimum I recommend all information at least be classified.  To learn more about creating classification labels using Azure Information Protection please visit: https://docs.microsoft.com/en-us/information-protection/understand-explore/what-is-information-protection

 

I won’t go through the details of installation process as it’s clearly documented in the link I provide below.  However, the output below is from a scan I completed using the AIP scanner against a few sample files.  The AIP scanner will look for specific information based on the AIP policies that are configured (e.g. credit card info, passport numbers, etc.).

clip_image001

For more information about the Azure Information Protection scanner please visit: https://docs.microsoft.com/en-us/information-protection/deploy-use/deploy-aip-scanner

 

Automation

To help with automating the AIP Scanner process I created a script to walk through each option.  Feel free to utilize, however keep in mind when new AIP scanner versions are released you may need to update the script to accommodate new features. I also make no guarantees so use at your own risk.

 

#AIP Scanner Script

#Created by Courtenay Bernier

 

 

$AIPScannerLogFiles = $env:LOCALAPPDATA + ‘MicrosoftMSIPScannerReports’

 

#AIP scanner config

Write-Host “”

Write-Host ‘AIP scanner configuration’

Write-Host “”

$ScanMode = Read-Host -Prompt ‘ScanMode: Enforce | Discover’

$Type = Read-Host -Prompt ‘ScanType: Incremental | Full’

$ReportLevel = Read-Host -Prompt ‘ReportLevel: Off | Debug | Info | Error’

$Schedule = Read-Host -Prompt ‘Scanner Runtime Schedule: OneTime | Continuous | Never’     

$JustificationMessage  = Read-Host -Prompt ‘JustificationMessage: Free Text or leave blank’

 

Write-Host “The AIPScannerConfiguration options selected are: ‘$ScanMode‘, ‘$Type‘, $ReportLevel, $Schedule, $JustificationMessage

 

Set-AIPScannerConfiguration -ScanMode $ScanMode -Type $Type -ReportLevel $ReportLevel -Schedule $Schedule -JustificationMessage $JustificationMessage

 

Write-Host “”

Write-Host ‘This is the AIP Scanner Configuration set:’

Get-AIPScannerConfiguration

 

 

 

#AIP scanner repository

Write-Host “”

Write-Host ‘AIP scanner repository’

Write-Host “”

$OverrideLabel = Read-Host -Prompt ‘OverrideLabel: On | Off’

$SetDefaultlabel = Read-Host -Prompt ‘SetDefaultLabel: UsePolicyDefault | On | Off’

$PreserveFileDetails = Read-Host -Prompt ‘PreserveFileDetails: On | Off’

$DefaultOwner = Read-Host -Prompt ‘Specify the default owner by: email address or leave blank’

 

do {$DLID = Read-Host -Prompt ‘Add a default label ID by GUID? Yes or No’ }

until (‘yes’,‘no’ -contains $DLID)

 

if ($DLID -eq ‘yes’)

    {

        $DefaultLabelID = Read-Host -Prompt ‘specify the label GUID found in the AIP label policy’

 

    }

elseif ($DLID -eq ‘no’)

    {

       Write-Host “”

       write-host “No default label ID was added”

       Write-Host “”

    }

 

 

#add file location

$Path = Read-Host -Prompt ‘Fileshare or SPS Path: e.g. F:SharesFileShare or \networkpath or http://sp2013/Shared Documents’

Add-AIPScannerRepository $Path

Write-Host “”

 

 

#ask to add for more file locations

do {$answer = Read-Host -Prompt ‘Would you like to add another file location? Yes or No’

 

if ($answer -eq ‘yes’)

    {

       $Path = Read-Host -Prompt ‘Fileshare or SPS Path: e.g. F:SharesFileShare or \networkpath or http://sp2013/Shared Documents’  

  

       #add file location

       Add-AIPScannerRepository $Path

       Write-Host “”

 

    }

 

else

    {

       Write-Host “”

       write-host “No additional paths were added”

       Write-Host “”

       Write-Host “To remove repositories: use Remove-AIPScannerRepository share/sps path”

       Write-Host “”

       Get-AIPScannerRepository

       Write-Host “”

  

    }

}

Until ($answer -eq ‘no’)

 

 

#set AIP scanner repository

Write-Host “”

Write-Host ‘Setting scanner repository config:’

Set-AIPScannerRepository -OverrideLabel $OverrideLabel -PreserveFileDetails $PreserveFileDetails -DefaultOwner $DefaultOwner -Path $Path -DefaultLabelId $DefaultLabelID -SetDefaultLabel $SetDefaultLabel

 

 

#show file location(s)

Get-AIPScannerRepository

Write-Host “”

 

 

#start AIP scanner service or abort

do {$answer = Read-Host -Prompt ‘Are you ready to start the AIP Scanner Service? Yes or No’ }

until (‘yes’,‘no’ -contains $answer)

 

if ($answer -eq ‘yes’)

    {

       write-host “Starting AIP Scanner Service for ($ScanMode)”

       start-Service ‘Azure Information Protection Scanner’

       Write-Host “”

  

       #Show last AIP events

       Write-Host “waiting for eventlogs to populate”

       Start-Sleep -s 15

       Get-EventLog -Newest 4 -LogName ‘Azure Information Protection’ | Format-List -Property *

       Write-Host “”

  

       #Open Scanner Report Folder

       explorer $AIPScannerLogFiles

       Write-Host “”

    }

elseif ($answer -eq ‘no’)

 

    {

       Write-Host “”

       write-host “Canceling AIP Scan”

       Write-Host “”

       Write-Host “To remove repositories: use Remove-AIPScannerRepository share/sps path”

       Write-Host “”

    }