For one of my customers I have been fooling around with a clean SCOM 2012 SP1 install through command line. I ran into some issues and workarounds that you might want to be aware of. There are probably more to come, but I thought it better to post this piece first.
First of all we would start with the TechNet page about installing operations manager by using the command prompt window:
http://technet.microsoft.com/en-us/library/hh416216.aspx
Also pay attention to the end of the article where there are specific references to different scenario’s, such as installing on a single server, installing first management server, the web console and so on.
Lesson 1
Of course there are prerequisites we can script as well, such as .net Framework 4 installer and the Report Viewer 2010 installer and the IIS prerequisites. Take them along.
Lesson 2
When installing the FIRST management server (or when it is the only one..) you need to accept the end user agreement. This is done through the “/AcceptEndUserLicenseAgreement” switch. However the documentation is currently wrong (as are the examples in the referenced example pages). The option you should use is “/AcceptEndUserLicenseAgreement:1“.
Lesson 3
I still do not know where this came from, but I had a few runs during the initial testing where it did not want to accept
multiple entries for the “/components:” switch, but I attributed that to the environment and the script. Because later after having re-written the script anyway, it did not give these errors anymore. When in doubt just type the commands again on a separate line and throw out the old one.
Lesson 4
This is a longer lesson, as it is multi part B)
When using the command line install, there is no option to change the database and log paths for each database. These options are available in the setup wizard. Of course we ran into this because of a known issue (read release notes!!) where setup tries to create files without a file name and only an extension for the datawarehouse database (so “.mdf” and “.ldf” are created).
There is a solution to this if the files are created already by using a solution as mentioned here:
https://blog.topqore.com/2013/01/25/scom-2012-sp1-strange-file
And when using the setup wizard GUI you can work around this by “using the error” in the script to circumvent this by adding the file name you want without a trailing “\” at the end of the line as blogged here:
http://blog.concurrency.com/infrastructure/scom-2012-sp1-installation-error/
However, as stated earlier the command line does not give an option for this. So what happens? Well, that depends on your settings in SQL and rights and the version of SQL as it turns out!
First of all if you can not specify the database and log paths, it will take the default paths defined on your SQL instance. For fun open the SQL Management Studio and take a look at the properties of the server and go to the “database settings” tab. Near the bottom you will see the default paths. This should be where the command line wizard tries to place the files for both databases. Now take a look at the very end of those paths and determine if your SQL is using a “\” at the end of the line. I found that SQL 2008 R2 is not using it and that SQL 2012 is using it. And I can not change the bahavior by manually adjusting this setting (remember that this is a registry setting in the end, so you need to restart SQL to get it active).
This has an effect, due to the error in the sql creation script for the datawarehouse. That script looks at the path variable, either from the setup wizard GUI or from SQL default settings as discussed above. Due to the error in the script it expects the last thing in the path to be a trailing “\”, otherwise it will see the last characters after the last “\” to be the file name you want for the datawarehouse. In many cases this would be something like “X:\Program Files\blabla\blabla\MSSQL\Data” and for the SQL 2008 R2 version I found the path to be like this without the trailing “\”. So what does it try to do in this case? It tries to create a database file called data.mdf in the MSSQL folder one level up. In my case this gave an immediate access denied and of course a roll-back of the whole installation.
In SQL 2012 the above problem does not exist as far as I know, because it keeps adding a trailing “\” to the end of the folder path. So in that case we are back to https://blog.topqore.com/2013/01/25/scom-2012-sp1-strange-file
In SQL 2008 R2, if you run into this you could work around this by assigning the SQL service account enough rights (lets go for full control for now) in the folder one level higher. Run the installer again and it will create data.mdf and data.ldf in my example in the MSSQL folder. And from there you can also both move and rename the file as in https://blog.topqore.com/2013/01/25/scom-2012-sp1-strange-file
Of course you can script the moving and renaming of these files as well, however it depends on the environment you are in to determine how to do those things. Stuff like paths and if you first want to check those paths and such require some thinking script-wise, but it can be done.
Lesson 5
Yeah, it seems I can still install SCOM faster by hand *grin*.
I will probably have more lessons learned soon, but thought to post this set first.
Update 7 May 2013: Lessons learned addendums to Lessons 2 and 4 are posted in the post “SCOM 2012 SP1 command line install lessons learned update 1“. The update to lesson 4 contains additional switches to manipulate the database file paths!
Good luck!
Bob Cornelissen
