Microsoft Endpoint Manager: Autopilot – White Glove or Not? Part 6 – Hybrid Scenario

Introduction

In the previous part we went through the third party vendor options and how they contribute towards the autopilot process workflow. We also discussed how it would look to either enhance or offload to structure the process out.

This next part will be quite an interesting part as this will be a collation of everything we have covered in all of the previous parts released and it will show how these decisions will look when incorporated into a hybrid setup where you have an Azure AD and an On-Premise AD setup.

How does white glove have ANY say in a hybrid setup?

This is perhaps a more complicated answer. White glove doesn’t necessarily have to play any part in a hybrid scenario, but what we will try to cover is perhaps some of the benefits or conveniences it has when it comes to this.

Lets paint the overall picture of a hybrid environment. So we essentially have an on premise active directory and then we also have an Azure AD as well, where once the device is enrolled it will join both of them.

Now there are many parts that come into play such as the Intune connector to create objects within the on-premise AD into the Autopilot portal to form the correlation between both endpoint accounts
(Note: Please see here for more information on this)

What we want to do in this part is to provide an overview of areas in how Autopilot and white glove option would play in this.

So what is or is there an actual benefit to using White Glove in a Hybrid Environment?

Well when we look at the actual deployment that takes place for the ESP (enrollment status page), what differs to the deployment as opposed to being in just an Azure AD is that the first stage would be where domain joins would happen between both on-premise and Azure AD.
(Note: Ensure that you have a Domain Join profile created if you are within a Hybrid setup. Information on how to create one can be found here.)

In this instance if you perhaps wanted to minimize the potential errors that could come from the domain join stages it could be worth having the white glove process involved. Of course this is heavily dependent on where the devices would be going through the Autopilot process.

If this was done in the office then there maybe a easier process to it, however depending on the working culture implemented, where users are able to work anywhere, then you have to take into account VPN connectivity whether that be from VPN clients, VPN Profiles within Intune, and if users are accessing from direct access. These type of scenarios would need to be considered, as you may not want users to have a hit and miss headache over devices which may have issues reaching the on-premise active directory.

What if a third party were to take care of devices in a Hybrid Environment?

Where third parties are concerned this could be a saving grace where they could handle that headache for you. With that being said, it would come with its challenges as there is still the VPN hurdle as they would need to be able to connect to your environment which has the on-premise domain. Perhaps slightly out of scope for this series but definitely worth noting if wanting to pursue this option.

Any known issues to watch out for?

The main one which comes to me is normally around devices joining the on premise domains and especially when naming devices through the Autopilot portal

Figure 1.1 – Windows Autopilot Devices right panel options

May not happen too often but I have seen issues where once the enrollment is completed, and when trying to sign into the on-premise domain, you will get an error such as “The security database on the server does not have a computer account for this workstation trust“.

Many areas could be the cause for this such as:

  • Synchronization issues between Azure AD and On-Premise AD
  • Conflicts with device name configurations in Autopilot profile
  • Stale records still in AD (On-Prem or/and Azure AD)
  • Issues with the Intune Connector creating the device record in Autopilot

These particular issues aren’t “White Glove” specific, but are worth highlighting if you were to ever come across them.

End of Series

This part now concludes the whole series.

Overall I hope each part has been able to cover at least the majority of scenarios – whether that is the normal process or utilizing White Glove.

When it comes down to it, it really comes down to the preference but also the overall objectives the organization is trying to achieve. This series made sure to explore all options and not have a biased approach as to which route you should take.

If you need guidance implementing any of these scenarios for your organization, please reach out to us via email, or phone.

Share:

Facebook
Twitter
LinkedIn

Contact Us

=
On Key

More Posts

WME Cybersecurity Briefings No. 004
Cyber Security

WME Security Briefing 11 April 2024

Mispadu Trojan Exploits Windows Vulnerability to Target Financial Data Overview The Mispadu banking trojan has intensified its operations as it’s exploiting an already patched Windows SmartScreen flaw. Since its initial identification in 2019, Mispadu has primarily preyed on

Read More »
WME Cybersecurity Briefings No. 003
Cyber Security

WME Security Briefing 29 March 2024

Russian hackers escalating their cyber warfare, deploying TinyTurla-NG to breach European NGOs. Cisco Talos reveals a targeted attack against organizations advocating democracy and supporting Ukraine. With their sophisticated methods, these cyber attackers are bypassing antivirus defenses

Read More »
Be assured of everything

Get WME Services

Stay ahead of the competition with our Professional IT offerings.

=