Modern Workplace Management: Build Endpoints without SCCM Part 5

D Walsham • 29 July 2021

Backend Configuration within Endpoint Manager

Introduction

In continuation from the previous part where we had discussed how we create the "on site" piece of the solution, this was the part which would allow us to get our endpoints into a state in which they would essentially be ready to go through the Autopilot process.

Which leaves our next piece of the puzzle, to begin the configuration of the actual backend side that resides within our Endpoint Management console. And you will see how everything ties up together to satisfy the full end to end process of getting an unknown (or known) device to proceed thorough the whole workflow to be finally managed by Intune without the aid of SCCM taking part in any of the prerequisites or preparation at hand.

What do we need to Complete the backend configuration

So of course the obvious part of this is going to be that our auto-enrolment side is setup which is most certainly a given, but in this case we want go a little bit more granular in what we specifically need to get this going.

To get to this we need to perform the following;

  • Define Company Standard Applications
  • Define Company Standard Profiles
  • Create Autopilot Profile
  • Create Enrollment Status Page

Define Company Standard Applications

The aim in this exercise is not to replicate a task sequence or gold image as such, but really to define what are exactly the absolute minimum types of software which every standard user requires before they can be up and running.

Best way to define this is if we were to lets say make a list of every application which we envisage a device would need as a pure example;

  • Microsoft Office
  • Google Chrome
  • Winrar
  • Winzip
  • PowerBI Desktop
  • Amazon WorkSpaces
Just really a few to list off as other companies standards could be much more extensive than this. And that's exactly what we want to account for. See if we have lets say 30 applications that we require a device to have. Do you know how long that could take to deploy to every single machine which went through the Autopilot service? A very long time indeed!

So how do we overcome this? We define categories of priority for these applications. And we would do it like this;

  1. Which applications are top priority?
  2. Which applications don't have to be installed during Autopilot but still be mandatory?
  3. Which applications can be made as available for users?

And the aim of that list is so we can cut down on the overall Autopilot process so that devices are not in a backlog and can make a turnaround of being completed a lot more efficiently.

To make another example of this lets combine the apps we listed with the category question list above;

  1. Which applications are top priority ? Microsoft Office, Google Chrome
  2. Which applications don't have to be installed during Autopilot bit still be mandatory ? PowerBI Desktop, Amazon WorkSpaces
  3. Which applications can be made as available for users ? Winrar, Winzip

Now the example applications list I made isn't too extensive so I would probably be saving seconds rather than minutes :) But when this list does scale up it will help the planning for the future as well as right now if you are at that point.

Define Company Standard Profiles

This is of course a monster of a type of exercise but will give some information on this briefly to cover how you would define these.

Things you perhaps want to take into account is that this is structured on a migration from on premise to cloud type of transition, so if you have policies or settings which could be applied to endpoints solely on SCCM then you may want to bring these over so that you can maintain the integrity of company standard policies. The transition bits are covered on a previous series I did on how to migrate from SCCM to Intune which you can check out :)

Create Autopilot Profile

The Autopilot profile bring us even closer to complete the full workflow as this is where we will be able to allow endpoints to be enrolled into the Azure domain and automate (or semi automate) the configurations within our OOBE (out of box experience) once the user has successfully authenticated with their device after first login once the Autopilot Profile has been detected.

So going into the Devices - Windows - Windows Enrollment - Deployment Profiles we can go ahead and create our deployment profile. Below are the settings of an example one here;

Now this also has an important bit checked which is called Convert all targeted devices to Autopilot. This allows for any machine which is not registered in Autopilot, but perhaps is registered within Intune to be converted to an Autopilot device. Which means that if we were to reset that specific endpoint for whatever reason, the Autopilot profile would kick in to help build that device again.

( Note: Bear in mind depending on the structure of your environment this could be a risk depending on where this is applied. Ensure that there are NO applications and NO profiles being deployed to ANY group which is specifically for Autopilot devices which you may not want applied!)

Figure 1.2 shows the OOBE settings which is where we want to make the user experience of going through this device very simple. Ideally when going through the OOBE stage the user will be doing this on their own, unless you have a process in which a service desk team may perform this with them or for them.

A popular method to use can be the Allow White Glove OOBE configuration where you can have the device complete the entire Autopilot process when no specific user has been identified and to simply hand or send the device to a user of your choosing. This can only strengthen the overall design of building endpoints without SCCM.

Next part is then the assignment of this profile, here we have a group which contains only Autopilot Devices. Now you don't necessarily have to deploy it to a group like this where it may contain the dynamic membership rule which will pull in ANY device that's in Autopilot as seen in Figure 1.4. You can also have a static group where you can place devices in if you wish to stagger or semi automate the process before fully committing a group to this process.

Create Enrolment Status Page

In my opinion this is a very slept on part of any piece which involves any part of a windows enrolment process. So many of us stick to using the default All users and All devices page which may have no specific configuration within it.

