Block access to a device until specific apps are installed

ESP-BlockApps-TweetThis week a short blog post about a recently introduced feature in the Enrollment Status Page (ESP). The ability block access to a device until specific apps are installed. I also tweeted about that feature recently and I thought it would be good to document the use case, the configurations and the end-user experience.

Introduction

Let’s start with a short introduction. The ESP is strongly recommended with Windows Autopilot. The idea of the ESP, is to block the device until the device is ready for usage by the user. This new feature enables an administrator to only block the device until the most important apps are installed for the user. That enables the user to be earlier productive. The administrator simply chooses which apps are tracked on the ESP and until those apps are installed, the user can’t use the device.

With the recent updates to Microsoft Intune, the ESP can track the following apps:

  • Licensed Microsoft Store for Business apps;
  • Line-of-business apps (APPX, MSIX, single-file MSI)
  • Office 365 ProPlus apps

Note; Keep in mind that there are difference between the user context and the system context. For the exact up-to-date details see the links in section More information.

Configuration

Now let’s continue by looking at the available configuration options. The following three steps walk through adjusting the default ESP. Those steps will show which configurations are required to get to the available configuration options for tracking specific apps. Similar steps are applicable when configuring custom ESPs.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment > Enrollment Status Page (Preview) to open the Enrollment Status Page (Preview) blade;
2 On the Enrollment Status Page (Preview) blade, select Default > Settings to open the All users and all devices – Settings blade;
3a On the All users and all devices – Settings blade, select Yes with Show app and profile installation progress and Yes with Block device use until all apps and profiles are installed to enable the Block device use until these required apps are installed if they are assigned to the user/device setting (see step 3b);
3b When the Block device use until these required apps are installed if they are assigned to the user/device setting is enabled, select Select apps to open the Select apps blade. On the Select apps blade, select the required apps and click Select to return to the All users and all devices – Settings blade and click Save;
ESP-BlockApps-Config

Note: Keep in mind that if the ESP is configured to track Office 365 ProPlus apps, other large apps, or just many apps, it might be required to also increase the timeout as documented in this Support Tip.

End-user experience

Now let’s end this post by looking at the end-user experience. The good thing is that the user will not notice any big differences. The user will still get the same screens and the same experiences. Only users that pay attention to details will notice the small differences. As shown below, the user will see a list of apps that is equal to the number of configured apps by the administrator. That list is most likely shorter then it was before. That’s also the reason why the user might notice that it’s possible to get productive sooner, as the device will be available for use sooner.

ESP-BlockApps-EUE

More information

For more information regarding blocking devices until certain apps are installed, please refer to the following articles:

Windows Autopilot self-deploying mode

This week a new blog post about Windows Autopilot. More specifically, Windows Autopilot self-deploying mode. Autopilot self-deploying mode is really useful for devices that are function specific, like for example kiosk devices. The biggest benefit is that a device with a wired network connection (with Internet) can be completely configured without any user interaction. Simply connect the device to the wired network and power it on! Real zero touch provisioning! In this post I’ll provide the configuration steps to create that experience, followed by some known errors and the end-user experience.

Configuration

Let’s start with a few important requirements and limitations:

  • The device must run Windows 10, version 1809 or later;
  • The device can only be Azure AD joined (Active Directory join is not supported);
  • The device must be a physical device with TPM 2.0 (virtual machine is not supported);

Now let’s continue by looking at the available configuration options. In this case I’ll look at the different available configurations options and the related impact of those configuration options. The following four steps walk through the steps to get create a new Windows Autopilot self-deploying profile (including the available settings). That deployment profile can be assigned to an Azure AD group that contains devices.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Deployment Profiles in the Windows Autopilot Deployment Program section to open the Windows Autopilot deployment profiles blade;
3 On Windows Autopilot deployment profiles blade, select Create profile to open the Create profile blade;
4a

WA-SD-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a unique name for the Windows Autopilot deployment profile;
  • Description: (Optional) Provide a description for the Windows Autopilot deployment profile;
  • Convert all targeted devices to Autopilot: Select Yes to automatically convert Intune managed devices to Autopilot;
  • Deployment mode: Select Self-Deploying (preview), as that deployment mode provides the functionality that is needed for this post;
  • Join to Azure AD as: Azure AD joined is selected by default and grayed-out, as it’s the only configuration option supported for Windows Autopilot self-deploying devices;
  • Out-of-box experience (OOBE): See 4b.

