12. Device Management

______________________________

In This Chapter

Introduction

Security and Compliance Center PowerShell

• Tenant Policy and Rule
• Device Conditional Access
• Device Configuration

_______________________________

 

Introduction

There are many options for device management and control in the world of cloud and on-premises services. Microsoft itself provides us with two different levels of this - ‘free’ Mobile Device Management (MDM) which is part of some licensing of Office 365 and Intune. Intune is a corporate solution for enterprise mobile device management for Office 365. Intune requires additional licensing for its increased functionality.

The PowerShell cmdlets that we will cover in this chapter are not Intune-related and are for the general MDM solution that Microsoft Provides. This is because Intune is separate from the SCC and out of scope for this book. These cmdlets are run from the Security and Compliance Center, but they work hand-in-hand to manage device access to data in Office 365.

Mobile Device Management is included in these Licenses for Office 365:

• Office 365 Business Essentials
• Office 365 Business Premium
• SharePoint 1
• SharePoint 2
• Office 365 Enterprise E1
• Office 365 Enterprise E3
• Office 365 Enterprise F1

Where can we find Device Management in the Security and Compliance Center?

If we click on this link, it will take you to an Office 365 admin page link - https://portal.office.com/adminportal/home#/MifoDevices - which looks like this:

If you have any enrolled devices, they should appear here now. Because these devices are connecting to Exchange Online, some of our Device Management may need to be performed in Exchange Online.

Connecting to Exchange Online

Use the information in the link below to connect to Exchange Online:

https://docs.microsoft.com/en-us/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/connect-to-exchange-online-powershell?view=exchange-ps

Once connected, we find we have these cmdlets to manage Mobile Devices in Exchange Online:

Clear-MobileDevice

Get-MobileDevice

Get-MobileDeviceDashboardSummaryReport

Get-MobileDeviceMailboxPolicy

Get-MobileDeviceStatistics

New-MobileDeviceMailboxPolicy

Remove-MobileDevice

Remove-MobileDeviceMailboxPolicy

Set-MobileDeviceMailboxPolicy

Most of these cmdlets should prove useful for our MDM experience for devices connecting to Exchange Online. First we can list all devices in Exchange Online with ‘Get-MobileDevice’:

From a management perspective, only the WP8 devices will be manageable or supported from this list. The official list as of the writing of this book:

• Windows Phone 8.1+
• iOS 7.1 or later versions
• Android 4 or later versions
• Windows 8.1
• Windows 8.1 RT
• Windows 10
• Windows 10 Mobile

We can review any Mobile Device Mailbox Policies:

Device Statistics for your phones (Get-MobileDeviceStatistics):

If we want to wipe a device, we can use the Clear-MobileDevice cmdlet. A specified device will be cleared the next time it connects to Office 365. Clearing a device should be approached with caution. This is because, depending on the supported version of the device and the options you choose, a remote wipe will:

“clear all data on the mobile phone, including installed applications, photos, and personal information”

If you have a BYOD environment, this means you are wiping out personal data probably without permission of the user. Now, with the introduction of EAS 16.1 compliance devices, there is now support for an AccountOnly wipe:

“-AccountOnly

The AccountOnly switch specifies whether to perform an account-only remote device wipe where only Exchange mailbox data is removed from the device. You don’t need to specify a value with this switch.

You don’t need to use this switch for the DeviceType value Outlook, because an account-only remote devices wipe is the only type of wipe that’s used on Outlook devices.”

If your device is not an EAS 16.1 device, and this parameter is specified, an error should occur but the wipe will still succeed.

Further Reading

https://docs.microsoft.com/en-us/exchange/clients/exchange-activesync/remote-wipe?view=exchserver-2019

https://docs.microsoft.com/en-us/powershell/module/exchange/devices/clear-mobiledevice?view=exchange-ps

https://blogs.msdn.microsoft.com/exchangedev/2016/06/13/announcing-exchange-activesync-version-16-1/

https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxprotlp/229f77ea-6518-4fe7-84fe-bd535fc6c32e

Security and Compliance Center PowerShell

Now that we’ve reviewed some of the background details and the interconnection to Exchange Online, let’s start working with PowerShell in the Security and Compliance Center. Since the included MDM solution is pretty basic, we also find that available PowerShell cmdlets are limited as well.

What cmdlets do we have available to us in the SCC?

Within the list above we can see cmdlet groups based on these nouns - Tenant, DeviceConfiguration, DeviceConditional, and DeviceCompliance. Let’s begin by exploring Tenant settings for MDM in the SCC.

When reviewing the help for several of these cmdlets, you will notice this general guidance on all the way the cmdlets are structured:

Tenant Policy and Rule

