You can do it manually via eem or the API (setuser/removeuser) - but how are you going to tell if some other user changed their password or not, and how will they change their password if you're using autoboot mode? SSO won't work with Autoboot - if it did then it would only be setting the details of the autoboot account itself?
You'd be better off looking into AutoDomain I think - I was designed to handle/automate all this deployment stuff.
Yes, I'm indeed using autodomain script to harvest the cached users and add them to respective machines.
So, if a Laptop-1 and Laptop-2 have autoboot user added to the policy and autodomain script added to the installation set. Can I do the following
Push the installation set with autodomain
Agent installation completes
Autodmain harvest user ids (User-A & User-B) and adds them to Laptop-1
User-A logs in the laptop at the GINA after the encryption installation and reboot
The policy has SSO enabled, so the windows password is updated in the SB filesystem and also synched with the MEE server
The consequent machine reboots does not bring Preboot
One week later, we remove Autoboot user from machine policy
Now when User-A reboots he logs in with the Windows credentials which he/she is familiar with.
Here I only took example fo Laptop-1. Laptop-2 may be lying around not powered on. So how would I remove the autoboot user (after having the knowledge that the laptop is encrypted and SSO updated) from Laptop-1. How would I capture the fact that Laptop-1 indeed had User-A login and update SSO credentials?
That is where I'm stuck....
You may find out that issues stemming from whole SSO concept, multiple users assigned to each machine and automatic autoboot approach are to complex to handle. Why not to stick to simple and proven approach of single user, default initial password and non-SSO deployment?