Error 1639 during SCOM reporting installation

March 26, 2015

Hello Everyone,

A few weeks ago I experienced a bizarre issue during the installation of the SCOM reporting component. It kept rolling back the installation. When I took a closer look in the installation logs(default location: %systemdrive%\Users\%username%\Appdata\Local\SCOM\Logs) I noticed the last error before rollback was ‘Error 1639 Invalid Command Line Argument‘. This was strange because the wizard validated all my data throughout the steps. The next step I took was to install the reporting component through command line, however the same issue occurred: Invalid Command Line Argument.

After further analyzing the logs and comparing it with a successful installation log I noticed that the installer was unable to read the location of the data warehouse instance. First I thought it was an issue with security, but everything seemed to be fine in that regard.
I was unsure of where the installation took the data of the data warehouse location, as this was not a parameter that could be defined during installation. So I figured this had to be something that was read from the OperationsManager database. This reminded me that the port of the SCOM SQL instance was changed from dynamic to static a few days before.

This technet article describes what configuration changes are required for SCOM to work on a fixed port. The article requires you to change some DB records, one of which is the Data Warehouse location.

I knew of at least one mistake in this article. The table dbo.MT_DataWarehouse in which we need to change the record is not correct in most cases. This table only exists in SCOM 2007 or when you upgraded your SCOM environment from 2007 to 2012 for example. On a clean installation of SCOM 2012 and higher however, this table has been renamed to MT_Microsoft$SystemCenter$DataWarehouse.


But then I noticed another mistake in this article.

The article describes to change the DB record in this table from computer\INSTANCE1 to computer\INSTANCE1, <port>.
Notice the space between the comma and <PORT>.

I assume when this record is read during setup, the space causes the port to be seen as an additional command line parameter. When I removed the space from the records the reporting installation completed successfuly.

Hope this post helps some people out there!



Recreate SSRS TempDB

May 23, 2012

Since all of the system center products are based on SSRS. It’s time to do some basic error resolving when the reporting does not work.
In this case there was the reporting services tempdb that could no longer be brought online. So I recreated the temp db. This was for a system center essentials installation.
First delete the old tempDB.
Then create a new database with the correct name.

Match the collation settings with the ReportServer DB


Recreate the RSexecRole ( Similar to ReportServer DB )

And add the created user

Run query ( found under Reportserver location , CatalogTempDb.sql )

And verify result

And now test the reporting … Success !