Monday, November 15, 2010 2:35 PMHello,
We use the .Net class PrincipalContext to query both AD and ADLDS. On Windows 2008 R2 (at least) and ADLDS, the constructor of PrincipalContext (PrincipalContext(ContextType contextType, string name, string container, ContextOptions options,string userName,string password)) takes 2.5 seconds, causing big delays in our web service. We have seen that this time is spent trying to write to \Server*\MAILSLOT\NET\NETLOGON, which timeouts after those 2.5 seconds. The operation does not fail, it finishes correctly (late but correct) and we can use the PrincipalContext thereafter.
Our guess is that for some reason, somebody is searching for a DC but we don't really know.
This happens mainly when our web service (who creates the PrincipalContext) is in the same machine than the ADLDS service. This is configured as standalone, without any synchonization with an AD.
Any clue would be very welcome
Thanks in advance
Tuesday, July 26, 2011 1:58 AM
I realize this is an old post, but I just had the same issue and identified the problem. I am using System.DirectoryServices.AccountManagement to manage Local User Accounts on a box, and the UserPrincipal.FindByIdentity was taking ~2520ms to return -- very slow! I was using PrincipalContext.Machine on the local machine, so didn't need to be traversing the network at all.
Well, somewhere in the network stack, Microsoft is still initiating NetBIOS Name Service requests, even on Windows 2008r2. For machines with static addresses not on a domain, this means sending a sequence of 3 UDP broadcast packets to port 137 and waiting a half second or so for each to time out. When I tested on a machine using DHCP, it sent a NetBios Name Service UDP packet to each DNS host listed, and each DNS host immediately returned a response that the host name was unknown. This was much quicker than the 3 broadcast packets waiting to time out. When testing on a machine with 2 network adapters, the UserPrincipal.FindByIdentity method was taking ~4600ms, so it was sending the packets to both intefaces sequentially. I realize you can Manage other machines using these objects, and for streamlined code you'd want to treat all hosts the same, but when accessing the local machine, why go to the network at all? I also realize most people would be using AD, so this probably isn't an issue worth addressing.
My fix was to simply disable "NetBios over TCP/IP" on each network adapter's TCP/IP v4 Properties, Advanced, WINS tab. The FindByIdentity method sent no network packets and took a much nicer ~15ms to complete.
- Proposed As Answer by Jeff.on.TechNet.Forums Tuesday, July 26, 2011 1:59 AM
Wednesday, July 27, 2011 5:06 PMI haven't got to try this yet (it's happening @ a customer site), but I'm hopeful it will make a difference. Does NetBios need to be disabled on the machine where FindByIdentity is being called, or on the AD server? I realize that in your case they are one and the same. Thanks.
Tuesday, January 10, 2012 8:06 AMRaising a dead thread again I know. Had a very similar problem where opening a new context could take 18 seconds if it was 20-30 seconds since your last query (i.e. the first call ran slow, immediate subsequent ones fine and then if you left it half a minute then the next call would be slow again). the NETBIOS suggestion did make a difference but still meant a 7 second first call lag. What made a big big difference was fully qualifying the server name in the LDAP string, so rather than LDAP://SERVERNAME use LDAP://SERVERNAME.YOURDOMAIN.LOCAL. This meant the first call was now only taking 100-200ms.