ConfigMgr Prerequisite Checker
The ConfigMgr Prerequisite checker typically does a good job of making sure that everything is in place for an installation of ConfigMgr. It also usually does a good job of telling why a check failed. Unfortunately, this week I started an implementation at a client and ran into the following results:
The double whammy, both “SQL Server sysadmin rights” and “SMS Provider Communication”.
I chased after just about everything including SPNs, kerberos, name resolution, account permissions, UAC, and more. I ended up creating a near replica of the environment in my home lab to experiment and test a working theory. Here’s a quick run-down of the environment:
- Windows 2003 Active Directory Domain
- Windows 2003, 4 node, SQL Server 2005 Cluster
- Non-default Instance of SQL
- Windows 2008 Primary Site Server
After trying endless permutations with varying, seemingly inconsistent results, I finally realized that the prerequisite checker was being blocked by the Windows 2008 firewall. Once I realized that, and was able to consistently reproduce the behavior, it was easy to figure out why:
- By default, SQL Server listens on TCP port 1433. The non-default instance of SQL Server was not listening on 1433.
- In order for SQL client applications to discover non-default instances of SQL or instances not listening on TCP port 1433, the SQL Browser is contacted by the SQL client.
- The SQL Browser listens and responds on UDP port 1434.
- Thus, the prerequisite checker (or any SQL client) contacts the SQL Browser to find the TCP port number of the non-default instance of SQL.
- The reply, being UDP, is blocked by the Windows firewall and thus the instance is never actually found by the checker and a ripple effect occurred causing error messages that really had nothing to do with the issue at hand.
The solution is to allow UDP traffic on port 1434 from all nodes of the cluster through the Windows firewall. One interesting thing is that once a SQL client finds the port number for an instance of SQL, it caches this and no longer needs to rely on the SQL Browser to find the instance.
One big take away for me is to always temporarily disable the firewall when troubleshooting any type of potential communication issue. I stress temporarily because the firewall is a good thing. If you determine that the firewall is indeed blocking traffic, the next step is to figure out what holes to create in the firewall, re-enable it, and test again.