Local Administrator, Access is Denied to C:\Users\Username(s)

[Garacesh]

Script to delete C:\Users\ folders upon startup, this stops the creation of USER, USER.DOMAIN, USER.DOMAIN.001, USER.DOMAIN.002 etcetera, and it was working, but for some reason is now not.

 

Script is as follows:

$DoNotDelete = ("Administrator", "Public", "Default")
ForEach ($UserFolder in Get-ChildItem "C:\Users") {
if ($DoNotDelete -notcontains $UserFolder.Name) {
	Remove-Item -Recurse -Force C:\Users\$UserFolder 
}
}

 

This silently fails, since it's a startup script and all. If I log in as the local administrator and run the script I get the following errors:

Remove-Item : Access to the path 'C:\Users\Username' is denied.
At \\domain.local\netlogon\DeleteUsers.ps1:4 char:3
+            Remove-Item -Recurse -Force C:\Users\$UserFolder
+            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo		: PermissionDenied: (C:\Users\Username:String) [Remove-Item], UnauthorizedAccessException
     + FullyQualifiedErrorID	: RemoveItemUnauthorizedAccessError,Microosft.Powershell.Commands.RemoveItemCommand

 

The script itself, as far as I can see, is sound. So the question remains, why the heck does the local administrator account (and presumably the SYSTEM account that runs startup scripts) not have access to user folders? They ought to have access to everything!

 

Edit: Looking at permissions of C:\Users..

SYSTEM and Administrators (LocalMachine\Administrators) both have Modify (This folder only) and Full Control (Subfolders and files only)

 

Edit, further testing

$DoNotDelete = ("Drone", "Public", "Default")
$fso = New-Object -ComObject scripting.filesystemobject
ForEach ($UserFolder in Get-ChildItem "C:\Users") {
if ($DoNotDelete -notcontains $UserFolder.Name) {
	$fso.DeleteFolder("C:\Users\$UserFolder")
}
}

gets me

Exception from HRESULT: 0x800A0046 (CTL_E_PERMISSIONDENIED)

So yep, this is definitely looking like it's an NTFS issue. But seriously. Why does the local administrator not have permission?

 

Edit 2:

WHOAMI /GROUP /FO LIST confirms the account I'm using is a local admin

Group Name:	NT AUTHORITY\Local account and member of Administrators group
Group Name:	BUILTIN\Administrators

Edited May 27, 2016 by Garacesh

[vizubeat]

Whilst I appreciate this isn't a solution to the issue of your script not running properly, you might consider taking a look at delprof2 - a replacement for the old Windows delprof tool. If you just delete folders from C:\Users it will get out of sync with the registry and the user profile service list and cause the problem you're trying to resolve.

 

Delprof2 has some powerful options and switches, well worth a look.

[Garacesh]

If you just delete folders from C:\Users it will get out of sync with the registry and the user profile service list and cause the problem you're trying to resolve. .

Aye, I've found delprof2 before.

 

I know that in Windows 7 if you delete the C:\Users\Username folder without deleting the accompanying registry key, that results in the problem I'm seeing, but that doesn't seem to be how it works for Win10. So far my testing has shown that in Windows 10, registry entries are not created at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList when using a Mandatory Profile, which I think is the cause of this problem.. There's no ProfileList entry, so it tries to create a profile for them, C:\Users\Username already exists, so it follows the path of Username.domain, then Username.domain.001 etc

 

I could be wrong, though.

 

I'll look into delprof2 some more, though. Can't hurt.

Edited May 27, 2016 by Garacesh

[Garacesh]

Well, what do you know.. DelProf2 sorted it and got rid of those folders nicely.

 

I do so loathe to use third-party tools as part of the core operating system, but alas, sometimes it can't be helped.. Especially when Windows 10 clearly wasn't written with our establishments in mind.

 

Thanks, @vizubeat!