Strange behaviour with local admin accounts after wds deployment

[GoodheadDC]

We are using wds to deploy win 7 clients.

 

We have group policy set to create a local admin account called support.

After we have done a gpupdate we then find that the support account is disabled.

 

We then have to go in and enable it.

 

Now following that we have another issue that once enabled we can't login to it. It says password incorrect.

If I login another way and manually set it the same as the policy and then attempt login again says same thing.

 

I can login to the account that wds sets up as part of imaging.

 

This is very annoying and slowing us down.

[LeMarchand]

Can you add the support account during the imaging process?

[GoodheadDC]

Can you add the support account during the imaging process?

 

I think the support account setup in gp is also setup with various access rights groups etc.

[LeMarchand]

I think the support account setup in gp is also setup with various access rights groups etc.

 

If it's a domain account that you're making local admin could you not set it somewhere like the below so that it's computer admin but AD should preserve the domain permissions?

 

 

Never done it - just throwing it out there!

[GoodheadDC]

I have noticed that in gp we have a policy that renames local administrator to support.

That's what we wanted to make it more secure.

 

Lower down in the same policy we have a setting that disabled the administrator account.

 

Do you think there could be a conflict here?

 

 

If it's a domain account that you're making local admin could you not set it somewhere like the below so that it's computer admin but AD should preserve the domain permissions?

 

[ATTACH=CONFIG]31778[/ATTACH]

 

Never done it - just throwing it out there!

[GoodheadDC]

Its not a domain account we are making local.

Seems we recreate the administrator and then disable.

 

I have disabled this pref and will image and see if that sorts.

[LeMarchand]

I have noticed that in gp we have a policy that renames local administrator to support.

That's what we wanted to make it more secure.

 

Lower down in the same policy we have a setting that disabled the administrator account.

 

Do you think there could be a conflict here?

 

Strange that it was working OK until now if so. Sounds like a likely culprit, though.