A few weeks ago I posted an article about some of my lessons learned for SCOM 2012 SP1 command line installations. It contained a very long Lesson 4 talking about creation and placement and naming of mostly the Datawarehouse database. I discussed the difference of SQL 2008 R2 and SQL 2012 in default file paths for databases and log files and its effect on the placement of the datawarehouse files. And of course the remaining effect that the created files have no name. As I explained for the GUI based setup there is a workaround by adding the datawarehouse database name as a folder name in the installation path of the database (basically this is using the bug in the install script B) ). SO lets go for the addendums to the lessons because there is hope:
Lesson 4 addendum 1:
Now I have been informed that there are a few additional install switches, until now not documented on the TechNet pages. This enables us to use the same trick as in the GUI. And of course this also enables us to change the paths for the opsdb and DW db separately, which was what I needed as well. These are listed below together with an example using a shorter path name:
/DatabasePath: “D:\Program Files\SQLstuff\Data”
/DatabaseLogPath: “E:\Program Files\SQLstuff\Data”
/DWDatabasePath: “D:\Program Files\SQLstuff\Data”
/DWDatabaseLogPath: “E:\Program Files\SQLstuff\Data”
Thanks to Byron Ricks for sending me these additional switches.
So what do we do if we want to make use of the trick to get the datawarehouse to be installed in the right directory and also for it to use the name we want? We append the database name we want to both the DW install paths.
/DWDatabasePath: “D:\Program Files\SQLstuff\Data\OperationsManagerDW”
/DWDatabaseLogPath: “E:\Program Files\SQLstuff\Data\OperationsManagerDW”
In my case this now created an empty folder with that name on my SQL box with that name, but the DW database was installed one level higher (where we wanted it) and with the right name (what we wanted). Now I can expand the script to have it clean up that empty directory later in the install process after checking for succesfull installation of the product.
Note: This happened to be a test with a SQL 2008 R2 SP2 backend server.
Lesson 2 addendum 1:
The previous post talked about the correct syntax of the /AcceptEndUserLicenseAgreement installation switch. And it talked about this only being needed for the first management server. However I have heard from a friend of mine that this is true for SCOM 2012 RTM, but that for a clean install of SCOM 2012 SP1 this switch is needed for all management servers. It will take a few more days until I can claim and clean a larger test environment for the clean deployment of a larger number of servers and components and I will write back with an update if I can confirm this story. In any case, if installing without this switch on a second management server gives you an error you can try to add this switch with a value of 1 and see if it works.
Update 10 June 2013: I can confirm this is needed also for other scripted installs. I ran into this requirement as well with the installation of a stand-alone Web Console server. So from now on I always add the /AcceptEndUserLicenseAgreement:1 to any install.
Other items
As soon as I claim and clean that other test environment I will be deploying a lot more components and will see what we run into and blog it back here. Keep in mind that this is just one of the possible setups, as you can have several prerequisite setups. For instance, are you installing on Windows 2008 R2 SP1 and SQL 2008 R2 SP2, or are you installing on Windows 2012 and SQL 2012 SPx? These can have diverse and sometimes unexpected effects as I have shown with the path variable inside SQL in my previous post. But never be discouraged :p
Happy installing!
Bob Cornelissen
