SQL Server 2012 Import-Module 'sqlps' breaks the "Test-Path" PowerShell cmdlet
-
Wednesday, October 24, 2012 12:44 AM
I've run into something that is "very" frustrating with the new SQL Server 2012 PowerShell module. When I Import the module, it breaks the "Test-Path" cmdlet when trying to test a UNC path to a directory.
For example:
"Test-Path -path \\server\dirname" returns true as expected before the sqlps module is imported. But after you import the SQL Server module "Import-Module 'sqlps' –DisableNameChecking" the same Test-Path now returns false.
If I run the following in Windows PowerShell ISE I see the following results:
Test-Path -path "\\server\directoryname"
Import-Module 'sqlps' –DisableNameChecking
Test-Path -path "\\server\directoryname"True
FalseAnyone have any idea what's going on?
UPDATE: after more testing, it looks like the problem happens with any cmdlet that references a UNC. The New-Item has the same problem. Before importing 'sqlps', New-Item is able to create a directory at the UNC path specified, but ater importing 'sqlps', the New-Item fails.
Thanks!
- Edited by mikea730 Wednesday, October 24, 2012 12:58 AM
All Replies
-
Thursday, October 25, 2012 8:03 AMModerator
Hi Mikea730,
Sqlps.exe doesn't take advantage of a couple of these nice PowerShell V2 cmdlets without doing a bit of configuring in your environment.
Please refer to the following references to make some configuration in your server
http://www.maxtblog.com/2010/11/denali-get-your-sqlpsv2-module-set-to-go/
http://sev17.com/2010/07/making-a-sqlps-module/
Thanks,
If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.
Iric Wen
TechNet Community Support
-
Thursday, October 25, 2012 4:19 PM
Iric, Thanks for the reply, do appreciate it!
Unfortunately I don't have time to build a new sqlps module. Seems a bit ridiculous to me! There must be an easier solution than this???
Guess I'll just stick with the 2008 R2 SMO for now. Looks like sqlps is a big step backwards in that it it impact cmdlets that are not part of the module!
-
Thursday, October 25, 2012 5:53 PMModerator
Could you please report this issue to https://connect.microsoft.com/SQLServer/Feedback?
Thanks
Sethu Srinivasan [MSFT]
-
Thursday, October 25, 2012 7:25 PM
Thanks for the quick replies everyone. I submitted the following:
Is any one else able to reproduce this?
Test-Path -path "\\server\directoryname"
Import-Module 'sqlps' –DisableNameChecking
Test-Path -path "\\server\directoryname"True
FalseThanks!
-
Saturday, November 03, 2012 8:40 PM
After importing the 'sqlps' module, your location is changed to the SQLSERVER drive, as indicated by the powershell prompt:
PS SQLSERVER:\>
This drive is an instance of the SQLSERVER Powershell Provider.
The core powershell cmdlets (Clear-Item, Convert-Path, Copy-Item, Get-Item, Get-Location, Invoke-Item, Join-Path, Move-Item, New-Item, Pop-Location, Push-Location, Remove-Item, Rename-Item, Resolve-Path, Set-Item, Set-Location, Split-Path, Test-Path, ...) will assume the item, path or location you specify as an argument of your cmdlet is relative to the Powershell Provider you are currently using.
The UNC path is meaningful to the FileSystem Provider, but not to the SQLServer Provider (which you are currently using).
To resolve your issue, you could (1) explicitly specify the FileSystem provider in your path or (2) switch to a drive of providertype FileSystem before invoking the Test-Path cmdlet for the second time:
Solution 1:
Test-Path -path "\\server\directoryname"
Import-Module 'sqlps' –DisableNameChecking
test-path -path Microsoft.PowerShell.Core\FileSystem::\\server\directorynameSolution 2:
Test-Path -path "\\server\directoryname"
Import-Module 'sqlps' –DisableNameChecking
C:
Test-Path -path "\\server\directoryname"
-
Saturday, November 03, 2012 9:25 PMModerator
I see the same issue with other Powershell providers as well ( Example: Registry Provider ). This issue may not be SQL Powershell specific issue
I ran the following commands in Windows Powershell 2.0 and Windows powershell 3.0
PS C:\Users> New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR
set-location HKCR:
PS HKCR:\> test-path \\machine\share
False
PS HKCR:\> c:
PS C:\Users> test-path \\machine\share
True
PS C:\Users>Thanks
Sethu Srinivasan [MSFT]
SQL Server
-
Saturday, November 03, 2012 9:36 PMModerator
Workaround:
test-path -literalpath "FileSystem::\\machine\uncpath"
Reference:
http://mcpmag.com/articles/2011/05/16/handling-errors-scripts-test-path.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ee126188(v=vs.85).aspxThanks
Sethu Srinivasan [MSFT]
SQL Server
- Proposed As Answer by Sethu SrinivasanMicrosoft Employee, Moderator Saturday, November 03, 2012 9:36 PM
-
Monday, November 05, 2012 3:59 PM
Thanks everyone. The following variations work.
Test-Path -path "Microsoft.PowerShell.Core\FileSystem::\\machine\uncpath"
Test-Path -literalpath "FileSystem::\\machine\uncpath"
Test-Path -path "FileSystem::\\machine\uncpath"

