Modern Workplace Management - Build Endpoints without SCCM - Part 2

So on the first part of this series we covered the synopsis of what we are really trying to achieve which is to basically design a process which enables us to not have any dependencies on any other technologies when it comes to provisioning endpoints and managing them within Intune, in this case we are talking about SCCM/MEMCM.

SCCM indeed will always play a big part and for those organisations that still use it and is a huge footprint in the overall design it's not a simple process to completely leave SCCM to manage everything solely in Intune. But what we can do is start by lessening the load of what SCCM is responsible for and try to allow Intune to be more of the lead when it comes to endpoint management, which is really the core of when it comes to Modern Workplace Management.

This may not necessarily be true in every case, but for where most of us in a real life scenario in which we utilize both SCCM and Intune, it will most likely be an option to use SCCM as a dependency and a step in between a device which is not provisioned to being auto-enrolled and provisioned.

These tasks can of course be done manually. But when you consider the administrative effort of how long it would take to provision thousands, tens of thousands and perhaps even more than that! Then this will definitely be a hurdle of course.

So if we look at the design below this gives a depiction of what we may most likely see our setup being.

So if we look closely at what this diagram illustrates and summaries in bullet points;

• Non Provisioned Devices just managed by SCCM or perhaps nothing at all
• They then are passed to SCCM for which a Task Sequence is deployed which sets a base image, and then runs the Autopilot import scripts which add the hardware hash to Autopilot.
• The machine is then applied to the Autopilot profile and auto-enrolled to Intune.
• The machine is then joined to the Azure AD
• The endpoint is ready to go

So here is a diagram which gives us an idea on where we really want to be;

So to summarize this in bulletpoints;

• Provisioned & Non provisioned devices are logically one of the same
• One process evaluates them and gets them into the auto-enrollment & Autopilot directly.
• Machines are joined to Azure AD
• Machines are managed by Intune & Autopilot.
• Endpoints are ready to go.

The most simple answer you could suggest is to simply hit Reset This PC! This would work for provisioned devices of course. But we want to take a look at the devices which are not provisioned in this case.

There are several factors which we have to take into account when it comes to Non provisioned devices and this is addressed by two questions ultimately;

• Are the devices company standard ready
• If not how do we get them company standard ready

This can be any criteria that you wish. But the most common tend to be the following;

• Windows 10 OS Build
• Business Critical Applications
• Business Critical Security Baselines
• Hardware Standard Checks

So for the build versions we can indeed manage these with Windows 10 Feature Updates and specify a version we want to stick to. But lets say we have devices that are not only not provisioned but also a ton of them are a extremely varied mix of build versions. Yes we can just add them to Intune/AutoPilot, but bear in mind they wouldn't exactly be ready to go as per the Company Standard would state. And this is where the convenience of using SCCM would come into play where we can wipe the devices off and place our ideal build.

Now this section may sound like i'm talking against the new outlined process, but that doesn't mean we still cant provision them without SCCM and still address and still use the Windows 10 feature updates.

There's always applications that absolutely have to be on all devices. Once we get to the department or user function level then this will get more interesting, but overall we all have applications where a standard user cannot simply work at all.

Having not only a list of these applications but also defining a priority to each of them is very important because this allows us to understand how we shape and deem what the company standard is.

We all want to stick to a certain security or hardening baseline for all devices which must be adhered to. Whether that's firewall policies, Bitlocker or endpoint security. Having these defined as compliance are absolutely critical to our company standard.

And not just the baselines we want to maintain this going forward to ensure all vulnerabilities are addressed with regular patching as well.

These fall into a category of where manual tasks are created. Things such as BIOS settings, asset tag information and various other things which can make or break a device from being managed in a certain way.

For example settings defined in your TPM, or secure boot which may prevent your machine from doing a UEFI PXE boot. These also follow very well in defining a standard.

In the Figure 1.2 diagram we showed how we want to group Non provisioned and Provisioned devices together, but what you don't see clearly in that diagram is simply what joins them together and allows them to step through the Modern Workplace Management process.

So this process is what will not only be the replacement for the SCCM dependency method, but also will bridge the gap of addressing many of the points defined in the Company Standard process, but also making sure the device is ready to be on boarded all round.

And we will be going deeper into what this process is in part 3.