Trying to prove that Skynet should be running on PowerShell!

Category Archives: System Center

When installing a new SMA (Service Management Automation) runbook worker or web service it might fail with the following error message in the log:
“Product: System Center 2012 R2 Service Management Automation Runbook Worker — Unable to communicate with SQL Server using database information provided.”

If you are doing a manual installation using the wizard it will look like this:

Not sure if this matters, but in my case, the database is hosted in a SQL AlwaysOn Availability Group on a non-default port (not 1433), and we are using “Windows Authentication”, or a “trusted” connection to log into the database.

After investigating this issue and looking at the network communication I realized that the installation actually tries to validate the connection on the database-settings page, but when it’s finally time to start the installation, it just fails right away. Also, I found that the connection at the “verify sql settings”-step is established via a service (svchost.exe or CcmExec.exe), which could explain why this workaround actually works (it’s probably using the same component in the OS).

I finally found a workaround for this issue though, which is pretty weird, but it got me through the installations of all my runbook workers and web services so I thought I’d share it if anyone else is experiencing this issue.

Workaround using temporary ODBC-connection
We will not actually create the connection, just fill in enough information to be able to do a test.

Fill in all the settings in the SMA Runbook Worker-wizard but do not click “Install” at the last page.

Instead, start the “ODBC Data Sources (64-bit)” (%windir%\system32\odbcad32.exe) using the same account as your installation wizard is running with and click “Add…”, see below:

Then click “Finish”:

Fill in the details of your database for SMA (the first two fields can be anything):

Fill in the name of your sql server, click next, and choose “Client Configuration” if you are using a non-default port and fill in the one you are using:

Click next, and choose to change default database to master (not 100% sure this is needed, but a thread @technet suggested this), like this:

Press “Finish” at the next step, but instead of pressing “OK” you choose “Test Data Source…” and you should see a successful test:

Immediately switch back to your SMA Runbook Worker wizard and press Install, it should now go through fine!

When the installation has finished, go back to your “ODBC connection test” and choose OK, then Cancel three times to exit the wizard for creating a ODBC-connection without actually creating it.

When deploying SCOM (System Center Operations Manager) in a multi-forest environment, you use certificates to establish the trust between the servers. Since we have CA Servers in every domain, we started up with configuring autoenrollment for all the SCOM Gateway Servers, and made sure all the different CA servers were added to the trust-store of the central servers. (I will not go through that process now, if you want me to, leave a comment).

So autoenrollment now works, but that isn’t really enough, is it? We still need to configure the Gateway Server to actually switch to the new certificate when it arrives.

The tool Microsoft has given to us to do this is MOMCertImport.exe, but that tool gives you a pop-up that you actually need to click on… Not very “automatable”.

After some research, we could find that all this tool seems to do is to add the certificates serial number, backwards (in pairs), as a binary key in the registry. That is very automatable! 🙂

Before you start, you should know that this method is probably NOT supported by Microsoft, on the other hand, if it fails, you could run MOMCertImport.exe and see if that helps…

A code walkthrough follows:

Let’s start with setting up some user controlled variables, like what Certificate Template is used and where the registry key is located:

It’s now time for some regex-magic again, we want to pair this number up (2 and 2), and then reverse those pairs. I must confess I did a couple of rewrites of this before I found one that seems quite effective:

# Reverse the serial number to match the format in the registry
$ReversedPairs=[regex]::Matches($SerialNumber,'..','RightToLeft') | ForEach-Object { $_.Value }

The two dots (‘..’) tells powershell to group them, and the ‘RightToLeft’ reverses them. The last foreach is to get only the values and nothing else.
But it needed to be in binary format aswell, we achieve that by doing this: