Categories
Intune

Autopilot registering for non admins

Windows Autopilot is a really nice thing, I think you all are familiar with this by now. But the process to add devices, and adding devices without being an administrator, isn’t really that straightforward with exporting CSV’s and such. The way I usually import the hardware IDs is by using the Get-WindowsAutopilotInfo.ps1 PowerShell script.

The built-in roles in Microsoft Endpoint Manager do not give you rights to add or remove devices, you need to create a custom role for this.

There are two options here, you could either duplicate an existing role such as the Help Desk Operator role and add the Enrollment Programs rights which you will need, or you can create a new custom role.

Creating a custom role for this could be very useful if you want to provide the possibility for your e.g. deskside support personal or a hardware coordinator to upload hardware IDs if this was not done by your hardware vendor.

In this example, I’ve created a new role called “Windows Autopilot Operator”.

Create a new role

Head to the Microsoft Endpoint Manager portal and navigate to Tenant Administration > Roles and click “+ Create” (or mark the role you want to duplicate and click the duplicate button).

Give your new role a name such as “Windows Autopilot Operator”.

Click next and find the heading “Enrollment programs” and enable:

  • Sync device
  • Delete device
  • Create device
  • Read device

Click through the wizard and create the new role.

We now need to assign this to a group of users. When the role is created, click on the role and go to Assignments.

Click “+ Assign” and give your assignment a name, such as Deskside Support or something describing what kind of users will be in this assignment.

Click next and add a group containing your users.

On “Scope groups”, add all users and all devices.

Complete the wizard and you have now created an assignment. If you wish to add more assignments, you can just click the “+ Assign” button again and repeat the steps.

Importing the hardware ID

We can now get started with importing the hardware ID into our tenant! You can do this either from the Out of Box Experiance (OOBE) process or in runtime. Since I think we all know how it works in run time, let’s have a look at what it looks like during OOBE.

In this example I’m using a virtual machine, but you need to have passed the Wi-Fi selection part if you are doing this on Wi-Fi since we need internet connectivity.

During the OOBE process, press SHIFT + F10 (don’t forget FN if you have such keyboard). Type powershell and hit enter.

You have now launched PowerShell in your terminal, and we can get going with executing the following three lines. You will during the have to confirm that you want to install the script, just press “y” and enter when asked to.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted
Install-Script -Name Get-WindowsAutoPilotInfo
Get-WindowsAutoPilotInfo.ps1 -online

When you run the third line of PowerShell code, you will be prompted to sign in with you account. If this is the first time you are running the online version, you will need to consent the sign in first (it will show up on the screen).

Once signed in, the process will start and the Hardware ID will be harvested and uploaded to your tenant.

This process usually takes a few minutes. Once completed, turn off the computer.

If you have a look in your Windows Autopilot devices list in the Microsoft Endpoint Manager by going to Devices > Windows > Windows Enrollment > Devices you can see that the devices has been uploaded.

Depending on how you are assigning deployment profiles, this will usually be assigned within 15 minutes. Once the profile has been assigned, you can start the computer again and enroll it!

Bonus tip

If you are using group tags to assign profiles like I do in my lab, you can actually do this while running the script by adding “-GroupTag ‘[YourTag]'” at the end of the script.

Get-WindowsAutopilotInfo.ps1 -online -GroupTag '[YOUR TAG]'

This will automatically add the group tag to the device entry, and if your automated profiles assignment is depending on this everything will happen automatically!

Categories
Intune Tips & Tricks

Exclude devices from profile

One of the most common ways to assign Windows Autopilot profiles is to use the wildcard argument for Autopilot devices in an dynamic Azure AD group:

device.devicePhysicalIds -any (_ -contains "[ZTDId]")

This is a powerful way of gathering all devices imported to Autopilot into a single group to assign either enrollment profiles, configuration profiles or even applications without the need for any additional work or use of group tags.

However, this group being powerful makes things a bit harder when it comes to excluding devices that might need a different enrollment profile for testing, different device type or just a different use case.

There are different ways of doing this, but this is the way I found that works well and it assumes that you have another Azure AD group which you use to assign Enrollment Profiles, dynamic or assigned.

Let’s say we have two enrollment profiles:

  • Production profile
  • HoloLens profile

The “Production profile” is assigned using a group called “All Autopilot devices” which gets devices using the “device.devicePhysicalIds -any (_ -contains “[ZTDId]”)” string to gather all devices which are imported to the environment.

We have also imported the HoloLens devices in to our device list for Autopilot, which we are using a group tag to populate our “HoloLens devices” group with which is then used to assign the HoloLens profile.

Now comes the tricky part. Since we have the “catch all” group already, that will include the HoloLens’s which means that we will assign configuration profiles and applications that are assigned using that group.

