Jump to content


anyweb

Root Admin
  • Posts

    9,103
  • Joined

  • Last visited

  • Days Won

    362

Everything posted by anyweb

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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}
  8. check the security event viewer logs on the server hosting the share to see how your computer is connecting
  9. 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
  10. 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
  11. 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)
  12. 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.
  13. 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
  14. 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.
  15. 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
  16. 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
  17. did every previous upgrade work without problem before this ? do you have any non microsoft AV software installed on the site server ?
  18. hi Michael, how long have you waited ? how many clients are managed by the primary ? does the cmupdate.log reveal anything interesting ?
  19. interesting! thanks for updating the thread
  20. weird, is the file blocked or corrupt in any way ?
  21. Introduction This is Part 1 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 <- you are here Automating Windows 365 part 2 - Using Graph X-Ray 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 Setup Visual Studio Code Installing Visual Studio Code Installing the PowerShell Extension Enabling ISEMode Initial connection to Graph Permissions Testing permissions using Graph Explorer Related reading Summary Introducing Graph Microsoft have summarized Graph as: ChatGPT summarized it as follows: OK so now we know that we can use Microsoft Graph to our advantage, to interact with data that we have access to and build scripts and apps to automate common tasks. But before we do let's take a look at one quick way of interacting with Graph, and that is via an online tool called Microsoft Graph Explorer which in turn uses the Graph API. Microsoft Graph Explorer lets you make requests and see responses against Microsoft Graph. To launch Graph Explorer click here. You'll be presented with a view such as below. Login to your tenant If you are new to Graph Explorer, there are a few things to keep in mind: 1. Allows you to select the method, eg: GET, POST, PUT, PATCH, DELETE 2. Select the context: v1.0 or beta 3. The address of your API call, including any variables or filters 4. Tabs containing more info 5. Sub set of Graph REST API examples Now you are ready to perform your first query, so go with the default selection and click on Run Query As you can see it returns a lot of data which we can use in our automation. Cool! Setting up Visual Studio Code Now that we know a little bit about Microsoft Graph, the next step is to install and configure a tool to connect with it effectively, and to do that we'll use Visual Studio Code. Visual Studio Code is more powerful and feature rich than the built in free PowerShell Integrated Scripting engine in Windows (PowerShell ISE) so let's use it. Installing Visual Studio Code It's free, to get started you'll need to download it first - https://code.visualstudio.com/docs/?dv=win Once downloaded, launch the executable to start setup. select your options and it's done. Click on Finish to launch Visual Studio Code. Installing the PowerShell Extension After installation, it's time to add a PowerShell extension. Click on Extensions. Search for PowerShell and click on Install Connect with Visual Studio Code Once you've installed the PowerShell extension, close Visual Studio Code and launch it again as an Administrator (Run As Administrator). Click on the Settings icon, and choose Command Palette Search for IseMode and select Enable IseMode from the list of choices This will force Visual Studio Code to look like PowerShell ISE. Initial connection to Graph Now we have everything in place, let's create our first script to make our initial connection to Graph from Visual Studio Code. To do that, click on File, give your script a suitable name such as connect to microsoft graph.ps1 Visual Studio Code now knows how to deal with the PowerShell commands as we've installed the PowerShell extension. Type in the following command: Install-Module Microsoft.Graph.Beta.DeviceManagement.Administration Once done, click on the run symbol (triangle) and notice the question. After answering Yes, PowerShell will start downloading the needed bits. After it has finished installing you can verify by running the following code Get-InstalledModule Microsoft.Graph.Beta.DeviceManagement.Administration You can do that in Visual Studio Code by typing the command, selecting it and then running the selected code. Finally, we want to connect to our installed module by using the the Connect-MgGraph command. Connect-MgGraph -Scopes "CloudPC.Read.All" You may get prompted for permissions (more on that below), if so click Accept. If required, you can also select the check box "Consent on behalf of your organization" to make it easier for other admins to do the same requests. Permissions In order to access the wealth of data in Microsoft Graph you'll need to provide permissions. For Cloud PC management, we can add an initial subset of permissions to review data. 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. 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 Testing permissions using Graph Explorer Launch Graph Explorer. To verify our permissions we'll try a simple Cloud PC related task, List all Cloud PCs. To list all your Cloud PC's using Graph Explorer and Microsoft Graph API, try the following. GET https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/cloudPCs You'll probably see permission errors if they are not yet set or if you have not yet elevated your role in Azure (PIM). Notice how it helpfully points us to the Modify Permissions tab. As an account that has permissions to grant consent, click on Consent for the permissions listed. You'll get one or more prompts to accept these permissions and you can revoke them at any time. Again, if required, you can also select the check box "Consent on behalf of your organization" to make it easier for other admins to do the same requests. After consenting to the permissions and running the query again in Graph Explorer, the result is shown. Note that it's only a subset of the available info and it informs you that if you want more data you'll need to modify the request to include $select to return non-default properties. So now we've seen how to modify the permissions to review Cloud PC data in Graph Explorer, let's gather the same data using Visual Studio Code and a PowerShell cmdlet for Cloud PC. In addition, we'll filter on the managedDeviceName property shown in the output above so that it will only list that data. $MyCloudPCs = Get-MgBetaDeviceManagementVirtualEndpointCloudPC | select-object "managedDeviceName" $MyCloudPCs and here's the output: Success ! Related reading Overview of Microsoft Graph -https://learn.microsoft.com/en-us/graph/overview Graph Explorer API - https://developer.microsoft.com/en-us/graph/graph-explorer Working with Windows 365 Cloud PCs using the Microsoft Graph API - https://learn.microsoft.com/en-us/graph/api/resources/cloudpc-api-overview?view=graph-rest-beta Download Visual Studio Code - https://code.visualstudio.com/docs/?dv=win Permissions - https://learn.microsoft.com/en-us/graph/permissions-reference Permissions overview - https://learn.microsoft.com/en-us/graph/permissions-overview?tabs=http Overview of Cloud PC with Graph - https://learn.microsoft.com/en-us/graph/cloudpc-concept-overview Working with Windows 365 Cloud PCs using the Microsoft Graph API - https://learn.microsoft.com/en-us/graph/api/resources/cloudpc-api-overview?view=graph-rest-beta&preserve-view=true Graph API examples for Cloud PC - https://learn.microsoft.com/en-us/graph/api/virtualendpoint-list-cloudpcs?view=graph-rest-beta&tabs=http Microsoft Graph Beta - https://learn.microsoft.com/en-us/powershell/module/Microsoft.Graph.Beta.DeviceManagement.Administration/get-mgbetadevicemanagementvirtualendpointcloudpc?view=graph-powershell-beta Summary Microsoft Graph and Visual Studio Code with the PowerShell Extension gives admins a useful and powerful way of managing their Windows 365 Cloud PC's and automating repetitive actions. Please join us in the next part where we'll look at how Graph X-Ray can help us further.
  22. the variables detected/set should be revealed in the smsts.log during the Gather steps, so look there and then add them to the new Powershell script, have you tried that ?
×
×
  • 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.