When deploying an image and using DeployAnywhere, after rebooting and while waiting for MiniSetup to complete, you may receive the following error:

"Windows could not complete the installation. To install Windows on this computer, restart the installation."

The installation will fail.

If you look at the installation logs from Minisetup in the Panther directory, you'll find the follwoing in the setuperr.xml file (note the highlighted text):

Error [audit.exe] EnableLocalUserAccount: Unable to enable local account [Administrator]; status = 0x8c5
Error [audit.exe] Unable to enable local account [Administrator]; hr = 0x800708C5
Error [audit.exe] Failed to arrange for [C:\Windows\system32\oobe\audit.exe /user] to be called after logon; hr = 0x800708c5
Error [windeploy.exe] Command [%windir%\system32\oobe\audit.exe /system] failed with exit code [0x800708c5]
Error [windeploy.exe] Failure occured during online installation. Online installation cannot complete at this time.; hr = 0x80004005

The root cause is that the built-in Administrator account password does not meet the password complexity requirements for the system (or domain if the system was part of a domain).  This account is temporarily enabled as a part of Minisetup during the AuditSystem pass as indicated in a Microsoft Technet article entitled "Enable and Disable the Built-in Administrator Account." The essential text from that article is as follows:

"In audit mode, Windows Setup will implicitly enable the built-in Administrator account as the last action in the auditSystem configuration pass if the built-in Administrator is not already enabled. The first action in the auditUser configuration pass is to disable the built-in Administrator account. This enables you to run programs and applications as an Administrator. When you complete your customizations in audit mode and log off, the built-in Administrator account will be disabled. If you want to leave the built-in Administrator account enabled, you can re-enable it in audit mode."

When DA runs, it adds the auditSystem section for various reasons, thus triggering the enablement of the built-in Administrator account.  The failures indicated in this KB is because when this account is enabled, if the password for the account (even if never used) doesn't meet the minimum requirements, the account can not be enabled and the step fails.  Taking the same system and simply trying to manually enable the account will result in a similar error - you'll be forced to modify the password to meet complexity requirements.

More information about the errors themselves can be found here: change password and password complexity violation error codes  The relevant text from this blog is as follows (note that the highlighted text matches the errors above):

"If you are a seasoned ADSI developer You may have noticed ChangePassword throws two different error codes when the new password violates the Password policy.

One error code is ERROR_DS_CONSTRAINT_VIOLATION (0x8007202f)

And the Second one is more descriptive NERR_PasswordTooShort (0x800708c5) “The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.“

In order to understand why the call returns different error codes please refer the remarks section of the MSDN article. The ADSI/S.DS API uses three different methods as described in the MSDN article to change the password. It first tries LDAP over SSL and if it fails to establish a SSL channel it tries Kerberos and Net API calls to change the password. While 0x8007202f is an ADSI LDAP error code, 0x800708c5 is a converted Network Management API error code (0x8c5 = 2245)."

NOTE: A similar error may be caused if the Administrator account has been renamed.  The error code will be different, but the main error of not being able to continue the installation will be the same

The solution is to modify the Administrator account password to fit the minimum requirements.  This can be done by enabling the account and modifying the password until it allows you to save it (and then disabling it if you want, though that is not necessary) or simply modifying the password on the account.  The latter option though runs the risk of failing and not being warned since validation doesn't occur.  This needs to be done prior to image capture.

NOTE:  Leaving the administrator account enabled is not a security risk because in the AuditUser phase, which is always run, Minisetup will disable this account again as noted in the cause section above.

NOTE:  If the error code is different in the setuperr.xml document, you may be facing something like simply renaming the Administrator account so it can't be found, which can cause the same net result as noted above in the Cause section.  If so, rename the account back to Administrator and re-capture the image.

Applies To

This applies to all versions of Symantec products that capture and deploy images and is related actually to a limitation in Windows.