If you want to monitor your environment there are a number of applications out there and even managed services. Typically these solutions monitor one type of object very well, either Windows servers, or network objects or printers. They then provide some level of monitoring and reporting against the other areas. From the R2 version of SCOM cross platform support has been released and with its ability to allow you to create your own monitors, probes and rules means that with a little effort you can have a monitoring solution which is capable of not only monitoring your enterprise solutions including hardware and network topology but will also provide a company knowledge repository, manufacturer recommended solutions for well known issues and the possibility to provide self-healing for identified issues.

Installation of SCOM is a fairly simple process which I have detailed below. As I will be deploying in a lab environment I have had to limit the amount of servers so I have a Domain Controller (called DC) which also hosts SQL 2008 SP2. The SQL Server has the SQL Broker Service set to Automatic and started. Check that the Service Principal Name has been registered for the SQL Service Account. To do this use the setspn utility – in my lab I am running Windows 2003 R2 as a domain controller and so need to install the support tools from the installation CD. Running the command

Setspn –L ServiceAccountName

gives the results below.

To register the Service Principal Name use the setspn utility and follow the guide at http://technet.microsoft.com/en-us/library/ms191153.aspx. In my case by entering the commands below.

The –L switch can then be used to check the SPN for the SQL service account.

SCOM itself will be installed on a server called SCOM. Whilst SCOM can be installed in a distributed fashion this guide will use a single SCOM server to demonstrate the installation process.

To install SCOM 2007 R2 without any reporting functionality (this will be covered in a later post) then we need to configure 2 service accounts and 1 security group.

 

At some point we will need various action accounts to perform actions on the end points, not least an account with Administrative privileges on the client systems to enable deployment of the agent. The security group is granted the “Operations Manager Administrators” built in role group to provide unrestricted access to SCOM for users in those groups (other users should be added to more restrictive role groups after installation). For now we need to initially set up the above accounts and group. Unless you are in a high security environment the domain accounts should be configured with “password never expires”.

Here, I have added the domain administrator to the SCOMAdmins Group. This is a Global Security group. The group and the two accounts are granted local administrator rights on the SCOM server.

When we install SCOM it will want to register SON’s for the SDK and Config service account. We can either add these by hand or prepare the account in Active Directory so that it has the rights to register SPN’s for itself. To do this log on to the DC and start the ADSIEdit tool (adsiedit.msc).

From the tool navigate through the domain entry point and the OU to where the service account was created.

Right click the service account and select Properties.

Click on the Security Tab and then the Advanced Button.

Click on the Add Button and add the SELF account

Click on the Properties tab

Change “Apply Onto” to read “This Object Only” and select to allow SELF to read and write the SPN.

Click on OK three times to close the interface and apply the new permissions.

The pieces are now in place on our other servers to install SCOM. However, there are some pre-requisites to install SCOM. On a single server these are:

• Windows Server 2003 Service Pack 1
  
• World Wide Web Service is running and set for automatic startup
  
• WS-MAN v1.1, available at:http://go.microsoft.com/fwlink/?LinkId=133219
  
• .NET Framework 2.0, available at: http://go.microsoft.com/fwlink/?LinkId=64221
  
• .NET Framework 3.0 components, available at: http://go.microsoft.com/fwlink/?LinkId=71270
  
• Windows PowerShell, available at: http://go.microsoft.com/fwlink/?LinkID=156058
  

Links to Optional Prerequisites

The SCOM pre-requisite checker will check for the presence of the above and provide advice and links to install the software if it finds it missing. The prerequisite does not alert of the following items are missing and these will need to be installed by hand if this functionality is required..

• For creating and editing product or company knowledge in management packs you must install Microsoft Office Word 2003 with the .NET Programmability feature and Microsoft Visual Studio 2005 Tools for the Microsoft Office System, available at: http://go.microsoft.com/fwlink/?LinkId=53267
  
• If you will install agents manually, you must install MSXML 6.0, available at http://go.microsoft.com/fwlink/?LinkId=76343 MSXML 6.0 requires Windows Installer 3.1, available at: http://go.microsoft.com/fwlink/?LinkId=77051
  

To run the prerequisite checker insert the installation disc in the server and, if it does not automatically start, double click on SetupOM.exe in the root of the disc.

Click on the Check Prerequisites link in the interface.

Select only those components that will be installed on the particular server. Here, we are installing SCOM (Server), the console and powershell on the server. The Web Console and Reporting will be installed under later guides. The Operational Database will be installed on our separate SQL server. When you have made the appropriate selections click on “Check”.