Note: The Self-Deploying (preview) deployment mode, defines the available Azure AD settings and the available out-of-box experience (OOBE) settings.

4b

On the Out-of-box experience (OOBE) blade, provide the following information and click Save.

  • Language (Region): Select the Language that should be automatically configured during the Windows Autopilot self-deploying experience. This configuration will only be performed when the device is on a wired network connection (with Internet);
  • Automatically configure keyboard: Select Yes to automatically configure the keyboard based on the selected Language. This setting is only available when a Language is configured and this configuration will only be performed when the device is on a wired network connection (with Internet);
  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot self-deploying experience;
  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot self-deploying experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot self-deploying experience;
  • User account type: Select Standard to only make any user on the device a standard user. With the exception of global administrators and company administrators;
  • Apply computer name template (Windows Insider Only): Create a computer name, according to the configured template, for devices at initial startup;
WA-SD-OOBE

Note: The Autopilot settings can only be downloaded when a network connection is in place. That’s the reason why a wired network connection should be in place. When a wired network connection is not available, it’s required to configure the region, the keyboard and a Wi-Fi.

Known errors

During the testing of Windows Autopilot self-deploying, I ran into multiple errors. More information about an error can always be found in the Event Viewer, at Application and Services Logs > Microsoft > Windows > Provisioning-Diagnostics-Provider > AutoPilot (thank you for the reminder Sandy!). The errors that I’ve seen on screen are documented and explained in the table below. If you’ve seen errors that are not on this list, let me know and I’ll add them.


Error Description
0x800705B4 This error means that the device is either a virtual machine, or does not have TPM 2.0, and is not capable of running Autopilot self-deploying.
0x801c03ea This error means that the device is TPM 2.0 capable, but that the TPM still needs to be upgraded from 1.2 to 2.0.
0xc1036501 This error means that the device cannot do an automatic MDM enrollment, because there are multiple MDM configurations in Azure AD.

End-user experience

As always, let’s end this post by having a look at the end-user experience. The end-user experience will provide a welcome message (see below) after receiving the Autopilot deployment profile and an automatic restart. An easy differentiation between the Autopilot user-driven experience and the Autopilot self-deploying experience, besides the interaction, is the logo that’s used. At this moment the Autopilot user-driven experience uses the square logo of the Azure AD company branding and the Autopilot self-deploying experience uses the banner logo of the Azure AD company branding.

20181104_165048

Note: From and administrator perspective, an Autopilot self-deploying device can be easily recognized by the Management name of the device. It contains a GUID instead of a username.

More information

For more information about enrolling Windows devices by using Windows Autopilot self-deploying mode, please refer to the documentation named Windows Autopilot Self-Deploying mode.

Automagically convert Intune managed devices to AutoPilot

Tweet-AutoPilotThis week a short blog post about my tweet of a bit more than a week ago. In that tweet I mentioned a new easy method to automagically convert Intune managed devices to AutoPilot. That method makes some scenarios a whole lot easier. Like for example what I did in this post to get the AutoPilot device information of Intune managed devices. That type of custom scripting is not needed anymore!

As I got many reactions to that tweet, mainly related to the location of that configuration, I thought it would be good to make a short post describing the configuration option and the expected behavior. In this post I’ll provide the steps to make this configuration and I’ll describe the expected behavior. There is no real end-user or administrator experience to show for this configuration. So, no section related to that. I’ll do explain the the expected behavior in the introduction.

Introduction

Let’s start with a short introduction about the mentioned configuration option. That configuration option is the Convert all targeted devices to AutoPilot setting. By default an AutoPilot deployment profile is only applied to already existing AutoPilot devices and doesn’t apply to non-AutoPilot devices. Configuring the Convert all targeted devices to AutoPilot setting to Yes will automagically convert all devices in the assigned group to AutoPilot. This is a one-time conversion that also works for co-managed devices. That also means that removing the AutoPilot profile will not remove the converted devices from AutoPilot. After conversion the devices can only be removed by using the Windows AutoPilot devices view. Keep in mind that it can take up to 48 hours for the conversion to be completed.

Configuration

