After addressing prerequisite requirements, the installation process goes through a standard System Center Operations Manager 2007 Setup Wizard. The first screen shown is a typical welcome to the wizard screen, which you move past by clicking Next.

The next screen displays the End-User License Agreement, which has to be accepted (check the I accept the terms in the license agreement option) and click Next to continue.

On the Product Registration screen, you need to enter the user name, organization, and 25-digit CD key, which is on the back of the CD case. (If your organization has a volume licensing agreement with Microsoft, this key is available on the Microsoft Volume License website.) Click Next to continue with the wizard.

The next screen is where you identify what OpsMgr components you will be installing. When installing the Operations database on a separate database server, this screen is where you choose only the Database Component and uncheck all the other components. Figure 6.4 shows the configuration to have the Database Component installed but none of the other components (displayed with a red X on them).

Figure 6.4. Custom Setup screen for the Operations database.

After you select the Database Component, the installation program automatically (re)runs the prerequisite checker to validate that the system has all required prerequisites installed. In our example, the checker passed with warnings due to the amount of memory available on the system selected for the Operations Database Server (shown in Figure 6.5). You can click on View Log to view information in the report.

Figure 6.5. Prerequisite check passed with warnings.

On the next screen of the wizard, you need to specify the management group name for your Operations Manager 2007 environment. This name is case-sensitive. The management group name should be unique (if you have existing Operations Manager 2007 or MOM 2005 environments) and easy to identify.

For our environment, we are using the management group name GROUP1, as shown in Figure 6.6. Note that once it’s specified, you cannot change the management group name without reinstalling the management group!

Figure 6.6. Management group configuration.

Next, identify the SQL Server database instance that the Operations database will run in. Because our environment is running SQL with a single (default) instance, the wizard defaults to the name of the server, as shown in Figure 6.7.

Figure 6.7. SQL Server instance.

If you are installing to a SQL server instance, the syntax would be the servernameinstance. For example, for our Thunder server having a named instance of Instance2, the syntax would be ThunderInstance2.

After we identify the instance into which the Operations database will install, the next configuration screen sets the database and log file options. As shown in Figure 6.8, this screen allows us to specify the name of the database, the database size, and the location of the data files (set on the Advanced tab).

Figure 6.8. Operations database and log file options.

The next screen of the wizard asks whether you want to send error reports to Microsoft. The default configuration on this is not checked, but you can check it and select one of the suboptions:

We have chosen the option to send error reports to Microsoft automatically, as shown in Figure 6.9.

Figure 6.9. Operations Manager Error Reports screen.

On the next screen, you specify if you want to use Microsoft Update to keep the system up to date with various security and other updates. If you do not currently have a method of providing patch management to the servers in your environment and you have configured your server to have access to the Internet, you should check the option to use Microsoft Update, as shown in Figure 6.10.

Figure 6.10. Microsoft Update specification and configuration.

After the Microsoft Update screen, the next screen indicates that Operations Manager is ready to install. Click Install to continue with the installation process. Once the installation is completed, the wizard finishes and displays the Completing the System Center Operations Manager 2007 Setup Wizard screen (see Figure 6.11.)

Figure 6.11. Wizard screen to finish the installation.

Closing this screen completes the installation of the Operations Database Component. If you want to validate that the installation was successful, you can use the Microsoft SQL Server Management Studio to validate that the Operations database was created correctly.

The OpsMgr Setup Wizard displays the startup screen; you will accept the license agreement and proceed to the product registration screen. After these screens, select the components you will install. These components are shown in Figure 6.13 and include all the components available (Management Server, User Interfaces, Command Shell, Web Console), except for the Database Component, which you have previously installed.

Figure 6.13. Custom installation for all components except for the Operations Database Component.

After you’ve chosen these components, the prerequisite checker runs. You then need to specify the database server, name, and port that contains the Operations database. For our environment, we are using the Thunder server with the OperationsManager database on port 1433. Enter the FQDN (Fully Qualified Domain Name) of the server to avoid any potential name resolution errors, as we show in Figure 6.14. OperationsManager is the default name for the Operational database.

Figure 6.14. Database server instance.

The next screen prompts you to identify a Management Server Action Account. As we discuss earlier in the “Security Accounts” section of this chapter, you should have already identified and configured each of these accounts prior to this step in the installation process. The account needs at least the following privileges:

