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.
So I tested this theory out in my home domain,
public static void BlankManager(string username)
{
DirectoryEntry updateUser =
FindStaticUser(username);
if (updateUser == null)
throw new
ApplicationException(username + " not found in the static OU.");
updateUser.Properties["manager"].Value =
" ";
updateUser.CommitChanges();
}
public static void UnassignManager(string username)
{
DirectoryEntry updateUser =
FindStaticUser(username);
if (updateUser == null)
throw new
ApplicationException(username + " not found in the static OU.");
if
(updateUser.Properties.Contains("manager"))
{
updateUser.Properties["manager"].RemoveAt(0);
updateUser.CommitChanges();
}
}
True enough, the first method will cause the “Directory service is busy”
error to surface – after a typical 30-second wait. Additional info returned
from that p/invoke method call:
8409: 000020D9: SvcErr: DSID-031510BA, problem 5001 (BUSY), data 13
(LDAP Provider)
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.
At any rate we have reported our findings to the customer and hopefully be
able to test this out in their environment soon.
Thanks,
Aaron
[Non-text portions of this message have been removed]