Analysis of SharePoint 2007 Usage Reporting Capabilities

An element of site usage reporting is included as part of the ‘out of the box’ capabilities of SharePoint 2007. After usage reporting is enabled by your site administrator, you can append ‘_layouts/usagedetails.aspx’ onto any SharePoint site to get access to site usage data, provided you have the appropriate level of permissions.
For example: http:///_layouts/usagedetails.aspx

According to Microsoft, Site administrators and site collection administrators can view site usage summary pages that have the following information for their sites and site collections:

• Requests and queries in the last day and the last 30 days.
• Average number of requests per day over the last 30 days.
• A chart of requests per day over the last 30 days.
• A list of the top page requests over the last 30 days.
• A list of top users over the last 30 days.
• A chart of top referring hosts over the last 30 days.
• A chart of top referring pages over the last 30 days.
• A list of top destination pages over the last 30 days.
• Top queries for the last 30 days (if search usage reporting is enabled).
• Search results top destination pages (if search usage reporting is enabled).

SSP administrators for the search service can view a search usage reports page that tracks the following information.

• Number of queries per day over the previous 30 days.
• Number of queries per month over the previous 12 months.
• Top queries over the previous 30 days.
• Top site collections originating queries over the previous 30 days.
• Queries per search scope over the previous 30 days.

Site collection administrators for the SSP site can view a usage summary page that tracks the following information:

• Total amount of storage used by the site collection.
• Percent of storage space used by Web Discussions.
• Maximum storage space allowed.
• Number of users for all sites in the hierarchy.
• Total hits and recent bandwidth usage across all sites.

Site collection administrators can also view a site usage report that includes monthly and daily page hit totals filtered by the following criteria:

• Page
• User
• Operating system
• Browser
• Referrer URL

Usage Reporting from SharePoint Designer 2007

SharePoint Designer 2007 extends the functionality available in SharePoint, enabling you to measure site performance and usage using the following OOTB reports:

• Site summary report
• Broken links reports
• Reports about files
• Reports about shared content
• Reports about problems
• View the Usage Summary report
• View details usage reports
• Chart your usage data results

Most reports can be customised with the addition of sorting and filtering, copied and saved as an external file, such as Microsoft Excel.

For further information read ‘Use reports to measure site performance and usage’:
http://office.microsoft.com/en-us/sharepointdesigner/ha101741361033.aspx

Third Party alternatives to the SharePoint 2007 Usage Reporting Solutions

• MAPIlab provides a tool that delivers richer stats:
http://www.mapilab.com/sharepoint/statistics/

• Nintex Reporting provides richer reporting on usage:
http://www.nintex.com/Nproducts/Reporting.aspx

• Quest Capacity Management reporting tool has some interesting reports, including growth and trending reports:
http://www.quest.com/capacity-manager-for-sharepoint/

• CardioLog Usage Reports for SharePoint
http://www.intlock.com

• AvePoint DocAve for SharePoint 2007
http://uk.avepoint.com/sharepoint-products/

• Google analytics can be used by SharePoint sites and it’s free. CWaC are trialling this:
http://www.google.com/analytics/

Broken links Scan

Scan broken links functionality in MOSS 2007 can only scan the broken links for sites created under the site directory. SharePoint Designer has a Broken Links report, but it’s poor and includes an awful lot of system files that you probably don’t want to know about.

A good alternative is Xenu’s Link Slueth and it’s available for free download too, from: http://home.snafu.de/tilman/xenulink.html

Adding a custom style sheets to InfoPath form designs

InfoPath view .xsl files contain three or four standard internal style sheets, depending on whether you have specified a color scheme. These can be identified by the attributes controlStyle=’controlStyle’, tableEditor=””TableStyleRulesID””, languageStyle=’languageStyle’, and themeStyle=’urn:office.microsoft.com:themeBlue’. Never modify any of these standard internal style sheets. InfoPath often regenerates these, which will cause you to lose any changes you make to them.
You can add your own custom internal or external style sheet to any or all of the view .xsl files in your form template. The best place to add it is after the InfoPath standard style sheets because styles have reverse order precedence, meaning the last value for an identical selector property wins. If both you and InfoPath have specified a value for the border property of the table selector, whichever one appears last will override the value for the same selector property of any preceding style sheet.
You might use HTML and class selectors when writing your own styles. ID selectors will not be useful because InfoPath will not allow you to place an ID attribute on an element in the XSL. This is because InfoPath autogenerates ID attributes when it creates the view.

div {…}
.myClass {…}
#myId {…}

INTERNAL STYLE SHEETS
Internal style sheets are stored directly in the view .xsl file, just as the InfoPath standard style sheets are. If you want to use the same styles across multiple views you will need to copy the styles from one view .xsl file to another. Let’s review the steps to add an internal style sheet.

Add a custom internal style sheet:Choose Extract Form Files from the File menu.Select a location to save your extracted form files to, and then click OK.Close InfoPath to release the lock it places on your form files.Using a text editor, open your view .xsl file.Add the following code just below the last style element:

    table { FONT-FAMILY: Courier New; BORDER: solid 1px black; }
Save your view .xsl file, and then close the text editor.Reopen your form template by right-clicking the manifest.xsf file and choosing Design.
Your custom styles should now be visible in the designer. Internal styles must be updated per view .xsl file, which can create inconsistencies if you forget to update one of the .xsl files. If you want to use the same styles across multiple views, you should consider using external style sheets instead. You can always override external styles for a particular view by using a combination of external and internal style sheets.

EXTERNAL STYLE SHEETS
External style sheets exist in separate .css files. They must be added to the form template as resource files as well as referenced in any view .xsl file that will use them. By using external style sheets you maintain a consistent set of styles across all of the views that reference them. Let’s review the steps to add a custom external style sheet named myCustomStyleSheet.css.
Add a custom external style sheet as a resource file:Choose Resource Files from the Tools menu.In the Resource Files dialog box, click Add.In the Add File dialog box, navigate to and select the myCustomStyleSheet.css file, and then click OK. Figure 1 shows the file added as a resource.Click OK to close the Resource Files dialog box.

Figure 1. The myCustomStyle.css file has been added as a resource file.
Link to a custom external style sheet from your view .xsl file:Choose Extract Form Files from the File menu.Select a location to save your extracted form files to, and then click OK.Close InfoPath to release the lock it places on your form files.Using a text editor, open your view .xsl file.Add the following code just below the last style element:

Save your view .xsl file, and then close the text editor.Reopen your form template by right-clicking the manifest.xsf file and choosing Design.
Your custom styles should now be visible in the designer. If you added the link element to the view .xsl file before you added the .css file as a resource, or if you later update the resource file, your updates will not be visible in the designer until you save and reopen your form template. They will, however, be visible in the form preview before you save and reopen your form template.
As long as your internal and external style sheets appear last you should not have any trouble with InfoPath overriding any of your values. However, if a scenario is encountered where a value in one of the InfoPath standard style sheets is still causing you trouble by overriding your value, add the !important declaration to yours. This will force your value to always be chosen.

table { FONT-FAMILY: Wingdings !important; }
Finally, it should be noted that inline styles are normally chosen over internal or external styles because they appear last. The !important declaration on an internal or external style will override a value on an inline style unless the inline style also uses the declaration. In other words, the !important declaration also follows the reverse order precedence.