We are using the OM_MSAA account in the Odyssey domain, as displayed in Figure 6.15.

Figure 6.15. Specifying the Management Server Action Account to use.

Next, we specify the SDK and Config Service Account, which we would also have previously identified. We are using the OM_SDK account, as shown in Figure 6.16. This account should have Local Administrator privileges. If your management group has the RMS and Operational database installed on the same server, you can also use Local System, although you may have issues during the Reporting Component setup.

Figure 6.16. Specifying the SDK and Config Service Account to use.

After the SDK account is configured, the next step is to specify the type of authentication to use for the Web console (shown in Figure 6.17). The options available are Windows Authentication and Forms Authentication.

Figure 6.17. Choosing the Web console authentication.

The next screen displayed is the option to join the Customer Experience Improvement Program, shown in Figure 6.18. If you choose to select this option, information about OpsMgr 2007 usage is collected and forwarded to Microsoft. If you do not choose the option, usage data is not sent to Microsoft.

Figure 6.18. Customer Experience Improvement Program.

Next, the Microsoft Update option is configured (which we discussed in the “Operations Database Server” section of the chapter), and installation is ready to begin. After the installation is complete, there is a default action to start the console, shown in Figure 6.19. The wizard also strongly recommends that you run the Secure Storage Backup tool to export the RMS key. (In SP 1, this happens automatically.)

Figure 6.19. Completing the Setup Wizard.

Refer to Chapter 12 for more information on how to use the Secure Storage Backup tool.

Log on as an OpsMgr administrator and open the Operations console.

Navigate to Administration -> Security -> Run As Profiles.

In the list of Run As Profiles, select the Data Warehouse account. Right-click and choose Properties; then select the Run As Accounts tab.

See if the new management server name is in the list. If it is not, click New.... In the Matching Computers list, click the name of the management server. Be sure the Run As Account specified is the Data Warehouse Action account.

This workaround was identified by Satya Vel, a Program Manager on the MOM team, and is written up at http://blogs.technet.com/momteam/archive/2007/08/29/if-you-install-opsmgr-2007-reporting-and-then-install-secondary-ms-then-it-will-not-be-able-to-write-dw-data-as-profiles-are-not-created.aspx

Choose the option to Install Operations Manager 2007 Reporting from the setup screen. The wizard displays the starting screen, the license agreement, product registration, and the custom setup screen. At Custom Setup, choose the Data Warehouse and Reporting Server Components, as displayed in Figure 6.21.

Figure 6.21. Custom installation for all reporting components.

The prerequisites for the components are checked, and you must specify the name of the Root Management Server. In our example, the Root Management Server is named Hydra.Odyssey.com (shown in Figure 6.22), which we fully qualify as we do when we installed the RMS component.

Figure 6.22. Connect to the Root Management Server.

At the next screen, specify the SQL Server database instance to connect to. For our case, we are connecting to the default database instance of Quicksilver, as displayed in the dropdown box in Figure 6.23.

Figure 6.23. Specify the Reporting SQL Server.

On the Database and Log File Options screen, we specify the name of the Reporting database, its size, and the locations for the data and log files (see Figure 6.24). The default name for the Data Warehouse database is OperationsManagerDW.

Figure 6.24. Data Warehouse database and log file options.

Now that we have determined which SQL Server Reporting Services Server to use and its configuration, we need to identify the instance to use, as shown in Figure 6.25. Note the warning in Figure 6.25 that Operations Manager role-based security will supersede (integrate) the security of the specified Reporting Services instance.

Figure 6.25. Specify the Reporting SQL Server instance.

On the next screen, we specify the Data Warehouse Write Account. This account will write to the data warehouse, as shown in Figure 6.26. The account should be a domain user account.

Figure 6.26. Data Warehouse Write Account.

The last account we specify is the Data Reader Account, as seen in Figure 6.27. This can be a domain user account.

Figure 6.27. Data Reader Account.

The final installation screens include the configuration for operational data reports, Microsoft Update (discussed in the “Operations Database Server” section), and then the installation is completed.

Install the ACS components by choosing the Install Audit Collection Server option from the setup screen. This installation needs to run on a management server, not on the server that will host the ACS database. When the installation process runs, the first screen is a Welcome to the Audit Collection Services Collector Setup Wizard screen. After the welcome screen, the license agreement screen displays, and then the database installation options start with the choice to either create a new database or use an existing database, as shown in Figure 6.28.

