by Nobody at 2013-04-09 14:41:06
Ok, the short story is my environment is Powershell v2 without remoting. I’m having a problem deleting copies of profiles using WMI on remote Windows XP machines. Oddly, it occassionally works… This seems to work reliably on "test" folders that I create. Any idea on why this might be failing, or is there some other WMI class or technique that I can use to occomplish this?by mjolinor at 2013-04-09 16:20:47
$a = get-wmiobject -computername $computer -query "SELECT * FROM win32_directory WHERE name =‘c:\documents and settings\userprofile.old’" -ea stop
$a|remove-wmiobject
When that doesn’t work, I get this error.
Remove-WmiObject :
At line:6 char:20
+ $d|remove-wmiobject <<<<
+ CategoryInfo : InvalidOperation: ([Remove-WmiObject], COMException
+ FullyQualifiedErrorId : RemoveWMICOMException,Microsoft.PowerShell.Commands.RemoveWmiObject
Perhaps it works reliable on the test folders because you created them (and are therefore the owner).by Nobody at 2013-04-16 14:09:06
I note that the WMI class Win32_UserProfile class has a ChangeOwner method. If you use that to take ownership, can you delete it then?
Finally got a chance to get back to this. To quickly solve my original issue on a bazillion computers, I renamed profile folders and rebooted the computers (xp) so a new profile folder would be created. Now I just want to cleanup the "user.old" folders. So unfortunately the win32_UserProfile class won’t apply. The root profile folder owner appears to be local administrators, but subfolders/files owner is generally the actual user.by Nobody at 2013-04-16 14:44:05
As I mentioned before this does work, even after rerunning on a pc where where it previously failed, it’s just incredibly unreliable. Fortunately, this isn’t a big deal as I can use other tools, I was just trying use this for a learning experience. I was hoping I was overlooking something. I do have another script to delete user profiles the proper way using the win32_userprofile class, and it seems to zap the profile folders quite reliably.
I did some additional testing, and it appears this only trips up on folders that I renamed using rename-item with a UNC path. Any idea what rename-item changed, other than the name?
rename-item -path "\computer\c$\documents and settings\username" -newname "username.old"