anyweb

you could just create a collection with these special computers and target them with different (custom) client settings with an appropriate forced restart time that works for those users, then deploy those custom client settings to the collection containing those computers and make sure the priority of these client settings is higher than the normal client settings

Introduction Microsoft released Windows 365 Boot (Generally Available) September 2023, and are now adding new abilities to that feature. If you are new to Windows 365 Boot please take a look at the blog post from myself and Paul on the subject here. So what's new ? 2 things stand out actually namely: Shared PC mode Dedicated mode for Windows 365 Boot Described here I took a look at these public preview features and I'll share my findings below. In this blog post, let's look at dedicated mode. But what is it ? well according to the official blog post it allows you to assign a dedicated corporate device to a users Cloud PC and to...: So let's give it a try. Step 1. Configure policy First off, open Intune and browse to the Windows 365 node. From there click on Windows 365 Boot Public Preview (or Windows 365 Boot) to launch the guided scenario. That will launch a new wizard, have a read and then click Next On the Basics screen, give the Resource prefix a name and select Dedicated mode from the options. You can also optionally use the device name template, but I won't bother in this example. In the screenshot below I've highlighted a box in red to show what resources will be created when you complete the wizard. Click Next and you'll be presented with an Endpoint updates screen, select your desired options there to ensure that your Corporate devices used for Windows 365 Boot will get updates according to your desired schedule. Your Cloud PCs will have their own update settings and could for example be managed by Windows Autopatch. Click Next once done. The next screen will show settings available. Some will be greyed out and not selectable (as per my screenshot) as they require you to have already created a VPN/Wi-Fi profile or securty baseline. If you have previously created these profiles you can select them here. In addition you can select a language, security baseline and connection timeout (default is 5 minutes) which you can extend as far as 20 minutes, although I think that the end user would be pretty miffed if they had to wait 20 minutes to connect to their Cloud PC or before an error message occurred. next, you can create a new group (recommended) or use an existing group. Pay close attention to the note, groups shouldn't have profiles or apps assigned to them yet. If necessary remove resources from the group and add them back when you are finished setting up Windows 365 Boot. Finally review the summary and click create. You'll get a nice summary screen complete with links to Docs explaining the features being created as part of the Windows 365 Boot feature. Step 2. Prepare a computer Next you need to prepare a computer for use with Windows 365 Boot dedicated mode, as this is still in public preview it needs to be enrolled in the Windows Insider Dev Channel and running Windows 11 Insider Preview Build 23601 or higher. You can configure Intune update policy to target the device with this setting. Once the computer is at the desired level (Windows Insider Preview dev channel and greater than Windows 11 Insider Preview Build 23601) you can reset the device and add it to the Windows 365 Boot dedicated mode group you created in step 1. Finally, hand the computer over to the user to enroll into Windows Autopilot. Step 3. Experience Windows 365 Boot dedicated mode Now everything is ready to test dedicated mode. Let the device get policy and once done you should see a new login experience. You can use Windows Hello for Business biometrics or PIN to login to your Cloud PC! the user logs on and... it should go pretty much straight to the Cloud PC desktop, but if there are any network issues, or anything that slows down that direct internet connection between the corporate device and the Cloud PC then you may see some logon delays as the bits and bytes navigate their way through VPN's. Below is an example of that. When network delays cause interference, they'll see the new login experience along with some new helpful text to explain what is going on As this was my first time logging on some work had to take place in the background and I saw the following followed by this, notice the timer showing how much time is left, that's the setting that you configure in the policy creation some moments later followed by your Cloud PC desktop Success ! Summary Dedicated mode is a cool new Windows 365 feature and one I'd recommend you start testing right now in public preview. This gives users the ability to use real hardware to connect quickly to their Cloud PC and informs them when things are being delayed due to traffic congestion etc. If you'd like to see how Windows 365 Boot shared mode differs, then please check out my blog post here.

normally with Virtual Machines you need to first remove any snapshots on that vm, power down the vm and then increase the size of the disk in question,after powering on the vm, you'll see the new expanded space on the disk in disk administration and you can expand the disk into the remaining space it would be a good idea to have a backup just in case, have you tried asking your VMWare guys about doing that operation ?

hi there, is this server virtual or real hardware ?

hi @LinPie I'm happy to hear it's working now! thanks for the update

