This article explains the environmental requirements necessary to successfully run UpSearch Authorize. These requirements help ensure accurate enterprise-wide SQL Server discovery, reliable data collection, and consistent execution across the environment.
UpSearch Authorize is an on-premises, agentless desktop application with a small installation footprint. The digitally signed and antivirus-whitelisted application discovers, verifies, and collects information about Microsoft SQL Server instances and the underlying Windows Operating Systems throughout the environment.
To ensure successful execution of the UpSearch Authorize data collection process, the following conditions must be in place:
1. Network Connectivity and Protocol Access
ICMP (Ping) must be enabled to allow host discovery and reachability validation. Target systems must permit Windows Management Instrumentation (WMI) access for remote data collection.
2. Windows Firewall Configuration
Windows Firewall must allow inbound traffic for:
- WMI — ports 135, 445
- ICMP — enable echo request rules
- WinRM — ports 5985 (HTTP), 5986 (HTTPS)
These settings enable secure, agentless communication with target systems.
Enable the following Windows Firewall rules:
- Windows Management Instrumentation (WMI-In)
- Windows Management Instrumentation (ASync-In)
- Windows Remote Management (HTTP-In)
- Windows Management Instrumentation (DCOM-In)
- Remote Service Management (NP-In)
- Core Networking Diagnostics – ICMP Echo Request (ICMPv4-In)
3. Subnet and Network Scope Definition
• Ensure subnet ranges accurately reflect the network topology
• Avoid incomplete or outdated subnet definitions, which may result in missed systems
• Scan duration is influenced by the number of IP addresses included:
- Larger ranges increase runtime due to the volume of network probes
- Scope subnets intentionally to balance coverage and execution time
4. Application Usage Requirements
UpSearch Authorize is designed for enterprise-wide discovery, including identification of previously unknown SQL Server instances.
The application must be executed with sufficient privileges to discover systems and collect data throughout the defined network scope.
5. SQL Server Network Binding Considerations
In environments where SQL Server instances are not configured to “Listen on All IP Addresses” and are instead bound to specific IP addresses:
• The application captures a single IP address per instance, based on the order defined in SQL Server Configuration Manager
• When multiple IP addresses are configured:
- IPs are evaluated in sequence (e.g., IP1, IP2, IP3, etc.)
- The application selects the first active IP address in that list
• As a result:
- Not all listening IP addresses may be captured
- The reported Service IP Address reflects the first configured and active binding, not all available bindings
Example
In a configuration where a SQL Server instance is bound to multiple IPs:
| Computer_Name | ComputerIPAddress | ServiceIPAddress |
| PROD-SQL1.UPSEARCH.LOCAL | 172.100.1.32 | 169.254.2.57 |
| PROD-SQL1.UPSEARCH.LOCAL | 172.100.1.32 | 172.100.1.32 |
In this example, the application selects 169.254.2.57, as it appears first in the SQL Server Configuration Manager IP binding order.
For environments requiring visibility into all SQL Server network bindings, review SQL Server Configuration Manager settings or consider standardizing SQL Server network configurations where appropriate.
Summary
These requirements ensure:
- Accurate discovery of SQL Server instances
- Reliable, agentless data collection
- Efficient execution aligned to network scope
- Alignment with standard enterprise security controls
Failure to meet these conditions may result in incomplete visibility or delays during discovery.