Modern Device Management with Microsoft 365 Business Premium–Part 6

Previous parts in this series are:

All the articles so far have focused on the technical implementation of device management, however these are all effectively subservient to real need of allowing users to get their work done. Security that gets in the way of what people need to do will simply result in them bypassing it and opting for solutions that are less secure and less controllable, aka shadow IT. Thus, when implementing successful device management, you keep in mind the end game here which is, allowing users to get done what they need to, securely.

Deploying all the options that are available with device management is daunting given the sheer number of settings, across multiple operating systems via multiple services like Intune and Endpoint security. Thus, even before you start implementation you should ensure that you have a good documentation regime in place to keep track of what you implement and what changes you make over times. There are going to be circumstances when you need to track down a specific setting in a specific policy and having good documentation is going to save you boatloads of time. It is also going to save you going round and round in circles making changes that have unexpected consequences. Thus,

Rule number 1 = maintain good documentation

With a plethora of policies and settings to configure having a define naming convention is going to make troubleshooting far easier. I have seen all sorts of policy names that bear no relevancy to the actual settings it implements. Remember, you can end up with multiple policies for multiple device operating systems, for multiple audiences across multiple services. Using something like MAM iOS Sales team or MDM Windows Executives or ES Antivirus Field Staff is going to allow people to quickly understand what these policies are for, where they come from and who they apply to. Good naming conventions are defined prior to implementation and applied consistently (which is why they are called conventions after all!). So,

Rule number 2 = define a naming convention upfront and apply it consistently

All users are not created the same. Thus, you’ll need to consider dividing up your policies into deployment rings, much like what Microsoft does with Windows I suggest. You’ll probably need a test or canary ring, and early adopters ring and an everyone else ring.

The canary ring is basically test devices and users to determine the effects of applying policies. This will give you early warning as to what impact settings actually have in your environment. This will be 1 – 2% of your population.

The early adopters ring is targeted at those users who like to be first and are prepared to ride out and bumps along the way by providing constructive feedback on the impacts of settings to them. This will probably be 10 – 15% of your population. Users in this ring should ‘opt in’ and understand the ramifications of getting things that may still be testing.

You may need to have multiple rings for different locations, devices or audiences. This is again where good documentation and naming conventions are critical. It is therefore recommended that:

Rule 3 = apply policies and updates to policies in rings to the environment

Not everything goes to plan. Sometimes setting and policy changes can have unexpected consequences on devices. Sometimes, these unexpected changes can prevent you from doing something you need to do. As with setting up conditional access, don’t lock yourself out:

Rule 4 = ensure you have an admin user that is not subject to any policy in case of emergency

Device management is typically never a world of all green check marks (and rainbows and unicorns). It is typically a world with setting conflicts, non compliance and strange impacts. Bulk policy implementations and/or changes are a recipe for never ending frustration. Start small and grow. Don’t turn everything on to the max out of the box. My advice is to start with one baseline at a time and get that all green, then move to individual Endpoint security policies and get that all green, then compliance and get that all green and so on. Thus,

Rule 5 = grow into your settings and policies

Some other recommendations for those that are actually tasked with deploying device management:

A. Have at least one physical test device for each operating systems. That means having a test iOS, Android and Windows 10 device at your disposal. It is easy enough to pick up a cheap or second hand device you can use. Nothing beats seeing exactly what happens on a physical device when policies are applied. It will also allow you to better understand the process of wiping and re-purposing devices.

B. Use a demo tenant first time out. Don’t learn this stuff on your customer’s dime. Don’t learn on your own production tenant. Sign up for a free demo Microsoft 365 demo tenant at https://cdx.transform.microsoft.com/ and do your learning there. There is nothing worse than test policies and configurations continuing to show up in production environments.

C. Fully implement device management in your own production tenant. Don’t forget that if you look after other customers, YOU are also a target of the bad actors. Your environment is an Aladdin’s cave full of passwords, logins and confidential information for many others. In short you hold the crown jewels for many businesses. Don’t think it can’t happen to you. Over prepare. Over secure your environment. Doing so will also help you more fully appreciate the impact that device and security settings will have on your customers and deployments as well as keeping their treasures secure.

D. Configuration is never complete. New devices, enhanced baselines, new policy options will all emerge over time. Security is a journey, not a destination as they say. You will need to monitor, review and adjust what you have implemented over time. You will need to evaluate what works, what doesn’t and what additional security you can apply to the environment. It will never be a ‘set and forget’ situation. Security is a service not a product.

