Renaming Local Admin Account - Using EC2 Image Builder for Windows 11 Images

The answer provided above is likely correct: you are running into these issues because modifying default local accounts during the EC2 Image Builder pipeline conflicts with how AWS orchestration and Windows Sysprep operate.

In short: Remove the account modification tasks from your Image Builder components entirely. Let Image Builder create a standard, generalized AMI, and shift your account renaming tasks to the provisioning phase (User Data or GPO). This will immediately resolve your Sysprep and AWSTOE failures.

Why Your Current Approach Fails During the Build Phase

1. AWSTOE Dependency: The AWS Task Orchestrator and Executor (AWSTOE), which runs your ApplyComponents steps, relies heavily on the built-in local Administrator account to execute scripts, maintain state across reboots, and validate success. If you rename or disable this account during the build phase, AWSTOE loses its execution context, causing the pipeline to hang or fail.

2. Sysprep Generalization: The Sysprep phase generalizes the OS (removing machine-specific SIDs) and drops the machine into OOBE (Out-Of-Box Experience). Sysprep relies on the unattend.xml file, which by default is configured to enable and utilize the standard built-in Administrator account. Any local account changes made prior to Sysprep are frequently overwritten, discarded, or cause the Sysprep process itself to fail.

Post-Deployment Automation

I would recommend leaving the local Administrator account strictly untouched during the entire EC2 Image Builder pipeline. Instead, you should apply your local account modifications after the AMI has been baked and Sysprep has completed—meaning these changes should occur when the final instance is provisioned from your golden image. Here are the three most robust ways to implement this:

Method 1: EC2 User Data via Launch Templates (Easiest & Most Common)

Since you are using Win11 (EC2Launch v2), you can pass a PowerShell script via User Data in the Launch Template used to deploy your instances or WorkSpaces. EC2Launch v2 will execute this script on the very first boot after Sysprep.

<powershell>
# 1. Rename the built-in Local Administrator
Rename-LocalUser -Name "Administrator" -NewName "NewAdminName"

# 2. Rename the built-in Guest account
Rename-LocalUser -Name "Guest" -NewName "NewGuestName"

# 3. Delete the Workspaces_BYOL account (if it exists)
if (Get-LocalUser -Name "Workspaces_BYOL" -ErrorAction SilentlyContinue) {
    Remove-LocalUser -Name "Workspaces_BYOL"
}

# 4. Create a new local account and add to Administrators
$Password = Read-Host -AsSecureString "YourSecurePassword123!" # In production, pull this securely from AWS Secrets Manager
New-LocalUser "NewLocalUser" -Password $Password -FullName "New User" -Description "Secondary Admin"
Add-LocalGroupMember -Group "Administrators" -Member "NewLocalUser"
</powershell>

Method 2: AD GPOs

If these Win 11 images are intended for Amazon WorkSpaces or will be joined to an AWS Managed Microsoft AD, the most secure, enterprise-grade solution is to use Group Policy.

• Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
• Enable and configure: Accounts: Rename administrator account and Accounts: Rename guest account. This ensures the accounts are renamed immediately upon domain join, requiring zero custom scripting in your AWS environment.

Method 3: Customizing EC2Launch v2 (Answering your directory question)

You asked if there is a tweak within C:\ProgramData\Amazon\EC2Launch that makes this work. Yes, there is. If you strictly want this baked into the image without relying on Launch Template User Data, you can use an Image Builder component to modify the EC2Launch v2 agent-config.yml or the standard Windows unattend.xml during the build. You can append a script to the execute stage of EC2Launch v2's post-sysprep boot sequence. However, modifying unattend.xml or agent-config.yml adds complexity to your pipeline. Using Method 1 (User Data) or Method 2 (GPO) is vastly preferred for maintainability.

You may consider applying local account changes only after Sysprep generalization, or via post‑deployment automation (e.g., SSM documents or Group Policy).

https://docs.aws.amazon.com/imagebuilder/

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sysprep-using.html