Tuesday, October 22, 2013

Wow - holy lack of posts Batman!

I apologize for my lack of posts... it's a good thing actually, it means nothing has blown up in sharepoint for a long time...

More to come soon... just wanted to post an update.

Thursday, December 1, 2011

When in doubt, ask the wizard. :)

It seems the majority of problems with wsp's/solutions/search server express issues in my new environment were beautifully solved by running the SharePoint Products and Technologies wizard.

- Search wasn't picking up sites copied into the new environment - wizard run fixed this...
- My "capture site on delete" feature (http://governance.codeplex.com/) wasn't working quite right - wizard run fixed this...
- Alternate access mappings weren't resolving quite right  - wizard run fixed this...
- General "wonkyness"  - wizard run fixed this...

Perhaps these issues are demonstrative of a larger issue? But, in any case I had tried everything and finally decided to run the wizard. Life is good now and SharePoint is happy. Yay.

Wednesday, August 24, 2011

Automatic Tagging Based on Folder (Path)

I just stumbled across this today and it is going to prove to be extremely helpful in our SharePoint 2010 rollout. Do yourself a favor and check out Dean Virag's article at www.nothingbutsharepoint.com on "auto-tagging using folders in sharepoint".

Here --> https://www.nothingbutsharepoint.com/sites/eusp/Pages/Automatic-Tagging-Based-from-a-Folder-How-to-Get-Your-Users-to-Eat-Their-Vegetables-Without-them-knowing-it.aspx


Friday, August 19, 2011

Crawl Status with an ID of "5" (aka FORBID!)

I saw in the SharePoint Search database that one of my full crawl instances (#129) had a status of "5". A list of all crawls (current and previous) is in the MSSCrawlHistory table if you're curious...

(Yes! GASP! I look in the SharePoint databases - but I just look, I don't touch. Neither should you. Ever.)

I looked the status code up online (here: http://msdn.microsoft.com/en-us/library/dd957360(v=office.12).aspx) and found that meant "FORBID".

Now, luckily, the search service was returning expected results during this time, so there was no obvious user impact.

I looked in the table MSSCrawlURLLog in the search database and saw no items (success or fail) under that crawlid. Curious. Nothing was even tried - sounds like the forbid flag must have been thrown a little earlier than the item level - I definitely don't think this is a permissions issue now as [1] the permissions haven't changed in any way and [2] there are no permissions errors on individual items in the table (because there are no rows).

I went in to my WFE server's application log to the time when this crawl failed and sure enough, found these errors:

Event Type: ErrorEvent Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 10036
Date:  8/18/2011
Time:  6:00:01 PM
User:  N/A
Computer: myservername
A database error occurred.
Source: Microsoft OLE DB Provider for SQL Server
Code: 11 occurred 1 time(s)
Description: [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Event Type: WarningEvent Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2423
Date:  8/18/2011
Time:  6:00:01 PM
User:  N/A
Computer: myservername
The update cannot be started because all of the content sources were excluded by crawl rules, or removed from the index configuration.
Context: Application 'Search index file on the search server', Catalog 'Search'
 Unspecified error
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Turns out there was some sort of network error that prompted SharePoint search to fail, as reported in the warning shown just below it. I haven't been able to pin down the network error but I haven't had an issue since with search.

Thursday, August 18, 2011

JavaScript Error on Search (WSS 3.0 SP2 w/Search Server Express)

At #spstcdc 2011, one of the presenters encouraged sharing when you figure something out and I realized I should start blogging about my day-to-day with SharePoint. I've rec'd so much help from the community, I realized I should give back whenever I have useful (and hopefully accurate) tips and tricks to share.

So here goes.

I needed to move my search center website(s) to a new content database and did so without issue EXCEPT: when I went to perform a search, I started getting this JavaScript error (see below) when I'd try to submit my query keyword.

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.3; .NET4.0E; MS-RTC EA 2; MS-RTC LM 8)
Timestamp: Thu, 18 Aug 2011 13:35:13 UTC

Message: 'options' is null or not an object
Line: 564
Char: 9
Code: 0
URI: http://mysitenamehere/_layouts/1033/search.js?rev=yqBjpvg%2Foi3KG5XVf%2FStmA%3D%3D
I was puzzled to say the least. I thought "oh, I shouldn't have moved this search center site, what have I done?"

I checked all my monitors, services, etc - I was stumped.

Finally, I realized that the scopes drop down was missing from the page. Here, turns out all I needed to do was re-associate the scopes I needed with the search box and the advanced search box and VIOLA! All better.

So, if you see this issue in your own sites/farm and you stumbled across this post, hopefully I've saved you some time and some grief!