Local Administrator Password Solution

[nsousaarlington]

Has anyone gotten LAPS to work correctly on their instant clones? We have it working on non-Horizon servers without any issues.

[vBritinUSA]

I've not looked at LAPS for awhile but I did see this

LAPS in a Virtual Environment:

LAPS works pretty well when configured on a physical computer that doesn’t change state. Things get a little tricky when you introduce LAPS in a VDI environment.

Persistent VDI (same computer name):
This process is the same as a physical computer since the user connects to the same VDI image which persists (not destroyed at logoff).

Non-Persistent VDI (new computer name):
If the VDI workstation has a new computer name at every connect (non-persistent session, new computer image spun-up as part of user logon), then LAPS will update the password when the LAPS client runs and notices the ms-Mcs-AdmPwdExpirationTime attribute for the AD computer account is blank. As part of this process, the LAPS client generates and sets the local admin password and then updates the LAPS ms-Mcs-AdmPwd attribute on the AD Computer account (the ms-Mcs-AdmPwdExpirationTime attribute is updated as well). No problem here as this process is the same as a physical computer.

Non-Persistent VDI (same computer name:
If the VDI workstation has the same computer name at every connect (non-persistent session, same computer image spun-up), then LAPS will not update the password when the LAPS client runs soon after startup since it will notice that the ms-Mcs-AdmPwdExpirationTime attribute for the AD computer account is within the defined threshold (14 days for example). In this case the LAPS client will sleep until it notices the value in the ms-Mcs-AdmPwdExpirationTime attribute is greater than the threshold. This means that the VDI system would have the default VDI image password during most of the threshold period and for the time while the VDI system is active when the LAPS threshold is exceeded. At this point, LAPS updates the local administrator password locally and on the ms-Mcs-AdmPwdExpirationTime attribute on the AD computer account as well as the ms-Mcs-AdmPwdExpirationTime attribute at which point it sleeps for the defined number of days (14 in this case).
Since  LAPS doesn’t have an (obvious) option to force the LAPS client to change the password at boot-up, a script would need to run to clear the ms-Mcs-AdmPwdExpirationTime attribute so when the LAPS client runs (GPO refresh time) and checks the last password change time (ms-Mcs-AdmPwdExpirationTime), the local admin password would be changed. A PowerShell script can be configured that clears the ms-Mcs-AdmPwdExpirationTime when the user logs off (or during another event). The VDI solution may provide the ability to run a script at this point. A computer startup script (via GPO) would work as well.

Reference