There has always been a bit of confusion on when to run the DBCreateWizard.exe tool, or when to just use SetupOM.exe to create the Operational DB or Data Warehouse DB.
Historically.... in MOM 2005, we used the DBcreate Wizard in order to create the Onepoint database on Active/Active clusters..... or when SQL DBA teams refused to run a MSI based setup on one of their SQL servers. The DB create wizard was a better option for them.... since it did not have to install any binaries on a SQL server. In practice.... it was pretty rare to see this in widespread use.
In OpsMgr 2007, we haven't really documented all the scenarios for when you should run the DBcreate Wizard.... and I will try and do that here.
The DB create wizard is located on the CD - In the \SupportTools folder. It does require some additional files to run it - these don't have to be "installed", just need to be copied over to the SQL DB server where you will run the wizard. Follow: http://support.microsoft.com/kb/938997/en-us
*** Note - the additional files required to run DBCreateWizard.exe are documented in the KB article above. They were also provided on the SP1 Select CD. However - the files provided on CD are for 32bit x86 only. If you are using the DBCreateWizard on a x64 platform - you MUST copy these files listed in the KB article from an x64 server.... any x64 server with the console installed will have them.
Note - there were some significant issues with the RTM version of this tool... in detecting the correct SQL instance on a multi-instance cluster, and leaving some table information blank (http://support.microsoft.com/kb/942865/en-us). When deploying SP1 - Use the SP1 version of this tool. If you MUST deploy the RTM version - I would recommend using SetupOM.exe for all installs.
Ok.... first, you will notice in the OpsMgr Deployment guide, they instruct to use the DBcreateWizard when installing the database on an Active/Passive cluster. That's pretty much our first introduction to this tool. While this isn't required (you can simply run SetupOM.exe on the Active node) it is recommended to use DBCreateWizard. Essentially, our recommendation is that anytime you have a dedicated SQL server for the OpsDB role... with no other OpsMgr role present, then you should use the DBcreateWizard to create the Operational database. The reason for this, from an internal discussion I have been involved in.... is because using SetupOM.exe will create some additional registry entries on the database server... and will change how updates are applied to the server from an OpsMgr perspective. Another scenario to leverage this tool, is anytime your SQL DBA teams refuse to allow you to run a MSI based setup on their SQL servers/clusters.
Below, I will just walk through some of the scenarios where using this stand-alone tool really makes good sense.
Scenarios:
1. All in one role/shared roles. This is where a single server hosts SQL Server 2005 and the Operational Database role, along with the RMS role. In this case.... you might as well just run SetupOM.exe and create the database while installing the management group. You potentially could run the DBcreatewizard first.... but this would be an additional step and provides no value.
2. Split roles: Dedicated SQL server (Server A) and dedicated RMS (Server B). In this scenario - we recommend using DBcreatewizard.exe instead of just running SetupOM.exe on the SQL server. However - you certainly can do either one.... both are fully supported.
3. Split roles - clustered DB: Dedicated cluster for SQL (can be A/P or A/A or multi-instance or multi node.... doesn't matter) In this scenario - we recommend using DBcreatewizard.exe instead of just running SetupOM.exe on the SQL server. That said.... you can run SetupOM.exe on any node that owns the SQL instance you are creating the DB in.... we just favor using DBcreateWizard.
4. Draconian DBA's. In general.... DBA's are used to creating an empty database for an application, then granting permissions to the DB only.... then washing their hands of it. They don't like running setup's... or even running tools on their SQL servers.... If they must have an application create a database as part of that application install - they MUCH prefer that all the DB creation be handled remotely. Unfortunately.... MOM 2005 and OpsMgr 2007 do not support what DBA's would most like to see. We must run our setup or tool on the database server/node in order to install that component. I suppose we could install the OpsDB using the DBcreatewizard in a test lab SQL box, then detach it.... then hand the files to a SQL team and have them drop in into a production environment to make them happier.... but I haven't really done much testing there. Anyway.... the DBcreateWizard is the best option when working with a rigid DBA team. Just follow the KB article listed above... and have the SQL team run the tool to create the database.... then they can delete to tool from the server. We will still require SA priv over the instance to complete the RMS setup.... but once that is done, they can remove these advanced rights, per my previous post: http://blogs.technet.com/kevinholman/archive/2008/04/15/opsmgr-security-account-rights-mapping-what-accounts-need-what-privileges.aspx
5. Multiple Operational Databases in the same SQL instance. It is possible, if you have multiple management groups, that you could place all the Operational DB's into a single SQL instance. Now - these had better be small environments (test/dev) or a beefy SQL server to handle all that I/O.... but just for grins.... lets say you are doing it. If you tried to run SetupOM.exe and install the database component multiple times.... it would detect it was already installed and ask you if you wish to repair or remove OpsMgr. No good. In comes the DBcreateWizard. This tool is the supported method for creating multiple OpsDB's in a single SQL instance.