Automation of gathering and importing Windows Autopilot information

Complete process automation of gathering and upload of a device Autopilot information to the Windows Autopilot service with an Azure Automation Runbook.

AzureAutomation
On one of my previous blog post Gather Windows 10 Autopilot info in azure blob storage during wipe and reload, I described the gathering of Autopilot information during operating system deployment in a wipe and reload scenario with MDT. Just a short recap of the problem and my initial solution:

If we purchase a new device, the OEM vendor takes care of installing Windows 10 with a signature edition or provisioning ready installation including all necessary drivers. If we buy new hardware the information for Autopilot can be synced into our tenant from the OEM vendor (Lenovo is already capable of doing that and others will follow). We will get the device information in Intune and we can start to assign an Autopilot Deployment Profile and start to enroll the devices.

What if we have a bunch of Windows 7 devices in the environment?

A way to handle this is that we are playing the role of the OEM vendor and do the install of a Windows 10 signature edition on the existing Windows 7 devices, gathering Autopilot information, and let Windows 10 start in the Out of Box Experience (OOBE) again for user enrollment. Depending what is available we can use ConfigMgr or MDT for this. My example uses MDT.

Now imagine a situation where a rollout team is preparing a lot of machines. We would end up in a lot of .csv files on different devices. To make this a little easier for IT to import the hardware information of new devices into the Autopilot service, we build up the following logic:

  1. Gather hardware information via PowerShell Script Get-WindowsAutoPilotInfo during wipe and reload
  2. Upload .csv file via AzCopy to an Azure Blob Storage
  3. Gather .csv files from Azure Blob Storage and combine them into a single combined.csv file
    This was a manual step in my previous solution
  4. Upload combined .csv file to Autopilot and assign Deployment Profiles
    This was a manual step in my previous solution
  5. Device can be delivered to the end user like it where shipped by the OEM vendor

You can read more about the initial solution here: Gather Windows 10 Autopilot info in azure blob storage during wipe and reload

This blog post is all about automating these two steps – gathering and upload of Autopilot information to Intune.

Architecture

First, I will explain the architecture and how it works and then I’m going to describe the way to implement it. The overall architecture is based on an Azure Automation Runbook and looks like this:

AutoPilotImportArchitectureOverview

The new procedure including the enhanced logic for a complete automation of the import is now as follows (modified steps for complete automation):

  1. Gather hardware information via PowerShell Script Get-WindowsAutoPilotInfo during wipe and reload scenario
  2. Upload .csv file via AzCopy to an Azure Blob Storage
  3. Gather .csv files from Azure Blob Storage and combine them into a single .csv file with the help of a scheduled Azure Runbook
  4. Upload combined .csv file information to Windows Autopilot Service via PowerShell Script WindowsAutoPilotIntune running in an Azure Automation Runbook 
  5. Cleanup Azure Blob Storage (delete all .csv files of successfully imported devices and delete all .csv files of already imported devices)
  6. Generate import notification and summary and post it to a Microsoft Teams channel
  7. Autopilot information is available for the OOBE user enrollment scenario with Autopilot. The Autopilot profile gets automatically assigned by a dynamic AzureAD device group membership.
  8. Device can be delivered to the end user like it where shipped by the OEM vendor

I’ve still chosen the copy via AzCopy of individual .csv files to the Azure Blob Storage approach as we can then limit the access quite well via shared access signature and we can easily limit permission to write blob objects only. No need to provide credentials or Blob Storage keys on the client side. Sure, we could build up a more advanced HTTP endpoint to gather device information, but this approach is quick and simple. I’m pretty sure that the complete solution of this automation task is something which we do not need in future when devices are Windows 10 migrated and we then buy Autopilot ready hardware only.

 

Guide to build the new solution

The Autopilot Graph API is an API with focus on batch processing. This means we import new device information into a kind of staging area and Windows Autopilot service will pick up the new device information and starts importing it. This process varies in the amount of time it takes and we have to check the status of all devices to get the import result. As soon as the devices are processed we can clean up the staging area and the import is done. Normally we would do this by wrapping the Graph API calls (REST) into some PowerShell functions and build the logic for the described process. Luckily Microsoft released a new PowerShell Module WindowsAutoPilotIntune (thx to @mniehaus) based on the Graph API to import new AutoPilot information into Intune.

In my previous blog post about Process automation for Intune and Azure AD with Azure Automation, I created a Runbook to delete old devices from Intune via Graph API and demonstrated how to do an unattended authentication within the Runbook. All the details how this can be achieved are explained there. Please follow the guide to setup the Azure Automation account. I use the same unattended authentication technique to utilize the PowerShell Module WindowsAutoPilotIntune to import the device information into Autopilot service in the following Runbook. Additionally, the Runbook is built to protect concurrent execution (thx to Tao Yang, I used his implementation for it) to ensure a sequential processing and to keep track of current running imports. If we would design this as a concurrent solution it would get much harder in terms of monitoring and reporting in the end. In addition, there is a max import of 175 devices into the staging area of the API which we are taking care of by limiting the Runbook import to 175 devices during one run.

If the requirements are implemented based on the previous blog post (especially the Intune native app and the automation service account) we simply need to extend the permissions to “Read and write Microsoft Intune configuration” of the automation account which was created during the setup of Process automation for Intune and Azure AD with Azure Automation in section Building the solution.

IntuneNativeAppPermission

For the concurrent execution protection, we need our automation credential to have Reader permission and for Blob Storage access we need Contributor permissions on the subscription. As the result we grant Contributor permission to the automation account:

SubscriptionPermissions

Finally, we can implement the complete Runbook which can be found on my GitHub account here:

https://github.com/okieselbach/Azure-Automation/blob/master/Import-AutoPilotInfo.ps1

The Runbook is written in PowerShell and follows the logic described in the beginning of this post – section architecture.

Create a PowerShell Runbook and paste-in the code.

CreateNewRunbook

PowerShellRunbook

To make sure the Runbook successfully runs we need to define some additional variables. I assume that the IntuneClientId and Tenant variable are defined as described in the previous blog post.

AzureAutomationVariables

Additional variables needed for Azure Blob Storage access:

ContainerName: <your-blob-storage-containername>
StorageAccountName:
<your-blob-storage-account>
StorageKey: <your-blob-storage-secret-key> * as encrypted variable

Additional variables needed for Microsoft Teams Channel notification:

SubscriptionUrl: <your-subscription-url>

The subscription URL can be found as shown below. Please do not copy the /overview end of the URL. The URL should end with the subscription GUID only (like highlighted):

AzureSubscriptionsUrl

TeamsWebHookUrl: <your-ms-teams-webhook-url>

Open MS Teams and choose a Channel where the Autopilot notification from the Azure Runbook should be displayed. Click on the three dots and choose Connectors:

TeamsConnectors

Look for Incoming Webhook and click Configure

incomingwebhook.png

Type in the details and upload a icon and click Create

ConnectorDetails

Finally copy the Webhook URL:

ConnectorWebHookUrl

Paste it into the Azure Automation variable TeamsWebHookUrl and set encrypted value to Yes

TeamsWebHookVarEncrypted

This is necessary to get Microsoft Teams notifications with some statistics and information to troubleshoot errors. Below is an example of an import notification in Microsoft Teams:

AutoPiloImportTeamsNotification

