-2

In my powershell script i am using New-PSDrive function to map remote server file path into my local computer as windows deployment operation proccess.

I plan to reuse this Powershell script in the future, so i dont want any conflict between drives because of naming. For example, if two deployment operations need to reach the script at the same time, then one of two will be deployed uncorrectly.

That's the question: Can i use timestamp or any other unique information as a drive mapping name? That way, i can be sure of avoiding name conflict.

Edit:

I have tried to create custom named new-psdrive mapping without persist parameter, but that way, powershell tries to reach the folder with relative path (under the current working directory)

Here is the code where i try to copy some files (backup):

$day = Get-Date -Format "yyyyMMdd"
$appsource = "\\$computername\D$\Applications"

New-PSDrive -Name J -PSProvider FileSystem -Root $appsource-Credential $cred -persist

Write-Host "Backup işlemi başladı." 
robocopy "J:\App" "J:\backup\$day"

Edit 2:

You can not use a dynamic name as a persisted drive mapping name. If you are to reach cross domain computer, the best way is (but cost-effective way) to use Invoke-Command for running script on remote computer. 2 way (remote-local, local-remote) file-sharing permissions are need to be allowed. If you use Invoke-Command, you are conflict-free. Because the command uses dynamic session on the remote computer.

metzelder
  • 655
  • 2
  • 15
  • 35
  • wondering, why do you need to map drive, rather than just copying stuff to the shared folder? like robocopy \\server\share1 \\server\share2 – Mike Twc Dec 28 '18 at 21:36
  • I cant use shared folders because of organization security policies. – metzelder Jan 02 '19 at 06:07

2 Answers2

1

Per the documentation from Get-Help New-PSDrive -full, the name of the new drive is supplied as a string, so if you can build up the string from your preferred information (timestamp, etc.) before passing it to New-PSDrive, you can use it as a drive name. Note that you should avoid characters that will be problematical in pathnames, such as spaces and the reserved characters (e.g., \, :,/, the wildcard characters, etc.).

Since your edit shows that you're using ROBOCOPY, which runs "outside" PowerShell's code/memory space, you may not be able to use New-PSDrive to establish the mapping - I've had inconsistent results with this. Much more reliable is to establish the mapping with NET USE - in your case, NET USE J: $appsource will likely do the trick.

Jeff Zeitlin
  • 9,773
  • 2
  • 21
  • 33
  • I have used it but it tries to reach the source and destination files under the current working directory. So it throws folder not found. – metzelder Dec 24 '18 at 08:33
  • What, specifically, is the command you are using, and the string that you are building to map to? Please edit your question to include this information. – Jeff Zeitlin Dec 24 '18 at 12:57
  • See the edit to the answer - you may need `NET USE` instead of `New-PSDrive`. – Jeff Zeitlin Dec 25 '18 at 12:13
  • No luck. It tries to find the files under current working directory. string(67) " Source : D:\var\build-dir\58097665 58163202\57480000-vpos:\VPOS\" [10]=> string(83) " Dest : D:\var\build-dir\58097665-58163202\57480000-vpos:\Vpos-backup\20181225\" – metzelder Dec 25 '18 at 13:00
  • There is obviously something else going on here that you haven't provided sufficient information to troubleshoot. I used the code you provided on my own system, after creating the appropriate shares, and had no problem. – Jeff Zeitlin Dec 25 '18 at 13:04
  • The remote computer i am trying to reach is in another domain. Maybe this is the difference? In addition, the drive name i create is something like name-milliseconds. You tried with custom name? – metzelder Dec 25 '18 at 13:08
  • The cross-domain connection _may_ be an issue; I'm not sure how you would provide credentials to `NET USE` in that case (we don't do cross-domain stuff, likely because of the difficulties involved in cross-domain credentialling). Also, distinguish between the drive _name_, which would be "J" in your example above, and the drive _root_, which is the value you stored in `$appsource` in your example above. – Jeff Zeitlin Dec 25 '18 at 13:36
  • It is entirely possible that where you don't have a drive name that `cmd.exe` would find valid, it tries to expand the root; this was part of the problems that we had with using `New-PSDrive`, and was a major reason we went to using `NET USE` instead. – Jeff Zeitlin Dec 25 '18 at 13:40
  • NET use is suitable when you have some shared directories among computers. But in this example, i try to reach directly hard-drive of the remote server machine (in another domain). There are some restricts with net-use usage (i have tried before) in my case. – metzelder Dec 25 '18 at 14:09
  • Then you may have to find a different way of handling the actual copy; Robocopy may not be able to access the PSDrive. Nevertheless, NET USE should work just fine if you can access the drive/directory with a UNC pathname. – Jeff Zeitlin Dec 25 '18 at 14:20
  • Regardless of the way that i try to reach remote computer, as you said before, new-psdrive is inconsistent. So i switch to net use. Thank you for your help. – metzelder Jan 09 '19 at 07:25
0

Since Windows-mapped drives have hard requirements on names (which is what is created when using the persist parameter) it may be better to use invoke-command and pass in a script block than mapping the drive at all.

$SB = {
$day = Get-Date -Format "yyyyMMdd"
Robocopy "D:\Test\App" "D:\Test\backup\$day"
}
Invoke-Command -ComputerName $CompName -Credential $cred -ScriptBlock $SB

This way it removes the need to worry about mapped drive collision

Jansen McEntee
  • 451
  • 5
  • 9
  • This would be the once and for all solution if i want to copy remote path to remote path. But i have to reach the source computer back again for some files to be deployed in remote. That makes things even more complicated then this one. – metzelder Dec 28 '18 at 11:37
  • Understood. I did test the code you posted cross domain and was successful. I tried replicating the exact error scenario you are seeing where the robocopy is evaluating the path at the current working directory. When I failed to authenticate I got a similar looking result. Is it possible you did not user the domain\username in your credential? Also does the drive need to persist past the script execution? If not that allows MUCH more flexibility in the names you may label it as. – Jansen McEntee Dec 28 '18 at 16:39
  • It is not authentication-based error. I use exact same credential username and password. Persist parameter is required when you have to create permanent physical drive. And that way, you can not use generic names. – metzelder Jan 02 '19 at 06:33