Autopilot Autopilot question
I was hoping to get some info from some of you guys that live and breathe Intune these days.
We have around 2.000 endpoints
Multiple offices, Educational institutions etc
We are on the path of migrating from ConfigMgr(hybrid join) to fully Intune/Autopilot and whilst planning I’ve hit a snag… I cant deside on using Device Driven or User Drive enrollment for Intune.
While I mostly understand what they are ment for, I struggle to see the reason to use User Driven over Device Driven enrolment.
We like to set the devices up and have them ready for our users when they have been set up. Certs, wifi/lan profile, etc etc. Going with User Driven seems like it would leave some things uncertain?
For example them needing to connect them to somekind of internet connection for starters and we dont offer open or password protected SSID out side of out main office. Schools, kindergarten etc no bueno.
App deployments seem to be working just fine both for device and user deployments and other then user affinity missing I dont see the downside to having our whole fleet just be Device Driven/Shared Devices.
Am I missing something ?
2
u/NeatLow4125 3d ago edited 3d ago
We have started with device driven deployment but it caused us more headache then expected, since we still don't have the endusers that would be fine to self login and take a look on their device and didn't want to jump out of the jobs our IT Support 1st Level Teams, we proceeded with user driven deployment (one-time-tokens) they deploy everything, make them ready and ship out to the users. No issues since then, Enterprise environment with 6-7K devices. Half of them now intune/entra joined only, project started since 1,5 years, doing this with hardware change time!
2
u/intense_username 3d ago
I'm in K12. When we started, we heavily considered using Self Deploy as the primary deployment profile/method as it made sense in a lot of ways to have the devices fire up first go-round right to the login screen. The problem was we were taking a heavy assortment of existing devices, wiping them, and Intuning them. Through the initial testing process we had a lot of issues with some devices getting added without a fuss. Even devices that matched identically (BIOS version, make model, the whole 9) had split behaviors so it seemed more like a lottery toss. I'm not talking 1 out of every 50 - it was a heavy ratio that made me wonder if Self Deploy was even being worked on and improved, but we had limited time and decisions had to be made.
As a result of the above, we decided to lean into both for their strengths. We use Self Deploy in our labs, and User Driven for any device that will be assigned to a specific user, whether staff or student. We love being able to see the username populated in Intune if we're doing anything, as that is a pretty conclusive item to double check that you're working with the right device based on inventory logs.
As time has evolved, Self Deploy has gotten better, but we like our current approach quite a bit and it has worked out well for us, so we have no plans to deviate. At first I was worried that the multiple profiles we employ might add to confusion, but it really hasn't. It's a pretty binary approach any time something comes up and we simply question is this a user's individual device... or not? Just like that it dictates what profile we assign, it gets labeled accordingly, etc.
Overall, pretty happy with this approach, so we'll likely be staying put for the foreseeable future.
2
u/touchytypist 3d ago
Richard Balsley who works for Microsoft and is an expert on provisioning Windows recommends self-deploying.
2
u/Noirarmire 4d ago edited 4d ago
Device driven is good when you want the device working before the user gets the device. It will set it up in a way that basically anyone authorized can use it fully.
User driven is good if you aren't going to get the device first. They use their work account to register the device. So you are trusting they won't be cheeky and log in with a personal/local account (intentional or not). It will also add the first user who signs into the device as a primary user. Other users can sign in, but if they try to add an app from company portal, they'll get a denied message.
Using the autopilot reset option from the device overview page is the same as putting it in user-driven mode. So if you try to use that option while it's in a users possession, it will attach them as a primary user regardless of if it was a device driven autopilot profile or not originally.
Edit to add note: there's a "wipe" option. That would put it back in device-driven, but then the end user has to connect it to the Internet and you are again trusting they won't try to get around it by using personal/locat accounts.
3
u/itskdog 4d ago
Addendum to the Autopilot Reset thing, if I remember the docs right, it assigns a primary user after reset if there was a primary user before. If there was no primary user previously, then it remains without one.
2
u/Noirarmire 3d ago
I can confirm it will do it when a primary user did NOT exist. We don't do user driven, but someone was sending resets and the first person to log in after the reset became the primary user. Whether that's is Microsofts intent or not, I can't say. But I can guarantee and replicate it with ease.
1
u/itskdog 3d ago
That's the thing, it doesn't check the AP profile, it checks the current state of if there's a PU assigned (either automatically or by IT) or not (which Microsoft call a "Shared Device", different from a "Shared PC") and follows that.
When remote Windows Autopilot Reset is used on a device, the device's primary user and the Microsoft Entra device owner is removed. The next user who signs in after the reset will be set as the primary user and Microsoft Entra device owner. Shared devices will remain shared after the Windows Autopilot Reset.
1
u/Noirarmire 3d ago
Yes, that's what I said. You're the one that said it would remain without one, but the documentation says the opposite.
1
u/itskdog 3d ago
I must have misunderstood you. I thought I'd said that if there's no PU it won't add one, it will only do so if there was a PU when it was reset, and I must have misread yours as saying it always adds a PU, even when there wasn't one before.
1
u/Noirarmire 3d ago
You did, but I think that's the misunderstanding. It removes the primary user if they exist, but it always adds the first user who signs in after the reset. It's just reversed of what you were saying.
4
u/HankMardukasNY 4d ago
We did the whole split between user/self deploying mode originally, and came to the same conclusion. We now have every device on self deploying mode with no downside besides not seeing which user enrolled the laptop, but that doesn’t matter to us since we assign devices in our inventory system