Changing between the domain name and the ip address served no benefit for me unfortunately.  I truly wish we could get Microsoft support on this, I do not want to have to pay the money for the tech support (which I think is ridiculous anyways).  This is obviously an issue, maybe not wide spread but it is effecting some of us.

 Thank you,

Josh

No wait.. strike that.. it only took 1+ minutes for the first queries.. which now it runs at normal speeds! 

But I can't get the description of the group.  One step forward, two steps back. 

Wait until you session expires.....

 My users will connect and the first one will take 30seconds then the subsequent ones can connect right away.  Give it about 2-3 minutes and no one has logged in the next person will have to wait the 30seconds to log in again and so on and so on.

Same problem here, first one takes some time after that all connects are normal.

Wait a few minutes and the whole thing starts all over....

Aye, I am hoping that this thread continually being bumped up to the top by other people having issues other than I will get the attention of someone that can help.  My users have been dealing with this now for almost a year and I can't seem to get a response. 

Thank you,

Josh

Josh,

Could you try this:

- both on the site and on the app-pool in IIS, instead of the default account try to let them run under a domain account. Remember to make the account a member of the local IIS_WPG group or else you can get errors (or at least I get those).

It's a bit to soon to tell but I think the problem is in the first contact. If that is initiated with the default local account something's going wrong. After that it seems to switch to another communication option (hence the smooth opperation after the first long period). After some time I gues the pipe is reset/dropped and everything starts all over again. I bet there are some people around here that could explain this better...

At least this seems to help with me.

Good luck.

We're having the same problem (SBS 2003, everything else AD related is fast, no eventviewer codes, maybe 100 AD accounts). Using IP instead of a name didn't help.

Are you logging security events?

Also try to look at the following: on the webserver that needs to authenticate go to dos-prompt and type: netstat

It should give you no references to the DC you are trying to authenticate against (in that case try to logon in the website) or it should give you several items that metion your server. When performace was slow on my webserver I only got 1 item in the list when a connection was made. After switching to dns-name and the account changes (listed above) I have several items in the list when using netstat.

In the security logs on the DC (not webserver) you should see several items around the time the first connection is made. When somethings wrong you can see why it takes so long because it retries after 30 seconds or so. This happens till some threshold is reached (this is not quit clear to me) after that you can see the loggin succeeds.

Try checking the dns settings also because with ip add, in web.config, it didn't work in my case. Only after switching to dns is perfermance good.

Hope this helps

Hello all,

this is my first time posting, so please forgive lack of etiquette if I have any......

I had a similar problem and was able to fix it with the dns setting mentioned above. We figure out why this happens if this helps anyone. In our domain we have internal dns servers and external, and when we placed our old named configuration file in the internal network  speeds were fine. When we placed it on the web server it took about 60 seconds to log in. After adjusting the config to the proper ip address this solved the problem. Alternately, you could try to edit your hosts file to point to the proper DC. I hope this helps..... 

Just to chime in that I've had the same problems.

1) I built an ldap query using the handy little win2k3 admin pack, which lets you create a query and then have the text of what you did. When I run it in the "Users & Computers" thingy, my request takes a fraction of a second.

2) I take the same code, and drop it into a DirectorySearcher(), doing a for/each to build a collection, and it takes about two minutes and beats the tar out of my web server's processor.

Haven't tried going against an IP instead of the name yet, although I don't understand why that would matter a lot since (I would hope) that when I send my request over that's the end of the conversation with the domain controller; maybe the reference variable is holding a reference all the way back to the LDAP source? :shudder:

So like everyone, I'm not sure why this is causing so much of a headache, and if I come up with anything, I'll of course post it.

I had the same problem. The reason is that the application domain times out every 20 mins if there is no activity, the first request after the timeout can force a recompile and reload of cache. Changing some settings in the machine.config file will solve the problem; unfortunately for me my hosting provider would not allow me to make this change and I do not have enough traffic to keep the cache from timing out. I found this utility to be useful.

http://www.spikesolutions.net/ViewSolution.aspx?ID=c2b7edc0-5de1-4064-a432-05f6eded3b82

Essentially it "Pings" my home page every few mins so the application domain does not time out. The utility can also be configured to ping more than one page so that auxiliary pages are fast too.

Digging out this old post just in case there are new findings. Got the same problem with our project. Hardware and network should not be the cause as AD operations in code does not suffer from the slow response at all. My guess is that when the web app starts the AD membership provider needs to negociate with the AD server to establish some sort of channel, which takes some time to finish. If that is the case, is there any way to speed it up?

Hi!

 Please, I need some help in here... I have the same issue and it's driving me crazy.

Login takes about 20-30 sec, if you logout and login again it will be really fast. Then wait for about  30 min, and login takes 20-30 sec again. I do not understand what is going on????

I have tried different ways of typing the LDAP connection string, and none of them worked.

LDAP://ServerIP/DC=domain,DC=com, this one takes about 20-30 sec

After struggling with this issue on production servers we found out the issue by running a trace. IIS was going to a VeriSign IP Address crl.VeriSign.com to pull an SSL Revocation list.

This would happen the first time a signed assembly was loaded by the IIS Worker Process. The second time you go to the page it was quick. If the assembly was unloaded and had to load again IIS would again call crl.VeriSign.com to get the SSL Cert revocation list.  

We were able to repeat this issue over and over again.

Microsoft has a hotfix, or .NET Framework SP1 plus a configuration setting change to stop IIS from going after the file from VeriSign.

Here are two helpful links.

http://digital.ni.com/public.nsf/allkb/18E25101F0839C6286256F960061B282

Well I am thoroughly impressed....it is sad although that someone from Microsoft couldn't have chimed in with this. Well the program that I originally had the issue with I am not even working with that company anymore....it was just something they had to deal with...unfortunate..I do thank you for the solution though and when I have the displeasure of dealing with this again I'll be referring to your solution!