I have configured hybrid autopilot for a 1500 user company, it was challenging but got there in the end, one of the major advances was pushing a manual ad sync when a new computer object joined the forest, that made the hybrid ad join alot quicker.
Can you elaborate on what you mean and how you are doing this? Do you have an automated process that triggers an AAD Connect sync when new computer objects are detected in the on-prem AD? Or are you manually triggering a sync once you see the computer object in AD and Autopilot is still running?
Hybrid autopilot sounds great in theory but it doesn't work well in reality. I'm also torn about autopilot with AAD devices because, at least to my knowledge, there's no way for an AAD device to join enterprise WiFi networks that are configured with Radius/NPS in a windows environment. This is because the AAD device doesn't exist in the local AD so the NPS match will fail during the connection attempt. Dean, if you ever find a way around this then I would love to see a video about it 😀😍😎 Thanks for great content as always 👍
@SweDownhill this is where 802.1x comes in play. So the idea is that you can auth-c and auth-z using certificate that was publish by your PKI infrastructure and in that cert you insert your intuneGUID for your radius to use it as authentication. its possible by the way for AAD devices to be connected to enterprise Wifi using device certs (theoritically you can also use user cert and combine it with intune MDM compliance, but i never done it, i like to keep things simple)
@@hyugai That's an interesting way to solve the issue. Do you know if there's any documentation about using the Intune guid-method available somewhere?
Too late. We've got 30yrs of GPO and no resources to convert to Intune CSP. Most of it will be hundreds of OMA/URI. Being public sector, we're beholden to security benchmarks so we're really stuck. At Ignite last year the PM's of Autopilot practically shamed me out of the room for using a product that our MS TAM pushed us hard on and brought in a PFE to get us started with AADHJ. Thankfully they HAVE to support this, so we're going to keep going and looking for opportunities to go cloud native at some point.
I think I understand. I’m OK with Hybrid (AADHJ) for all the reasons you mentioned - most organisations have hundreds of GPOs that simply cannot be reviewed to be converted to Intune. That said, no one is forcing organisations to use Autopilot. Autopilot is best for Cloud Only, and it’s just so much more difficult to use it for Hybrid. The caution here is simple… just don’t use it. Use some other method of building legacy devices. When you’re ready to go Cloud native, use Autopilot.
I agree. I'd rather put effort into making AAD Join computers work with local systems, such as App Proxy, than set up a cloud deployment method that needs internal resources. It's not impossible, but it's making a complex and fragile operation even more complex... It seems to me that it's more cost-effective in the long term to skip the Autopilot Hybrid step.
Absolutely. And that's pretty much my reason for this video. If all we ever see or hear is Microsoft saying that Hybrid Autopilot "works" or "is supported" or "is possible", it gives the impression that it's easy and painless. It's not, so... if you avoid it, do 🙂
@@DeanEllerbyMVP Thank you for the reply. I think the 'why' is always important because you need to have valid reasons when presenting your ideas to the IT director.
We have it working with autopilot for a year seems simple no issue 150 machines joined across Australia and Singapore now just another site. I just have an issue with TPM on new lenovo machine. Not sure if i should stop TPM on Intune or why the lenovo TPM was rejected by intune
I voted not to try Hybrid Autopilot but my vote was mainly meaning that Hybrid join is a pain. That’s not an acceptable answer tbh, as a technician I love finding solutions to problems and Hybrid join is something that can be done (although I haven’t managed to get it to work yet) amd we shouldn’t discourage people from using it in my opinion.
As a thought experiment and a technical "i really want to make this work", i agree - it's a great problem to try to solve and it definitely can be done. I absolutely disagree with your last sentence, though. We should definitely discourage people from using it. It is probably not worth the effort, when you take into account that most organisations who try to migrate to it are migrating from solutions such as MDT, ConfigMgr and USB media for no reason. Many organisations try to move to Hybrid Autopilot because they think it's *better* than the thing they're currently doing, and - given my experience and the experience of many others I've spoken to - it's probably not.
Hey Dean, I am in a new-to-me organization that is moving towards a cloud-only infrastructure plan in the future, and it currently using Hybrid-ADJoin for all devices. Right now we have Intune lightly configured for device security compliance.We are not sure when the full roll-out to the cloud will occur as we have other dependencies to get there. We currently are having issues with our current imaging process and procedures and AutoPilot has been thrown in as an idea to get us somewhere in the interim. All users would be deploying their machines on the network first day, so we wouldn't have too many issues with join from internet. Given this scenario, would it be worth while to do Hybrid AutoPilot? Or should we just save AutoPilot for the full migration?
Hi Dean, Am new to Intune. I have some idea in Sccm. Now Searching job here in USA. So how do u suggest me learn and upgrade Intune? Do I need to go online training classes?
Finally got it to work, it wasn't that hard to be honest. I found my mistake was that the Domain Join policy does not accept any variables for a device name eg. %SERIAL% which makes me kind of hate Hybrid Join in the end, cause It'd be neat to have nice uniform naming convention
Hybrid AD join is not difficult. It was quite simple and works well for our org. Until we have the time/resources to transfer our large GPO settings and time to move away from SCCM we will continue to use this. If you have a large investment in either SCCM or GPO I would not suggest moving to AAD only as this will cause you headaches in itself. If you need to direct ship devices to end users and again have a large investment in SCCM GPO I would say Hybrid is where you want to be. We typically use Autopilot to deploy and join the device and then hand it off to SCCM to complete the process. The largest hurdle is having a VPN solution that will allow you to start it before the Windows Logon. Cisco and others already allow for this and once installed no issues.
I have configured hybrid autopilot for a 1500 user company, it was challenging but got there in the end, one of the major advances was pushing a manual ad sync when a new computer object joined the forest, that made the hybrid ad join alot quicker.
Can you elaborate on what you mean and how you are doing this? Do you have an automated process that triggers an AAD Connect sync when new computer objects are detected in the on-prem AD? Or are you manually triggering a sync once you see the computer object in AD and Autopilot is still running?
Hybrid autopilot sounds great in theory but it doesn't work well in reality.
I'm also torn about autopilot with AAD devices because, at least to my knowledge, there's no way for an AAD device to join enterprise WiFi networks that are configured with Radius/NPS in a windows environment. This is because the AAD device doesn't exist in the local AD so the NPS match will fail during the connection attempt.
Dean, if you ever find a way around this then I would love to see a video about it 😀😍😎 Thanks for great content as always 👍
@SweDownhill this is where 802.1x comes in play. So the idea is that you can auth-c and auth-z using certificate that was publish by your PKI infrastructure and in that cert you insert your intuneGUID for your radius to use it as authentication. its possible by the way for AAD devices to be connected to enterprise Wifi using device certs (theoritically you can also use user cert and combine it with intune MDM compliance, but i never done it, i like to keep things simple)
@@hyugai That's an interesting way to solve the issue. Do you know if there's any documentation about using the Intune guid-method available somewhere?
100000000% will agree with you, Hybrid is super pain and ton of work and struggle to go try, where you can cut time in a half with AAD.
Too late. We've got 30yrs of GPO and no resources to convert to Intune CSP. Most of it will be hundreds of OMA/URI. Being public sector, we're beholden to security benchmarks so we're really stuck. At Ignite last year the PM's of Autopilot practically shamed me out of the room for using a product that our MS TAM pushed us hard on and brought in a PFE to get us started with AADHJ. Thankfully they HAVE to support this, so we're going to keep going and looking for opportunities to go cloud native at some point.
I think I understand.
I’m OK with Hybrid (AADHJ) for all the reasons you mentioned - most organisations have hundreds of GPOs that simply cannot be reviewed to be converted to Intune.
That said, no one is forcing organisations to use Autopilot. Autopilot is best for Cloud Only, and it’s just so much more difficult to use it for Hybrid. The caution here is simple… just don’t use it. Use some other method of building legacy devices.
When you’re ready to go Cloud native, use Autopilot.
I agree. I'd rather put effort into making AAD Join computers work with local systems, such as App Proxy, than set up a cloud deployment method that needs internal resources. It's not impossible, but it's making a complex and fragile operation even more complex... It seems to me that it's more cost-effective in the long term to skip the Autopilot Hybrid step.
Absolutely. And that's pretty much my reason for this video. If all we ever see or hear is Microsoft saying that Hybrid Autopilot "works" or "is supported" or "is possible", it gives the impression that it's easy and painless. It's not, so... if you avoid it, do 🙂
Hello Dean, you did not explain the 'Why'
Not in full, no. But I did touch upon the why at 1:00 minute in...
@@DeanEllerbyMVP Thank you for the reply. I think the 'why' is always important because you need to have valid reasons when presenting your ideas to the IT director.
We have it working with autopilot for a year seems simple no issue 150 machines joined across Australia and Singapore now just another site.
I just have an issue with TPM on new lenovo machine. Not sure if i should stop TPM on Intune or why the lenovo TPM was rejected by intune
I voted not to try Hybrid Autopilot but my vote was mainly meaning that Hybrid join is a pain.
That’s not an acceptable answer tbh, as a technician I love finding solutions to problems and Hybrid join is something that can be done (although I haven’t managed to get it to work yet) amd we shouldn’t discourage people from using it in my opinion.
As a thought experiment and a technical "i really want to make this work", i agree - it's a great problem to try to solve and it definitely can be done.
I absolutely disagree with your last sentence, though. We should definitely discourage people from using it. It is probably not worth the effort, when you take into account that most organisations who try to migrate to it are migrating from solutions such as MDT, ConfigMgr and USB media for no reason.
Many organisations try to move to Hybrid Autopilot because they think it's *better* than the thing they're currently doing, and - given my experience and the experience of many others I've spoken to - it's probably not.
And here I am stuck with a federated IdP that still doesn't support hybrid-AAD and AAD join in 2023
Hey Dean,
I am in a new-to-me organization that is moving towards a cloud-only infrastructure plan in the future, and it currently using Hybrid-ADJoin for all devices. Right now we have Intune lightly configured for device security compliance.We are not sure when the full roll-out to the cloud will occur as we have other dependencies to get there.
We currently are having issues with our current imaging process and procedures and AutoPilot has been thrown in as an idea to get us somewhere in the interim.
All users would be deploying their machines on the network first day, so we wouldn't have too many issues with join from internet.
Given this scenario, would it be worth while to do Hybrid AutoPilot? Or should we just save AutoPilot for the full migration?
Hi Dean,
Am new to Intune. I have some idea in Sccm. Now Searching job here in USA. So how do u suggest me learn and upgrade Intune? Do I need to go online training classes?
Finally got it to work, it wasn't that hard to be honest.
I found my mistake was that the Domain Join policy does not accept any variables for a device name eg. %SERIAL% which makes me kind of hate Hybrid Join in the end, cause It'd be neat to have nice uniform naming convention
Ah, yes. That's true. It only allows a prefix.
You can probably push out a Remediation script to rename the devices once they're built.
Hybrid AD join is not difficult. It was quite simple and works well for our org. Until we have the time/resources to transfer our large GPO settings and time to move away from SCCM we will continue to use this. If you have a large investment in either SCCM or GPO I would not suggest moving to AAD only as this will cause you headaches in itself. If you need to direct ship devices to end users and again have a large investment in SCCM GPO I would say Hybrid is where you want to be. We typically use Autopilot to deploy and join the device and then hand it off to SCCM to complete the process. The largest hurdle is having a VPN solution that will allow you to start it before the Windows Logon. Cisco and others already allow for this and once installed no issues.
I hate hybrid azure ad joining :(