Where to start with Autopilot

[tcable]

Hi All,

 

Been slowly moving our on prem to the cloud (got app and polices running though Intune, windows updates over Easter), and we are currently co-managed using sccm. Once i have completed these, that only thing i think i will be using SCCM for is OS deployment.

 

I want to start to use autopilot to provision devices instead of SCCM and move away from co-management, but I'm getting super confused on where to start and set this up. I've tried ready various articles and scrolling though the forum here, but not really finding the answers that i want (or at least not or a educational setting with devices used by more than one user).

 

I know how to get the hardware ID from devices and import into Intune - I've already done that for my test device - and i believe the best way to reinstall windows is through a USB version of the OS, but it's the deployment profile that I am getting confused with.

 

Do I need user-driven or self-deploying? I think user-driven is for 1:1 laptops, and self-deploying is for shared devices? or are they the same thing, just not as automated?

 

if it's a shared device, do i need to do anything special once it is all deployed? I.e. I know intune deploys a primary user, so does this need to be removed, and if it does, is there an automated way of doing it?)

 

Do i need a 'deployment' account to sign into the machine for the first time to complete the setup? All devices will go to IT first to be configured before going out to users/classrooms.

 

Can I still access my on prem network if a device is entra connected? Ideally I want to move away from hybrid approach so I can manage everything in the cloud and manage devices regardless of where they physically are, but I'll still need to access some on-prem services like SIMS and a few legacy group policies that i haven't managed to migrate to intune yet, so this is a requirement. I assume if this is the case, then it needs to be set up as a hybrid device, rather than entra joined.

 

sorry for all the questions and if this is basic - I'm just starting to confuse myself (and possibly taking something that is very simple and making it very confusing) and hopefully get some guidance before I start to test this after the Easter holidays.

 

Thanks in advance.

Edited March 17, 2024 by tcable

[phil1lock]

That Mr C is very easy to do and use - all it is, is practise and you are good at that

youll need for existing machines a usb version of windows to set back to the oobe, self deploy is best but only takes you so far

youll need a suitable dynamic aad group for the pc's to go in and get policies

you should still get internal connection if it is an aad machine but for legacy gpo then will need to be domain joined

 

Phil

[psydii]

Assuming you haven't taken steps to completely block the Windows Recovery Environment, you don't even need a USB

 

There is a script to bring legacy machines into autopilot. The (now former) Microsoft Employee who made the original get-autopilotinfo script's blog is a fantastic place to know about: https://oofhours.com/.

 

He 'endorses' a community lead update to his script since it seems nobody at MS is maintaining his script since changes in MS Graph sometime last year.

https://oofhours.com/2023/06/09/get-windowsautopilotinfo-ps1-updated-but-not-by-microsoft/

https://andrewstaylor.com/2023/06/14/get-windowsautopilotinfo-and-windowsautopilotintune-community-editions/

(MS did update their script later in June, however as of February 2024 I could not get the Microsoft one to work and had to swap it out for the community edition)

 

You need an autopilot profile that applies to the tag you specify when running the script. I use the self-deploying option. We have a dynamic AAD groups that pick up devices with these tags as members. Intune configuration profiles (a completely separate thing to AutoPilot profiles) are deployed to these groups (as appropriate) (dynamic group / autopilot / intune configuration profiles used to be highly unreliable for us, it seems that things have got more consistent and this combination of tech now works 98-99% of the time) The tag from autopilot is exposed as the OrderID in Entra/AAD so the rule for the AAD/EntraID group(s) need to look something like: (device.devicePhysicalIds -any (_ -eq "[OrderID]:TAGNAMEINAUTOPILOT")) https://learn.microsoft.com/en-us/autopilot/enrollment-autopilot

Tutorial: https://learn.microsoft.com/en-us/autopilot/tutorial/self-deploying/self-deploying-workflow

 

(we have shared devices, student one to one devices, and staff one to one devices as both Autopilot Tags and AAD groups to which profiles etc are deployed this so far has covered all requirements and is markedly simpler that our 20 year old+ AD OU/Group and Group Policy / SCCM collection arrangement)

 

