Jump to content

Recommended Posts

Posted

Hello

 

Not been here for a while but somthing is really bugging me now ive googled the hell out of this issue to no ovail.

 

We are getting to the point were most machine have 100+ profiles which has a knockon effect on drive space.

 

I have added group policy "Delete user profiles older than a specified number of days on system restart" but this doesn't appear to work with the "Windows 10" machines #annoying

 

So i have loaded up gpedit.msc changed the setting "Delete user profiles older than a specified number of days on system restart" for the local profile......rebooted still nothing everything is the same......so changed the setting back i then used regshot 1.9 took a shot of the registry then changed the setting then took another shot to see the changes.

 

So i then exported [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]

"CleanupProfiles"=dword:00000005

 

And

 

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\System]

"CleanupProfiles"=dword:0000001e

 

Rebooted the machine but still the profiles are on the machines........Can someone help me with this task

  • 2 weeks later...
Posted (edited)

I trialled using DelProf2 on Windows 10 but it always fails, I remember someone on here using another newer program that did work but can't for the life of me remember what it was called -

 

Anyone have any ideas?

Edited by Warwick_Tech
  • 1 year later...
Posted

I am currently in discussions with Microsoft about this.

 

The GPO setting and Delprof2, by default, both look at the last modified date of NTUser.dat in each profile to obtain profile age. Some Windows Process is modifying the .dat file (I suspect Windows updates and Store Updates) so the .dat file has some random modified date compared to the modified date of users Profile Folder.

 

I am getting no where fast with MS, but you can tell delprof2 to use the timestamp of ntuser.ini to determine the age of the profile using the /ntuser.ini switch, so this may be a better way to go, this seems to be a more reliable gauge of how old the profiles are.

 

I had never seen this problem prior to the summer due to us using roaming profiles and delprof to clean them, however I am now using Local Profiles and UEV so only want to remove unused profiles due to the added logon times of recreating profiles.

  • Thanks 1
Posted
The GPO does indeed work with Local Profiles, been tested and confirmed, for example if I put it down to 1 day old. As long as the .dat files are within the date range. The fact that Premier support are telling me it should be working also confirms this. The GPO setting specifically mentions User Profiles so all profiles. It does work IME and according to MS(But that's no guarantee is suppose! lol)
Posted
Can anyone shed some light on this, we want kids local profiles to be deleted at log off, and if i make the children's AD accounts members of "Domain Guests" they do seem to be deleted at log off. Is there any negatives/pit falls to using this method for clearing local profiles?
Posted
Ok so I have just finished the latest round of data gathering for Microsoft. It is definitely Windows updates, everything was fine until rebooted to install the Cumulative update(Which ever one happens to be there at the time), then on reboot the .dat files are modified. Awaiting response.
Posted
Ok, Microsoft have got back to me. They have replicated the issue, and it would seem this is by design! They are however now aware of the knock on effects of this issue, and it has many implications beyond the issue we are experiencing. This is now with the Product Design team so will see what they come up with. I suspect I will get the dreaded "This will be resolved in a future feature update" response.
  • 3 months later...
Posted

Just had my Premier case closed. The fix for this is only being applied to RS5 (1809), it will not be retrospectively fixed for previous versions of Windows 10.

 

Apparently been an issue since windows 8!

 

 

At Least I am getting all my support time credited back, no finders fee though :(

  • Thanks 4
Posted

Thanks for the 1809 heads up. depending on the school area we use either.

 

GPO to 'Delete cached copies of roaming profiles' on logoff works fine. e.g keep no roaming profile.

 

other than that we use Delprof2 with a GPO to copy the file locally and a start-up script using a signed powershell script.

 

been very reliable with 1706/1709.

  • Thanks 1
  • 4 months later...
Posted
Does anyone have a copy of the script they use with Delprof2 and powershell? This is starting to see this more and more. Would be nice to have to wait to be informed from spiceworks that a drive is nearly full
Posted
I'm finding delprof2 to not work very reliably with windows 10. Seems something to do with apps getting updated also updates the the profiles so they never get older than a few days. Tried a few scripts but can't get any to work.
Posted
I'm finding delprof2 to not work very reliably with windows 10. Seems something to do with apps getting updated also updates the the profiles so they never get older than a few days. Tried a few scripts but can't get any to work.

 

Yep that is the way it is for now. If you check earlier in the thread I was on the phone to Microsoft quite a bit. Its now a known bug, and I was told the fix for this should be in 1809, but seeing as thats been a disaster and you cant get it who knows. as a short term solution, which is not perfect by any means, you can tell delprof2 to use the NTUSER.ini file rather than the NTUSER.dat file to determine profile age. the .ini file is not affected as often as the .dat file by updates.

 

the switch is /ntuserini

  • Thanks 2
Posted (edited)

Is anyone able to IM me a script or point me in a direction of one as I am not a great scripter and anything to get me started would be great? Or an article with how to use Delprof in this scenario?

 

Edit: I think looking at the delprof site I may be able to work it out in the short term. Let's hope 1809 does what they say it will and working nicely with UEV profiles.

Edited by Maxamoth
Added
Posted (edited)

Just create a batch file with the following in it( I am assuming that Delprof2.exe is in your NETLOGON folder in this example and anything older than 5 days /d:5) and use it as a startup script through GPO:

 

"\\DOMAIN\NETLOGON\DelProf2.exe" /ed:admin* /ed:default* /q /d:5 /ntuserini /i

 

I have used the /ntuserini switch as like folk have said, the .dat file is being modified by updates to regularly to be of any use, hence why the Group Policy setting doesnt work either.

 

No need for powershell if all you are wanting to do is have the machine clean itself. I have a powershell script for use with Delprof2 but only so I can selectively clean specific groups of machines of one profile or all profiles at any given site and change the switches on the fly.

Edited by rosslaing
  • Thanks 1
Posted

Along with the built-in GPO we are also using the following PowerShell script to run ion start up to nuke the cached profiles.

 

# Check if there is not currently an in-progress MDT task sequence.

 

if (!(Test-Path -Path "C:\_SMSTaskSequence")) {

 

#Should now be safe to remove profiles.

#Get a list of profiles from the machine.

 

$Profiles = Get-WMIObject -class Win32_UserProfile | Where {(!$_.Special) -and !($_.LocalPath -like "*Administrator*")}

 

if ( ($Profiles | Measure).Count -gt 0 ) {

"[$(Get-Date)] Deleting Profiles" | Out-File "C:\ClearProfiles.log" -Append

 

$Profiles | ForEach-Object {

"Deleting Local Profile: $($_.LocalPath)" | Out-File "C:\ClearProfiles.log" -Append

$_ | Remove-WmiObject

}

 

}

 

}

 

  • 2 weeks later...
Posted
A nasty side effect of an attempt to fix this in the windows code prior to 1809 appears to be the unexpected deletion of user profiles where policy sets a “remove after “ date.
Posted

Ok, I have had 1809 running for a couple of weeks on a few production machines and can confirm that this issue is still not fixed in build 1809. DAT files are still being modified by windows updates and store updates. :mad:

 

This is now the second feature update to pass without this being resolved, even though I was assured by Premium support it would be fixed in a later Feature update.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...