Modern Device Management with Microsoft 365 Business Premium–Part 9

Previous parts in this series have been:

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

Baselines – Modern Device Management with Microsoft 365 Business Premium – Part 5

Deployment – Modern Device Management with Microsoft 365 Business Premium – Part 6

Autopilot admin – Modern Device Management with Microsoft 365 Business Premium – Part 7

Autopilot endpoint – Modern Device Management with Microsoft 365 Business Premium – Part 8

In part 3 I talked about Mobile Application Management (MAM) and in the last part, I talked about Windows deployment using Autopilot, now it is time to look at deploying applications to devices via Endpoint Manager.

image

This tasks will be accomplished via the All apps option inside the Apps menu in Microsoft Endpoint Manager as shown above.

image

Here you’ll see a list of existing applications, but what you’ll typically need to do is select Add from the menu at the top to add a custom application.

image

You’ll now need to select an app type, as you can see above, from the list that appears. Because we are dealing with applications across a wide range of platforms, you need to create a deployment policy for each app on each platform.

image

In this case, I’ll go with an application from the iOS store as shown above, just to keep things simple.

image

I’ll then need to select the link, as shown above, to Search the App Store for the desired application. Note that it doesn’t necessarily have to come from the store, but it is easier if it does.

image

Here, I’ll locate Microsoft Whiteboard as shown above and select it.

image

The details of the app are now populated as shown above. You can make any changes here you wish. Note, I have elected to feature this app in the Company Portal as well.

image

Next, I can target that application to be Required by users and or devices, which I have done as shown above. However, you see that it is possible to just make the application available (i.e. optional) for enrolled and non-enrolled devices as well as being able to uninstall the application if present.

image

You can now review the application settings and then press the Create button to complete the policy process.

image

In a short amount of time the device will process that policy as seen above. Here the user will be prompted that a required application will be installed. Press Install on device to continue.

image

The application will be installed.

image

The application is now ready for use on the device.

image

If you now look back at the All Apps area, as shown above, you should see the app that was just configured for deployment.

image

If you select this entry and then select Device install status, you should see a confirmation that the Status is installed as shown above.

image

If you take a look inside the Intune Company Portal App, you see the app is featured as shown above. The application can now be installed directly from here as well if needed.

image

To configure the settings for applications that are deployed, navigate to the the App configuration policies option as shown above and select the Add button that appears on the right.

image

Here, I will select Managed devices from the drop down menu that appears.

image

To keep things simple, I’ll choose to configure the Outlook app for iOS. This is because there are many different ways to configure applications, especially if they are not from Microsoft or not common apps like Outlook, Word, Excel, etc.

In this case, you need to click the Select app at the bottom of the page as shown.

image

Select the Outlook option from the menu that appears as shown.

image

Because this a ‘well-known’ app, I select Use configuration designer in the Configuration settings format field as shown. This presents a number of options I can now configure for that application.

image

You’ll then need to allocate this application configuration policy as shown above. Again, to keep this example simple, the option for All users and all devices has been selected but you can get more granular if you wish.

image

You can now Review and Create the policy.

image

The policy should then appear in the list of App configuration policies as shown above. You can select the policy name at any time to return to editing the policy.

image

The main take away is that you can use Endpoint Manager to create deployment and configuration policies for the different applications on the different platforms and apply them quickly and easily. As shown above, this also extends to granular configuration of the Office suite of apps.

It is important to remember that there can be a lot to configure here if you consider individual apps on individual platforms, so be prepared for some set up initially. But, once complete, deployment and configuration going forward across all platforms is easy. The main benefit is that both deployment and configuration can be done directly across the Internet for both enrolled and non-enrolled devices give good management of devices in the environment.

Modern Device Management with Microsoft 365 Business Premium – Part 10

Modern Device Management with Microsoft 365 Business Premium–Part 8

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

Baselines – Modern Device Management with Microsoft 365 Business Premium – Part 5

Deployment – Modern Device Management with Microsoft 365 Business Premium – Part 6

Autopilot admin – Modern Dev Management with Microsoft 365 Business Premium – Part 7

In the previous post I detailed Windows Autopilot from the administrator’s point of view. What does it look on the device side?

image

Just before the Autopilot Reset is selected in the EndPoint Manager portal as shown above, let me show you one quick configuration I’ve also done in Windows Hello for Business to make life that little bit easier.

image

In Devices | Enroll Devices | Windows enrollment select Windows Hello for Business as shown above.

SNAGHTMLf86d2ee

I have set the Configure Windows Hello for Business to be Disabled. Because I’m using a machine WITHOUT a TPM chip here (i.e. a Virtual Machine), it means that if Windows Hello for Business is enabled I’m going to need to go through the process of registering a device PIN. For now, to keep it as simple as possible, I want that Disabled.

Of course, I have also completed the Autopilot enrolment process and created an Autopilot device policy as detailed in the previous part in the series. Note, that a user has also already been assigned to this device. This means that the machine will be joined to Azure AD using this assigned user. That means they will not need to input their credentials during the process.

image

After selecting Autopilot Reset in Endpoint Manager I am asked to confirm the process as shown above. Take careful note here of what Autopilot does to that machine.

Select Yes to continue.

image

Once I select Autopilot Reset in Endpoint Manager, any active user will receive the above message that they have 45 minutes before the targeted machine is forcibly rebooted. I will fast track that process by manually rebooting the workstation to commence the Autopilot reset process.

image

If the devices is at the lock screen you will see the above message when the Autopilot process commences.

image

The workstation will then reboot and commence a Windows ‘refresh’ of the device, effectively doing a clean installation of Windows 10.

image

image

image

image

image

image

image

image

It will then complete the Autopilot configuration as seen above. You will note here that no user input is required. The reason for this is in Endpoint Manager a user has already been assigned to the device.

image

Not long after, you’ll will then end up with the ability to login to the workstation, as shown above.

image

image

When you do, you’ll be taken through the normal first run Windows experience as shown above.

image

The standard desktop should appears and all the device policies, Intune, Endpoint Security, etc will commence application to the device. Thus, it is just like you did a manual device join to Azure AD but you DIDN’T! Autopilot did all the hard work for you!

This is an example of how easy modern device management cam make your life once you set it up. If there is a problem with a machine, don’t waste long hours troubleshooting! Do an Autopilot reset to get a fresh version with everything deployed and accessible from the cloud. Easy! Need to reprovision an existing machine for a new user? Autopilot Reset again. Easy! the list goes on and on for the benefits of Windows Autopilot.

Although not yet available, what would you say if the same Autopilot concept was coming to both iOS and Android? Roll on modern device management is what I would say.

Modern Device Management with Microsoft 365 Business Premium – Part 9

Need to Know podcast–Episode 255

FAQ podcasts are shorter and more focused on a particular topic. In this episode I speak about some automation options that are available in the Microsoft Cloud.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-255-modern-device-management/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

FAQ 17

Modern Device Management – Part 1

CIAOPS Patron Community

@directorcia

Modern Device Management with Microsoft 365 Business Premium–Part 6

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

Baselines – Modern Device Management with Microsoft 365 Business Premium – Part 5

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.

image

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.

image

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.

image

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.

image

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.

image

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

image

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

image

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.

image

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.

image

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