Remove-Item cannot remove crap in Documents folder

[DustinB3403]

Can you take ownership of the files first with something like this?

New-Item -type directory -path C:\Users\admin\NextCloud
$Acl = Get-Acl "C:\Users\admin\Documents\My Music"
$Ar = New-Object  system.security.accesscontrol.filesystemaccessrule("ROOT","FullControl","Allow")
$Acl.SetAccessRule($Ar)
Set-Acl "C:\Users\admin\NextCloud" $Acl

Replacing ROOT with whatever the username is?

[Emad R]

@JaredBusch said in Remove-Item cannot remove crap in Documents folder:

powershell

Interesting approach, what I used to do is robocopy and scan for specific file extensions (usually MS office)and copy them to NC folder, cause this way stuff like Outlook files will be tricky for NC, and I used third party copy solution that uses VSS to copy locked filed into NC folder. but that was like 3 years ago and now I'm much more dumber

[JaredBusch]

@Emad-R The point is to create symlink in the location Windows expects the files to be by default. I find this a much better solution than changing the location of the folders. Because it seems half the time the crap on the computer is hard coded.

Doing it this way

Causes problems. I no longer do this.

But I hate the manual steps to clean the documents folder. so that is why I posted.

[black3dynamite]

I'm still trying to figure out how to automate the remover of those hidden items, so I've been renaming the root folders and setting the attributes to hidden and system.

Rename-Item "$UserProfile\$Folder" "$UserProfile\$FolderOld" -Force
$(Get-Item $UserProfile\$FolderOld).Attributes = "Hidden","System"

[JaredBusch]

@black3dynamite said in Remove-Item cannot remove crap in Documents folder:

I'm still trying to figure out how to automate the remover of those hidden items, so I've been renaming the root folders and setting the attributes to hidden and system.

Rename-Item "$UserProfile\$Folder" "$UserProfile\$FolderOld" -Force
$(Get-Item $UserProfile\$FolderOld).Attributes = "Hidden","System"

Windows lets you do that? As the user?

Do you then create a new empty documents folder? Or are you creating a symlink or something like I am doing?

[Obsolesce]

@JaredBusch said in Remove-Item cannot remove crap in Documents folder:

So, I have a process for user computers to change the user folders into links pointing to the Nextcloud copy of the folder.

I want this automated, but I cannot because I cannot remove the Documents folder.

Here is the script, abbreviated to just Documents

$User = $env:UserName
Remove-Item -Path "C:\Users\$User\Documents" -Force -Recurse
New-Item -ItemType Junction -Path "C:\Users\$User" -Name "Documents" -Target "C:\Users\$User\Nextcloud\Documents" -Force

Here is the result of the second line.

Here is the cause. Empty folder is not empty.

Show hidden and system...

Surprise!

Pictures and Videos can be deleted.


But Music pukes and requires admin rights.


But it is a user folder that the admin account has no access to.

So I have to manually open Explorer as admin and gain access to the folder, then I can delete it.

Then the script above will run normally.

Anyone have an idea on how to resolve this?

Does the script work if you run it as system? That's what I would run it as, instead of as an account without correct permissions.

[black3dynamite]

@JaredBusch said in Remove-Item cannot remove crap in Documents folder:

@black3dynamite said in Remove-Item cannot remove crap in Documents folder:

I'm still trying to figure out how to automate the remover of those hidden items, so I've been renaming the root folders and setting the attributes to hidden and system.

Rename-Item "$UserProfile\$Folder" "$UserProfile\$FolderOld" -Force
$(Get-Item $UserProfile\$FolderOld).Attributes = "Hidden","System"

Windows lets you do that? As the user?

Do you then create a new empty documents folder? Or are you creating a symlink or something like I am doing?

For new users, I do something like this.

$_oUserProfile = $env:USERPROFILE

Move-Item "$_oUserProfile\Documents" "$_oUserProfile\Nextcloud\Documents" -Force

# Rename-Item and Hide the folder if Move-Item doesn't move the Folder
Rename-Item "$_oUserProfile\Documents" "$_oUserProfile\Documents_Old"
$(Get-Item "$_oUserProfile\Documents_Old").Attributes = "Hidden","System"

# Then I create the link
New-Item -ItemType Junction -Path "$_oUserProfile\Documents" -Value "$_oUserProfile\Nextcloud\Documents"

If this was a previous nextcloud user, I skip the Move-Item and just rename the folder and hide it. Then create the link.

