Remember waaaaay back like, a week ago, when I told you about all the cool stuff you can do with AutoPilot and Runtime Provisioning? One of the ideas that I put forward was that users could be empowered to go get a new computer from a big box store and just roll with it. While true, it spurred a discussion in the office about whether or not AutoPilot was actually necessary to complete that deployment.
As with everything Microsoft, it turns out there’s another way.
I won’t call it a “limitation” of AutoPilot, but one thing that’s critical for AutoPilot’s success is having the user provide IT with some sort of machine identifier. In a big corporate AutoPilot scenario, typically those identifiers can be provided directly from the manufacturer. That’s the end goal, too: user unpacks the brand new machine, AutoPilot identifies it out of the box as belonging to your company, and the user is up very quickly. And since I wrote that post, a lot of additional development has occurred in the AutoPilot space. It IS the future of system deployment. But for our user who’s just dropped his production machine into a lake, it means a sheepish call to IT explaining what they’ve done, and requesting mercy while reading off a serial number that’s often printed in dark gray 2-pt type.
As a thought experiment, I set about trying to be that user (and also a merciful admin... in my little imaginary kingdom, I can be benevolent when I want to).
I created a demo environment with all the bells and whistles, including Windows Defender ATP (which is super cool and totally worth another visit—look for an upcoming post or webinar!). I wanted to ensure that my test users would be set up for MFA and some security best practices. So, to that end, I set up enrollment, configuration, and compliance policies for the devices; app assignment from the Microsoft Store for Business; and conditional access policies for the users.
First, all users were configured to be able to enroll all Windows devices. Simple enough. Save and apply.
Second, I wanted to control the Windows environment configuration. I was raised to believe that group policy objects should be created and applied for each set of controls or settings you want to manage, so I built separate Device Configuration Policies to manage:
Edition switch was simple. Just 2 settings: what edition do you want, and what’s your product key?
Wi-Fi profile was, in this case, equally easy. But having supported clients with PEAP networks, I was thrilled to know that I could upload a certificate and configure all of that mess from end to end, too.
Creating a local admin user took a bit of research, but that one step took most of the manual work that would otherwise necessitate a visit to the IT department. Typically, this would involve logging on initially with a local user account, doing admin wizardry on the machine, then adding the user account, then logging on with that account, and then adding it to the Azure AD. That whole process was nuked with one 3-line policy.
The device security profile applied all the security settings I used to be responsible for doing with GPO’s: disabling LM & NTLM, blocking access to Named Pipes, and blocking anonymous enumeration of SAM accounts & shares. There are HUNDREDS more options I could have chosen, but my goal was to be in & done quickly.
With those settings applied, the machine would be assessed against a pretty simple compliance policy. But since some of those settings needed to be in place for the machine to be considered ‘compliant,’ I also built in a 2-day grace period to meet compliance before restricting access to apps (it can take a while to pull down all the necessary patches, depending on the Windows 10 build and your network).
Then I set up a very simple conditional access policy that would hit the user upon accessing email: require that the user be MFA-enabled, and that the device be marked ‘compliant.’
So in theory, a user should be able to get a new machine, take it out of the box, log in with an Azure AD account, get prompted to set up MFA immediately, get the company portal app and all configuration requirements, open email, and be off to the races. All without AutoPilot or any other deployment tools—or hands-on support from IT—in place.
It’s a great theory, but we’re side-stepping the preferred methodologies, so while it definitely worked, it wasn’t as smooth as could be hoped.
We did pull a fresh machine from the box, image it with Windows 10 Home (like so many department store computers have from the factory), and set it on the desk for the initial login. But Windows 10 Home cannot natively join an Azure AD, so the first logon had to be done with a local account. No big deal: just create a local user and log in. But at that point there is no automation: the user must do something extra to make things happen. In our case, the user had to go to Settings -> Accounts and select “Access work or school.” I entered Azure AD credentials and... nothing evident happened.
I poked about, as a user might, and decided to reboot after a couple minutes. Lo and behold, when the machine came back up, it was running Windows 10 Enterprise! But still logging in as the local user. Hm...
I went back to Settings -> Accounts and removed my connection to the Azure AD, rebooted, then re-added it. Sounds goofy, but Windows 10 Home does not give users the option to join an Azure AD, whereas Enterprise does give that option. So I chose that option and rebooted again, and now I was presented with a winlogon screen asking me to provide company credentials.
Once provided, I was challenged for MFA, as expected, and when I got to Windows, I verified the new corporate admin account and Wi-Fi profile had been added. Score!
I installed the Company Portal app from the Microsoft Store, loaded all my apps that were available, and was immediately able to log on to email and get started. Best of all, with Enterprise State Roaming enabled, my user preferences were in place from a previous build I’d done in the same environment.
So it wasn’t automatic. In fact, there were about 4 times where I, as the user, had to Do Something™. But all of those somethings was basically just logging in. None involved IT interaction, and at no point did I need to enter a serial number or download a PPKG file. I wouldn’t say this presents a great way to roll out systems, but as an experiment it did successfully prove that you don’t have to be all-or-nothing with a single deployment model. And I learned how to configure a local admin account, which was pretty nifty.
Would you like to find out more about Intune & Endpoint Manger? Learn how you can manage & protect your devices, apps, & users with Endpoint Manager?