I decided I needed to re-install my lab environment.  I wanted to keep all of the firewalls on during the install process and only open the ports that are actually needed. I installed SQL using a named instance as many customers use a SQL 2008 cluster.

After I installed the SCOM database on the SQL 2008 server with all firewalls on.  I created a firewall rule to let port 1433 allow connections.  As specified in the Supported Configurations doc

Root management server 1433 —> OperationsManager database


I also setup a firewall rule to allow port 1434 back to the RMS server from the SQL Instance Server. (Also in the guide)

Root management server 1434 UDP < — OperationsManager database


I start the install of SCOM to the RMS server.  I unchecked Database as my database is already install the on the SQL instance.


I typed in my SC Database Instance Name and clicked Next


But I got this error “Setup cannot location the SC database”


So I enabled firewall logging to see what was getting dropped blocked by setting the firewall to log dropped packets.


In the SCOM setup I clicked back and then next.

I checked the firewall logs in %systemroot%\system32\Logfiles\Firewall\pfirewall.log  and it looks like UDP port 1434 is being dropped

date time action protocol src-ip dst-ip src-port dst-port size path
12/26/2010 16:56:54 DROP UDP 58321 1434 38 RECEIVE


I create another rule on the SQL server to enable UDP port 1434


In the SCOM setup I click back and next again.


Once again same failure.  “Setup cannot location the SC database”

Back to the firewall logs.  It now needs TCP port 62756 (Not in the guide)

date time action protocol src-ip dst-ip src-port dst-port size path
12/26/2010 17:12:03 DROP TCP 50503 62756 38 RECEIVE



I create another rule on the SQL server to enable TCP port 62756


After that rule is enabled I am able to continue on a install SCOM successfully with all of the windows firewalls still on.



6 Responses

    • You can remove TCP port 62756 after the install is complete.

      I would keep UDP port 1434

      The guide does mention UDP port 1434 but the have it going on the reverse direction.

      Root management server 1434 UDP < — OperationsManager database

  1. I did my dev install on SQL 2008 R2 and it ran fine with just 1433 and 1434. Did not have any other ports opened that I recall but will check. I only had issues with web console but will follow your psot on that.


  2. The high port was likely only required due to the use of a named instance – vs a default instance. Named instance will pick a random high port for use. Default instance will use 1433 TCP and then the 1434 UDP isnt needed.

  3. If SQL Server 2005 or SQL Server 2008 is installed using a default instance, the port number is 1433. If SQL Server is installed with a named instance, as done in this example, then it is probably using a dynamic port. To identify the port, you can do the following:
    1. Run SQL Server Configuration Manager.
    2. Open SQL Server Network Configuration.
    3. Open Protocols for INSTANCE1 (or the instance that is running under it).
    4. Open TCP/IP.
    5. Click IP Addresses.
    6. The port is under IPAll (usually the TCP Dynamic Ports).

    This is from the SCOM 2007 R2 guide.

  4. If you install SQL on Windows 2008 (R2) you need to allow the SQL browser to receive incoming request (port 1433). Instead op opening port 1434 you can allow the sqlbrowser service + sqlserver executable to receive incoming requests. The browser will tell the requesting applications which port SQL server using.
    The executables can be found in the following location.

    SQL Browser
    C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe

    SQL Server
    %ProgramFiles%\Microsoft SQL Server\\MSSQL\Binn\sqlservr.exe

    Start “Windows Firewall with Advanced Security” to add the inbound rules.

Leave a Reply

Your email address will not be published. Required fields are marked *