I have a virtual environment where we are setting up a small OM management group for testing.  In this environment the plan is to have the following systems as the foundation:

• DB1 - member of a two node SQL cluster for DB instances
• DB2 - same as above
• MS1 - first OM management server to be installed
• MS2 - second OM management server to be installed
• RS1 - SQL Reporting Services for OM

After installing and configuring the SQL cluster and specific SQL instances for the OM operational DB and the data warehouse DB, we have successfully installed the first management server.  However, during the attempt to install the second management server, the installation wizard CANNOT seem to recognize the existing Operational database - meaning that the drop down list available for selecting the DB is empty.

Note the following:

• All systems were installed using the same base syspreped VHDs
• All OS configuration is performed in a scripted fashion
• All systems are running the same Windows patches
• All systems reside on the same Hyper-V host and reside in the same AD OU
• For troubleshooting, the SQL Management tools were installed on the second management server to verify that connectivity to the SQL cluster is functional from the second management server
• The latest patches and hotfix rollup have been applied to the first management server 

I've also attempted to script the install and included what I believe to be the relevant portions of the log below.  Any suggestions are welcome...

[23:20:39]: Debug: :MSSQL$OMDB on server MySQLCluster-OMDB is in a running state
[23:20:39]: Debug: :Connection was not open.  We will try to open it.
[23:20:39]: Debug: :SqlConnectionReady returned True.
[23:20:39]: Error: :CheckForConflictingSqlDatabases: Found a database with the name OperationsManager in this instance.
[23:20:39]: Debug: :MSSQL$OMDB on server MySQLCluster-OMDB is in a running state
[23:20:39]: Debug: :Connection was not open.  We will try to open it.
[23:20:39]: Debug: :SqlConnectionReady returned True.
[23:20:39]: Error: :CheckForConflictingSqlDatabases: Found a database with the name OperationsManager in this instance.
[23:20:39]: Info: :Info:Using DB command timeout = 1800 seconds.
[23:20:39]: Info: :Info:isOMDatabase:  Read was successful. This is OM DB
[23:20:39]: Info: :Info:Using DB command timeout = 1800 seconds.
[23:20:39]: Info: :Info:SetDBAndServerScenario: OM Server FQDN is: MyServer.SomeWhere.com
[23:20:39]: Error: :Error:SetDBAndServerScenario: this is disaster recovery scenario but mandatory commandline switch to recover has not been passed. This is fatal error.
[23:20:39]: Error: :RationalizeServer: failed to get valid DB or Server scenario for given server and database.
[23:20:39]: Always: :End: Rationalize System Center Operations Manager.
[23:20:39]: Error: :RationalizeComponents blocked because: Could not retrieve a valid database or server scenario for this install.
[23:20:39]: Always: :End: Rationalize server component.
[23:20:39]: Error: :We could not rationalize the component choices.  We must fail.
[23:20:39]: Always: :Begin: Property bag dump.



• Edited by Aric Bernard Friday, July 13, 2012 3:29 PM Insert proper screen shot

Hi

Are you installing the second Management Server using an account which has permission on the SQL Server? If the install account does not have the permission on SQL Server you won't see any database.

Stefan

Hi

Is this a named instance? You have servername\instancename  e.g xxSQLC1\SCOMDB ... is SCOMDB the SQL instance name?

If not, have you tried just XXSQLC1?

If this is a named instance then it is almost certainly not using port 1433 as the default sql instance uses that:

http://technet.microsoft.com/library/hh205990.aspx#BKMK_Firewall

"If SQL Server 2008 SP1, SQL Server 2008 R2, SQL Server 2008 R2 SP1, SQL Server 2008 SP2, or SQL Server 2008 SP3 is installed by using a default instance, the port number is 1433. If SQL Server is installed with a named instance, it is probably using a dynamic port. To identify the port, 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)."

If it is a named instance then Also check that the SQL Server browser service is running on the SQL Server

Cheers

Graham

Hi,

Please check the firewall settings and ensure the port 1433 has been opened:

Supported Configurations for System Center 2012 - Operations Manager
http://technet.microsoft.com/en-us/library/hh205990.aspx#BKMK_Firewall

How To Open Firewall Port 1433 for SQL Server Database Engine For Use With SCOM (or anything else)
http://blogs.technet.com/b/danstolts/archive/2011/06/08/how-to-open-firewall-port-1433-for-sql-server-database-engine-for-use-with-scom-or-anything-else.aspx

In addition, about the issue, please also refer to the following posts:

Trouble with setup due to SQL not being detected?
http://blogs.technet.com/b/momteam/archive/2010/10/26/trouble-with-setup-due-to-sql-not-being-detected.aspx