In your Office 365 tenant, there is an overriding Device Policy and Device Rule that is configured by default (If Device Management has been enabled). There can only be one of each of these configured in your tenant at any point in time. We can manipulate, add and remove these tenant wide rules as there is a set of cmdlets dedicated to this function:

Get-DeviceTenantPolicy

Get-DeviceTenantRule

New-DeviceTenantPolicy

New-DeviceTenantRule

Remove-DeviceTenantPolicy

Remove-DeviceTenantRule

Set-DeviceTenantPolicy

Set-DeviceTenantRule

Let’s review the default Tenant Policy and Rule which we can pull with two cmdlets and

Get-DeviceTenantRule

Get-DeviceTenantPolicy

Now that we had a look at the configuration, what can we do with the Tenant Policy / Rule? With the Policy, we have a few options, we can change a couple of settings, remove it and then create a new one. If we remove the Policy, we will also remove the Tenant wide Device Rule as well which is something to keep in mind.

If we do not have Mobile Device Management Enabled and we try to create a new Policy or run, we will receive an error:

Now, if we have an existing Device Tenant Policy / Rule configured and we try to add a new one, we also get an error message:

If we wish to remove and recreate the Rule/Policy combination, make sure to remove the Policy first as trying to remove the rule will generate a Dr. Watson error. Removing a Policy also removes the Rule:

To recreate these, we simply need to run these two cmdlets in succession - New-DeviceTenantPolicy and New-DeviceTenantRule. No need to specify any parameters, they are not required.

Now, what about changing any settings on the Policy or the Rule. What can we change if anything?

Set-DeviceTenantPolicy - we can add a comment, disable the Policy or retry distribution. Adding comment is optional, disabling the policy would be useful for troubleshooting and retrying distribution should also only be used if the DistributionStatus property of the Policy is ‘Error’:

To attempt a fix for this error, try this one-liner:

Set-DeviceTenantPolicy -RetryDistribution

This will place the DistributionStatus of your Policy into a Pending state as it retries. Adding a comment is a quick option we can put into place:

Set-DeviceTenantPolicy -Comment ‘Default Device Tenant Policy (BigCompany.Com)’

Not a lot to it. For a Device Tenant Rule, we can adjust a couple of settings:

BlockUnsupportedDevices: We can block certain devices from accessing the tenant.

ApplyPolicyTo: We can choose from three options on this parameter - ExchangeOnline, SharepointOnline and ExchangeAndSharepoint. This will scope your Device Tenant Rule to the specified workloads.

ExclusionList: Determines who will be excluded from the unsupported device blocking rule.

Device Conditional Access

Conditional Access is a concept used in Office 365 that basically means that certain conditions will need to be met before a device can connect. We will need to build Device Conditional Access Policy and Rule pairs. PowerShell cmdlets available for this configuration are as follows:

Get-DeviceConditionalAccessPolicy

Get-DeviceConditionalAccessRule

New-DeviceConditionalAccessPolicy

New-DeviceConditionalAccessRule

Remove-DeviceConditionalAccessPolicy

Remove-DeviceConditionalAccessRule

Set-DeviceConditionalAccessPolicy

Set-DeviceConditionalAccessRule

Let’s see if we have any Policies or Rules to begin with. The answer is no:

Since we don’t have any to start with, we can review the Get-Help for each cmdlet to see what is available:

Get-Help New-DeviceConditionalAccessPolicy -Examples

Get-Help New-DeviceConditionalAccessRule -Examples

For our first example, we will create a Policy and Rule that will target users in the Legal Department. Due to requirements in their department, they’re not allowed to use Bluetooth due to security concerns and the App store will also be blocked due to the corporate software installation policy. How can we do this?

First, we need a Policy for our Device Conditional Access Rule to Reference:

New-DeviceConditionalAccessPolicy ‘Legal Department Mobile Policy’

Next, since we need to target the Legal Department, we need the GUID from the Azure AD group:

Get-Group Legal | Ft Name,GUID

Now that we have our group and its GUID, we can create the Rule:

New-DeviceConditionalAccessRule -Policy ‘Legal Department Mobile Policy’ -BluetoothEnabled $False -AllowAppStore $False -TargetGroups 8503291d-cf21-4de5-8719-17fb58e95285

In the future if the requirements for our Device Conditional Access Rule change, we can use the Set cmdlet to handle any changes. For example, if we now need to set a value for the ‘MaxPasswordAttemptsBeforeWipe’ property to 20. This way if someone is trying to break into a device, they can only enter so many codes before it wipes the device. First, the name of the Rule:

Get-DeviceConditionalAccessRule | Ft Name,GUID, TargetGroups

** Note ** When using the SET cmdlet, we also need to reiterate the TargetGroups parameter again, hence the cmdlet above. Also note the ‘{394b}’ in the name, this is added by the Microsoft.

