SQL Monitor 13

Your server estate is best accessed via WinRM so it is worth aiming for this.

If using WMI over WinRM, go to: WMI over WinRM.
If using WMI over DCOM, go to: WMI over DCOM.
If the Base Monitor must make connections to servers in a different network domain, and so navigate firewalls, review Adding servers on a different network from your Base Monitor and Summary of firewall requirements .

Adding SQL Server instances running on different types of server

Add SQL Server instances using the Adding SQL Server link in the web interface (Configuration > Monitored Servers).

For standalone machines:

If on the same network domain as the Base Monitor service, just enter the machine name.
If remote, enter the IP address of the machine or its fully-qualified network name.

For instances hosting AGs, installed in a cluster, including standalone instances installed on the cluster's nodes:

If on the same local domain as the Base Monitor service, enter [cluster-name] or the name of any node in the cluster [node-name], or you can use the [availability-group-listener]. SQL Monitor will automatically start monitoring any Availability Groups on the cluster.
If the cluster is on a different network domain to the Base Monitor service, you will first need to set up Domain Name System (DNS) for the cluster.

Add virtual machines using the Adding SQL Server link in the web interface (Configuration > Monitored Servers).

There are a few steps to complete first, depending on where the VM is hosted and on whether you need to monitor clusters.

VMware

SQL Monitor will monitor SQL Server running in a virtual machine under VMWare. It will be able to monitor both the guest virtual machine and the physical host.

You'll need to:

Register either the vCenter or ESXi machine using the Configuration > VMware hosts page.
Add the SQL Server instance using the Configuration > Monitored Servers page.

See: Configuring a VMWare host then adding the Virtual Machine.

Cloud-hosted (Azure, Amazon EC2)

The Base Monitor service will, ideally, run "within the same network" as the virtual machine. This could mean installing the Base Monitor on a virtual machine in the same network, or creating a VPN connection to it.
Alternatively, you'll need to establish inbound firewall rules for the WMI ports. After that, add the VM to SQL Monitor, just as for any machine.

See: Machines hosted in the cloud.

Azure-based Clusters and Availability Groups

The Base Monitor service must be "within the same network" as the virtual machine as your FCI or AG. This could mean installing the Base Monitor on a virtual machine in the same network, or creating a VPN connection to it.
Regardless, you'll need to take steps to forward the WMI traffic correctly through the Azure load balancer.

See: Monitoring SQL Server Failover Cluster Instances and AlwaysOn Availability Groups hosted in Azure IAAS.

Permissions required to monitor Windows servers and instances

For each remote server that you wish to monitor, you need to provide the Base Monitor service with a login account to connect to it, and with:

Sufficient permissions on the remote machine to collect the monitoring data.
Login rights on the machine hosting the Base Monitor service, since SQL Monitor must be able to authenticate the account locally.

Similarly, you'll need to supply a login account that the Base Monitor service can use to monitor each SQL Server instance.

The Base Monitor service will need to collect detailed diagnostic data from the Windows machine and from each of the monitored SQL Server instances. As such, ideally, the Base Monitor service will either run as a domain account that is both of the following, or will have access to other accounts that are:

A member of the Windows administrator group on the remote machine.
- If this is not possible, see Monitoring host Windows machines without admin permissions.
A member of the sysadmin fixed server role, on the SQL Server instance.
- If this is not possible:
  1. Disable Actions that require sysadmin membership.
  2. Add required permissions for monitoring SQL Server instances.

Authenticating using domain accounts

By default, SQL Monitor will use the Windows/Active Directory domain account that is running the Base Monitor service to connect both to the Windows machine and the SQL Server instances it hosts. SQL Monitor supports use of a group managed service account (gMSA).
However, you can also supply the Base Monitor service with one or more separate accounts to collect the Windows and SQL Server data.
- You add the user account to SQL Monitor on the Configuration > Monitored servers page, and a domain user is entered with the domain qualifier. You can specify:
  - A Windows / Active Directory login on the monitored server to collect data from Windows.
  - Either a Windows / Active Directory account or a SQL Server login to collect data from SQL Server.

If you are using an AD-authenticated account to connect between domains, you may need to ensure that there is bi-directional trust between them.

Authenticating using non-domain accounts

To connect to remote machines, SQL Monitor must authenticate the user locally, to the machine where the Base Monitor is installed. Therefore, with non-domain user accounts, you need to have on each machine (the Base Monitor machine and the remote machine) the same local user with the same password (i.e. UserName1 with Password1 must exist on both machines).

Add the user to SQL Monitor on the Configuration > Monitored servers page as .\UserName1 so that it will use the user local to each machine. This will be automatically changed to display as UserName1@, but don't worry about this.
You may also need to add the registry key specified in this article to stop the UAC from reducing the user's privilege when accessing the machine remotely (this is on the machine you want to monitor).