Revice Password Last Set logic to check local PasswordLastSet and msLAPS-PasswordExpirationTime
Awesome - thank you for the extra details. I am going to do two separate replies - the first one (this one) will focus on a short-term workaround. The second reply will explore some longer-term improvement ideas.
>>Could the fix be to ensure that LAPS is not configured on the master image and that these settings are blank/removed?
>>All local admin passwords are randomized, which means that we would prefer that the master images are also is using LAPS.
My preferred approach to fix your problem would be to just make sure that the Windows LAPS policy is never configured on your master images. Since this goes against your second requirement above, never mind on this option.
The image of the LAPS\State registry key you pasted is not written by policy (whether GPO or Intune). Those registry values are the locally saved breadcrumbs that Windows LAPS uses to keep itself consistent from run to run. Note that those registry values are not documented or intended for external use (granted, it's not hard to understand what they do). What I can suggest here as a short-term solution is the following: after sysprep'ing a new master image, delete ALL of the registry values under the LAPS\State key (don't delete the key itself). The next time Windows LAPS runs, the absence of those values will cause us to do an immediate password rotation on the managed account. Which should put that image into a good state (Windows LAPS-wise, anyway) and fix your problem, if I am understanding everything correctly.
Is it possible for you to implement this workaround within your deployment framework?
One follow-up question: when it is necessary to apply updates to the master image, does that involve booting the master image, or are the updates applied to the offline image?
Jay