Link to home
Start Free TrialLog in
Avatar of Josh Gravedoni
Josh GravedoniFlag for United States of America

asked on

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.
Avatar of Dan McFadden
Dan McFadden
Flag of United States of America image

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.

Dan
Avatar of Josh Gravedoni

ASKER

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.
Here is our CS.ini used for MDT 2012 u1 builds:

[Settings]
Priority=Reference, ByDesktop, ByLaptop, Default
Properties=MyCustomProperty

[Reference]
SubSection=TID-%TaskSequenceID%

[TID-WIN7_64BIT]
SkipCapture=NO
DoCapture=YES
ComputerBackupLocation=%DEPLOYROOT%\Captures
BackupFile=Win7x64CoreImage.WIM

[ByDesktop]
SubSection=Desktop-%IsDesktop%

[Desktop-True]
MachineObjectOU=OU=Windows 7 DT,OU=DT,OU=COMPY,OU=Department,DC=DOMAIN,DC=DOM
BDEInstall=TPM

[ByLaptop]
SubSection=Laptop-%IsLaptop%

[Laptop-True]
MachineObjectOU=OU=Windows 7 laptops,OU=Lappy,OU=Compy,OU=Department,DC=DOMAIN,DC=DOM
BDEInstall=TPMPIN
BDEPin=1111

[Default]
DeploymentType=REFRESH
OSInstall=Y
SkipSummary=YES
_SMSTSOrgName=My Organization
SkipBitLocker=NO
BDERecoveryKey=AD
OSDBitLockerWaitForEncryption=FALSE
SkipAppsOnUpgrade=NO
SkipApplications=NO
Applications=\\mdtserver\distribution01$\applications
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerName=NO
SkipComputerBackup=YES
OSDComputerName=Delete_Old_AD_Entry
SkipLocaleSelection=YES
UserLocale=en-us
KeyboardLocale=en-us
SkipTimeZone=YES
TimeZoneName=Central Standard Time
SkipFinalSummary=NO
FinishAction=
SkipDomainMembership=NO
JoinDomain=DOMAIN.DOM

SLShareDynamicLogging=\\mdtserver\Distribution01$\Logs\%OSDComputerName%

; Capture State Variables
SkipCapture=NO
DoCapture=NO
BackupFile=ImageName.WIM
ComputerBackupLocation=NETWORK
BackupShare=\\mdtserver\Distribution01$\Captures
BackupDir=%OSDComputerName%

; USMT Variables
SkipUserdata=NO
UserDataLocation=\\mdtserver\backup\%OSDcomputername%
ScanStateArgs=/ue:*\* /uel:60 /o /v:4 /c
OSDStateStorePath=\\mdtserver\Distribution01$
USMTMigFiles001=MigApp.xml
USMTMigFiles002=MigUser.xml
USMTMigFiles003=Offline.xml
USMTConfigFile=config.xml
USMTOfflineMigration=TRUE
LoadStateArgs=/v:4 /c /lac
UDSHARE=\\mdtserver\backup
UDDir=%OSDcomputername%
Wipedisk=TRUE

*Below is our Bootstrap.ini as well*

[Settings]
Priority=Default

[Default]
DeployRoot=\\MDTserver.DOMAIN.DOM\Distribution01$

SkipBDDWelcome=YES
KeybordLocale=en-US

UserDomain=DOMAIN.DOM

**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**
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.

Dan
ASKER CERTIFIED SOLUTION
Avatar of Josh Gravedoni
Josh Gravedoni
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Figured it out myself :)