SQL Ping is a nice little command line enumerator that specifically looks for SQL servers and requires no authentication whatsoever. It works on all versions of SQL server up to and including 2005 and also Express editions.SQL Ping is a cool utility that’s useful for both discovering SQL Server systems in your environments as well as determining their health. SQLPing looks for servers on port UDP 1434, and it’s particularly useful for finding stealth SQL Server Express instances.

How it works

The tool will first create a temporary table with 64kb of data on the target SQL server.  It will then retrieve the contents of the temporary table on a fixed interval.  By measuring the round trip time, an evaluation of the network communications between the NS host and the SQL server can be accomplished.  This pure read operation test is designed to incur zero CPU load on the SQL server (which can be proven with a SQL Profiler trace).In a pristine environment, response times would be between 0 and 15 milliseconds (ms).  There would be zero network failures.  A congested network can cause delays in forwarding packets between the servers, including re-sending of the same request.

 Setup

1. Copy the attached executable to the NS, and open it. Note: For running on Windows 2008, first right click on the program icon and then choose Run as Administrator, otherwise the program will fail to run.
2. The NS database settings will be read from the registry.
3. If indicated, enter the SQL password
4. Click the Ping button
5. By default, the tool will create a 64kb row in a temporary table, and request the data every 3 seconds.
6. Click the Stop button to calculate the average response time.

Sample Execution:

The boxes at the top keep a running count of response times.

• Good is less than 100ms
• Warning  is between 100ms and 400ms
• Bad is greater than 400ms
• Failures are counted when a network communication problem is encountered
• File logging

1. Check the Enable Logging box.
2. If desired, modify the specified filename and path.
3. Start the ping trace as normal.
4. The logging is output in tab-delimited format.  It can be viewed with notepad or Excel.

 For each error, the first 100 characters of the error message are included in the last column.

Sample log file viewed in Excel

Performance Monitor counter

1. Open Perfmon.msc > Performance Logs and Alerts > Right click > New Log Settings
2. Name the log “SQL Ping”
3. Click Add Objects > SQL Ping > Add > Close
   Note: The SQL Ping perfmon counters will only exist if the SQL Ping tool is running
4. Click OK (The default interval of every 15 seconds is appropriate)
5. Verify that the new counter log is now running (it should be green)
6. After a few hours, stop the counter log, and analyze them for obvious performance issues. (C:\Perflogs\sql_ping_00000*.blg)
7.  An error message of “Application has generated an exception that could not be handled.” at startup indicates that the application is being launched from an UNC path.  Default assembly security requires registry access to be performed from a local executable.  Copy SQLping.exe to the local file system and execute again.

Version History

v 1.4

• • Added detection for additional types of SQL connection failures
  • Added Date and Time information for each ping attempt
  • Added alignment and formatting of ping number and ping length
  • Added asterisks indicator to bad & failed ping attempts
  • Added textbox to display the running ping average.  For reference, network failures are counted as ~100 seconds.
  • Added display filters to pause and show the last 64k of all ping attempts or just the bad/failed ping attempts.
  • Disabled usage of SQL pooled connections
    • This was implemented to avoid a known bug in .NET 1.1 ADO, which fails to recover from a dead SQL pool after network connectivity is restored.  NS6 appears to suffer from this bug, but it would be very expensive to disable connection pooling for the NS web and Altiris service.
  • Set counter fields to read-only
  • Set interval box to read-only during ping operations
  • Fixed issue where it was difficult to stop pinging during network failures
  • Improved thread safety
  • Other minor UI improvementsAdded file logging functionalityv 1.33v 1.21
  • Fixed flaw in milliseconds measurement

SQLPing scans your network to locate new and unprotected SQL Server and Microsoft SQL Server Desktop Engine (MSDE) instances. SQLPing works with SQL Server 2000 and later, and requires the .NET Framework. SQLPing uses both active and passive scans to find SQL Server and Microsoft SQL Server Desktop Engine (MSDE) installations that need to be secured.

SQL Server backup doesn’t have to be complex. With these simple commands you can perform full, transaction log or incremental, differential, and file backups. Plus you’ll learn commands for recovering files and when to do a tail-log backup.

The SQL slammer Internet worm that appeared in 2003 caused a lot of damage and resulted in lost productivity for many IT shops. Consider the virulent means by which SQL slammer was able to propagate itself: By scanning the network for other SQL Server instances through well-documented means, SQL slammer simply copied itself from one SQL Server to the next. You can prevent this sort of propagation by using SQLPing 3.0 to scan your network for new and possibly misconfigured or unprotected SQL Server and Microsoft SQL Server Desktop Engine (MSDE) installations so that you can properly secure them.

SQL Server backup doesn’t have to be complex. With these simple commands you can perform full, transaction log or incremental, differential, and file backups. Plus you’ll learn commands for recovering files and when to do a tail-log backup.

