Bulk join a Windows device to Azure AD and Microsoft Endpoint Manager using a provisioning package
Published May 25 2021 09:00 AM 52.4K Views

By Anders Ahl – Principal Program Manager | Microsoft Endpoint Manager - Intune

 

As an admin that manages Windows 10 devices, you can take advantage of joining large numbers of new Windows devices to Azure Active Directory (Azure AD) and Intune.


This article will help IT pros and mobile device administrators understand the steps required to create a provisioning package, as well as enrolling them into the Intune service.

 

Current state: CATAhlyst Corp has hundreds of stand-alone Windows 10 devices in their stores, acting as kiosks or electronic signs. These machines are not Active Directory joined today and the management platform is an old and outdated proprietary solution that has proven to be too expensive to maintain.

 

Desired state: All userless devices should be joined to Azure Active Directory and enrolled into Intune.

 

Process: The goal is to Azure AD join these machines and enroll them into Intune using a provisioning package. The IT Pro tasked with the job has read through the Microsoft Docs article Bulk enrollment for Windows devices but doesn’t like the requirement to rename the device as all devices are already conforming to the established naming standard, we will therefore examine how this requirement can be overcome by modifying the provisioning package.

 

Automatic MDM enrollment into Intune is enabled for Azure AD joined machines. If this is not the configuration you use in your tenant you would simply end up with an Azure AD joined device, without Intune management after applying the provisioning package. There is nothing in the provisioning package itself that will address the MDM enrollment, it’s all automatically taken care of by Azure AD.

 

Let’s get started!

 

Creating provisioning packages is preferably done using the Windows Configuration Designer (WCD) available from the Microsoft Store.

 

Figure 1: Windows Configuration Designer Store AppFigure 1: Windows Configuration Designer Store App

 

As you download and install WCD on an ITPro Windows 10 device, make sure you’re running at least Windows 10 2004 (20H1) to be able to leverage the new computer rename logic. In this particular scenario, we will be removing it altogether which is a new functionality introduced in 20H1.

 

Start WCD and from the first screen, make sure you select “Provision desktop devices”. As we will see later on, the template we want to use is actually “Advanced provisioning” but if we start off with that, it is much more work to create and supply the Bulk Azure AD Token than it is to first use the Wizard and then delete the items we don’t need.

 

Figure 2: WCD Create profileFigure 2: WCD Create profile

 

Supply the necessary project details for your package and if you regularly create provisioning packages, make sure you give it both a relevant name and a fitting description, especially if you have to come back later to make modifications.

 

Figure 3: WCD Enter project detailsFigure 3: WCD Enter project details

 

As you probably can tell from the Project folder path, I’m running as a local account on my ITPro machine. This is not a requirement, but I usually prefer to create provisioning packages from standalone/Workgroup machines just to make sure I’m not involuntarily using any domain references or single sign-on abilities.

 

Although the button in the bottom right says “Finish” it’s literally the opposite so press it and let’s get started!

 

Already on the next screen is our first little trick to get what we want: An Azure AD joined, Intune enrolled device without renaming it along the way. The device name value, highlighted in red in Figure 4: WCD Set up device could be anything that the wizard accepts as we will delete this in a later step. As of Windows 10 20H2, the value is required so you have to enter something to be able to continue.

 

Also worth noting is the statement highlighted in green which tells you that this operation requires Windows 10 2004 (20H1), even if we intend on deleting this part from our package, earlier versions of Windows 10 doesn’t like this so make sure you have an up-to-date client estate before you venture on.

 

Figure 4: WCD Set up deviceFigure 4: WCD Set up device

 

When you’re done, click Next, on ‘Set up network’ page de-select the option to provision a Wireless Network and then click Next again. You should now be on the ‘Account Management’ page.

 

This is where we prepare the provisioning package to join the machine to Azure AD by supplying a Bulk Azure AD Token. Choose an expiration for the Token itself (the default is 180 days) and click the “Get Bulk Token” button. When the provisioning package is created, there are no other credentials needed to add a machine to your tenant so make sure you set the expiration date as short as possible without requiring you to re-create the provisioning package again if you haven’t completed your migration on time.

 

Figure 5: WCD Account ManagementFigure 5: WCD Account Management

 

Depending on your Azure AD settings, the next couple of screens will look different, potentially asking you for multi-factor authentication (MFA) along with your credentials. Unless you have tweaked your default user settings in Azure AD, the credentials you use to request the Bulk Azure AD Token could be any valid user credentials in your tenant, it doesn’t have to be an admin or a user with any particular rights. As I will show in a bit, the Bulk Azure AD Token will be flagged with the users’ name, so I suggest you use a non-personal account or one that IT has control over. The standard Intune scenario is typically that a user enrolls their own machine and thereby attaches themselves to that device going forward. In this example, as we’re bulk enrolling hundreds of non-personal kiosks and digital signage devices it’s perfectly fine to use a non-personal account.

 

Note: Using a Bulk Registration token (BPRT) doesn’t count against any enrollment restrictions by number of enrolled devices, it’s for most intents and purposes considered unlimited.

 

As you have successfully supplied the necessary credentials and honored potential MFA requests, if this is the first time you use WCD to request a Bulk Azure AD Token, you will be presented with a Permission request as seen in Figure 6: WCD Permission request.

 

Figure 6: WCD Permission requestFigure 6: WCD Permission request

 

Accepting this permission request will bring you to a crucial step in the provision package creation. Please read the entire paragraph before you click Accept.

 

Important: In the next step, the first check box, highlighted in red in Figure 7: WCD Stay signed in to all your apps “Allow my organization to manage my device” is checked by default and will enroll the device you’re running on right now into Intune. Make sure to un-check this box. This has nothing to do with the provisioning package you’re in the middle of creating.

 

Do not click the “OK” button in the lower right corner of the dialog box as this will register your device (the device you’re running WCD on) in Azure AD. Instead, click the tiny text in the lower left corner “No, sign in to this app only” to start creating the Bulk Token.

 

Figure 7: WCD Stay signed in to all your appsFigure 7: WCD Stay signed in to all your apps

 

If you’re on any of the Insider builds, this message has now been updated to reflect this potentially unwanted behavior and avoid making mistakes. The new dialog looks like this:

 

Figure 8: WCD Stay signed in to all your apps – Upcoming dialogFigure 8: WCD Stay signed in to all your apps – Upcoming dialog

 

If everything was successfully created in Azure AD you will return back to the WCD editor as shown in Figure 10: Bulk Token fetched successfully.

 

Common errors at this stage could be:

  • Your Azure AD Device settings are not allowing users to join devices to Azure AD. If you have the setting shown in Figure 9: Users may join devices to Azure AD to either “None” or “Selected” and the users defined as Selected aren’t including the account you try to create the Bulk Token with, the creation will fail.

    Figure 9: Users may join devices to Azure ADFigure 9: Users may join devices to Azure AD

  • Conditional Access rules are blocking you from accessing Azure AD as you’re running WCD from a non-Azure AD machine.

    Figure 10: Bulk Token fetched successfullyFigure 10: Bulk Token fetched successfully

 

If you’re wondering what just happened in the backend, open up your Microsoft Endpoint Manager admin center and head over to the Users blade.

 

Unless you have created any Bulk Tokens in the past you should only have a single user called “package_<GUID>@yourdomain.com”. This is the placeholder account used for joining the devices, and an easy way of invalidating the provisioning package before it expires automatically would be to remove this account.

 

Figure 11: Bulk Token user account in AADFigure 11: Bulk Token user account in AAD

 

Want to keep track of who created a particular Bulk Token? Scrolling down to the “Contact info” section of the account will show you the UPN under “Alternate email” as seen in Figure 12.

 