E. Leverage the power of automation. Baselines are a great starting point and reduce much of the need for individual settings. However, technologies like PowerShell and the Microsoft Graph give you the ability to automate much. An example of this that I have detailed is here:

Automating the deployment of an Attack Surface Reduction policy across multiple tenants

The great things about these device management services from Microsoft is that they are consistent for everyone that has them. Thus, the same script will work across every customer that has those services. With so many settings available to you in device manage these days, it makes sense to invest your time in become more ‘code centric’ (DevOps anyone?) and adding those skills to your quiver.

In summary then, successful device deployment is all about people. It should be focused on delivering secure productivity without mindless obstruction, which being carried out in a systematic and consistent manner. You can have all the greatest deployment tools at your beckoned call, but if they are implemented incorrectly, the end result is far worse for end users and administrators than it would have been without device management. So, don’t make the mistake of seeing device management as a purely technical challenge, It ain’t!

Modern Device Management with Microsoft 365 Business Premium – Part 7

Modern Device Management with Microsoft 365 Business Premium–Part 5

Previous parts in this series are:

Office 365 Mobile MDM – Modern Device Management with Microsoft 365 Business Premium–Part 1

Intune MDM – Modern Device Management with Microsoft 365 Business Premium – Part 2

Intune MAM – Modern Device Management with Microsoft 365 Business premium – Part 3

Endpoint Manager – Modern Device Management with Microsoft 365 Business Premium – Part 4

One of the biggest challenges with the availability of all these policies via Intune MDM and MAM as well as Endpoint security is getting to a ‘best practices’ state.

One of the benefits that Endpoint security provides is the ability to implement Security baselines as shown above. There is a baseline for Windows 10 security, Microsoft Defender ATP and Microsoft Edge already. Microsoft recently announced that an Office baseline will soon be available.

The idea is that Microsoft will publish a ‘best practices’ baseline, as shown above for Edge, and that you can create a policy or ‘profile’ as it is called here, from this to use across your environment just like any other policy we have already spoken about.

The idea is that, rather than you having to work out and apply a range of best practice settings across all the individual policies, you can simply implement these baseline policies from Microsoft as a starting point.

Another benefit is, as updated baselines are released by Microsoft, you can simply update any existing ‘profile’ you have created with these baselines to incorporate these updated settings.

When you look at the settings available in these baselines, as shown above for Edge, you’ll notice that they basically contain many of the same settings available to you in individual Endpoint security policies. Thus, setting once via a baseline ‘profile’ is a much faster method of implement these settings. Otherwise, you’d probably have to create multiple individual policies to achieve the same level of protection.

You can, of course, adjust any baseline ‘profile’ that you create and when a new baseline is available it can be applied to existing ‘profile’ you have created while maintaining any custom settings you have made in that ‘profile’. You can also create a range of different ‘profiles’ from baselines and target them to different audiences in your environment just as you can with other individual policies from Intune MDM, MAM and Endpoint security.

If you already have individual Endpoint security and Intune policies deployed you will need to be careful if you then start to deploy baseline policies. If there are differences in the settings between the baseline policies and those configured in Intune MDM, MAM and Endpoint security you’ll end up with a conflict. Thus, you will either need to make sure that the settings are identical between all the policies that you use or stop using some of the conflicting policies. Generally, I would suggest that just using the baseline policy for the setting is a best practice approach.

Why do I believe this? If you look at the volume of policy settings that can be made across all options like Intune MDM, MAM and Endpoint security, it makes more sense to me to start with what Microsoft believes is best practice first and adjust from there. Doing so is going to:

1. Reduce the amount of individual settings in individual policies that you need to make.

2. Reduce setting conflicts across all your policies.

3. Allow you to more easily to update to new best practices when they become available.

With this in mind and looking back across what we have talked about so far with MDM and MAM, Intune and Endpoint security, I would suggest this as a new best practice approach to configuring device security is, in order:

1. Implement all Microsoft baseline security policies.

2. Make any required customisations to the deployed baseline ‘profiles’ in your environment.

3. Implement individual Endpoint security policies for additional settings not covered by the baselines.

4. Implement MDM compliance policies for additional settings not covered by baselines or individual Endpoint security policies.