[Obsolesce]

@JaredBusch
I had a little bit of fun... whether useful to you or not.

You can run this script as a regular user that has permissions to create and run scheduled tasks and create a file in specified directory.

This will create a powershell script, and a scheduled tasks to run the script as the SYSTEM account. Then it will delete the script and the scheduled task.

I could test most of it, but not some of it for obvious reasons.

<#---- CHANGE THESE VARS: ----#>

# Users to exclude from profile manipulation script, separated by pipe:
$excludedKnownUsers = "Administrator|SpecialUser1"

# New Script:
$newLocalScriptPath = "$ENV:SystemDrive\scripts"
$newLocalScriptFile = "testScript.ps1"

# SID ending: (likely 21 if domain users)
$sidEnd = 21

# Scheduled Task Name:
$TaskName = "_Test Task 1"

# Scheduled Task Description:
$Description = "This is a test scheduled task that runs as the SYSTEM account and will be ran and then deleted at the end of this script."

<#-------- END CHANGE --------#>

# New Script:
$newLocalScript = "$newLocalScriptPath\$newLocalScriptFile"

# Gethers list of user profile paths:
$userPaths = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*" -ErrorAction SilentlyContinue | Where-Object {($_.PSChildName -split '-')[3] -eq $sidEnd -and ($_.ProfileImagePath -split "\\")[2] -notmatch $excludedKnownUsers}

# Creates a 'script in memory':
$testScript = $null
foreach ($userPath in $userPaths.ProfileImagePath) {
    $testScript += "Remove-Item -Path "$userPath\Documents" -Force -Recurse`n"
    $testScript += "New-Item -ItemType Junction -Path $userPath -Name 'Documents' -Target '$userPath\Nextcloud\Documents' -Force`n"
}

# Create a PowerShell script and save it as specified in vars:
if (-not(Test-Path $newLocalScript)) {New-Item -Force $newLocalScript}
$testScript | Out-File $newLocalScript -NoNewline -Force

# Task Action:
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy Bypass -File $newLocalScript"

# Task Trigger: (task will be manually run immediately and then deleted, so keep 1 year out)
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddYears(1)

# Task Compatibility: 
$Compatibility = "Win8" # 'Win8' is 'Windows 10' in the GUI

# Task Settings:
$Settings = New-ScheduledTaskSettingsSet -Compatibility $Compatibility -StartWhenAvailable -AllowStartIfOnBatteries

# Run task as local SYSTEM account with highest privileges:
$Principal = New-ScheduledTaskPrincipal -UserId 'S-1-5-18' -RunLevel Highest

# Create the scheduled task:
Register-ScheduledTask -TaskName $TaskName -Description $Description -Action $Action -Trigger $Trigger -Settings $Settings -Principal $Principal -Force

<#--------------------------#>

# Run the scheduled task:
Get-ScheduledTask -TaskName $TaskName | Start-ScheduledTask

# Remove the created script:
Remove-Item $newLocalScript -Force

# Delete the scheduled task:
Get-ScheduledTask -TaskName $TaskName | Unregister-ScheduledTask -Confirm:$false

[Dashrender]

@Obsolesce said in Remove-Item cannot remove crap in Documents folder:

@JaredBusch
I had a little bit of fun... whether useful to you or not.

You can run this script as a regular user that has permissions to create and run scheduled tasks and create a file in specified directory.

This will create a powershell script, and a scheduled tasks to run the script as the SYSTEM account. Then it will delete the script and the scheduled task.

I could test most of it, but not some of it for obvious reasons.

<#---- CHANGE THESE VARS: ----#>

# Users to exclude from profile manipulation script, separated by pipe:
$excludedKnownUsers = "Administrator|SpecialUser1"

# New Script:
$newLocalScriptPath = "$ENV:SystemDrive\scripts"
$newLocalScriptFile = "testScript.ps1"

# SID ending: (likely 21 if domain users)
$sidEnd = 21

# Scheduled Task Name:
$TaskName = "_Test Task 1"

# Scheduled Task Description:
$Description = "This is a test scheduled task that runs as the SYSTEM account and will be ran and then deleted at the end of this script."

<#-------- END CHANGE --------#>

# New Script:
$newLocalScript = "$newLocalScriptPath\$newLocalScriptFile"

# Gethers list of user profile paths:
$userPaths = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*" -ErrorAction SilentlyContinue | Where-Object {($_.PSChildName -split '-')[3] -eq $sidEnd -and ($_.ProfileImagePath -split "\\")[2] -notmatch $excludedKnownUsers}

# Creates a 'script in memory':
$testScript = $null
foreach ($userPath in $userPaths.ProfileImagePath) {
    $testScript += "Remove-Item -Path "$userPath\Documents" -Force -Recurse`n"
    $testScript += "New-Item -ItemType Junction -Path $userPath -Name 'Documents' -Target '$userPath\Nextcloud\Documents' -Force`n"
}

# Create a PowerShell script and save it as specified in vars:
if (-not(Test-Path $newLocalScript)) {New-Item -Force $newLocalScript}
$testScript | Out-File $newLocalScript -NoNewline -Force

# Task Action:
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy Bypass -File $newLocalScript"

# Task Trigger: (task will be manually run immediately and then deleted, so keep 1 year out)
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddYears(1)

# Task Compatibility: 
$Compatibility = "Win8" # 'Win8' is 'Windows 10' in the GUI

# Task Settings:
$Settings = New-ScheduledTaskSettingsSet -Compatibility $Compatibility -StartWhenAvailable -AllowStartIfOnBatteries

# Run task as local SYSTEM account with highest privileges:
$Principal = New-ScheduledTaskPrincipal -UserId 'S-1-5-18' -RunLevel Highest

# Create the scheduled task:
Register-ScheduledTask -TaskName $TaskName -Description $Description -Action $Action -Trigger $Trigger -Settings $Settings -Principal $Principal -Force

<#--------------------------#>

# Run the scheduled task:
Get-ScheduledTask -TaskName $TaskName | Start-ScheduledTask

# Remove the created script:
Remove-Item $newLocalScript -Force

# Delete the scheduled task:
Get-ScheduledTask -TaskName $TaskName | Unregister-ScheduledTask -Confirm:$false

This seems like a HUGE security problem - normal users can schedule a task to run as SYSTEM? Then any virus could do the same thing. So what am I missing?

[Obsolesce]

@Dashrender said in Remove-Item cannot remove crap in Documents folder:

@Obsolesce said in Remove-Item cannot remove crap in Documents folder:

@JaredBusch
I had a little bit of fun... whether useful to you or not.

You can run this script as a regular user that has permissions to create and run scheduled tasks and create a file in specified directory.

This will create a powershell script, and a scheduled tasks to run the script as the SYSTEM account. Then it will delete the script and the scheduled task.

I could test most of it, but not some of it for obvious reasons.

<#---- CHANGE THESE VARS: ----#>

# Users to exclude from profile manipulation script, separated by pipe:
$excludedKnownUsers = "Administrator|SpecialUser1"

# New Script:
$newLocalScriptPath = "$ENV:SystemDrive\scripts"
$newLocalScriptFile = "testScript.ps1"

# SID ending: (likely 21 if domain users)
$sidEnd = 21

# Scheduled Task Name:
$TaskName = "_Test Task 1"

# Scheduled Task Description:
$Description = "This is a test scheduled task that runs as the SYSTEM account and will be ran and then deleted at the end of this script."

<#-------- END CHANGE --------#>

# New Script:
$newLocalScript = "$newLocalScriptPath\$newLocalScriptFile"

# Gethers list of user profile paths:
$userPaths = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*" -ErrorAction SilentlyContinue | Where-Object {($_.PSChildName -split '-')[3] -eq $sidEnd -and ($_.ProfileImagePath -split "\\")[2] -notmatch $excludedKnownUsers}

# Creates a 'script in memory':
$testScript = $null
foreach ($userPath in $userPaths.ProfileImagePath) {
    $testScript += "Remove-Item -Path "$userPath\Documents" -Force -Recurse`n"
    $testScript += "New-Item -ItemType Junction -Path $userPath -Name 'Documents' -Target '$userPath\Nextcloud\Documents' -Force`n"
}

# Create a PowerShell script and save it as specified in vars:
if (-not(Test-Path $newLocalScript)) {New-Item -Force $newLocalScript}
$testScript | Out-File $newLocalScript -NoNewline -Force

# Task Action:
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy Bypass -File $newLocalScript"

# Task Trigger: (task will be manually run immediately and then deleted, so keep 1 year out)
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddYears(1)

# Task Compatibility: 
$Compatibility = "Win8" # 'Win8' is 'Windows 10' in the GUI

# Task Settings:
$Settings = New-ScheduledTaskSettingsSet -Compatibility $Compatibility -StartWhenAvailable -AllowStartIfOnBatteries