normally you'd fix the expiring certificates first https://www.niallbrady.com/2021/12/26/cloud-attach-endpoint-managers-silver-lining-part-9-renewing-expiring-certificates/ i've done a video too however, you'll have to adapt the above for use with whatever boot media you created, and create NEW boot media with valid certificates in place.

no, that is not necessary, leave the old boot image until you are sure you no longer need it, then clean it up

it will use LIFO method (LAST IN FIRST OUT), meaning, the last task sequence deployed to whatever collection your computer is in, that is the boot image it will pull down, if you select a different task sequence deployed to the same computer or collection, and that task sequence has a different boot image attached to it, then it will stage that new boot image once you select the task sequence

if you cannot find the boot image you manually created, make sure to first 'import' it by right clicking boot images, and choosing Add boot image

to change the boot image to a newly created one, first make sure that PXE boot is enabled on the boot image itself (if you are using Windows Deployment Services to serve boot images) and 'command support' (f8) and that it's distributed to your distribution points, after that, edit your task sequence and change the boot image assigned to that task sequence to use the 'new' boot image

what does the smsts.log file reveal ? the fact that it's not domain joined when it's failing points to lack of network connectivity, you can review the netsetup.log in C:\Windows\Debug to find out why it's failing to join the domain, start with those 2 issues first to figure out how to solve it

hi Lin did you run the script i posted to patch your boot.wim exactly as I explained ? if so then storage will not be a problem when pxe booting using that boot image, so i think you've missed something, please verify the steps i posted above again

yes of course it's easier, but if your company uses Windows 10 currently and wants minimal impact to a working ConfigMgr infrastructure, then what ?,. that is the purpose of this blog post. Surface Go 4 currently supports both windows 10 22h2 and windows 11 from Microsoft so the challenge here was to get it all to work with minimal impact to 'production'. I did test with Windows 11 ADK and that has it's own issues including the inability to use bitlocker during imaging. See the known issues here https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/configs/support-for-windows-adk

you could have a detection script for the KB like so, change the kb number to whatever kb you are looking for # niall brady 2023/10/04 # check if the KB is actually installed # $result = systeminfo.exe | findstr KB5030310 if ($result){ write-output "Found KB5030310" exit 0} else { write-output "Could not find KB5030310" exit 1}

check the security event viewer logs on the server hosting the share to see how your computer is connecting

i just checked my own x64 boot image and it's 1.8GB so the size is ok, mine downloads very fast in my lab environment, it could be your switches in the network that are slowing it down

hi, without more info about this it's hard to tell, has it always been 18 minutes ? is the distribution point hosting the boot image far away from the device you are pxe booting ? or is this only happening on specific models ? more info is needed please

no my point was, in order to see WHEN pxe boot started you need to get the timestamp from the smspxe.log then, compare that with the smsts.log and you can work out exactly how long that device took to boot to the PXE password prompt (if enabled)

there's nothing revealed here, it took a couple of minutes to launch WinPE, search the SMSPXE.log on the primary or pxe enabled dp for the mac address of this device to see when it really started PXE boot.

there is no more x86 boot image in the Windows ADK and that is why it fails to update the x86 boot image, This is by design: The 32-bit versions of Windows PE (WinPE) in the WinPE add-ons for Windows 11 and Windows Server 2022 aren't supported. for more info and a possible workaround see here > https://learn.microsoft.com/en-us/answers/questions/892268/unable-to-update-x86-default-boot-image-after-upgr

