after struggeling with the Gold support i hope that i'm going to find help in the forums...
Used EEPC version: 5.2.0
Business descision: Using $autoboot" and i know that autoboot means to hide the key to the car under the tire. But, i think everybody knows this feeling, i'm not the descision maker. ;-)
First we implemented EEPC 5.2.0 with activated PBA without any problems, worked nice and completely hassle free. Then we switched to the $autoboot$ user and since 5 days the horror is lurking round the corner.
Until know i have 3 clients on which the PBA is turned ON again by some evil forces/magic, without touching the clients configuration. The behaviour should be: autoboot with $autoboot§/12345 and the reduced security level.
But the user powers on the machine and what he get is the PBA screen. Since there is only the $autoboot$ user and another administrative group the user has to go through the challenge and response procedure in order to boot the machine. This is annoying for the user and the poor helpdesk guy.
After the machine is booted once via challenge&response, the user can work until reboot. After that, the PBA pops up again.
One can see absolutely nothing in the logs. The configuration of the two machines are absolutely identical to the config of the other machines where the autoboot works like a charm.
If anyone has a hint that could lead me in the right direction, i will offer a virtual cookie as a gift!
StefanNachricht geändert durch Doxpara on 29.03.10 06:19:50 CDT
anything in the client side log? Maybe the user account got messed up somehow?
If you use one $autoboot$ user on lots of machines, remember (as others have found), if it gets messed up, that change will propagate to everyone else. Best practice is to use a unique autoboot user per machine to stop this.
Because i have decrypted and removed the encryption there is nothing i could say abou the client side log.
Could you plese explain what you mean with "unique autoboot user".
Is there possibility to create several users with the name "$autoboot$"? Is there a manual for this best practice?
We have roughly 130 $autoboot$ accounts.
About 20 calls/month due to the autoboot account (and every other account) getting removed from the client due to a DB collision on that account.
Sorry, should have posted.
~23,000 machines, ~130 autoboot accounts.
(Decisions, decisions...my role is to ADVISE management on risks. They accept or don't)
There's a 1 to 176 relationship between users and machines. I guess it depends on the distribution. If you have a strong 9am effect, you could get dozens of machines trying to update the same account at the same time.
the utopia of course, is to have a 1-1 relationship.