Vista - pwdLastSet attribute not updating

We have a VBScript that runs on a schedule that disables old computer
objects & deletes really old computer objects from the domain. For the most
part, the script works as designed. However, it has on several occasions
disabled computers that are still active. In looking at the attribute on one
of these computers, I see that the 'pwdLastSet' date is less than an hour
newer that 'createTimeStamp'. The 'whenChanged' & 'lastLogonTimestamp'
attributes are being updated, but 'pwdLastSet' is not. Can anyone explain
what might be causing this on just a few of the computers in the domain?

Hi,

If we're talking computer accounts, isn't it better to use the
lastLogonTimestamp instead of pwdLastSet?

James Whitlow wrote:
--
Gerry Hickman (London UK)

"Gerry Hickman" <gerry666uk2@xxxxxx> wrote in message
news:%23TkdUetNJHA.4372@xxxxxxThanks for the reply, Gerry!

In the original script I wrote, I was using 'whenChanged'. During a
meeting with Microsoft, they advised using 'pwdLastSet'. In searching
postings on the subject on the web and Usenet, 'pwdLastSet' seemed to be the
popular choice. Anyway, the change from 'whenChanged' to 'pwdLastSet' was
not my choice. I actually argued against it based on the problems it was
creating with the deletions of computers that should not have been deleted.
In all of the research I did on the web, I did not see anyone else
complaining about the problem, so I decided to post a message seeing if
anyone else was experiencing this issue. It has affected on a very small
numbers of computer in a very large pool, so it is not a huge problem, but
one I would like to solve if possible so that I have an option other than
reimaging the computer.

I tried solving the issue of computer not updating their 'pwdLastSet'
attribute by deleting their computer accounts in AD, recreating it, moving
the computer to a workgroup & then rejoining the domain, but this did not
work. The get a new 'pwdLastSet' from the initial joining, but it still
never updates.

"James Whitlow" <jwhitlow.60372693@xxxxxx> wrote in message
news:ePzY9rtNJHA.1160@xxxxxxThe whenChanged attribute is not replicated. A different value for each
object is saved on every DC. The pwdLastSet attribute is better because it
is replicated.

Possibly the problem computers have a group policy setting "Disable machine
account password changes". See this link:

http://technet.microsoft.com/en-us/l.../cc785826.aspx

By default each computer should request a new password every 30 days, but
this setting can be modified by policy. See:

http://technet.microsoft.com/en-us/l.../cc781050.aspx

Possibly you can find a Group Policy that applies to the problem computers.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

"Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote in
message news:uuXCCEuNJHA.2100@xxxxxxThanks, Richard! Good information, as always!

I out for a week, but will investigate the information when I return.
These computers are in the same OU and, to the best of my knowledge, have
the same policies applied to them. There are less than a dozen out of
thousands with this issue, so I think it is some type of corruption on the
computer itself (considering the domain account in AD has been recreated).

"James Whitlow" <jwhitlow.60372693@xxxxxx> wrote in message
news:ePzY9rtNJHA.1160@xxxxxxI like that attribute, as it is displayed legibly in ADU&C and when
extracted by csvde, ldifde, ADO, or other scripting techniques.

Unfortunately, I believe that "whenChanged" records the last change made to
the object in AD, so you have to be sure that no administrators are adding
comments or moving it to an alternate OU.

/Al

vvvbcbcb
"James Whitlow" <jwhitlow.60372693@xxxxxx> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ ×
ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:OqFgetXLJHA.5060@xxxxxx