The issue occurs even if with GPupdate /force. I can go into the DC and change the expiration to a date further then 1 year in the past and run gpupdate and it will update the password in DC and the machine . If however, the password (laps is set to 1 year) is more then 42 days old and the user enters that recovery password for the .\rescue account to log into the laptop for the first time, it will say the password is expired and must be changed but it will not allow them to change it. They then have to bring it in , I change the attribute mc-Mcs-AdmPWD expire to a date older then 1 year (for example 132856932200000000 that is 1/3/2022) it will then on next GPUpdate set a new ADMPWD in the attributes on the DC and they can use that password to log in the first time. Currently the way this is working and what we use it for is we provide them the laptop, we use DUO, and netextender and LAPS to manage a local user (.\rescue) they log in using that, they connect to there wifi, they then connect to netextender, once they are connected they do a switch user, then enter there domain credentials, it caches those credentials to the machine, then they can log back into the laptop without using the .\rescue and connect to the netextender. Problem is if the laptop has been updated and ready to provide to a user for BC purposes and it has been sitting in the server room for more then 42 days that password will not work and that is why we set the LAPS to 1 year.
My thought was that Domain group policy is not only effecting the domain users but also the local rescue account and overrides the LAPS GPO. But not sure how to get GP to not effect the rescue account when it comes to the password policy and let laps manage that one but still have password group policy enforce the 42 day policy for domain users.