Someone suggested to enable and increase DefaultWaitTime=0 to larger walue, even 300 seconds.
I guess that database server has been already tuned to parameters suggested in Best Practices guide.
The MEE server has definitely been tuned and everything associated with EEPC and Autodomain have been configured by either McAfee's product guides or recommended by professional services. As a matter of fact, when I upgraded the Autodomain script, it was done with a McAfee employee by my side. He helped me to configure the autodomain.ini and get everything imported to the MEE server.
I do not want to come accross like I am argumentative, but IMHO, suggesting a default wait time of 5 minutes seems a bit extreme. I could understand that suggestion if I was on a 16 bit token ring network, but we are running on a gigabit network with no latency issues.
It is also my understanding that DefaultWaitTime sets a mandatory time for the script to pause before doing any work or performain any database functions. I thought this was more to make sure that the machine remains responsive during boot time. If the script is paused, how is it supposed to ask for credentials?
I am not sure that this would have anything to do with the issue but my install sets were created and set to automatically reboot the machine after install. Having said that, during my testing, everything worked flawlessly by asking for the credentials after the initial reboot.
It must be that you did not "stress test" in production alike environment. With multiple clients deploying simultaneously from different network places (latency and other effects like packet fragmentation and sporadic loss) and large database. Remember that overall result will depend on many factors, application design being the most important one.
Post the autodomain log and the user name of the person experiencing the problem and I'll take a look. Usually this is because the script thinks the user has already been through this ( ie already set to the machine)
I doubt any of this is the cause. The problem is not connectivity, it's logic. The script is deciding not to prompt for a password.
You make impression that script "thinks" . Maybe you, as an author, can shed some light as what makes script to react that way. Any possible causes?
I am definately not an application designer by any means, so I am stabbing in the dark as far as that is concerned. That is why I have come here for expert advice. However, all of the testing that has been done thus far was actually in a production environment on our production server (I know, I know..please don't say it).
The extensive testing I performed "at my desk" is in a production environment and the users that are currently being tested (with intermittent results) are also in a production environment.
I agree whole-heartedly with your statement, but the real question is how to pinpoint the cause of the intermittent results.
I will get hold of one of the autodomain logs, along with the user name, and post it as soon as possible. Thank you.
OK Simon, as strange and rediculous as this may sound there are no autodomain log files on any of the affected machines or users. Is there a location that the log may be going other than C:\temp? I have a desktop tech searching the entire drive for AutoDomain.log.html. I will let you know the results.
I have also just noticed another problem that is semmingly unrelated. If needed I will put it in another post. The issue is that a single user that is not part of any of the admin groups is getting intermittently added to the machine of new eepc installs. strangely enough, there is no log file on these machines either. Any Ideas on this?
EDIT: By the way, I just checked all of the machines on which we have been testing. None of these machines have logs. Did I perhaps screw up something in the autodomain.ini?
Message was edited by: eguhlin on 3/10/10 10:19:58 AM GMT-06:00
Looks like I may have found the culprit, will you please confirm?