Set-DeviceConditionalAccessRule ‘Legal Department Mobile Policy{394b}’ -MaxPasswordAttemptsBeforeWipe 20 -TargetGroups 8503291d-cf21-4de5-8719-17fb58e95285

At some future date, we can also lift the restrictions entirely with the Remove cmdlets:

Get-DeviceConditionalAccessRule | Ft name,GUID

Once we have the GUID of the Rule we can then delete it.

Remove-DeviceConditionalAccessRule -Identity f8c8bb1f-2e22-4eac-a437-1d749041a74e

Next, we need the GUID of the Policy to remove:

Get-DeviceConditionalAccessPolicy | Ft Name,GUID

Remove-DeviceConditionalAccessPolicy -Identity 1b2b427f-5d18-41d3-82ee-055c437772b7

Device Configuration

Next we have Device Configuration Policies and Rules. Device Configuration Policies and Rules are used to configure Mobile Devices to fit a particular configuration or Corporate policy. The settings here are not meant to control device access to Office 365 like the Conditional Access ones from the previous section. We can use Device Configuration cmdlets to configure devices to a standard spec and we can target these to groups in Office 365 which allows for a more customizable configuration for your users. This way if the IT department wants to lock down devices more with a certain configuration, they can do so while opening up the configuration to users hat are at the C-Level in a corporate environment. What PowerShell cmdlets do we have access to?

PowerShell

Just like Conditional Access Policies and Rules, we have no existing or default ones to work with in a new and untouched tenant:

Get-DeviceConfigurationPolicy

Get-DeviceConfigurationRule

Let’s start off by looking at examples from each cmdlet to see what we can do with these cmdlets:

Get-Help New-DeviceConfigurationPolicy -Examples

Get-Help New-DeviceConfigurationRule -Examples

We can see from the above examples that the Device Configuration cmdlets are structured similarly to the Device Conditional Access. As such, we will start with the Policy cmdlet and then associate the Policy with a Rule.

New-DeviceConfigurationPolicy and New-DeviceConfigurationRule

For our first example the IT group has mandated some settings that must apply to all of their users. First we will create the base policy for the IT Group:

New-DeviceConfigurationPolicy -Name ‘IT Mobile Device Configuration’

Then get the GUID of the IT Group:

Get-Group IT | Ft Name,GUID

Lastly, we will apply a restrictive policy with these settings:

New-DeviceConfigurationRule -Policy ‘IT Mobile Device Configuration’ -MaxPasswordGracePeriod 00.01:00:00 -PasswordMinimumLength 8 -PasswordHistoryCount 6 -MaxPasswordAttemptsBeforeWipe 20 -PasswordExpirationDays 182 -PasswordMinComplexChars 4 -PasswordRequired $True -AutoUpdateStatus NeverCheckUpdates -PasswordQuality 2 -TargetGroups 7ffbd4b4-ad91-44eb-a735-86ee5809f311

For the next example, we will create a slightly less restrictive Policy for our company’s executives in order for them to use other features. However, we will change a couple of settings to be even more restrictive due to the nature of their job titles. First we will create the base policy for the Executives:

New-DeviceConfigurationPolicy -Name ‘Executive Mobile Device Configuration’

Then get the GUID of the IT Group (located in Azure AD):

Get-Group Executives | Ft Name,GUID

Lastly, we will apply a more restrictive policy with these settings:

New-DeviceConfigurationRule -Policy ‘Executive Mobile Device Configuration’ -MaxPasswordGracePeriod 00.00:15:00 -AllowSimplePassword $True -PasswordMinimumLength 8 -PasswordHistoryCount 2 -MaxPasswordAttemptsBeforeWipe 10 -PasswordExpirationDays 365 -PasswordMinComplexChars 2 -PasswordRequired $True -AutoUpdateStatus NeverCheckUpdates -TargetGroups 71da8431-38a1-4c44-9798-3deb0c555d41

We can now verify our two new Rules:

Get-DeviceConfigurationRule

If we need to modify these Rules or Policies later, we can handle that with SET cmdlets like the Conditional Access cmdlets mentioned previously. For our Device Configuration Policies, we can add a comment, we can RetryDistribution and enable/disable the Policy. In fact, if our Policies did not deploy and an error occurred, we can use the RetryDistribution switch to try and process them:

Just like the Device Conditional Access Policies, we can remove them with a simple one-liner:

Remove-DeviceConfigurationPolicy ‘IT Mobile Device Configuration’

Lastly, if we want to modify an existing Device Configuration Rule we have a lot of options to choose from:

Make sure to verify that the option you chose from the above list will work for your device. Some of the configuration items only work with a particular version or higher of a Phone OS.

** Note ** If more additional / more complex options are needed, Intune may be a better solution. The only caveat is that Intune may be an additional license depending on what you have already licensed.