In an interesting turn of events, we have gotten access to one of the
customer's test domain, and I wasted no time attempting the same tests onto
this domain. Surprisingly the method to assign a " " whitespace to the
manager property *actually works*. The user's manager property will no
longer show another user. It seems the production domain and my home domain
are exhibiting some sort of behaviour that this test domain, and possibly
the past development domains, were not "inflicted" with. That may suggest
why the previous developers did not find anything wrong with this code.

Does anybody have any experience or further insight to explain this
behaviour? Is a whitespace considered a valid way to unassign a user's
manager?


Thanks,
Aaron

On Tue, Mar 24, 2009 at 11:53 AM, Aaron Seet <icelava@...> wrote:

> Yesterday I got hold of the actual source employee data and log file that
> was used to update AD, and checked it against the user account provisioning
> code. I began to observe a pattern in the errors, where employees/users with
> no supervisor (NULL) were inducing the “directory service is busy error”.
> Because they have no supervisor, the code logic attempts to assign a mere “
> “ space into their AD user object’s manager property.
> .
> .
> .
> The manager attribute is designed to accept a DN that points to another
> user object, so it appears a whitespace character is not going to cut it.
> The second method is able to properly remove any manager currently assigned
> to a user. It does seem odd though, why wouldn’t AD immediately respond
> stating “invalid user DN; cannot assign manager” for an error message. In
> this manner, it seems to think a single space character is a valid DN and
> attempts to go look for that in the AD store, and even thinks it is busy.
>


[Non-text portions of this message have been removed]