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 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 withthat, 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 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 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 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 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 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 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 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 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 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 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 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 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 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 removal
This should leave you with exactly two customizations: Authority and BPRT as shown in Figure 16: Authority and BPRT.
Figure 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 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 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 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 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 - 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!
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 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 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 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 namingstandard 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 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 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 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 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 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.