Figure 6.28. Database installation options.

The next screen specifies the data source name (DSN) to use to communicate with the ACS database. The default is OpsMgrAC, as shown in Figure 6.29.

Figure 6.29. Data source name for ACS.

The Database screen provides you with two options regarding the location of the database server:

The instance and database name are also specified on this screen, with the defaults for these two fields set to blank for the instance and OperationsManagerAC for the database name, respectively. For our example, we are installing to a remote database server named Fireball (identified using its Fully Qualified Domain Name) and will take the defaults for the instance and database name, as shown in Figure 6.30.

Figure 6.30. Connecting to a remote database server for ACS.

Next, we specify the type of database authentication to use. The two options available are Windows Authentication and SQL Authentication. We recommend using the Windows Authentication option unless the collector and database server are not in the same or trusting domains. Figure 6.31 shows the options available for authentication to the ACS database.

Figure 6.31. Database Authentication screen.

Next, specify where the ACS database and log file information will be stored on the SQL Server system. As a standard for increased database performance, the database and log files should be on different drives, and the drives should have sufficient space available. If the nondefault location is chosen (as we show in Figure 6.32), the directories need to be manually created.

Figure 6.32. Database Creation Options screen.

Now, we specify the event retention information, which defaults to performing daily maintenance at 2:00 a.m. and retaining data for 14 days, as we see in Figure 6.33.

Figure 6.33. Event Retention Schedule screen.

Two options are available for how the timestamp information will be stored in the ACS database: Local and Universal Coordinated Time (UTC). The Local option is the default and is recommended, unless there are multiple ACS databases or you are very familiar with UTC. We have chosen to go with the default setting, Local, as shown in Figure 6.34.

Figure 6.34. ACS Stored Timestamp Format screen.

The remaining screens show a summary of the configuration, connecting to the ACS database server to create the database, and displaying a screen to notify when the setup has finished. Start the Operations Manager Audit Collection service to verify that ACS is properly installed.

The first screen displayed is the Welcome to the System Center Operations Manager Gateway Setup Wizard screen. The next screen identifies where to install the gateway files, which defaults to the %ProgramFiles%System Center Operations Manager 2007 folder.

On the next screen, we specify the management group name, management server, and management server port number. We have configured these for our sample environment (GROUP1 as management group, Hydra.Odyssey.com as the management server, and 5723 as the default port), as shown in Figure 6.35.

Figure 6.35. Management Group Configuration screen for the gateway server.

Next, we need to identify what account to use for the Gateway Action Account. The options available are Local System and a domain or local account. This account needs the permissions to be able to install and uninstall agents and to manage the computers. For our example, shown in Figure 6.36, we are using the OM_GWAA account within the domain that the gateway is a member of.

Figure 6.36. Gateway Action Account screen.

The remainder of the installation includes the Microsoft Update screen, a summary screen, and a wizard completion screen.

Copy the Microsoft.EnterpriseManagement.GatewayApprovalTool from the SupportTools folder on the Operations Manager 2007 installation media to the %ProgramFiles%System Center Operations Manager 2007 folder.

After copying the program, open a command prompt (cmd.exe) to that folder and run the program with the required options.

The wizard starts with an introduction page, which introduces each of the steps that will occur, including CEIP (Client Experience Improvement Program) Forwarding, Error Collection, Error Forwarding, Create File Share, Task Status, and Client Settings.

On the CEIP Forwarding screen of the wizard, we configure the Customer Experience Improvement Program. You can configure how CEIP collects data in several ways:

If you select the second option, you can specify whether you want to use the Secure Sockets Layer (SSL) protocol, whether you use Windows Authentication, and the specific port number (which defaults to 51907), as shown in Figure 6.37.

Figure 6.37. Customer Experience Improvement Program screen.

On the Error Collection settings screen, specify the following:

In our example, we have created a file share path of D:AEM and have enabled all the Windows Vista configurations for the organization name of Odyssey, as shown in Figure 6.38.

Figure 6.38. Error collection settings.

Figure 6.39 shows the next step of the wizard, where you configure forwarding to send either basic or detailed information to Microsoft.

Figure 6.39. Error forwarding Settings.

Finally, we need to specify which account will provide the credentials required to create the share on the system. The default configuration is to use the Action Account (see Figure 6.40), but another account can be specified.

Figure 6.40. Create the file share and specify credentials.