Now let’s continue by having a look at the actual configuration. And in this case only the specific Convert all targeted devices to AutoPilot setting. The following four steps walk through the steps to get to the specific setting and are not meant to create a complete the Windows AutoPilot deployment profiles.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Deployment Profiles in the Windows AutoPilot Deployment Program section to open the Windows AutoPilot deployment profiles blade;
3 On Windows AutoPilot deployment profiles blade, either select Create profile or select [existing deployment profile] > Properties to open the Create profile blade or the [existing deployment profile] – Properties  blade;
4 On the Create profile blade or the [existing deployment profile] – Properties  blade, the setting Convert all targeted devices to AutoPilot must be switched to Yes (below is an example of the the [existing deployment profile] – Properties  blade, the Create profile blade looks similar) ;
MSIS-AutoPilot-Target

Note: There’s not a real easy method to see which devices are converted to AutoPilot. Those devices will show as any other imported device, without enrollment state. However, as the configuration is done via an AutoPilot deployment profile, the device is immediately assigned to a profile. Again, without creating any fancy configurations, like query based dynamic device groups.

More information

For more information about enrolling Windows devices by using Windows AutoPilot, please refer to the documentation named Enroll Windows devices by using the Windows Autopilot.

Assign a user to a Windows AutoPilot device

This blog post uses capabilities that are added in Windows 10, version 1809, which is currently still in preview.

This week a short blog about another relatively new Windows AutoPilot feature. This week is all about assigning a specific user to a specific Windows AutoPilot device. That enables an administrator to directly assign a user to a Windows AutoPilot device. Assigning a user to a Windows AutoPilot device will make sure that the username will be pre-filled during Windows setup. It also lets the administrator set a custom greeting name, which will also be added during the Windows setup. In this post I’ll show the actual configuration steps, followed by the end-user experience.

Configuration

Before starting with the actual configuration steps, it’s important to name a few prerequisites.

  • Azure AD company branding is configured;
  • Device is running Windows 10, version 1809 or later;
  • User is Microsoft Intune licensed

When the prerequisites are in place, it’s time to start looking at the actual configuration. The following five steps walk through assigning a user to a Windows AutoPilot device.

1 Open the Azure portal and navigate to Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, click Devices to open the Windows AutoPilot devices blade;
3 On the Windows AutoPilot devices blade, select the specific device (make sure to check the box) and click Assign user to open the Select user blade;
AP-AssignUser
4 On the Select user blade, select the specific user and click Select, which will open the Properties blade of the device;
5

AP-UserFriiendlyNameOn Properties blade of the device, provide the User Friendly Name and click OK to return to the Windows AutoPilot devices blade.

Note: This will provide a message like in this case “Awesome dude has ben successfully assigned to 3008-9109-1000-6969-987…

End-user experience

Now let’s end this post by looking at the end-user experience when using a user-driven deployment. After configuring the location and the keyboard, the user will get a personal welcome message. The message includes the configured custom user friendly name and the username will be preconfigured (as shown below). The user only needs to provide a password and click Next.

AP-UserExperience

Note: This experience does not work when used in combination with ADFS.

More information

For more information about assigning a user to a Windows AutoPilot device, please refer to the documentation Enroll Windows devices by using the Windows AutoPilot | Assign a user to a specific Autopilot device.

Remote Windows AutoPilot Reset

This blog post uses remote Windows AutoPilot Reset, to remotely trigger a device reset on Windows 10 devices. This capability is added in Windows 10, Insider Preview Build 17672 and later.

This week it’s all about (remote) Windows AutoPilot Reset. That might sounds like something really cool and really new, but it’s actually not that new. Remember my post about Windows Automatic Redeployment? Well, that functionality still exists, but with the addition to trigger the redeployment (read: reset) remotely via Microsoft Intune, this feature is rebranded to (remote) Windows AutoPilot Reset. That means that Windows Autopilot Reset removes personal files, apps, and settings, by resetting Windows 10 while still maintaining the Azure AD Join and the Microsoft Intune enrollment. In this post I’ll show the required configuration to enable Windows AutoPilot Reset, followed by the steps to trigger a remote Windows AutoPilot Reset. I’ll end this post by looking at the end-user experience.

Configure automatic redeployment

