Showing results for 
Search instead for 
Did you mean: 
Level 7

Machines, wiped and newly imaged, arriving at McAfee EE Login screen on their own

This is a weird, new issue for me. In a corporate environment, reimaging machines on a daily basis.

99% of Win7Pro imaged machines arrive at the initial Ctrl+Alt+Del screen, and wait for user input for first login. After initial login, Windows sits for a while, and eventually encrypts the drive, arriving at the McAfee EE login after restart.

However, several machines have taken it upon themselves, to enable McAfee Endpoint Encryption, and sit at the McAfee login screen, with no user action required.

This creates a problem, because any user name that is entered, gives a "ERROR EE0500002 Unknown User" error.

Is there something in the ePolicy orchestrator that needs to be done, to prevent a machine from "activating" itself, for lack of a better term, before Windows has been logged into for the first time?

Or, does a machine need to be :"disassociated" with whatever user it was connected to prior?

Thanks in advance!

0 Kudos
3 Replies
McAfee Employee

Re: Machines, wiped and newly imaged, arriving at McAfee EE Login screen on their own

To understand the cause we need to know why the other systems are not activating. The most likley senerio is due to boxes not having users assigned. Likely either a user is now assigned to these boxes allowing for activation or a policy change occurred in which ALDU was set to only currently logged in user and now is set to current a previous users. If the "Force system restart once activation completes" is also selected this would be the expected behavior.

Other possibilities could be occurring but without logs it is difficult to say with any certainty what the actual cause it.

0 Kudos
Level 7

Re: Machines, wiped and newly imaged, arriving at McAfee EE Login screen on their own

Thanks for the reply. Sorry if my thoughts weren't clear.

Here's what we do.

A system is needed for use by another individual. We use a program to wipe the HDD, most of which are SSDs if that makes a difference.

Once wiped, system is restarted, and booted from Network.

Windows installation takes place, and eventually, the system shuts down.

Once powered on, "most" machines arrive at the Ctrl+Alt+Del screen, awaiting the first login by a domain user.

Once logged in, McAfee eventually encrypts the drive, and upon restart, arrives at the EE login screen.


On a few machines, however, it almost seems like after Windows installation, the system doesn't shut down. It seems like McAfee encrypts the drive on its own, and restarts to the EE login screen.

Is there somewhere specifically  in the ePolicy Orchestrator, that I can tell McAfee to leave the machine alone until a user has logged into Windows for the first time?

I'm wondering if there is a McAfee suggested process for reusing domain machines .

Or, maybe part or all of the McAfee MBR hanging around after HDD being "erased," causing the trouble?


I looked at one of the affected systems, and mine, side by side, from the ePolicy Orchestrator> System Tree, and the only differences I could spot right away, were the "User Name" and "Vdi" fields.

Affected machine:

User Name = administrator

Vdi = No

My machine

User Name = my username

Vdi = (blank)

Not sure if this even makes a difference.


Thanks again for your/anyone else's time. Haven't seen issues like this until the last couple of weeks. I am still green to the inner workings of McAfee EE, as far as troubleshooting goes.

0 Kudos
McAfee Employee

Re: Machines, wiped and newly imaged, arriving at McAfee EE Login screen on their own

There are two schools of thought. One is to not activate prior to provisioning. This has the drawback of provisioning systems with disks that are not yet encrypted. Generally, the ALDU option "Only add currently logged on local domain user(s); activation is dependent on a successful user assignment" is utilized and no domain users log on to the system or desktop support personnel are excluded from ALDU using the ALDU policy. This will work if done correctly but will require editing of the configuration, as additional support personnel need to be added or removed from the ALDU policy. The other option is the keep the system in a provisioning group in the system tree with a policy preventing activation. This can run into issues if you are using AD sorting of the system tree.

The second thought is to provision systems only after activation. But as you see, the user assignments have not yet been made. To workaround this preboot needs to be bypassed in some way. The to logical methods to do this is either:

1. Utilize temporary autoboot to set the machine to bypass preboot a specific number of times. This will allow provisioning of the machine to the user and after the machine has been rebooted x number of times, the user is presented preboot in which ALDU has automatically added the user. The temporary autoboot exe can be found in the product download running the utility to enable and set the number of times can be added to the build process. This is my recommended method.

2. The second method is to leave the machine in a provisioning group in the system tree that has an Autoboot policy enforcing. Upon provisioning the system, the machine is moved and because the system has not yet received the policy update, will autoboot the upon the first boot. Depending if you are syncing the System Tree to AD, this may be a  great solution or cumbersome depending upon system renames and AD system tree sorting.

0 Kudos