Solution: OpsMgr 2007 setup fails cannot detect SQL
http://blogs.technet.com/b/operationsmgr/archive/2010/10/27/solution-opsmgr-2007-setup-fails-cannot-detect-sql.aspx

Hope this helps.

Thanks.

Both management servers are being installed with the same account and the first management server is being installed without issues.

Based on the log I posted in the original post, I have to assume that the firewall is not the issues:

:SqlConnectionReady returned True.
[23:20:39]: Error: :CheckForConflictingSqlDatabases: Found a database with the name OperationsManager in this instance.

However, we have turned the firewalls off on all systems and still have not change in behavior.

Hi Graham,

You are correct in the fact that we are using SQL named instances for this installation.  However, we are in fact using a fixed port for each SQL instance. The screen shot above is misleading since the port field shows 1433 whereas the SQL instance is using port 49010 for the SCOM DB instance and 49011 for the SCOM DW instances - yet the affect in the SCOM installation wizard shown in the screen shot with the proper port in use is the same.

We have also validated that the SQL browser service is running.

Hi Aric

Any errors in the SQL Server Error log, especially around permissions?

Cheers

Graham

Hi

Are you using an Alias for the Database Server?

Stefan

The only error I see is:

2012-07-13 16:56:31.43 Server      The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

I believe that I have manually registered all the required SPNs.

I am not using any Alias.

Hi

I am just wondering, the Service account your SQL Server Service is runnig, is it a domain user service account or is it a local server service account? May you could make a Screenshot of the SQL server Services so we can see what kind of service are running and which accounts they are using.

Which SPN did you register?

Regards,

Stefan

I am not sure if you speak german, but here is a post which explains the SQL server SPNs

http://social.technet.microsoft.com/Forums/de-DE/sqlserver/thread/f71f7cd9-bbaa-43c5-866e-f3b330861887/

If I should translate, let me know :)

Stefan

For each SQL instance, the SQL Server service and Server Agent service are running as domain accounts.

As far as SPNs go:

• For the cluster name of each SQL instance: Domain/ClusterInstanceMachineAccount and Domain/ClusterInstanceMachineAccount.MyDomain.com
• For the OM MS: Domain/OMMSName, Domain/OMMSName.MyDomain.com, MSOMHsvc/OMMSName, MSOMHsvc/OMMSName.Mydomain.com, MSOMSdkSvc/OMMSName, MSOMSdkSvc/OMMSName.MyDomain.com
  
• For the SCOM SDK/DA service account:  MSOMSdkSvc/OMMSName, MSOMSdkSvc/OMMSName.MyDomain.com (for each management server)

SO.... After further digging, something very strange is happening in this environment for which I have no explanation.  Let me explain...

• I delete the AD computer object affiliated with my second management server (let's call it OM2).  
• I have created a basic installation of WS2008R2SP1 in a VM.  
• Before performing ANY configuration, I take a snapshot.
• I configure my VM in the exact same manner I have done previously (I say exactly because I have scripted every step).

The result is identical - no ability to access the SCOM Operational DB created by OM1 (the first management server installed).

• I roll back my snapshot so that my VM is in the original un-configured state.
• This time I give the VM a different name: OMTest2
• I configure my VM in the exact same manner I have done previously (this includes the same MAC address and IP address) - again this is scripted.

The result is completely different as I CAN access the SCOM Operational DB!!!

Any thoughts?

 

• Edited by Aric Bernard Friday, July 13, 2012 10:34 PM spelling

I don't see how you registered your SPN's for MOM in case you are using a domina account for the SDKConf account it would be

MSOMSdkSvc/OMMSName.MyDomain.com Domain\sdkconf

MSOMSdkSvc/OMMSName Domain\sdkconf

Check out here...

http://blogs.technet.com/b/kevinholman/archive/2011/08/08/opsmgr-2012-what-should-the-spn-s-look-like.aspx

Stefan

All SPNs were registered as described in the article you referenced.  I have not root caused the issue, but I do know that using a different computer name for the second management server resolves the problem.

Having the same issue. But even when rebuilding a MS with the SAME name it works second time through, but...

The 3rd and 4th MS's are having the same issue of not being able to connect to the DB, even though 1 & 2 could (now)!!

Never had a problem with SCOM installs with 2007R2, but this is proving to be a real time-waster for 2012.

John Bradshaw

Bradje,

  Did you ever figure this out?  We're running into this now for a client.  Every other SCOM install went down correctly, and now the final site (of course, its always the last site), it failing in the same way as yours!

We were not able to root cause the problem.  Repeated system rebuild with same name failed every time. As mentioned above, we used a different machine name and everything worked as expected.  As such we slowly stepped away from the keyboard.

Hi,

I may be late in replying.

I also had same issue. Check if the management server is listing under operations manager console and remove it. Because even after roll back the management server has to be removed from the operations console.

Try to install after removing. It will work.