Figure 12: Alternate email contains the bulk enroller UPNFigure 12: Alternate email contains the bulk enroller UPN

 

This account will be the owner of all joined devices but the user will not be assigned as the primary user, nor will it be listed on the device object as the “Enrolled by” account. We will come back to this a bit later in this post when we have joined our first machine to Azure AD.

 

After a slight detour in explaining the behind-the-scenes work, hopefully you’ve arrived back at the WCD editor without running into any issues and you could click through the rest of the screens without any modifications until you end up at the summary shown in Figure 13: Final WCD screen, ready to create package.

 

Figure 13: Final WCD screen, ready to create packageFigure 13: Final WCD screen, ready to create package

 

At this stage, don’t click the blue “Create” button just yet. Remember where we used “Placeholder” in the beginning of this scenario instead of specifying a proper device name? We need to clean up that reference so instead of pressing “Create”, use the option in the bottom left to “Switch to advanced editor”.

 

This will prompt you for confirmation as there’s no possibility of using the wizard again after you leave it. We used the Wizard simply to facilitate the Bulk Token creation so go ahead and click “Yes”.

 

Figure 14: Switch to advanced editorFigure 14: Switch to advanced editor

 

As we get into the Advanced editor, locate the DNSComputerName on the right-hand side of the screen. Clearing out the field “Placeholder” in the middle pane of the editor will not work, you will have to go to the right pane and select “Remove” to take out the DNSComputerName altogether, as shown in Figure 15: DNSComputerName removal.

 

Figure 15: DNSComputerName removalFigure 15: DNSComputerName removal

 

This should leave you with exactly two customizations: Authority and BPRT as shown in Figure 16: Authority and BPRT.

 

Figure 16: Authority and BPRTFigure 16: Authority and BPRT

 

We knew from the start that these two items were the only one of interest to us but if you look at the “BPRT” value you can see that it’s a very long, seemingly garbled string that makes up our Bulk Token. Using PowerShell or GraphExplorer to create the BPRT would have been more work than running the Wizard and then cleaning up the DNSComputerName but feel free to ask for a PowerShell scenario and I’d be happy to add one.

 

With a provisioning package containing only two items/customizations we are now ready to select “Export” from the menu bar up top, shown in Figure 17: Export Provisioning package.

 

Figure 17: Export Provisioning packageFigure 17: Export Provisioning package

 

The next series of dialog boxes will cover provisioning package metadata as well as an option to sign the package. Signing scripts and packages is of course always recommended but as you will see in this scenario, we will consciously not sign this package as the target systems are thought of as not being managed at this point and therefore we don’t have an easy method to distribute the necessary certificate trust requirements.

 

On the first screen, shown in Figure 18: Describe the provisioning package we provide at set of metadata properties for easier versioning control of the package. Feel free to accept the defaults and click “Next” or provide additional data if it makes sense in your specific case. You might have several provisioning packages for different device types and if so, giving them descriptive names is a very good idea.

 

Figure 18: Describe the provisioning packageFigure 18: Describe the provisioning package

 

Up next is the Encrypt & Sign details which we will skip right past for the purpose of this scenario. Selecting to encrypt the package will provide you with a password and the signing process should be straight forward if you are used to signing scripts and have a code signing certificate already available on your device. Click “Next”.

 

Figure 19: Security details for the provisioning packageFigure 19: Security details for the provisioning package

 

Select a good place to store the finished provisioning package, then click “Next”. Make sure you store the package somewhere suitable for rebuilding and/or resetting the machine you work on, in case you use a lab/test machine for the creation. I.e. the local hard drive might not be the best choice.

 

Figure 20: Select where to save the provisioning packageFigure 20: Select where to save the provisioning package

 

Figure 21: Build the provisioning package - Summary shows the summary screen and offers you a last chance to back out of creating the package in case you want to change something. Unless you spot something that doesn’t look right, click “Build”.

 

