Modern Workplace Management: Build Endpoints without SCCM Part 4

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.

We will look at how we construct this technically but we will also look at two ways in which we can do this. But the whole idea is to make this a script based process which will automate the assessment of the device before we say OK its in a position to be reset and then be put in a position to be put through Autopilot...or even whitegloved.

For the BIOS checks as we mentioned we have various methods of how we would check settings as well as set them such as;

• Enabling Secure Boot
• Enabling TPM
• Ensuring Virtualization is Enabled

So looking at the first section in Figure 1.1 we have a done a few things for this process;

• Obtain the manufacturer details
• Detect if the device is a Lenovo manufacturer
• If it is then obtain all of the BIOS information details
• Ask for BIOS Password

This first section focuses on the capturing of information currently configured on the device where the BIOS is concerned. Which covers everything we talked about in the bulletpoints above.

Once thing we need to take note of which is quite an important line which is the $mypassword variable.

When it comes to the Lenovo BIOS settings via WMI, one of the things you simply CANNOT do is set a BIOS password for a Lenovo device where no password was set beforehand. This can only be done if a password was already set beforehand, hence the reason for the line which asks for a BIOS password as in order to make any changes to the BIOS via this method you need the password in order to make any BIOS changes.

For more information on the Lenovo WMI BIOS settings you can obtain a guide here https://download.lenovo.com/pccbbs/mobiles_pdf/kbl-r_deploy_01.pdf

This section is also great for when you have multiple vendors where if you want to add additional vendors such as HP then you can make another section in your script to include this.

The second part of the BIOS checks is where we do the verification of the BIOS Password as stated above. There is a line in there which will essentially stop the script running any further if no BIOS Password has been set. This would allow a user to set the BIOS password manually on the device and they can kick the script off again when ready.

The TPM verification will check if its enabled, as this is quite important when wanting to use Bitlocker as well as managing its recovery keys. If the TPM chip is not enabled then it would enable this feature.

Final part of this section looks at the verification of the Secure Boot and Virtualization Technology.

The Secure Boot feature has the same caveat as the BIOS password where it cannot be enabled through this, so I've placed some lines which will say if it is enabled or not. If you require this enabling then you would need to do this manually on the device.

The virtualization setting on the other hand can be enabled if detected its not enabled already.

This section is really optional as in the next part we will show how to get all of these into Autopilot anyway. But if you do have a policy in which you want to stagger which devices would get into Autopilot then this section is perfect.

So this will do the following;

• Obtain the serial number of the device
• Prompt you to connect to your Intune tenancy
• Check if the device is in Autopilot
• If not then it will add it to Autopilot
• Then will check to see an Autopilot Profile has been deployed

Again this could be another optional section if you are using SCCM to a certain level.

If using Co-Management or just using SCCM in a normal fashion, if the endpoint you are working on also contains an SCCM agent then there could be a potential issue where you could have duplicate records once this machine is rebuilt This could even happen when having an Active Directory System Discovery which would discover an obsolete record there.

This section will check to see if the record exists in SCCM, if it does then it will delete it.

Once everything has gone through and been validated up to a standard which we are happy with, then the last part is to run the systemreset command which will prepare the machine to go back into an OOBE (Out of box experience) state

When we think about how the devices are managed on the floor we think of service desk and hardware support. In cases where we want to kick the machines off to be reset we would kick the script off on the machine.

The best way to achieve this would be to create a Win32 Application which would be deployed to all of the devices which are also registered within Autopilot so when it is kicked off, we know the machine will already have an Autopilot profile already associated with it.

Another way is to perhaps split these sections or not and have them run as a Proactive Remediation script.

The aim would be here is to be able to have a reported amount of how we would deem "eligible endpoints" that can indeed be reset. Whilst the scenario above is great, we have to take into account the remote aspect of things.

So for example say we create a brand new group in Intune, and then we build a dynamic query of devices that are all based on a Lenovo Manufacturer.

Then we take a new template which we have which is based off the Automated Reset PC script but we split this up so we will focus on this being the Lenovo BIOS settings section.

So we then deploy this to the Lenovo Devices group, and this would then check to see if all of our BIOS Settings are enabled and this would mean they show as compliant. If not then they are not compliant.

But the important thing is that we would have a list of which machines are deemed as ready to go. And then we can go ahead and hit the Wipe Device button.

Of course depending on your setup either a service desk user would be able to control the other side, or instructions for a user which would allow them to just log right into the device using their email or login credentials which would set the device up right after it enters the OOBE state.

The next part we will focus on how we do the technical steps on the Endpoint Manager side so that we consolidate the overall workflow between the Automated Reset PC process and the back end of Intune.

You can download the template scripts used in the article right hereto reference from.