SharePoint 2010 has been architected to be a proactive system that provides many tools to the administrators. The goal is to catch issues before they occur. If they do occur, the system should give the administrator the capability to debug the issues with the least amount of resistance.
One example of this is the new logging database. It collects information from disparate servers and collates this information into the database. For instance, the Unified Logging Service (ULS) logs collect information that is useful in troubleshooting issues. These logs are found on every SharePoint Server. These ULS logs are collected from all servers and the event logs. This makes the logging database a valuable tool. It is must-have knowledge for SharePoint administrators and covered in one of the recipes.
Reporting is another area where SharePoint 2010 has been given focus. Reports are more robust and present better information down at the site level. This gives administrators a better idea...
The SharePoint 2010 logging database covered in the previous recipe captures information that can be modified via the Central Administration interface. The advantage of this being that the collection of information can be voluminous, which can also be the disadvantage.
Disk space, I/O, and just the amount of data needed to retain this information can become an issue. Being able to reduce the type of information that gets captured is critical to the wellness of your farm.
In this recipe, we will cover how to change what gets captured and put into the logging database.
You must have farm-level administrative permissions to the Central Administration site.
SharePoint 2010 has a built-in health analyzer that acts as a best practice analyzer. The health analyzer will report whether or not the farm is compliant with each predefined health rule. The health analyzer builds upon the best practice analyzer from Microsoft Office SharePoint Server 2007.
There are roughly 65 rules that are categorized as follows:
Security
Performance
Configuration
Availability
Each rule is run by a timer job, and each rule has a specific purpose such as checking application pool memory, checking how security is configured on the farm, or checking drive space.
In Central Administration, it is possible to edit existing rules in order to meet the needs of your organization. Changes can be made to the scheduled execution of the job. On the ribbon, there is an option named Run Now that will execute the rule immediately. The rules are available out of the box and are meant to allow you to be proactive.
In this recipe, we will modify...
Web analytics reports are an innate part of the SharePoint 2010 installation. These reports are prebuilt. They use collected data from the active SharePoint installation to present information such as number of site collections, top destinations, top pages, page views, and top referrers. Using this information, an administrator can determine the flow of traffic. This is information that will comprise part of the story for performance monitoring.
This recipe shows how to invoke the reports and how to view custom reports.
You must have farm-level administrative permissions to the Central Administration site.
1. Open up the SharePoint 2010 Central Administration website.
2. Click Monitoring.
3. Under the Reporting section, click View Web Analytics reports.
4. Choose a web application by clicking on it.
5. The page that is presented contains a left-hand navigation, as shown here:
Click any of the above options and you will be presented with...
An undesirable thing for users of SharePoint is getting an indefinite message that has a big red "X" and the word "Error" in bold adjacent to it. The user has done something but the page does not tell what the error is and how to fix this error. It only points them to the site administrator, that is, you.
SharePoint 2010 has addressed this issue by creating a mechanism to track communications between the web front-ends and the user's requests. This is in the form of a GUID called the correlation ID. Now when a user gets his/her error page, he/she can contact the administrator and provide the correlation ID. The administrator can then track the cause of this error using the correlation ID as a reference in the ULS logs.
This recipe shows the steps to perform after the correlation ID is provided to the administrator. To induce the error with a correlation ID, we will stop the web analytics service.
The Developer Dashboard is not just for developers who write code. It is an important tool in the arsenal of the SharePoint Administrator.
Tools such as Microsoft's Visual Round Trip Analyzer are used to determine why a page is performing poorly. The downside of tools such as this is that they interrogate the page from the outside and so information such as database queries cannot be seen. We would have to use another tool such as SQL Profiler to see this information.
The Developer Dashboard brings this functionality natively to SharePoint 2010. It provides information, such as how a page is built, how it is performing, what database queries are being run and for how long, at the bottom of a page in report form. Administrators can use this information to pinpoint what is happening on a page.
In this recipe, we will enable the Developer Dashboard and view the report at the bottom of the page. This is done through PowerShell and can be scripted in the SharePoint...
© 2011 Packt Publishing Limited All Rights ReservedAuthor (1)