This is super important to this series. Why? because if we look back at the exercise in which we did for defining company standard applications we had some applications which we said we COULD NOT do without and they were the absolute most critical to be on a device before it would actually move along. This, is where it's all controlled at!

So once again navigating to Devices - Windows - Windows Enrollment - Enrollment Status Page you should see the default page mentioned. Here we will create a new Enrollment Status Page specifically for our Autopilot process.

Once we hit Create and provide a name we should then get the following settings below. Very typical settings which simply allows for the device to display the progress windows which perform the domain joining, application installing and other forms of configuration. But the one setting we want to configure is the Block device use until these required apps are installed if they are assigned to the user/device seen in Figure 1.7

Here I click Selected and then choose the applications which I want to be installed first, being the ones which we had defined earlier as the absolute top priority ones. This way once those apps are completed the device is ready to go and doesn't have to be held up by an excess amount which wouldn't stop an endpoint from being defined as ready.

The last part is of course where we deploy it to. So we can only deploy it a group, so we select the group which has the Autopilot Profile assigned to it being the POC - Windows 10 AutoPilot Devices group.

With everything now configured on the backend, you should now be able to perform the following;

  • Reset a device which is in Intune but now converted to an Autopilot Device (Known Device)
  • Manually import a device into Autopilot to have its profile assigned (Unknown Device)
As both will go through the same process, we have now consolidated known and unknown, to just "known go ahead and reset" :)

Next Part

The next couple of parts on this series will be focused around how we tackle this on a hybrid environment where we have an on premise Active Directory and an Azure Active Directory. May find most of the previous parts have covered the majority but there are little things which can cause great hurdles in trying to achieve the same goal.

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side Part 4 - SQL Server Requirement Analysis

by D Walsham • 13 December 2021
Looking through the current SQL Server topology and how it affects our decision

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side Part 3 - Current Branch Upgrade Approaches

by D Walsham • 19 November 2021
Impact of Current Branch Upgrades

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side - Part 2 - Operating System Considerations

by D Walsham • 29 October 2021
Introduction

Microsoft Endpoint Manager: In-Place Upgrade or Side by Side

by D Walsham • 7 October 2021
Introduction

Endpoint Manager: Device Estate Cleanup

by D Walsham • 6 October 2021
Introduction

Modern Workplace Management: Creating Applications Common Practices - LOB vs Win32 Package

by D Walsham • 3 September 2021
Introduction

Modern Workplace Management: Build Endpoints Without SCCM Part 6

by D Walsham • 12 August 2021
All the parts of the series we went into great detail about how we analyse an end to end solution and how we would design a solution in which would allow us to build endpoints without SCCM being a dependency. Whilst we did this, there is another scenario which we have not touched on yet, which is the hybrid scenarios. In a perfect world ideally you would have your Azure Active Directory within the cloud, every machine meets the recommended requirements for Windows 10, everything is imported into Intune/Autopilot and everyone is happy. But we know this isn't realistic in all cases. Many organisations cannot just simply up and go from on-premise into the cloud therefore the checkpoint here is of course getting into hybrid solutions such as; Co-Management Between Intune and SCCM Hybrid AD with Azure AD and On-Premise AD syncing together These things can play a very interesting part in how you would tackle this if you envisage the next step in the blueprint is to be in a position in which you can build and manage endpoints soley within Intune. With this final part of the series we will go in-depth in how the common hybrid setups look like and how we go about moving into the next step of being able to manage and build devices without SCCM.

Modern Workplace Management: Build Endpoints without SCCM Part 4

by D Walsham • 15 July 2021
In this part we are now going to look into the technical step by step points on how we put everything together. In the previous part we spoke about the structure of how we would asses whether a machine was actually ready to be built with Autopilot or not with a build checklist process which would step through all areas which would cover an endpoints eligibility. Now with everything planned out we finally want to step into making things reality by putting everything together.

Endpoint Manager: Find machines not in Autopilot

by D Walsham • 2 July 2021
When it comes to managing your endpoints in endpoint manager, one of the things you may be looking to do is to get all of your Intune registered machines to also be enrolled as Autopilot devices. Now we can of course just have the deployment profile deployed to all machines and then hit the "Convert targeted machines to autopilot" but this might not necessarily be feasible for every client. We may want to perform some due diligence first so we can at least understand what devices in Intune are not in Autopilot.

Modern Workplace Management - Build Endpoints without SCCM Part 3

by D Walsham • 24 June 2021
So just to recap on the previous part of this series we covered a base scenario of where we would utilise other products as a dependency to provision or even pre-provision endpoints before getting them to a state where they can be auto-enrolled and then into Autopilot - in this case this would be around SCCM. We also detailed in a diagram form of where we ideally want to be, and that's to not have any dependency when it comes to the provisioning of the endpoints where its also soley performed within Intune. This part we will be going into the nitty gritty of how this works.
Show More