Figure 21: Build the provisioning package - SummaryFigure 21: Build the provisioning package - Summary

 

After a couple of seconds of creation time, your package should now be created and ready for use. Click “Finish” and we’re all done!

 

Figure 22: Provisioning package - All done!Figure 22: Provisioning package - All done!

 

To test our shiny new provisioning package, find a machine that is meeting the requirements for being brought into management by Intune as well as added to Azure AD. The quickest way to check the status of a machine is probably to use the dsregcmd /status command from a PowerShell or Command Prompt. As we can see in Figure 23: we have a standalone Windows 10 device called CATScreen42, driving one of the many digital displays that CATAhlyst Corp. have spread around their locations in Europe.

 

Figure 23: Device Domain Status - Pre Azure AD joinFigure 23: Device Domain Status - Pre Azure AD join

 

By double-clicking on the provisioning package it will launch but as we didn’t sign it, it prompts for user consent. Note that one (the only one actually) of the actions is “Enrolls in Azure Active Directory”. Click “Yes, add it” to start the Azure AD-join process.

 

Figure 24: Provisioning package - Trusted SourceFigure 24: Provisioning package - Trusted Source

 

Note: If you prefer to apply the provisioning package using a Command Line instead of double-clicking it, the syntax as described here is:

 

DISM.exe /Image=C:\ /Add-ProvisioningPackage /PackagePath:C:\BulkJoin.ppkg

 

The package should apply instantly and there is no noticeable activity on the machine. The Azure AD-join itself is instantaneous and the same way we checked on the device domain status above, let’s run the dsregcmd /status command again.

 

Figure 25: Device Domain Status - Post Azure AD joinFigure 25: Device Domain Status - Post Azure AD join

 

As if by magic, the device is now joined to Azure AD and we haven’t even rebooted the device yet.

 

Let’s have a look at the Sign-in blade in the Microsoft Azure console and see what has happened. This is a very busy log in an Enterprise environment so we’ll make use of the filter options to get rid of the noise. The flow is outlined in Figure 26: AAD Sign-in logs. From the Azure AD blade in the Azure portal, scroll down to “Sign-ins” and then make sure you switch to the non-interactive view as the entries we’re after are showing up here. The last step is to press the “Add filters” button and add the “User” field. If this is your first attempt at Bulk Token joining devices, specifying “package” as the string to look for is likely enough. If you have several Bulk Tokens or a naming standard that includes users with the string “package” in the name, feel free to qualify the User-field further to narrow your search as necessary.

 

Figure 26: Azure AD Sign-in logsFigure 26: Azure AD Sign-in logs

 

You should see two log entries for each device you run the provisioning package on. As the log is sorted chronologically with the oldest entry at the bottom, we first see the Device Registration entry as the device is brought into Azure AD. Right after this, in my example illustrated in Figure 27, 11 seconds later we see a Microsoft Intune Enrollment event. That’s it!

 

Figure 27: Sign-in log entriesFigure 27: Sign-in log entries

 

Diving into these individual log entries shows that for the Device Registration the Device Info details is pretty empty as the device wasn’t fully registered in Azure AD yet but for the Intune Enrollment entry we can start tracking the lifecycle of the Device ID as well as filter on some of the basic attributes of the device such as Operating System and Join Type. This will be investigated further in a future post about a new concept called Filters.

 

From an Azure AD perspective, the device object is owned by the Bulk Token user as seen in Figure 28.

 

Figure 28: Azure AD Device ownerFigure 28: Azure AD Device owner

 

Wrapping up the scenario, you probably recall from earlier that the Bulk Token user won’t be assigned as the primary user for any of the devices it joins, nor will it be listed on the Intune device object as the “Enrolled by” account. We see this on the Overview blade for the device itself, illustrated in Figure 29.

 

Figure 29: Primary user and Enrolled by are intentionally emptyFigure 29: Primary user and Enrolled by are intentionally empty

 

