miércoles, 29 de agosto de 2012

Web analytics:: Where are the reports?


Web analytics is a great tool to get an insight of what´s going on in our farm at performance level . Sometimes when the customer asks me where to find a specific report after a while I find myself looking in every possible place where those reports are available and I waste some time looking for them. So here it goes, a collection of where to find the reports, it shouldn´t take me time to find them now!

Localization of the Reports:
Site collection/site > Site´s configuration > acciones del sitio >

    • informes de web analytics del sitio
    • Informes de web analytics of the Site  Collection
Central Administration > Search service application > Web analytics
Central Administration > Monitoring >  Reporting: Web Analytics : reports by web application
Central Administration > Monitoring > Reporting: View health reports:

    • Slowest pages
    • Top Active Users

This post (thanks!!) explains how to get the Slowest Pages report quering the DB:

If you need you can get top slowest pages directly from Usage and Health Data Collection database (WSS_UsageApplication by default) calling proc_GetSlowestPages stored procedure

declare @webApp uniqueidentifier
select @webApp = WebApplicationId from dbo.RequestUsage where ServerUrl = 'http://myWebApplicationUrl'

declare @stime datetime
declare @etime datetime
set @stime = getDate() - 10
set @etime = getDate()

exec dbo.proc_GetSlowestPages
@StartTime = @stime,
@EndTime = @etime,
@WebApplicationId = @WebApp,
@MachineName = null

 
In this great post you might find details regarding to each report: http://blogs.msdn.com/b/ecm/archive/2010/05/03/web-analytics-in-sharepoint-2010-insights-into-reports-and-metrics.aspx

miércoles, 22 de agosto de 2012

Troubleshooting tools, Part I: ULS viewer


This tool helps us administrators to troubleshoot issues in our SharePoint environments. You just select where your SharePoint logs are (the Usage and Health data collection service must be installed and configured) and you can see the logs in real time.

Where are the logs stored? The logs are stored into the DB of the service, standardly named WSS_loging. The tables are named dbo.ULStracelogs_partition X where X is a value between [0-31], in total 32 tables, a new table per each day.

The advantage and disadvantage is in the same place, the number of servers we might monitor at a certain point.

It´s an easy tool when speaking about an standalone installation or a small SP farm, if we have to monitor a medium to large farm we´ll have to open the tool in each of the servers and monitor at the same time, neither comfortable nor efficient.

 

Would you like to know more and get the tool?  http://archive.msdn.microsoft.com/ULSViewer

martes, 21 de agosto de 2012

Removing a server from the SharePoint farm


 

Something as easy as removing a server from a SharePoint farm has its considerations if we don´t want to end up suffering consequences.

In the central administration there´s an easy way of "removing a server" but it is not the correct path unless you don´t have other option.

The first thing is to plan, plan and plan. Some considerations that should receive our attention are:

1-Perform a farm backup. It´s an easy way to protect our farm and recover any service application in short time. Be careful if we´re using the User profile Service application.
2- Reorganize the services from the server/s that are going to be removed to the rest of the servers. Some questions that may help us to rearrange the services are:

Which kind of server do we want to remove? Frontend, application server or SQL?
Before removing the SQL server all the Databases must be moved to another SQL server into the farm.
Does any server you want to remove use any of these services?...

  • Hosts the central administration. Add this service to another server.
  • It´s a search topology component (query, crawl, administration); perform a full crawl in case you change the search topology. Review the logs afterwards.

Take it easy with the UPS and search service applications, both are critical and complex services to take care of.
  
Once all the services are running on the servers that will remain in the farm we might go for the second step.

1- Uninstall the server from the SharePoint Wizard. Using the wizard, the server will be disconnected from the farm, but before all the services and databases associated will be removed in a clean way.

What if the server doesn’t exist anymore or if we cannot uninstall from the SharePoint’s wizard or from control panel? Then we may use the option that appears in the central administration > Manage servers in the farm


In a nutshell even the easier things need our attention to succeed.