System Center Operations Manager 2007 R2 Service Level Dashboard Deployment Guide
Microsoft Corporation
Published: March 2011
Author
Matthew J. Goedtel
Feedback
Send suggestions and comments about this document to mgoedtel@microsoft.com. Please include the document name with your feedback.
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2008 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, and Active Directory are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.
Revision History
|
Release Date |
Changes |
|
April , 2011 |
Original release of this guide |
Contents
Manually Creating Windows SharePoint Services 3.0
Databases..................................... 10
Configure proxy server settings to bypass the proxy
server for local addresses.................. 18
Modifying DCOM Permissions for the IIS WAMREG Admin
Service.................................... 19
Scenario 1: Creating a Service Level Dashboard for a
Distributed Application..................... 28
In order to determine that a service level commitment is being met, IT and business users must be able to monitor service levels.
The Service Level Dashboard (SLD) meets the need of organizations to track service levels not only for an application, but also for an application as a service, a group, or a class of object. It identifies any shortfalls between service goals and actual performance, thereby enabling organizations to accurately measure and view, in near real time, Service Level Objectives (SLOs) for business-critical applications or groups of objects within Microsoft® System Center Operations Manager 2007 R2. This means that organizations are aware of problems as soon as they appear and can track their relative business impact. The Service Level Dashboard also helps IT to proactively fix problems in services before service levels are breached.
This document provides deployment guidance for installing and configuring the System Center Operations Manager 2007 R2 Service Level Dashboard, including guidance on installing and configuring Windows SharePoint Services 3.0 (WSS) within your environment. It is not intended to replace existing documentation released by Microsoft for the architecture planning and deployment of Windows SharePoint Services 3.0.
The Service Level Dashboard supports being deployed in several different configurations. It can be deployed onto an existing Windows SharePoint Services 3.0 standalone computer or a server farm, a new installation of Windows SharePoint Services 3.0 standalone computer or server farm, or a new or existing Office SharePoint Services 2007 farm. This document covers the deployment of a new Windows SharePoint Services 3.0 server farm topology dedicated for the Service Level Dashboard for customers who do not have experience with Windows SharePoint Services 3.0. The Server farm topology is the most flexible by providing you with the option to leverage SQL Server 2005, SQL Server 2008 or SQL Server 2008 R2 to host the WSS databases, and expand beyond one web front-end server to provide redundancy and load-balancing.
In addition, there are options to consider for the deployment of the WSS and SLD SQL databases, which are:
Windows SharePoint Services supports a standalone server or a server farm configuration. A standalone configuration is useful if you want to evaluate Windows SharePoint Services 3.0 features and capabilities, such as collaboration, document management, and search. The standalone configuration leverages the Windows Internal Database to host the WSS configuration and content databases. In a simple server farm topology, you can deploy in a server farm environment if you are hosting a large number of sites, if you want the best possible performance, or if you want the scalability of a multi-tier topology. A server farm consists of one or more servers dedicated to running the Windows SharePoint Services 3.0 application and utilizes SQL Server 2005, SQL Server 2008, SQL Server 2008 R2 to host the WSS configuration and content databases. There is no direct upgrade from a standalone installation to a server farm installation.
This document recommends implementing the server farm configuration as it allows you to easily expand the solution if performance and availability are important business or IT requirements.
Note:
This document does not provide guidance on configuring complex configuration scenarios such as installing additional web front-end servers to support load-balancing. For detailed guidance on deploying additional web front-end servers, please review the WSS 3.0 Deployment Guide, which you can download from http://go.microsoft.com/fwlink/?LinkID=79602.
Service Level Dashboard 2.0 integrates with the already functioning deployment of Operations Manager 2007 R2. It is assumed Operations Manager 2007 R2 and the Data Warehouse database are configured in accordance with Microsoft installation and configuration guidance.
The following table lists software requirements for the Service Level Dashboard:
|
Infrastructure |
Resource |
|
Software |
Operations Manager 2007 R2 with Reporting
and Data Warehouse Windows SharePoint Services 3.0 SP2
x64. Download link - http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9fb41e51-cb03-4b47-b89a-396786492cba&DisplayLang=en SQL Server 2008 R2. Note Typically, WSS and MOSS installations
install SQL Server Embedded Edition, which does not meet the Service Level
Dashboard requirement to create SLD content database. Microsoft .NET Framework 3.5 |
|
Browser |
Microsoft Internet Explorer 7.0 or greater |
Table 1 - Software Requirements
This information applies to Microsoft Windows Server 2008 and Windows Server 2008 R2, and SQL Server 2008 and SQL 2008 R2.
As of Windows SharePoint Services 3.0 with Service Pack 1 (SP1), you can now install Windows SharePoint Services 3.0 on Windows Server 2008. With the release of Windows SharePoint Services 3.0 with Service Pack 2 (SP2), you can now install on Windows Server 2008 x64 and Windows Server 2008 R2.
As with the Windows Server 2003 operating system, you must download and run Setup and the SharePoint Products and Technologies Configuration Wizard. You cannot install Windows SharePoint Services 3.0 without the appropriate service packs on Windows Server 2008 or Windows Server 2008 R2.
Important:
The following components are required for Windows SharePoint Services 3.0 to run correctly: the Web Server role, and the Microsoft .NET Framework 3.5 for Windows Server 2008, or .NET Framework 3.51 for Windows Server 2008 R2. Do not uninstall them, or Windows SharePoint Services 3.0 will cease to run.
Before you install and configure Windows SharePoint Services 3.0, you must install and configure Internet Information Services so your computer acts as a Web server.
Note:
The Add Role Wizard displays a dialog box indicating the following required
features must also be installed in support of the Web Server (IIS) role:
· Windows Process Activation Service
· Process Model
· Configuration APIs
· Static Content
· Default Document
· Directory Browsing
· HTTP Errors
· HTTP Redirection
Note:
The Add Role Wizard will display a dialog box indicating the following
required features must also be installed in support of the ASP.NET:
· Web Server Application Deployment:
· ISAPI Extensions
· ISAPI Filters
· .NET Extensibility
· Windows Product Activation Service
· .NET Environment
· IIS Metabase Compatibility
· IIS 6 WMI Compatibility
· IIS 6 Management Console
The SQL Server database collation must be configured for
case-insensitive, accent-sensitive, Kana-sensitive, and width-sensitive. This
is used to ensure file name uniqueness consistent with the Windows operating
system.
Only the database component of SQL Server is required in
support of this configuration.
In many IT environments, database creation and management are handled by the database administrator (DBA). Security and other policies might require the DBA to create the databases required by Windows SharePoint Services 3.0. For more information about manually creating the databases, including detailed procedures describing how the DBA can create these databases, see the section Deploy using DBA-Created Databases in the WSS 3.0 Deployment Guide.
The following table describes the accounts used to
configure SQL Server and to install Windows SharePoint Services 3.0.
|
Account |
Purpose |
Requirements |
|
SQL Server Service Account |
This account is used as the service account for the following SQL Server services: · MSSQLSERVER · SQLSERVERAGENT If you are not using the default instance, these
services will be shown as: · MSSQL$InstanceName · SQLAgent$InstanceName |
SQL Server prompts for this account during SQL Server Setup. You have two options: · Assign one of the built-in system accounts
(Local System, Network Service, or Local Service) to the logon for the
configurable SQL Server services. For more information about these accounts
and security considerations, refer to the Setting Up Windows Service Accounts topic (http://go.microsoft.com/fwlink/?LinkId=121664&clcid=0x409)
in the SQL Server documentation. · Assign a domain user account to the logon
for the service. However, if you use this option you must take the additional
steps required to configure Service Principal Names (SPNs) in Active
Directory in order to support Kerberos authentication, which SQL Server uses. |
|
Setup user account |
The Setup user account is used to run the following: · Setup on each server · The SharePoint Products and Technologies
Configuration Wizard · The PSConfig command-line tool · The Stsadm command-line tool |
· Domain user account · Member of the Administrators group on each
server on which Setup is run · SQL Server login on the computer running
SQL Server · Member of the following SQL Server security
roles: · securityadmin
fixed server role · dbcreator
fixed server role If you run Stsadm command-line tool commands that read from or write to a database, this account must be a member of the db_owner fixed database role for the database. |
|
Server farm account/Database access account |
The Server farm account is used to: · Act as the application pool identity for
the SharePoint Central Administration application pool. · Run the Windows SharePoint Services Timer
service. |
· Domain user account. Additional permissions are automatically granted for
this account on Web servers and application servers that are joined to a
server farm. This account is automatically added as a SQL Server
login on the computer running SQL Server and added to the following SQL
Server security roles: · dbcreator fixed server role · securityadmin fixed server role · db_owner fixed database role for all databases in the server farm |
|
Operations
Manager Service Level Dashboard Application Pool Identity |
The Service Level Dashboard installation sets this user
credential for the application pool in IIS.
|
·
Domain user
account Additional permissions are automatically granted for this account on the
Web servers that are joined to a server farm.
This account is automatically added as a SQL Server login on the
computer running SQL Server and added to the following SQL Server security
roles: ·
SLDReader role on the Operations Manager Data Warehouse database ·
db_owner fixed database role for the SLDSession and WSS_Content databases |
Table 2 - Required Security Accounts
Important:
This article discusses how to perform a clean installation of Windows SharePoint Services 3.0 in a server farm environment. It does not cover upgrading from previous releases of Windows SharePoint Services 3.0 or from previous releases of Windows SharePoint Services. For more information about upgrading from a previous release of Windows SharePoint Services, see Upgrading to Windows SharePoint Services 3.0 in the Windows SharePoint Services 3.0 Deployment Guide.
Note:
This article does not cover installing Windows SharePoint Services 3.0 on a single computer as a standalone installation.
After
Setup finishes, you can use the SharePoint Products and Technologies
Configuration Wizard to configure Windows SharePoint Services 3.0. The
configuration wizard automates several configuration tasks, including:
installing and configuring the configuration database, installing Windows
SharePoint Services 3.0 services, and creating the Central Administration
Web site. Use the following instructions to run the SharePoint Products and
Technologies Configuration Wizard.
Important:
This
account is the server farm account and is used to access your SharePoint
configuration database. It also acts as the application pool identity for the
SharePoint Central Administration application pool and it is the account under
which the Windows SharePoint Services Timer service runs. The SharePoint
Products and Technologies Configuration Wizard adds this account to the SQL
Server Logins, the SQL Server Database Creator server role, and the SQL Server
Security Administrators server role. The user account that you specify as the
service account must be a domain user account, but it does not need to be a
member of any specific security group on your Web servers or your back-end
database servers. We recommend that you follow the principle of least privilege
and specify a user account that is not a member of the Administrators group on
your Web servers or your back-end servers.
8. On the Configure SharePoint Central Administration Web Application page, select the Specify port number check box and type a port number if you want the SharePoint Central Administration Web application to use a specific port, or leave the Specify port number check box cleared if you do not care which port number the SharePoint Central Administration Web application uses.
9. On the Configure SharePoint Central Administration Web Application dialog box, do one of the following:
· If you want to use NTLM authentication (the default), click Next.
· If you want to use Kerberos authentication, click Negotiate (Kerberos), and then click Next.
Note:
In most cases, you should use the default setting (NTLM). Use Negotiate (Kerberos) only if Kerberos authentication is supported in your environment. Using the Negotiate (Kerberos) option requires you to configure a Service Principal Name (SPN) for the domain user account. To do this, you must be a member of the Domain Admins group. For more information, see the sections Register Service Principal Names (SPNs) and Configure trust for delegation for Web parts.
The
SharePoint Central Administration Web site home page opens.
Note:
If
you are prompted for your user name and password, you might need to add the
SharePoint Central Administration site to the list of trusted sites and
configure user authentication settings in Internet Explorer. Instructions for
configuring these settings are provided in the next set of steps.
Note:
If a
proxy server error message appears, you might need to configure your proxy
server settings so that local addresses bypass the proxy server. Instructions
for configuring this setting are provided later in this section.
After you create Web applications in your server farm, you must use Windows Firewall with Advanced Security in Windows Server 2008 to open ports on computers that host Web Applications.
By default, port 80 is open on Web servers, but to be able to communicate with other computers you must open the port for Central Administration. You must also open the ports for any additional Web applications that you create in your server farm.
The default configuration of the Windows Server 2008 firewall is to deny all connections unless there is an exception. Make sure you create the exceptions for the currently enabled profile (Private, Public, or Domain) when you are making changes to ports. If you create the exceptions in the wrong profile they will not work.
Note:
If you configure host headers in IIS, the ports for the Web Applications will be created on port 80 and you may not have to perform the procedures in this section. If, however, you use the host header mode in Windows SharePoint Services 3.0 to create multiple domain-named sites in a single Web application you will need to perform the procedures in this section to determine which ports the Web applications, including Central Administration, will use in your server farm.
Determine
ports used by Web Applications
|
1. Click Start, point to All Programs, point to Administrative Tools, and then click SharePoint 3.0 Central Administration. 2. On the Central Administration site, click Application Management. 3. On the Application Management Web page, in the SharePoint Web Application Management section, click Web application list. 4. On the Web Application List Web page, in the URL column, the server name with port number is listed for each Web application. |
You should use Windows Firewall with Advanced Security to open the ports required for your server farm as identified in the Determine ports used by Web Applications procedure.
For ease in managing the rules, we recommend that you create one rule per Web application. Alternatively, for more centralized rule management you can create one rule to manage all the ports.
For Web applications you only need to create a rule to open a port for incoming connections.
Configure
Windows Firewall with Advanced Security
|
1. Click Start, point to All Programs, point to Administrative Tools, and then click Windows Firewall with Advanced Security. 2. On the details pane, in the Overview section, verify that the domain profile is active by noting if the domain network location entry displays Domain Profile is Active. 3. In the Domain Profile is Active area, depending on how the inbound connections rule is configured, choose one of these options. · If it is Inbound connections that do not match a rule are allowed, then you do not need to complete this procedure. · If it is Inbound connections that do not match a rule are blocked, then you must proceed to the next step in this procedure to configure the firewall to allow Windows SharePoint Services 3.0 traffic. 4. On the console tree, select Inbound Rules, and then in the action pane click New Rule. 5. Complete the New Inbound Rule Wizard using the settings from the following table.
|
For more information about Windows Firewall with Advanced Security, see Windows Firewall (http://go.microsoft.com/fwlink/?LinkID=84639).
Because the application pool identity for Windows SharePoint Services is a domain user account, you must configure an SPN for that account. To configure an SPN for the domain user account, follow these steps:
Use the Setspn.exe tool to add an SPN for the domain account. To do this, follow these steps:
Note:
In this command, ServerName is the fully
qualified domain name (FQDN) of the server, Domain is the name of the domain,
and UserName is the name of the domain user account.
Note:
In this command, ServerName is the
NETBIOS name of the server, Domain is the name of the domain, and UserName is
the name of the domain user account.
To
configure the IIS server to be trusted for delegation, follow these steps:
If the application pool identity is configured to use a domain user account, the user account must be trusted for delegation before you can use Kerberos authentication. To configure the domain account to be trusted for delegation, follow these steps:
If Kerberos authentication is configured correctly, when you launch the SharePoint Central Administration Web and you are prompted for authentication, the web site should present the administration page successfully. Otherwise, open the Event Viewer and look in the System event log for an Event ID 4 from source Security-Kerberos to begin troubleshooting.
When running Windows Server 2008 R2, Event ID 10016 DCOM error 61738644-F196-11D0-9953-00C04FD919C1 related to the IIS-WAMREG Admin Service may be written in the Application Event Log. To correct this, please perform the following steps: