Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Saturday, August 28, 2010 9:14 PM
I am writing a small powershell script... I do not want to hard-code a letter and a root path for new-psdrive cmdlet...
This works...
New-PSDrive -name "S" -psprovider filesystem -root "D:\Domain Data\Projects\Powershell"
This does NOT WORK:
$letter = "S"
$path = "D:\Domain Data\Projects\Powershell"
New-PSDrive -name $letter -psprovider filesystem -root $path
It seems that when the cmdlet hits the space in "Domain Data" it no longer recognizes this as an appropriate path and it throws an error. "The folder does not exist..." However if I simply set $path = "D:\ it works.
Solutions?
Stew.
ME
All replies (7)
Sunday, August 29, 2010 6:52 PM ✅Answered
Thanks for everyones help... Although all the posters were accurate, none of them got the answer correct... but I believe that my have been my fault. Since I asked a rudimentary question I got a rudimentary answer... Perhaps I should have been more explicit, or more importantly I should have looked at my issue closer before posting a question. At any rate, the problem has been solved.
I would suggest that anyone trying to resolve scope issues, or PSSession Issues read all about scopes first. It is really quite boring reading, however it did answer my question very explicitly... Creating a PSSession object within powershell is out side of SCOPE, scope. In other words, the scope of your variable has nothing to do with one session to another and MS defines interleaved sessions very specifically... Thus, a script that runs in a powershell session, creates variable, functions, etc..., and then creates a PSSession object and enters that session will not have access to variables outside that session, and vis-versa... So in my script I was creating a PSSession and expecting my variables to set a parameter inside the session where I had not rightful access to that variable.
Here is the solution to my problem:
#First I create the PSSession Object
$Session = New-PSSession -ComputerName adc01
# Then I Invoke the active directory module into that session... I will need this later
Invoke-command { import-module activedirectory } -session $Session
# I then create enter the actual session
Enter-PSSession $Session
# AND THIS IS WHAT SOLVED MY PROBLEM
Invoke-command -ScriptBlock { New-PSDrive -Name 'V' -PSProvider FileSystem -Root 'D:\Domain Data\Projects\Windows Scripting\Powershell'; Set-Location "V:" } -session $Session
I suppose I could have solved this problem by configuring a default Powershell Profile on the server side, but I really didn't want to do that... it doesn't go along with the big picture element of what I was trying to accomplish...
Thanks for everyones help.
ME
Saturday, August 28, 2010 10:17 PM
I didn't have any issues with spaces when I tried this:
PS C:\Users\Administrator> $letter = "S"
PS C:\Users\Administrator> $path = "C:\Program Files\Windows NT"
PS C:\Users\Administrator> New-PSDrive -Name $letter -PSProvider filesystem -Root $path
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
S 29.32 FileSystem C:\Program Files\Windows NT
PS C:\Users\Administrator> S:
PS S:\> dir
Directory: C:\Program Files\Windows NT
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 7/14/2009 1:41 AM Accessories
d---- 7/14/2009 1:41 AM TableTextService
PS S:\>
Saturday, August 28, 2010 11:12 PM
If you use the name directly as in
New-PSDrive-Name$letter -PSProvider filesystem-Root C:\dir with space
Shouldn't the path be quoted as in
New-PSDrive-Name$letter -PSProvider filesystem-Root "C:\dir with space"
On 8/28/2010 6:17 PM, JHofferle wrote:
> I didn't have any issues with spaces when I tried this:
>
> PS C:\Users\Administrator> $letter = "S"
> PS C:\Users\Administrator> $path = "C:\Program Files\Windows NT"
> PS C:\Users\Administrator> New-PSDrive-Name$letter -PSProvider filesystem-Root$path
>
> Name Used (GB) Free (GB) Provider Root CurrentLocation
>
> S 29.32 FileSystem C:\Program Files\Windows NT
>
>
> PS C:\Users\Administrator> S:
> PS S:\ dir
>
>
> Directory: C:\Program Files\Windows NT
>
>
> Mode LastWriteTime Length Name
>
> d 7/14/2009 1:41 AM Accessories
> d 7/14/2009 1:41 AM TableTextService
>
>
> PS S:\
>
xxxx
Sunday, August 29, 2010 2:59 AM
Use single quotes on the outside and double inside. this way when the sting contains a quoted string.
$letter = "S"
$path = '"D:\Domain Data\Projects\Powershell"'
New-PSDrive -name $letter -psprovider filesystem -root $path
Sunday, August 29, 2010 3:34 AM
Perhaps I wasn't clear... My apologies...
I have a server that hosts several scripts I want to execute from workstations in an automated way... I want to execute a simple script in this fashion...
$map = "S"
$path = "D:\Domain Data\Projects\Powershell"
$Session = New-PSSession -ComputerName adc-01
Enter-PSSession $Session
New-PSDrive -Name $map -PSProvider FileSystem -Root $path -Scope 0
Set-Location "$Map:"
.{go_do_some_junk.ps1}
What happens is everthing works right up until the New-PSDrive. This throws an error telling me that the drive does not exist... however I am dropped at the [ADC-01] PS>> Prompt. and I can navigate to the D: partition and If I type the command into the shell manually, after the script has crashed, it will execute... In the initial script however it simply will not execute... either with variables or hard-coded... This is seriously frusterating...
Thanks for everyone help so far.
ME
Friday, September 3, 2010 9:37 AM
Thank you for sharing the solution and analyze, it’s helpful. If you have more questions in the future, you’re welcomed to this forum.
Regards
This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Monday, September 6, 2010 12:25 PM
The other thing with configuring a profile on the remote server side is that it doesn�??t work.. I used a method much like yours to create a remote profile.
http://jrich523.wordpress.com/2010/07/21/update-creating-a-profile-for-a-remote-session/
It�??s a neat little way around the problem :)
Justin