Service Level Dashboard 2.0 Installation Considerations and Guidance, Part 2

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.

clip_image002

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.

clip_image004

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.

clip_image007

clip_image009

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

clip_image011

Ensure ASP.Net 2.0 is allowed in IIS.

clip_image013

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

clip_image015

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.

clip_image017

Select Advanced.

clip_image019

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

clip_image021

When installation finishes, run the configuration wizard.

clip_image023

When the wizard starts, click Next.

clip_image025

Then click Yes on the informational dialog.

clip_image027

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

clip_image029

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.

clip_image032

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.

clip_image034

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

clip_image036

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.

clip_image038

This will launch Internet Explorer to the Central Administration site.

clip_image040

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.

clip_image042

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!

clip_image043

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.

clip_image044

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.

clip_image047

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

clip_image048

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.

clip_image049

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.

clip_image052

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

clip_image054

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.

clip_image055

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…

clip_image057

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