Before actually looking at the required configuration, it’s good to keep in mind that WinRE must be enabled on the device to use Windows AutoPilot Reset. Now let’s continue with the configuration to enable Windows AutoPilot Reset (previously know as Windows Automatic Redeployment). The previous time I configured it by using a custom OMA-URI, while the configuration already became available through the UI. So this time I’ll simply show the UI-setting. The following three steps walk through the creation of a new device configuration profile, including configuring the required setting. After that simply assign the created profile to a user or device group.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

On the Create profile blade, provide the following information and click Create.

  • Name: Provide a valid name for the profile;
  • Description: (Optional) Provide a description for the profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Device restrictions;
  • Settings: See step 3b;
3b On the Device restrictions blade, select General, select Allow with Automatic Redeployment and click OK and OK;
Intune-Automatic-Redeployment

Note: Remember that it’s not a requirement to create this as a separate new profile. This setting can also be added to an existing device restrictions profile.

Trigger remote reset

Based on my previous post about Windows Automatic Redeployment, I showed how to trigger the reset locally from the device. Now let’s continue this post by looking at how to actually trigger the remote reset by using Microsoft Intune. The following three steps walk through the actions.

1 Open the Azure portal and navigate to Intune > Devices > All devices to open the Devices – All devices blade;
2 Intune-AutoPilot-ResetOn the Devices – All devices blade, select the target device and click More > AutoPilot Reset (preview);
3 On the AutoPilot Reset (preview) – [computer name] confirmation box, click Yes;
Intune-AutoPilot-Reset-Confirmation

Note: After confirming the action will show as Action automaticRedeployment with the Status Pending. Once the action is completed the status will change to Completed.

End-user experience

Let’s end this post by looking at the end-user experience. Once the remote Windows AutoPilot is triggered the end-user will receive a notification message, as shown below. That message will tell the end-user that the system needs to restart for automatic redeployment and that the restart is scheduled in 45 minutes.

Intune-AutoPilot-Reset-Experience

More information

For more information about remote Windows AutoPilot Reset, please refer to the documentation about Reset devices with AutoPilot Reset.

Automatically assign Windows AutoPilot deployment profile to Windows AutoPilot devices

This week another (short) blog post about Windows AutoPilot. More specifically, about automatically assigning a Windows AutoPilot deployment profile to Windows AutoPilot devices. That makes it a lot easier for administrators, as this prevents the administrators from potentially forgetting to assign the deployment profile to newly imported devices. Great improvement. Also, I have to say that this subject is documented pretty good, but it could be easier to find. This post is mainly for creating awareness regarding this subject. I’ll provide the options regarding to grouping Windows AutoPilot devices and I’ll show how those options can be used to create a dynamic group.

Options

Let’s start by having a look at the configuration options regarding the grouping of Windows AutoPilot devices. The imported Windows AutoPilot devices are pre-created in Azure AD and, during that creation process, a few values are automatically set for those devices. Below is an overview of those different values.

Value Devices Explanation
[ZTDId] All Windows AutoPilot devices A unique value assigned to all imported Windows AutoPilot devices
[OrderID]:{YourOrderId} All Windows AutoPilot devices with a specific order Id An optional Id that can be specified when importing Windows AutoPilot devices
[PurchaseOrderId]:{YourPurchaseOrderId} All Windows AutoPilot devices with a specific purchase order Id An Id that is set by the OEM when importing Windows AutoPilot devices

Those different values can be used to create dynamic device groups within Azure AD. Below is an overview of the required queries per grouping of Windows AutoPilot devices.

Devices Query
All Windows AutoPilot devices (device.devicePhysicalIDs -any _ -contains “[ZTDId]”)
All Windows AutoPilot devices with a specific order Id (device.devicePhysicalIds -any _ -eq “[OrderID]:{YourOrderId}”)
All Windows AutoPilot devices with a specifc purchase order Id (device.devicePhysicalIds -any _ -eq “[PurchaseOrderId]:{YourPurchaseOrderId }”)

Note: These values can be seen by simply using Graph Explorer, querying https://graph.microsoft.com/v1.0/devices and looking for the physicalIds value.

Configuration

Let’s continue by having a look at how to use these different values and queries for actually grouping all Windows AutoPilot devices. The following 3 steps walk through the creation of a dynamic device group that can use the different queries mentioned earlier.

1 Open the Azure portal and navigate to Intune > Groups or navigate to Azure Active Directory > Groups to open the Groups – All groups blade;;
2 On the Groups – All groups blade, click New group to open the Group blade;
3a