Introduction This is Part 2 of a new series of guides which will cover managing Windows 365 Cloud PC's using PowerShell and Microsoft Graph. This mini series should help you get started with automating and managing your Cloud PC's using PowerShell via Microsoft Graph. If you are new to Windows 365 Cloud PC's then please read our previous series called Getting started with Windows 365 available here. At the time of writing, Paul is a 7 times Enterprise Mobility MVP based in the UK and Niall is a 13 times Enterprise Mobility & Windows and Devices MVP based in Sweden. Below you can find all parts in this series: Automating Windows 365 part 1 - Introducing Graph and setting up Visual Studio code Automating Windows 365 part 2 - Using Graph X-Ray <- you are here Automating Windows 365 part 3 - Provisioning Cloud PC's Automating Windows 365 part 4 - Managing your Cloud PC Automating Windows 365 part 5 - Cloud PC reports In this part we'll cover the following: Introducing Graph X-Ray Installing Graph X-Ray Using the extension Running code produced by Graph X-Ray Related reading Summary Introducing Graph X-Ray Graph X-Ray is a web browser extension created by a bunch of very smart people at Microsoft including Merill Fernando (Senior Product Manager). It was designed as part of a hackathon project to work with various web-browsers including Google Chrome and Microsoft Edge running on Windows or MacOS. The extension gives you a sneak peek at the API calls that Graph is making when you do various actions in any app or console that uses Graph API. Graph X-Ray does more than the built in Network developer tools included with these web-browsers, for example, it simplifies some of the calls as well as giving you the commands in other programming languages. Below is a sample of data from Network developer tools output when viewing the details of a Windows 365 Cloud PC in Intune. Without filtering, you have to really dig through masses of data to find the Graph calls in the output. If we compare output of the same action using Graph X-Ray highlighted in the green box below, you can see it's much easier to comprehend and more useful for scripting a solution. In addition, it removes all the unnecessary information captured via Network developer tools and only shows the Graph calls we are interested in and if available the respective cmdlets that can be used to get that info using PowerShell. Graph X-Ray will definitely make your job easier when it comes to automating things with Windows 365, but it won't do all the work for you, so be prepared to get stuck in. Installing Graph X-Ray Installing Graph X-Ray is simple. You can download it directly from http://graphxray.merill.net or if using Microsoft Edge click here. After downloading the extension by clicking on Get, you'll need to Add the extension to your browser. Click on Add extension. You'll be informed of the progress. Using the extension After installing the extension (in Edge in our example), you can access it via Developer Tools by using the shortcut keys CTRL+SHIFT+I or by clicking on the 3 dots or ellipses (1) and then selecting More Tools (2) and finally clicking on Developer Tools (3) as per the picture below. Once done, click on + and then select the Graph X-Ray extension. The Graph X-Ray developer tool is now available in your web-browser. Once enabled, you can select the chosen language (PowerShell, C#, Java, JavaScript, Objective C or Go) by clicking on the drop down, we will focus on PowerShell examples only for this mini-series. As Graph X-Ray is focused on revealing hidden gems in apps/portals that use the Graph API, you can start seeing it's power by launching a portal such as Microsoft Intune (which uses the Graph API) to review some of the data it reveals about your Windows 365 Cloud PC's. So let's get started. Below we browsed to the Intune console and launch Graph X-Ray as shown above, next we clicked on the Windows 365 Provisioning node in Intune. The amount of data revealed is shown in the Graph X-Ray window. From that window you can copy snippets of code that interest you or save the entire script by clicking on Save script. And then you can open that script in Visual Studio Code If you get a warning about restricted spaces, make your choice to continue and the Graph X-Ray session script opens in Visual Studio Code. But remember even though we saved a script of what we were doing at the time (reviewing the Windows 365 node in Intune) it won't be enough to do everything that you just revealed. So let's dig deeper. Running code produced by Graph X-Ray Next, let's try and run some of the code produced by Graph X-Ray to see how it helps us. If we simply run the script downloaded above, the following occurs. Lots of errors in red highlighted in the screenshot below. As we said before, Graph X-Ray helps you but doesn't do everything. In the example errors highlighted above, we can see it's trying to import a module that isn't already installed, so to fix that you'll need to first install any module that is used in the script you are creating. To fix things in the downloaded script, close Visual Studio Code and restart it as Administrator, this is only needed to install those missing PowerShell modules. Once done, the edited script is shown below, note that we had to run it a few times and browse the output to see if there were any missing scopes. The scopes are added one after another in the script and when added, you'll be prompted to accept those new permissions. After Approving that, and running the script the output below shows all the data generated from the edited 'save script' content. Success ! Below is a copy of the script we edited in the GIF above. # windows-noob.com 2023/12/29 # https://www.windows-noob.com/forums/topic/23345-automating-windows-365-part-1-introducing-graph-and-setting-up-visual-studio-code/ # our additions below, to allow the 'save-script' script to run without error Install-Module Microsoft.Graph.Beta.Identity.DirectoryManagement Install-Module Microsoft.Graph.Beta.DeviceManagement Install-Module Microsoft.Graph.Beta.DeviceManagement.Functions Install-Module Microsoft.Graph.Beta.DeviceManagement.Administration Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration # now we need to Connect to Graph, with the scopes needed for accessing the appropriate information Connect-MgGraph -Scopes "CloudPC.Read.All", "Directory.Read.All", "DeviceManagementConfiguration.ReadWrite.All" # The remainder of the script below is downloaded directly via 'save script' in Graph X-Ray Import-Module Microsoft.Graph.Beta.Identity.DirectoryManagement Get-MgBetaSubscribedSku Import-Module Microsoft.Graph.Beta.DeviceManagement Get-MgBetaDeviceManagement Import-Module Microsoft.Graph.Beta.DeviceManagement.Functions Get-MgBetaDeviceManagementVirtualEndpointEffectivePermission Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Get-MgBetaDeviceManagementVirtualEndpointOnPremiseConnection Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Get-MgBetaDeviceManagementVirtualEndpointOnPremiseConnection Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Get-MgBetaDeviceManagementVirtualEndpointCloudPc -CountVariable CountVar -Top 1 -Filter "servicePlanType eq 'enterprise'" Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Get-MgBetaDeviceManagementVirtualEndpointCloudPc -CountVariable CountVar -Top 1 -Filter "servicePlanType eq 'enterprise'" Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Get-MgBetaDeviceManagementVirtualEndpointCloudPc -CountVariable CountVar -Top 1 -Filter "status eq 'provisioned' and servicePlanType eq 'enterprise'" Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Get-MgBetaDeviceManagementVirtualEndpointCloudPc -CountVariable CountVar -Top 1 -Filter "status eq 'inGracePeriod' and servicePlanType eq 'enterprise'" Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Get-MgBetaDeviceManagementVirtualEndpointCloudPc -CountVariable CountVar -Top 1 -Filter "status eq 'failed' and servicePlanType eq 'enterprise'" Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Get-MgBetaDeviceManagementVirtualEndpointCloudPc -CountVariable CountVar -Top 1 -Filter "status eq 'inGracePeriod' and servicePlanType eq 'enterprise'" Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Get-MgBetaDeviceManagementVirtualEndpointCloudPc -CountVariable CountVar -Top 1 -Filter "status eq 'provisioned' and servicePlanType eq 'enterprise'" Import-Module Microsoft.Graph.Beta.DeviceManagement.Administration Get-MgBetaDeviceManagementVirtualEndpointCloudPc -CountVariable CountVar -Top 1 -Filter "status eq 'failed' and servicePlanType eq 'enterprise'" Keep in mind that you might want to edit the -Top 1 references to -Top 5 or some other figure to increase the output when making your own scripts based on the above. Related reading Introduction to Graph X-Ray Microsoft Graph Overview - https://learn.microsoft.com/en-us/graph/overview Microsoft Graph X-Ray Edge add-on - https://microsoftedge.microsoft.com/addons/detail/graph-xray/oplgganppgjhpihgciiifejplnnpodak PSCloudPC - https://pscloudpc.com/ Summary The Graph X-Ray extension is a fantastic tool to help you find out what is going on behind the scenes for Graph API tasks. Using the Graph X-Ray extension in your web browser makes it easier to automate many tasks for your Windows 365 Cloud PC's using PowerShell.

