Analysing Hybrid Scenarios
Introduction
All the parts of the series we went into great detail about how we analyse an end to end solution and how we would design a solution in which would allow us to build endpoints without SCCM being a dependency.
Whilst we did this, there is another scenario which we have not touched on yet, which is the hybrid scenarios.
In a perfect world ideally you would have your Azure Active Directory within the cloud, every machine meets the recommended requirements for Windows 10, everything is imported into Intune/Autopilot and everyone is happy.
But we know this isn't realistic in all cases. Many organisations cannot just simply up and go from on-premise into the cloud therefore the checkpoint here is of course getting into hybrid solutions such as;
- Co-Management Between Intune and SCCM
- Hybrid AD with Azure AD and On-Premise AD syncing together
These things can play a very interesting part in how you would tackle this if you envisage the next step in the blueprint is to be in a position in which you can build and manage endpoints soley within Intune.
With this final part of the series we will go in-depth in how the common hybrid setups look like and how we go about moving into the next step of being able to manage and build devices without SCCM.
Current Hybrid Design And Process
First we need to outline in high level how a typical hybrid solution would look, very similar to the 2nd part of this series when we looked at a typical setup in a perfect world scenario.
Once we have a view of this we will understand the role in which endpoints play once they go through the workflow cycle of being a device managed by Intune/Autopilot.
Below in Figure 1.1
we can see a detailed diagram of how a hybrid solution is currently looking like.
Looking at how this is laid out we will then also draw out how this would look for an endpoint going through this process as we see it;
- A new device gets built via MEMCM Task Sequence
- Device is then provisioned to be an Autopilot Device
- Device goes through the Autopilot process once the user has logged in with their credentials
- Device then is joined to the Azure AD and also the On-Premise AD
- Endpoint is now ready managed by both Intune and MEMCM as well as Azure AD and On Premise AD
There are of course a few little bits to configure before it will just get you to the point of being in a hybrid AD environment which will go into further in the next sections below.
Notice though in the diagram I have left the Non Provisioned and Provisioned devices there. Reason being is because yes the main goal is to eradicate the categories, but as a lot of us maybe in a hybrid scenario these categories will still linger as we still have devices coming in or registered in multiple places such as;
- Autopilot Only
- Intune Only
- SCCM Co-Management
- Azure AD Joined Only
- On-Premise AD Only
So the next sections will help to consolidate these paths where once we get devices from all areas centralized we can then start to work on the removal of the categories of non provisioned and provisioned.
Consideration of the Hybrid Connector
Of course one of the next things you want to do is also be able to get your devices enrolled into Autopilot. Given the hybrid scenarios and of course with the addition of an on-premise Active Directory you have another option.For where you have your on-premise computer accounts in AD, you can utilise an Intune Connector
which will allow you to have the same computer accounts created within your on premise AD so that they are ready to go when needing to rebuild those endpoints again.
The process works by taking devices which have been already provisioned within Autopilot and then creates them within the On-Premise AD, so when it comes to the provisioning process via Autopilot the device is then ready to go once the endpoint has been enrolled.
If you have an environment where you have a multitude of devices in Intune/Autopilot which are not on-premise joined already then this is most certainly an option to look into.
An extensive guide is available for how implement this here
Co-Management Affinity - Between SCCM and Intune
For those which use Co-Management we are at that safe point where we cannot call as to which direction we want to stay in and that is most certainly fine. The overall solution is not to necessarily make a case where we dump SCCM as such, but to at least remove a core dependency of the responsibility of building devices.
Now in a Co-Management case, once we have a nominated device collection and Azure AD group in mind, those devices will then have records within Intune now and you will be able to identify them in the properties of the Intune devices by looking at it's Managed By section reading as Co-Managed.
Depending on the setup you have with devices which are solely manged in SCCM, there is a high chance your devices will primarily be managed within an On-Premise AD unless you are using the Azure AD Connector or have it where devices are using a work or school account configuration to be managed in Intune without an auto-enrolment in place.
But with Co-Management, this is primarily to get Windows 10 Devices managed which are of course eligible, but also means there are devices within your estate which you cannot manage by Intune therefore SCCM is still needed. The devices which are in Co-Management can be eligible for the Intune Connector to prep them for autopilot deployment as well as the whole provisioning process which will allow them to be Hybrid AD Joined afterwards.
Preparing Intune for Hybrid Autopilot Deployment
Taking all of the previous parts into account as well as the design prep considerations above, we just need to tweak a couple of things to ensure that everything is good for supporting the hybrid scenario.
Domain Join Profile
This configuration profile is primarily for your on-premise AD, and this will be applied during the autopilot profile is being deployed to your endpoint.
The domain join profile does have some prerequisites. One being the actual Intune Connector. The connector would have had permissions delegated to an OU in which it could be able to create the Autopilot devices with, this is also the same so the relevant delegated permissions need to be in place for this to work.
Once this has been completed ensure that you deploy the configuration profile to the group which has your autopilot devices so when it comes to a reset or rebuild this will come into play during the autopilot process.
Autopilot Deployment Profile
To ensure that our autopilot deployment profile also accommodates our hybrid setup, we need to edit this so that we are able to use a Hybrid Azure AD Joined profile.
Now you may not be able to edit a current one so you may have to create a new one which reflects the settings below in Figure 1.3
specifically around the Join to Azure AD as
line
Once this has been completed ensure that you deploy the configuration profile to the group which has your autopilot devices so when it comes to a reset or rebuild this will come into play during the autopilot process.
Third Party Option?
So for those who are moving towards a third party to provision devices before they are shipped either to the user or to the organisation itself to distribute them, the hybrid scenario is something which the third party will need to accommodate.
There maybe a reason to bring a VPN into the scenario so that devices can go through the hybrid join process so that when they arrive they will be ready to be supported. An always on VPN solution could be ideal for this scenario indeed.
End of Series
This now concludes the whole series. Hopefully this has covered a lot of areas well and looking to come back with some additions to this at some point soon.
