anyweb

hi @Wizu I've now finished updating the changes and testing to the new release (1.5.28) I plan on blogging about the changes shortly, if you'd like to try it before I blog it then please pm me and i'll make the code available,

Microsoft Outlook users advised to urgently apply the security patches provided by Microsoft Hannover, Germany – 16 March 2023 – A severe security vulnerability has been discovered in Microsoft Outlook, which is currently being exploited by cybercriminals. The vulnerability, identified as CVE-2023-23397 with a CVSS score of 9.8, permits a remote, unauthorized attacker to compromise systems simply by transmitting a specifically crafted email. This malicious email enables the attacker to gain unauthorized access to the recipient’s credentials. More widespread attacks that target this vulnerability are expected Umut Alemdar, Head of the Security Lab at Hornetsecurity, said, “We expect that the likelihood of more widespread attacks targeting the CVE-2023-23397 vulnerability to increase, as public proof-of-concepts have already been released. We therefore highly recommend that all users of Microsoft Outlook apply the security patches provided by Microsoft as soon as possible.” He confirmed that Hornetsecurity detects emails that exploit the vulnerability and quarantines them to prevent emails from reaching the victim’s inbox, and added, “The Security Lab at Hornetsecurity is continuing to monitor the threat landscape to ensure that customers are protected from the latest cyber threats.” Exploitation occurs even before the email is displayed in the preview pane The exploit is initiated by fetching and processing a malicious email by the Outlook client, potentially leading to exploitation even before the email is displayed in the preview pane. It triggers a connection from the victim to a location controlled by the attacker. This results in the leakage of the victim’s Net-NTLMv2 hash, a challenge-response protocol used for authentication in Windows environments. The attacker can then relay this information to another service and authenticate as the victim, further compromising the system. The complexity of the attack is low, and it has been seen in the wild according to Microsoft, with the exploit being used to target the European government, military, energy, and transportation organisations. It was initially reported to Microsoft by CERT-UA (the Computer Emergency Response Team for Ukraine). A proof-of-concept created by the Hornetsecurity’s Security Lab team demonstrates that the exploit is hard-to-detect since all anti-malware and sandbox services incorporated into VirusTotal were unable to recognize it as malicious. Recommended actions For a list of affected versions, and recommended action to secure your organization, please click here.

Introduction If you are new to Windows 365 Cloud PC's please check out our series about Getting Started with Windows 365. Microsoft recently blogged about the ability to use alternate ANCs (Azure Network Connection) when Provisioning Cloud PCs so that if one ANC goes down it can fall over to the next in line according to priority. You can read that blog post here. Lets look at the new feature in detail. But first, what is a provisioning policy. This policy defines what settings you will apply to new Cloud PCs when they are provisioned for your users. When creating a new provisioning policy you have to enter some details, such as join type, network type, and so on. In this case we are interested in the type of network we'll use, it can be Microsoft hosted network Azure network connection as you can see here The reason there are two types of network depends entirely on your needs. If you want minimum fuss and minimum requirements when creating the policy choose the Microsoft hosted network, that way you don't have to create a virtual network or have an Azure subscription tied to your Cloud PCs connectivity. If on the other hand you want to have more control over the type of network settings such as specifying individual DNS servers, IP ranges or address spaces then you need to choose Azure network connection and create those separate virtual networks (vnet) in your Azure subscription. Once you've decided which network join type to use, you are shown active working ANCs in your environment at the time you started creating the provisioning policy. Those ANC's listed are based on the list of healthy ANC's you have at time of creation of the provisioning policy, so at the time I created this provisioning policy, the following ANCs were healthy. Note that it will only list those ANCs based on the join type you select. Note: You should only add an alternate ANC if you fully understand the implications of provisioning Cloud PCs in a different ANC. If any of the above are unhealthy, they won't appear in the drop down list. Select those that you want included in this provisioning policy. You'll notice that a new Network prioritization UI appears behind your choices. Clicking away from the drop down menu allows you to sort your ANCs by your chosen priority. You can click and drag the ANC from one priority to another within your list. After sorting your ANCs by priority your new list is shown UI note: It would be nice if all the information in each of the columns for each ANC was shown, right now you need to scroll right to see what's what. Continue through the wizard to complete your Alternate ANC provisioning policy. The policy is listed below, note how the Azure network connection column shows a + What about existing provisioning policies ? You can also edit existing provisioning policies to add alternate ANCs, however it's not that intuative. To do so, open the properties of an existing policy and click Edit at the General settings. in the Azure network connection section, click the drop down menu to show other healthy ANC's next, make your selection and change priority as shown earlier Verifying alternate ANCs in your provisioning policy Now that I've created an Alternate ANC provisioning policy with three healthy ANCs (listed below), I decided it was time to see this working in a lab. W365Demo1_anc W365Demo2_anc W365 North Europe HAAD ANC For this test I forced one of the three Routing and Remote Access Service (RRAS) servers which host services used in the hybrid azure network connections into an unhealthy state by shutting down the corresponding on premises server. By doing this I basically forced the following ANC offline. W365Demo1_anc Once that ANC was offline I retried the network tests in each respective ANC and then refreshed to see the latest status. You can clearly see that W365Demo1_anc is listed with a status of Checks failed. The next logical step is to provision a Cloud PC for a user targeted with the Alternate networks in windows 365 provisioning policy. I then added a user to the group targeted with the this provisioning policy and waited for it to provision. The provisioning started after a few minutes, but strangely it listed the very ANC that i took offline in the Azure network connection status column. This was not what I expected, but maybe just a UI glitch. According to the priority I specified in my alternate ANC list, I expected W365Demo2_anc to be the ANC used during provisioning as W365Demo1_anc was already offline and marked unhealthy. I've made the Product Group aware of this. I'll update this blog post once they reply back. After completing the provisioning process I could see that it correctly listed the second of three available ANC's from my list (as the first was offline). That's a result ! Great job Microsoft ! Recommended reading Using Alternate ANCs in Windows 365 - https://techcommunity.microsoft.com/t5/windows-it-pro-blog/using-alternate-ancs-in-windows-365/ba-p/3780384 Getting started with Windows 365 - https://www.windows-noob.com/forums/topic/23040-getting-started-with-windows-365-part-1-introduction/ Configuring alerts for Windows 365 Cloud PC's - https://www.windows-noob.com/forums/topic/23164-how-can-i-configure-alerts-for-windows-365-activity-in-intune/ Create and assign provisioning policy - https://learn.microsoft.com/en-us/windows-365/enterprise/create-provisioning-policy#continue-creating-a-provisioning-policy Summary Providing the ability to use multiple/alternate ANC's during provisioning of a new Windows 365 Cloud PC is an important step forward in reducing downtime when provisioning new Cloud PC's. The recommended actions in Matt's blog post do point out that you should keep an eye on the health of your ANC's and while that is nice in theory, the existing methods of doing that are to look at the ANC health in the Azure Network Connections view directly, or read the emails generated by the alerting feature. I'd like to see a report that shows the reliability/health of your ANC's over time, so that it's easy for the admin to pinpoint problem locations (during specific time periods) and fix them. This new feature only applies to the actual provisioning of the new Cloud PC. It does not apply to existing Cloud PC's that may be affected if an ANC goes unhealthy.

