Windows 11 sysprep

sjaak327 whatever 31 Reputation points
2022-09-28T18:02:05.947+00:00

Please, no questions on to why I use a thick image, deployment time IS a concern here.

I have been using the same procedure to create an image, sysprep it and capture it for years, with various operating systems included Windows 10 21H2 and Windows 11 21H2, working just fine.

So... I tried to do the exact same procedure for Windows 11 22H2, using the same applications inisde the image, same language options. Exactly the same as with Windows 11 21H2.

The problem, after the successfull sysprep, rebooting the reference pc, will get the PC into the Getting Ready stage, and it will never move beyond it (even after 8 hours). The captured image deployed to another pc obviously has the same problem, after the first reboot, it is also stuck in Getting Ready.

The sysprep log indicates no problems.

I am at a loss here.

Windows 11
Windows 11
A Microsoft operating system designed for productivity, creativity, and ease of use.
8,098 questions
{count} votes

22 answers

Sort by: Most helpful
  1. Martin Schneeberger 76 Reputation points
    2023-01-11T18:13:36.6766667+00:00

    Thanks for the hint.
    I have included a PowerShell script in the "Build and Capture" task sequence before the Sysprep steps.

    257444-screenshot-2022-11-05-105302.png

    The script removes the "CryptoSysPrep_Specialize" actions from the "Specialize.xml".

    $FilePath = "$($env:windir)\System32\Sysprep\ActionFiles\Specialize.xml"  
    [xml]$xml = Get-Content $FilePath  
    $TrackingNumber = @()  
    $xml.SelectNodes("//sysprepModule") | ForEach-Object{  
         if($_.methodName -eq "CryptoSysPrep_Specialize"){  
            $_.ParentNode.RemoveChild($_) | Out-Null  
         }  
    }  
    $xml.Save($FilePath)  
    

    So far I haven't noticed any side effects. Still, I'm hoping for a fix from Microsoft soon.

    7 people found this answer helpful.

  2. Marcel Meurer 26 Reputation points
    2022-11-02T18:34:29.517+00:00

    Hello together.

    It would be great to find a solution for the behavior. It's also blocking customers from using Azure Virtual Desktop based on a domain-joined Windows 11 22H2.

    What I figured out. The setup process stops after handling the following task (found in C:\Windows\Panther\setupact.log):

    ActionPlatform::LaunchModule: Executing method 'CryptoSysPrep_Specialize' from C:\Windows\system32\capisp.dll

    After that, no more happens. Also, the ETL files are not showing any process. I guess the process hangs.

    I was able to bring it down to this part. For a test (!), I modified the "C:\windows\system32\Sysprep\ActionFiles\Specialize.xml" on the master VM and removed the actions for 'CryptoSysPrep_Specialize'. This file is processed after a rollout based on an image on this VM. And: It worked. The deployed VMs are running, and the timeout didn't happen.

    I hope that this information will help (Microsoft) to get the root cause of this issue.

    Best,
    Marcel

    blog.itprocloud.de

    2 people found this answer helpful.

  3. Martin Schneeberger 76 Reputation points
    2023-03-06T06:48:31.6+00:00

    @Patrick C Thank you for your information.

    I have obtained the "Windows 11 Build 22621.1343" and successfully performed a capture/deploy scenario using "Configuration Manager".

    The workaround with the customization of the "Specialize.xml" is no longer necessary from version 1343. I hope for a general release soon.

    2 people found this answer helpful.
    0 comments No comments

  4. Johan Pol 11 Reputation points
    2022-11-03T07:02:40.683+00:00

    Microsoft close the case with the status "bug". They know the issue and Windows 11 next version will be a fixed version. (or the next or the next :-( )
    For now we need to monitor https://support.microsoft.com/en-us/help/5018680 and if new version is available test it and communicate here if the issue is resolved or not.

    1 person found this answer helpful.
    0 comments No comments

  5. Rad 5 Reputation points
    2023-01-14T04:00:31.8666667+00:00

    I have the same problem.
    I am creating 2 images on Dell Image Assist (Dynamic) 11.0.3.18 with VMware Workstation 17 Pro.

    First one (STANDARD) is quite clean and has only a couple of apps added to the reference image due to configurational complexity or failure on my end to install them with script. Everything else is set to install on Synchronous and First Logon Commands. I usually will get to the last snapshot and do updates for those apps and run Windows updates and do another sysprep. I use the DIA option to join to domain. That usually is in the first boot on my Dell computers OOBE. Last time I revised it was 12/13/2022 with OS Build 22621.936. No problem with deploying that image whatsoever.

    My Second image (FIELD) has a bunch of old software installed for field technicians. Those have no way deploying with script (custom company apps). Everything else the same. No problem with sysprep of my last snapshot Win 11 21H2 from September. Then did at least 7 attempts to sysprep the updated 22H2 since beginning of December. Every time I hand on OOBE image deployment. It is not even recognizing existence of Ethernet adapter which or ping the Domain Controller, so I thought is the issue and chased all sorts of Drivers troubleshooting but my first image works so can't be that. Then I came back to my September snapshot and ran only the update 22H2 and sysprepped. The deployment hanged again on OOBE. Last attempt was 1/9/2023 with OS Build 22621.1105. That is when I found this thread.

    Workaround is not available because the line for ActionPlatform 'CryptoSysPrep_Specialize' is missing from Specialize.xml I assume because my reference images are clean and have never been joined to domain.

    I guess I will start over on my Second image with brand new VM and install 22H2 directly with adding all the software (which is a pain, it is a lot to configure).
    I will update my comment if I get any progress.


    UPDATE 1/13/2023: I deployed/imaged a VM with my last "FIELD" image revision. It worked and went through the OOBE quite fast. I do have the Network adapter of the VM set to Briged: Replicate physical network connection state, so I am getting back to drawing board if drivers or 22H2 is the reason my multiple models Dell laptops won't load network and pass by OOBE.


    UPDATE 1/27/2023: I completely rebuilt the image. It worked. Sad that it had to go to that extend.

    1 person found this answer helpful.
    0 comments No comments