Dave's Technophorical Times

A blog about Microsoft's Technologies!
SharePoint :: MVC :: ASP.NET :: IIS :: SQL Server :: Visual Studio :: MS Access

I came across this error message when searching my SharePoint Foundation Site. I had already configured the Search and it is working so this message caught me off guard. Luckily I was able to find a quick solution for it before my demo that afternoon. 

To resolve this issue go to Central Admin. Under Application Management, click on Manage Web Applications, then click on Service Connections in the Manage section of the Ribbon. 

 

You may notice that it opens with the [default] settings that are all selected.

 

Click on the list and select the configuration you need to update. In this case it's the [custom] configuration.
Then simply click on the Search Service Application check box and click OK.

That's all there is to it, so hopefully this post will help someone else out there.

Thanks
Dave



While crawling SSL enabled web applications in SharePoint 2010, it may fail giving the following error.

Error message: An unrecognized HTTP status was received. Check that the address can be accessed using Internet Explorer. (WebExceptionStatus TrustFailure The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

This happens mostly when we implement self signed certs or certs from untrusted authorities in the web servers. In order to avoid the error message and to successfully crawl contents, make the following changes in farm level search settings in Central Administration.

  1. Go to Application Management > Search Service Application Settings > Farm Search Administration
  2. Change the setting “Ignore SSL warnings” from No to Yes.


When I was trying to deploy the SharePoint 2010 Web Part on a server using PowerShell, I got this error when I tried to run the Install -SPSolution command saying that:

Install-SPSolution: Admin SVC must be running in order to create deployment timer job

So all I needed to do was to go to the Services and look for the service called SharePoint 2010 Administration. It woill not be running so I switched it to Automatic and then started it. Then I was able to re-run my Installation script!



If you are annoyed at the IIS timeouts when running .NET code via Visual Studio then you'll want you know how to fix that problem!

You can do 1 of 2 things.
* Go to the Application Pool for the Web Application you are working with. Select the Advanced Settings. Set the Ping Enabled property to False. This will allow you debugging to run forever.
* If you prefer to allow IIS to continue the monitoring process then change the Ping Maximum Response Timeout value to something larger than 90 seconds (default value).

 



If you're getting this error when running backups via Central Admin in SharePoint 2010 then the most likely cause is that the SQL Server, where your Site Collections are, does not have access to the folder you are backing up to. Meaning, your Farm configuration is on multiple machines. Mine is on 2 machines. A Web Front End (where I run the backups from) and a SQL Server machine.

You probably configured the back-up to write to a lettered drive on the Web Front End. Don't worry, I did this too then I realized that it would be best to make a Shared Folder that has the correct permission so thet BOTH machines have access to write to the same location. Then it worked.

 



Error: Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled.

If you get this error in your Crawl search log then the problem is directly related to the infamous loopback Issue as described below.
You can also read more about this issue on another post located here: http://blog.dafran.ca/post/2011/07/04/Cant-log-into-SharePoint.aspx

The OFFICIAL Microsoft KB article describes the 2 different ways to resolve this issue.
http://support.microsoft.com/kb/896861

The following is copied from the KB link above.
There are two methods to work around this issue, use one of the following methods, as appropriate for your situation.

Method 1: Specify host names (Preferred method if NTLM authentication is desired)

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

  1. Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
    281308 (http://support.microsoft.com/kb/281308/ ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
  2. Click Start, click Run, type regedit, and then click OK.
  3. In Registry Editor, locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
  4. Right-click MSV1_0, point to New, and then click Multi-String Value.
  5. Type BackConnectionHostNames, and then press ENTER.
  6. Right-click BackConnectionHostNames, and then click Modify.
  7. 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.
  8. Quit Registry Editor, and then restart the IISAdmin service.

Method 2: Disable the loopback check (less-recommended method)

The second method is to disable the loopback check by setting the DisableLoopbackCheck registry key.

To set the DisableLoopbackCheck registry key, follow these steps:

  1. Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
    281308 (http://support.microsoft.com/kb/281308/ ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
  2. Click Start, click Run, type regedit, and then click OK.
  3. In Registry Editor, locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  4. Right-click Lsa, point to New, and then click DWORD Value.
  5. Type DisableLoopbackCheck, and then press ENTER.
  6. Right-click DisableLoopbackCheck, and then click Modify.
  7. In the Value data box, type 1, and then click OK.
  8. Quit Registry Editor, and then restart your computer.


I hope this helps someone out there!



After installing and configuring Search Server Express 2010 on Foundation I was unable to open the Search Service Application I had created in order to configure the crawling. To fix this problem you need to do the following.

  • Go To Central Administration
  • Under Application Management, click Manage Service Applications 
  • Highlight the Search Service Application Service that you can't get access to.
  • Click on Administrators in the ribbon
  • Add your account to the list of Administrators and then check the Full Control Check Box.
  • Click OK

Now you should be able to click on the Service Application and Administer it.

Hope this helps!



I had yet another one of those head banging on desk moments yesterday and then discovered the solution today! The problem was that I could NOT log onto SharePoint 2010 Foundation on the machine that was hosting the site (known as the WFE, the Web Front End) using the FQDN (Fully Qualified Domain Name), such as http://mydev.foobar.com. I could, however, log in just fine externally from the domain and even from a different machine in the same domain. I could also log into it on the WFE using the local machine name, like http://MyServer. No matter how hard I tried I could NOT log into the damned SharePoint site using the FQDN on the actual WFE. It prompted me for credentials which I entered correctly but it just kept prompting me.
 
I even had the network guys set up a zone on the DNS and create A Records etc. But still it wouldn't work. Not only that but the Search Engine Crawl failed for the FQDN and would only work for the Local machine name. So I went on a quest and found the answer. Rather than claim it as my own I have added the link to the article AND also added the resolution steps, just in case the article vanishes from the web! Don't you just hate it when someone posts something and all they do is say the answer is in this link, then the link is so old that it's gone! 
 
http://sharepoint.stackexchange.com/questions/5574/i-cant-login-to-sharepoint-2010-whats-wrong
For the record, this solved my issue on Windows Server 2008 R2 running SharePoint 2010. ALSO AS DC! :) For all you purists!
Disable the loopback check loadTOCNode(2, 'workaround'); Follow these steps:
1.    Click Start, click Run, type regedit, and then click OK.
2.    In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3.    Right-click Lsa, point to New, and then click DWORD Value. Type DisableLoopbackCheck, and then press ENTER.
4.    Right-click DisableLoopbackCheck, and then click Modify. In the Value data box, type 1, and then click OK.1.2.
RESTART PC!
 
This explains the reason why! http://www.harbar.net/archive/2009/07/02/disableloopbackcheck-amp-sharepoint-what-every-admin-and-developer-should-know.aspx

The OFFICIAL Microsoft KB article describes the 2 different ways to resolve this issue.
http://support.microsoft.com/kb/896861

The following is copied from the KB link above.
There are two methods to work around this issue, use one of the following methods, as appropriate for your situation.

Method 1: Specify host names (Preferred method if NTLM authentication is desired)

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

  1. Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
    281308 (http://support.microsoft.com/kb/281308/ ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
  2. Click Start, click Run, type regedit, and then click OK.
  3. In Registry Editor, locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
  4. Right-click MSV1_0, point to New, and then click Multi-String Value.
  5. Type BackConnectionHostNames, and then press ENTER.
  6. Right-click BackConnectionHostNames, and then click Modify.
  7. 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.
  8. Quit Registry Editor, and then restart the IISAdmin service.

Method 2: Disable the loopback check (less-recommended method)

The second method is to disable the loopback check by setting the DisableLoopbackCheck registry key.

To set the DisableLoopbackCheck registry key, follow these steps:

  1. Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
    281308 (http://support.microsoft.com/kb/281308/ ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
  2. Click Start, click Run, type regedit, and then click OK.
  3. In Registry Editor, locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  4. Right-click Lsa, point to New, and then click DWORD Value.
  5. Type DisableLoopbackCheck, and then press ENTER.
  6. Right-click DisableLoopbackCheck, and then click Modify.
  7. In the Value data box, type 1, and then click OK.
  8. Quit Registry Editor, and then restart your computer.


I hope this helps someone out there!



If you've ever configured SharePoint search in 2007 or 2010 then you may have come across this nasty gotcha.

In the SharePoint 2010 world your results would look like this! Nothing! But you know your search engine crawls correctly because you've seen it work and there are no errors in the log!

The reason why this happens is the Default URL is not the one used in the Search crawl. If you don't have this configured correctly then you'll get zero results returned. Not only that but you will see some very weird happenings. When I was playing around trying to understand the problem I did a search and frustratingly got no results so I decided to log in as a different user, and then I saw the results of the search! Wow, that was just silly, so I did another search, thinking it would now work. But no it did not. OK, I thought I would switch back to the previous user again, and guess what! Yes, I saw the results again. But then searching failed if I tried another search. It really stumped me to think that the only way to see search results was to do a search and then log in as a different users. That's what I mean about weird stuff.

The Default URL in this Alternate Access Mapping is used in the Search Configuration. So just following the configuration below is all you need to get results.

 

This is the Search Service Configuration. Putting it all together will now allow your search to work without even running a crawl! Brilliant. So I thought it would be good to blog about my experience so that others could save their sanity when I almost lost mine...Laughing

 



The following is an explanation of the 2 types of Authentication. This is well documented on the web!

Classic Mode: This is nothing but Windows Authentication. If any web application is created with Classic Mode Authentication then it cannot applicable to configure forms based authentication. That is basically it.

Claims Based: In SharePoint 2010 for a web application we can enable both windows AND forms authentication. In earlier implementation to do this, we have to create two web applications which has different zones and different authentication. But, with the new claims based authentication a single application can have the capability to configure both windows and forms under single URL. All this is possible because of the authentication framework is built on Microsoft Identify Foundation, and it uses “Geneva” framework to handle this authentication.

Convert from Classic Windows to Claims Based Authentication:  To configure a Windows Authentication application to use Forms Based Authentication then you can convert from Classic Mode to Claims Based. But, there is no UI exist for doing this conversion. The only way around is through PowerShell.

WARNING! This cannot be UNDONE!
At the PS Prompt Type the following commands and press enter after each one.

$app = get-spwebapplication "http://<your site's URL>"

$app.useclaimsauthentication = "True"

$app.Update()  Don't forget the brackets!

IMPORTANT:  If an application is created using Claims Based Authentication and if you want to convert to Classic Mode then it is not possible either through the UI or through PowerShell.



The Blogger

Dave Stuart I'm a Developer with a passion for coding. I enjoy the challengers that come with the job! SharePoint is one of my expert areas along with .NET Web Development with MVC and good old MS Access VBA coding. I Blog so that I can remember how I did that way back when; PLUS all this stuff is searchable! I constantly study and run my own business, Dafran Inc. I have passed 22 Microsoft Exams since 1998 when I first jumped on the treadmill of knowledge. I hope that you enjoy this Blog as much as I enjoy updating it. All the very best from Calgary, Alberta, Canada. contact me at linkedin @ dafran.ca

Calendar

<<  November 2017  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

View posts in large calendar

Sign in