# Run task as local SYSTEM account with highest privileges:
$Principal = New-ScheduledTaskPrincipal -UserId 'S-1-5-18' -RunLevel Highest

# Create the scheduled task:
Register-ScheduledTask -TaskName $TaskName -Description $Description -Action $Action -Trigger $Trigger -Settings $Settings -Principal $Principal -Force

<#--------------------------#>

# Run the scheduled task:
Get-ScheduledTask -TaskName $TaskName | Start-ScheduledTask

# Remove the created script:
Remove-Item $newLocalScript -Force

# Delete the scheduled task:
Get-ScheduledTask -TaskName $TaskName | Unregister-ScheduledTask -Confirm:$false

This seems like a HUGE security problem - normal users can schedule a task to run as SYSTEM? Then any virus could do the same thing. So what am I missing?

I assume regular user would need elevated privileges at least... But I didn't test as a non-local admin, which is different than elevated privileges. But either way, that script can be automated and run as a user in the local admin group too with successful results.

[Dashrender]

@Obsolesce said in Remove-Item cannot remove crap in Documents folder:

@Dashrender said in Remove-Item cannot remove crap in Documents folder:

@Obsolesce said in Remove-Item cannot remove crap in Documents folder:

@JaredBusch
I had a little bit of fun... whether useful to you or not.

You can run this script as a regular user that has permissions to create and run scheduled tasks and create a file in specified directory.

This will create a powershell script, and a scheduled tasks to run the script as the SYSTEM account. Then it will delete the script and the scheduled task.

I could test most of it, but not some of it for obvious reasons.

<#---- CHANGE THESE VARS: ----#>

# Users to exclude from profile manipulation script, separated by pipe:
$excludedKnownUsers = "Administrator|SpecialUser1"

# New Script:
$newLocalScriptPath = "$ENV:SystemDrive\scripts"
$newLocalScriptFile = "testScript.ps1"

# SID ending: (likely 21 if domain users)
$sidEnd = 21

# Scheduled Task Name:
$TaskName = "_Test Task 1"

# Scheduled Task Description:
$Description = "This is a test scheduled task that runs as the SYSTEM account and will be ran and then deleted at the end of this script."

<#-------- END CHANGE --------#>

# New Script:
$newLocalScript = "$newLocalScriptPath\$newLocalScriptFile"

# Gethers list of user profile paths:
$userPaths = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*" -ErrorAction SilentlyContinue | Where-Object {($_.PSChildName -split '-')[3] -eq $sidEnd -and ($_.ProfileImagePath -split "\\")[2] -notmatch $excludedKnownUsers}

# Creates a 'script in memory':
$testScript = $null
foreach ($userPath in $userPaths.ProfileImagePath) {
    $testScript += "Remove-Item -Path "$userPath\Documents" -Force -Recurse`n"
    $testScript += "New-Item -ItemType Junction -Path $userPath -Name 'Documents' -Target '$userPath\Nextcloud\Documents' -Force`n"
}

# Create a PowerShell script and save it as specified in vars:
if (-not(Test-Path $newLocalScript)) {New-Item -Force $newLocalScript}
$testScript | Out-File $newLocalScript -NoNewline -Force

# Task Action:
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy Bypass -File $newLocalScript"

# Task Trigger: (task will be manually run immediately and then deleted, so keep 1 year out)
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddYears(1)

# Task Compatibility: 
$Compatibility = "Win8" # 'Win8' is 'Windows 10' in the GUI

# Task Settings:
$Settings = New-ScheduledTaskSettingsSet -Compatibility $Compatibility -StartWhenAvailable -AllowStartIfOnBatteries

# Run task as local SYSTEM account with highest privileges:
$Principal = New-ScheduledTaskPrincipal -UserId 'S-1-5-18' -RunLevel Highest

# Create the scheduled task:
Register-ScheduledTask -TaskName $TaskName -Description $Description -Action $Action -Trigger $Trigger -Settings $Settings -Principal $Principal -Force

<#--------------------------#>

# Run the scheduled task:
Get-ScheduledTask -TaskName $TaskName | Start-ScheduledTask

# Remove the created script:
Remove-Item $newLocalScript -Force

# Delete the scheduled task:
Get-ScheduledTask -TaskName $TaskName | Unregister-ScheduledTask -Confirm:$false

This seems like a HUGE security problem - normal users can schedule a task to run as SYSTEM? Then any virus could do the same thing. So what am I missing?