AAD_DD_GroupOn the Group blade, provide the following information and click Create.

  • Group Type: Select Security;
  • Group name: Provide a valid name for the group;
  • Group description: (Optional) Provide a description for the group;
  • Membership type: Select Dynamic Device;
  • Dynamic device members: See step 3b;
3b

AAD_DD_RulesOn the Dynamic membership rules blade, select Advanced rule, provide one of the mentioned queries (depending on the type of AutoPilot devices selection) and click Add query;

Note: The example on the right is showing the query for all AutoPilot devices.

Once the dynamic device group is created it can used for assigning Windows AutoPilot deployment profiles. That enables the administrator to automatically assign a Windows AutoPilot deployment profile to all Windows AutoPilot devices.

Result

Let’s end this post by having a look at the results. Below, on the left, is a quick overview, via Microsoft Graph, about the device information of CLDCLN879139238. That shows the name of the device and the value related to all imported Windows AutoPilot devices. Below on the right is an overview of that same device, showing it as a member of the earlier created dynamic device group.

AAD_DD_Example2 AAD_DD_Example1

More information

For more information regarding the latest Windows AutoPilot features and the configuration steps, please refer to the following articles:

Windows enrollment status page

This week is all about the enrollment status page for Windows 10, version 1803 and later, devices. Yes, I know that I’m not the first to write about this subject and I won’t be the last either, but I really thought that this feature deserves and demands a place on my blog. With the recent updates to Microsoft Intune, it’s now possible to enable the enrollment status page, as a preview feature, for Windows 10, version 1803 and later devices. This feature is often mentioned in combination with Windows AutoPilot, and it’s a great addition, but it’s good to remember that it’s actually applicable to any Azure AD joined (and Intune managed) Windows device. Not just Windows AutoPilot. In this post I’ll walk through the configuration options, followed by the end-user experience related to the configuration options.

Configuration options

Let’s start by walking through the configuration options for the Windows enrollment status page. The following 5 steps walk through those configuration options, with step 4 detailing the actual configuration options and the related behavior.

1 Open the Azure portal and navigate to Intune > Windows enrollment > Enrollment Status Page (Preview) to open the Enrollment Status Page (Preview) blade;
2 EnrollmentStatusPageOn the Enrollment Status Page (Preview) blade, select Default to open the All Users blade;
3 On the All Users blade, select Settings to open the All Users – Settings blade;
4a

Windows-enrollment-status_Config03On the All Users – Settings blade, select Yes with Show app and profile installation progress to enable the enrollment status page during OOBE;

4b Windows-enrollment-status_Config02On the All Users – Settings blade, select Yes with Block device use until all apps and profiles are installed to prevent users from using the device before it’s completely configured and to enable further configuration options for the enrollment status page during OOBE;
4c Windows-enrollment-status_Config01On the All Users – Settings blade,

  • select Yes with Allow users to reset device if installation error occurs to enable end-users to reset the device after a failure during OOBE;
  • select Yes with Allow users to use device if installation error occurs to enable end-users to use the device after a failure during OOBE;
  • configure [number] with Show error when installation takes longer than specified number of minutes to determine how long, in minutes, an installation can take before showing a failure during OOBE;
  • select Yes with Show custom message when an error occurs to enable a custom error message that will be shown to the end-user after a failure during OOBE;
  • select Yes with Allow users to collect logs about installation errors to enable end-users to collect log files of any installation failure during OOBE;
5 On the All Users – Settings blade, click Save;

Note: At this moment I haven’t been able to see my custom error message during OOBE and I haven’t found out how to collect the log files related to the installation failures as an end-user.

Configuration results

Now let’s have a look at the effect of the different configuration options. When configuring the basics, which is simply enabling the enrollment status page (steps 4a), the end-user will get the experience as shown below. It shows the end-user the current status and enables the end-user to click Continue anyway at any point during the enrollment status page.

Windows-enrollment-status_Continue

When configuring all the available options, which is basically enabling all the options (step 4b and 4c), the end-user will get the experience as shown below. It shows the en-user the current status and only provides the end-user with options after a failure. The Reset button is available because of the Allow users to reset device if installation error occurs setting and the Continue anyway link is available because of the Allow users to use device if installation error occurs setting.

