Hello everyone,

I am writing a code that searches through our folders and finds home drives and profiles that do not have a corresponding AD object and delete them, i.e. for people that have left and their profile was never deleted. I am using the following script to run against one user and I keep getting the errors : Method Failed with error code 1337.

this is underlined in RED for the error: Set-acl -path "$Folderpath" -aclobject $currentACL

Error: the data area passed to the system is too small

this is underlined in RED for the error: Takeown.exe /f "$folderpath" /R /D Y /A

Function Get-ACLError($Folder){

$Error.clear()

$Errorarray = @()

get-childitem "$Folder" -Recurse -erroraction silentlycontinue | select Fullname

     IF($error){

      $errorarray = $error + $errorarray

       foreach($err in $errorarray){

        if($err.fullyqualifiedErrorID -eq "DirUnathorizedAccessError,Microsoft.Powershell.Command.Getchilditem"){

         Write-host "Unable to Access $Err.TargetObject" -foregroundcolor yellow

            Take-ownership($err.TargetObject)

            Get-ACLError($err.TargetObject)

          }

        }

      }

  }

Function Take-Ownership{

     param(

     [string]$folderpath

     )

     Takeown.exe /F "$folderpath" /R /D Y /A

     $currentACL + Get-ACL "$folderPath"

     Write-host "..Adding Admin to $Folderpath" -fourgroundcolor yellow

     $systemACLPermissions = "Administrator","Fullcontrol","containerinherit,objectinherit","none","allow"

     $systemaccessrule = new-object system.security.accesscontrol.filesystemaccessrule $systemACLPermission

     $currentACL.addaccessrule($systemaccessrule)

     write-host "..adding Infrastructure to "Folderpath" -fourgroundcolor yellow

     $adminACLPermission = "mydomain","fullcontrol",containerinherit,objectinherit","none","allow"

     $systemaccessrule = new-object system.security.accesscontrol.filesystemaccessrule $adminACLPermission

     $currentACL.addaccessrule($systemaccessrule)

     Set-ACL -path "$Folderpath" -Aclobject $currentACL

}

 Take-ownership "XXXX\home\(SID)" -recurse |get-aclerror; remove-item "XXXX\home\(SID)"

Any help would be appreciated.



• Edited by Richardlaw 14 hours 46 minutes ago

No idea what you are trying to do.  You need to post the complete error message and not just part of it.

You must pass a complete path  to the utility or it will error.

The function does NOT have a -recurse parameter. 

Perhaps you should ask the person who wrote this to fix it for you.

This line has to be done like this:

     Takeown.exe /F "`"$folderpath`"" /R /D Y /A

You cannot use quote without escaping them or they will be removed.

There are numerous syntax errors in the code which will make execution completely unreliable.

This would be best if you just explain what you are trying to do. As it is the code appears to be unnecessary.

This is a more reliable way to call an external program:

$arglist=@(
    ('/F "{0}"' -f $folderpath),
    '/R /D Y /A'
)
start-process 'takeown' -ArgumentList $arglist 

To correctly manage the error we would do this:

$arglist=@(
    ('/F "{0}"' -f $folderpath),
    '/R /D Y /A'
)
Try{
	start-process 'takeown' -ArgumentList $arglist -ErrorAction Stop
# other code ....
}
Catch{
   #re-throw error
  Throw $_
}
    

     Takeown.exe /F "`"$folderpath`"" /R /D Y /A

The extra quotes are unnecessary. You can use this:

     Takeown.exe /F "`"$folderpath`"" /R /D Y /A

The extra quotes are unnecessary. You can use this:

Here is a pure PowerShell way to do this:

http://gallery.technet.microsoft.com/scriptcenter/Set-Owner-ff4db177

http://learn-powershell.net/2014/06/24/changing-ownership-of-file-or-folder-using-powershell/

In this case probably but not if there are spaces in the path.

You can test yourself with ShowArgs.exe tool I published here:

Windows IT Pro: Running Executables in PowerShell

Simply prepend the takeown command line with ShowArgs.exe to see the command line that PowerShell actually constructs. You will find that it will automatically quote when needed. The article contains some of the other common pitfalls for constructing command lines for PowerShell to execute.

Yes.  I see. In this case it does but not when we don't have switches to note arguments. In that case the auto quoting mechanism  may fail. At least I have had it fail in some cases.

So I was asked to explain what I am trying to do. here it is.

We are looking for profiles and home directories that do not have a corresponding AD object or AD account. we are trying to take ownership of these profiles and home directories and then delete them. We have worked a bit on the script and are not longer receiving the 1337 error. That was due to a specific permissions issue we resolved.

We are receiving the following error: ( I would put in a screenshot but due to the network separation I work on I cant)

Error: the data area Passed to the system is too small

Takedown.exe /f $folderpath /R /D Y /A

 I wish I could give you screenshots but again I cant. Items are not getting deleted, I am at a loss for what to do next.

Thank you for all of your help.

Use delprof2.exe to delete old profiles.

There is no "takedown.exe" (maybe you mean "takeown.exe"?).

Don't grant users full control to directories where they can remove administrator permissions. Otherwise you will need to take ownership, change permissions, then delete (as you have seen).

As an aside, this is not a support forum for the command-line tool takeown.exe. That is a built-in Windows command, not a script.

I suggest posting the exact command you are running and the exact error messages to the server security forum instead:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserversecurity

This is all why managing profiles in Group Policy is so much easier and more reliable.

Takeown.exe /f $folderpath /R /D Y /A
Remove-Item $folderpath -recurse

If you play with ACLs you will likely damage the DACL and have to manually fix it.

Try this:

Invoke-Command -ComputerName . -ScriptBlock { Remove-Item c:\folder -Recurse }

Calling it through Invoke-Command is important. When you use Invoke-Command with a -ComputerName, the session that is created has all of your granted privileges enabled. When the SeRestorePrivilege is enabled, you sometimes get to completely ignore the DACL on the file/folder. It turns out that the underlying Win32 calls that are used when calling Remove-Item honor that privilege, so you get to remove stuff without having permission to view or delete it. Anytime I do something quick with PowerShell or .NET that requires privileges to be enabled, I just wrap the call in Invoke-Command instead of worrying with handling the privilege modification manually.

Of course, this won't work for you if PS Remoting isn't available...