I have a program which our Account Operators use to create accounts, rename
accounts, move accounts in AD, etc. which encapsulates some local rules,
accesses the HR data, and generally makes the process much easier than using
the ADU&C or other basic tools. The program is in VB6.

After either a rename operation or a move, the distinguished name (DN) is
different. Often other operations may be needed on the same account which
was renamed/moved. Because the operations take place in different modules,
it is not practical (and would be fairly complicated) to retain the new DN
after the rename/move to be used in a new operation on the same account.
Finding a new DN with nameTranslate often fails due to replication delays (I
expect). In testing I observe that I can prevent program issues by adding
undesirable measured delays to the follow-up operations.

Two options are:
Retry operations which may be subject to replication delays.
Do all operations to a single domain controller (instead of not specifying).

I favor the second option so that undesirable retry delays won't be needed.
However, I am not sure how to maintain the affinity to a specific DC for the
nameTranslate operation. I would pick a specific DC at program start rather
than hard code any DC names.

Hi,

Can't you just do the move operation last, then the delay won't matter?

Rich Raffenetti wrote:

Gerry,
That would be a good idea. Indeed, the move operation is the last of
the multi-attribute changes which are also needed. However, my account
operators have a habit of checking the status of the account which was just
moved. It is this operation which would fail due to the move. At the same
time, I prefer to then refresh the display, which also shows the attributes
of the same account by fetching them from AD. These fetches also fail for
the same reason. Either way, I need to stop the failures.

The failures are definitely a timing issue. It's easy to show that by
adding breakpoints and inserting a manual delay, after which there is no
failure.

"Gerry Hickman" wrote in message
news:OM%%239BGUtIHA.420@TK2MSFTNGP02.phx.gbl...

Hi Rich,

Bear in mind, even with Microsoft's own ADUC tool, you will also get
this exact behavior. If you move an account, and try to use the tool
(without hitting refresh) you'll get an error.

Therefore, your app should simply say "operation in progress" or
"there's a world outside the dimensions of your computer screen" or
something like that?

Rich Raffenetti wrote:

Thanks to all for the responses. However, I have arrived at the following:

The real problem is that I started using the nameTranslate service to
determine a distinguished name whereas before I had been using an LDAP
query. NameTranslate has the unwanted effect.

My program starts out by creating the rootDSE object and keeps that object
during its operation. I believe (and I may be way off base) that because I
keep the object open, then following LDAP queries use the same DC as was
used to get rootDSE. At least, my program formerly did not have any latency
issues when I was not using nameTranslate. I started keeping the object
active was originally a way to improve performance - repeatedly creating a
connection seems to add considerable overhead. I'm sure I read about
improving performance by keeping an open connection. I presume that a
static connection would have to be to only one DC.

I find NameTranslate faster than queries that must search AD. NameTranslate
has an Init method, which can connect to a specific DC, the domain, or a GC.
It sounds like the Init method connected to a different DC that wasn't aware
of the move/rename. When I query AD I specify the connection object, but you
don't pass an existing connection object to NameTranslate. Short of hard
coding a DC, which isn't wise, I can't think of way to ensure NameTranslate
uses the same DC. If there was a way to determine which DC was used for the
move/rename, you could specify that DC in the Init method.

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

"Rich Raffenetti" raffenetti_takethisout.com> wrote in message
news:OhEb6IQuIHA.748@TK2MSFTNGP05.phx.gbl...