Windows-enrollment-status-page_Failure

Note: Not all components are actually tracking something yet. For an up-to-date list of the different tracked components, see the more information URL.

More information

For more information about the enrollment status page, please refer to this article about Set up an enrollment status page.

Get Windows AutoPilot device information of Microsoft Intune managed devices

This week I’m going to show an example of how to collect the Windows AutoPilot device information of existing Microsoft Intune managed (Windows 10) devices. That could be useful, for example, when an organization wants one similar deployment experience for all devices. For now and in the future. In that case it can be very useful to gather the device information and upload that information. That will provide future deployments of those existing devices with the same company branded deployment experience as new devices. Also, another reason for this post is the simple fact that I’ve received this request multiple times now.

This example will use an Azure storage account that will be used to store the Windows AutoPilot device information and it will use the Get-WindowsAutoPilotInfo script to collect the information. In this post I’ll show high over the steps to create the Azure storage account, followed by an overview of the PowerShell script to collect the information and write the information to the storage account. I’ll end this post with the Microsoft Intune configuration and a quick peak at the results. After that simply collect the information and upload it via Microsoft Intune or the Microsoft Store for Business (or the Partner portal).

Create storage account

The first step is to create a storage account in Azure. The following four steps walk through the high over steps to create a storage account including a file share. That file share will be used to store the Windows AutoPilot device information.

1 Open the Azure portal and navigate to Storage accounts;
2 Add a storage account of the Storage (general purpose v1) kind and make sure that Secure transfer required is enabled (remember the storage account name);
3 Navigate to Files and add a file share (remember the file share name);
4 Navigate to Access keys and view the available keys (remember the key) ;

