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.
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.