Can you elaborate on the inconsistencies at all? If there is a bug in this functionality, development aren't aware of it, so I'd need to raise this.
Thanks for all your input. Yesterday the PER was accepted as a new requirement, but has not yet been assigned to a particular release. Note that it will not resolve the assignment of arbitrary old users, but it will delay activation until a fresh domain user is assigned.
I'm not so much concerned about an inconsistency where a re-imaged machine effectively "inherits" its previously assigned user(s), I'm concerned about a re-imaged machine activating before it has been domain joined and a domain user has logged in. Although I did not raise the PER, my understanding is that it is the specific situation it is designed to prevent.
I don't believe the "inherited" user situation is particularly serious because, in the case where the machine has been re-imaged as part of assigning it to a new user, the ability of a previous user to boot the machine and then login with their domain account will NOT give them admin privileges on the re-imaged machine, so they will not be able to access the new user's data.
Here our process is if you re-image its a new machine so delete it out of ePO + other systems otherwise you end up with lots of ghost data + other junk you dont need.
I have just confirmed that this issue still exists in Drive Encryption 7.1.1 on ePO 5.1. A newly imaged machine, even with a different version of Windows being installed, will activate more or less immediately upon a network connection if that same machine was previously encrypted with Drive Encryption on the same ePO server.
I still believe the Drive Encryption client should confirm that the assigned user(s) actually exist on the machine before activating. This is a bug as far as I'm concerned not a "feature".
Again to everyone who says "just delete the record in ePO" -- that may work fine in a small company but as a solution it is totally impractical in a worldwide organization with tens of thousands of machines and a dozen or more groups performing machine imaging.
But, no users exist on a machine, or rather only the user profile of the person who logged in immediately after the machine was joined to the domain? The answer would invariably be no, all but one of the users don't have a local profile.
This would seem to be not what the majority of people want, especially given most re-image events are fixing problem in advance of giving them their machine back?
The problem is that activation occurs even before domain join, so no one has logged on other than the built-in Administrator. We have EEPC/DE configured to do a forced reboot as a work around for the "hibernation after activation without reboot = machine won't boot and must be recovered" issue, so as soon as it activates, a reboot happens. This disrupts the re-image/rebuild process and also (presumably because we don't use PBA) requires the tech doing the re-imaging to know the ID necessary to login to PBA during the reboot. Since the machine is not domain joined, the Windows login will fail. I have no idea what this does to the ID's password.
This is not theoretical issue here. We are getting complaints that automated re-imaging scripts are failing because the machine activates and reboots, breaking the re-imaging script.