Hello! Your videos about Intune are really good! Even configuring access according to your video, at no point does the computer show the process on the Setting up for work school screen, informing you that the programs are being installed and configured. Do you have a link to the official Microsoft documentation for deploying AutoPilot V2?
If you're having that issue, verify which build of Windows you're using. Details here: www.getrubix.com/blog/how-to-configure-autopilot-device-preparation-part-2-user-experience
This looks like a dumpster fire. The point of Autopilot was to streamline the OOBE. If I'm generous I'd describe it as half baked. I don't get how this has made it into production in this state.
Hello! I have a question regarding Autopilot V1 and V2. Autopilot V1 I have to enter information into Intune, such as hardware hash. In the case of Autopilot V2, I no longer need to execute the process. How should I proceed with the acquisition of new devices with Dell, since there is no longer a need to have the hardware hash. Just ask the manufacturer to send the devices and that's it?
Thank you so much for this amazingly detailed video!!! I guess I am still stuck in the "OG" Autopilot mindset, because I am confused as to how will Autopilot V2 know to enroll my new device to the correct device group (W2), withOUT me uploading the hardware hash and assigning it to a device group in order for the policies and profiles to attach to it. How will this "Intune Autopilot Confidential client" Know how to recognize my brand new laptop, apply the apps and policies to it without knowing its Identification(hardware hash)? This is where Im still lost
Thanks- it's a VERY different mind set, but I will say this; unless there is a reason you cannot use V1, I would continue to do so until V2 becomes more fleshed out.
I wish we could just have the better ESP and the new diagnostic reporting folded back into the old Autopilot. In fact, I wish we had a GOOD ESP which actually told you what it was doing (e.g. the name of the app it's installing), but I'd take this new one over the old one. But this just doesn't do what Autopilot does, seemingly by design. I was really thinking this was going to be awesome, and I'm gutted that's it's so bad. I'm guessing they won't now fix the issues in APv1, they'll just leave it to stagnate until they kill it... 😞
I thought this new user-centric deployment would be cool. I can have separate user groups that would put their machines in different device groups and the big thing for me was a device naming standard. Users at different sites would have machines with a different prefix, easy-peasy. I go to demo this out and realize you CAN'T set the device name (yet) in the OOBE profile. I'm going to test pushing a script to rename the computer and hopefully it will only rename the computer once after a reboot.
Anyone seen the issue where the Device group is not saved.. The group owner is set correctly with the Intune Autopilot ConfidentialClient and the app id is correct..
I like the fact that there is no upload needed anymore, but - no Hybrid Domain Join? this is a no go for us. We do this standard. - asking a user to name his computer - say goodbye to your standard naming conventions. This will only create more work for admins to tell Jason to rename his 'PokemonSeeker' to instead. Hope this is becoming standardized at some point. - Privacy settings, should be able to be hidden as well.
This is prob a dumb question, but as Entra is now the old Azure AD, signing up this device with the User account already in Azure which is pulled from our Ms 365 Admin Center, means it is essentially in Azure AD (now Entra) and as such I can control printer drivers, local drivers, app etc..? Sorry very new to Azure always been in physical domains. Does this mean also that this device is now part of my Domain? Or is it only linked to the user in Entra only?
Joining to Entra (Cloud Native) means the device is not physically part of the domain. But if the user who signed in is syncing from on-premises Active Directory, they will be able to SSO into resources like printers, drivers, etc. Check out this playlist I did on Cloud Native devices: ruclips.net/p/PLKROqDcmQsFlk61rLJRfN3szDg6ZPmuZa&si=BD5SBAoST1zaBbDT
Your video is awesome - constructive criticism just as deserved. Now my take: AP is crap, sure but this? This is crap on steroids, anything that must be shown to the user when they open the box should be "press ctrl-alt-del to login" - APv2 is nearly a guarantee for a fail; even if zero questions are presented the sheer fact of anything happening in front of the user is an invitation for failure
ty for vid bro, but how do you generate the identifier remotely , yes know you can create .csv and uploud , but in apv1 you could do a -online and generate the hash to pre populate the the device container , does the msp have tool to push the serial no & model the device group , seem to me like we have do more work here ....
I got a question and hoping you can answer. I setup AP device prep. works great, my only is this. All my test devices just don't seem to install apps during the setup process, and they only install after setup is complete. When I look at Devices>Montior>Device prep and select my test device, in the "App" selection field, It shows no apps there either. Any idea what I could be missing here? I deployed the apps I want to deploy on intial setup to my device group, and selected all the correct apps. I have my device group setup correctly with the correct owner too. I don't know what could be preventing it from installing apps but it seems to completely skip that part during the setup page
I'm not really sure- it sounds like you did everything correct, with the Apps being targeted to the same group that the Autopilot V2 profile is assigned to. Are the apps set to assign in SYSTEM context or 'user' ?
@@getrubix I actually figured this out. It seems there is a bug that causes issues with it. MS has an entire document about it. Seems to be working perfectly now. So happy. We are in GCCH and this is the first time we have a true autopilot even though it's not a true AP lol
Really glad to hear- the initial reception to AP V2 was mixed (to say the least), but most folks didn't understand the impact to GCCH. And once we can go the corporate device identifier route, then we're really in business!
GAH! It took me a while to figure out Intune Autopilot ConfidentialClient. I should have waited until you covered it in the video.
Hello!
Your videos about Intune are really good!
Even configuring access according to your video, at no point does the computer show the process on the Setting up for work school screen, informing you that the programs are being installed and configured.
Do you have a link to the official Microsoft documentation for deploying AutoPilot V2?
If you're having that issue, verify which build of Windows you're using. Details here: www.getrubix.com/blog/how-to-configure-autopilot-device-preparation-part-2-user-experience
@@getrubix Thank you very much for your willingness to answer my question. Your content about Microsoft Intune is very TOP!
This looks like a dumpster fire. The point of Autopilot was to streamline the OOBE. If I'm generous I'd describe it as half baked. I don't get how this has made it into production in this state.
absolute disaster, I'm so glad I saw your reply; I felt like the black sheep here lol
Nice and look forward to using this. thank you.
Glad you like it!
Great video though, much appreciated. I'm glad the MVP hasn't stopped you telling it like it is.
Thanks- I'm still me, and Microsoft seems to really value the different perspectives
Nice intro. I can understand the hesitation to trust end users with pretty much anything.
Hello! I have a question regarding Autopilot V1 and V2. Autopilot V1 I have to enter information into Intune, such as hardware hash. In the case of Autopilot V2, I no longer need to execute the process. How should I proceed with the acquisition of new devices with Dell, since there is no longer a need to have the hardware hash. Just ask the manufacturer to send the devices and that's it?
Thank you so much for this amazingly detailed video!!! I guess I am still stuck in the "OG" Autopilot mindset, because I am confused as to how will Autopilot V2 know to enroll my new device to the correct device group (W2), withOUT me uploading the hardware hash and assigning it to a device group in order for the policies and profiles to attach to it. How will this "Intune Autopilot Confidential client" Know how to recognize my brand new laptop, apply the apps and policies to it without knowing its Identification(hardware hash)? This is where Im still lost
Thanks- it's a VERY different mind set, but I will say this; unless there is a reason you cannot use V1, I would continue to do so until V2 becomes more fleshed out.
I wish we could just have the better ESP and the new diagnostic reporting folded back into the old Autopilot. In fact, I wish we had a GOOD ESP which actually told you what it was doing (e.g. the name of the app it's installing), but I'd take this new one over the old one. But this just doesn't do what Autopilot does, seemingly by design. I was really thinking this was going to be awesome, and I'm gutted that's it's so bad. I'm guessing they won't now fix the issues in APv1, they'll just leave it to stagnate until they kill it... 😞
You should definitely hop into the discord to discuss further... discord.gg/getrubix
I thought this new user-centric deployment would be cool. I can have separate user groups that would put their machines in different device groups and the big thing for me was a device naming standard. Users at different sites would have machines with a different prefix, easy-peasy. I go to demo this out and realize you CAN'T set the device name (yet) in the OOBE profile. I'm going to test pushing a script to rename the computer and hopefully it will only rename the computer once after a reboot.
Anyone seen the issue where the Device group is not saved.. The group owner is set correctly with the Intune Autopilot ConfidentialClient and the app id is correct..
The group isn't saving meaning it's not visible in Intune or not collecting device members?
Keep up the good work! 👍🏻
Thank you!
I like the fact that there is no upload needed anymore, but
- no Hybrid Domain Join? this is a no go for us. We do this standard.
- asking a user to name his computer - say goodbye to your standard naming conventions. This will only create more work for admins to tell Jason to rename his 'PokemonSeeker' to instead. Hope this is becoming standardized at some point.
- Privacy settings, should be able to be hidden as well.
Absolutely valid. These are things Autopilot V1 handled for us, so it’s easily a deal breaker for V2
This is prob a dumb question, but as Entra is now the old Azure AD, signing up this device with the User account already in Azure which is pulled from our Ms 365 Admin Center, means it is essentially in Azure AD (now Entra) and as such I can control printer drivers, local drivers, app etc..? Sorry very new to Azure always been in physical domains. Does this mean also that this device is now part of my Domain? Or is it only linked to the user in Entra only?
Joining to Entra (Cloud Native) means the device is not physically part of the domain. But if the user who signed in is syncing from on-premises Active Directory, they will be able to SSO into resources like printers, drivers, etc. Check out this playlist I did on Cloud Native devices: ruclips.net/p/PLKROqDcmQsFlk61rLJRfN3szDg6ZPmuZa&si=BD5SBAoST1zaBbDT
Great video, but if I am being honest it gives the end user way to many choices. I'll be sticking with AutoPilotV1
Most folks are
Your video is awesome - constructive criticism just as deserved. Now my take: AP is crap, sure but this? This is crap on steroids, anything that must be shown to the user when they open the box should be "press ctrl-alt-del to login" - APv2 is nearly a guarantee for a fail; even if zero questions are presented the sheer fact of anything happening in front of the user is an invitation for failure
ty for vid bro, but how do you generate the identifier remotely , yes know you can create .csv and uploud , but in apv1 you could do a -online and generate the hash to pre populate the the device container , does the msp have tool to push the serial no & model the device group , seem to me like we have do more work here ....
All will be answered in Part 2... and Part 3 :)
I got a question and hoping you can answer. I setup AP device prep. works great, my only is this. All my test devices just don't seem to install apps during the setup process, and they only install after setup is complete. When I look at Devices>Montior>Device prep and select my test device, in the "App" selection field, It shows no apps there either. Any idea what I could be missing here? I deployed the apps I want to deploy on intial setup to my device group, and selected all the correct apps. I have my device group setup correctly with the correct owner too. I don't know what could be preventing it from installing apps but it seems to completely skip that part during the setup page
I'm not really sure- it sounds like you did everything correct, with the Apps being targeted to the same group that the Autopilot V2 profile is assigned to. Are the apps set to assign in SYSTEM context or 'user' ?
@@getrubix I actually figured this out. It seems there is a bug that causes issues with it. MS has an entire document about it. Seems to be working perfectly now. So happy. We are in GCCH and this is the first time we have a true autopilot even though it's not a true AP lol
Really glad to hear- the initial reception to AP V2 was mixed (to say the least), but most folks didn't understand the impact to GCCH. And once we can go the corporate device identifier route, then we're really in business!