Click on the area I marked in yellow

nevermind i figured it out, it was a forum setting you should be able to mark it as solved now

i admit i'm stumped, do you have time to do a remote session with me so I can see exactly what you see ?

hmm i'll keep digging, I've not found the answer yet, but i'll try !

does this help ? https://invisioncommunity.com/news/invision-community/45-marking-as-solved-r1187/ do you see the option by clicking in the top right of a post ?

heh good question, let me try and figure it out, it could be a forum setting that i need to enable, i'll take a look and report back later

@sugarpickle check your pm

did you read the post above it at all ?

glad you got it sorted and that you posted the solution

without logs on a failing client it's hard to understand your problems, so.... can you zip up and attach the smsts.log file from a pxe booted device that has issues ?

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). 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: Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 1 Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 2 Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 3 <- you are here 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. 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 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. 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. This will leave you with 2 new encoded scripts, shown below Open each of the respective encoded text files in notepad and mark all text within (CTRL+A) then COPY the text (CTRL+C), The paste that copied text into the respective variable in the Win.AP.CreateScheduledTask_AddWhiteGloveDeviceToAzureAdGroup.ps1 script shown here. 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 Registry: HKEY_LOCAL_MACHINE\SOFTWARE\windows-noob\WhiteGlove Value name: KeyUploadedAfterWhiteGlove as per the screenshot below: Detection rules Rules format: Manually configure detection rules Detection rules File: C:\Windows File or folder: Installed_WhiteGlove_Add_device_to_aad_group.txt Detection method: File or folder exists finally, assign the Win32 app as Required to our WhiteGlove Computers Azure ad group created in part 1. 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. 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. 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... Verify it's the same in Intune and next, trigger a BitLocker key rotation action in Intune You can then confirm on the device that it's rotated and the new recovery key information is stored in Azure. Job done ! Troubleshooting This Win32App creates some files which are extracted to C:\Windows\Temp. 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:\Windows\Temp'... 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:\Windows\Temp\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

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). 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: Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 1 Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 2 <- you are here Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 3 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 Registry: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\windows-noob\WhiteGlove as per the screenshot below: Detection rules Rules format: Manually configure detection rules Detection rules File: C:\Windows File or folder: Installed_WhiteGlove_Bitlocker_key_uploader.txt Detection method: File or folder exists Next, configure the following Dependencies for the Win32 app finally, assign the Win32 app as Required to our WhiteGlove Computers Azure ad group created in part 1. 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. This generates an EventID (Microsoft-Windows-User Device Registration/Admin">*[System[(EventID=300)) 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. Troubleshooting This Win32App creates some files which are extracted to C:\Windows\Temp. 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:\Windows\Temp'... 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:\Windows\Temp\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: Checking in Intune we can see the key is uploaded, job done i'd say ! 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 Windows Autopilot for pre-provisioned deployment (Public preview) - https://learn.microsoft.com/en-us/mem/autopilot/pre-provision 3 things to know before deploying bitlocker with Intune - https://brookspeppin.com/2022/07/06/3-things-to-know-before-deploying-bitlocker-with-intune/