- Newest
- Most votes
- Most comments
Additional Technical Context to the AI-generated recommendation
While the workflow stages are correct, the "reset" you are seeing is likely due to how Windows Sysprep handles user profiles and provisioning. To ensure your changes persist, consider these points:
- User Profile Persistence: If you copied wallpapers or settings to the Administrator profile, they were deleted during Sysprep. To make them "stick" for WorkSpaces users, you must copy files to the
C:\Users\Defaultfolder or use a CopyProfile setting in your Answer File, see also -> https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/customize-the-default-user-profile-by-using-copyprofile?view=windows-11 - AppX Removal: Using
Remove-AppxPackageonly affects the current user. To permanently remove apps from the image, you must useRemove-AppxProvisionedPackagewith the-AllUsersflag. Otherwise, Windows will re-install them for every new user, see -> https://learn.microsoft.com/en-us/powershell/module/dism/remove-appxprovisionedpackage?view=windowsserver2025-ps - Unattend.xml Overwrites: EC2 Image Builder often generates its own unattend.xml during the finalization phase. If your custom component modifies the file in the standard location, it might be overwritten. Ensure your component runs as one of the last steps or targets the specific pass (e.g., oobeSystem) correctly.
- Files in Temp Folders: Any files placed in
C:\Windows\Tempor the build user’s temporary directories are purged during the cleanup phase before the AMI snapshot is taken. Move your VDI tools to a permanent path likeC:\ProgramDataorC:\VDI_Tools.
Tip: Check the Sysprep\Panther logs on a launched instance to see if your unattend.xml changes were processed or rejected during the generalization phase.
I'll need to review that then, so thank you. What you described kind of is conflicting to me considering the below. I would think how the steps are ordered, that SysPrep (step 5) would not be interfering with BuildComponents (step 2).
The default workflow steps show 1. LaunchBuildInstance, 2. ApplyBuildComponents, 3. InventoryCollection, 4. RunSanitizeScript (always appears as Skipped), 5. RunSysPrepScript, 6. CreateOutputAMI, 7. TerminateBuildInstance
I see where the confusion lies. It seems logical that since Step 2 (ApplyBuildComponents) happens before Step 5 (RunSysprepScript), your changes should simply be 'saved.'
However, the reality is that Sysprep is not a passive 'save' step—it is a destructive 'cleanup' process.
When you run your components in Step 2, you are working within a temporary build environment. If you copy a wallpaper to C:\Users\Administrator\Desktop, it exists during Step 2. But during Step 5 (Generalization), Sysprep intentionally wipes the local Administrator profile to make the image 'generic' for new deployments.
To make your changes survive Step 5, you must target the system globally or the Default User Profile:
For Wallpapers/Files: Move them to C:\Users\Default or a public path like C:\ProgramData. This ensures that when a new WorkSpace is launched, it clones the settings from the 'Default' folder.
For Apps: As mentioned, targeting the 'Provisioned' layer is the only way to prevent Sysprep from re-installing them from the system cache during finalization.
In short: Step 5 is designed to 'undo' user-specific changes from Step 2 unless they are baked into the system-wide configuration.
The behavior you're experiencing is related to how EC2 Image Builder's workflow stages operate and when snapshots are created during the image creation process.
Image Builder follows a specific workflow framework with distinct stages:
-
Build Stage (pre-snapshot): During this stage, changes are made to the EC2 build instance running your base image. This is where your recipe components execute - installing applications, copying files, modifying configurations, etc. After this stage completes successfully, Image Builder creates a snapshot that becomes the basis for your AMI.
-
Test Stage (post-snapshot): For AMI workflows, Image Builder launches a new EC2 instance from the snapshot created at the end of the build stage. Tests run on this new instance to validate settings.
-
Distribution Stage (post-build): Once the image passes all tests, it undergoes distribution phases including AMI copy operations and sharing.
The key issue you're encountering is likely related to the timing of when SysPrep runs relative to when the snapshot is taken. If SysPrep is executing as part of your build components and resetting certain configurations (like wallpaper, copied files, or unattend.xml modifications) before the snapshot is created, those changes will be lost in the final AMI.
When you tested components individually, SysPrep may not have been included in those test runs, allowing you to see your customizations. However, in your final recipe with all components together, if SysPrep runs after your customization components, it would reset or remove those changes before the snapshot is captured.
To resolve this, you should carefully review the order of your components and ensure that:
- Customization components run after any system preparation steps that might reset configurations
- SysPrep-related activities are positioned appropriately in your component sequence
- You're not inadvertently running cleanup or reset operations that undo your customizations
Check your log streams to identify exactly when SysPrep executes relative to your customization components, and adjust the component order accordingly in your recipe.
Sources
Manage build and test workflows for Image Builder images - EC2 Image Builder
How EC2 Image Builder works - EC2 Image Builder
Relevant content
- asked 2 years ago
- asked 3 years ago
- asked 3 years ago
- AWS OFFICIALUpdated 2 years ago
If my answer helped solve your problem, I would appreciate it if you click on “accepted answer”