Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Andy, > I joined the new machine to the domain. > > After which: > > 'cvs -ver' displays nothing for ~14 seconds after which it > completes as usual. > 'cvs ls' displays nothing for ~28 seconds after which it > completes as usual. (sspi) > 'cvs ls' displays nothing for ~14 seconds after which it > completes as usual. (local) We use CVSNT on AD all the time and do not experience this. If you have the available resources at home or elsewhere - set up your own domain and re-test, I'm certain the problem won't recur. It seems to me as though there is something wrong with your domain and or DNS. The best problem to tackle is the :local: one since CVSNT is not connecting to the network at all (it will use the loopback to connect to cvslock) - this should just run instantly. You are not running your client in 'simple networking' mode are you? It has to be explicitly turned off in Windows XP Pro from memory. http://support.microsoft.com/kb/307874 If you only experienced the problem with SSPI I would put it down to clock timing differences between the AD and your client (I know you said earlier everything is sync'ed ok). However that would not affect :local:. I'd start by trying to leave your PC connected to the network but start disconnecting 'things' - eg: switch to a different DNS, or put all your DNS entries in the local Windows host file, stopping services or network protocols (I'd be looking for some sort of network snooper/antivirus stuff - again I know you said you do not have any - but still). Try also 'hiding' cvslock.exe so that CVSNT client cannot try and start it when running in :local:. Have you ran cvsdiag on the client - it does list the network stack which may point to a problem. As far as 'local' mode goes there is not much of a difference between CVSNT 2.0.41 and 2.5.04 up to the point of execution where you are seeing the delays, however cvslock.exe could be quite different. Once you find the cause for :local: taking 15 seconds and then fix that I hope that the :sspi: problem will just go away (or at least that the explanation for :local: pointing to an explanation for :sspi:). It may also be worth getting a list of all the group policy settings that have been set in the AD looking for anything particular that may explain what you are seeing (the 'wait 15 seconds randomly when starting open source applications' is the sort of setting you should look for). Regards, Arthur Barrett