In my lab my SCOM server is running Windows 2008 R2 and without installing any of the prerequisites the utility returns the results below.

To understand how to resolve the failure click on the “More” button to the right of the errant item. The utility will provide advice on how to proceed.

Once the advice has been followed simply return to the utility and click on “Check” once again to confirm the appropriate prerequisites are available.

The above checks the prerequisites on the SCOM server. The same procedure should be followed on the SQL server but this time selecting to check the Operational Database (I receive warnings due to the limitations in size of my lab environment – these warnings can be safely ignored in this case).

Now that we have the appropriate service accounts, groups and permissions configured and the prerequisites have been provisioned we can now begin the installation.

First we deploy the database, then the server and console and configure our Management Group. To deploy the database insert the installation disc in the SQL server as before but this time select “Install Operations Manager 2007 R2”.

Once the installation interface starts click on “Next”.

Accept the license agreement and click on “Next”.

Enter your registration information and click on “Next”.

Set all but the “Database” item to “This component will not be available”.

Set the database component to “This component, and all dependant components, will be installed on local hard disk”. Change the binary install location if required. Click on “Next”.

The results of the prerequisite check will be displayed. Click on “Next”.

Enter the name for the management group. This will refer to the boundary of the management group and may be a company name, a physical location, a department or some other item that indicates the coverage for the management group. Click on “Browse” and change the group selected to our “SCOMAdmins” domain global group previously configured so that it is added to the SCOM built in “Operations Manager Administrators” group. Click on “Next”.

Confirm that the database will be configured on the correct SQL server and will use the correct port. In our case this is the default port of 1433. Click on “Next”.

On the next screen we accept the default name for the Operations Manager database. As this is only a lab environment we have not changed the size of the database. By default SCOM databases are not set to auto-grow and so you may need to change this value for a production environment. From a performance perspective it is recommended that the database be kept as small as possible and, in general, should not grow above around 20GB. In a production environment the database and logs should be placed on separate drives according to best practice. This can be done by clicking on the “Advanced” button. Once the appropriate options have been selected click on “Next”.

Decide whether you want to help improve the product for everyone and click on “Next”.

Decide whether to use Microsoft Update and click on “Next”.

Finally, click on Install to deploy the database.

Once the installation has completed click on the “Finish” button.

Check using SQL Server Management Studio that the database has been created.

Now that the database has been created we can proceed to install the server and console components on our SCOM server. To do this, log on to the SCOM server with an account that is a member of the SCOMAdmins global group previously created and insert the installation disc. Click on “install Operation Manager 2007 R2” and click on “Next” at the welcome screen. As before, accept the license agreement and enter the Product Registration information. This time, mark the “Database” and “Web Console” nodes as “This component will not be available” and mark the “Management Server”, “User Interfaces” and “Command Shell” as “This component, and all dependant components, will be installed on local hard disk”. Change the binary install location if required. Click on “Next”.

Enter the name of the SQL server and instance. As we deployed to the default instance of SQL we only need to enter the name of the SQL server. Click on “Next”.

Enter the name of the Management Server Action Account and its associated password. Click on “Next”.

Enter the details of the SDK and Config account set up earlier and click on “Next”.

Decide whether or not to join the customer experience program and click on “Next”.

Decide if you want to use Windows Updates and click on “Next”.

Click on “Install” and wait while the software installs.

Note that you have the choice to backup the encryption key and start the console. Clear the “Start the console” check box and click on “Finish”.

The encryption key is used the encrypt / decrypt the “Run as Accounts” user names and passwords. If the server suffers a failure then this encryption key will need to be restored to any replacement server if it is to be able to access this information. At the introduction screen click on “Next”.

Select to backup the encryption key and click on “Next”.

Provide a location and name to use to store the encryption key and click on “Next”.

Provide a password for the encryption key and click on “Next”.

Click on “Finish” to complete the backup of the encryption key.

SCOM has now been installed. To check for a successful installation check the spn of the SDK and config account to ensure that the appropriate SPN’s haven been registered.

Check the OperationsManager database on the SQL server and ensure that the accounts created have been granted permissions to the database.

Check the setup log (in the temp directory of the logged on user) for any errors.

Check the Operations Manager Event Log in Event Viewer for any issues.

Start the Operations Console (Start | All Programs | Systems Centre Operations Manager 2007 R2 | Operations Console). Click on Windows Computers and check that the Root Management Server (SCOM) is showing a healthy state (green tick mark).

You now have deployed a working SCOM 2007 R2 server. It simply remains to deploy management packs, optimise them for your environment, configure security to the SCOM server, deploy agents, deploy and reporting services requirements and plan and deploy a backup solution.