Password will not Rotate and Name does not Update in CloudLaps after Re-image and Rename

[rodawing]

After re-imaging and renaming a computer the computer name will not update in Cloudlaps and password will not rotate. CloudLaps seems to hold on to the old computer name. The computer was removed from AAD and Intune before being re-imaged and renamed. Does anyone know where CloudLaps stores the computer names so I can remove the old one?

[dbarajas1]

Stores in the key vault. You'll have to give yourself permissions to be able to view those and then purge old ones.

[dwiller11]

I think I may be running into this too. I do a lot of re-imaging using the same device/serial as part of testing deployment scenarios. But I have seen it work sometimes so that makes me wonder if there's something else causing the issue. I saw another post about the rotation frequency set in the function app - could it be that if I'm re-imaging multiple times daily?

Event ID 14 - CloudLAPS: Forbidden, password was not allowed to be updated.

Otherwise, working great! what a cool tool.

[dwiller11]

OK, confirmed, in my case, it was not able to rotate the password for that re-imaged device because it had not been enough days since the last time it rotated for that same device. CloudLAPS uses the serial number to store the password in the keyvault so from CloudLAPS perspective, it was the same exact device even though it had been re-imaged. I set the "UpdateFrequencyDays" setting in the function app to "0" and it was able to rotate.
@rodawing

[PatsGithu8]

Hi
We also just discovered this and want to try and work out how to clear the timestamp or clear the serial number from the keyvault
What we had with the old LAPS is when imaging a device and the LAPS install script was executed. We added a powershell command to clear the Active Directory timestamp for that computer name
This allowed LAPS to update the password instantly
So a newly imaged device would have its LAPS account created and password updated

Does anyone know how to do similar with the keyvault in Azure AD ?

[dwiller11]

Did you try changing the function app UpdateFrequencyDays to 0? I haven't had any issues after changing it to 0. The password changes every time the baseline runs but that's OK, I'd be looking up the password and copying and pasting it anyway so it's no extra work. Even devices that I re-image over the top get a LAPS password assigned almost immediately since baselines run soon after workplace join/autopilot. Not sure what else you might be running into. If that doesn't work, can you describe the exact problem you're running into?

[PatsGithu8]

Did you try changing the function app Confirm-SecureBootUEFI to 0? I haven't had any issues after changing it to 0. The password changes every time the baseline runs but that's OK, I'd be looking up the password and copying and pasting it anyway so it's no extra work. Even devices that I re-image over the top get a LAPS password assigned almost immediately since baselines run soon after workplace join/autopilot. Not sure what else you might be running into. If that doesn't work, can you describe the exact problem you're running into?

Hi Thanks for the reply
No I havent yet
This might work ok with our on prem machines (domain joined) as we use a configuration baseline that is set to run once a day ( so the same frequency as I set in the function app )

But not sure how this will work with our Azure-Joined machines. Would it stop updating completely if its set to 0 on those azure-joined devices?

Worth a test though

Wanted a more permanent and automated solution to the imaging issue as we re-image many machines per day

[dwiller11]

It never even occurred to me that this would also work for on-prem, AD-joined devices. I think most people are using this with Intune, do you have Intune + AAD or just AAD? Or SCCM? Or anything that can run some kind of script regularly on an AAD-joined device?

If you set that setting to 0, it just updates the password in the KV every time the script runs. That solved my problem because I also re-image constantly throughout the day when I'm testing things and I was running into an error than prevented the password from being updated in the KV for a serial number that was updated less than X days ago.

[PatsGithu8]

It never even occurred to me that this would also work for on-prem, AD-joined devices. I think most people are using this with Intune, do you have Intune + AAD or just AAD? Or SCCM? Or anything that can run some kind of script regularly on an AAD-joined device?

If you set that setting to 0, it just updates the password in the KV every time the script runs. That solved my problem because I also re-image constantly throughout the day when I'm testing things and I was running into an error than prevented the password from being updated in the KV for a serial number that was updated less than X days ago.

CloudLAPS was that fantastic to us we wanted to make it work with our on prem environment and evetually let it replace old LAPS
We have so many users working at home now since COVID hit and hardly any of the old LAPS passwords are updating
so we combined both detection and remediation scripts and threw it in SCCM configuration item / baseline to run once a day
It works ok. But just a few of issues I would like to sort out. Like the newly imaged machine issue I am writing here about

We have two environments ( currently in testing and development is our AAD ) and we use SCCM for our older environment
We use the configuration basline via SCCM to execute the CloudLAPS scripts once a day to our old environment

Changing the update frequency to 0 will work ok with our old domain joined environment as we use SCCM to run the script on a daily basis

But unsure how it will trigger on our AAD environment

[dwiller11]

Are you moving to AAD and trying to leave AD/SCCM behind with no connectivity between the two? SCCM can work with AAD and for internet clients, could you use an SCCM cloud management gateway? (https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/overview) Or better yet, could you just use Intune? I have a similar problem, I have Intune but Intune doesn't manage servers so I'm not sure how I could do LAPS (or any app deploy or running scripts/config) on straight AAD-joined server OS. :/

[RaghuKeenLearner]

We have two environments ( currently in testing and development is our AAD ) and we use SCCM for our older environment
We use the configuration basline via SCCM to execute the CloudLAPS scripts once a day to our old environment

so where does the password go? Does it go to same portal? TBH with you I never though about this from on-prem perspective before.

[PatsGithu8]

We have two environments ( currently in testing and development is our AAD ) and we use SCCM for our older environment
We use the configuration basline via SCCM to execute the CloudLAPS scripts once a day to our old environment

so where does the password go? Does it go to same portal? TBH with you I never though about this from on-prem perspective before.

It goes to the same loction to the Azure Function app keyvault. It behaves the same way except we get SCCM to deploy execute the script

Are you moving to AAD and trying to leave AD/SCCM behind with no connectivity between the two? SCCM can work with AAD and for internet clients, could you use an SCCM cloud management gateway? (https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/overview) Or better yet, could you just use Intune? I have a similar problem, I have Intune but Intune doesn't manage servers so I'm not sure how I could do LAPS (or any app deploy or running scripts/config) on straight AAD-joined server OS. :/

I just set the update frequency to 0. But I think this will cause the Azure AD devices to never rotate the password ever

On https://msendpointmgr.com/cloudlaps/#12-function-app-documentation
it states the following:

UpdateFrequencyDays
Password rotation (described more in detail in the solution overview documentation above) will only be allowed if the most recent password rotation occurred in the past, more than the specified amount of days configured in this application setting. The default value is 3, which for instance only allows the password rotation process from a device to happen every 3 days. Change this value to a desired amount of days that meets the organization requirements. A value of 0 is not supported.**_