We just upgraded our autodomain script to 5.25 after upgrading the MEE server to 188.8.131.52. I set all of the parameters in the autodomain.ini and tested very extensively. Everything worked famously during my testing period. We dicided to start testing in the general population of our company and things went a bit awry.
Here is the issue, during testing of the autodomain script, it would ask for the users credentials 100% of the time. Now that it is being tested in the wild, 30-40% of the time the autodomain script is not asking for credentials. I reeled everythig in again and started to do more testing and I cannot reproduce the problem no matter what I do. The only difference is that I am sitting at my desk and some of the test users are on different subnets. I saw a post in McAfee Communities that a user may be rebooting too soon or the network connection may be dropping. I am certain that this is not the issue here. At this point, I have desktop techs performing the installs in the wild and they have been given explicit written instructions on how to perform the install. Furthermore, ping times are consistent with the MEE server at 1ms.
Can anyone provide any further insight as to why this is happening? I have also attached one of my autodomain.ini files in case it is needed. I am going crazy, please help. Thanks.
Solved! Go to Solution.
users are never encrypted - machines are? Users always have credentials, you have to set them when you create them.
You are right - you are confusing lots of things. The impetus to ask the user for their password is the creation event by default, (askforcurrentuserpassword). If you want to ask during a set event (where the user already existed), you need to also turn on alwaysaskforcurrentuserpassword.
it's not asking for the credentials because the user already exists in EEM.
The script follows this logic to make sure that if a user uses more than one machine or is a current admin or EEFF user, they don't get asked unnecessary questions. In your case, since you're pre-creating the users (with default passwords), this means we assume the user is already aware of their credentials.
So, you can either continue how you are and turn on alwaysask... , or you can let autodomain create the users as it goes.
So, for the users who ARE getting prompted, I guess they are also being created at the same time (check the autodomain log), which would mean there's probably something wrong with your connector settings (it's missing users). Unless you were smart enough to put the connector details in the autodomain.ini file, that probably means you have some unmanaged users (you can use linkuser to re-establish the connection)
If you are using the connector to create users, you can turn off user creation in AutoDomain - it should not really be necessary.
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.
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.
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 will get hold of one of the autodomain logs, along with the user name, and post it as soon as possible. Thank you.Message was edited by: eguhlin on 3/10/10 9:48:21 AM GMT-06:00
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?