whenChanged Attribute

Discussion:

(too old to reply)

Joe Kaplan

2007-01-05 16:12:44 UTC

whenChanged is replicated, so that can be used. However, it is not
typically used this this purpose. You are generally better off using the
Directory Synch control for doing change tracking or doing explicit polling
on the usnChanged attribute. The DirectorySearcher in .NET 2.0 includes
access to the DirSynch stuff and makes it pretty easy to consume. We cover
how to use that in ch 5 of our book (see link below if interested).

The downside of using dir sync or usnChanged polling is that usnChanged is
not replicated, so you must use a specific domain controller for change
tracking. This approach generally yields better results anyway, but it may
not be appropriate for your particular scenario.

I'd suggest staying away from anything that points you towards forcing
replication. That is almost always a bad design and should not be necessary
for this type of application.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

IŽm currently researching on the best way to track if a user has changed
any
of its attributes recently. IŽm developing in .net.
IŽve found that the whenChanged attribute stores the date and time of the
last change made to the user, but IŽve also read that this attribute is
not
replicated among domain controllers, so i have some question on that
1. How can i make sure the whenChanged attribute is the same among all DC?
can I force a Directory Synchronization? (how can I do it? any articles
urls
will be appreciated).
2. If I force a DC sync operation, will these replicate the whenChanged
attribute?
3. Is there any other method to track the active directory changes? IŽve
read this article "http://support.microsoft.com/kb/891995" but have not
found
further info on this.
Thanks for any help.
--
Jairo Andrés Portela S.
.Net developer

Joe Richards [MVP]

2007-01-05 17:29:20 UTC

Permalink

JoeK: Sorry, whenChanged actually isn't replicated... It is specific to
every DC.

G:\Transfer\Delphi\ServerList>adfind -sc s:whenchanged systemflags

AdFind V01.33.00cpp Joe Richards (***@joeware.net) October 2006

Using server: r2dc1.test.loc:389
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=test,DC=loc

dn:CN=When-Changed,CN=Schema,CN=Configuration,DC=test,DC=loc

systemFlags: 19 [NOT REPLICATED(1);PAS-ATTR(2);CAT-1(16)]

1 Objects returned

Jairo: You can't force whenChanged to be in sync. Period. It isn't even
an avenue to start thinking about going down.

The first thing you need to keep in mind is that AD is built from the
ground up to be loosely consistent and it is multimaster so make no
assumptions on the state of information and the order in which changes
come in. This means when syncing if you can no longer sync against a
specific DC, be prepared to do a full resync to get back to where you
were when you jump to a new DC. Most schemes you could think up to try
and get around it will likely have holes and until you have a really
seriously strong understanding of the replication mechanisms you don't
want to think you can find a shortcut.

The next thing is as JoeK mentioned, you have DirSync available. You
also have the possibility of getting change notifications. Alternately
you can poll a single DC based on whenChanged or uSNChanged for specific
objects.

One popular "lite" mechanism which doesn't require any kind of special
rights and works just as well on 2K AD, K3 AD, and ADAM is to do
something like

1. Retrieve highestCommittedUSN from rootdse of DC

2. Query for all objects you care about on that DC that have that USN or
less.

3. Process the objects, making sure you understand what you have already
done heavy duty processing on so you can avoid. This is for resync points...

4. Go to 1

I have written several successful syncing tools for specific purposes
that work this way and only require normal user access rights to AD.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net

---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

whenChanged is replicated, so that can be used. However, it is not
typically used this this purpose. You are generally better off using the
Directory Synch control for doing change tracking or doing explicit polling
on the usnChanged attribute. The DirectorySearcher in .NET 2.0 includes
access to the DirSynch stuff and makes it pretty easy to consume. We cover
how to use that in ch 5 of our book (see link below if interested).
The downside of using dir sync or usnChanged polling is that usnChanged is
not replicated, so you must use a specific domain controller for change
tracking. This approach generally yields better results anyway, but it may
not be appropriate for your particular scenario.
I'd suggest staying away from anything that points you towards forcing
replication. That is almost always a bad design and should not be necessary
for this type of application.
Joe K.

