The System Center Operations Manager Support Team Blog

This is the OpsMgr 2007 blog for the Microsoft support team. If you were looking for the SCOM 2007 or MOM 2005 blog then you are in the right place.

Service Level Dashboard 2.0 Installation Considerations and Guidance, Part 2

Service Level Dashboard 2.0 Installation Considerations and Guidance, Part 2

  • Comments 5
  • Likes

imageIn part 1 of this two-part series, I covered some of the more eluding points that are not addressed in the SLD guide, like where to host the SLD components, and accounts required for installation and configuration.

This is the second installment of the series, where I document my installation experience with plenty of screenshots.  Apart from this series, I’ve also posted a page talking about some common security related issues you might run into while implementing SLD.

Before getting started

Download the SLD installation package and associated documentation.  I always recommend reading official documentation before following any guidance on the community blogs and forums, and this is no exception, as many questions are usually answered there and resources like this only supplement the official guides.

Example server configuration

In this exercise, the server configuration is as follows:

Computername: UTILITY – This is an all-purpose database server I have in my lab.  It is a Windows 2008 Enterprise (x64) physical server with SP2, and SQL Server 2008 Enterprise (x64) with SP1 hosting multiple databases.

Computername: SRVWSS01 – This is a Windows Server 2003 Standard (x86) virtual server with SP2, which will be dedicated to hosting the WSS and SLD applications.  I happened to have this server spinning in my lab, so I used it because it was available and met the requirements for WSS.  The installation process should be similar (actually much easier) on Windows 2008.

Pre-installation tasks

Launch the Operations Console and import the Service Level Dashboard 2.0 management pack.  The management pack is found in the extracted SLD files.


In Active Directory Users and Computers, create two user accounts required for WSS and SLD installation and configuration.  These are regular user accounts and should be treated as service accounts.  Do not add to any security groups.  Name your accounts to whatever makes sense in your environment.


I logged on to SRVWSS01 with administrator account.  This is the computer where we’ll be installing the WSS and SLD applications.

imageNote: The account I’m using to do all installation and configuration actions is a member of the Administrators local group on all machines, is an Operations Manager Administrator, and has DBO access to the SQL Instance where the WSS and SLD databases will be created.  Although the Operations Manager Administrator role is not required in any of these steps, local administrator and DBO access to the SQL Instance is.  It is important to use a domain account when installing WSS and SLD, not a local account.

Install IIS and ASP.Net components.  Obviously this will be different in Windows 2008, in which you’ll add the IIS Role and check the appropriate components.



Install at least .Net Framework 3.5.  I installed .Net Framework 3.5 with SP1.


Ensure ASP.Net 2.0 is allowed in IIS.


If ASP.Net v2.0.50727 does not appear in IIS, you’ll need to register it first.


Install WSS 3.0

Install WSS 3.0 SP2 slipstream.  The slipstream version is required if installing in Windows 2008 R2.  Read more about Windows 2008 support here. You may need to launch the setup package in the command line with elevated privileges if installing on Windows 2008.


Select Advanced.


Select Web Front End (and your preferred data location if you wish), and click Install Now.


When installation finishes, run the configuration wizard.


When the wizard starts, click Next.


Then click Yes on the informational dialog.


Select “No, I want to create a new server farm”.


image Note: Since we are creating a new WSS site for SLD, we need to create a new server farm.  Adding servers to the farm can be done later to add redundancy, such as additional load-balanced Web servers.  The SLD documentation does not address a load-balanced scenario, so I am unsure at this time whether this is supported for the SLD application.

Next, specify the config database settings.  This is where we input the WSS Config Service account we created earlier in Active Directory.


Now specify the administration web application settings.  I chose to specify a static port, since I’m not a fan of anything random.  This makes it more conducive if there are any firewalls that need to be configured.

I also selected to use Kerberos.  Not because I want to complicate the installation, but because I know that Kerberos will be the authentication mechanism of choice within the Operations Manager community.  Keep in mind that there will be some extra steps later to complete the Kerberos configuration.


Selecting Kerberos will generate this dialog.  Click Yes to continue.


