PowerShell Problem Solver: Copy Files with Credentials Revisited

Posted on October 22, 2014 by Jeff Hicks in PowerShell with 0 Comments

In the last PowerShell Problem Solver, I shared a proxy function to copy files to a network share using alternate credentials. You might want to take a moment to look at that article before continuing. As I stated at the end of the article, most of the time using the temporary PSDrive works just fine.

Troubleshooting the use of PSDrive to copy files

In my testing, I eventually ran into an error “Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.” What makes this difficult to troubleshoot is that it isn’t always apparent where this connection is defined. I used WMI to query for network connections.

I even checked using the legacy NET USE command to see if there were any lingering connections. Sometimes you can be left with a mapped connection to the IPC$ share. If that happens, then you can easily delete it.

Rebooting didn’t always resolve this issue. So I decided to take a different approach in my Copy-Item proxy function. Sometimes the old school ways are the best ways. I still wanted a mapped drive using alternate credentials so why not use NET USE? The syntax for mapping a drive with credentials is:

To use this in PowerShell requires a little work. First, the NET USE command can only use a single letter for the drive mapping. Since I have no way of knowing what drive letters are in use, I’ll use PowerShell to programmatically figure it out.

When you start PowerShell, it automatically creates a function for every drive letter. That’s why when you type D: at a PowerShell prompt, you change location to the D: drive. In the one-liner above, I’m getting a directory listing of functions E: through Z:. The [e-z] is a regular expression pattern. The –Name parameter means the first part of the expression will only write something like D: to the pipeline, in other words a filesystem location. These locations are piped to Where-Object which tests if the drive exists or not. If it doesn’t exist, PowerShell writes the object to Select-Object where I am selecting only the first drive letter not in use.

Credentials, NET USE, and PSCredential

The credential part is a little trickier because the NET USE command has no concept of a PSCredential and I don’t want to have to include a Password parameter. So here’s how you can break apart a PSCredential object. The name part is stored in the Username parameter. However, the password is stored as a secure string, meaning it is encrypted in memory on your computer. The NET USE command is expecting plain text. The trick is to invoke the Get-NetworkCredential() method on the PSCredential object. This will break the PSCredential down, including a Password property with a clear next value! This is why it is important that you lock your desktop when stepping away if using PSCredentials in your PowerShell session. While the credential goes away when PowerShell ends, anyone with access to your computer and some PowerShell knowledge could quickly find and decipher credential password. The end result is that I can use the NET USE command to map a temporary drive using credentials, delivered from PowerShell.

As with the previous version of my script, I can change the destination parameter.

The wrapped Copy-Item cmdlet will use this destination. At the end, I’ll remove the NET USE mapping.

Sponsored

Here is another version of my Copy-Item2 function that uses the NET USE command.

Sponsored

This command is essentially the same as the previous version. The only thing that differs is how the temporary drive is created. In my testing, the NET USE approach was much more resilient. Although if you have an existing drive mapping to the server you will still get the multiple connections not allowed error. But at least in my experience this has been easier to troubleshoot and resolve.

Proxy functions can be great problem solvers because you can take advantage of all the cmdlet’s features with the benefit of adding your own customizations. I expect will see proxy functions solving future PowerShell problems.

Sponsored

Tagged with , ,