In 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.
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.
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.
Note: If installing on Windows 2008, just add the Web Server role (IIS) and add the ASP.Net role service.
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.
Note: In IIS7, you check whether ASP.NET is allowed under ISAPI and CGI Restrictions.
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 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”.
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.
Do not use the same port which is being used for the WSS administration site, otherwise SLD site creation will fail.
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.
|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.
Click on Groups in the left nav pane.
Click Setup Groups for this Site link.
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.