Once a device is AutoPilot registered, autopilot profiles and Intune configuration profiles are assigned to the appropriate groups that your computer will become a member of you can issue the following command on computer to re-image it without needing a USB:

 

shutdown /o /r /t 0

 

You will end up in the Troubleshooting / Maintenance screen - step through that to reset the PC (wipe data option) and it will wipe itself and reinstall from the recovery partition(*). The Windows install process will detect it is an Autopilot'd device and everything will happen automatically.

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/windows-recovery-environment-explained/ba-p/2273533

 

With a correctly configured Azure AD Connect set up, your AAD/EntraID devices should be able to get Kerberos tickets for themselves and the 365 users who log on, simplifying access to legacy network resources. I haven't explored this much. You can check if you are good to by following the step in the "lab sign in" section of this page: https://msendpointmgr.com/2021/08/15/sso-to-domain-resources-from-azure-ad-joined-devices-the-mega-series/#see-it-in-action

[tcable]

Mr L - I've not got to where i am today by listening to you, and I'm certainly not going to start now

 

Thanks for the replies. I couldn't wait until Easter so decided to give 'Self-Deploying' a go, and it deployed fine (in the end).

 

Kept getting error 0x800705b4 on 'securing your hardware', which seemed to suggest a TPM error, however it seems to be because of filtering somewhere as if i attach it to an unfiltered network then it goes fine. Need to go through the logs to see what website is being blocked on this stage.

From what i can see using this method doesn't apply a primary user to the machine within intune.

I seemed to be able to access the on-prem network fine. Managed to get onto some services that don't have an internet presence ok, and it seemed to install a printer from my printer server ok (no VPN running yet, but do have azure AD connect running which is what i think helps make this possible).

Still a few weird things happening that I need to test (like I logged on first and it made me an admin, despite it being set to standard account in account type settings, however the second account to login was a standard user), and a few policies to migrate to the cloud and the shared PC policy to dig through a bit more, but so far i give it a good start for a first attempt.

Whilst i still have some testing to do, it does seem that the configuration policies apply a lot faster than when on a hybrid machine. This might just be a weird coincidence at this stage though.

If anyone knows how to put an answer file onto a USB stick that's been created with Rufus , that would be handy getting fed up of selecting the keyboard layout every time i reinstall the machine!

[garethEds]

We've had a nightmare connecting an autopilot'ed machine to some on-prem services. I tried getting it to map an on-prem file server but it kept asking for a username and password.

 

Ok - these two machines were on different domains, but I did set the on-prem file server to allow anonymous access (for testing). Still didn't work. I've not tried printers yet.

[Wubbalubbadub]

We've had a nightmare connecting an autopilot'ed machine to some on-prem services. I tried getting it to map an on-prem file server but it kept asking for a username and password.

 

Ok - these two machines were on different domains, but I did set the on-prem file server to allow anonymous access (for testing). Still didn't work. I've not tried printers yet.

 

Not to be “that guy” but that is expected behaviour. To your file server that is no different to a stranger trying to connect in.

 

Intune isn’t designed to connect to your on prem network. It’s designed to connect to cloud services. You will need to look at a cloud printing solution really. Plus online file storage, like OneDrive or SharePoint.

[KK20]

Our autopilot AAD (I should really get round to calling it Entra) only devices connect just fine to our onsite services. Yes Intune can do this without issue, you need to have a hybrid system with writeback in place but the AD resources are happy to accept AAD azure tokens for onsite services. Here is the MS document on how to ensure it works. https://learn.microsoft.com/en-us/entra/identity/devices/device-sso-to-on-premises-resources

 

Our teachers still have a couple of onsite fileservers (as well as onedrive and sharepoint). So I have a shortcut to the onsite fileserver for when they either VPN in or are onsite. SSO works throughout even though the devices do not appear in the onsite AD. You can see the ticket using the usual dsregcmd /status command

Edited March 27, 2024 by KK20