Hi All,

I was hoping someone could help me out with a little problem I'm having.

I need to run the test-path cmdlet on a DFS Namespace UNC, but I also need to run it with alternate credentials.

Problem is, the test-path cmdlet doesn't support the -Credental parameter, so I'm trying to wrap it up in an Invoke-Command cmdlet.

For some reason, I keep getting an access denied error returned. I know for a FACT that the account I'm using for the alternate creds has permissions here because when I open a powershell prompt as that user, it works fine.

The invoke-command wrapper works too if I'm using a local path (C:\path\folder), but not with a DFS UNC.  Here's my code:

$targ = "filesystem::\\domain.com\FakePath\FakeFolder"
$username = "FakeUser"
$password = ConvertTo-SecureString "FakePassword" -AsPlainText -Force
$cred = new-object System.Management.Automation.PSCredential ($username, $password)
$tp = Invoke-Command -ComputerName "." -Credential $cred -ScriptBlock {test-path $args[0]} -ArgumentList $targ	
if ($tp -eq $false) {Write-host "Cannot find folder!"}
if ($tp -eq $true) {Write-host "Found folder!"}

Here's the error it's returning:

ERROR: Access is denied
ERROR:     + CategoryInfo          : PermissionDenied: (\\domain.com\fakepath\fakefolder:String) [Test-Path], UnauthorizedAccessException
ERROR:     + FullyQualifiedErrorId : ItemExistsUnauthorizedAccessError,Microsoft.PowerShell.Commands.TestPathCommand
ERROR:     + PSComputerName        : localhost

Any ideas?

Thanks,

Chris

• Edited by Topher2798 11 hours 35 minutes ago

You cannot elevate your self.

This is not legitimate: filesystem::\\domain.com\FakePath\FakeFolder"

Test-Path \\server\share\folder

or

Test c:\folder\folder\file.ext

Perhaps you would do better if you just stated what you were trying to do instead of trying to invent an impossible solution.

Obviously it is legitimate, because when I run the test-path to that DFS namepase UNC within a PowerShell console running as the elevated user, it returns true. It's not until I try to wrap it in the Invoke-Command that it fails.

And the filesystem:: prefix is to force the provider context. See here:

http://powershell.com/cs/blogs/tips/archive/2014/04/02/testing-unc-paths.aspx

I'd accept the idea that this cannot be done if it's wasn't working in a PowerShell prompt as the user I'm trying to run with alternate credentials. It DOES work with a DFS namespace UNC. It just refuses to work when I wrap it in the Invoke-Command cmdlet.

As for the UNC, since it's a DFS namespace the \\domain.com\ portion of it is going to resolve to the nearest domain controller. I'd prefer that over specifying the path with an actual domain controller name as \\servername\share\folder, either way, it resolves the same, but with the namespace UNC, I don't have to worry about the script breaking later on when the domain controller it's hard coded for is decommissioned.

And I'm not trying to elevate myself. I'm writing a script for our help desk to use for verifying folder paths. They don't have permissions to see the folders themselves. The script will contain credentials for an account that DOES so it will verify for them. Once completed, the script will be encoded and run from an RDS server as a remote app. The help desk personnel will not be able to see the username and password of the account it's running as.

Regardless, thanks for your reply.

YOu invoke command is going to the local machine which will not work.  It will only work if you target a remote machine.
-ComputerName" cannot be "." and cannot be the local computer name.