Hi @dwseckman12,

I wanted to let you know that we now have a Catalog Worklet for cleaning up dormant user profiles!

You can check it out here: Windows - Maintenance Tasks - Remove Old User Profiles

Be sure to read through the worklet’s help section to ensure you understand how to properly implement the worklet. And test, test, test(!) before rolling out to your production environment!

By default, the worklet will clean up unused profiles older than 30 days, but you can change the $ageLimit variable to specify your needs.  There is also an optional commented out $whitelistedUsers variable that can be defined if you would like to exclude certain profiles from the clean up (administrator, VIP,  or service accounts for example).
 

Have a great day!

Hi @JohnG-Automox, I’m testing this worklet and it isn’t working for me. The script says there are no stale profiles older than the specified ageLimit (90 day in my case), but there are. I also tried a GP to do this but that also isn’t working.

Then I found this post. Could it be that the ntuser.dat files are being updated and thus fooling the GP/script?

https://learn.microsoft.com/en-us/answers/questions/441800/group-policy-automatically-delete-user-profiles-ol

Any help would be appreciated! Thanks.

Hi @sparrowhawk !

Our Catalog Worklet works by detecting present user profiles via Get-CimInstance -ClassName 'Win32_UserProfile', and then iterates through each object found in the class to get the LastUseTime.

To your point though, if the ntuser.dat file is being mounted or queried, this would in fact change the return for the LastUseTime property.  I’ve seen instances where Antivirus software may mount ntuser.datfor scanning registry hives, and thus cause the last modified timestamp to get updated for the profiles.  I’m wondering if something like this is occurring in your environment.

We will have to investigate further before we can cook up another solution.  I have opened a ticket for myself to look into what are options are.  I’ll keep you posted with my findings!

Hi @JohnG-Automox , thanks, it would be great to get this working. I had some help from @AnthonyM-Automox a few weeks ago on a worklet to stop Teams from auto installing into a profile, because these instances were not being updated and then would be flagged by Tenable as a vulnerability. That worked a treat, for Teams, but there are other applications I also need to remove so this worklet would be the perfect solution.

Sorry that you hard work was in vain @AnthonyM-Automox ! 

@JohnG-Automox are you able to share the support ticket with me so that I can help you with more info? I’ve run that PS command and it reyurns all of the users that have profile folders which I want to remove. The “lastusetime” fields are empty though.

Hey @sparrowhawk,  I’ll DM you!

@JohnG-Automox I am experiencing the exact same thing. I would appreciate any update you may have on this as well. Thanks

Hi @ericee,

We have a request in for re-writing this worklet based on the findings in my previous post.

We’ll post here when the changes go live.

Until then, I will reach out to you via DM to assist in the immediate.

Have a great day!

Hey @JohnG-Automox,

Can you also let me know what was modified to exclude the .dat file? 

Hi @Joe Wash !

We currently have a pull request in for the previously discussed changes to the Windows - Maintenance Tasks - Remove Old User Profiles Catalog Worklet.

If you were looking for something in the immediate, here is the rewritten Worklet I put together and previously shared:

Evaluation Code
Remediation Code

This Worklet uses different detection logic for finding and removing profiles that are deemed stale.

Instead of looking at the LastUseTime return from Get-CimInstance -ClassName 'Win32_UserProfile', the new code instead uses the delta of LocalProfileLoadTime and LocalProfileUnloadTime to determine more precisely if a profile was actually used/logged into or not.

This rewritten Worklet was provided to help the previous poster with their specific scenario, but feel free to try it out for yourself. Just be sure to test it in a controlled environment first, so you understand how it works before deploying to your production devices.

Hope this helps!

@JohnG-Automox - This is perfect!  We are going to do some testing of course.  But quick glance at the evaluation code looks like it will do the trick! Thank you!