I assume regular user would need elevated privileges at least... But I didn't test as a non-local admin, which is different than elevated privileges. But either way, that script can be automated and run as a user in the local admin group too with successful results.

I think your script affects every user on the machine - assuming that's Ok for the envivronment - yep, have the local admin run it - and done.

[Obsolesce]

@Dashrender said in Remove-Item cannot remove crap in Documents folder:

@Obsolesce said in Remove-Item cannot remove crap in Documents folder:

@Dashrender said in Remove-Item cannot remove crap in Documents folder:

@Obsolesce said in Remove-Item cannot remove crap in Documents folder:

@JaredBusch
I had a little bit of fun... whether useful to you or not.

You can run this script as a regular user that has permissions to create and run scheduled tasks and create a file in specified directory.

This will create a powershell script, and a scheduled tasks to run the script as the SYSTEM account. Then it will delete the script and the scheduled task.

I could test most of it, but not some of it for obvious reasons.

<#---- CHANGE THESE VARS: ----#>

# Users to exclude from profile manipulation script, separated by pipe:
$excludedKnownUsers = "Administrator|SpecialUser1"

# New Script:
$newLocalScriptPath = "$ENV:SystemDrive\scripts"
$newLocalScriptFile = "testScript.ps1"

# SID ending: (likely 21 if domain users)
$sidEnd = 21

# Scheduled Task Name:
$TaskName = "_Test Task 1"

# Scheduled Task Description:
$Description = "This is a test scheduled task that runs as the SYSTEM account and will be ran and then deleted at the end of this script."

<#-------- END CHANGE --------#>

# New Script:
$newLocalScript = "$newLocalScriptPath\$newLocalScriptFile"

# Gethers list of user profile paths:
$userPaths = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*" -ErrorAction SilentlyContinue | Where-Object {($_.PSChildName -split '-')[3] -eq $sidEnd -and ($_.ProfileImagePath -split "\\")[2] -notmatch $excludedKnownUsers}

# Creates a 'script in memory':
$testScript = $null
foreach ($userPath in $userPaths.ProfileImagePath) {
    $testScript += "Remove-Item -Path "$userPath\Documents" -Force -Recurse`n"
    $testScript += "New-Item -ItemType Junction -Path $userPath -Name 'Documents' -Target '$userPath\Nextcloud\Documents' -Force`n"
}

# Create a PowerShell script and save it as specified in vars:
if (-not(Test-Path $newLocalScript)) {New-Item -Force $newLocalScript}
$testScript | Out-File $newLocalScript -NoNewline -Force

# Task Action:
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy Bypass -File $newLocalScript"

# Task Trigger: (task will be manually run immediately and then deleted, so keep 1 year out)
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddYears(1)

# Task Compatibility: 
$Compatibility = "Win8" # 'Win8' is 'Windows 10' in the GUI

# Task Settings:
$Settings = New-ScheduledTaskSettingsSet -Compatibility $Compatibility -StartWhenAvailable -AllowStartIfOnBatteries

# Run task as local SYSTEM account with highest privileges:
$Principal = New-ScheduledTaskPrincipal -UserId 'S-1-5-18' -RunLevel Highest

# Create the scheduled task:
Register-ScheduledTask -TaskName $TaskName -Description $Description -Action $Action -Trigger $Trigger -Settings $Settings -Principal $Principal -Force

<#--------------------------#>

# Run the scheduled task:
Get-ScheduledTask -TaskName $TaskName | Start-ScheduledTask

# Remove the created script:
Remove-Item $newLocalScript -Force

# Delete the scheduled task:
Get-ScheduledTask -TaskName $TaskName | Unregister-ScheduledTask -Confirm:$false

This seems like a HUGE security problem - normal users can schedule a task to run as SYSTEM? Then any virus could do the same thing. So what am I missing?

I assume regular user would need elevated privileges at least... But I didn't test as a non-local admin, which is different than elevated privileges. But either way, that script can be automated and run as a user in the local admin group too with successful results.

I think your script affects every user on the machine - assuming that's Ok for the envivronment - yep, have the local admin run it - and done.

Yeah I designed it like that on purpose, because if users are using the device, whether it's one or 10 (unlikely), IMO they should all be redirected. But that can be changed no problem. But at least if it's one main person using it, it'll hit that one. If others do, they can be excluded. But you can always get the current signed on user and use that as in JB's original script, or in an automated way using other means I could add in if needed.