Default Domain Administrator Account Locked out when polling WSUS 3.0 during MDT 2012 Windows 7 deployment

I'm having a unique issue it appears, as I have not been able to find a resolution elsewhere and can't seem to wrap my head around why.

We utilize MDT 2012 update 1 to deploy Windows 7 Enterprise x64 onto our PCs. During the MDT deployment task sequence, it joins our domain (using credentials that are prompted for from the tech that is imaging the computer during the gather phase) into an OU that has WSUS GPOs applied to automatically check for updates but do not download or install (notify). I also have a task that runs an update check after the domain join and reboot, so it gets the WSUS policies, downloads, and installs all available updates. MDT 2012, to the best of my knowledge, automatically utilizes the default local built-in account, "administrator", to auto-login to run the task sequence after the image is brought down to the computer and it is restarted. The only way I'm aware to change this is to either 1) create a task that changes the account name and reboots, though I'm not sure what else I have to do to make this work, or 2) Put a domain-joined username and password into my customsettings.ini file, which puts a domain password into plain-text on our USB flash drives we use to boot and load WinPE to start the imaging process.

My problem is that during the deployment, at the point where it checks for and downloads updates, our reporting tools suddenly start spamming email that the built-in Domain\Administrator account is getting locked out. This built-in domain account is disabled, so its locking out doesn't harm anything except that it spams us with false negative brute-force hacking attempts. That said, we are working our way into hardening the network significantly and want to make sure we aren't ignoring these kinds of emails should they come in. I have to figure this out.

To note: Domain Users nor Local Accounts other than 'Administrator' do not get locked out when they get WSUS updates.

This issue has been going on for 18 months or longer, since the day we stood up the MDT and WSUS servers (which we didn't have previously, as we used a ghost imaging solution previously and didn't patch Windows at all). No matter what I do: allow anonymous authentication on WSUS IIS 6, ensure passwords match on the administrator account, tried with and without the update task in the MDT task sequence (as in we would manually run updates after MDT's task sequence completed), and updated the OS.wim with the latest updates in the event a single update causes the issue, but none of these have resolved this.

Any help would be much appreciated (aside from telling us that we shouldn't use the built-in "Administrator" account, as it seems that MDT requires it and I'm not putting domain credentials onto the several unencrypted USB flash drives we use). I'm looking at PXE booting, but that's still not a huge improvement from the looks of things.
Josh GravedoniSystem AdministratorAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Dan McFaddenSystems EngineerCommented:
Can you post (redacted to protect the innocent) the join domain section of your ini?

What I use is a specific service account for MDT that have domain permissions.  MDT doesn't require the use of the built in Admin account but it does require an account with the appropriate permissions to join a device to the domain in a specific OU (if you don't want the task sequence to prompt for an account and password during the build process.

Josh GravedoniSystem AdministratorAuthor Commented:
I request a username and password prompt on bootup for those permissions for domain join and folder access. Being we USB flash drives for booting to WinPE, I don't want to have plain text domain passwords exposed to risk.

I'll post the remainder of our .ini when I'm back in the office though to try and help.
Josh GravedoniSystem AdministratorAuthor Commented:
Here is our CS.ini used for MDT 2012 u1 builds:

Priority=Reference, ByDesktop, ByLaptop, Default




MachineObjectOU=OU=Windows 7 DT,OU=DT,OU=COMPY,OU=Department,DC=DOMAIN,DC=DOM


MachineObjectOU=OU=Windows 7 laptops,OU=Lappy,OU=Compy,OU=Department,DC=DOMAIN,DC=DOM

_SMSTSOrgName=My Organization
TimeZoneName=Central Standard Time


; Capture State Variables

; USMT Variables
ScanStateArgs=/ue:*\* /uel:60 /o /v:4 /c
LoadStateArgs=/v:4 /c /lac

*Below is our Bootstrap.ini as well*





**I'm wondering if I changed the Autologon section of my Unattend.xml for my task sequence I could get it to log in with a different admin account to complete the setup phases. I'm going to try that next if nothing is glaring here**
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Dan McFaddenSystems EngineerCommented:
Unfortunately, I don't see anything that jumps out and screams error.

But, yeah, dropping the autologon might be a good test to try to isolate the issue.

Josh GravedoniSystem AdministratorAuthor Commented:
So it's totally a workaround, but in our grand plan of renaming the local administrator account on all systems, changing my unattend.xml file to use an alternate local administrator account as the autologon appears to have worked in resolving this issue.

I did run into an issue where it wouldn't kick off the MDT scripts when it first logged in as this account, but a manual restart resolved that so I'm guessing I have logged in as that account on my base capture image at some point, so I'll be removing that profile to verify this is the case.

Anyway, it appears I found my own solution. Below is the section of my Unattend.xml that I changed and the process to change it if you also have this issue:

1. Find your Unattend.xml

Browse to your *deployment share*\Control\*Task_Sequence_Name* folder, Make a backup copy of your Unattend.xml in this folder. I just typically append *.old to the file name of the copy. Then edit your Unattend.xml file either with Notepad or with XML Notepad (or any other XML editor you trust).

2. Find the Autologon Field in that file

Find the field in the <AutoLogon> section and edit your Username and Password listed in there (unless you did not allow plain text for passwords, then I'm sure you'll have to use another method; though you likely did the right thing doing it this way)

3. Edit your Username and Password values to use a different account

These settings are typically under the Pass="oobeSystem" area of your unattend, and look like this in Notepad:

Save the file and try to deploy again to see if it resolves the issue. You'll have to do this for all of your task sequences you want to use this autologon option for...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Josh GravedoniSystem AdministratorAuthor Commented:
Figured it out myself :)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.