New to Intune? Avoid this Windows Autopilot mistake!

แชร์
ฝัง
  • เผยแพร่เมื่อ 26 ส.ค. 2024
  • Here's what not to do with Windows Autopilot.

ความคิดเห็น • 22

  • @jack4553
    @jack4553 หลายเดือนก่อน +1

    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.

  • @SweDownhill
    @SweDownhill ปีที่แล้ว +5

    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 👍

    • @hyugai
      @hyugai 7 วันที่ผ่านมา +1

      @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)

    • @SweDownhill
      @SweDownhill 7 วันที่ผ่านมา

      @@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?

  • @GovG33k
    @GovG33k 4 หลายเดือนก่อน +2

    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.

    • @DeanEllerbyMVP
      @DeanEllerbyMVP  4 หลายเดือนก่อน

      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.

  • @glebgreenspan
    @glebgreenspan 11 หลายเดือนก่อน +1

    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.

  • @spiritmorin
    @spiritmorin ปีที่แล้ว +2

    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.

    • @DeanEllerbyMVP
      @DeanEllerbyMVP  ปีที่แล้ว

      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 🙂

  • @Giancarlo_Sforza
    @Giancarlo_Sforza ปีที่แล้ว +2

    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.

    • @DeanEllerbyMVP
      @DeanEllerbyMVP  ปีที่แล้ว

      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.

  • @Giancarlo_Sforza
    @Giancarlo_Sforza 11 หลายเดือนก่อน +1

    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

    • @DeanEllerbyMVP
      @DeanEllerbyMVP  11 หลายเดือนก่อน +1

      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.

  • @blablablablaaaaa
    @blablablablaaaaa ปีที่แล้ว +1

    And here I am stuck with a federated IdP that still doesn't support hybrid-AAD and AAD join in 2023

  • @tomfritsche2656
    @tomfritsche2656 4 หลายเดือนก่อน

    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.

  • @kb8570
    @kb8570 ปีที่แล้ว +3

    Hello Dean, you did not explain the 'Why'

    • @DeanEllerbyMVP
      @DeanEllerbyMVP  ปีที่แล้ว +1

      Not in full, no. But I did touch upon the why at 1:00 minute in...

    • @kb8570
      @kb8570 ปีที่แล้ว +2

      @@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.

  • @zaffusmoments4718
    @zaffusmoments4718 4 หลายเดือนก่อน

    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?

  • @Rubensteezy
    @Rubensteezy 10 หลายเดือนก่อน

    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?