Can SQL Sentry connect to AlwaysOn listener

Philn

My SQL Sentry database is an alwayson group of servers, but when I try to connect from SQLSentry Client to the AlwaysOn listener, the tool gave me an error message "The SQL Sentry database can't be reached and maybe offline" look like it doesn't like the listener name. It works fine if I setup the connection with the server name is the physical primary server name. I was able to connect to the listener with other application just fine like SSMS, Powershell etc. but SQL Sentry tool.

what are the setting in SQL Sentry I need to do in order to make it works?

Thanks

jeremymayfield

Yes, SQL Sentry supports connectivity to a Microsoft SQL Server Always On Availability Groups listener.

However, the SQL Sentry Client error — “The SQL Sentry database can't be reached and may be offline” — when connecting via the AG listener name typically indicates a configuration mismatch rather than a product limitation. The most common causes are:

1. Missing MultiSubnetFailover=True
2. ApplicationIntent mismatch
3. SQL Sentry service configuration bound to physical node
4. SQL alias / DNS resolution issue
5. SentryOne database registered against physical server

SQL Sentry consists of:

• Monitoring Service
• SQL Sentry Database
• SQL Sentry Client

The Client does not connect directly to SQL Server — it connects to the Monitoring Service, which then connects to the SQL Sentry repository database. If the Monitoring Service is configured against the physical primary node instead of the listener, client connectivity may fail when using the listener name.

Required Configuration for AlwaysOn Listener

1. Ensure Repository Database Is in the AG

Confirm:

• SQL Sentry repository DB is part of the Availability Group
• Database is synchronized
• Readable secondary not required unless configured

2. Configure Monitoring Service to Use Listener

On the SQL Sentry Monitoring Service host:

1. SQL Sentry Monitoring Service Configuration
2. Modify the Repository connection:
   • Server name = AlwaysOn Listener DNS name
   • Authentication method unchanged
   • Advanced connection string parameters include:

MultiSubnetFailover=True;ApplicationIntent=ReadWrite;

If multi-subnet AG, this parameter is mandatory. Restart Monitoring Service after change.

3. Validate Client Connection Target

The SQL Sentry Client connects to:

Monitoring Service hostname

NOT the SQL listener directly.

Ensure:

• Client is not pointed at SQL listener
• Client is pointed at Monitoring Service server

Common Failure Scenarios

Scenario	Root Cause
Listener works in SSMS but not SQL Sentry	Monitoring Service still bound to physical server
Error says DB offline	Failover occurred but Monitoring Service still targeting old node
Works on primary only	No MultiSubnetFailover flag
DNS resolves but fails	SQL Browser / port mismatch

Additional Checks

Validate Listener from Monitoring Service Host

From Monitoring Service server:

Test-NetConnection <ListenerName> -Port 1433

Confirm:

• DNS resolution correct
• Port accessible

Verify Connection String in Registry (Advanced)

SQL Sentry stores repository connection details in:

HKLM\Software\SentryOne\Monitoring Service

Ensure no hardcoded physical server reference exists.

Best Practice Configuration

For stable AlwaysOn support:

• Repository DB in AG
• Monitoring Service uses Listener name
• MultiSubnetFailover=True
• ApplicationIntent=ReadWrite
• Static port configured on AG
• SQL Browser not relied upon

Important Note

Older SQL Sentry builds (pre-SentryOne rebranding) had limited AlwaysOn listener handling.
If running legacy version, upgrade is recommended.

Final Recommendation

The issue is almost certainly that:

The Monitoring Service is still configured against the physical primary node rather than the AlwaysOn listener.

Reconfigure the Monitoring Service repository connection to the listener and include MultiSubnetFailover=True.