Last week I installed hotfix 941653 and hotfix 950292 (post SP1) to a client site to fix the dreaded Error: 'length' is null or not an object that occurs with Office 2003 Standard edition and MOSS Content Types. Unfortunately, not only did the problem remain (i.e. the hotfix fixed nothing), but I started to get 403 (Forbidden) errors when I tried to navigate to Search Settings page.
To fix this problem, I had to do the following:
From the index server (I've got a front-end web server and a backend index server, both 64 bit):
stsadm -o search -action stop -f
then I did
stsadm -o search -action start -role indexquery
then I did a:
stsadm -o execadmsvcjobs
Then I went back to the front end web server, navigated to the Shared Services Admin page, selected the SSP site, then from its context menu selected 'Edit Properties'. Then from the screen I reselected what the Index server was. After this, on the front end server I did a stsadm -o execadmsvcjobs. Then search started working again (but as the index was blown away, I had to do a full reindex).
Monday, April 28, 2008
Friday, April 04, 2008
Fiddler2 and Pipeboost are your friend!
To my surprise this week, one of the sites that I am helping with went live (deployed by the customer). One of the comments from the customer was 'it is quite slow'. Well to help identify what was going on, I brought out my trusty friends - Fiddler2 and Pipeboost.
Fiddler2
Basically, Fiddler is an IE add-on that monitors what comes down the wire to the browser whenever you request a page. In includes all the details about what types of files are downloaded (jpg, swf, css, js etc) and how long it takes. It even provides a pie chart to show what file types are causing the biggest payload. My first test on the site was with all of my cache cleared (so that I measure the performance of the first time visitor to the site). Yes it was definitely slow. My second request was done without clearing the cache. In this report however, it showed that although the flash files were being cached, All of the images stored in the SiteCollectionImages library were not.
So Fiddler helped me to identify that the BlobCache had not been configured on the server. This is a setting in the Web.Config file. It helps IIS to store images that are stored in SharePoint (and therefore in the backend database) to the local file system. Thus making subsequent requests for those resources a whole lot quicker (because a SharePoint database request is not required). The syntax for BlobCache is as follows:
Pipeboost (www.pipeboost.com)
Pipeboost helped me to identify whether or not IIS Compression had been configured on the production server. As most of you would know, browsers such as IE can handle compression. There is a handshake that goes on between the server and the browser to see whether the browser supports compression. If it does, then IIS compresses the contents (thus reducing the payload) and sends it to the browser, where it is decompressed and displayed to the user. There are two types of content that can be compressed - Static (like images) and Dynamic (like ASPX pages). Static compressioncan compress the file as well as stores it in the Temporary Internet Files directory, so that it can be served up quicker next time. Dynamic waits for the ASPX to return its content, then it just sends that page compressed back to the browser (i.e. it doesn't store it in the Temporary Internet Files location).
There is a great article at http://www.dotnetjunkies.com/Article/16267D49-4C6E-4063-AB12-853761D31E66.dcik that explains how to setup IIS Compression. At the end of this article, it talks about Pipeboost, which can tell you whether or not the payload returned from the web server is compressed (i.e. via IIS Compression).
Fiddler2
Basically, Fiddler is an IE add-on that monitors what comes down the wire to the browser whenever you request a page. In includes all the details about what types of files are downloaded (jpg, swf, css, js etc) and how long it takes. It even provides a pie chart to show what file types are causing the biggest payload. My first test on the site was with all of my cache cleared (so that I measure the performance of the first time visitor to the site). Yes it was definitely slow. My second request was done without clearing the cache. In this report however, it showed that although the flash files were being cached, All of the images stored in the SiteCollectionImages library were not.
So Fiddler helped me to identify that the BlobCache had not been configured on the server. This is a setting in the Web.Config file. It helps IIS to store images that are stored in SharePoint (and therefore in the backend database) to the local file system. Thus making subsequent requests for those resources a whole lot quicker (because a SharePoint database request is not required). The syntax for BlobCache is as follows:
Pipeboost (www.pipeboost.com)
Pipeboost helped me to identify whether or not IIS Compression had been configured on the production server. As most of you would know, browsers such as IE can handle compression. There is a handshake that goes on between the server and the browser to see whether the browser supports compression. If it does, then IIS compresses the contents (thus reducing the payload) and sends it to the browser, where it is decompressed and displayed to the user. There are two types of content that can be compressed - Static (like images) and Dynamic (like ASPX pages). Static compressioncan compress the file as well as stores it in the Temporary Internet Files directory, so that it can be served up quicker next time. Dynamic waits for the ASPX to return its content, then it just sends that page compressed back to the browser (i.e. it doesn't store it in the Temporary Internet Files location).
There is a great article at http://www.dotnetjunkies.com/Article/16267D49-4C6E-4063-AB12-853761D31E66.dcik that explains how to setup IIS Compression. At the end of this article, it talks about Pipeboost, which can tell you whether or not the payload returned from the web server is compressed (i.e. via IIS Compression).
Strange Behaviour when Editing a SharePoint Search Resuls Page
As part of the the work that I do with my own company (MS-Advantage), I get to work on a lot of interesting projects, as well as work with a lot of interesting partner/development companies.
For example, currently I am doing some work on the side with a Graphic Design company who have been charged with developing the branding for a global web site. I basically provide them with guidance on how to best use and develop with SharePoint, while they do the leg work of developing the master pages and page layouts.
While I was working on the project yesterday, the customer indicated that the Search results page was returning sites and list information that they did not want to appear. To resolve the issue, I went into the search results page, edited the core results web part to add an additional query to the results (Query2 and isdocument:1, which basically says 'only show pages or documents').
Well I checked in a draft version of the search results page and started to test that it worked. As the results returned was exactly what I was after, I then published the page (so that it would get picked up in that night's content deployment job). After publishing the page however, every time I navigated to the search results page (even without providing a search keyword), the search results that I had previously used while testing were still being displayed. I tried to roll back to previous versions, but that didn't help. In the end I had to open up the page in SharePoint Designer, AND TO MY HORROR SharePoint had injected the results HTML into my web page. Once I deleted this and saved it, I was then able to re-publish the page.
For example, currently I am doing some work on the side with a Graphic Design company who have been charged with developing the branding for a global web site. I basically provide them with guidance on how to best use and develop with SharePoint, while they do the leg work of developing the master pages and page layouts.
While I was working on the project yesterday, the customer indicated that the Search results page was returning sites and list information that they did not want to appear. To resolve the issue, I went into the search results page, edited the core results web part to add an additional query to the results (Query2 and isdocument:1, which basically says 'only show pages or documents').
Well I checked in a draft version of the search results page and started to test that it worked. As the results returned was exactly what I was after, I then published the page (so that it would get picked up in that night's content deployment job). After publishing the page however, every time I navigated to the search results page (even without providing a search keyword), the search results that I had previously used while testing were still being displayed. I tried to roll back to previous versions, but that didn't help. In the end I had to open up the page in SharePoint Designer, AND TO MY HORROR SharePoint had injected the results HTML into my web page. Once I deleted this and saved it, I was then able to re-publish the page.
SharePoint Deployment Guide and Checklist
While I was at the SharePoint Conference in Seattle, I attended a session on 10 Steps to Governance (presented by Brian Cook and Joel Olesen). Just before the session started, Microsoft were handing out a little pocket guide called the SharePoint Deployment Guide and Checklist. It contained lots of useful information about governance plans, deployment checklists and deployment team roles.
When I showed it to a few guys I work with, they thought 'hey, where can I get a copy'. Well, I found it online at http://office.microsoft.com/download/afile.aspx?AssetID=AM102552101033.
So enjoy!
When I showed it to a few guys I work with, they thought 'hey, where can I get a copy'. Well, I found it online at http://office.microsoft.com/download/afile.aspx?AssetID=AM102552101033.
So enjoy!
Subscribe to:
Posts (Atom)