Monitoring Project Server and Windows SharePoint Services

Reliability, performance, and security are vital to any organization. A proactive approach to managing your infrastructure requires real-time monitoring. This section outlines several recommendations for monitoring Project Server, WSS, and their components and is intended to complement your existing monitoring processes. As any system administrator knows, the first step in resolving any problem is becoming aware that a problem exists. Waiting for your user base to report an issue is a reactive approach and can result in unnecessary and redundant calls to your help desk.

Windows 2003 Server Log File Monitoring

These days log management is an essential skill for any IT administrator or network security professional, and a Project Server administrator is no exception. It includes the monitoring, collection, consolidation, and analysis of log files and is a necessary and vital component to maintaining a healthy and secure system. With the vast amounts of log data being passed to a system, these activities can be a burden. Understanding where Project Server 2003 logs its information, warnings, and errors can help to reduce the effort and provide a valuable proactive troubleshooting tool.

Real-Time Monitoring

Real-time monitoring provides a proactive approach to diagnosing potential problems with Project Server 2003 and should be considered a cornerstone in any organization's network security plan. The presence of a strong event monitoring strategy provides a substantial advantage in identifying problems and potential threats early on instead of investigating them after the fact. Consider real-time monitoring to be a sort of "early warning" system.

The Microsoft Windows 2003 Server family provides an extensive mechanism for event log monitoring. If you've administered Windows Servers before, you are no doubt familiar with the Event Log Viewer built in to the operating system. To find this valuable tool, select Start, Run; type in eventvwr; and click OK. The Event Viewer window is launched, as shown in Figure 25.1.

Figure 25.1. Event Viewer filtered by Microsoft Project errors only.

Project Server 2003 events are stored in the application log and have a source of Microsoft Project Server Tracing Eventlog Provider. If your Project Server hosts many other applications, you may want to create a custom filter and key off of this source.

The application log is useful for tracking issues related to the access and publishing of projects and views in Project Server. If you start to notice high numbers of Error events, it is time to investigate further. Project Server error events almost always contain the following elements:

• Date and time

• Source Usually Microsoft Project Server

• Event ID

• User Most commonly reports NT AUTHORITY\LOCAL SERVICE

• Computer Typically the Project Server itself

• Description Contains the service or offending component name and descriptive error code

NOTE

Not all Project Serverrelated errors contain Microsoft Project Server as the source. Pay close attention to errors related to any of the related components listed at the beginning of this chapter.

The other important log to monitor for Project Server is the security log. This log contains the successful, and more importantly, the failed attempts to authenticate on the Project Server. Monitor this log carefully for potential illegal attempts to access your system.

TIP

Several third-party tools can monitor the event logs in Windows and alert you to potential problems real-time. Do a search online using the keywords "Event Log Management software" for suggestions and potential software solutions.

Internet Information Services (IIS) Log File Monitoring

Depending on your organization, you may have a web administrator who is already familiar with the IIS logging portion of this chapter. This section outlines some recommendations for monitoring and logging entries in IIS 6.0, as well as highlighting basic, normal Project Server type entries.

The Importance of IIS Logging

Keeping good IIS logging information is important primarily because it will assist you in tracking down potential problems as well as provide a detailed record of transactions for security and monitoring purposes. IIS logs can contain a lot of useful information for recognizing unauthorized entries into the Project Server including IP addresses, information accessed, logon information, and so on. In addition to the security benefits, these logs contain error entries and time stamps that assist in identifying performance problems and other potential project server issues.

Log File Formats and Locations

IIS provides the following formats for logging:

• National Center for Supercomputer Applications (NCSA) common log file format Log entries are typically smaller in size, which reduces the amount of disk space required.

• Microsoft Internet Information Services (IIS) log file format More detailed than NCSA format, and log files can become large. Performance on a busy server can be negatively impacted by lengthy entries.

• World Wide Web Consortium (W3C) extended log file format Same traits as the IIS format; however, it allows for customization of the fields being tracked. This is the default format for most IIS servers and the most recommended format.

• ODBC logging Allows writing to an ODBC-compatible database. Log files are compact, and data can be read much more quickly than a standard text-based log file. However, ODBC logging is processor intensive and requires tracking software capable of reading from the database.

• Centralized binary logging Used to combine logging information from multiple websites to a single log file. This format records the log with an .ibl extension. You need an application capable of reading this format. Tools available in the IIS 6.0 Resource Development Kit can read this format.

