We have an environment built out of SQL Servers installed on Azure Virtual Machines. We want to use Redgate’s SQL Monitor to monitor this environment; however, as of version 4.x it wasn’t completely supported on the Azure platform. Mainly, I suspect, because of the network requirements…
Our basic architecture was:
- Multiple VLANs containing SQL Servers to be monitored
- VLAN containing the monitoring server
Probably not the best for what we were wanting to do, but you work with what you’re given. I installed SQL Monitor, fired it up, and nothing worked.
After much trial and error, and a lot of network monitoring by a very enthusiastic young infrastructure guy, here are the inbound rules that we needed to put in place on each SQL Server VLAN to get this working:
| Name | Action | Destination | Protocol |
|---|---|---|---|
| SQL | Allow | *:1433 | TCP |
| SMB | Allow | *:445 | TCP |
| RPC | Allow | *:135 | TCP |
| Netlogon | Allow | *:137 | TCP |
| RPC_Dynamic | Allow | *:49152-65535 | TCP |
| TCP | Deny | *:* | TCP |
| UDP | Deny | *:* | UDP |
| ALL | Allow | *:* | * |
Missing fields:
- Type – all inbound
- Source Address: all from the IP address of the monitoring server
- Source port: * (there’s probably a more elegant way of doing this)
Those last three rules are just to allow PING traffic; without this, Redgate SQL Monitor (and probably most other monitoring systems) won’t work.
Everything is now fine…
…except version 5 introduced functionality to also monitor SQL Server Availability groups by talking directly to the SQL AG IP address, and we haven’t yet managed to get that working properly. But we’re working on it, and will update this post when ready.
disclaimer
I am a friend of Red Gate, and I do get free stuff to play with; however, this isn’t one of those tools, and Redgate hasn’t asked / paid me to write this post. I’ve written partly so that I have notes for the next time, and partly because it might help someone else.
Pingback: Red Gate SQL Monitor On Azure VMs | Curated SQL