This could possibly be unfortunate for some scenarios but remember that this enrollment method is primarily intended for non-personal devices which shouldn’t necessarily have a primary user. The default behavior for Bulk Enrolled devices using a provisioning package is to flag the device as “Shared”. If you like, there’s always the option of assigning a primary user yourself by going to the Properties blade of the device and press the “Change primary user” button as highlighted in Figure 29.

 

Figure 30: Change primary user for a deviceFigure 30: Change primary user for a device

 

That concludes the “Bulk join a Windows device to Azure AD/Intune using a Provisioning package” scenario. I hope you found it useful! Let us know in the comments below or on Twitter (@IntuneSuppTeam) if you have any questions or feedback.

29 Comments
Copper Contributor

Terrific article.  We are currently configuring our kiosk computers using this method so it's good the see the Intune team supporting this approach.

Copper Contributor

Amazing article. Thanks for detailing the behind the scene stuff and calling out gotchas. Cheers!

Iron Contributor

Good article.. Its really useful for Kiosk computers.

Brass Contributor

Great article. How long does it normally take for the machine to show in Intune?

Copper Contributor

we also have MDM group policy that enrolled all the AAD or on prem devices to intune

Hi @Ronald Lawrimore, thanks for the feedback! We expect devices appear to appear soon after enrollment but in some cases, there may be a slight delay. If you are seeing excessive delays, please log a ticket with our support team via: aka.ms/IntuneSupport so we can help you investigate the cause.

Copper Contributor

Great Article. We have got a full install of windows, join AAD/intune in under 12 minutes off a USB Drive. (SSD makes all the difference). We combined the package with an Autounattend.xml that automated as far as the region settings, where the package then took over.

Have just used the basic package. Lots of settings to be explored on Advanced but for simple installs Basic is fine. We used prefix-Serial for naming the machines and renamed them in intune before logging in. Our experience has been that the device is in intune as soon as the install is done.
There is a version of the configuration designer aimed at education as well with many presets for student PCs. The Configuration Designer is a fantastic tool .

Copper Contributor

Has anyone ever had any success with automatically joining a machine to AAD via a PPKG within a SCCM OSD Task Sequence? I am trying to achieve this but failing. If I run the PPKG via Powershell near the end of the TS it applies the PPKG and renames the machine. Looking in the 'Provisioning-Diagnostics-Provider' Admin log in Event Viewer shows joining AAD appears to be successful. But it isn't.... 

Copper Contributor

I followed the guide to a T, but for some reason, the device just doesn't get enrolled in Intune. When I check the sign-ins, there are no entries for the package token.

However, the few settings I edited in the provisioning package do get applied to the device.

 

Any idea what the problem might be? For information, I'm using a work account when creating the package in WCD, and I didn't get the prompt for credentials when creating the bulk token. Could that be part of it?

Copper Contributor

Thanks for the article!  I've successfully created and executed the package and it successfully registered with Azure but not Intune, even though we are setup to automatically manage devices that join AD.  Is there any license requirement for this capability and if so, what object needs to have that license?

Copper Contributor

Graham Riley, I also had issues running the Provisioning Package during an SCCM Task Sequence. In the end I added a local script to run after the TS completes and run the Provisioning Package from there.  Has been super reliable since I moved it outside the TS.

Copper Contributor

I'm still struggling with this. For the benefit of myself and others would someone be able to confirm exactly how you are having success with this?

 

@JensAr Try using the WICD from the Windows Store. This version allows your to create the token whereas the one included in the ADK does not.

Brass Contributor

I created the provisioning package just as indicated in the blog.

In the TS, we are do a standard TS that is installing any applications we need. The machine is not domain joined.

The last steps we are doing is:

Copying the ppkg file to the machine via a Package w/o program.

Running a PS script to install the PPKG

Running a command line script to remove the SCCM client. 

So far it has worked everytime.