TIP

Microsoft provides a tool called CONVLOG.EXE that can convert log files from one format to another. It is located in the \%WinDir%\System32 directory.

Each website under IIS is assigned a logging folder based on the type of service. This folder name can be found by following these steps:

1.	Launch the IIS Manager from Administrative Tools, Internet Information Services (IIS) Manager.
2.	Expand the folder called Web Sites; then highlight a website instance such as Default WebSite and right-click on it.
3.	Choose Properties.
4.	Click the Web Site tab, and then click the Properties button.

You should see the Log file name listed toward the bottom of the window. The actual logs are stored in \%WinDir%\System32\Logfiles\[folder name].

Recommended Logging Options

For the most part, the default logging options are sufficient. You should add one extra field labeled "Time Taken (time-taken)," because this field can shed some light on slow response times through PWA. Follow the same steps you used previously to find the log folder name to modify the logging properties. Table 25.1 lists recommended settings.

Table 25.1. Logging Options

Field Type	Actual Field Name	Description
Client IP Address	c-jp	IP address of the client that accessed the server
Date	Date	Date on which the activity occurred
Method Used	cs-method	HTTP request method
Protocol Status	sc-status	HTTP status code, such as 404
Protocol Substatus	sc-status	HTTP substatus code, such as 2
Server IP	s-jp	IP address of the IIS server
Server Port	s-port	Port number to which client is connected
Time	Time	Time the activity occurred
Time Taken	time-taken	Time taken (in milliseconds) for the transaction to be completed
URI Query	cs-uri-query	Query parameters passed in request (if any)
URI Stem	cs-uri-stem	Requested resource
User Agent	cs(User-Agent)	Browser type and version used on the client
User Name	c-username	Name of an authenticated user (if available)
Win32 Status	sc-win32-status	Error status code from Windows

When troubleshooting, you may find other fields helpful, but be aware that writing longer log files decreases the overall response time of the server.

Typical Project Server Entries

The most common Project Server entries almost always look like the following:

[View full width]
 {Date}{Time}{Method}{Project Server URL}{Port}{DOMAIN\username}{referring IP address }{Browser and OS info}{Status or Error codes} 

For example:

[View full width]
 2005-01-01 00:37:14 192.168.5.150 POST /ProjectServer/logon/PDSRequest.asp - 80 domain .local\joeuser 192.168.1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+.NET+CLR+1.1 .4322) 200 0 0 

In the preceding example, IIS returned a status code of 200, which translates to "OK. The client request has succeeded." For a list of other IIS status codes, try referencing Microsoft Knowledge Base article 318380. As with most content on the web, a search may be necessary if the preceding article is unavailable.

Monitoring SQL Server 2000

This section outlines recommendations for monitoring usage, performance, database connections, and log files associated with SQL Server 2000 as it relates to Project Server 2003.

Establishing a Baseline

An important element to monitoring SQL Server is creating a baseline. Over time, performance will degrade, and without a solid baseline it is difficult to troubleshoot problems. Keep in mind four key areas when monitoring performance and creating baselines:

• System resources Physical capacity hardware

• Workload Volume of activity

• Throughput Amount of queries in a given time period

• Contention Resources competing for the same data

Project Server relies heavily on SQL Server performance, and most bottlenecks can be traced to one of the four key areas just mentioned. It is recommended that you use the built-in Windows performance monitoring (PERFMON.EXE) tool and the SmokeTest utility, freely available from Microsoft, to create your baseline. The SmokeTest utility tests the basic functionality of a Project Server 2003 installation, but it also has the capability to put a valid load on the system. The following list represents Microsoft's recommended counters for monitoring SQL using PERFMON.EXE:

• Memory Pages/sec

• Network Interface Bytes total/sec

• Processor Disk Transfers/sec

• SQLServer:Access Methods Full Scans/sec

• SQLServer:Buffer Manager Buffer Cache Hit Ratio

• SQLServer:Databases Log Growths

• SQLServer:Databases Application Database Percent Log Used

• SQLServer:Databases Application Database Transactions/sec

• SQLServer:General Statistics User Connections

• SQLServer:Latches Average Latch Wait Time

• SQLServer:Locks Average Wait Time

• SQLServer:Locks Locks Waits/sec