We have some statistics, detailed error list with device information and a link to the Runbook itself in Azure. All based on Adaptive Cards JSON code. This can be easily modified to fulfill personal needs. Have a look at the Adaptive Cards Designer (https://acdesignerbeta.azurewebsites.net) for experimenting with layouts and adjust the Runbook code.

 

Enhanced client-side script part

I my previous blog post about Gather Windows 10 Autopilot info in azure blob storage during wipe and reload I have described how to setup the Azure Blob Storage to gather the “<hostname>.csv” files during MDT operating system installation. Please follow the previous guide to setup the Azure Blob Storage and the integration in MDT.

I have an enhanced version of the gather script now which can be found on my GitHub account and is also shown below. The enhanced version does not have the dependency on AzCopy.exe (incl. dependency files) and Get-WindowsAutoPilotInfo.ps1 in the script directory. If they are not available, they are downloaded from an additional Blob Storage container named resources. The additional container resources must be created and the AzCopy.zip and Get-WindowsAutoPilotInfo.ps1 must be uploaded there to successfully run the script:

BlobStorageResources

BlobStorageResourcesContent

The enhanced Get-WindowsAutoPilotInfoAndUpload.ps1 version:

Replace ZZZZ with your Blob Storage account name and ZZZZ with your SAS signature in the script above. See here Delegating Access with a Shared Access Signature for more SAS signature details.

This version can also be used to be executed via Microsoft Intune Management Extension to run it on existing Windows 10 devices. It is possible to collect all targeted device information and the Runbook will import the device information. Already imported devices will be skipped. This way we can make sure every device is imported to the Autopilot service.

SideCarAutoPilotScript

 

Sample output of the Runbook

AutoPiloImportRunbookOutput

If a device information <hostname>.csv is successfully imported the .csv files will be deleted from the Azure Blob Storage. In case of an error it will be left there untouched but reported via Runbook output and Teams notification. There is one case where the Runbook will delete the .csv file from the Azure Blob Storage also. This is if the Runbook detects an error 806 – ZtdDeviceAlreadyAssigned. In that case we can delete the .csv as it has no consequences. In every other error situation someone needs to resolve the error manually. The Teams notification is only generated if there is some device information in the Azure Blob Storage. The normal procedure would be if operations gets an import notification it should check and in case of errors they should be resolved manually.

AutoPiloImportTeamsNotification

 

Important observations during testing

The Autopilot import via Graph API takes some time and it may also timeout. So, it is not a typical request response REST API in this case. Remember all device information is staged and then the devices are monitored for their success or error state. This led to situations where I had to wait up to 1 hour to get a successful import, even when the UI in Intune tells us it takes up to 15 min. So be prepared that it might take longer or fails during the run. I chose this approach as it is the same procedure as the Azure Portal does the import. In fact, we really automated the import process in Intune but did not invent a complete different process which might cause different problems of device tracking or concurrency and so on. Depending on the use case you can run the Runbook on a recurring schedule. My normal use case for this scenario is to support people who are preparing older devices when they are getting reinstalled from Windows 7 to Windows 10. If someone expects immediate availability of Autopilot information after such a reinstall this might be problematic as the API is not designed for this. Another fact is that the Autopilot Deployment Profile assignment using Intune does take some time also at the moment. I observed that it took several hours sometimes. I suggest to re-arrange the operational processes and hand out reinstalled Windows 10 devices after some additional time and not directly after reinstalling, as this increases the possibility that the Autopilot information is not imported and profile assigned yet.

To run the Runbook on a recurring schedule just go to the Runbook and add a schedule. The max recurrence is limited to every hour.

AddRunbookSchedule

Just define a schedule (max once per hour) and monitor the recent job overview if it works:

AzureRunbookSchedule

The schedule can even be enhanced by using a simple Logic App and not using the Azure Automation Runbook schedule at all:

LogicAppTriggerRunbook

Please see Stefan Strangers post for detailed instructions how to implement a simple Logic App to trigger an Azure Automation Runbook:

https://blogs.technet.microsoft.com/stefan_stranger/2017/06/23/azur-logic-apps-schedule-your-runbooks-more-often-than-every-hour/

In case something goes wrong I have created a second Runbook to clean up the staging area of the Autopilot Graph API. Get it from my GitHub account and run it in case of fatal errors where you might want to clean up the staging area:

https://github.com/okieselbach/Azure-Automation/blob/master/Cleanup-AutoPilotImportedDevices.ps1

Here is a sample output of the Cleanup Runbook:

CleanupRunbookOutput

Further information

Azure Logic Apps – Schedule your Runbooks more often than every hour
https://blogs.technet.microsoft.com/stefan_stranger/2017/06/23/azur-logic-apps-schedule-your-runbooks-more-often-than-every-hour

Preventing Azure Automation Concurrent Jobs In the Runbook
https://blog.tyang.org/2017/07/03/preventing-azure-automation-concurrent-jobs-in-the-runbook

Post notifications to Microsoft Teams using PowerShell
https://blogs.technet.microsoft.com/privatecloud/2016/11/02/post-notifications-to-microsoft-teams-using-powershell

importedWindowsAutopilotDeviceIdentity resource type
https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/intune_enrollment_importedwindowsautopilotdeviceidentity

Autopilot profile assignment using Intune
https://blogs.technet.microsoft.com/mniehaus/2018/06/13/autopilot-profile-assignment-using-intune

Adaptive Cards Designer
https://acdesignerbeta.azurewebsites.net

I published the same article on SCConfigMgr in a more step-by-step guide version, meaning there are not so many cross references to my other articles:

Automation of gathering and importing Windows Autopilot information
http://www.scconfigmgr.com/2018/07/23/automation-of-gathering-and-importing-windows-autopilot-information

 

I hope this can increase your throughput on the way to an Autopilot Windows 10 modern management environment.

When someone finds bugs or problems with the solution let me know and leave a comment. I will do my best to fix them as it should be a reliable part during preparing old devices with Windows 10.

Use Delivery Optimization with DHCP Option on Pre-Windows 10 version 1803

The new Windows 10 Peer 2 Peer feature Delivery Optimization was enhanced by the setting to query DHCP option ID 234 to get a Group ID (DOGroupIdSource). It was implemented into the latest Windows 10 version 1803 based on my feedback. I’m a little proud that the idea was well received and my product feedback was implemented as new option within six month.

It was officially announced with Windows Insider Preview 17063. It can be read here: https://blogs.windows.com/windowsexperience/2017/12/19/announcing-windows-10-insider-preview-build-17063-pc/#zluZyU1FMlLMzU6h.97 in the section New features for IT Pros in Delivery Optimization.

I’ve written a blog post how Delivery Optimization works and how to use this feature with new Windows versions 1803+, see here: Configure Delivery Optimization with Intune for Windows Update for Business.  It’s really great to have it with Windows 10 version 1803+ but I need to provide this functionality to older Windows 10 versions (1703 and 1709) also. I want to use this very good and flexible grouping capability from now on for all devices even pre-version 1803.

Therefore I have designed a solution to provide this functionality to older versions of Windows 10 and switch over to the native Windows 10 implemented solution as soon as the device gets upgraded to 1803.

First problem is to get the DHCP option from the DHCP server. Luckily I’ve written a small C++ program to do that in the past. I’ve written it to even work with a WinPE environment. The small binary can be used to send the DHCP option ID x request. When executed the binary expects a result as a string value. Below an example:

DhcpOption.exe <OptionID>

DhcpOptionExeExample

It’s even possible to specify a debug switch

DhcpOption.exe <OptionID> [debug]

to get debug output for troubleshooting:

DhcpOptionExeDebugExample

The C++ solution can be found on my GitHub here:
https://github.com/okieselbach/Helpers/tree/master/DhcpOption_VC2017

The compiled x64 binary DhcpOption.exe can be found here:
https://github.com/okieselbach/Intune/tree/master/ManagementExtension-Samples/DOScript

With this little helper we can use the Intune Management Extension and design a PowerShell script to:

  1. query DHCP server for the Option ID 234
  2. write result (Group ID) to the registry

Prerequisite is an available Option ID 234 on the DHCP server. See Configure Delivery Optimization with Intune for Windows Update for Business how to configure the DHCP server for this.

To support travelling users we need to make sure the device will query the DHCP server from time to time to get the group ID belonging to the current DHCP scope the client is using. For this we schedule the script as a scheduled task and run it at logon and on every unlock of the workstation.

The Delivery Optimization service will query the registry value for every new request and this makes sure a client uses the Group ID delivered by DHCP from the particular site.

To make sure we do not interfere with the native implementation starting with 1803 I implemented a logic to disable the scheduled task and remove the registry key as soon as Windows 10 version 1803, a build greater than 16299 is found.

The DhcpOption.exe will be provided from an Azure Blob Storage account. We need to create a Storage account as type Blob storage and a container to store the DhcpOption.exe. Then we use the provided download link in the script to get the binary during install. A guide how to create the Azure storage account is included in my article Gather Windows 10 AutoPilot info in Azure Blob Storage during wipe and reload. You don’t need the SAS token, just the container and upload DhcpOption.exe. The SAS token is only needed to support POSTS methods for uploading new files to the blob storage. The DhcpOption.exe is uploaded once and then provided for download only.

With this solution we can use the DHCP option for all Windows 10 version until 1803 and as soon as we get upgraded we disable and remove our self and the native implementation takes over. To make sure the native implementation is used as soon 1803 is found we need to implement the new DO settings (DOGroupIdSource). Follow my guide in my previous post for this Configure Delivery Optimization with Intune for Windows Update for Business.

Source Code of the full custom DO install script Register-DOScript.ps1 can be found on my GitHub Gist here:

Make sure to replace the Azure blob storage URL with your own one!

The uninstall script Unregister-DOScript.ps1 is also available via my GitHub Gist:

If we combine the script with Intune Management Extension we can easily deploy this solution to our Azure AD joined modern managed Windows 10 pre-version 1803 devices.

We will get the files for scheduling at C:\ProgramData\CustomScripts

DOScriptProgramDataFiles

and the scheduled task RunCustomDOscript

DOScriptScheduledTask

with task trigger logon or unlock of workstation

DOScriptScheduledTaskTrigger

when executed we will get the Group ID from the DHCP server

MD DHCP Group ID Option in Scope

and the received string is written to the registry

DOGroupIdRegistry

for me this bridges the time until all devices are upgraded to Windows 10 version 1803 and gives me enough flexibility to group my devices to achieve maximum Delivery Optimization benefits.

Happy caching!

Part 2, Deep dive Microsoft Intune Management Extension – PowerShell Scripts

Because of the popularity of my first blog post Deep dive Microsoft Intune Management Extension – PowerShell Scripts, I’ve decided to write a second post regarding Intune Management Extension to further explain some architecture behind this feature and upcoming question from the community. A deeper understanding helps to successful troubleshoot the feature.

Table of content for easy navigation

 

Details of the MSI deployment of the Intune Management Extension agent?

Please read the first article Deep dive Microsoft Intune Management Extension – PowerShell Scripts, to get an understanding of the MSI install job.

The EnterpriseDesktopAppManagement CSP takes care of this task and delivers the MSI to the device and starts the execution. The CSP provides some helpful information in registry for troubleshooting.

In the registry at HKLM\SOFTWARE\Microsoft\EnterpriseDesktopAppManagement\<SID>\<MSI-ProductCode> you can find helpful information for troubleshooting:

EnterpriseDesktopAppManagementCspRegistry

Highlighted value names are described in detail here:

CurrentDownloadUrl: URL to the MSI install file.

EnforcementRetryCount: The number of times the download and installation operation will be retried before the installation will be marked as failed.

EnforcementRetryIndex: The current number of retry.

EnforcementRetryInterval: Amount of time, in minutes between retry operations.

EnforcementStartTime: Start time of enforcement.

EnforcementTimeout: Amount of time, in minutes that the installation process can run before the installer considers the installation may have failed and no longer monitors the installation operation.

LastError: Error after last execution.

Status: The Status can have the following values according to the EnterpriseDesktopAppManagement CSP documentation:

Value = Status
10 = Initialized
20 = Download In Progress
25 = Pending Download Retry
30 = Download Failed
40 = Download Completed
48 = Pending User Session
50 = Enforcement In Progress
55= Pending Enforcement Retry
60 = Enforcement Failed
70 = Enforcement Completed

In case of no sidecar agent on the device the status may indicate an error or it is still in progress of downloading. Try to figure out this status. Correlate the status with your device and environment. There may be a proxy issue?

According to the screenshot above the CSP will try it 3 times with a timeout of 10 min and then it will be marked as failed. Is there a retry after x days, I assume yes but I don’t have some documentation for it. As soon as I have more information I will update the article accordingly.

 

Be aware of the log files regarding sensitive data!

The following script below will create a local user account with a specified static password. It is a working script, but be aware that it should not be used in production! The whole script content will be logged to the IntuneManagementExtension.log file. There you will find the clear text static password as defined in the script. As an example I have copied and marked the particular log file entries below the script to show that. Disk encryption technologies like BitLocker are lowering the risks a bit, but even then this is not a concept to be used in production environments! An attacker can read the log files with standard user permissions and get the sensitive data. Without BitLocker encryption this can be done even offline!

Again: I do NOT recommend transferring sensitive data like passwords via this approach! I know it’s often done. There is a similar approach for on-prem AD which is often used. The GPO preferences for local user management tasks uses a simple xml file with passwords base64 encoded -> this is not secure! Please consider something that was build for that purpose. Admin account management should be done via LAPS or other third party. I know there is no equivalent solution like LAPS for a cloud only environment right now from Microsoft.

# Author: Oliver Kieselbach
# Date: 01/03/2018
# Description: Create a local user account.

# REMARK: DO NOT USE IN PRODUCTION, Password will not be unique and be visible in clear text in log file!

# The script is provided "AS IS" with no warranties.

Param([switch]$Is64Bit = $false)

Function Restart-As64BitProcess
{
If ([System.Environment]::Is64BitProcess) { return }
$Invocation = $($MyInvocation.PSCommandPath)
if ($Invocation -eq $null) { return }
$sysNativePath = $psHome.ToLower().Replace("syswow64", "sysnative")
Start-Process "$sysNativePath\powershell.exe" -ArgumentList "-ex bypass -file `"$Invocation`" -Is64Bit" -WindowStyle Hidden -Wait
}

if (!$Is64Bit) { Restart-As64BitProcess }
else
{
Start-Transcript -Path "$env:temp\CreateLocalUser.log"

$password = ConvertTo-SecureString "SecretP@ssw0rd!" -AsPlainText -Force
New-LocalUser "John" -AccountNeverExpires:$true -FullName "John Doe" -Password $password

Stop-Transcript
}

To demonstrate the problem with this approach, here is the corresponding log file part after script execution with the complete script and static password in clear text:

sensitivedatainlogfile.png

 

Getting content of scripts once they are uploaded to Intune?

The Intune Azure Portal does not provide any UI element to show the uploaded script again. Thanks to the GitHub repository Intune PowerShell Samples we do not script something by our own. We can use a script provided from there called DeviceManagementScripts_Get.ps1. It will get all uploaded scripts, including script content, and details from the Intune API via Microsoft Graph API.

Get it from here:
https://github.com/microsoftgraph/powershell-intune-samples/blob/master/DeviceConfiguration/DeviceManagementScripts_Get.ps1

Save it locally and run it with PowerShell and provide your Intune Administrator credentials when asked for:

IntuneManagementExtensionScriptContent

 

What about return codes (exit codes) of PowerShell scripts?

At the moment the Intune Management Extension will gather various results, but the Intune Azure portal does not show them in an UI element (if it will change in the future and we have something available, I will update the post accordingly). As for now scripts can be executed through the Intune agent and the Intune UI will show just the execution state success or failure. The status is related to successful agent execution, like no hash mismatch, no script content problem, and no error output… it does not reflect the script exit code.

Scripts like this, I called it “failscript.ps1” are handled as success at the moment:

[Environment]::Exit(-1)

See here the results in Intune Azure Portal:

IntuneAgentFailscriptStatus

Perhaps Intune will show us script exit codes in the UI sometime, then we could verify this easily with the failscript from above.

If we use Write-Error cmdlet in our scripts then Intune will pick up the error output. Here an example:

Write-Error -Message "Could not write regsitry value" -Category OperationStopped

This gives us a failed status in the monitoring section of the PowerShell scripts:

IntuneAgentWriteErrorScriptStatus

 

 

Where can I find a helpful PowerShell script template to start with?

I have made a simple script template which:

  1. Enforces execution in x64 PowerShell (restart of PowerShell as x64 process)
  2. Generates a log file in C:\Windows\temp when run in system context
    or %LocalAppData%\temp when run in user context
  3. Has exit code handling (exit code is even gathered when restarted as x64 process)
  4. Uses Write-Error to signal Intune a failed execution and makes sure we have reporting reflecting our script execution success (standard error is even gathered when restarted as x64 process)

For ongoing maintenance it is provided via GitHub Gist:

 

Script execution retry interval when failed?

The PowerShell scripts are executed via agent on the target device. If an execution fails, the agent tries to run the script again during next check-in. Current check-in interval is every 60 minutes. This procedure is limited to 3 attempts!

This is tracked in registry at:

HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Policies\UserGUID\ScriptGUID

The DownloadCount also means execution count and the result is tracked as Success or Failed.

IntuneManagementExtensionScriptRegistry

If we change the run as account (user/system), signature check or script content, the DownloadCount will be reset, and the agent will try another 3 attempts to execute the script.

If a script should be enforced to run again, we can simply reset DownloadCount and ErrorCode to 0 and set Result and ResultDetails to nothing (empty string). After this we just restart the Microsoft Intune Management Extension Service (IntuneManagementExtension) and the script will rerun again on this device.

 

Can we schedule scripts?

No we do not have a run schedule at the moment. For example the agent does not execute the script every x hours. The agent checks every 60 minutes for new policies in the backend – during this no re-run of scripts occurs once a script is successful executed. If scheduling of scripts is needed I suggest to register the script as a scheduled tasks via PS commands. That’s the only way at the moment (as soon as we have something available for scheduling I will update the post accordingly).

Below a script to copy the scheduled script to a certain folder like C:\ProgramData\CustomScripts\myScript.ps1 and then register a scheduled task to run it periodically:

# Author: Oliver Kieselbach
# Date: 01/31/2018
# Description: install ps script and register scheduled task

# The script is provided "AS IS" with no warranties.

# define your PS script here
$content = @"
Out-File -FilePath "C:\Windows\Temp\test.txt" -Encoding unicode -Force -InputObject "Hello World!"
"@

# create custom folder and write PS script
$path = $(Join-Path $env:ProgramData CustomScripts)
if (!(Test-Path $path))
{
 New-Item -Path $path -ItemType Directory -Force -Confirm:$false
}
Out-File -FilePath $(Join-Path $env:ProgramData CustomScripts\myScript.ps1) -Encoding unicode -Force -InputObject $content -Confirm:$false

# register script as scheduled task
$Time = New-ScheduledTaskTrigger -At 12:00 -Daily
$User = "SYSTEM"
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ex bypass -file `"C:\ProgramData\CustomScripts\myScript.ps1`""
Register-ScheduledTask -TaskName "RunCustomScriptDaily" -Trigger $Time -User $User -Action $Action -Force

Here some documentation regarding PowerShell and scheduled tasks:
https://docs.microsoft.com/en-us/powershell/module/scheduledtasks/register-scheduledtask?view=win10-ps

But you need to think about a strategy how to track all this or how to modify in the future. Once set you may want to have a modification script to change schedules or even delete it from the device again.

 

Integrated HealthCheck of Intune Management Extension agent?

The Intune Management Extension creates a scheduled task which will run a Health Check once a day.

IntuneManagementExtensionHealthCheck

If familiar with ConfigMgr and the ConfigMgr agent, there we have the same concept. The health check involves 4 files:

ClientHealthEval.exe and ClientHealthEval.exe.config: The binary which runs the health check.

HealthCheck.xml: The xml with all rules to run to perform the health check.

HealthReport.json: The json report with results of the rules defined by the xml.

The tests are defined in the xml file to check the agent registered service, startup type, service status and memory usage.

 

User interaction and timeout?

When using a scripts with the typical user interaction (like shown as an example in my first article Deep dive Microsoft Intune Management Extension – PowerShell Scripts), be advised that this script is getting executed and showing a dialog which blocks the script from finishing, until the user interacts with the dialog and then let the script finish. This can lead to timeouts and then scripts are getting marked as failed even when successfully ran.

The current default script timeout is 10 minutes for execution which is currently not adjustable.

 

If you find something missing or changed feel free to leave a comment. Thanks!

How to “Push-button reset” Windows 10

The “push-button reset” (PBR) is the way to do a “factory reset” on Windows 10. It constructs a fresh Windows 10 installation and we can start over again.

Implementing a Microsoft 365 powered device mobility concept for a modern workplace with Windows 10, makes usage of Windows as a Service and provides new ways of self enrollment. Wherever we are, we service the OS from the cloud (Windows Update for Business) and manage it from the cloud (Intune).

In case of failure there are primarily two options:

  • Get a new device and enroll the device to Azure AD again
  • Start push-button reset to run a factory reset and start over again

In case of failure or if we want to re-purpose the device (back into stock or hand over to another employee) we use the push-button reset in this concept.

 

How is push-button reset triggered from the client?

First of all we need to distinguish between a device where the user is local administrator and a device where the user is standard user.

In case of local administrator the push-button reset can be triggered from Settings > Update & Security > Recovery > Reset this PC > Get started

PBR Settings Local Administrator

As shown there are two options available:

  • Keep my files
  • Remove everything

When choosing “Remove everything” we have the following two additional options:

PBRResetEverything

Be aware if “Remove files and clean the drive” is chosen it will really take a long time to complete!

 

In case of standard user we do not have the reset option in settings available. This is relevant when using AutoPilot and a profile with “Disable local admin account creation on the device” as shown below:

AutoPilotProfileSfB

As a standard user the settings are shown with no reset option in the recovery menu:

PBRSettingsStandardUser

For Microsoft 365 powered devices managed by Intune we can deploy the Company Portal and use it to trigger the reset. Open the deployed Company Portal > choose device > … (menu in the upper right) > Reset

PBRCompanyPortal

PBRCompanyPortalDialog

 

How is push-button reset triggered from Intune?

We need to open the Intune portal portal.azure.com and navigate to Intune > Devices > All Devices > pick the particular device > Factory reset

IntuneFactoryReset

as shown in the screenshot there is the additional option to “Retain the enrollment state and user account”.

For detailed description what is retained please refer to: https://docs.microsoft.com/en-us/intune/devices-wipe#factory-reset

If the device is on and connected, it takes less than 15 minutes for a factory reset command to propagate across all device types.

 

What is the “Fresh Start” available in Intune?

The Fresh Start device action removes any apps that were installed on a Windows 10 PC running the Creators Update, then automatically updates the PC to the latest version of Windows. This can be used to help remove pre-installed (OEM) apps that are often delivered with a new PC. You can configure if user data is retained when this device action is issued. In this case, apps and settings are removed, but the contents of the users Home folder are retained.

IntuneFreshStart

IntuneFreshStartDialog

If the device is on and connected, it takes less than 15 minutes for a factory reset command to propagate across all device types.

 

Reset in Action

When a reset is triggered the device will end up rebooting and the reset will occur.

Windows10Resetting

After finishing the reset the device will start in OOBE again for new enrollment or at the logon screen when enrollment was retained.

 

Issues with Lenovo devices and the troubleshooting

During tests I observed Lenovo devices which ran into an error after resetting and starting into OOBE again. Shortly after language and keyboard selection I got this:

OOBESomethingWentWrong

After some debugging I found out that the license.rtf file was not available in C:\Windows\System32 and this blocked the OOBE from displaying the EULA and resulted in the “Something went wrong” error screen. Click on “Try again” generated a loop.

I could solve this problem with a small customization of the PBR. The PBR has options to add a script to the PBR routine. More details see here: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-a-script-to-push-button-reset-features

I prepared a script which copies the license.rtf file back to C:\Windows\System32 folder if it is missing after the reset. We need to prepare 2 files and we need the license.rtf from a running Windows 10 device.

EnableCustomizations.cmd

rem EnableCustomizations.cmd

rem Define %TARGETOS% as the Windows folder (This later becomes C:\Windows)
for /F "tokens=1,2,3 delims= " %%A in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RecoveryEnvironment" /v TargetOS') DO SET TARGETOS=%%C

rem Define %TARGETOSDRIVE% as the Windows partition (This later becomes C:)
for /F "tokens=1 delims=\" %%A in ('Echo %TARGETOS%') DO SET TARGETOSDRIVE=%%A

rem Add back license.rtf file if missing
IF NOT EXIST "%TARGETOS%\System32\license.rtf" (
copy "%TARGETOSDRIVE%\Recovery\OEM\license.rtf" "%TARGETOS%\System32\license.rtf" /y
)
exit /b 0

ResetConfig.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- ResetConfig.xml -->
<Reset>
 <Run Phase="BasicReset_AfterImageApply">
 <Path>EnableCustomizations.cmd</Path>
 <Duration>2</Duration>
 </Run>
 <Run Phase="FactoryReset_AfterImageApply">
 <Path>EnableCustomizations.cmd</Path>
 <Duration>2</Duration>
 </Run>
</Reset>

In the end copy EnableCustomizations.cmd, ResetConfig.xml and the license.rtf to the folder:

C:\Recovery\OEM

After deploying the custom PBR fix for the Lenovo devices the push button reset runs smoothly.

 

Further information

Remove devices by using factory reset or remove company data
https://docs.microsoft.com/en-us/intune/devices-wipe

Push-button reset
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/push-button-reset-overview

Add a script to push-button reset features
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-a-script-to-push-button-reset-features

 

Happy resetting!

 

Configure Delivery Optimization with Intune for Windows Update for Business

When using the Modern IT approach and building Microsoft 365 powered devices it is a combination of the following cloud services for Modern Management:

WUfB

To support the Windows as a Service strategy with cloud services we rely on the well known Windows Update service, but with the controls for business usage. This is called Windows Update for Business (WUfB). That means our content is provided by Microsoft Update servers and we define the installation behavior like deferrals or even pause of feature or quality updates. The WUfB settings can be configured in Intune via Software Udpates. This article will not show the details of the WUfB settings. To monitor the Delivery Optimization Performance we have the Delivery Optimization Status in the Windows Analytics solution – Update Compliance.

For successful servicing we need to make sure an internet break out with proper bandwidth capacity is available to support our devices. To prevent internet traffic congestion we can utilize Peer 2 Peer technologies like BranchCache and Delivery Optimization to optimize Windows 10 update delivery. In case of Windows Update for Business we need to focus on Delivery Optimization (DO).

You can use Delivery Optimization to reduce bandwidth consumption by sharing the work of downloading these packages among multiple devices in your deployment. Delivery Optimization can accomplish this because it is a self-organizing distributed cache that allows clients to download those packages from alternate sources (such as other peers on the network) in addition to the traditional Internet-based Windows Update servers.

How does Delivery Optimization work in detail?

First of all the published content must be chunked and hashed. Currently Microsoft supports the following content:

  • Windows Updates (Feature/Quality)
  • Drivers
  • Store Apps

The basic procedure is:

  1. Client A checks for Updates
  2. Client A gets download sources (MS content server and additional clients (peers) B, C, …
  3. Client A requests chunks from MS content server and peers B, C, …
  4. Client A verifies hashes of chunks and builds file from chunks
  5. Client A verifies complete file via hash

The clients will check-in to the Delivery Optimization cloud service as long as the content is valid in its cache. This is necessary to let DO service keep track of devices and let it distribute peer info to requesting clients.

The Delivery Optimization has multiple Download Modes and this is an important part for successful utilization of DO. It configures the logical grouping of devices based on certain criteria. In this example we set Download Mode to Group and we use a custom group ID. This custom Group ID can be delivered by DHCP as an Option ID with code 234 when using upcoming Windows 10 Version 1803.

Group download mode is the recommended option for most organizations looking to achieve the best bandwidth optimization with Delivery Optimization.

The custom group id delivered by DHCP for scoped devices will let us take control over the grouping. We can assign multiple DHCP scopes the same Group ID or different Group IDs. That’s how we build our device collections and control the peer 2 peer traffic even across NATs.

The DO Peer 2 Peer traffic is a direct TCP/UDP connection on port 7680.

DOFirewall

Now we can build effective groups aligned with our networking infrastructure to restrict P2P traffic to physical sites, multiple sites, subnets, what ever we want.

 

How to configure DO with Intune?

At time of this writing I’m using the Insider Preview for the upcoming Windows 10 Version 1803 to test and include settings which are really worth to mention in this context.

I won’t get into details about every available setting but I will show a complete setup to test DHCP Option ID as source for Group ID.

The custom group ID can be generated by PowerShell:

[guid]::NewGuid()

The custom OMA-URI to configure Download Mode to Group is:

Name: DODownloadMode
OMA-URI: ./Vendor/MSFT/Policy/Config/DeliveryOptimization/DODownloadMode
Data type: integer
Value: 2 (group)

With Windows 10 Version 1803 we can provide the Group ID as a DHCP Option ID with code 234. To configure the client to use DHCP option ID we need to configure the following OMA-URI:

Name: DOGroupIdSource
OMA-URI: ./Vendor/MSFT/Policy/Config/DeliveryOptimization/DOGroupIdSource
Data type: integer
Value: 3 (DHCP Option ID)

Now we need to configure our DHCP infrastructure to provide the DHCP Option ID to our clients. In my example I use a Microsoft DHCP Server:

1. Set Predefined Options

 

MSDHCPpredefinedOptions

2. Configure the Predefined Options

MSDHCPpredefinedoptionsAdd

3. Confirm with OK

MSDHCPGroupIdValue

4. Configure Scope Options

MSDHCPScopeOptions

5. Set Custom Group ID as Option ID 234

MSDHCPScopeOptionsGroupId

6. Verify new Scope Option 234 DOGroupID

MSDHCPGroupIdOptionInScope

This would be enough to let all clients in the same DHCP scope group together and allow P2P traffic.

When testing DO in Virtual Machines I encourage you to configure the following additional settings:

  • DOMinFileSizeToCache to 1 MB to ensure caching with even small downloads
  • DOMinRAMAllowedToPeer to 1 GB to let VMs with small amount of RAM P2P
  • DOPercentageMaxForegroundBandwidth to limit manual Store download Bandwith (this will not restrict peer traffic) *
  • DODelayForegroundDownloadFromHttp to 30 seconds to give time to find other peers *

* Windows 10 Version 1803 is needed

Custom OMA-URIs:

./Vendor/MSFT/Policy/Config/DeliveryOptimization/DOMinFileSizeToCache = 1 (Integer, in MB)

./Vendor/MSFT/Policy/Config/DeliveryOptimization/DOMinRAMAllowedToPeer = 1 (Integer, in GB)

./Vendor/MSFT/Policy/Config/DeliveryOptimization/DOPercentageMaxForegroundBandwidth = 10 (Integer, in %)

./Vendor/MSFT/Policy/Config/DeliveryOptimization/DODelayForegroundDownloadFromHttp = 30 (Integer, in Sec.)

A test environment configuration may look like this:

DOMDMSettings

For production environments please review all available MDM Delivery Optimization settings and adjust as needed for your environment. For example DOMaxCacheAge, DOMinBackgroundQoS, DOPercentageMaxBackgroundBandwidth , and DOMinBatteryPercentageAllowedToUpload might be from interest for production environments. Remember to check for new settings with every new Version of Windows 10!

 

Test to verify everything works as expected!

Make sure the settings are applied to the test devices. Generate a advanced diagnostic report:

Open Settings > Accounts > Access work or school > Connected to TenantName’s Azure AD > Info > scroll down to the bottom and click “Create report”

AdvancedDiagnosticsReport

Important settings to verify:

DOMDMReport

Test procedure:

On Client A start a download from the Store with 100MB+ download size and wait for finish. You should observe a throttled download when using VMs with setting DOPercentageMaxForeDownloadBandwidth.

On Client B start the same download from the Store and wait for finish. You should notice a significant faster download on Client B, as it will receive data from local peer without restrictions when tested with VMs and mentioned settings above.

Since Windows 10 Version 1803 we can generate a DO log file to trace the behavior:

Get-DeliveryOptimizationLog | ft -Wrap | Out-File -FilePath $env:temp\DOLogs.txt ; notepad $env:temp\DOLogs.txt

Get the log files from Client A and B and look for entry “Using groupID”, here you must find the DHCP Group ID in both logs:

DOLogFileGroupId

On Client B you will find stats regarding communication with Peer Client A on port 7680:

DOLogfilePeerUsage

If you like to test again you can use disk cleanup utility to clean the DO cache:

DODiskCleanup

Then uninstall the Store app and start the test over again.

 

Further information

 

Happy caching and a good P2P utilization!