So there are a couple ways of presenting custom error pages to users. One approach is to directly edit the error page paths to point to your own on IIS and the other is to specify custom error pages in your asp.net application (whether this is in web.config, redirect in global.asax, or pageerror). I had a bit of experience with doing IIS custom error pages with non-asp.net apps; but for the most part, the convention for asp.net apps was to specify customErrors in web.config and redirects at the page level for more granularity.
When setting up IIS->WebSite->Properties->Custom Errors Tab->Edit HTTP Error and editing the page paths to point to a custom error page, this will get handled for non-aspx pages. So if someone types a non-existent *.html/*htm page, then they will be directed to the custom error page. However, if they specify a non-existent *.aspx page, they will see ASP.NET's 404 'The resource cannot be found Description: Http 404...'. This is because the aspnet_isapi.dll handles the .aspx extensions. So after editing the custom error properties on IIS, you would have been surprised by this default behaviour.
To keep it simple then, it would be recommended to just handle this in the web.config of your application. The other advantage of doing this is so that it reduces an extra step for IT Ops/Release Managers to take care of. If you really want to take it a step further and have consistent error pages regardless of someone heading to *.htm or *.aspx extensions, you can add application extension mapping by specifying aspnet_isapi.dll as the executable and .html as the path. There is a great article on it that goes into greater detail. Hopefully, this will alleviate some of the trial and error testing when dealing with this.
A BETTER approach is actually to edit IIS custom error properties if a "catch-all" approach for any file extensions is what you're after. To do this, for all original extensions that gets handled by aspnet_isapi.dll, make sure that 'check that file exists' is checked. Edit the paths for custom error properties on IIS and you should be set now. All errorCodes not handled in your application will now use custom error pages specified on IIS.
RANDOM THOUGHTS OF THE DAY:
Security
JavaScript security and best practices was on my mind today. You know how problems become more real to you when you actually see examples of it? (i.e. the first time you tried performing a sql injection on someone's web app after you started dealing with database driven web apps, read about it or were lectured on it). After you see it live, it becomes ingrained in your head. Well, I decided to find some case studies...
I was reading about Google's social networking service, Orkut, and all the security and vulnerabilities. Boy, there were problems and it ultimately resulted in a product that didn't take off.
Social Networking Companies
Curious about this company and social networking: http://doostang.com/. Apparently, this is by invitation only. The intent is to maintain the quality of people in the community. On the other hand, http://www.linkedin.com is a organization freely allows users to register.
Google Docs
I have been playing around with Google Docs lately. This latest addition to their "Office" suite is their document editing/sharing app. Their track changes/revisions feature has been pretty useful when two people are collaborating on the same document However, it looks like they need a bit more work on the yellow "Refresh". It is not very intuitive since it acts as a link but is non responsive. However, your document does get updated with the collaborators changes eventually.