• SQLServer:Locks Number of Deadlocks/sec

• SQLServer:Memory Manager Memory Grants Pending

• SQLServer:User Settable Query

NOTE

A more detailed explanation on what each counter monitors and how to create a baseline chart can be found in the book Microsoft SQL Server 2000 Operations Guide published by the Microsoft Corporation, 2002.

Tracing Events Using SQL Profiler

SQL Server 2000 includes a powerful tracing tool called SQL Profiler. The SQL Profiler can monitor the server and databases providing an effective method of tracking activities and events associated with a SQL instance. This can be especially useful when trying to troubleshoot performance issues with Project Server. For example, you can monitor the activities of connected users allowing the ability to track concurrent usage and memory overhead.

Monitoring Connections to Project Server 2003

Using SQL Profiler, you can monitor connections to the Project Server 2003 database. To do this, launch the SQL Profiler from the Tools menu in Enterprise Manager and perform the following steps:

1.	Choose File, New, Trace.
2.	Type in your SQL server name and click OK.
3.	Give your trace a name and click the Events tab.
4.	Under the Selected Event Classes column, remove everything but the one labeled Sessions ExistingConnection.
5.	Click the Run button.

You see a results window like the one shown in Figure 25.2. Users with open Project Professional sessions will show up with an EventClass of ExistingConnection with the login name of the Project role defined during the installation. Two application-level user logins are created by default during installation: MSProjectServerUser and MSProjectUser. MSProjectServerUser is used by Project Server's web application to log on to the database (these connections are defined as a pool, so you may see several over time). Project Professional (the desktop client) uses the other application-level login (MSProjectUser). You can count the unique processIDs associated with MSProjectUser login entries to get an idea of concurrent connections to the Project Server database.

Figure 25.2. The results of this trace show one active connection (from Project Server) to the Project Server DB.

NOTE

The default usernames, MSProjectServerUser and MSProjectUser, can be modified during installation so that they may be different in your implementation. Check the security logins using Enterprise Manager to verify.

NOTE

Each active session of Project Professional shows up with multiple rows in Figure 25.2. Look at the ClientProcessID column to determine unique connections. Additionally, this type of trace only tells you the current connections when the trace was executed. It will not pick up any new connections that occur after the trace was started.

Analysis Services Monitoring

This section outlines recommendations for monitoring Analysis Services as it relates to Project Server 2003.

Enterprise and Standard Edition Differences

Just like SQL Server 2000, Analysis Services (AS) comes in a Standard and an Enterprise edition. Project Server uses both versions the same with the exception of implementations that include an extranet (outside your firewall) component. AS Standard transmits OLAP cube requests over port 2725, which is typically closed on the firewall. This issue results in an error, like the one shown in Figure 25.3, for computers accessing Portfolio Analyzer views from outside the firewall. For more information on extranet implementations, see the Project Server 2003 Installation Guide and the Project Server 2003 Configuration Planning Guide published by Microsoft.

Figure 25.3. This OLAP error can appear if permissions are applied incorrectly to the OLAP cube or if the wrong edition of AS is used.

The Enterprise edition allows for these transactions to use port 80 or port 443.

Monitoring Log Entries

From the monitoring standpoint, Analysis Services can be monitored from the event logs in Windows 2003 Server. Entries show up under the application logs in the Windows Event Viewer (EVENTVWR.EXE). Typical implementations of Project Server schedule a nightly build of the OLAP cube. By monitoring the event logs, you can actively alert and troubleshoot potential failed builds. The following is a log entry example of a failed cube build:

[View full width]
 Event Type:Error Event Source:    Microsoft Project Server Tracing Eventlog Provider Event Category:    None Event ID:    2 Date:        1/31/2005 Time:        4:52:19 PM User:        NT AUTHORITY\LOCAL SERVICE Computer:    PROJECTSERVER1 Description: Component: MSP Resource Availability Refresh and OLAP Cube Creation Component (ProjOLAP) File: PROJOLAPProcess Line: 1 Description: <Description><![CDATA[DSO.Server.Connect failed with error message 'Cannot  open connection to Analysis server 'PROJECTSERVER2'. Unable to connect to the Analysis server. The server name 'PROJECTSERVER2' was not found.  Please verify that the name you entered is correct, and then try again' Error Number :  '-2147221424]]></Description> 

PAGE 671.