Joe Kaplan

2007-01-05 18:01:53 UTC

Permalink

Really? Yikes! Sorry about that. I should go back to bed. :)

I still stand by the rest of my recommendation though.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Post by Joe Richards [MVP]
JoeK: Sorry, whenChanged actually isn't replicated... It is specific to
every DC.
G:\Transfer\Delphi\ServerList>adfind -sc s:whenchanged systemflags
Using server: r2dc1.test.loc:389
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=test,DC=loc
dn:CN=When-Changed,CN=Schema,CN=Configuration,DC=test,DC=loc

systemFlags: 19 [NOT REPLICATED(1);PAS-ATTR(2);CAT-1(16)]

1 Objects returned
Jairo: You can't force whenChanged to be in sync. Period. It isn't even an
avenue to start thinking about going down.
The first thing you need to keep in mind is that AD is built from the
ground up to be loosely consistent and it is multimaster so make no
assumptions on the state of information and the order in which changes
come in. This means when syncing if you can no longer sync against a
specific DC, be prepared to do a full resync to get back to where you were
when you jump to a new DC. Most schemes you could think up to try and get
around it will likely have holes and until you have a really seriously
strong understanding of the replication mechanisms you don't want to think
you can find a shortcut.
The next thing is as JoeK mentioned, you have DirSync available. You also
have the possibility of getting change notifications. Alternately you can
poll a single DC based on whenChanged or uSNChanged for specific objects.
One popular "lite" mechanism which doesn't require any kind of special
rights and works just as well on 2K AD, K3 AD, and ADAM is to do something
like
1. Retrieve highestCommittedUSN from rootdse of DC
2. Query for all objects you care about on that DC that have that USN or
less.
3. Process the objects, making sure you understand what you have already
done heavy duty processing on so you can avoid. This is for resync points...
4. Go to 1
I have written several successful syncing tools for specific purposes that
work this way and only require normal user access rights to AD.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net
---O'Reilly Active Directory Third Edition now available---
http://www.joeware.net/win/ad3e.htm

whenChanged is replicated, so that can be used. However, it is not
typically used this this purpose. You are generally better off using the
Directory Synch control for doing change tracking or doing explicit
polling on the usnChanged attribute. The DirectorySearcher in .NET 2.0
includes access to the DirSynch stuff and makes it pretty easy to
consume. We cover how to use that in ch 5 of our book (see link below if
interested).
The downside of using dir sync or usnChanged polling is that usnChanged
is not replicated, so you must use a specific domain controller for
change tracking. This approach generally yields better results anyway,
but it may not be appropriate for your particular scenario.
I'd suggest staying away from anything that points you towards forcing
replication. That is almost always a bad design and should not be
necessary for this type of application.
Joe K.

Joe Kaplan

2007-01-17 19:15:41 UTC

Permalink

Always specify the server's DNS name in your path if you want a specific DC
(which you do for this application):

LDAP://somedc.domain.com/RootDSE

Any time you are doing usnChanged polling, you need to use the same DC every
time.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Post by Joe Richards [MVP]
1. Retrieve highestCommittedUSN from rootdse of DC
I should bind to a specific DC when asking for the "highestCommittedUSN"?
Is the "LDAP://ServerName/RootDSE" the right way?
If I do it this way "LDAP://rootDSE" will this bind for the rootDSE in any
server?
Thanks again!
--
Jairo Andrés Portela S.
.Net developer

systemFlags: 19 [NOT REPLICATED(1);PAS-ATTR(2);CAT-1(16)]