RonaldLawrimore_0-1625843198182.pngRonaldLawrimore_1-1625843240773.png

RonaldLawrimore_2-1625843303336.png

 

 

Copper Contributor

@Graham Riley Appreciate the response.

I don't think that's the issue, since the WICD I used did allow me to create a bulk token. It just didn't prompt me for credentials like described in the guide.

Hi @Justin Phillips, thanks for the feedback! Windows 10 automatic enrollment requires to be enabled, which in turn requires an Azure Active Directory Premium subscription. For more information on Windows 10 device enrollment prerequisites, see: Set up enrollment for Windows devices by using Microsoft Intune.

Copper Contributor

@Intune_Support_Team - Can we use this method to actually deploy shared devices/ kiosks/ sales desks shared by a couple of First Line employees who would in turn access few published apps via AVD.  These users don't have a domain joined/ aad account. So even though userless we should still be able to allow users access their VDIs from the kiosks right? 

Copper Contributor

I am completely new to WICD.

I want to use a package file to join multiple devices to AAD which has worked pretty well. But now the expiry date kind of confuses me.

What exactly happens to the device after the expiry date?

Thanks in advance.

Copper Contributor

Is it possible to automate the process of  getting Bulk Token (which is valid for a day or two)  and creating WCD package using that Bulk Token?    

Hi @polea, thanks for the question and there is good news to share here. You can indeed automate the process and we have another blog here that can talk you through the steps you need to take. To initiate this process, you can start by this creating bulk enrollment token (BPRT) using PowerShell. Have a read through: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-to-retrieve-an-azure-ad-... to get started now!

Copper Contributor

Thanks. @Intune_Support_Team 

 

Was able to get the token using AADInternals.  It also has scripts to join AAD and Intune Enrollment, what are downsides to using those scripts directly instead of .ppkg?  

Copper Contributor

I have created the package according to the instructions, but I can't get it to work on the client. The error code 800700B7 appears. Any idea what this can be?

Hi all,

 

@polea Glad to hear you got it working! Provisioning packages are a prescribed method, and depending on certain scenarios, the use of scripts can be extremely handy. Feel free to reach out if there's anything else we can help with or if you require further info!

@SirHartmann Sorry to hear your experiencing issues. We've had a look, and the error requires further investigation: aka.ms/IntuneSupport. Please include the additional details: Does the package works on another device, and if it works from another network. Once created, feel free to DM us the support request number for us to keep an eye on!

 

Thanks!

Copper Contributor

@Intune_Support_Team Thank you very much for the feedback. Just for the sake of completeness: The cause was that the package was already applied. However, it was only displayed after a restart.

Copper Contributor

How to bring Device name instead of serial number

Microsoft

For folks that have followed this article (especially those Teams admins doing MTR for Windows deployments) and get a provisioning package that joins the machine to AAD, but does NOT enroll in Intune, there's a critical step missing depending on how your tenant is configured.  Once you've obtained the Bulk Token and the Package_xxx account is created...if your auto-enrollment for windows MDM scope is set to none, then Intune will not be enrolled.  Additionally, if this scope is set to "some" then you need to ensure that the Package_xxx account is included in any of the security groups Windows auto-enrollment is targeting...otherwise all you'll ever get is AADJ with this package.  I am doing this as part of a Microsoft Teams Room deployment so this was a key step that was throwing me off...I'd like to credit Tom F. from Intune team for helping me (from Teams side) to better understand this nuance.  I hope this helps someone, and/or the owner updates the original article.

Copper Contributor

Can we use it to enroll AAD devices into Intune?

Copper Contributor

Does it work with GCC High tenants? I tried and I am getting the following error: 
Bulk token retrieval failed.
The operation returned an empty response. Please try again.

Copper Contributor

Our enrollment token is now expired and we get the same error as @daghogarcia 

Copper Contributor

I like it

Version history
Last update:
‎Dec 19 2023 01:20 PM
Updated by: