Jump to content


anyweb

Root Admin
 View Profile  See their activity

  • Posts

    9,108

  • Joined

  • Last visited

  • Days Won

    363

 Content Type 

Posts posted by anyweb

  4. Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 3

    in Microsoft Intune

    Posted

    Introduction

    Note: This method is not officially supported by Microsoft. That said, this speeds up compliance and more importantly increases security as the device is already encrypted (part 1) before the user logs on (part 2). BitLocker recovery key changes after the user has completed enrolment are handled automatically (part 3).

    Note: I've updated the scripts 2023/12/23 to use new logging path and detection files instead of registry keys.

    Windows Autopilot preprovisioning (WhiteGlove) is the ability to pre-stage content and policies to devices while it's been installed in the factory. We had a challenge to speed up the overall compliance of Windows Autopilot devices and the obvious solution was to stage as much content as we could during pre-provisioning (WhiteGlove) but to also enable BitLocker encryption during that process, the only problem is that Microsoft don't officially support BitLocker encryption during the WhiteGlove scenario as the recovery key information is only uploaded after a user logs in. In our initial testing, Bitlocker disk encryption wouldn't even start until the user logged in.

    That is not so much of a problem for a small amount of content on the hard disc but what if you have hundreds of Gigabytes of data to encrypt which could potentially take hours to encrypt after the user has logged on. As BitLocker encryption is a common Compliance policy setting, this needed to be addressed.

    The challenge was to do the heavy lifting (pre-provisioning and encryption) during the WhiteGlove process and to only upload the key to Intune once the user actually enrolled the device. That need brought about this solution which is in 3 parts. The first part covers device encryption during provisioning at the factory. The second part uploads the recovery key to Intune after the user has signed in and completed WHFB setup and the final part moves those successfully encrypted devices to a WhiteGlove_Completed azure ad group targeted with BitLocker policy to take care of rotating recovery key info etc.

    All parts are listed below:

     

    Step 1. Create an Azure AD group

    In Microsoft Intune, create an assigned device group called WhiteGlove Completed. This group will dynamically fill with computers that have completed the upload of the BitLocker recovery info in Part 2 based on registry settings via a scheduled task.

    whiteglove completed object id.png

     

    Step 2. Add a function app

    In previous blog posts I showed you how to use http triggers via function apps to dynamically add devices to Azure AD groups, if you've already completed that then move to the next step otherwise follow the advice here. The code used for this trigger is pasted below.

    Make sure to modify the following three variables otherwise it won't do anything.

    • $ApplicationID             = "" # this is the id of the app you created in app registrations
    • $TenantDomainName = "" # your tenant name, eg: windowsnoob.com
    • $AccessSecret            = "" # this is the secret of the app you create in app registrations

      

    # Niall Brady 2023/03/05 (used by the WhiteGlove Completed, Check Compliance, Software Updates to devices and others...)
# Dynamically ADDS a device to an azure ad group 
# 

using namespace System.Net
# Input bindings are passed in via param block.
param($Request, $TriggerMetadata)

# Write to the Azure Functions log stream.
Write-Host "PowerShell HTTP trigger function processed a request."
# Interact with query parameters or the body of the request.
$deviceId = $Request.Query.deviceId
$GroupID = $Request.Query.GroupId

if (-not $deviceId) { 
$deviceId = $Request.Body.deviceId
}
if (-not $GroupId) { 
$GroupId = $Request.Body.GroupId
} 

# define the following variables
$ApplicationID =    "" # this is the id of the app you created in app registrations
$TenantDomainName = "" # your tenant name, eg: windowsnoob.com
$AccessSecret =     "" # this is the secret of the app you create in app registrations

# create the body
$Body = @{
Grant_Type = "client_credentials"
Scope = "https://graph.microsoft.com/.default"
client_Id = $ApplicationID
Client_Secret = $AccessSecret
}

# make initial connection to Graph
$ConnectGraph = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantDomainName/oauth2/v2.0/token" -Method POST -Body $Body
# get the token
$token = $ConnectGraph.access_token
$token

# to improve logging...
$triggerName = "add_device_to_aad_group"
$a = Get-Date
$body = " `n"
$body = $body + "$a Starting the '$triggerName' function...`n"
$body = $body + "$a Connected to tenant: $TenantDomainName.`n"

#START $FindDevice
if ($deviceId -and $GroupId) {
	$Group = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/groups?`$filter=Id eq '$GroupId'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value
	$GroupName = $Group.displayName
	$body = $body + "$a You supplied deviceId: '$deviceId'" + ".`n" 
	$body = $body + "$a You supplied groupId: '$GroupId'" + ".`n"    
	$body = $body + "$a Group.displayName: '$GroupName'" + ".`n"
    
	#$GroupMembers =  Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/groups/$GroupID/members?$filter " -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value
	# | Select-Object -ExpandProperty Value
    
    # below fixes the 100 members per returned result in AAD problem
    $GroupMembers2 = Invoke-RestMethod -Method GET -uri "https://graph.microsoft.com/v1.0/groups/$GroupID/members?`$count=true&`$filter=startswith(deviceid,'$deviceId')" -Headers @{Authorization = "Bearer $token";"ConsistencyLevel" = "eventual"}
	
	# if found do this
	if ($GroupMembers2.value.deviceId){
		#$body = $body + "--------------------------------------------------------------------`n"
        #$body = $body + "This device was found in the AAD group so no need to add it again...`n"
		#$body = $body + "deviceId: " + $GroupMembers2.value.deviceId + "`n"
        #$body = $body + "displayName: " + $GroupMembers2.value.displayName + "`n"
		#$body = $body + "--------------------------------------------------------------------`n"
		Write-Host -ForegroundColor Yellow "$GroupMembers2.value.displayName is in the group" 
		$body = $body + "$a Device: " + $GroupMembers2.value.displayName + " is already in the " + $GroupName + " group, nothing to do.`n"
		$body = $body + "$a The computer is already in the group, nothing to do.`n"
		$Status = "Already present in group"
	}
	else	{
        $AddDevice = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/devices?`$filter=deviceId eq '$deviceId'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value | %{ 
        Write-Host -ForegroundColor Green "Adding $($_.DisplayName) ($($_.ID)) to the group"
        $body = $body +  "$a Adding $($_.DisplayName) ($($_.ID)) to the group with ObjectID $GroupID.`n"
        $ComputerName = $($_.DisplayName) 
        $Status = "ADDED"
        $BodyContent = @{
            "@odata.id"="https://graph.microsoft.com/v1.0/devices/$($_.id)"
        } | ConvertTo-Json
            # code to add it here...
            # the $ref variable is explained here... kinda # https://docs.microsoft.com/en-us/graph/api/group-post-members?view=graph-rest-1.0&tabs=http
            try {Invoke-RestMethod -Method POST -uri "https://graph.microsoft.com/v1.0/groups/$GroupID/members/`$ref" -Headers @{Authorization = "Bearer $token"; 'Content-Type' = 'application/json'} -Body $BodyContent
            # pause some seconds to allow time for the object to be populated if recently added...
            sleep 30
            }
            catch { $body = $body + "$a ERROR ADDING THE DEVICE`n"
                    $body = $body + "Here is the error message: '$_.ErrorMessage'"
                    $Status = "ERROR ADDING THE DEVICE"
                    }
	}
    }

}
#END $FindDevice

$a = Get-Date
$body = $body + "$a Exiting Azure function."
# Associate values to output bindings by calling 'Push-OutputBinding'.
Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
StatusCode = [HttpStatusCode]::OK
Body = $body
})

    Once done and tested, copy the functions URL in the function app

    get function url.png

    Step 3. Download the scripts

    Next, download the attached 7 ZIP file, use 7-Zip to decompress.

    Note: Only logged on members of windows-noob.com can download this file.

     

    WhiteGlove - Add device to aad group.7z

    Step 4. Modify the scripts

    Modify the AddWhiteGloveDeviceToAzureAdGroup.ps1 script and configure the Object ID (of the WhiteGlove Completed group) and the URL of the http trigger for adding devices to an azure ad group. That is lines 142 and 143 in the screenshot below:

    groupid and graph function url.png

     

    Once done with your changes, you'll need to encode the files to a base64 text file. To do that, modify the path of where you are running the encode script, then run it in PowerShell ISE.

     

    encode path.png

    This will leave you with 2 new encoded scripts, shown below

    encoded scripts.png

    Open each of the respective encoded text files in notepad and mark all text within (CTRL+A) then COPY the text (CTRL+C),

    copy the text.png

    Then paste that copied text into the respective variables in the Win.AP.CreateScheduledTask_AddWhiteGloveDeviceToAzureAdGroup.ps1 script in lines 165 and 170.

    paste in the encoded scripts.png

    save your changes, to the Win.AP.CreateScheduledTask_AddWhiteGloveDeviceToAzureAdGroup.ps1 script

     

    Step 5. Add the Win32 app

    Next, using the latest version of the IntuneWinappUtil.exe app, create a Win32 app. Configure the app settings as follows:

    Name: Win.AP.CreateScheduledTask_AddWhiteGloveDeviceToAzureAdGroup
    Program Install command:  install.Win.AP.CreateScheduledTask_AddWhiteGloveDeviceToAzureAdGroup.cmd
    Program uninstall command: install.Win.AP.CreateScheduledTask_AddWhiteGloveDeviceToAzureAdGroup.cmd
    Install behavior: System
    Device restart behavior: No specific action
    Return codes:
    0 Success
    1707 Success
    3010 Soft reboot
    1641 Hard reboot
    1618 Retry

    Requirements

    Operating system architecture x64
    Minimum operating system Windows 10 1903
    Disk space required (MB) No Disk space required (MB)
    Physical memory required (MB) No Physical memory required (MB)
    Minimum number of logical processors required No Minimum number of logical processors required
    Minimum CPU speed required (MHz) No Minimum CPU speed required (MHz)
    Additional requirement rules
    File C:\ProgramData\windowsnoob\WhiteGlove\KeyUploadedAfterWhiteGlove.txt

    as per the screenshot below:

     

    requirements.png

    Detection rules

    Rules format: Manually configure detection rules

    Detection rules File: C:\ProgramData\windowsnoob\WhiteGlove

    File or folder: Installed_WhiteGlove_Add_device_to_aad_group.txt

    Detection method: File or folder exists

    detection rules.png

     

    finally, assign the Win32 app as Required to our WhiteGlove Computers Azure ad group created in part 1.

    configure required assignment to whitelove computers.png

     

    Step 6. Duplicate your Endpoint Protection BitLocker Policy

    Locate your existing Endpoint Protection Bitlocker Policy (which you excluded from the WhiteGlove Computers azure ad group in part 1). Copy the settings to a new BitLocker Policy and assign this new policy to the WhiteGlove Completed azure ad group.

    duplicated endpoint protection bitlocker policy.png

    Step 7. Enroll a new device and verify Bitlocker recovery

    Now you've completed all the parts necessary to verify the overall solution in action.

    To do that preprovision a WhiteGlove computer, get a user to enroll it, and after it's all complete the device will get magically added to the WhiteGlove Completed Azure AD group via the Win32 app in this part.

    device added.png

     

    It will then get the BitLocker policy that we targeted to that group.

    To verify everything is working, take note of the BitLocker recovery info on the device...

    before rotation.png

    Verify it's the same in Intune

    recovery key before rotation.png

    and next, trigger a BitLocker key rotation action in Intune

    bitlocker key rotation.png

    You can then confirm on the device that it's rotated

    after rotation.png

    and the new recovery key information is stored in Azure.

    key rotated.png

    Job done !

    Troubleshooting

    This Win32App creates some files which are extracted to C:\ProgramData\windowsnoob\WhiteGlove.

    Review the log files for the generation of the Scheduled Task. Below is a reference log file, use it to compare to your attempts.

      

    03/05/2023 05:03:39 Starting the 'AddWhiteGloveDeviceToAzureAdGroup' version: '0.1' script...