The SQL slammer Internet worm that appeared in 2003 caused a lot of damage and resulted in lost productivity for many IT shops. Consider the virulent means by which SQL slammer was able to propagate itself: By scanning the network for other SQL Server instances through well-documented means, SQL slammer simply copied itself from one SQL Server to the next. You can prevent this sort of propagation by using SQLPing 3.0 to scan your network for new and possibly misconfigured or unprotected SQL Server and Microsoft SQL Server Desktop Engine (MSDE) installations so that you can properly secure them.

When invoking SQLPing, you can choose to perform an active scan on a range of IP addresses or to scan all the IP addresses in a specified text file, if you choose to perform an IP address range scan, SQLPing also includes a couple of buttons on the Scan tab that let you perform a DNS lookup for the starting point of the range scan and/or fill in the last octet of the Class C scan.

SQLPing uses two input files, userlist.txt and password. txt. Userlist.txt contains a list of all the user IDs that you want SQLPing to attempt to challenge. Password.txt contains a list of all the passwords that you want to challenge against each of the users identified in the userlist.txt file. The SQLPing .zip file contains samples of the userlist .txt and password.txt files for demonstration purposes. Although you can use the sample files, you’re encouraged to replace the sample values with your custom dictionaries of users and passwords.

When defining your scan, you can choose whether SQLPing will use all available techniques to scan for SQL Server instances or a subset of the techniques available by selecting the appropriate check boxes on the Options tab.SQLPing includes six active scanning techniques and two passive scanning techniques.

You can enable or disable most aspects of the scan under General Options on the Options tab. You can also choose to enable a Debug Log (and specify the path and name of the debug log file), which provides additional information about the performance of SQLPing. Note that you can specify alternate login credentials on the Options tab if you need to access specific domains on the network.

When you’re ready to run a scan, simply click the Scan button on the Scan tab. SQLPing will return a list of all the SQL Server instances it finds. You can save the entire report (or just the IP address list) by clicking File, Save.

SQLPing requires the Microsoft .NET Framework 2.0. Also, due to .NET policy restrictions on most computers, you should execute the SQLPing 3.0.exe program from a local drive; otherwise, you risk losing partial functionality.

Note that there’s an alpha release of a command-line version of SQLPing now available. This release includes only the high-level switches included in the GUI version of SQLPing. The benefit of the command-line version is that you can automate SQLPing scans and reporting as part of a DTS or SQL Server Integration Services job.

Use SQLPing to prevent outside access

SQL Server 2000 is accessed through the network, either through a named pipe or a network protocol, such as TCP. For this reason, a SQL Server deployment has to be set up to accept connections only from trusted sources. If you’re running SQL Server on only one machine (possibly in conjunction with a Web server on the same box), then you’ll want to make sure it’s only accessible to that machine and not to unauthorized remote clients who may try to connect.

Even when SQL Server 2000 only uses named pipes as its network protocol, it can still be accessed from the outside world if the host server does not block connections from UDP port 1434. SQL Server listens on UDP port 1434 for a handshake (a packet payload of value 0x02) and then replies with detailed information about all the available instances of SQL Server on that computer. This includes the names of the server instances, the network connections (such as named pipe info) and the version(s) of SQL Server running. This is obviously a major problem!

To help combat this problem, a team of programmers from the SQLSecurity.com site created SQLPing, a simple command-line tool to determine if a given machine has its SQL Server listening port open for public access. The program is simple enough: Invoke it from the command line with either an IP address or a hostname, and it will attempt to contact UDP port 1434 on the target machine and report any results returned.

If you run SQLPing across the Internet and are able to retrieve information from a given SQL Server, that box should be locked down as soon as possible. Block UDP port 1434 wherever possible, or simply set up an appropriate firewall and only open ports as needed. Even if that instance of SQL Server isn’t set to accept connections from the Internet at large, the information revealed can be used in other contexts.

–SQLPing scans your network to locate new and unprotected SQL Server and Microsoft SQL Server Desktop Engine (MSDE) instances. SQLPing works with SQL Server 2000 and later, and requires the .NET Framework. SQLPing uses both active and passive scans to find SQL Server and Microsoft SQL Server Desktop Engine (MSDE) installations that need to be secured.

Major Features of Sql Ping

• Installation Instructions For Windows

Installation Instructions For Windows

A) Click the Windows “Start” button and select “All Programs” and then point to Sql Ping

B) RDP Connection: To connect to the operating system,

1) Connect to virtual machine using following RDP credentials :

• Hostname: PublicDNS  / IP of machine
• Port : 3389

Username: To connect to the operating system, use RDP and the username is Administrator.
Password : Please Click here  to know how to  get password .

C) Other Information:

1.Default installation path: will be on your root folder “C:\SQLPing”
2.Default ports:

• Windows Machines:  RDP Port – 3389
• Http: 80
• Https: 443

Configure custom inbound and outbound rules using this link

Installation Step by Step Screenshots