April 19, 2011 at 8:41 am
I tried to run powershell (changed only value for $destserver)
but getting
Get-Service : A parameter cannot be found that matches parameter name 'computername'.
At E:\AG\FoundSQLServers.ps1:22 char:43
+ $computers |? {(get-service -computername <<<< $_ |% {$_.name}) -match "sql"}
Get-Service : A parameter cannot be found that matches parameter name 'computername'.
At E:\AG\FoundSQLServers.ps1:22 char:43
April 19, 2011 at 9:39 am
I can't seem to duplicate the error your seeing. What PS version are you using?
There is an exception to every rule, except this one...
April 19, 2011 at 10:31 am
I can't argue that SQLPing does a more exhaustive search and returns more results than the approach used in this article.
I was using it on an IP range so it took most of the day each Sunday to run and then I'd come in on Monday to find an error box on the server it was running on.
When you clicked on the error box to cancel or OK or whatever it did not write any results to the output file and all was lost.
It is a third party tool and when I had problems with it there was no support for it.
I was using a free version and you get what you pay for.
PowerShell is, IMHO, the best free solution to finding new installations of SQL server on your network.
April 19, 2011 at 10:58 am
Craig A. Silvis (4/19/2011)
PowerShell is, IMHO, the best free solution to finding new installations of SQL server on your network.
Have you tried Quest's Discovery Wizard? It's free, too.
Also, when we did scan with SQLPing, we tended to use C class subnets, just batched up a bunch of scans. Made the files easier to process, too.
K. Brian Kelley
@kbriankelley
April 19, 2011 at 11:03 am
my pc windows XP sp3
April 19, 2011 at 11:12 am
I had downloaded and tested the Quest tool too but I still like using PowerShell overall because it does not depend on a third party tool.
There are a lot of sites out there that you can go to for help with PowerShell, not so many if you are using a tool provided for free by a lesser known vendor.
I don't want to slam any tool or deny their worth, but in my experience it is better to go with Microsoft on this one since they make both SQL Server and PowerShell.
They support both and there are a lot of other people that are using them and posting solutions too.
April 19, 2011 at 11:14 am
That is the minimum for the OS, but my question the PowerShell version. Run Get-Host from the ISE window.
There is an exception to every rule, except this one...
April 19, 2011 at 11:20 am
PS H:\> Get-Host
Name : ConsoleHost
Version : 1.0.0.0
InstanceId : c3010a3a-453d-460e-86fb-0c944b129c42
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : en-US
CurrentUICulture : en-US
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
PS H:\>
April 19, 2011 at 11:32 am
Try updating to PSv2. You can find the correct version for your OS here: http://support.microsoft.com/kb/968929
There is an exception to every rule, except this one...
April 19, 2011 at 11:46 am
Of course, all of the solutions listed assume that you have a domain admin-level account that can go out and do this searching. If you work in a locked down environment like I do, where we even have to fight for local admin on the database servers we administer, so segmented and controlled is security, none of these help. In such an environment, there unfortunately is not (at least that I have found) a practical way to locate every SQL Server on site.
April 19, 2011 at 1:02 pm
powershell script works fine after upgrade to version 2.0
sqlcmd -L list only brodcasting servers ,while this solution simply try to access every station that is up
and running
April 19, 2011 at 1:21 pm
I am getting the following error when I try to execute the script through powershell. Is anyone else getting this error. New to powershell so I am not sure where to start troubleshooting this.
Get-Service : A parameter cannot be found that matches parameter name 'computername'.
At D:\find.ps1:22 char:46
+ $computers |? {(get-service -computername <<<< $_ |% {$_.name}) -match "sql"}
I have always wanted to use powershell for a reason and this seems like an exellent use for it. Thanks.
April 19, 2011 at 1:34 pm
Craig A. Silvis (4/19/2011)
I had downloaded and tested the Quest tool too but I still like using PowerShell overall because it does not depend on a third party tool.There are a lot of sites out there that you can go to for help with PowerShell, not so many if you are using a tool provided for free by a lesser known vendor.
I don't want to slam any tool or deny their worth, but in my experience it is better to go with Microsoft on this one since they make both SQL Server and PowerShell.
They support both and there are a lot of other people that are using them and posting solutions too.
And here I'll disagree because at the end of the day, unless you write a complex script that probably should be a .NET app, it's not going to be able to do what SQLPing (with source code available, if I recall correctly), Quest Discovery Wizard, or nMap can do.
K. Brian Kelley
@kbriankelley
April 19, 2011 at 1:36 pm
jeff.mason (4/19/2011)
Of course, all of the solutions listed assume that you have a domain admin-level account that can go out and do this searching. If you work in a locked down environment like I do, where we even have to fight for local admin on the database servers we administer, so segmented and controlled is security, none of these help. In such an environment, there unfortunately is not (at least that I have found) a practical way to locate every SQL Server on site.
Not exactly. In this kind of environment the DBAs shouldn't be running the discovery. One of your security folks should be. In our case we had a process run on a schedule as a domain admin level account. It put its results in a folder accessible by the DBAs.
K. Brian Kelley
@kbriankelley
April 19, 2011 at 1:39 pm
@Needy Info-318558
Try upgrading to PSv2, see above posts for link.
There is an exception to every rule, except this one...
Viewing 15 posts - 16 through 30 (of 57 total)
You must be logged in to reply to this topic. Login to reply