At a customer-site today we discovered some interesting things installing a few OpsMgr management servers.

The scenario is:
- A active/active SQL Cluster running SQL 2005 SP3 (This is where we want to host the OpsMgr-database)
- A couple of Server 2008 as RMS and MS

When you install the database on you run the setup on one of the clusternodes… works fine.

Then… when it’s time to install the RMS the problems kicks in.
A few steps in to the setup you are prompted to name the SQL-Server, Databasename and what port… this works fine.
The next steps are for the accounts you want to use…
Then when at the end of the progress bar the text says something like “Executing SQL Strings” it fails.

If you look in to the log file you can see that it cant create a connection to the SQL Server, kinda strange since it did verify that the database existed in the step where you point out server and name.

After trying everything we started to create logs… massive amount of logs, traces and dumps.
We couldn’t see that the msiexec tried to connect to the SQL… so after googling, reading and googling some more we found the problem.

IP-Sec and the broker-service.

What happens is that the msiexec tries to connect to the SQL Server, what it does in a clustered environment is that it talks to the SQL Broker who then says “Hey the instance you are looking for is located on port 123″… But, when the broker responds, it doesn’t respond from the same IP as the SQL server.

And what do a standard IP-Sec-setup do with packages from “another” IP… drop.

So, to work around this you need to install the SQL Client on the RMS/MS.
Then set up an alias (32-Bit alias if you are using a x64, if you are using a x86 you don’t have to bother) that’s named the same as the SQL-Server and with the right port.
When that’s done you can install your RMS or MS.