I am doing testing with Windows 7 and EEPC 5.2.5 using AUTODOMAIN for user creation and assignment and the OS refresh process provided by McAfee and have run into something very odd on 1-2 laptops so far. Basically the user already exists in the server side database and was already logging in through EEPC before the OS refresh so they must have been in the local SBFS as well. However after the intial installation and required reboot has been completed, the user is getting the window that would appear for a brand new user and that is the mechanism for a brand new user to create their passowrd which then goes and creates their user account in the database and assigns it to the specific laptop the install is running on. I have had the user cancel that window and it re-appears and I have had them enter a password as if they do not have an existing account, but then I see in the log file that it cannot create the user because it already exists.
I must say that up this point in time with Windows XP and EEPC 5.2. with AUTODOMAIN I have never ever seen this type of behaviour for the user creation/assignment functionality, I cannot figure out what is causing the AUTODOMAIN to pop up the "create user" window for an existing user, quite the head-scratcher for me.
I am able to provide the SBClientlog.txt and Autodomain_log.txt files to provide more detail as to the activity that the AUTODOMAIN and the client itself is doing while we are seeing this behaviour.
Please let me know if anyone can help with this one, and thanks in advance.
please post the autodomain logfile first - let's see exactly what it's doing. We'll need to know the user name of the user in question as well.
So do you want the whole file copied/pasted into this discussion window? Or just the relevant sections?
Can I upload the file itself as an attachment, what is the normal process to provide the log file?
Thanks a lot.
yes, just attach it. If you want to strip out the sections, please do, but most of the log is interesting in some way or another.
Here you go, with as much in-house data stripped out while trying to leave the required and important details in it.
While editing the file, I did notice this option being enabled: askforcurrentpassword=true and that did make me wonder if that setting was causing or contributing to what we are seeing. That being said, I have also run the OS refresh process on other laptops with the same EEPC installer and autodomain files/config and did not see the same issue with geting user creation prompt for existing user.
Please review and advise, thanks a lot.
Message was edited by: smmd on 1/26/12 8:08:57 AM CST
Message was edited by: smmd on 1/26/12 8:09:23 AM CSTMessage was edited by: smmd on 1/26/12 8:09:53 AM CST
I think you're running into the old "name mismatch" issue - you're using quite an old version of the script which does not handle that situation, and I guess an old version of EEPC which does not properly update the name in SBFS.
the key section is
1/25/2012 1:07:34 PM: Got local machine name using SBFS method - it is "laptop-name0001"
1/25/2012 1:07:34 PM: 0xe0020021 | Access to driver not permitted
1/25/2012 1:07:34 PM: Running sbadmclSetMachineDescription (laptop-name0001/AutoDomain script Modified this existing active machine. This happened on 1/25/2012 at 1:07:34 PM)...
1/25/2012 1:07:34 PM: Existing Connection
1/25/2012 1:07:38 PM: ....Captured Command Result Description: The name was not found in the database
1/25/2012 1:07:38 PM: ....Captured Command Result Code: 0xdb000004
1/25/2012 1:07:38 PM: Failed sbadmclSetMachineDescription for laptop-name0001 because The name was not found in the database
1/25/2012 1:07:38 PM: 0xdb000004 | The name was not found in the database
1/25/2012 1:07:38 PM: Rename machine failed - strange as the boot code is active? Continuing without trying to move the machine.
I am guessing your laptop name in EEM is "laptop-name", not the one the script thinks (which is the original name). And, the script can't ask EEPC what its real name is, as you are not running the script as an admin, so it guesses.
and in this case the guess is wrong.
Thus, it's trying to process users against the wrong machine object.
You need to either update autodomain, or EEPC to the latest version, preferably both.
Hi and thanks for your time and help, much appreciated.
How would I go about updating only the AUTODOMAIN only and not the EEPC client, where can I get it? I am on version 5.6, what is the latest version / version you recommend to resolve this issue?
As well, as you seem to be referring to a known issue - old "name mismatch" issue - can you provide any more details on that, along with any other causes/fixes for that known issue? Same with this statement: "And, the script can't ask EEPC what its real name is, as you are not running the script as an admin, so it guesses, what do I need to change to fix that to allow the script to be able to get the correct inforamtion from EEPC?
I have had other laptops updated to Windows 7 using the OS refresh process and all the same versions of EEPC and AUTODOMAIN that I have provided and did not run into this issue. So I would really appreciate more details if you can provide them because upgrading the server, client and AD files seems a little drastic (and will be painful and time consuming) if this is something that may not happen very often or that we might be able to figure out an alternate fix for.
I am definitely NOT trying to shoot the messenger, and again I appreciate your time and expertise on all this.
Message was edited by: smmd on 1/26/12 12:03:02 PM CSTMessage was edited by: smmd on 1/26/12 12:05:14 PM CST
the issue will occur if the laptop changes name after it is activated - yours started off as Laptop_0001 or something, then got renamed to Laptop.
Either the new Autodomain, or the updated client will resolve it. I suggest both.
As to where to get it from - same place you got it last time. Unfortunately there's no support for Autodomain as you know outside of Professional Services though.
(edit - re-reading, this appeared a bit rude - what I meant was, people get autodomain from many different places, and some under custom support agreements, so it's best to get the updated version from the same place).
The other thing which can happen (depending on configuration) is your machines will get deleted out of EEM, so I advise you to update Autodomain at least.Message was edited by: SafeBoot on 1/27/12 10:17:34 AM EST