The final screen will display your configuration settings.  Click Next to install WSS with these settings and complete the wizard.  When the installation completes, click Finish.


This will launch Internet Explorer to the Central Administration site.


Before going any further, let’s first perform those additional tasks to complete the Kerberos configuration.  If you’re installing SLD, I’ll assume you know the basics of the SETSPN tool.  You could also create these SPN’s by using ADSIEdit.

Register SPN’s for both service accounts, WSS Config Service and WSS Content Pool Service.  The following screenshot demonstrates registering only for the WSS Config Service.


Install Service Level Dashboard

Copy the Service Level Dashboard MSI package to the WSS server.  Launch setup by running the MSI.  You may need to launch the MSI package from an elevated command prompt if installing on Windows 2008.  Since Windows 2008 and the induction of AUC, I’ve made a habit of doing this any time I do any installation tasks.  You should, too, since not doing so can get you into trouble with AUC blocking some processes and causing failures during installations and patching.

Be sure to run the correct MSI package for your server architecture!


On the “Operations Manager 2007 R2 Information” screen, enter the other WSS Content Pool service account we created earlier in Active Directory.  This will be used as the Application Pool Identity.  Also enter the Data Warehouse information.


Enter your information on the “Windows SharePoint Services 3.0 Information” screen.  For the Site Owner information, I chose to enter the same account I used to install WSS and SLD.

Then enter the database server name which hosts your WSS databases, and name the SLD database.

Finally, the URL should be auto-filled.  I chose to keep the default port.

image Note: Do not use the same port which is being used for the WSS administration site, otherwise SLD site creation will fail.


When installation completes, you can open Internet Explorer and navigate to http://[wss_server_name]:[port].  In my case, the URL is http://SRVWSS01:51918.


That’s it for installation.  If you have Windows Firewall enabled on your WSS server, don’t forget to add an exception for the SLD site port.

Configure SLD Users

The final step to installing SLD is configuring access to the SLD site.  If you read the SLD guide, you understand that SLD really only uses two types of accounts; Users and Administrators (aka, SLDV2.0 Visitors and SLDV2.0 Owners).  Most everyone will be a User.

I chose to create two groups in Active Directory, in the same OU that contains my other Operations Manager User Role security groups.  I named these groups SLD Users and SLD Admins.  Add domain accounts to these groups as needed for SLD access.  Association with Operations Manager User Roles is not required for SLD access, as we do not use the Operations Manager User Role SDK workflows to secure SLD.


Next, open Internet Explorer and navigate to the SLD site, and login with an account that is a member of the SLD Admins group.

image Note: The account used to install WSS and SLD earlier is automatically added to the SLDV2.0 Owners role in the SLD SharePoint site.

Navigate to Site Actions > Site Settings > People and Groups > Set Up Groups.

Add your domain groups to their respective roles here.  I removed the user account that was automatically added during installation, since that domain account is now added to the SLD Admins security group.


Test the site as a SLD User by signing in with an account that is a member of the SLD Users group.


First thing you’ll notice is there isn’t much to look at, and there is a message directing us to the Site Actions menu.  But as a SLD User, the Site Actions menu is hidden.


Sign into the SLD site again with an account that is a member of the SLD Admins group and navigate to Site Actions > Edit Page.  You’ll see something similar to this…


Oops.  Now I’m getting ahead of myself.  I already configured some Service Level Objectives in my environment, so I have one ready to go here.  You should see a blank dashboard.

For information about how to configure some basic Service Level Objectives for your dashboard views, see the SLD guide.

Jonathan Almquist | Microsoft Premier Field Engineer

Follow MSManageability on Twitter
  • Can I install the SCOM SLD on SharePoint Foundation 2010? Have you tested it? Is it supported?

  • Please is it possible to install the SLD on sharepoint 2010 server? Thanks.

  • After 3 weeks of agony, I found out that you must turn off the ws-management service to install this correctly on win 2k3 r2.

  • No you can't install on SharePoint 2010.....yet!

  • Shall i install all the components using single service account?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment