Showing user profile sizes without taking ownership

[Pyroman]

Heya,

Is there a way of being able to see the user profiles folders sizes and contained files without taking ownership of the files and affecting users rights to their profile folders?

I can do it on an individual basis by taking ownership but this is long winded, basically our profiles are adding up to 50Gb on the server but i can't see who's the biggest user without taking ownership individually then i'm just guessing who's going to be the biggest.

Hope this makes sense!

Any thoughts?

[elsiegee40]

try this: TreeSize Free - Quickly Scan Directory Sizes and Find Space Hogs

[Pyroman]

try this: TreeSize Free - Quickly Scan Directory Sizes and Find Space Hogs

Thanks but get the same as i do with windirstat - access denied because i don't have permissions without taking ownership

[badders]

Don't think there's any way to access the current profiles and keep the permissions, but there is a group policy setting for newly created profiles located at Computer Configuration\Administrative Templates\System\User Profiles "Add the Administrators security group to the roaming user profile share".

[jinnantonnixx]

Heya,

Is there a way of being able to see the user profiles folders sizes and contained files without taking ownership of the files and affecting users rights to their profile folders?

I can do it on an individual basis by taking ownership but this is long winded, basically our profiles are adding up to 50Gb on the server but i can't see who's the biggest user without taking ownership individually then i'm just guessing who's going to be the biggest.

Hope this makes sense!

Any thoughts?

I know what you mean.

The default security is:
System: Full Control
Username: Full Control

Maybe you could write a routine to run a file utility (may like the one elsiegee40 suggested) as the SYSTEM account? This should be straightforward if you stick it in the scheduler and run the job as SYSTEM.

[Jamo]

You should have the administrators as a delegated permission on all user areas anyway, it is good practice for administration, then the users can be owners of their own files but you still have access to them regardless.

[Pyroman]

You should have the administrators as a delegated permission on all user areas anyway, it is good practice for administration, then the users can be owners of their own files but you still have access to them regardless.

How do i go about adding permissions to the profiles folder? according to the properties of the profiles folder under security administrators group has full control, however when you go on the properties of a folder within the profiles folder there's nothing atall in the groups and user names

[jinnantonnixx]

I haven't tried it, but maybe a script that runs cacls to add administrators group to the profile folders?
Again, run as a task in scheduler under SYSTEM account.

If it works, it would neatly sidestep the disruption of taking ownership.

Worth a go, won't take long to see if it works.


CACLS <profile path> /E /T /C /G "Group to add (e.g Domain Admins)":F

[Jamo]

Yes I think retrospectively it would have to be done by script as the permission inheritence would have been broken by default when the profiles are created. I would start by adding the GPO setting suggested by Badders and then try running the script on a subset of folders so you know it is working before trying it on the live system . Dont want users not being able to access there own files!!

[Pyroman]

I haven't tried it, but maybe a script that runs cacls to add administrators group to the profile folders?
Again, run as a task in scheduler under SYSTEM account.

If it works, it would neatly sidestep the disruption of taking ownership.

Worth a go, won't take long to see if it works.


CACLS <profile path> /E /T /C /G "Group to add (e.g Domain Admins)":F

Is the :F at the end supposed to be a /F ?

Sorry, just looked at a cheat sheet for cacls i understand now it's :F

I'll try this out :-) Cheers

[Pyroman]

I've managed to run

CACLS <profile path> /E /T /C /G "Group to add (e.g Domain Admins)":F

on a test staff account and it's seemed to let me in but i didn't have to run it as SYSTEM i just put it in a batch file and ran it, should i be worried that i didn't have to run as SYSTEM?

[jinnantonnixx]

Let us know if it works. If it does, it'll be a good trick.

[Jamo]

I've managed to run

CACLS <profile path> /E /T /C /G "Group to add (e.g Domain Admins)":F

on a test staff account and it's seemed to let me in but i didn't have to run it as SYSTEM i just put it in a batch file and ran it, should i be worried that i didn't have to run as SYSTEM?

As an administrator you will have permission to alter the security permissions on the folder. Running as a system account was meant as a workaround to the treesize program rather than for actually changing the permissions on the folders themselves.

[Pyroman]

As an administrator you will have permission to alter the security permissions on the folder. Running as a system account was meant as a workaround to the treesize program rather than for actually changing the permissions on the folders themselves.

Ah okay kewl, in which case it works!

Just ran it in a batch file as i've said in my above post and it's worked fine, logged on the account i tested it on on one machine, created a folder on the desktop, logged off and logged on on another machine and the folder appears, no warnings about not finding profiles or anything like that so it would appear it's worked fine, i just get a little nervous when things work this easily! Wondering what it's going to break when i apply it to the whole profile folder (sods law)!! Might try it with a few select kids/teachers accounts i know get a lot of hammer and see if anyone complains!

[elsiegee40]

Treesizefree is great for sorting out the profile size problems... once you get the permissions sorted, you'll wonder why you didn't have it years ago!