Forum Discussion
Issue with date modified for NTUSER.DAT
Here is the code from the script:
#Purpose: Used to set the ntuser.dat last modified date to that of the last modified date on the user profile folder.
#This is needed because windows cumulative updates are altering the ntuser.dat last modified date which then defeats
#the ability for GPO to delete profiles based on date and USMT migrations based on date.$ErrorActionPreference = "SilentlyContinue"
$Report = $Null
$Path = "C:\Users"
$UserFolders = $Path | GCI -DirectoryForEach ($UserFolder in $UserFolders)
{
$UserName = $UserFolder.Name
If (Test-Path "$Path\$UserName\NTUSer.dat")
{
$Dat = Get-Item "$Path\$UserName\NTUSer.dat" -force
$DatTime = $Dat.LastWriteTime
If ($UserFolder.Name -ne "default"){
$Dat.LastWriteTime = $UserFolder.LastWriteTime
}
Write-Host $UserName $DatTime
Write-Host (Get-item $Path\$UserName -Force).LastWriteTime
$Report = $Report + "$UserName`t$DatTime`r`n"
$Dat = $Null
}
}
I am currently having the same issue and have a call open with Microsoft about it. This has been ongoing now for months. I initially suspected windows updates and Store updates are changing the .dat files, which makes some sense. Looking at event logs you can see the user registry hives being modified and usually preceded by windows update client kicking in to download something.
Microsoft have been round the houses trying to blame everything but the OS, suggesting Anti-Virus software for example, but cant be that with no third party AV on the machine.
I can confirm that this problem has persisted in 1709 as well.
Currently away to use process monitor to confirm what is changing the registry.
My current feeling is that this is expected behaviour and no one wants to admit it.
Just to add, I am only seeing this behaviour since going to 1703 in the Summer as we have switched from roaming profiles to local profiles and UEV, and we were wiping all roaming profiles remnants using delprof tool on startup prior to the summer so machines were clean of profiles on every boot. This is not really an option if you are using local profiles, hence the switch to the GPO.
Thanks for the update and I look forward to seeing if you're able to get a resolution. I can also confirm this is not caused by antivirus. We have Defender completely disabled via GPO and I had McAfee VSE uninstalled at the time of my testing.