Introduction The Configuration Manager team at Microsoft have been busy and have released a new Technical Preview release, this time version 2311. This release has several new features but the one I find most interesting is the addition of ARM64 support for OSD. Configuration Manager first provided client support for ARM64 in Configuration Manager 2107 with the update rollup. ARM based devices running Windows are increasing. Microsoft have previously released ARM based hardware such as the Surface Pro X or Windows Developer kit 2023. I wouldn’t be surprised if Microsoft pushes out their own ARM64 chips soon, and having the support to re-image these ARM based hardware from Configuration Manager is a bonus. So what’s possible with this new ability in Configuration Manager ? Configuration Manager operating system deployment support is now added on Windows 11 Arm64 devices. Currently Importing and customizing Arm64 boot images, Wipe and load Task Sequence, Media creation Task sequence and WDS PXE for Arm64 is supported. To test it out you’d need ARM based hardware, which I don’t have, but I can at least download the ISO from Microsoft Volume License Servicing center (or from here) and then add it to TP2311. Install Windows 11 ADK (september 2023) But before doing that it was time to update Windows ADK to the latest version which is Windows 11 ADK (updated September 2023). This version of the ADK isn’t perfect as there are some known issues with OSD but it’s required for getting ARM64 OSD support to work. Previous versions can be imported but will fail to PXE boot. Download Windows 11 ADK here. After installing both that and the Windows PE environment, reboot the server. Update existing boot images After that, update your boot media and choose the option to reload the existing boot images with Windows PE from the installed ADK. Add ARM64 boot image Now it’s time to add the ARM64 boot media and for that you need to use the boot WIM file from the newly installed Windows 11 ADK. Thanks goes to fellow MVP Yutaro Tamai @ https://sccm.jp/ Twitter : tamai_pc for that tip. I copied the winpe.wim file from my ADK path shown above to my OSD sources folder and added that as the ARM64 boot image. after importing the boot image, don’t forget to make it available to your PXE environment. and review the SMSPXE.log file to see all goes well. Adding the Windows 11 ARM64 media Next, I downloaded the Windows 11 23H2 ARM64 ISO and added it to ConfigMgr. After importing the WIM file you can review its properties by clicking on the Images tab to verify that it’s ARM64 architecture. after importing the image it’s ready to be distributed to your dp’s and added to a task sequence. Modify task sequence Finally, modify an existing task sequence to use the ARM64 boot image and modify the Apply Operating System step to use the ARM64 Install.wim file. Finally you can test PXE boot. Unfortunately I currently don’t have any of that hardware available yet but once I do, i’ll give it a twirl and update this blog post. cheers niall