Since our HoloLens’s are a different type of devices, we want to assign a separate set of configuration profiles and applications towards them, meaning that we need to exclude them from the “All Autopilot devices” group and add them a HoloLens specific group to assign our HoloLens profile.

Creating out groups

To add them to the HoloLens deployment profile you can create a dynamic group which is using Group Tags to populate. This will require you to add this group tag to all your HoloLens’s. In this case, we will use the Group Tag “Hololens”.

(device.devicePhysicalIds -any _ -eq "[OrderID]:Hololens")

This will assign the HoloLens specific deployment profile to the device.

However, we also want to make sure that we do not include these devices in the bigger group which is used to assign the “regular” Windows policies. This was a bit trickier than I thought to be honest.

After playing around with excluding the group tag, which for some reason didn’t work that great, the most effective way was to exclude devices from my big “All Autopilot devices” group by using the fact that it has a deployment profile assigned to it. This value can be used in the rules for the group by saying that we don’t want to include devices having a deployment profiled called “Autopilot HoloLens” assigned to them.

device.enrollmentProfileName -ne "Autopilot HoloLens"

The outcome

By changing the rule to say that in addition to “catch all” also no include anything that has the deployment profile “Autopilot HoloLens” assigned to it, we will now have a group which will exclude all HoloLens devices!

This can of course be used for other things than HoloLens, it applies for anything that has a deployment profile assigned to it.

There are other ways to accomplish this, but this is the easiest way I’ve found so far!

Categories
Digital Transformation Modern Workplace

What is Windows Autopilot – management edition

There are A LOT of misconceptions what Windows Autopilot is. Today I will try to sort those misconceptions out.

You have already heard a lot of different presentations about Windows Autopilot, why you should use it and why it’s so great. Because of that, I’ll leave most of those things out. This wont a technical post about what Windows Autopilot is, this will be more of the management edition of this.

Windows Autopilot – the concept

The basic theory behind Windows Autopilot is to streamline and take away time-consuming phases in the setup process of a corporate computer.

In the “traditional world” you would need to be on the corporate network and press F12 on the computer to initiate the installation of your custom image, that your IT-guys built. This custom image of Windows contains all your customizations, drivers and settings are pushed through Group Policy Objects, also called GPO. Many companies requires the computer to be “known” before it’s installed and you do what is called a pre-stage where you create the computer account in the active directory (AD) and assign group memberships. This process can take from an hour up to a few hours based on your connection and size of image (it’s usually pretty big).

In the world of Windows Autopilot, you take advantage of that the hardware manufacturer has already put a Windows 10 installation on the computer, with drivers installed from the factory (this is actually how computers are shipped even if you don’t use Windows Autopilot). Your vendor/partner/IT-department registers the computer hardware ID, which is unique to each computer, with your Microsoft tenant. Computer can also be joined to Azure AD groups based on this hardware ID.

When the computer is launched the first time, the user will be greeted with “Welcome to Contoso” and then asked to sign in. When sign in is completed, the computer is registered in Microsoft Intune and settings and customizations are applied.

This process is A LOT faster than traditional OS-deployment. The entire process and the computer are ready to use in 30-60 minutes (based on connectivity). All traffic is routed through the internet during setup and any connectivity to the corporate infrastructure can be routed through VPN if needed.

If you do the math, you can deploy a whole lot of more computer for a lower cost using Windows Autopilot.

Windows Autopilot – the reality

This sounds pretty neat huh?

But what is Windows Autopilot? Is it a completely new tool? Will it replace Microsoft Intune? What will my IT-technicians do, they spend 80% of the time installing computers today?

Without getting to technical about this, Windows Autopilot is a new name on a bunch of things that has been around for a while. And some new features.

Windows Autopilot is utilizing a lot of different technologies and should be viewed more as a workflow or a process rather than a technical feature. It combines the power of Azure AD, Microsoft Intune, and Microsoft Store for Business to provide a streamlined process for installing new computers. That’s about it.

This means that Windows Autopilot is nothing else than an automated and standardized process of setting up computers for your company.

However, from a technical point of view, there is a lot more things going on though. But this is the simple version.

Key take-away

The key take-away, and the thing to consider, around Windows Autopilot is if you need all the fancy switches and total customization you have with the traditional approach. Or would a lighter weight management do the trick for you? It probably will…

There are of course some if’s and but’s around this, but in general there aren’t that much. Your users could get their computer delivered straight to them and set them up by login in, given that they have internet access at their location.

There are options to prepare the computer for the user by having a technician do half the registration and setup to then re-seal the computer and ship it off to the user, if you want to minimize the amount of work being done by the end-user. This way, initial setup will be shorter for the end-user.

If you view Windows Autopilot as an automated process to setup computers in your organization and not a technology, things get a lot easier. With that said, it won’t suite all your special situations for computers, but you will cover most cases for office-based work!