Part 4 – Time Frame of Endpoint Readiness

Introduction

In the previous post, we covered all of the elements which would build on the overall user experience in which the user would see when it comes to the configuration of their new endpoint and get it prepared to be in a usable state where the allocated user can hit the ground running.

With all of this being said, we now want to focus on an additional part of this process which is primarily around the time frame in which an endpoint is ready. See, the time it takes for a device to be company-standard ready plays a very important part in the overall user experience. No user wants to wait for their device to finish building and not be able to do anything. Not only this, but it would also reflect badly overall to the appointed technician, IT department, and more further up the chain the more this issue occurs.

In this part we are going to explore areas where we can help reduce the duration of this process on both White Glove and non white glove scenarios and also analyze what the typical time frames would be in normal circumstances and enhanced ones.

Average Duration of Autopilot Profile Deployments

When we analyze the overall process, it primarily comes down to the three stages which we see within the enrollment status page. But unless we see a significant trend in issues across joining the domains and the registering of the device within Azure/Active directory, then we could probably agree that the bulk of the duration resides in the stage where the applications and packages are installed.

The duration of an Autopilot deployment can of course vary but lets analyze them within the stages that they go through.

Device Preparation

This phase of joining the organizations network, registering the device into Intune, and other preparations around the devices account being registered (Hybrid joined or not) would last between 15 minutes – 30 minutes. I would say anything longer than 30 minutes could constitute a network issue or perhaps something more hardware specific. But the duration mentioned earlier is a good time frame on average.

Device Setup

Now here is where we get into some interesting parts, which are perhaps where the biggest bottlenecks occur. This section takes into account where the applications are deployed. Security policies and certificates can be tricky but they don’t necessarily tend to be the cause of many issues.

If we look at some of the “typical” applications you maybe expect to see here they would be things such as:

• Company Portal
• Microsoft Office 365 (Intune Package or Win32 built from SCCM reference or more)
• Adobe Reader
• Secondary Browser i.e. Google Chrome, Mozilla Firefox, Safari
• Universal Multimedia Tool i.e. VLC Media Player, iTunes

So with these typical applications, combined with other applications a company would consider “standard”, and a couple which could be more company-specific or individual, you are perhaps looking at 8+ applications minimum on average.

Big application suites, whether in size or configuration, such as Office 365 are going to take the longest. Some of these can take up to 15 minutes to 30 minutes alone. So an average setup could potentially be between 60 minutes – 90 minutes for this stage.

Account Setup

The finishing stage sorts out the account used to initiate the endpoint build if allocated a primary user. This section takes between 10 minutes to 20 minutes on average.

Total Duration

So if we look at everything, we are assuming it would be 85 minutes, or worst case scenario – 150 minutes per endpoint. Even at the best case scenario these can be improved.

Wouldn’t It make sense to just use White Glove to scrap the duration issues altogether?

In terms of having a device pre-built and ready to go it may shave down this scenario but not completely. There are many things to take into account with this.

First lets analyze the whole pre-provisioning itself. This would still have to go through all the various stages mentioned above. So even if the duration is not experienced by an end user it would still be endured by someone in IT support or a build engineer team which would have to prepare these devices on a somewhat regular basis. And where there can be mysterious room for error, balancing the administrative effort of ensuring that they actually do finish the builds and can be logged into will only add to the overall administrative effort. So if you’re wanting to go down a White Glove route, we would still need to address the overall duration.

Another point to add into consideration is, for example a user which you give a pre-built device to may require additional applications, baselines, configuration profiles, and various other settings which are either user-specific or departmental-specific. If you don’t already have a process for application management and assignment then this would also need to be setup beforehand in order to accommodate such requests. These can of course be performed on the fly, but when more requests come in performing this on the fly can become quite tedious if a process doesn’t already exist.

How to Enhance the Duration in Device Setup Stage

The most efficient way I find to attack this is to understand exactly what the priority of the suite of applications are. When we design logical objects such as Task Sequences, runbooks or any kind of workflows we tend to sometimes add in everything we want the device to have overall all into the same logical object. While this is convenient, the compromise is the time consumption it would take to fulfill this completely.

Not to mention these kinds of configurations can leave bigger room for errors to occur, so error handling them comes into play especially when an application we wouldn’t consider as a priority could fail and disrupt the entire sequence.  So in a MEMCM example you would have something like “Continue on Error” or “Continue if the application fails to install in the list”. It works, but the drawback is not only will you not know if certain applications don’t install, it may have been easier to have deployed this in a different way or most certainly a different stage.

In Endpoint Manager we have ways in which we can overcome this and tailor these kinds of stages.

Enrollment Status Page – Top Priority Applications

We have touched on this before but it is good to reiterate this in the context of this next part as it relates a lot to this.

In the enrollment status page you can have a setting which is “Block device use until these required apps are installed if they are assigned to the user/device” where this allows us to specifically choose which applications we want installed before it can even pass the Device Setup stage.

Now when we look at the list of applications mentioned above as the most typical ones, which would we consider the highest priority that every device should have at this stage? Remember we may have a lot of applications that are high priority but there is a difference between which would be the level of what you want the device to have first before anything. Even if an application was to fail and hinder the whole apps list allocated to the device.

So I’d say Microsoft 365 Apps for Windows 10 would be a good choice. Because at least once the device has been onboarded at the very least a user can get right into it while other applications which are needed can follow as soon after a user has logged on.

Looking at Figure 1.1 we can see where we can edit this setting within our enrollment status page.

Required Application Deployment Management – Next Priority

The next section will accommodate the rest of the required assignments. These are the ones which were NOT selected in the option above. This means that they will get pushed to the endpoint once the device is on the network. And these would be great for applications which are of course needed, but they may not be ones which would need to be accessible right away. This cuts down considerably on the time taken within the Autopilot process.

You can see an application as an example in Figure 1.2

Available Application Deployment Management – Self-Service Priority

The last section would be around the applications which can be free to download at leisure by the user as a self-service option, where they are made available via the company portal.

As these are removed from the overall Autopilot process, this cuts down even more when we assign this priority where we can allow these to be done at any time as there maybe ones which may be needed but more on an optional front.

Below is an example of an application in a available assignment in Figure 1.3

Next on Part 5

Next we will discuss going down the third party routes, which will allow you to offload the device enrollment up to the builds on the devices before they are provided to you or to allocated users. Until then, reach out to us via email or phone if we can help.