Introduction I got my hands on a test unit, a Microsoft Surface Go 4, and wanted to see if we could image it via SCCM as we currently are doing for Surface Go 3 models. However, the problems became apparent quickly. Problem The problems were lack of storage (no HDD detected) if using an Windows 10 ADK version 2004 that hasn’t been updated with the latest servicing stack and cumulative update to address CVE-2023-24932, or if using an ADK based on Windows 11, the partitioning steps hangs forever along with the other issues that ADK 11 has (preprovision bitlocker fails, no vbs support). So how to fix this ? The easiest choice was to grab the driver pack from Microsoft and inject the missing storufs.inf driver into the Windows 10 ADK version 2004 boot wim. So I went down what I thought was the path of least resistance. Download the drivers (MSI) You can download the MSI drivers for the Surface Go 4 from here, select the appropriate OS (Windows 10 or Windows 11). Extracting the drivers Once you’ve downloaded the MSI, you’ll want to extract the drivers from the pack, to do that use the cmdline below, replace it with the MSI name you want to extract and point it to the exact folder you want the drivers to extract to. Do not have any spaces between TARGETDIR and the = sign. MSIEXEC /a SurfaceGo4_Win10_19045_23.072.25310.0.msi /qb TARGETDIR=C:\drivers\SG4 But guess what, those UFS storage drivers are not available in the downloadable MSI. You will need to rip the needed drivers from the factory image so keep that in mind before you blow it away. I found the needed files in the following folder on the factory install: C:\Windows\Inf The drivers and were dated 2023/04/13 on my example unit, and the needed are: storufs.inf storufs.sys However even with those files it’s not enough, you cannot import them into the boot.wim image as they are not signed (missing the CAT file). And the necessary CAT file is nowhere to be found in the factory install image. So we are back to square one. I asked Microsoft to provide me with this signed driver but for some reason was declined. Instead they advised me to patch the boot images. The solution To fix this you’ll need to patch your ADK 10 version 2004 boot wim to include the latest SSU and CU updates. In my testing that was the October CU. Here’s the script used, yes it’s a batch file but it works just fine, there is a PowerShell script available from Microsoft (here) but you’ll need to modify it heavily before starting. Copy the downloaded CU to the appropriate folder before starting REM use this to patch ADK 2004 with latest CU/SSU/optional components REM to start with, copy the CU to C:\dev\patch_winpe\CU REM make sure to REMOVE any pre-existing C:\winpe_amd64 before starting! REM thanks to Microsoft for the script, modified by Niall Brady, 2023/11/23 REM - > copy a fresh boot.wim without any component (you can use the boot.wim from your Configuration Manager Installation as well to start with) REM CLEANUP if needed! DISM.exe /Unmount-Wim /MountDir:C:\winpe_amd64\mount /discard DISM.exe /Cleanup-Wim call "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\copype.cmd" amd64 c:\winpe_amd64 REM - Create some temp folders... MD c:\winpe_amd64\SSU MD c:\winpe_amd64\CU MD c:\winpe_amd64\temp REM - > expand SSU expand.exe C:\dev\patch_winpe\CU\windows10.0-kb5031356-x64_65d5bbc39ccb461472d9854f1a370fe018b79fcc.msu -f:*ssu*.cab c:\winpe_amd64\SSU REM - > expand CU expand.exe C:\dev\patch_winpe\CU\windows10.0-kb5031356-x64_65d5bbc39ccb461472d9854f1a370fe018b79fcc.msu -f:*Windows*x64.cab c:\winpe_amd64\CU REM - > mount the boot.wim file for servicing operations dism.exe /Mount-Wim /WimFile:C:\winpe_amd64\media\sources\boot.wim /index:1 /MountDir:C:\winpe_amd64\mount REM - > Apply SSU dism.exe /image:C:\winpe_amd64\mount\ /Add-Package /PackagePath:c:\winpe_amd64\SSU\ REM - > adding the core components (bare minimum requirement by Configuration Manager) REM Scripting (WinPE-WMI) dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-WMI.cab" dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-WMI_en-us.cab" REM Scripting (WinPE-Scripting) dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-Scripting.cab" dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-Scripting_en-us.cab" REM Network (WinPE-WDS-Tools) dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-WDS-Tools.cab" dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-US\WinPE-WDS-Tools_en-us.cab" REM Startup (WinPE-SecureStartup) dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-SecureStartup.cab" dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-SecureStartup_en-us.cab" REM - > adding optional / additional components (do not forget to add them, if needed) REM HTML (WinPE-HTA) REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-HTA.cab" REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-HTA_en-us.cab" REM Database (WinPE-MDAC) REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-MDAC.cab" REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-MDAC_en-us.cab" REM Storage (WinPE-EnhancedStorage) REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-EnhancedStorage.cab" REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-EnhancedStorage_en-us.cab" REM Microsoft .NET (WinPE-NetFx) REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-NetFx.cab" REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-NetFx_en-us.cab" REM Windows PowerShell (WinPE-PowerShell) - this requires WinPE-NetFx to be added first REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-PowerShell.cab" REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-PowerShell_en-us.cab" REM Windows PowerShell (WinPE-DismCmdlets) - this requires WinPE-PowerShell to be added first REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-DismCmdlets.cab" REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-DismCmdlets_en-us.cab" REM Windows PowerShell (WinPE-StorageWMI) - this requires WinPE-PowerShell to be added first REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-StorageWMI.cab" REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-StorageWMI_en-us.cab" REM Windows Secure Boot Cmdlets (WinPE-SecureBootCmdlets) - this requires WinPE-PowerShell to be added first REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-SecureBootCmdlets.cab" REM dism.exe /Add-Package /Image:"C:\winpe_amd64\mount" /PackagePath:"c:\program files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-SecureBootCmdlets_en-us.cab" REM - > Apply CU dism.exe /image:C:\winpe_amd64\mount\ /Add-Package /PackagePath:c:\winpe_amd64\CU\ REM pause here to add any custom stuff pause REM - > final step unmount the boot.wim and commit the changes dism.exe /unmount-Wim /MountDir:C:\winpe_amd64\mount /commit After patching the boot.wim, import it back into SCCM, distribute it to your distribution points and attach it to your task sequence. Note: Keep in mind that you’ll also need the patched version of Windows 10/Windows 11 operating system wim file to the same CU level otherwise you’ll get a BSOD after applying the image. I hope this helps someone cheers niall Related reading Surface Go 4 drivers (MSI) – download October 2023 CU – download Windows 11 ADK 22H2 – download Surface Recovery Image download – Surface Recovery Image Download – Microsoft Support PowerShell script to modify boot images Manage boot images for CVE-2023-24932

I'd open a Microsoft ticket and ask them to investigate

did every previous upgrade work without problem before this ? do you have any non microsoft AV software installed on the site server ?