03/05/2023 05:03:39 Checking if registry path registrypath: 'HKLM:\SOFTWARE\windows-noob\WhiteGlove\' exists...
03/05/2023 05:03:39 registrypath exists...
03/05/2023 05:03:39 found 'KeyUploadedAfterWhiteGlove', will now add the device to the azure ad group...
03/05/2023 05:03:39 Starting the AddDeviceToAzureAdGroup Function...
03/05/2023 05:03:40 Using the following deviceId: 4a6f1a9a-46d0-4fd1-8b4b-f158e01fda2c
03/05/2023 05:03:40 Using the following URL: https://graph-functions-function-app.azurewebsites.net/api/add_device_to_aad_group?code=<SNIPPED>==&deviceId=4a6f1a9a-46d0-4fd1-8b4b-f158e01fda2c&GroupId=43e106bc-b8ce-4f1c-97bb-f9c21fcbc8cf
03/05/2023 05:03:40 Making the query...
03/05/2023 05:04:13 The query returned:  
03/05/2023 13:03:42 Starting the 'add_device_to_aad_group' function...
03/05/2023 13:03:42 Connected to tenant: windowsnoob.com.
03/05/2023 13:03:42 You supplied deviceId: '4a6f1a9a-46d0-4fd1-8b4b-f158e01fda2c'.
03/05/2023 13:03:42 You supplied groupId: '43e106bc-b8ce-4f1c-97bb-f9c21fcbc8cf'.
03/05/2023 13:03:42 Group.displayName: 'WhiteGlove Completed'.
03/05/2023 13:03:42 Adding AP-5CG03729P0 (aa1278ab-03d5-49f6-868e-5c8e7d2f415d) to the group with ObjectID 43e106bc-b8ce-4f1c-97bb-f9c21fcbc8cf.
03/05/2023 13:04:13 Exiting Azure function.
03/05/2023 05:04:13 Group name identified as: 'WhiteGlove Completed'
03/05/2023 05:04:13 The computer is not confirmed in the group yet, will retry...
03/05/2023 05:04:29 The query returned:  
03/05/2023 13:04:28 Starting the 'add_device_to_aad_group' function...
03/05/2023 13:04:28 Connected to tenant: windowsnoob.com.
03/05/2023 13:04:28 You supplied deviceId: '4a6f1a9a-46d0-4fd1-8b4b-f158e01fda2c'.
03/05/2023 13:04:28 You supplied groupId: '43e106bc-b8ce-4f1c-97bb-f9c21fcbc8cf'.
03/05/2023 13:04:28 Group.displayName: 'WhiteGlove Completed'.
03/05/2023 13:04:28 Device: AP-5CG03729P0 is already in the WhiteGlove Completed group, nothing to do.
03/05/2023 13:04:28 The computer is already in the group, nothing to do.
03/05/2023 13:04:29 Exiting Azure function.
03/05/2023 05:04:29 Group name identified as: 'WhiteGlove Completed'
03/05/2023 05:04:29 The computer was confirmed as added to the group.
03/05/2023 05:04:29 Removing the scheduled task...
03/05/2023 05:04:29 About to delete scheduled task: AddWhiteGloveDeviceToAzureAdGroup
03/05/2023 05:04:31 Succeeded to remove scheduled task: AddWhiteGloveDeviceToAzureAdGroup
03/05/2023 05:04:31 Exiting script.

    and the scheduled task creation log file 

    03/05/2023 05:02:34 Starting the 'Win.AP.CreateScheduledTask_AddWhiteGloveDeviceToAzureAdGroup' version '0.01' script...
03/05/2023 05:02:34 Checking if computer was enrolled within the allowed timeframe...
03/05/2023 05:02:34 Current date/time = 03/05/2023 05:02:34, computer install date/time = 03/05/2023 12:45:48
03/05/2023 05:02:34 Enroll date [03/05/2023 12:45:48] created within the allowed timeframe...
03/05/2023 05:02:34 Hours since enrollment: -7.72057391491667
03/05/2023 05:02:34 EnrollmentDateCheck detected as: True
03/05/2023 05:02:34  Logged on user is: AzureAD\NiallBrady
03/05/2023 05:02:34 extracting scripts to 'C:\ProgramData\windowsnoob\WhiteGlove'...
03/05/2023 05:02:34 decoding BASE64 encoded file...AddWhiteGloveDeviceToAzureAdGroup.ps1
03/05/2023 05:02:34 decoding BASE64 encoded file...AddWhiteGloveDeviceToAzureAdGroup.vbs
03/05/2023 05:02:34 Creating windows-noob foldername...
03/05/2023 05:02:34 Creating scheduled task...
03/05/2023 05:02:36 Info: The scheduled task doesn't exist, will create it.
03/05/2023 05:02:36 DEBUG: Using the following values for the scheduled task...
03/05/2023 05:02:36 DEBUG: Time: 03/04/2023 05:03:36 Script: C:\ProgramData\windowsnoob\WhiteGlove\AddWhiteGloveDeviceToAzureAdGroup.vbs Action: MSFT_TaskExecAction Trigger: MSFT_TaskTimeTrigger Settings: MSFT_TaskSettings3 Principal: MSFT_TaskPrincipal2 Foldername: windows-noob.
03/05/2023 05:02:37 DEBUG: task=MSFT_ScheduledTask (TaskName = "AddWhiteGloveDeviceToAzureAdGroup", TaskPath = "\windows-noob\") taskName=AddWhiteGloveDeviceToAzureAdGroup run=03/05/2023 05:03:36
03/05/2023 05:02:37 DEBUG: settings the scheduled task settings=MSFT_ScheduledTask (TaskName = "AddWhiteGloveDeviceToAzureAdGroup", TaskPath = "\windows-noob\")
03/05/2023 05:02:37 Exiting script.

    That's it for this mini series, see you in the next one !

    cheers

    niall

  5. Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 2

    in Microsoft Intune

    Posted

    Introduction

    Note: This method is not officially supported by Microsoft. That said, this speeds up compliance and more importantly increases security as the device is already encrypted (part 1) before the user logs on (part 2). BitLocker recovery key changes after the user has completed enrolment are handled automatically (part 3).

    Note: I've updated the scripts 2023/12/23 to use new logging path and detection files instead of registry keys.

    Windows Autopilot preprovisioning (WhiteGlove) is the ability to pre-stage content and policies to devices while it's been installed in the factory. We had a challenge to speed up the overall compliance of Windows Autopilot devices and the obvious solution was to stage as much content as we could during pre-provisioning (WhiteGlove) but to also enable BitLocker encryption during that process, the only problem is that Microsoft don't officially support BitLocker encryption during the WhiteGlove scenario as the recovery key information is only uploaded after a user logs in. In our initial testing, Bitlocker disk encryption wouldn't even start until the user logged in.

    That is not so much of a problem for a small amount of content on the hard disc but what if you have hundreds of Gigabytes of data to encrypt which could potentially take hours to encrypt after the user has logged on. As BitLocker encryption is a common Compliance policy setting, this needed to be addressed.

    The challenge was to do the heavy lifting (pre-provisioning and encryption) during the WhiteGlove process and to only upload the key to Intune once the user actually enrolled the device. That need brought about this solution which is in 3 parts. The first part covers device encryption during provisioning at the factory. The second part uploads the recovery key to Intune after the user has signed in and completed WHFB setup and the final part moves those successfully encrypted devices to a WhiteGlove_Completed azure ad group targeted with BitLocker policy to take care of rotating recovery key info etc.

    All parts are listed below:

    The Win32 app in this part actually does a few things namely:

    • creates a scheduled task which is triggered on an event id
    • extracts a second script which does the following
      • removes the BEK protector
      • adds a numerical password protector
      • uploads the recovery information to Intune
      • *if the above is successful*
        • removes the users local admin permissions
        • adds a runonce regkey for the next login
        • adds a reg key to show that all is completed
        • deletes the scheduled task
        • restart the computer to speed up BitLocker compliance with a 5 second warning

    Step 1. Add the Win32 app

    Using the latest version of the IntuneWinappUtil.exe app, create a Win32 app called Win.AP.CreateScheduledTask_Win.AP.WhiteGlove.UploadBitLockerKeyToIntune. The app is in the attached 7 ZIP file, use 7-Zip to decompress.

    Note: Only logged on members of windows-noob.com can download this file.

    WhiteGlove - Upload bitlocker key after user login.7z

    Configure the app settings as follows:

    Name: Win.AP.CreateScheduledTask_Win.AP.WhiteGlove.UploadBitLockerKeyToIntune
    Program Install command:  install.Win.AP.CreateScheduledTask_Win.AP.WhiteGlove.UploadBitLockerKeyToIntune.cmd
    Program uninstall command: install.Win.AP.CreateScheduledTask_Win.AP.WhiteGlove.UploadBitLockerKeyToIntune.cmd
    Install behavior: System
    Device restart behavior: No specific action
    Return codes:
    0 Success
    1707 Success
    3010 Soft reboot
    1641 Hard reboot
    1618 Retry

    Requirements

    Operating system architecture
    x64
    Minimum operating system
    Windows 10 1903
    Disk space required (MB)
    No Disk space required (MB)
    Physical memory required (MB)
    No Physical memory required (MB)
    Minimum number of logical processors required
    No Minimum number of logical processors required
    Minimum CPU speed required (MHz)
    No Minimum CPU speed required (MHz)
    Additional requirement rules
    File C:\ProgramData\windowsnoob\WhiteGlove

     

    as per the screenshot below:

     

    requirements.png

    Detection rules

    Rules format: Manually configure detection rules

    Detection rules File: C:\ProgramData\windowsnoob\WhiteGlove

    File or folder: Installed_WhiteGlove_Bitlocker_key_uploader.txt

    Detection method: File or folder exists

    detection rule.png

     

    Next, configure the following Dependencies for the Win32 app

    dependencies.png

    finally, assign the Win32 app as Required to our WhiteGlove Computers Azure ad group created in part 1.

    assignments.png

     

    Step 2. Enroll a provisioned device

    Now that you've completed parts 1 and 2, you are ready to review what happens with the new Win32 app. After the user logs on, the ESP does it's thing and starts Account Setup, during this phased the Windows Hello For Business (WHFB) setup starts. Once completed the end user will see something like this.

    whfb completed.png

     

    This generates an EventID (Microsoft-Windows-User Device Registration/Admin">*[System[(EventID=300))

    user device registration.png

    and that event ID triggers our scheduled task to run the associated win.ap.upload.bitlocker.key.after.whiteglove.vbs script which in turn launches the powershell script of the same name.

    That script does all the points mentioned above and then restarts the computer within 5 seconds to enforce compliance quickly.

    shutdown message.PNG

    Troubleshooting

    This Win32App creates some files which are extracted to C:\ProgramData\windowsnoob\WhiteGlove.

    Review the log files for the generation of the Scheduled Task. Below is a reference log file, use it to compare to your attempts. 

    02/27/2023 04:49:16 Starting the 'Win.AP.CreateScheduledTask_win.ap.upload.bitlocker.key.after.whiteglove' version '0.16' script...
02/27/2023 04:49:16 Starting initial checks to determine if we should exit from the script if not...
02/27/2023 04:49:16 Logged on user method#1 detected as: 'AP-5CG03729P0\defaultuser0'
02/27/2023 04:49:16 Logged on user method#2 detected as: 'AP-5CG03729P0$'
02/27/2023 04:49:16 Looking for the following Regpath: 'HKLM:\Software\WOW6432Node\windows-noob\WhiteGlove\'...
02/27/2023 04:49:16 testing reg key
02/27/2023 04:49:16 returning true to reg key check
02/27/2023 04:49:16 The required WhiteGlove registry key was found, continuing script
02/27/2023 04:49:16 Found: 'EncryptedDuringWhiteGlove'
02/27/2023 04:49:16  Logged on user is: AP-5CG03729P0\defaultuser0
02/27/2023 04:49:16 extracting scripts to 'C:\ProgramData\windowsnoob\WhiteGlove'...
02/27/2023 04:49:16 decoding BASE64 encoded file...win.ap.upload.bitlocker.key.after.whiteglove.ps1
02/27/2023 04:49:16 decoding BASE64 encoded file...win.ap.upload.bitlocker.key.after.whiteglove.vbs
02/27/2023 04:49:16 Creating windows-noob foldername...
02/27/2023 04:49:16 Creating scheduled task...
02/27/2023 04:49:18 Info: The scheduled task doesn't exist, will create it.
02/27/2023 04:49:18 DEBUG: Using the following values for the scheduled task:
02/27/2023 04:49:18 DEBUG: User: 'AP-5CG03729P0\defaultuser0' Time: '' Script: 'C:\ProgramData\windowsnoob\WhiteGlove\win.ap.upload.bitlocker.key.after.whiteglove.vbs' Action: 'MSFT_TaskExecAction' Trigger: 'MSFT_TaskLogonTrigger' Settings: 'MSFT_TaskSettings3' Principal: 'MSFT_TaskPrincipal2' Foldername: 'windows-noob'.
02/27/2023 04:49:18 about to create the scheduled task...
02/27/2023 04:49:18 Succeeded in creating the scheduled task
02/27/2023 04:49:19 DEBUG: task=MSFT_ScheduledTask (TaskName = "Win.AP.WhiteGlove.UploadBitLockerKeyToI..., TaskPath = "\windows-noob\") taskName=Win.AP.WhiteGlove.UploadBitLockerKeyToIntune run=02/27/2023 04:50:18
02/27/2023 04:49:19 DEBUG: settings the scheduled task settings=MSFT_ScheduledTask (TaskName = "Win.AP.WhiteGlove.UploadBitLockerKeyToI..., TaskPath = "\windows-noob\")
02/27/2023 04:49:19 Exiting script.

    Below is the log file from the which uploads the key 

    02/27/2023 04:51:48 Starting script: 'win.ap.upload.bitlocker.key.after.whiteglove' version: '0.14'...
02/27/2023 04:51:48 Checking logged on user to determine if we are still in the ESP or not.
02/27/2023 04:51:49 Not in ESP, will continue!
02/27/2023 04:51:49 Removing BEK...
02/27/2023 04:51:49 removing BEK protector
02/27/2023 04:51:51 DEBUG: BLV = 'C:'
02/27/2023 04:51:51 attempting to remove protector...
02/27/2023 04:51:52 succeeded removing protector!
02/27/2023 04:51:52 DEBUG: BLV = 'C:'
02/27/2023 04:51:52 Adding RK...
02/27/2023 04:51:52 adding recovery password...
02/27/2023 04:51:53 succeeded adding protector !
02/27/2023 04:51:53
02/27/2023 04:51:53 about to upload key to Azure
02/27/2023 04:51:55 succeeded to upload the BitLocker recovery key to Azure !
02/27/2023 04:51:55 removing user 'AzureAD\NiallBrady' from Local Admins group
02/27/2023 04:51:55 succeeded to remove the user from the group
02/27/2023 04:51:55 about to remove the Scheduled task
02/27/2023 04:52:00 Info: The 'Win.AP.WhiteGlove.UploadBitLockerKeyToIntune' scheduled task exists, removing the scheduled task...
02/27/2023 04:52:00 About to delete scheduled task: Win.AP.WhiteGlove.UploadBitLockerKeyToIntune
02/27/2023 04:52:01 Succeeded to remove scheduled task: Win.AP.WhiteGlove.UploadBitLockerKeyToIntune
02/27/2023 04:52:01 succeeded removing the 'Win.AP.WhiteGlove.UploadBitLockerKeyToIntune' scheduled task !
02/27/2023 04:52:01 adding reg key to confirm key upload status
02/27/2023 04:52:01 Creating a RunOnce reg key to trigger intune sync
02/27/2023 04:52:01 succeeded to create the RunOnce registry key
02/27/2023 04:52:01 doing a mandatory shutdown/restart...
02/27/2023 04:52:01 succeeded to issue the shutdown command, will restart in 5 seconds!
02/27/2023 04:52:01 script completed...

    That's it !

    checking on the computer which was just enrolled we can determine the Protectors using 

    manage-bde -protectors -get c:

    confirm recovery info.png

     

    Checking in Intune we can see the key is uploaded, job done i'd say !

    show recovery key.png

     

    Please join me in part 3 where we'll look at adding our successfully enrolled WhiteGlove computers into an Azure AD group to target them with additional policies (such as BitLocker) so that when the BitLocker recovery key is revealed in Intune or on the device, that the policy will rotate the key and upload it to Intune

    Recommended reading

     

     

    WhiteGlove - Upload bitlocker key after user login.7z

  7. Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 1

    in Microsoft Intune

    Posted

    Introduction

    Note: This method is not officially supported by Microsoft. That said, this speeds up compliance and more importantly increases security as the device is already encrypted (part 1) before the user logs on (part 2). BitLocker recovery key changes after the user has completed enrolment are handled automatically (part 3).

    Note: I've updated the scripts 2023/12/23 to use new logging path and detection files instead of registry keys.

    Windows Autopilot preprovisioning (WhiteGlove) is the ability to preprovision content and policies to devices while they are installed in the factory.

    We had a challenge to speed up the overall compliance of Windows Autopilot devices and the obvious solution was to stage as much content as we could during preprovisioning (WhiteGlove) but to also enable BitLocker encryption during that process, the only problem is that Microsoft don't officially support BitLocker encryption during the WhiteGlove scenario as the recovery key information is only uploaded after a user logs in. In our initial testing, Bitlocker disk encryption wouldn't even start until the user logged in.

    That is not so much of a problem for a small amount of content on the hard disc but what if you have hundreds of Gigabytes of data to encrypt which could potentially take hours to encrypt after the user has logged on. As BitLocker encryption is a common Compliance policy setting, this needed to be addressed.

    The challenge was to do the heavy lifting (pre-provisioning and encryption) during the WhiteGlove process and to only upload the key to Intune once the user actually enrolled the device. That need brought about this solution which is in 3 parts. The first part covers device encryption during provisioning at the factory. The second part uploads the recovery key to Intune after the user has signed in and completed WHFB setup and the final part moves those successfully encrypted devices to a WhiteGlove_Completed azure ad group targeted with BitLocker policy to take care of rotating recovery key info etc.

    All parts are listed below:

     

    Step 1. Create an Azure AD group

    In Microsoft Intune, create a dynamic device group called WhiteGlove Computers with a query for a WhiteGlove Group Tag. This group will dynamically fill with computers that have the correct Group Tag assigned to them.

    create azure ad group with grouptag.png

    Below is the query used: 

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

    Step 2. Exclude BitLocker configuration profiles from this group

    Locate any existing BitLocker configuration profiles in your tenant and exclude then from this group otherwise they will cause the solution to fail.

    exclude bitlocker policy.png

    Step 3. Allow Pre-provisioned deployment

    Next, locate your Windows Autopilot Deployment Profiles and enable the WhiteGlove ability by turning on the Allow Pre-provisioned deployment setting. Deploy the profile to the group created in Step 1. This profile must also enable a User Account Type of Local Admin. Don't panic, we'll be removing this local admin ability later on in the solution before the end user can cause trouble.

    In the example below you can see a Windows Autopilot deployment profile called Intune: Local admin

    Windows Autopilot Deployment Profile settings.png

     


    Step 4. Exclude standard user deployment profiles

    If you have any additional Deployment Profiles for Standard Users, make sure to exclude this group from those profiles otherwise they won't get the right settings needed for the second part of this solution.

    exclude standard user deployment profiles.png

     

    Step 5. Configure a WhiteGlove ESP

    Configure at least one Enrollment Status Page (ESP) targeted to your WhiteGlove Computers Azure AD group

    WhiteGlove ESP.png

    Step 6. Add a Win32 App

    Next, using the latest version of the IntuneWinappUtil.exe app, create a Win32 app called Enable Bitlocker during Windows Autopilot WhiteGlove. This app will enable Bitlocker during WhiteGlove at the factory. The app is in the attached 7 ZIP file, use 7-Zip to uncompress.

    Note: Only logged on members of windows-noob.com can download this file.

    WhiteGlove - Enable BitLocker During WhiteGlove preprovisioning.7z

     

    Configure the app settings as follows:

    Name: Enable Bitlocker during Windows Autopilot WhiteGlove
    Program Install command: install.win.ap.enable.bitlocker.during.whiteglove.cmd
    Program uninstall command: install.win.ap.enable.bitlocker.during.whiteglove.cmd
    Install behavior: System
    Device restart behavior: No specific action
    Return codes:
    0 Success
    1707 Success
    3010 Soft reboot
    1641 Hard reboot
    1618 Retry

    Requirements:

    Operating system architecture: x64
    Minimum operating system Windows 10 1903

    Detection rules:

    Rules format Manually configure detection rules

    Detection rules File

    Path: C:\ProgramData\windowsnoob\WhiteGlove

    File or folder: EncryptedDuringWhiteGlove.txt

    Detection method: File or folder exists

    detection rule.PNG

    Next, assign the app as required to your WhiteGlove Computers AAD group

    assignments.png


    Step 7. Add the Group tag to a test device

    In this step either import a new CSV of a Windows Autopilot device (or use an existing device) to test this on, and then add the WhiteGlove GroupTag to that Windows Autopilot device.

    whiteglove group tag.png

    Step 8. Provision the device

    The staging of content and policies to the device normally will take place at the factory (OEM) or IT Admin staging area. At the first screen of OOBE (shown below)

    oobe first screen.png

    The technician needs to press the Windows key 5 times to start provisioning mode.

    Next, Select Windows Autopilot provisioning from the list and click Continue.

    Windows Autopilot Provisioning.png

    If everything went well it will download the correct Windows Autopilot deployment profile and display it (Intune: Local admin)

    correct ESP loaded.png

    Click Provision to start the staging process.

    Once the ESP installs the Win32 app, it will begin encrypting the drive. You can reveal this with the following command: 

    manage-bde -status

    The next screenshots are from real hardware.

    IMG_7002.JPG

    and once all apps and policies are installed completely and successfully the drive is fully encrypted and the protectors are stored in the TPM along with a BEK key stored on the SYSTEM partition temporarily.

    encryption 100 percent completed.png

    At this point the technician can click on Reseal to seal the device for user enrollment (Part 2).

    reseal.png

    That 's it for this part, please join me in Part 2 where we'll add the next Win32 app which will do a bunch of actions including:

    • create a scheduled task to run a script when WHFB setup is completed
    • remove BEK protector
    • add numerical password protector
    • upload the key to Intune
    • restart the computer with a shutdown message to the end user

    Troubleshooting

    The Win32 app used in this part logs to C:\ProgramData\windowsnoob\WhiteGlove\win.ap.enable.bitlocker.during.whiteglove.log

    The contents of which are shown below from a working WhiteGlove deployment, please use this as a reference to compare your log file. 

    02/27/2023 04:33:46 Starting script: 'win.ap.enable.bitlocker.during.whiteglove' version: '0.11'...
02/27/2023 04:33:46 checking the current bitlocker encryption status
02/27/2023 04:33:47 Current Bitlocker Status: FullyDecrypted, None
02/27/2023 04:33:47 Fully decrypted, no need to decrypt
02/27/2023 04:33:47 starting TPM section
02/27/2023 04:33:48 TPM chip is currently owned, will not attempt to take ownership
02/27/2023 04:33:48 attempting to assign drive letter to the SYSTEM partition
02/27/2023 04:33:51 starting BitLocker Encryption section
02/27/2023 04:33:51 adding reg keys for BitLocker encryption settings
02/27/2023 04:33:51 succeeded adding the reg key
02/27/2023 04:33:51 adding AES-XTS256 reg key for BitLocker encryption settings
02/27/2023 04:33:51 succeeded adding the reg key
02/27/2023 04:33:51 Enabling BitLocker, TPM Protector and Recovery Password Protector
02/27/2023 04:34:10 enabling bitlocker worked YAY!!!!
02/27/2023 04:34:16 Current BL Status: C:, EncryptionInProgress, XtsAes256,Tpm ExternalKey
02/27/2023 04:34:16 Percentage Encrypted: '96'%.
02/27/2023 04:34:16 Percentage Encrypted: '96'%.
02/27/2023 04:34:16 Percentage Encrypted: '96'%.
02/27/2023 04:34:17 Percentage Encrypted: '96'%.
02/27/2023 04:34:17 Percentage Encrypted: '96'%.
02/27/2023 04:34:17 Percentage Encrypted: '96'%.
02/27/2023 04:34:17 Percentage Encrypted: '96'%.
02/27/2023 04:34:18 Percentage Encrypted: '96'%.
02/27/2023 04:34:18 Percentage Encrypted: '96'%.
02/27/2023 04:34:18 Percentage Encrypted: '96'%.
02/27/2023 04:34:18 Percentage Encrypted: '96'%.
02/27/2023 04:34:18 Percentage Encrypted: '96'%.
02/27/2023 04:34:19 Percentage Encrypted: '96'%.
02/27/2023 04:34:19 Percentage Encrypted: '96'%.
02/27/2023 04:34:19 Percentage Encrypted: '97'%.
02/27/2023 04:34:19 Percentage Encrypted: '97'%.
02/27/2023 04:34:19 Percentage Encrypted: '97'%.
02/27/2023 04:34:20 Percentage Encrypted: '97'%.
02/27/2023 04:34:20 Percentage Encrypted: '97'%.
02/27/2023 04:34:20 Percentage Encrypted: '97'%.
02/27/2023 04:34:20 Percentage Encrypted: '97'%.
02/27/2023 04:34:21 Percentage Encrypted: '97'%.
02/27/2023 04:34:21 Percentage Encrypted: '97'%.
02/27/2023 04:34:21 Percentage Encrypted: '97'%.
02/27/2023 04:34:21 Percentage Encrypted: '97'%.
02/27/2023 04:34:21 Percentage Encrypted: '97'%.
02/27/2023 04:34:22 Percentage Encrypted: '97'%.
02/27/2023 04:34:22 Percentage Encrypted: '97'%.
02/27/2023 04:34:22 Percentage Encrypted: '97'%.
02/27/2023 04:34:22 Percentage Encrypted: '97'%.
02/27/2023 04:34:22 Percentage Encrypted: '97'%.
02/27/2023 04:34:23 Percentage Encrypted: '97'%.
02/27/2023 04:34:23 Percentage Encrypted: '97'%.
02/27/2023 04:34:23 Percentage Encrypted: '97'%.
02/27/2023 04:34:23 Percentage Encrypted: '97'%.
02/27/2023 04:34:24 Percentage Encrypted: '97'%.
02/27/2023 04:34:24 Percentage Encrypted: '97'%.
02/27/2023 04:34:24 Percentage Encrypted: '97'%.
02/27/2023 04:34:24 Percentage Encrypted: '97'%.
02/27/2023 04:34:24 Percentage Encrypted: '97'%.
02/27/2023 04:34:25 Percentage Encrypted: '97'%.
02/27/2023 04:34:25 Percentage Encrypted: '97'%.
02/27/2023 04:34:25 Percentage Encrypted: '97'%.
02/27/2023 04:34:25 Percentage Encrypted: '97'%.
02/27/2023 04:34:26 Percentage Encrypted: '97'%.
02/27/2023 04:34:26 Percentage Encrypted: '97'%.
02/27/2023 04:34:26 Percentage Encrypted: '97'%.
02/27/2023 04:34:26 Percentage Encrypted: '97'%.
02/27/2023 04:34:26 Percentage Encrypted: '97'%.
02/27/2023 04:34:27 Percentage Encrypted: '97'%.
02/27/2023 04:34:27 Percentage Encrypted: '97'%.
02/27/2023 04:34:27 Percentage Encrypted: '97'%.
02/27/2023 04:34:27 Percentage Encrypted: '97'%.
02/27/2023 04:34:28 Percentage Encrypted: '97'%.
02/27/2023 04:34:28 Percentage Encrypted: '97'%.
02/27/2023 04:34:28 Percentage Encrypted: '97'%.
02/27/2023 04:34:28 Percentage Encrypted: '97'%.
02/27/2023 04:34:29 Percentage Encrypted: '97'%.
02/27/2023 04:34:29 Percentage Encrypted: '97'%.
02/27/2023 04:34:29 Percentage Encrypted: '97'%.
02/27/2023 04:34:29 Percentage Encrypted: '97'%.
02/27/2023 04:34:29 Percentage Encrypted: '97'%.
02/27/2023 04:34:30 Percentage Encrypted: '97'%.
02/27/2023 04:34:30 Percentage Encrypted: '97'%.
02/27/2023 04:34:30 Percentage Encrypted: '98'%.
02/27/2023 04:34:30 Percentage Encrypted: '98'%.
02/27/2023 04:34:31 Percentage Encrypted: '98'%.
02/27/2023 04:34:31 Percentage Encrypted: '98'%.
02/27/2023 04:34:31 Percentage Encrypted: '98'%.
02/27/2023 04:34:31 Percentage Encrypted: '98'%.
02/27/2023 04:34:31 Percentage Encrypted: '98'%.
02/27/2023 04:34:32 Percentage Encrypted: '98'%.
02/27/2023 04:34:32 Percentage Encrypted: '98'%.
02/27/2023 04:34:32 Percentage Encrypted: '98'%.
02/27/2023 04:34:32 Percentage Encrypted: '98'%.
02/27/2023 04:34:33 Percentage Encrypted: '98'%.
02/27/2023 04:34:33 Percentage Encrypted: '98'%.
02/27/2023 04:34:33 Percentage Encrypted: '98'%.
02/27/2023 04:34:33 Percentage Encrypted: '98'%.
02/27/2023 04:34:34 Percentage Encrypted: '98'%.
02/27/2023 04:34:34 Percentage Encrypted: '98'%.
02/27/2023 04:34:34 Percentage Encrypted: '98'%.
02/27/2023 04:34:34 Percentage Encrypted: '98'%.
02/27/2023 04:34:35 Percentage Encrypted: '98'%.
02/27/2023 04:34:35 Percentage Encrypted: '98'%.
02/27/2023 04:34:35 Percentage Encrypted: '98'%.
02/27/2023 04:34:35 Percentage Encrypted: '98'%.
02/27/2023 04:34:35 Percentage Encrypted: '98'%.
02/27/2023 04:34:36 Percentage Encrypted: '98'%.
02/27/2023 04:34:36 Percentage Encrypted: '98'%.
02/27/2023 04:34:36 Percentage Encrypted: '98'%.
02/27/2023 04:34:36 Percentage Encrypted: '98'%.
02/27/2023 04:34:36 Percentage Encrypted: '98'%.
02/27/2023 04:34:37 Percentage Encrypted: '98'%.
02/27/2023 04:34:37 Percentage Encrypted: '98'%.
02/27/2023 04:34:37 Percentage Encrypted: '98'%.
02/27/2023 04:34:37 Percentage Encrypted: '98'%.
02/27/2023 04:34:38 Percentage Encrypted: '98'%.
02/27/2023 04:34:38 Percentage Encrypted: '98'%.
02/27/2023 04:34:38 Percentage Encrypted: '98'%.
02/27/2023 04:34:38 Percentage Encrypted: '98'%.
02/27/2023 04:34:39 Percentage Encrypted: '98'%.
02/27/2023 04:34:39 Percentage Encrypted: '98'%.
02/27/2023 04:34:39 Percentage Encrypted: '98'%.
02/27/2023 04:34:39 Percentage Encrypted: '98'%.
02/27/2023 04:34:39 Percentage Encrypted: '98'%.
02/27/2023 04:34:40 Percentage Encrypted: '98'%.
02/27/2023 04:34:40 Percentage Encrypted: '98'%.
02/27/2023 04:34:40 Percentage Encrypted: '98'%.
02/27/2023 04:34:40 Percentage Encrypted: '98'%.
02/27/2023 04:34:40 Percentage Encrypted: '98'%.
02/27/2023 04:34:41 Percentage Encrypted: '98'%.
02/27/2023 04:34:41 Percentage Encrypted: '98'%.
02/27/2023 04:34:41 Percentage Encrypted: '98'%.
02/27/2023 04:34:41 Percentage Encrypted: '98'%.
02/27/2023 04:34:41 Percentage Encrypted: '98'%.
02/27/2023 04:34:42 Percentage Encrypted: '98'%.
02/27/2023 04:34:42 Percentage Encrypted: '99'%.
02/27/2023 04:34:42 Percentage Encrypted: '99'%.
02/27/2023 04:34:42 Percentage Encrypted: '99'%.
02/27/2023 04:34:42 Percentage Encrypted: '99'%.
02/27/2023 04:34:43 Percentage Encrypted: '99'%.
02/27/2023 04:34:43 Percentage Encrypted: '99'%.
02/27/2023 04:34:43 Percentage Encrypted: '99'%.
02/27/2023 04:34:43 Percentage Encrypted: '99'%.
02/27/2023 04:34:44 Percentage Encrypted: '99'%.
02/27/2023 04:34:44 Percentage Encrypted: '99'%.
02/27/2023 04:34:44 Percentage Encrypted: '99'%.
02/27/2023 04:34:44 Percentage Encrypted: '99'%.
02/27/2023 04:34:44 Percentage Encrypted: '99'%.
02/27/2023 04:34:45 Percentage Encrypted: '99'%.
02/27/2023 04:34:45 Percentage Encrypted: '99'%.
02/27/2023 04:34:45 Percentage Encrypted: '99'%.
02/27/2023 04:34:45 Percentage Encrypted: '99'%.
02/27/2023 04:34:45 Percentage Encrypted: '99'%.
02/27/2023 04:34:46 Percentage Encrypted: '99'%.
02/27/2023 04:34:46 Percentage Encrypted: '99'%.
02/27/2023 04:34:46 Percentage Encrypted: '99'%.
02/27/2023 04:34:46 Percentage Encrypted: '99'%.
02/27/2023 04:34:46 Percentage Encrypted: '99'%.
02/27/2023 04:34:47 Percentage Encrypted: '99'%.
02/27/2023 04:34:47 Percentage Encrypted: '99'%.
02/27/2023 04:34:47 Percentage Encrypted: '99'%.
02/27/2023 04:34:47 Percentage Encrypted: '99'%.
02/27/2023 04:34:48 Percentage Encrypted: '99'%.
02/27/2023 04:34:48 Percentage Encrypted: '99'%.
02/27/2023 04:34:48 Percentage Encrypted: '99'%.
02/27/2023 04:34:48 Percentage Encrypted: '99'%.
02/27/2023 04:34:48 Percentage Encrypted: '99'%.
02/27/2023 04:34:49 Percentage Encrypted: '99'%.
02/27/2023 04:34:49 Percentage Encrypted: '99'%.
02/27/2023 04:34:49 Percentage Encrypted: '99'%.
02/27/2023 04:34:49 Percentage Encrypted: '99'%.
02/27/2023 04:34:49 Percentage Encrypted: '99'%.
02/27/2023 04:34:50 Percentage Encrypted: '99'%.
02/27/2023 04:34:50 Percentage Encrypted: '99'%.
02/27/2023 04:34:50 Percentage Encrypted: '99'%.
02/27/2023 04:34:50 Percentage Encrypted: '99'%.
02/27/2023 04:34:51 Percentage Encrypted: '99'%.
02/27/2023 04:34:51 Percentage Encrypted: '99'%.
02/27/2023 04:34:51 Percentage Encrypted: '99'%.
02/27/2023 04:34:51 Percentage Encrypted: '99'%.
02/27/2023 04:34:51 Percentage Encrypted: '99'%.
02/27/2023 04:34:52 Percentage Encrypted: '99'%.
02/27/2023 04:34:52 Percentage Encrypted: '99'%.
02/27/2023 04:34:52 Percentage Encrypted: '99'%.
02/27/2023 04:34:52 Percentage Encrypted: '99'%.
02/27/2023 04:34:52 Percentage Encrypted: '99'%.
02/27/2023 04:34:53 Percentage Encrypted: '99'%.
02/27/2023 04:34:53 Percentage Encrypted: '99'%.
02/27/2023 04:34:53 Percentage Encrypted: '99'%.
02/27/2023 04:34:53 Percentage Encrypted: '99'%.
02/27/2023 04:34:54 Percentage Encrypted: '99'%.
02/27/2023 04:34:54 Percentage Encrypted: '99'%.
02/27/2023 04:34:54 Percentage Encrypted: '99'%.
02/27/2023 04:34:54 Percentage Encrypted: '99'%.
02/27/2023 04:34:54 Percentage Encrypted: '99'%.
02/27/2023 04:34:55 Percentage Encrypted: '99'%.
02/27/2023 04:34:55 Percentage Encrypted: '99'%.
02/27/2023 04:34:55 Percentage Encrypted: '99'%.
02/27/2023 04:34:55 Percentage Encrypted: '99'%.
02/27/2023 04:34:55 Percentage Encrypted: '99'%.
02/27/2023 04:34:56 Percentage Encrypted: '99'%.
02/27/2023 04:34:56 Percentage Encrypted: '99'%.
02/27/2023 04:34:56 Percentage Encrypted: '99'%.
02/27/2023 04:34:56 Percentage Encrypted: '99'%.
02/27/2023 04:34:56 Percentage Encrypted: '99'%.
02/27/2023 04:34:57 Percentage Encrypted: '99'%.
02/27/2023 04:34:57 Percentage Encrypted: '99'%.
02/27/2023 04:34:57 Percentage Encrypted: '99'%.
02/27/2023 04:34:57 Percentage Encrypted: '99'%.
02/27/2023 04:34:57 Percentage Encrypted: '99'%.
02/27/2023 04:34:58 Percentage Encrypted: '99'%.
02/27/2023 04:34:58 Percentage Encrypted: '99'%.
02/27/2023 04:34:58 Percentage Encrypted: '99'%.
02/27/2023 04:34:58 Percentage Encrypted: '99'%.
02/27/2023 04:34:59 Percentage Encrypted: '99'%.
02/27/2023 04:34:59 Percentage Encrypted: '99'%.
02/27/2023 04:34:59 Percentage Encrypted: '99'%.
02/27/2023 04:34:59 Percentage Encrypted: '99'%.
02/27/2023 04:34:59 Percentage Encrypted: '99'%.
02/27/2023 04:35:00 Percentage Encrypted: '99'%.
02/27/2023 04:35:00 Percentage Encrypted: '99'%.
02/27/2023 04:35:00 Percentage Encrypted: '99'%.
02/27/2023 04:35:00 Percentage Encrypted: '99'%.
02/27/2023 04:35:01 Percentage Encrypted: '99'%.
02/27/2023 04:35:01 Percentage Encrypted: '99'%.
02/27/2023 04:35:01 Percentage Encrypted: '99'%.
02/27/2023 04:35:01 Percentage Encrypted: '99'%.
02/27/2023 04:35:01 Percentage Encrypted: '99'%.
02/27/2023 04:35:02 Percentage Encrypted: '99'%.
02/27/2023 04:35:02 Percentage Encrypted: '99'%.
02/27/2023 04:35:02 Percentage Encrypted: '99'%.
02/27/2023 04:35:02 Percentage Encrypted: '99'%.
02/27/2023 04:35:03 Percentage Encrypted: '99'%.
02/27/2023 04:35:03 Percentage Encrypted: '99'%.
02/27/2023 04:35:03 Percentage Encrypted: '100'%.
02/27/2023 04:35:03 Current BL Status: C:, FullyEncrypted, XtsAes256,Tpm ExternalKey
02/27/2023 04:35:03 removing drive letter assigned to the SYSTEM partition now...
02/27/2023 04:35:04 The drive is fully encrypted now :-), we are exiting the script !

    Once encryption during WhiteGlove is completed a reg key is created

    encrypted during whiteglove reg key.png

    and a file is created called EncryptedDuringWhiteGlove.txt in C:\ProgramData\windowsnoob\WhiteGlove

    wg logs after enrollment.png

    This file is used as the detection rule for this Win32 app meaning that encryption must be completed by the app to be detected.

    Note: This solution was originally tested and released for use on Windows 10 version 22H2, but it works just fine on Windows 11 version 22H2 or later. Do make sure that Automatic Bitlocker Encryption is disabled by the OEM (HP, Dell, Lenovo, etc) or disable it yourself using the following method:
      

    1. DISM mount your WIM image.
2. reg load HKLM\TEMP C:\mountpath\Windows\System32\config\SYSTEM
3. reg add HKLM\TEMP\CurrentControlSet\Control\BitLocker /v PreventDeviceEncryption /t REG_DWORD /d 1 /f
4. reg unload HKLM\TEMP
5. DISM commit your changes.

    Recommended reading

  8. Windows 365, Intune, ConfigMgr and PKI step by step guides

    in System Center Configuration Manager (Current Branch)

    Posted

    This list of guides is a living index covering Windows 365 Cloud PC, Microsoft Intune or Configuration Manager. The Configuration Manager Current Branch releases are meant for your production deployments and the Technical Preview releases are for testing new upcoming features in the product, and are aimed at Lab use only. The PKI guides are added as https communication within ConfigMgr and Intune is desired.

    These guides are broken down into different sections:

    • Windows 365
    • Microsoft Intune
    • Configuration Manager - Current Branch
    • Configuration Manager - Technical Preview
    • Setting up PKI

    Note: The guides in each section are (mostly) sorted in the direction of oldest first.

    Windows 365

    Microsoft Intune

     

    Configuration Manager Current Branch

    Configuration Manager Technical Preview

    Setting up PKI

     

    cheers
    niall

    • Like 3
    • Thanks 1

  10. Getting started with Windows 365 - Part 7. Patching your Cloud PCs with Windows Autopatch

    in Windows 365

    Posted

    Introduction

    This is Part 7 in a new series of guides about getting started with Windows 365. This series of guides will help you to learn all about Windows 365 in a clear and insightful way. This series is co-written by Niall & Paul, both of whom are Enterprise Mobility MVP’s with broad experience in the area of modern management. At the time of writing, Paul is a 6 times Enterprise Mobility MVP based in the UK and Niall is a 12 times Enterprise Mobility MVP based in Sweden. In this series we aim to cover everything we learn about Windows 365 and share it with you to help you to deploy it safely and securely within your own organization. In Part 1 we introduced you to Windows 365, selecting the right edition with the level of management that you need, choosing the plan that suits your users needs at a cost you can afford, or modifying the configuration to make it more suited to your individual needs, purchasing licenses and saving money for your organization via the Windows Hybrid Benefit. In Part 2 you learned how to provision an Azure Ad joined Cloud PC and take a look at the different network options available when provisioning an Azure Ad joined Cloud PC. In Part 3 you learned about the steps needed to successfully provision a Hybrid Azure Ad Joined Cloud PC. In Part 4 you saw the many different ways you can connect to your Cloud PC from many device be it Android, Mac, Windows, Linux or iPhone and you learned that not all connection options have the same abilities. In Part 5 we covered the management capabilities of your Cloud PCs and explained the different options available depending on which version (Business versus Enterprise) that you purchase. In Part 6 we looked at the built in configurable backup technology in Windows 365 which is known as Point-in-time restore, which gives the admin (or user) the ability to restore Cloud PC's to an earlier time before a problem such as a Ransomware incident occurred.

    Below you can find all parts in this series:

    In this part we'll cover the following:

    • Introduction to Windows Autopatch
    • Prerequisites
    • Allow access to admins without licenses
    • Enroll into Windows Autopatch
      • Readiness assessment tool
      • Enroll
      • Device registration
    • Moving devices between deployment rings
    • Reports
    • User Experience
    • Create Provisioning policy
    • Recommended reading
    • Summary

    Introduction to Windows Autopatch

    Quote

    "Do more with less"

    Windows Autopatch was created to ease the pain of managing software updates by automating those tasks, improve security and thereby freeing up IT admins time. After registering devices with Windows Autopatch it can deal with multiple areas of update management including:

    • Windows quality updates
    • Windows feature updates
    • Microsoft 365 apps for Enterprise
    • Microsoft Edge
    • Microsoft Teams

    Windows Autopatch aims to reach the following SLO (Service Level Objective) at the time of writing.

    • Windows quality updates  - 95% of eligible devices on the latest quality update within 21 days
    • Windows feature updates - 99% of eligible devices on a supported version
    • Microsoft 365 apps for Enterprise - 90% of eligible devices on a supported version of the Monthly Enterprise Channel (MEC)

    Prerequisites

    Windows Autopatch like all Microsoft services has a list of prerequisites and you can review them here and it covers 4 main areas.

    1. Licensing
    2. Connectivity
    3. Azure Active Directory
    4. Device Management

    In a nutshell you must be licensed to use Windows Autopatch, Windows 10/11 Enterprise E3 (or higher) to be assigned to your users. Additionally, Azure Active Directory Premium and Microsoft Intune licenses are required. You must also allow connectivity to all endpoints specified here including mmdcustomer.microsoft.com, mmdls.microsoft.com, logcollection.mmd.microsoft.com and support.mmd.microsoft.com. Your users must be created in Azure Active Directory or synced via the latest version of Azure AD Connect. Last but not least, your devices must already be enrolled into Intune management before you try to register them with the Windows Autopatch service. They can use co-management but, if so, make sure that the following workloads are pointing to Pilot Intune or Intune.

    • Windows Update policies workload to Pilot Intune or Intune.
    • Device configuration workload to Pilot Intune or Intune.
    • Office Click-to-Run apps workload to Pilot Intune or Intune.

    comanagement workloads to intune.png

    Allow access to admins without licenses

    When turning on Windows Autopatch for your Tenant, one of the tests that will be done is admin licensing. You can make things smoother by configuring this setting in advance. You can give administrators access to Microsoft Endpoint Manager without them requiring an Intune license, see Unlicensed admins in Microsoft Intune | Microsoft Learn

    Quote

    This feature applies to any administrator, including Intune administrators, global administrators, Azure AD administrators, and so on. Other features or services, such as those in Azure Active Directory (AD) Premium, may require a license for the administrator.
    The Unlicensed admins option has been enabled by default on all accounts created after the 2006 release.

    To flip the setting go to your Tenant admin, click on Roles, and select Endpoint Manager roles, click on Administrator Licensing and you'll see this.

    allow access to unlicensed admins.png

    read the warning before clicking Yes (or No if you are unsure.)

    allow access to unlicensed admins warning.PNG

    Once done, there will simply be a blank space to greet you in the Administrator Licensing space.

    where's the confirmation.PNG

     

    Enroll into Windows Autopatch

    Readiness assessment tool

    At this point you are hopefully ready to enroll your tenant into Windows Autopatch, so let's do it. In the Tenant Admin node, click on Tenant enrollment and select Windows Autopatch.

    enroll into windows autopatch.png

    place a tick in the checkbox and click Agree. this will launch the readiness assessment tool.

    readiness assessment tool initial results.png

    clicking on View details gives you an overview of what is OK or NOT OK in your tenant in relation to Windows Autopatch. Any errors marked in red must be fixed (notice the unlicensed admin error !)

    errors in red not ready.png

    You can click on a linked entry to get details of the problem, for example here is the co-management advisory.

    comanagement advisory.png

    and here's the advisory for Update rings for Windows 10, which is odd as you haven't created any for Windows Autopatch yet so how can you exclude them in advance ?

    update rings for windows 10.png

    After fixing the minor problems noted above, you can click on Run checks again and this time it should report that it is Ready (to enroll).

    ready to enroll.png

    If you are still curious about why there are still 2 advisories you can also click on View details again to review that.

    2 ready 2 advisory.png

    Enroll

    Now that the readiness assessment is happy, go ahead and click on Enroll. You'll have to agree to allow admin access for Microsoft requiring 2 admin users email and phone numbers.

    allow administrator access for Microsoft.png

    supply the details of your Primary admin

    primary admin.png

    and the Secondary admin

    secondary admin.png

    after clicking complete you might see an error, don't panic, we did in both our tenants.

    an error has occurred during enrollment.png

    but on the second attempt all was good ! Notice all the activity going crazy in the notification area.

    windows autopatch is enrolled.png

    After some time you should be notified that Windows Autopatch Setup is complete.

    windows autopatch setup complete.png

    Changes to your tenant

    When you enroll into Windows Autopatch the service creates many new objects including Azure AD Groups, policies, update rings and reports, here are a few snippets of some of those many changes.

    New Azure AD Groups

     

    new Azure AD groups.png

    New configuration profiles

    new configuration profiles.png

    New PowerShell script

    Modern Workplace - Autopatch Client Setup v1.1

    New Update Rings

    image.png

    New Feature Updates

    image.png

    New reports

    windows quality update reports.png

    Device registration

    Clicking Continue (in the screenshot above) brings you to the Windows Autopatch devices view which will most likely be empty after enrollment. It's separated into three tabs

    • Ready
    • Not ready (Preview)
    • Not registered

    windows autopatch devices empty.png

    After reading the text and clicking the included link it was clear that there was a new Azure AD Group created by the Windows Autopatch service called Windows Autopatch Device Registration. We went ahead and added a Windows 365 Cloud PC to the Windows Autopatch Device Registration group.

    add one cloud pc to the group.png

    Next, in the Windows Autopatch devices node, click on Discover Devices to get the service to look for new members in that group.

    image.png

     

    After some time it showed up.

    added one cloud pc to the group.png

    We then looked at the Group Membership of that device directly after we registered it with Windows Autopatch.

    group membership after windows autopatch.png

    Interesting how it detects that the Cloud PC is a Virtual Machine.

    You'll notice that the Windows Autopatch service has automatically added this Cloud PC to a group called First, this is one of 4 update ring groups.

    • Modern Workplace Devices-Windows Autopatch-Test       Deployment ring for testing update deployments prior to production rollout.
    • Modern Workplace Devices-Windows Autopatch-First       First production deployment ring for early adopters.
    • Modern Workplace Devices-Windows Autopatch-Fast       Fast deployment ring for quick rollout and adoption.
    • Modern Workplace Devices-Windows Autopatch-Broad    Final deployment ring for broad rollout into the organization.

    Intrigued we added another Cloud PC along with several unpatched, out of date devices in the tenant to see what would happen.

    add devices to Windows Autopatch Device Registration.png

    within some time the Windows Autopatch service had assigned these devices to groups automatically with both of the Windows 365 Cloud PC's added to the First update ring.

    devices added to update ring groups.png

    In addition to these Ready devices some were Not registered with the service due to not meeting prerequisites.

    not registered.png

    Moving device between deployment rings

    To change the update ring a device is in you must select one of more devices and use the Device actions dropdown to move to another update ring group, do not simply move the device from one Azure ad group to another (more on those groups later).

    assign device group.png

    This brings up a dropdown list of the available rings (update ring groups)

    assigning a group.png

    We selected the Test ring for this Cloud PC

    selected Test.PNG

    after the change

    test ring.png

    Note that you can only move devices to other deployment rings when they are in an Active state in the Status tab.

    Reports

    Windows Autopatch includes new reports to assist with monitoring the effectiveness of automated software update management. Let's take a look. In the Reports node of Intune, select Windows Quality Updates in the Windows Autopatch section. You'll be presented with a summary of Windows Autopatch managed devices in their various states, listed below:

    • Up to Date
    • In Progress
    • Paused
    • Not Up to Date
    • Ineligible
    • Total

    Windows Quality Updates.png

    clicking on the Reports tab (beside summary) will show the actual reports.

    reports.png

    In the first report, All devices report, you can see our Cloud PCs are currently up to date ! Great.

    Cloud PCs up to date.png

    Truth be told however, they had an issue before Windows Autopatch could do it's thing, and that was they were getting a GPO applied (as they are Hybrid Azure AD joined) which was blocking automatic updates. Once that GPO was identified and delinked, they updated very quickly indeed.

    Below you can see what they looked like before the GPO was identified. Notice how they are both showing with an Update Status of Not Up to Date, and the Update sub status looks confused (Other and No Heartbeat).

    not up to date.png

    The offending GPO was setting the following registry key which was blocking Windows Autopatch (highlighted below in bold) 

    HKLM\software\policies\microsoft\windows\windowsupdate
    • WUServer
    • WUStatusServer
    • DoNotConnectToWindowsUpdateInternetLocations
    • DisableWindowsUpdateAccess
    • AU\NoAutoUpdate
    • AU\UseWUServer

    the next report is the All devices Report - historical which gives you a historical view of how up to date (or not) your devices are over a period of time (90-day trend), notice how currently 7 out of 10 devices are up to date and none are not up to date.

    all devices report historical.png

    You can click on any of the headings in the right pane to get time points and clarity of that section. You can also choose to Export trend to get a CSV file containing this data, unfortunately it doesn't go any deeper than what you see here so you won't for example see device names/serial numbers or anything useful like that. Hopefully we can get that data in a later release.

    export trend.png

    The next report is the Eligible devices report - historical where you can review the effectiveness of any of the Windows Autopatch update rings over a period of time.

    eligible devices report historical.png

    And finally we have the ineligible devices report historical which shows data about your ineligible devices and whether they are on an unsupported build or not.

    ineligible devices report historical.png

     

    User Experience

    the user experience is exactly what you'd expect from WUFB managed clients, you get the normal Windows notifications and they are goverened by the Windows Autopatch update ring policies, which you shouldn't change as they will be overwritten by the Windows Autopatch service. Below is one such notification received by our Cloud PCs over the last few weeks.

    windows update info in windows update settings.png

    Create Provisioning policy

    Lastly, we'd like to mention the Windows Autopatch setting in the Create Provisioning Policy section. It's there, but it's not clear exactly what it does (for example, would it kick off a Windows Autopatch readiness assessment tool if you hadn't yet enrolled into Windows Autopatch. This remains unanswered. We'll update it after getting clarification from Microsoft.

    Windows Autopatch ANC setting.png

    Recommended reading

    Summary

    The Windows Autopatch service is like your very own IT Admin for Software Update Management, much like what you get with Automatic Deployment Rules within Configuration Manager or Windows Intune's quality and feature update rings. The difference here is that when you enable Windows Autopatch, Microsoft define and manage these administrative tasks so you don't have to. Keep in mind that it is not recommended to change any settings in the preconfigured update rings or policies or scripts provided by the service as they could be overwritten by the service when it gets updated by Microsoft. Also, you should not manually populate the Azure AD groups created by the service except the one used for device registration. The fact that you can't really deviate from the settings, policies and parts that make up Windows Autopatch can be a downside for some customers. Hopefully Microsoft reads this and adds this ability going forward. Overall though, a thumbs up from us, well done to all involved with creating Windows Autopatch, it makes the management of updates, security patches and more to your Cloud PC's a walk in the park.

  12. Side-by-side upgrade of a Domain Controller running Windows Server 2012R2 to Windows Server 2022

    in Windows Server General

    Posted

    My Configuration Manager Technical Preview lab has been going strong since 2015 and when I installed it Windows Server 2012R2 was the logical choice for the domain controller server in that lab. Fast forward to 2023 and the imminent news that Windows Server 2012 R2 will reach end of support in October 2023.

    eol.png

    This blog post is a summary of what I did to upgrade my DC to a supported version, read on, and comment !

    In this blog post I'll cover the following:

    • Introduction
    • Prerequisites
    • Install a new Windows Server, rename it, join the domain
    • Update the server
    • Install Active Directory Domain Services
    • Promote to a domain controller
    • Move FMSO to the new domain controller
    • Verify FMSO roles
    • Demote the old domain controller
    • Verification
    • Recommended reading

    Introduction
    I still use my ConfigMgr labs and update the Technical Preview releases every month since it was first released, so I wanted to keep this on-premises lab going. I decided that it was time to upgrade my Lab's aging domain controller to a newer, more secure operating system. In-place upgrades from Windows Server 2012 R2 to Windows Server 2022 are possible but not recommended for Domain Controllers.

    Take note of the recommended way to upgrade your domain controller from Microsoft below.

    recommended way.png

    Based on that recommendation, that meant deploying a new one side-by-side and migrating things over to the new one before decommissioning the old. As this is an on-premises lab my goal was to upgrade to the latest and greatest Windows Server 2022.

    Prerequisites

    Before starting make sure to review the list of prerequisites needed. Microsoft has detailed them here. They are also listed here. You should follow these general steps before you promote a server to a DC that runs a newer version of Windows Server:

    • Verify the target server meets the system requirements.
    • Verify application compatibility.
    • Review recommendations for moving to a newer version of Windows Server.
    • Verify security settings.
    • Check connectivity to the target server from the computer where you plan to run the installation.
    • Check for availability of the necessary Flexible Single Master Operation (FSMO) roles in Active Directory.

    Note: If you are doing this in a LAB and I'd suggest you take a backup snapshot of your old domain controller before continuing.

    Install a new Windows Server, rename it, join the domain

    You can install your new server whichever way that suits you, it's quick. Once done, rename the server to it's new name, and join the domain where you other domain controller(s) reside.

    install server rename and join domain.png

     

    Update the server

    After you've installed the server there will most likely be several updates waiting to be installed, so go ahead and install them, repeat until complete.

    update server.png

     

    Install Active Directory Domain Services

    Next you need to install Active Directory Domain Services (ADDS) on the new server and that can be done easily with PowerShell. In an administrative Windows PowerShell prompt enter the following: 

    Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

    install ADDS using PowerShell.PNG

     

    Promote to a domain controller

    Once ADDS is complete you'll promote the new server to a domain controller. To do that open Server Manager and you'll see a yellow exclamation mark highlighting Post-deployment Configuration required for Active Directory Domain Services on the new server.

    yellow exclamation mark post configuration for ADDS.PNG

     

    Click on Promote this server to a domain controller and this will launch the Active Directory Domain Services Configuration Wizard. From the list of available deployment operation options select Add a domain controller to an existing domain.

    add a domain controller to an existing domain.PNG

    fill in the Directory Services Restore Mode (DSRM) password

    directory services restore mode dsrm password.PNG

    If you are using .local FQDN's in your lab like me click OK to the warning.

    a delegation for this dns server cannot be created because the authoritative parent zone cannot be found.PNG

    On the Specify Install From Media (IFM) Options screen select the option that suits your scenario best

    Install from media.PNG

    and decide where you want the NTDS, logs file folder and SYSVOL folder to be located (or accept the defaults)

    paths for sysvol etc.PNG

    take note of the Preparation Options

    preparation options.PNG

    before you see the Review Options screen, at this point you can also click on View Script to get a PowerShell script of your actions which is useful for automating the installation of more Domain Controllers.

    Review Options.PNG

    Clicking Next will bring you to the Prerequisites Check results.

    prerequisites check.PNG

    and clicking Install will start the promotion of this server to a domain controller. As long as you are signed in with a domain admin account, adprep will automatically prepare your existing domain. After it's completed and restarted, sign in on the new domain controller and there should be no additional configuration tasks waiting in Server Manager.

    domain controller promotion done.PNG

     

    Move FMSO to the new domain controller

    After the server was promoted to a domain controller it's time to move the Flexible Single Master Operation (FMSO) from the old domain controller to the new domain controller. To do that open an administrative PowerShell window on the old domain controller server. In the PowerShell window, use the 

    Move-ADDirectoryServerOperationMasterRole

    cmdlet to move the FSMO roles. You can enter the name of each Operation Master Role or use numbers to specify the roles. For more information, see Move-ADDirectoryServerOperationMasterRole.

    move fmso to the new domain controller.PNG

     

    Verify FMSO roles

    Now that you've moved the FMSO roles you should verify that they are in place correctly on the new domain controller, to do that on the new domain controller open an Administrative PowerShell window and type the following. 

    Get-ADDomain

    get-addomain.PNG

    Verify that the following match the FQDN of your NEW domain controller.

    • InfrastructureMaster
    • PDCEmulator
    • RIDMaster

     

    Demote the old domain controller

    Once everything is verified and complete it's time to demote the old domain controller. Only start this part when you are sure that everything you need on the new domain controller is in place and working, for example, in my case I had to manually add the DHCP server options/scope etc to my new domain controller as it was not carried over. On the old domain controller open an Administrative PowerShell window and issue the following command. 

    Uninstall-ADDSDomainController

    uninstall-addsdomaincontroller.PNG

    It will prompt you to enter the password of a local administrator user twice and after answering Y it will demote the server and then restart the server.

    you are about to be signed out.PNG

    After the server is demoted and removed, you can raise the forest functional and domain functional levels to the latest version of Windows Server. Once  done, power off the old domain controller and optionally rename it so you know it's demoted and offline.

    ad1 demoted offline.PNG

     

    Verification

    On the new domain controller use DCDiag to check everything is OK.

    image.png

    On any domain joined device (for example on my hybrid Azure AD joined Windows 365 Cloud PC) issue a GPUpdate /force. This will pull group policy from the nearest domain controller (your new domain controller in a one DC environment.

    gpupdate force.png

    You should also verify main services such as

    • DNS
    • DHCP
    • PKI

    and any other services that were provided on your old domain controller.

    Job done !

    Recommended reading

     

  15. Getting started with Windows 365 - Part 6. Point in time restore

    in Windows 365

    Posted

    Introduction

    This is Part 6 in a new series of guides about getting started with Windows 365. This series of guides will help you to learn all about Windows 365 in a clear and insightful way. This series is co-written by Niall & Paul, both of whom are Enterprise Mobility MVP’s with broad experience in the area of modern management. At the time of writing, Paul is a 6 times Enterprise Mobility MVP based in the UK and Niall is a 12 times Enterprise Mobility MVP based in Sweden. In this series we aim to cover everything we learn about Windows 365 and share it with you to help you to deploy it safely and securely within your own organization. In Part 1 we introduced you to Windows 365, selecting the right edition with the level of management that you need, choosing the plan that suits your users needs at a cost you can afford, or modifying the configuration to make it more suited to your individual needs, purchasing licenses and saving money for your organization via the Windows Hybrid Benefit. In Part 2 you learned how to provision an Azure Ad joined Cloud PC and take a look at the different network options available when provisioning an Azure Ad joined Cloud PC. In Part 3 you learned about the steps needed to successfully provision a Hybrid Azure Ad Joined Cloud PC. In Part 4 you saw the many different ways you can connect to your Cloud PC from many device be it Android, Mac, Windows, Linux or iPhone and you learned that not all connection options have the same abilities. In Part 5 we covered the management capabilities of your Cloud PCs and explained the different options available depending on which version (Business versus Enterprise) that you purchase. In this part we'll take a look at the built in configurable backup technology in Windows 365 which is known as Point-in-time restore, this is a great ability to restore your Cloud PC's to an earlier time before a problem such as a Ransomware incident occurred.

    Below you can find all parts in this series:

    In this part we'll cover the following:

    • Introduction to Point in time restore
    • Configuring restore point settings
    • Restoring a single Cloud PC
    • Restoring multiple Cloud PCs at the same time (bulk)
    • End user initiated restore
    • Recommended reading
    • Summary

    Introduction to Point in time restore

    Point in time restore for Windows 365 is explained as follows according to Microsoft:

    Quote

    Point-in-time-restore lets an administrator restore a Cloud PC to the exact state it was at an earlier point in time. Admins can also give users permission to restore their own Cloud PCs.

    However, based on our testing this is not entirely correct as the type of restore points (or snapshots) are similar in concept to hyper-V's production checkpoints. Why does that matter ? Well in hyper-v, production checkpoints capture the current state of the operating system, not the running apps at the time that the snapshot was taken. If you use hyper-v virtual machines then you'll love using standard checkpoints as they capture everything you are doing at the time, including running apps, settings, operating system state. Everything.

    With Point-in-time restore, you'll get a restore point of a Cloud PC to the exact state it was in at the time the backup was made, however it won't capture the state of any apps that were running at the time the backup was made, the operating system will essentially be in a 'just booted' state with no apps running and that becomes immediately obvious when you restore a point-in-time restore..

    Point-in-time restore has 2 different types of restore points, long term and short term.  Long term restore points are saved every 7 days and there are a maximum of 4 long term restore points. Short term restore points are saved based on the user settings interval, so can be every 4, 6, 12, 16 or 24 hours.  Each Cloud PC will have up to 10 short term restore points saved at intervals defined in user settings configured by the admin and a further (up to) 4 long term restore points making a total of 14 possible restore points.

    In the screenshot below of a Cloud PC in Microsoft Intune you can see 3 long term restore points (every 7 days) and 10 short term restore points (configured for the default setting of every 12 hours).

    long term versus short terms.png

     

    So now that we know there are different types of restore-points let's take a look at how to configure them.

     

    Configuring restore point settings

    In Microsoft Intune, navigate to Devices, Windows 365 and click on the User Settings tab.

    devices windows 365 and user settings.png

     

    Click on Add + and give your User Settings policy a suitable name, keep in mind that if you have multiple policies targeting the same users that there is no way to currently enforce one over the other. In this example we'll configure the restore points every 24 hours (the default setting is every 12 hours), which means one restore point every day. You can also configure whether the user is allowed to restore their own Cloud PC via the Windows 365 portal and you can additionally configure Local Admin Settings.

    point in time restore settings.png

    Click Next and then add one or more groups with Users that you wish to target with these settings.

    add groups of users.png

     

    When ready, click Select, then click Create.

    create.png

     

    Once done, any users in the Groups added will be able to restore their own restore points and their restore points will be taken every 24 hours.

    Restoring a single Cloud PC

    To restore a single Cloud PC simply locate it in the Endpoint Manager console selecting Devices and then clicking on Windows 365, next select All Cloud PC's and select the Cloud PC you wish to restore. Notice that there is a node on the left called Restore Points. You can access the same ability via the Restore option at the top of the screen and the last previous Restore action will listed in the summary.

    restore points options.png

    Click on Restore Points in the left pane. This will bring up a new window showing all restore points that have been taken for the Cloud PC.

    In our testing, the Restore Point type and Expiration date columns never populated with any information. We have informed Microsoft PG about this, however, the Last restored column does populate after a restore is completed.

    restore point type and expiration date.png

    Note: Be careful when restoring a Cloud PC as no indication/message or information will be sent to the user logged on that their Cloud PC is about to be restored. They will simply see the computer shutting down all of a sudden and after that it will be inaccessible for a time.

    Keeping in mind that Cloud PC's that are domain joined may have rolling passwords/secrets that change causing you to lose the ability to logon to the domain if you restore a Cloud PC from too far back. So let's pick a fairly recent date in the above list and right click, you'll get the option to Restore this version. Continuing the process will give you one last chance to cancel, and if you select restore it will start the restore process which can typically take about 30 seconds.

    You can see an edited (shortened) video of that process below:

    2023-01-29_15-36-27.gif

    After the restore is complete, you can refresh the Intune console and the Last restored column should now indicate the latest restore.

    restored.png

    The end user may see the following in their Windows 365 app, indicating that there is an error connecting to their Cloud PC.

    restore is in progress.png

    Clicking on details may give you some information like the following.

    Quote

     

    Your session was disconnected. If this keeps happening ask your admin or tech support for help.

    Error Code: 0x3000046
    Error Message: Gateway does not have resource to assign to the connection
    Timestamp: 2023-01-29T14:53:02.671Z
    Activity ID: 1d435b62-b3d7-465c-85fa-84ed545b0000

     

    Waiting a minute or so and clicking on retry should be enough to reconnect.

    If the end user accesses the Cloud PC using the Windows 365 portal, then they'll be correctly informed that the Cloud PC is in the following state: Restoring Cloud PC

    restoring cloud pc.png

    Restoring multiple Cloud PCs at the same time (bulk)

    When an admin needs to restore multiple Cloud PC's at the same time (up to 100 at a time) then Bulk PC actions are to the rescue. Let's take a look at that process. In Microsoft Intune, select Devices, and next select All devices. In the top field you'll see Bulk Device Actions.

    Bulk Device Actions.png

    Click on it and it'll bring up the Bulk Device Actions menu. Select Windows as the OS and then select Restore from the options available.

    select windows as the OS and then select Restore.png

    Next, select the date and time and the time range from the available options.

    sspecify date and time and whichever is closest.png

     

    Next, select which devices to include (up to 100), you can use filters to assist with this

    add filters.png

    or you can simply add Cloud PC's individually by selecting them and adding them to the list

    select devices to include.png

    Once done, review the summary before clicking on Create to start the Bulk Action.

    create bulk action.png

     

    You should then be notified of the success or failure of the action in the Intune console.

    successfully initiated restore.png

     

    End user initiated restore

    Now that you have seen how an admin can restore one or many Cloud PC's, what about the end user's view of things? The end user can restore their Cloud PC either using the Windows 365 app settings or via the Windows 365 portal.

    In the Windows 365 app, the user can simply click on the 3 dots to gain access to user-initiated actions.

    click and select restore.png

    After selecting restore, the following window will popup informing the user about what is about to happen if they continue and asking them to confirm the action.

    confirm the action.png

    After confirming, they can select a restore point

    select a restore point.png

    before finally clicking on Restore to complete the action.

     

    Similarly to the app, in the Windows 365 portal the end user will see their available Cloud PC's and options available based on what was configured by the admin. Clicking on the 3 dots to Manage this Cloud PC

    manage this cloud pc.PNG

    brings up the same experience as with the Windows 365 app above.

    restore a cloud pc via the portal.png

     

    Recommended reading

     

    Summary

    Windows Cloud PC's are more manageable than ever, but sometimes things can and do go wrong. As an admin having the ability to restore one or more Cloud PC's to a previous point-in-time is great, we only wish that we could get more options such as the ability to customize the type of restore point to include say running apps. We've sent the feedback to Microsoft. It would also be nice if the Status of a restore revealed if it was the end-user that initiated it versus the Admin.

     

  19. Migrate to the cloud - Part 1. Setup

    in System Center Configuration Manager (Current Branch)

    Posted

    hi @dipalma

    thank you for trying out my solution, this code is 'as is' and it's up to you to make it work in your environment, you can rem out all the scrolling by editing the associated log file, but what you really should have seen is the full screen status screen and not the powershell logging

    what that means is something probably failed which is why you are seeing the powershell cmd instead of the status screen,

    feel free to post your logs here and i can take a look.

    that said, i'm still working on it and will hopefully have a newer version of it to release in the coming month or two with a LOT of bug fixes and improvements

    cheers

    niall

  22. Getting started with Windows 365 - Part 5. Managing your Cloud PC

    in Windows 365

    Posted

    Introduction

    This is Part 5 in a new series of guides about getting started with Windows 365. This series of guides will help you to learn all about Windows 365 in a clear and insightful way. This series is co-written by Niall & Paul, both of whom are Enterprise Mobility MVP’s with broad experience in the area of modern management. At the time of writing, Paul is a 6 times Enterprise Mobility MVP based in the UK and Niall is a 12 times Enterprise Mobility MVP based in Sweden. In this series we aim to cover everything we learn about Windows 365 and share it with you to help you to deploy it safely and securely within your own organization. In Part 1 we introduced you to Windows 365, selecting the right edition with the level of management that you need, choosing the plan that suits your users needs at a cost you can afford, or modifying the configuration to make it more suited to your individual needs, purchasing licenses and saving money for your organization via the Windows Hybrid Benefit. In Part 2 you learned how to provision an Azure Ad joined Cloud PC and take a look at the different network options available when provisioning an Azure Ad joined Cloud PC. In Part 3 you learned about the steps needed to successfully provision a Hybrid Azure Ad Joined Cloud PC. In Part 4 you saw the many different ways you can connect to your Cloud PC from many device be it Android, Mac, Windows, Linux or iPhone and you learned that not all connection options have the same abilities.

    The management capabilities of your Cloud PCs are dependent on which edition of Windows 365 you purchase. If you want rich device management, go with Windows 365 Enterprise. If your business is small (less than 300 employees) use the Windows 365 Business option and it's associated (limited) management. Cloud PC's from Microsoft have come about from traditional Desktop as a Service (DaaS) offerings (providing a Windows experience for end users with little or no overhead for IT admins) and an evolution from PaaS offerings (such as Azure Virtual Desktop).

    Microsoft's definition of Cloud PC is defined as a Windows experience delivered in an elastic way from the cloud while maintaining their full security posture and flexibility and user experiences that they see in the physical world. That flexibility and maintenance is of course done via management and that's our focus in this blog post, managing your Cloud PC's whether you are using the Business or Enterprise edition of the product.

    Below you can find all parts in this series:

    In this part we'll cover the following:

    • Different abilities between editions
    • Management capabilities for Windows 365 Business
      • Sign up for a Windows 365 Business Trial
      • Assigning a user an administrative role
      • Abilities in the Windows365 portal
    • Management capabilities for Windows 365 Enterprise
      • Quick overview of features in Intune
      • Cloud PC related actions on Windows 365 devices
      • Configure Alerts for Windows 365 related issues
      • Custom Windows 365 role-based access control (RBAC) roles
    • Management capabilities via Powershell
      • Create Enterprise app
      • Configure permissions
      • Grant consent
      • Script samples
    • Recommended reading
    • Summary

    Different abilities between editions

    In Part 1 of this blog series we highlighted the main differences between the 2 editions. The following table further outlines the different capabilities (including management capabilities) between Windows 365 Business and Windows 365 Enterprise editions. It's clear that if you want image management, device management, connection to on-premises network resources, reporting, monitoring and more that Windows 365 Enterprise is the right choice.

    different management capabilities between business and enterprise.PNG

     

    Management capabilities for Windows 365 Business
    Windows 365 comes in two flavors, Windows 365 Business, or Windows 365 Enterprise. With the Enterprise edition you get Intune device management and more included. With the Business edition you are limited to actions (listed below) in the Windows 365 portal or remote actions via the admin console. As there is no Intune management included, there are no licensing prerequisites to set up Windows 365 Business.

     

    Sign up for a Windows 365 Business Trial

    If you'd like to try out the Windows 365 Business for yourself to test Cloud PC's and the management capabilities available to Windows 365 Business, you can sign up for a free 30 days trial if you are in a region where trials are offered. Below are 2 applicable regions (there may be more) where the trial period is currently valid at the time of writing. We signed up for the UK trial.

    For a list of management capabilities for the Business edition via windows365.microsoft.com see below:

     

    Assigning a user an administrative role

    To avail of this management ability for Windows 365 Business, you'll need a user to be assigned either of the following roles:

    • Global Administrator
    • Windows 365 Administrator

    In our testing however, there are some scenarios where you'll need more than just the Windows 365 Administrator role and we've asked the Microsoft Product Group for comment. We'll update this blog post when we have more clarity on that.

    You can assign these RBAC (Role Based Access Control) roles via the admin.microsoft.com portal as a Global Administrator or if the customer has access to Azure Active Directory.

    To apply the Windows 365 Administrator role using the admin.microsoft.com portal, login as a Global Administrator and click on Users, select Active Users, select the user in question, click on Manage Roles and scroll down to Devices and select the Windows 365 Administrator role before selecting Save Changes.

    manage roles in admin.png

     

    To apply the role to a user in Azure AD, login as Global Administrator, select Roles and administrators

    roles and administrators in Azuread.png

    Search for the appropriate role, in this example we will apply the Windows 365 Administrator role.

    windows 365 administrator role.png

    Click on + Add assignments and then click on No member selected to add at least one member to this role.

    adding windows 365 business admin.png

     

    Note: If your Windows 365 business admin user does not have either of those roles assigned, then none of the remote actions or additional abilities will be available or visible on windows365.microsoft.com or admin.microsoft.com. We noted that in order to see anything in the admin portal you'd also need to assign the Global Reader role in addition to the Windows 365 Administrator role.

     

    Abilities in the Windows365 portal

    Here we can see a typical view of the windows365.microsoft.com portal and the management capabilities available to a user with one of the roles mentioned above for Windows 365 Business. In this view we can see an additional tab called Your organization's Cloud PCs.

    new abilities in the windows365 portal.png

    Clicking on Your organization's Cloud PCs reveals a list of users in your organization and their assigned licenses and it reveals another option to Update organization settings.

    options available.png

    From this view the admin can select to manage users by clicking on them directly and accessing the options available, this gives you access to add users, reset passwords, update organization settings or do remote actions on users Cloud PCs all from one place. For example in the screenshot below, clicking on the account the devices or even the licenses and apps  tabs will show additional options available for that user.

    account device and licenses and apps.png

    Note: You can only add/remove Licenses if you are logged in with a user that has the appropriate role, for example a Global Administrator or License Administrator role.

     

    Management capabilities for Windows 365 Enterprise

    Windows 365 Enterprise management capabilities take place in Microsoft Intune and as such Intune licensing is required. Windows 365 Enterprise Cloud PC's are managed by Intune so anything you can do in Intune is possible on your Cloud PC's, with a few exceptions currently, such as BitLocker encryption. Logging in to the Microsoft Endpoint Manager portal you can see Windows 365 Enterprise Cloud PC management in various places, so let's take a look at where you can find it.

    In the portal you can get Windows 365 information easily by clicking on Explore

    cloud pcs news in Intune.png

    This brings you directly to the Windows 365 provisioning area in Intune which also contains monitoring reports and links to product documentation and forums.

    provisioning using etc.png

    For example, the Remoting connection link brings you directly to Endpoint Analytics reports with lots of useful data.

    remoting connection.png

    and we also have Resource performance.

    resource performance.png

     

    In addition to the above, Windows 365 management is visible in other areas, while we can't take a look at all of them let's review a few.

    Cloud PC related actions on Windows 365 devices

    In addition to the standard actions available to regular devices there are several Windows 365 actions available for Cloud PCs in the Intune portal. The following actions are available on the Overview page after selecting a Cloud PC.

    • Restore
    • Reprovision
    • Resize (preview)
    • Place Cloud PC under review

    and in the left node you have additional related actions such as:

    • Performance (preview)
    • User experience
    • Restore points

     

    managed device actions available to cloud pcs.png

    User experience is available on non Cloud PC's also however Cloud PC's will also see two additional tabs namely

    • Resource performance
    • Remoting connection

    It's also worth noting that at the time of writing that Recovery keys are greyed out (not available) for Cloud PCs and that is because Bitlocker encryption is not currently supported (but is on the roadmap).

    Custom Windows 365 role-based access control (RBAC) roles

    You can create custom RBAC roles for Cloud PC management as explained here. In Tenant administration, click on Roles, select All Roles, click on + Create and select Windows 365 role.

    windowsd 365 role.png

    Once there, select the abilities you want this role to have access to.

    custom role creation.png

     

     

    Configure Alerts for Windows 365 related issues

    You can now configure alerts in Intune to notify your admins via email about problems occurring with your Windows 365 Cloud PCs. The following Windows 365 based alert rules are currently available at the time of writing (January 2023)

    • Azure network connection failure
    • Upload failure for custom images
    • Provisioning failure impacting Cloud PCs

    For details about configuring these alerts see here.

    alert-email.png

     

    Management capabilities via Powershell

    You can do most Windows 365 Cloud PC tasks automatically using PowerShell via Microsoft Graph. To use this automation however you need to fulfill some requirements.

    • Create an Enterprise app
    • Configure permissions
    • Grant consent

    Note: Please note that in this example we will use client secrets as it's in a lab, however in production environments please use Azure Key vault to keep this access secure.

    Create an Enterprise App

    We'll use app registrations in Azure AD to create an Enterprise app that allows us to use Microsoft Graph to carry out our automation work. In Azure AD go to App registrations. Click on + New registration.

    new registration.png

    In the new app registration, give it a useful name like Windows 365 Graph Automation so that you know what it is for, and choose Accounts in your tenant (first option), and optionally  select Web from the Redirect URI (optional)+ choices and point it to a localhost address or one that you have available. Finally click on Register.

    creating app registration.png

    Next, you'll want to add a secret by clicking on Add a certificate or secret, and then once the secret has been created, copy the following values from this app registration as we'll need them in our PowerShell scripts:

    • Application (client) ID
    • Directory (tenant) ID
    • Client credentials (certificate or secret)

    copy these values.png

    Below you can see the secret is created and copied, store that info somewhere safe.

    secret created.png

    Review Permissions

    To review the permissions see the Graph API Documentation for what permissions are needed, keep in mind that these are currently in Beta and subject to change.

    cloud pc graph permissions.png


    Those permissions are basically broken down into three areas, License, Group and Cloud PC

    License permissions

    • User.ReadWrite.All
    • Directory.ReadWrite.All

    Group permissions

    • GroupMember.ReadWrite.All,
    • Group.ReadWrite.All
    • Directory.ReadWrite.All

    CloudPC permissions

    • CloudPC.ReadWrite.All

    But before we get started with those permissions we need to create an App registration.

    Configuring API permissions

    To configure API Permissions for the your app API, Click API permissions, then click + Add a permission, select Microsoft Graph, select Application permissions

    add api permissions.png

    Next, add the following:

    • User.ReadWrite.All
    • Group.ReadWrite.All
    • GroupMember.ReadWrite.All
    • CloudPC.ReadWrite.All
    • Directory.ReadWrite.All

    The permissions are now added

    permissions added.png


    Grant consent

    Don't forget to Grant admin consent for your Tenant after doing so otherwise this won't work.

    grant admin consent.png

    after clicking on Yes you can see the scripts are granted

    consent granted.png

    Sample scripts

    We recently hosted a session about troubleshooting Hybrid Azure AD joined Cloud PC's in a USA Cloud PC meetup. Before our session Dawn Wertz did a demo about this automating Cloud PC actions with Graph and PowerShell. She very kindly provided her sample scripts that she used during her demo and you can download them yourself below. We'd highly recommend that you review the included PowerPoint (thanks Dawn) and video.

    You can download the scripts (and PowerPoint) here. Windows 365 Cloud PC Powershell samples.zip

    After editing one of the scripts in Visual Studio Code and adding the missing info (tenant id, app id, secret on lines 2-4) we could easily connect to Microsoft Graph.

    welcome to microsoft graph.png

    Once connected, it's possible to run commands such as list all the Cloud PCs.

    Get-MgDeviceManagementVirtualEndpointCloudPC

    and the output proves it's working.

    cloud pcs listed via powershell.png

    Recommended reading

     

    Summary

    Managing Cloud PC's as an Admin is possible via a variety of different methods and depending on your subscription level and level of expertise. Windows 365 Business admins can manage their Cloud PC's via two main methods, the Windows365 portal and admin.microsoft.com. Windows 365 Enterprise admins get feature rich device management via Microsoft Intune and can automate repetitive actions using PowerShell scripts and Microsoft Graph. The possibilities are endless !

  23. How can I configure alerts for Windows 365 activity in Intune

    in Windows 365

    Posted

    Introduction

    Microsoft added an ability to configure Alerts (preview) in Intune back in October 2022 and I’ve been using them since then, however I never got around to blogging about it as other things took priority.

    I was reminded that the alerts feature was configured by an email I received yesterday.

    alert-email.png

    clicking on the View alert link in the email brings you to the associated alert info in Intune as shown here.

    alert-in-intune.png

    And clicking on the Azure network connection failure alert gives more data.

    more-data-about-the-failure.png

    Note: You can further drill down into the details to get more data, and if you click on the linked reports it'll show your fail(ed) Azure Network Connections.

     

    So why is this useful ?

    Well in my particular case I caused the issue by shutting down the Routing and Remote Access (RRAS) server. I was doing some hyper-v maintenance and shut down the RRAS server before exporting it, and i never resumed the virtual machine, meaning that the Azure Network Connection check (ANC) would fail.

    But let’s imagine that the RRAS server had an issue causing it to fail to start the service(s) or taking it offline. The email alert is yet another way of alerting admins that something is not right.

    How to configure Windows 365 Alerts

    In the Intune portal select Tenant admin (1), select Alerts (preview) (2) and finally select Alert Rules (3) as shown in the screenshot below.

    configure-alerts.png

    next, configure the alert making sure to select On for Status and add one or more email addresses. Finally, click on Apply.

    configure-alert.png

    The following Windows 365 based alert rules are currently available at the time of writing (December 2022)

    • Azure network connection failure
    • Upload failure for custom images
    • Provisioning failure impacting Cloud PCs

    Currently it seems that the Alert rules are only available for failures or problems. Hopefully we’ll get more alert rules types such as the successful provisioning of a Cloud PC as I requested here. What else do you think we should be alerted about ?

    until next time, adios !

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.