Nice. Easy, graphical, find out if your domain/email has been naughty.

http://bsn.borderware.com/

And don't forget www.mxtoolbox.com

Ok, this week alone, I've run into two different scenarios, where I've gotten Application Event ID 2424 errors, when WSS Search is attempting to perform a search/catalog update.

Symptoms:


  • Search returns no results, but no errors either, in WSS - simply that no results were found, when there definitely should be something there.

  • Event ID 2424 and the error (along the lines of) "The update cannot be started because the content sources cannot be accessed. Fix the errors and try the update again. Context: Application 'Search', Catalog 'index file on the search server search'

Solutions (for me (this week, 2 different issues/2 different fixes)


  1. On one install, it was a brand new WSS site. All configured, all tuned, everything cool but missing SP1. Soon as I applied it and rebooted, my search started working - Whoopee! Happy.

  2. On the other install, it was a little more complicated but ultimately made perfect sense. My WSS server was on a private IP network (192.168.5.x). The URL I assigned it, instead of setting up a local web application and extending it (what I really should have done), actually resolved to the public IP of the site (67.44.44.x). Therefore, when search attempted to run, it itself was unable to *visit* the website, in order to search it. The quick fix was to resolve the IP's internally by modifying the local hosts file. The real solution will be to rebuild the sites (backup/restore collection) to local web applications, that are extended for public access.

I'll add more solutions, when/if I come across them. Hope this helps someone, somewhere.

Well, I helped solve this by accident, but mostly Zac came to this conclusion.

Problem:

You have a SharePoint list/form that you want to control the order of data entry into. No matter what way you order the columns in the list or view, it doesn't show them the way you'd expect.

Answer:

The column ordering is based on the content type's ordering, and then list settings ordering is applied after. I think the rules are that it applies the content type's ordering first, and then orders any additional columns that you have added later.

To change the ordering of the content type, you need to first enable the management of content types on that list (Advanced settings), then select the content type (Issue, in my case), and re-order the columns there.

Zac wrote and discovered it first, so it would be rude not to point out the reference :)
http://www.sharepointu.com/forums/p/1494/4056.aspx

Nice to be the boss. I gave my man Dougie my requirements and the skeleton for a script and he produced the rest. Download it if you want...

It provides an automated mechanism (that can be scheduled via your task scheduler) for WSS Site Collection Backups (multiple sites, via CSV selection list)

Download the script here - NOTE: you use this at your own risk. I'm just being a nice guy here. http://www.itgroove.net/central/Scripts/WSS.zip

Simply copy the script to your server, fill out the few required variables and modify the CSV file to suit. CSV format is as following:

ClientName,PortalURL,friendlyname

E.g.

itgroove,https://portal.itgroove.net:443,itgroovePortal

This dude has prepared a lovely and simple detail/method for hiding (don't remove!) the TITLE field in a SharePoint list, so why write it myself? :)

http://dlocc.com/sharepoint/35-customization/46-how-to-remove-the-qtitleq-column-from-a-sharepoint-list.html

Ran into some confusion today and found this fella's blog. Very useful indeed.

http://vmetc.com/2008/08/10/whats-the-difference-between-free-esxi-and-licensed-esxi

And this ESX vs ESXi comparison:

Ok, so this drove me bonkers. I'm not loving the workaround (basic authentication) but I'm happy enough, as I have an SSL cert protecting the site anyways, thus auth is secured.

But even after blowing away the web application and site collection, creating a new web application and restoring the site collection from backup, this problem would just reappear (errors below):

You are not authorized to view this page

You do not have permission to view this directory or page using the credentials that you supplied because your Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept.

HTTP Error 401.2 - Unauthorized: Access is denied due to server configuration.
Internet Information Services (IIS)

For me, what worked was this...

This was the article that got me thinking about the problem:
http://support.microsoft.com/default.aspx/kb/832769

And then I did this...

Configure Basic authentication (I disabled NTLM/Integrated, to get mine to work) on the Web application from SharePoint 3.0 Central Administration.

  1. Click Start, Administrative Tools, and then double-click SharePoint Central Administration.
  2. Click the Application Management tab, and then click Authentication Providers.
  3. In the Web Application list, select the Web application that you have to update.
  4. Click the Zone that you want.
  5. On the Edit Authentication page for the IIS Authentication Settings, Integrated Windows authentication, click Basic authentication (and uncheck or try/alternate with Integrated Windows Authentication turned off).
  6. To apply the change, click Save.


Find recent content on the main index or look in the archives to find all content.

Recent Assets

  • img_22491_windows_xp_logo.jpg
  • RBLCapture.JPG
  • Account_Lockout_and_Management_Tools.JPG
  • 9s-matrix.gif

Pages

Powered by Movable Type 4.1