1 Objects returned
Jairo: You can't force whenChanged to be in sync. Period. It isn't even
an avenue to start thinking about going down.
The first thing you need to keep in mind is that AD is built from the
ground up to be loosely consistent and it is multimaster so make no
assumptions on the state of information and the order in which changes
come in. This means when syncing if you can no longer sync against a
specific DC, be prepared to do a full resync to get back to where you
were when you jump to a new DC. Most schemes you could think up to try
and get around it will likely have holes and until you have a really
seriously strong understanding of the replication mechanisms you don't
want to think you can find a shortcut.
The next thing is as JoeK mentioned, you have DirSync available. You
also have the possibility of getting change notifications. Alternately
you can poll a single DC based on whenChanged or uSNChanged for specific
objects.
One popular "lite" mechanism which doesn't require any kind of special
rights and works just as well on 2K AD, K3 AD, and ADAM is to do
something like
1. Retrieve highestCommittedUSN from rootdse of DC
2. Query for all objects you care about on that DC that have that USN or
less.
3. Process the objects, making sure you understand what you have already
done heavy duty processing on so you can avoid. This is for resync points...
4. Go to 1
I have written several successful syncing tools for specific purposes
that work this way and only require normal user access rights to AD.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net
---O'Reilly Active Directory Third Edition now available---
http://www.joeware.net/win/ad3e.htm

whenChanged is replicated, so that can be used. However, it is not
typically used this this purpose. You are generally better off using the
Directory Synch control for doing change tracking or doing explicit polling
on the usnChanged attribute. The DirectorySearcher in .NET 2.0 includes
access to the DirSynch stuff and makes it pretty easy to consume. We cover
how to use that in ch 5 of our book (see link below if interested).
The downside of using dir sync or usnChanged polling is that usnChanged is
not replicated, so you must use a specific domain controller for change
tracking. This approach generally yields better results anyway, but it may
not be appropriate for your particular scenario.
I'd suggest staying away from anything that points you towards forcing
replication. That is almost always a bad design and should not be necessary
for this type of application.
Joe K.

Joe Kaplan

2007-01-05 18:06:00 UTC

Permalink

Please see other post from Joe Richards. I was wrong about whenChanged
being replicated. Sorry.

Regarding your other question, you wait for the change to be replicated to
the server you are doing your change polling/dir sync against. Depending on
how your domain is set up, this probably shouldn't take very long, but it
depends a great deal on your replication topology.

DirSync is your friend here. Use it. :) If you want, you can download the
code samples from ch 5 from our website to get some usage examples. That
won't give you the text from the book, but it could give you a jump start.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

thanks for the quick response Joe...
If whenChanged is replicated I think itŽs enough for me, I know its value
changes even when a new password is set, but this should do the trick for
me.
I will read some more on the DirectorySearcher DirSync stuff also.
Another question, if usnChanged is not replicated, and you are always
pointing to the same server, how will it know a user was updated ir the
update ocurred in an other Domain controller?
Thanks again for the reply.
--
Jairo Andrés Portela S.
.Net developer

Post by Joe Kaplan
whenChanged is replicated, so that can be used. However, it is not
typically used this this purpose. You are generally better off using the
Directory Synch control for doing change tracking or doing explicit polling
on the usnChanged attribute. The DirectorySearcher in .NET 2.0 includes
access to the DirSynch stuff and makes it pretty easy to consume. We cover
how to use that in ch 5 of our book (see link below if interested).
The downside of using dir sync or usnChanged polling is that usnChanged is
not replicated, so you must use a specific domain controller for change
tracking. This approach generally yields better results anyway, but it may
not be appropriate for your particular scenario.
I'd suggest staying away from anything that points you towards forcing
replication. That is almost always a bad design and should not be necessary
for this type of application.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Joe Kaplan

2007-01-09 15:49:13 UTC

Permalink

Yes, definitely.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

When IŽm using the DirSync in .net 2.0, should I always bind to the same
DC?
Thanks again!
--
Jairo Andrés Portela S.
.Net developer