August 2008 Archives

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:

Don't mind me, just bookmarking...

http://planetwilson.blogspot.com/2008/02/version-2-of-colour-calendar-released.html

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

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.

This from Zac Mullett today, blog ready, I just needed to cut and paste. Nice :)

I resolved the problem I was having where I would create a DataViewWebPart for one of our lists and get this:

The server returned a non-specific error when trying to get data from the data source. Check the format and content of your query and try again. If the problem persists, contact the server administrator.

It turns out that amongst the 100 fields the list has there was one that was tripping it up. That field just so happened to be a look-up to that list itself (self-referential). Whether or not it was because of the nature of the reference or some other spurious mal-formatted data is yet to be assessed.

Well this came in handy the other day…

Use this path, to connect to your local SharePoint Windows Internal Database (WIB) using SQL Server Management Studio Express (2005).

.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

(note: there are two backslashes at the front of that syntax that aren’t shown via HTML, so don’t forget those)

Hey,

When you've got it, flaunt it, right?

itgroove Testimonials, online and available.

http://www.itgroove.net/cms/index.php?option=com_content&view=article&id=1&Itemid=3

We recently encountered an issue where Terminal Services was installed on a Domain Controller, and an administrator would try and use the 'Connect To' feature built into Terminal Services Manager, but would result in error. Whenever an administrator tried to 'Connect To' a Terminal Server user session, the administrator would be prompted to enter the end user's password, and after doing so, an error message would pop up informing the administrator that a 'wrong password was entered', and event ID 1326 was logged in the application event log. The administrator in question had tried all sorts of group memberships and GPO configurations, but all resulted in failure.

Although not reported by Microsoft as a problem (pretty much no info on the net), through some testing, we were able to ascertain that the problem was being caused by permissions and restrictions, more than likely because of the server being a domain controller. The test results concluded that if the end user was an 'administrator', the 'Connect To' feature worked perfectly in Terminal Services Manager, which gave us a flash back of the 'Windows 2000, Log on Locally' privilege. Of course, ever since Windows 2003, there's been the introduction of the 'Remote Desktop Users' group, that by default, is not granted the 'Log on Locally' privilege (although it allows you to connect to the server with a TS client). As soon as we granted the 'Remote Desktop User's group the 'log on locally' privilege in the Default Domain Controller's Group Policy object...BAM!...everything was working with 'as expected' functionality.

Thanks to Avi for the write up :)