Note: Be aware that not every ISP allows access from port 445 to Azure (for an overview see: https://social.technet.microsoft.com/wiki/contents/articles/32346.azure-summary-of-isps-that-allow-disallow-access-from-port-445.aspx).

Create PowerShell script

The second step is to create a PowerShell script to upload the Windows AutoPilot device information to the file share in the just created storage account.

Script variables

This PowerShell script is created for usage within Microsoft Intune. Currently the PowerShell script functionality within Microsoft Intune can’t work with input variables, which means that the values of the different variables have to be available in the script. That means that in the variables block on top of the script (see script snippet section) the following values should be adjusted.

  1. <StorageAccountKey>: This should be the access key of the created storage account (step 4);
  2. <StorageAccountName>: This should be the name of the created storage account (step 2);
  3. <ShareName>: This should be the name of the share of the created storage account (step 3).

Script actions

The PowerShell script contains a few actions that it should perform to complete the required activities. It contains the following actions that can be found in the different try-catch blocks (see script snippet section).

  1. Create a drive with the created Azure storage account;
  2. Download the available script from PowerShell Gallery;
  3. Set the location to the location of the downloaded script;
  4. Install the downloaded script;
  5. Run the installed script and use the created drive for the output;
  6. Remove the downloaded script and the created drive.

Script snippet

The PowerShell script is shown below.

Note: Be aware that downloading PowerShell Gallery items requires PowerShellGet and that PowerShellGet requires the NuGet provider to work with the PowerShell Gallery (for more information see: https://docs.microsoft.com/en-us/powershell/gallery/psgallery/psgallery_gettingstarted).

Configure PowerShell script

The third step is to configure the PowerShell script in Microsoft Intune. To upload the script, follow the next five steps. After uploading the script, simply assign the script to the required users and/or devices.

1 Open the Azure portal and navigate to Intune > Device configuration > PowerShell scripts;
2 On the Device configuration – PowerShell scripts blade, click Add script to open the Script Settings blade;
3 GWAI_AddPowerShellScriptOn the Add PowerShell script blade, provide the following information and click Settings to open the Script Settings blade;

  • Name: Provide a valid name for the PowerShell script policy;
  • Description: (Optional) Provide a description for the PowerShell script policy;
  • Script location: Browse to the PowerShell script.

Note: The script must be less than 10 KB (ASCII) or 5 KB (Unicode).

4 GWAI_ScriptSettingsOn the Script Settings blade, provide the following configuration and click OK to return to the PowerShell script blade;

  • Run the script using the logged on credentials: No;
  • Enforce script signature check: No;

Note: Configure Run the script using the logged on credentials to No means that the PowerShell script will run in SYSTEM context;

5 Back on the Add PowerShell script blade, click Create.

End result

Now let’s end this post by looking at the results. The share in the created storage accounts will start filling with CSV-files of the different Windows 10 devices that are managed by Microsoft Intune. That means that it will start to look like something as shown below.

GWAI_AzureStorage

As the required device information is available now, within the file share of the storage account, it can be downloaded and imported via for example Microsoft Intune. Of course it’s possible to use PowerShell to merge these CSV-files into one big CSV-file. This is relatively easy by simply using something like Get-Content and always grab the second line of the CSV-files.

Import Windows AutoPilot devices in Microsoft Intune

This week I’m going to show the import experience of Windows AutoPilot devices in Microsoft Intune. About three months ago, this wasn’t possible yet and it was still required to use the Windows Store for Business (see this blog post). Even up until a few weeks ago it was still required to perform additional steps with the formatting. Now the experience is really straight forward.

I was planning on showing that experience during my session last week, at the Microsoft Tech Summit, but after speaking to many people onsite I noticed that it would be better to spent more time on explaining what Windows AutoPilot is and what Windows AutoPilot is not. Setting the expectations. An easy comparison with car and aircraft functionality helped a lot (together with some statements about what Windows AutoPilot does and what Windows AutoPilot does not do).

Now, back to the subject of this post, let’s have a look at the latest import experience by getting the device information and than importing that information in Microsoft Intune.

Get device information

To get the required device information, I’m using the latest version of the Get-WindowsAutoPilotInfo PowerShell script. That script is the easiest method to get the required information, especially for testing purposes. An alternative could be the Windows AutoPilot Device Information report in Configuration Manager, version 1802 or later. The script can create a CSV with a column for the Device Serial Number, the Windows Product ID and the Hardware Hash of the device. With the latest version of the script the value for the Windows Product ID will be skipped. Simply follow the next four steps.

1 Open Windows PowerShell as an Administrator;
2 Run Save-Script -Name Get-WindowsAutoPilotInfo -Path C:\Windows\Temp to inspect the PowerShell script;
3 Run Install-Script -Name Get-WindowsAutoPilotInfo to install the PowerShell script;
4 Run Get-WindowsAutoPilotInfo.ps1 -OutputFile C:\Windows\Temp\MyComputer.csv to get the required device information;
WA_MyComputer

Note: Keep in mind that the script can also run with a Partner switch, which will make sure that also the Manufacturer name and Device model are collected and reported.

Import device information

Now import the Windows AutoPilot device information into Microsoft Intune. The import process in Microsoft Intune can now also handle a header row in the CSV and an empty column for the Windows Product ID. This wasn’t possible until a couple of weeks ago. To import the device information, simply follow the next five steps.

1 Open the Azure portal and navigate to Intune > Device enrollment > Windows Enrollment;
2 On the Devices enrollment – Windows enrollment blade, click Devices below Windows AutoPilot devices (Preview) to open the Windows AutoPilot devices (Preview) blade;
3 On the Windows AutoPilot devices (Preview) blade, click Import to open the Add Windows AutoPilot devices blade;
4 WA_AddWAdevicesOn the Add Windows AutoPilot devices blade, select the just created CSV (MyComputer.csv) and click Import to trigger the import process;

Note: Selecting the CSV will immediately trigger a check on the formatting of the CSV.

5* Back on the Windows AutoPilot devices (Preview) blade, click Sync followed by Refresh to speed up the process to show the devices in Microsoft Intune;
WA_WAdevices

*At this moment the Microsoft Intune experience might still be a bit out of sync (it’s still preview) with the Windows AutoPilot deployment service, which is why I’ve added this step to manually trigger the sync.

Join me at the Tech Summit in Amsterdam

Next week, March 28-29, the Microsoft Tech Summit will be in Amsterdam and I will be there. On Wednesday (March 28) I will be available at the Ask the Experts Reception and on Thursday (March 29) I will be speaking about Manage Windows AutoPilot via Microsoft Intune. I hope I will see you there!

pvanderwoude

About my session

In this session, I will pull you into the world of Windows AutoPilot. Learn what Windows AutoPilot is and also, learn what Windows AutoPilot is not. In this demo-rich session I will show you how to use Windows AutoPilot, together with Microsoft Intune, to simplify device provisioning.