5. Implement MDM configuration policies for additional settings not covered by baselines, individual Endpoint security and MDM compliance policies.

6. Implement MAM application protection polices for additional settings not covered by baselines, individual Endpoint security, MDM compliance and MDM configuration policies.

7. Implement MAM configuration policies for additional settings not covered by baselines, individual Endpoint security, MDM compliance, MDM configuration policies and MAM application protection policies.

in short, start with baselines, then implement individual Endpoint security policies, then Intune MDM policies, then Intune MAM policies.

At this stage, no single policy is going to provide all the protection required. Thus, you need to use a mix of policies across baseline, Endpoint security and Intune to suit your needs. However, in the long run, I see baselines and Endpoint security policies as being the future and suggest you start there rather than the traditional approach that was to start with Intune. If you already have Intune in place, for example, then you’ll need to think about migrating to baselines and Endpoint security policies as I am currently doing. It will be frustrating at times tracking down the duplicates at times, but I suggest doing so will position you better for future improvements in the device management space.

Success with device management is not merely about select the right setting in a policy, it is also about deploying it effectively into your organisation. That’s what I’ll take a look at in the next article.

As something else to consider, I’d suggest you have a read of my article:

The changing security environment with Microsoft 365

In light of the recommendation to apply Microsoft baselines. The questions to think about are – in the future why can’t Microsoft simply apply these baseline policies automatically and use AI to fill the gaps with additional settings? Where does that then leave those who are setting device polices today?

Modern Device Management with Microsoft 365 Business Premium – Part 6

Modern Device Management with Microsoft 365 Business Premium–Part 4

In the previous parts of this series I have covered:

Office 365 Mobile MDM – Modern Device Management with Microsoft 365 Business Premium–Part 1

Intune MDM – Modern Device Management with Microsoft 365 Business Premium – Part 2

Intune MAM – Modern device Management with Microsoft 365 Business premium – Part 3

We still have some additional device configuration options available to us thanks now to Microsoft Endpoint Manager.

As well as Intune MDM and MAM policies we now have extra Endpoint security policies.

You’ll find these under the Endpoint security menu item on the left and then under the Manage heading as shown above. In there you will find the following options that you can go and configured policies:

– Antivirus

– Disk encryption

– Firewall

– Endpoint detection and response

– Attack surface reduction

– Account protection

If look inside any of these Endpoint option, here Attack surface reduction, you see that you can set policies just like what has already been covered around Intune device and application policies.

When you do create an Attack surface reduction policy, for example, you’ll get the option to target device control, attack surface reduction rules, app and browser isolation and so on, as shown above.

If you configure the attack surface reduction rules, as shown above, you’ll see the now familiar configuration settings that you choose from and then save to the policy. You then finally target the policy that you create to a user and/or a device, again just like Intune.

In essence, you now have a number of additional policies, largely focused on Windows 10 device security for now, that can also be applied to your environment.

The challenge here becomes, some of these Endpoint Manager policy settings are unique and some overlap with existing Intune policies that you may have set. If there is a mismatch in the policy settings you have between Endpoint Manager and Intune, these will report as conflicts in the Endpoint Manager portal. So, the trick is to either use the duplicate Endpoint Manager policy settings BUT ensure they are the SAME as what is set in Intune or only have one set of policies (Endpoint Manager or Intune) for the desired option. My opinion would be that if the desired setting option is available in Endpoint Manager policies, set it there and don’t set it in any Intune policy. It is my understanding, that in the long run, Endpoint Manager policies are were Microsoft is investing the most in currently.

In summary then, it is possible to use three sets of policies for your devices:

1. Intune device policies

2. Intune application policies

3. Endpoint Manager policies

You can set any combination of the three, but be careful about creating conflicts as they can be challenging to track down as some settings overlap.

All of these policies can be implemented and accessed with PowerShell, however I would suggest not ‘basic’ PowerShell like you might be used to with Exchange Online for example. Think more of accessing the settings via the Microsoft Graph with PowerShell, which is a little more complex than ‘standard’ Microsoft 365 PowerShell with commands like get-msoluser for example.

There are still more considerations with device management that will be covered in the next article. Hopefully, by now you are beginning to appreciate the power and granularity that is possible with device management from Microsoft 365. However, as they say, “With great power comes great responsibility” (and I would add a lot more complexity).

Modern device Management with Microsoft 365 Business Premium – Part 5