Search Results Blank in Windows SharePoint Services 3.0 (WSS 3.0)
Recently I experienced an issue where one of my WSS 3.0 sites stopped returning search results after having worked perfectly for a long period of time. I found that the Event Log had entries stating that the Search Gatherer service was failing.
Event Type: Warning
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2436
The first thing I tried was just to stop and start the search service and give it some time to index again. After a day or two, I returned to see that the same issue was occurring. The next step was to focus on permissions issues, but I did not understand why something that always worked would suddenly stop, since I had not made any changes to permissions on the system. The likely issue was a recent security patch on the server.
In the SharePoint Application Management back-end, I changed the account for the Search Indexer to my own login, but even my Administrator account was unable to index the site, having received the same error messages. I decided to just access the site in the browser on my web server and received an error 401.1 loading up the site. I was unaware that the search indexer even worked in this method, but apparently it was failing because it was unable to load the FQDN (fully qualified domain name) of itself using Windows Authentication.
I then was able to find a Microsoft Support Article which stated the following:
You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version
This issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.
There are two methods listed to fix this issue. I performed both methods by editing registry settings. The first method requires a reboot of the server. I did not want to reboot the server, but after making changes specified in method 2, the search indexer began to work, so I will assume method 2 is actually what fixed the issue.
Method 2: Specify host names
To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:
Set the DisableStrictNameChecking registry entry to 1.
Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
Quit Registry Editor, and then restart the IISAdmin service.
Asynchronously mirroring a SharePoint Content Database between Two Farms
Recently, I triumphantly setup an asynchronous content mirror between two separate SharePoint farms.
My SharePoint architecture consists of two separate farms in two different cities (San Diego and Las Vegas), both accessible over a corporate intranet. Each farm is unique and the configuration and administration databases contain unique information that cannot be mirrored from one site to another. The technique outlined below works, however, because the content databases are identical between the two sites and that is the only information that must be mirrored. One farm is a fail over for the other farm, so each farm contains the same sites.
After searching the Internet for information on how to mirror SharePoint data, I only found one MSDN article which stated that it should be done either with SQL Server clustering or with synchronous mirroring requiring a witness server. Eventually I found a picture in the MSDN showing a way to mirror only the SharePoint content databases between two farms asynchronously.
This picture outlined what I wanted, but I knew SharePoint well enough to know it was going to cause problems. I decided to try my hand at a solution, nevertheless. I started on the primary farm in Las Vegas, where I set up mirroring on the Sharepoint_Content database and mirrored it to the Sharepoint_Content database in San Diego, which was designated as the backup farm. By design, the San Diego content database was inaccessible while the mirroring was in place, so I had little chance of the backup farm actually loading up any pages. This was acceptable, however, because the backup farm did not need to work unless I failed over to it. I made some changes to my primary farm by adding a few announcements to a web part on a site and attached a picture to it. After some time, I decided to remove mirroring from the primary database. The reason I removed mirroring instead of doing a fail over, is because I could not have downtime on the primary farm. Nor did I want to take any chances breaking the database by reversing the mirroring if my technique did not work.
After breaking the mirror, the mirrored database showed as "Restoring.." until I ran the command: RESTORE DATABASE [SharePoint_Content] WITH RECOVERY.
This method is used to make the mirror available again as a stand-alone database. Once the database was available, I loaded up my SharePoint site on the fail over farm with my fingers crossed. As the page loaded, I saw a dreaded "Error 400 - Bad Request." I figured this would happen, as things are rarely straightforward with SharePoint. I didn't have time to address the issue so I decided to just restore from my most recent backup and put my experiment on hold. After issuing a restore command using stsadm, I saw a peculiar error which stated that it could not restore my site because no content databases were associated and suggested that I add a content database before proceeding.
Perhaps this could work after all! I loaded up the administration panel, found at http://servername:8080, and navigated to Content Databases under Application Management. The Sharepoint_Content database was listed as it should have been but I figured since it was not working as desired anyway, I could remove the SharePoint_Content database from the configurations and re-add it. First, I removed the content database and re-added a new content database with the same name and selected my SQL Server from the drop-down menu. I clicked OK and SharePoint updated its configuration. Soon the new content database was listed.
I hurried back to my site, refreshed the browser and to my delight, the page loaded and the announcements I had added in Las Vegas were displayed on the site running in San Diego. It was at this moment when I realized that this instance of making the impossible possible would be perfect fodder for my first blog post on netnerds.net.
IIS: Authentication Fails with Error Code 2148074254
Recently, we migrated a web application to a SharePoint server. The web application is a custom built ASP/ASPX app that supports Integrated Windows Authentication. We were able to run the application successfully using Anonymous Access but we were unable to authenticate from remote computers when Anonymous Access was disabled.
I checked the NTFS permissions and double checked the IIS properties for both the Web site and the Virtual directory and everything was setup properly. Different types of domain accounts, even Domain Admins, were attempted and none were able to login successfully from remote machines. Logging in from the server itself, however, worked just fine.
Our SharePoint sites which Windows Authentication and Kerberos were authenticating properly, so it wasn't the server. I checked the web server logs and saw HTTP 401 errors failing with the IIS specific code "2148074254." Searching the web turned up nothing useful. I tried a registry change and even rebooted the server to no avail.
I checked the server again -- local login works just fine, remote logins do not. I recalled experiencing something similar with another application I'd written and the problem had to do with Kerberos' restrictions on double-hop authentication. Maybe this site just needs an SPN?
I created a new application pool, assigned the web application to that pool and ran the pool as a domain user. I then created an SPN using the hostname of the newly migrated site.
Setspn.exe -A HTTP/vieval.domain.com domain\iisservice
Setspn.exe -A HTTP/vieval domain\iisserviceSuccess! Once the registration was complete, we were able to login to the web application. I find it surprising that the Kerberos setting is server-wide. Anyone know the reasons why?
SharePoint: Help with Choosing Between Site Collections and Sub-sites
I wish I had access to this resource when I was first working with SharePoint. If you get as confused as I do when trying to decide between making a site a Site Collection or Sub-site, check out this fantastic article on Steve Goodyear's Blog called Determining Between SharePoint Site Collections and Sub-sites. It even includes a nice lil flowchart for easy reference.
SharePoint Server 2007 SP1: Incorrect syntax near ‘COLLATE’ When Joining a Farm
While attempting to add a new Indexing Server to my firm's SharePoint farm using the SharePoint Products and Technologies Configuration Wizard, I ran into the following error when clicking Retrieve Database Names:
Incorrect syntax near 'COLLATE'
************** Exception Text **************
System.Data.SqlClient.SqlException: Line 1: Incorrect syntax near 'COLLATE'.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at Microsoft.SharePoint.PostSetupConfiguration.SqlSession.ExecuteNonQuery(SqlCommand command)
at Microsoft.SharePoint.PostSetupConfiguration.SqlServerHelper.DatabaseTableWithColumnExists(String table, String column)
at Microsoft.SharePoint.PostSetupConfiguration.SqlServerHelper.GetV3WSSConfigurationDatabases()
at Microsoft.SharePoint.PostSetupConfiguration.ConnectConfigurationDbForm.GetDatabasesButtonClickEventHandler(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)The SharePoint_Config's database and set to collation is set to Microsoft's recommended collation for a SharePoint farm: Latin1_General_CI_AS_KS_WS while SQL Server 2005's default collation on the master database is set to SQL_Latin1_General_CP1_CI_AS. For whatever reason, this is causing a very time consuming issue on our SharePoint farm. With the help of my SharePoint Consultant friend, Trevor, I was able to resolve it by doing the following:
- Ensuring the newly installed SharePoint server's service pack matched that of the farm. Initially, the RTM was installed on the server but the farm was running SharePoint Server 2007 SP1.
- Typing in the Sharepoint config's database name (SharePoint_Config) manually instead of relying on the "Retrieve Database Name" button to populate the drop-down list.
I know it's not a solution so much as it is a workaround but after three days of failed configuration attempts, I really just wanted it to work and that did the trick.
Shared Services Administration: Error: Access is Denied
This has come up a few times for me, so I'm documenting this mostly for myself. Sometimes, clicking on the SharedServices1 link results in:
Error: Access Denied
Current User
You are currently signed in as: MOSSERVER\AdminLogin
Surprisingly, I was using a domain admin account and still ran into this error. According to the MSDN forums, the resolution is as follows:
Central Administration >> Application Management >> Policy for Web Application >> Add Users >> Select the Web Application (All Zones) >> Web Application >> (Add the user) >> Full Control >> Finish
Additionally, you may also need to perform the following once you have permissions: SharedServices1 >> "User Profiles and My Sites" >> "Personalization Services Permissions" (Thanks, James!)
Microsoft Office Sharepoint Server 2007 Quickstart
Implementing and eventually developing Sharepoint 2007 (also known as MOSS) stuff is my next big project at 'work work'. It's been tough finding straightforward information on implementation but I finally did. First, Martin Kearn, an MCS Sharepoint guy based in the UK, wrote an outstanding four page guide (bulleted) titled "How to Install Sharepoint Server 2007 on a Single Machine." I adapted this slightly to use a small farm configuration. The only change I'd suggest for this guide is to use CNAME records in DNS instead of A records; it's a little less maintenance.
I also have a Sharepoint consultant friend, Trevor that shared a few tips. Here's what I've learned.
| 1. | Microsoft SharePoint: Building Office 2007 Solutions in VB 2005 (or C# edition) is the holy grail of Sharepoint 2007 books. Not only does the author Scot Hillier, a well-known Sharepoint Expert, discuss development, but much of the book discusses administration as well. He also talks about implementation for the first three chapters or so. In this book I learned that... |
| 2. | Kerberos isn't just more secure than NTLM, but it also performs a lot better. More secure was intriguing but better performance had me sold. |
| 3. | Wondering what to name your Sharepoint website? Many companies name their Sharepoint sites: portal, extranet/intranet or sharepoint. |
| 4. | A small farm configuration (2 machines - SQL & App/IIS) with powerful servers is good enough for companies with 500 employees or less. At least to start.. |
| 5. | Yes, many companies often run other small intranet sites on their Sharepoint IIS servers. I plan to as well. |
| 6. | Sharepoint 2007 is much more Internet friendly than Sharepoint 2003. Many companies are now using Sharepoint to power their Internet websites. |
| 7. | Fir those running MOSS 2007 in a lab environment, don't run it on a domain controller; it's been said not to work. |
Also, here's a list of my bookmarks tagged as sharepoint setup on delicious.
About
-
We are IT consultants
who grew up living and loving life
in Cajun Country.
Authors
Categories
What's Your Job Title?
Loading ...
information
wants to be free
