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.