Windows 10 empty downloads folder on log off

[HanwellFields]

Good afternoon

 

I am trying to empty our staff network user download area on log off however i just cant get the script to run

 

I have a created a .bat file which i have setup in the group policy under logoff however it runs but doesn't clear , if i run the .bat file on my desktop it works have tries powershell also

 

"%HOMEDRIVE%%HOMEPATH%\downloads\*..."pushd "%HOMEDRIVE%%HOMEPATH%\downloads"for /d %%a in (*) do rd /s /q "%%a"del /s /q "*.*"popd

 

Regards

 

Peter

[ShellfishClive]

[color=#2A2A2A][font=&amp]Remove-Item -Path $env:UserProfile\Downloads -Recurse -Force [/font][/color]

 

Try this Ppwershell script, should do what you need it too.

[HanwellFields]

I tried that one and it ended up deleting the whole folder itself ,My downloads folder is located on the network drives in user profiles

[ThomL]

Tested ShellfishClive's script and I agree it deletes the whole folder - but this isn't a bad thing, it's simple and does what's needed, KISS. At the next user login the folder should be recreated automatically, all fresh clean and ready to go.

 

I'd consider not redirecting this folder to a file server/network drive and bit instead keeping it local - especially if your going to delete it like this at logoff. Redirecting to a file server with the data cleared at the end of a session is just placing more IOPS on that fileserver and wasting resources to write the data then followed by removing all the data a short time later. I'd keep it local to the machine they're using so it impacts on the device not the server if possible.

Edited November 1, 2018 by ThomL

[HanwellFields]

I will give this a go on my test machine and keep you updated

[HanwellFields]

Hi Thanks for the reply

 

I have tried this script and it doesn't run with GPO ,if i run manually i have to click yes in powershell to delete folder , can i add this to the script to run this automatically ?

[ThomL]

Have you made a PS1 file and then added it to the GPO within the Powershell area?

[ShellfishClive]

Sorry I thought you wanted to folder deleted, I misread.

 

[color=#2A2A2A]Remove-Item -Path $env:UserProfile\Downloads\*.* -Recurse -Force [/color]

 

That should delete all the contents but keep the folder.

[HanwellFields]

That works to clear the user data from the c:/ Downloads however i wish to clear from the H:/ network drive as this where our data is kept for our network profiles

 

Thanks

[ShellfishClive]

That works to clear the user data from the c:/ Downloads however i wish to clear from the H:/ network drive as this where our data is kept for our network profiles

 

Thanks

 

 

You should be able to point to the share that is their drive then. Replace the path with \\shared-drive\$env:username\downloads not sure how you have it setup though so tweak it to your actual path.

[ThomL]

I forgot the variable used changed from OP to $env:UserProfile, you could still use the original environment variables like $env:HOMEDRIVE $env:HOMEPATH just a case of checking your pathing is correct - its tweaking to match your setup as ShellfishClive said.

 

Looking at the updated cmdlet:

Remove-Item -Path $env:UserProfile\Downloads\*.* -Recurse -Force

This is just going to delete files from the root folder - if a user downloads a zip file and extracts to the folder, or any subfolders are created they will not be deleted. This isn't an issue if subfolders are unlikely I guess.

Is there a better way to get a true recursive deletion of all sub files/folders than this?:

Get-ChildItem -Path "$env:UserProfile\Downloads" -Recurse | foreach {Remove-Item $_.FullName -Recurse -Force}

 

Did some cmdlet execution timing while digging into this (very small dataset 3.5MB-32 Files); in my testing deleting the whole folder is the quickest option (8.9641 ms), deleting just the files in the root folder is 52% slower (13.7042 ms) with the slowest being the true recursive delete above - this is 127% slower (20.4096 ms)

 

****Edit****

 

This comes in much quicker for a true reclusive delete 10.5144 ms but still 17% slower than deleting the root folder :

Get-ChildItem -Path "$env:UserProfile\Downloads" -Recurse | foreach {$_.Delete()}

[HanwellFields]

Many thanks for both of you helping with this ,really appreciate it ,i will give this a go and let you know the outcome

[Arthur]

This comes in much quicker for a true reclusive delete 10.5144 ms but still 17% slower than deleting the root folder:

 

Get-ChildItem -Path "$env:UserProfile\Downloads" -Recurse | foreach {$_.Delete()}

If you want something significantly quicker try this...

 

Get-ChildItem -Path "$env:UserProfile\Downloads\" -Recurse | Remove-Item -Recurse -Force

 

I managed to delete 8,644 files and 1,235 folders totalling 17.6GB in under a second!

[ThomL]

If you want something significantly quicker try this...

 

Get-ChildItem -Path "$env:UserProfile\Downloads\" -Recurse | Remove-Item -Recurse -Force

 

I managed to delete 8,644 files and 1,235 folders totalling 17.6GB in under a second!

 

This is still slower with the same dataset that I've been using: 19.9831ms. Not to say this is slow, its 100% not slow! I'm being very pedantically measuring the differences in the ms range on these cmdlets. From my testing I think this would've been fastest deleting your 17.6GB:

[color=#333333]Get-ChildItem -Path "$env:UserProfile\Downloads" -Recurse | foreach {$_.Delete()}[/color]

 

I still think there might be a faster option i just haven't found it yet... The nerd inside of me has enjoyed timing and tweaking these cmdlets too much

[T_Lister]

[color=#2A2A2A][font=&amp]Remove-Item -Path $env:UserProfile\Downloads -Recurse -Force [/font][/color]

 

Try this Ppwershell script, should do what you need it too.

 

Can this script be used with an entry that only deletes say, over 30 days old? Also, can it be used to purge the recycle bin in the same manner?

[thimon]

Alternative thought, could you have it as a one minute delayed logon script, via task scheduler? This would work if users frequently log into the same computers. Wouldn’t affect log on or off speeds.