Modern Workplace Management - Build Endpoints without SCCM Part 3

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.

This is the part which was not visible in the diagrams. Reason being is because we want this to be a seamless transition, embedded part of the process that gets you from point a to point b.

But first, lets explore how we see the provisioning phase working below.

This diagram gives a flow chart which mimics how we would see a typical build checklist would go, and then see it go through the motions where we would then have the machine prepared within this process and then we can say yes its ready to go through Autopilot or even the white glove process.

In real world cases this process is split up where prerequisite checks can be of a manual process, where as there are scripts which can easily add a machine into Intune & Autopilot, more notably the Get-WindowsAutopilotInfo.ps1 script

Depending on manufacturer these can range from various little tasks such as;

1. Ensuring TPM is enabled and using 2.0 for using Bit locker
2. Secure Boot if using a UEFI boot using something like SCCM
3. Time & Date Settings in BIOS
4. Standardised Boot Order
5. BIOS Updates (optional but can vary)
6. Removal of existing device records (i.e Active Directory, SCCM, Intune, Azure AD)
7. Checking if device exists in Autopilot already

These are the somewhat obvious bits when looking to get machines enrolled in masses. A task sequence that would contain things like;

1. Enroll into Intune
2. Add device to Autopilot
3. Check if Autopilot profile has been added

Of course these can be done manually, but you don't want to be doing this manually :)

Tasks such as these are consolidated within some form of a Task Sequence to be able to deploy to mass amounts of devices. But as you can see with both the manual checklist and automatic one we have a semi-automatic process altogether. There isn't anything wrong with this as semi-automatic approaches have a benefit of at least being checked over with some form of human interaction. But we would like to get to a point we can automatic and logically structure this process as close as possible.

To reiterate this section is applicable for management of all existing machines within your estate and not for machines which are brand new. These ideally would already be provisioned and ready to go. Having said this a new device will turn into an existing device so bear this in mind.

Very simple and straight forward option to go with when needing to reset the device to go through the process again if giving the device to another user.

Of course this option is useful if you are absolutely certain that everything has had a check so that it had all of the standardised requirements, and that's more on the hardware front. Depending on the kind of setup you have whether it would be an Azure AD or even hybrid scenarios (will be covered in a later part) there are still other technologies you would have to consider to perform clean ups on before you can move forward.

Take for example Active Directory and SCCM/MEMCM. If you are going through the Autopilot and joining the machine to the domain whether the scenario you could run into issues where the record already exists and therefore has an issue joining it to the domain and that would have a knock on affect on the Autopilot process.

Then looking at the SCCM/MEMCM side of things, this isn't necessarily as critical but you could face duplicate device records and if deploying anything via SCCM still can also cause issues too.

The wipe device method is also great. Bear in mind your device would have to already be managed by Intune at this point, and is seen more of a security measured in case a device is lost. But it does have its benefits when wanting to reset a machine too.

Here is where we want to add the magic.

What we ideally want to do is to turn those manual checks into a process which goes through these seamlessly and then prepare the machine to be reset. Best thing to compare this to would be similar to how you would have seen a Windows Feature update be applied.

First thing it does is check all of the prerequisites, mandatory ones of course if that fails then the upgrade will essentially stop but if any optional ones flag up it wouldn't halt the process. And this is what we want.

Figure 1.2 - Shows how we want it to be as just one process, and not split up into multiple tasks. But lets perhaps cover the tasks in which we have mentioned just to give a high level overview of how this can be automated into a process.

BIOS Checks
 So we mentioned earlier about things such as

• Setting Date & Time
  
• Enabling Secure Boot
• Enabling TPM
• Ensuring Virtualization is Enabled
• Organising of Boot Order

 Removing Device Records
 This can be tricky. Perhaps more on an Active Directory front.

 In an ideal world we would love to automate the removal of device records from technologies such as SCCM, AD etc but there are some factors you have to think about, especially since I've experienced this.

Say for example you remove the computer from AD but you either accidently or purposely reboot the machine for whatever reason, you can't get back into the machine after that. Unless you have a local account on the machine you would have problems. Now you can wipe the device from Intune ONLY if its managed in Intune and you can ONLY Reset This PC if you haven't used anything such as Bitlocker. Why? because it will ask you for a recovery ID and if you don't have that at hand you will simply have a dead machine.

So we want to have a process for a section such as this to do the following;

• Detect whether the records exist or not

• Detect whether a local account exists or not, if not then create it

• Proceed to remove account in preparation

 Enrolling to Intune/Autopilot

This part is mostly in best practice done within an SCCM task sequence. And what we want to do is take SCCM out of the equation for this process.

So we utilise the scripts that perform this step, extract the commands out of it and then build the automated reset pc process with it which would do the following;

• Obtain the device serial number
• Connect to Intune
• Produce the hardware hash
• Check that the device is already in Autopilot
• If not then upload it to the Autopilot
• Check to see if the Autopilot Profile has been deployed (optional)

Next part we will show a template which can be followed to automate this process for when it comes to re-provisioning devices and also cover the process parts in the Intune/Autopilot side. Will be quite a lengthy part so will be coming soon as!