Josh Gravedoni
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.
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.
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.
I'll post the remainder of our .ini when I'm back in the office though to try and help.
ASKER
Here is our CS.ini used for MDT 2012 u1 builds:
[Settings]
Priority=Reference, ByDesktop, ByLaptop, Default
Properties=MyCustomPropert y
[Reference]
SubSection=TID-%TaskSequen ceID%
[TID-WIN7_64BIT]
SkipCapture=NO
DoCapture=YES
ComputerBackupLocation=%DE PLOYROOT%\ Captures
BackupFile=Win7x64CoreImag e.WIM
[ByDesktop]
SubSection=Desktop-%IsDesk top%
[Desktop-True]
MachineObjectOU=OU=Windows 7 DT,OU=DT,OU=COMPY,OU=Depar tment,DC=D OMAIN,DC=D OM
BDEInstall=TPM
[ByLaptop]
SubSection=Laptop-%IsLapto p%
[Laptop-True]
MachineObjectOU=OU=Windows 7 laptops,OU=Lappy,OU=Compy, OU=Departm ent,DC=DOM AIN,DC=DOM
BDEInstall=TPMPIN
BDEPin=1111
[Default]
DeploymentType=REFRESH
OSInstall=Y
SkipSummary=YES
_SMSTSOrgName=My Organization
SkipBitLocker=NO
BDERecoveryKey=AD
OSDBitLockerWaitForEncrypt ion=FALSE
SkipAppsOnUpgrade=NO
SkipApplications=NO
Applications=\\mdtserver\d istributio n01$\appli cations
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=\\md tserver\Di stribution 01$\Logs\% OSDCompute rName%
; Capture State Variables
SkipCapture=NO
DoCapture=NO
BackupFile=ImageName.WIM
ComputerBackupLocation=NET WORK
BackupShare=\\mdtserver\Di stribution 01$\Captur es
BackupDir=%OSDComputerName %
; USMT Variables
SkipUserdata=NO
UserDataLocation=\\mdtserv er\backup\ %OSDcomput ername%
ScanStateArgs=/ue:*\* /uel:60 /o /v:4 /c
OSDStateStorePath=\\mdtser ver\Distri bution01$
USMTMigFiles001=MigApp.xml
USMTMigFiles002=MigUser.xm l
USMTMigFiles003=Offline.xm l
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.DOM AIN.DOM\Di stribution 01$
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**
[Settings]
Priority=Reference, ByDesktop, ByLaptop, Default
Properties=MyCustomPropert
[Reference]
SubSection=TID-%TaskSequen
[TID-WIN7_64BIT]
SkipCapture=NO
DoCapture=YES
ComputerBackupLocation=%DE
BackupFile=Win7x64CoreImag
[ByDesktop]
SubSection=Desktop-%IsDesk
[Desktop-True]
MachineObjectOU=OU=Windows
BDEInstall=TPM
[ByLaptop]
SubSection=Laptop-%IsLapto
[Laptop-True]
MachineObjectOU=OU=Windows
BDEInstall=TPMPIN
BDEPin=1111
[Default]
DeploymentType=REFRESH
OSInstall=Y
SkipSummary=YES
_SMSTSOrgName=My Organization
SkipBitLocker=NO
BDERecoveryKey=AD
OSDBitLockerWaitForEncrypt
SkipAppsOnUpgrade=NO
SkipApplications=NO
Applications=\\mdtserver\d
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerName=NO
SkipComputerBackup=YES
OSDComputerName=Delete_Old
SkipLocaleSelection=YES
UserLocale=en-us
KeyboardLocale=en-us
SkipTimeZone=YES
TimeZoneName=Central Standard Time
SkipFinalSummary=NO
FinishAction=
SkipDomainMembership=NO
JoinDomain=DOMAIN.DOM
SLShareDynamicLogging=\\md
; Capture State Variables
SkipCapture=NO
DoCapture=NO
BackupFile=ImageName.WIM
ComputerBackupLocation=NET
BackupShare=\\mdtserver\Di
BackupDir=%OSDComputerName
; USMT Variables
SkipUserdata=NO
UserDataLocation=\\mdtserv
ScanStateArgs=/ue:*\* /uel:60 /o /v:4 /c
OSDStateStorePath=\\mdtser
USMTMigFiles001=MigApp.xml
USMTMigFiles002=MigUser.xm
USMTMigFiles003=Offline.xm
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.DOM
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
But, yeah, dropping the autologon might be a good test to try to isolate the issue.
Dan
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Figured it out myself :)
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